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@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