Hi.
My situation : beaglebone black boots on eMMC, unless I put a flasher microSD in the slot, in which case the microSD is copied on the eMMC and the beaglebone shuts down. Then, we need to unplug the microSD, and repower the beaglebone. We use this process when we need to “fix” some PRU corruption.
The situation I would like: the beaglebone black always boots on the eMMC, even if a flasher is plugged. We can flash on demand when it’s needed and the beaglebone restarts instead of powering off after flashing the master. No need to press any buttons on the board, everything can be done through the console.
How to do it?
I read things about uEnv.txt, u-boot, button-pressing-during-boot and whatnot, but I can’t figure out if what I want to do is as simple as tweaking a uEnv.txt file somewhere, or if a deep dive in u-boot’s arcanes is needed.
I kinda understood I should not have a uEnv.txt file on the microSD, in order to never boot on it. But if I do this, after it’s flashed onto the eMMC, there would be a uEnv.txt missing, wouldn’t it? It seems some people needed to press a button on boot to flash from the eMMC, so I guess there is a way to not flash by default.
I thought I could just get away with it by commenting cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh in uEnv.txt, but it appears that it’s already commented…
Of course it would be best to solve the PRU corruption problem in the first place, but we don’t have the ressources for that at the moment.
As long as your microSD does not have any of these files in that location or name… U-Boot will just move on from microSD to eMMC in the boot search process…
Once your microSD is used to flash the eMMC (and has completed the flashing procedure), just either ‘reformat it’ or just mount it and remove the boot trigger files listed above…
Hmm, ok, so if I understand we “just have to” tweak the flasher script to change the file names after flashing on boot, and manually call another script to mount the microSD and revert the files’ names back before flashing again if needed. I’ll tell the guys about this, and see how it goes.
The main goal was ‘bulk’ programming… Once you setup the microSD for flashing, it actually boots up in single user (read only) mode… So once it completes flashing the eMMC, the board just shuts down.
The next step would be to remove the microSD and go to the next board, and flash it.
So looking at our flashing technique… What do you expect or want us to do…
If we ‘disable’ the flasher after it’s done and before the board shuts down.
On the next power up, it’ll still boot to the microSD (as that is default over eMMC) but not flash the eMMC…
In deed, our quick hack didn’t work so smoothly! I guess it was to be expected since what we want it not was it was designed for (keeping the µSD for ever slotted and only calling it when reflashing is needed, as a restore rescue).
We tried to add mv /tmp/rootfs/boot/uEnv.txt /tmp/rootfs/boot/uEnv.txt.disabled in line 377 of the flasher-maker script to make a flasher on which the beaglebones doesn’t boot, and that first step works.
Then, when we want to falsh we call a simple script which just restores the flasher’s uEnv.txt name: mv /mnt/boot/uEnv.txt.disabled /mnt/boot/uEnv.txt and reboots the system. This second step also works.
The third step doesn’t. That would be to rename uEnv.txt as uEnv.txt.disabled after the flashing is done and before rebooting, to avoid flashing again and again.
But as you said, when flashing, the µSD is in read-only mode, and therefore the kernel panics when we try to rename uEnv.txt.
We briefly tried to find where the µSD was mounted as -ro in the scripts, but it seems we were mistaken: -ro mounting comes from the single-user mode boot? Is there anyway to change that?
It seems renaming the files right before shutdown was the solution, and that happens in generic-starup.sh.
Thank you so much, we need more testing but this looks promising!
In the SoC, boot proirity is controlled by pin strapping at start up time. So there is S2 (Boot) switch on the board. The button is pressed, it boots from sd. Not pressed, and it boots from mmc. That’s it, clear and simple.
Not any more. With recent test builds, the clarity is ruined by a software trick that overrides the boot rom’s decision. This change may or may not add convenience, depending on usage scenarios. For instance, if I’m playing with a custom SPL code on SD card, I still have to press the button. Anyway it looks more like an ad-hoc change rather than from a strategy. As every ad-hoc solution, it solves one problem and creates another.
Now it’s difficult to document the boot process. I’m not mentioning the software domain, the situation there is totally hopeless for a long time. But the SRM document, that provides a new user with some orientational info, still exist. I have a feeling that because of very few basic conventions proposed by the document, the author was hoping that the SW guys will pay due respect to the conventions, for the sake of common sense. With recent builds, all the SRM information about the booting remains technically correct, but now it does contradict with factual user experience about SD card. The user gets confused from the beginning. Not good. The document is made to be as SW-neutral as possible. So it makes little sense to contaminate it with volatile SW particularities. But it’s difficult to explain the new boot process otherwise. That’s the main problem, IMHO.
My overall impression is that now the board is more convenient for using but less convenient for experimenting. But it’s an EVB, after all. Those obsessed with convenience can buy a true consumer-oriented device, like iPod iPhone, etc. Who cares how it work, convenience is the only matter. So I think the boot selection method change is not well aligned with initial product goals.