Those config options are all the same on the stretch kernel. I assume @tsunulukai was running a different kernel (maybe one of yours?) last time they were able to make changes. In any case, removing that read-only; attribute in the dts and making a new dtb should get it working again.by 1000001101000 - uBoot
I think ignoring the cmdline partition info is normal for the vanilla Debian kernel: ~# cd /boot /boot# grep -i parts config-4.19.0-5-armmp # CONFIG_MTD_REDBOOT_PARTS is not set # CONFIG_MTD_CMDLINE_PARTS is not set # CONFIG_MTD_AFS_PARTS is not set CONFIG_MTD_OF_PARTS=m CONFIG_MTD_AR7_PARTS=m Wouldn’t that cause it to use the partitions defined in the dtb? The armada 370/xpby 1000001101000 - uBoot
Looks like the mainline dtb marks it as read-only. https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/kirkwood-goflexnet.dts partition@0 { label = "u-boot"; reg = <0x0000000 0x100000>; read-only; }; Looks like it has for a long time, but if you changed to the dtb distributed by debian recently it might explain it.by 1000001101000 - uBoot
@oxygen8 I'm working on creating a script to automatically adjust the fan speed on devices that use the microcontroller to control the fan, I think you said you were putting something similar together for the other devices. If so, what logic are you using to map drive temperature to fan speeds?by 1000001101000 - Debian
Can you be more specific about what you want to accomplish? Most distros use "hybrid" images for there installation media these days which can be directly written to a usb drive via dd.I use grub-mkrescue to generate usb-bootable disk images for a custom Debian Installer I maintain. There are many other ways to create bootable media but it depends greatly on what you are trying tby 1000001101000 - Off-Topic
Was finally able to confirm that trying to scan this i2c bus locks something up if you try to scan it and it stays that way across resets until you physically disconnect power. It works fine if you just use the rtc without trying to scan via i2cdetect or sensors-detect. I confirmed this happens with the i2c-mv64xxxx driver and using the i2c-gpio “bitbang” driver. I’m still narrowing dby 1000001101000 - Debian
I’m 99% sure that I got to detect the chip once a few days ago when I was troubleshooting a UART issue. I didn’t pay much attention since I thought fixing the UART pins resolved some kind of conflict. I wonder if stumbled across some sort of power/chip select pin without realizing it... or imagined it. I think i’ll work it from that angle for a while. I didn’t find any meaningful diffeby 1000001101000 - Debian
Howdy, I'm trying to get the rtc working on an armada-370 device but am having trouble getting the i2c bus to work. I can tell from the dmesg output from the stock firmware that the rrtc works and is connected via i2c. In fact I've had no trouble with some very similar devices (with the same stock dmesg output) but haven't had luck with this one but am encountering this on mulby 1000001101000 - Debian
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