Re: Compiling barebox without PBL and using dts from Linux dts upstream for Zynq SoC

["Michał Kruszewski" <mkru@protonmail.com>]

Of course, due to the hurry, I made a mistake in my previous message.
The program for the boot.bin generation is called bootgen not bootbin.

You can find AMD bootgen user guide here:
  https://docs.amd.com/r/en-US/ug1283-bootgen-user-guide/Introduction.

The ELF file provided to the bootgen can have multiple loadable sections, each of which forms a partition in the boot image.
The AMD/Xilinx FSBL will load and hand-off execution to the next executable partition found in the boot.bin file.
The u-boot.elf file has one LOAD section:
  [user@host] readelf -l u-boot.elf
  Elf file type is EXEC (Executable file)
  Entry point 0x4000000
  There is 1 program header, starting at offset 52
  Program Headers:
    Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
    LOAD           0x010000 0x04000000 0x04000000 0x108ff0 0x108ff0 RW  0x10000
   Section to Segment mapping:
    Segment Sections...
     00     .data
The readelf for barebox shows 3 LOAD sections and 1 DYNAMIC section.
The second difference is that Elf file type for u-boot is EXEC (Executable file), for barebox DYN (Position-Independent Executable file).

The bootgen user guide has the table 49 with the following note for the ELF file format:
"Symbols and headers removed."
However, it is not clear whether bootgen automatically removes symbosls and headers, or whether it expects the elf file without symbols and headers.


Now, I would like to describe a few ideas and potential problems.
I am by far not bootloaders expert.
However, I had to boot and debug booting on a few custom and off-the-shelf boards with AMD/Xilinx SoCs and MPSoCs.
All the things I write below are related to booting ADM/Xilinx chips only.


There are 2 alternative paths you may chose when trying to boot AMD/Xilinx SoCs.

Path 1: The no-FSBL path
This is the path currently supported by barebox.
You do not want to utilize the AMD/Xilinx automatically generated FSBL.
In such a case, you have to define a board, and provide C code for the low-level board initialization.
The barebox PBL does the FSBL job in this case.
I think this path is fine for hobby projects and off-the-shelf boards when you want to quickly get things running.
However, I am not a fan of this path in professional projects because of the following reasons:
  a) The FSBL code is automatically generated, it may include some workarounds or fixes for hardware bugs.
     The copied low-level initialization C code may potentially miss them.
  b) Forget about getting official support from AMD/Xilinx if you mention you don't use the official FSBL for boot.

Path 2: The FSBL path
For me, this is the way to go in professional projects.
Barebox currently does not support this path.
In this case, you do not want to be forced to define a board.
This is simply pointless, the FSBL is responsible for initializing the low-level stuff.
All you need to boot Linux when FSBL stops execution is some SSBL and device tree.


Now, what a support for path 2 in the barebox could look like.
We could use the concept of the virtual board.
The virtual board is a board that:
  - is assumed to already be low-level initialized when barebox starts running,
  - can accept arbitrary device tree,
  - should not be bound to any specific device tree by default.
The boilerplate related to the board definition should not exist for the virtual board.
What the user experience would look like:
  1. make zynq_virt_defconfig,
  2. open menuconfig,
  3. find and set config containing path for the device tree file (can be out of tree),
  4. make,
  5. copy the required elf and/or bin files to your project.

The u-boot has a similar concept of virt defconfigs, for example:
xilinx_versal_virt_defconfig
xilinx_zynqmp_virt_defconfig
xilinx_zynq_virt_defconfig


What potential problems do I see?
The bootgen handles elf files with multiple loadable sections by putting each section into a separate partition.
The FSBL simply loads and hands-off to the next executable partition from the boot.bin.
I do not know how barebox works and prepares images.
However I can see 3 potential scenarios.

Scenario 1: PBL and SSBL are logical entities put into the same LOAD section
This scenario is easy.
FSBL will load both into memory.
The hand-off from PBL to SSBL does not require loading SSBL into memory since it was already done by FSBL.
The hand-off from PBL to SSBL is a simple jump.

Scenario 2: PBL and SSBL are puto into the same ELF file but separate LOAD sections
FSBL will load only PBL.
PBL has to parse boot.bin file, load SSBL into memory and hand-off to it.

Scenario 3: Only PBL is put in the ELF file, ELF file has one LOAD section
PBL must load SSBL from the SD card parition (not boot.bin file partition).
The SSBL can be an image in binary format since it is not put into boot.bin.


Unfortunately, I do not have enough skills to apply required changes to barebox to test these ideas on my own.
However, I would be more than happy to test your changes.
Let me know what you think.

Regards,
Michał Kruszewski