[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0
Hi,
I am working on a board (AMOS820 from Via) based on the mx6qsabrelite.
The BSP provided by the manufacturer is quite old. I managed to port it from Freescale uboot-imx rel_imx_3.0.35_4.1.0 to u-boot mainline, and basically the latest issue I have is the cpu frequency.
The kernel I use is the rel_imx_3.0.35_4.1.0 as well (same tag name)
With the old u-boot, it runs at 1Ghz because the BSP explicitly has a call to
clk_config(CONFIG_REF_CLK_FREQ, 1000, CPU_CLK);
With the new u-boot, it runs at default freq which is 800Mhz (at least, what I guess from the Bogomips because no other log says it) I have attempted to pass "arm_freq=1000" to the boot args but that does not change anything.
My concern is that clk_config does not seem to be available anymore, there is get_mcu_main_clk but no set routine.
I wonder if it is intentional, I could write a set routine but I wonder if it could be accepted as a patch. What it your advice about it ?
Regards Thierry
Hi Thierry,
On 18/03/2014 12:28, tbultel@free.fr wrote:
Hi,
I am working on a board (AMOS820 from Via) based on the mx6qsabrelite.
The BSP provided by the manufacturer is quite old. I managed to port it from Freescale uboot-imx rel_imx_3.0.35_4.1.0 to u-boot mainline, and basically the latest issue I have is the cpu frequency.
The kernel I use is the rel_imx_3.0.35_4.1.0 as well (same tag name)
With the old u-boot, it runs at 1Ghz because the BSP explicitly has a call to
clk_config(CONFIG_REF_CLK_FREQ, 1000, CPU_CLK);
With the new u-boot, it runs at default freq which is 800Mhz (at least, what I guess from the Bogomips because no other log says it)
It is can taken as reference, but checking the BogoMIPS is not the right way to proof it. You should take a look at the CCM registers when Linux is running ( CCM_ANALOG_PLL_ARM).
I have attempted to pass "arm_freq=1000" to the boot args but that does not change anything.
Well, this is a kernel issue, and related to an ancient version.
My concern is that clk_config does not seem to be available anymore, there is get_mcu_main_clk but no set routine.
It was never available in mainline.
I wonder if it is intentional, I could write a set routine but I wonder if it could be accepted as a patch.
Why not ? All patches are discussed here and if it makes sense to merge it, it will be merged.
Best regards, Stefano Babic
Le 18/03/2014 13:34, Stefano Babic a écrit :
Hi Thierry,
On 18/03/2014 12:28, tbultel@free.fr wrote:
Hi,
I am working on a board (AMOS820 from Via) based on the mx6qsabrelite.
The BSP provided by the manufacturer is quite old. I managed to port it from Freescale uboot-imx rel_imx_3.0.35_4.1.0 to u-boot mainline, and basically the latest issue I have is the cpu frequency.
The kernel I use is the rel_imx_3.0.35_4.1.0 as well (same tag name)
With the old u-boot, it runs at 1Ghz because the BSP explicitly has a call to
clk_config(CONFIG_REF_CLK_FREQ, 1000, CPU_CLK);
With the new u-boot, it runs at default freq which is 800Mhz (at least, what I guess from the Bogomips because no other log says it)
It is can taken as reference, but checking the BogoMIPS is not the right way to proof it. You should take a look at the CCM registers when Linux is running ( CCM_ANALOG_PLL_ARM).
I have attempted to pass "arm_freq=1000" to the boot args but that does not change anything.
Well, this is a kernel issue, and related to an ancient version.
My concern is that clk_config does not seem to be available anymore, there is get_mcu_main_clk but no set routine.
It was never available in mainline.
I wonder if it is intentional, I could write a set routine but I wonder if it could be accepted as a patch.
Why not ? All patches are discussed here and if it makes sense to merge it, it will be merged.
Hi Stefano, many thanks for your advice,
It is now running at 1Ghz. I still have a couple of issues that prevent me to submit a patch as is:
1) The kernel (old, I know) I am using does not like that PCIe to have been formerly probed by u-boot. It hangs at probing if so. Thus I have to patch my kernel, or add an environment variable to not initialize PCIe when set, in order to keep compatible with old kernels. For now, in order to boot, I have temporary disabled PCIe support in U-boot.
2) The splashscreen (loaded at 10000000) disappears when loading the kernel Would you have any idea or hints about it ?
Best Regards Thierry
Best regards, Stefano Babic
Hi Thierry,
On 03/21/2014 11:47 AM, Thierry Bultel wrote:
Le 18/03/2014 13:34, Stefano Babic a écrit :
Hi Thierry,
On 18/03/2014 12:28, tbultel@free.fr wrote:
Hi,
I am working on a board (AMOS820 from Via) based on the mx6qsabrelite.
The BSP provided by the manufacturer is quite old. I managed to port it from Freescale uboot-imx rel_imx_3.0.35_4.1.0 to u-boot mainline, and basically the latest issue I have is the cpu frequency.
<snip>
It is now running at 1Ghz. I still have a couple of issues that prevent me to submit a patch as is:
- The kernel (old, I know) I am using does not like that PCIe to have
been formerly probed by u-boot. It hangs at probing if so.
We haven't had any trouble with our boundary-imx_3.0.35_4.1.0 branch (which is based on rel_imx_3.0.35_4.1.0):
https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.0.35_4.1.0
You might give that a pin and see if it works for you. Troy did make some modifications to PCIe in that tree.
Thus I have to patch my kernel, or add an environment variable to not initialize PCIe when set, in order to keep compatible with old kernels. For now, in order to boot, I have temporary disabled PCIe support in U-boot.
Thanks for the ping.
Marek, I didn't catch that you had enabled PCIE by default.
Since there aren't any peripherals which depend on this, and even the PCIe daughter board is an extra-cost item, I'd prefer to leave this disabled and require the user to enable it specifically.
AFAIK, you're the only one who's tested this.
Let me know if you disagree and if you'd like me to work up the patch.
Regards,
Eric
On Friday, March 21, 2014 at 11:50:18 PM, Eric Nelson wrote:
[...]
- The kernel (old, I know) I am using does not like that PCIe to have
been formerly probed by u-boot. It hangs at probing if so.
We haven't had any trouble with our boundary-imx_3.0.35_4.1.0 branch (which is based on rel_imx_3.0.35_4.1.0):
https://github.com/boundarydevices/linux-imx6/tree/boundary-
imx_3.0.35_4.1
.0
You might give that a pin and see if it works for you. Troy did make some modifications to PCIe in that tree.
Let me remind you about that PCIe reset pin [1] again ... so, did you wire your PCIe slot's nRESET line or not on this design? Do you operate the nRESET correctly ?
Thus I have to patch my kernel, or add an environment variable to not initialize PCIe when set, in order to keep compatible with old kernels.
For now, in order to boot, I have temporary disabled PCIe support in U-boot.
Thanks for the ping.
Marek, I didn't catch that you had enabled PCIE by default.
Maybe Stefano applied the patch which enabled the PCIe on SL ? If you want it disabled, just submit a patch, either way WFM.
Since there aren't any peripherals which depend on this, and even the PCIe daughter board is an extra-cost item, I'd prefer to leave this disabled and require the user to enable it specifically.
AFAIK, you're the only one who's tested this.
Didn't you guys also test that ? But yes, I'm OK either way, feel free to send a patch.
[...]
[1] http://lists.denx.de/pipermail/u-boot/2014-February/172496.html
Best regards, Marek Vasut
Thanks Marek,
On 03/21/2014 06:33 PM, Marek Vasut wrote:
On Friday, March 21, 2014 at 11:50:18 PM, Eric Nelson wrote:
[...]
- The kernel (old, I know) I am using does not like that PCIe to have
been formerly probed by u-boot. It hangs at probing if so.
We haven't had any trouble with our boundary-imx_3.0.35_4.1.0 branch (which is based on rel_imx_3.0.35_4.1.0):
https://github.com/boundarydevices/linux-imx6/tree/boundary-
imx_3.0.35_4.1
.0
You might give that a pin and see if it works for you. Troy did make some modifications to PCIe in that tree.
Let me remind you about that PCIe reset pin [1] again ... so, did you wire your PCIe slot's nRESET line or not on this design? Do you operate the nRESET correctly ?
:) It's a little late in the game for that, with lots of boards in the wild.
Thus I have to patch my kernel, or add an environment variable to not initialize PCIe when set, in order to keep compatible with old kernels.
For now, in order to boot, I have temporary disabled PCIe support in U-boot.
Thanks for the ping.
Marek, I didn't catch that you had enabled PCIE by default.
Maybe Stefano applied the patch which enabled the PCIe on SL ?
No worries.
If you want it disabled, just submit a patch, either way WFM.
Since there aren't any peripherals which depend on this, and even the PCIe daughter board is an extra-cost item, I'd prefer to leave this disabled and require the user to enable it specifically.
AFAIK, you're the only one who's tested this.
Didn't you guys also test that ? But yes, I'm OK either way, feel free to send a patch.
Right. We did test. What I should have said was that we're not "using" this feature...
Patch on the way.
[...]
[1] http://lists.denx.de/pipermail/u-boot/2014-February/172496.html
Best regards, Marek Vasut
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(-)
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
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 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 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 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 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 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
participants (5)
-
Eric Nelson -
Marek Vasut -
Stefano Babic -
tbultel＠free.fr -
Thierry Bultel