freeze when reading a PCI bridge register

[Nicolas Lavocat]

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 
addition, I use outbe_32 and inbe_32, which make a sync or isync ... And 
these functions are used for the serial port and perfectly work
about boot traces,  there is nothing to see...  system freezes just when 
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 at 20000000 **

OF: bus is default (na=1, ns=1) 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 = 0xfdfe1098, pci1_cfg_data = 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 écrit :
> Thank you for your advices! I try it as soon as possible! (the board 
> is not often available...)
>
> Nicolas Lavocat
>
> Gabriel Paubert a écrit :
>> On Wed, Apr 22, 2009 at 10:04:29AM +0200, Nicolas Lavocat wrote:
>>  
>>> Hi everybody!
>>>
>>> I' am trying to configure a PCI bridge on a private board, with a  
>>> powerpc . In a first time, I tried to get informations about PCI  
>>> devices, in order to be sure  that  my read  and write methods work 
>>> (  using 2 configuration registers, like on an x86 architecture.) . 
>>> 2  configuration registers  are used, for example we  write  an 
>>> encoded  address (it is a request to a PCI device) in the first and 
>>> the answer of  the PCI device can be read in the second register (it 
>>> is a configuration  cycle)
>>> Firstly, I did it by JTAG: it works. Then, under uboot, it is ok.
>>>     
>>
>> JTAG is probably a completely different hardware path, so it
>> does not really count. uboot testing is ok.
>>  
>>> 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=CFG_ADDR_PCI1;
>>> *addr=0x80007800;
>>>
>>> addr= CFG_DATA_PCI1;
>>> vendor_device_ID= *addr;
>>> printf("PCI1: PCI1_VENDOR_DEVICE_ID= %08x  \n" ,vendor_device_ID);
>>>     
>>
>> 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 at ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>   
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>