Buffalo LS421DE

customdev · February 2, 2018, 1:49am

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:

https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034393.html
https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034394.html
https://lists.openwrt.org/pipermail/openwrt-devel/2015-July/034395.html

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.

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

danitool · March 27, 2020, 10:46am

Hi customdev, I've sent my own patches to support this device.
http://patchwork.ozlabs.org/patch/1267406

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:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=85ef69b2029

customdev · May 29, 2020, 3:59pm

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.)

erdoukki · March 20, 2021, 10:37am

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

danitool · March 20, 2021, 2:51pm

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.

Regards

erdoukki · March 20, 2021, 2:52pm

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

danitool · March 20, 2021, 2:58pm

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.

erdoukki · March 20, 2021, 3:04pm

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

erdoukki · March 20, 2021, 3:15pm

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 !

danitool · March 20, 2021, 3:20pm

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.

Regards

danitool · March 26, 2021, 4:11pm

I made some tests to circumvent this issue:

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).
Working ok:
- GPT table.
- first partition with swap format (1GB) for being virtual memory.
- second partition with EXT4 format (all remaining space).
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
BUFFALO_BOOTVER=0.13
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:
       AUDIO
       TDM
Modules/Interfaces Detected:
       SDIO
       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)

Regards

erdoukki · March 26, 2021, 4:58pm

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

danitool · April 2, 2021, 7:47pm

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:

Install the openssl util
opkg update
opkg install openssl-util
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
Install the cryptodev driver and its libopenssl library:
opkg install kmod-cryptodev
opkg install libopenssl-devcrypto
Enable the crypto device: edit /etc/ssl/openssl.cnf and uncoment devcrytpo under the [engines] section:
[engines]
devcrypto=devcrypto
Under the [devcrypto] section add the DIGESTS = ALL line:
[devcrypto]
DIGESTS = ALL
Save the file and make again the test:
openssl sha1 test.bin

Did the checksums match?

erdoukki · April 3, 2021, 7:05am

done...

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_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r16383-ec6293febc'
DISTRIB_TARGET='mvebu/cortexa9'
DISTRIB_ARCH='arm_cortex-a9_vfpv3-d16'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r16383-ec6293febc'
DISTRIB_TAINTS=''

danitool · April 3, 2021, 8:57am

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.

customdev · August 27, 2021, 2:50am

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.

ckchan · March 21, 2022, 4:49pm

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

Does anyone know if it is working now?

danitool · March 21, 2022, 9:06pm

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.

ckchan · March 22, 2022, 1:15am

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!

danitool · March 22, 2022, 9:06am

The patch is already in the OpenWrt sourcecode:

github.com

openwrt/openwrt/blob/openwrt-22.03/target/linux/mvebu/patches-5.10/316-armada-370-dts-fix-crypto-engine.patch

--- a/arch/arm/boot/dts/armada-370.dtsi
+++ b/arch/arm/boot/dts/armada-370.dtsi
@@ -234,7 +234,7 @@
 				clocks = <&gateclk 23>;
 				clock-names = "cesa0";
 				marvell,crypto-srams = <&crypto_sram>;
-				marvell,crypto-sram-size = <0x7e0>;
+				marvell,crypto-sram-size = <0x800>;
 			};
 		};
 
@@ -255,12 +255,17 @@
 			 * cpuidle workaround.
 			 */
 			idle-sram@0 {
+				status = "disabled";
 				reg = <0x0 0x20>;
 			};
 		};
 	};

This file has been truncated. show original