Turns out the PCI issue for non-DTB devices was less complicated than I thought…. Or at least working around it is fairly simple. The PCI setup attaches a map_irq function to a function pointer so that the proper irq can be assigned when a device is detected. If the driver making the call is in a kernel module that call crosses a namespace boundary and results in a kernel panic. This issue canby 1000001101000 - Debian
I have a similar quick and dirty solution I use in my installer: https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Tools/ifup-mac.sh I know someone created an out-of-tree kernel patch that mimicked the method buffalo/marvell use to pass the MAC though that repo appears to have disappeared. I never used it personally since I have this weird fixation with compatibility with Debian&by 1000001101000 - Debian
Sorry, I've been away and didn't see this. I've got a device tree for that device here: https://github.com/1000001101000/Debian_on_Buffalo/tree/master/Buster/device_trees make sure to use the wxl device tree (I believe there is mainline one too), your comment about 64 vs 128mb has me worried you may have the wrong one in mind.by 1000001101000 - uBoot
Neat! On a brighter note, I was able to Upgrade my LS-GL to Bullseye (with Debian's 5.10 kernel) without issue. Looks like some Orion5x devices should work just fine.by 1000001101000 - Debian
Quotebodhi Ah, I see that the 2MB kernel size is artificial (limited by the stock MTD partition). That sounds worth a shot, though it might not be the only limitation. I know from experience on some of those Orion5x devices uboot crashes if you try to load a kernel file larger than 2mb. It's also pretty common for NAS devices that boot from mtd devices to not have drivers for their onboarby 1000001101000 - Debian
I believe the specific issue is that the uboot on these older devices can't handle kernel images larger than 2MB and it's become virtually impossible to compile a kernel that small these days. I have some ideas to work around that limit but haven't spent much time looking at it yet. I'm guessing the TS-409 would have separate issues since it is an Orion5x devices that usesby 1000001101000 - Debian
@bhodi Thanks or starting this thread. I'm working on Bullseye support for a bunch of similar Buffalo devices and am curious to hear about any experiences with these older QNAP devices. I'm particularly curious if anyone has TS-409 and what was the latest kernel it worked with.by 1000001101000 - Debian
Quotebodhi Thanks, I defer to your experience about this :) I recall some binding for LCD in some Armada boxes. But I don't really know if this LCD needs some driver that is not in mainline yet. I believe the binding is for the shift-register that is used to multiplex the LEDs (I had fun writing a script to find those pins). As far as I could tell when I was looking into it there was noby 1000001101000 - Debian
I don't think there is a driver/binding for this type of display (please correct me if I'm wrong about that). Last year I wrote a python script which displays a bitmap on the screen (it can also be used to read the screen). Checkout lcd_test.py here: https://github.com/1000001101000/ix4-200d-research I was originally planning to do a bunch of other things for this device but ranby 1000001101000 - Debian
I'm assuming you're not using systemd, if you were you can set your script to run after the network is up via a "wants=" field. you should be able to set your script to run have dhcp-client to ensure the network will be up. it's been a while....but don't you put it in rc.6 with a suitable filename (since they get executed alphabetically)?by 1000001101000 - Debian
lol, maybe Buffalo forgot a resistor on their board design.by 1000001101000 - Debian
Exactly! Quote Aurora cache disabled: 42 MB/s Aurora cache enabled: 82 MB/s Aurora cache enabled and CPU coherency enabled: 99 MB/s If the 82MB/s->99MB/s checks out I could see going through the trouble of moving to a custom kernel based around this patch and a few others I'm aware of (phy voltage fix, patch to read MAC from atag etc). I suppose I'd need at leastby 1000001101000 - Debian
Hmmm, i’ll have to try and reproduce that. It might give me a reason to move to a custom kernel for the armhf devices. I tried to avoid that for years but the CI/CD process I put together for the MV78100 kernel is way less painful than I expected.by 1000001101000 - Debian
I suppose technically it's available form debian in the kernel-image or kernel-config package. Here's the one I just grabbed from the device.by 1000001101000 - Debian
depends on whether the kernel will just change it again after you do or not. as far as I can tell danitool and I are using the same hardware and uboot image (I flashed the one they posted) and are getting different results. I think the main difference is I'm using Debian's kernel and my DTB and they are using a custom openwrt kernel and DTB. Seems to me a strong indication this isby 1000001101000 - Debian
One of these days I should take a closer look at the openwrt work on this device. danitool has posted some really interesting stuff about the hardware and even figured out why a subset of these devices have network issues. I wonder if there's something about the openwrt kernel or their DTB that is causing this problem and is subsequently fixed by that DTB entry on the post.by 1000001101000 - Debian
I tested it against Debian's current kernels: 4.9.0-14-armmp (Stretch) 4.19.0-12-armmp (Buster) 5.8.0-0.bpo.2-armmp (Buster-backports) For all three the cache appears to be enabled already (the devmem values look correct and dmesg says it is) [ 0.000000] Aurora cache controller enabled, 4 ways, 256 kB [ 0.000000] Aurora: CACHE_ID 0x00000100, AUX_CTRL 0x1a086302 root@ls4by 1000001101000 - Debian
I'll test this out on the LS421DE (same device he's using on openwrt) under Debian and see if I can reproduce.by 1000001101000 - Debian
is it marked read-only in your device tree?by 1000001101000 - Debian
you can search for packages using: apt-cache search sqlite3 Debian's package page is also a great resource: https://www.debian.org/distrib/packagesby 1000001101000 - Debian
Keep us updated though. I've been trying to build a u-boot image for a different armada-370 device (Linkstation LS441DE). I've had some success setting up a crossbuild setup but haven't been able to generate anything useful yet.by 1000001101000 - Debian
Buffalo deactivates the serial console on many of their devices. Many can be reactivated with moderate soldering skill though some are pretty difficult. Using the external programmer with a clip connector provides a handy alternative.by 1000001101000 - Debian
my cheap CH341a has opened up all sorts of possibilities for me on devices I don't have a serial console working on. I use flashrom to do the actual programming with it. Is there a better application I should be using?by 1000001101000 - Debian
if you define your device-tree entry for the spi bus as compatible with spi-dev the flashrom utility will be able to program whatever is attached to it. I did this once while I was testing something. You could solder on a ZIF socket (or a header to connect to a breadboard or something) and fairly easily user it as a programmer.by 1000001101000 - Debian
It depends somewhat on how the various devices are defined, If the GPIOs are reserved via the DTB it won't let you export them. Some devices (I'm thinking specifically of NAND but I've seen it with others in the past) can be referenced by address without reserving the GPIO pins. In those cases it can be possible to trigger crashes or undesired behavior by messing with GPIO pins neeby 1000001101000 - Debian
They may be using those GPIOs for something else, I've noticed that with some buffalo devices. For some reason a lot of their boards have traces for a card reader but the actual SDIO pins are used for other things. you could always set up a script to to toggle GPIO pins and a known rate and then monitor points on the board you are interested in with a logic analyzer or oscilloscope.by 1000001101000 - Debian
@cyraxxx In the case of the Buffalo NAS devices most won’t reboot without sending a code to the RTC, on-board microcontroller or triggering the WOL interrupt. Since they would otherwise poweroff I had a strong motivation to figure out how to manage the shutdown/restart scripts. For devices that reboot by default this is less important, though a clean shutdown is nice when moving a device or reby 1000001101000 - Debian
You probably want to add something to disable it for a shutdown/halt (unless this wouldn’t affect that) I’m doing something very similar for a different device: https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Tools/rtc_restart.sh For systemd the script is placed in /lib/systemd/system-shutdown/ and then systemd passes restart/shutdown/halt/kexec to it as needed. I assumeby 1000001101000 - Debian
try something lighter that doesn't come with libreoffice like icewm.... unless you were planning on using this for libreoffice that is.by 1000001101000 - Debian
I haven’t tried a display but have run apps on a dummy display and used them over VNC. I’d suggest starting small... I’d start by just installing xorg and then see if you can launch xclock. Assuming that works okay try installing a lightweight window manager like icewm. KDE/Gnome/mate/etc might not work very well for this setup but a more lightweight approach might.by 1000001101000 - Debian