Dear Rajdeep Vaghasia,
In message <CAONsvZW=xsmpexixipn5-gnmnpn7r5en_4pwfj1r+3fucbx...@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: w...@denx.de
SW engineering is a race between programmers trying to make better
idiot-proof programs and the universe producing greater idiots.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
