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
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
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
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
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
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
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
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
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
right on, I'll give it a try and see if I can get it to work.by 1000001101000 - Debian
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
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
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
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
When I get home i’ll look at mine and see what else you can check.by 1000001101000 - Debian
That looks right. Do you get any dmesg output if you plug something into it?by 1000001101000 - Debian
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
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
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
Yeah, the device trees are located in: Stretch/device-trees/ Buster/device-trees/ etcby 1000001101000 - Debian
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
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
Do you know if there are bindings for those devices or an example device tree I’m unaware of?by 1000001101000 - Debian
My bad. Specifically the mv781xxby 1000001101000 - Debian
Digging into this device is on my extended todo list (funny how the list keeps getting longer faster than it gets worked on) There is code in the mainline kernel for this series of devices(specifically the 2 bay model I think). see here: https://github.com/torvalds/linux/blob/master/arch/arm/mach-mv78xx0/buffalo-wxl-setup.c Quotebodhi But for this box, it is ARMv5 so I think you can boot wby 1000001101000 - Debian
Ah, good. You had me very confused.by 1000001101000 - Debian
The installer is just the debian netboot installer with a few scripts added to: -retrieve the mac address from the uboot parameters and set it in the interfaces file -install flash-kernel and copy over all the files to make it work (device trees and the db file) -configure update-initramfs to work with the kernel params passed by stock uboot -a script to ensure the ls441de reboots rather thaby 1000001101000 - Debian
anytime! let me know if you run across anything I should add to the installer/instructions.by 1000001101000 - Debian
looks like fancontrol reserves access to the pwm once you enable it. Just stopping fancontrol doesn't seem to release it but when I removed fancontrol and reboot I'm able to access it manually. if you're planning to control it manually/by a custom script you'll probably want to remove fancontrol anyway.by 1000001101000 - Debian
I got the same error on my ts1200d, i'm still not clear why I didn't get it when I did my original testing.... oh well I posted a new version that corrects the issueby 1000001101000 - Debian