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
excellent! I don't beleive there will be any bad effects from getting interrupted at that point, the only other tasks after that are specific to the ts3000 and ls441. Either way I'll try to get a fix out in the next day or so.by 1000001101000 - Debian
Good to hear from you! That file gets generated automatically but only if needed, it shouldn’t be triggering an error for that device. I must have made a mistake when I updated that script. I’m confused how I missed that in my testing but it should be an easy fix. What version of debian are you trying to install?by 1000001101000 - Debian
admittedly that would probably only work if you're running debian stretch you can grab the source from: http://deb.debian.org/debian/pool/main/l/linux/linux_4.9.144.orig.tar.xzby 1000001101000 - Debian
I took another stab at the dts based on what we can see from that console output. I made sure it compiles but am not sure whether it would actually work. I'd recommend building the same dtb you've been using first to verify your able to successfully build/package them before trying mine. /dts-v1/; #include "kirkwood.dtsi" #include "kirkwood-6281.dtsi"by 1000001101000 - Debian
excellent. Looks like I was wrong about sata being pcie, that’s good to know. Also good info about the rtc/nand/etc all of which will help when we get that far.by 1000001101000 - Debian
I took a stab at a first dts specific to this device, it's based on the NS2 dts but with some changes: removed anything that showed as failing in your initial boot removed anything specific to lacie or the NS2 removed the dependency on kirkwood-ns2-common.dtsi adjusted the ram to the correct size enabled pcie which will hopefully allow sata to be detected I confirmed it will build wby 1000001101000 - Debian
actually I think you'll need to grab the needed include files out of the kernel source too: kirkwood-6281.dtsi kirkwood-ns2-common.dtsi kirkwood.dtsi I think moving forward you'll want to try to eliminate kirkwood-ns2-common.dtsi as a dependency but I'd suggest verifying you can successfully build a DTB before moving forward with actually editing one.by 1000001101000 - Debian
Here is the basic process for getting started modifying the device tree (example shows just building the one you've already tested). #install the needed tools and source (for the dts file) apt-get install device-tree-compiler linux-source-4.9 u-boot-tools #grab the installer initrd (it's already packaged and ready for use) wget "http://ftp.nl.debian.org/debian/dists/stretchby 1000001101000 - Debian
typically when I start modifying/testing a device tree I setup a full kernel crosscompile environment with some scripts to make executing the build and packaging the resulting dtb file with the kernel easier. I can help you set something like that up for your testing but I suspect there is an easier way. I'm curious to compare notes with @bohdi who seems to do this more than I do.by 1000001101000 - Debian
nice, that's a good starting point. getting it to boot is half the battle and you've already managed that. it looks like it didn't find your hard drive(s) but we were expecting that. you can confirm this by trying to run through the installer, i'm guessing it will say it can't find any disks. hopefully you can find it on the network, you should be able to connect oby 1000001101000 - Debian
Looks good. Now add the initrd and you should be in businessby 1000001101000 - Debian
My bad, I think I directed you at something that doesn't exist for that one. looking at the dts files in the mainline kernel I see the following options: kirkwood-blackarmor-nas220.dts kirkwood-laplug.dts kirkwood-ns2lite.dts kirkwood-ns2mini.dts kirkwood-pogoplug-series-4.dts kirkwood-rd88f6192.dts you could try the lacie ns2 files as a start: https://d-i.debian.org/daily-imaby 1000001101000 - Debian
i'd recommend doing it from a hard drive to start, we know it will boot from that. @bohdi might have some advice for getting it to work if you want to pursue that route. also it looks like this has a different SoC than the N4B1 did, rather than trying the kurobox image you'd want to try the ls-xl installer image instead to start.by 1000001101000 - Debian
it's been a while since I worked on this one, sadly I didn't keep the greatest notes. You shouldn't have to replace uboot to get this working. as I recall the serial console feels pretty laggy which is fine. I'd recommend starting by trying to boot into that debian installer I linked to earlier. The main advantage being that if sata doesn't work right away you'llby 1000001101000 - Debian
I had an N4B1 that I did a lot of work with ~ 2010 - 2014 and know quite a bit about that device, I suspect the N2B1 is basically the same. if that's the case it should have a pretty easily accessible serial header on the board. I was able to boot the device using the device-tree for the "kurobox pro" which got network and some other things working. I believe if you enable pcieby 1000001101000 - Debian
Yeah, usually by the time I can narrow down the issue to the specific patch/commit that caused the problem I find that some has reported it. By then you usually understand the problem well enough to search for it effectively.by 1000001101000 - Debian
QuoteSo you have the same problem as mine - it looks, that the newer kernel isn't perfect. Nobody noticed that besides us yet? I couldn't find noone with this problem in the whole google. Weird... 4.20.x is right at the bleeding edge, it hasn't worked its way into much yet. Even debian testing only moved to 4.19 about a month ago though I beleive there is a 4.20 experimental packby 1000001101000 - Debian
sounds like a good start. sometimes if you have hardware defined in the dtb that doesn't actually exist it will reserve the pins that you need which will keep you from changing them. I just had that with a device where the drive power pin was one of the i2c pins, the device I copied the original dts from was using i2c for the rtc but the device I was working with didn't use i2c at aby 1000001101000 - Debian
Typically what I do at this point is pull up the gpio binding documentation for the SoC and determine what range of GPIO pins are likely to be the power pins for the drives (ie not reserved for the ethernet controller/uart/etc) and loop through them with a script enabling each while watching dmesg for the drive being detected. Once I've identified all the pins I create the appropriate deviceby 1000001101000 - Debian
looks like progress, the drive is still accessible with SoC sata disabled. is this a typo? pcie@3,0 { /* Port 2, Lane 0 */ status = "okay"; }; pcie@3,0 { /* Port 3, Lane 0 */ status = "okay"; };by 1000001101000 - Debian
Quoteso this means one drive accessible through pcie and another accessible via soc sata I guess ? look like it. That matches what I've seen before, the soc sata taking priority over the pcie when both are enabled (only the one drive since the device-tree only enables one sata via soc). You should be able to remove the soc sata entry from the dtb so that pcie takes over for that one too:by 1000001101000 - Debian
I might not be the best person to ask when it comes to these devices. These logs might be disabled to reduce disk activity or something like that (I'm guessing if you can run apt-get install it's not a read only filesystem). If you have any logs in /var/log they may be a good place to start. there are a bunch of options you can pursue but someone with more experience troubleshootingby 1000001101000 - Debian