[U-Boot] Separately compile Master boot loader

[U-Boot] Separately compile Master boot loader

[Rajdeep Vaghasia]

Hi
I am working on one board with an arm11 based cpu, NOR flash and DDR2 SDRAM.
When I compile u-boot source code, I get u-boot.bin image generated.
This image has primary(second stage) and secondary(third stage) bootloader
combined.

I have following queries:
1) The question that still eats me everyday is, How can I compile
primary(Master) boot loader and secondary boot loader separately?
2) I want to Flash only initial 4kb of code (Master boot loader or second
stage). The remaining code I want to keep at another partition in the
Flash. How can I achieve this?
3) Is there any separate code available for Master boot loader, which
copies the third stage bootloader to SDRAM and then transfers control to
that third stage boot loader(u-boot)?

I am unable to find a way to do this.

Can anyone help me please?

[U-Boot] Separately compile Master boot loader

[Albert ARIBAUD]

Hi Rajdeep,

On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
<rajdeep.vaghasia@gmail.com> wrote:

> Hi
> I am working on one board with an arm11 based cpu, NOR flash and DDR2 SDRAM.
> When I compile u-boot source code, I get u-boot.bin image generated.
> This image has primary(second stage) and secondary(third stage) bootloader
> combined.
> 
> I have following queries:
> 1) The question that still eats me everyday is, How can I compile
> primary(Master) boot loader and secondary boot loader separately?
> 2) I want to Flash only initial 4kb of code (Master boot loader or second
> stage). The remaining code I want to keep at another partition in the
> Flash. How can I achieve this?
> 3) Is there any separate code available for Master boot loader, which
> copies the third stage bootloader to SDRAM and then transfers control to
> that third stage boot loader(u-boot)?
> 
> I am unable to find a way to do this.
> 
> Can anyone help me please?

Since you do not indicate exactly which target you're building, I'll
assume it is one with SPL (what you describe as master or second stage,
with third stage being u-boot itself).

I don't know of a way to build SPL alone.

As for building separate U-Boot and SPL, you'll find them in ELF format
in file ./u-boot and ./spl/u-boot-spl. You can then use
$(CROSS_COMPILE)objcopy to convert from ELF to .bin.

Note that your target may need a specific format different from the
pure binary that objcopy can produce.

Can you tell us more about your target?

Amicalement,
-- 
Albert.

[U-Boot] Separately compile Master boot loader

[Rajdeep Vaghasia]

Waiting for a reply.


On Tue, Jul 9, 2013 at 4:12 PM, Rajdeep Vaghasia <rajdeep.vaghasia@gmail.com
> wrote:

> Hi
> I am working on one board with an arm11 based cpu, NOR flash and DDR2
> SDRAM.
> When I compile u-boot source code, I get u-boot.bin image generated.
> This image has primary(second stage) and secondary(third stage) bootloader
> combined.
>
> I have following queries:
> 1) The question that still eats me everyday is, How can I compile
> primary(Master) boot loader and secondary boot loader separately?
> 2) I want to Flash only initial 4kb of code (Master boot loader or second
> stage). The remaining code I want to keep at another partition in the
> Flash. How can I achieve this?
> 3) Is there any separate code available for Master boot loader, which
> copies the third stage bootloader to SDRAM and then transfers control to
> that third stage boot loader(u-boot)?
>
> I am unable to find a way to do this.
>
> Can anyone help me please?
>

[U-Boot] Separately compile Master boot loader

[Albert ARIBAUD]

Hi Rajdeep,

On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia
<rajdeep.vaghasia@gmail.com> wrote:

> Waiting for a reply.

Well, maybe if you had not e-mailed your 8:32 AM answer to me but to
the list... :)

Here it is, with my comments.

> On Tue, Jul 9, 2013 at 5:31 PM, Albert ARIBAUD <albert.u.boot@aribaud.net>wrote:
> 
> > Hi Rajdeep,
> >
> > On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
> > <rajdeep.vaghasia@gmail.com> wrote:
> >
> > > Hi
> > > I am working on one board with an arm11 based cpu, NOR flash and DDR2
> > SDRAM.
> > > When I compile u-boot source code, I get u-boot.bin image generated.
> > > This image has primary(second stage) and secondary(third stage)
> > bootloader
> > > combined.
> > >
> > > I have following queries:
> > > 1) The question that still eats me everyday is, How can I compile
> > > primary(Master) boot loader and secondary boot loader separately?
> > > 2) I want to Flash only initial 4kb of code (Master boot loader or second
> > > stage). The remaining code I want to keep at another partition in the
> > > Flash. How can I achieve this?
> > > 3) Is there any separate code available for Master boot loader, which
> > > copies the third stage bootloader to SDRAM and then transfers control to
> > > that third stage boot loader(u-boot)?
> > >
> > > I am unable to find a way to do this.
> > >
> > > Can anyone help me please?
> >
> > Since you do not indicate exactly which target you're building, I'll
> > assume it is one with SPL (what you describe as master or second stage,
> > with third stage being u-boot itself).
> >
> > I don't know of a way to build SPL alone.
> >
> > As for building separate U-Boot and SPL, you'll find them in ELF format
> > in file ./u-boot and ./spl/u-boot-spl. You can then use
> > $(CROSS_COMPILE)objcopy to convert from ELF to .bin.
> >
> > Note that your target may need a specific format different from the
> > pure binary that objcopy can produce.
> >
> > Can you tell us more about your target?
> >
> > Amicalement,
> > --
> > Albert.
> >
> 
> Sorry, My target board is not with SPL.

Then your question does not make sense, since a target without SPL has
no "second" and "third" stage, only a single standalone U-Boot stage.

> According to my understanding, SPL is required when we want to use NAND or
> oneNAND flash. And even in that case, the image generated, is combined of
> u-boot.bin+nand_driver.

This is quite reductive and partly wrong. 

SPL is required when you cannot directly boot into U-boot, one of the
cases being when you boot from NAND as it usually only allows very small
binaries; but NAND is far from the only case where SPL is needed or
useful.

Also, as I said, the image generated in the SPL case is not "u-boot +
NAND driver", it is "complete SPL + complete U-Boot" (although you can
have them separate as I explained), and the "complete SPL" part is not
itself an "U-Boot plus NAND driver".

> I am using NOR flash.

Ok.

> Actually, I am building firmware upgrade procedure.
> For that I need 3 partitions for u-boot.
> One with master u-boot.
> Other two with u-boot-1 and u-boot-2. (One contains current working u-boot,
> whereas another is with upgraded u-boot code).
> For that I need one Master uboot which contains code that initializes the
> SDRAM, choses one of the 2 secondary u-boot with the help of an environment
> variable (Or fixed jump to the start address of u-boot-1 or u-boot-2) and
> then copies u-boot(Secondary boot loader) to SDRAM and executes it from
> there.

Ok, so "secondary" is a concept specific to your design. No wonder I
could not understand it properly until you explained.

> These steps of initializing SDRAM and copying of u-boot code there, are
> already implemented in u-boot code. I just want to separate it from the
> main source code and want to generate binary of that much code only.
> 
> Is there any way to achieve this?

Several; and then there is an infinity of other possible approaches,
depending, not on *what* you want to do, but on *why* you want to do
it. Can you give more details on why your firmware upgrade procedure
needs to boot two different U-Boots  ?

> or
> Is there any resource of information available which can help me to
> understand this?

The source code and the Denx website, at this point; once you explain
the goal you are trying to reach, people on the list might point you
to more specific resources.

> Rajdeep.

Amicalement,
-- 
Albert.

[U-Boot] Separately compile Master boot loader

[Rajdeep Vaghasia]

Hi Albert,

I would like to explain you my exact idea.
For that, The Partition layout is:
1) Master u-boot
2) u-boot-1
3) u-boot-2
4) kernel
5) filesystem
6) data

Sometimes, When we may require to update with a new u-boot(to provide some
additional support), we have to overwrite the existing u-boot.
I don't want to overwrite the existing u-boot.
Instead, I want to keep a separate partition for new u-boot.

*Here is the whole procedure:*
I will maintain one environment variable(say "*safe_u-boot*"), which will
be used to point to the current 'working u-boot' partition(means, *u-boot-1*
).

I will develop one simple user space application.
Whenever a new u-boot is available, It will be first copied into the SDRAM
by this application.
Then, This application will check the environment variable "*new_u-boot*"
which will be pointing to second u-boot partition("u-boot-2") in flash.
And then, it will copy the new u-boot from SDRAM to *NOR flash* on the
partition pointed to by the "*new_u-boot*" environment variable, and then
mark one update flag(say, *u_boot_UPDATE*) as '*1*' and reboot the system.
This update flag is readable/writable by u-boot, kernel and user
application.

On reboot,
master u-boot(on every reboot or system power-up) will check this *
U_boot_UPDATE* flag  status.
If it is *set*, then Master u-boot will *first clear* that flag and then,
will load the u-boot from the partition pointed to by the "new_u-boot" env
variable.

case-1:
If the system is up successfully, the user space application will set the "*
safe_u-boot*" env variable to point the new partition(which was pointed to
by "*new_u-boot*") and set "*new_u-boot*" env variable to point to the
first u-boot partition(which was pointed to by "*safe_u-boot*"). (In short,
swapping of these environment variables). So, that on second time, when
system reboots, Master u-boot will see the *U_boot_UPDATE* flag *cleared*,
and will load the u-boot from the partition pointed to by "*safe_u-boot*",
which now contains the updated new u-boot.

case-2:
If the system fails and can not come up successfully with new u-boot, then
on *manual reboot*, Master u-boot will check the "*U_boot_UPDATE*" flag,
which will be in cleared state. (Because during update process, as soon as
Master U-boot reads this flag as set, it clears the flag). So, Master
U-boot will load the u-boot from the partition pointed to by the "*
safe_u-boot*" env variable(which is the working u-boot not updated
one.(say, u-boot-1)). As the swapping of these environment variables is
done by user application on successful update, this will not be the case
with this unsuccessful system up.

I hope everything is clear, now.
*So, in this overall implementation*,
I want to keep a little code of Master u-boot, which initializes SDRAM, and
copies secondary u-boot from flash to SDRAM. In addition to these, it keeps
track of two env variables.

Is there any separate source code available for this kind of Master U-boot?
*Or*
Can we compile the existing u-boot source code such that it will generate
only a small binary with these little functionalities?
*Or*
Can we compile the existing u-boot source code such that it will generate
both the binaries separately(master u-boot+secondary u-boot)?

Of course, even if Master u-boot is available, I will have to change that a
bit to implement those environment variable stuff in Master u-boot.

But this will be very helpful to me, if I get help from you.

I would like to remind again that, I want to implement this on *NOR Flash*.

Regards,
Rajdeep



On Wed, Jul 10, 2013 at 5:53 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net>wrote:

> Hi Rajdeep,
>
> On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia
> <rajdeep.vaghasia@gmail.com> wrote:
>
> > Waiting for a reply.
>
> Well, maybe if you had not e-mailed your 8:32 AM answer to me but to
> the list... :)
>
> Here it is, with my comments.
>
> > On Tue, Jul 9, 2013 at 5:31 PM, Albert ARIBAUD <
> albert.u.boot at aribaud.net>wrote:
> >
> > > Hi Rajdeep,
> > >
> > > On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
> > > <rajdeep.vaghasia@gmail.com> wrote:
> > >
> > > > Hi
> > > > I am working on one board with an arm11 based cpu, NOR flash and DDR2
> > > SDRAM.
> > > > When I compile u-boot source code, I get u-boot.bin image generated.
> > > > This image has primary(second stage) and secondary(third stage)
> > > bootloader
> > > > combined.
> > > >
> > > > I have following queries:
> > > > 1) The question that still eats me everyday is, How can I compile
> > > > primary(Master) boot loader and secondary boot loader separately?
> > > > 2) I want to Flash only initial 4kb of code (Master boot loader or
> second
> > > > stage). The remaining code I want to keep at another partition in the
> > > > Flash. How can I achieve this?
> > > > 3) Is there any separate code available for Master boot loader, which
> > > > copies the third stage bootloader to SDRAM and then transfers
> control to
> > > > that third stage boot loader(u-boot)?
> > > >
> > > > I am unable to find a way to do this.
> > > >
> > > > Can anyone help me please?
> > >
> > > Since you do not indicate exactly which target you're building, I'll
> > > assume it is one with SPL (what you describe as master or second stage,
> > > with third stage being u-boot itself).
> > >
> > > I don't know of a way to build SPL alone.
> > >
> > > As for building separate U-Boot and SPL, you'll find them in ELF format
> > > in file ./u-boot and ./spl/u-boot-spl. You can then use
> > > $(CROSS_COMPILE)objcopy to convert from ELF to .bin.
> > >
> > > Note that your target may need a specific format different from the
> > > pure binary that objcopy can produce.
> > >
> > > Can you tell us more about your target?
> > >
> > > Amicalement,
> > > --
> > > Albert.
> > >
> >
> > Sorry, My target board is not with SPL.
>
> Then your question does not make sense, since a target without SPL has
> no "second" and "third" stage, only a single standalone U-Boot stage.
>
> > According to my understanding, SPL is required when we want to use NAND
> or
> > oneNAND flash. And even in that case, the image generated, is combined of
> > u-boot.bin+nand_driver.
>
> This is quite reductive and partly wrong.
>
> SPL is required when you cannot directly boot into U-boot, one of the
> cases being when you boot from NAND as it usually only allows very small
> binaries; but NAND is far from the only case where SPL is needed or
> useful.
>
> Also, as I said, the image generated in the SPL case is not "u-boot +
> NAND driver", it is "complete SPL + complete U-Boot" (although you can
> have them separate as I explained), and the "complete SPL" part is not
> itself an "U-Boot plus NAND driver".
>
> > I am using NOR flash.
>
> Ok.
>
> > Actually, I am building firmware upgrade procedure.
> > For that I need 3 partitions for u-boot.
> > One with master u-boot.
> > Other two with u-boot-1 and u-boot-2. (One contains current working
> u-boot,
> > whereas another is with upgraded u-boot code).
> > For that I need one Master uboot which contains code that initializes the
> > SDRAM, choses one of the 2 secondary u-boot with the help of an
> environment
> > variable (Or fixed jump to the start address of u-boot-1 or u-boot-2) and
> > then copies u-boot(Secondary boot loader) to SDRAM and executes it from
> > there.
>
> Ok, so "secondary" is a concept specific to your design. No wonder I
> could not understand it properly until you explained.
>
> > These steps of initializing SDRAM and copying of u-boot code there, are
> > already implemented in u-boot code. I just want to separate it from the
> > main source code and want to generate binary of that much code only.
> >
> > Is there any way to achieve this?
>
> Several; and then there is an infinity of other possible approaches,
> depending, not on *what* you want to do, but on *why* you want to do
> it. Can you give more details on why your firmware upgrade procedure
> needs to boot two different U-Boots  ?
>
> > or
> > Is there any resource of information available which can help me to
> > understand this?
>
> The source code and the Denx website, at this point; once you explain
> the goal you are trying to reach, people on the list might point you
> to more specific resources.
>
> > Rajdeep.
>
> Amicalement,
> --
> Albert.
>



On Wed, Jul 10, 2013 at 5:53 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net>wrote:

> Hi Rajdeep,
>
> On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia
> <rajdeep.vaghasia@gmail.com> wrote:
>
> > Waiting for a reply.
>
> Well, maybe if you had not e-mailed your 8:32 AM answer to me but to
> the list... :)
>
> Here it is, with my comments.
>
> > On Tue, Jul 9, 2013 at 5:31 PM, Albert ARIBAUD <
> albert.u.boot at aribaud.net>wrote:
> >
> > > Hi Rajdeep,
> > >
> > > On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
> > > <rajdeep.vaghasia@gmail.com> wrote:
> > >
> > > > Hi
> > > > I am working on one board with an arm11 based cpu, NOR flash and DDR2
> > > SDRAM.
> > > > When I compile u-boot source code, I get u-boot.bin image generated.
> > > > This image has primary(second stage) and secondary(third stage)
> > > bootloader
> > > > combined.
> > > >
> > > > I have following queries:
> > > > 1) The question that still eats me everyday is, How can I compile
> > > > primary(Master) boot loader and secondary boot loader separately?
> > > > 2) I want to Flash only initial 4kb of code (Master boot loader or
> second
> > > > stage). The remaining code I want to keep at another partition in the
> > > > Flash. How can I achieve this?
> > > > 3) Is there any separate code available for Master boot loader, which
> > > > copies the third stage bootloader to SDRAM and then transfers
> control to
> > > > that third stage boot loader(u-boot)?
> > > >
> > > > I am unable to find a way to do this.
> > > >
> > > > Can anyone help me please?
> > >
> > > Since you do not indicate exactly which target you're building, I'll
> > > assume it is one with SPL (what you describe as master or second stage,
> > > with third stage being u-boot itself).
> > >
> > > I don't know of a way to build SPL alone.
> > >
> > > As for building separate U-Boot and SPL, you'll find them in ELF format
> > > in file ./u-boot and ./spl/u-boot-spl. You can then use
> > > $(CROSS_COMPILE)objcopy to convert from ELF to .bin.
> > >
> > > Note that your target may need a specific format different from the
> > > pure binary that objcopy can produce.
> > >
> > > Can you tell us more about your target?
> > >
> > > Amicalement,
> > > --
> > > Albert.
> > >
> >
> > Sorry, My target board is not with SPL.
>
> Then your question does not make sense, since a target without SPL has
> no "second" and "third" stage, only a single standalone U-Boot stage.
>
> > According to my understanding, SPL is required when we want to use NAND
> or
> > oneNAND flash. And even in that case, the image generated, is combined of
> > u-boot.bin+nand_driver.
>
> This is quite reductive and partly wrong.
>
> SPL is required when you cannot directly boot into U-boot, one of the
> cases being when you boot from NAND as it usually only allows very small
> binaries; but NAND is far from the only case where SPL is needed or
> useful.
>
> Also, as I said, the image generated in the SPL case is not "u-boot +
> NAND driver", it is "complete SPL + complete U-Boot" (although you can
> have them separate as I explained), and the "complete SPL" part is not
> itself an "U-Boot plus NAND driver".
>
> > I am using NOR flash.
>
> Ok.
>
> > Actually, I am building firmware upgrade procedure.
> > For that I need 3 partitions for u-boot.
> > One with master u-boot.
> > Other two with u-boot-1 and u-boot-2. (One contains current working
> u-boot,
> > whereas another is with upgraded u-boot code).
> > For that I need one Master uboot which contains code that initializes the
> > SDRAM, choses one of the 2 secondary u-boot with the help of an
> environment
> > variable (Or fixed jump to the start address of u-boot-1 or u-boot-2) and
> > then copies u-boot(Secondary boot loader) to SDRAM and executes it from
> > there.
>
> Ok, so "secondary" is a concept specific to your design. No wonder I
> could not understand it properly until you explained.
>
> > These steps of initializing SDRAM and copying of u-boot code there, are
> > already implemented in u-boot code. I just want to separate it from the
> > main source code and want to generate binary of that much code only.
> >
> > Is there any way to achieve this?
>
> Several; and then there is an infinity of other possible approaches,
> depending, not on *what* you want to do, but on *why* you want to do
> it. Can you give more details on why your firmware upgrade procedure
> needs to boot two different U-Boots  ?
>
> > or
> > Is there any resource of information available which can help me to
> > understand this?
>
> The source code and the Denx website, at this point; once you explain
> the goal you are trying to reach, people on the list might point you
> to more specific resources.
>
> > Rajdeep.
>
> Amicalement,
> --
> Albert.
>

[U-Boot] Separately compile Master boot loader

[Albert ARIBAUD]

Hi Rajdeep,

On Thu, 11 Jul 2013 10:57:44 +0530, Rajdeep Vaghasia
<rajdeep.vaghasia@gmail.com> wrote:

> Hi Albert,
> 
> I would like to explain you my exact idea.
> For that, The Partition layout is:
> 1) Master u-boot
> 2) u-boot-1
> 3) u-boot-2
> 4) kernel
> 5) filesystem
> 6) data
> 
> Sometimes, When we may require to update with a new u-boot(to provide some
> additional support), we have to overwrite the existing u-boot.
> I don't want to overwrite the existing u-boot.
> Instead, I want to keep a separate partition for new u-boot.
> 
> *Here is the whole procedure:*
> I will maintain one environment variable(say "*safe_u-boot*"), which will
> be used to point to the current 'working u-boot' partition(means, *u-boot-1*
> ).
> 
> I will develop one simple user space application.
> Whenever a new u-boot is available, It will be first copied into the SDRAM
> by this application.
> Then, This application will check the environment variable "*new_u-boot*"
> which will be pointing to second u-boot partition("u-boot-2") in flash.
> And then, it will copy the new u-boot from SDRAM to *NOR flash* on the
> partition pointed to by the "*new_u-boot*" environment variable, and then
> mark one update flag(say, *u_boot_UPDATE*) as '*1*' and reboot the system.
> This update flag is readable/writable by u-boot, kernel and user
> application.
> 
> On reboot,
> master u-boot(on every reboot or system power-up) will check this *
> U_boot_UPDATE* flag  status.
> If it is *set*, then Master u-boot will *first clear* that flag and then,
> will load the u-boot from the partition pointed to by the "new_u-boot" env
> variable.
> 
> case-1:
> If the system is up successfully, the user space application will set the "*
> safe_u-boot*" env variable to point the new partition(which was pointed to
> by "*new_u-boot*") and set "*new_u-boot*" env variable to point to the
> first u-boot partition(which was pointed to by "*safe_u-boot*"). (In short,
> swapping of these environment variables). So, that on second time, when
> system reboots, Master u-boot will see the *U_boot_UPDATE* flag *cleared*,
> and will load the u-boot from the partition pointed to by "*safe_u-boot*",
> which now contains the updated new u-boot.
> 
> case-2:
> If the system fails and can not come up successfully with new u-boot, then
> on *manual reboot*, Master u-boot will check the "*U_boot_UPDATE*" flag,
> which will be in cleared state. (Because during update process, as soon as
> Master U-boot reads this flag as set, it clears the flag). So, Master
> U-boot will load the u-boot from the partition pointed to by the "*
> safe_u-boot*" env variable(which is the working u-boot not updated
> one.(say, u-boot-1)). As the swapping of these environment variables is
> done by user application on successful update, this will not be the case
> with this unsuccessful system up.
> 
> I hope everything is clear, now.
> *So, in this overall implementation*,

Thank you -- now your goals are clear and your question can be answered
in a more detailed manner.

> I want to keep a little code of Master u-boot, which initializes SDRAM, and
> copies secondary u-boot from flash to SDRAM. In addition to these, it keeps
> track of two env variables.
> 
> Is there any separate source code available for this kind of Master U-boot?
> *Or*
> Can we compile the existing u-boot source code such that it will generate
> only a small binary with these little functionalities?
> *Or*
> Can we compile the existing u-boot source code such that it will generate
> both the binaries separately(master u-boot+secondary u-boot)?
>
> Of course, even if Master u-boot is available, I will have to change that a
> bit to implement those environment variable stuff in Master u-boot.
> 
> But this will be very helpful to me, if I get help from you.
> 
> I would like to remind again that, I want to implement this on *NOR Flash*.

There is no separate source code for your "Master U-Boot" concept, nor
is there currently a way to build several U-Boots in one go. The best
match in U-Boot to your "small binary" is SPL, which is intended to be
run first when the whole of U-boot cannot be run directly.

But...

SPL has never been used for NOR FLASH booting, since basically if you
have NOR, then you can start U-boot directly from there whatever its
size, and the first thing it does is setting up DDR and relocating
there; therefore there is (currently) no need for SPL with NOR.

So you would have to:

- make the SPL framework able to run from NOR and chain-load U-boot from
  NOR too;

- make SPL able to select the U-Boot it chainloads to, for instance
  through env variables that override the SPL defaults (maybe looking
  at the Falcon mode might give you ideas on how to best do this);

- configure your target to use SPL with NOR support, with a default
  environment that will load u-boot-1 rather than u-boot-2.

The very first build would produce SPL as your initial (and hopefully
final, too) "Master -U-Boot", and U-Boot as your initial, u-boot-1,
payload. This, flashed onto your target, should boot.

The subsequent builds would build newer SPL (arguably useless if same
as the previous one) and newer U-boot (which would be the "upgrade"
one). You could then, from the u-boot-1 prompt, manually flash this
'new' u-boot-2 and set the environment for an upgrade, then reboot and
test your upgrade procedure.

If rebuilding SPL when not needed is really a pain to you despite not
being the most time-critical task in your overall process, you could
also patch the U-boot build system to allow skipping the SPL build.
Maybe some other boards would be interested in that too, BTW.

> Regards,
> Rajdeep

Amicalement,
-- 
Albert.

[U-Boot] [RFC] Multiple binaries per U-Boot target (was: Separately compile Master boot loader)

[Albert ARIBAUD]

On Thu, 11 Jul 2013 10:35:07 +0200, Albert ARIBAUD
<albert.u.boot@aribaud.net> wrote:

> [...] nor is there currently a way to build several U-Boots in one go.

Although, with recent proposals like the TPL one:

http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/164432

... I am toying with the idea of a more generic build mechanism which
would allow a target to specify as many binaries as it needs, each with
its own configuration.

The simplest targets would have a single build (U-boot itself).

SPL-type targets would have two (SPL and U-Boot).

TPL-like ones would have three (SPL, TPL and U-boot).

Etc.

A developer could then choose to build the default binaries or a
specific set, e.g. only rebuild U-boot for targets whose SPL needs not
change.

For maximum reuse, U-boot would have to be a set of components (and
that's what it is right now, and would be all the more with Kconfig)
and each 'binary' would be a selection of which components. Examples of
components would be:

- startup (mandatory component which contains the entry point);

- setup (optional component which would set up the system incl. DDR);

- relocation (optional component which moves the code up in DDR);

- console (optional component which allows interactive commands);

- chainload (optional component which allows chainloading another
  binary);

Etc. Of course there would be components for architecture support
(PPC, ARM, MIPS, x86)..., for CPU [class] support, for driver support,
for function support).

The interest of this idea would be that SPL and U-Boot would not be
distinguished by #ifs across the code, but only by their respective
configurations. We'd have a clear view and control in a single place
(the configuration header file) of what goes in SPL and what goes in
U-Boot (and what goes in TPL).

To be clearer on configurations and header files: my idea would be to
put SPL configuration under a single '#if CONFIG_BUILDING_SPL'-like
conditional, and U-Boot configuration under #if CONFIG_BUILDING_UBOOT,
and that SPL related configuration options either be replaced by their
general equivalents (for instance, no need for CONFIG_SPL_I2C_SUPPORT
if the SPL configuration includes some CONFIG_I2C_somedriver) or turned
into a component option (e.g. CONFIG_SPL_MAX_FOOTPRINT becoming option
CONFIG_SIZECHECK_MAX_FOOTPRINT).

I don't think this would require overhauling the whole of U-Boot; nor
should all be done in one go. We could independently:

- make sure SPL, U-Boot and TPL are independent sub-targets which can
  be built separately from the command line if needed, with a sane
  default for existing targets;

- progressively replace CONFIG_SPL_xxx options with equivalent
  CONFIG_SYS_xxx ones or move them into new "components" such as
  "sizecheck" or "chainload".

I realize I'm drawing a very rough picture here...

Comments/Criticisms welcome.

Amicalement,
-- 
Albert.

[U-Boot] Separately compile Master boot loader

[Wolfgang Denk]

Dear Rajdeep Vaghasia,

In message <CAONsvZW=XsMPEXixipn5-gnMnpn7R5en_4Pwfj1r+3fuCbxsmw@mail.gmail.com> you wrote:
>
> I would like to explain you my exact idea.
> For that, The Partition layout is:
> 1) Master u-boot
> 2) u-boot-1
> 3) u-boot-2
> 4) kernel
> 5) filesystem
> 6) data

You can do something like this using the SPL in a Pseudo-Falcon-mode.
As you probably know (if not, then please read the docs), Falcon mode
allows you to have the SPL select one from several optional images to
load and start.  Normally the choice is between normal U-Boot and
Linux (to allow for short boot times), but nothing prevents you from
1) providing more than just 2 options to choise from and 2) chosing
between several U-Boot images.

> Sometimes, When we may require to update with a new u-boot(to provide some
> additional support), we have to overwrite the existing u-boot.
> I don't want to overwrite the existing u-boot.
> Instead, I want to keep a separate partition for new u-boot.

Sorry, but your wording is difficult to understand.  You write:

	- We have to do X.
	- I don't want to do X.
	- Instead, I want to do Y.

If you really _have_ to do X, it does not really matter if you like it
or not, you have to do it anyway - in this casse we can stop the
discussion here.

> *Here is the whole procedure:*
> I will maintain one environment variable(say "*safe_u-boot*"), which will
> be used to point to the current 'working u-boot' partition(means, *u-boot-1*
> ).

This is a pretty complex mechanism for a simple thing to do.  I'm not
sure why you are designing such a complicated system.  Standard U-Boot
shell commands should be sufficient.

> *So, in this overall implementation*,
> I want to keep a little code of Master u-boot, which initializes SDRAM, and
> copies secondary u-boot from flash to SDRAM. In addition to these, it keeps
> track of two env variables.

I recommend to take a step back, stop thinkng about a specific
implementation, and just consider which functionality is needed.
Then you should try to find out, which of these requirements are
already provided by existing code and features in U-Boot.  You should
realize that most of this is already ready available in place.

So instead of complicated code that needs to be written new, you just
need minimal glue code to combine the existing features.

> Is there any separate source code available for this kind of Master U-boot?

If I were in your place, I would use SPL to do that.

> Can we compile the existing u-boot source code such that it will generate
> only a small binary with these little functionalities?

That's SPL.

> Can we compile the existing u-boot source code such that it will generate
> both the binaries separately(master u-boot+secondary u-boot)?

That's the "normal" U-Boot, which is used as payload to the SPL.

> I would like to remind again that, I want to implement this on *NOR Flash*.

This actually does not matter at all.  The SPL approach (and Falcon
mode) is not dependent on the boot device.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
SW engineering is a race between programmers trying  to  make  better
idiot-proof programs and the universe producing greater idiots.

[U-Boot] Separately compile Master boot loader

[Wolfgang Denk]

Dear Albert,

In message <20130711103507.48bd224f@lilith> you wrote:
> 
> SPL has never been used for NOR FLASH booting, since basically if you
> have NOR, then you can start U-boot directly from there whatever its
> size, and the first thing it does is setting up DDR and relocating
> there; therefore there is (currently) no need for SPL with NOR.

This is not correct.  SPL on NOR is in no way special from SPL on
other boot devices.  We have successfully used SPL (in Falcon mode) on
NOR flash to reduce boot times.  for example, the MPC5200 (PPC) based
a4m2k board uses SPL on NOR; see include/configs/a3m071.h

> - make the SPL framework able to run from NOR and chain-load U-boot from
>   NOR too;

This has been done before.  It is not a special case, actually.

> - make SPL able to select the U-Boot it chainloads to, for instance
>   through env variables that override the SPL defaults (maybe looking
>   at the Falcon mode might give you ideas on how to best do this);

Adding environment support to SPL on NOR is trivial; it boils down to
adding CONFIG_SPL_ENV_SUPPORT to the board configuration.

> The very first build would produce SPL as your initial (and hopefully
> final, too) "Master -U-Boot", and U-Boot as your initial, u-boot-1,
> payload. This, flashed onto your target, should boot.
> 
> The subsequent builds would build newer SPL (arguably useless if same
> as the previous one) and newer U-boot (which would be the "upgrade"
> one). You could then, from the u-boot-1 prompt, manually flash this
> 'new' u-boot-2 and set the environment for an upgrade, then reboot and
> test your upgrade procedure.

Correct.  And no additional code needs to be written to do all this.
It's all ready available out of box.

> If rebuilding SPL when not needed is really a pain to you despite not
> being the most time-critical task in your overall process, you could
> also patch the U-boot build system to allow skipping the SPL build.
> Maybe some other boards would be interested in that too, BTW.

I think the overhead of always building the SPL is small enough so
this can probably be ignored.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.

[U-Boot] Separately compile Master boot loader

[Albert ARIBAUD]

Hi Wolfgang,

On Thu, 11 Jul 2013 12:08:19 +0200, Wolfgang Denk <wd@denx.de> wrote:

> Dear Albert,
> 
> In message <20130711103507.48bd224f@lilith> you wrote:
> > 
> > SPL has never been used for NOR FLASH booting, since basically if you
> > have NOR, then you can start U-boot directly from there whatever its
> > size, and the first thing it does is setting up DDR and relocating
> > there; therefore there is (currently) no need for SPL with NOR.
> 
> This is not correct.  SPL on NOR is in no way special from SPL on
> other boot devices.  We have successfully used SPL (in Falcon mode) on
> NOR flash to reduce boot times.  for example, the MPC5200 (PPC) based
> a4m2k board uses SPL on NOR; see include/configs/a3m071.h

Apologies for my mistake.

Amicalement,
-- 
Albert.

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Sascha Silbe]

Albert ARIBAUD <albert.u.boot@aribaud.net> writes:

> Although, with recent proposals like the TPL one:
>
> http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/164432
>
> ... I am toying with the idea of a more generic build mechanism which
> would allow a target to specify as many binaries as it needs, each with
> its own configuration.

FWIW, I like the idea. Apart from streamlining the current code, it
would allow building custom chains of bootloaders. One thing I could use
for development would be a minimal stage that can load one of two
"normal" / full-blown U-Boot versions, similar to dual BIOS support on
modern x86 PCs. All devices I work with can be un-bricked reasonably
easily, but for most of them it either requires manual interaction
(e.g. the push-button for UART boot on CuBox) or prevents "normal" boots
(e.g. removing the SD card on Wandboard so that it boots via USB
_instead_ of from SD card).

In addition, it would allow customising SPL features without having to
introduce more special code.

Sascha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130719/e4905f97/attachment.pgp>

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Simon Glass]

Hi,

On Fri, Jul 19, 2013 at 9:27 AM, Sascha Silbe <t-uboot@infra-silbe.de>wrote:

> Albert ARIBAUD <albert.u.boot@aribaud.net> writes:
>
> > Although, with recent proposals like the TPL one:
> >
> > http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/164432
> >
> > ... I am toying with the idea of a more generic build mechanism which
> > would allow a target to specify as many binaries as it needs, each with
> > its own configuration.
>
> FWIW, I like the idea. Apart from streamlining the current code, it
> would allow building custom chains of bootloaders. One thing I could use
> for development would be a minimal stage that can load one of two
> "normal" / full-blown U-Boot versions, similar to dual BIOS support on
> modern x86 PCs. All devices I work with can be un-bricked reasonably
> easily, but for most of them it either requires manual interaction
> (e.g. the push-button for UART boot on CuBox) or prevents "normal" boots
> (e.g. removing the SD card on Wandboard so that it boots via USB
> _instead_ of from SD card).
>
> In addition, it would allow customising SPL features without having to
> introduce more special code.
>

We actually use something like this in Chrome OS. Right now we are working
on a 'small' U-Boot which is not SPL but has no commands (they are compiled
out by a CONFIG option which I will post one day). This will involve two
complete runs of the U-Boot Makefile - one to create each version of
U-Boot. It would be great if this could be handled automatically in the
same build.

I wonder in fact if one day full U-Boot could be small enough then we
wouldn't need SPL for some SOCs.

Another idea I think Wolfgang suuggested was to implement modules, and
bring in code as needed, but that seems a bigger ask.

Regards,
Simon

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Albert ARIBAUD]

Hi Simon,

On Fri, 19 Jul 2013 10:53:33 -0600, Simon Glass <sjg@chromium.org>
wrote:

> Hi,
> 
> On Fri, Jul 19, 2013 at 9:27 AM, Sascha Silbe <t-uboot@infra-silbe.de>wrote:
> 
> > Albert ARIBAUD <albert.u.boot@aribaud.net> writes:
> >
> > > Although, with recent proposals like the TPL one:
> > >
> > > http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/164432
> > >
> > > ... I am toying with the idea of a more generic build mechanism which
> > > would allow a target to specify as many binaries as it needs, each with
> > > its own configuration.
> >
> > FWIW, I like the idea. Apart from streamlining the current code, it
> > would allow building custom chains of bootloaders. One thing I could use
> > for development would be a minimal stage that can load one of two
> > "normal" / full-blown U-Boot versions, similar to dual BIOS support on
> > modern x86 PCs. All devices I work with can be un-bricked reasonably
> > easily, but for most of them it either requires manual interaction
> > (e.g. the push-button for UART boot on CuBox) or prevents "normal" boots
> > (e.g. removing the SD card on Wandboard so that it boots via USB
> > _instead_ of from SD card).
> >
> > In addition, it would allow customising SPL features without having to
> > introduce more special code.
> >
> 
> We actually use something like this in Chrome OS. Right now we are working
> on a 'small' U-Boot which is not SPL but has no commands (they are compiled
> out by a CONFIG option which I will post one day). This will involve two
> complete runs of the U-Boot Makefile - one to create each version of
> U-Boot. It would be great if this could be handled automatically in the
> same build.

My idea is that any 'component' needed in at least one 'binary' would
be compiled once, and then linked as many times as there would be
binaries needing it, all in one single makefile invocation.

> Regards,
> Simon

Amicalement,
-- 
Albert.

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Simon Glass]

Hi Albert,

On Fri, Jul 19, 2013 at 12:12 PM, Albert ARIBAUD
<albert.u.boot@aribaud.net>wrote:

> Hi Simon,
>
> On Fri, 19 Jul 2013 10:53:33 -0600, Simon Glass <sjg@chromium.org>
> wrote:
>
> > Hi,
> >
> > On Fri, Jul 19, 2013 at 9:27 AM, Sascha Silbe <t-uboot@infra-silbe.de
> >wrote:
> >
> > > Albert ARIBAUD <albert.u.boot@aribaud.net> writes:
> > >
> > > > Although, with recent proposals like the TPL one:
> > > >
> > > > http://permalink.gmane.org/gmane.comp.boot-loaders.u-boot/164432
> > > >
> > > > ... I am toying with the idea of a more generic build mechanism which
> > > > would allow a target to specify as many binaries as it needs, each
> with
> > > > its own configuration.
> > >
> > > FWIW, I like the idea. Apart from streamlining the current code, it
> > > would allow building custom chains of bootloaders. One thing I could
> use
> > > for development would be a minimal stage that can load one of two
> > > "normal" / full-blown U-Boot versions, similar to dual BIOS support on
> > > modern x86 PCs. All devices I work with can be un-bricked reasonably
> > > easily, but for most of them it either requires manual interaction
> > > (e.g. the push-button for UART boot on CuBox) or prevents "normal"
> boots
> > > (e.g. removing the SD card on Wandboard so that it boots via USB
> > > _instead_ of from SD card).
> > >
> > > In addition, it would allow customising SPL features without having to
> > > introduce more special code.
> > >
> >
> > We actually use something like this in Chrome OS. Right now we are
> working
> > on a 'small' U-Boot which is not SPL but has no commands (they are
> compiled
> > out by a CONFIG option which I will post one day). This will involve two
> > complete runs of the U-Boot Makefile - one to create each version of
> > U-Boot. It would be great if this could be handled automatically in the
> > same build.
>
> My idea is that any 'component' needed in at least one 'binary' would
> be compiled once, and then linked as many times as there would be
> binaries needing it, all in one single makefile invocation.
>

That would be excellent!

Regards,
Simon

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Wolfgang Denk]

Dear Sascha Silbe,

In message <toetxjq8t90.fsf@twin.sascha.silbe.org> you wrote:
>
> FWIW, I like the idea. Apart from streamlining the current code, it
> would allow building custom chains of bootloaders. One thing I could use
> for development would be a minimal stage that can load one of two
> "normal" / full-blown U-Boot versions, similar to dual BIOS support on
> modern x86 PCs. All devices I work with can be un-bricked reasonably
> easily, but for most of them it either requires manual interaction
> (e.g. the push-button for UART boot on CuBox) or prevents "normal" boots
> (e.g. removing the SD card on Wandboard so that it boots via USB
> _instead_ of from SD card).

I think this could be done easily using SPL (look up the Falcon mode
docs).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
In my experience the best way to get something done  is to give it to
someone who is busy.               - Terry Pratchett, _Going_Postal_

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <20130719201237.7c83a314@lilith> you wrote:
> 
> My idea is that any 'component' needed in at least one 'binary' would
> be compiled once, and then linked as many times as there would be
> binaries needing it, all in one single makefile invocation.

This works only as long as all builds use the very same configuration
and compiler options.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I program, therefore I am.

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Albert ARIBAUD]

Hi Wolfgang,

On Fri, 19 Jul 2013 21:27:54 +0200, Wolfgang Denk <wd@denx.de> wrote:

> Dear Albert ARIBAUD,
> 
> In message <20130719201237.7c83a314@lilith> you wrote:
> > 
> > My idea is that any 'component' needed in at least one 'binary' would
> > be compiled once, and then linked as many times as there would be
> > binaries needing it, all in one single makefile invocation.
> 
> This works only as long as all builds use the very same configuration
> and compiler options.

Indeed. I suspect driver configurations would be pretty much constant
but other components might have different settings for different
binaries.

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Wolfgang Denk]

Dear Albert,

In message <20130719230905.7a0d7f97@lilith> you wrote:
> 
> > This works only as long as all builds use the very same configuration
> > and compiler options.
> 
> Indeed. I suspect driver configurations would be pretty much constant
> but other components might have different settings for different
> binaries.

Tapping into ccache might be an idea - it has to determine exactly
the same situation: recompiling the same set of sources under
identical conditions.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is nothing in this world constant but inconstancy.      - Swift

[U-Boot] [RFC] Multiple binaries per U-Boot target

[Albert ARIBAUD]

Hi Wolfgang,

On Sat, 20 Jul 2013 00:32:26 +0200, Wolfgang Denk <wd@denx.de> wrote:

> Dear Albert,
> 
> In message <20130719230905.7a0d7f97@lilith> you wrote:
> > 
> > > This works only as long as all builds use the very same configuration
> > > and compiler options.
> > 
> > Indeed. I suspect driver configurations would be pretty much constant
> > but other components might have different settings for different
> > binaries.
> 
> Tapping into ccache might be an idea - it has to determine exactly
> the same situation: recompiling the same set of sources under
> identical conditions.

Thanks for the suggestion -- I will look into it.

> Best regards,
> 
> Wolfgang Denk

Amicalement,
-- 
Albert.