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

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

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

> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x80100bb8 in pci_test () at pcitest.c:293
> > > 293     (*(pci_base + 0x004)) = 0x0000;
> > >
> > > Dump of assembler code from 0x80100ba6 to 0x80100bff:
> > > 0x80100ba6 <pci_test+682>: daddiu $a0,$a0,-8908
> > > 0x80100baa <pci_test+686>: jal 0x8010522c <diag_printf>
> > > 0x80100bae <pci_test+690>: lw $a1,156($s8)
> > > 0x80100bb2 <pci_test+694>: lw $v0,156($s8)
> > > 0x80100bb6 <pci_test+698>: addiu $v0,$v0,4
> > > 0x80100bba <pci_test+702>: sb $zero,0($v0)
> >
> > I would guess that this sb is the problem instruction. One thought is
> > that the device is not happy with byte sized accesses. Maybe you need
> > to do 16 bit or 32 bit accesses. This is certainly true of the
> > configuration space.
> >
> 
> I tried to access 32bit access, the result is the same. So this won't be the
> problem.
> 
> > See my previous message about how to determine whether this is a TLB
> > or an device problem.
> >
> > 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.
> >
> 
> 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.
> 
> Could you please explain the implementation of TLB in eCos a little bit for
> me? Thanks!
> 

To be honest I know very little about the TLB or the code to set it
up. That was all taken from the PMON sources and fortunately worked as
it was.

As far as I can see, in its default state it is setting up 16 16Mb
pages in the TLB. Starting at 0x80000000 physical and mapping them to
0xC0000000 virtual.

I cannot see any reason why simply increasing NUMB_PG would not work,
assuming that the TLB has >8 entry pairs. None of the constants seem
to be dependant on the value of NUMB_PG. 

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