Re: [U-Boot] (imp) uboot image size
i am working on Powerpc. sorry for the late response. -SAgar On Wed, Jul 14, 2010 at 6:37 PM, Albert ARIBAUD albert.arib...@free.frwrote: 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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
Dear Sagar Heroorkar, In message aanlktinffetcecool9xw-e3dthx3pxy-vlol3hcu4...@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: w...@denx.de Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
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 w...@denx.de wrote: Dear Sagar Heroorkar, In message aanlktinffetcecool9xw-e3dthx3pxy-vlol3hcu4...@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: w...@denx.de Living on Earth may be expensive, but it includes an annual free trip around the Sun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
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 fffa (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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
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 fffa (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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
Dear Sagar Heroorkar, please mind the Netiquette - do not top post, do not full quote. In message aanlktilh2l9qoofmfto4ho5xkvmkkn0u1o_iskzpo...@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: w...@denx.de Respect is a rational process -- McCoy, The Galileo Seven, stardate 2822.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
Dear Sagar Heroorkar, In message aanlktiku-szcralad6kmsynezwpqh2uqnfmfctyyu...@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 fffa (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: w...@denx.de Keep your eyes wide open before marriage, half shut afterwards. -- Benjamin Franklin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
Dear Albert ARIBAUD,
In message 4c3e135b.7040...@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: w...@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 mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
Dear Albert ARIBAUD, In message 4c3e20a3.1020...@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 0xFFFC 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: w...@denx.de If anything can go wrong, it will. - Edsel Murphy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
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 message4c3e2808.5040...@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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
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@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] (imp) uboot image size
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 fffa now i changed to fe40 let me know what else i should change so that it will hve image size as 384k -Sagar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] (imp) uboot image size
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 fffa now i changed to fe40 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 mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
