**** BEGIN LOGGING AT Fri Jan 21 02:59:57 2022 Jan 21 08:15:22 Hi set Jan 21 08:15:42 Recommend the EEVblog youtube channel, very interesting Jan 21 08:53:18 Good morning. I play around with a BBAI and especially the booting. I compiled u-boot 2022.01 and it boots. but it cant access the mmc0 (sd card). It can just access mmc1. The running debian mainline kernel linux-image-5.10.0-11-rt-armmp can only access mmc0 and not mmc1. I bootet the BBAI via netboot pxe. So i compared the dts of u-boot and the Jan 21 08:53:19 kernel. THey are different in many places. Why are they so different? How to match betwen a u-boot version and a kernel version? Jan 21 08:57:20 most of the dts is irrelevant to u-boot anyway Jan 21 08:57:59 and the kernel dts is kernel version dependent, so u-boot keeps its own dts files Jan 21 08:59:23 Yes, i know that the kernel keeps it own version. U-boot loads it as a seperate file on the startup of the kernel Jan 21 09:00:39 not sure what you mean by "match between u-boot version and kernel version" ... there's generally no version-dependency between those Jan 21 09:01:56 or actually, there's just no version dependency between those... an ancient u-boot should load the latest kernel just fine and conversely the latest u-boot should have no problem loading an ancient kernel Jan 21 09:02:49 Maybe i mismatched my experiments with the pi4 which just has one dtb for both u-boot and kernel. it doesnt load it again from netboot (Rpi4 with u-boot) Jan 21 09:03:24 how odd Jan 21 09:04:04 that makes no sense, u-boot's dts needs to be compiled into u-boot, which you can't do with the kernel dts since it's kernel version dependent Jan 21 09:04:36 At the pi4, the dtb is on the first partition and get loaded by the firmware. Thats all.... Jan 21 09:04:55 by u-boot you mean? Jan 21 09:05:09 oh, or by an earlier bootloader stage? Jan 21 09:05:23 Rpi4 firmware. early boot loader Jan 21 09:05:46 yeah I guess that could work... that's a very unusual arrangement though Jan 21 09:05:59 Yes, i was used to the BBB way... Jan 21 09:06:11 but the rpi is strange anyway, the ARM core isn't even the boot cpu Jan 21 09:06:19 it boots from the videocore ("gpu") Jan 21 09:07:37 which then brings up the ARM subsystem Jan 21 09:07:57 at least that's how it works on older rpis, I assume it's still the same on the rpi4 Jan 21 09:13:38 On the image from bb.org for the BBAI, i got u-boot 2019.07-rc4-00001-g607b5b738b . But that version is not upstream. Where can i find it? Jan 21 09:13:51 i mean in the u-boot upstream src from denx Jan 21 09:15:22 yeah bb.org has custom patches on top, e.g. for things like u-boot overlays Jan 21 09:15:53 I don't remember off the top of my head what the primary repo is for those, I'd need to check Jan 21 09:17:06 https://github.com/RobertCNelson/Bootloader-Builder is the primary repo for the patches I think Jan 21 09:17:38 I found https://github.com/beagleboard/u-boot ... ok .... Jan 21 09:17:41 Thx :) Jan 21 09:18:17 yeah I think that contains snapshots of the resulting patched trees, but isn't where those patches are maintained... I *think* Jan 21 09:18:39 rcn-ee: am I saying that right? Jan 21 09:21:57 it would be nice if there was a repo with the final patched trees, tagged with the version string that's actually in the u-boot builds found on beagleboard.org images (e.g. 2019.07-rc4-00001-g607b5b738b) to remove any ambiguity on what the source code for these binary builds looks like Jan 21 09:22:03 This builds for am335x_boneblack and am335x_evm Jan 21 09:22:19 am335x_evm is used, not am335x_boneblack afaik Jan 21 09:22:25 am335x_evm autodetects the board Jan 21 09:22:34 for all am335x-based boards Jan 21 09:23:25 Bootloader-Builder is also used for non-am335x boards Jan 21 09:23:35 pretty sure about that Jan 21 09:24:08 The BBAI is am5729 Jan 21 09:24:23 I look into it Jan 21 09:24:41 correct, u-boot target am57xx_evm Jan 21 09:25:56 and I'm seeing a bunch of hits for "am57xx_evm" in build.sh Jan 21 09:26:16 Ins uncommented in the end ^ Jan 21 09:29:23 https://github.com/RobertCNelson/Bootloader-Builder/commit/ba50222022a06a00ef97c742c6acc9c7bcf4a418#diff-4d2a8eefdf2a9783512a35da4dc7676a66404b6f3826a8af9aad038722da6823 Jan 21 09:30:14 is the commit that changed from building am57xx only by default to building am335x only by default Jan 21 09:30:27 it probably just reflects what he's working on at any given moment, dunno Jan 21 09:30:34 you'd need to ask him Jan 21 09:31:16 I'll agree it is a bit odd Jan 21 09:31:57 as the version from upstream denx cant access mmc0 (sd) i wanted to build the version that is running on the image and change 2 options ..... i guess i can make that work ;) Jan 21 09:32:45 and as i see the patch folder of the Bootloader Builder, i can see why this script exists :D Jan 21 09:37:53 yeah like I said, it would be nice if it were more obvious how to get the exact source tree corresponding to one of the binary u-boot builds Jan 21 09:41:09 the beagleboard/u-boot repo would be first place I'd expect people to look, it ought to just have tags corresponding to binaries Jan 21 09:42:20 the problem is, I know it doesn't have the exact commit corresponding to the u-boot version you listed, since that would have to be https://github.com/beagleboard/u-boot/tree/607b5b738b Jan 21 09:42:25 That was what i expected Jan 21 09:42:42 but that's probably just due to a difference in git metadata (e.g. commit date) Jan 21 09:43:34 The whole arm universe is just like a mess.... each board is different ... like the famous rant from Linux Jan 21 09:43:37 Linus Jan 21 09:44:47 I think passing --committer-date-is-author-date to git-am should make the commit hashes reproducible Jan 21 15:05:02 zmatt, still a lot of legacy using the old u-boot tree's.. on the forum's snapshot pages, i link to the branch of u-boot used.. Jan 21 15:05:42 https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots/31280 -> U-Boot: either: https://github.com/beagleboard/u-boot/tree/v2021.10-bbb.io-am335x or https://github.com/beagleboard/u-boot/tree/v2021.04-bbb.io-am57xx Jan 21 15:06:18 i'm moving both to v2022.01 under a single branch, jsut a differet build config.. Jan 21 15:07:42 i like have a simple ./build.sh under that branch, so users will see that going forward too.. Jan 21 15:10:33 hi o/ Jan 21 23:24:03 How do people normally use the serial console on a BeagleBone when a cape is mounted on top. I've been removing the 7-pin 0.10" header and replacing it with a right-angle one. Jan 21 23:44:37 SJFriedl, i use a lot of thru hole spacers on the cape headers.. Jan 21 23:47:18 through-hole spacers? Jan 21 23:47:42 like nylon standoffs to boost them higher? Jan 21 23:49:31 SJFriedl, 2x of these: https://www.digikey.com/en/products/detail/samtec-inc/SSQ-123-03-G-D/1111439 Jan 21 23:50:16 easy 8mm of more vertial space to plug in a serial adpater.. Jan 21 23:51:15 ok. I think my right-angle thing will serve the same purpose. I was hoping there was some magic solution Jan 21 23:54:22 I used wires instead of a direct connect from BBGW to Cape and the header in question is then easy to access. Jan 21 23:55:46 I wish these pins would be moved to where the cape wouldn't be in the way. Jan 21 23:56:05 Besides that, GenTooMan, I took notes last night on reactance (capacitive and inductive) and MOSFETs being encompassed in this field. Jan 21 23:56:41 Two pages later, I nice right up will be done w/ SCIENCE in mind and not just "DO IT THIS WAY" ideas. Jan 21 23:57:46 I also noticed that MOSFETs not FETs where patented in '60, i.e. the year after two people from Bell Labs invented them. Jan 21 23:59:24 SJFriedl: Did you use wires "inside" the cove of BBB and Cape to manage your UART header(s)? Jan 21 23:59:59 Oh! I got you now. I am w/ you. You used right-angle headers on the UART header(s). Jan 22 00:00:04 Yes Jan 22 00:00:08 Okay. Jan 22 00:00:12 That works too! Jan 22 00:00:32 desolder the old ones, solder in a new one but only 3 pins, and I use keying plugs on the RS232 adapter so it can only go in one way. Jan 22 00:00:42 not sure why they bothered with 7 pins. Jan 22 00:00:55 Or...one could make a...oh. Nice. Jan 22 00:01:25 I was thinking on the cape in question, one could make a cut-out of PCB too. Jan 22 00:01:57 So, the header is accessible that way could be beneficial. Jan 22 00:02:34 I use a small cable clip to keep this adapter more or less permanently connected Jan 22 00:03:39 Hmm. SJFriedl: What specific UART is this specific header? I think it is UART0, right? Jan 22 00:03:56 Whatever the serial console is. Jan 22 00:04:12 I don't use it at runtime, only for initial setup or troubleshooting Jan 22 00:04:22 Yep. Yep. I need to review again but I think it is UART0. Oh. Okay. Jan 22 00:04:51 Oh, yea. It is nice to read logs that way. Jan 22 00:05:10 Do you mess w/ your own builds already? Jan 22 00:06:09 No, but I start over often enough and re-flash the BeagleBone, and on the wifi unit the serial console is the only way I know how to do this. Jan 22 00:06:22 Sorry. Image building is what I am discussing. Jan 22 00:06:26 Oh. Jan 22 00:06:45 I think beaglebone.local works too! Jan 22 00:07:09 that wont work until the wifi is set up, and on a newly flashed unit I need the console to get there. Jan 22 00:07:13 For getting the board to locate itself via usb networking, beaglebone.local sometimes works too. Jan 22 00:07:20 Oh. Jan 22 00:07:54 Sometimes, at least for me, I found that it works at times and then does not work at times. Jan 22 00:08:20 Oh, that would work too, of course. Jan 22 00:08:55 I guess I've used serial ports on computers for >30 years and this is just an old habit. Jan 22 00:09:29 30 years! Jan 22 00:09:53 I am still new to you! I have been mingling for only about six or eight years. Jan 22 00:09:56 I'm an old fart :-) Jan 22 00:09:59 ha Jan 22 00:11:13 So, have you ever built a Cape based on a controller and driver for inductive loads? Jan 22 00:11:21 one of the reasons, now that I think about it, that I mostly don't use the USB port is because the default IP address 192.168.6.x is the same as what's on my network. Jan 22 00:11:32 Oh. Jan 22 00:11:34 Hmm. Jan 22 00:11:35 Okay. Jan 22 00:12:20 the thing I'm building now drives a relay, but a small one so a simple 2N3904 transistor and flyback diode works fine. Jan 22 00:12:28 it's an inductive load but a small one. Jan 22 00:13:02 Oh. So, Yep! I am trying to build a thing for 12v motors using a controller and driver but... Jan 22 00:13:32 I need to test more. My motor(s) as of now, do not turn w/ power applied to the breadboard. Jan 22 00:13:45 Why not get a motor cape? Jan 22 00:13:50 I have two! Jan 22 00:14:01 they working for you? Jan 22 00:14:24 I do not want another one...oh and yes. They work awesomely. Is awesomely a word? Jan 22 00:14:32 Anyway... Jan 22 00:14:36 it's a great word :-) Jan 22 00:15:01 I think they are great builds but I want one for myself, i.e. that I actually built. Jan 22 00:15:16 I want to make a TI.com build of a Cape too. I found one a while back. Jan 22 00:15:30 sounds like a good project Jan 22 00:16:01 Yes. I know I am probably boring you but wait. I will show you the exact controller and driver(s) bring used... Jan 22 00:16:48 is it an h-bridge ? Jan 22 00:16:51 uc2637 and lm1949 are my two pieces. Jan 22 00:17:03 No. Not an H-bridge. Jan 22 00:17:05 (looking) Jan 22 00:17:09 Okay. Jan 22 00:18:17 trying to stick all with TI? Jan 22 00:19:05 For now. I found other parts but I was thinking why not stick w/ them... Jan 22 00:20:04 They still produce updates to their datasheets constantly and offer ideas into how to build test circuits too. Jan 22 00:29:18 Hmm. I also bought a Power Cape from the same people, and though the 3.3v output is 3.3v, the 5v output is 4.75v. Seems low. Jan 22 00:30:14 Oh? Well, I should check that out. I think you need to supply a barrel jack to the BBB in question. Jan 22 00:32:34 I don't think so - this power cape is meant to take higher voltages (in my case, 24v) and power the BBBW via the pins. Jan 22 00:34:26 That is news to me. I thought all the Capes listed at https://beagleboard.org/capes had to have a barrel jack connector to make the Capes work. Jan 22 00:34:33 This is a first I have heard of this idea. Jan 22 00:39:42 https://www.mouser.com/ProductDetail/GHI-Electronics/PWRCPE-BBBCAPE Jan 22 00:40:39 Okay. I will test mine. It is plugged into the BBBW now. I will add a 12v supply to the Cape and test 3.3v and 5.0v. Jan 22 00:48:58 4.67v Jan 22 00:49:25 Yeppers. It does boot the BBBW too! Jan 22 00:49:58 But...where does the GND go to test the actual voltage? Jan 22 00:50:12 Is it onboard the BBBW or the Cape? Jan 22 01:00:02 From what I read, 5v is not regulated. am i correct? Jan 22 01:01:36 So, maybe the BBBW is the GND for 5v while the Cape regulates only 3.3v? Jan 22 01:06:47 The ground is the same for all voltage points Jan 22 01:07:39 Oh. But, is it on the cape or the Header Pins on the BBBW? I looked at the schematic and came to a conclusion. Jan 22 01:08:06 other than the analog ground, I think all ground points are tied together. Jan 22 01:08:34 The 5v, I think, is just routed from the BBBW and not regulated. Jan 22 01:11:13 Do you think it is adjustable via source? Jan 22 01:11:42 Or via a pot? Jan 22 01:12:23 Never mind. It is just routed from the BBB and not the Cape. I got ahead of myself. Jan 22 01:12:46 The power cape I have generates the quasi-5v independent of the BBB Jan 22 01:14:36 Hmm. Okay. Well...I am misreading the schematic then. I looked at it here, https://github.com/beagleboard/capes/blob/master/beaglebone/Power/Power_Cape_sch.pdf , and found that it states 3.3v regulated and not 5v. Jan 22 01:14:47 But... Jan 22 01:15:11 The Cape states it is regulating the 5v via the silkscreen. Jan 22 01:17:14 Let me test something else. Jan 22 01:18:53 aha. The output of IC2 (pin 4) is right at 5V, but the other side of diode D3 is the lower 4.86 Jan 22 01:19:07 I think you are right. 5v is 4.67v on my Cape. I tested from the Cape and the BBBW GNDs. Jan 22 01:19:18 Hmm. Jan 22 01:19:25 but if you test on the other side of D3, it will be 5 Jan 22 01:21:33 say what? Hmm. So, do you think it was built to hinder specific pins from using exactly or close to 5v? Jan 22 01:21:53 I don't know what the rationale is. Jan 22 01:21:59 Oh. Jan 22 01:22:01 Okay. Jan 22 01:22:05 Me neither. Jan 22 01:23:12 What is the port for VS Code? Jan 22 01:28:34 Yah, the switching IC is the 5.0v version, and the voltage drop across the diode brings it to ~4.75v. Seems like something the cape docs should have noted. Jan 22 01:29:01 Oops. Jan 22 01:29:02 Ha. Jan 22 01:38:03 This just looks crazy - they used a 5.0v regulator then drop it with a diode to power the BB at ~4.8v, when they could have used the adjustible version of the same chip and used a voltage divider to set the output so it's 5.0v after the diode. I don't get it Jan 22 01:40:46 One, meaning myself here, the BBB needs under 5v to supply its needs for power? Jan 22 01:50:30 no, input should be 5V Jan 22 01:50:49 Hmm. Jan 22 01:50:54 So, what is up w/ the Cape? Jan 22 01:50:58 4.75 is already marginal and may cause problems with usb Jan 22 01:54:18 SJFriedl: the diode is presumably there to protect the buck converter if the BBB is powered via its 5V barrel jack while the cape is attached (which regrettably causes the 5V input on P9 to become a 5V output since it's tied directly to the 5V barrel jack) Jan 22 01:58:57 though it's not clear to me whether that would even bother the MIC4680 Jan 22 02:12:40 I wonder if the FB pin can be connected after that diode and remain stable Jan 22 02:18:58 I see no obvious reason to suspect that the diode is needed at all Jan 22 02:22:17 I cannot be the first person who has observed this. Jan 22 02:22:27 I'm pretty special, but not *that* special :-) Jan 22 02:22:52 hnv: but if it is, I'd sooner suspect the FB pin is what needs protection than the SW pin, but I guess either could be the case, dunno Jan 22 02:23:37 SJFriedl: this is the first time I've encountered someone using this cape Jan 22 02:27:03 The FB has the high impedance of an OpAmp in // with a voltage divider, I guess no protection is needed. The series pass transistor may have a emitter-base breakdown voltage gt the 5v rail so maybe it doesn't need protection either... not sure though Jan 22 02:32:17 Wait... Jan 22 02:32:29 hnv: it'll also depend on what kind of ESD protection has been implemented Jan 22 02:32:48 So, the barrel jack makes an input of 5v an output of 5v? Jan 22 02:33:01 set_: ??? Jan 22 02:33:17 I just read what you typed, @zmatt. Jan 22 02:33:37 W/ this Cape attached is what I am describing. Jan 22 02:33:57 set_: the barrel jack and the 5V input on the expansion header (P9.05-06) are directly tied together Jan 22 02:34:05 Okay. Jan 22 02:34:22 so any voltage you put one one will also appear on the other, since they're literally the same thing Jan 22 02:34:40 Okay. Jan 22 02:35:00 What happens when there is not a barrel jack present? Jan 22 02:35:27 what do you mean? Jan 22 02:35:28 It is just as usual, i.e. 5v input? Jan 22 02:35:47 For Cape detection...right? Jan 22 02:35:52 ????? Jan 22 02:36:14 Okay, so let me try to make more sense here. Jan 22 02:38:11 So, say the PowerCape, in which I currently have one attached to the BBBW, is attached and a barrel jack is installed into the connector on the BBBW. Okay so, the PowerCape now on P9.5/6 is output but was input beforehand, e.g. before the installation of the barrel jack? Jan 22 02:39:51 Either way, no issue w/ me. I am just entertaining the idea of working w/ this specific Cape. Jan 22 02:40:21 I got it a while back and wanted to incorporate it in w/ the controller and driver(s) for 12v motors. Jan 22 02:50:39 set_: simplified diagram of 5V distribution on the BBB: https://photos.app.goo.gl/SRk1BPWsi2NAD92MA Jan 22 02:53:11 5V output of PMIC is comes either from usb vbus or 5V in, whichever has a higher voltage... or neither when the beaglebone is powered off Jan 22 02:53:33 Okay. Jan 22 02:54:50 but the 5v input via P9 and 5v input via barrel jack are tied together, there's nothing preventing power from flowing into one and out the other Jan 22 02:56:11 (which has resulted in some capes erroneously using P9.05-06 as power supply input, causing those capes to fail to work when powering the BBB via USB) Jan 22 02:57:08 Okay. Jan 22 02:57:27 Thank you! That is good news. Jan 22 02:57:32 now I know! Jan 22 02:57:42 ??? Jan 22 02:57:47 I did not know. Jan 22 02:57:50 which part is "good news" ? Jan 22 02:57:57 me knowing now. Jan 22 02:58:23 If I am to use these boards, I need to know as much as possible... Jan 22 02:58:46 I get sidetracked, as you know, easily. So, to know something else simply by reading makes me feel better. **** ENDING LOGGING AT Sat Jan 22 02:59:56 2022