[U-Boot] uboot redundancy.

[Sagar Heroorkar]

Hi Wlfgang,


> resending this.
>
> Please do reply
>
> -Sagar
>
>   On Fri, Jul 16, 2010 at 3:12 PM, Sagar Heroorkar <
> sagar.heroorkar at gmail.com> wrote:
>
>> 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
>>>
>>
>>
>