On Saturday, March 22, 2014 at 09:50:52 PM, Thierry Bultel wrote:
When I communicated about the bug I had, and said that my temporary workaround was to disable the PCIe, my intention was not to make the suppression become a standard, and I believe it is a little bit frustrating for Marek.
It's not frustrating for me ;-)
The AMOS820, based on the sabrelite/nitrogen has a PCIe slot on the main board, so there might be some interest of having the PCIe support enabled.
Do you have the PERST routed correctly and handled correctly ? If so, it does not matter whether or not you probed the PCIe bus in U-Boot , since toggling the PERST will cause Fundamental Reset (See [1]).
To my mind, the bug is in the kernel I am using, it should be robust to the fact that PCIe has been formerly probed.
Freescale's 3.0.35 is crap, that's no news. If possible (read: you don't need GPU/VPU), use mainline.
Wouldn't that be smarter to have the PCIe enabled or not, by an environment variable (defaulted to YES, and that the user could set to NO eventually for older kernels) ? Best regards
No, read [1] and probably the entire thread . For example [2] is also of interest here. If you soft-reset the system, your PCIe link will still be up from the previously running Linux instance (just like if it was started in U- Boot) and you'll run into the same problem with the newly booted instance if Linux kernel.
So once again, did you correctly implement PERST so you can do FR properly ?
[1] http://lists.denx.de/pipermail/u-boot/2014-February/172496.html [2] http://lists.denx.de/pipermail/u-boot/2014-February/172509.html
Best regards, Marek Vasut