Hi Erwin,
My problem is the same as in...
http://mailman.uclinux.org/pipermail/uclinux-dev/2003-October/021990.html
... but using an AT91. I simulate until reaching __wake_up() and I
view that the passed pointer to __wake_up() from down_trylock() is a NULL
pointer. The micro captures the value from 0x00000000 as the semaphore
pointer and the data abort occurs when it tries to check it. I've also tried
what Greg said to LuoHao but nothing changed. What can I do?. What should I
configure at the cmdline? Hardcoded or passed by the bootloader?. I'm
starting to feel a little bit depressed :,,,-(. Tomorrow I'll try with the
at_91 debug functions. Could it be an initialization problem? Maybe a serial
console initialization problem?....
Thank you very much in advance.
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
En nombre de Erwin Authried
Enviado el: viernes, 16 de febrero de 2007 14:16
Para: uClinux development list
Asunto: RE: [uClinux-dev] uClinux on AT91 (Simulated Data abort in
__wake_up)
Am Freitag, den 16.02.2007, 13:37 +0100 schrieb rflores:
> Hi,
>
> I can simulate the uClinux image.bin in Keil Software Environment,
> the disassembled code in the last mail is from this environment.
>
> In the Makefile of the linker The TEXTADDR is fixed at 0x02024000,
>
> In the make menuconfig the RAM is fixed at 0x02200000 with length of
> 0x400000 and the flash is fixed at 0x01010000 with length of 0x190000
> (reserved 0x10000 for bootloader 0x01000000-0x1010000).
>
> In my board the result is the same as the one of my simulation.
>
> The kernel crashes at __wake_up function, at the addresses
>
> Data Abort: ARM Instruction at 022165B0H, Memory Access at E59FF014H
> Data Abort: ARM Instruction at 02216630H, Memory Access at E59FF018H
>
> Where is the source code of __wake_up ????
>
> In this instruction the first time R4 points to 0x0000000 reset
> vector and in the second time R4 contains the instruction located
at R0,
> and crashes because tries to access at address E59FF014 but this is code
> instruction.
>
> 0x022165B0 E5140004 LDR R0,[R4,#-0x0004]
>
> The other data abort is a similar case.
>
> Any idea? I'm very very blocked in this point.
>
> Thanks
do you see any output of printk? If the printk output isn't working for
some reason, you can try to use the functions in
arch/armnommu/kernel/debug.c to write messages into a reserved memory
space, and read that out later by JTAG. You can reduce your memory size
to make space at the top of ram, so that you use as a buffer. Although
it's a very rude hack, it can be incredibly helpful until the serial
console is working. You have to call at91_debug_init() first. You can
put at91_debug_putn(...) into the printk function so that the whole
printk output is placed into the memory buffer, or place
at91_debug_str(..) calls into the source.
Regards,
Erwin
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
