[U-Boot-Users] tftpboot of BIG file fails !
Hi, I find a typical problem downloading a BIG ( 4MB) linux image to the SDRAM using u-boot's _tftpboot_ command. The Linux image is Linked at 0x20000. My u-boot is liked at 0x3e0000 (I understaood this from the following two macros) TEXT_BASE = 0x3E0000 CFG_MONITOR_BASE = 0x3E0000
On an anlysis, I figured out that, I can only download a image file of size (0X3E0000 - 0X20000 = less than 4MB) before I start overwriting the u-boot's code itself.
So I reconfigured the macros to link the u-boot on _top_ of the SDRAM (SDRAM map is 0x00000000 to 0x01000000)
TEXT_BASE = 0xFE0000 CFG_MONITOR_BASE = 0xFE0000
This should ensure that the _ftftp_ will download the 4MB image well within the u-boot code. But still I face the problem of not able to download the BIG image. Do I have to modify anything else to actually move the u-boot execution to 0XFE0000 ? Dows the tftp boot itself restrict the size of the file to be downloaded ?
Any clues in this regard. Thanks - - rupesh
In message 01a401c3e2a9$c29a0510$6706a8c0@Rupesh you wrote:
I find a typical problem downloading a BIG ( 4MB) linux image to the SDRAM
I don't think this is a typical problem. On contrary, it is a very UNtypical problem since this has always been working fine on many, many boards.
using u-boot's _tftpboot_ command. The Linux image is Linked at 0x20000.
Then your Linux image is broken. You must not change the kernel's link address unless you know exactly what you are doing. This means that for example on PowerPC the kernel will be linked for (virtual) address 0xC0000000 and started at (physical) address 0x00000000.
My u-boot is liked at 0x3e0000 (I understaood this from the following two macros) TEXT_BASE = 0x3E0000 CFG_MONITOR_BASE = 0x3E0000
Then your port of U-Boot is seriously broken.
I would like to point out that NONE of the configurations in the public source tree uses such a broken definition.
So I reconfigured the macros to link the u-boot on _top_ of the SDRAM (SDRAM map is 0x00000000 to 0x01000000)
A correctly configured U-Boot will automatically copy itself at the end of the RAM (at least on PPC).
But still I face the problem of not able to download the BIG image.
You probably have other problems in your port.
Dows the tftp boot itself restrict the size of the file to be downloaded ?
Yes. The current implementation puts a limit at 16 MB.
Best regards,
Wolfgang Denk
On Tuesday 27 January 2004 07:57, Wolfgang Denk wrote:
In message 01a401c3e2a9$c29a0510$6706a8c0@Rupesh you wrote:
I find a typical problem downloading a BIG ( 4MB) linux image to the SDRAM
I don't think this is a typical problem. On contrary, it is a very UNtypical problem since this has always been working fine on many, many boards.
using u-boot's _tftpboot_ command. The Linux image is Linked at 0x20000.
Then your Linux image is broken. You must not change the kernel's link address unless you know exactly what you are doing. This means that for example on PowerPC the kernel will be linked for (virtual) address 0xC0000000 and started at (physical) address 0x00000000.
Seems to be uClinux for Motorola Coldfire. Therefore it's ok.
My u-boot is liked at 0x3e0000 (I understaood this from the following two macros) TEXT_BASE = 0x3E0000 CFG_MONITOR_BASE = 0x3E0000
Then your port of U-Boot is seriously broken.
I would like to point out that NONE of the configurations in the public source tree uses such a broken definition.
In the current Coldfire 5272 port u-boot will be loaded to 0x3e0000 by colilo and started there.
So I reconfigured the macros to link the u-boot on _top_ of the SDRAM (SDRAM map is 0x00000000 to 0x01000000)
A correctly configured U-Boot will automatically copy itself at the end of the RAM (at least on PPC).
Yes, in my new 5272 port u-boot relocates itself to the end of RAM.
But still I face the problem of not able to download the BIG image.
You probably have other problems in your port.
Dows the tftp boot itself restrict the size of the file to be downloaded ?
Yes. The current implementation puts a limit at 16 MB.
Best regards,
Wolfgang Denk
Best regards,
Josef Baumgartner
participants (3)
-
Josef Baumgartner -
Rupesh S -
Wolfgang Denk