How to supersede DTB with custom one?

[lis6502]

It's a know flaw that ttyS0 on TS3400D is read-only. The UART's RX line isn't routed to CPU, effectively disabling inbound communication. Serial communication is needed for me to mess with bonding without a risk of loosing newtork link and need to reboot. Also i wanted to dig a bit more on living official firmware, as i've found that OFW's SATA speeds as well as crypto efficency is at least 2x higher. Same goes for USB3 attached disks so i have to investigate this deeper.

I've found a tutorial for Terastation on how to move some jumper R0's form there to here, however it must be relevant to other model as i didn't found described chips at mine and hackery without schematics is as easy as heart surgery wearing boxing gloves ;)

I've took another approach: TS3400D has second UART, ment for UPS. Using some minicom magic i've been successful enough to estabilsh bidirectional data transmission using PL2303 usbserial at laptop's end. So i do have candidate to do some more hackery. yay.

Problem at the moment is that u-boot's serial line is hardcoded as ttyS0 in u-boot-env file/partition, located at /dev/mtd1. I was successful to dump mtd1's contents and mess with bits and bytes using hexeditor. Now i wanted to ultimately flash new env and give it a try. But i am unable to, as every MTD is read-only.

i've found read-only definitions in actual DTS file, so i've recompiled it and wanted to apply "somehow" to final uImage.buffalo, but i got stuck at this point where i can extract bare kernel from "u-boot legacy image", but no step further. I thought that if file is embedded to kernel every time the later one is being built, i've gave a try to utilize tools/kernel_scripts, however i still don't know wherther built from source 4.19 will boot due to broken whatever, also process of making bzImage to uImage readable by uboot is a mystery to me. inb4: buy/ make an SPI programmer ;p

[1000001101000]

I’m glad to see someone interested in digging into the performance on these devices. It’s been on my todo list for a long time.

Installing a new DTB is actually pretty easy for this setup. Just put the new file in /etc/flash-kernel/dtbs then run flash-kernel. It will then take the new dtb, append it to the kernel and generate a new uImage.

Let me know if you need anything else to start your testing!

[lis6502]

So far so good

root@bawul:~# for i in {0..2};do mtdinfo /dev/mtd${i}|grep ^Device;done
Device is writable:             true
Device is writable:             true
Device is writable:             true

I'll attach modified DTS file for future referrence

armada.zip

in order to compile this file into proper DTB, issue dtc -I dts -O dtb armada.dts > armada-xp-terastation-ts3400r.dtb

[lis6502]

Well, it painfully sucks. Although i am able to use flashcp now as below

root@bawul:~# flashcp -v mtd1 /dev/mtd1
Erasing blocks: 1/1 (100%)
Writing data: 64k/64k (100%)
Verifying data: 64k/64k (100%)
root@bawul:~# grep S2 /dev/mtd1
Binary file /dev/mtd1 matches

bootloader does some nasty stuff while booting, i yet don't know why. Notice writitng to spi flash line in attached minicom's capture I am grepping for S2 as only console=console=ttyS2 in modified mtd1 batch should match, and it does.

cap.zip

ffs, this thing definetely does not want to be bothered during bootup, i can tell ya that :/ At the moment i am out of ideas

[lis6502]

Update: i am an fucking idiot xD

root@bawul:~# dpkg-query -L u-boot-tools
/.
/usr
/usr/bin
/usr/bin/dumpimage
/usr/bin/fw_printenv
/usr/bin/kwboot
/usr/bin/mkenvimage
/usr/bin/mkimage
/usr/bin/mksunxiboot

notice printenv and mkenvimage. So going to check and will report shortly

[lis6502]

Yup, bi-directional console is working now

Debian GNU/Linux 10 bawul ttyS2

bawul login: root
[   21.822881] mvneta d0070000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
[   21.830778] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Password: 
Last login: Sun Jan 17 18:06:52 CET 2021 from 172.16.32.18 on pts/0
Linux bawul 4.19.0-13-armmp-lpae #1 SMP Debian 4.19.160-2 (2020-11-28) armv7l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
croot@bawul:~# cat /proc/cmdline 
console=ttyS2,115200 panic=5 mtdparts=armada-nand:-(nandubifs) ubi.mtd=1 BOOTVER=0.18 UBOOT_DATE=2015/08/17 earlyprintk
root@bawul:~# 

DO NOT USE FW_PRINTENV TO DUMP UBOOT CONFIG, it's not complete dump and afterwards nand boot does not work

tl;dr:

fw_printenv > environment
vi environment
(do neccessary modifications)
mkenvimage -p 0 -s 65536 -o this_will_be_my_new_mtd1 environment
flashcp -v  this_will_be_my_new_mtd1 /dev/mtd1
reboot

[1000001101000]

Why do you want to modify the flash?

I can provide some advice on that too but don’t understand what that has to do with the performance stuff.

be careful, messing with the bootloader could make the device in-bootible ... thats why I marked it read-only in the dtb

[lis6502]

Why do you want to modify the flash?

i've made them both writeble as at the begining i was convinced that i've opened wrong flash partition. My goal was to reach u-boot-env partition and it was successful. Now i can boot to OFW and (hopefully) see getty at ttyS2 :) This whole mess is needed as i am unable to login over SSH to OFW, and trials and errors with PAM require me to constantly shuffling with disk, between USB-to-SATA adapter and Terastation. I hope that PAM won't kick me out once i login as root on ttyS2 and ultimately i'll be able to check what differs vanilla Debian from OFW and name source of performance issues.

be careful, messing with the bootloader could make the device in-bootible

yes, i am fully aware of what i am doing. That's why i am trying to modify as less as possible and am not touching u-boot partition itself.

[1000001101000]

Sounds like you’ve got things under control.

you might have an easier time with telnet on the stock firmware. Sounds like you have a plan already either way.

Let me know what you figure out!

[lis6502]

I wasn't able to spawn telnet binary, this javish ACP commander-something didn't worked either. My only chance is to hack somehow over /etc/shadow (prefferably by copying admin's pass to root's). At this moment i am recovering stock firmware out of NAND.

IMPORTANT

fw_printenv does NOT dump all key=value pairs from uboot-env-mtd. I'll post details later

[lis6502]

first smal success:

BUFFALO INC. BuffaloNas series 
UNINSPECT556 login: 
admin
Password: 
[admin@UNINSPECT556 ~]$ uname -a
Linux UNINSPECT556 3.3.4 #1 SMP Thu Aug 6 16:46:44 JST 2020 armv7l Marvell - PJ4Bv7 Processor rev 2 (v7l) Marvell Armada XP Developmentx
[admin@UNINSPECT556 ~]$ date
Sun Jan 17 19:56:13 GMT 2021
[admin@UNINSPECT556 ~]$ 

so getty (after modifying inittab) is happy on ttyS2 :) Unfortunately, my messing with mtd1 partition probably discarded my original serial number as well as unit name as it identifies now as Uninspect556.

Now, thanks to having Debian on USBs (one vfat with /boot contents, other one with swap and rootfs) boot selecting is as easy as flipping USB<>HDD switch on the back of the case :) Also, forcing console on ttyS2 redirected whole diagnostic messages to the other serial port while booting from nand and recovering.

Now, when i achieved what i was after i am wondering where to look at, hmmm;p

[lis6502]

Oh, one more thing

U-BOOT IMPORTANT INFO GOES HERE

consider following

sdiff -s ubootenv ubootenv_generated_by_printenv_yet_not_working 
DEVICEID=_tysgkFFSEaoWr30qXm6hMPSK1rE0Hak                     <
SerialNo=80068135100589                                       <
bootcommon2=setenv bootargs $console $mtdparts $opt_arg $buff <
bootorder=ide tftp                                            | bootorder=ide nand tftp 
eth1addr=10:6F:3F:CE:25:57                                    | eth1addr=00:50:43:fe:d4:78
eth2addr=00:50:43:fe:ed:83                                    | eth2addr=00:50:43:fe:c5:78
ethact=egiga0                                                 | ethaddr=00:50:43:c5:d4:78
ethaddr=10:6F:3F:CE:25:56                                     <
mv_pon_addr=00:50:43:83:ed:fe                                 | mv_pon_addr=00:50:43:78:c5:fe
pcieTune=no                                                   <
tftpbootcmd2=tftp 0x1200000 $kernel; tftp 0x2600000 $initrd;  | uboot_date=UBOOT_DATE="2015/08/17_hacked_by_lis6502"
uboot_date=UBOOT_DATE="2015/08/17"                            <
usb0bootcmd=dispboot usb; setenv usbActive 0;usb reset; fatlo <
usb1bootcmd=setenv usbActive 1;usb reset; fatload usb 0 0x120 <
usb2bootcmd=setenv usbActive 2;usb reset; fatload usb 0 0x120 <
EnableNandBoot=1                                              <

Due to unknown reason, fw_printenv does not dump all variables being set. Therefore keeping backup of unmodified mtd1 partition is crucial. Also at the very env of 64kb image file there are some Terastation strings, identifiers of some kind, image generated by mkenvimage does not have them. I've worked this out by tr '\0' '\n' < original_mtd1_image and manually copied and pasted content into fresh environment file, which i later used to prepare new image. Also note bootorder's lack of nand keyword. I think it's something that one should be aware of messing on such low level.

[lis6502]

keywords for google, some1 will thank me some day ;d

sftp ssh buffalo nas /etc/sftponly_config input_userauth_request: invalid user root [preauth]

only mechanism which prevents ssh logins to TS3400d is (probably custom) /etc/sftponly_config This file serves at least as a "source of authorized users to login remotely" - thus only guest/admin is able to ssh while even freshly created myremoteuser is not.

SOLUTION

is to append to file

user root                      
allowssh no                    
hidelist /                     
defaultdir "/mnt"
chrootdir "/mnt"
showlist "/mnt"  
rolist "/mnt"    

it must have been some custom patch made by Buffalo as i didn't found any referrences to it in openssh sources

[1000001101000]

If you want to distill any of these into guides we can add them to the wiki: https://buffalonas.miraheze.org/wiki/Main_Page

I'm more interested to find out what you figure out about performance issues now that you've got your test environment together.

good luck!

[lis6502]

Sorry for my verboseness :P. I've just felt that i need to document my progress somewhere or it'll be lost. Anyway - don't have too much hope. Example with custom ssh binary (one calling /etc/sftponly_config) leads me to thinking that kernel modules responsible for sata/crypto or even cpu performance can be manually tuned by Buffalo's engineers and my skills wouldn't be much help here. keep fingers crossed for me to be mistaken, yet it isn't my first commercial product which i am trying squeeze as much as i can of and every finding only prooves how much modification has been made to GPLd code in order to make it work decently.

As for the wiki- sure i can yet i would need some guidance to wrap my head around editing wiki (haven't done this ever).

[1000001101000]

On the brightside buffalo is pretty good about posting their source .... except uboot and some of the kernels.

there maybe some gains to be had with kernel config options. Disabling spectr/meltdown protection would increase some types of performance, for example.

If you discover they custom compiled their samba/etc to take advantage of hardware crypto we can look into creating our own custom version with similar build options.

I originally didn’t want to host anything like that but I’ve been hosting a custom kernel for the terastation 2/3 for a while now without problems.

there are probably some easier wins out there to be found by optimizing smb.conf and things like that.