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,
Quoted 10 lines · tbultel at free.fr
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.
Quoted 8 lines
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).
Quoted 2 lines
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.
Quoted 3 lines
My concern is that
clk_configdoes not seem to be available anymore, there isget_mcu_main_clkbut no set routine.
It was never available in mainline.
Quoted 2 lines
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
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
Le 18/03/2014 13:34, Stefano Babic a ?crit :
Quoted 29 lines
Hi Thierry,
Quoted 9 lines · tbultel at free.fr
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.Quoted 8 lines
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).Quoted 2 lines
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.
Quoted 8 lines
Quoted 2 lines
My concern is that
clk_configdoes not seem to be available anymore, there isget_mcu_main_clkbut no set routine.It was never available in mainline.
Quoted 2 lines
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
Quoted 3 lines
Best regards,
Stefano Babic
Hi Thierry,
Quoted 15 lines · Thierry Bultel
Le 18/03/2014 13:34, Stefano Babic a ?crit :
Quoted 13 lines
Hi Thierry,
Quoted 10 lines · tbultel at free.fr
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.
Quoted 9 lines
<snip>
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.
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.
Quoted 5 lines
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:
[...]
Quoted 7 lines
Quoted 2 lines
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.
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
Quoted 4 lines
.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 ?
Quoted 9 lines
Quoted 5 lines
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.
Quoted 6 lines
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,
Quoted 12 lines · Marek Vasut
On Friday, March 21, 2014 at 11:50:18 PM, Eric Nelson wrote:
[...]
Quoted 7 lines
Quoted 2 lines
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.
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
Quoted 9 lines
Quoted 4 lines
.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.
Quoted 11 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 7 lines
If you want it disabled, just submit a patch, either way WFM.
Quoted 5 lines
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.
Quoted 5 lines
Quoted 1 line
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.
Quoted 7 lines
[...]
[1] http://lists.denx.de/pipermail/u-boot/2014-February/172496.html
Best regards,
Marek Vasut
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
In reply to Marek VasutUse 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.
--- include/configs/nitrogen6x.h | 1 - 1 file changed, 1 deletion(-)
include/configs/nitrogen6x.h +0 -1
@@ -356,7 +356,6 @@/* * PCI express */ -#define CONFIG_CMD_PCI #ifdef CONFIG_CMD_PCI #define CONFIG_PCI #define CONFIG_PCI_PNP
Signature · 1 line
1.8.3.2
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
Quoted 8 lines · Eric Nelson
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 <[email protected]>
:-(
Best regards,
Marek Vasut
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
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 :
Quoted 15 lines · Eric Nelson
Quoted 8 lines
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 <[email protected]>:-(
Acked-by Marek Vasut <[email protected]>Best regards,
Marek Vasut
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
Hi Thierry,
Quoted 5 lines · Thierry Bultel
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.
Quoted 4 lines
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.
Quoted 3 lines
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.
Quoted 3 lines
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
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
Quoted 11 lines · Eric Nelson
Hi Thierry,
Quoted 4 lines · Thierry Bultel
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.
Quoted 8 lines
Quoted 4 lines
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
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
In reply to Thierry BultelQuoted 4 lines · Thierry Bultel
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 ;-)
Quoted 3 lines
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]).
Quoted 2 lines
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.
Quoted 4 lines
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
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
In reply to Thierry BultelQuoted 5 lines · Thierry Bultel
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
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
In reply to Marek VasutQuoted 5 lines · Marek Vasut
Quoted 4 lines · Eric Nelson
Use of PCIe on SABRE Lite and Nitrogen6x boards is atypical and requires the use of custom daughter boards.
Quoted 9 lines
Quoted 4 lines
Use in U-Boot is even rarer, so this patch removes it from the standard configuration.
Signed-off-by Eric Nelson <[email protected]>:-(
Acked-by Marek Vasut <[email protected]>
Thanks all. I'll merge it for the release.
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================
PATCH 1/1 ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x
In reply to Eric NelsonQuoted 9 lines · Eric Nelson
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 <[email protected]>---
Applied to u-boot-imx, thanks !
Best regards,
Stefano Babic
Signature · 5 lines
===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de =====================================================================