On Mon, Jun 03, 2013 at 03:37:39PM -0700, Stephen Boyd wrote:
> On 06/03/13 15:23, Russell King - ARM Linux wrote:
> > On Mon, Jun 03, 2013 at 02:13:39PM -0700, Stephen Boyd wrote:
> >> We
> >> can't get any information about why the decompression failed if
> >> we have debug_ll enabled. I had to patch the error() routine to
> >> not while loop forever to get that print after do_decompress to
> >> be useful.)
> > Maybe your implementation of puts() for the decompressor is faulty then?
> > Because it works for me - when something goes wrong with the decompression,
> > I get a message such as:
> >
> > Decompressing kernel...
> >
> > CRC error
> >
> > -- System halted
> >
>
> I was expecting to see
>
> Decompressing kernel...
>
> CRC error
>
> decompressor returned an error
>
>
> but since we loop forever this code in arch/arm/boot/compressed/misc.c
> doesn't do anything:
>
> if (ret)
> error("decompressor returned an error");
I think that's just a final catch-all in case one of the decompressors
doesn't use the error() function pointer it was passed.
> In my case I'm booting a kernel with textoffset = 0x208000 but RAM
> starts at 0x0. Does "minimum of RAM start" mean 0x0 or 0x200000?
The basic requirement for zImage's is no less than the start of RAM
plus 32K. Or let me put it another way - start of writable memory
plus 32K.
Whether you need an offset of 0x200000 or not is not for the
decompressor to know. If you're having to avoid the first 0x200000
bytes of memory for some reason (eg, secure firmware or DSP needs
it left free) then there's no way for the decompressor to know that,
so it's irrelevant.
So, lets say that your platform has a DSP which needs the first 0x200000
bytes left free. So the boot loader _already_ needs to know to load
the image not at zero, but above 0x200000. The additional 32K
requirement is really nothing new and so should be treated in just the
same way.
Leave at least 32K of usable memory below the zImage at all times.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
