Hi Daniel,
Thanks for the update. It looks like I'm almost there now :-)
On 29 October 2013 07:48, Daniel Hellstrom <daniel at gaisler.com> wrote:
> Hello,
>
> On 10/28/2013 05:40 PM, David Paterson wrote:
>
>
>> On 28 October 2013 14:50, Daniel Hellstrom <daniel at gaisler.com <mailto:
>> daniel at gaisler.com>> wrote:
>>
>> Yes there are a lot PCI changes. We have implemented a PCI library
>> located in cpukit/libpci. Now the cfg space identifier {int bus, int slot,
>> int func} is substituted with pci_dev_t to reduce
>> the footprint of all PCI functions and callers. Now there are also
>> I/O access routines.
>>
>> grpci_* is the GRPCI specific implementation, it is better to use the
>> new PCI library definitions defined in pci/access.h:
>>
>> /* Configuration Space Access Read Routines */
>> extern int pci_cfg_r8(pci_dev_t dev, int ofs, uint8_t *data);
>> extern int pci_cfg_r16(pci_dev_t dev, int ofs, uint16_t *data);
>> extern int pci_cfg_r32(pci_dev_t dev, int ofs, uint32_t *data);
>>
>> /* Configuration Space Access Write Routines */
>> extern int pci_cfg_w8(pci_dev_t dev, int ofs, uint8_t data);
>> extern int pci_cfg_w16(pci_dev_t dev, int ofs, uint16_t data);
>> extern int pci_cfg_w32(pci_dev_t dev, int ofs, uint32_t data);
>>
>> /* Read a register over PCI I/O Space */
>> extern uint8_t pci_io_r8(uint32_t adr);
>> extern uint16_t pci_io_r16(uint32_t adr);
>> extern uint32_t pci_io_r32(uint32_t adr);
>>
>> /* Write a register over PCI I/O Space */
>> extern void pci_io_w8(uint32_t adr, uint8_t data);
>> extern void pci_io_w16(uint32_t adr, uint16_t data);
>> extern void pci_io_w32(uint32_t adr, uint32_t data);
>>
>>
>> Thanks Daniel, it's starting to look a bit closer to working now :-)
>>
>> I've made all the changes, and I can get my test driver and test program
>> to build, but it's not initialising the driver. Trying the sample
>> "rtems-pci" program with the custom driver enabled shows the same problem,
>> which might give you an idea of what's going wrong.
>>
>> If I enable the "#define CONFIGURE_DRIVER_CUSTOM1" flag, then both my
>> program and the sample fail with, e.g. :-
>>
>
> You must also update (which you probably also did):
>
> /* CHANGE THIS !!! to match the DEVIC/VENDOR of your PCI board */
> #define PCIID_VENDOR_CUSTOM 0x1186
> #define PCIID_DEVICE_CUSTOM 0x4000
>
> Yep - I modified those to match our own vendor and device IDs.
> grlib> load /opt/rtems-4.10-mingw/src/**samples/rtems-pci
>> section: .text at 0x40000000, size 180176 bytes
>> section: .data at 0x4002bfd0, size 5520 bytes
>> section: .jcr at 0x4002d560, size 4 bytes
>> total size: 185700 bytes (19.8 Mbit/s)
>> read 1100 symbols
>> entry point: 0x40000000
>> grlib> run
>> IU in error mode (tt = 0x2b)
>> 40016818 80a0a000 cmp %g2
>>
>> Looking at a dump of the executable, this is near the start of
>> "_CORE_mutex_Seize", if that helps in any way...
>>
>
> This is caused by the printf() in custom_pci_board_register, please change
> it to printk() instead. It is too early to call printk(). The code works if
> the drvmgr is initialized from the Init task, then printf() could have been
> used. I have updated the example for the next release. Thanks for the
> feedback!
>
Glad I could help. I've made the above changes, and my own code, i.e. my
driver and test program, now runs (although with errors) but the rtems-pci
sample is still crashing, even when I change all printf's to printk's. I
suspect this is due to other changes I've made to the sample code, and I'll
go back to the original later today and try it again. The crash seems to
be in a context switch, and looks like trying to execute a prvileged
instruction in user mode :-
grlib> load /opt/rtems-4.10-mingw/src/samples/rtems-pci
section: .text at 0x40000000, size 180192 bytes
section: .data at 0x4002bfe0, size 5520 bytes
section: .jcr at 0x4002d570, size 4 bytes
total size: 185716 bytes (20.1 Mbit/s)
read 1100 symbols
entry point: 0x40000000
grlib> run
Registering CUSTOM PCI driver
PCI[0:0:0]: DEV BAR6 (2): no resource assigned
CUSTOM PCI @ [0:0:0]
CUSTOM PCI: BAR0: 0x80040800
CUSTOM PCI: BAR1: 0xFFF20001
CUSTOM PCI: BAR2: 0x80000000
CUSTOM PCI: BAR3: 0x80040000
CUSTOM PCI: BAR4: 0x00000000
CUSTOM PCI: BAR5: 0x00000000
CUSTOM PCI: IRQ: 25
IU in error mode (tt = 0x03)
40011798 81910000 mov %g4, %wim
grlib> bt
Inside trap/irq
%pc %sp
#0 0x40011798 0x4ffffeb0 _CPU_Context_restore_heir + 0x74
#1 0x4000dedc 0x4ffffeb0 rtems_initialize_device_drivers + 0x10
#2 0x40001edc 0x4fffff10 boot_card + 0xbc
#3 0x400010c0 0x4fffff80 hard_reset + 0xc0
As I said, this may be due to some of the changes I made to the code while
trying to find the cause of the previuos problems.
Overall we've made a lot of progress and I think we're much closer to
having a working driver, so thanks for your help on this.
Regards,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20131029/47a11161/attachment-0001.html>