<br><font size=2 face="sans-serif">Well</font>
<br><font size=2 face="sans-serif"> I'm not complaining about what's happening and several bells have been ringing.-) I'm merely asking for some clarification, corroboration.</font>
<br>
<br><font size=2 face="sans-serif"> No I did not try to figure out what happens when U-Boot compresses the kernel image.</font>
<br><font size=2 face="sans-serif"> I did not try a higher load address for the kernel. I shall do so and see what happens.</font>
<br>
<br><font size=2 face="sans-serif"> Finally in our setting it is not okay if the ram-disk load address is 3MB, 4MB, 5MB, 6MB or 7MB. It works only when it is 8MB and above. Hence my question.</font>
<br>
<br><font size=2 face="sans-serif">I'll make sure that the ram-disk is loaded at a much higher address but what about the 7-8MB corruption. Is there anything in it?</font>
<br>
<br><font size=2 face="sans-serif">Thanks</font>
<br>
<br><font size=2 face="sans-serif">Sadanand</font>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td>
<td><font size=1 face="sans-serif"><b>Wolfgang Denk <wd@denx.de></b></font>
<br><font size=1 face="sans-serif">Sent by: wd@denx.de</font>
<p><font size=1 face="sans-serif">02/28/2005 03:10 PM</font>
<br>
<td><font size=1 face="Arial"> </font>
<br><font size=1 face="sans-serif"> To: warrier@optovia.com</font>
<br><font size=1 face="sans-serif"> cc: u-boot-users@lists.sourceforge.net</font>
<br><font size=1 face="sans-serif"> Subject: Re: [U-Boot-Users] Verifying checksum problems.</font></table>
<br>
<br>
<br><font size=2 face="Courier New">In message <OFC0BE6659.AF54EF2D-ON85256FB6.006C6C07-85256FB6.006DD828@optovia.com> you wrote:<br>
><br>
> We load our kernel at 1 MB. We load our associated ram-disk at 2MB. This <br>
> ram-disk is currently 6.2MB compressed. <br>
<br>
Why are you doing this? Did you check how big your _uncompressed_<br>
images will be? Did you try to try to figure out what happens when<br>
U-Boot actually uncompresses the kernel image?<br>
<br>
> However since the increase in the size of the ram-disk we have encountered<br>
> the following error. After the kernel and ram disk are loaded to their <br>
> respective locations and we use<br>
> "bootm 100000 200000" , this is what happens.<br>
<br>
And this doesn't ring a bell to you? Did you try out higher load<br>
addresses, like 0x200000 for the kernel and 0x400000 for the ramdisk<br>
image?<br>
<br>
> The checksum is verified for the kernel and it is decompressed and <br>
> everything is fine. <br>
> It however fails in the ram-disk checksum verification. We get a checksum <br>
> error.<br>
<br>
> However if we move the ramdisk load address to an area above 8MB everthing > <br>
> works fine. If we load it at 7MB we see the same error. <br>
<br>
Well - what are you complaining about then? Isn't it obvious that the<br>
Linux kernel, when being uncompressed, overwrites your ramdisk image<br>
which was loaded at a too low address?<br>
<br>
> Since our earlier ram-disk at 5.8 MB worked we surmise that something is <br>
> corrupting the area between 7.8MB and 8MB. Following the sequence of <br>
<br>
I don't think so.<br>
<br>
> Is by any chance this area being used or is there some other explanation? <br>
<br>
Yes: it's a user error - using a too low load address.<br>
<br>
> As I said earlier if the ram-disk is loaded at 8MB or above everything is <br>
> currently okay.<br>
<br>
I bet it's also OK if you load it at 3 or 4 MB.<br>
<br>
Best regards,<br>
<br>
Wolfgang Denk<br>
<br>
-- <br>
Software Engineering: Embedded and Realtime Systems, Embedded Linux<br>
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de<br>
Objects in mirror are closer than they appear.<br>
</font>
<br>
<br>