On 1/18/20 10:53 AM, Jaehoon Chung wrote:

Hi

On 1/18/20 9:22 AM, Alexander von Gluck IV wrote:

...

Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?

I'm using 32-bit u-boot on RPI4 board with Tizen Platform. You can refer to tizen u-boot git. Also I modified some configurations.

https://protect2.fireeye.com/url?k=d4848ff3-8957d64d-d48504bc-0cc47a31ba82-4...

Oops. https://git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen

So you may modify some configs about your environment.

...

Building via the following:

make rpi_4_32b_defconfig ARCH=arm CROSS_COMPILE=arm-none-eabi- make

Booting via:

• u-boot.bin on Fat32 partition
• start.elf from
• config.txt on Fat32 partition kernel=u-boot.bin enable_uart=1 arm_64bit=0

Our config.txt is below,

enable_uart=1 uart_2ndstage=1

I didn't add "arm_64bit" config.

Best Regards, Jaehoon Chung

...

Just a black screen, however, no serial uart output

Thanks!

-- Alex

On 18/01/2020 04:18, Alexander von Gluck IV wrote:

January 17, 2020 7:59 PM, "Jaehoon Chung" jh80.chung@samsung.com wrote:

...

On 1/18/20 10:53 AM, Jaehoon Chung wrote:

...

Hi

On 1/18/20 9:22 AM, Alexander von Gluck IV wrote:

...

Has anyone successfully used u-boot on the Raspberry Pi 4 in 32-bit mode?

I'm using 32-bit u-boot on RPI4 board with Tizen Platform. You can refer to tizen u-boot git. Also I modified some configurations.

https://protect2.fireeye.com/url?k=d4848ff3-8957d64d-d48504bc-0cc47a31ba82-4...: /git.tizen.org/cgit/platform/kernel/u-boot/log/?h=tizen

enable_uart=1 uart_2ndstage=1

uart_2ndstate=1 helped a lot :-)

I have it figured out now.

I wasn't aware of the change around Raspberry Pi's FDT's needing to be on the boot partition for start4.elf.

All of our existing bootloader code depends on the FDT embedded into u-boot. (fdtcontroladdr, see below for our boot.scr)

Does u-boot "pick-up" the FDT from the Pi foundation's start4.elf and place it at fdtcontroladdr?

test -e mmc 0 uEnv.txt && fatload mmc 0 ${scriptaddr} uEnv.txt && env import -t ${scriptaddr} ${filesize} \ fatload mmc 0 ${kernel_addr_r} haiku_loader.ub \ fatload mmc 0 ${ramdisk_addr_r} haiku_floppyboot.ub \ env exists dtb && fatload mmc 0 ${fdt_addr_r} ${dtb} && fdt addr ${fdt_addr_r} && bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r} \ fdt addr ${fdtcontroladdr} && bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdtcontroladdr}"

I thought the FDT embedded into u-boot was the "best way" to get it :-|

If you want to do that you are still free to do so by changing your config. The idea is to get rid of the U-Boot DTS as the FW can provide us with one. In the case of RPi4 it even helps us, as we don't have to deal with the different versions with 1/2/4 GiB of RAM, as the FW updates the DTB as needed.

If you want to use an embedded device tree you are either bound to one RAM size or you have to add code to detect the size and update that on the fly.

Feel free to send patches if that's something you are interested in.

Regards, Matthias

Regards, Matthias