**** BEGIN LOGGING AT Thu Jan 21 02:59:57 2021 Jan 21 14:46:39 I want to set the default pin state for GPIO pin 8_17 on the P8 cape, so that its 'active low' by default. Is there an example device tree overlay someone could point me to, to get started? Jan 21 15:09:25 TonyTheLion: I'm pretty sure you mean "low", not "active low" Jan 21 15:11:00 "active low" / "active high" refers to the semantics of a logic signal (e.g. if a chip-select signal is active-low, that means that when the chip is selected (chip-select active) the signal is low and if the chip is deselected (chip-select inactive) the signal is high) Jan 21 15:11:33 also you mean the P8 header. (a cape is an expansion board you plug into the beaglebone) Jan 21 15:12:20 hmmm not sure if "low" is what I mean Jan 21 15:12:26 then explain what you mean Jan 21 15:12:59 I can only describe it by its feature, the pin is connected to a device that sets a pin low on interrupt, and then when the interrupt is finished it goes back to high Jan 21 15:13:15 okay, then you do mean active-low Jan 21 15:13:32 then referring to it as "pin state" is the problem Jan 21 15:13:49 wow semantics are hard :P Jan 21 15:14:47 I do mean the P8 header Jan 21 15:15:15 active-low/active-high is not any sort of hardware configuration, it's purely a software thing, and how to specify it depends on what the pin is used for. for gpios exported via sysfs it is indeed possible to configure them as active-low, meaning the "value" attribute will be inverted from its usual meaning Jan 21 15:16:26 hmmm, it appears tho, that for the leds for example, this is specified in the DT https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/am335x-bone-common.dtsi#L37 (example) Jan 21 15:16:35 and for a gpio used as interrupt signal for a DT-declared device you can generally specify whether it's triggered by low level, high level, rising edge, or falling edge Jan 21 15:17:24 yes, for many other DT-declared uses of gpios you can specify whether it's active-high or active-low Jan 21 15:17:33 it depends on the driver that consumes the declaration Jan 21 15:18:41 I noted that not all GPIO's are defined in the DT, this one I referenced has only P9 header GPIO's but no P8 header GPIO's. Does that mean the P8's are left in some undefined state, or configured otherwise? Jan 21 15:18:41 so there's multiple different answers to your question depending on context Jan 21 15:19:20 whether the pin is configured as active-low or active-high has no direct influence on its state Jan 21 15:19:29 it merely affects the semantic interpretation of its state Jan 21 15:21:40 when using a not-ancient image in its default configuration, the gpios corresponding to the P9/P8 header pins are by default exported by "gpio-of-helper" devices, which allow gpios to be declared/configured in DT for export to userspace Jan 21 15:22:30 you'll be happy to know I'm using a TI 4.19.y kernel :) Jan 21 15:22:54 this functionality, along with the ability for userspace to reconfigure pins at runtime (using config-pin), is known as "cape-universal" (even though it has nothing to do with capes) Jan 21 15:23:55 or the "universal overlay" (even though recently it isn't even an overlay anymore but a main DT variant: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am335x-boneblack-uboot-univ.dts Jan 21 15:24:00 ) Jan 21 15:24:44 do you mean rcn's 4.19-ti kernel series, or TI's 4.19 kernel series? Jan 21 15:25:08 (the latter seems unlikely, but I just want to be clear on that) Jan 21 15:25:47 rcn's Jan 21 15:26:24 is there a way to ask the system what DT its using? Jan 21 15:26:54 so, when you say you want the pin to be active-low by default, do you mean you're using it as gpio via sysfs and wants its active-low property to be set to 1 by default? (which inverts its value property) Jan 21 15:27:00 yeah, one sec Jan 21 15:28:02 when I say by default, I mean that active-low property is set from the moment its booted, and I don't have to manually go and change it on every boot Jan 21 15:28:16 I assumed, that making a DT overlay, would be the thing to do for that Jan 21 15:28:21 correct Jan 21 15:28:48 so, there's two options Jan 21 15:31:44 since you're using cape-universal, you can override just the gpio-declaration in the relevant child node of its gpio-of-helper device Jan 21 15:32:00 if I can find it, yes Jan 21 15:32:29 uboot at boot time seems to reference loading this /boot/dtbs/4.19.94-ti-r57/am335x-boneblack-uboot.dtb Jan 21 15:32:58 okay, so it's loading cape-universal from an overlay presumably Jan 21 15:33:13 from what I can tell that only uses am335x-bone-common.dtsi, which only has P9 header pins defined, but perhaps I'm not quite understanding what's going on here Jan 21 15:33:46 you can find which dtb you're using in /proc/device-tree/chosen/base_dtb Jan 21 15:34:03 and /proc/device-tree/chosen/base_dtb_timestamp for its compile-date Jan 21 15:34:37 and overlays applied are in /proc/device-tree/chosen/overlays (ignore the "name" property) Jan 21 15:34:50 ah I see, let me have a look Jan 21 15:35:30 okay base is: am335x-boneblack-uboot.dts Jan 21 15:36:06 I compiled it not so long ago so this seems correct: Mon Jan 18 18:58:09 Jan 21 15:36:22 why did you compile that? Jan 21 15:37:14 oh right Jan 21 15:37:19 custom-compiled kernel Jan 21 15:37:28 because I changed kernel version, by your recommendation a while back, and I was trying to play with things Jan 21 15:37:39 okay so overlays: BB-ADC-00A0 BB-BONE-eMMC1-01-00A0 BB-UART2-00A0 BB-UART4-00A0 Jan 21 15:38:52 you should normally not manually (re)compile standard dtbs, except implicitly as part of building a kernel or maybe when you're working on a bug fix to submit to rcn Jan 21 15:39:09 it gets recompiled as part of the kernel build Jan 21 15:39:35 yeah that's fine Jan 21 15:39:50 anyway, this sounds like you don't have cape-unviersal enabled Jan 21 15:39:58 but are using overlays for everything Jan 21 15:40:09 which is fine, but then no gpios are exported to userspace by default at all Jan 21 15:40:25 that (cape universal) would be in /boot/uEnv.txt right? Jan 21 15:41:35 instead you can use an overlay to explicitly declare gpios to be exported, and per gpio you'll be able to specify its name, whether it's active-low or active-high, whether it's by default input or output, if default output whether it's default low or default high, and whether userspace is allowed to change its direction (between input and output) Jan 21 15:43:25 right Jan 21 15:43:52 do you know of an example overlay I could base mine on, for a gpio? Jan 21 15:44:09 yes, one moment Jan 21 15:47:32 my overlay-utils has a gpio-demo.dtsi example Jan 21 15:47:46 I can convert it to bb.org-overlays compatible format if you prefer Jan 21 15:48:19 I'm not sure what the difference is Jan 21 15:50:16 my overlay-utils uses normal device tree snippets (like you'd use in a base dts) as input and preprocesses them using a perl script into an overlay .dts. it also uses different macros Jan 21 15:50:44 oh perhaps, the bb.org-overlay is easier for me to parse Jan 21 15:51:19 bb.org-overlays mostly still uses the raw overlay format, which is hideous and obnoxious Jan 21 15:51:36 dtc at some point gained the ability to itself perform some of the functionality of what my perl script does Jan 21 15:51:54 I'm assuming that's the default format you see in the kernel dts Jan 21 15:52:14 so overlay-utils is less necessary nowadays, though its input format is still cleaner than the best you can hope for with bb.org-overlays Jan 21 15:52:31 hold on, an example will clarify Jan 21 15:59:34 TonyTheLion: so, overlay-utils version: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi Jan 21 16:00:03 bb.org-overlays version for modern dtc: https://pastebin.com/7fdKLCZK Jan 21 16:01:49 bb.org-overlays version using raw overlay format (as originally required by dtc, and still used by existing overlays): https://pastebin.com/F4SV57NS Jan 21 16:02:58 that last one looks mostly like what I've seen in the kernel dts Jan 21 16:03:08 there are no overlays in the kernel dts Jan 21 16:03:24 I mean like the base ones, in terms of formatting Jan 21 16:03:30 the second one is the closest to kernel dts Jan 21 16:03:47 the last one is an obnoxious format specific to overlays Jan 21 16:03:50 I guess it doesn't matter too much, which one I use? Jan 21 16:03:52 lol Jan 21 16:05:22 sorry didnt mean to interrupt... the obnoxious comment made me laugh Jan 21 16:05:26 no, it only matters in terms of readability and ease of maintenance. use the second format if you attach great value to mainline-linux-compatible macros Jan 21 16:06:16 yea, that's what I'm going to use Jan 21 16:06:24 overlay-utils has the benefit of more concise macros that are more sanely named, and it automatically inserts the file identification block based on the actual filename (so there's no risk of that getting out of sync with the actual filename) Jan 21 16:06:38 the last format has no benefits, don't use it Jan 21 16:08:05 (but it's the ugly reality of what overlays look like behind the scenes) Jan 21 16:08:24 they weren't made with beauty in mind huh Jan 21 16:09:09 no, but that's fine.. more damningly is that dtc initially required the user to manually write overlays in that format instead of performing the transformation for you, like it does now Jan 21 16:09:18 that was the original incentive for me to create overlay-utils Jan 21 16:09:57 back then there were also less macros, most overlays used magic hex values instead, so I declared my own macros for max readability Jan 21 16:12:46 buzzmarshall: well it *is* obnoxious... especially the need to manually number the fragments Jan 21 16:13:43 I find these DTs confusing for a noob to wrap your head around Jan 21 16:14:10 i agree... being a hacker tho with no formal training i get lost with terminology sometimes Jan 21 16:14:13 if I had a lot of time to play with it, I could get my head around how to write them from scratch, possibly, but not otherwise Jan 21 16:14:17 the term kills me Jan 21 16:14:19 :) Jan 21 16:15:16 TonyTheLion: the overlay-utils one is the simplest to understand, it has the least boilerplate nonsense Jan 21 16:17:15 zmatt: my heads still buzzing tho with a couple of ideas after reading that gpio discussion cause i do agree with your thoughts Jan 21 16:17:17 TonyTheLion: it creates a gpio-of-helper device at /gpio-demo (name is arbitrary as long as it doesn't conflict with anything else) containing declarations for four example gpios Jan 21 16:18:06 it also creates a pinmux node for these four pins and attaches it to the gpio-of-helper device as its "default" pinmux state Jan 21 16:18:23 the four gpios are just four examples showing off different config options Jan 21 16:22:36 TonyTheLion: the second version I gave modifies it to use mainline macros (with corresponding #includes) and adds the necessary boilerplate at the top to allow it to be compiled using the bb.org-overlays Makefile instead of the overlay-utils one Jan 21 16:26:38 TonyTheLion: if there's anything specific that's unclear, just ask. Jan 21 16:30:52 I also have general notes about dts: https://pastebin.com/XC8vB33d Jan 21 16:31:54 zmatt: while looking at QT based stuff on the BBB i came across what appears to be a older gui based frontend for i/o's called BBIOConfig is that still relavent or just something from the old days? Jan 21 16:32:37 never heard of it Jan 21 16:32:45 based on the discussion between you and pdp7 i seen mention of a nice looking graphical tool Jan 21 16:32:56 make me recall it Jan 21 16:32:57 k Jan 21 16:33:41 looks like it generates output for config-pin, not a device tree Jan 21 16:33:54 i liked the idea of a tool Jan 21 16:34:42 and wondered if something sim to that which could be expanded on to include the creation of tree stuff as well Jan 21 16:35:14 yeah, though maybe something web-based would be smarter, to accomodate users of all platforms Jan 21 16:35:49 there's way more to generating a dts than pinmux though Jan 21 16:36:08 web based would be nice as i plan to keep a web server on the bb's even on a stripped down os Jan 21 16:36:53 when i am done i need the bb's to be able to use the web interface for the drv8711 drivers i use on my motor drivers Jan 21 16:37:20 but yeah, I'm sure it could be really nice and user-friendly, if someone has the necessary web UI development skill and wants to put the time in Jan 21 16:37:25 and i really like the idea of a better graphical front end to tree stuff as well Jan 21 16:40:29 well... im still researching and looking at other ideas for some unrelated things to see if i can pull peices from things while i pick away at the kernel and getting usb off the pio mode and have a couple of buds that are really into the web ui stuff that i am sure would be interested in a project Jan 21 16:41:49 I have a feeling that a good UI for this will not be a small amount of work Jan 21 16:42:37 few good things are Jan 21 16:44:28 hmmm so I've made the overlay, how would I be able to tell if it worked, ie that it set the gpio to "active-low" Jan 21 16:44:38 would that show up in the sysfs entry on the gpio? Jan 21 16:45:11 I mean, first of all you'll have sysfs entries for your gpios, which I assume previously you did not (since cape-universal is disabled) Jan 21 16:45:30 and yes if you inspect those you'll find they have been setup as declared Jan 21 16:45:47 I'm talking about /sys/class/gpio Jan 21 16:45:51 so am I Jan 21 16:46:46 by default that pin is not there, I have to "echo 27 > export" it Jan 21 16:47:24 which should now be no longer the case (and in fact attempting to export it may cause it to disappear due to a bug) Jan 21 16:47:31 (in addition to giving an error) Jan 21 16:47:41 for the gpios declared in DT that is Jan 21 16:50:28 I guess it didn't work then, cause it isn't default listed Jan 21 16:50:40 you sure the overlay got loaded? Jan 21 16:51:32 (check in /proc/device-tree/chosen/overlays/ ) Jan 21 16:52:45 its not listed in there, but another overlay I have (for a gio-key) is also not listed there, but is loaded, because the /dev/input directory exists for it Jan 21 16:53:02 did you put a file identification fragment in it? Jan 21 16:53:21 those entries in /proc/device-tree/chosen do not appear magically, they're created by the overlays themselves Jan 21 16:53:50 and while overlay-utils automatically adds a suitable fragment for you to ensure it gets created, bb.org-overlays does not Jan 21 16:54:17 I ended up using your overlay-utils one Jan 21 16:54:53 then it will appear if it got loaded by u-boot Jan 21 16:55:42 (note that instead of using a bunch of different overlays for different things you can also just put all your stuff in one overlay) Jan 21 16:56:19 perhaps that is a good idea Jan 21 16:57:26 when using overlay-utils you can just literally concatenate sources to make one larger one... that's not quite true for bb.org-overlays Jan 21 16:58:59 okay I appear to have successfully merged the two Jan 21 17:03:02 but it still doesn't list in in /proc/device-tree/chosen/overlays Jan 21 17:03:10 tho during boat it claims to be loading it Jan 21 17:03:15 boot Jan 21 17:03:27 what did you merge exactly? Jan 21 17:03:50 since it sounded like you weren't using overlay-utils previously? Jan 21 17:03:56 but maybe I misunderstood Jan 21 17:04:37 if you were already using overlay-utils, make sure it's uptodate Jan 21 17:10:15 I changed my mind about using overlay-utils, at first I was going to use one of the other ones, but then I remembered I already had an overlay based on overlay-utils so that's what i'm using Jan 21 17:10:59 okay so if you already had some checkout of overlay-utils, make sure it's uptodate (git pull) Jan 21 17:11:26 ye, did that Jan 21 17:11:33 shows up in chosen/overlays now :) Jan 21 17:11:49 so your checkout was more than 15 months old :P Jan 21 17:12:02 (which is when I added that functionality according to github) Jan 21 17:12:05 ye I wouldn't have updated that unless I needed to Jan 21 17:12:17 I don't touch what works unless I have to Jan 21 17:12:25 makes sense Jan 21 17:12:53 /sys/class/gpio still doesn't have my pin by default tho Jan 21 17:13:17 export gpiochip0 gpiochip32 gpiochip64 gpiochip96 unexport Jan 21 17:13:22 do none of the pins used conflict with any of the other overlays you have enabled? Jan 21 17:14:12 so my overlay (that I made) uses pin 0.26 and 0.27 Jan 21 17:14:24 those are gpio numbers, not pins :P Jan 21 17:14:39 aaahhhh terminology Jan 21 17:15:01 important terminology though since I *am* talking about pins Jan 21 17:15:30 i'm not sure I see the distinction Jan 21 17:20:21 TonyTheLion: https://photos.app.goo.gl/9Ph5ABujjCRTst9g9 Jan 21 17:21:54 there are four gpio controllers, each with 32 gpios (though not all of them actually in use) Jan 21 17:22:48 pins can be muxed to various functionality, one of which is (usually) a gpio of some gpio controller Jan 21 17:24:03 on the am335x nearly all pins have a gpio mode, and each gpio is connected to at most one pin, so _on the am335x_ you can use gpio numbers to identify pins... but that's definitely not always true Jan 21 17:24:34 (on the am572x not all pins have gpio mode, on the dm814x some gpios are connected to more than one pin) Jan 21 17:24:36 ah i see Jan 21 17:25:02 gpio controllers and other peripherals are also completely oblivious to pinmux Jan 21 17:25:32 it's your responsibility to attach a pinmux node to the device that configures pinmux appropriately for the pins used by that device Jan 21 17:26:21 like the comment in gpio-demo says, this is not _strictly_ needed for gpio mode since that's the default after reset anyway (on the am335x, though not on the am572x), but it's highly recommended to explicitly configure pinmux anyway Jan 21 17:26:24 so PIN_PULLUP(P8_17, 7), the '7' is the pinmux mode right? Jan 21 17:27:02 yes, and the PULLUP means internal pull-up is enabled. in most cases it's a good idea to just use whichever pull direction is default for that pin Jan 21 17:27:16 hmm, I should add that in comments in bone/black.h Jan 21 17:28:11 maybe Jan 21 17:28:56 I know that pinmux 7 is 'gpio' Jan 21 17:28:57 P8.11-P8.19 all have default pull-down Jan 21 17:29:00 or at least that is my recall Jan 21 17:29:12 yes, 7 is gpio for all pins on the am335x that have it Jan 21 17:29:35 (which is all but a few special-purpose ones like the reset line, jtag pins, etc) Jan 21 17:30:18 for other pinmux modes, see the P9/P8 tabs of my spreadsheet.. https://goo.gl/Jkcg0w#gid=1847985463 Jan 21 17:33:04 (in the column right next to the pin number it indicates default pull: L = default internal pull-down, H = default internal pull-up) Jan 21 17:37:41 TonyTheLion: since you were previously using an older overlay-utils, I recommend reading this commit message: https://github.com/mvduin/overlay-utils/commit/edad7ca48a79518a72d0df6b9bc4240a7166d945 Jan 21 17:38:25 also this: https://github.com/mvduin/overlay-utils/commit/b30d3333db7a63fc891d27cc4bfd81416b1f7050 Jan 21 17:39:13 for both of them I've made sure to keep backwards compatibility, but you may want to update your old overlay to the new preferred ways Jan 21 17:39:27 ah okay Jan 21 17:52:30 I amended my overlay to match your changes in the those commits Jan 21 17:52:51 I put it as pulldown now, but it doesn't show up in /sys/class/gpio Jan 21 17:53:24 that will have no influence over that. the only logical reason I can think of is a pinmux conflict, i.e. you're trying to set pinmux on pins already claimed by another overlay Jan 21 17:53:36 that *should* result in an error in your kernel log indicating this Jan 21 17:53:47 you can also use show-pins to check if the pins you want to use are in fact already in use Jan 21 17:54:55 if that isn't it, please share your overlay source code (or at least the declaration of your gpio-of-helper device and its pinmux) Jan 21 17:55:16 checking kernel log for errors is a good idea in general of course Jan 21 17:55:33 is show-pins a cmd line utility? Jan 21 17:55:40 https://github.com/mvduin/bbb-pin-utils/#show-pins Jan 21 17:56:03 I somehow assumed I've previously pointed you to it Jan 21 17:58:26 that's a neat utility Jan 21 17:58:47 it doesn't show as that gpio (0.27) as being used by anything Jan 21 18:09:37 okay so here is my overlay https://pastebin.com/Wp3ChMMr Jan 21 18:09:57 my internet connection had a hickup Jan 21 18:12:44 oh I just realized, since this is an active-low interrupt line you'll probably actually want PIN_PULLUP for it (regardless of the default) ... but that's just a minor thing, not related to it not appearing Jan 21 18:13:10 does the gpio-test device show up in /sys/bus/platform/devices/ ? Jan 21 18:15:02 also, since you're using a custom kernel, check: grep CONFIG_GPIO_OF_HELPER /boot/config-$(uname -r) Jan 21 18:28:43 it does show up in /sys/bus/platform/devices Jan 21 18:29:15 # CONFIG_GPIO_OF_HELPER is not set Jan 21 18:29:50 welp, problem found: your custom kernel config Jan 21 18:30:26 omits the gpio-of-helper driver Jan 21 18:36:46 ahah Jan 21 18:37:26 like, pruning your kernel config of "unnecessary" drivers is fine... if you're sure they're actually unnecessary ;) Jan 21 18:38:31 especially if they're =y in rcn's config (as opposed to =m) you'll want to double-check that Jan 21 18:55:26 is anybony can help me? my BB black v2.5 doesnt boot I tried several things to fix it using SD card when I plug in debug it stall at this line "image entry point: 0x80800000" only one red led if on nothing else happen Jan 21 18:55:52 there's no such thing as a "BB black v2.5", and the BBB has no red led Jan 21 18:57:11 in fact I don't know of any official beaglebone variant with a red power led Jan 21 18:57:48 its r Jan 21 18:58:20 its write on it beaglebone_Black_v2.5 Jan 21 18:58:55 then it's presumably some company's custom bbb-derived board on which they rudely wrote "beaglebone black" despite this being a trademark violation Jan 21 18:59:01 and there's a red led right beside the eth port Jan 21 18:59:12 (e.g. those antminer things) Jan 21 18:59:31 it's not a beaglebone black, it's not a beaglebone Jan 21 19:00:06 where did you get it, and can you post a photo? Jan 21 19:00:07 yep its a antminer thing that I want to reuse Jan 21 19:00:15 ah Jan 21 19:01:09 yeah people have meanaged to do so, but you're basically on your own. these boards are not supported by beagleboard.org and it's basically pure luck if some beagleboard.org image happens to work on it Jan 21 19:01:52 if it's using an am3358, it shouldn't be _that_ hard to make it do something Jan 21 19:02:06 or, alternatively, doing so may damage the hardware (immediately or slowly in the long run)... this because the board id of these boards claim they're a BBB but they're not actually hardware-compatible Jan 21 19:02:30 sure, but ideally you'd want the schematic for that so you can make a proper DT Jan 21 19:02:46 for sure Jan 21 19:02:54 but since these are proprietary products, no schematic is available Jan 21 19:03:28 ok I understand.. Jan 21 19:04:39 you're not the only one though, plenty of people get these boards for very cheap or free (and "free" is really the only right price to pay for them)... maybe if you manage to find each other and pool your efforts you can get these boards working properly ;P Jan 21 19:05:31 to get them working properly you'll want to build a custom u-boot and get that into the NAND flash of this thing Jan 21 19:06:03 which ignores the board id and uses a DTB name specific to these boards Jan 21 19:06:30 or reprogram the board id Jan 21 19:07:02 or that Jan 21 19:07:10 and of course you'd need to make that dtb Jan 21 19:08:10 you'll want to make sure u-boot does not think there's eMMC, since there isn't Jan 21 19:08:50 alternatively, and much simpler, you could try to override the sysboot pins to get it to ignore NAND flash entirely Jan 21 19:09:07 or remove the flash chip Jan 21 19:09:09 use a bb.org image but with /boot/uEnv.txt configured to disable eMMC and disable video Jan 21 19:09:12 then it'll be ignored for sure Jan 21 19:09:33 well, if you change sysboot then that's not needed, and if you don't change sysboot that won't result in a booting system Jan 21 19:10:21 main reason to do that would be to free up those expansion header pins, assuming the corresponding processor pins are routed to the expansion headers at all (in addition to being connected to NAND) Jan 21 19:11:31 first ask yourself if all that effort is worth the cost of a real beaglebone Jan 21 19:11:32 LoRdMiCk: I know people have reported some success with running bb.org images, so it's possible that even in default configuration the system's assumption that the board is a beaglebone black does not result in hardware damage Jan 21 19:12:43 ok even if I don't answer I read everything and do reseach and test :P you give me good direction.. Jan 21 19:12:51 im still there :P Jan 21 19:13:07 so I guess step 1 would be to try overriding the sysboot0-4 pins Jan 21 19:13:17 to configure it to ignore NAND and boot directly from sd Jan 21 19:14:02 (or maybe first measure their voltage while the board is held in reset, that may give a good hint whether they're even connected to the processor at all) Jan 21 19:14:06 see https://goo.gl/Jkcg0w#gid=1847985463 Jan 21 19:14:21 (lcd d0-d15 == sysboot d0-d15) Jan 21 19:14:47 (this is the right-side header when the Ethernet connector is pointing up) Jan 21 19:15:17 the meaning of the sysboot pins can be found on the Boot tab of the same spreadsheet: https://goo.gl/Jkcg0w#gid=750891223 Jan 21 19:17:33 on the beaglebone black sysboot 4-0 are 11100, on this board they're presumably one of 01011-01101 or 10010-10101 Jan 21 19:17:56 like mru said, do ask yourself is this is worth your time Jan 21 19:18:09 even if you get them fully working, they're still crap boards Jan 21 19:18:23 especially since afaik they use am AM3352 instead of AM3358 Jan 21 19:18:26 yeah thats what im asking myself right now Jan 21 19:18:28 (that will be marked on the processor) Jan 21 19:19:14 I have a bbb with a mislabeled chip Jan 21 19:19:18 3352 Jan 21 19:19:19 specifically the BBB uses an AM3358BZCZ100 Jan 21 19:19:26 don't think there were many of those made though Jan 21 19:19:39 mru: yeah some early protos were mislabeled Jan 21 19:20:01 am3352bzcz100 Jan 21 19:20:15 so it's missing pru and some other stuff Jan 21 19:20:28 well at least it's a 1 GHz part instead of a lower speed bin Jan 21 19:21:26 but yeah, no PRU (which is the coolest feature of the BBB) Jan 21 19:21:47 also no 3d gpu but that's less relevant since I'm guessing it doesn't have video output in the first place Jan 21 19:22:19 no gpu at least has the upside of sparing you the trouble of trying to make it work Jan 21 19:22:24 hehehe Jan 21 19:22:49 after which you'd find it sucks anyway Jan 21 19:25:03 LoRdMiCk: so, here's min-effort attempt to get it working: download a recent beagleboard.org sd card image for AM335x (either IoT or console) and flash to microsd card. mount it on a linux system and edit its /boot/uEnv.txt to uncomment the lines disable_uboot_overlay_emmc=1 and disable_uboot_overlay_video=1 Jan 21 19:26:58 use wires to connect P8.41 and P8.44 to 3.3V (available on P9.03 and P9.04), and connect P8.43, P8.45, and P8.46 to ground (see P9/P8 pinout diagrams for where you can find ground) Jan 21 19:28:13 if this doesn't result in a system that boots, expect having to invest a lot of time to get the board to work Jan 21 19:29:19 if you neglect to uncomment disable_uboot_overlay_video=1 you'll be shorting out multiple pins and have a decent chance of damaging the hardware Jan 21 19:30:47 (assuming it manages to reach the point of loading the kernel from sd card) Jan 21 19:33:19 and with that I think I've reached the quotum of how much time *I* want to spend on this... but I would appreciate hearing back whether or not it works, if you choose to attempt these steps... so I know in case more people show up Jan 21 19:33:35 with the same problem Jan 21 19:34:02 ok I give it a try.. it will take some time as I want to be sure of what i do.. Jan 21 19:34:04 you're the second one in a very short time though, did a bunch of these boards get dumped somewhere or something? :P Jan 21 19:34:57 yea many antminer getting old so poeple juste trow it away.. Jan 21 19:37:20 you could try asking the company for the schematic... this control board isn't really a relevant piece of intellectual property for them, it has no market value, and it would be better for the environment if these boards can be reused for some new purpose instead of just ending up in the bin Jan 21 19:37:39 maybe if you phrase it the right way they could be convinced Jan 21 19:43:02 then again, they're a chinese company and most questions on their support forum seem to go unanswered Jan 21 20:09:32 humm I get CCCCCC as soon as i put the power on Jan 21 20:09:58 that's a good sign most likely Jan 21 20:10:23 that means it's attempting xmodem boot via uart 0 Jan 21 20:10:57 which, in particular, means it did not attempt to boot from NAND Jan 21 20:13:39 as far why it didn't boot from sd card, three options: 1. one or more of the sysboot lines is wrong, resulting in sd card (mmc 0) not being in the boot order, 2. the sd card is not bootable (e.g. misflashed, though that doesn't seem likely if you were able to mount it after flashing), 3. the sd card slot is not on mmc 0 on this device (but e.g. mmc 1) Jan 21 20:14:28 option 3 seems very unlikely Jan 21 20:19:50 lordmick2: did you catch what I said or did you lose some chat due to reconnection? Jan 21 20:22:14 for reference: https://pastebin.com/RpKdpX89 (P8.45 does not need to be connected to ground like I said earlier; while it does affect boot order, both options are fine) Jan 21 20:26:12 <@zmatt> that means it's attempting xmodem boot via uart 0 Jan 21 20:26:23 that was the last part before disconection Jan 21 20:26:53 https://pastebin.com/iLNNVLmK Jan 21 20:29:16 actually I did what you tell me.. and i'v been able to bring it back with the "original" antminer boot image Jan 21 20:29:36 what changed? Jan 21 20:31:13 between getting CCC and being able to boot the original image (from NAND I assume?) Jan 21 20:31:31 it boot like it should (antminer thing) before it was not doing anything.. Jan 21 20:33:19 (as in, what did you change to get a different result?) Jan 21 20:33:34 now I need to find the right image and try to reflash Jan 21 20:33:51 i don't know why ma sdcard was not bootable Jan 21 20:34:25 oh you mean you were able to boot an antminer boot image from sd card? Jan 21 20:36:00 you're being really unclear about what actions you did to get what results, which makes it really hard for me to know what conclusion to draw Jan 21 20:36:05 yeah with the mod you tell me in the uEnv.txt and by connecting P8.41 and P8.44 to 3.3V, and connect P8.43, P8.45, and P8.46 to ground Jan 21 20:36:57 the /boot/uEnv.txt mod was for normal beagleboard.org images though, I wouldn't even expect those settings to exist on an antminer image Jan 21 20:37:45 though maybe it bizarrely does, who knows.. doesn't hurt to have 'em either way Jan 21 20:38:19 I actually don't know if it help but I put those line in the uEnv.txt in the antminer image.. Jan 21 20:38:53 almost certainly they do nothing in the antminer image Jan 21 21:09:58 LoRdMiCk: if you just want a minimalist debian system, get the buster console image from https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console Jan 21 21:10:13 probably should have linked to that earlier :P Jan 21 22:31:21 he may be able to glean what he needs from hxxps://github.com/bitmaintech/Antminer_firmware but its probably not worth the time... ive a bud that picked a couple up from some recycler and was driving me nuts trying to adapt and make it work on buster Jan 21 22:31:30 not worth the time Jan 21 22:32:36 I mean, depends on your viewpoint.. if it can allow hardware to be put to good use again instead of throwing it in the bin, some may find that worthwhile just from an environmental perspective or something Jan 21 22:32:52 and for some people it will be much faster/easier to get these working than others Jan 21 22:33:18 if you got a batch of 100 of these for cheap you'll probably be more motivated to figure out how to get them working well ;) Jan 21 22:36:43 if you can do the work yourself i would agree... but cause he's cheap and see's the bbb as overpriced compared to things like the rpi4 and wants to bug me i see it as a waste as i can find better things to do Jan 21 22:38:25 if i was actually interested in them tho, i would spend the as i agree i hate to see stuff in the bin as well Jan 21 22:40:45 buzzmarshall: the antminer thing isn't a substitute for a BBB even if you get it working perfectly anyway Jan 21 22:41:04 i got into the ti's based on interest in the pru's and sick of fighting with vendor bsp's and the lack of full docs on lower level stuff otherwise i'd not be taking on learning someone else's SoC Jan 21 22:41:53 if he considers BBB overpriced compared to rpi4... he can just use an rpi4, why care about some antminer thing? Jan 21 22:46:41 he's got a bud thats a recycler that had bunch of them so he got them for next to nothing and figured he could use them for some robotic stuff he's into Jan 21 22:49:35 if i wasnt busy doing what i am i would probably be a bit more keen in them... initially i looked a one as i was gonna pop the sitara off it and design a board around it as i have all the required tools here to handle stuff like that Jan 21 22:51:05 in the end i just bought a bbb to move ahead and will worry about a new board down the road as i may just go the way of using the ai and cape in the end rather then design and create a new board Jan 21 22:59:13 designing a board around the am335x is non-trivial, with the ddr3 memory and such Jan 21 23:00:19 and if you're gonna do that, you wouldn't want that am3352 with its lack of pru Jan 21 23:03:24 buzzmarshall: so you have seen this thing? ;) https://twitter.com/pdp7/status/1100349116515827712 Jan 21 23:09:19 ya i came across that awhile ago while intially looking at the TI stuff Jan 21 23:09:39 over the years ive used alot of ti stuff just not their soc's Jan 21 23:10:06 the osd335x-CSiP doesn't make huge sense to me though, compared to using the osd335x-sm + external eMMC Jan 21 23:10:07 and while looking at existing boards i kinda found out from them while looking at the replicate boards Jan 21 23:10:28 which i couldn't get Jan 21 23:10:44 but i like the stuff i had seen about the pru's Jan 21 23:10:54 the PRUs are cool Jan 21 23:10:59 so the bbb's tho stuck in my head Jan 21 23:11:42 so i kinda just landed on them and then i grabbed a ai as well which ive not even taken out of the box yet Jan 21 23:12:59 the PWMSS peripherals are nice too... like, PWM with 10ns resolution for the duty cycle and eCAP with its ability to measure pulse width and pulse distance with that same resolution Jan 21 23:13:14 (or 5ns resolution for the PRUSS eCAP) Jan 21 23:13:27 my current goal is in motion control (cnc) and ive already designed my own motor drivers around ti's drv8711's so the bbb or at least a sitara seemed like a nice fit Jan 21 23:13:51 ya i can't wait to get a bit more up to speed and then start playing with the prus Jan 21 23:15:15 most of the better/higher end motion stuff is using pc cards driven by a fpga to get the timing they need Jan 21 23:16:09 the more i learn about the sitara's i think the bb stuff can hit a similar area without the fpga and have more benifits then having a pc and card to a machine Jan 21 23:17:51 i like assembly as pretty much since the atmels came out in the old days that was the way to go and even tho bitsizes are wider these days i think i can leverage against all those years of assembly coding in reqards to the pru's Jan 21 23:17:56 at least thats my hope Jan 21 23:18:09 and if not i learned some more crap Jan 21 23:18:10 lol Jan 21 23:18:10 if anything, pru assembly will be more comfortable Jan 21 23:19:33 with its 31 32-bit registers and highly regular instruction set Jan 21 23:20:26 ive been slowly going over some of the docs as i take breaks from this part and it looks not to bad Jan 21 23:20:27 (31 32-bit general-purpose registers I meant, it has 32 registers of course but r31 isn't a normal register) Jan 21 23:21:24 i was grabbing stuff off ti's server but then they archived a bunch of stuff recently so ive got tons of info to go thru Jan 21 23:24:08 i seen the octavo last year when it came out and grabbed some of the osdxxx docs but then seen the replicate stuff but got sick of waiting for it to be available and they then changed to something else Jan 21 23:24:29 but that put me down the path of the beagles which i kinda now like Jan 21 23:25:26 replicate? you mean replicape (now "recore" using some allwinner soc and a bunch of microcontrollers) Jan 21 23:25:32 ? Jan 21 23:25:49 replicate was originally a custom cape for the bbb Jan 21 23:26:07 for 3dprinters Jan 21 23:26:25 kinda like the smoothy and some of the other upper end printer boards Jan 21 23:26:27 again, you mean "replicape" ? Jan 21 23:26:32 rather than "replicate" ? Jan 21 23:26:39 sorry brain fart Jan 21 23:26:41 yes Jan 21 23:29:45 i need higher amp for motors and hate the idea of drivers on board as well Jan 21 23:30:06 how so? Jan 21 23:30:31 most peeps don't have equipment to fix very easily Jan 21 23:31:08 and the machines i have use at least nema 34 motors which are heavier then the typical printer stuff Jan 21 23:31:28 oh, in case they're fried? I guess protecting them adequately might be difficult Jan 21 23:31:48 my machines are typically 34 x 24 x 28 build tables Jan 21 23:31:54 and 4 colors Jan 21 23:33:00 after i built the mechanical machine i realized there was no real pre built control system around Jan 21 23:33:20 not without goin way up into real cnc control stuf Jan 21 23:34:25 i was forced to build drivers that could handle the motors i used which i don't mind as i like to learn and play Jan 21 23:35:01 and after years of atmel coding came to see them being useless for what i wanted Jan 21 23:35:46 atmels are pretty much driving the 3dprinter scene these days tho i do see some movement finally to the stm32 platform Jan 21 23:36:40 they're cheap and ubiquitous I guess Jan 21 23:36:52 yes Jan 21 23:37:20 stm32 sounds more pleasant, although its pinmux can be obnoxious iirc Jan 21 23:37:42 cheap is the thing and even cheaper makers blasting out crappy printers are leveraging all their controls against the stuff Jan 21 23:37:57 so there all pretty much in the same boat with buggy and slow software Jan 21 23:38:36 plus trying to expand the printers with more peripherals is tough as the boards are already squeezed to their limits Jan 21 23:38:59 the nice thing about PRU is that not only is it a fast microcontroller, it's also connected to the rest of the linux system via a very high bandwidth bus allowing direct memory access Jan 21 23:39:55 being semi-retired i was looking for something to design and release maybe once retired and a mid ranged control system seems to be a decent opening Jan 21 23:40:17 ya i seen the dma thing which is really nice Jan 21 23:40:44 thats kinda what originally made me see in the kernel the usb was stuck on pio Jan 21 23:40:57 then i seen you post that in some talk here Jan 21 23:40:58 yeah I meant more in the sense of linux being able to directly access PRUSS memory and PRU being able to directly access DDR3 memory Jan 21 23:41:23 though it's certainly also possible to use EDMA to transfer data between DDR3 memory and PRUSS memory Jan 21 23:42:37 definately looks interesting and i am fighting trying not to get sidetracked with it right now while doing this other stuff Jan 21 23:42:38 haha Jan 21 23:42:42 lol Jan 21 23:42:52 i am bad for that Jan 21 23:43:02 it's thanks to that that an application like BeagleLogic is possible Jan 21 23:44:05 ive got normal benchtop tools here but recently was looking for a cheap LA and seen some mention of a Beaglebone LA Jan 21 23:44:12 is that what your talking about? Jan 21 23:44:29 yeah, BeagleLogic uses PRU to turn a beaglebone into a 12-channel 100 Msps logic analyzer Jan 21 23:45:21 is there a cape for that or is it just being pulled out of the p8/p8 with a cable? Jan 21 23:46:39 ive got a grove base cape here and kinda wondered if it was just a matter of making some pigtails or if it was more involveds Jan 21 23:47:34 other then seeing it show up in a google search i never really went much further as not to get sidetracked Jan 21 23:47:36 lol Jan 21 23:47:56 there's a design for a cape for it, basically just connector + input buffer to allow wider input voltage range and protect the am335x Jan 21 23:48:04 dunno if it was ever manufactured Jan 21 23:48:28 its neat to know that stuff exists Jan 21 23:49:18 one thing that always puzzled me is why the beagles aren't more popular with in some circles Jan 21 23:49:21 he also has a design for a standalone version based on the osd3358-sm that supports 16 channels and has gigabit ethernet Jan 21 23:49:41 now that would be nice Jan 21 23:50:42 but I don't think that project is alive... at least, no activity since 2017 Jan 21 23:52:10 still tho i'd be interested in looking as seeing how others do things is always a good thing Jan 21 23:59:30 it got into the top 5 for the "best product" category of the hackaday 2017 prize Jan 22 00:01:28 anyway, what beaglelogic does is pretty nifty.. one pru core sampling the inputs every other cpu cycle, and use the remaining cycles inbetween to transfer the samples in batches to the other pru core (using single-cycle core-to-core transfer) which writes it to a ringbuffer in ddr3 memory Jan 22 00:02:45 can it do fancy things like trigger on i2c address? Jan 22 00:04:05 I think analyzing/processing the data is left to software (sigrok)... but you're right that pru could definitely be used to do some types of real-time analysis/decoding/triggering Jan 22 00:04:16 especially for slowass i2c ;) Jan 22 00:04:26 haha... now you did it... im over on his github poking around Jan 22 00:05:59 https://github.com/abhishek-kakkar/BeagleLogic/tree/master/firmware has the asm for both cores (and trivial C wrappers for some reason, even though there's really no need for those) Jan 22 00:06:27 yep Jan 22 00:06:50 ive cloned his github now so i know where it is Jan 22 00:06:52 ah wait never mind, pru0 is actually a fair bit of C Jan 22 00:07:11 pru1 (the sampling core) pure asm Jan 22 00:08:05 you don't think the standalone was ever released? Jan 22 00:08:12 doesn't look like it Jan 22 00:08:30 to bad as the ethernet alone makes interesting Jan 22 00:09:24 if you want gigabit ethernet there's https://www.sancloud.co.uk/beaglebone-enhanced-bbe Jan 22 00:14:42 iirc it had some things in its schematic that made me go "hmm"... but dunno if that still applies or if it was just some early version Jan 22 00:15:04 didn't we talk about this a while ago? Jan 22 00:15:15 about what? Jan 22 00:15:34 something possibly dodgy in the bbe schematics Jan 22 00:16:06 something about the power sequencing, iirc Jan 22 00:16:39 I don't exclude the possibility I've mentioned it before, though not particularly recently I think :P Jan 22 00:16:55 maybe a couple of months ago Jan 22 00:17:55 just build your own with whatever feature you want Jan 22 00:18:08 it is pretty trivial thesedays Jan 22 00:18:09 ya i looked at the enhanced stuff while looking at something with more ddr ram as well as all the other makers of the beagle stuff Jan 22 00:18:56 mru: yeah the power sequencing is indeed a bit dodgy Jan 22 00:21:26 since they're using SYS_5V as both supply and enable-signal for the VDD_3V3 regulator (a buck converter on the BBE instead of an LDO) Jan 22 00:21:47 in the end i just bought what digi or mouser had which was beagleboard.org's Jan 22 00:21:57 ive accounts with them Jan 22 00:23:09 biab... gonna grab some eats and now that you got me sidetracked go snooping round his githubs while i eat Jan 22 00:23:11 hahaa Jan 22 00:23:26 they have some boards at 20% discount because they were produced with the wrong pcb color Jan 22 00:32:17 Smarts, lies, video tape! Jan 22 00:33:42 well. SCratch out video tape and just use video servers. Jan 22 00:34:10 A little a day, learning, keeps the boring away. Jan 22 00:36:06 Now...how am I supposed to attach this 2TB piece of metal to my BBB? Jan 22 00:36:26 SATA. Boo! Jan 22 01:32:53 USB2SATA bridge? Jan 22 01:39:58 Serious? Jan 22 01:40:14 Nice...I will look into it. I have one! Jan 22 01:41:06 So their now get to fun. Jan 22 01:41:11 Otay! Jan 22 01:41:13 Otay! Jan 22 01:41:27 Is it sleep time yet? Jan 22 01:42:08 Anyway, I will check it out soon. Jan 22 01:43:20 you've got 2.25 hours for that Jan 22 01:54:55 Par-tay! Jan 22 01:57:53 Can you shell what the cook is rockin'? Sorry. I tried. Jan 22 02:05:20 Do I need special software? Jan 22 02:05:50 or does the bridge supposedly handle it? Jan 22 02:07:10 Well, hold that thought. I need to catch up on tractor lever specifications right now. Jan 22 02:07:11 it should just work. Try it first. If you have an external USB drive try that. Jan 22 02:07:18 Okay. Jan 22 02:07:34 Oh. Jan 22 02:08:14 I have a ssd bridge and not the 3.5" bridge. Jan 22 02:08:19 Dang it. Jan 22 02:08:32 hmm you have an external USB drive? Jan 22 02:11:35 Party time. I found an old ssd. Jan 22 02:14:35 GenTooMan: I am booting now w/ the bridge and 2.5". Jan 22 02:15:49 I am plugged in via BBGW. Should I use the Black w/ power adapter? Jan 22 02:16:45 Okay. Booted. Jan 22 02:17:39 lsusb does not show anything. Jan 22 02:20:21 Should I install gparted? Jan 22 02:29:56 I am in /etc/fstab Jan 22 02:29:59 What next? Jan 22 02:35:57 Maybe i need more power. Jan 22 02:36:01 Who knows? Jan 22 02:36:11 Off to get more power. Jan 22 02:39:52 Okay. I found a new cable. Cables! Jan 22 02:40:09 It seems one for com. and one for power may help. Who knows? Jan 22 02:56:17 It only makes the board hot. Jan 22 02:56:29 I must be messing w/ poison. **** ENDING LOGGING AT Fri Jan 22 02:59:58 2021