BSP vs FSBL and its impact on uboot and kernel

[Gautam M]

Hi,

I am confused between the function of BSP and FSBL, and its impact on uboot and kernel. My question is three fold:

1. BSP initializes the arm processor, clock, ram, etc. But since FSBL is what is being loaded after control is passed from the BootROM, I assume FSBL contains the Board support Package (I base this on the workflow of building FSBL in Xilinx SDK) and therefore (bsp part of) FSBL does all initialization and configurations necessary to launch the secondary boot loader (u-boot). Is this assumption and boot sequence correct?

2. What is the purpose of having linux-xlnx and u-boot-xlnx repositories separate from original linux and denx repos? My understanding says that since all the initialization is carried out in the FSBL, so I could use vanilla linux kernel source and u-boot source, compile it for arm and run it on zynq. But are there any additional components in xilinx maintained clone of the kernel and u-boot which are specific to zynq processors?

3. Are there any initializations which take place in u-boot and kernel which are specific to zynq boards which are not done in the FSBL? I am not concerned about the general linux boot procedure where storage media is initialized to read and load kernel, fdt and platform drivers are linked together, etc.

 

[Cousins]

Hi Gautam,

Sorry for the delay! Our resident Linux expert Russell Bush can answer this one. He's been out the last week or so but should be getting back to you shortly. 

-Ryan

[Bush]

On Tuesday, December 19, 2017 at 7:06:36 PM UTC-8, Gautam M wrote:

Hi,

I am confused between the function of BSP and FSBL, and its impact on uboot and kernel. My question is three fold:

1. BSP initializes the arm processor, clock, ram, etc. But since FSBL is what is being loaded after control is passed from the BootROM, I assume FSBL contains the Board support Package (I base this on the workflow of building FSBL in Xilinx SDK) and therefore (bsp part of) FSBL does all initialization and configurations necessary to launch the secondary boot loader (u-boot). Is this assumption and boot sequence correct?

Just to avoid any confusion, the BSP is not a separate executable. The BSP, for any application in the Xilinx SDK (in this case FSBL), provides a set of support files that expose functionality for any configured peripherals and frameworks that are being used by that project. Compilation of the application that references the BSP will include the necessary BSP code in the final executable so it would be a mistake to view the BSP as separate from the project that references it. The FSBL has two responsibilities: 1) Initialize the hardware peripherals, clocks, etc. 2) Hand off execution to the user application (in this case U-Boot). This does not mean that U-Boot does not need any device support for the peripherals that have been initialized by FSBL before U-Boot execution begins. For example, FSBL may perform some UART initialization for the console by executing some function. After U-Boot has been handed execution, calls to read or write the UART need to be performed, which are done through the U-Boot device drivers.

 

2. What is the purpose of having linux-xlnx and u-boot-xlnx repositories separate from original linux and denx repos? My understanding says that since all the initialization is carried out in the FSBL, so I could use vanilla linux kernel source and u-boot source, compile it for arm and run it on zynq. But are there any additional components in xilinx maintained clone of the kernel and u-boot which are specific to zynq processors?

I'm not sure the specifics on policies for pull requests and mainline source repositories for Linux or U-Boot but typically the maintainers of the mainline repositories have requirements for device target support that have been historically discriminating of embedded architectures. This has changed in the past few years as we've seen the rise and ubiquity of ARM but many of the features supported by mainline kernels require additional porting for embedded devices. I don't know all of the porting that has been done to add support for the Zynq in the forked repositories. Theoretically, if there is mainline architecture support for ARM Cortex-A9 then you should be able to find a mainline kernel configuration that will run on the Zynq but you will likely be missing important Xilinx specific device drivers that you will need to use the peripherals (some, like SDIO, will be needed to successfully boot the system).

 

3. Are there any initializations which take place in u-boot and kernel which are specific to zynq boards which are not done in the FSBL? I am not concerned about the general linux boot procedure where storage media is initialized to read and load kernel, fdt and platform drivers are linked together, etc.

The device drivers and architectural support that is included in the Xilinx (and forked snickerdoodle) repositories contain device drivers that will be required to run on those systems on Zynq. While the initialization is (mostly) performed by FSBL, there are many other operations/interactions that occur with the peripherals and connected devices during the boot process and regular operation. For example, after U-Boot loads the Linux kernel and device tree into RAM and begins the boot process, the Linux kernel will attempt to load a root filesystem (typically located on the SD card) which will require reading using the SDIO peripheral. Without device driver support for the Zynq SDIO hardware peripheral built into the Linux kernel, loading the root filesystem will fail.

I hope these responses answer your questions adequately but if you need any further clarification or you want to more deeply understand the boot process and the board support requirements, please let me know.

[Gautam M]

Thank you Bush, this clarifies most of my doubts. 

Just one more question, from what you have said, am I right in inferring that sometimes there exists three separate drivers (one in FSBL, one in U-boot, and one in Linux kernel) for the same peripheral such as for serial console (uart)? i.e. the driver provided in the FSBL (via the BSP) is not used/called by u-boot or linux kernel.

[Gautam M]

My basis for the above question is in relation to x86 PC platforms where the operating system makes bios calls to actuate some hardware. Are there any such calls made to the FSBL (bsp) by uboot or the kernel?

[Bush]

The FSBL does not continue to be accessible after it hands off execution to U-Boot (or other application). A BIOS may continue to be accessible from an x86 system to provide (as the name suggests) basic input/output access on the hardware. No such relationship exists between FSBL and application code (U-Boot, Linux, bare-metal) that is loaded after FSBL has finished execution. For this reason, any application code requires built-in or dynamically loadable device drivers for peripheral access. Just a thought: Because the FSBL is run out of OCM rather than RAM, it may be possible to write a customized FSBL that provides low-level access to the peripherals, however, the design of such an FSBL would be very configuration specific which would defeat much of the purpose of such a system.

[Gautam M]

Thank you for the clarifications Bush.