| Message ID | cover.1599343429.git.chunkeey@gmail.com |
|---|---|
| Headers | show |
| Series | powerpc: apm82181: adding customer devices | expand |
On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote: > This patch adds an DTSI-File that can be used by various device-tree > files for APM82181-based devices. > > Some of the nodes (like UART, PCIE, SATA) are used by the uboot and > need to stick with the naming-conventions of the old times'. > I've added comments whenever this was the case. > > Signed-off-by: Chris Blake <chrisrblake93@gmail.com> > Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > --- > rfc v1 -> v2: > - removed PKA (this CryptoPU will need driver) > - stick with compatibles, nodes, ... from either > Bluestone (APM82181) or Canyonlands (PPC460EX). > - add labels for NAND and NOR to help with access. > v2 -> v3: > - nodename of pciex@d.... was changed to pcie@d.. > due to upstream patch. > - use simple-bus on the ebc, opb and plb nodes > --- > arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++ > 1 file changed, 466 insertions(+) > create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi > > diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi > new file mode 100644 > index 000000000000..60283430978d > --- /dev/null > +++ b/arch/powerpc/boot/dts/apm82181.dtsi > @@ -0,0 +1,466 @@ > +// SPDX-License-Identifier: GPL-2.0-or-later > +/* > + * Device Tree template include for various APM82181 boards. > + * > + * The SoC is an evolution of the PPC460EX predecessor. > + * This is why dt-nodes from the canyonlands EBC, OPB, USB, > + * DMA, SATA, EMAC, ... ended up in here. > + * > + * Copyright (c) 2010, Applied Micro Circuits Corporation > + * Author: Tirumala R Marri <tmarri@apm.com>, > + * Christian Lamparter <chunkeey@gmail.com>, > + * Chris Blake <chrisrblake93@gmail.com> > + */ > + > +#include <dt-bindings/dma/dw-dmac.h> > +#include <dt-bindings/input/input.h> > +#include <dt-bindings/interrupt-controller/irq.h> > +#include <dt-bindings/gpio/gpio.h> > + > +/ { > + #address-cells = <2>; > + #size-cells = <1>; > + dcr-parent = <&{/cpus/cpu@0}>; > + > + aliases { > + ethernet0 = &EMAC0; /* needed for BSP u-boot */ > + }; > + > + cpus { > + #address-cells = <1>; > + #size-cells = <0>; > + > + CPU0: cpu@0 { > + device_type = "cpu"; > + model = "PowerPC,apm82181"; This doesn't match the existing bluestone dts file. Please separate any restructuring from changes.
On 2020-09-15 03:05, Rob Herring wrote: > On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote: >> This patch adds an DTSI-File that can be used by various device-tree >> files for APM82181-based devices. >> >> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and >> need to stick with the naming-conventions of the old times'. >> I've added comments whenever this was the case. >> >> Signed-off-by: Chris Blake <chrisrblake93@gmail.com> >> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> >> --- >> rfc v1 -> v2: >> - removed PKA (this CryptoPU will need driver) >> - stick with compatibles, nodes, ... from either >> Bluestone (APM82181) or Canyonlands (PPC460EX). >> - add labels for NAND and NOR to help with access. >> v2 -> v3: >> - nodename of pciex@d.... was changed to pcie@d.. >> due to upstream patch. >> - use simple-bus on the ebc, opb and plb nodes >> --- >> arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++ >> 1 file changed, 466 insertions(+) >> create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi >> >> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi >> new file mode 100644 >> index 000000000000..60283430978d >> --- /dev/null >> +++ b/arch/powerpc/boot/dts/apm82181.dtsi >> @@ -0,0 +1,466 @@ >> +// SPDX-License-Identifier: GPL-2.0-or-later >> +/* >> + * Device Tree template include for various APM82181 boards. >> + * >> + * The SoC is an evolution of the PPC460EX predecessor. >> + * This is why dt-nodes from the canyonlands EBC, OPB, USB, >> + * DMA, SATA, EMAC, ... ended up in here. >> + * >> + * Copyright (c) 2010, Applied Micro Circuits Corporation >> + * Author: Tirumala R Marri <tmarri@apm.com>, >> + * Christian Lamparter <chunkeey@gmail.com>, >> + * Chris Blake <chrisrblake93@gmail.com> >> + */ >> + >> +#include <dt-bindings/dma/dw-dmac.h> >> +#include <dt-bindings/input/input.h> >> +#include <dt-bindings/interrupt-controller/irq.h> >> +#include <dt-bindings/gpio/gpio.h> >> + >> +/ { >> + #address-cells = <2>; >> + #size-cells = <1>; >> + dcr-parent = <&{/cpus/cpu@0}>; >> + >> + aliases { >> + ethernet0 = &EMAC0; /* needed for BSP u-boot */ >> + }; >> + >> + cpus { >> + #address-cells = <1>; >> + #size-cells = <0>; >> + >> + CPU0: cpu@0 { >> + device_type = "cpu"; >> + model = "PowerPC,apm82181"; > > This doesn't match the existing bluestone dts file. > > Please separate any restructuring from changes. "I see" (I'm including your comment of the dt-binding as well). I'm getting the vibe that I better should not touch that bluestone.dts. An honestly, looking at the series and patches that the APM-engineers posted back in the day, I can see why this well is so poisoned... and stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing. As for the devices. In the spirit of Arnd Bergmann's post of <https://lkml.org/lkml/2020/3/30/195> |It would be nice to move over the the bluestone .dts to the apm82181.dtsi file |when that gets added, if only to ensure they use the same description for each |node, but that shouldn't stop the addition of the new file if that is needed for |distros to make use of a popular device. |I see a couple of additional files in openwrt. I mean I don't have the bluestone dev board, just the consumer devices. Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller), the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram". And then add nodes for PCIE+MSI, AHBDMA+SATA, I2C, Ethernet, NAND+NOR and finally the Crypto each in separate patches.
On Sat, Sep 19, 2020 at 2:23 PM Christian Lamparter <chunkeey@gmail.com> wrote: > > On 2020-09-15 03:05, Rob Herring wrote: > > On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote: > >> This patch adds an DTSI-File that can be used by various device-tree > >> files for APM82181-based devices. > >> > >> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and > >> need to stick with the naming-conventions of the old times'. > >> I've added comments whenever this was the case. > >> > >> Signed-off-by: Chris Blake <chrisrblake93@gmail.com> > >> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > >> --- > >> rfc v1 -> v2: > >> - removed PKA (this CryptoPU will need driver) > >> - stick with compatibles, nodes, ... from either > >> Bluestone (APM82181) or Canyonlands (PPC460EX). > >> - add labels for NAND and NOR to help with access. > >> v2 -> v3: > >> - nodename of pciex@d.... was changed to pcie@d.. > >> due to upstream patch. > >> - use simple-bus on the ebc, opb and plb nodes > >> --- > >> arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++ > >> 1 file changed, 466 insertions(+) > >> create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi > >> > >> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi > >> new file mode 100644 > >> index 000000000000..60283430978d > >> --- /dev/null > >> +++ b/arch/powerpc/boot/dts/apm82181.dtsi > >> @@ -0,0 +1,466 @@ > >> +// SPDX-License-Identifier: GPL-2.0-or-later > >> +/* > >> + * Device Tree template include for various APM82181 boards. > >> + * > >> + * The SoC is an evolution of the PPC460EX predecessor. > >> + * This is why dt-nodes from the canyonlands EBC, OPB, USB, > >> + * DMA, SATA, EMAC, ... ended up in here. > >> + * > >> + * Copyright (c) 2010, Applied Micro Circuits Corporation > >> + * Author: Tirumala R Marri <tmarri@apm.com>, > >> + * Christian Lamparter <chunkeey@gmail.com>, > >> + * Chris Blake <chrisrblake93@gmail.com> > >> + */ > >> + > >> +#include <dt-bindings/dma/dw-dmac.h> > >> +#include <dt-bindings/input/input.h> > >> +#include <dt-bindings/interrupt-controller/irq.h> > >> +#include <dt-bindings/gpio/gpio.h> > >> + > >> +/ { > >> + #address-cells = <2>; > >> + #size-cells = <1>; > >> + dcr-parent = <&{/cpus/cpu@0}>; > >> + > >> + aliases { > >> + ethernet0 = &EMAC0; /* needed for BSP u-boot */ > >> + }; > >> + > >> + cpus { > >> + #address-cells = <1>; > >> + #size-cells = <0>; > >> + > >> + CPU0: cpu@0 { > >> + device_type = "cpu"; > >> + model = "PowerPC,apm82181"; > > > > This doesn't match the existing bluestone dts file. > > > > Please separate any restructuring from changes. > > > "I see" (I'm including your comment of the dt-binding as well). > > I'm getting the vibe that I better should not touch that bluestone.dts. I don't know about that. > An honestly, looking at the series and patches that the APM-engineers > posted back in the day, I can see why this well is so poisoned... and > stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing. > > As for the devices. In the spirit of Arnd Bergmann's post of > <https://lkml.org/lkml/2020/3/30/195> > > |It would be nice to move over the the bluestone .dts to the apm82181.dtsi file > |when that gets added, if only to ensure they use the same description for each > |node, but that shouldn't stop the addition of the new file if that is needed for > |distros to make use of a popular device. > |I see a couple of additional files in openwrt. > > I mean I don't have the bluestone dev board, just the consumer devices. This stuff is old enough, I'd guess no one cares about a dev board. But we should figure that out and document that with any changes. > Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi > This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller), > the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram". This skeleton would be chunks moved over or duplicated? I don't think we want 2 of the same thing. The order I would go is split into an apm82181.dtsi with 0 changes to the built dtb(s). Then make changes/additions you need. As far as changes to existing bindings, it's only an ABI if someone notices. Rob
On Tue, Sep 22, 2020 at 9:14 PM Rob Herring <robh@kernel.org> wrote: > > On Sat, Sep 19, 2020 at 2:23 PM Christian Lamparter <chunkeey@gmail.com> wrote: > > > > On 2020-09-15 03:05, Rob Herring wrote: > > > On Sun, Sep 06, 2020 at 12:06:12AM +0200, Christian Lamparter wrote: > > >> This patch adds an DTSI-File that can be used by various device-tree > > >> files for APM82181-based devices. > > >> > > >> Some of the nodes (like UART, PCIE, SATA) are used by the uboot and > > >> need to stick with the naming-conventions of the old times'. > > >> I've added comments whenever this was the case. > > >> > > >> Signed-off-by: Chris Blake <chrisrblake93@gmail.com> > > >> Signed-off-by: Christian Lamparter <chunkeey@gmail.com> > > >> --- > > >> rfc v1 -> v2: > > >> - removed PKA (this CryptoPU will need driver) > > >> - stick with compatibles, nodes, ... from either > > >> Bluestone (APM82181) or Canyonlands (PPC460EX). > > >> - add labels for NAND and NOR to help with access. > > >> v2 -> v3: > > >> - nodename of pciex@d.... was changed to pcie@d.. > > >> due to upstream patch. > > >> - use simple-bus on the ebc, opb and plb nodes > > >> --- > > >> arch/powerpc/boot/dts/apm82181.dtsi | 466 ++++++++++++++++++++++++++++ > > >> 1 file changed, 466 insertions(+) > > >> create mode 100644 arch/powerpc/boot/dts/apm82181.dtsi > > >> > > >> diff --git a/arch/powerpc/boot/dts/apm82181.dtsi b/arch/powerpc/boot/dts/apm82181.dtsi > > >> new file mode 100644 > > >> index 000000000000..60283430978d > > >> --- /dev/null > > >> +++ b/arch/powerpc/boot/dts/apm82181.dtsi > > >> @@ -0,0 +1,466 @@ > > >> +// SPDX-License-Identifier: GPL-2.0-or-later > > >> +/* > > >> + * Device Tree template include for various APM82181 boards. > > >> + * > > >> + * The SoC is an evolution of the PPC460EX predecessor. > > >> + * This is why dt-nodes from the canyonlands EBC, OPB, USB, > > >> + * DMA, SATA, EMAC, ... ended up in here. > > >> + * > > >> + * Copyright (c) 2010, Applied Micro Circuits Corporation > > >> + * Author: Tirumala R Marri <tmarri@apm.com>, > > >> + * Christian Lamparter <chunkeey@gmail.com>, > > >> + * Chris Blake <chrisrblake93@gmail.com> > > >> + */ > > >> + > > >> +#include <dt-bindings/dma/dw-dmac.h> > > >> +#include <dt-bindings/input/input.h> > > >> +#include <dt-bindings/interrupt-controller/irq.h> > > >> +#include <dt-bindings/gpio/gpio.h> > > >> + > > >> +/ { > > >> + #address-cells = <2>; > > >> + #size-cells = <1>; > > >> + dcr-parent = <&{/cpus/cpu@0}>; > > >> + > > >> + aliases { > > >> + ethernet0 = &EMAC0; /* needed for BSP u-boot */ > > >> + }; > > >> + > > >> + cpus { > > >> + #address-cells = <1>; > > >> + #size-cells = <0>; > > >> + > > >> + CPU0: cpu@0 { > > >> + device_type = "cpu"; > > >> + model = "PowerPC,apm82181"; > > > > > > This doesn't match the existing bluestone dts file. > > > > > > Please separate any restructuring from changes. > > > > > > "I see" (I'm including your comment of the dt-binding as well). > > > > I'm getting the vibe that I better should not touch that bluestone.dts. > > I don't know about that. k, understood. > > > An honestly, looking at the series and patches that the APM-engineers > > posted back in the day, I can see why this well is so poisoned... and > > stuff like SATA/AHBDMA/USB/GPIO/CPM/... was missing. > > > > As for the devices. In the spirit of Arnd Bergmann's post of > > <https://lkml.org/lkml/2020/3/30/195> > > > > |It would be nice to move over the the bluestone .dts to the apm82181.dtsi file > > |when that gets added, if only to ensure they use the same description for each > > |node, but that shouldn't stop the addition of the new file if that is needed for > > |distros to make use of a popular device. > > |I see a couple of additional files in openwrt. > > > > I mean I don't have the bluestone dev board, just the consumer devices. > > This stuff is old enough, I'd guess no one cares about a dev board. > But we should figure that out and document that with any changes. > > > Would it be possible to support those? I can start from a "skeleton" apm82181.dtsi > > This would just include CPU, Memory (SD-RAM+L2C+OCM), UIC (Interrupt-Controller), > > the PLB+OBP+EBC Busses and UART. Just enough to make a board "boot from ram". > > This skeleton would be chunks moved over or duplicated? I don't think > we want 2 of the same thing. My Idea was copying the working apm82181.dtsi we have in OpenWrt and stripping the nodes we added for SATA, USB, GPIO and the likes. so the remaining nodes would be very close to what bluestone.dts had. The main differences would be: - It's a bit smaller since I made a separate patch for the NOR/NAND on the EBC. Reason being that the SoC uses glue-logic for mapping NOR/NAND (and other external peripherals like the GPIOs on the WD) into the memory and I thought this needed some explanation as to why this weird thing works. - it would already use the dt-bindings/interrupt-controller/irq.h macros for LEVEL/EDGE cell values - it contains valuable comments about the uboot. Because ethernet0 alias and the /plb/obc/ebc node-name requirements). - UART are using 16750 compatible (as per hardware docs) > > The order I would go is split into an apm82181.dtsi with 0 changes to > the built dtb(s). Then make changes/additions you need. As far as > changes to existing bindings, it's only an ABI if someone notices. This will rewriting the history, as the development of apm82181.dtsi did happen differently (basically, each device started with its own full dts. But early on in 2016 we merged the common nodes and switched over to the macros). This is fine though, I'll need some time to rebase and rewrite the patches. (Note: I've already wrote a patch for a the apm82181 dwc USB binding for this: <https://www.spinics.net/lists/devicetree/msg378884.html>. Not sure about uic, sata and dw-dma as these drivers each use a common binding. I hope there's some leeway for this old stuff.) Cheers, Christian
On Sun, Sep 06, 2020 at 12:06:10AM +0200, Christian Lamparter wrote: > Hello, > > I've been holding on to these devices dts' for a while now. > But ever since the recent purge of the PPC405, I'm feeling > the urge to move forward. > > The devices in question have been running with OpenWrt since > around 2016/2017. Back then it was linux v4.4 and required > many out-of-tree patches (for WIFI, SATA, CRYPTO...), that > since have been integrated. So, there's nothing else in the > way I think. > > A patch that adds the Meraki vendor-prefix has been sent > separately, as there's also the Meraki MR32 that I'm working > on as well. Here's the link to the patch: > <https://lore.kernel.org/linuxppc-dev/20200822154045.16036-1-chunkeey@gmail.com/> > > Now, I've looked around in the arch/powerpc for recent .dts > and device submissions to get an understanding of what is > required. > >From the looks of it, it seems like every device gets a > skeleton defconfig and a CONFIG_$DEVICE symbol (Like: > CONFIG_MERAKI_MR24, CONFIG_WD_MYBOOKLIVE). > > Will this be the case? Or would it make sense to further > unite the Bluestone, MR24 and MBL under a common CONFIG_APM82181 > and integrate the BLUESTONE device's defconfig into it as well? > (I've stumbled across the special machine compatible > handling of ppc in the Documentation/devicetree/usage-model.rst > already.) I haven't found any traces of this to be applied. What is the status of this patch series? And what is the general state of affairs for the PPC44x?
Hi Andy! On 23/07/2021 21:19, Andy Shevchenko wrote: > On Sun, Sep 06, 2020 at 12:06:10AM +0200, Christian Lamparter wrote: >> I've been holding on to these devices dts' for a while now. >> But ever since the recent purge of the PPC405, I'm feeling >> the urge to move forward. >> >> The devices in question have been running with OpenWrt since >> around 2016/2017. Back then it was linux v4.4 and required >> many out-of-tree patches (for WIFI, SATA, CRYPTO...), that >> since have been integrated. So, there's nothing else in the >> way I think. >> >> A patch that adds the Meraki vendor-prefix has been sent >> separately, as there's also the Meraki MR32 that I'm working >> on as well. Here's the link to the patch: >> <https://lore.kernel.org/linuxppc-dev/20200822154045.16036-1-chunkeey@gmail.com/> >> >> Now, I've looked around in the arch/powerpc for recent .dts >> and device submissions to get an understanding of what is >> required. >> >From the looks of it, it seems like every device gets a >> skeleton defconfig and a CONFIG_$DEVICE symbol (Like: >> CONFIG_MERAKI_MR24, CONFIG_WD_MYBOOKLIVE). >> >> Will this be the case? Or would it make sense to further >> unite the Bluestone, MR24 and MBL under a common CONFIG_APM82181 >> and integrate the BLUESTONE device's defconfig into it as well? >> (I've stumbled across the special machine compatible >> handling of ppc in the Documentation/devicetree/usage-model.rst >> already.) > > I haven't found any traces of this to be applied. What is the status of this > patch series? And what is the general state of affairs for the PPC44x? My best guess is: It's complicated. While there was a recent big UPSET EVENT regarding the My Book Live (MBL) that affected "hundreds" and "thousands": "An unpleasant surprise for My Book Live owners" (<https://lwn.net/Articles/861235/>). Sadly this wasn't getting any traction. I can tell that the mentioned Cisco Meraki MR32 (Broadcom ARM SoC) got merged. So this is off the plate 😌. But APM821xx sadly went nowhere 😕. One reason being that I haven't yet posted a V4, V5 and so on... In theory, for v4 I would have liked to know how to handle the kConfig aspect of the series: Would it be "OK" to have a single CONFIG_APM82181/CONFIG_APM821XX symbol or should there be a CONFIG_MBL the CONFIG_MR24 (CONFIG_WNDR4700 and CONFIG_MX60W in the future)? As for the MBL: Well, If you (or any one else) is interested in having a more up-to-date Debian. Then I have something: A while back, I made a "build.sh". This will build a "out-of-the-box" Debian unstable/SID powerpc system image. This includes sensible NAS defaults + programs as well as a Cockpit Web-GUI. But also makes it easily possible to do the DTBs development on the latest vanilla (5.14-rc2 as of the time of writing this) kernel for the MyBook Live Single and Duo: <https://github.com/chunkeey/mbl-debian> I can't really make one for the MR24 though. Its 32MiB NAND makes it difficult to install anything else than OpenWrt (and get some use out of the device). So, how to proceed? Cheers, Christian PS.: As for PPC44x health regarding APM82181: It works! This is with a My Book Live (MBL) and the 5.14.0-rc2(+) kernel. [ 0.000000] printk: bootconsole [udbg0] enabled [ 0.000000] Activating Kernel Userspace Execution Prevention [ 0.000000] Linux version 5.14.0-rc2+ (root@debian64) (powerpc-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 Fri Jul 23 22:59:56 CEST 2021 [ 0.000000] Found initrd at 0xcf000000:0xcfe73b70 [ 0.000000] Using PowerPC 44x Platform machine description [ 0.000000] ----------------------------------------------------- [ 0.000000] phys_mem_size = 0x10000000 [ 0.000000] dcache_bsize = 0x20 [ 0.000000] icache_bsize = 0x20 [ 0.000000] cpu_features = 0x0000000000000100 [ 0.000000] possible = 0x0000000040000100 [ 0.000000] always = 0x0000000000000100 [ 0.000000] cpu_user_features = 0x8c008000 0x00000000 [ 0.000000] mmu_features = 0x00000008 [ 0.000000] ----------------------------------------------------- [ 0.000000] Top of RAM: 0x10000000, Total RAM: 0x10000000 [ 0.000000] Memory hole size: 0MB [ 0.000000] Zone ranges: [ 0.000000] Normal [mem 0x0000000000000000-0x000000000fffffff] [ 0.000000] Movable zone start for each node [ 0.000000] Early memory node ranges [ 0.000000] node 0: [mem 0x0000000000000000-0x000000000fffffff] [ 0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x000000000fffffff] [ 0.000000] MMU: Allocated 1088 bytes of context maps for 255 contexts [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [ 0.000000] pcpu-alloc: [0] 0 [ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16352 [ 0.000000] Kernel command line: root=UUID=ef4e8942-768b-4d2e-ba57-486397c97081 console=ttyS0,115200 [ 0.000000] Dentry cache hash table entries: 32768 (order: 3, 131072 bytes, linear) [ 0.000000] Inode-cache hash table entries: 16384 (order: 2, 65536 bytes, linear) [ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off [ 0.000000] Kernel virtual memory layout: [ 0.000000] * 0xffbdc000..0xffffc000 : fixmap [ 0.000000] * 0xd1000000..0xffbdc000 : vmalloc & ioremap [ 0.000000] Memory: 237088K/262144K available (6096K kernel code, 832K rwdata, 1888K rodata, 256K init, 338K bss, 25056K reserved, 0K cma-reserved) [ 0.000000] random: get_random_u32 called from cache_random_seq_create+0x68/0x148 with crng_init=0 [ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [ 0.000000] NR_IRQS: 512, nr_irqs: 512, preallocated irqs: 16 [ 0.000000] UIC0 (32 IRQ sources) at DCR 0xc0 [ 0.000000] UIC1 (32 IRQ sources) at DCR 0xd0 [ 0.000000] UIC2 (32 IRQ sources) at DCR 0xe0 [ 0.000000] UIC3 (32 IRQ sources) at DCR 0xf0 [ 0.000000] time_init: decrementer frequency = 800.000008 MHz [ 0.000000] time_init: processor frequency = 800.000008 MHz [ 0.000008] clocksource: timebase: mask: 0xffffffffffffffff max_cycles: 0xb881274fa3, max_idle_ns: 440795210636 ns [ 0.008985] clocksource: timebase mult[1400000] shift[24] registered [ 0.014006] clockevent: decrementer mult[ccccccef] shift[32] cpu[0] [ 0.019181] Console: colour dummy device 80x25 [ 0.022289] pid_max: default: 32768 minimum: 301 [ 0.025979] Mount-cache hash table entries: 4096 (order: 0, 16384 bytes, linear) [ 0.032024] Mountpoint-cache hash table entries: 4096 (order: 0, 16384 bytes, linear) [ 0.041291] devtmpfs: initialized ... The "+" Patch is: <https://github.com/chunkeey/mbl-debian/blob/master/patches/kernel/9999-powerpc-apm82181-add-WD-MyBook-Live-NAS.patch> (which adds the "wd,mybooklive" to the list of supported devices to ppc44x_simple.c)
On Sat, Jul 24, 2021 at 12:08:30AM +0200, Christian Lamparter wrote: > On 23/07/2021 21:19, Andy Shevchenko wrote: > > On Sun, Sep 06, 2020 at 12:06:10AM +0200, Christian Lamparter wrote: > > > I've been holding on to these devices dts' for a while now. > > > But ever since the recent purge of the PPC405, I'm feeling > > > the urge to move forward. > > > > > > The devices in question have been running with OpenWrt since > > > around 2016/2017. Back then it was linux v4.4 and required > > > many out-of-tree patches (for WIFI, SATA, CRYPTO...), that > > > since have been integrated. So, there's nothing else in the > > > way I think. > > > > > > A patch that adds the Meraki vendor-prefix has been sent > > > separately, as there's also the Meraki MR32 that I'm working > > > on as well. Here's the link to the patch: > > > <https://lore.kernel.org/linuxppc-dev/20200822154045.16036-1-chunkeey@gmail.com/> > > > > > > Now, I've looked around in the arch/powerpc for recent .dts > > > and device submissions to get an understanding of what is > > > required. > > > >From the looks of it, it seems like every device gets a > > > skeleton defconfig and a CONFIG_$DEVICE symbol (Like: > > > CONFIG_MERAKI_MR24, CONFIG_WD_MYBOOKLIVE). > > > > > > Will this be the case? Or would it make sense to further > > > unite the Bluestone, MR24 and MBL under a common CONFIG_APM82181 > > > and integrate the BLUESTONE device's defconfig into it as well? > > > (I've stumbled across the special machine compatible > > > handling of ppc in the Documentation/devicetree/usage-model.rst > > > already.) > > > > I haven't found any traces of this to be applied. What is the status of this > > patch series? And what is the general state of affairs for the PPC44x? > > > My best guess is: It's complicated. While there was a recent big > UPSET EVENT regarding the My Book Live (MBL) that affected "hundreds" > and "thousands": "An unpleasant surprise for My Book Live owners" > (<https://lwn.net/Articles/861235/>). Sadly this wasn't getting any > traction. > > I can tell that the mentioned Cisco Meraki MR32 (Broadcom ARM SoC) > got merged. So this is off the plate 😌. > > But APM821xx sadly went nowhere 😕. One reason being that I haven't > yet posted a V4, V5 and so on... I will help with testing if needed, please continue this, it's helpful! > In theory, for v4 I would have liked to know how to handle the > kConfig aspect of the series: Would it be "OK" to have a > single CONFIG_APM82181/CONFIG_APM821XX symbol or should there > be a CONFIG_MBL the CONFIG_MR24 (CONFIG_WNDR4700 and CONFIG_MX60W > in the future)? No idea. Not a PPC maintainer here. > As for the MBL: Well, If you (or any one else) is interested in > having a more up-to-date Debian. Then I have something: > > A while back, I made a "build.sh". This will build a > "out-of-the-box" Debian unstable/SID powerpc system image. > This includes sensible NAS defaults + programs as well as > a Cockpit Web-GUI. But also makes it easily possible to do > the DTBs development on the latest vanilla (5.14-rc2 as of > the time of writing this) kernel for the > MyBook Live Single and Duo: > > <https://github.com/chunkeey/mbl-debian> Thanks for the pointer. > I can't really make one for the MR24 though. Its 32MiB NAND > makes it difficult to install anything else than OpenWrt > (and get some use out of the device). Not interested in MR24, up to you. > So, how to proceed? At least send a v4 :-)