Help needed for porting Buffalo LS421DE img to LS220DE

For Developers
1

'Sup mates, all good?

I have a Buffalo LS220DE NAS device. It's working, but httpadmin got corrupted or smth (seems a common issue on stock Buffalo fw).

Before that, I already was "flirting" with OpenWrt LS421DE img [https://openwrt.org/toh/buffalo/ls421de]. It's, basically, the same setup, just a lower arm of same family, less ram, and only a usb2.0 port (LS421DE have a 2nd, 3.0).

So I took courage and reached step 5 of above tutorial. But after reboot, the main led keeps blinking (I left the first reboot for 30min), and soft powerswitch of the back panel loses functionality. The expected behavior was the led blink a couple of minutes on the boot, and reach a solid state after.

[Important note: I had to disable w10 fw on the network type I was (public in my case, public IPv6 -- but even if I change to private that was needed too) to reach Buffalo correctly, even with IPv4 being just internal lan.]

No connection at all. Telnet, SSH, ftp, NAS Manager, no DHCP offers to w10 if wired directly, no ip leased if connected to my main OpenWrt...

Powered off, removed the hd's, booted, LS220DE got into emergency mode with stock fw. Hotplugged both hd's at same time (they'r a raid1), mounted both sda1 and sdb1, restored the stock uImage. New AC power-off, booted as expected, returning to previous state -- httpadmin-less.

Since I want a better hw usage (terrible stock fw), and use smb3 or 4, and assuming that just few changes must be made, I think I can achieve the port of OpenWrt to Buffalo LS220DE NAS.

But I need some directions. I'm damn rusty, several linux commands changed nowadays. And I don't know if Debian WSL environment would do the job for compiling some build.

This would be an acceptable approach for what I'm intended to? [[Solved] How to make firmware image compatible with other devices]

Also, I found the LS421DE port topic here: [Buffalo LS421DE].

I got a partial dmesg on Putty (freezes), it's at the end of the topic (in w10 telnet, it freezes at the command, doesn't show anything!). I can lsmod, but shows me only usb & hdd ppl. I can cat almost any file, but the important ones, like /var/log/messages & /var/log/linkstation.log, freezes. Messages after few lines (from 12h ago), and linkstation.log at the command. I think it's because connection is by lan, not serial port. O_o

Several tech info and a full dmesg (& friends) are avaliable @ [https://buffalonas.miraheze.org/wiki/Linkstation_LS220D].

Also, there is the Debian on Buffalo Git [https://github.com/1000001101000/Debian_on_Buffalo/] [https://www.youtube.com/watch?v=dfMHlLmsSF8], but I don't want it (besides being my favorite distro), I want and need a light direct-approach fw, and OpenWrt is perfect in this way.

Someone can please give me a hand on trying to figure out the path to the success? xD

LK

###lsmod

usblp                   8257  0
usb_storage            33204  0
ohci_hcd               16860  0
ehci_hcd               33698  0
xhci_hcd               60842  0
usbcore               111314  6 usblp,usb_storage,ohci_hcd,ehci_hcd,xhci_hcd
usb_common               525  1 usbcore

###dmesg

Booting Linux on physical CPU 0
Initializing cgroup subsys cpu
Linux version 3.3.4 (nasbuild@nasbuild) (gcc version 4.6.2 (Linaro GCC branch-4.6.2. Marvell GCC 201201-883.01c949de) ) #1 Mon Dec 6 19:56:18 JST 2021
CPU: Marvell PJ4Bv7 Processor [561f5811] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: Marvell Armada-370
Using UBoot passing parameters structure
>>>>>>>Tag MAC <censored>
>>>>>>>Tag MAC <censored>
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c0578a44, node_mem_map c05b2000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65024 pages, LIFO batch:15
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2 rw initrd=0x2600040 panic=5 BOOTVER=0.38 UBOOT_DATE=2019/12/18 mtdparts=armada-nand:0x2000000(boot),0x1e000000(rootfs)
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 236176k/236176k available, 25968k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
    lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0524f3c   (5236 kB)
      .init : 0xc0525000 - 0xc054a000   ( 148 kB)
      .data : 0xc054a000 - 0xc0579820   ( 191 kB)
       .bss : 0xc0579844 - 0xc05b1a10   ( 225 kB)
NR_IRQS:256
axp_time_init
Calibrating delay loop... 795.44 BogoMIPS (lpj=3977216)
pid_max: default: 32768 minimum: 301
Mou
2

Searching OpenWrt github, I found:

[target/linux/mvebu/image/cortexa9.mk]

define Device/buffalo_ls421de
  $(Device/NAND-128K)
  DEVICE_VENDOR := Buffalo
  DEVICE_MODEL := LinkStation LS421DE
  SUBPAGESIZE :=
  KERNEL_SIZE := 33554432
  FILESYSTEMS := squashfs ubifs
  KERNEL := kernel-bin | append-dtb | uImage none | buffalo-kernel-jffs2
  KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none
  DEVICE_DTS := armada-370-buffalo-ls421de
  DEVICE_PACKAGES :=  \
    kmod-rtc-rs5c372a kmod-hwmon-gpiofan kmod-hwmon-drivetemp kmod-usb3 \
    kmod-linkstation-poweroff kmod-md-raid0 kmod-md-raid1 kmod-md-mod \
    kmod-fs-xfs mkf2fs e2fsprogs partx-utils
endef
TARGET_DEVICES += buffalo_ls421de

I was able to dmesg grepping NAND, and confirmed the same blocksize, "$(Device/NAND-128K)".

Proposed commit:

define Device/buffalo_ls200
  $(Device/NAND-128K)
  DEVICE_VENDOR := Buffalo
  DEVICE_MODEL := LinkStation LS200 Series
  SUBPAGESIZE :=
  KERNEL_SIZE := 33554432
  FILESYSTEMS := squashfs ubifs
  KERNEL := kernel-bin | append-dtb | uImage none | buffalo-kernel-jffs2
  KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none
  DEVICE_DTS := armada-370-buffalo-ls200
  DEVICE_PACKAGES :=  \
    kmod-rtc-rs5c372a kmod-hwmon-gpiofan kmod-hwmon-drivetemp \
    kmod-linkstation-poweroff kmod-md-raid0 kmod-md-raid1 kmod-md-mod \
    kmod-fs-xfs mkf2fs e2fsprogs partx-utils
endef
TARGET_DEVICES += buffalo_ls200

Should the KERNEL_SIZE remain the same?

Adding the section, does it need to be device specific?
There's LS210 (1 hdd) and LS220 (2hdds),
[https://www.buffalotech.com/products/linkstation-200-series]

I can add a "umbrella" like the "LS200 Series" above -- and the devices will recognize? Or needs do the one by one?

Do I need add "SUPPORTED_DEVICES += buffalo_ls210" , "SUPPORTED_DEVICES += buffalo_ls220"? How/what defines the string what the device would recognize? (Because I wonder that's why LS421DE img failed at boot on LS220DE. Too trippy?)

On LS421DE OpenWrt install, /boot/initrd.buffalo remains untouched. Maybe it's because the version 0.13 of the bootloader?

Thanks in advance.

LK

3

Check the doozan forum, they likely have support for this NAS already in Debian

4

Tnx jdwl1o1, but as I wrote in the 1st post, I'm aware of the beautiful Debian support on Buffalo's NAS, but I want OpenWrt.

I guess I'm pretty close from getting it.

5

Made a few more tests.

In fact I couldn't downgrade bootloader in the earlier OpenWrt install try -- and I think nor now. Dunno if that (up-to-date bootloader) what made LS421 img not load.

I spoke think because maybe the "u-boot mainline" (not much aware of what is, found reading [https://forum.doozan.com/read.php?3,84034,84329]) is forcing the "answer" of bootloader version number arbitrarily despite the "real" bootloader -- and what I did below worked, despite dmesg still returning BOOTVER=0.38. No idea if nand bootloader is assuming control.
Makes no sense (for me) u-boot.buffalo file on hdd, if the sys always uses the nand one -- like, if the nand gets damaged, nor even hdd would be accessed, making the idea of copy useless for soft recovery purposes.

On "normal boot" LS220 environment (system on hd, not nand), I saw an eventual bootloader backup (2017 date) on /boot:

722172 Feb  3 22:46 u-boot.buffalo*
722172 Feb  3 20:11 u-boot.buffalo.bak* (bkp what I made)
745812 Jun 12  2017 u-boot.buffalo.org*
200 Dec 15  2021 u-boot.files*

cat u-boot.files (nand locations?!?):

0x0000001D u-boot-ls210.buffalo.updated
0x0000300D u-boot-ls220.buffalo.updated
0x0000300E u-boot-ls220.buffalo.updated
0x00003011 u-boot-ls220.buffalo.updated
0x0000002E u-boot-ls210.buffalo.updated

I bkped the u-boot.buffalo, initrd.buffalo, and uImage.buffalo, copied the u-boot.buffalo.org in place to u-boot.buffalo, uploaded (-xfer in acp_commander) some old initrd.buffalo and uImage.buffalo got in [https://blog.aaronhastings.me/content/buffalo_ls200/TFTP_Boot_Recovery_LS200.zip] [https://blog.aaronhastings.me/completely-recovering-from-a-bricked-buffalo-linkstation-ls200-series-nas-and-opening-the-firmware-too/], rebooted, and not problems (except the previous httpadmin error).

But BOOTVER stills 0.38 grepping dmesg, despite teorical changes.
Since I was working on hdd (/dev/sd[ab]1), sounds very likely that the NAND copy of bootloader is taking care of it. Or not, could be u-boot mainline. I'm too ignorant on this to know. Look the lsblk:

NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
mtdblock0  31:0    0     1M  0 disk
mtdblock1  31:1    0    32M  0 disk
mtdblock2  31:2    0   480M  0 disk
sda         8:0    0   3.7T  0 disk
|-sda1      8:1    0 976.6M  0 part
| `-md0     9:0    0 976.4M  0 raid1 /boot
[...]

mtd_debug binary isn't present on normal boot -- probably on recovery (nand) also not.

Since I got no progress, I restored the bkps.

Still stalled on what changes are needed on OpenWrt sourcefiles, and how to interact with initrd.buffalo and bootloader 0.38 to make things happen.

LK

6

Uboot version is unlikely to have any impact on whether you can run openwrt on your device.

But the different ram size will. You need a unique dts defining the correct hardware for your device and then compile an openwrt image matching your device setup and dts.

You also need a serial / uart console connection so you can see where the device fails during boot. It is near impossible to add new device support without uart access

1 Like
7

See https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Bullseye/device_trees/armada-370-linkstation-ls220d.dts for a proper DTS file for this device. You should be able to use it and then follow the pattern used to create the LS412DE changes to create a version for the LS220DE.

2 Likes
8

It's almost the same hardware as LS421DE but the main difference is the RAM size. In theory, the support should be quite easy. We will need to also add it to the linkstation poweroff driver for a proper shutdown/reboot (assuming it uses the same hardware poweroff mechanism).

I can compile a compatible firmware for testing.

1 Like
9

Hi Dani, thanks for making the LS421DE port and for arriving here :smiley:

That would be wonderful. I was in doubt of making a LS200 generic makefile profile, but I guess would be better a LS220 one, and some eventual LS210 user can test and assure it works. The main difference between them is the second sata II port. But eventually could have changes in gpios, led, etc.

The LS220 soft poweroff button is like LS421 one, between eth and usb in the back panel.

I dmeseged to a .txt, and was able to cat it. Some info, pretty similar to Miraheze logs:

CPU: Marvell PJ4Bv7 Processor [561f5811] revision 1 (ARMv7), cr=10c53c7d
CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
Machine: Marvell Armada-370
[...]
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 65536
free_area_init_node: node 0, pgdat c0578a44, node_mem_map c05b2000
  Normal zone: 512 pages used for memmap
  Normal zone: 0 pages reserved
  Normal zone: 65024 pages, LIFO batch:15
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 65024
Kernel command line: console=ttyS0,115200 root=/dev/sda2 rw initrd=0x2600040 panic=5 BOOTVER=0.38 UBOOT_DATE=2019/12/18 mtdparts=armada-nand:0x2000000(boot),0x1e000000(rootfs)
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 256MB = 256MB total
Memory: 236176k/236176k available, 25968k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    vmalloc : 0xd0800000 - 0xff000000   ( 744 MB)
    lowmem  : 0xc0000000 - 0xd0000000   ( 256 MB)
    pkmap   : 0xbfe00000 - 0xc0000000   (   2 MB)
    modules : 0xbf000000 - 0xbfe00000   (  14 MB)
      .text : 0xc0008000 - 0xc0524f3c   (5236 kB)
      .init : 0xc0525000 - 0xc054a000   ( 148 kB)
      .data : 0xc054a000 - 0xc0579820   ( 191 kB)
       .bss : 0xc0579844 - 0xc05b1a10   ( 225 kB)
NR_IRQS:256
[...]
CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 256MB
SDRAM_CS1 ....disable
SDRAM_CS2 ....disable
SDRAM_CS3 ....disable
DEVICE_CS0 ....base f2000000, size  32MB
DEVICE_CS1 ....no such
DEVICE_CS2 ....no such
DEVICE_CS3 ....no such
PEX0_MEM ....base e0000000, size  32MB
PEX0_IO ....base f1100000, size   1MB
PEX1_MEM ....base e2000000, size  32MB
PEX1_IO ....base f1200000, size   1MB
INTER_REGS ....base d0000000, size   1MB
DMA_UART ....no such
SPI_CS0 ....base f0000000, size  16MB
[...]
DEV_BOOTCS ....base f5000000, size  16MB
PMU_SCRATCHPAD ....no such
CRYPT0_ENG ....base c8010000, size  64KB
[...]
SPI Serial flash detected @ 0xf0000000, 1024KB (16sec x 64KB)
armada-nand armada-nand.0: Initialize HAL based NFC in 8bit mode with DMA Disabled using BCH 4bit ECC
NAND device: Manufacturer ID: 0x98, Chip ID: 0xdc (Toshiba NAND 512MiB 3,3V 8-bit)
[...]
Creating 2 MTD partitions on "armada-nand":
0x000000000000-0x000002000000 : "boot"
0x000002000000-0x000020000000 : "rootfs"

I can see gpio's assignments if told how to (software or board trail seeking).

If is in the hand to you send me the binary, I would appreciate a lot!

LK

10

But I ask you Dani, expert on those NAS devices, about NAND partitioning and (%P) multiboot.

In the step 12 of OpenWrt LS421 tuto:

It will boot with openwrt installed in the NAND flash

So, I'll lose the stock fw of Emergency Mode stored in NAND?

That NAND has a lot of space, I wonder if is possible to "repartition" it, letting the Buffalo EM fw untouched, but adding OpenWrt after it -- and programming some behavior on the bootloader or smth, like "untouched boot", go to OpenWrt NAND, "reset button boot" try to go to stock Buffalo on hdd, if not, EM Buffalo in NAND.

What you folks think about this? Too trippy?

LK

11

It probably can be done, but I prefer to keep things as simple as possible to avoid headaches. For recovering purposes you just need to keep a hard drive with the linkstation OS installed.

The bootloader will load in the first place the OS stored at the Sata Hard drive even if the NAND was void. For reflashing again the NAND with the original stuff you'll only need to perform a regular upgrade of the Buffallo software.

Since OpenWrt is mainly used for embedded software, we use the NAND flash if present. Also respecting the original partitioning if possible. I we didn't want to touch the NAND then probably a regular Debian installation is preferred.

1 Like
12

Wonderful, that would make the job.

Indeed firmwares are made to run from nand's, eeprom's, etc, not that crazy slow Buffalo way. Dunno why Buffalo letted so much free space on NAND, that more complex partitioning scheme above would work also for a recovery and running purposes.

Btw, Debian on Buffalo I think it's a hdd install also, too robust to a 512mb install.

Thanks again for your enlightenment.

LK

13

After minor modifications a compiled a firmware specific for LS220DE:
openwrt-buffalo_ls220d-test.zip

I'm not sure if the bootloader will load my initramfs for installing via sysupgrade (for some reason it grew a lot up to the 6MB limit). I can shrink it by deleting unused packages.

Testing via serial console and TFTP would make things easier. Using the 2nd method.

BTW for this firmware you need an old bootloader which uses a jffs2 filesystem for the kernel partition. I preferred this old bootloader to avoid nasty bugs on the ethernet interface. Not sure if this is the same version I used in my LS421DE unit.

1 Like
14

Hi Dani, I'm compiling here too. Never imagined that would be a endurance mission.

Got the llvm-bpf error, worked around [Snapshots fail to build because of llvm-bpf - #6 by VA1DER], more info @ my script in the next msg. Now I'm getting compiling error of kmod-hwmon-gpiofan on end of make.

Your initramfs works flawlessly, but sysupgrade don't. I'm damn lazy to solder the serial interface.
After running the sysupg, I guess SPI bootloader prevents from further action -- removing or not the hdd's, I get the stock error 7 red led of Buffalo manual.
Also could be incorrect SPI addresses at dts file, how can I confirm it?

I'm unable to find an older bootloader for LS220.
Also, eventually the SPI addresses table (what is mapped where) can be different for LS220 (dunno if LS421 bootloader would work).

LS220D ?SPI? table (u-boot.files):

0x0000001D u-boot-ls210.buffalo.updated
0x0000300D u-boot-ls220.buffalo.updated
0x0000300E u-boot-ls220.buffalo.updated
0x00003011 u-boot-ls220.buffalo.updated
0x0000002E u-boot-ls210.buffalo.updated

I didn't found the LS421 ?SPI? table on ls400-v134en.zip.

Sysupgrade runs quite fast, and NAS immediately restarts, would be better a shutdown instead a reboot after the sysupgrade. I tryed 3 times, so I'm completely sure that I avoided a hdd bootup.

I guess that sharing actual bootloader wouldn't help, would need some IDA decompiling & study. But he's the point to achieve success on NAND flash.

I'm restoring Buffalo stock fw on nand for the 4th time, will try to use squashfs binary directly from hd next time. Heard about some restrictions, like configs getting lost.

Major doubt: if the flash fully worked as intended (i.e. older SPI bootloader), in each NAS boot I would have to take of the hdd's to load correctly OpenWrt from NAND?
That would be a partial problem, nobreak without battery, and several power outages this year where I live -- climate changes.

15

What I did for compiling:

git clone https://git.openwrt.org/openwrt/openwrt.git
cd openwrt
git pull
git branch -a
git tag
git checkout v22.03.3
./scripts/feeds update -a
./scripts/feeds install -a
wget https://github.com/1000001101000/Debian_on_Buffalo/raw/master/Bullseye/device_trees/armada-370-linkstation-ls220d.dts -O target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls220d.dts
cat <<EOT >> target/linux/mvebu/image/cortexa9.mk
define Device/buffalo_ls220d
  \$(Device/NAND-128K)
  DEVICE_VENDOR := Buffalo
  DEVICE_MODEL := LinkStation LS220D Series
  SUBPAGESIZE :=
  KERNEL_SIZE := 33554432
  FILESYSTEMS := squashfs ubifs
  KERNEL := kernel-bin | append-dtb | uImage none | buffalo-kernel-jffs2
  KERNEL_INITRAMFS := kernel-bin | append-dtb | uImage none
  DEVICE_DTS := armada-370-buffalo-ls220d
  DEVICE_PACKAGES :=  \
    kmod-rtc-rs5c372a kmod-hwmon-gpiofan kmod-hwmon-drivetemp \
    kmod-linkstation-poweroff kmod-md-raid0 kmod-md-raid1 \
    kmod-md-mod kmod-fs-xfs mkf2fs e2fsprogs partx-utils
endef
TARGET_DEVICES += buffalo_ls220d
EOT
wget https://downloads.openwrt.org/releases/22.03.3/targets/mvebu/cortexa9/config.buildinfo -O .config

Until here, all good. Then, I got a llvm-bpf compiling error (at end of this msg), and worked around with part of this advice: [Snapshots fail to build because of llvm-bpf - #6 by VA1DER]

sudo apt install lsb-release wget software-properties-common gnupg #llvm compile error workaround
sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh)" #llvm compile error workaround
wget https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/llvm-bpf-15.0.7.Linux-x86_64.tar.xz #just in case
tar -xvf llvm-bpf-15.0.7.Linux-x86_64.tar.xz
echo CONFIG_BPF_TOOLCHAIN_HOST_PATH="/usr/lib/llvm-15" >> .config 
echo CONFIG_PACKAGE_qosify=y >> .config
make menuconfig #selecting only ls220d subtarget, and setting "use prebuilt" on adv settings (dev) -> bpf toolchain, saving all to .config again
make -j $(nproc) V=sc toolchain/install #no errors using prebuilt llvm
make -j $(nproc) download

Still no problems. But at the final make, I got another compiling error, at kmod-hwmon-gpiofan package (at end of this msg).
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin make -j $(nproc) V=sc #I'm on WSL Debian

Tutorial notes [https://openwrt.org/docs/guide-developer/toolchain/use-buildsystem]":

"Note that make kernel_menuconfig modifies the Kernel configuration templates of the build tree and clearing the build_dir will not revert them. :!: Also you won't be able to install kernel packages from the official repositories when you make changes here."

I guess that cmd should be replace from "typical build steps" tutorial -- putting make download in place --, the first preformatted box of above site ("Quick image building guide" -> "Build system usage"). Do you ppl agree? Should someone or I change it?
Also, in the above guide, make download appears after make kernel_menuconfig and before make defconf. Is that right, or make download should be the first cmd? Pardon my ignorance.

###llvm-bpf error

make[3] -C tools/mpc compile
    ERROR: tools/llvm-bpf failed to build.
make -r toolchain/install: build failed. Please re-run make with -j1 V=s or V=sc for a higher verbosity level to see what's going on
make: *** [/home/w/openwrt/include/toplevel.mk:230: toolchain/install] Error 1

###kmod-hwmon-gpiofan error

Collected errors:
 * pkg_hash_check_unresolved: cannot find dependency kmod-thermal for kmod-hwmon-gpiofan
 * pkg_hash_fetch_best_installation_candidate: Packages for kmod-hwmon-gpiofan found, but incompatible with the architectures configured
 * opkg_install_cmd: Cannot install package kmod-hwmon-gpiofan.
make[2]: *** [package/Makefile:70: package/install] Error 255
make[2]: Leaving directory '/home/w/openwrt'
make[1]: *** [package/Makefile:111: /home/w/openwrt/staging_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/stamp/.package_install] Error 2
make[1]: Leaving directory '/home/w/openwrt'
make: *** [/home/w/openwrt/include/toplevel.mk:230: world] Error 2

[Try of temporary fix]
I removed kmod-hwmon-gpiofan from make menuconfig (kernel/modules/hwmon iirc).
Now I got a brand new error:

/home/w/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-5.10.161/arch/arm/boot/dts/armada-370-c200-v2.dts:344.6-16: Warning (reg_format): /soc/pcie@82000000/pcie@1,0/bridge@0,1/usb@1,0/port@1:reg: property has invalid length (4 bytes) (#address-cells == 3, #size-cells == 2)
/home/w/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/linux-5.10.161/arch/arm/boot/dts/armada-370-c200-v2.dts:349.6-16: Warning (reg_format): /soc/pcie@82000000/pcie@1,0/bridge@0,1/usb@1,0/port@2:reg: property has invalid length (4 bytes) (#address-cells == 3, #size-cells == 2)
/home/w/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/image-armada-370-c200-v2.dtb: Warning (i2c_bus_reg): Failed prerequisite 'reg_format'
/home/w/openwrt/build_dir/target-arm_cortex-a9+vfpv3-d16_musl_eabi/linux-mvebu_cortexa9/image-armada-370-c200-v2.dtb: Warning (spi_bus_reg): Failed prerequisite 'reg_format'
[...]
make: *** [/home/w/openwrt/include/toplevel.mk:230: world] Error 2

Will try a make clean and leave compiling all night. No expectations at all.

16

@danitool very interestingly the squashfs @ hdd uImage.buffalo was ignored in boot (by SPI bootloader or initrd? Seems that the NAND bkp one was loaded), but the initramfs not.
-rw-r--r-- 1 root root 37069616 Feb 4 23:23 uImage.buffalo

Something in initram (size?) bypassed eventual spi/initrd protection -- I'm wondering what is.

But I must admit, OpenWrt booting as hdd uImage, with the actual possibility of restore the original fw with only one rename/copy is the ideal setup for me.

How can I compile some hdd image to test it? There's some output binaries options (initram, squash, don't remember the others) in the middle of the process (don't remember if on make menuconfig), do you know what would fit for that purpose? Any advice?

I'll fix kmod-thermal error and walk on that way, more pratical than reverse engineering the SPI bootloader.

Tnx again.

LK

17

Syupgrade is very fast on NAND devices, it takes seconds.

Since you didn't experience issues with your ethernet port, then it might be a good idea to stick with the current bootloader. In this case the kernel should be stored into an ubifs instead of jffs2.

Can you execute this command from the original Linkstation OS?, and paste the result:
devmem 0xd00184e0

I just want to see if the ethernet phy uses the correct voltages in your unit. Our LS421DE units didn't and this seems which caused permanent problems on some of them if a recent bootloader is used.

1 Like
18

Returns:
0x00000AAA

I saw your fix and explanation on LS421 page. The only issue I had on eth was that cat/dmesg earlier error, but I found that probably was because jumbo size frames (even with 8k configured at NAS, router, and windows). No issues at all while working via ssh on initramfs.

19

For reference, the default LS220D partition table (2 equal 4tb hdd, 1 raid1 array) from lsblk (mtd0 is SPI, mtd[12] NAND):

NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
mtdblock0  31:0    0     1M  0 disk
mtdblock1  31:1    0    32M  0 disk
mtdblock2  31:2    0   480M  0 disk
sda         8:0    0   3.7T  0 disk
|-sda1      8:1    0 976.6M  0 part
| `-md0     9:0    0 976.4M  0 raid1 /boot
|-sda2      8:2    0   4.8G  0 part
| `-md1     9:1    0   4.8G  0 raid1 /
|-sda3      8:3    0 384.5K  0 part
|-sda4      8:4    0   512B  0 part
|-sda5      8:5    0 976.6M  0 part
| `-md2     9:2    0   976M  0 raid1 [SWAP]
`-sda6      8:6    0   3.6T  0 part
  `-md10    9:10   0   3.6T  0 raid1 /mnt/array1
sdb         8:16   0   3.7T  0 disk
|-sdb1      8:17   0 976.6M  0 part
| `-md0     9:0    0 976.4M  0 raid1 /boot
|-sdb2      8:18   0   4.8G  0 part
| `-md1     9:1    0   4.8G  0 raid1 /
|-sdb3      8:19   0 384.5K  0 part
|-sdb4      8:20   0   512B  0 part
|-sdb5      8:21   0 976.6M  0 part
| `-md2     9:2    0   976M  0 raid1 [SWAP]
`-sdb6      8:22   0   3.6T  0 part
  `-md10    9:10   0   3.6T  0 raid1 /mnt/array1

And lscpu:

Architecture:          armv7l
Byte Order:            Little Endian
CPU(s):                1
On-line CPU(s) list:   0
Thread(s) per core:    1
Core(s) per socket:    1
Socket(s):             1
20

Found:
[https://opensource.buffalo.jp/ls200-163.html]