[ECOS] Fw: [ECOS] How to access PCI memory(HELP)....

[ECOS] Fw: [ECOS] How to access PCI memory(HELP)....

[Ling Su]

> Nick wrote,
> >
> > PCI_IOSPACE_BASE only maps PCI device IO registers, not memory
> > mappings. I don't believe we actually use any of these mappings, which
> > appear at 0x0C000000/0xAC000000 physical/logical addresses.
> >
> > We also use the master address windows. Window one is set up to map
> > the 4372 control registers at 0x1C000000 in PCI space to
> > 0x1C000000/0xBC000000 in the CPU. Window 2 maps 0x80000000 in PCI
> > space to 0x80000000 physical which the MMU remaps to 0xC0000000
> > logical. However, the 4372 also occupies the first 256Mb of this.
> >
> [Ling]
> You mean the south bridge chip also occupies 256MB space? Where I can find
> this information? I didn't quite understand the MMU inialization part now,
I
> have to read the vr4300 manual to catch it. I agree that the part on PCI
> address windows, you mean the first register is for mapping 4372
registers,
> so the second register windows set for memory space on PCI bus, right?
>
> > So, if my reading of the code and documentation is correct, then
> > HAL_PCI_PHYSICAL_MEMORY_BASE should be 0xD0000000, to skip the first
> > 256Mb, and HAL_PCI_ALLOC_BASE_MEMORY should be 0x90000000. You should
> > then be able to access PCI device memory from 0xD0000000.
> >
>
> Why need I set HAL_PCI_ALLOC_BASE_MEMORY to 0x90000000, originally it is
> 0x0, which means mapp the memory from the beginning, what is the rational
to
> add a 0x9000_0000 offset?
>
> > Of course currently the MMU only maps the first 256Mb of PCI space at
> > 0xC0000000, so the MMU mapping needs to be extended. The simplest way
> > to do this is to increase NUMB_PG in platform.S from 8 to 16. The
> > current code appears to only use 16 of the 32 TLB entries, so using
> > all 32 will give 512Mb of mapped PCI memory.
> >
> >
> > Ling Su, please give this a try and if it works we can put these
> > values into the standard sources.
> >
>
> Nick, I follow your suggestion, basically I changed three things,
> (1). HAL_PCI_PHYSICAL_MEMORY_BASE set to 0xD0000000
> (2). HAL_PCI_ALLOC_BASE_MEMORY set to 0x90000000
> (3). increase NUMB_PG to 16
>
> Unfortunately it doesn't work, I append the the log in the end of this
> message, what causes a SIGSEGV signal ususally?
>

Nick,

I think I understand what Nick means, because 0x8000_0000 maps to
0xC000_0000, I should use 0x9000_0000 mapping to 0xD000_0000. Acutally last
time, I made a mistake, I changed HAL_PCI_ALLOC_BASE_MEMORY to 0x0900_0000,
not 0x9000_0000. So the result is,
----------------------------------------------------------------------------
----------
BAR[0]    0x09000000 / probed size 0xFFF00000 / CPU addr 0xD9000000
----------------------------------------------------------------------------
----------

If I correct this mistake, I find
----------------------------------------------------------------------------
----------
BAR[0]    0x90000000 / probed size 0xFFF00000 / CPU addr 0x60000000
----------------------------------------------------------------------------
----------

The CPU address 0x6000_0000 is 0xD000_0000 + 0x9000_0000 = 0x6000_0000, so
there is a bug for "cyg_pci_allocate_memory_priv" in pci1.c,
    dev_info->base_map[bar] = (cyg_unit32)
(aligned_addr+HAL_PHYSICAL_MEMORY_BASE) &0xFFFFFFFF

where the aligned_addr = (*base+size-1) & ~(size - 1);

*base is set to HAL_PCI_ALLOC_BASE_MEMORY as default, if I set
HAL_PCI_ALLOC_BASE_MEMORY will be added on HAL_PHYSICAL_MEMORY_BASE for
base_map. so it is not what I supposed, is that any understanding problem? I
don't know what is the exact meaning for "HAL_PCI_ALLOC_BASE_MEMORY" and
"HAL_PHYSICAL_MEMORY_BASE ", if what I think is true, I will change
dev_info->base_map[bar] to
    (cyg_unit32) (aligned_addr + HAL_PHYSICAL_MEMORY_BASE -
HAL_PCI_ALLOC_BASE_MEMORY) &0xFFFFFFFF

Any suggestion, let me know, I will try this way first tomorrow.

Thanks,

-Ling

[ECOS] Re: Fw: [ECOS] How to access PCI memory(HELP)....

[Nick Garnett]

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

> Nick,
> 
> I think I understand what Nick means, because 0x8000_0000 maps to
> 0xC000_0000, I should use 0x9000_0000 mapping to 0xD000_0000. Acutally last
> time, I made a mistake, I changed HAL_PCI_ALLOC_BASE_MEMORY to 0x0900_0000,
> not 0x9000_0000. So the result is,
> ----------------------------------------------------------------------------
> ----------
> BAR[0]    0x09000000 / probed size 0xFFF00000 / CPU addr 0xD9000000
> ----------------------------------------------------------------------------
> ----------
> 
> If I correct this mistake, I find
> ----------------------------------------------------------------------------
> ----------
> BAR[0]    0x90000000 / probed size 0xFFF00000 / CPU addr 0x60000000
> ----------------------------------------------------------------------------
> ----------
> 
> The CPU address 0x6000_0000 is 0xD000_0000 + 0x9000_0000 = 0x6000_0000, so
> there is a bug for "cyg_pci_allocate_memory_priv" in pci1.c,
>     dev_info->base_map[bar] = (cyg_unit32)
> (aligned_addr+HAL_PHYSICAL_MEMORY_BASE) &0xFFFFFFFF
> 
> where the aligned_addr = (*base+size-1) & ~(size - 1);
> 
> *base is set to HAL_PCI_ALLOC_BASE_MEMORY as default, if I set
> HAL_PCI_ALLOC_BASE_MEMORY will be added on HAL_PHYSICAL_MEMORY_BASE for
> base_map. so it is not what I supposed, is that any understanding problem? I
> don't know what is the exact meaning for "HAL_PCI_ALLOC_BASE_MEMORY" and
> "HAL_PHYSICAL_MEMORY_BASE ", if what I think is true, I will change
> dev_info->base_map[bar] to
>     (cyg_unit32) (aligned_addr + HAL_PHYSICAL_MEMORY_BASE -
> HAL_PCI_ALLOC_BASE_MEMORY) &0xFFFFFFFF
>

Yes that might work. I'll have to think about it.


> Any suggestion, let me know, I will try this way first tomorrow.
> 

I responded to your previous message before I saw this one. As I said
there, I think that adjusting HAL_PHYSICAL_MEMORY_BASE so that the CPU
addr ends up at 0xD000_0000 will fix your problem.

I guess HAL_PHYSICAL_MEMORY_BASE is probably misnamed, it should
really be HAL_PHYSICAL_MEMORY_OFFSET. It only works as a base when the
PCI memory allocation starts at zero.

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

Re: [ECOS] How to access PCI memory(HELP)....

[Ling Su]

>
> I responded to your previous message before I saw this one. As I said
> there, I think that adjusting HAL_PHYSICAL_MEMORY_BASE so that the CPU
> addr ends up at 0xD000_0000 will fix your problem.
>
> I guess HAL_PHYSICAL_MEMORY_BASE is probably misnamed, it should
> really be HAL_PHYSICAL_MEMORY_OFFSET. It only works as a base when the
> PCI memory allocation starts at zero.
>
Hi, Nick,

Yeah, I think I can understand your suggestion, unfortuantely I still met
segment fault. I append my log message in the end, please take a look, I
don't exactly the memory mapping for eCos in vrc4373 board. I guess there is
something wrong on the PCI space and memory space. Could you let me know how
can I trace the SIGSEGV and the segment fault, so that I can figure out
which part is wrong. I don't quiet understand why I can not access
0xD000_0000 at all.

Thanks a lot!

Best Rgds,
-Ling

======================================================
(gdb) cont
Continuing.
Found device on bus 0, devfn 0x10:
 Device configuration succeeded
 **** Device IO and MEM access enabled
 Vendor    0x1688
 Device    0x8888
 Command   0x0000, Status 0x0280
 Class/Rev 0x07800001
 Header 0x11FF0F
 SubVendor 0x1111, Sub ID 0xFF1A
 BAR[0]    0x90000000 / probed size 0xFFF00000 / CPU addr 0xD0000000
 BAR[1]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[2]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[3]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[4]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[5]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 Wired to HAL vector 13
Current pci base is D0000000
[New thread 3]

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 3]
0x80100bb8 in pci_test () at pcitest.c:293
293     (*(pci_base + 0x004)) = 0x0000;
Current language:  auto; currently c
(gdb)

Re: [ECOS] How to access PCI memory(HELP)....

[Nick Garnett]

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

> >
> > I responded to your previous message before I saw this one. As I said
> > there, I think that adjusting HAL_PHYSICAL_MEMORY_BASE so that the CPU
> > addr ends up at 0xD000_0000 will fix your problem.
> >
> > I guess HAL_PHYSICAL_MEMORY_BASE is probably misnamed, it should
> > really be HAL_PHYSICAL_MEMORY_OFFSET. It only works as a base when the
> > PCI memory allocation starts at zero.
> >
> Hi, Nick,
> 
> Yeah, I think I can understand your suggestion, unfortuantely I still met
> segment fault. I append my log message in the end, please take a look, I
> don't exactly the memory mapping for eCos in vrc4373 board. I guess there is
> something wrong on the PCI space and memory space. Could you let me know how
> can I trace the SIGSEGV and the segment fault, so that I can figure out
> which part is wrong. I don't quiet understand why I can not access
> 0xD000_0000 at all.
> 
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.


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

[ECOS] Anyway to access the 7 segment display on NEC vrc4373 board?

[Ling Su]

Hi, Jifl,

I can not find the 7 segment display on the schematic of NECvr4373 board I
have, and actually I want to use it for some signaling purpose. I found it
is enabled in plarform.S, but I don't know what is the address that it is
mapped to. Could you please do me a favor to look it up in your document? I
just want to write some bytes into it to show the progress of a program.

Thanks a lot!

Regards,
-Ling

[ECOS] Re: Anyway to access the 7 segment display on NEC vrc4373 board?

[Jonathan Larmour]

Ling Su wrote:
> 
> I can not find the 7 segment display on the schematic of NECvr4373 board I
> have, and actually I want to use it for some signaling purpose. I found it
> is enabled in plarform.S, but I don't know what is the address that it is
> mapped to. Could you please do me a favor to look it up in your document? I
> just want to write some bytes into it to show the progress of a program.

If you look at the vrc4372 data sheet at:

http://www.necel.com/home.nsf/Createpage?OpenAgent&Microprocessors&V ()R()+Series(TM)+64-Bit+MIPS(R)+RISC&Companion+Chips&&&&&&&

Then look at section 6.5, page 24. And as you can see in platform.S, the 7
segment display is IOPROF_06 and IOPROF_07.

For more than this, you're on your own, sorry :-/. Unless someone else out
there has done this.

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

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

[Ling Su]

Dear Nick and Jifl,

Sorry for posting so many dump messages! Since we have some time difference,
I cannot catch your on net when I work, I have a lot of questions to ask
when I am digging this problem. Thanks for your patience!

I checked the schematic for the board, I doubt if the 4373 I/O memory
physical space can be changed. Therefore, if I still use 0x8000_0000 for the
my PCI card physical space, 4372 always response when I wrote into this
range. Probably set the PCI space to 0x9000_0000 will be the best choice, as
Nick suggested. Currently problem with this, it always trigger a
Segmentation Fault, I didn't really catch the reason. I guess it might
relate to the TLB(MMU) configuration. I append the recent session I run in
gdb, helpfully it can give you more information on this. The gdb debugger
complain 0xd000_0000 is out of bound when I try to take a look at its value,
how come?

Hope you can find anything out on the memory mapping and hopefully you can
answer my previous email questions. Thanks a lot!

Rgds,
-Ling
===============================================
(gdb) cont
Continuing.
Found device on bus 0, devfn 0x10:
 Device configuration succeeded
 **** Device IO and MEM access enabled
 Vendor    0x1688
 Device    0x8888
 Command   0x0000, Status 0x0280
 Class/Rev 0x07800001
 Header 0x11FF0F
 SubVendor 0x1111, Sub ID 0xFF1A
 BAR[0]    0x90000000 / probed size 0xFFF00000 / CPU addr 0xD0000000
 BAR[1]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[2]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[3]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[4]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 BAR[5]    0x00000000 / probed size 0x00000000 / CPU addr 0xFFFFFFFF
 Wired to HAL vector 13
Current pci base is D0000000
[New thread 3]
[Switching to thread 3]

Breakpoint 1, pci_test () at pcitest.c:293
293     (*(pci_base + 0x004)) = 0x0000;
Current language:  auto; currently c
(gdb) print pci_base
$1 = 0xd0000000 <Address 0xd0000000 out of bounds>                <---- ????
(gdb) cont
Continuing.

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)
0x80100bbe <pci_test+706>: lui $a0,0x8011
0x80100bc2 <pci_test+710>: jal 0x8010522c <diag_printf>
0x80100bc6 <pci_test+714>: daddiu $a0,$a0,-8880
0x80100bca <pci_test+718>: lui $a0,0x8011
0x80100bce <pci_test+722>: jal 0x8010522c <diag_printf>
0x80100bd2 <pci_test+726>: daddiu $a0,$a0,-8852
0x80100bd6 <pci_test+730>: lw $v0,156($s8)
0x80100bda <pci_test+734>: addiu $v0,$v0,1024
0x80100bde <pci_test+738>: sw $v0,160($s8)
0x80100be2 <pci_test+742>: sw $zero,152($s8)
0x80100be6 <pci_test+746>: lw $v0,152($s8)
0x80100bea <pci_test+750>: slti $v0,$v0,10
0x80100bee <pci_test+754>: bnez $v0,0x80100bfc <pci_test+768>
0x80100bf2 <pci_test+758>: nop
0x80100bf6 <pci_test+762>: j 0x80100c40 <pci_test+836>
0x80100bfa <pci_test+766>: nop

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

[Nick Garnett]

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

> (gdb) print pci_base
> $1 = 0xd0000000 <Address 0xd0000000 out of bounds> <---- ????

This is a result of the stub ROM getting a segfault and translating it
into an error message.

> (gdb) cont
> Continuing.
> 
> 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. 

See my previous message about how to determine whether this is a TLB
or an device problem.

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

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

[Ling Su]

> >
> > 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!

Best Regards,
-Ling

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

[Ling Su]

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)?
<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?
<3>. Should I use STATIC MMU table? Will it bring any diffrence? Actually I
did try it, result is the same, just curious.

Thanks a lot!

Rgds,
-Ling

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

[Nick Garnett]

"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

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

[Andrew Lunn]

> 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.

I've been here, done that for the EBSA. I needed to change the MMU
setup so that i could write to the FLASH without the MMU/CPU doing
caching and write buffering. For the EBSA i needed some of the macros
used to setup the TLB available in user applications. This required a
change to the header files. Also it needed a change to the macros that
flush the cache. On the ARM you change the TLB, flush the cache so
that the TLB is written to the DRAM, and then tell the MMU to flush
its copy of the TLB and read it from DRAM again. This last stage was
missing on the EBSA. Without that last bit it sometimes worked and
sometimes not depending on what memory i used first.

Hope this helps.

        Andrew

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

[Ling Su]

Nick wrote,
>
> 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.
>
> 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.
>

Hi, Jifl,

Could you please do me a favor? As you may know, I still have trouble to use
my tool chain with "-O2" option. I believe Nick's point is correct, since
the RAM startup code doesn't initlize the MMU. I have tried to include the
hal_mmu_init in the RAM startup code, the progrem just hang somewhere, it is
not so good to initialize the TLB twice, I guess. I think to rebuild the
gdbstub will be a better solution, I hope I can have a optimized stub code,
could you help me build me and send me a gzipped code privately? Thanks a
lot!

Best Regards,
-Ling

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

[Jonathan Larmour]

Ling Su wrote:
> 
> Could you please do me a favor? As you may know, I still have trouble to use
> my tool chain with "-O2" option. I believe Nick's point is correct, since
> the RAM startup code doesn't initlize the MMU. I have tried to include the
> hal_mmu_init in the RAM startup code, the progrem just hang somewhere, it is
> not so good to initialize the TLB twice, I guess. I think to rebuild the
> gdbstub will be a better solution, I hope I can have a optimized stub code,
> could you help me build me and send me a gzipped code privately? Thanks a
> lot!

First it would surely be better to rebuild the stubs without -O0 just to
see if it works. Is there any requirement for the stubs to be optimized? Do
they not fit otherwise?

Once we _know_ you have code that works, then you can send the patches, and
I'll gladly build you a new stub image in return :-).

Jifl
-- 
Red Hat, 35 Cambridge Place, Cambridge, UK. CB2 1NS  Tel: +44 (1223) 728762
"Plan to be spontaneous tomorrow."  ||  These opinions are all my own fault

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

[Ling Su]

[-- Attachment #1: Type: text/plain, Size: 1854 bytes --]

Ling Su wrote,
> > Could you please do me a favor? As you may know, I still have trouble to
use
> > my tool chain with "-O2" option. I believe Nick's point is correct,
since
> > the RAM startup code doesn't initlize the MMU. I have tried to include
the
> > hal_mmu_init in the RAM startup code, the progrem just hang somewhere,
it is
> > not so good to initialize the TLB twice, I guess. I think to rebuild the
> > gdbstub will be a better solution, I hope I can have a optimized stub
code,
> > could you help me build me and send me a gzipped code privately? Thanks
a
> > lot!
>

Jifl Wrote,
> First it would surely be better to rebuild the stubs without -O0 just to
> see if it works. Is there any requirement for the stubs to be optimized?
Do
> they not fit otherwise?
>
> Once we _know_ you have code that works, then you can send the patches,
and
> I'll gladly build you a new stub image in return :-).
>

Hi, Dear Jifl,

I attached the small patch for the PCI bus access. I tested using the old
stub rom provided in eCos-1.3.1 release, now I can access my PCI card
without any problem. Basically I just add the hal_mmu_init even for RAM
startup program.

I still have trouble to build a stub rom, I guess it is due to my toolchain
problem. If I build one using "-O2" option, it simply doesn't not response,
but I am sure it is alive since I can observe its PCI access to serial port.
But it can not connect to GDB. If I build with "-O0" option, it can
connected, but the strange thing is it display a different thing when I type
"target remote /dev/ttyS0" from the original stub ROM. Even worse, I simply
complain can not find 0x8000xxxx to start the program. If you have interests
to see the problem, I can send you a detail log.

If you have some time, can you build a stub rom for me after applying the
patch, thanks a lot.

Best Regards,
-Ling

[-- Attachment #2: patch_pci --]
[-- Type: text/x-diff, Size: 3333 bytes --]

Index: hal/mips/arch/current/src/vectors.S
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/mips/arch/current/src/vectors.S,v
retrieving revision 1.20
diff -u -r1.20 vectors.S
--- vectors.S	2000/08/25 17:33:03	1.20
+++ vectors.S	2000/09/15 00:38:27
@@ -51,7 +51,8 @@
 # include <pkgconf/kernel.h>	
 #endif
 			
-#include <cyg/hal/arch.inc>	
+#include <cyg/hal/arch.inc>
+#include <cyg/hal/platform.inc>
 #include <cyg/hal/hal_arch.h>	
 	
 #ifdef at
Index: hal/mips/vrc4373/current/include/platform.inc
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/mips/vrc4373/current/include/platform.inc,v
retrieving revision 1.1
diff -u -r1.1 platform.inc
--- platform.inc	2000/03/28 14:11:31	1.1
+++ platform.inc	2000/09/15 00:38:29
@@ -155,7 +155,7 @@
 # Since the setup code must work only in registers, we do not do a subroutine
 # linkage here, instead the setup code knows to jump back here when finished.
 	
-#if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMRAM)
+#if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMRAM) || defined(CYG_HAL_STARTUP_RAM) 
 
 	.macro	hal_mmu_init
 	.extern	hal_mmu_setup
@@ -174,7 +174,7 @@
 # MEMC macros.
 # 
 	
-#if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMRAM)
+#if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMRAM) 
 
 	.macro	hal_memc_init
 	.extern	hal_memc_setup
Index: hal/mips/vrc4373/current/include/plf_io.h
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/mips/vrc4373/current/include/plf_io.h,v
retrieving revision 1.1
diff -u -r1.1 plf_io.h
--- plf_io.h	2000/03/28 14:11:32	1.1
+++ plf_io.h	2000/09/15 00:38:29
@@ -67,7 +67,7 @@
 
 // This is where the PCI spaces are mapped in the CPU's (virtual)
 // address space.
-#define HAL_PCI_PHYSICAL_MEMORY_BASE    0xC0000000
+#define HAL_PCI_PHYSICAL_MEMORY_BASE    0x40000000
 #define HAL_PCI_PHYSICAL_IO_BASE        0xAC000000
 
 //-----------------------------------------------------------------------------
@@ -176,7 +176,7 @@
 // Resources
 
 // Map PCI device resources starting from these addresses in PCI space.
-#define HAL_PCI_ALLOC_BASE_MEMORY       0
+#define HAL_PCI_ALLOC_BASE_MEMORY       0x90000000
 #define HAL_PCI_ALLOC_BASE_IO           0
 
 // Translate the PCI interrupt requested by the device (INTA#, INTB#,
Index: hal/mips/vrc4373/current/src/platform.S
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/mips/vrc4373/current/src/platform.S,v
retrieving revision 1.2
diff -u -r1.2 platform.S
--- platform.S	2000/09/01 13:45:26	1.2
+++ platform.S	2000/09/15 00:38:31
@@ -275,7 +275,7 @@
 ## Much of this code is taken from the PMON sources, hence it does not fully
 ## conform to our normal coding conventions.
 
-#if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMRAM)
+#if defined(CYG_HAL_STARTUP_ROM) || defined(CYG_HAL_STARTUP_ROMRAM) || defined(CYG_HAL_STARTUP_RAM)
 
 ## DEFINITIONS FOR THE TLB SUPPORT
 
@@ -301,7 +301,7 @@
 #define TLBLO_UNCACHED  (CFG_C_UNCACHED<<TLBLO_CSHIFT)
 #define PAGE_SIZE       0x01000000
 #define PADDR_INC       0x02000000
-#define NUMB_PG         8
+#define NUMB_PG         16
 
 	.text
 	

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

[Nick Garnett]

"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