alfatauhi 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
alfatau 'bootargs' other than uEnv.txt?
zmattnormally you don't set 'bootargs' directly in uEnv.txt
zmattit's constructed by u-boot from various variables, including 'cmdline' which is set in /boot/uEnv.txt
zmattand a bbb normally doesn't have any enclosure
alfatauzmatt: 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?
tbralso if your flash image is old. I'd recommend to try latest.
zmatthow exactly did you flash the eMMC ? it sounds like your older bbb still uses some very old u-boot
zmatt"card did not respond to voltage select" is because u-boot attempts to boot from sd card initially
zmatt"waiting for root device" also suggests some serious mismatch between u-boot and the rest of the system
zmatttbr: I get the impression he's deliberately trying to reuse some old image
zmattthat's my guess anyway
alfatauzmatt: for both BBBs I used (a customized version of ) the /opt/scripts/tools/" script.
alfatauzmatt: and the source is a pre-configured os on sdcard
zmattalfatau: how does it install u-boot ?
alfatauzmatt: let me check
zmattthe 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
tbrzmatt: yes, that was my impression too and why I suggested to try with a recent one...
alfataui'm checking the script. anyway, it does not load the uEnv.txt from the fat partition, but from the mmc/sdcard
zmattalfatau: so a FAT partition does exist?
alfatauyes, for both sdcard and emmc
zmattthat means it's trying to install the bootloader the old way, which also means it's not overwriting the new bootloader which takes precedence
zmattsimplest solution is wiping sector 256
alfatauzmatt: ah ok. so the new bootloader starts from mmcblkboot0/1 ?
zmattsector 256 of mmcblk0/1
zmattanother solution is wiping the whole eMMC using blkdiscard at the very beginning of the flashing procedure
zmattthat's probably not a bad idea anyway
alfatauzmatt: 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?
zmattwell, 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 ->╬╝sdemmc
zmattwhen using u-boot, this file contains the u-boot "SPL" (secondary program loader), which loads the full u-boot
zmattthe offset at which the full u-boot is located is hardcoded in a compile-time config file of u-boot
zmattfor the u-boot used on bbb nowadays that's sector offset 768
alfatauzmatt: ok so now I'm going to backup sectors 0-2047 of /dev/mmcblk1, then I'll try to wipe sector 256
alfatauzmatt: 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...
zmattseek=255 means you wiped sector 255
zmattnot 256
zmattobs=512 is default btw
alfatauseek=N skip N obs-sized blocks at start of output --> i skipped 255 blocks and then wrote the 256th ??
alfatauzmatt: however, no problem: I've a backup. I'll try with seek=256
zmattI didn't say the 256th sector, I said sector 256 :)
zmattsector 0 is the first sector
alfatauzmatt: ah, ok! :P
zmattno need to restore from backup btw, sector 255 isn't used for anything
alfatauzmatt: perfect! fastest to do :P
alfatauuhm... not a good result :( "ERROR PLEASE RESET BOARD" then keep producing character "C : "CCCCC..." !!
alfatauzmatt: anyway, booting from sdcard still works (so I can restore that sector)
zmattokay that makes no sense to me... especially that first error
zmattCCCCC normally indicates ROM can't find MLO, but then that would be the only output
alfatauzmatt: maybe the first error is due to sdcard extraction during reset
alfatauzmatt: if I reset again i obtain only CCCC
zmattthen it couldn't find a bootloader
alfatauzmatt: then I could try to restore the first sectors of the initial mmc (before flashing) and try again...
zmattit that suggests the new u-boot is the only u-boot
alfatauzmatt: ??
zmattif 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
santheepi am looking for a distributor for beagleboard in India
alfatauzmatt: ok. now
alfatauI reverted the previous boot sectors
alfatauzmatt: 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?
zmattthere's normally never one at those other offsets
zmattbut you mentioned there was a FAT partition
zmattthe only reason for that to exist is for the bootloader
zmatt(ROM checks for one after trying the fixed offsets)
alfatauzmatt: 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.
alfatauzmatt: alternatively I could try to copy the first emmc sectors from the older bbb to the new one and see if it boots
alfatauzmatt: 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 :(
Epiloghi everyone. I'm trying to enable a custom overlay (dto) to enable rs485 on uart5 running with 4.9 kernel
Epilogthe problem is, how do I load this dto at runtime?
alfatauzmatt: this is what the flasher scripts does for the boot records:
alfatauzmatt: tried to boot with another (updated) kernel: works!
alfatauzmatt: so the problem seem related to the kernel
alfatauzmatt: will this imply that something hw-side has changed?
zmattalfatau: 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
zmattoh it doesn't
zmattonly the card has two partitions
zmattEpilog[]: do you specifically need to load it at runtime rather than at boot ?
alfatauzmatt: 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":
alfatauzmatt: then it seem the old kernel is no more able to load the eMMC...
alfatauzmatt: correct?
Rishi_I have expand my SD card after reboot it is not booting . Please help how i can restore partition table
zmattalfatau: ??
zmattalfatau: "root=/dev/mmcblk1p2" is definitely wrong
zmatt"root=/dev/mmcbld" even more so, where on earth did that come from
tbrsounds like there might have been an ancient u-boot and an sd-card for storage in the mix?
zmattnormally u-boot will pass the correct root=
alfatauzmatt: I pasted here some output obtained booting with the customized OS but pushing microsd during boot. otherwise boot process stucks with message "waiting for root device".
zmattalfatau: that means you've simply booted from sd card now, not eMMC
tbrIIRC in the early days the mmc devices got renumbered depending on the presence of an sd-card
zmattbut his eMMC has only one partition so mmcblk1p2 is definitely wrong
zmatt(mmcblk1 can never refer to the sd card, regardless of kernel version)
alfatauzmatt: 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.
zmattcan you show full kernel log?
alfatautbr: it's possible I've an "ancient" u-boot. however just upgrading the kernel makes it booting.
zmatt[ 1.824180] mmc1: unrecognised EXT_CSD revision 8
zmattthat looks... very odd
zmattstuff looks really confused
alfatauzmatt: yes, I can paste the full kernel log: wait a sec
zmattohhhh, maybe it really *is* just a hw difference
zmattcombined with a really old kernel
Epilog[]zmatt: right now I'm just trying to understand the differences between 4.9 and the old slots way.
zmattEpilog[]: 4.9 still support the slots way
alfatauzmatt, tbr: this is the full log (without inserting sdcard during boot)
Epilog[]really? What is the file located?
zmattuhh, something like /sys/devices/platform/bone_capemgr/slots ?
Epilog[]zmatt: I can only see "/sys/module/bone_capemgr"
alfatauzmatt,tbr: the old kernel is a customized kernel with a custom rt-patch driver.
zmattalfatau: yeah, I see now the issue isn't remotely like any of the previous guesses
zmattthat new bbb has a newer eMMC that implements version 5.1 of the eMMC standard
zmattand your old kernel doesn't support it
zmatt(even though I'm pretty sure that removing the version should would allow it to work just fine)
alfatauzmatt: oh-my-god! so what did you read from the kernel log that pointed you to this conclusion?
zmatt*the version check
zmatt[ 1.688013] mmc1: unrecognised EXT_CSD revision 8
zmattthat's the ECSD revision for eMMC 5.1
alfatauzmatt: very clear :P
alfatauzmatt: so what about "version check" ? what do you mean?
zmattyeah I had to look it up in the eMMC standard
zmattwell I'm pretty sure that eMMC 5.1 is fully backwards compatible
alfatauzmatt: should I re-compile the custom kernel?
zmattso the only reason it doesn't mount is because the kernel sees that EXT_CSD revision number and refuses to do anything with it
alfatauzmatt: yes i understand now (would have been impossible for me to understand the problem without your help!)
alfatauzmatt: so looking here 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?
zmattof 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
zmattyou make it sound like recompiling the kernel is a lot of work
alfatauzmatt: 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 :
alfatauzmatt: so actually I'm still flashing the old-kernel even if I'm not happy to do it :(
alek_hello everyone, i have a question on beaglebone black power draw, can somebody help me
zmattACTION . o O ( well, not if you keep that question to yourself... )