| Author |
Message |
|
|
 Posted: Nov 09, 2010 - 10:37 AM |
|
Joined: Sep 23, 2005
Posts: 387
Location: UK
|
|
All of a sudden I can't run the kernels I build!!!
I've no idea what I've done - the kernel size has jumped from 1.2M to 1.4M though
Is it possible I've run out of space to load the compressed image or store the uncompressed one?
I've never quite understood the significance of the 10200000 and 10400000 numbers used by boot - can someone inform my ignorance, or suggest another reason why I sudden get no output after
Starting kernel at 90000000 (params at 11f6e008)...
TVM
David |
|
|
| |
|
|
|
|
|
|
Posted: Nov 09, 2010 - 11:32 AM |
|
Joined: Jan 07, 2003
Posts: 4580
Location: Oslo, Norway
|
|
|
Quote:
I've never quite understood the significance of the 10200000 and 10400000 numbers used by boot - can someone inform my ignorance, or suggest another reason why I sudden get no output after
You didn't understand why loading at a different address might solve the issue when the kernel starts growing? 
The kernel loads to the address you refer to above, then it extracts to address 0x10000000. If there is not enough room between 0x10000000 and your load address, then you will corrupt the contents at your load address while extracting the kernel.
Adjust your load address to 0x10400000 and you should have enough room. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 09, 2010 - 12:06 PM |
|
Joined: Sep 23, 2005
Posts: 387
Location: UK
|
|
doesn't fix it even if I stick the kernel in parallel flash.
Oh what on earth have I done .... 200k bigger and not working - it must be SOMETHING I've changed
D |
|
|
| |
|
|
|
|
|
|
Posted: Nov 09, 2010 - 12:19 PM |
|
Joined: Jan 07, 2003
Posts: 4580
Location: Oslo, Norway
|
|
|
dexdynedgc wrote:
doesn't fix it even if I stick the kernel in parallel flash.
Oh what on earth have I done .... 200k bigger and not working - it must be SOMETHING I've changed
Could you paste the output from U-Boot when trying to load the kernel?
Have you tried restarting by cleaning your kernel tree, and load a *_defconfig?
100% sure you got the correct prefix to your avr32-linux-* toolchain? Also, are you using the avr32-linux-* toolchain generated by Buildroot for AVR32? If not, I highly recommend to switch to that, as this fixes quite some compiler bugs. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 09, 2010 - 03:39 PM |
|
Joined: Sep 23, 2005
Posts: 387
Location: UK
|
|
good lord - somehow I had picked up a corrupt/ancient .config file....
So a simple question does 1040 mean "space for a 4M kernel once decompressed"?
D |
|
|
| |
|
|
|
|
|
|
Posted: Nov 09, 2010 - 04:51 PM |
|
Joined: Jan 07, 2003
Posts: 4580
Location: Oslo, Norway
|
|
|
Quote:
So a simple question does 1040 mean "space for a 4M kernel once decompressed"?
Correct. The SDRAM starts at address 0x10000000, and you have to have enough space from the beginning to the address you load the compressed kernel. Strait forward simple kernels are typically well below 2 MB in size uncompressed, hence the default 0x10200000 load address in U-Boot. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 10, 2010 - 11:56 AM |
|
Joined: Sep 23, 2005
Posts: 387
Location: UK
|
|
OK - sorted now - I have no idea what happened but all of a sudden my .config file was one for an STK100n board.
and I've found a comment which says that1040 means "allow for a 4M kernel" so I believed it once and I guess it's still true. |
|
|
| |
|
|
|
|
|
|
Posted: Nov 10, 2010 - 12:57 PM |
|
Joined: Jan 07, 2003
Posts: 4580
Location: Oslo, Norway
|
|
|
Quote:
and I've found a comment which says that1040 means "allow for a 4M kernel" so I believed it once and I guess it's still true.
Correct, if you mean 1040 actually means 0x10400000 load address for the compressed kernel. That leave 0x400000 bytes (4 MB) space for the uncompressed kernel. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
