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

[Stefano Babic]

Hi Petr,

On 03/09/2016 01:15, Petr Kulhavy wrote:
> 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.

This is why they have two different defconfigs.

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

I am noit a Buildroot expert, someone else can better point you in the
right direction. I will expect that you need a second target. If I had
to do thuis in Yoct, I will tend to add a new recipe to build .imx variant.

Best regards,
Stefano Babic

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

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