On Thu, Sep 27, 2012 at 1:41 PM, David A. Marlin <dmarlin@xxxxxxxxxx> wrote: > Peter Robinson wrote: >> >> On Wed, Sep 26, 2012 at 10:32 PM, David Marlin <dmarlin@xxxxxxxxxx> 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 >> > > _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
