[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

Can you find who generates the data abort? You can use addr2line for
this purpose.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.