Uboot question

Phishfry

Phishfry

With the newer GENERIC Arm images that are not board dependent do you need to manually create the uboot partition and copy appropriate uboot port into the fat partition?
In the old days an RPi2 image was board dependent but was ready to use.
How is uboot working with the newer platform generic ARM images?
 
A bit info. The boot order and components are as follows:

  • First stage bootloader - This is used to mount the FAT32 boot partition on the SD card so that the second stage bootloader can be accessed. It is programmed into the SoC itself during manufacture of the RPi and cannot be reprogrammed by a user.
  • Second stage bootloader (bootcode.bin) - This is used to retrieve the GPU firmware from the SD card, program the firmware, then start the GPU.
  • GPU firmware (start.elf) - Once loaded, this allows the GPU to start up the CPU. An additional file, fixup.dat, is used to configure the SDRAM partition between the GPU and the CPU. At this point, the CPU is release from reset and execution is transferred over.
  • User code - This can be one of any number of binaries. By default, it is the Linux kernel (usually named kernel.img), but it can also be another bootloader (e.g. U-Boot), or a bare-bones application.

 
probably for every soc it's a bit different
anyway for pi zero uboot is slow or combination of uboot+loader is slow
the rpi-b 11.1 image is resonably fast, 13.0 is slowest
(just the booting part)
netbsd boots blazing fast (whitout uboot)
 
The fat32lba partition with size of 50M contains two important files.
config.txt , a configuration file and
u-boot.bin , it contains efi related stuff and raspberry firmware
file ./u-boot.bin
./u-boot.bin: PCX ver. 2.5 image data bounding box [8223, 54531] - [0, 8], 20-bit uncompressed
 
u-boot.bin is u-boot code (loaded by broadcom start.elf)
it's a kind of bios/open firmware
it loads ubldr.bin (freebsd loader) or efi/boot/bootarm.efi (freebsd efi loader)
 
that did not work for me. it loaded ubldr.bin (loader),loader loaded everything from loader.conf then boot failed
it complained no device tree is loaded
you probably have to compile in the dtb but i did not figure it how fast enough and gave up
 
What I now wonder about is why ubldr was removed from U-Boot. That really seems to be a death blow to arm7.
sysutils/u-boot-master

sysutils/u-boot-*: Remove ubldr support

We have been using loader.efi on armv7 for a long time now.
Remove support for booting with ubldr and the needed patches that were
never upstreamed.
While here add CONFIG_EFI_GRUB_ARM32_WORKAROUND=y in the Fragment as it's
needed to have the cache flushed for us when loader.efi is started.
Click to expand...

We have a different way of using u-boot via API support.
bodhi (developer) from u-boot stated in a thread that the API is the modern way to implement u-boot.
Wonder why no one else is using that method.

Why did our patches never get upstreamed? Is this the deathblow for our u-boot?
So we can only do EFI boot on ARMv7 now? Am I reading too much into this?
 
i managed to boot with ubldr with latest u-boot-rpi
just rename the EFI dir on the card to something else and get a boot.scr from a previous image
i was pissed that EFI boot on pi zero is dog slow
ubldr is a bit better
the problem is at least on pi zero with a video console because freebsd loader console code does not use uboot api puts
only putc. u-boot flushes cpu caches after any puts or putc and this makes video console slow (like a 9600 baud session)
i added CONFIG_SYS_DCACHE_OFF=y to the config fragment and it works much better
unfortunately efi boot is slow even with this patch (i think disk io is slower with efi)
 
ubldr version is was from 2016 but who cares. It works.

So does efi work on armv7? I thought there is no 32 bit uefi on FreeBSD? Arm has it?

If so do I build an image like amd64 EFI with /boot/EFI/arm32.efi symlinked/mounted to some /boot/ place?
Where can I get the needed arm32 efi file?
 
covacat said:
efi/boot/bootarm.efi (freebsd efi loader)
Click to expand...
I found this file on the Generic Armv7 Image on the s1 partition.

What I have discovered is that U-boot builds device tree binaries from its own dts tree.
This is addition to the uboot loader.
This tree includes everything including devices that don't work on FreeBSD.
Please note this example is for cubox-hummingboard u-boot from ports.
usr/ports/sysutils/u-boot-cubox-hummingboard/work/u-boot-2021.07/arch/arm/dts/
Code: 
<sniped>
imx6q-hummingboard2-emmc-som-v15-u-boot.dtsi
imx6q-hummingboard2-emmc-som-v15.dtb
imx6q-hummingboard2-emmc-som-v15.dts
imx6q-hummingboard2-som-v15.dtb
imx6q-hummingboard2-som-v15.dts
imx6q-hummingboard2.dtb
imx6q-hummingboard2.dts
<sniped>

The compiled uboot dtb files are only from the imx6 family in my case.
Here is the comprehensive list:

When I used the Hummingboard2 DTB binaries from Uboot build directory everything worked differently.
This is with a Uboot 2021 build from ports. Copied u-boots dtb files to /boot/dtb/ directory on da0s1.
 
Phishfry said:
What I now wonder about is why ubldr was removed from U-Boot. That really seems to be a death blow to arm7.
sysutils/u-boot-master



We have a different way of using u-boot via API support.
bodhi (developer) from u-boot stated in a thread that the API is the modern way to implement u-boot.
Wonder why no one else is using that method.

Why did our patches never get upstreamed? Is this the deathblow for our u-boot?
So we can only do EFI boot on ARMv7 now? Am I reading too much into this?
Click to expand...
IIRC u-boot API was not that supported nor used in u-boot (except for FreeBSD?).
My armv7 board is using EFI boot without problems, just like my arm64 board.

Regarding DT:
- You can use DT from u-boot (from u-boot arch/arm/dts/) - this is already loaded when you reach u-boot shell
- you can load your own from u-boot from (FAT32/EFI/ext4) partition
- you can tell FreeBSD's loader to load your dtb file (even from ZFS IIRC)
(I am using method2 on arm64, for armv7 router I don't remember, probably method1)

Not using rpi, but on rk3399 EFI boot is also slow - you can see on the LCD and UART how it is printing char by char :'‑(
Maybe suppressing all that printfs (EFI vars & stuff) will speed it up :D
 
How do you custom modify your u-boot port?

So I let it download distfile, extract it and 'CTL-C' to quit building.
I modify uboot ports /configs/mx6cuboxi_defconfig
Then I restart make in port directory.
This method sometimes requires modifying .config too....
A patch with my fixes would be the official way.
How do you build and re-build u-boot?

I delete the stage log files manually then it keeps distfile and recompiles.
 
if you just want do add stuff to default _defconfig look at u-boot-rpi/Makefile
create a file in files/
and set FRAGMENT_NAME in the Makefile
Code: 
[00:18:11] [host!user]/usr/ports/sysutils/u-boot-rpi$make -V FRAGMENT_NAME
rpi_fragment
[00:18:20] [host!user]/usr/ports/sysutils/u-boot-rpi$cat files/rpi_fragment
CONFIG_OF_EMBED=y
CONFIG_OF_BOARD=y
CONFIG_API=y
CONFIG_SYS_DCACHE_OFF=y
[00:18:25] [host!user]/usr/ports/sysutils/u-boot-rpi$
 
This setting must be nixed for me.
CONFIG_NET_RANDOM_ETHADDR=y

Who in the world needs a random MAC address.
 
add to Makefile

EXTRA_PATCHES= ${.CURDIR}/files/
in files/

patch-mx6cuboxi_defconfig.txt
Diff: 
--- configs/mx6cuboxi_defconfig    2021-07-05 18:11:28.000000000 +0300
+++ /tmp/mx6cuboxi_defconfig    2022-01-13 00:39:09.166758000 +0200
@@ -47,7 +47,6 @@
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y
-CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_DM=y
 CONFIG_SPL_DM=y
 CONFIG_BOUNCE_BUFFER=y
 
What do you know about the SPL files? u-boot-with-spl.imx for example?
I know think SPL is serial presence loader. How is this used on Arm?
I tried flashing the image to my SATA disk and it didn't boot from it.
My hummingboard has jumpers for boot device and one is SPL. That's why I tried it.

The makefile alludes to it too.
ALL_TARGET= u-boot-with-spl.imx

On top of u-boot building it there is also a dedicated port that looks similar.
sysutils/u-boot-imx-serial-loader/

So I am guessing u-boot-with-spl.imx would be used for booting over OTG USB port?
This seems to support that idea

Imx usb loader

Read the Booting from USB using the imx_usb_loader utility guide or browse Variscite's excellent knowledge base for more how-to guides related to Variscite's System on Module / Computer on Module.
variwiki.com variwiki.com
 
I compiled with the correct options and u-boot was still issuing a random MAC.
Turns out if MAC address environment is zero length it ignores the random MAC setting and issues a random MAC.
The solution is to add MAC to environmental settings in u-boot.
Code: 
=> setenv ethaddr 62:73:64:68:82:2e

=> printenv ethaddr
ethaddr=62:73:64:68:82:2e

=> saveenv
Saving Environment to MMC... Writing to MMC(2)... OK

What is puzzling to me is "Writing to MMC(2)"
This is my uboot raw image drive. Only flashed u-boot.imx to it.
No filesystem installed.
I was wondering where u-boot stored these environmental settings?
uEnv.txt
loader.env
Somewhere inside u-boot.imx flashed area?
 
the spl part (second program loader) is loaded directly by the embedded bootrom
this is the most platform specific part of u-boot
for the android tv i play with its like this
uboot image = splcode.bin (32K) + u-boot-fit image
u-boot-fit image is in dtb format and looks like this
Code: 
#dtc -O dts -I dtb ./work/u-boot-2021.07/u-boot-sunxi-with-spl.fit.fit
/dts-v1/;

/  {

    timestamp = <0x61dfd0df>;
    description = "Configuration to load ATF before U-Boot";
    #address-cells = <0x1>;
    images {

        uboot {
            data = <.....
            description = "U-Boot (64-bit)";
            type = "standalone";
            os = "u-boot";
            arch = "arm64";
            compression = "none";
            load = <0x4a000000>;
        };
        atf {
            data = <.....
            description = "ARM Trusted Firmware";
            type = "firmware";
            os = "arm-trusted-firmware";
            arch = "arm64";
            compression = "none";
            load = <0x104000>;
            entry = <0x104000>;
        };
        scp {

            data;
            description = "SCP firmware";
            type = "firmware";
            arch = "or1k";
            compression = "none";
            load = <0x114000>;
        };
        fdt-1 {
            data = <.....
            description = "sun50i-h6-tanix-tx6";
            type = "flat_dt";
            compression = "none";
        };
    };
    configurations {

        default = "config-1";
        config-1 {

            description = "sun50i-h6-tanix-tx6";
            firmware = "atf";
            loadables = "scp", "uboot";
            fdt = "fdt-1";
        };
    };
};
 
Phishfry said:
What is puzzling to me is "Writing to MMC(2)"
This is my uboot raw image drive. Only flashed u-boot.imx to it.
No filesystem installed.
I was wondering where u-boot stored these environmental settings?
uEnv.txt
loader.env
Somewhere inside u-boot.imx flashed area?
Click to expand...

Env is stored on device defined with:
Code: 
grep "^CONFIG_ENV" .config
CONFIG_ENV_SIZE=0x8000
CONFIG_ENV_OFFSET=0x3F8000
CONFIG_ENV_VARS_UBOOT_CONFIG=y
CONFIG_ENV_SUPPORT=y
CONFIG_ENV_IS_IN_MMC=y
Default env is stored somewhere in u-boot binary, my custom environment is stored in MMC, at defined offset, 32 kB of space is reserved for it.
To show it:
Code: 
dd if=/dev/mmcsd0 of=env.bin bs=1k skip=4064 count=32
strings env.bin | less

Env is not stored in file, it is stored as blocks in device defined with config vars above.
more details

Linux has ./tools/env/fw_printenv in u-boot repo for showing/editing env variables but it doesn't work under FreeBSD.
I made myself a nifty shell script for editing and writing back environment under FreeBSD. It is 90% finished, but not ready for sharing, I'll try to upload it in the next year of two 🤕

To see default environment you can (from u-boot repo folder) run:
Code: 
sh ./scripts/get_default_envs.sh | head
altbootcmd=setenv boot_syslinux_conf extlinux/extlinux-rollback.conf;run distro_bootcmd
arch=arm
baudrate=1500000
board=evb_rk3399
board_name=evb_rk3399
boot_a_script=load ${devtype} ${devnum}:${distro_bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_efi_binary=load ${devtype} ${devnum}:${distro_bootpart} ${kernel_addr_r} efi/boot/bootaa64.efi; if fdt addr ${fdt_addr_r}; then bootefi ${kernel_addr_r} ${fdt_addr_r};else bootefi ${kernel_addr_r} ${fdtcontroladdr};fi
boot_efi_bootmgr=if fdt addr ${fdt_addr_r}; then bootefi bootmgr ${fdt_addr_r};else bootefi bootmgr;fi
 
What is the the binary program u-boot(almost 5 megs) that is in the root of u-boot build.
Code: 
-rwxr-xr-x    1 root  wheel  4938244 Jan 14 21:12 u-boot
-rw-r--r--    1 root  wheel   479762 Jan 14 21:12 u-boot-dtb.bin
-rw-r--r--    1 root  wheel   479826 Jan 14 21:12 u-boot-dtb.img
-rwxr-xr-x    1 root  wheel   438584 Jan 14 21:12 u-boot-nodtb.bin
-rw-r--r--    1 root  wheel   512594 Jan 14 21:12 u-boot-sunxi-with-spl.bin
-rw-r--r--    1 root  wheel      156 Jan 14 21:12 u-boot-sunxi-with-spl.map
-rw-r--r--    1 root  wheel   479762 Jan 14 21:12 u-boot.bin
-rw-r--r--    1 root  wheel    15347 Jan 14 21:10 u-boot.cfg
-rw-r--r--    1 root  wheel     9542 Jan 14 21:10 u-boot.cfg.configs
-rw-r--r--    1 root  wheel    41178 Jan 14 21:12 u-boot.dtb
-rw-r--r--    1 root  wheel    41316 Jan 14 21:12 u-boot.dtb.out
-rw-r--r--    1 root  wheel   479826 Jan 14 21:12 u-boot.img
-rw-r--r--    1 root  wheel     1719 Jan 14 21:10 u-boot.lds
-rw-r--r--    1 root  wheel   970427 Jan 14 21:12 u-boot.map
-rwxr-xr-x    1 root  wheel  1315874 Jan 14 21:12 u-boot.srec
-rw-r--r--    1 root  wheel   179190 Jan 14 21:12 u-boot.sym

I was hoping it was a shell to u-boot command prompt.
 
OK More questions.

I was looking at Turris Omnia support on FreeBSD and ran across this OPNSense post.
The Chart in the beginning is new to me.
Code: 
U-Boot SPL 2020.07 (Oct 15 2020 - 00:10:34 +0200)
High speed PHY - Version: 2.0
MiniPCIe/mSATA card detection... MiniPCIe
Detected Device ID 6820
board SerDes lanes topology details:
 | Lane # | Speed |  Type       |
 --------------------------------
 |   0    |   5   | PCIe0       |
 |   1    |   5   | USB3 HOST0  |
 |   2    |   5   | PCIe1       |
 |   3    |   5   | USB3 HOST1  |
 |   4    |   5   | PCIe2       |
 |   5    |   0   | SGMII2      |
 --------------------------------
:** Link is Gen1, check the EP capability
PCIe, Idx 0: remains Gen1
:** Link is Gen1, check the EP capability
PCIe, Idx 1: remains Gen1
PCIe, Idx 2: detected no link

What is this chart? I want to see PCI details on Hummingboard with U-Boot.

What is this config option? Is this board dependent?
 
You must log in or register to reply here.
Back
Top