Stefan Roese wrote:
On Thursday 27 March 2008, Bartlomiej Sieka wrote:
## Booting kernel from Legacy Image at 00200000 ... Image Name: Linux-2.6.25-rc7-next-20080327-d Created: 2008-03-27 13:51:18 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 1288643 Bytes = 1.2 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ERROR: image overwritten - must RESET the board to recover.
<snip>
Any ideas?
The image got overwritten during decompression. Try loading the image at a higher address.
Right. This works. But I'm wondering why this is the case, since "old" U-Boot can decompress to this destination successfully. This is quite annoying, since now I have to change all default env variables for this new "legacy" bootm command. So do you have any idea where the difference comes from?
Hi Stefan,
It's because we assume that if the image got overwritten, its contents can't be trusted anymore, and abort booting. "Old" U-Boot didn't care about overwrites, which sometimes worked out OK, and sometimes didn't, the latter case resulting in nasty failure modes.
The overwrite issue is particularly acute in case of the new image format. Image is based on FDT and is being accessed via libfdt functions, so if it gets overwritten, there's little point in processing it further. But even with images in old format, this issue has been brought up on this list, and there's been proposals to add safeguards. So since overwrite checking was rather necessary for the new format, and desired for the old one, it got added.
There's also a technical reason why the overwrite check is active even when CONFIG_FIT is not defined. To minimize code size increase when adding new format, a lot of boot-related code has been re-factored. In particular, the decompression (and the check for the overwrite) is handled by code common to new and old formats, and hence the check is performed in both cases.
Regards, Bartlomiej