[U-Boot] (imp) uboot image size

[U-Boot] (imp) uboot image size

[Sagar Heroorkar]

Hi All,

I changed the TEXT_BASE address to something different. I see that the image
size of the uboot is changed so much.

Image size became to 28MB. I dotn know how to make it to 384k.

Earliar text base was at address fffa0000
now i changed to fe400000

let me know what else i should change so that it will hve image size as 384k

-Sagar

[U-Boot] (imp) uboot image size

[Albert ARIBAUD]

Le 13/07/2010 20:38, Sagar Heroorkar a ?crit :
> Hi All,
>
> I changed the TEXT_BASE address to something different. I see that the image
> size of the uboot is changed so much.
>
> Image size became to 28MB. I dotn know how to make it to 384k.
>
> Earliar text base was at address fffa0000
> now i changed to fe400000
>
> let me know what else i should change so that it will hve image size as 384k
>
> -Sagar

Hi Sagar,

What board are you building for? Maybe you changed TEXT_BASE in the 
board's config.mk but not in the linker file.

Amicalement,
-- 
Albert.

[U-Boot] (imp) uboot image size

[Wolfgang Denk]

Dear Sagar Heroorkar,

In message <AANLkTinFFEtcEcool9xW-E3dthx3PXy-VLoL3hcU46x3@mail.gmail.com> you wrote:
> 
> I changed the TEXT_BASE address to something different. I see that the image
> size of the uboot is changed so much.

It seems you did not really understand what your change is doing, so
maybe you explain why you made this change in the first place?

What did you try to acchive?

> let me know what else i should change so that it will hve image size as 384k

Undo your changes to TEXT_BASE.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Living on Earth may be expensive, but it includes an annual free trip
around the Sun.

[U-Boot] (imp) uboot image size

[Sagar Heroorkar]

I am trying to relocate the uboot code to different address in the norflash.

-Sagar

On Wed, Jul 14, 2010 at 2:10 AM, Wolfgang Denk <wd@denx.de> wrote:

> Dear Sagar Heroorkar,
>
> In message <AANLkTinFFEtcEcool9xW-E3dthx3PXy-VLoL3hcU46x3@mail.gmail.com>
> you wrote:
> >
> > I changed the TEXT_BASE address to something different. I see that the
> image
> > size of the uboot is changed so much.
>
> It seems you did not really understand what your change is doing, so
> maybe you explain why you made this change in the first place?
>
> What did you try to acchive?
>
> > let me know what else i should change so that it will hve image size as
> 384k
>
> Undo your changes to TEXT_BASE.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
> Living on Earth may be expensive, but it includes an annual free trip
> around the Sun.
>

[U-Boot] (imp) uboot image size

[Sagar Heroorkar]

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.

[U-Boot] (imp) uboot image size

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] (imp) uboot image size

[Wolfgang Denk]

Dear Sagar Heroorkar,

please mind the Netiquette - do not top post, do not full quote.

In message <AANLkTilh2L9qoOfMfto4Ho5XKvmKKN0u1o_iSKZPOX7x@mail.gmail.com> you wrote:
> 
> I am trying to relocate the uboot code to different address in the norflash.

You definitely do NOT want to do that - mind that "relocate" is a
well-defined term that does not mean what you seem to think it means
(or you don't care).

> > It seems you did not really understand what your change is doing, so
> > maybe you explain why you made this change in the first place?
> >
> > What did you try to acchive?

You did not answer my question.

Why are you trying to move the TEXT_BASE?

Eventually your processor (which you do not care to mention) has it's
reset entry point at the end of the physical addess space, so this
will always be included in theimage - the further you move TEXT_BASE
down, the bigger your image will be.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Respect is a rational process
	-- McCoy, "The Galileo Seven", stardate 2822.3

[U-Boot] (imp) uboot image size

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Keep your eyes wide open before marriage, half shut afterwards.
                                                 -- Benjamin Franklin

[U-Boot] (imp) uboot image size

[Albert ARIBAUD]

Le 14/07/2010 22:29, Wolfgang Denk a ?crit :

> Eventually your processor (which you do not care to mention) has it's
> reset entry point at the end of the physical addess space, so this
> will always be included in theimage - the further you move TEXT_BASE
> down, the bigger your image will be.

Uhm... At least for edminiv2 (and I assume, for other orion5x-based 
boards as well) changing TEXT_BASE in the board's config.mk does not 
change the size of the u-boot image; it just changes the RAM address at 
which it shall relocate and run.

Amicalement,
-- 
Albert.

[U-Boot] (imp) uboot image size

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4C3E135B.7040403@free.fr> you wrote:
>
> 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"

Be careful.

CONFIG_SKIP_LOWLEVEL_INIT is an ARM specific thing, and I am almost
sure that Sagar is on a PowerPC systems.

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

Be careful again. Do you really mean "relocate" here? And
"overloading" a running image is definitely NOT a safe operation.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ein weiser Herrscher kann in einem gro?en Land  mehr  Gutes  bewirken
als  in  einem kleinen - ein dummer Herrscher aber auch viel mehr Un-
fug. Da weise Herrscher seltener sind als dumme, war ich schon  immer
gegen gro?e Reiche skeptisch.                   - Herbert Rosendorfer

[U-Boot] (imp) uboot image size

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4C3E20A3.1020600@free.fr> you wrote:
>
> > Eventually your processor (which you do not care to mention) has it's
> > reset entry point at the end of the physical addess space, so this
> > will always be included in theimage - the further you move TEXT_BASE
> > down, the bigger your image will be.
>
> Uhm... At least for edminiv2 (and I assume, for other orion5x-based
> boards as well) changing TEXT_BASE in the board's config.mk does not
> change the size of the u-boot image; it just changes the RAM address at
> which it shall relocate and run.

I think I am aware of this :-)

Actually this is the very reason why I am pretty sure that the OP is on
a PPC box with the reset vector at 0xFFFFFFFC being part of the image.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"If anything can go wrong, it will."                   - Edsel Murphy

[U-Boot] (imp) uboot image size

[Albert ARIBAUD]

Le 14/07/2010 23:49, Wolfgang Denk a ?crit :
> Dear Albert ARIBAUD,
>
> why not keeping the list on Cc:?

Wrong and unintended action on my part, sorry: I hit the wrong reply 
button (maybe there's a Thunderbird plugin that helps avoiding this?). 
As I don't know if you meant this reply of yours to be made public 
eventually, I'm replying in private. If you want to switch back to the 
list, no problem for me.

> In message<4C3E2808.5040509@free.fr>  you wrote:
>>
>>> CONFIG_SKIP_LOWLEVEL_INIT is an ARM specific thing, and I am almost
>>> sure that Sagar is on a PowerPC systems.
>>
>> I think we both asked what system Sagar is talking about. But yes, I am
>> talking about ARM here -- the only architecture for which I can claim
>> knowledge of u-boot init sequence if I have any.
>
> I understand this. Sagar probably doesn't.
>
>>> Be careful again. Do you really mean "relocate" here? And
>>> "overloading" a running image is definitely NOT a safe operation.
>>
>> By "relocate" I mean the code that runs after low level init code once
>> RAM is available: if CONFIG_SKIP_RELOCATION is not defined (again, on
>> ARM, at least on arm926ejs) this relocation code moves u-boot from its
>> current location to TEXT_BASE, then jumps to it.
>
> But that is actyally only copying the code, not relocating it. We need
> to be very precise with these terms, as they mean different things.

I understand your point -- indeed, the code was intended to run at 
TEXT_BASE, and the actual relocation is when it is stored in Flash (or 
RAM when TFTP'ed) and starts running there; the code I mentionede which 
is under !CONFIG_SKIP_RELOCATION actually "de-relocates" it back to 
where it should have been.

>> As for "overloading", I should say "overwriting" actually, and it is
>> quite safe -- as safe as booting u-boot at least, as this "overwriting"
>> is the effect of the relocation I just described, which happens at every
>> (ARM) u-boot NOR FLASH startup.
>
> I disagree. You do not "overwrite" any running code.

If you mean "it is forbidden to overwrite any running code", you're 
right; but this never happens in the two scenarios I describe where 
(de)relocation happens: in the NOR Flash boot scenario, there is no code 
running at TEXT_BASE when U-boot gets copied there; in the "TFTP" 
scenario, granted the "chaining" u-boot is running at TEXT_BASE when it 
executes the 'go' to whereever in RAM the "chained" u-boot resides; but 
as soon as this "chained" u-boot starts executing, the "chaining" u-boot 
executes no more and never will again (there is caution of course to be 
taken regarding e.g. instruction cache, but this is taken care of in the 
u-boot startup code).

>> For instance, when I boot my edmini from NOR Flash, its flashed u-boot
>> starts, then relocates itself to TEXT_BASE in RAM and runs from there. I
>
> ...it gets copied to RAM...
>
>> can then do e.g. a tftp of a u-boot (which has low level init disabled
>> but relocation enabled) to some location in RAM other than TEXT_BASE,
>> and 'go' there. The RAM-loaded u-boot will relocate to TEXT_BASE and run
>> there, and will never return (it will destroy the former u-boot's stack
>> and establish its own).
>
> This may, or may not work. In general, it will NOT work unless you
> make sure that your new copy does not assume it is running on a a
> pre-initialized system.

Precisely. That is why I specified that in such a scenario, the 
"chained" u-boot needs to have CONFIG_SKIP_LOWLEVEL_INIT set 
(implicitely assuming that the chaining u-boot should have it unset, but 
that may or may not be necessary--for instance, a Flash-based orion5x 
u-boot should, and a Flash-based kirkwood should not, have 
CONFIG_SKIP_LOWLEVEL_INIT unset).

> Best regards,
>
> Wolfgang Denk

Amicalement,
-- 
Albert.

[U-Boot] (imp) uboot image size

[Albert ARIBAUD]

Le 15/07/2010 00:35, Albert ARIBAUD a ?crit :
> Le 14/07/2010 23:49, Wolfgang Denk a ?crit :
>> Dear Albert ARIBAUD,
>>
>> why not keeping the list on Cc:?
>
> Wrong and unintended action on my part, sorry: I hit the wrong reply
> button (maybe there's a Thunderbird plugin that helps avoiding this?).
> As I don't know if you meant this reply of yours to be made public
> eventually, I'm replying in private. If you want to switch back to the
> list, no problem for me.

Argh. Seems like I'm cursed :( -- Apologies for going back to the list 
when I say I don't.

Amicalement,
-- 
Albert.

[U-Boot] (imp) uboot image size

[Sagar Heroorkar]

i am working on Powerpc. sorry for the late response.

-SAgar

On Wed, Jul 14, 2010 at 6:37 PM, Albert ARIBAUD <albert.aribaud@free.fr>wrote:

> Le 15/07/2010 00:35, Albert ARIBAUD a ?crit :
> > Le 14/07/2010 23:49, Wolfgang Denk a ?crit :
> >> Dear Albert ARIBAUD,
> >>
> >> why not keeping the list on Cc:?
> >
> > Wrong and unintended action on my part, sorry: I hit the wrong reply
> > button (maybe there's a Thunderbird plugin that helps avoiding this?).
> > As I don't know if you meant this reply of yours to be made public
> > eventually, I'm replying in private. If you want to switch back to the
> > list, no problem for me.
>
> Argh. Seems like I'm cursed :( -- Apologies for going back to the list
> when I say I don't.
>
> Amicalement,
> --
> Albert.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>