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
here's a device tree using a drive detect gpio as a button as I described earlier: https://github.com/1000001101000/Debian_on_Buffalo/blob/master/Buster/device_trees/armada-370-linkstation-ls421d.dtsby 1000001101000 - Debian
Typically I've seen those GPIOs configured as gpio-buttons in the device-tree. Once you have that setup you can cause them to trigger things using triggerhappy or similar.by 1000001101000 - Debian
If you're looking for the behavior to change when a drive is inserted you could create a udev rule that changes the trigger. You could create a corresponding one for when it's removed for that matter. If this device has drive-detect GPIOs you could also use that to signal the change. perhaps easier than both of the above would be writing a daemon script that checks for a drive eveby 1000001101000 - Debian
I do wish there was a definitive guide for optimal file transfers between low CPU/RAM devices. I see similar questions from time to time but don't have a good answer to provide anyone. It seems like there is some sort of upper limit in the range you're seeing though I haven't identified what it is exactly.by 1000001101000 - Debian
I don't think i have my notes but I can try it again in the near future and make sure I capture the output. I think the source archive earlier in the thread may have included u-boot for this box.by 1000001101000 - Debian
Looking back, your original error might have been resolved by just installing GCC/etc: apt-get install build-essential I still prefer to use the Debian packaged versions in most cases. I usually try to avoid to avoid the extra space required for all the build dependencies and the hassle of building/compiling on these devices where possible.by 1000001101000 - Debian
Lol, i’m just knowledgable enough of Python to know the libraries I’ve written are pretty ugly... though they do get the job done. I just installed motioneye on a Buster armel system (TS-XL) without much trouble: apt-get install python3-pip python3-pil python3-pycurl pip3 install motioneyeby 1000001101000 - Debian
I'm growing to dislike the python ecosystem/pip for exactly this type of issue.Some packages work like magic others will download 5gigs of libraries and spend 2 hours compiling only to throw an error because you're not running on a raspberrypi. Fortunately, Debian provides packages for some of the common python libraries that are difficult to build on platforms like armel. You shby 1000001101000 - Debian
I guess it's time to start my testing/Bullseye branch. I suppose it was around this time on the cycle i started working on Buster.by 1000001101000 - Debian
Nice. It's probably 115200. if you've got it wired up correctly you should see some output even with the wrong settings (it's just be gibberish). Try reversing rx/tx and see if that helps... also connect gnd if you didn't already.by 1000001101000 - Debian
Could you post pictures of the board? The serial header was painfully obvious on the N4B1 board. but this model is very different it turns out. Does this look like it: https://www.smallnetbuilder.com/myincludes/image_page.php?/images/stories/nas/lg_n2b1/lg_n2b1_board.jpg It's not obvious to me from that picture but could be somewhere not in frame. Interestingly this one appearsby 1000001101000 - Debian
ugh, did the binding change? Guess I have some device trees to update.by 1000001101000 - Debian
heck, it makes swap even more important. If you're going to reserve that much memory you'll end up needing to swap even sooner.by 1000001101000 - Debian
No, the scripts main purpose is to send instructions to the microcontroller built into the board on some buffalo devices. It wouldn’t work for other devices.by 1000001101000 - Debian