[meta-freescale] Should all T4240 errata be applied to T1040?

[Bob Cochran]

On 10/14/2014 03:55 AM, zhenhua.luo at 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 at mindchasers.com]
>> Sent: Saturday, September 27, 2014 11:36 PM
>> To: Luo Zhenhua-B19537; meta-freescale at 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 at 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 at ffe000000/fman at 400000/port at 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 at ffe000000/fman at 400000/port at 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 at yoctoproject.org [mailto:meta-freescale-
>>>> bounces at yoctoproject.org] On Behalf Of Bob Cochran
>>>> Sent: Thursday, September 18, 2014 11:44 AM
>>>> To: meta-freescale at 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 at yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/meta-freescale
>>>
>
>