Re: [Xen-devel] Problems when using latest git tree to boot xen on OMAP5

[Vaibhav Bedia <vaibhav.bedia@xxxxxxxxx>]

Hi,

On Thu, Oct 10, 2013 at 7:36 AM, Chen Baozi <baozich@xxxxxxxxx> wrote:
>
> On Oct 10, 2013, at 7:07 PM, Julien Grall <julien.grall@xxxxxxxxxx> wrote:
>
>> On 10/10/2013 09:05 AM, Chen Baozi wrote:
>>> On Wed, Oct 09, 2013 at 09:11:16AM +0100, Ian Campbell wrote:
>>>> On Wed, 2013-10-09 at 15:46 +0800, Chen Baozi wrote:
>>>>> On Mon, Oct 07, 2013 at 11:59:16AM +0100, Julien Grall wrote:
>>>>>> On 10/07/2013 10:58 AM, Chen Baozi wrote:
>>>>>>> On 10/07/2013 04:39 PM, Ian Campbell wrote:
>>>>>>>>
>>>>>>>> It is certainly a bug in the kernel if it is accessing something which
>>>>>>>> is disabled. It may also independently be a bug in the dts that this
>>>>>>>> devices is disabled.
>>>>>>>>
>>>>>>>> However in v3.12-rc4 I don't see mmc@480d1000 being disabled in
>>>>>>>> omap5-uevm.dts and I can't see anything in the history of that file
>>>>>>>> either. Where did your copy come from?
>>>>>>>
>>>>>>> I'm currently working on the "omap5-v3.11-rc3" branch from
>>>>>>> git://github.com/rogerq/linux.git, which contains a few necessary
>>>>>>> platform patches not upstreamed. In omap5-uevm.dts, there are lines 
>>>>>>> like:
>>>>>>>
>>>>>>> 253 &mmc4 {
>>>>>>> 254     status = "disabled";
>>>>>>> 255 };
>>>>>>> 256
>>>>>>> 257 &mmc5 {
>>>>>>> 258     status = "disabled";
>>>>>>> 259 };
>>>>>>>
>>>>>>> the mmc4 refers to mmc@480d1000, which defines at omap5.dtsi:
>>>>>>>
>>>>>>> 417         mmc4: mmc@480d1000 {
>>>>>>>
>>>>>>> I checked Linus' mainline git tree. It is the same about disabled mmc4
>>>>>>> in omap5-uevm.dts. And the change is introduced in commit 5dd18b0 of the
>>>>>>> mainline kernel.
>>>>>>>
>>>>>>> Anyway, I'll see what exactly happened in the dom0 kernel dealing with
>>>>>>> those "disabled" regions.
>>>>>>
>>>>>> I looked at the Linux code. It will populate the different devices via
>>>>>> the of_platform_populate (drivers/of/platform.c).
>>>>>>
>>>>>> This function checks in of_platform_create_pdata if the device is
>>>>>> available. So the mmc driver (driver/mmc/host/omap_hsmmc.c) should not
>>>>>> be called for mmc4.
>>>>>
>>>>> I've discuessed this issue on linux-omap@xxxxxxxxxxxxxxxx The TI guy says
>>>>> that "DT disabled" means that device won't be created but hwmod bus
>>>>> initially would try to initialize all supported modules by doing reset
>>>>> access in their io memory address regions. That's why dom0 have accessed
>>>>> mmc4 address even though it has been disabled.
>>>>
>>>> ePAPR lists the option of "status = fail" which is "Indicates that the
>>>> device is not operational. A serious error was detected in the device,
>>>> and it is unlikely to become operational without repair." I'm not sure
>>>> that is quite right though.
>>>>
>>>> Rather than whitelisting and mapping disabled devices through perhaps we
>>>> should implement them as read 0xf (or 0x0) and write ignore?
>>>>
>>>> Or maybe we should just be mapping non-blacklisted disabled devices
>>>> through to dom0, for it to use or ignore as it pleases. Julien, what was
>>>> the reasoning here again?
>>>
>>> If we just simple don't pass the disabled node in DT to the dom0, anything
>>> inpropriate?
>>
>> Few mails ago, you said there is hardcoded access in Linux for OMAP,
>> right? I don't think removing the node from the Device Tree will change
>> something with this problem.
>
> Oh, I just had a assumption about hardcoded stuffs then. However, after 
> discussed
> with TI guys, it turns out I've just made a wrong assumption. There is no
> hard-coding rather a different requirement why omap_hwmod accesses the 
> module's
> io memory space, according to their explanation. Sorry for not making it clear
> when I got the new explanation.
>

I think most of the hardcoded access has been removed. Kernel would just try to
access the modules that are listed in DT and then attemtp to do a
soft-reset to get
those modules to a known state.

I am still trying to wrap my head around how Xen works but from what i
understood
so far the soft reset in both Dom0 and DomU is the problem here?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel