NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.

NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.

[Tim Small]

Hello,

I contributed a patch to OpenWRT a couple of days ago to fix the device 
tree for a device which uses an NXP p1014 without the SEC4 module.  I 
was wondering about getting a similar fix applied upstream...

The device uses the P1014 (without SEC4 functionality), and includes:

fsl/p1010si-pre.dtsi and fsl/p1010si-post.dtsi

... in its device tree.  The latter pulls in leads to a node for 
soc@ffe00000/crypto@30000 - which then causes the CAAM modules to be 
used for crypto operations, when then fail at runtime.

AN4938 states that there are versions of both the p1010 and p1014 
without the SEC4 module.

The P1010 errata at:

https://media.digikey.com/pdf/PCNs/Freescale/P1010CE_RevL.pdf

(table 2 on page 2), says that the P1010 and P1014 don't have the SEC4 
module, only the P1010E and P1014E models do.

So, I think there should probably be device trees for p101xE (with SEC) 
and p101x (without SEC).

Any thoughts?  Not really sure how best to do that...  My openwrt patch 
just does a:

/delete-node/ crypto@30000;

after the p1010si-post.dtsi include.

Cheers,

Tim.
-- 
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309

Re: NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.

[Scott Wood]

On Fri, 2018-07-06 at 15:50 +0100, Tim Small wrote:
> Hello,
> 
> I contributed a patch to OpenWRT a couple of days ago to fix the device 
> tree for a device which uses an NXP p1014 without the SEC4 module.  I 
> was wondering about getting a similar fix applied upstream...
> 
> The device uses the P1014 (without SEC4 functionality), and includes:
> 
> fsl/p1010si-pre.dtsi and fsl/p1010si-post.dtsi
> 
> ... in its device tree.  The latter pulls in leads to a node for 
> soc@ffe00000/crypto@30000 - which then causes the CAAM modules to be 
> used for crypto operations, when then fail at runtime.
> 
> AN4938 states that there are versions of both the p1010 and p1014 
> without the SEC4 module.
> 
> The P1010 errata at:
> 
> https://media.digikey.com/pdf/PCNs/Freescale/P1010CE_RevL.pdf
> 
> (table 2 on page 2), says that the P1010 and P1014 don't have the SEC4 
> module, only the P1010E and P1014E models do.
> 
> So, I think there should probably be device trees for p101xE (with SEC) 
> and p101x (without SEC).
> 
> Any thoughts?  Not really sure how best to do that...  My openwrt patch 
> just does a:
> 
> /delete-node/ crypto@30000;
> 
> after the p1010si-post.dtsi include.

U-Boot should already be removing the node on non-E chips -- see
ft_cpu_setup() in arch/powerpc/cpu/mpc85xx/fdt.c

-Scott

Re: NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.

[Tim Small]

On 06/07/18 19:41, Scott Wood wrote:
>> My openwrt patch
>> just does a:
>>
>> /delete-node/  crypto@30000;
>>
>> after the p1010si-post.dtsi include.
> U-Boot should already be removing the node on non-E chips -- see
> ft_cpu_setup() in arch/powerpc/cpu/mpc85xx/fdt.c


Hi Scott,

Thanks for your email.  The device in question ships an old uboot (a 
vendor fork of U-Boot 2010.12-svn15934).

I am right in saying that the right fix is to either:

Use a bootloader (such as current upstream uboot) which adjusts the 
device tree properly...

or:

In the case (such as OpenWRT) where the preferred installation method is 
to retain the vendor bootloader, then the distro kernel should handle 
the device tree fixup itself?

Regards,

Tim.

Re: NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.

[Scott Wood]

On Mon, 2018-07-09 at 09:38 +0100, Tim Small wrote:
> On 06/07/18 19:41, Scott Wood wrote:
> > > My openwrt patch
> > > just does a:
> > > 
> > > /delete-node/  crypto@30000;
> > > 
> > > after the p1010si-post.dtsi include.
> > 
> > U-Boot should already be removing the node on non-E chips -- see
> > ft_cpu_setup() in arch/powerpc/cpu/mpc85xx/fdt.c
> 
> 
> Hi Scott,
> 
> Thanks for your email.  The device in question ships an old uboot (a 
> vendor fork of U-Boot 2010.12-svn15934).

This was added by commit 6b70ffb9d1b2e, committed in July 2008... maybe
there's a problem with the old U-Boot finding the crypto node on this
particular chip?

> I am right in saying that the right fix is to either:
> 
> Use a bootloader (such as current upstream uboot) which adjusts the 
> device tree properly...
> 
> or:
> 
> In the case (such as OpenWRT) where the preferred installation method is 
> to retain the vendor bootloader, then the distro kernel should handle 
> the device tree fixup itself?

The NXP PPC device trees in the kernel are meant to be completed by U-Boot
(years ago I repeatedly suggested that the trees be moved into the U-Boot
source to reflect this, but nobody seemed interested).  Generally that is
mainline and  NXP SDK U-Boot, but a board dts file might cater to some other
U-Boot fork (or   other bootloader) if that's what ships on the board.  Does
this hardware have a board dts file in mainline Linux?

-Scott

TP Link WDR4900 (was NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs).

[Tim Small]

On 09/07/18 23:21, Scott Wood wrote:

>> Thanks for your email.  The device in question ships an old uboot (a
>> vendor fork of U-Boot 2010.12-svn15934).
> 
> This was added by commit 6b70ffb9d1b2e, committed in July 2008... maybe
> there's a problem with the old U-Boot finding the crypto node on this
> particular chip?

Hi Scott,

Thanks for your response and the pointers...  I don't know my way around 
this code at all (I just got here when I hit a user space bug when 
trying to use 802.1AE), so I'm in the dark a bit here.

The device doesn't have mainline support, there is the original vendor 
patched uboot and kernel (linux 2.6.35 based) released here:

https://www.tp-link.com/us/download/TL-WDR4900.html#GPL-Code

The the vendor u-boot serial output identifies the board as a P1014RDB 
in its serial output, so I'd guess that TP-Link just made minimal 
changes from the NXP reference design.

The OpenWRT distro package, which has its own reasonably simple set of 
kernel patches (it's currently using 4.9.x on this platform) at:

https://git.openwrt.org/openwrt/openwrt.git

in:

target/linux/mpc85xx/files/arch/powerpc/platforms/85xx

It produces a cuImage for this board, but I don't know why that decision 
was made, maybe it's just what the vendor kernel did, or maybe it's 
difficult to differentiate a TL-WDR4900 from a P1010RDB reference board. 
  I couldn't find the P1010RDB BSP to see what TP-Link has done.

I could potentially work on getting those upstream if you think that 
would be worthwhile, but I don't really have a good feel for how good or 
hacky the code that's in OpenWRT is at the moment.  I'd probably need 
help getting it up and running.

I presume it'd mean switching from a cuImage to a uImage if practical?

Cheers,

Tim.

-- 
South East Open Source Solutions Limited
Registered in England and Wales with company number 06134732.
Registered Office: 2 Powell Gardens, Redhill, Surrey, RH1 1TQ
VAT number: 900 6633 53  http://seoss.co.uk/ +44-(0)1273-808309