Hi Rajdeep,
On Thu, 11 Jul 2013 10:57:44 +0530, Rajdeep Vaghasia
<rajdeep.vagha...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
