SD card flashing / partitions

Ward

Ah my bad

diff with-sd-no-button.txt without-sd-no-button.txt
3,4c3
< Loading Environment from EXT4...
< ** Unable to use mmc 0:1 for loading the env **
---
> Loading Environment from EXT4... Card did not respond to voltage select!
18,19c17
< Loading Environment from EXT4...
< ** Unable to use mmc 0:1 for loading the env **
---
> Loading Environment from EXT4... Card did not respond to voltage select!
30,31c28,31
< 1498 bytes read in 2 ms (731.4 KiB/s)
< booting from SD card
---
> Card did not respond to voltage select!
> Card did not respond to voltage select!
> 1498 bytes read in 1 ms (1.4 MiB/s)
> booting from eMMC

giuliomoro

OK so maybe I have misinterpreted things earlier and all looks as expected.
The big picture is that without button:

if a valid boot partition is found on the emmc, the am3358 always boots from it.
The bootloader from emmc then checks if the sd card is valid for boot and if it is it reads uEnv.txt from it and boots Linux from sd card otherwise it continues booting from emmc
if no valid boot partition is found on emmc or when pressing the button, it boots directly from sd card.

So what you are observing seems expected behaviour.

Ward . I plan to add a 32 SDHC card with a valid image + extra storage space for samples. Then if the eMMC image breaks the user can hold the SD boot button to boot a valid image, and copy the SD image to the eMMC using /opt/Bela/bela_flash_emmc.sh.

I think I thought of this the other way around: keep the eMMC as a backup and always boot from SD card. That would be easiest, being things as they are.

Ward

giuliomoro So what you are observing seems expected behaviour.

Ah so then there's also some misunderstanding on my side.

My assumption (mostly based on the problems Pi users have with SD card corruption) is that SD cards are less durable than eMMC memory. Therefore I thought: boot and run Bela from eMMC and have another valid Bela image on the SD card as backup for if the eMMC image gets messed up somehow. Then the only thing end users would need to do to unbrick their unit is hold the boot button and apply power to fix the eMMC.

giuliomoro The bootloader from emmc then checks if the sd card is valid for boot and if it is it reads uEnv.txt from it and boots Linux from sd card otherwise it continues booting from emmc

Could you point me into the right direction to disable this step? Is that in /dev/mmcblk0p1/uEnv.txt ?

Ward

giuliomoro if a valid boot partition is found on the emmc, the am3358 always boots from it.
The bootloader from emmc then checks if the sd card is valid for boot and if it is it reads uEnv.txt from it and boots Linux from sd card otherwise it continues booting from emmc
if no valid boot partition is found on emmc or when pressing the button, it boots directly from sd card.

Also I don't really get what the point of the SD boot button is then, if it ends up booting from SD anyways if an SD is present...

giuliomoro

I am unsure where that decision is made. I think the logic for switching to sd card when booting from emmc may be baked into the uboot binary. Not sure how that works, maybe it overrides the content of the mmc variable which is then used by uenvcmd to put together the flattened device tree and boot linux. You may be able to override that by hardcoding partitions in uenvcmd, but you'll have to try it for yourself.

However, I think you should consider the emmc as the backup storage and the sd card as the "corruptible" one. Then you should be just fine using the default configuration and using the emmc to flash the sd if the latter fails. In that case you may have to use md or gpio (if it works) in uenvcmd to avoid booting from sd card when your button (which should be different from the one you are currently using) is pressed. As a matter of fact you could make the booting from sd your default and upon some button press boot from emmc where you'll hopefully be able to hardcode avoid jumping to sd.

Ward

giuliomoro You may be able to override that by hardcoding partitions in uenvcmd, but you'll have to try it for yourself.

I did find out yesterday that by setting mmcid to 1 in the uEnv.txt on the SD card it always boots from the eMMC, even if the boot button is pressed. Perhaps I can set mmcid using gpio in the uenvcmd= line just before load mmc ${mmcid}:2;. I'll try this tomorrow

Could this line be what makes it always prioritize the SD over eMMC?? It seems to say if you can boot from SD do that, otherwise go eMMC, which is the behavior we see. Could I set bootcmd in uEnv.txt?

giuliomoro (which should be different from the one you are currently using)

I already have the PCB's though so I can't change the gpio pin the button goes to.

Ward

giuliomoro In that case you may have to use md or gpio (if it works) in uenvcmd

So I modified uenvcmd in uEnv.txt to check if I can read P8_43:

uenvcmd=echo loading ${fdtfile}; gpio read bootbutton 72; echo "button is: " ${bootbutton}; (rest of the command...)

This prints:

(...)
loading am335x-boneblack.dtb
gpio - query and control gpio pins

Usage:
gpio <input|set|clear|toggle> <pin>
    - input/set/clear/toggle the specified pin
gpio status [-a] [<bank> | <pin>]  - show [all/claimed] GPIOs
button is: 
load mmc 0:2 0x88000000 boot/dtbs/4.14.108-ti-xenomai-r143/am335x-boneblack.dtb
(...)

This makes me think it doesn't work because the u-boot needs to have CONFIG_CMD_GPIO=y and CONFIG_CMD_GPIO_READ=y set somewhere.

Could you tell me how I figure out what address to use with md to read the gpio value?

giuliomoro

It could be that line's fault but I am surprised that the change comes from us when this behaviour is the same on upstream beagleboard bootloader. Try setting bootcmd from uEnv.txt indeed, or hardcoding the mmc=.

Ward I already have the PCB's though so I can't change the gpio pin the button goes to.

You won't need to: if you can modify uEnv.txt on the mmc so that it always boots from emmc, then when you press the button and it will skip that and boot directly from SD card. If you do need to read it, you can still use

Ward Also I don't really get what the point of the SD boot button is then, if it ends up booting from SD anyways if an SD is present...

I believe the motivation for this behaviour is that Beagleboard realised late that it was convenient that if a valid SD card was present it would boot from it instead of eMMC, but the hardware wiring was such that eMMC booted before SD card. It makes sense in most cases: if you put in an SD card, you'd expect to boot from it. But as they had hardwired an emmc-first behaviour, they introduced this as a sw workaround. Later boards (e.g.: BBAI64 I think) would have the default boot sequence so that it boots from SD card first and then eMMC.

giuliomoro

https://github.com/BelaPlatform/Bela/blob/dev/core/Gpio.cpp#L5 and https://github.com/BelaPlatform/Bela/blob/dev/include/Gpio.h#L79
Combined can give you the pin address. However, I am afraid GPIO bank 2 may need an initialization step that may be complicated. Worth trying to access it and see if the system hangs when you try to, in which case it did need initialization.

« Previous Page