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

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

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

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

[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

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

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

[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

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)