Thread (5 messages) 5 messages, 2 authors, 2018-07-20

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

From: Scott Wood <oss@buserror.net>
Date: 2018-07-09 22:23:57

On Mon, 2018-07-09 at 09:38 +0100, Tim Small wrote:
On 06/07/18 19:41, Scott Wood wrote:
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help