Should all T4240 errata be applied to T1040?

Should all T4240 errata be applied to T1040?

[Bob Cochran]

I find that during initialization of my T1040rdb-64b using the kernel 
built with meta-fsl-ppc master, the FMBM_CFG2.TNTASKS field (total 
number of BMI tasks) is being overwritten to 0x7b (the reset value is 
documented as 0x3b in the T1040 reference manual).

I believe this is being overwritten due to sharing the errata 
definitions with the T4240, but this particular erratum may not apply to 
the T1040 and may cause undesirable side effects.

The T4240 uses DPAA FMAN_v3H, and the T1040 uses DPAA FMAN_v3L.


Here is my understanding of how this erratum (A005127) is being applied 
to the T1040:

1) t1040_64bit_smp_defconfig defines CONFIG_FMAN_T4240

2) By defining CONFIG_FMAN_T4240, 
drivers/net/ethernet/freescale/fman/ncsw_config.mk adds 
-I$(FMAN)/inc/integrations/T4240 to EXTRA_CFLAGS.

3) dpaa_integration_ext.h is included throughout the fman source files 
from drivers/net/ethernet/freescale/fman/inc/integrations/T4240

4) This defines FM_WRONG_RESET_VALUES_ERRATA_FMAN_A005127, but it is my 
understanding that this erratum does not apply to the T1040.

5) This results in FMBM_CFG2.TNTASKS being overwritten with a value 
approximately twice its default value, and my concern is that the 
FMAN_V3L does not have the resources to support this many tasks.



In general, I'm also wondering whether the other errata in the 
integration file is appropriate for the T1040 and whether the FMAN_v3L 
devices should have their own integration tree.

Re: Should all T4240 errata be applied to T1040?

[zhenhua.luo]

Hi Bob, 

Thanks for the great finding. 

Defining the CONFIG_FMAN_T4240 for T1 is inaccurate and potentially dangerous for the correct function. The manual explicitly states for TNTSKS that exceeding the max supported values is not permitted, but it doesn't actually state that the reset value is the maximum permissible value. 

As for the correct way to define things, we probably need to share integrations across common SoCs per, e.g., Table A-5 in the T1040 DPAA RM to make SW match our docs properly. A configuration "T4240" is likely a bad one anyway if we should name it effectively "FMAN_V3H_384KiB" vs. "FMAN_V3H_512KiB" for B4860 rev 2.  So it is good to change "FMAN_V3L" for T1 to match the documentation and part behavior.

Also the correct way is to stop configuring such things at compile time to avoid separate kernel build for every FMan revision.


Best Regards,

Zhenhua

> -----Original Message-----
> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> bounces@yoctoproject.org] On Behalf Of Bob Cochran
> Sent: Thursday, September 18, 2014 11:44 AM
> To: meta-freescale@yoctoproject.org
> Subject: [meta-freescale] Should all T4240 errata be applied to T1040?
> 
> I find that during initialization of my T1040rdb-64b using the kernel built with
> meta-fsl-ppc master, the FMBM_CFG2.TNTASKS field (total number of BMI
> tasks) is being overwritten to 0x7b (the reset value is documented as 0x3b in
> the T1040 reference manual).
> 
> I believe this is being overwritten due to sharing the errata definitions with the
> T4240, but this particular erratum may not apply to the T1040 and may cause
> undesirable side effects.
> 
> The T4240 uses DPAA FMAN_v3H, and the T1040 uses DPAA FMAN_v3L.
> 
> 
> Here is my understanding of how this erratum (A005127) is being applied to the
> T1040:
> 
> 1) t1040_64bit_smp_defconfig defines CONFIG_FMAN_T4240
> 
> 2) By defining CONFIG_FMAN_T4240,
> drivers/net/ethernet/freescale/fman/ncsw_config.mk adds
> -I$(FMAN)/inc/integrations/T4240 to EXTRA_CFLAGS.
> 
> 3) dpaa_integration_ext.h is included throughout the fman source files from
> drivers/net/ethernet/freescale/fman/inc/integrations/T4240
> 
> 4) This defines FM_WRONG_RESET_VALUES_ERRATA_FMAN_A005127, but it is
> my understanding that this erratum does not apply to the T1040.
> 
> 5) This results in FMBM_CFG2.TNTASKS being overwritten with a value
> approximately twice its default value, and my concern is that the FMAN_V3L
> does not have the resources to support this many tasks.
> 
> 
> 
> In general, I'm also wondering whether the other errata in the integration file is
> appropriate for the T1040 and whether the FMAN_v3L devices should have
> their own integration tree.
> 
> 
> 
> 
> 
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale

Re: Should all T4240 errata be applied to T1040?

[Bob Cochran]

On 09/19/2014 06:04 AM, zhenhua.luo@freescale.com wrote:
> Hi Bob,
>
> Thanks for the great finding.
>
> Defining the CONFIG_FMAN_T4240 for T1 is inaccurate and potentially dangerous for the correct function. The manual explicitly states for TNTSKS that exceeding the max supported values is not permitted, but it doesn't actually state that the reset value is the maximum permissible value.
>
> As for the correct way to define things, we probably need to share integrations across common SoCs per, e.g., Table A-5 in the T1040 DPAA RM to make SW match our docs properly. A configuration "T4240" is likely a bad one anyway if we should name it effectively "FMAN_V3H_384KiB" vs. "FMAN_V3H_512KiB" for B4860 rev 2.  So it is good to change "FMAN_V3L" for T1 to match the documentation and part behavior.
>
> Also the correct way is to stop configuring such things at compile time to avoid separate kernel build for every FMan revision.


Thank you for the quick reply Zhenhua.  Your proposed solution makes 
sense to me.

I'm seeing other registers that have their values set to FMAN_v3H rather 
than FMAN_v3L values, and I'm trying to track them down in the source to 
see whether they are being incorrectly set (or maybe the doc is wrong?).

Perhaps I'll send you a list of suspicious register settings in the next 
few days.

I continue to investigate the DPAA to hopefully resolve CPU hangs & oops 
during network loading.

Bob








>
>
> Best Regards,
>
> Zhenhua
>
>> -----Original Message-----
>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>> bounces@yoctoproject.org] On Behalf Of Bob Cochran
>> Sent: Thursday, September 18, 2014 11:44 AM
>> To: meta-freescale@yoctoproject.org
>> Subject: [meta-freescale] Should all T4240 errata be applied to T1040?
>>
>> I find that during initialization of my T1040rdb-64b using the kernel built with
>> meta-fsl-ppc master, the FMBM_CFG2.TNTASKS field (total number of BMI
>> tasks) is being overwritten to 0x7b (the reset value is documented as 0x3b in
>> the T1040 reference manual).
>>
>> I believe this is being overwritten due to sharing the errata definitions with the
>> T4240, but this particular erratum may not apply to the T1040 and may cause
>> undesirable side effects.
>>
>> The T4240 uses DPAA FMAN_v3H, and the T1040 uses DPAA FMAN_v3L.
>>
>>
>> Here is my understanding of how this erratum (A005127) is being applied to the
>> T1040:
>>
>> 1) t1040_64bit_smp_defconfig defines CONFIG_FMAN_T4240
>>
>> 2) By defining CONFIG_FMAN_T4240,
>> drivers/net/ethernet/freescale/fman/ncsw_config.mk adds
>> -I$(FMAN)/inc/integrations/T4240 to EXTRA_CFLAGS.
>>
>> 3) dpaa_integration_ext.h is included throughout the fman source files from
>> drivers/net/ethernet/freescale/fman/inc/integrations/T4240
>>
>> 4) This defines FM_WRONG_RESET_VALUES_ERRATA_FMAN_A005127, but it is
>> my understanding that this erratum does not apply to the T1040.
>>
>> 5) This results in FMBM_CFG2.TNTASKS being overwritten with a value
>> approximately twice its default value, and my concern is that the FMAN_V3L
>> does not have the resources to support this many tasks.
>>
>>
>>
>> In general, I'm also wondering whether the other errata in the integration file is
>> appropriate for the T1040 and whether the FMAN_v3L devices should have
>> their own integration tree.
>>
>>
>>
>>
>>
>> --
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: Should all T4240 errata be applied to T1040?

[Bob Cochran]

On 09/19/2014 06:04 AM, zhenhua.luo@freescale.com wrote:
> Hi Bob,
>
> Thanks for the great finding.
>
> Defining the CONFIG_FMAN_T4240 for T1 is inaccurate and potentially dangerous for the correct function. The manual explicitly states for TNTSKS that exceeding the max supported values is not permitted, but it doesn't actually state that the reset value is the maximum permissible value.
>
> As for the correct way to define things, we probably need to share integrations across common SoCs per, e.g., Table A-5 in the T1040 DPAA RM to make SW match our docs properly. A configuration "T4240" is likely a bad one anyway if we should name it effectively "FMAN_V3H_384KiB" vs. "FMAN_V3H_512KiB" for B4860 rev 2.  So it is good to change "FMAN_V3L" for T1 to match the documentation and part behavior.
>
> Also the correct way is to stop configuring such things at compile time to avoid separate kernel build for every FMan revision.


Zhenhua,

I believe a similar issue exists with the dts files.

fsl/qoriq-fman3-0.dtsi defines two O/H ports that don't exist on the 
T1040.

After setting CONFIG_FMAN_V3L,  FM_MAX_NUM_OF_OH_PORTS was defined as 4 
in T4240/dpaa_integration_ext.h.  This matches what I see in the T1040 
SoC RM.

However, during boot, I see errors reported on the command line from the 
FM module:

Freescale FM module (Sep 26 2014:14:25:29), FMD API version 21.1.0
cpu1/1: ! MAJOR FM Error [CPU01, 
drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272 
ReadFmPortDevTreeNode]: Invalid Value;
cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@86000, 
cell-index) failedcpu1/1:

fsl-fman-port: probe of ffe486000.port failed with error -5
cpu1/1: ! MAJOR FM Error [CPU01, 
drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272 
ReadFmPortDevTreeNode]: Invalid Value;
cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@87000, 
cell-index) failedcpu1/1:

If I remove the extra O/H ports in my dts file, the errors go away.
	
So, if we follow your suggestion, I believe we should add a 
qoriq-fman3l-0.dtsi file that excludes the non-existent O/H ports.

However, I need some feedback because my T1040 DPAA Reference Manual 
Table A-47 states that the number of O/H ports are SoC specific, so 
maybe some V3L devices actually have these extra O/H ports???

And fsl/t1040si-post.dtsi also specifies the extra two O/H ports, but 
that's a straight forward patch.

Finally, who will do these patches for proper V3H/V3L support (me or 
FSL)?  If I do it, I'm just going to work through the issues with the 
T1040 / V3L (I can't address B4860 rev 2 - don't have the specs & don't 
want them).

Thanks,

Bob
















>
>
> Best Regards,
>
> Zhenhua
>
>> -----Original Message-----
>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>> bounces@yoctoproject.org] On Behalf Of Bob Cochran
>> Sent: Thursday, September 18, 2014 11:44 AM
>> To: meta-freescale@yoctoproject.org
>> Subject: [meta-freescale] Should all T4240 errata be applied to T1040?
>>
>> I find that during initialization of my T1040rdb-64b using the kernel built with
>> meta-fsl-ppc master, the FMBM_CFG2.TNTASKS field (total number of BMI
>> tasks) is being overwritten to 0x7b (the reset value is documented as 0x3b in
>> the T1040 reference manual).
>>
>> I believe this is being overwritten due to sharing the errata definitions with the
>> T4240, but this particular erratum may not apply to the T1040 and may cause
>> undesirable side effects.
>>
>> The T4240 uses DPAA FMAN_v3H, and the T1040 uses DPAA FMAN_v3L.
>>
>>
>> Here is my understanding of how this erratum (A005127) is being applied to the
>> T1040:
>>
>> 1) t1040_64bit_smp_defconfig defines CONFIG_FMAN_T4240
>>
>> 2) By defining CONFIG_FMAN_T4240,
>> drivers/net/ethernet/freescale/fman/ncsw_config.mk adds
>> -I$(FMAN)/inc/integrations/T4240 to EXTRA_CFLAGS.
>>
>> 3) dpaa_integration_ext.h is included throughout the fman source files from
>> drivers/net/ethernet/freescale/fman/inc/integrations/T4240
>>
>> 4) This defines FM_WRONG_RESET_VALUES_ERRATA_FMAN_A005127, but it is
>> my understanding that this erratum does not apply to the T1040.
>>
>> 5) This results in FMBM_CFG2.TNTASKS being overwritten with a value
>> approximately twice its default value, and my concern is that the FMAN_V3L
>> does not have the resources to support this many tasks.
>>
>>
>>
>> In general, I'm also wondering whether the other errata in the integration file is
>> appropriate for the T1040 and whether the FMAN_v3L devices should have
>> their own integration tree.
>>
>>
>>
>>
>>
>> --
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale
>

Re: Should all T4240 errata be applied to T1040?

[zhenhua.luo]

Bob, 

Thanks for your comments. 

FSL SDK developer will fix the issue in QorIQ SDK 1.7(Dec-2014). 


Best Regards,

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Saturday, September 27, 2014 11:36 PM
> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
> Cc: Wood Scott-B07421; Wrobel Heinz-R39252
> Subject: Re: [meta-freescale] Should all T4240 errata be applied to T1040?
> 
> On 09/19/2014 06:04 AM, zhenhua.luo@freescale.com wrote:
> > Hi Bob,
> >
> > Thanks for the great finding.
> >
> > Defining the CONFIG_FMAN_T4240 for T1 is inaccurate and potentially
> dangerous for the correct function. The manual explicitly states for TNTSKS that
> exceeding the max supported values is not permitted, but it doesn't actually
> state that the reset value is the maximum permissible value.
> >
> > As for the correct way to define things, we probably need to share
> integrations across common SoCs per, e.g., Table A-5 in the T1040 DPAA RM to
> make SW match our docs properly. A configuration "T4240" is likely a bad one
> anyway if we should name it effectively "FMAN_V3H_384KiB" vs.
> "FMAN_V3H_512KiB" for B4860 rev 2.  So it is good to change "FMAN_V3L" for
> T1 to match the documentation and part behavior.
> >
> > Also the correct way is to stop configuring such things at compile time to
> avoid separate kernel build for every FMan revision.
> 
> 
> Zhenhua,
> 
> I believe a similar issue exists with the dts files.
> 
> fsl/qoriq-fman3-0.dtsi defines two O/H ports that don't exist on the T1040.
> 
> After setting CONFIG_FMAN_V3L,  FM_MAX_NUM_OF_OH_PORTS was
> defined as 4 in T4240/dpaa_integration_ext.h.  This matches what I see in the
> T1040 SoC RM.
> 
> However, during boot, I see errors reported on the command line from the FM
> module:
> 
> Freescale FM module (Sep 26 2014:14:25:29), FMD API version 21.1.0
> cpu1/1: ! MAJOR FM Error [CPU01,
> drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272
> ReadFmPortDevTreeNode]: Invalid Value;
> cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@86000,
> cell-index) failedcpu1/1:
> 
> fsl-fman-port: probe of ffe486000.port failed with error -5
> cpu1/1: ! MAJOR FM Error [CPU01,
> drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272
> ReadFmPortDevTreeNode]: Invalid Value;
> cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@87000,
> cell-index) failedcpu1/1:
> 
> If I remove the extra O/H ports in my dts file, the errors go away.
> 
> So, if we follow your suggestion, I believe we should add a qoriq-fman3l-0.dtsi
> file that excludes the non-existent O/H ports.
> 
> However, I need some feedback because my T1040 DPAA Reference Manual
> Table A-47 states that the number of O/H ports are SoC specific, so maybe
> some V3L devices actually have these extra O/H ports???
> 
> And fsl/t1040si-post.dtsi also specifies the extra two O/H ports, but that's a
> straight forward patch.
> 
> Finally, who will do these patches for proper V3H/V3L support (me or FSL)?  If I
> do it, I'm just going to work through the issues with the
> T1040 / V3L (I can't address B4860 rev 2 - don't have the specs & don't want
> them).
> 
> Thanks,
> 
> Bob
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >> -----Original Message-----
> >> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
> >> bounces@yoctoproject.org] On Behalf Of Bob Cochran
> >> Sent: Thursday, September 18, 2014 11:44 AM
> >> To: meta-freescale@yoctoproject.org
> >> Subject: [meta-freescale] Should all T4240 errata be applied to T1040?
> >>
> >> I find that during initialization of my T1040rdb-64b using the kernel
> >> built with meta-fsl-ppc master, the FMBM_CFG2.TNTASKS field (total
> >> number of BMI
> >> tasks) is being overwritten to 0x7b (the reset value is documented as
> >> 0x3b in the T1040 reference manual).
> >>
> >> I believe this is being overwritten due to sharing the errata
> >> definitions with the T4240, but this particular erratum may not apply
> >> to the T1040 and may cause undesirable side effects.
> >>
> >> The T4240 uses DPAA FMAN_v3H, and the T1040 uses DPAA FMAN_v3L.
> >>
> >>
> >> Here is my understanding of how this erratum (A005127) is being
> >> applied to the
> >> T1040:
> >>
> >> 1) t1040_64bit_smp_defconfig defines CONFIG_FMAN_T4240
> >>
> >> 2) By defining CONFIG_FMAN_T4240,
> >> drivers/net/ethernet/freescale/fman/ncsw_config.mk adds
> >> -I$(FMAN)/inc/integrations/T4240 to EXTRA_CFLAGS.
> >>
> >> 3) dpaa_integration_ext.h is included throughout the fman source
> >> files from
> >> drivers/net/ethernet/freescale/fman/inc/integrations/T4240
> >>
> >> 4) This defines FM_WRONG_RESET_VALUES_ERRATA_FMAN_A005127, but
> it is
> >> my understanding that this erratum does not apply to the T1040.
> >>
> >> 5) This results in FMBM_CFG2.TNTASKS being overwritten with a value
> >> approximately twice its default value, and my concern is that the
> >> FMAN_V3L does not have the resources to support this many tasks.
> >>
> >>
> >>
> >> In general, I'm also wondering whether the other errata in the
> >> integration file is appropriate for the T1040 and whether the
> >> FMAN_v3L devices should have their own integration tree.
> >>
> >>
> >>
> >>
> >>
> >> --
> >> _______________________________________________
> >> meta-freescale mailing list
> >> meta-freescale@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/meta-freescale
> >

Re: Should all T4240 errata be applied to T1040?

[Bob Cochran]

On 10/14/2014 03:55 AM, zhenhua.luo@freescale.com wrote:
> Bob,
>
> Thanks for your comments.
>
> FSL SDK developer will fix the issue in QorIQ SDK 1.7(Dec-2014).


If that's the case, I'll set a goal to post my own patches to 
meta-fsl-ppc, but I would like to clean up the hangs I experience during 
network testing first (not sure when I'll have all this worked out).

Can we please use the Yocto project / FSL Community to test a beta of 
SDK1.7?  SDK1.6 on T1040RDB certainly would have benefited from 
additional testing.


>
>
> Best Regards,
>
> Zhenhua
>
>> -----Original Message-----
>> From: Bob Cochran [mailto:yocto@mindchasers.com]
>> Sent: Saturday, September 27, 2014 11:36 PM
>> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
>> Cc: Wood Scott-B07421; Wrobel Heinz-R39252
>> Subject: Re: [meta-freescale] Should all T4240 errata be applied to T1040?
>>
>> On 09/19/2014 06:04 AM, zhenhua.luo@freescale.com wrote:
>>> Hi Bob,
>>>
>>> Thanks for the great finding.
>>>
>>> Defining the CONFIG_FMAN_T4240 for T1 is inaccurate and potentially
>> dangerous for the correct function. The manual explicitly states for TNTSKS that
>> exceeding the max supported values is not permitted, but it doesn't actually
>> state that the reset value is the maximum permissible value.
>>>
>>> As for the correct way to define things, we probably need to share
>> integrations across common SoCs per, e.g., Table A-5 in the T1040 DPAA RM to
>> make SW match our docs properly. A configuration "T4240" is likely a bad one
>> anyway if we should name it effectively "FMAN_V3H_384KiB" vs.
>> "FMAN_V3H_512KiB" for B4860 rev 2.  So it is good to change "FMAN_V3L" for
>> T1 to match the documentation and part behavior.
>>>
>>> Also the correct way is to stop configuring such things at compile time to
>> avoid separate kernel build for every FMan revision.
>>
>>
>> Zhenhua,
>>
>> I believe a similar issue exists with the dts files.
>>
>> fsl/qoriq-fman3-0.dtsi defines two O/H ports that don't exist on the T1040.
>>
>> After setting CONFIG_FMAN_V3L,  FM_MAX_NUM_OF_OH_PORTS was
>> defined as 4 in T4240/dpaa_integration_ext.h.  This matches what I see in the
>> T1040 SoC RM.
>>
>> However, during boot, I see errors reported on the command line from the FM
>> module:
>>
>> Freescale FM module (Sep 26 2014:14:25:29), FMD API version 21.1.0
>> cpu1/1: ! MAJOR FM Error [CPU01,
>> drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272
>> ReadFmPortDevTreeNode]: Invalid Value;
>> cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@86000,
>> cell-index) failedcpu1/1:
>>
>> fsl-fman-port: probe of ffe486000.port failed with error -5
>> cpu1/1: ! MAJOR FM Error [CPU01,
>> drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272
>> ReadFmPortDevTreeNode]: Invalid Value;
>> cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@87000,
>> cell-index) failedcpu1/1:
>>
>> If I remove the extra O/H ports in my dts file, the errors go away.
>>
>> So, if we follow your suggestion, I believe we should add a qoriq-fman3l-0.dtsi
>> file that excludes the non-existent O/H ports.
>>
>> However, I need some feedback because my T1040 DPAA Reference Manual
>> Table A-47 states that the number of O/H ports are SoC specific, so maybe
>> some V3L devices actually have these extra O/H ports???
>>
>> And fsl/t1040si-post.dtsi also specifies the extra two O/H ports, but that's a
>> straight forward patch.
>>
>> Finally, who will do these patches for proper V3H/V3L support (me or FSL)?  If I
>> do it, I'm just going to work through the issues with the
>> T1040 / V3L (I can't address B4860 rev 2 - don't have the specs & don't want
>> them).
>>
>> Thanks,
>>
>> Bob
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>>
>>>
>>> Best Regards,
>>>
>>> Zhenhua
>>>
>>>> -----Original Message-----
>>>> From: meta-freescale-bounces@yoctoproject.org [mailto:meta-freescale-
>>>> bounces@yoctoproject.org] On Behalf Of Bob Cochran
>>>> Sent: Thursday, September 18, 2014 11:44 AM
>>>> To: meta-freescale@yoctoproject.org
>>>> Subject: [meta-freescale] Should all T4240 errata be applied to T1040?
>>>>
>>>> I find that during initialization of my T1040rdb-64b using the kernel
>>>> built with meta-fsl-ppc master, the FMBM_CFG2.TNTASKS field (total
>>>> number of BMI
>>>> tasks) is being overwritten to 0x7b (the reset value is documented as
>>>> 0x3b in the T1040 reference manual).
>>>>
>>>> I believe this is being overwritten due to sharing the errata
>>>> definitions with the T4240, but this particular erratum may not apply
>>>> to the T1040 and may cause undesirable side effects.
>>>>
>>>> The T4240 uses DPAA FMAN_v3H, and the T1040 uses DPAA FMAN_v3L.
>>>>
>>>>
>>>> Here is my understanding of how this erratum (A005127) is being
>>>> applied to the
>>>> T1040:
>>>>
>>>> 1) t1040_64bit_smp_defconfig defines CONFIG_FMAN_T4240
>>>>
>>>> 2) By defining CONFIG_FMAN_T4240,
>>>> drivers/net/ethernet/freescale/fman/ncsw_config.mk adds
>>>> -I$(FMAN)/inc/integrations/T4240 to EXTRA_CFLAGS.
>>>>
>>>> 3) dpaa_integration_ext.h is included throughout the fman source
>>>> files from
>>>> drivers/net/ethernet/freescale/fman/inc/integrations/T4240
>>>>
>>>> 4) This defines FM_WRONG_RESET_VALUES_ERRATA_FMAN_A005127, but
>> it is
>>>> my understanding that this erratum does not apply to the T1040.
>>>>
>>>> 5) This results in FMBM_CFG2.TNTASKS being overwritten with a value
>>>> approximately twice its default value, and my concern is that the
>>>> FMAN_V3L does not have the resources to support this many tasks.
>>>>
>>>>
>>>>
>>>> In general, I'm also wondering whether the other errata in the
>>>> integration file is appropriate for the T1040 and whether the
>>>> FMAN_v3L devices should have their own integration tree.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> _______________________________________________
>>>> meta-freescale mailing list
>>>> meta-freescale@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-freescale
>>>
>
>

Re: Should all T4240 errata be applied to T1040?

[zhenhua.luo]

Please post your patches to meta-fsl-ppc. Yocto 1.6(daisy) is used by SDK 1.7, the SDK 1.7 content will be submitted to master of meta-fsl-ppc when SDK 1.7 is formally released. 
       

Best Regards,

Zhenhua

> -----Original Message-----
> From: Bob Cochran [mailto:yocto@mindchasers.com]
> Sent: Wednesday, October 15, 2014 4:20 AM
> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
> Cc: Wood Scott-B07421; Wrobel Heinz-R39252
> Subject: Re: [meta-freescale] Should all T4240 errata be applied to T1040?
> 
> On 10/14/2014 03:55 AM, zhenhua.luo@freescale.com wrote:
> > Bob,
> >
> > Thanks for your comments.
> >
> > FSL SDK developer will fix the issue in QorIQ SDK 1.7(Dec-2014).
> 
> 
> If that's the case, I'll set a goal to post my own patches to meta-fsl-ppc, but I
> would like to clean up the hangs I experience during network testing first (not
> sure when I'll have all this worked out).
> 
> Can we please use the Yocto project / FSL Community to test a beta of SDK1.7?
> SDK1.6 on T1040RDB certainly would have benefited from additional testing.
> 
> 
> >
> >
> > Best Regards,
> >
> > Zhenhua
> >
> >> -----Original Message-----
> >> From: Bob Cochran [mailto:yocto@mindchasers.com]
> >> Sent: Saturday, September 27, 2014 11:36 PM
> >> To: Luo Zhenhua-B19537; meta-freescale@yoctoproject.org
> >> Cc: Wood Scott-B07421; Wrobel Heinz-R39252
> >> Subject: Re: [meta-freescale] Should all T4240 errata be applied to T1040?
> >>
> >> On 09/19/2014 06:04 AM, zhenhua.luo@freescale.com wrote:
> >>> Hi Bob,
> >>>
> >>> Thanks for the great finding.
> >>>
> >>> Defining the CONFIG_FMAN_T4240 for T1 is inaccurate and potentially
> >> dangerous for the correct function. The manual explicitly states for
> >> TNTSKS that exceeding the max supported values is not permitted, but
> >> it doesn't actually state that the reset value is the maximum permissible
> value.
> >>>
> >>> As for the correct way to define things, we probably need to share
> >> integrations across common SoCs per, e.g., Table A-5 in the T1040
> >> DPAA RM to make SW match our docs properly. A configuration "T4240"
> >> is likely a bad one anyway if we should name it effectively
> "FMAN_V3H_384KiB" vs.
> >> "FMAN_V3H_512KiB" for B4860 rev 2.  So it is good to change
> >> "FMAN_V3L" for
> >> T1 to match the documentation and part behavior.
> >>>
> >>> Also the correct way is to stop configuring such things at compile
> >>> time to
> >> avoid separate kernel build for every FMan revision.
> >>
> >>
> >> Zhenhua,
> >>
> >> I believe a similar issue exists with the dts files.
> >>
> >> fsl/qoriq-fman3-0.dtsi defines two O/H ports that don't exist on the T1040.
> >>
> >> After setting CONFIG_FMAN_V3L,  FM_MAX_NUM_OF_OH_PORTS was
> defined as
> >> 4 in T4240/dpaa_integration_ext.h.  This matches what I see in the
> >> T1040 SoC RM.
> >>
> >> However, during boot, I see errors reported on the command line from
> >> the FM
> >> module:
> >>
> >> Freescale FM module (Sep 26 2014:14:25:29), FMD API version 21.1.0
> >> cpu1/1: ! MAJOR FM Error [CPU01,
> >> drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272
> >> ReadFmPortDevTreeNode]: Invalid Value;
> >> cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@86000,
> >> cell-index) failedcpu1/1:
> >>
> >> fsl-fman-port: probe of ffe486000.port failed with error -5
> >> cpu1/1: ! MAJOR FM Error [CPU01,
> >> drivers/net/ethernet/freescale/fman/src/wrapper/lnxwrp_fm_port.c:272
> >> ReadFmPortDevTreeNode]: Invalid Value;
> >> cpu1/1: of_get_property(/soc@ffe000000/fman@400000/port@87000,
> >> cell-index) failedcpu1/1:
> >>
> >> If I remove the extra O/H ports in my dts file, the errors go away.
> >>
> >> So, if we follow your suggestion, I believe we should add a
> >> qoriq-fman3l-0.dtsi file that excludes the non-existent O/H ports.
> >>
> >> However, I need some feedback because my T1040 DPAA Reference
> Manual
> >> Table A-47 states that the number of O/H ports are SoC specific, so
> >> maybe some V3L devices actually have these extra O/H ports???
> >>
> >> And fsl/t1040si-post.dtsi also specifies the extra two O/H ports, but
> >> that's a straight forward patch.
> >>
> >> Finally, who will do these patches for proper V3H/V3L support (me or
> >> FSL)?  If I do it, I'm just going to work through the issues with the
> >> T1040 / V3L (I can't address B4860 rev 2 - don't have the specs &
> >> don't want them).
> >>
> >> Thanks,
> >>
> >> Bob
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>> Best Regards,
> >>>
> >>> Zhenhua
> >>>
> >>>> -----Original Message-----
> >>>> From: meta-freescale-bounces@yoctoproject.org
> >>>> [mailto:meta-freescale- bounces@yoctoproject.org] On Behalf Of Bob
> >>>> Cochran
> >>>> Sent: Thursday, September 18, 2014 11:44 AM
> >>>> To: meta-freescale@yoctoproject.org
> >>>> Subject: [meta-freescale] Should all T4240 errata be applied to T1040?
> >>>>
> >>>> I find that during initialization of my T1040rdb-64b using the
> >>>> kernel built with meta-fsl-ppc master, the FMBM_CFG2.TNTASKS field
> >>>> (total number of BMI
> >>>> tasks) is being overwritten to 0x7b (the reset value is documented
> >>>> as 0x3b in the T1040 reference manual).
> >>>>
> >>>> I believe this is being overwritten due to sharing the errata
> >>>> definitions with the T4240, but this particular erratum may not
> >>>> apply to the T1040 and may cause undesirable side effects.
> >>>>
> >>>> The T4240 uses DPAA FMAN_v3H, and the T1040 uses DPAA FMAN_v3L.
> >>>>
> >>>>
> >>>> Here is my understanding of how this erratum (A005127) is being
> >>>> applied to the
> >>>> T1040:
> >>>>
> >>>> 1) t1040_64bit_smp_defconfig defines CONFIG_FMAN_T4240
> >>>>
> >>>> 2) By defining CONFIG_FMAN_T4240,
> >>>> drivers/net/ethernet/freescale/fman/ncsw_config.mk adds
> >>>> -I$(FMAN)/inc/integrations/T4240 to EXTRA_CFLAGS.
> >>>>
> >>>> 3) dpaa_integration_ext.h is included throughout the fman source
> >>>> files from
> >>>> drivers/net/ethernet/freescale/fman/inc/integrations/T4240
> >>>>
> >>>> 4) This defines FM_WRONG_RESET_VALUES_ERRATA_FMAN_A005127,
> but
> >> it is
> >>>> my understanding that this erratum does not apply to the T1040.
> >>>>
> >>>> 5) This results in FMBM_CFG2.TNTASKS being overwritten with a value
> >>>> approximately twice its default value, and my concern is that the
> >>>> FMAN_V3L does not have the resources to support this many tasks.
> >>>>
> >>>>
> >>>>
> >>>> In general, I'm also wondering whether the other errata in the
> >>>> integration file is appropriate for the T1040 and whether the
> >>>> FMAN_v3L devices should have their own integration tree.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> _______________________________________________
> >>>> meta-freescale mailing list
> >>>> meta-freescale@yoctoproject.org
> >>>> https://lists.yoctoproject.org/listinfo/meta-freescale
> >>>
> >
> >