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
Looking at the relevant dtsi's your offsets look correct. using the other buttons I've previously identified the addresses continue to be slightly off what I would expect. f1010111: 0x01 is mpp16 f1010151: 0x20 is mpp49 f1010152: 0x80 is mpp47by 1000001101000 - Debian
I just started playing with this. I dumped 0xF1010150 and then did again with a button pressed which corresponds to mpp47. I believe that toggled 0x80 at 0xF1010152: f1010100: 1000d080 efff0f7f 00000000 00000000 ................ f1010110: 3001d080 b401ff94 00000000 00000000 ...0............ f1010120: 00000000 00000000 00000000 00000000 ................ f1010130: 00000000 0000by 1000001101000 - Debian
That gives me something to play with. I verified that the sata controller shows up within uboot but also confirmed that the drives don't show up at all via scsi scan I also tried setting all the outputs of the on-board shift register high and low used for the leds but that didn't do anything either.by 1000001101000 - Debian
That would be great. I put 4 drives in and added 4x likely pins as regulators. I tried as both active high and active low but no drives showed up. I don't see the crash anymore. I'm not sure if that's because of disabling on-board sata, adding the regulatord, or just because it's a different kernel than before. the sata controller does show up in lspci: root@ix4:~by 1000001101000 - Debian
Interesting. I suppose enabling gpios after mv_sata already crashed probably isn’t a great test. I suppose I could set up the regulators in the dts on the assumption they exist. Fortunately, the lcd etc takes up so many gpios there are only a handful left I haven’t identified, it shouldn’t be hard to guess which ones control drives if any do.by 1000001101000 - Debian
hmm, your output looks almost identical to mine (see attached). I was starting to think mine was just broken since I hadn't seen other folks with the same issue. I've mostly skipped trying to get the stock firmware working and have been working on building on the existing hardware support in Debian. I've tried enabling all the GPIO pins but none them caused the drives to powerby 1000001101000 - Debian
I implemented that to troubleshoot some bit order issues but now that I have it working it's super helpful to get a sense for how things are showing up on the screen without having to physically sit in front of it. Ascii art is a fun bonus.by 1000001101000 - Debian
I haven't read the entire thread, but have you set passwords for the users via smbpasswd?by 1000001101000 - uBoot
I took a look at that GPL code you found, it looks like it has some things in there specific to the ix4-200d but seems to be missing some things. Specifically, the driver for the lcd doesn't seem to be anywhere that I can find. There is a kernel image in there and I can see from it's strings that it was built with the lcd driver but I don't see the actual source in there anywhere.by 1000001101000 - Debian
The gpl source would be good to have access too if you have it. I did a little work with my device though not as much as I would have liked with sata not working. What I did do is: - add entries to the dts for each of the buttons - add entries to the dts for the leds - add entries to the dts for the stock nand partitions - create a python script that displays an example image (debianby 1000001101000 - Debian
I've started working with mine but can't seem to get sata to work at all (built-in or PCI). It's possible mine is a hardware problem but I haven't confirmed that yet. At one point I dug through those posts too but didn't find what the solution was. I'd be interested to know as well.by 1000001101000 - Debian