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
I know @bohdi isn't a fan of them but I have had some really good luck with hybrid MBR/GPT partition tables to allow older devices that boot from disk to use large drives without replacing u-boot. I've actually recently been testing some old orion5x devices from ~2007 with 4TB drives with surprisingly good results. I'm still working on the documentation but this includes thby 1000001101000 - Off-Topic
another thing you can try is removing unneeded drivers from the kernel. It doesn't look like you have much unneeded stuff but removing the PCI driver and skipping PCI initialization/scanning might be worth a few seconds.by 1000001101000 - Debian
cross compiling is surprisingly easy (I love how much better these tools have gotten since ~2006 when I first tried them). The script I use to build armel kernels for mv78100 device can be found here: https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Tools/kernel_tools/build_kernel.sh here are the prereqs for it: apt-get -y install libc6-armel-cross libc6-dev-armel-cross binutby 1000001101000 - Debian
Honestly, it's been a few years since I did a deboostrap so I may be mistaken about the ways that it differs from the normal process. I believe the main thing is that it automatically handles the emulation for the second stage automatically. You still have to copy in qemu-arm-static before chrooting into it afterwards, I don't know if the process copies it in and then deletes it afteby 1000001101000 - Debian
Good point. 60 sec really is pretty good. Reducing the size of the initrd by a few megabytes might get you a couple seconds faster depending on the speed of the device it is being loaded from. Installing haveged will speed up the filling the entropy pool and allow ssh to start a little faster in some cases. You could build a custom kernel that does not need an initrd at all which would save evby 1000001101000 - Debian
Oddly enough we were just talking about this on another thread. A sizeable amount of the time uboot spends initializing is from loading the kernel+initrd into memory before booting them. You can reduce the size of the initrd significantly by limiting the included modules and switching to a more aggressive compression algorthm.by 1000001101000 - Debian
I haven't tried you're uboot/kernels and I know that modern uboot documentation mentions handling decompression of uImages... but every kernel/uboot I've worked with has relied on the kernel to do the actual decompression of the initrd image which works as long as the associated kernel options have been enabled. The settings I listed above have been tested on devices with 64MBby 1000001101000 - Debian
I've been using XZ compression to reduce the size further in some cases. After some trial and error I've found these settings to be the best trade-off between speed/compression while keeping memory usage low: ``` ~# cat /etc/initramfs-tools/conf.d/compress COMPRESS=xz XZ_OPT=-2e export XZ_OPT ``` downgrading kmod to a version before they added the libssl dependency (to theby 1000001101000 - Debian
Although anything requiring re-flashing the NAND should not be taken lightly.... You're definition of "ain't broken" may require some additional consideration in some cases. Part of what got me into running mainline linux on consumer NAS devices was serious un-patched security vulnerabilities often found in old versions of samba/bash/ftpd/etc on these devices. It might be wby 1000001101000 - Debian
If necessary you could also force it: modprobe -fby 1000001101000 - Debian
depmod -a; modprobe r8188eu or insmod /lib/modules/4.14.176-oxnas-tld-1/kernel/drivers/staging/rtl8188eu/r8188eu.koby 1000001101000 - Debian
Depends on your use cases. Lately i’ve been using vagrant to automate creating/destroying VMs for testing. I’ve also played around with QEMU to emulate arm systems, though that adds more overhead than it’s worth in most casesby 1000001101000 - Off-Topic
For these serial connections RX and TX are completely independent of each other, the fact that RX is working doesn't indicate anything about TX. I would suspect since one is working that your ground is also fine. Anything you are seeing with the cursor is likely client-side and probably doesn't indicate much. One thing to try is start tapping a key immediately after pressing the pby 1000001101000 - Debian
sounds like you already have a working solution then. I'm not familiar with this trigger but my guess for why it wouldn't work from setting it in the device tree is that the gpio-led module might be loaded before the module for that trigger resulting in the trigger not being set. Either that or there is something wrong/missing with that binding or how it's being used. I thinby 1000001101000 - Debian
QuoteI am pretty much a Linux noob despite using ubuntu on a daily basis as my go to OS, in hopes of becoming fluent after an eternitty (Go figure) Sounds like you're exactly where I was in ~2010 when I started messing with my LG N4B1 NAS. It's a good way to learn a bunch of things "the hard way" without messing up your main system. Eventually those lessons apply back to manaby 1000001101000 - Debian
you can use triggerhappy to trigger a script whenever KEY_PROG1 changes. You could then have that script change the LED trigger or perform any other action that you'd like. ....though, thinking about it you'd likely want to run the script at startup as well since triggerhappy will only see when it changes.by 1000001101000 - Debian