All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefano Babic <sbabic@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Building u-boot.imx and SPL simultaneously
Date: Sat, 3 Sep 2016 11:40:40 +0200	[thread overview]
Message-ID: <11f4e24d-17c2-69a6-ba59-078e3bbfe09f@denx.de> (raw)
In-Reply-To: <e853474d-92b9-b023-bd4e-0e02ab1ce06a@jikos.cz>

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

  reply	other threads:[~2016-09-03  9:40 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-02 16:46 [U-Boot] Building u-boot.imx and SPL simultaneously Petr Kulhavy
2016-09-02 18:18 ` Stefano Babic
2016-09-02 18:57   ` Petr Kulhavy
2016-09-02 20:03     ` Fabio Estevam
2016-09-02 20:53       ` Petr Kulhavy
2016-09-06 13:40         ` Tom Rini
2016-09-06 13:53           ` Otavio Salvador
2016-09-06 13:56             ` Tom Rini
2016-09-06 14:00           ` Eric Nelson
2016-09-06 14:12             ` Petr Kulhavy
2016-09-06 14:17               ` Tom Rini
2016-09-06 14:15             ` Tom Rini
2016-09-10 23:40               ` Eric Nelson
2016-09-18  6:50                 ` Peng Fan
2016-09-18  7:18                   ` Stefano Babic
2016-09-02 21:45     ` Stefano Babic
2016-09-02 23:15       ` Petr Kulhavy
2016-09-03  9:40         ` Stefano Babic [this message]
2016-09-03 20:27           ` Otavio Salvador
2016-09-04  8:53             ` Stefano Babic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=11f4e24d-17c2-69a6-ba59-078e3bbfe09f@denx.de \
    --to=sbabic@denx.de \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.