NXP p1010se device trees only correct for P1010E/P1014E, not P1010/P1014 SoCs.
Scott Wood
oss at buserror.net
Tue Jul 10 08:21:42 AEST 2018
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 at 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
More information about the Linuxppc-dev
mailing list