BeagleV-Ahead automatic SD card boot

Hello all,

I built the uboot for the BeagleV-Ahead (GitHub - beagleboard/beaglev-ahead-u-boot: Mirror of:, put it on an SD card and booted the uboot on the BeagleV-Ahead. However, to do so, I had to press the “SD” button on the board during power up. I would like to not have to press the “SD” button to boot from sd card. Is this possible?

Best regards,

How did you put it on the SD card? special formatting, position?

Vendor had not provided the proper SD card format instructions, so i never test booted the SD card…


Via dd:

sudo dd if=u-boot-with-spl.bin of=/dev/disk/by-id/<my-sd-card> seek=64

That’s awesome!

I so need to test that tonight, board’s at home!.. That’s so simple, why didn’t they want to share that in our hours and hours of technical meetings…

But yeah, today you need to hold the SD card down.

I’ve got a patch from Sipeeed i’m going to port over to our board, to also scan for extlinux.conf boot/scanning of sd card.


1 Like

Hello Robert,

thanks for your answer! Unfortunately I am not very familiar with booting uboot, so I don’t fully understand your answer.

First of all, here is what I did, so you can try and reproduce it:

  1. I cloned the beaglev-ahead-u-boot git (GitHub - beagleboard/beaglev-ahead-u-boot: Mirror of: and used the branch “beaglev-v2020.01-1.1.2”
  2. make light_beagle_defconfig
  3. make CROSS_COMPILE=riscv64-linux-gnu- -j16
  4. sudo dd if=u-boot-with-spl.bin of=/dev/disk/by-id/<my-sd-card> seek=64
  5. sync

Then I put the SD card into the board’s SD card slot, pressed the SD button and pressed the reset button. I believe that it boots from sd card, because a) without an SD card I get the errors:

[APP][E] protocol_connect failed, exit.
[APP][E] sd card boot error.
brom_ver 8

and b) with the SD card I see different build dates in the uboot log:

U-Boot SPL 2020.01 (Jun 10 2023 - 20:19:32 +0000)
U-Boot 2020.01-00038-gbbf3994802 (Aug 08 2023 - 14:12:23 +0200)

To be honest, I don’t know exactly what you refer to by porting a patch such that it scans for extlinux.conf. Is extlinux.conf some config file, which would then have to be present on the SD card, so that the board boots from SD card? If so: how would I have to format the SD card and what would the contents of the extlinux.conf be?

1 Like

i must have missed something, it didn’t work for me.

Hello amf99,

I tried to reproduce my steps myself, and the behaviour is really strange! I actually cannot reproduce it myself, while I still have the one SD card, where it seem to boot the uboot, which I built on 8th of August … I don’t know what’s going on, to be honest.

First of all, forgot to mention 1 step, which I probably did: In the light_beagle_defconfig I changed the parameter “CONFIG_OF_EMBED=y” to “CONFIG_OF_EMBED=n”

Here is the UART output (picocom) with the one SD card, where it seems to work:


Type [C-a] [C-h] to see available commands
Terminal ready
brom_ver 8
[APP][E] protocol_connect failed, exit.

U-Boot SPL 2020.01-00038-gbbf3994802 (Aug 08 2023 - 14:12:23 +0200)
FM[1] lpddr4x singlerank freq=3733 64bit dbi_off=n sdram init
ddr initialized, jump to uboot
image has no header

U-Boot 2020.01-00038-gbbf3994802 (Aug 08 2023 - 14:12:23 +0200)

CPU:   rv64imafdcvsu
Model: T-HEAD c910 light
DRAM:  4 GiB
C910 CPU FREQ: 750MHz
MMC:   sdhci@ffe7080000: 0, sd@ffe7090000: 1
Loading Environment from MMC... OK
Error reading output register
Warning: cannot get lcd-en GPIO
LCD panel cannot be found : -121
splash screen startup cost 15 ms
In:    serial
Out:   serial
Err:   serial
Warning: ethernet@ffe7070000 (eth0) using random MAC address - 6e:94:d1:1e:b4:b7
eth0: ethernet@ffe7070000ethernet@ffe7070000:0 is connected to ethernet@ffe7070000.  Reconnecting to ethernet@ffe7060000

Warning: ethernet@ffe7060000 (eth1) using random MAC address - ca:72:23:e4:84:8b
, eth1: ethernet@ffe7060000
Hit any key to stop autoboot:  0
50340 bytes read in 1 ms (48 MiB/s)
15748 bytes read in 0 ms
85856 bytes read in 2 ms (40.9 MiB/s)
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0:2...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
264 bytes read in 0 ms
1:      Linux eMMC
Retrieving file: /Image
27543040 bytes read in 86 ms (305.4 MiB/s)
append: root=/dev/mmcblk0p3 rw rootfstype=ext4 rootwait console=ttyS0,115200 earlycon clk_ignore_unused init=/init rootinit=/sbin/init rootrwoptions=rw,noatime net.ifnames=0
Retrieving file: /light-beagle.dtb
170543 bytes read in 2 ms (81.3 MiB/s)
## Flattened Device Tree blob at 46000000
   Booting using the fdt blob at 0x46000000
   Using Device Tree in place at 0000000046000000, end 000000004602ca2e

Starting kernel ...

[    0.000000] Linux version 5.10.113-yocto-standard (oe-user@oe-host) (riscv64-linux-gcc (Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.2.8 B-20221201) 10.2.0, GNU ld (GNU Binutils) 2.35) #1 SMP PREEMPT Sat Jun 10 03:53:19 UTC 2023
[    0.000000] OF: fdt: Ignoring memory range 0x200000 - 0x40200000


I also seem to still have the “u-boot-with-spl.bin” file, which I flashed on the SD card. When I flash this binary to another (similar) SD card, it does not work. When binary comparing the “u-boot-with-spl.bin” from 8th August with the one I build yesterday, this is the output:

cmp -l u-boot-with-spl.bin ../beaglev-ahead-u-boot.old/u-boot-with-spl.bin | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
0001F8B4 32 31
0001F8B5 33 30
0001F8B7 31 32
0001F8B8 35 37
0001F8BA 33 30
0001F8BB 30 33
0009A31F 32 31
0009A320 33 30
0009A322 31 32
0009A323 35 37
0009A325 33 30
0009A326 30 33

I got the compare command from diff - How do I compare binary files in Linux? - Super User
It does not seem to be so much difference - I guess (but don’t now for sure) that its just date strings inside the binaries which differ, but I don’t know. Anyone any suggestion what I could do?

Best regards,

1 Like

what class/brand/size is the sdcard that works.
time for me to break out all my cheat sheets.

Hello amf99,

the SD card on the right (in the box) is the one, which works. The one on the left doesn’t. The problem is: They are both the same type!

Now, I really think that I may have confused, what I actually flashed on the working SD card. I was absolutely not aware, that preparing an SD card for the BeagleV-Ahead was such a big deal. And I also tbh. did not so much know what I was doing: I actually just compiled the u-boot and afterwards flashed different binaries in a trial-and-error manner onto the SD card, untill it worked. Then I cared more about the annoying button.

What I could do is obtain the image from the working SD card, e.g., via dd and then try to identify from that which binary file was flashed onto the SD card. However, I would need help for that, i.e., which tools to use for something like that, because I don’t know how to do this. Also if there are tools to get some hardware specifics of the two cards, I could use them and drop the output here. If someone is really proficient with this stuff, I could even send the SD card to that person, given, that I get it back eventually.

The image also contains the only serial interface I had at hand, which worked with the BeagleV-Ahead (see also How to see boot messages on uart). Unfortunately it stopped working :frowning: So I have to get another one. So, with regards to testing, my hands are a bit tied.

Best regards,

(Wrong forum link: I meant this thread, when talking about the only serial interface, which worked for me: BeagleV-Ahead - debug terminal problems)

by setting “CONFIG_OF_EMBED=n”, i get the following when starting the build. so which of these are you using ?

Provider of DTB for DT control
> 1. Separate DTB for DT control (OF_SEPARATE)
  2. Embedded DTB for DT control (OF_EMBED) (NEW)
  3. Provided by the board at runtime (OF_BOARD)
  4. Prior stage bootloader DTB for DT control (OF_PRIOR_STAGE)

I just freshly cloned the repo again, checked that it was on the correct branch (beaglev-v2020.01-1.1.2), changed to CONFIG_OF_EMBED=n in the light_beagle_defconfig and then did the steps described above to compile. On my PC, the menu you described did not come up, so I did not have to choose anything …

that’s interesting,
beaglev-v2020.01-1.1.2, is the git branch that i’m using also, this is also the same branch that yocto build is using. I would think that we both should get the same build results.
Being the u-boot image is less than 1M, could ya copy off the first 2Megs from the working sdcard and some how send it to me? Maybe we can use Dropbox.
the seek=64 is 32768 offset, correct? so 2 Megs should cover it

One more question to everyone reading this: Could you please allow me to post here right away without “waiting for allowance to post”?!? This is super annoying, thanks!

Best regards,

1 Like

Ok, interesting news!

As mentioned, my only working serial adapter broke. So I currently don’t have any means to see the boot log. However, what I noticed: With the one working SD card, after approx. 10 seconds, the blue LEDs start blinking. This does not happen with any of the other cards: There the LEDs were all on, not blinking.

However, when writing the 2MB image file (obtained from the working SD card via ‘dd’) to another Sandisk SD card and put that into the BeagleV-Ahead, keep the (annoying) SD card button down and apply power to the board, the LEDs also start blinking after approx 10 seconds! So maybe it is working? Can you try to reproduce this? If this is working, then it might not be the SD card after all, but maybe I actually confused what I actually flashed or built …

Best regards,

Hello Everyone,

Is this a fact? Is it a fact that the BeagleV-Ahead can boot via SD Card? I have been trying w/ xuantie but have come up short. I used the build on the site and it boots via USB to eMMC which is nice and dandy…

Is there a particular set of commands one would use to handle flashing to SD Card? I reviewed the repo online and still cannot get my SD Card outside of cfdisk to get working w/ mkfs.ext4 and then mounting it.

I know…I can learn a thing or two.


P.S. I have not tried the CP2102 yet on the Debug Header. I will try that next.

Could it be, that you changed it in the .config? I changed it in the defconfig, and then (the relevant part) of the .config looks like this:

# Device Tree Control
# CONFIG_OF_LIVE is not set
# CONFIG_OF_EMBED is not set
# CONFIG_OF_BOARD is not set
CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names interrupt-parent interrupts"

So, I think, maybe if one sets CONFIG_OF_EMBED=n in the light_beagle_defconfig, it maybe automatically sets CONFIG_OF_SEPARATE=y in the .config? But I.d.k. for sure.

I of course can provide you an image of the SD card! I obtained a 2MB binary file from the SD card with the following command:

sudo dd if=/dev/disk/by-id/usb-UGREEN_MassStorageClass_0123456789ABCDE-0\:0 bs=1M count=2

Dropbox would be an option. I write you via PM.

Best regards,

To all BeagleV-aHead fans;
Thanks to Kilian,
He has made a u-boot-with-spl image that when dd to a sdcard, without any seek offset. the BeagleV board will boot when the SD button is pressed during power on or when reset is pressed.
I have placed the image on several different, including cheap, sdcards and it works.
However, we are still trying to find which u-boot settings were used to reproduce the working image. So we are almost there.

1 Like

yes, Kilian created a u-boot image that boots from the sdcard, however we can not reproduce the build. WIP. the u-boot-with-spl.bin is just dd to the sdcard, no seek offset, no partitioning.

@amf99 Look at this stackoverflow article:

See the response “In my devices UBoot automatically creates a “ver” environment variable containing its version”: You could do 2 tests: First, you could boot without an SD card an have the “space” key pressed, until you get into the u-boot console. There you could execute printenv and have a look at the “ver” variable. Alternatively you could also try the “version” command, as seen in this screenshot:

Hopefully you then get the version and the build date.

Then you basically do the same, but with the SD card (don’t forget to press the annoying SD button). If you then see a different build date (or other variables differ), then it must be the case, that you boot another uboot, hence you then most likely really booted a uboot from the SD card.

Could you try to do this test?

Best regards,