Le 14/07/2010 21:25, Sagar Heroorkar a écrit :

I changed the TEXT_BASE to implement the uboot redundancy. I got in to problem of having image size. See this: 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

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?

Any pointers will help me if any one already did this kind of approach making uboot redundant.

I see several issues in your overall plan, the main one of which being, once you've chosen from uboot1 or uboot2 and given control to it, it can fail in many irrecoverable ways, so you won't be able to detect it failed. But let's assume your failure scenarios handle this (or discuss it in another thread).

The way your system is designed, as I understand it, you don't need to touch TEXT_BASE at all:

1) your golden u-boot does not need TEXT_BASE as it will execute from Flash only (it is basically made of the beginning of the current low level init code of u-boot plus whatever is needed to read the data necessary to decide which u-boot to jump to;

2) each of your uboot1/uboot2 can relocate to the current TEXT_BASE in RAM (basically the only change would be removing the beginning of the low-level init code which is already done by the "golden" bootloader).

Even if your "golden", uboot1 and uboot2 bootloaders are all full-blown u-boots, you still don't need to change their TEXT_BASE: just make sur uboot{1,2} have CONFIG_SKIP_LOWLEVEL_INIT defined, and that "golden" either go'es to their Flash entry point or copies them from Flash to somewhere free in RAM then go'es there: in any case, they will relocate themselves over "golden" -- this overloading works, I use it routinely on my ED Mini V2.

Amicalement,

Dear Sagar Heroorkar,

In message AANLkTikU-szcraLAd6kmsYneZWPQH2uQnFmFcTyyugZl@mail.gmail.com you wrote:

I changed the TEXT_BASE to implement the uboot redundancy. I got in to problem of having image size.

See this:

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

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.

You are miscounting. You are talking about 3 (three) instances (not copies, as these will NOT be identical copies) of U-Boot here.

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?

Frankly, you should try and get a better understanding of the innards of U-Boot before trying to implement such a relatively complicated feature.

Instead of trying to use "copies" of the normal U-Boot images, you probably want to look into the equivalent of second-stage images as used for example with NAND-booting systems.

Best regards,

Wolfgang Denk