[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0

[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0

[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.

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

[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0

[Stefano Babic]

Hi Thierry,


On 18/03/2014 12:28, tbultel at 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

-- 
=====================================================================
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
=====================================================================

[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0

[Thierry Bultel]

Le 18/03/2014 13:34, Stefano Babic a ?crit :
> Hi Thierry,
>
>
> On 18/03/2014 12:28, tbultel at 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
>

[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0

[Eric Nelson]

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 at 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:
>
> 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.

> 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

[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0

[Marek Vasut]

On Friday, March 21, 2014 at 11:50:18 PM, Eric Nelson wrote:

[...]

> > 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.

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

[U-Boot] Running mx6qsabrelite at 1Gz with Freescale kernel rel_imx_3.0.35_4.1.0

[Eric Nelson]

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:
>
> [...]
>
>>> 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.
>
> 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
 >

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[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 <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
-- 
1.8.3.2

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[Marek Vasut]

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

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[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 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

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[Eric Nelson]

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

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[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

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[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

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[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

-- 
=====================================================================
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
=====================================================================

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[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


-- 
=====================================================================
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
=====================================================================

[U-Boot] [PATCH] ARM: mx6: Disable PCIe on SABRE Lite/Nitrogen6x

[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

-- 
=====================================================================
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
=====================================================================