I get the solution ... I followed the steps of that video [https://www.youtube.com/watch?v=d1UbEg9kf5c](link url) but at the end I add one step ... I execute that command mount /dev/mmcblkop1 /overlay ... and then reboot. That was the only way to configure the microSD card. Thanks for your help :)
Same SD card works fine on another Omega2+ so I'm less likely to think its the card. Supply voltage looks good as well, 3.45v (need to adjust regulator resistors to bring that down to 3.3v) That's a good path to check and more data sheet driven then my approach of swapping the cards and performing a functional check.
I saw that diagram with those pinouts as well but isn't EPHY_APGIO_AIO_EN set in software and not affected by the boot pins?
After a few hours of experimenting here the issue turned out to be a relatively strong pulldown on GPIO45. This was affecting a boot pin. Looking at http://plan44.ch/downloads/Onion-Omega2-Pinout-annotated.png and the MT7688 data sheet though it isn't clear exactly what the issue is. Measuring the module itself there is a 4.7k pullup to 3.3V on that pin, so no need for external strapping. Pulling that pin down would appear to be enabling JTAG mode, page 33 of the MT7688 data sheet fyi.
JTAG pins look entirely separate from SD interface pins though so maybe I'm close on the bootstrap pin issue but off on the effect? I still can't figure out why everything would boot fine if that GPIO45 was strapped low (overriding the 4.7k pullup) but just the SD card wouldn't be working......
@Maximilian-Gerhardt I agree on your idea for laying this out. USB for the disk, the built-in µSD card slot for the µSD card. Add some LEds, buttons, and/or expansion boards for a physical user interface if you want one.
USB 2.0 will be limited to ~60 megabytes per second, but that might be fast enough for many uses, like if you just want to leave the µSD card in this auto-backup-dock-thing whenever it's not in use. If you want more speed, it's probably time to use a more powerful device with USB 3.0 or native SATA. That might be an old laptop, or a faster single-board computer (some have USB 3.0).
As to software, I bet this will be possible using some combination of scripts or programs that do the actual sync, and something to start it when a new card is inserted, probably procd. For copying, I'd consider rsync, as I bet there's some combination of flags that will make sure that your data only gets copied off once, not multiple copies of the same data.
Assuming you want to delete the files off of the uSD card once they're copied, you could mount the µSD card once as "read-only", copy the data off, then remount it as "read-write" for just a few seconds to delete the files, then unmount. This is pretty safe, as you can safely yank the µSD card out at any point in time except during that time when it's mounted "read-write".
but i mean logically swapon should be part of swap_utils right? i mean that would make sense
Sure, it would. It's not the Onion-devs who decided to place it in block-mount, though -- the decision is made upstream.
secondly dunno my microsd keeps becoming un accessible, i actually think its random and not associated with the command error, however it was still under the temp directory as i wasn't mounting it on startup - maybe that was the issue
Maybe you could try with another card? Perhaps the one you're trying is bad or doesn't sit entirely properly in the slot. Or, perhaps mountd (the application that handles automatic mounting of stuff) is buggy -- have you tried manually mounting it? Something like e.g. mount /dev/mmcblk0p1 /where/you/want/it/mounted -o noatime -t ext4 should work. Personally, I don't like the automount-thingamabob.
i really appreciate your response, i think because its in such an early stage and im inexperienced i struggle to tell if i am doing somehting incorrect or its broken, so knowing you have it going helps alot