From: Vitaly Bordug <vbordug@ru•mvista.com>
To: Alex BASTOS <alebas@televes•com>
Cc: linuxppc-embedded list <linuxppc-embedded@ozlabs•org>
Subject: Re: pq2_find_bridges hangs system
Date: Wed, 14 Dec 2005 14:29:34 +0300 [thread overview]
Message-ID: <43A0021E.7030406@ru.mvista.com> (raw)
In-Reply-To: <1134555662.439ff20e6e812@webmail.televes.com:443>
Alex BASTOS wrote:
> Vitaly,
>
> So, I have arrived to some conclusions.
>
> 1) With my previous kernel version (2.6.11) I had no problems
> because it had CONFIG_PCI_8260 and CONFIG_PPC_INDIRECT_PCI unset.
> So I think no effective read/write operation was executed, and so
> that, no Machine Check.
>
> In fact, this is the configuration I would prefer for my board. I have
> to set CONFIG_PCI for enabling USB, but I don't want all the HW stuff
> of the PCI. I can get these also with 2.6.15 if I modify Kconfig, to
> allow me to unset PCI_8260 (and then PPC_INDIRECT_PCI) for my board.
> With that, the problem dissapears and I can boot 2.6.15.
>
> Shouldn't this (PCI_8260) be visible from xconfig for those like me
> who wants USB (=> CONFIG_PCI) but don't really have any PCI device?
>
Maybe, but I guess more correct is to deal with USB->PCI dependency..
Is it really needed(I am not USB expert)?
> 2) Although I am using Uboot 1.1.4, it is not top of git. I have
> found your changes to support PCI on 8272ADS for u-boot are not
> still applied on the version i am using. So, could this be causing
> the problem? Is there any configuration done in u-boot required by
> the PCI on the linux kernel to boot (BR3,OR3, EMR, ...)?
>
> I should say that, on ADS, I have an older version of u-boot, 1.1.2,
> and it boots OK.
>
My changes do not required for kernel to deal with PCI, that patch just allows access to PCI in
U-Boot. Hence I might be useful if you'll head for resolving this issue which I guess unlikely to happen
> 3) I have seen that from u-boot, a reset occurs when I read Internal
> Memory at offset 0x10904 (PCI CFG_DATA). From BDI, when I do the same
> all PCI section on IM becomes zero. Is this a known behaviour? May this
> reflect a hardware problem?
>
Sounds weird
> In conclusion, 1) solves my "must", a working board (without PCI).
> But I still would like to know what am I doing so wrong with this.
>
IMHO ability to disable PCI_8260 while PCI is on might be confusing, at least for upstream.
> Best regards,
>
> Alex
>
> Citando Alex BASTOS <alebas@televes•com>:
>
>> Vitaly,
>>
>> It didn't work. So I will check pq2ads_setup_pci to check if
>> some board specific issue is affected.
>>
>> I will say you if I find anything
>>
>> Thanks
>>
>> Alex.
>>
>
>
--
Sincerely,
Vitaly
next prev parent reply other threads:[~2005-12-14 11:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-14 10:21 pq2_find_bridges hangs system Alex BASTOS
2005-12-14 11:29 ` Vitaly Bordug [this message]
2005-12-14 14:13 ` [SOLVED] " Alex BASTOS
2005-12-14 14:14 ` Vitaly Bordug
2005-12-14 14:30 ` Kumar Gala
2005-12-15 9:39 ` Alex BASTOS
-- strict thread matches above, loose matches on Subject: below --
2005-12-02 10:51 Alex BASTOS
2005-12-02 10:30 ` Vitaly Bordug
2005-12-02 13:56 ` Alex BASTOS
2005-12-02 14:49 ` Alex BASTOS
2005-12-02 14:55 ` Vitaly Bordug
2005-12-03 17:36 ` Alex BASTOS
2005-12-13 8:24 ` Alex BASTOS
[not found] ` <0IQV004GGIH0UG@mailstore1.hut-mail>
2005-12-02 14:09 ` Kalle Pokki
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=43A0021E.7030406@ru.mvista.com \
--to=vbordug@ru$(echo .)mvista.com \
--cc=alebas@televes$(echo .)com \
--cc=linuxppc-embedded@ozlabs$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox