| Message ID | 1395501429-4872-1-git-send-email-eric.nelson@boundarydevices.com |
|---|---|
| State | Accepted |
| Delegated to: | Stefano Babic |
| Headers | show |
On Saturday, March 22, 2014 at 04:17:09 PM, Eric Nelson wrote: > Use of PCIe on SABRE Lite and Nitrogen6x boards > is atypical and requires the use of custom daughter > boards. > > Use in U-Boot is even rarer, so this patch removes it from > the standard configuration. > > Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> :-( Acked-by: Marek Vasut <marex@denx.de> Best regards, Marek Vasut
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. 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. 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. 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 Thierry Le 22/03/2014 19:26, Marek Vasut a écrit : > On Saturday, March 22, 2014 at 04:17:09 PM, Eric Nelson wrote: >> Use of PCIe on SABRE Lite and Nitrogen6x boards >> is atypical and requires the use of custom daughter >> boards. >> >> Use in U-Boot is even rarer, so this patch removes it from >> the standard configuration. >> >> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> > :-( > > Acked-by: Marek Vasut <marex@denx.de> > > Best regards, > Marek Vasut
Hi Thierry, On 03/22/2014 01:50 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. > I'm not sure I understand Marek's frustration. Marek's a capable guy, and certainly in a position to carry a 1-line patch around for his needs. > 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. > My first instinct is to say that if AMOS820 needs its' own setting, you can add a board for it and carry your own amos820.h. AFAIK, this can be done without code updates in board/boundary (i.e. add include/configs/amos820.h and an entry into boards.cfg). We have users of our SOM that do precisely this to configure boards for their use cases. It's our job primarily to support users of "actual" SABRE Lites and Nitrogen6X boards. > 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. > Sure. I pointed you at our tree, which likely has this fixed. > 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) ? Regards, Eric
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
On Saturday, March 22, 2014 at 10:49:25 PM, Eric Nelson wrote: > Hi Thierry, > > On 03/22/2014 01:50 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. > > I'm not sure I understand Marek's frustration. Marek's a capable > guy, and certainly in a position to carry a 1-line patch around > for his needs. Uh, I'm not frustrated, where did that come from ? There's like gazilion of things which do frustrate me now (like I'm not in Germany now so I cannot eat a tasty Frankenschmaus or Bratwurst), but this ... nah. > > 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. > > My first instinct is to say that if AMOS820 needs its' own > setting, you can add a board for it and carry your own > amos820.h. Yes, make a new board support with all you need in there (new board dir, new board config etc). [...] Best regards, Marek Vasut
On 22/03/2014 19:26, Marek Vasut wrote: > On Saturday, March 22, 2014 at 04:17:09 PM, Eric Nelson wrote: >> Use of PCIe on SABRE Lite and Nitrogen6x boards >> is atypical and requires the use of custom daughter >> boards. >> >> Use in U-Boot is even rarer, so this patch removes it from >> the standard configuration. >> >> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> > > :-( > > Acked-by: Marek Vasut <marex@denx.de> > Thanks all. I'll merge it for the release. Best regards, Stefano Babic
On 22/03/2014 21:50, 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. > The issue is the missing reset line. PCIe can be enabled as default for boards with the correct reset line. Suppression is not a standard for all boards. Best regards, Stefano Babic
On 22/03/2014 16:17, Eric Nelson wrote: > Use of PCIe on SABRE Lite and Nitrogen6x boards > is atypical and requires the use of custom daughter > boards. > > Use in U-Boot is even rarer, so this patch removes it from > the standard configuration. > > Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> > --- Applied to u-boot-imx, thanks ! Best regards, Stefano Babic
diff --git a/include/configs/nitrogen6x.h b/include/configs/nitrogen6x.h index f2db8c5..f7e7315 100644 --- a/include/configs/nitrogen6x.h +++ b/include/configs/nitrogen6x.h @@ -356,7 +356,6 @@ /* * PCI express */ -#define CONFIG_CMD_PCI #ifdef CONFIG_CMD_PCI #define CONFIG_PCI #define CONFIG_PCI_PNP
Use of PCIe on SABRE Lite and Nitrogen6x boards is atypical and requires the use of custom daughter boards. Use in U-Boot is even rarer, so this patch removes it from the standard configuration. Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com> --- include/configs/nitrogen6x.h | 1 - 1 file changed, 1 deletion(-)