These devices are back from the days that Buffalo posted their modified u-boot/kernel source code too: https://opensource.buffalo.jp/ls-x-165.htmlby 1000001101000 - uBoot
The mainline device tree for the device lists mpp11 for usb powerby 1000001101000 - uBoot
I’ve done similar things with some of the newer linkstation/terastation devices with a built in usb boot option, it’s nice having all 4 drive bays available for running hdd diagnostics when booting from usb. One non-uboot solution for your use case would be to keep /boot on your hard drive and keep your rootfs on the usb. That would allow you spin the drive down as you describe since youby 1000001101000 - uBoot
I finally got back to looking at this and figured out what the problem is, The default UART1 pins for the armada-370 are 41(RX) and 42(TX), it turns out this device is using 57(RX) and 42(TX), I'll be posting updated device trees that reflect that shortly. I had previously suspected it was something like that but wasn't detecting activity on the other pins at the time. I guess the scby 1000001101000 - Debian
It's probably about as simple as changing it to this: mdio@72004 { phy0: ethernet-phy@0 { reg = <0>; }; phy1: ethernet-phy@1 { reg = <1>; }; }; For most device's it either "0" or "1" though it was "8" for some SoCs if I remember correctly. The stock device tree and/or trial and error can probably getby 1000001101000 - Debian
@oxygen8 I corrected the issues with my ls400 restart script (see attached). It now: properly handles shutdown/restart/halt for the ls410d/ls420d/ls421d/ls441d/ts1200d by simply putting the script in /lib/systemd/system-shutdown/ and setting it as executable by root. It no longer introduces any long delays and should work reliably with most network/system configurations. I'll be adby 1000001101000 - Debian
if you really want to avoid a separate /boot partition you could probably setup your rootfs on the first partition and then symlink uImage.buffalo and initrd.buffalo to /. the relevant uboot command is usually something similar to "ext2load ide 0:1 0x1200000 /uImage.buffalo" which only cares that the expected file is in the root of the first partition. I mean, you could also alter thby 1000001101000 - uBoot
Some notes: Debian does have an installer updated for Buster RC1 which would get you a more modern kernel: http://ftp.debian.org/debian/dists/testing/main/installer-armel/current/images/kirkwood/network-console/buffalo/ By the time Buffalo started using Kirkwood SoCs they also began disconnecting the serial headers on most of their devices. There are some old instructions for enabling it (by 1000001101000 - uBoot
I use python’s pySerial module to send commands to an on-board microcontroller similar to the one on your device. I’ve found that it’s a bit more reliable than echoing bytes to the device, it also makes it pretty easy to handle the response bytes that come back. I’ve got that code published here if you’re interested: https://github.com/1000001101000/Python_buffalo_libmicon The tby 1000001101000 - Debian
I recently had some success measuring fan speeds on a similar device by marking one of the fan blades with a crayon and using "slo-mo" mode on my iphone to record a few seconds of the fan spinning at various speed settings. It's fairly easy to take that video and count the frames it takes the marked blade to complete a revolution and use that to calculate the RPMs. I'm sureby 1000001101000 - Debian
Have you tried the brute force approach? Usually at this point I pull up “dmesg -w” in one window and then run a script that sequentially activates each unassigned gpio pin in another. I can usually find the sata pwr pins based on when the dmesg output shows the drive being recognized.by 1000001101000 - Debian
changing the bootcmd variable didn't have any affect. Looking at it again it seems it's not the actual command being executed, for one thing it hardcodes which drive loads the boot files from which doesn't match the device's behavior. I don't know if that means the boot sequence is hardcoded in that source code buffalo didn't publish or what. for reference hby 1000001101000 - Debian
I read the whole thread and have some thoughts. I don't do much with windows so I could be missing some of it. at one point you notice the difference between the output of df -h and the expected sizes (MB vs MiB). Modern versions of df have a "-H" (uppercase) which may give you what you want. you mentioned at another point showing 5% usage on an empty filesystem (i think). Thby 1000001101000 - Debian
yes. I haven't moved it in my testing so farby 1000001101000 - Debian
I think most of the delay is from how shutdown works by default. "shutdown now" instructs the system to immediately begin the shutdown. putting that script in place on my ls421de allowed "shutdown" and "reboot" to have the expected effects. I still have a fair amount of testing/tweaking before I add it to the repository. I figured if it worked for you it mightby 1000001101000 - Debian
nice. I've finally got the restart script adjusted so that it properly handles shutdowns and restarts for the ls400 models (note it no longer uses a systemd service). I'll be posting it to github but if you want to try it out here it is: #!/bin/bash # place in /lib/systemd/system-shutdown/ for debian based systems # other systems it's /usr/lib/systemd/system-shutdown/by 1000001101000 - Debian
are you saying that starting/stopping triggerhappy isn't working or that your triggers aren't working?by 1000001101000 - Debian
I don't know much about triggerhappy but the following seems to work: root@ls421de-stretch:~# /etc/init.d/triggerhappy stop [ ok ] Stopping triggerhappy (via systemctl): triggerhappy.service. root@ls421de-stretch:~# /etc/init.d/triggerhappy start [ ok ] Starting triggerhappy (via systemctl): triggerhappy.service. root@ls421de-stretch:~# /etc/init.d/triggerhappy restart [ ok ] Restaby 1000001101000 - Debian
oh, I may know what the problem was. If you set up my old script + systemd service it probably changed the value back to "restart" when you issued the shutdown command. if you remove the ls400_reboot script and then issue those commands the device will shutdown rather than restart. I'm working on a new version of the shutdown/restart script that sets these values appropriateby 1000001101000 - Debian
I ran it before posting and got a successful shutdown on my ls421de can you run the following and post the output? phytool write eth0/0/22 3 && phytool read eth0/0/16; phytool write eth0/0/22 0 phytool write eth0/0/22 3 && phytool write eth0/0/16 0x0881; phytool write eth0/0/22 0 phytool write eth0/0/22 3 && phytool read eth0/0/16; phytool write eth0/0/22 0by 1000001101000 - Debian
Nope. Depending on the model they either use a built in microcontroller for power management which they send commands to over a serial connection or use this clever ethernet controller hack. Actually, on the ls200 series they shutdown and restart normally without any of the above. None of them use the poweroff gpio as far as I can tell.by 1000001101000 - Debian
the issue is with the service rather than the commands, I probably misread the documentation when I created it. if you run the following the device will shutdown (I just did it with mine): phytool write eth0/0/22 3 && phytool write eth0/0/16 0x0881; phytool write eth0/0/22 0 shutdown now **note you need all 3 phytool commands on one line when running interactively. This is becausby 1000001101000 - Debian
For these devices Buffalo uses the unused 3rd LED output from the ethernet controller to signal to the boot loader whether it should shutdown or reboot when the system shuts down. I defaulted that line to signal restart by default in the DTB (it's the opposite for the ls441 because that line is also tied to the power button gpio). I included a script to set this value right before rebootby 1000001101000 - Debian
I’ve tested all the hardware I can think of on all the devices. The only thing not working out of the box with the vanilla debian kernel is the rtc, though that’s just because the driver isn’t included by default. I’ve included info on how to enable it if needed. For the ts1400 and the ts3000 models the lcd/fans/etc are controlled via the built-in microcontroller which requires a seperby 1000001101000 - Debian
Yeah, I think so. Looking at the ts3400 its showing the same thing (but that one works as expected)by 1000001101000 - Debian
interesting, and confusing. All I'm doing in the dts is enabling them: serial@12000 { status = "okay"; }; serial@12100 { status = "okay"; };by 1000001101000 - Debian
hmm, good thought. so, this is what I'm seeing: root@ts1400d-stretch:~# dmesg | grep serial [ 1.231269] d0012000.serial: ttyS0 at MMIO 0xd0012000 (irq = 19, base_baud = 12500000) is a 16550A [ 2.039621] d0012100.serial: ttyS1 at MMIO 0xd0012100 (irq = 20, base_baud = 12500000) is a 16550A root@ts1400d-stretch:~# find /proc/irq | grep serial /proc/irq/19/serial interesby 1000001101000 - Debian
I'm not explaining it well. I'm sending commands from the device to an external microcontroller via uart1 (it's on the pcb but is external from the os's perspective). if stdout was going out uart1 that output would also go "out" to the microcontroller. i can tell the commands I send out are being received and accepted because the microcontroller plays the expecby 1000001101000 - Debian
I think I'll purse that next. All my attempts at fixing the PCI issues have been failing so far but I'll be in a better position to troubleshoot that if I can get it to complete the boot process. for all i know it's working better than I think and just giving up too soon.by 1000001101000 - Debian