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.r...@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 >
_______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
