I don't know anything about your system or CPU so this is likely of little value. That said, the contents of memory are potentially different when you do an external reset (after running code, flashing, etc.) than they are on power-up. It could be that your kernel only boots when the contents of memory are in a certain state and you can never get them to be in that state after power-on. I don't know how much control you have over specifying the image size and RAM load address but if the compressed image size is wrong or the initial RAM load address overlaps the uncompressed address, depending on the code that decompresses and copies it, the act of decompressing and copying it can either fail to complete or actually trash the compressed image (if it is in RAM). This has happened to me when I specified the wrong uncompressed image size.

Also, some processors can distinguish between an external reset and a power-on reset and execute different code based on that determination so check into your bootloader to see it intentionally does anything different and you might find a clue.

That's all I can think of. Good luck.

hi john,

thx for your reply and your wishes - they seemed to work <!-- s;-) --><!-- s;-) -->

Well, we already had the same idea, because the elf file defines the memory areas to clear - and the elf version works.
We tried some traces this morning - but without success. dbug and linux are both modifying A7 (sp) and crash the system.

So we just went through the dbug code and watched for differences between elf and bin version load and had an idea.
The dbug decompresses the kernel image to RAM. So we assume this area to be well defined and the problem to be just behind the kernel.

Some zeros behind the kernelimage won't really size up the zipped image, so we did a

just to zero the next 4 MB behind the kernel but not to touch the stack (16 MB RAM).

And, well, this hack works <!-- s;-) --><!-- s;-) -->

thx

Glad to hear it!