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.b...@aribaud.net>wrote:
> Hi Rajdeep,
>
> On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia
> <rajdeep.vagha...@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.b...@aribaud.net>wrote:
> >
> > > Hi Rajdeep,
> > >
> > > On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
> > > <rajdeep.vagha...@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.b...@aribaud.net>wrote:
> Hi Rajdeep,
>
> On Wed, 10 Jul 2013 15:04:12 +0530, Rajdeep Vaghasia
> <rajdeep.vagha...@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.b...@aribaud.net>wrote:
> >
> > > Hi Rajdeep,
> > >
> > > On Tue, 9 Jul 2013 16:12:14 +0530, Rajdeep Vaghasia
> > > <rajdeep.vagha...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
