Upstream support for mv78xx0 / WXL

[arndb]

I maintain the Arm SoC specific code in mainline Linux and recently went through all platforms to see which ones might be completely obsolete and could be scheduled for removal. I noticed that arch/arm/mach-mv78xx0/ has not need any meaningful updates since I made it coexist with the other ARMv5 platforms in an ARCH_MULTIPLATFORM kernel in 2015, and neither Debian nor OpenWRT picked up support for it in their orion/kirkwood kernels after that.

I did however find that you have patches for this platform that you keep updating on https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Tools/kernel_tools/patches/default

If this is a platform you still care about, would you mind sending you patches upstream and be available for testing further changes we might have coming, or would it be ok if we retire the platform next year?

[1000001101000]

Good to hear from you!

I would be happy to submit my patches upstream and handle future testing for this device.

What process should I follow for submitting them?

[arndb]

https://www.kernel.org/doc/html/v4.10/process/submitting-patches.html describes the general procedure. The maintainers listed for the platform in the MAINTAINERS file are Andrew Lunn, Sebasitan Hesselbarth and Gregory Clement, so send any patches to them with a proper changelog text and Signed-off-by, and add the linux-arm-kernel and me (arnd@arndb.de) to Cc.

[1000001101000]

I'll work on putting that together shortly. Would you like to review it before I submit it to the list?

[arndb]

On Tue, Dec 22, 2020 at 8:37 PM 1000001101000 notifications@github.com wrote:

I'll work on putting that together shortly. Would you like to review it before I submit it to the list?

I'll just review it on the list

  Arnd

[lunn]

Is there a list of devices somewhere? I'm currently looking at the Orion5x devices the mainline kernel supports and if we can remove any which make use of board files, rather than device tree, or convert them to device tree. For the Buffalo, that would be:

mv2120-setup.c Buffalo Linkstation LS-HGL ts209-setup.c Buffalo Terastation Pro II/Live

Do you have access to these devices in order to do tests, if we try to convert them to DT?

[1000001101000]

Good to hear from you!

I believe the only Orion5x Buffalo device that still needs a device file is the "Buffalo Terastation Pro II/Live" which relies on terastation_pro2-setup.c

I do have one for testing and would be glad to help with device-tree testing.

[lunn]

I ported terastation_pro2-setup.c to DT. I expect there are bugs in it, it has been a few years since i last did a conversion like this.

https://github.com/lunn/linux.git branch v5.11-rc1-orion5x-cleanup

The new DT file is arch/arm/boot/dts/orion5x-linkstation-pro2.dts

[1000001101000]

Good to hear from you again!

I'll get everything ready for testing on my end.

I think there are some complications that need to be addressed before this will work though:

1. This device has a 88f5182 SoC and relies on PCI for SATA. I think we need an entry added to make that work
2. model = "Buffalo Linkstation Pro II"; should be model = "Buffalo Terastation Pro II";

[lunn]

Orion5x does not allow PCI to be described in DT, because of the way GPIOs are used for PCI interrupts. There is a bit of C code to make this work. See https://github.com/lunn/linux/commit/be19cb5fbd03bd6dfbe623fe9319d1c3e1f0f8e0 arch/arm/mach-orion5x/board-pro2.c which is very similar to board-rd88f5182.c.

I have renamed from linkstation to terastation and changed the included soc dtsi file. I updated the existing branch.

[1000001101000]

Sounds good, I'll give it a try.

[1000001101000]

The first attempt didn't get very far:

Hit any key to stop autoboot:  0 

Reset IDE: 
Marvell Serial ATA Adapter
Found adapter at bus 1, device 7 ... Scanning channels
  Device 1: OK
Model: KingDian S100 16GB                       Firm: 20141224 Ser#: 2017050500590       
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 15104.0 MB = 14.7 GB (30932992 x 512)

Using device ide1, partition 1

Loading from block device ide device 1, partition 1: Name: hdb1
  Type: U-Boot  File:/uImage.buffalo

2459819 bytes read
Using device ide0, partition 1
## Booting image at 00100000 ...
   Image Name:   kernel 5.11.0-rc1
   Created:      2021-01-24   1:22:52 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2459755 Bytes =  2.3 MB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 00800000 ...
   Image Name:   ramdisk 5.11.0-rc1
   Created:      2021-01-24   1:22:53 UTC
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:    4710448 Bytes =  4.5 MB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK

Starting kernel ...

arg:console=ttyS0,115200 root=/dev/sda2 rw initrd=0x00800040,15M panic=5 BOOTVER=1.19

[1000001101000]

I’ll see if I can enable earlier debugging and take a closer look at the dtb tomorrow.

[arndb]

Orion5x does not allow PCI to be described in DT, because of the way GPIOs are used for PCI interrupts. There is a bit of C code to make this work. See lunn/linux@be19cb5 arch/arm/mach-orion5x/board-pro2.c which is very similar to board-rd88f5182.c.

Out of curiosity, what is the problem with a DT representation of this? I would have expected that this could easily be expressed in an interrupt-map property, as long as the gpio controller is represented as an irqchip in DT.

[lunn]

I assume you are appending the DT blob to the kernel and using CONFIG_ARM_APPENDED_DTB? Hopefully earlyprintk will give more clues.

[1000001101000]

I used flash-kernel to handle the append which gave the expected output. Looking closer I may have generated a kernel that was too large for this device. I'm working on adding earlyprink and adjusting the config before my next attempt.