thanks for commenting
Since my APPRAMBASE in umon is 0xa0300000, I have changed my parametes in a
way that the kernel would be loaded above that address:
unfortunately, the problem persists, i.e., the systems hangs just after the
zImage: size=680372 base=0xa0300000
loaded at: A0300000 A03A4000
zimage at: A0306180 A03A3EE1
Uncompressing Linux at load address B0000000
I am pretty sure that the problem relates to where the things are loaded, but
I don't realize exactly what.
On Monday 11 September 2006 15:55, you wrote:
> I had faced similar issue with AU1100 based boards which also use the
> zImage patch. It turned out to be board initialization issue rather that
> a zImage problem, since after uncompressing the image control is
> transferred to kernel_entry.
> -----Original Message-----
> From: firstname.lastname@example.org
> [mailto:email@example.com] On Behalf Of Carlos Mitidieri
> Sent: Monday, September 11, 2006 7:00 PM
> To: firstname.lastname@example.org
> Subject: "Uncompressing Linux at load address"
> I am trying to boot a zImage from micromonitor on a csb655 board
> (Au1550 processor).
> For that matter, I patched my kernel 2.6.15 with the zImage_2_6_10.patch
> In the arch/mips/boot/compressed/au1xxx/Makefile, I have set:
> 1) RAM_RUN_ADDR=0xa0300000, which is the value got from the
> APPRAMBASE environment variable.
> 2) AVAIL_RAM_START=0x80500000
> 3) LOADADDR =0x80100000, which is the same value I have set in
> entry for this board in arch/mips/Makefile.
> I can compile and link the zImage with home build gcc cross tools, based
> gcc-3.4.4 and glibc-2.3.4 . When the (binary) zImage is decompressed on
> target, I get these messages:
> zImage: size=680372 base=0xa0300000
> loaded at: A0300000 A03A4000
> zimage at: A0306180 A03A3EE1
> Uncompressing Linux at load address 80100000
> and then the target resets.
> This zImage is very small, so the decompressed image is not going beyond
> AVAIL_RAM limits. Would you have any guess on what is going on?
> I have looked for this information the list through, but anyone seems to
> had this problem before. Thanks for any comment.
SYSGO AG - Office Ulm
Tel: +49 731 94683 16
Fax: +49 731 94683 10
Meet us at our next event:
RTS Embedded Systems 2006
April 4-6, 2006
Paris, La Défense