The problem is while booting up rasbberry pi with uboot as boot loader not able to decrypt encrypted rootfs partition with initramfs,to debug and analyse what happening want to enable uboot debug logs. When checked with current loglevel in Kconfig it show default i.e. CONFIG_LOGLEVEL=4 these are boot logs : U-Boot 2024.04 (Apr 02 2024 - 10:58:58 +0000) DRAM: 948 MiB (effective 7.9 GiB) RPI 4 Model B (0xd03114) Core: 213 devices, 16 uclasses, devicetree: board MMC: mmcnr@7e300000: 1, mmc@7e340000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial,usbkbd Out: serial,vidconsole Err: serial,vidconsole Net: eth0: ethernet@7d580000 PCIe BRCM: link up, 5.0 Gbps x1 (SSC) starting USB... Bus xhci_pci: Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT! bcmgenet: PHY startup failed: -110 ethernet@7d580000 Waiting for PHY auto negotiation to complete......... TIMEOUT! bcmgenet: PHY startup failed: -110 U-Boot> updated the common/Kconfig default to 7 still cannot see any change in the logs kconfig snippet: config LOGLEVEL int "loglevel" default 7 range 0 10 help All Messages with a loglevel smaller than the console loglevel will be compiled in. The loglevels are defined as follows: 0 - emergency 1 - alert 2 - critical 3 - error 4 - warning 5 - note 6 - info 7 - debug 8 - debug content 9 - debug hardware I/O don't know if im able to config it correctly or are there other config parameters need to configure and which are those please let me know if any one has done this before.

I'm using U-Boot 2020.10. In U-Boot, out of two USB drives, one is recognized and the other is not. Once Debian 12 is running, I have my two USB drives that are recognized and use the same driver xhci-hcd. Here are the dmesg logs for the unrecognized USB drive [ 2.460318] usb 1-1.2: new high-speed USB device number 4 using xhci-hcd [ 2.597067] usb 1-1.2: New USB device found, idVendor=058f, idProduct=6387 [ 2.597073] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 2.597077] usb 1-1.2: Product: Mass Storage [ 2.597081] usb 1-1.2: SerialNumber: F2611EC0 [ 2.597845] usb-storage 1-1.2:1.0: USB Mass Storage device detected [ 2.612148] scsi host1: usb-storage 1-1.2:1.0 Here is the output of the command fdisk -l /dev/sdb1 Disk /dev/sdb1: 7.5 GiB, 8052015104 bytes, 15726592 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x0a0dff65 Device Boot Start End Sectors Size Id Type /dev/sdb1p1 * 1869881445 3571221465 1701340021 811.3G 7a unknown /dev/sdb1p2 * 1634566756 3553817813 1919251058 915.2G 72 unknown /dev/sdb1p3 0 0 0 0B 0 Empty /dev/sdb1p4 * 28049408 28049849 442 221K 0 Empty Partition table entries are not in disk order. The detected size is also incorrect with the USB drive recognized by U-Boot Disk /dev/sdb1: 1.9 GiB, 2013233664 bytes, 3932097 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x73696420 Device Boot Start End Sectors Size Id Type /dev/sdb1p1 1936286752 6221126032 4284839281 2T 45 unknown /dev/sdb1p2 1853169786 3723051230 1869881445 891.6G 65 Novell Netware 386 /dev/sdb1p3 1701978226 3336544981 1634566756 779.4G 20 unknown /dev/sdb1p4 0 3468733439 3468733440 1.6T d unknown When I run usb start in U-Boot, the following error message appears. Starting the controller USB XHCI 1.00 scanning bus usb@2f00000 for devices... Device not responding to set address. USB device not accepting new address (error=80000000) The error seems to be a timeout to me, but I don't know why the USB drive doesn't respond in U-Boot. Why is one of the USB drives not recognized in U-Boot?

**The goal is to sign the mender yocto image and run it on secure boot enabled raspberry pi**. I have raspberrypi-4 and the yocto image from mender (open source OTA platform). To give a quick try here is the link: **Image and Modified Files ** of generated image flash to sd card using **rasbperry pi imager **, sign with private key and **step-2** flash secure-boot-recovery pieeprom via rpiboot and boot. Referred to **Secure Boot Example Readme ** enabled secure boot on rasberrypi-4. **Step-1 Generate private key for generating signed images** Source python virtual environment, install the pycryptodmex and generate private key, then export variable KEY_FILE. source path/to/python/virtual_env/activate pip install pycryptodomex openssl genrsa 2048 > private.pem export KEY_FILE=$(pwd)/private.pem **Step-2 Secure-boot-recovery for flashing signed pieeprom to raspberrypi-4** Once the private key is generated, cloned the secure boot git reposistory and complied to get rpiboot binary. git clone https://github.com/raspberrypi/usbboot secure-boot cd secure-boot git submodule update --init make To enabled rpiboot mode, updated the program_rpiboot_gpio=5 in secure-boot/secure-boot-recovery/config.txt and connected it GND pin, then connected the raspberrypi-4 to host with usb type-C Then in secure boot directory sign the pieeprom image with generate private key in step-1 and flash it to eeprom. cd secure-boot-recovery ../tools/update-pieeprom.sh -k "${KEY_FILE}" cd .. ./rpiboot -d secure-boot-recovery Now secure boot is enabled on raspberrypi-4 it will only run signed images and refereeing to document **Raspberry Pi 4 Boot Security ** raspberrypi4 expects singed boot.img. **Step-3 Process to create a signed mender yocto image** In this process the mender yocto image is modified, the mender yocto image create a sdcard flashable imagename.sdimg which contain boot partition, Root A/B partition and data parition, so to flash boot files to boot partition it creates imagename.bootimg and then it is packaged to imagename.sdimg, to make it work with rasberrypi-4 secure boot enabled i modified files two yocto recipe file **mender-bootimg.bbclass** and **mender-part-images.bbclass** from **classes ** here are the modified files **Image and Modified Files ** that made **imagename.bootimg** to **boot.img** also added the image signing code by refereeing **sign.sh** script secure-boot/secure-boot-example and **rpi-eeprom-digest.sh** script secure-boot/tools/rpi-eeprom. Dependencies: python virtual env and kas need to be installed source /path/to/python/venv/activate pip install kas mkdir mender-raspberrypi4 && cd mender-raspberrypi4 git clone https://github.com/theyoctojester/meta-mender-community -b scarthgap cd meta-mender-community mkdir my-raspberrypi4 && cd my-raspberrypi4 After modification of files to build image **Build Command** kas build ../kas/demos/raspberrypi4-64-wifi.yml After build is complete flash imagename.sdimg to sdcard using raspberry pi Imager, below are the boot logs captured serially where got the error complaining boot.img not found on sdcard, please let me know if anything I'm missing in it. **Errors Logs:** 2.62 RPi: BOOTLOADER release VERSION:69471177 DATE: 2025/05/08 TIME: 16:21:35 2.62 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1746717695 serial 7c2 2.36 Unsupported boot order 6 2.61 Boot mode: SD (01) order f254 2.82 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div6 2.83 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div6 2.98 OCR c0ff8000 CID: 000353444a554c494580d5b740550127 CSD: 400e00325b59000076b27f800a404000 2.98 SD: bus-width: 4 spec: 2 SCR: 0x02358043 0x00000000 2.99 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ2 3.00 MBR: 0x0000c000, 206848 type: 0x0c 3.01 MBR: 0x00040000, 770048 type: 0x83 3.01 MBR: 0x000fc000, 770048 type: 0x83 3.01 MBR: 0x001b8000, 262144 type: 0x83 3.21 Trying partition: 0 3.49 type: 16 lba: 49152 'mkfs.fat' ' V ^ ' clusters 51603 (4) 3.05 rsc 4 fat-sectors 200 root dir cluster 1 sectors 32 entries 512 3.06 FAT16 clusters 51603 3.06 [sdcard] autoboot.txt not found 3.06 Select partition rsts 0 C(boot_partition) 0 EEPROM config 0 result 1 3.71 Trying partition: 1 3.76 type: 16 lba: 49152 'mkfs.fat' ' V ^ ' clusters 51603 (4) 3.08 rsc 4 fat-sectors 200 root dir cluster 1 sectors 32 entries 512 3.08 FAT16 clusters 51603 3.89 secure-boot 3.91 Loading boot.img ... 3.09 boot.sig 3.09 hash: b70a74e651e9bde92dd921ac6b26c9704077bcec431518c384aafd0c39f98fc7 3.10 ts: 1750829740 3.10 rsa2048: 7937a7eeacf12d1433011cc1fcbd57901e0d0796fafce03d811a44e54f255f8c 3.15 [sdcard] boot.img not found 3.53 Error 6 loading boot.img 3.55 Boot mode: USB-MSD (04) order f25 3.17 PCI0 init 3.17 PCI0 reset 3.34 PCIe scan 00001106:00003483 3.46 XHCI-STOP 3.46 xHC0 ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb 3.47 USBSTS 11 3.47 xHC0 ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb 3.48 xHC0 ports 5 slots 32 intrs 4 3.18 USB2[3] 400202e1 connected 3.33 USB2 root HUB port 1 init 3.53 DEV [01:00] 2.16 000000:01 class 9 VID 2109 PID 3431 3.53 HUB init [01:00] 2.16 000000:01

I’m trying to make a big endian build of a linux distribution for ARM. Since I’m on Gentoo, cross-compiling couldn’t be easier. I’ve already built it all, but then got stuck with getting it/the kernel to boot. I’m targetting Cubieboard with AllWinner A10 CPU. As a bootloader I use u-boot. Since u-boot doesn’t support big endian ARM, I patched it exactly before passing control to the kernel: diff -Naur u-boot-2016.01-1/arch/arm/lib/bootm.c u-boot-2016.01-2/arch/arm/lib/bootm.c --- u-boot-2016.01-1/arch/arm/lib/bootm.c 2016-01-12 15:06:54.000000000 +0100 +++ u-boot-2016.01-2/arch/arm/lib/bootm.c 2017-07-09 14:13:29.675865446 +0200 @@ -315,7 +315,16 @@ 0, machid, r2); } else #endif + { + { + unsigned long v; + __asm volatile ("mrc p15, 0, %0, c1, c0, 0\n\t" + "orr %0, %0, #(1 setenv bootargs console=tty0 console=ttyS0,115200 earlyprintk hdmi.audio=EDID:0 disp.screen0_output_mode=EDID:1280x800p60 root=PARTUUID=AC9D6C6F-01 rootwait panic=10 => ext2load mmc 0 0x48000000 boot/uimage 5025856 bytes read in 592 ms (8.1 MiB/s) => ext2load mmc 0 0x51000000 boot/sun4i-a10-cubieboard.dtb 28542 bytes read in 237 ms (117.2 KiB/s) => bootm 0x48000000 - 0x51000000 ## Booting kernel from Legacy Image at 48000000 ... Image Name: Linux-4.9.9-gentoo Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 5025792 Bytes = 4.8 MiB Load Address: 48000000 Entry Point: 48000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 51000000 Booting using the fdt blob at 0x51000000 Loading Kernel Image ... OK Loading Device Tree to 49ff6000, end 49ffff7d ... OK Starting kernel ... And it just hangs there like this – no progress, no output, nothing. My question is, how to proceed from here/how to find out what is actually happening? Am I missing something, did I do anything wrong (or didn’t do something)? Some more things I tried, but without success: - word-swapping the kernel image (as APEX does) (resulted in undefined instruction on boot), - using compressed kernel image, - using legacy FEX file instead of FDT. ---------- Update 2017/07/21: I’ve been partly successful in solving my issue. I took the hint from Tom Rini’s comment and tried packing zImage into the uImage which made the kernel boot. With a custom init program (just a simple Hello World compiled either BE or LE) I confirmed the other Tom Rini’s suspicion: my original kernel was not big endian, but little. To fix this, I added the following two lines to the top of kernel’s .config: CONFIG_ARCH_SUPPORTS_BIG_ENDIAN=y CONFIG_CPU_BIG_ENDIAN=y I sourced my inspiration from a [how-to for Nvidia Jetson TK1](http://wiki.baserock.org/How_to_install_a_big-endian_Linux_system_to_NVIDIA_Jetson_TK1/) . I also added the following line to arch/arm/mach-sunxi/Kconfig at the end of A10 section: select ARCH_SUPPORTS_BIG_ENDIAN It turned out that this is enough to build and boot a big endian kernel as the kernel itself switches the CPU to big endian mode. However, it does so with setend instruction---its scope is only for the kernel itself, not for userspace (as link in Murray Jensen’s answer explains). I’m going to try: - jumping to kernel’s decompressor entry point via exception, or (if I fail) - patching the kernel so that it spawns processes into big endian settings (although I sort of smell a minefield there...).

The responsiveness of the Linux service udhcpc (native DHCP relative to /etc/init.d/S40network service which invokes ip up and udhcpc) differs before and after logging at the prompt. When invoked via /etc/init.d/rcS (boot sequence), udhcpc does not assign an IP address: udhcpc: no lease, failing However, once logged in, with the root account, the S40network restart provides an IP address very quickly via udhcpc. The /etc/inittab is normal and basic: # /etc/inittab # # Copyright (C) 2001 Erik Andersen # # Note: BusyBox init doesn't support runlevels. The runlevels field is # completely ignored by BusyBox init. If you want runlevels, use # sysvinit. # # Format for each entry: ::: # # id == tty to run on, or empty for /dev/console # runlevels == ignored # action == one of sysinit, respawn, askfirst, wait, and once # process == program to run # Startup the system ::sysinit:/bin/mount -t proc proc /proc ::sysinit:/bin/mount -o remount,rw / ::sysinit:/bin/mkdir -p /dev/pts ::sysinit:/bin/mkdir -p /dev/shm ::sysinit:/bin/mount -a ::sysinit:/bin/hostname -F /etc/hostname # now run any rc scripts ::sysinit:/etc/init.d/rcS # Put a getty on the serial port ttyPS0::respawn:/sbin/getty -L ttyPS0 0 vt100 # GENERIC_SERIAL # Stuff to do for the 3-finger salute #::ctrlaltdel:/sbin/reboot # Stuff to do before rebooting ::shutdown:/etc/init.d/rcK ::shutdown:/sbin/swapoff -a ::shutdown:/bin/umount -a -r How can we explain this ?

I'am using Arduino Yun and i want mount rootfs over NFS. I downloaded openwrt sources, build the project and then copied the generated rootfs from build_dir/target-mips_34kc_musl-1.1.15/root-ar71xx under /home/user/srv/nfs/root-ar71xx in the uboot prompt the command line i used is : setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.1:/home/user/srv/nfs/root-ar71xx ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0::off; bootm uboot environement variables: ar7240> printenv bootcmd=bootm 0x9fea0000 bootdelay=4 baudrate=115200 ethaddr=0xb4:0x21:0x8a:0x00:0x00:0x10 ipaddr=192.168.1.2 serverip=192.168.1.1 stdin=serial stdout=serial stderr=serial ethact=eth0 bootargs=root=/dev/nfs rw nfsroot=192.168.1.1:/home/user/srv/nfs/root-ar71xx ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0::off Environment size: 319/65532 bytes But i got : ## Booting image at 81000000 ... Bad Magic Number I read in [this link](http://lists.denx.de/pipermail/u-boot/2006-May/014983.html) , that there is a kind of encapsulation for the kernel in order to be "known" by U-Boot. Is it the same thing for the rootfs I have another question but it's not very related to the topic: After building the project i have several binaries (24) under bin/ar71xx/: openwrt-ar71xx-generic-wzr-hp-ag300h-squashfs-tftp.bin openwrt-ar71xx-generic-tl-mr11u-v1-squashfs-sysupgrade.bin openwrt-ar71xx-generic-wzr-hp-g300nh2-squashfs-factory.bin ... I expect only one kernel image what all these images are supposed to do ? Thanks in advance. **EDIT**: I change the cmd line to : setenv bootargs root=/dev/nfs rw nfsroot=192.168.1.1:/home/bou6/srv /nfs/root-ar71xx ip=192.168.1.2:192.168.1.1:192.168.1.1:255.255.255.0::off; bootm 0x9fea0000 and i don"t have Bad Magic Number anymore, but still questions: 1- How can we know the load address of the kernel 2- I noticed even though the ethernet cable is not branched the kernel continue to use the default file system flashed on the Yun, is there a method to desactivate this.

After hours of reading and try and error process i'd like to explain my nfs mount problem and solution. I was working for years on a virtual **debian 8.5** host system to develop software for multiple embedded devices, based on imx, or raspi, beagle board and so on. During the development process it's more than usefull to mount the embedded root partion over nfs from the host machine. The configuration is normaly straight forward. # host configuration

# /etc/exports
/opt/tftpboot/rootfs *(rw,sync,insecure,no_subtree_check,no_root_squash)

- instead of wildcard it's recommend to use specific ips - also remove the option insecure in productive enviroment # client configuration if the kernel supports the network file system it's pretty easy to configure the mounting of the root file system from the embedded / or remote system.

# example part of the kernel command line
root=/dev/nfs nfsroot=10.0.102.247:/opt/tftpboot/rootfs,nolock

By the way, with the new version of **nfs-kernel-server**, delivering with **debian 10.2** or **9.x** it's impossible to mount the root file system. The boot process stuck, no error log on host device, no error log on the remote system. # testing from shell I've tried to boot the remote system from flash and mount the remote folder from our busybox shell, but failed.

$ mount -t nfs 10.0.102.247:/opt/tftpboot/rootfs /mnt/nfs
no route to host

Ping works fine ;-) Also the firewall on the host side was well configured. After exluding any other problem, like problems on the networking, i've changed the mount command to use the NFS V4 the mount command works like expected.

mount -t nfs -o nfsvers=4 10.0.102.247:/opt/tftpboot/rootfs /mnt/nfs

I had an old tablet lying around so I created the page according to linux-sunxi (https://linux-sunxi.org/Softwinners_crane ). I was trying to get Linux running on it. A different tablet was similar (as also pointed out in another mailing list) to mine - Topwise A721, so I used it's .dts file for this. After following the extensive documentation on the website, collecting all details and so on, I built u-boot and kernel and flashed them on an SD card. When trying to boot I get stuck at this screen, and then the display goes off:

U-Boot 2025.07-rc2-00018-g126a88d49bca (May 18 2023 - 10:35:18 +0530) Allwinner Technology

CPU:   Allwinner A10 (SUN4I)
Model: Topwise A721
DRAM:  1 GiB
Core: 70 devices, 21 uclasses, devicetree: separate
WDT:   Not starting watchdog@01c20c90
MMC:   mmc@1c0f000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1...
HDMI connected: Setting up a 1920x1080 hdmi console (overscan 0x0)
In:    serial,usbkbd
Out:   serial,vidconsole
Err:   serial,vidconsole
Net:   No ethernet found.

starting USB...
No host cable detected. Bus usb@01c13000: Port not available.
No USB controllers found
   scanning USB for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc0:1...
Found U-Boot script /boot.scr
301 bytes read in 1 ms (293.9 KiB/s)
## Executing script at 43100000
24070 bytes read in 3 ms (7.7 MiB/s)
6105264 bytes read in 335 ms (21.6 MiB/s)
Kernel image @ 0x42000000 [ 0x000000 - 0x5d28b0 ]
## Flattened Device Tree blob at 43000000 
   Booting using the fdt blob at 0x43000000 
Working FDT set to 43000000
   Loading Device Tree to [49ff7000, end 49fffe05] ... OK
Working FDT set to 49ff7000 

Starting kernel ...

How do I fix this?

I’m working with a Jetson TK1 where it’s configured as a **PCIe Root Complex**, connected to two endpoints: - An FPGA on a x1 lane - A PowerPC processor on a x4 lane During boot-up, the Jetson consistently establishes a link with the x1 device (FPGA). However, it **intermittently fails** to establish a connection with the x4 lane endpoint (PowerPC). After investigating in kernel space (L4T R21.5, kernel 3.10.40), I noticed that the **Data Link Up** flag (RP_VEND_XP_DL_UP) is not set for the x4 lane, so the device is never enumerated. I’m looking to **debug this issue further** and would really appreciate any suggestions or insights from the community also at which stage of the Jetson TK1 boot process does PCIe **link training** occur? i want to dive into that area of debugging aswell

I'm trying to update the recovery image from sdcard to recovery partition using Uboot command below update recovery mmc 1 fat recovery.ext2 Update is successful when the image size is 479MB and fails when the image size is 557MB (After adding my application to rootfs) ext4fs_devread read outside partition 1068475736 Error loading firmware file to RAM I'm using dd command to copy the image to sdcard dd if=img.sdcard of=/dev/sda bs=4k

I have managed to install Alpine Linux on a Marvell Octeon NIC. One thing I'm missing for this to be a clean setup is managing the u-boot variables in firmware. That will also allow to query the card's serial number from the running OS which will allow for some better tracking when there's multiple cards. (they're behind a PCIe switch, and the device order is not static so far) I created the file and put in various nice-looking numbers, but to no avail: It's not working so far, showing me alignment errors. - I wasn't able to find a generated config in the SDK tools. - I've collected most info from the u-boot prompt and some hardware specific tools. This is what I had thought could be right:

# MTD device name   Device offset  Env. size   Flash sector size   Number of sectors
#/dev/mtd0 	          0x400000      (8188 Bytes)  256 	   32

I've tried it, also converthing some of it to multiples of 256, but it seems arbitrary (i.e. 0x400000 is simply what they picked and the u-boot tools tell me it's not aligned on an erase block. yeah, err, wasn't me, right?) ### What I found out: There's /dev/mtd0 and /dev/mtdblock0, neither are partitioned.

# => saveenv
# SF: Detected MT25QL01G with page size 256 Bytes, erase size 4 KiB, total 128 MiB

Env size is reported as 8188 bytes Flash sector size is supposed to be 256 bytes The number of sectors should then be (probably) 32. There *may* be a redundant copy being it. In the sources I found those definitions

# u-boot/include/configs/octeon_generic_nand_stage2.h:#define CONFIG_ENV_RANGE		0x200000	/* 2 blocks */
#define CONFIG_ENV_IS_IN_NAND
#define CONFIG_ENV_OFFSET               0x400000        /* 4MB */
#define CONFIG_ENV_SIZE                 (32*1024)
#define CONFIG_ENV_RANGE                0x200000        /* 2 blocks */

#ifdef CONFIG_NAND_ENV_DST
        nand_load(&nand_info, CONFIG_ENV_OFFSET, CONFIG_ENV_SIZE,
                  (uchar *)CONFIG_NAND_ENV_DST);
#ifdef CONFIG_ENV_OFFSET_REDUND
        nand_load(&nand_info, CONFIG_ENV_OFFSET_REDUND, CONFIG_ENV_SIZE,
                  (uchar *)CONFIG_NAND_ENV_DST + CONFIG_ENV_SIZE)

So the most confusing thing here is the (32*1024). Meaning 32MB, which would fit into a 256mbit NAND. But with the env size being shown as roundabout 8k, I'm not able to make sense of the two. i had a command 'sf probe' that shows info about the flash chip but doesn't show layout info. The documentation had this line: The kernel needs to know the flash layout. This is controlled with the kernel mtdparts command line option. Here is the mtdparts option for the above flash layout. Note that the bootloader partitions are marked read only for safety.

bootoctlinux  mtdparts=phys_mapped_flash:2048k(bootloader)ro,2048k(kernel),3072k(cramfs),256k(jffs2),256k(bootloader_env)ro

Check your partitioning:
	$ cat /proc/mtd
	dev:    size   erasesize  name
	mtd0: 00200000 00010000 "bootloader"
	mtd1: 00200000 00010000 "kernel"
	mtd2: 00300000 00010000 "cramfs"
	mtd3: 00040000 00010000 "jffs2"
	mtd4: 00040000 00010000 "bootloader_env"

i wanna ask: - is there a way to see more about the layout of u-boots variable storage from within the u-boot prompt? - is there a way to find them in the flash device (are they just plain ascii? what about endianness?) - is there an explanation about the erase block sizes?, does it want the "sector" size (256) or the erase size (4)? - is it safe to just set the mtdparts kernel variable as they mentioned, even if i know nothing about it really? I somewhat tried the latter, with doubtful result:

cn7322:~# cat /proc/cmdline 
 bootoctlinux $(loadaddr) coremask=ffff noinitrd root=/dev/sdb2 rootfstype=ext4 rw rootdelay=10 mtdparts=phys_mapped_flash:2048k(bootloader)ro,2048k(kernel),3072k(cramfs),256k(jffs2),256k(bootloader_env)ro console=ttyS0,115200
cn7322:~# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00100000 00010000 "bootloader"
cn7322:~#

i looked through /dev/mtd0ro, seems to be the bootloader, but seems not to have the env. or at least i cannot see a single variable name or content. (could be format issues). I didn't get the bootloader_env :(

I've got a U-Boot image file, and I would like to explore its contents. I tried to run binwalk u-boot.img, and this is the output:

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
0             0x0             uImage header, header size: 64 bytes, header CRC: 0xB6056508, created: 2019-04-01 15:46:00, image size: 280420 bytes, Data Address: 0x80800000, Entry Point: 0x0, data CRC: 0x159289AE, OS: Firmware, CPU: ARM, image type: Firmware Image, compression type: none, image name: "U-Boot 2015.07_ZZZS00_ZZZS00_v2."
170800        0x29B30         CRC32 polynomial table, little endian
173218        0x2A4A2         bix header, header size: 64 bytes, header CRC: 0x0, created: 1970-01-01 00:00:00, image size: 35914 bytes, Data Address: 0x83800100, Entry Point: 0x994A, data CRC: 0x83809F4A, image type: OS Kernel Image, compression type: none, image name: ""
179190        0x2BBF6         Unix path: /path/to/xxx0001
182572        0x2C92C         LZO compressed data
197326        0x302CE         Unix path: /path/to/miiphyutil.c
212517        0x33E25         Unix path: /path/to/cmd_nvedit.c
213945        0x343B9         Unix path: /path/to/env_common.c
219014        0x35786         Unix path: /path/to/fb_mmc.c
223547        0x3693B         Unix path: /path/to/omap_gpio.c
226263        0x373D7         Unix path: /path/to/mtdcore.c
227418        0x3785A         Unix path: /path/to/musb_core.c
232195        0x38B03         Unix path: /path/to/eth.c
236378        0x39B5A         bix header, header size: 64 bytes, header CRC: 0x100, created: 1970-01-01 00:00:04, image size: 52367 bytes, Data Address: 0x8380CC8F, Entry Point: 0x83800000, data CRC: 0x5B61, image name: "[initrd[:size]] [fdt]]"
236398        0x39B6E         bix header, header size: 64 bytes, header CRC: 0x5B61, created: 2023-05-17 06:20:16, image size: 1533636201 bytes, Data Address: 0x7472645B, Entry Point: 0x3A73697A, data CRC: 0x655D5D20, image name: "]]"
240198        0x3AA46         bix header, header size: 64 bytes, header CRC: 0xA20, created: 1987-01-30 03:38:21, image size: 543975795 bytes, Data Address: 0x74207061, Entry Point: 0x72746974, data CRC: 0x696F6E20, image name: "e"

I also tried to run mount -o loop u-boot.img /mnt, but this is the error: mount: /mnt: wrong fs type, bad option, bad superblock on /dev/loop17, missing codepage or helper program, or other error.

I'm working on booting U-Boot from the SPI flash memory of an Arty A7 100T FPGA and encountering an issue where U-Boot does not execute after power-on **Issue** U-Boot does not produce any output on the UART console when booting from flash **Setup:** 1. I have built U-Boot for my RISC-V-based system and flashed it to SPI flash at address 0x0C000000 2. The expectation is that, upon power-on, the bootloader should be loaded from flash into RAM and executed **Observations:** 1. After flashing the bitstream into the FPGA, the board powers on, but U-Boot does not boot. I see no output on the UART console. 2. To test the flash execution path, I flashed a small UART print test program to 0x0C00 0000, which worked correctly, confirming that the flash itself is accessible. I verified the U-Boot binary in flash, and it appears to be written correctly 3. However, if I load the same U-Boot image directly into RAM using GDB, it boots successfully, indicating that the image itself is functional 4. After flashing U-Boot into the flash, I verified that the contents were written correctly **What I need help with:** 1. What could be preventing U-Boot from executing when loaded from flash? 2. What debugging steps can I take to analyze the issue further? 3. Could this be related to missing relocation, boot address misalignment, or an issue with the OpenSBI handoff?

I am having a Raspberry Pi 3b+ (Arch64) device. Generally I run Raspbian 64-bit by using the Rasbian Imager tool to setup my SD card. I am interested to run Archlinux 64-bit on the same. And following the official guide to set it up from > here I have successfully setup the SD card by creating the required partitions and Filesystems. I have also updated the /etc/fstab with the correct PARTUUIDs to mount the / and /boot partitions. Now I have observed that I need to update the /boot/boot.txt appropriately and run ./mkscr command after installing uboot-tools on another running arch64 linux system. Fot this I have used a Archlinux arch64 instance from UTM on MacOS M-series machine. The question is what to update i the /boot/boot.txt file. Below is the entire /boot/boot.txt file already included in the downloaded tarball: # After modifying, run ./mkscr # Set root partition to the second partition of boot device part uuid ${devtype} ${devnum}:2 uuid setenv bootargs console=ttyS1,115200 console=tty0 root=PARTUUID=${uuid} rw rootwait smsc95xx.macaddr="${usbethaddr}" if load ${devtype} ${devnum}:${bootpart} ${kernel_addr_r} /Image; then if load ${devtype} ${devnum}:${bootpart} ${fdt_addr_r} /dtbs/${fdtfile}; then if load ${devtype} ${devnum}:${bootpart} ${ramdisk_addr_r} /initramfs-linux.img; then booti ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}; else booti ${kernel_addr_r} - ${fdt_addr_r}; fi; fi; fi I think I need to update the line: part uuid ${devtype} ${devnum}:2 uuid Can anyone suggest what needs to be changed here and does any other file needs to be changed in /boot/ for the system to work?

The goal is to erase confidential information from the UBIFS volume. In Linux you'd use ubiupdatevol -t, but there's no such an option in the u-boot. Not sure if removing volume cleans up the contents of the chip and space the volume was allocated with. Writing into the volume space should not help because UBI employs wear leveling. I can't figure out the possible solution reading the UBI/FS documentation. Erasing the whole chip is not an option. **Update:** the documentation says >A Special case of the volume update operation is what we call volume truncation, which is done by the same ioctl command when the data length is zero. In this case the volume is wiped out and will contain all 0xFF bytes (all LEBs will be un-mapped). therefore theoretically it may work using

ubi write[vol] address volume 0

but it must be tried and proven that U-boot UBI driver supports truncation. **Update:** truncation is supported by the U-boot I have, and writing 0 byte count physically erases all the volume's space.

I am using bitbake to generate my u-boot and linux images. I have two boards, one of which is running a simple TFTP server written in c++ code. U-Boot can tftp boot ~50MB in around 7 seconds. When it boots in the the linux image it just TFTP booted from it takes about 2.5 minutes. I was using the builtin busybox tftp, so I thought that might be the issue. So I added tftp-hpa to my linux image and re-tried with that tftp -m binary -c get and got basically the same result. The tftp server always writes 512 byte chunks and reports and re-tries, which there are none. So I am at a bit of a loss to explain this difference. Its all the exact hardware, the *only* difference is one is running from u-boot and the other is running from Linux. What might be the difference? - any way I can test/resolve this? **Clarifications** - U-boot takes 7 seconds to tftp-get/transfer the FIT image from the server - Linux (once booted) takes 2.5 minutes to tftp-get/transfer the same image - By adding tftp-hpa to my bitbake recepie, it has replaced the busybox implementation - My question is how to make the linux tftp transfer the same speed as the u-boot transfer. - The simple c++ tftp server is on a separate board, running on linux, its always running and is left unchanged for all these tests ### Update Using rsync to copy the files when in linux is very fast also... so that is a workaround - but still does not answer *why* tftp in linux is so slow.

Is this possible to boot Rpi CM4 + io-board completely from NVME ? I updated Rpi bootloader and it loads kernel well without U-boot. When I switch to U-boot, it doesn't load boot.scr located in the same FAT partition. It tries mmc, usb but never nvme drive. What is my problem ?

I have built uboot and linux for qemu-x86_64 and I am booting u-boot.rom and then try to boot linux from there, but I think cpu resets when I execute zboot command and uboot starts again. Here is my command with which I start qemu: qemu-system-x86_64 -m 1024 -M pc -bios u-boot.rom -drive file=rootfs.ext2.img,format=raw,if=virtio -kernel bzImage -net nic,model=virtio -net user -serial mon:stdio I have created rootfs.ext2.img as mentioned in the following post create image with partition table in order for uboot to recognize the virtio device. The main problem is that when I try to boot linux the last message is "Loading bzImage at address 100000 (4820640 bytes)" and then uboot is started again. Here is the log starting from error, I did not put the uboot boot logs twice not to duplicate:

Load address: 0x1000000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
=> ext2load virtio 0:1 0x1000000 /boot/bzImage
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
dev=virtio, devnr=0:1, path=/boot/bzImage, buffer=0000000001000000, size=49c6a0
Wrong FIT format: not a flattened device tree (err=-9)
- not remembering image
4834976 bytes read in 68 ms (67.8 MiB/s)
=> zboot 0x1000000
Valid Boot Flag
Setup Size = 0x00003800
Magic signature found
Using boot protocol version 2.0f
Linux kernel version 5.15.41 (mikhail@Prague) #1 SMP Wed Nov 6 10:12:54 CET 2024
Building boot_params at 0x00090000
Loading bzImage at address 100000 (4820640 bytes)

U-Boot SPL 2022.04 (Nov 05 2024 - 14:07:51 +0100)
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
notbr: returning err=-1
Trying to boot from SPI
Jumping to 64-bit U-Boot: Note many features are missing
size=30, ptr=30, limit=1000: 1104e0
size=3c8, ptr=3f8, limit=1000: 110510
size=30, ptr=428, limit=1000: 1108d8
size=98, ptr=4c0, limit=1000: 110908
bind node chosen
Device 'chosen' has no compatible string
bind node aliases
Device 'aliases' has no compatible string
bind node memory
Device 'memory' has no compatible string
bind node serial
   - attempt to match compatible string 'ns16550'
   - found match at 'ns16550_serial': 'ns16550' matches 'ns16550'
size=30, ptr=4f0, limit=1000: 1109a0
size=98, ptr=588, limit=1000: 1109d0
size=28, ptr=5b0, limit=1000: 110a68
bind node keyboard
   - attempt to match compatible string 'intel,i8042-keyboard'
Skipping device pre-relocation
bind node reset
   - attempt to match compatible string 'x86,reset'
   - found match at 'x86_reset': 'x86,reset' matches 'x86,reset'
size=30, ptr=5e0, limit=1000: 110a90
size=98, ptr=678, limit=1000: 110ac0
size=8, ptr=680, limit=1000: 110b58
bind node rtc
   - attempt to match compatible string 'motorola,mc146818'
   - found match at 'motorola_mc146818': 'motorola,mc146818' matches 'motorola,mc146818'
size=30, ptr=6b0, limit=1000: 110b60
size=98, ptr=748, limit=1000: 110b90
bind node tsc-timer
   - attempt to match compatible string 'x86,tsc-timer'
   - found match at 'x86_tsc_timer': 'x86,tsc-timer' matches 'x86,tsc-timer'
size=30, ptr=778, limit=1000: 110c28
size=98, ptr=810, limit=1000: 110c58
bind node smbios
   - attempt to match compatible string 'u-boot,sysinfo-smbios'
Skipping device pre-relocation
bind node config
Device 'config' has no compatible string
bind node cpus
Device 'cpus' has no compatible string
bind node pci
   - attempt to match compatible string 'pci-x86'
   - found match at 'pci_x86': 'pci-x86' matches 'pci-x86'
size=30, ptr=840, limit=1000: 110cf0
size=98, ptr=8d8, limit=1000: 110d20
bind node pch@1,0
   - attempt to match compatible string 'intel,pch7'
   - found match at 'intel-pch7': 'intel,pch7' matches 'intel,pch7'
size=30, ptr=908, limit=1000: 110db8
size=98, ptr=9a0, limit=1000: 110de8
size=20, ptr=9c0, limit=1000: 110e80
bind node irq-router
   - attempt to match compatible string 'intel,irq-router'
No match for node 'irq-router'
bind node binman
Device 'binman' has no compatible string
size=8, ptr=9c8, limit=1000: 110ea0
size=20, ptr=9e8, limit=1000: 110ea8
size=18, ptr=a00, limit=1000: 110ec8


U-Boot 2022.04 (Nov 05 2024 - 14:07:51 +0100)

size=70, ptr=a70, limit=1000: 110ee0
size=1b8, ptr=c28, limit=1000: 110f50
notbr: returning err=-1
pre: returning err=-1
notbr: returning err=-1
pre: returning err=-1
pre: returning err=-1
pre: returning err=-1
size=30, ptr=c58, limit=1000: 111108
size=30, ptr=c88, limit=1000: 111138
size=98, ptr=d20, limit=1000: 111168
size=18, ptr=d38, limit=1000: 111200
bind node cpu@0
   - attempt to match compatible string 'cpu-qemu'
   - found match at 'cpu_qemu': 'cpu-qemu' matches 'cpu-qemu'
size=98, ptr=dd0, limit=1000: 111218
size=20, ptr=df0, limit=1000: 1112b0
CPU:   QEMU Virtual CPU version 2.5+
DRAM:  size=30, ptr=e20, limit=1000: 1112d0
size=8, ptr=e28, limit=1000: 111300
size=30, ptr=e58, limit=1000: 111308
1 GiB
bind node chosen
Device 'chosen' has no compatible string
bind node aliases
Device 'aliases' has no compatible string
bind node memory
Device 'memory' has no compatible string
bind node serial
   - attempt to match compatible string 'ns16550'
   - found match at 'ns16550_serial': 'ns16550' matches 'ns16550'
bind node keyboard
   - attempt to match compatible string 'intel,i8042-keyboard'
   - found match at 'i8042_kbd': 'intel,i8042-keyboard' matches 'intel,i8042-keyboard'
bind node reset
   - attempt to match compatible string 'x86,reset'
   - found match at 'x86_reset': 'x86,reset' matches 'x86,reset'
bind node rtc
   - attempt to match compatible string 'motorola,mc146818'
   - found match at 'motorola_mc146818': 'motorola,mc146818' matches 'motorola,mc146818'
bind node tsc-timer
   - attempt to match compatible string 'x86,tsc-timer'
   - found match at 'x86_tsc_timer': 'x86,tsc-timer' matches 'x86,tsc-timer'
bind node smbios
   - attempt to match compatible string 'u-boot,sysinfo-smbios'
   - found match at 'sysinfo_smbios': 'u-boot,sysinfo-smbios' matches 'u-boot,sysinfo-smbios'
bind node smbios
Device 'smbios' has no compatible string
bind node config
Device 'config' has no compatible string
bind node cpus
Device 'cpus' has no compatible string
bind node pci
   - attempt to match compatible string 'pci-x86'
   - found match at 'pci_x86': 'pci-x86' matches 'pci-x86'
bind node pch@1,0
   - attempt to match compatible string 'intel,pch7'
   - found match at 'intel-pch7': 'intel,pch7' matches 'intel,pch7'
bind node irq-router
   - attempt to match compatible string 'intel,irq-router'
No match for node 'irq-router'
bind node binman
Device 'binman' has no compatible string
binman: Selected image node 'rom'
Core:  10 devices, 10 uclasses, devicetree: separate
0
   - -1 'pci'
   - not found
vesa_video_bind: Frame buffer size fa0000
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
0
   - 0 'pci'
   - found
Loading Environment from nowhere... OK
0
   - 0 'vesa_video'
   - found
No x resolution: returning err=-6
returning err=-6
0
   - 0 'vesa_video'
   - found
Incorrect expansion ROM header signature 4daa
returning err=-22
Model: QEMU x86 (I440FX)
Net:   No ethernet found.
bind node cpu@0
   - attempt to match compatible string 'cpu-qemu'
   - found match at 'cpu_qemu': 'cpu-qemu' matches 'cpu-qemu'
smbios_version = 00000000000f00bf: '2022.04'
Hit any key to stop autoboot:  0 
starting USB...
No working controllers found
USB is stopped. Please issue 'usb start' first.
scanning bus for devices...

Device 0: unknown device

Device 0: 1af4 VirtIO Block Device
            Type: Hard Disk
            Capacity: 61.0 MB = 0.0 GB (124928 x 512)
... is now current device
 
 
 
Scanning virtio 0:1...
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Scanning disk virtio-blk#1...
unhandled device class: virtio-pci.l#1 (virtio)
unhandled device class: pci (pci)
 
 
 
Found 2 disks
No EFI system partition
Initializing EFI driver framework
Adding EFI driver 'EFI block driver'
Incorrect expansion ROM header signature 4daa
returning err=-22
0
   - 0 'virtio-net#0'
   - found
0
   - 0 'virtio-net#0'
   - found
unhandled device class: virtio-pci.l#0 (virtio)
unhandled device class: pci (pci)
smbios_version = 000000003dcec03f: '2022.04'
BootOrder not defined
EFI boot manager: Cannot load any image
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Reset IDE: Bus 0: OK Bus 1: OK 
  Device 0: not available
  Device 1: not available
  Device 2: Model: QEMU Firm: 2.5+ Ser#: QEMU DVD-ROM
            Type: Removable CD ROM
            Capacity: not available
  Device 3: not available

Device 0: unknown device
starting USB...
No working controllers found
0
   - 0 'virtio-net#0'
   - found
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (2 ms)
Using virtio-net#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x7000000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...
BOOTP broadcast 1
DHCP client bound to address 10.0.2.15 (1 ms)
Using virtio-net#0 device
TFTP from server 10.0.2.2; our IP address is 10.0.2.15
Filename 'boot.scr.uimg'.
Load address: 0x1000000
Loading: *
TFTP error: 'Access violation' (2)
Not retrying...

I've also gathered some information by adding **-d int,pcall,cpu,cpu_reset,guest_errors -D qemu.log** and there is a triple fault before cpu reset. The exception causing the triple fault:

check_exception old: 0xffffffff new 0xd
     1: v=0d e=0000 i=0 cpl=0 IP=0010:72b63af36fd82b54 pc=72b63af36fd82b54 SP=0018:000000000010e6b8 env->regs[R_EAX]=0000000000100000
RAX=0000000000100000 RBX=0000000000498ea0 RCX=0000000000000000 RDX=0000000000000000
RSI=000000000149c6a0 RDI=0000000000598ea0 RBP=0000000001000000 RSP=000000000010e6b8
R8 =0000000000000000 R9 =0000000000100000 R10=000000000010e46e R11=00000000000186a0
R12=0000000000000001 R13=000000000000020f R14=000000003eff6280 R15=0000000000003800
RIP=72b63af36fd82b54 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0020 0000000000110118 00003fff 00809300 DPL=0 DS   [-WA]
GS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl
GDT=     00000000fffddc20 0000002f
IDT=     0000000000120000 000007ff
CR0=80000011 CR2=0000000000000000 CR3=0000000000080000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000000 CCD=0000000000000000 CCO=SUBQ
EFER=0000000000000500
check_exception old: 0xd new 0xd
     2: v=08 e=0000 i=0 cpl=0 IP=0010:72b63af36fd82b54 pc=72b63af36fd82b54 SP=0018:000000000010e6b8 env->regs[R_EAX]=0000000000100000
RAX=0000000000100000 RBX=0000000000498ea0 RCX=0000000000000000 RDX=0000000000000000
RSI=000000000149c6a0 RDI=0000000000598ea0 RBP=0000000001000000 RSP=000000000010e6b8
R8 =0000000000000000 R9 =0000000000100000 R10=000000000010e46e R11=00000000000186a0
R12=0000000000000001 R13=000000000000020f R14=000000003eff6280 R15=0000000000003800
RIP=72b63af36fd82b54 RFL=00000046 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
CS =0010 0000000000000000 ffffffff 00af9a00 DPL=0 CS64 [-R-]
SS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
DS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
FS =0020 0000000000110118 00003fff 00809300 DPL=0 DS   [-WA]
GS =0018 0000000000000000 ffffffff 00cf9300 DPL=0 DS   [-WA]
LDT=0000 0000000000000000 00000000 00008200 DPL=0 LDT
TR =0020 0000000000000000 00000fff 00808900 DPL=0 TSS64-avl
GDT=     00000000fffddc20 0000002f
IDT=     0000000000120000 000007ff
CR0=80000011 CR2=0000000000000000 CR3=0000000000080000 CR4=00000020
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000 
DR6=00000000ffff0ff0 DR7=0000000000000400
CCS=0000000000000000 CCD=0000000000000000 CCO=SUBQ
EFER=0000000000000500
check_exception old: 0x8 new 0xb

I'm booting U-Boot in QEMU via Yocto's runqemu command and I'm trying to make the U-Boot to load an environment from FAT partition. Yocto is built from master (312488228ad408fb0f29b2aa272e72cf87de8e93) branch with MACHINE=genericarm64. The U-Boot version is 2024.07 which seems to contain the commit which add support for loading an environment from virtio interface, see [this](https://stackoverflow.com/questions/78490686/custom-u-boot-writes-to-environment-file-but-cannot-read-from-it#comment138387932_78490686) StackOverflow comment. I have enabled following options:

CONFIG_ENV_IS_IN_FAT=y
# CONFIG_ENV_IS_IN_FLASH is not set
CONFIG_ENV_FAT_INTERFACE="virtio"
CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
CONFIG_ENV_FAT_FILE="uboot.env"

following options came along with when enabled the CONFIG_ENV_IS_IN_FAT:

CONFIG_SYS_MMC_ENV_DEV=0
CONFIG_SYS_MMC_ENV_PART=0

I assume the device and part config is correct in CONFIG_ENV_FAT_DEVICE_AND_PART as fatls virtio 0:1 lists the partition content properly. And FAT support is also enabled:

CONFIG_FS_FAT=y
CONFIG_FAT_WRITE=y
CONFIG_FS_FAT_MAX_CLUSTSIZE=65536

But I get the error that virtio is not supported:

Loading Environment from FAT... ** Bad device specification virtio 0 **

Am I missing something crucial here?

I got Debian working on my Olimex Lime 2 with official images today. I installed Wireguard and attempted to reboot but am getting these errors:

U-Boot 2021.04*olimex-1-20231103.141125 (Nov 03 2023 - 13:12:2* +0000) Allwinner Technology
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0A89D237
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0A89D23
Speed: 100, full duplex
*** ERROR: 'serverip' not set
Speed: 100, full duplex
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0A89D2
Speed: 100, full duplex
*** ERROR: 'serverip' not et
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0A89D
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0A89
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0A8
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0A
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi-a20_olinuxino
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
Speed: 100, full duplex
*** ERROR: 'serverip' not set
missing environment variable: bootfile
Config file not found
Speed: 100, full duplex
BOOTP broadcast 1
DHCP client bound to address  (104 ms)
*** ERROR: 'serverip' not set
Cannot autoload with TFTPGET
Speed: 100, full duplex
BOOTP broadcast 1
DHCP client bound to address  (104 ms)
*** ERROR: 'serverip' not set
Cannot autoload with TFTPGET
=>

(**Note**: Error message manually typed out) ------ Any ideas what the issue might be? The device its self is a brand new Olimex Lime 2 (A20-OLINUXINO-LIME2-E16GS16M-ND) from DigiKey. Thank you so much for any help you can provide.