In message 200711060631.12189.sr@denx.de you wrote:
-#define CFG_MALLOC_LEN (CFG_ENV_SIZE + 128*1024) +#define CFG_MALLOC_LEN (128*1024)
...
see why this change would be needed. If there is a compi8le problem, the reason for that problem should be located and fixed, without changing this code.
...
Well ARM assembly only accepts immediate values with certain properties (representable as an 8-bit value plus a 5-bit shift or something, I forgot the details). My ARM assembly skills
My gut feeling is that this is not the root of the problem. I feel that probably the assembler does not see a pure numerical expression, but instead is confronted with the (unsubstituted) string literal CFG_ENV_SIZE, and that this is causing the problem.
This is what I think needs to be checked and fixed, as the same problem might be present (eventually undetected) somewhere else, too.
are pretty weak, so changing start.S to accept an arbitrary constant is out of scope for me. We could maybe just set CFG_MALLOC_LEN to 132*1024 (untested), or we could move the CFG_MALLOC_LEN down in the file next to the
Please try out if "(132*1024)" works... that would give a some helpful additional information.
#ifdef CONFIG_KB9202 #define CFG_ENV_OFFSET 0x3E00 #define CFG_ENV_SIZE 0x0200
This is broken. 512 bytes of environmnt is much too small to be useful.
#define CFG_MALLOC_LEN (CFG_ENV_SIZE + 128*1024 + 0x4e00)
This is broken,too. Where is the 0x4e00 coming from here?
#else #define CFG_ENV_OFFSET 0x1000 #define CFG_ENV_SIZE 0x1000 #define CFG_MALLOC_LEN (CFG_ENV_SIZE + 128*1024 + 0x3000)
Where is the 0x3000 coming from here?
Why not just increasing. It's normally no problem having bigger malloc area:
#define CFG_MALLOC_LEN (256*1024)
If this works, then it is another indication that there is a preprocessing problem. This problem should be fixed and not hidden.
Best regards,
Wolfgang Denk