[fedora-arm] BZ regarding 3.6.x kernel boot from MMC issue

[Peter Robinson]

On Thu, Sep 27, 2012 at 1:41 PM, David A. Marlin <dmarlin at redhat.com> wrote:
> Peter Robinson wrote:
>>
>> On Wed, Sep 26, 2012 at 10:32 PM, David Marlin <dmarlin at redhat.com> wrote:
>>
>>>
>>> As discussed in our meeting today, I have submitted a BZ for the kernel
>>> boot
>>> from MMC issue:
>>>
>>>   https://bugzilla.redhat.com/show_bug.cgi?id=860855
>>>
>>> A patch that includes the config changes we tested is attached to the BZ.
>>> They are based on the last known-good (booting) kernel for OMAP and
>>> Tegra.
>>>
>>> If these are acceptable, will someone with commit privileges please apply
>>> the changes and push it out.  If you prefer to submit a scratch build of
>>> the
>>> changes first (which I recommend), Paul Whalen and I will be happy to
>>> test
>>> the resulting images to confirm they work as expected.
>>>
>>> Please reply with any questions or comments.
>>>
>>
>>
>> I have some issues with it. For example why do you enable these:
>>
>
> I did not do a complete analysis of all options.  I simply compared (diff)
> with the MMC settings from last known-good config and reverted the changes,
> plus I added the DMA changes from the email list.
>
>>
>> +CONFIG_MMC_SPI=m
>> +CONFIG_MMC_USHC=m
>>
>
> Although I don't have the link, at least one message board was discussing
> this, and MMC_SPI was recommended to be included, but I did not specifically
> test that is was required.  MMC_USHC was just an option from the previous
> (working) config.
>
>
>> when they're not used by OMAP, similarly the following aren't even
>> part of a tegra platform
>>
>> +CONFIG_MMC_SDHCI_PXAV3=m
>> +CONFIG_MMC_SDHCI_PXAV2=m
>>
>
> Ok, I questioned these too, but they were in the previous (working) config,
> and since it takes many hours to build the kernels, I just put them in to
> see if it would boot.  I have no objection to removing them (and others) if
> not required.
>
>
>> What's more dgilmore and I were discussing the following change:
>>
>> +CONFIG_DMADEVICES=y
>> +CONFIG_DMA_OMAP=m
>>
>> Which resulted in a booting system as can be seen here:
>>
>> http://fpaste.org/BJLj/
>>
>
> Did that actually boot to a login prompt.  The last thing I see in the paste
> is:
>
> -----------------
>
> [   11.973571] omap_hsmmc omap_hsmmc.0: Failed to get debounce clk
> [   11.980590] dmaengine: __dma_request_channel: fail ((null))
> [   11.987426] omap_hsmmc omap_hsmmc.0: unable to obtain RX DMA engine
> channel 62
> [   11.995666] omap_hsmmc omap_hsmmc.4: Failed to get debounce clk
> [   12.002319] dmaengine: __dma_request_channel: fail ((null))
> [   12.008209] omap_hsmmc omap_hsmmc.4: unable to obtain RX DMA engine
> channel 60
>
> -----------------
>
> which appear to be DMA errors.

Google tells me at least some of those are spurious errors.

http://old.nabble.com/-PATCH-V2--omap_hsmmc:-Fix-for-the-db-clock-failure-message-td25047778.html

> We also found that verbose debugging on DMA was far too noisy to be useful
> on the serial console (constant stream of messages), which is why we
> included:
>
> # CONFIG_DMADEVICES_VDEBUG is not set
>
> There was one remaining message that streamed to the console, so I added the
> attached patch to make the debug message a 'verbose debug' message.  I think
> this patch might be appropriate to push upstream (as that message, at least
> on OMAP, is quite verbose).
>
>
>> I'm building a scratch kernel now for OMAP to see if it works (it also
>> has some other OMAP changes) and once has been tested we can move onto
>> the likely similar fix for tegra.
>>
>> http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=1156419
>>
>
>
> Ok, please let us know how it goes, and when we can test on both Panda and
> Trim Slice.
>
>
> d.marlin
> =========
>>
>> Peter
>>
>
>