Show all posts by user
Discuss all things Debian on your device
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
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
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
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
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
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
Re: armada370 serial port that can send but not receive - 6 years ago
Yeah, I think so. Looking at the ts3400 its showing the same thing (but that one works as expected)by 1000001101000 - Debian
Re: armada370 serial port that can send but not receive - 6 years ago
interesting, and confusing. All I'm doing in the dts is enabling them: serial@12000 { status = "okay"; }; serial@12100 { status = "okay"; };by 1000001101000 - Debian
Re: armada370 serial port that can send but not receive - 6 years ago
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
Re: armada370 serial port that can send but not receive - 6 years ago
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
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
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
Re: armada370 serial port that can send but not receive - 6 years ago
in this case the console/etc are all on uart0, as far as I've been able to tell uart1 doesn't have anything like that assigned. as far as i can tell. Even if it was I would still find this odd, at least if it were stdout/stderr since those are all "output" and output is what is succeeding for me. I've been half wondering if something else could be grabbing the rxby 1000001101000 - Debian
armada370 serial port that can send but not receive - 6 years ago
I'm working with a device (Buffalo Terastation TS1400D) that uses one of the SoC uart connections (uart1) to communicate with an on-board microcontroller which control some of the devices peripherals (fan speed, leds, buzzer etc). I'm able to send commands to it (and can see/hear that it's executing the) but I am not getting any of the acknowledgement messages back. When doing theby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
i think you're probably right though I still desire a "don't mess with uboot" solution if possible. I'm wondering if I can configure the kernel to not mess with that area of memory. I finally found the config for buffalo's kernel (the whole kernel source actually) and am looking in the differences. I'm wondering if i need to cahnge something like this:by 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
here is what my dmesg output looks like [66517.863078] usb 1-2: new high-speed USB device number 2 using xhci_hcd [66518.013465] usb 1-2: New USB device found, idVendor=0930, idProduct=6544 [66518.020242] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [66518.027447] usb 1-2: Product: USB Flash Memory [66518.031931] usb 1-2: Manufacturer: [66518.036151] usb 1-2:by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
i'm still scratching my head with the initrd issue. I don't think it's getting truncated and I think I have the relavant kernel settings enabled. I'll else need to figure out what's going on with the pci/sata before I get much further.by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
I made two changes to the kernel source and tried again. One was to fix the rtc (which worked) one was to try to fix pci/sata (which did not). I'm still having trouble with my initrd but have only begun to look into it. CPU = MV78 Checking DATA BUS OK! Checking ADDRESS BUS OK! Checking DATA BUS Checking ADDRESS BUS BUFFALO U-BOOT Start !!! ** LOADER ** ** BUFFALO BOARDby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
The uImage was ~2.5M. I'm guessing the old 2M limit didn't apply to this version of uBoot since i didn't get an error. It only output like 20 modules, which probably explains the largish kernel. I'll post the whole output when I get a chance, there are a couple of interesting things that come up that I'm wondering if you've seen elsewhere. It looks like that deby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
I think you're right about that. the mv78xx0_defconfig worked relatively well, at least it recognized the mach_type etc. Uncompressing Linux... done, booting the kernel. Booting Linux on physical CPU 0x0 Linux version 4.9.144 (jeremy@earth) (gcc version 7.3.1 20180425 revision 0 (ARMv5TE), cr=0005397f CPU: VIVT data cache, VIVT instruction cache Machine: Buffalo Nas WXL Ignorinby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
I compiled a kernel with the debian-stretch marvell kernel config as a base with those two options added but got the same result. I think I’ll try again with the mv78xx0_defconfig tomorrow.by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
right on, I'll give it a try and see if I can get it to work.by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
Looks like I need to add these options: CONFIG_ARCH_MV78XX0=y CONFIG_MACH_TERASTATION_WXL=y Any chance one of your kernels already has them?by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
Got this trying the stretch kernel (4.9.0-8-marvell) Uncompressing Linux... done, booting the kernel. Error: unrecognized/unsupported machine ID (r1 = 0x00000a89). Available machine support: ID (hex) NAME ffffffff Generic DT based system ffffffff Marvell Kirkwood (Flattened Device Tree) 0000054e Marvell Orion-2 Development Board 000005e4 Marvelby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
Fortunately for this model I do have a read-only serial console so I can see any messages that are output, i just can't interrupt the boot to make uboot changes. This is particularly fortunate for this model since it is much more picky about what partitions it will load boot files from (for reasons I have not yet explored). If necessary i can even change uboot parameters from userspace uby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
Interesting, That's good to know. Buffalo also has the unfortunate habit of not posting their u-boot source. I wouldn't mind but they do a whole bunch of interesting things in u-boot. My new favorite is that they trigger a watchdog timer in a separate microcontroller before booting the kernel and then rely on the firmware to turn it off if the system boots successfully. It took me anby 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
When I get home i’ll look at mine and see what else you can check.by 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
That looks right. Do you get any dmesg output if you plug something into it?by 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
It should work immediately once you've got Debian installed. I use mine quite a bit. Are you using Stretch on that one too? can you verify the output of "/proc/device-tree/model" (usb3 is only enabled in the ls421d device tree)by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
Yeah, I think it dates back to the first attempts to boot multiple devices from the same kernel rather than custom compile for every board... way before device trees were standardized. Still, this device requires removing an IC from the board and bridging the resulting gap to enable input from the serial port which makes that route unappealing to me in the short term. oddly enough it looks likby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
I found one of the references I had remembered. It looks like you can also stick it in front of the kernel in some configurations. devio > /tmp/foo 'wl 0xe3a01c07,4' 'wl 0xe3811027,4' cat foo /boot/vmlinuz-$ver > /tmp/zImage I don’t exactly get what that does and haven’t seen a reference to the technique just a couple examples. If I didn’t know better iâby 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 6 years ago
Yeah, the device trees are located in: Stretch/device-trees/ Buster/device-trees/ etcby 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
I’m just looking for the procedure for setting the mach_type so I can try booting it that way for now.by 1000001101000 - Debian
Re: Buffalo Terastation III TS-X4.0L/r5 (Sakura) From Stock 1.71(Buffalo Latest FW) ==>Debian Jessie/Stretch - 6 years ago
I beleive the code for the ts-wxl (the two bay version of this dev). Would probably work (assuming it still works). I’m pretty sure there is a mach number for it. Admittedly I haven’t looked at that process since the 2.6.35 days. Is there a resource with the commands you can point me at?by 1000001101000 - Debian