Re: freeze when reading a PCI bridge register

[Nicolas Lavocat <nicolas.lavocat@fr.thalesgroup.com>]

Tests done...

-I use ioremap for the mapping of the memory, so it should be uncacheable
-I inserted a  eieio() before the read and there is no change. In=20
addition, I use outbe_32 and inbe_32, which make a sync or isync ... And=20
these functions are used for the serial port and perfectly work
about boot traces,  there is nothing to see...  system freezes just when=20
the register "pci1_cfg_addr_register" has to be read:

traces
-------------------------------------------------------------------------
[snip]
<- unflatten_device_tree()

get_real_base: looking for abac-bridge :

OF: ** translation for device /abac@20000000 **

OF: bus is default (na=3D1, ns=3D1) on /

OF: translating address: 20000000

OF: reached root node

get_real_base: base address of ABAC : 20000000

console [udbg0] enabled

setup_arch: bootmem

reading PCI vendorID and deviceID

pci1_cfg_addr =3D 0xfdfe1098, pci1_cfg_data =3D 0xfdfe1f00

writing in pci1_cfg_data_register

reading pci1_cfg_addr_register
-------------------------------------------------------------
freeze, nothing after that...

so writing seems to be ok but reading freezes...
thank you again for your suggestions ^^
If somebody has another idea...

best regards,

Nicolas Lavocat

Nicolas Lavocat a =E9crit :
> Thank you for your advices! I try it as soon as possible! (the board=20
> is not often available...)
>
> Nicolas Lavocat
>
> Gabriel Paubert a =E9crit :
>> On Wed, Apr 22, 2009 at 10:04:29AM +0200, Nicolas Lavocat wrote:
>> =20
>>> Hi everybody!
>>>
>>> I' am trying to configure a PCI bridge on a private board, with a =20
>>> powerpc . In a first time, I tried to get informations about PCI =20
>>> devices, in order to be sure  that  my read  and write methods work=20
>>> (  using 2 configuration registers, like on an x86 architecture.) .=20
>>> 2  configuration registers  are used, for example we  write  an=20
>>> encoded  address (it is a request to a PCI device) in the first and=20
>>> the answer of  the PCI device can be read in the second register (it=20
>>> is a configuration  cycle)
>>> Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
>>>    =20
>>
>> JTAG is probably a completely different hardware path, so it
>> does not really count. uboot testing is ok.
>> =20
>>> For example, the code used under u-boot:
>>>
>>> volatile u32* addr;
>>> u32 vendor_device_ID;
>>>
>>> puts("PCI1 reading PCI VENDOR and DEVICE ID\n");
>>> addr=3DCFG_ADDR_PCI1;
>>> *addr=3D0x80007800;
>>>
>>> addr=3D CFG_DATA_PCI1;
>>> vendor_device_ID=3D *addr;
>>> printf("PCI1: PCI1_VENDOR_DEVICE_ID=3D %08x  \n" ,vendor_device_ID);
>>>    =20
>>
>> 2 possibilities:
>> - your I/O is not marked uncacheable (should be with ioremap)
>> - the PPC is reordering and issuing the read before the write,
>>   you should use accessors. A simple test is inserting
>>   an asm volatile("eieio") before the read.
>>
>> About your other mails, please avoid HTML mail.
>>
>>     Gabriel
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>  =20
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>