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

[Stefano Babic]

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.

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.

> 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.

Generally, we cannot assume that a u-boot.img, behaves as u-boot.imx: it
could be, but it is only luck. At the end, they are two different
systems - two targets, that means two defconfig.

> I don't
> see a reason why it shouldn't be possible to compile with the same make
> command.

See above - we should have the same result, just with two formats. It is
not.

> And the interdependency of SPL and u-boot.imx, that only one can be
> built at a time, isn't obvious to me either. After all SPL is a
> completely different binary.

...and result and behavior are completely different. That means having
two targets, or two defconfig.

> 
> ...or am I touching some skeleton in a cupboard?
> 

Best regards,
Stefano Babic

> Thanks
> Petr
> 
> On 02/09/16 20:18, Stefano Babic wrote:
>> Hi,
>>
>> On 02/09/2016 18:46, Petr Kulhavy wrote:
>>> Hi,
>>>
>>> I'm facing a problem that the iMX Makefile does not allow to build
>>> u-boot.imx and the SPL binary simultaneously.
>> ...I am missing why you need to build them at the same time. Can you
>> start with a detailed description of the problem ? Why is it not enough
>> to build them in sequence ?
>>
>>> This would be useful for
>>> generating images for flash and for a serial loading.
>>> The reason is that each target needs a different config file, but there
>>> is only one IMX_CONFIG variable.
>> I do not get the point. Yes, you have two defconfig. And yes, you cannot
>> built it at the same time. But you define the IMX_CONFIG in each of the
>> two defconfig, making use of two different IMX_CONFIG, if this is what
>> you want.
>>
>>> I have tried to create a dedicated IMX_CONFIG_SPL for the SPL, which
>>> seems to work and I almost prepared a patch for submit.
>>> Unfortunatelly there is some problem with the dependencies if both
>>> u-boot.imx and SPL are put in ALL-y. The make with single job runs but
>>> it fails in multi-job execution.
>>>
>>> Could you please help me and throw some light into the dependencies. I
>>> think this patch could be useful also for others, see below.
>>>
>>>
>> Best regards,
>> Stefano Babic
>>
>>
> 

-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================