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.
Thank you,
d.marlin
On Wed, Sep 26, 2012 at 10:32 PM, David Marlin dmarlin@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:
+CONFIG_MMC_SPI=m +CONFIG_MMC_USHC=m
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
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:
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
Peter
Peter Robinson wrote:
On Wed, Sep 26, 2012 at 10:32 PM, David Marlin dmarlin@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:
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.
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
On Thu, Sep 27, 2012 at 1:41 PM, David A. Marlin dmarlin@redhat.com wrote:
Peter Robinson wrote:
On Wed, Sep 26, 2012 at 10:32 PM, David Marlin dmarlin@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:
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-me...
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
-
d.marlin -
Peter Robinson