Show all posts by user
Discuss all things Debian on your device
Re: Debian on Synology RS816 (Armada 385) - 5 years ago
That's also probably why using the stock dtb is failing, the new kernel doesn't like that older style binding for pcie (and possibly others). looking again at @bohdi 's dts it looks like that's already covered, the pcie errors are probably from the extra entry he has in there, maybe. I'd guess the drives aren't showing up because they aren't being poweredby 1000001101000 - Debian
Re: Debian on Synology RS816 (Armada 385) - 5 years ago
more or less. most of that is covered in armada-385.dtsi which you are including at the top of your dts file, most likely all you need to do is override the status from "disabled" to "okay". It's probably something like: &pciec { pcie@2,0 { status = "okay"; }; };by 1000001101000 - Debian
Re: Debian on Synology RS816 (Armada 385) - 5 years ago
I had a virtually identical experience with the Linkstation 441de, Though it's a different SoC the same situation seems to apply. If I'm reading the right specs the armada-385 has 2x sata ports built in just like the armada-370, for the 4+ bay model buffalo uses a seperate sata chip connected via pcie, I'm guessing it's the same for this synology device. If so enabling pcie inby 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 5 years ago
The model I’m working with (TS3400D) helpfully has a serial port on the front which outputs the console, but they disconnect or otherwise inhibit the RX pin. Most other models don’t have any easily accessible UART header (or if they do it’s disconnected). One of these days I’ll put more effort into working around those issues but so far I’ve just lived without being able to directly accby 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 5 years ago
I forgot you're out of town, I can probably try builing against your source. I've got your patch and config, which version of the source are you currently using? The device I'm using doesn't permit input on the console ( I beleive I need to remove/bypass a diode to re-enable it). It'll be a while before I get a chance to try out that operation. I suppose I could make tby 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 5 years ago
fortunately these devices don't have that issue, in my previous testing I confirmed they can handle kernels up to 11mb (I only tested up to 6mb) and initrd > 75mb. I hooked up the serial console and tried again, unfortunately I didnt get anything past "Starting Kernel ...". most of the times I've had that problem have been an issue with the dtb I was testing, consideby 1000001101000 - Debian
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 5 years ago
Fortunately Debian has now moved to kernel 4.19 which includes all the fixes required to boot armada-370 devices again and even fixes the temperature sensor issue. I've created new device trees for the 4.19 kernel which can be found at https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Buster/device_trees I attempted to install your linux-4.19.1-mvebu-tld-1 kernel on a deviceby 1000001101000 - Debian
Re: Why do we need custom kernel? - 5 years ago
Someone who's actually worked with that device can probably give you better info, but I did a quick search and found a few things. The device is running an SoC that works with that kernel and the kernel package includes a dtb for the device but I didn't find anyone claiming to have actually tried to use that kernel with this device anywhere I've been successful getting thatby 1000001101000 - Debian
Re: armada 370 (88f6710) mainline uboot support - 5 years ago
Looks like the issue with the temperature sensor was due to a bug that was introduced when they made the binding changes rather than the changes themselves. a patch was recently accepted into the mainline kernel to fix it: https://github.com/torvalds/linux/commit/70bb27b79adf63ea39e37371d09c823c7a8f93ceby 1000001101000 - uBoot
Re: NSA310 - fail installing debian - initramfs - 5 years ago
I should have probably mentioned that the /etc/fstab would be found inside the rootfs once you manage to mount it. bodhi or someone familiar with these specific images might chime in with a best practice for this situation (I haven't gotten around to trying them out yet). But I've been at this point before and think I know what you need. I'm thinking you should be able to gby 1000001101000 - Debian
Re: NSA310 - fail installing debian - initramfs - 5 years ago
admittedly I'm making a few assumptions. If you post the output of "ls /sys/block", "cat /etc/fstab" from that recovery shell and the output of "printenv" from uboot I can probably be more specific.by 1000001101000 - Debian
Re: NSA310 - fail installing debian - initramfs - 5 years ago
Quotedrakul mount: can't find /root in /etc/fstab done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... mount: mounting /dev on /root/dev failed: No such file or directory mount: mounting /dev on /root/dev failed: No such file or directory done. I'd guess the location of your rootfs doesn't match what your passing from uboot (root=xxxxby 1000001101000 - Debian
Re: armada 370 (88f6710) mainline uboot support - 5 years ago
In the change for armada-38x.dtsi the status register stayed the same: https://github.com/torvalds/linux/commit/568cc2f07c8ea5f71a0486464bd9703e4671045f#diff-6dccd1fec72d6153447441ecf6ae2ce7 I wonder if either of these would work: reg = <0x18300 0x4 0x18300 0x8>; reg = <0x18300 0x4 0x18304 0x8>; They both seem problematic to me for different reaby 1000001101000 - uBoot
Re: armada 370 (88f6710) mainline uboot support - 5 years ago
@bodhi Definitely in 4.16, I believe it worked in 4.17/4.18 but I'm not certain. My testing on those was mainly limited to figuring out why the debian versions wouldn't boot at all for me. For the record this was because they enabled CONFIG_FORTIFY_SOURCE which triggered a panic at boot because of an underlying issue with MVEBU code: https://salsa.debian.org/kernel-team/linux/commby 1000001101000 - uBoot
Re: armada 370 (88f6710) mainline uboot support - 5 years ago
There were a bunch of changes in July which seem to have broken things in the name of adding support for newer SoCs It might have been this one but I'm not entirely sure: https://github.com/torvalds/linux/commit/f7c2068a1728c1b2aed9416b071a3e2f8f887786#diff-b5e932bc729b070c9b8e17b642aeffae I found a thread where it was being discussed: https://patchwork.kernel.org/patch/10486613/by 1000001101000 - uBoot
Re: Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 5 years ago
Right on. I'm currently working on making some adjustment to the Stretch (4.9.XX) device trees to address some hardware differences that have come up in testing. Once I get those changes finished I'll make the adjustments needed to account for the binding changes needed for the 4.18 kernel and try them out with your kernel. I'll plan on using that for my testing while I wait forby 1000001101000 - Debian
Re: Unbricking OMNINAS kd20 (oxnas820) - 5 years ago
QuoteBastler I append zImage + ox820-kd20.dtb to the new file uImage. Did you create uboot images for your kernel/initrd? You should have a step where you generate them before moving them to your TFTP folder, similar to what's listed in the instructions: QuoteBodhi mkimage -A arm -O linux -T kernel -C none -a 0x60008000 -e 0x60008000 -n Linux-4.4.133-oxnas-tld-1 -d vmlinuz-4.4.133-by 1000001101000 - uBoot
Debian Stretch on Armada-370 Buffalo Devices (LS2XX, LS4XX, TS1XXX) - 5 years ago
Howdy, I've spent some time over the past year working on adapting the device tree for the the Linkstation 421DE found here to work with the Vanilla Kernel provided by Debian Stretch and also adapt it for the other Armada-370 Buffalo devices. Using these device trees along with the ssh-based network-console installer image provided by Debian it is now possible to install Debian Stretcby 1000001101000 - Debian