**** BEGIN LOGGING AT Mon Sep 04 03:00:00 2017 Sep 04 07:17:20 hi everybody! I'm trying to boot a new BBB but it stucks on "waiting for root device". I noticed 2 things: 1) bootargs are duplicated 2) the new BBB has a different enclosure than the latest i bought. Anyway, the sdcard I used to flash the configured OS is the same for both BBBs but the older boots, the newest doesn't. can you help me? who sets the Sep 04 07:17:21 'bootargs' other than uEnv.txt? Sep 04 07:28:23 normally you don't set 'bootargs' directly in uEnv.txt Sep 04 07:28:54 it's constructed by u-boot from various variables, including 'cmdline' which is set in /boot/uEnv.txt Sep 04 07:29:29 and a bbb normally doesn't have any enclosure Sep 04 07:48:12 zmatt: thank you. I just noticed also this message "card did not respond to voltage select" and then "switch to partitions #0, OK" and finally "mmc1(part 0) is current device. using the older BBB i don't have these errors and I get "mmc0 is current device". Possible different initial cfg of uboot? Sep 04 07:49:33 also if your flash image is old. I'd recommend to try latest. Sep 04 07:49:49 how exactly did you flash the eMMC ? it sounds like your older bbb still uses some very old u-boot Sep 04 07:51:07 "card did not respond to voltage select" is because u-boot attempts to boot from sd card initially Sep 04 07:52:24 "waiting for root device" also suggests some serious mismatch between u-boot and the rest of the system Sep 04 07:53:38 tbr: I get the impression he's deliberately trying to reuse some old image Sep 04 07:54:01 that's my guess anyway Sep 04 07:54:03 zmatt: for both BBBs I used (a customized version of ) the /opt/scripts/tools/init-eMMC-flasher.sh" script. Sep 04 07:54:25 zmatt: and the source is a pre-configured os on sdcard Sep 04 07:55:06 alfatau: how does it install u-boot ? Sep 04 07:55:29 zmatt: let me check Sep 04 07:56:54 the old way would be as files in a separate FAT partition, the new way is at fixed offsets in the space between the partition table and the rootfs partition Sep 04 07:58:48 zmatt: yes, that was my impression too and why I suggested to try with a recent one... Sep 04 07:58:49 i'm checking the script. anyway, it does not load the uEnv.txt from the fat partition, but from the mmc/sdcard Sep 04 07:59:11 alfatau: so a FAT partition does exist? Sep 04 07:59:46 yes, for both sdcard and emmc Sep 04 07:59:49 that means it's trying to install the bootloader the old way, which also means it's not overwriting the new bootloader which takes precedence Sep 04 08:00:30 simplest solution is wiping sector 256 Sep 04 08:01:01 zmatt: ah ok. so the new bootloader starts from mmcblkboot0/1 ? Sep 04 08:01:05 no Sep 04 08:01:18 sector 256 of mmcblk0/1 Sep 04 08:02:28 another solution is wiping the whole eMMC using blkdiscard at the very beginning of the flashing procedure Sep 04 08:02:42 that's probably not a bad idea anyway Sep 04 08:03:44 zmatt: thank you, I'm going to try to wipe that sector. however, where can I find some documentation about the newest boot process and bootloader offsets? Sep 04 08:05:59 well, it's a two-stage process: ROM tries to locate an "MLO" in various locations. This is documented in detail in the am335x TRM, but you can find a summary here -> https://github.com/mvduin/bbb-asm-demo#booting-μsdemmc Sep 04 08:06:35 when using u-boot, this file contains the u-boot "SPL" (secondary program loader), which loads the full u-boot Sep 04 08:07:04 the offset at which the full u-boot is located is hardcoded in a compile-time config file of u-boot Sep 04 08:07:40 for the u-boot used on bbb nowadays that's sector offset 768 Sep 04 08:09:09 zmatt: ok so now I'm going to backup sectors 0-2047 of /dev/mmcblk1, then I'll try to wipe sector 256 Sep 04 08:15:05 zmatt: this is what I did: "dd if=/dev/zero seek=255 count=1 obs=512 of=/dev/mmcblk1" (I wiped sector 256). so now I should be booting with the old bootloader? I'm getting the same problem... Sep 04 08:15:25 seek=255 means you wiped sector 255 Sep 04 08:15:29 not 256 Sep 04 08:15:58 obs=512 is default btw Sep 04 08:16:26 seek=N skip N obs-sized blocks at start of output --> i skipped 255 blocks and then wrote the 256th ?? Sep 04 08:17:16 zmatt: however, no problem: I've a backup. I'll try with seek=256 Sep 04 08:17:22 I didn't say the 256th sector, I said sector 256 :) Sep 04 08:17:27 sector 0 is the first sector Sep 04 08:17:59 zmatt: ah, ok! :P Sep 04 08:18:31 no need to restore from backup btw, sector 255 isn't used for anything Sep 04 08:18:47 zmatt: perfect! fastest to do :P Sep 04 08:18:53 faster Sep 04 08:23:05 uhm... not a good result :( "ERROR PLEASE RESET BOARD" then keep producing character "C : "CCCCC..." !! Sep 04 08:23:25 o.O Sep 04 08:23:30 zmatt: anyway, booting from sdcard still works (so I can restore that sector) Sep 04 08:24:44 okay that makes no sense to me... especially that first error Sep 04 08:25:20 CCCCC normally indicates ROM can't find MLO, but then that would be the only output Sep 04 08:25:44 zmatt: maybe the first error is due to sdcard extraction during reset Sep 04 08:26:09 zmatt: if I reset again i obtain only CCCC Sep 04 08:26:44 ah Sep 04 08:26:51 then it couldn't find a bootloader Sep 04 08:28:23 zmatt: then I could try to restore the first sectors of the initial mmc (before flashing) and try again... Sep 04 08:28:39 it that suggests the new u-boot is the only u-boot Sep 04 08:30:39 zmatt: ?? Sep 04 08:38:57 if there were a valid u-boot in the FAT partition then it would fall back to that after wiping sector 256, that didn't happen evidently Sep 04 08:52:19 hi Sep 04 08:52:37 i am looking for a distributor for beagleboard in India Sep 04 09:14:15 zmatt: ok. now Sep 04 09:14:52 I reverted the previous boot sectors Sep 04 09:22:42 zmatt: so to recap: we tried to wipe sector 256. since BBB doesn't find MLO after that sector wiping, it means that none of 0, 256, 512, 768 sectors contains a valid bootoloader and this means the "old-one" was the only bootloader existing on the internal emmc. correct? Sep 04 09:32:57 there's normally never one at those other offsets Sep 04 09:33:19 but you mentioned there was a FAT partition Sep 04 09:33:35 the only reason for that to exist is for the bootloader Sep 04 09:33:46 (ROM checks for one after trying the fixed offsets) Sep 04 09:37:11 zmatt: ok. so could it be a good idea (in your opinion) to try to dd extra/raw-mmc-header.img to the emmc? what have no sense for me is that system boots correctly on an older BBB, so it means the new one has something different into the internal emmc. Sep 04 09:37:45 zmatt: alternatively I could try to copy the first emmc sectors from the older bbb to the new one and see if it boots Sep 04 09:41:46 zmatt: I'm quite confused because that script has always worked like a charm. If the hw is not changed, the only reason could be the bootloader. However, I also tried upgrading the kernel: using the 4.1.15-ti-rt it boots. I'm not sure to have understood where's the problem :( Sep 04 10:02:06 hi everyone. I'm trying to enable a custom overlay (dto) to enable rs485 on uart5 running with 4.9 kernel Sep 04 10:02:23 the problem is, how do I load this dto at runtime? Sep 04 10:13:06 zmatt: this is what the flasher scripts does for the boot records: https://pastebin.com/Wx6ssRm0 Sep 04 10:17:24 zmatt: tried to boot with another (updated) kernel: works! Sep 04 10:17:56 zmatt: so the problem seem related to the kernel Sep 04 10:18:15 zmatt: will this imply that something hw-side has changed? Sep 04 10:26:29 alfatau: okay, so it does install the new bootloader... then I don't understand why you'd see a difference between two beagles, nor why it makes two partitions Sep 04 10:26:36 oh it doesn't Sep 04 10:26:44 only the card has two partitions Sep 04 10:29:37 Epilog[]: do you specifically need to load it at runtime rather than at boot ? Sep 04 10:35:13 zmatt: debugging kernel output, on the new BBB it produces these messages: to be able to boot I inserted the microsd card just after the kernel loading started, otherwise I'll get the message "waiting for root device": https://pastebin.com/xEShmcDH Sep 04 10:35:48 hi/help Sep 04 10:36:09 zmatt: then it seem the old kernel is no more able to load the eMMC... Sep 04 10:36:45 zmatt: correct? Sep 04 10:37:16 I have expand my SD card after reboot it is not booting . Please help how i can restore partition table Sep 04 10:42:43 alfatau: ?? Sep 04 10:44:10 alfatau: "root=/dev/mmcblk1p2" is definitely wrong Sep 04 10:44:40 "root=/dev/mmcbld" even more so, where on earth did that come from Sep 04 10:45:07 sounds like there might have been an ancient u-boot and an sd-card for storage in the mix? Sep 04 10:45:09 normally u-boot will pass the correct root= Sep 04 10:45:36 zmatt: I pasted here https://pastebin.com/xEShmcDH some output obtained booting with the customized OS but pushing microsd during boot. otherwise boot process stucks with message "waiting for root device". Sep 04 10:45:55 alfatau: that means you've simply booted from sd card now, not eMMC Sep 04 10:45:55 IIRC in the early days the mmc devices got renumbered depending on the presence of an sd-card Sep 04 10:46:05 yes Sep 04 10:46:46 but his eMMC has only one partition so mmcblk1p2 is definitely wrong Sep 04 10:47:10 (mmcblk1 can never refer to the sd card, regardless of kernel version) Sep 04 10:48:02 zmatt: I know. the difference is that if I boot (load bootloader) from sdcard, with the default kernel on the sdcard, lsblk shows me both emmc and sdcard. booting from emmc and inserting sdcard just before mounting root, make the system to boot but emmc is not detected. Sep 04 10:49:10 can you show full kernel log? Sep 04 10:49:13 tbr: it's possible I've an "ancient" u-boot. however just upgrading the kernel makes it booting. Sep 04 10:49:15 [ 1.824180] mmc1: unrecognised EXT_CSD revision 8 Sep 04 10:49:20 that looks... very odd Sep 04 10:50:00 stuff looks really confused Sep 04 10:50:11 zmatt: yes, I can paste the full kernel log: wait a sec Sep 04 10:50:51 ohhhh, maybe it really *is* just a hw difference Sep 04 10:50:57 combined with a really old kernel Sep 04 10:50:59 zmatt: right now I'm just trying to understand the differences between 4.9 and the old slots way. Sep 04 10:51:15 Epilog[]: 4.9 still support the slots way Sep 04 10:51:27 zmatt, tbr: this is the full log (without inserting sdcard during boot) https://pastebin.com/Pm6kJzD3 Sep 04 10:51:36 really? What is the file located? Sep 04 10:51:57 uhh, something like /sys/devices/platform/bone_capemgr/slots ? Sep 04 10:52:52 zmatt: I can only see "/sys/module/bone_capemgr" Sep 04 10:52:58 zmatt,tbr: the old kernel is a customized kernel with a custom rt-patch driver. Sep 04 10:53:33 alfatau: yeah, I see now the issue isn't remotely like any of the previous guesses Sep 04 10:53:53 that new bbb has a newer eMMC that implements version 5.1 of the eMMC standard Sep 04 10:54:30 and your old kernel doesn't support it Sep 04 10:54:53 (even though I'm pretty sure that removing the version should would allow it to work just fine) Sep 04 10:54:57 zmatt: oh-my-god! so what did you read from the kernel log that pointed you to this conclusion? Sep 04 10:54:58 *the version check Sep 04 10:55:17 [ 1.688013] mmc1: unrecognised EXT_CSD revision 8 Sep 04 10:55:53 that's the ECSD revision for eMMC 5.1 Sep 04 10:56:02 zmatt: very clear :P Sep 04 10:56:21 zmatt: so what about "version check" ? what do you mean? Sep 04 10:56:22 yeah I had to look it up in the eMMC standard Sep 04 10:56:36 well I'm pretty sure that eMMC 5.1 is fully backwards compatible Sep 04 10:56:54 zmatt: should I re-compile the custom kernel? Sep 04 10:57:07 so the only reason it doesn't mount is because the kernel sees that EXT_CSD revision number and refuses to do anything with it Sep 04 10:58:31 zmatt: yes i understand now (would have been impossible for me to understand the problem without your help!) Sep 04 10:59:50 zmatt: so looking here https://e2e.ti.com/support/embedded/linux/f/354/t/545614 it seems that I need to re-compile the custom kernel... do you know if there's some other workaround to avoid to re-compile the whole kernel? Sep 04 10:59:54 of course it would also be a good idea to try to move to a newer kernel at some point... but until you're ready to do so it should be easy enough to fix this with a tiny patch Sep 04 11:00:23 you make it sound like recompiling the kernel is a lot of work Sep 04 11:03:32 zmatt: yes, that kernel was not patched by me, but by another developer that now I cannot meet for support... Really, the problem is that I have an updated release of the same custom system that works with a 4.4-rt version of the kernel and PRU. Unfortunately the latency of that kernel, even using one PRU is not enouth for the current application : Sep 04 11:03:33 ( Sep 04 11:05:07 zmatt: so actually I'm still flashing the old-kernel even if I'm not happy to do it :( Sep 04 15:53:14 hello everyone, i have a question on beaglebone black power draw, can somebody help me Sep 04 18:15:08 * zmatt . o O ( well, not if you keep that question to yourself... ) Sep 04 19:11:21 can any one please provide the hts code of an BBBWL-SC-562 Sep 04 19:12:05 hts code of the BBBLUE or the BBBWL-SC-562 Sep 04 19:12:12 the harmonized code tariff Sep 04 19:12:19 please Sep 04 19:21:19 Help1 Sep 04 19:21:46 HELP! Sep 04 19:36:47 people Sep 04 19:37:50 lol Sep 04 19:38:26 i searched https://hts.usitc.gov/, and looked at my blue box. nothing Sep 04 19:41:04 HEY Sep 04 19:41:08 C'mon Sep 04 19:46:38 thank you Sep 04 20:13:40 Hi, I am trying to boot a uImage onto my BBB via IPoverUSB interface. The problem is the the DHCPd is not binding to eth1 interface as it does not exist during the boot-up. Could any of you please guide me, thank you! Sep 04 22:52:38 Hello, Sep 04 22:53:02 I have inherited a project with a beaglebone. Sep 04 22:53:30 I'm lining up to make some changes about the power supply Sep 04 22:54:07 Could I possibly ask a few questions of someone regarding that area of the beaglebone? Sep 04 22:55:28 Is there anyone there? **** ENDING LOGGING AT Tue Sep 05 03:00:00 2017