[U-Boot] uboot redundancy.
Sagar Heroorkar
sagar.heroorkar at gmail.com
Fri Jul 16 21:12:00 CEST 2010
Hi Joakim,
Graeme referred me to contact you for this.
I am working on U-boot making it PIC for ppc 405ex based boards.
I see in the following link
http://www.mail-archive.com/u-boot@lists.denx.de/msg26918.html
that you have implemented similar thing on 83xx board.
I have downloaded latest u-boot from ftp server of denx. I dont see the
functions what you have modified like LINKF_OFF() etc.
I would like to know where is the source code for that. Also is there any
document other than the mail thread that explains what you have chagned.
Thanks in advance.
-Sagar
On Sat, Jul 10, 2010 at 7:11 AM, Graeme Russ <graeme.russ at gmail.com> wrote:
> On 10/07/10 00:03, Sagar Heroorkar wrote:
> > Hi All,
> >
> > I am planning to implement uboot redundancy.
> > This means having the following idea which we thought.
> >
> > Golden-Uboot which is flashed in the NOR-FLASH. This is not field
> > upgradable.
> > This golden uboot is going to have logic to pick the other uboot based on
> > certain flags or env vriables
> >
> > As i mentioned i wanted the uboot to be redundant.
> > So i will have 2 copies of uboot now.
> > Uboot1
> > Uboot2
>
> I have a similar plan for x86 although the rationale was to enable rapid
> load-reset-test(-write to boot ROM on pass).
>
> The x86 port has the ability to load a new version of U-Boot into an
> arbitrary location in RAM and 'boot-strap' directly into it. I was planning
> on doing something similar to what you propose - All that is needed is a
> little bit of code in the low-level boot-strap to choose whether to
> continue loading the main image, or a secondary image. Note that at this
> point, there is no environment and no CFI driver so any decision would need
> to be based on NVRAM data.
>
> >
> > Golden uboot will pick either of one uboots mentioned above. If the
> uboot1
> > which is picked fails to boot, then we will have uboot2 as back up to
> boot.
> > vice versa.
> >
> > Golden uboot recides in the address fffa0000 (start.s).
> > There is a relocation code which copies the code from flash to ram. if
> the
> > uboot which i have picked addressess will change , hence how can i do the
> > relocation?
>
> x86 port has 'proper' relocation. It does not matter where the target image
> resides, it will reload itself into the highest available memory location
> and run from there.
>
> >
> > Any pointers will help me if any one already did this kind of approach
> > making uboot redundant.
> >
>
> There were some posts a little while ago (search for posts by Joakim
> Tjernlund - he was working on a 100% position independent U-Boot)
>
> My work on U-Boot has been very slow of late, but I would be really
> interested in working through this idea in a platform independent way.
>
> --
> Graeme
>
More information about the U-Boot
mailing list