一个关于__create_page_tables出问题的邮件

problems with __create_page_tables in arch/arm/kernel/head.S

Am Freitag, 7. Oktober 2005 21:23 schrieb Russell King - ARM Linux:
> On Fri, Oct 07, 2005 at 01:39:52PM +0200, Juergen Schindele wrote:
> > Hello guys,
> > I have a problem booting the kernel when
> > the part surounded with CONFIG_DEBUG_LL
> > in "__create_page_tables" is not enabled!
> > If this is not enabled the kernel is NOT BOOTING
> > (BDI shows
> >        Current PC        : 0xffff000c
> >     Current CPSR      : 0x800000d7 (Abort)
> > ) which seems to be an abort/fault vector.
> >
> > My problem is i dont know exactly what this code is doing
> > and i have a special memory mapping adviced from Nicolas Pitre
> > (see http://lists.arm.linux.org.uk/pipermail/
> > linux-arm-kernel/2005-July/030457.html)
> >
> > TEXTADDR is 0x80008000 !
> > and I use the BTUART (0x40200000)
> > as console on startup.
> > My kernel version is 2.6.12
> > with patches from Nicolas Pitre and Bill Gatliff
> >
> > What is the clean way to solve this problem ??
>
> No idea.  There's no way to tell what's going on from your message.
> You say that there's an abort but you don't say which one.  So,
> looking it up, it seems to be the prefetch abort.
>
> This is odd because anything mapped by the debug mappings should not
> be executed.
>
> > Is there an other problem which is not fixed ??
>
> No idea.  Maybe the problem is related to your debugger.  What happens
> if you don't use the debugger?

The helping hint came from Junjie Cai who told me that in "fixup" the memory
map was already used. I found in my machine_fixup a "pxa_gpio_mode()" which
is very bad here. I moved that code to machine_init and all is fine.
Thanks for your help.
--------------------------------------------------------------
Jürgen Schindele            NENTEC Netzwerktechnologie GmbH
Entwicklung                 Greschbachstrasse 12
                           76229 Karlsruhe/Germany
eMail:schindele at nentec.de   Phone: +49(0)721 94249-<51>
Web:   www.nentec.de        Fax:   +49(0)721 94249-10
--------------------------------------------------------------
hi,
we had this similar problem before.
it was because that the mdesc->fixup was just
using the memory map created by DEBUG_LL .
and the peripheral meory map has not been created
before mdesc->map_io.

just for your information.
thanks.
On 10/7/05, Juergen Schindele <schindele at nentec.de> wrote: