Peter Robinson wrote:
On Wed, Sep 26, 2012 at 10:32 PM, David Marlin
> As discussed in our meeting today, I have submitted a BZ for the kernel boot
> from MMC issue:
> 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.
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
part of a tegra platform
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:
Which resulted in a booting system as can be seen here:
Did that actually boot to a login prompt. The last thing I see in the
[ 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.
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
# 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
has some other OMAP changes) and once has been tested we can move onto
the likely similar fix for tegra.
Ok, please let us know how it goes, and when we can test on both Panda
and Trim Slice.