Mainline Linux support for vcoreiii ASIC

[halmartin]

u-boot has basic support for the luton26, including networking support.

It is possible to build and boot u-boot on the MS220-8P with functional networking:

U-Boot 2019.10 (Apr 04 2020 - 09:26:23 +0000)

MSCC VCore-III MIPS 24Kec
Model: Luton26 PCB090 Reference Board
DRAM:  128 MiB
Loading Environment from SPI Flash... SF: Detected mx25l12805d with page size 256 Bytes, erase size 64 KiB, total 16 MiB

OK
In:    serial@10100000
Out:   serial@10100000
Err:   serial@10100000
Net:   Could not get PHY for miim-bus1: addr 0
Could not get PHY for miim-bus1: addr 1
Could not get PHY for miim-bus1: addr 2
Could not get PHY for miim-bus1: addr 3
Could not get PHY for miim-bus1: addr 4
Could not get PHY for miim-bus1: addr 5
Could not get PHY for miim-bus1: addr 6
Could not get PHY for miim-bus1: addr 7
Could not get PHY for miim-bus1: addr 8
Could not get PHY for miim-bus1: addr 9
Could not get PHY for miim-bus1: addr 10
Could not get PHY for miim-bus1: addr 11

Warning: switch@1010000 (eth0) using random MAC address - ee:6a:6f:da:b9:7a
eth0: switch@1010000
Hit any key to stop autoboot:  0 
luton # dhcp
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
DHCP client bound to address 192.168.0.51 (20779 ms)

The Luton26 PCB090 Reference Board does not correspond exactly to the MS220-8P (nor, I suspect, to the MS220-24). This is the cause of the miim-bus1 errors above, incorrect system LED output, and may be related to the MS220-8P losing uart output after userspace starts.

Support for Jaguar1 (MS42, MS220-48, MS320-48) does not yet exist in u-boot.

The ultimate stretch goal would be upstream support in the kernel for the Vitesse ASICs used in Meraki switches, as this would allow newer kernels and support for other operating systems like OpenWrt on the hardware.

[mterron]

Hi, support for the SOC and switch has been added to the upstream kernel yesterday: https://lore.kernel.org/linux-mips/20201106100849.969240-1-gregory.clement@bootlin.com/T/#t

This is the initial patchset but hopefully the switch will be fully supported upstream and we’ll be able to just use a clean kernel implementation instead of the Click router thing. It is a continuation/expansion of the work done in 2018 see: https://www.youtube.com/watch?v=OUTrzz1vwSE

This also opens up the possibility to use modern kernels.

[halmartin]

@mterron That's awesome news! I'll keep an eye on the patch set and look into building an upstream kernel.

I don't see support for the jaguar1 (VSC7434/VSC7434 Dual) mentioned in the patch set, this means that the MS320-24 and MS42/MS220-48 are still lacking upstream support.

I'm not sure how much luton differs from jaguar1, so perhaps it won't be a huge leap to add upstream support for jaguar1.

[mterron]

I don't see support for the jaguar1 (VSC7434/VSC7434 Dual) mentioned in the patch set, this means that the MS320-24 and MS42/MS220-48 are still lacking upstream support. That seems to be the case, yes.

Updated 11/02/2021 :

~ $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
~ $ cd linux-next
~/linux-next $ make ARCH=mips 32r2el_defconfig BOARDS='' menuconfig
Using ./arch/mips/configs/generic_defconfig as base
Merging arch/mips/configs/generic/32r2.config
Merging arch/mips/configs/generic/el.config
#
# configuration written to .config
#

*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.

 .config - Linux/mips 5.11.0-rc7 Kernel Configuration
 > Machine selection ──────────────────────────────────────────────────────────────────────
  ┌────────────────────────────────── Machine selection ──────────────────────────────────┐
  │  Arrow keys navigate the menu.  <Enter> selects submenus ---> (or empty submenus      │
  │  ----).  Highlighted letters are hotkeys.  Pressing <Y> includes, <N> excludes, <M>   │
  │  modularizes features.  Press <Esc><Esc> to exit, <?> for Help, </> for Search.       │
  │  Legend: [*] built-in  [ ] excluded  <M> module  < > module capable                   │
  │ ┌───────────────────────────────────────────────────────────────────────────────────┐ │
  │ │          System type (Generic board-agnostic MIPS kernel)  --->                   │ │
  │ │          *** Legacy (non-UHI/non-FIT) Boards ***                                  │ │
  │ │      [ ] Support MIPS SEAD-3 boards                                               │ │
  │ │      [ ]   Legacy support for Ocelot based boards                                 │ │
  │ │          *** FIT/UHI Boards ***                                                   │ │
  │ │      [ ] Include FDT for MIPS Boston boards                                       │ │
  │ │      [ ] Include FDT for NI 169445                                                │ │
  │ │      [ ] Include FDT for Xilfpga                                                  │ │
  │ │      [ ] Include FDT for Microsemi Ocelot development platforms                   │ │
  │ │      [*] Include FDT for Microsemi Luton development platforms                    │ │
  │ │      [ ] Include FDT for Microsemi Jaguar2 development platforms                  │ │
  │ │      [ ] Include FDT for Microsemi Serval development platforms                   │ │
  │ │      [ ] Support boards based on Ingenic SoCs                                     │ │
  │ └──────v(+)─────────────────────────────────────────────────────────────────────────┘ │
  ├───────────────────────────────────────────────────────────────────────────────────────┤
  │               <Select>    < Exit >    < Help >    < Save >    < Load >                │
  └───────────────────────────────────────────────────────────────────────────────────────┘

[halmartin]

u-boot already works on the MS220-8P, but with pcb090 device tree:

U-Boot 2019.10-dirty (Apr 02 2020 - 20:10:10 +0000)

MSCC VCore-III MIPS 24Kec
Model: Luton26 PCB090 Reference Board
DRAM:  128 MiB
Loading Environment from SPI Flash... SF: Detected mx25l12805d with page size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment

In:    serial@10100000
Out:   serial@10100000
Err:   serial@10100000
Net:   Could not get PHY for miim-bus1: addr 0
Could not get PHY for miim-bus1: addr 1
Could not get PHY for miim-bus1: addr 2
Could not get PHY for miim-bus1: addr 3
Could not get PHY for miim-bus1: addr 4
Could not get PHY for miim-bus1: addr 5
Could not get PHY for miim-bus1: addr 6
Could not get PHY for miim-bus1: addr 7
Could not get PHY for miim-bus1: addr 8
Could not get PHY for miim-bus1: addr 9
Could not get PHY for miim-bus1: addr 10
Could not get PHY for miim-bus1: addr 11

Warning: switch@1010000 (eth0) using random MAC address - 4a:fb:d9:42:97:e4
eth0: switch@1010000
Hit any key to stop autoboot:  0 

I was never able to get u-boot working on the MS220-8P using pcb091

Also, when using u-boot as the bootloader with the pcb090 device tree, console output was always broken in userspace. e.g. you can see kernel messages (including kernel output after the kernel invokes init) but userspace output is never displayed via UART:

[    0.669000] devtmpfs: mounted
[    0.713000] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.
[    0.743000] devtmpfs: mounted
[    0.751000] Freeing unused kernel memory: 292K
(there should be output from init starting here, but there isn't)
[    5.780000] random: dropbear urandom read with 86 bits of entropy available
[  105.150000] random: nonblocking pool is initialized

I have not been able to determine the root cause of this.

[mterron]

Have you tried looking into https://github.com/halmartin/switch-11-22-ms220/tree/master/linux-3.18/arch/mips/meraki/ms220-8.* ? That should have the correct config to create a working dts.

It does seems like ms220-8p is a different board from PCB090 and PCB091.

[halmartin]

🤦 I was always focused on arch/mips/vcoreiii/ and totally missed that arch/mips/meraki exists. Thanks for the tip!

[halmartin]

Were the patches delayed, or am I being dense? I'm looking at 5.10.0-rc6 from kernel.org:

 .config - Linux/mips 5.10.0-rc6 Kernel Configuration                                                                
 > Machine selection                                                                                                 
  lq Machine selection qk                                                                                            
  x  Arrow keys navigate the menu.  <Enter> selects submenus ---> (or empty submenus ----).  Highlighted letters x   
  x  are hotkeys.  Pressing <Y> includes, <N> excludes, <M> modularizes features.  Press <Esc><Esc> to exit, <?> x   
  x  for Help, </> for Search.  Legend: [*] built-in  [ ] excluded  <M> module  < > module capable               x   
  x                                                                                                              x                                                                                                            
  x x                      System type (Generic board-agnostic MIPS kernel)  --->                              x x   
  x x                      *** Legacy (non-UHI/non-FIT) Boards ***                                             x x   
  x x                  [*] Support MIPS SEAD-3 boards                                                          x x   
  x x                        *** MSCC Ocelot doesn't work with SEAD3 enabled ***                               x x   
  x x                      *** FIT/UHI Boards ***                                                              x x   
  x x                  [*] Include FDT for MIPS Boston boards                                                  x x   
  x x                  [*] Include FDT for NI 169445                                                           x x   
  x x                  [*] Include FDT for Xilfpga                                                             x x   
  x x                  [*] Include FDT for Microsemi Ocelot development platforms                              x x   
  x x                  [ ] Support boards based on Ingenic SoCs                                                x x   
  x x                  [*] Support Ranchu platform for Android emulator   

No Luton/Jaguar2 options under FIT

[mterron]

You want to follow Gregory: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/log/?qt=author&q=gregory+clement

[mterron]

If you can define a new BOARD using the data on the Meraki GPL dump, then you should get a kernel that just works (TM)

[halmartin]

Thanks for the update. I've been following the status of things and it looks like upstream support is coming for luton26.

You're correct that there's still some work to be done, someone will need to write appropriate device trees for both u-boot and the kernel. I also have not seen any upstream support for the Jaguar1 ASIC, which is used in the 48 port models.

Until things mature a bit, I don't see myself investing a lot of time into this, especially when support is still limited to -rc kernel versions and only luton26.

As always, I welcome PRs if someone else gets a mainline kernel booting.

[halmartin]

I have spent several evenings on this, and I must be doing something horribly wrong

Filename 'vmlinux.gz.itb'.
Load address: 0x80100000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #####################################
         765.6 KiB/s
done
Bytes transferred = 4513820 (44e01c hex)
luton # bootm 0x80100000
## Loading kernel from FIT Image at 80100000 ...
   Using 'conf@default' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux 5.11.0
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x801000c0
     Data Size:    4509639 Bytes = 4.3 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x80100000
     Entry Point:  0x8086705c
     Hash algo:    sha1
     Hash value:   c44ff616ea6c066a94c0161c82b9ab0aae4bd58f
   Verifying Hash Integrity ... sha1+ OK
   Uncompressing Kernel Image
Error: inflate() returned -3
gzip compressed: uncompress error -1
Must RESET board to recover

I don't really understand how the ITB is created, since the kernel compression used is not GZIP but rather LZMA (CONFIG_KERNEL_LZMA=y). It seems to come from arch/mips/boot/vmlinux.its.S which somehow decides that GZIP is the right way to go. I also have it in my notes from previously experimenting with u-boot (back in 2020) that 0x80100000 does not work with compressed kernels, and instead to use 0x81000000 however changing this in 5.11 does not help.

I also tried writing this vmlinux.its to just boot vmlinux.bin without any additional compression, but this just results in a different error:

## Loading kernel from FIT Image at 81000000 ...
   Using 'conf@luton_pcb091' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux 5.11.0
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x810000c0
     Data Size:    11584912 Bytes = 11 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x81000000
     Entry Point:  0x81891804
     Hash algo:    sha1
     Hash value:   d13175476fd38269a02a3e85bef53419092c01e1
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 81000000 ...
   Using 'conf@luton_pcb091' configuration
   Trying 'fdt@luton_pcb091' fdt subimage
     Description:  img,luton_pcb091 Device Tree
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x81b0c758
     Data Size:    2303 Bytes = 2.2 KiB
     Architecture: MIPS
     Hash algo:    sha1
     Hash value:   daa8a8147bbce692d81383af7b748a763212bb24
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x81b0c758
   Loading Kernel Image
ERROR: new format image overwritten - must RESET the board to recover

The error implies that I'm somehow overwriting the kernel in memory, but I know not how to resolve it. If someone knows, please tell me. I grow weary of banging my head against u-boot and patching Load Addresses in the kernel.

[mterron]

I presume this its.S files work as overlays so I'd look into arch/mips/generic/board-luton.its.S to see if there's any clue there?

uboot has an iminfo command so iminfo 0x80100000 should show you what uboot thinks the image looks like.

[halmartin]

luton # iminfo ${loadaddr}

## Checking Image at 81000000 ...
   FIT image found
   FIT description: Linux 5.11.0
    Image 0 (kernel@0)
     Description:  Linux 5.11.0
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x810000c0
     Data Size:    5151848 Bytes = 4.9 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x81000000
     Entry Point:  0x818806e4
     Hash algo:    sha1
     Hash value:   86327f66e6022c031b0b165b867ff6fb2cd9c3b5
    Image 1 (fdt@luton_pcb091)
     Description:  MSCC Luton PCB091 Device Tree
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x814e9e30
     Data Size:    2851 Bytes = 2.8 KiB
     Architecture: MIPS
     Hash algo:    sha1
     Hash value:   5283ae4322294e594a7be5e6de65e4f039ff36a5
    Default Configuration: 'conf@default'
    Configuration 0 (conf@default)
     Description:  Generic Linux kernel
     Kernel:       kernel@0
    Configuration 1 (pcb091)
     Description:  Luton Linux kernel
     Kernel:       kernel@0
     FDT:          fdt@luton_pcb091
## Checking hash(es) for FIT Image at 81000000 ...
   Hash(es) for Image 0 (kernel@0): sha1+
   Hash(es) for Image 1 (fdt@luton_pcb091): sha1+

Looks good, right?

luton # bootm 0x81000000 - 0x814e9e30
## Loading kernel from FIT Image at 81000000 ...
   Using 'conf@default' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux 5.11.0
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x810000c0
     Data Size:    5151848 Bytes = 4.9 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x81000000
     Entry Point:  0x818806e4
     Hash algo:    sha1
     Hash value:   86327f66e6022c031b0b165b867ff6fb2cd9c3b5
   Verifying Hash Integrity ... sha1+ OK
## Flattened Device Tree blob at 814e9e30
   Booting using the fdt blob at 0x814e9e30
   Uncompressing Kernel Image
Error: inflate() returned -3
gzip compressed: uncompress error -1
Must RESET board to recover

Doesn't boot.

[mterron]

Reading the Zlib manual (https://www.zlib.net/manual.html), I found this:

inflate() returns (...) Z_DATA_ERROR (-3) if the input data was corrupted (input stream not conforming to the zlib format or incorrect check value, in which case strm->msg points to a string with a more specific error)

[halmartin]

Well, according to file it is a valid gzip archive (and the decompressed size is under the BOOTM_LEN in uboot):

$ file linux-custom/arch/mips/boot/vmlinux.bin.gz
linux-custom/arch/mips/boot/vmlinux.bin.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 11494800

I considered that perhaps the kernel compression method (I had chosen LZMA) needed to be gzip, so I recompiled the kernel with gzip selected instead of LZMA, same result.

I will email Gregory, maybe he has some suggestions for how to boot this.

[halmartin]

Asked on StackOverflow: https://stackoverflow.com/questions/66950536/u-boot-cannot-boot-linux-kernel-despite-kernel-being-less-than-maximum-bootm-le

[halmartin]

Quoting from the SO answer:

The final problem you run in to:

ERROR: new format image overwritten - must RESET the board to recover

is because you've loaded the image in to memory in the same location as the entry point but you need to load it in to memory somewhere else so that U-Boot can unpack the image and put the contents where their load address is set to.

I'm still unable to boot the kernel though, it now hangs at "Uncompressing/Loading Kernel Image":

luton # tftp 0x83000000 vmlinux.gz.itb
luton # bootm 0x83000000
## Loading kernel from FIT Image at 83000000 ...
   Using 'conf@default' configuration
   Trying 'kernel@0' kernel subimage
     Description:  Linux 5.11.11
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x830000c0
     Data Size:    5167511 Bytes = 4.9 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x80100000
     Entry Point:  0x809898f4
     Hash algo:    sha1
     Hash value:   b963ed48f45e332bd5df263dd69d69c3818e6586
   Verifying Hash Integrity ... sha1+ OK
   Uncompressing Kernel Image
(hangs indefinitely)

luton # tftp 0x83000000 vmlinux.bin
luton # tftp 0x85000000 ms220.dtb
luton # bootm 0x83000000 - 0x85000000
## Booting kernel from Legacy Image at 83000000 ...
   Image Name:   Linux 5.11.11
   Image Type:   MIPS Linux Kernel Image (uncompressed)
   Data Size:    11531664 Bytes = 11 MiB
   Load Address: 80100000
   Entry Point:  809898f4
   Verifying Checksum ... OK
## Flattened Device Tree blob at 85000000
   Booting using the fdt blob at 0x85000000
   Loading Kernel Image
(hangs indefinitely)

[mterron]

Are you sure it hangs or just there's no output? Could be the dtb is wrong somehow.

[halmartin]

The board is using the generic 32r2el config, for which there is no SYS_HAS_EARLY_PRINTK support. The BOARD parameter seems to be only for legacy targets.

[halmartin]

I have made some progress as per fb7f0ccad234e9d2c6f9fcc5afdf4b5cb63efa6e:

luton # tftpboot 0x85000000 vmlinux-5.12-20210516.itb
Using switch@1010000 device
Filename 'vmlinux-5.12-20210516.itb'.
Load address: 0x85000000
Loading: #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         #################################################################
         ###########################################################
         776.4 KiB/s
done
Bytes transferred = 4626692 (469904 hex)
luton # bootm 0x85000000#pcb091
## Loading kernel from FIT Image at 85000000 ...
   Using 'pcb091' configuration
   Trying 'kernel' kernel subimage
     Description:  Linux 5.12.4
     Type:         Kernel Image
     Compression:  gzip compressed
     Data Start:   0x850000bc
     Data Size:    4621682 Bytes = 4.4 MiB
     Architecture: MIPS
     OS:           Linux
     Load Address: 0x81000000
     Entry Point:  0x817a6abc
     Hash algo:    sha1
     Hash value:   944195eef5bb41ea67af13648852760933a9e6ae
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 85000000 ...
   Using 'pcb091' configuration
   Trying 'fdt-luton_pcb091' fdt subimage
     Description:  MSCC Luton PCB091 Device Tree
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x85468738
     Data Size:    3144 Bytes = 3.1 KiB
     Architecture: MIPS
     Hash algo:    sha1
     Hash value:   7168bcef0a81bee88510c51348b5472c7a729f82
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x85468738
   Uncompressing Kernel Image
[    0.000000] Linux version 5.12.4 (root@a97eaea4c5ba) (mipsel-buildroot-linux-uclibc-gcc.br_real (Buildroot 2020.02.10) 8.4.0, GNU ld (GNU Binutils) 2.32) #2 SMP Sun May 16 08:57:25 U
TC 2021
[    0.000000] CPU0 revision is: 02019654 (MIPS 24KEc)
[    0.000000] MIPS: machine is Luton10 PCB091 Reference Board
[    0.000000] Initrd not found or empty - disabling initrd
[    0.000000] MIPS CPS SMP unable to proceed without a CM
[    0.000000] Primary instruction cache 32kB, VIPT, 4-way, linesize 32 bytes.
[    0.000000] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes
[    0.000000] This processor doesn't support highmem. -131072k highmem ignored
[    0.000000] Zone ranges:
[    0.000000]   Normal   [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000]   HighMem  empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000000000-0x0000000007ffffff]
[    0.000000] percpu: Embedded 16 pages/cpu s34448 r8192 d22896 u65536
[    0.000000] Built 1 zonelists, mobility grouping on.  Total pages: 32480
[    0.000000] Kernel command line:
[    0.000000] Dentry cache hash table entries: 16384 (order: 4, 65536 bytes, linear)
[    0.000000] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes, linear)
[    0.000000] Writing ErrCtl register=80000811
[    0.000000] Readback ErrCtl register=80000811
[    0.000000] Cache parity protection enabled
[    0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[    0.000000] Memory: 118232K/131072K available (7869K kernel code, 686K rwdata, 1296K rodata, 1340K init, 265K bss, 12840K reserved, 0K cma-reserved, 0K highmem)
[    0.000000] SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[    0.000000] rcu: Hierarchical RCU implementation.
[    0.000000] rcu:     RCU event tracing is enabled.
[    0.000000] rcu:     RCU restricting CPUs from NR_CPUS=16 to nr_cpu_ids=1.
[    0.000000]  Tracing variant of Tasks RCU enabled.
[    0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25 jiffies.
[    0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
[    0.000000] NR_IRQS: 256
[    0.000000] random: get_random_bytes called from start_kernel+0x3d8/0x608 with crng_init=0
[    0.000000] timer_probe: no matching timers found
[    0.000000] clocksource: MIPS: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 9174050157 ns
[    0.000005] sched_clock: 32 bits at 208MHz, resolution 4ns, wraps every 10307921917ns
[    0.000315] Console: colour dummy device 80x25
[    0.002930] printk: console [tty0] enabled
[    0.003140] Calibrating delay loop... 277.50 BogoMIPS (lpj=555008)
[    0.036179] pid_max: default: 32768 minimum: 301
[    0.036683] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.036920] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.045086] rcu: Hierarchical SRCU implementation.
[    0.046966] smp: Bringing up secondary CPUs ...
[    0.047161] smp: Brought up 1 node, 1 CPU
[    0.049225] devtmpfs: initialized
[    0.054180] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[    0.054504] futex hash table entries: 256 (order: 3, 32768 bytes, linear)
[    0.055088] pinctrl core: initialized pinctrl subsystem
[    0.057463] NET: Registered protocol family 16
[    0.059349] thermal_sys: Registered thermal governor 'step_wise'
[    0.095266] pm-cps: no CM, non-coherent states unavailable
[    0.131695] vgaarb: loaded
[    0.132654] SCSI subsystem initialized
[    0.133552] pps_core: LinuxPPS API ver. 1 registered
[    0.133723] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[    0.133963] PTP clock support registered
[    0.137789] clocksource: Switched to clocksource MIPS
[    0.185006] NET: Registered protocol family 2
[    0.185760] IP idents hash table entries: 2048 (order: 2, 16384 bytes, linear)
[    0.187462] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 6144 bytes, linear)
[    0.187914] TCP established hash table entries: 1024 (order: 0, 4096 bytes, linear)
[    0.188182] TCP bind hash table entries: 1024 (order: 1, 8192 bytes, linear)
[    0.188387] TCP: Hash tables configured (established 1024 bind 1024)
[    0.188898] UDP hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.189234] UDP-Lite hash table entries: 256 (order: 1, 8192 bytes, linear)
[    0.190286] NET: Registered protocol family 1
[    0.193625] RPC: Registered named UNIX socket transport module.
[    0.193827] RPC: Registered udp transport module.
[    0.193933] RPC: Registered tcp transport module.
[    0.194036] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.194160] PCI: CLS 0 bytes, default 32
[    0.196366] Initialise system trusted keyrings
[    0.197664] workingset: timestamp_bits=14 max_order=15 bucket_order=1
[    0.211532] NFS: Registering the id_resolver key type
[    0.211779] Key type id_resolver registered
[    0.211889] Key type id_legacy registered
[    0.212316] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.212482] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.212777] fuse: init (API version 7.33)
[    0.215525] Key type asymmetric registered
[    0.215719] Asymmetric key parser 'x509' registered
[    0.215954] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    0.216163] io scheduler mq-deadline registered
[    0.216272] io scheduler kyber registered
[    0.219887] pinctrl-ocelot 60070068.pinctrl: driver registered
[    0.500345] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.507067] 70100000.serial: ttyS0 at MMIO 0x70100000 (irq = 8, base_baud = 13020833) is a 16550A
[    0.211532] NFS: Registering the id_resolver key type
[    0.211779] Key type id_resolver registered
[    0.211889] Key type id_legacy registered
[    0.212316] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[    0.212482] nfs4flexfilelayout_init: NFSv4 Flexfile Layout Driver Registering...
[    0.212777] fuse: init (API version 7.33)
[    0.215525] Key type asymmetric registered
[    0.215719] Asymmetric key parser 'x509' registered
[    0.215954] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 250)
[    0.216163] io scheduler mq-deadline registered
[    0.216272] io scheduler kyber registered
[    0.219887] pinctrl-ocelot 60070068.pinctrl: driver registered
[    0.500345] Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
[    0.507067] 70100000.serial: ttyS0 at MMIO 0x70100000 (irq = 8, base_baud = 13020833) is a 16550A
[    1.035231] printk: console [ttyS0] enabled
[    1.092709] brd: module loaded
[    1.131222] loop: module loaded
[    1.138185] libphy: Fixed MDIO Bus: probed
[    1.144272] i2c /dev entries driver
[    1.148980] sdhci: Secure Digital Host Controller Interface driver
[    1.155469] sdhci: Copyright(c) Pierre Ossman
[    1.163758] NET: Registered protocol family 10
[    1.172005] Segment Routing with IPv6
[    1.176235] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[    1.184450] NET: Registered protocol family 17
[    1.190555] Key type dns_resolver registered
[    1.195467] Loading compiled-in X.509 certificates
[    1.201126] Key type ._fscrypt registered
[    1.205481] random: fast init done
[    1.209017] Key type .fscrypt registered
[    1.213121] Key type fscrypt-provisioning registered
[    1.227691] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    1.235725] Please append a correct "root=" boot option; here are the available partitions:
[    1.244427] 0100            4096 ram0
[    1.244458]  (driver?)
(snipped)
[    1.342044] 010f            4096 ram15
[    1.342073]  (driver?)
[    1.348586] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[    1.357064] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]---

It's not correctly detecting SPI, so further booting isn't possible.

Also I overlooked this previously, but bootlin's blog post for 5.11 they mention:

For now the support only includes the base platform support, but we are working on the switchdev driver for the Ethernet switch.

So getting mainline Linux booting will not immediately mean a fully functional switch, the switchdev driver is outstanding.

[neggles]

Well, according to file it is a valid gzip archive (and the decompressed size is under the BOOTM_LEN in uboot):

$ file linux-custom/arch/mips/boot/vmlinux.bin.gz
linux-custom/arch/mips/boot/vmlinux.bin.gz: gzip compressed data, max compression, from Unix, original size modulo 2^32 11494800

I considered that perhaps the kernel compression method (I had chosen LZMA) needed to be gzip, so I recompiled the kernel with gzip selected instead of LZMA, same result.

I will email Gregory, maybe he has some suggestions for how to boot this.

Ah, this one. I love this one.

There's a fixed-size buffer that u-boot allocates in RAM for gunzip() and lzmadec() to write their outputs into. So far in most prebuilt vendor u-boots I've come across, it's been set to 8MB or 16MB. A modern kernel is too big to fit, so you have to either use a self-extracting kernel (not an option on mipsel 😞), an uncompressed kernel, or a custom-built u-boot with the buffer size increased.

Config option is CONFIG_SYS_BOOTM_LEN (which also defines how big the initial area of RAM the kernel gets passed to use at startup is).

And, uh, there's also a fully functional/buildable open-source SDK for these chips on a public microchip S3 bucket - with a directory listing here

This includes full device trees for PCB090 - which the MS220-8P is based off - and PCB091 (which is luton10, not luton26). The kernel included in the 2021.09 release is v5.10.57 which is pretty impressively recent, u-boot 2021.04 as well.

There will no doubt be some pinctrl changes and the like needed to adapt to the specifics of the MS220-8P, but that's something i've done plenty of times before... and the switchdev driver for the VSC7425 is available in there as well, though I've not tested whether it works with mainline (or DSA) yet.

Let's see how far I can get with this... 😄

[halmartin]

@neg2led This is in my local working tree, which might help you out:

--- a/include/configs/vcoreiii.h        2021-03-28 22:41:50.316157021 +0200
+++ b/include/configs/vcoreiii.h        2021-03-30 10:42:26.805635344 +0200
@@ -63,7 +63,7 @@
 #define VCOREIII_DEFAULT_MTD_ENV    /* Go away */
 #endif

-#define CONFIG_SYS_BOOTM_LEN      (16 << 20)      /* Increase max gunzip size */
+#define CONFIG_SYS_BOOTM_LEN      (32 << 20)      /* Increase max gunzip size */

 #define CONFIG_EXTRA_ENV_SETTINGS                                      \
        VCOREIII_DEFAULT_MTD_ENV                                        \

[neggles]

Thanks! I've mostly been finishing up work on another device (Sophos APX530) for the last few days, but with any luck I should get to working on this properly in the next few.

I believe I've worked out what causes loss serial console output when booting linux, as well - though it'll take a little bit more digging to find the specific bits that need tweaking to fix that.

[systemcrash]

Hi, did conversation move elsewhere or no further progress on this? I have a small pile of Zyxel GS1910-24 switches which are all based on this chipset. I'm not a seasoned kernel dev, so I think at best I can build a DTB and hope for the best.

Did Luton support ever land in the kernel?

Link to board info

[halmartin]

Did Luton support ever land in the kernel?

No. Bootlin only added preliminary support for the luton in the kernel:

For now the support only includes the base platform support, but we are working on the switchdev driver for the Ethernet switch.

As far as I can tell, support for switchdev never happened. Support has been added for other chips like Ocelot, but not Luton.

It also doesn't seem like bootlin is working on the Luton anymore.

I also bought a used GS1910-24HP with the aim to produce a custom firmware for it. It might be possible to spin a custom firmware using the Microchip MESA SDK: https://github.com/microchip-ung/mesa

I also looked at that possibility a few months ago, however it seems support for Luton has been dropped from recent MESA releases, and I didn't get around to completing a build of an older release to test.

tl;dr - no.

[systemcrash]

Did Luton support ever land in the kernel?

No. Bootlin only added preliminary support for the luton in the kernel:

As a naïve user - is full switch support possible in the kernel without this bit?

For now the support only includes the base platform support, but we are working on the switchdev driver for the Ethernet switch.

As far as I can tell, support for switchdev never happened. Support has been added for other chips like Ocelot, but not Luton.

So this is a question of migrating Luton from swdev to DSA?

It also doesn't seem like bootlin is working on the Luton anymore.

aka the linux kernel?

[halmartin]

As a naïve user - is full switch support possible in the kernel without this bit?

No. They have added support for booting the MIPS core embedded in the Luton26, but that doesn't mean the switch functions as a switch.

So this is a question of migrating Luton from swdev to DSA?

No. As far as I know, Bootlin never contributed their work upstream so there is zero support for Luton (the L2 ethernet switch) in the mainline kernel.

aka the linux kernel?

Bootlin are still contributing to the Linux kernel, but not for this device.

[systemcrash]

Hmm - so for someone with a bit of time but lacking in experience, is this, to bring up an older code-base to a modern kernel, biting off more than one can chew? I mean, the datasheet is there, and the code base isn't so old. So, in theory everything is available...?

[halmartin]

@systemcrash it is probably easier to look at the Microchip MESA SDK and build that before you tackle porting everything to a mainline kernel. The MESA documentation states that xstax (SMBStaX) is a build target for Luton, so while you won't have switchdev/DSA, you should be able to build something much more modern that the ZyXel firmware.

[systemcrash]

I see. Thanks @halmartin. I was interested to get openwrt running on the 1910s. But poking around in MESA might give some inspiration.