[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

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

[namita chawla]

Dear All,
Can anybody help me know whether i am drowning or there are some 
chances of escape.;-)I want to acess PCI memory from my 
application.The scenerio is in linux we have
mmap() method to select memory physical base address to access 
memory mapped hardware.Does a similar function  exist in windows 
so that my application can directly access the memory of device?
i would be glad to get your feedback.
Thanx,
Namita
_________________________________________________________
Click below  to experience Aishwarya Rai's beauty secrets. New 
International Lux Skincare - It's not just soap, It's skincare.
http://www.luxskincare.com


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

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

[David N. Welton]

"namita  chawla" <namita05@rediffmail.com> writes:

> Does a similar function exist in windows so that my application can
> directly access the memory of device?

I take it you mean eCos... did you try just reading and writing to the
memory location?

-- 
David N. Welton
   Consulting: http://www.dedasys.com/
     Personal: http://www.dedasys.com/davidw/
Free Software: http://www.dedasys.com/freesoftware/
   Apache Tcl: http://tcl.apache.org/

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

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

[Stephen Polkowski]

Just use the pci functions in eCos. First find the device your are 
interested in, then get the device info.  The info has the base 
addresses of the pci memory.  Then, just reference the memory.


     // Find host bridge
     cyg_pci_find_class(0x060000, &shadow_devid);

     // Get Vendor ID
     cyg_pci_get_device_info(shadow_devid, &device);



David N. Welton wrote:

> "namita  chawla" <namita05@rediffmail.com> writes:
> 
> 
>>Does a similar function exist in windows so that my application can
>>directly access the memory of device?
>>
> 
> I take it you mean eCos... did you try just reading and writing to the
> memory location?
> 
> 


-- 
Stephen Polkowski
Centaur Technology
Austin, TX
(512) 418-5730


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

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

[Ling Su]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4294 bytes --]

Hello, everyone,
 
I attached my pci1.exe test running result in the end, the UNKNOW device is 
my own card, according to the dump, which address that I should use to access 
the PCI memory? Any helpful explaination will be appreciated very much. Thanks a 
lot in advance!
 
Best Rgds,
-Ling
 
==========================================================
(cont) Continuing.  Found device on bus 0, devfn 
0x00:  Note that board is active. Probed sizes and CPU addresses 
invalid!  Device configuration failed - device already 
enabled  Vendor    0x1033 [NEC][NEC 
Corporation]  Device    0x001A 
[UNKNOWN]  Command   0x0146, Status 0x0280  Class/Rev 
0x06800001 [Bridge Device][Other][]  Header 0x11FF0E  SubVendor 
0x1111, Sub ID 0xFF19  BAR[0]    0x1C000000 / probed size 
0x00000000 / CPU addr 0x1111FF15  BAR[1]    0x80000000 / 
probed size 0x00000000 / CPU addr 0x00000000  BAR[2]    
0x00000000 / probed size 0x00000000 / CPU addr 
0x1111FF16  BAR[3]    0x00000000 / probed size 0x00000000 
/ CPU addr 0x00000000  BAR[4]    0x00000000 / probed size 
0x00000000 / CPU addr 0x1111FF17  BAR[5]    0x00000000 / 
probed size 0x00000000 / CPU addr 0x00000000  Wired to HAL vector 
11 Found device on bus 0, devfn 0x08:  Device configuration 
succeeded  Vendor    0x1023 [Trident][Trident 
Microsystems]  Device    0x9660 
[9660][]  Command   0x0000, Status 0x0280  Class/Rev 
0x030000D3 [Display Controller][PC Compatible][VGA]  Header 
0x11FF0E  SubVendor 0x1111, Sub ID 
0xFF19  BAR[0]    0x00000000 / probed size 0xFFC00000 / 
CPU addr 0xC0000000  BAR[1]    0x00400000 / probed size 
0xFFFF0000 / CPU addr 0xC0400000  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 12 Found device 
on bus 0, devfn 0x10:  Device configuration 
succeeded  Vendor    0x1688 
[UNKNOWN]         <------------ This 
is my own card  Device    0x8888 
[UNKNOWN]  Command   0x0000, Status 0x0280  Class/Rev 
0x07800001 [UNKNOWN]  Header 0x11FF0E  SubVendor 0x1111, Sub ID 
0xFF19  BAR[0]    0x00410008 / probed size 0xFFFFF008 / 
CPU addr 0xC0410000  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 Found device 
on bus 0, devfn 0x18:  Device configuration 
succeeded  Vendor    0x1011 [DEC][Digital Equipment 
Corporation]  Device    0x0009 [DC21140][Fast Ethernet 
Ctrlr]  Command   0x0000, Status 0x0280  Class/Rev 
0x02000022 [Network Controller][Ethernet][]  Header 
0x11FF0E  SubVendor 0x1111, Sub ID 
0xFF19  BAR[0]    0x00000001 / probed size 0xFFFFFF81 / 
CPU addr 0xAC000000  BAR[1]    0x00411000 / probed size 
0xFFFFFF80 / CPU addr 0xC0411000  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 14
 
Strings in [] are from the PCI Code List at http://www.yourvote.com/pci It seems 
that some of the device information has not been registered in the PCI Code 
List. Please consider improving the database by registering the [UNKNOWN] 
information for your devices. Thanks.
 
Testing PCI memeory mapping: PASS:<pci1 test 
OK> EXIT:<done> [New thread 3]

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

[Jonathan Larmour]

> Ling Su wrote:
> 
> I attached my pci1.exe test running result in the end, the UNKNOW device
> is my own card, according to the dump, which address that I should use to
> access the PCI memory? Any helpful explaination will be appreciated very
> much. Thanks a lot in advance!
> 
[snip]
> Found device on bus 0, devfn 0x10:
>  Device configuration succeeded
>  Vendor    0x1688 [UNKNOWN]         <------------ This is my own card
>  Device    0x8888 [UNKNOWN]
>  Command   0x0000, Status 0x0280
>  Class/Rev 0x07800001 [UNKNOWN]
>  Header 0x11FF0E
>  SubVendor 0x1111, Sub ID 0xFF19
>  BAR[0]    0x00410008 / probed size 0xFFFFF008 / CPU addr 0xC0410000
                                                            ^^^^^^^^^^

Looks like this address is where the I/O ports for this card should have
been mapped into the CPU address space. Hopefully my last e-mail provides
some of the explanation. Other than that, UTSL - Use The Source Ling ;)!

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] How to access PCI memory(HELP)....

[Jonathan Larmour]

Jonathan Larmour wrote:
> 
> >  BAR[0]    0x00410008 / probed size 0xFFFFF008 / CPU addr 0xC0410000
>                                                             ^^^^^^^^^^
> 
> Looks like this address is where the I/O ports for this card should have

I mean "memory", not "I/O ports".

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] How to access PCI memory(HELP)....

[Ling Su]

> Jonathan Larmour wrote:
> >
> > >  BAR[0]    0x00410008 / probed size 0xFFFFF008 / CPU addr 0xC0410000
> >                                                             ^^^^^^^^^^
> >
> > Looks like this address is where the I/O ports for this card should have
>
> I mean "memory", not "I/O ports".
>

Thanks, Jifl.

You mean I can use 0xC0410000 pointer to access the PCI memeory, is that
correct? But what physical address will appear on the PCI bus then? I check
the source in platform.S for vrc4373, I didn't quite catch how the PCI
address and CPU address mapping for the window 0xC0xxxxxx, both the two PCI
memory access window registers are not configured for mapping this piece of
memory, you can refer the last message that I sent to you for more
information. I did  check the VR4373 manual, especially on the PCI interface
part, but I didn't quite get the idea how to transfter CPU 0xC0xxxxxx to PCI
address. Please do me a favor to give me some hints. Thanks!

Rgds,
-Ling

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

[Jonathan Larmour]

Ling Su wrote:
> 
> > Jonathan Larmour wrote:
> > >
> > > >  BAR[0]    0x00410008 / probed size 0xFFFFF008 / CPU addr 0xC0410000
> > >                                                             ^^^^^^^^^^
> > >
> > > Looks like this address is where the I/O ports for this card should have
> >
> > I mean "memory", not "I/O ports".
> >
> 
> Thanks, Jifl.
> 
> You mean I can use 0xC0410000 pointer to access the PCI memeory, is that
> correct? But what physical address will appear on the PCI bus then? I check
> the source in platform.S for vrc4373, I didn't quite catch how the PCI
> address and CPU address mapping for the window 0xC0xxxxxx, both the two PCI
> memory access window registers are not configured for mapping this piece of
> memory, you can refer the last message that I sent to you for more
> information. I did  check the VR4373 manual, especially on the PCI interface
> part, but I didn't quite get the idea how to transfter CPU 0xC0xxxxxx to PCI
> address. Please do me a favor to give me some hints. Thanks!

After another look I now see what's going on. Yes, there is a problem here
I believe and some of my understanding before was wrong(!) The relevant
stuff is in hal_memc_setup_table (a table-driven initialization thing
driven by hal_memc_setup) in platform.S.

In there, PCI_IOSPACE_BASE is set to 0x0c. This is used at the entry:

# Map PCI IO space Phys == Local
.long   PCIMSTRIO,      (0x000fd000 | ( PCI_IOSPACE_BASE << 24) |
PCI_IOSPACE_BASE)                                                                                              

So while the space is being mapped 1:1, it is indeed set up for 0x0C000000
and not 0xC0000000, as you suggested.

The fix may be just changing the definition of 
HAL_PCI_PHYSICAL_MEMORY_BASE in plf_io.h to 0x0C000000

Give that a go and let us know if it worked.

Nick, any comments?

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] How to access PCI memory(HELP)....

[Nick Garnett]

Jonathan Larmour <jlarmour@redhat.com> writes:

> Ling Su wrote:
> > 
> > > Jonathan Larmour wrote:
> > > >
> > > > >  BAR[0]    0x00410008 / probed size 0xFFFFF008 / CPU addr 0xC0410000
> > > >                                                             ^^^^^^^^^^
> > > >
> > > > Looks like this address is where the I/O ports for this card should have
> > >
> > > I mean "memory", not "I/O ports".
> > >
> > 
> > Thanks, Jifl.
> > 
> > You mean I can use 0xC0410000 pointer to access the PCI memeory, is that
> > correct? But what physical address will appear on the PCI bus then? I check
> > the source in platform.S for vrc4373, I didn't quite catch how the PCI
> > address and CPU address mapping for the window 0xC0xxxxxx, both the two PCI
> > memory access window registers are not configured for mapping this piece of
> > memory, you can refer the last message that I sent to you for more
> > information. I did  check the VR4373 manual, especially on the PCI interface
> > part, but I didn't quite get the idea how to transfter CPU 0xC0xxxxxx to PCI
> > address. Please do me a favor to give me some hints. Thanks!
> 
> After another look I now see what's going on. Yes, there is a problem here
> I believe and some of my understanding before was wrong(!) The relevant
> stuff is in hal_memc_setup_table (a table-driven initialization thing
> driven by hal_memc_setup) in platform.S.
> 
> In there, PCI_IOSPACE_BASE is set to 0x0c. This is used at the entry:
> 
> # Map PCI IO space Phys == Local
> .long   PCIMSTRIO,      (0x000fd000 | ( PCI_IOSPACE_BASE << 24) |
> PCI_IOSPACE_BASE)                                                                                              
> 
> So while the space is being mapped 1:1, it is indeed set up for 0x0C000000
> and not 0xC0000000, as you suggested.
> 
> The fix may be just changing the definition of 
> HAL_PCI_PHYSICAL_MEMORY_BASE in plf_io.h to 0x0C000000
> 
> Give that a go and let us know if it worked.
> 
> Nick, any comments?
> 

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.

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.

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 Garnett, eCos Kernel Architect
Red Hat, Cambridge, UK

Re: [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?

Any other suggestions? Thanks a lot!

Regards,
-Ling

============================================
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x80003a50 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0xb4 lma 0x80100000
Loading section .text, size 0xd9b0 lma 0x801000b4
Loading section .ctors, size 0x28 lma 0x8010da64
Loading section .dtors, size 0x14 lma 0x8010da8c
Loading section .rodata, size 0x9cc lma 0x8010daa0
Loading section .data, size 0x473c lma 0x8010e470
Start address 0x801000a4 , load size 76712
Transfer rate: 27895 bits/sec, 501 bytes/write.
(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]    0x09000000 / probed size 0xFFF00000 / CPU addr 0xD9000000
 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 D9000000
[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:

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

Since the 4372 is already mapped at 0x80000000 in the PCI space, any
further allocations must be contiguous with that, since the aperture
onto the PCI address space starts there.

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


>  BAR[0]    0x09000000 / probed size 0xFFF00000 / CPU addr 0xD9000000

These look like the value of HAL_PCI_ALLOC_BASE_MEMORY is
0x09000000 rather than 0x90000000 - a missing zero most probably.
Also the value of CPU addr suggests that HAL_PCI_PHYSICAL_MEMORY_BASE
should be 0x40000000, since that is the offset between a PCI address
and its virtual address in the CPU.

So try these values:

HAL_PCI_PHYSICAL_MEMORY_BASE = 0x40000000
HAL_PCI_ALLOC_BASE_MEMORY = 0x90000000
NUMB_PG = 16


Let me know what happens.

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

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

[Ling Su]

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

Nick,

I still have question on why 4372 will occupies the first 256Mb of the PCI
space, where we initialize this setting, can we decrease the space size.
Currently I change to following configuration,

<1>. HAL_PCI_PHYSICAL_MEMORY_BASE to 0x4000_0000
<2>. HAL_PCI_ALLOC_BASE_MEMORY to 0x8000_0000
<3>. NUMB_PG to 8

I can observe signal from PCI bus by using Logic Analyzer, of course, I
wonder if this will conflict with 4372 address space. But anyway right now I
can see signals on PCI pci bus, I haven't fully verify this. I doubt it will
have some conflict with serial port debugging if 4372 also mapps to this
space.

I will go ahead to check my PCI FPGA logic, in the meantime, I hope you can
give me some idea and suggestion on the 4372 mapping stuff. Thanks a lot!

Best Regards,
-Ling

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

[Ling Su]

>
> I still have question on why 4372 will occupies the first 256Mb of the PCI
> space, where we initialize this setting, can we decrease the space size.
> Currently I change to following configuration,
>
> <1>. HAL_PCI_PHYSICAL_MEMORY_BASE to 0x4000_0000
> <2>. HAL_PCI_ALLOC_BASE_MEMORY to 0x8000_0000
> <3>. NUMB_PG to 8
>
> I can observe signal from PCI bus by using Logic Analyzer, of course, I
> wonder if this will conflict with 4372 address space. But anyway right now
I
> can see signals on PCI pci bus, I haven't fully verify this. I doubt it
will
> have some conflict with serial port debugging if 4372 also mapps to this
> space.
>

Hi, Dear Nick and Jifl,

After carefully examine our FPGA PCI bus design and monitor the signal on
PCI bus, I found both south bridge(4372) and our PCI board drive the PCI
bus. I am thinking of change the address base of 4372. I found the 256MB
address is occupied by I/O memory space configured by N2IOADD, which is set
to 0x8000_0000 originally. I changed it to 0x9000_0000, and keep following,

 <1>. HAL_PCI_PHYSICAL_MEMORY_BASE to 0x4000_0000
 <2>. HAL_PCI_ALLOC_BASE_MEMORY to 0x8000_0000
 <3>. NUMB_PG to 16
 <4>. N2IOADD to 0x9000_0000

Unfortuately the PCI still have multiple target when I access 0x8000_xxxx
address. There is no segment fault as before, but I can not actually access
my board due to some timing problem.

Do you have any idea on why the Segment Falut occurs if I move the PCI
address space to ox9000_0000(physical address, CPU address 0xD000_0000), I
have no clue.

I have a tiny request, hope you can help me out, can you give me the memory
map for eCos in vrc4373 case, I am not sure if this is secrect, but I do
have trouble to figure it out completely although I am use the source now.
:-) More specifically, I'd like to know a following table,

Resource             Physical Address            Virtual Address
--------------------------------------------------------------------
Base Memory                 X                                   X
SIMM/DIMM                 X                                   X
PCI-I/O Space                X                                   X
PCI Mem Space              X                                   X  (*)
VRC 4373                       X                                   X  (*)
VRC 4372                       X                                   X  (*)
Z8530 UART                  X                                   X  (*)
Z8536 Timer                   X                                   X
8255 Parallel                  X                                   X
7-segment Display          X                                   X   (*)
---------------------------------------------------------------------

(*) are more important, if you don't have time, just let me know them will
be fine. Thanks a lot for you time and I appreciate any assiatance you can
offer.

Ling is poor, always meet some trouble out of prediction, please help him.
:-)

Best Regards,
-Ling

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

[Nick Garnett]

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

> >
> > I still have question on why 4372 will occupies the first 256Mb of the PCI
> > space, where we initialize this setting, can we decrease the space size.
> > Currently I change to following configuration,
> >
> > <1>. HAL_PCI_PHYSICAL_MEMORY_BASE to 0x4000_0000
> > <2>. HAL_PCI_ALLOC_BASE_MEMORY to 0x8000_0000
> > <3>. NUMB_PG to 8
> >
> > I can observe signal from PCI bus by using Logic Analyzer, of course, I
> > wonder if this will conflict with 4372 address space. But anyway right now
> I
> > can see signals on PCI pci bus, I haven't fully verify this. I doubt it
> will
> > have some conflict with serial port debugging if 4372 also mapps to this
> > space.
> >
> 
> Hi, Dear Nick and Jifl,
> 
> After carefully examine our FPGA PCI bus design and monitor the signal on
> PCI bus, I found both south bridge(4372) and our PCI board drive the PCI
> bus. I am thinking of change the address base of 4372. I found the 256MB
> address is occupied by I/O memory space configured by N2IOADD, which is set
> to 0x8000_0000 originally. I changed it to 0x9000_0000, and keep following,
> 
>  <1>. HAL_PCI_PHYSICAL_MEMORY_BASE to 0x4000_0000
>  <2>. HAL_PCI_ALLOC_BASE_MEMORY to 0x8000_0000
>  <3>. NUMB_PG to 16
>  <4>. N2IOADD to 0x9000_0000
> 
> Unfortuately the PCI still have multiple target when I access 0x8000_xxxx
> address. There is no segment fault as before, but I can not actually access
> my board due to some timing problem.
>

Moving the 4372 to 0x9000_0000 will also confuse the UART code and
anything else that accesses devices attached to it. Be careful with
this.

> Do you have any idea on why the Segment Falut occurs if I move the PCI
> address space to ox9000_0000(physical address, CPU address 0xD000_0000), I
> have no clue.

I am afraid I am running out of ideas too. Maybe there is a hardware
problem with the 4373 chip, the DDB-VRC4373 board, the PCI connectors
or the card you are trying to use. We seem to have exhausted all the
possible things we can do in software.

> 
> I have a tiny request, hope you can help me out, can you give me the memory
> map for eCos in vrc4373 case, I am not sure if this is secrect, but I do
> have trouble to figure it out completely although I am use the source now.
> :-) More specifically, I'd like to know a following table,
>

We have used exactly the same memory map that was set up on the
DDB-VRC4373 board by PMON. You said that you had the DDB-VRC4373 board
users manual, the table in section 3.7 "Memory Map" describes exactly
what we do.


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

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

[Ling Su]

Jifl said,
>
> After another look I now see what's going on. Yes, there is a problem here
> I believe and some of my understanding before was wrong(!) The relevant
> stuff is in hal_memc_setup_table (a table-driven initialization thing
> driven by hal_memc_setup) in platform.S.
>
> In there, PCI_IOSPACE_BASE is set to 0x0c. This is used at the entry:
>
> # Map PCI IO space Phys == Local
> .long   PCIMSTRIO,      (0x000fd000 | ( PCI_IOSPACE_BASE << 24) |
> PCI_IOSPACE_BASE)
>
> So while the space is being mapped 1:1, it is indeed set up for 0x0C000000
> and not 0xC0000000, as you suggested.
>
> The fix may be just changing the definition of
> HAL_PCI_PHYSICAL_MEMORY_BASE in plf_io.h to 0x0C000000
>
> Give that a go and let us know if it worked.
>

Thanks, Jifl,

I think Nick said is correct, "PCI_IOSPACE_BASE only maps PCI device IO
registers, not memory
mappings ". I still try what you suggested, change the
HAL_PCI_PHYSICAL_MEMORY_BASE to 0x0C00_0000, unfortunately the is a SIGSEGV
signal, and a segment fault. I didn't dig the codes on the MMU part, and
don't know if the eCos actived TLB in VR4300, I have grabbed a copy of
vr4300 manual, hopefully I can find anything helpful.... but I don't know if
I could still catch up my project scedule...:) if you have any thing new to
update, kindly let me know, thanks a lot!

Best Regards,
-Ling

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

[Jonathan Larmour]

Ling Su wrote:
> I think Nick said is correct, "PCI_IOSPACE_BASE only maps PCI device IO
> registers, not memory
> mappings ". I still try what you suggested,

Also try what Nick suggested.

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] How to access PCI memory(HELP)....

[Ling Su]

> The fix may be just changing the definition of 
> HAL_PCI_PHYSICAL_MEMORY_BASE in plf_io.h to 0x0C000000
> 
> Give that a go and let us know if it worked.
> 

Hi, Jifl, 

following are the log after I apply your suggested change.

Regards,
-Ling

======================================================
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0x80003a50 in ?? ()
(gdb) load
Loading section .rom_vectors, size 0xb4 lma 0x80100000
Loading section .text, size 0xd9b0 lma 0x801000b4
Loading section .ctors, size 0x28 lma 0x8010da64
Loading section .dtors, size 0x14 lma 0x8010da8c
Loading section .rodata, size 0x9cc lma 0x8010daa0
Loading section .data, size 0x473c lma 0x8010e470
Start address 0x801000a4 , load size 76712
Transfer rate: 26682 bits/sec, 501 bytes/write.
(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]    0x00000000 / probed size 0xFFF00000 / CPU addr 0x0C000000
 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 0C000000
[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