[Arm-netbook] microSD breakout board, suitable for debugging using tablets.

[lkcl luke]

2012/2/13 Alejandro Martínez <zen at itram.es>:
> On Mon, Feb 13, 2012 at 4:16 PM, lkcl luke <luke.leighton at gmail.com> wrote:
>>  so wait - forget mali, does the LCD module work?
>>
>>  you need to be much more explicit.  you can load the lcd module (and
>> you tested that independently) and then you load mali and that's where
>> the freeze occurs?
>>
>>  it's really important to narrow things down like this.
>>
>
> If I remember well, loading disp.ko and lcd.ko made the LCD turn on
> (black), but then the kernel freezes when writing to /dev/fb0.

 'd be good to get an accurate diagnosis, eh? :)

> Loading mali and its dependencies from the init.rc, I was able to
> write to fb0 but then it froze after some seconds.

 ok that sounds like there's a proper fun-fun-fun bug for allwinner to
investigate, there.

 "freeze" isn't really particularly helpful, it tells you pretty much
zilch - can you get the kernel messages out onto the serial console,
and if so is there anything on it? (stop running klogd if you have
to).  you shouldn't need to use the jtag thingy for this, although it
would make life a lot easier if you could.

 btw, things to try:

 * write a *small* amount of data to /dev/fb0 and see what happens
 * repeatedly write small amounts of data (with delays in between)
 * load the lcd modules and just... wait.
 * boot up, leave it running for a long time period, _then_ load the lcd modules

 what you're looking to determine is: is the instability _actually_
anything to do with the lcd module(s).  try the same trick with
disp.ko and lcd.ko (suitable delays)

 you want the smallest set of changes which do and do not give the
crash not-crash.  mali is therefore irrelevant right now because
you've determined that there is a crash even without mali, so forget
mali: the venn diagram of the test / diagnosis matrix already excludes
it.

 basically: what's the _absolute_ minimalist venn diagram you can come up with?

 l.