[U-Boot] Building u-boot.imx and SPL simultaneously

[Petr Kulhavy]

Hi Stefano,

I need to build two set-ups:
1) SPL + u-boot.img for normal device run out of flash
2) u-boot.imx for initial device load together with fastboot

For (2) SPL + kermit + u-boot.img is not an option for me, simply 
because it is too slow.

I agree that the u-boot images in case (1) and (2) do not generally have 
to be identical. However in my case I don't need them to be different.

You are saying that in order to cover my use case(s) I need two 
defconfigs. Well, ok...
But how do I integrate this into Buildroot? For the sake of 
maintainability, simplification, reducing chance for an error during 
build I want to have one Buildroot defconfig, run one build command and 
get all the necessary images.
How do I do that with two U-boot defconfigs?


On 02/09/16 23:45, Stefano Babic wrote:
> Hi Petr,
>
> On 02/09/2016 20:57, Petr Kulhavy wrote:
>> Hi,
>>
>> you have already brought it to the point - it needs two defconfigs.
>> This means double the files in U-boot and second and more important, how
>> does it integrate into a tool like Buildroot?
>> In other words I'm trying to do it with just one defconfig.
>>
>> Alltogether I want to build 3 files:
>> * SPL which is started by the RBL
>> * u-boot.img which is loaded by the SPL from the flash after typing 'c'
>> or similar on the terminal
>> * u-boot.imx for an initial load of the board via USB if there is no BL
>> at all
> You are assuming that the two different setups are equivalent: u-boot.ix
> against SPL + u-boot.img. It is not, and they have very different
> concepts on the basis of two.

Well, I see it slightly different. There is some core functionality of 
u-boot, which is the command interpreter, scripting, drivers, etc.
And then there is some one-time HW initialization that needs to be done. 
There are two different ways of doing the HW initialization: either via 
RBL and DCD, or via SPL.
But after the HW is initialized it comes in both cases to the same 
functionality. Once the u-boot is started it does not see the SPL and it 
probably doesn't even know how it was loaded.
It just assumes that certain HW is initialized in a certain way.

In the end both u-boot.imx and u-boot.img are generated out of the same 
u-boot.bin, just with different mkimage parameters.
> And with imx_usb_loader it is still possible to load the SPL via USB,
> and via UART, SPL loads u-boot.img - see README.imx6.
That is  too slow for my needs.
>> All these images plus rootfs and kernel should be an outcome of one
>> build in Buildroot.
>>
>> Since the u-boot.imx is in fact u-boot.img with an extra header
> It is not: it is different. If it was just an header, I agree that it is
> like building the bootloader in several formats. That happens for
> u-boot.bin and u-boot.img, or u-boot.bin and u-boot.imx.
>
> u-boot.imx has much more as a header: it is contain the DCD tables
> according to the FSL documentation that it is interpreted by the RBL.
> This is a static setup, because the DCD table is fixed. The RBL sets the
> SOC according to the values in the DCD table and has (or it can have)
> nothing to do with the SPL+u-boot.img built for the same board.
>
> On the other side, SPL does not use DCD at all (it could be, but it is
> empty), and the setup is done with runtime detection by SPL code. The
> u-boot.img built together with SPL depends on it, that means it does not
> set again some parts already set by the SPL. That means you cannot
> simply exchange u-boot.img or u-boot.imx.
I don't want to exchange them. I want to do the same HW initialization 
which u-boot expects from SPL in the DCD and out of that create the 
u-boot.imx, which is then directly loaded without SPL.
But currently it is not possible.
> Generally, we cannot assume that a u-boot.img, behaves as u-boot.imx: it
> could be, but it is only luck.

Of course, if I want to use two different vesions of u-boot with 
different sets of commands and features it makes sense to have two 
defconfigs.
But if I want to use the same functionality why should the make process 
hinder generating the .img and .imx in the same build process?


Regards
Petr