**** BEGIN LOGGING AT Sun Jan 06 02:59:57 2019 Jan 06 07:41:26 has anyone heard anything about uboot cape detection being broken in RCN's 2018-12-10 images (U-Boot 2018.09-00002-gd5b4c4b656) ? Jan 06 07:42:03 I just tried to use that Ubuntu image for the first time and I'm seeing that U-Boot makes no attempt to load the DTB for my cape Jan 06 08:22:30 ubuntu? debian you mean? Jan 06 08:23:12 if you're booting from sd card rather than eMMC, you may want to wipe eMMC since the presence of an old bootloader on eMMC can cause problems like these Jan 06 08:23:26 ( sudo blkdiscard /dev/mmcblk1 ) Jan 06 08:23:55 rom bootloader prefers loading u-boot from eMMC over loading it from sd card Jan 06 08:36:58 no, I meant Ubuntu :) Jan 06 08:37:04 I believe the U-Boots are the same, though Jan 06 08:37:15 oh I have no idea what, if anything, works on ubuntu Jan 06 08:37:20 and I booted a flasher image, flashed it to eMMC, and booted from eMMC Jan 06 08:37:29 I don't think Ubuntu vs Debian matters here Jan 06 08:37:34 if you want stuff to work, use debian Jan 06 08:37:44 well it definitely works on debian Jan 06 08:37:57 so if it doesn't work on ubuntu, then ubuntu vs debian very much matters Jan 06 08:38:16 I'm a bit curious how switching to Debian makes U-Boot load an overlay before the kernel even starts :) Jan 06 08:38:18 the ubuntu images are unofficial, have few users, are therefore rarely tested Jan 06 08:39:07 are you sure it's the same u-boot? are the overlays present in /lib/firmware ? are u-boot overlays enabled in /boot/uEnv.txt ? Jan 06 08:39:29 I haven't checked but RCN would be insane to do otherwise, yes, and yes Jan 06 08:40:08 I'm currently trying the previous Ubuntu image for comparison Jan 06 08:40:13 I can certainly try Debian after that Jan 06 08:40:57 did autodetection work for this cape on any previous firmware? which cape is it? Jan 06 08:41:33 it's a Replicape and yes, this is the first U-Boot I've hit in the last year or two that didn't detect it and load the overlay Jan 06 08:41:39 ok Jan 06 08:42:06 the serial output shows that U-Boot isn't attempting to load the DTB at all - it doesn't seem to have detected that the cape is present Jan 06 08:42:34 you should definitely test the latest debian image. if it doesn't load the overlay then that Jan 06 08:43:05 would be a serious bug. if it works on debian but not ubuntu then *shrug* Jan 06 08:43:16 yup, the 2018-09 image is fine Jan 06 08:43:36 I get a uboot_detected_capes=BB-BONE-REPLICAP and good things happen Jan 06 08:44:34 I'll copy down the U-Boot version info for the uboot this image flashed onto the board and then try the 2018-12 Debian Jan 06 08:49:52 broken U-Boot seems to be U-Boot 2018.09-00002-gd5b4c4b656, working one is U-Boot 2018.09-00002-g0b54a51eee Jan 06 08:52:57 what about v2018.09-r7 from http://rcn-ee.net/repos/bootloader/am335x_boneblack/ ? Jan 06 08:55:10 https://pastebin.com/Xv2WwT3Y script to install u-boot onto a disk (put MLO and u-boot.img in same directory) Jan 06 08:55:45 I just ran /opt/scripts/tools/developers/update_bootloader.sh Jan 06 08:56:17 that works too. I should really check what scripts rcn has on his images so I can refer to them XD Jan 06 08:56:20 seems to have bumped me to u-boot-am335x_evm-v2018.09-r7.img Jan 06 08:56:49 ... which seems to be 2018.09-00002-gd5b4c4b656, which is broken :( Jan 06 08:57:43 hum, in that case you should definitely email rcn Jan 06 08:59:53 would it be better to email him directly or try to hit the Google Group or somesuch? Jan 06 08:59:59 direct email Jan 06 09:00:36 interesting Jan 06 09:00:49 I'll get the version info assembled and send it his way Jan 06 09:00:50 thanks! Jan 06 09:01:08 (and I'll also try Debian because I'm just curious now :D ) Jan 06 09:01:31 this sounds like a definite bug in u-boot, and you've reasonably narrowed down when it went wrong Jan 06 09:01:55 you could try bisecting the seven v2018.09 releases to see when the problem was introduced Jan 06 09:03:00 there's definitely a weird-sounding commit... "am335x_evm: bring back bug, so users can prototype with overlays" Jan 06 09:05:42 can you pastebin your /boot/uEnv.txt ? Jan 06 09:05:50 I just want to check something Jan 06 09:06:22 ooh, 2018.09-r6 does work Jan 06 09:08:50 https://pastebin.com/gPUukPG7 Jan 06 09:09:04 it's basically all the defaults and UIO Jan 06 09:09:22 I do have the universal cape enabled, but disabling that didn't seem to help Jan 06 09:09:55 omap_wdt.nowayout=0 .. ew Jan 06 09:10:14 but yeah it looks fine overall Jan 06 09:10:53 any clues in the output from u-boot on the serial console? Jan 06 09:11:51 hm, r6 and r7 were release one day apart Jan 06 09:12:52 nothing obvious, but here are the serial spews: https://pastebin.com/8Krn3fi8 Jan 06 09:12:54 ok this is reaaally weird Jan 06 09:13:24 I'm looking at the commit which presumably corresponds to r7, and I don't see how it could possibly affect anything Jan 06 09:13:46 actually... Jan 06 09:14:06 it looks like on the broken one, all the I2C probes are failing and printing "Check if pads/pull-ups of bus are properly configured" Jan 06 09:14:28 ehh Jan 06 09:14:57 i2c bus requires external pull-ups anyway, so the pull-up configuration shouldn't matter Jan 06 09:17:33 r7 does mess with pin config however, so lemme double-check it Jan 06 09:19:19 seems fine to me. r7 changed the internal pull on the i2c pins from pull-down to pull-up, although like I said it shouldn't matter since external pull-ups are required anyway (since the internal pull-ups are waaay too weak) Jan 06 09:21:50 https://github.com/RobertCNelson/Bootloader-Builder/commit/6d59b42c4531 this is the commit for v2018.09-r6 -> -r7 Jan 06 09:23:16 interesting Jan 06 09:23:46 unfortunately, it's 1AM here, which is too late for me to be digging into pin settings :\ Jan 06 09:24:13 I fired off an email with the working and broken U-Boot logs to RCN and I'll have to take another look at this tomorrow Jan 06 09:24:15 thanks! Jan 06 09:25:33 wiley: which replicape revision do you have? Jan 06 09:25:41 0B3A Jan 06 09:26:23 oh and of course *that* revision doesn't have a pdf for the schematic, while B3 and B4 do Jan 06 09:26:34 lol Jan 06 09:26:48 I can poke Elias if it bothers you that much :) Jan 06 09:27:06 actually... Jan 06 09:27:14 B4 may actually be B3A Jan 06 09:27:23 either that or Elias never manufactured B4 Jan 06 09:27:39 welp Jan 06 09:27:43 replicape is missing pull-ups on i2c Jan 06 09:28:20 that doesn't explain things though, it means that r7 should work and r6 shouldn't Jan 06 09:28:34 actually, it means neither should work except by miracle Jan 06 09:28:39 lol Jan 06 09:31:46 at least they're missing in the b3 schematic. I can't tell in the b4 schematic since that pdf is a broken mess Jan 06 15:41:39 zmatt: feel like giving this a look. It's something with the U-Boot, but I'm not sure what's happening. https://stackoverflow.com/questions/54054142/flashing-beaglebone-with-a-custom-image-problem Jan 06 15:51:12 zmatt: I'm guessing the older U-Boot SPL built by OE doesn't find the "new" debian image U-Boot and thus proceeds with the one in FAT on the SD. While in the other case it finds the one in the FAT partition and ends up booting eMMC. I'm not that good with all this though. Jan 06 17:25:34 zmatt, RCN responded by shipping 2018.09-r8, which resolves the issue :) Jan 06 23:27:41 wiley: huh, oh wow I just looked at the r7 patch again, and it actually changes the pull from up to down. I have no idea how I managed to think it changed it from down to up when I looked at it yesterday Jan 06 23:28:43 wiley: note that the *real* bug is still the lack of appropriately sized pull-ups on the replicape Jan 06 23:31:55 I'd need to check the spec on what is "appropriately sized" exactly, and it depends on how much capacitance the replicape and its i2c chips put on the bus, but it'll be around the order of magnitude of 4.7 kΩ. the internal pull-ups are 100 kΩ ±50% Jan 06 23:57:25 that's something I'd have to defer to the hardware designer on, unfortunately Jan 06 23:58:03 but the practical answer is that Replicape production is finished, likely forever, and the capes have been working as-is for the last few years Jan 06 23:58:45 wiley: oh lol, it gets even better: replicape (rev B3) uses an i2c pwm controller powered at 5V but doesn't specify 3.3v i2c bus compatibility in that case. V_IH(min) is 0.7*VCC = 3.5 V Jan 06 23:58:59 so it's being used outside its specified electrical parameters Jan 07 00:30:23 is their a /sys directory/file for inspecting the pwm outputs? Jan 07 00:31:55 ayjay_t: the built-in pwm outputs of the am335x? yes, you find them in /sys/class/pwm/ and if you have the latest bbb-customizations debian package then convenient symlinks are created in /dev/pwm/ Jan 07 00:34:52 tanks mucho Jan 07 01:15:11 wiley: anyway, ignoring the incompatibility, max pull-up value (at estimated 30 pF total bus capacitance) is 39 kΩ for standard mode (100 kHz) or 12 kΩ for fast mode (400 kHz). minimum pull-up value is 1 kΩ. if you ever run into any i2c problems (e.g. random NAKs) or want to improve noise immunity, adding pull-ups would definitely be recommended **** ENDING LOGGING AT Mon Jan 07 02:59:56 2019