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: AVAIL_RAM_START=0xb0a00000 AVAIL_RAM_END=0xb0f00000 LOADADDR =0xb0000000 unfortunately, the problem persists, i.e., the systems hangs just after the messages: 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. > > Thanks > Hemanth > > -----Original Message----- > From: linux-mips-bounce@xxxxxxxxxxxxxx > [mailto:linux-mips-bounce@xxxxxxxxxxxxxx] On Behalf Of Carlos Mitidieri > Sent: Monday, September 11, 2006 7:00 PM > To: linux-mips@xxxxxxxxxxxxxx > Subject: "Uncompressing Linux at load address" > > Hi, > > 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 > from > Popov. > > In the arch/mips/boot/compressed/au1xxx/Makefile, I have set: > 1) RAM_RUN_ADDR=0xa0300000, which is the value got from the > umon's > APPRAMBASE environment variable. > 2) AVAIL_RAM_START=0x80500000 > AVAIL_RAM_END=0x80900000 > 3) LOADADDR =0x80100000, which is the same value I have set in > an > entry for this board in arch/mips/Makefile. > > I can compile and link the zImage with home build gcc cross tools, based > on > gcc-3.4.4 and glibc-2.3.4 . When the (binary) zImage is decompressed on > the > 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 > the > 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 > have > had this problem before. Thanks for any comment. -- Carlos Mitidieri SYSGO AG - Office Ulm Lise-Meitner-Str. 15 D-89081 Ulm Tel: +49 731 94683 16 Fax: +49 731 94683 10 Web: www.sysgo.com Meet us at our next event: RTS Embedded Systems 2006 April 4-6, 2006 Paris, La Défense http://www.birp.com/rts
