Re: Re: hx2490 support?

On Wed, Jan 17, 2007 at 11:18:27PM +0000, Tvrtko A. Ursulin wrote:
> > Does this mean you've never had a stable Linux boot? If so, this
>
> Correct, it is exactly as I described it above.
>
> > raises the question of whether this is a haret issue or a linux kernel
> > issue. There is clearly a haret issue with looping on a non-closed
> > dma channel (which can probably be fixed by simply removing the loop).
> > However, this doesn't mean that the linux failure has anything to do
> > with DMA.
>
> It's definitely not a clear situation. The thing is I am using the same image
> which reportedly works flawlessly on HX2750 (which should be the same
> hardware as HX2490 just double amount of RAM). Pairing that with either old
> 0.3.6-2 haret or this latest one does not work for me. So yes, maybe it's
> Linux or maybe Haret, I currently don't have enough inside knowledge to tell.

I'd be careful before assuming the only difference is memory --
manufactures have been known to change the internal chips but keep the
external features the same.

> Disabling the loop which waits for DMA to complete looks suspicious to me -
> shouldn't we somehow fix the problem and not the symptoms?

This loop was added in the 0.4.x series - the old haret did not have
it. I think it is better to have the loop, but I'm not sure it is
strictly required. (The docs seem to imply only a single burst - max
32 bytes - could last past a dma channel shutdown.) Given that the
loop isn't correct in all cases, it looks like it will either have to
be removed or upgraded to full correctness.

>Couldn't the
> non-quiescent state of hardware confuse the kernel when it tries to boot?

If that were the case, I'd expect Linux to reliably boot whenever you
used to get past the green line. The fact that you're hanging after
Haret successfully shutdown all DMA implies something else is also an
issue.

> If it is Linux it would have to be very early in kernel initialisation, before
> it outputs anything to the serial console. Which would be slightly strange
> since it never got only halfway through kernel init. Either it doesn't output
> anything (those 99% percent of attempts) or it gets to the part where it
> tries to mount rootfs but fails to communicate with the SD card (crc errors
> on mmc bus). Only once ever it had passed that point and successfully mounted
> root, but the it hung a couple of seconds later.

You have a serial console? That is definitely where you should start
-- see include/asm-arm/arch-pxa/uncompress.h. There is code to write
to the serial port very early in the boot process. (And if it is not
using the correct UART, it can also hang the boot.)

> The next thing I was thinking about doing (when I find some free time) was
> printing out which DMA channel exactly is causing trouble and the looking up
> the PXA270 docs to see is it related to the mmc reader (something). Any
> comments usefullness of this approach?

You should be able to run:

pd 0x40000000 0x80

A bunch of times and see which dma channel is in a "not shutdown" state.

-Kevin
Received on Fri Jan 19 2007 - 20:01:59 EST