Re: [ECOS] Re: Problem on allocate PCI memory space...

[Nick Garnett <nickg at cygnus dot co dot uk>]

"Ling Su" <lingsu@palmmicro.com> writes:

> Nick wrote,
> > >
> > > If you take a look at the registers and the specific instruction that
> > > the exception occured on you should be able to work out exactly what
> > > address it was trying to access, and the value in the cause register
> > > should tell you what exception it actually was. If it's a TLB
> > > exception then maybe the MMU setup needs changing, if its
> > > a bus exception then the problem lies in the hardware setup.
> > >
> 
> Ling Su wrote,
> >
> > I checked the "cause" register, the value is 0x800C, which means the TLB
> > Miss Exception(store) occurs. I dobut if I only change the NUMB_PG to 16
> the
> > TLB will be enough to handle 512MB space, could you please take a look at
> > the TLB part. I will also check this by myself.
> >
> 
> Dear Nick and Jifl,
> 
> After carefully checking the result of my pci test program, I am pretty sure
> the Segmentation Fault is caused by TLB setup problem, but I still didn't
> find the point why TLB can not map address above 0x8FFF_FFFF. I have several
> small questions here,
> 
> <1>. What is the meaning of NUMB_PG, what is relationship to TLBENTRIES
> (32)?

NUMB_PG is just the number of pairs of 16Mb pages that the code is
going to set up. As long as it is less than TLBENTRIES, there should
be no problem.

> <2>. I want to trace the TLB inistialization part code, unfortunately I
> found I can not set breakpoint in the hal_mmu_setup Macro, I tried the
> hal_mmu_init in Vector.S, it doesn't work as well. There is a _start funtion
> in vector.S, it calls hal_cpu_init, hal_diag_init, hal_mmu_init.... etc... I
> can set a breakpoint on hal_cpu_init, but I can not set anything on the next
> line, hal_diag_init and hal_mmu_init. I don't quite understand this, where I
> can setup a break point for the MMU setup routine, so that I can step by
> step go through the procedure? Could you please drop me a hint?

Setting breakpoints on the initialization code may not work very
well. This code is busy changing the state of the CPU in ways that
normal code does not. This can confuse the GDB stubs or GDB itself.

Actually, I think I've just worked out what the problem may be. The MMU
setup code is not included at all in RAM startup executables, it is
only present in the ROM monitor.

So the solution is either to make the change to NUMB_PG and build a
new stub ROM, or change the ifdefs around hal_mmu_init in platform.inc
and hal_mmu_setup in platform.S to cause the code to be included in a
RAM startup configuration.

> <3>. Should I use STATIC MMU table? Will it bring any diffrence? Actually I
> did try it, result is the same, just curious.
> 

I'm not sure what you mean here.


-- 
Nick Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK