Beaglebone stops booting from SD

General Discussion
1

Hi all,

I have a BB Blue that has been booting and running off an SD card, however it now boots using the internal eMMC image every time. As far as I know I changed nothing about the SD card image between when it was working and when it stopped, besides maybe updating some packages. The internal image boots fine, and I am able to mount the SD card. The data appears completely unchanged from when it was working as the boot disk and I’m able to access files and folders. Plugging the card into another BB Blue has the same issue, but both can boot from a fresh image on the same SD card, so I know the issue must be with the image itself. This is also the second time I’ve ran into exactly the same issue, using the same starting image from the EduMip project.

Any help would be greatly appreciated. I have seen this may be an issue with the uEnv.txt file in the SD card but I can’t find any solution to fix it if it is. Of course I have also tried holding down the SD button on boot to no avail.

2

Hello @TyFi ,

Seth here. Will you post your /boot/uEnv.txt file please? There are some lines or at least one line that may be commented or not commented that I would like to view.

Also, older images from when the EduMip project was made may have had specific files located in the fs that enables builds and an image get ported to the eMMC.

Seth

P.S. Anyway, it is a neat project. I never got to fully address it when it was around, i.e. back when I started to use the BBB and BBBlue boards.

One thing…

There was also some issue w/ the u-boot versioning which is on the eMMC and separate, different u-boot versioning on the SD Card which entails oddity. Oddity like incorrect booting and/or updating issues ensued.

3

Hello,
Thanks for the reply. I’ve attached the uEnv.txt file from /boot. There was also a uEnv file in the root directory, I’ve included that as well in case it is relevant.

I did also double check that the boot flag was set for the SD card, and it shows as a boot device in fdisk.

uEnv 041123.txt (2.2 KB)
uEnv root 041123.txt (1.4 KB)

1 Like
4

@TyFi ,

Hello. Will you please post those .txt files in this forum instead of having me download them?

This way, there are easy reporting to the frow from the forum dialog.

Seth

5

Sure thing, here is the /boot/uEnv file:

#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=5.3.0-1042-raspi2
#uuid=
#dtb=

###U-Boot Overlays###
###Documentation: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays
###Master Enable
enable_uboot_overlays=1
###
###Overide capes with eeprom
#uboot_overlay_addr0=/lib/firmware/<file0>.dtbo
#uboot_overlay_addr1=/lib/firmware/<file1>.dtbo
#uboot_overlay_addr2=/lib/firmware/<file2>.dtbo
#uboot_overlay_addr3=/lib/firmware/<file3>.dtbo
###
###Additional custom capes
#uboot_overlay_addr4=/lib/firmware/<file4>.dtbo
#uboot_overlay_addr5=/lib/firmware/<file5>.dtbo
#uboot_overlay_addr6=/lib/firmware/<file6>.dtbo
#uboot_overlay_addr7=/lib/firmware/<file7>.dtbo
###
###Custom Cape
#dtb_overlay=/lib/firmware/<file8>.dtbo
###
###Disable auto loading of virtual capes (emmc/video/wireless/adc)
#disable_uboot_overlay_emmc=1
#disable_uboot_overlay_video=1
#disable_uboot_overlay_audio=1
#disable_uboot_overlay_wireless=1
#disable_uboot_overlay_adc=1
###
###PRUSS OPTIONS
###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
###pru_rproc (4.19.x-ti kernel)
uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo
###pru_uio (4.14.x-ti, 4.19.x-ti & mainline/bone kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
###
###Cape Universal Enable
enable_uboot_cape_universal=1
###
###Debug: disable uboot autoload of Cape
#disable_uboot_overlay_addr0=1
#disable_uboot_overlay_addr1=1
#disable_uboot_overlay_addr2=1
#disable_uboot_overlay_addr3=1
###
###U-Boot fdt tweaks... (60000 = 384KB)
#uboot_fdt_buffer=0x60000
###U-Boot Overlays###

cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet

#In the event of edid real failures, uncomment this next line:
#cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet video=HDMI-A-1:1024x768@60e

#Use an overlayfs on top of a read-only root filesystem:
#cmdline=coherent_pool=1M net.ifnames=0 rng_core.default_quality=100 quiet overlayroot=tmpfs

##enable Generic eMMC Flasher:
##make sure, these tools are installed: dosfstools rsync
#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh

And the one from the root directory:

##Rename as: uEnv.txt to override old bootloader in eMMC
##These are needed to be compliant with Angstrom's 2013.06.20 u-boot.

loadaddr=0x82000000
fdtaddr=0x88000000
rdaddr=0x88080000

initrd_high=0xffffffff
fdt_high=0xffffffff

##These are needed to be compliant with Debian 2014-05-14 u-boot.

loadximage=echo debug: [/boot/vmlinuz-${uname_r}] ... ; load mmc 0:1 ${loadaddr} /boot/vmlinuz-${uname_r}
loadxfdt=echo debug: [/boot/dtbs/${uname_r}/${fdtfile}] ... ;load mmc 0:1 ${fdtaddr} /boot/dtbs/${uname_r}/${fdtfile}
loadxrd=echo debug: [/boot/initrd.img-${uname_r}] ... ; load mmc 0:1 ${rdaddr} /boot/initrd.img-${uname_r}; setenv rdsize ${filesize}
loaduEnvtxt=load mmc 0:1 ${loadaddr} /boot/uEnv.txt ; env import -t ${loadaddr} ${filesize};
check_dtb=if test -n ${dtb}; then setenv fdtfile ${dtb};fi;
check_uboot_overlays=if test -n ${enable_uboot_overlays}; then setenv enable_uboot_overlays ;fi;
loadall=run loaduEnvtxt; run check_dtb; run check_uboot_overlays; run loadximage; run loadxrd; run loadxfdt;

mmcargs=setenv bootargs console=tty0 console=${console} ${optargs} ${cape_disable} ${cape_enable} root=/dev/mmcblk0p1 rootfstype=${mmcrootfstype} ${cmdline}

uenvcmd=run loadall; run mmcargs; echo debug: [${bootargs}] ... ; echo debug: [bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr}] ... ; bootz ${loadaddr} ${rdaddr}:${rdsize} ${fdtaddr};
1 Like
6

This is the new software for the EduMip project. I am not so sure about how root has anything to do right now w/ u-boot and I may not be able to reenact the issue.

Hmm.

I might be out.

#cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh was the file in question for handling the SD Card to eMMC install then.

There may be some files in /opt/scripts/tools or /opt/scripts. It may be a long shot but maybe there is a file in those files that is creating the eMMC build from the SD Card.

Seth

P.S. Maybe listing the contents of the /opt/scripts/tools dir. and the /opt/scripts dir. could make me remember?

So,

ls -la /opt/scripts/tools && ls -la /opt/scripts

That output may prove useful to me so far. This is an odd circumstance that I did not know could happen w/ the BBB or BBBlue b/c of older libs, u-boot, and the kernels.

If you have the SD Card and you want to keep its contents, okay.

Maybe backup the contents of the SD Card, copy it to another SD Card, and then try to erase some eMMC first few bytes. I remember there was/is a fellow that taught me about an issue during this time.

sudo blkdiscard /dev/mmcblk1 # Or whatever the eMMC name is on that image...

Maybe also give the output of…

ls -la /dev/mmc*

Be careful to not have a backup in case the system cruds out.

When you say, And the one form the root directory, I have not known there to be a uEnv.txt file in root.

But, it is acting like, from what I see, loadxrd is causing the issue of it building to eMMC from SD Card.

I need to research older u-boot (if it is still around). Also, in the meantime, try to research u-boot and files associated w/ loadximage, loadxfdt, loadxrd, loadEnvtxt.

I will try but I cannot promise anything now. I am not well versed in uboot or changes along the way (sort of). But yes sir, I think the idea of things being compliant w/ Debian 2014-05-14 u-boot can shed light on this issue.

I researched some. I am not familiar w/ kernel 5.3.x at all. Researching kernel 5.3.x will help and learning what u-boot versioning is used via your UART0 debug header will also help in u-boot prompts.

One thing I do no get:

You are on kernel 5.3.x w/out a dtb in uEnv.txt
and...
There is something else going on I cannot discuss for some reasoning

Did you make the image yourself? It looks and feels like a beagleboard.org image but the case of root having authority of the uEnv.txt files via u-boot is new to me.

7

Hi @TyFi ,

Ok I don’t own a BB Blue so I am assuming the boot sequence is the same as the BBB.

There are a couple of possibilities and things you can try.

Firstly the board will always try to boot from the eMMC unless you hold down the SD button on power up, in which case it will try to boot from the SD card first.

However if something fails trying to boot the first choice, it will try the second option.

You have a valid eMMC image as that is booting, so that is what it does.
However you have said you have tried holding down the button to force a boot from the SD card and this still boots from the eMMC.

There are three possibilities here.

  1. Your SD card is corrupted in some way causing u-boot to fall back to the eMMC.
  2. You have an issue with the boot switch not closing and so it always boots from eMMC even when pressing the button.
  3. There is an issue with the SD card interface, however you have said you can mount the SD card once booted from eMMC, so there is no issue with the interface.

To check 1, get a spare/new SD card and flash a new image and then try booting that, holding down the boot button. If that still fails, then in all likely hood it is a faulty button.

Have you got a serial terminal connected ? It would be handy to see what u-boot messages you are getting when the board boots.

You said it used to work, but you haven’t changed anything apart from some updates. When it was working I assume you were pressing the boot button to make it boot from the SD card, because with a valid eMMC image it will boot from there first always.

Did you or someone at some point in time modify any u-boot variables ?
It is possible to modify the u-boot boot sequence such that while u-boot gets loaded from the eMMC, you can then get u-boot to actually boot from the SD card first and then fall back to eMMC if that fails.

I am not sure if you can cause this by changing uEnv.txt.

You can force booting from SD card, by erasing the eMMC. You don’t need to erase all of it. I think just the first few K is enough, although if I do this I usually wipe a meg or two. You should be able to do this once booted using the dd command.
This is a drastic option, as if the SD card interface is faulty you will brick the board, however you have said you can read the SD card once booted, so wiping the eMMC should be safe.

1 Like
8

Hi all,
Thank you for the very thorough replies! Unfortunately I haven’t been able to test the solutions involving the eMMC as the beagle bone is currently being used in another project. I didn’t want to risk bricking it if the flash goes badly, is that a concern with erasing the eMMC?

/opt/scripts/tools on the left and /opt/scripts on the right:
image
(sorry for screenshots, I can only read the card thru windows for now)

Also the image itself is larger than 4GB so I don’t think it can be flashed to the eMMC? or would flashing it just update u-boot on the eMMC?

I did not make the image myself, the only major changes as far as I know has just been to upgrade the installed packages. However, the SD card worked perfectly fine with those updates for at least a few on/off cycles.