All of lore.kernel.org
 help / color / mirror / Atom feed
From: "tiejun.chen" <tiejun.chen@windriver.com>
To: Nicolas Lavocat <nicolas.lavocat@fr.thalesgroup.com>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>
Subject: Re: freeze when reading a PCI bridge register
Date: Wed, 22 Apr 2009 17:45:13 +0800	[thread overview]
Message-ID: <49EEE729.1090802@windriver.com> (raw)
In-Reply-To: <49EEE2C2.7@fr.thalesgroup.com>

Nicolas Lavocat wrote:
> In fact, because system froze, I wanted to know where was the problem, so, step 
> by step, I removed operations, until try to  read this register, basic operation 
> when a PCI device is used. This register can be read with JTAG, and under uboot, 
> so I think that it is not a PCI problem..
> 

I agreed this is not a PCI hardware problem as you said. But you want to
read/write PCI device on Linux you have to work under the Linux rules. If you
remove your PCI operation PCI works well I think MMU should be good as well.

BTW, you will make life easier for others if you can attach your crash log.

Best Regards
Tiejun

> Nicolas Lavocat
> 
> tiejun.chen a écrit :
>> 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.
>>>
>>> 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);
>>>
>>>
>>> Therefore, when I do the same thing under Linux, the system crash when I
>>> try to read the second register...
>>> Linux is frozen, and there is no error message.
>>> Under Linux, I made an ioremap before use the registers and access to
>>> these registers thanks to  functions  "in_be32" and "out_be32".
>>> I tried with different endianness to avoid an error of this type.
>>>
>>> If I understand, the main difference between u-boot and Linux (about
>>> registers access) is the activation of the MMU.
>>> So I thought that  problem could come from it. I think the problem could
>>> came from the configuration of DBAT and IBATS registers of the MMU, but
>>> I didn't found any information about the MMU configuration under Linux.
>>> So after this novel, I have some questions:
>>>
>>> -Is the MMU configuration generic under Linux?
>>> -Does somebody think that the problem doesn't come from MMU?
>>> -How does work ioremap? Is it a fully software function, or does it
>>> speaks to MMU to get the effective address from physical address?
>>> -Does somebody have an idea, or a documentation about MMU configuration
>>> under linux?
>>> -Do you think that my MMU is under the control of an evil spirit? ^^
>>>
>>> thank you for your help
>>>
>>>     
>>
>> Looks you want to re-configure the PCI bridge again?
>>
>> If so you really should do the private fixup function via some kernel API,
>> DECLARE_PCI_FIXUP_XXXX. It's not reasonable to re-configure PCI bridge after PCI
>> sub-system initial process is completed by kernel.
>>
>> Best Regards
>> Tiejun
>>
>>   
>>> Nicolas Lavocat
>>> _______________________________________________
>>> Linuxppc-dev mailing list
>>> Linuxppc-dev@ozlabs.org
>>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>>
>>>     
>>
>> _______________________________________________
>> Linuxppc-dev mailing list
>> Linuxppc-dev@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>>
>>   

  reply	other threads:[~2009-04-22  9:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-22  8:04 freeze when reading a PCI bridge register Nicolas Lavocat
2009-04-22  8:30 ` Liu Dave-R63238
2009-04-22  8:31   ` Nicolas Lavocat
2009-04-22  8:33     ` Liu Dave-R63238
2009-04-22  9:10       ` Nicolas Lavocat
2009-04-22  9:21 ` tiejun.chen
2009-04-22  9:26   ` Nicolas Lavocat
2009-04-22  9:45     ` tiejun.chen [this message]
2009-04-22 11:03 ` Gabriel Paubert
2009-04-22 12:28   ` Nicolas Lavocat
2009-04-22 14:56     ` Nicolas Lavocat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49EEE729.1090802@windriver.com \
    --to=tiejun.chen@windriver.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=nicolas.lavocat@fr.thalesgroup.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.