Buffalo LS421DE

I have a target in the form of the Buffalo LS421DE two disk NAS. I have a compiled image to put onto to the board from a series of three patches submitted July 2015 by Daniel Golle. See the links for reference:


I have soldered up a USB TTL serial adapter and have console. U-Boot is readily accessible from the terminal and I can also get the board to transfer the compiled image over TFTP. However I am trying to figure out how to get U-Boot to successfully boot the image and properly modify the setenv. Any ideas?

Given the boot logs it has been done before and I am trying to put together a complete guide on how to do it.


Hi customdev, I've sent my own patches to support this device.

The OpenWrt firmware can be installed in the NAND flash. No need to use external hard drives.

New wiki link: https://openwrt.org/toh/buffalo/ls421de

Edit: Patch accepted, this device is now officially supported:

1 Like

This is wonderful news and thanks for submitting the patches. I should log into the OpenWRT forums more often. It's been over two years but it is good to see this little device supported. Now to find a couple of 4TB drives and put it back together.

Here's to hoping the cat has not killed the power supply cord... (Om nom nom chew.) :roll_eyes:

Any modification about setenv to do after openwrt install ?
I have no TTL console and made a full from linux installation of my LS421DE...
all is OK except that I need to remove the disk at power up for boot in nand OpenWRT :frowning:

The Uboot env is read only in this device. Therefore you can't use a hard drive with the stock OS installed because it will allways boot from this media. The best option is to keep apart this hard drive (useful if you want back to stock firmware), and insert a new formatted one. Or you can also format the stock hard drive if you have no intentions to back to stock firmware.

It might also be possible to use a modded U-boot to skip the stock command line and boot from NAND even if a hard drive with the stock firmware is present. But this isn't straightforward.


My problem is that a formatted disk, without any data, block also the boot from nand !

I never had this problem. Is it a hard drive without partitions?

Well I don't remember if I made tests with different filesystem formats. I almost always used a hard drive with a XFS partition in my tests. Probably I also used ext4.

It’s a 4Tb hard drive with gpt partition map formatted in ext4

Resolved, by formatting the partition with xfs, the NAS boot up now correctly.
I suppose that the ext4 partition is discovered by uboot and break bootup of OpenWrt from NAND !

1 Like

Thanks for reporting. I'll add the tip to the wiki.

XFS is used for data and ext4 for the stock OS, maybe it hangs while looking for the stock OS files. BTW I'll make more tests to see if we can solve this problem adding a dummy partition or another trick.


1 Like

I made some tests to circumvent this issue:

  1. Working ok:

    • GPT table
    • first partition with EXT3 format with minimum size (8MB) for being just a dummy partition
    • second partition with EXT4 format (all remaining space).
  2. Working ok:

    • GPT table.
    • first partition with swap format (1GB) for being virtual memory.
    • second partition with EXT4 format (all remaining space).
  3. Not working:

    • GPT table.
    • Only one partition for the whole hard drive with EXT4 filesystem.

Therefore the first partition must be never formated with EXT4 filesystem or it will hang forever looking for initrd:

BootROM 1.08
Booting from SPI flash
DDR3 Training Sequence - Ver 2.3.5 
DDR3 Training Sequence - Ended Successfully 
BootROM: Image checksum verification PASSED

==== Welcome to YANAGI ==

 ** LOADER **

U-Boot 2009.08 ( 8<0xe6><0x9c><0x88> 28 2013 - 21:36:20)Marvell version: 1.1.3 NQ
U-Boot Addressing:
       Code:		00600000:006AFFF0
       BSS:		006F8360
       Stack:		0x5fff70
       PageTable:	0x8e0000
       Heap address:	0x900000:0xe00000
Board: Buffalo LS-M 88f6710
SoC:   MV6710 A1
CPU:   Marvell PJ4B v7 UP (Rev 1) LE
       CPU @ 1200Mhz, L2 @ 600Mhz
       DDR @ 600Mhz, TClock @ 200Mhz
       DDR 16Bit Width, FastPath Memory Access
PEX 0: Root Complex Interface, Detected Link X1
PEX 1: Detected No Link.
DRAM:  512 MB
       CS 0: base 0x00000000 size 512 MB
       Addresses 14M - 0M are saved for the U-Boot usage.
SF: Detected MX25L8006E with page size 256, total 1048576 bytes
NAND:  512 MiB
u-boot envinit tval=e4a9c09d
FPU not initialized
USB 0: Host Mode
USB 1: Host Mode
Shutting down unused interfaces:
Modules/Interfaces Detected:
       RGMII0 Phy
       RGMII1 Phy
       PEX0 (Lane 0)
       PEX1 (Lane 1)
       SATA0 (Lane 2)
       SATA1 (Lane 3)
HDD0 Power ON

Marvell Serial ATA Adapter
Integrated Sata device found
  Device 0 @ 0 0:
Model: ST3120026AS                              Firm: 8.05     Ser#: 3JT3S88N            
            Type: Hard Disk
            Supports 48-bit addressing
            Capacity: 114439.8 MB = 111.7 GB (234372887 x 512)

MAC Address : 10:6F:3F:CD:17:00
MAC Address read from block device 0 : 
Loading file "/initrd.buffalo" from ide device 0:1 (gpt1)


1 Like

Thanks for the tips !
Must be added to the wiki ... :wink:

I'm testing crypto improvements with the Marvel CESA engine. I installed the cryptodev driver with openssl.

However I'm having some troubles with the digest algorithms, they return a wrong checksum from any file. I'm not sure if my hardware has some issue, might be related with the L2 cache.

@erdoukki could you test if it works ok in your Linkstation?. These are the steps:

  1. Install the openssl util
    opkg update
    opkg install openssl-util

  2. Create a file big enough in tmp (or on an external hard drive), and make the checksum:
    cd /tmp
    dd if=/dev/urandom of=test.bin bs=1M count=128
    openssl sha1 test.bin

  3. Install the cryptodev driver and its libopenssl library:
    opkg install kmod-cryptodev
    opkg install libopenssl-devcrypto

  4. Enable the crypto device: edit /etc/ssl/openssl.cnf and uncoment devcrytpo under the [engines] section:

  5. Under the [devcrypto] section add the DIGESTS = ALL line:

  6. Save the file and make again the test:
    openssl sha1 test.bin

Did the checksums match?


no !

Here the results :

root@LS421DE:~#  cd /tmp
root@LS421DE:/tmp# dd if=/dev/urandom of=test.bin bs=1M count=128
128+0 records in
128+0 records out
root@LS421DE:/tmp# openssl sha1 test.bin
SHA1(test.bin)= 3f73b9d0b3ad5de19ef5c09ab6abdaef7769ca4a
root@LS421DE:/tmp# nano /etc/ssl/openssl.cnf 
root@LS421DE:/tmp# openssl sha1 test.bin
SHA1(test.bin)= 9f5ae6436b01adbaa01011103786bd2e563f923e
root@LS421DE:/tmp# uname -ar
Linux LS421DE 5.4.109 #0 SMP Fri Apr 2 14:45:28 2021 armv7l GNU/Linux
root@LS421DE:/tmp# cat /etc/openwrt_release 
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r16383-ec6293febc'

Thanks for testing!. Then I'm afraid the crypto driver is broken.

We know the idle driver is also broken, it might be related since it uses part of the crypto sram.

It's been a while and I am impressed with the progress. Cat killed the LS421DE before I could get OpenWRT on it.

However I now have something new that has the same hardware... perhaps two somethings.

One is a TeraStation TS1400D and the other is a TeraStation 1200D. Both variants are based on the same hardware as the LS421DE.

I will see what I can get into with them shortly.

There is now a section for CESA at https://openwrt.org/toh/buffalo/ls421de

Does anyone know if it is working now?

Yes, it works.

However the kernel patch for fixing this issue in Openwrt isn't still upstreamed. It means future versions of Openwrt might contain this bug again.

Could you please share the kernel patch for fixing this issue please? I would like to make my own build as I would like to use the CESA feature. Many thanks!

The patch is already in the OpenWrt sourcecode: