[U-Boot] how can i change u-boot load address?
hi every one..
currently, u-boot load it self in SDRAM address : 0x80100000 i want the u-boot to be loaded to address: 0x80FE0000. i have try the following:
1#repeating the last steps preform by the build script: 1-./tools/mkimage -A mips -T firmware -C bzip2 -a 0x80100000 -e 0x80100000 -n 'u-boot image' -d u-boot.bz2 u-boot.zimg 2-./mk_ubootimg.sh head.bin u-boot.zimg 12400 u-boot.img 3-mipsel-linux-objcopy -I binary -O binary --pad-to 0x10000 u-boot.img u-boot.img that of course after changing to the new address, but when downloading it to the board, it hangs
2#in the mkimage.c file, i have change the code a little:
case 'a': if (--argc <= 0) usage (); addr = strtoul ("0x80FE0000", (char **)&ptr, 16); *++argv; if (*ptr) { fprintf (stderr, "%s: invalid load address %s\n", cmdname, *argv); exit (EXIT_FAILURE);
their was no compilation error, but also the board hangs 3# i thought a bout the entry point, and make it to match the load address, but still the same result.
can you tell me how to change the load address without crippling the u-boot?
with respect sahar mustafa.
On Mon, Oct 6, 2008 at 7:13 AM, sahar mustafa nilesmile@live.com wrote:
can you tell me how to change the load address without crippling the u-boot?
It's not 100% clear what you are trying to do, and you didn't mention your target other than it's MIPS...
If you want to build a version of u-boot that is linked to a start address that is in RAM for loading via a jtag debugger, then change the definition of TEXT_BASE in board/<your board name here>/config.mk. You have to make sure that u-boot doesn't try to re-initialize the ram or caches, and doesn't write over parts of itself when it relocates or allocates memory for the stack and heap.
If you want to make sure u-boot is still linked in ROM, but gets put at the top of memory during relocation, then you have to make sure the initdram() function in your code returns the correct ram size. If you look in lib_mips/board.c board_init_f(), ram starts being allocated top down, starting at CFG_SDRAM_BASE + gd->ram_size. gd->ram_size is initialized by the return value of a call to initdram() which is usually somewhere in the board specific code.
Hello Andrew,
2008/10/6 Andrew Dyer amdyer@gmail.com:
If you want to build a version of u-boot that is linked to a start address that is in RAM for loading via a jtag debugger, then change the definition of TEXT_BASE in board/<your board name here>/config.mk.
Can the value of TEXT_BASE be arbitrary chosen for test purposes?
If you want to make sure u-boot is still linked in ROM, but gets put at the top of memory during relocation, then you have to make sure the initdram() function in your code returns the correct ram size.
As I understand it's valid for MIPS or PPC based architectures, right? On many MCUs built on arm7tdmi core (for example, SAM7 family from Atmel) the process of starting up involves remapping, i.e. 0x0 address points on ROM at reset and on RAM after remap. U-Boot usually resides in ROM storage at startup, after reset relocates itself to RAM -- should not it involve remapping as well?
I didn't find how it's done in U-Boot (if it's done at all). Would appreciate a lot for clarification.
I'm trying to understand how it's done on ARM --
Hello
2008/10/6 Roman Mashak romez777@gmail.com:
[skip]
On many MCUs built on arm7tdmi core (for example, SAM7 family from Atmel) the process of starting up involves remapping, i.e. 0x0 address points on ROM at reset and on RAM after remap. U-Boot usually resides in ROM storage at startup, after reset relocates itself to RAM -- should not it involve remapping as well?
I didn't find how it's done in U-Boot (if it's done at all). Would appreciate a lot for clarification.
I seem to understand that remapping, being a CPU specific and depending on a way U-Boot starts (either from ROM or RAM), is taken away in 'lowlevel_init' function, defined either in in $(uboot)/cpu/arm/$(soc)/lowlevel_init.S (for example, $(uboot)/cpu/arm920t/ks8695/) or in $(uboot)/board/board_name/lowlevel_init.S, but what confuses me is that I couldn't find remap functions on every ARM platform, running from ROM at reset.
Dear Roman,
In message 40a670230810061636u3c7c3c1dn26f6860a1b463d8b@mail.gmail.com you wrote:
Can the value of TEXT_BASE be arbitrary chosen for test purposes?
No, it cannot. You have to define a memory map for your system, which will result in certain restrictions for the choice of TEXT_BASE.
In general, you have to understand what you are doing, and in detail.
I'm trying to understand how it's done on ARM --
On ARM it's being done wrong - no real relocation is preformed; instead, U-Boot is liked to a fixed address in RAM. The startup code (mostly assembler) can run from ROM (too).
Best regards,
Wolfgang Denk
Hi Wolfgang Denk,
wd wrote:
I'm trying to understand how it's done on ARM --
On ARM it's being done wrong - no real relocation is preformed; instead, U-Boot is liked to a fixed address in RAM. The startup code (mostly assembler) can run from ROM (too).
If you can tell me what exactly is wrong with ARM startup, i will try to find a solution. Can u point the platform and its startup functions where it is been done correctly. Then i will try to fixup th error in ARM.
Thanks in advance
Regards Gururaja
Dear Hebbar,
In message 19853320.post@talk.nabble.com you wrote:
If you can tell me what exactly is wrong with ARM startup, i will try to find a solution. Can u point the platform and its startup functions where it is been done correctly. Then i will try to fixup th error in ARM.
The fundamental problem with the ARM port is that on ARM, U-Boot gets linked to a fixed address in RAM.
We inherited this deficiency from the ARMBoot port - when the old PPCBoot (PowerPC only) got ported to ARM, the developers thought that the whole relocation as implemented in PPCBoot was too complicated and just not worth the effort, so they did what they did. BTW: later, the MIPS port copied the ARM implementation, unfortunately.
The advantage of the PowerPC implementation with relocation is that we can measure the actual size of memory present on the board, and then relocate U-Boot to the very end of the RAM, leaving nearly th whole RAM usable as one big contiguous area for "applications" like loading Linux kernel, ramdisk, etc.
The problem with the ARM implementation is that the link address is fixed, i. e. it cannot be adjusted to varying RAM sizes. If you have a board which can be fit with either 32 or with 64 MB of RAM, you have to link U-Boot so that it sits at the end of the 32 MB area. Which means that on a 64 MB system it will sit right in the middle of the RAM, splitting the RAM in two small chunks. Try to explain to a customer why he has some 60+ MB of free RAM on the system but he still cannot load a 33 MB ramdisk image...
There are more consequences from this design - on PowerPC we can implement "protected RAM", framebuffer memory we can share with Linux, log buffer memory we can share with Linux, etc. - all these need to sit at the end of the available physical RAM. On PowerPC, it goes without saying that all this works perfectly fine with variable RAM sizes (so we can have one U-Boot image working for example with different DIMM modules). On ARM, you have to configure U-Boot for a fixed memory size.
Best regards,
Wolfgang Denk
Hello
2008/10/7 Wolfgang Denk wd@denx.de:
I'm trying to understand how it's done on ARM --
On ARM it's being done wrong - no real relocation is preformed;
What do you mean by "real relocation"? As per start.S bootcode is copied from ROM to RAM.
instead, U-Boot is liked to a fixed address in RAM. The startup code (mostly assembler) can run from ROM (too).
However, this is possible if only startup code is in NOR flash.
The problem with the ARM implementation is that the link address is fixed, i. e. it cannot be adjusted to varying RAM sizes.
Usually one ports U-Boot on a board with predefined hardware layout, i.e. flash, SDRAM and peripherals are fixed. If hardware changes, say SDRAM size, no big deal to make two/three distinct u-boot images -- after all it ends up by changing TEXT_BASE only, as I understand.
Dear Roman,
In message 40a670230810070536w5ab3251cm39b1a4ebd199e14a@mail.gmail.com you wrote:
On ARM it's being done wrong - no real relocation is preformed;
What do you mean by "real relocation"? As per start.S bootcode is copied from ROM to RAM.
Copied to a fixed address where it is actiually already linked for. See my previous message with a lenghty explanation why this is a poor design when dealing with variable sized memory.
The problem with the ARM implementation is that the link address is fixed, i. e. it cannot be adjusted to varying RAM sizes.
Usually one ports U-Boot on a board with predefined hardware layout, i.e. flash, SDRAM and peripherals are fixed. If hardware changes, say SDRAM size, no big deal to make two/three distinct u-boot images -- after all it ends up by changing TEXT_BASE only, as I understand.
This may be your opinion, but it is an isolated one and not shared by *many* board vendors who offer different configurations of boards with smaller and bigger amounts of RAM etc. For these, having only a single binary image of U-Boot for all board configurations is a MAJOR win. Also consider systems which use memory modules.
Just try to imagine you have to install a new version of the BIOS on your PC just because you add or remove a memory module. Would you buy such a PC?
Best regards,
Wolfgang Denk
Hello
2008/10/7 Wolfgang Denk wd@denx.de:
The advantage of the PowerPC implementation with relocation is that we can measure the actual size of memory present on the board, and then relocate U-Boot to the very end of the RAM, leaving nearly th
When you say "end of the RAM', I think you mean higher addresses, i.e. 0xffff_ffff downwards or lower 0x000_0000 onwards? (this depends on how to look at memory map, written on a sheet of paper -- straight or upside down :-) ).
So the bottom line of PPC architecture is that it tries to have unified booting/relocation process for every platform? For instance, always copy itself in the upper addresses, occupying, say, 128kB or so of RAM.
whole RAM usable as one big contiguous area for "applications" like loading Linux kernel, ramdisk, etc.
[skip]
Just try to imagine you have to install a new version of the BIOS on your PC just because you add or remove a memory module. Would you buy such a PC?
Well, you convinced me; but despite its flaws and drawbacks the current ARM port architecture exists and it is here to stay for quite awhile, unless there will be some hero ready to break it up and build a new from scratch.
participants (5)
-
Andrew Dyer -
Hebbar -
Roman Mashak -
sahar mustafa -
Wolfgang Denk