Iris runs from SD card

Bas Wijnen wijnen at debian.org
Mon Jul 12 08:50:54 EDT 2010


Hi,

Thanks for trying all this!

On Mon, Jul 12, 2010 at 05:51:18PM +0800, Xiangfu Liu wrote:
> Hi Bas.
>
> I want try UDC boot first. so I can the remove the comment of UDC_BOOT = set.
> then I compile again.

> here is the steps I tried in my computer:
> 1. sudo make setup
>   then it open two terminal. one for serial. another is for usbserver.
> 2. make CROSS=mipsel-openwrt-linux- test
>   the nanonote screen goto black. then nanonote justreboot.

That is all correct.  The reason for the reboot is that there is a
kernel panic.  It reboots on panic, so that I don't need to power-cycle
it.  I have the usbboot pins soldered together, so rebooting puts it
back into a usable state for testing.

Anyway, the serial output shows the reason for the panic.  By the way,
you are missing some characters in the serial output.  On my system, I
always see everything it sends.  Are you sure your serial connection is
working well? (this doesn't make it panic, but it makes the output
slightly harder to read.)

> attach is the serial and usbserver message.

I'm quoting the panic message (and a bit before it) from the serial log:

> found device; size = 000f1f00 * 00000200 = 1e3e0000

So your card is 500 MB (0x1e3e0000 B), with 512 B blocks.

> running partition
> (created thread 81f3dea4)

The program "partition" is started, which handles a partitioned device.
It prints the partitions it detects.

> Partition read: 00000081+000f1e7f

The first partition contains the entire device (except the first 0x81
sectors, which are not used).

> running fat
> Partit000000+00000000
> (created thread 81f36ea4)
> Partition read: 00000000+00000000
> Partition read: 00000000+00000000

And the other partitions are empty.  Very good.  Through it, fat is
started, which is responsible for reading the file system.  It has id
81f36ea4.

> warning: limiting clusters because of limited sector count

This should not happen.  It means that the fat claims that there are
more clusters than can fit on the device.  This can happen with an
improperly formatted card, but much more likely is a bug in the driver.

> raise ff:81f36ea4/unmapped write/00416000

Which leads to process 81f36ea4 (looking back, that's "fat") trying to
write to a page that isn't mapped in its address space, at 0x416000 to
be exact.  I'm not sure what is there, but it doesn't really matter: the
problem is earlier, in the cluster parsing code.

To find out more about it, I suggest adding some more debugging info.
In source/fat.ccp, look up "limiting clusters" (line 189) and print out
some extra numbers:
	kdebug ("sectors: ")
	kdebug_num (sectors)
	kdebug ("\n")
Inside the if, just before sectors gets a new value.
(Yes, a printf-style version would be nice, but it doesn't bother me
enough to make me implement it. ;-))

> BadVAddr: 00416000; PC: 00404770; epc: 00404770
> Panic: caller = ff:81f36ea4 at 00404770

Here you can see the current PC.  If epc is not (almost) equal to it,
but >= 0x80000000, the detected exception is in the kernel itself, and
all data about the process is irrelevant.  But in this case they're
equal, so it is in the driver.

To see where the problem occurs, you can use "objdump -S fs/fat.elf" and
search for the address.  You get disassembly and source code intermixed
with it.  However, it only works if you didn't strip the executable, so
you need to comment out the $(OBJCOPY) line from the fs/%.elf target in
the makefile.

The rest of the pannic message is almost only useful
when debugging the kernel itself.

> registers: sp=7ffffb40 at=00000000
> v=0000ffff 0000ff00
> a=00000008 00015004 00000002 00000002 
> t=0000ffff ffffffff 0000001f 0000001c 00000000 00000000 00000000 00000000 00000000 00400850 
> s=00416000 00000000 00000000 7ffffd8c 00410000 00000001 00000010 0000000c 
> gp=0041d530 fp=00000020 ra=00404770
> hi=00000000 lo=00000000
> k=00000000 00000000ead::raise(unsigned int, unsigned int):71: raise/00000003; debug: 00000001:00000000
> debug buffer (most recently pushe
>  81f3dea4 00400b38 81fe0ea4 00400b38
>  81f3dea4 00400b38 81f36ea4 00400b38
>  81f3dea4 00400b38 81f36ea4 00400b38
>  81f3dea4 00400b384 00400b38
>  81f3dea4 00400b38 81f36ea4 00400b38
>  81f3dea4 00400b38 81ff8ea4 00400b38
>  81f93ea4 00400b38 81ff8ea
>  81f3dea4 00400b38 81f36ea4 00400b38
> Attempt to print *pc:
> 00404730 ==> 8e700084 00452821 02602021 24060004
> 00404740 ==> 0c100bbd 02128021 08101167 ae020000
> 00404750 ==> 8e8255b8 8e700084 00052840 00452821
>  ==> 02602021 24060002 0c100bbd 02128021
> 00404770 ==> 08101167 ae020000 8e630084 00721821
> 00404780 ==> 8c620000 30420fff 08101167 ac620000
> 00404790 ==> 3403ffff 10430005 3403fff7 1043ffc0
> 004047a0 ==> 2442fffd ac820000 2402ffff
> 004047b0 ==> 08101153 ac820000 3c050040 00002021
> 004047c0 ==> 0c10039c 24a55288 08101153 00000000
> 004047d0 ==> 8e660008 27a4002c 00c23004 0c10029c
> 004047e0 ==> 00003821 8ea655ac 8fa4002c 8fa50030

Thanks,
Bas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.en.qi-hardware.com/pipermail/discussion/attachments/20100712/08c8c8e5/attachment.pgp>


More information about the discussion mailing list


interactive