* NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.
@ 2018-07-06 14:50 Tim Small
2018-07-06 18:41 ` Scott Wood
0 siblings, 1 reply; 5+ messages in thread
From: Tim Small @ 2018-07-06 14:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Kumar Gala
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.
2018-07-06 14:50 NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs Tim Small
@ 2018-07-06 18:41 ` Scott Wood
2018-07-09 8:38 ` Tim Small
0 siblings, 1 reply; 5+ messages in thread
From: Scott Wood @ 2018-07-06 18:41 UTC (permalink / raw)
To: Tim Small, linuxppc-dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.
2018-07-06 18:41 ` Scott Wood
@ 2018-07-09 8:38 ` Tim Small
2018-07-09 22:21 ` Scott Wood
0 siblings, 1 reply; 5+ messages in thread
From: Tim Small @ 2018-07-09 8:38 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.
2018-07-09 8:38 ` Tim Small
@ 2018-07-09 22:21 ` Scott Wood
2018-07-20 14:32 ` TP Link WDR4900 (was NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs) Tim Small
0 siblings, 1 reply; 5+ messages in thread
From: Scott Wood @ 2018-07-09 22:21 UTC (permalink / raw)
To: Tim Small, linuxppc-dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* TP Link WDR4900 (was NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs).
2018-07-09 22:21 ` Scott Wood
@ 2018-07-20 14:32 ` Tim Small
0 siblings, 0 replies; 5+ messages in thread
From: Tim Small @ 2018-07-20 14:32 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev
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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-07-20 14:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-06 14:50 NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs Tim Small
2018-07-06 18:41 ` Scott Wood
2018-07-09 8:38 ` Tim Small
2018-07-09 22:21 ` Scott Wood
2018-07-20 14:32 ` TP Link WDR4900 (was NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs) Tim Small
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.