CryBaby

Will it cook my breakfast too?

linux-sunxi@googlegroups.com is where they used to hang out but I don't know if they are still active there.

https://docs.armbian.com/Developer-Guide_Build-Preparation/ Once you have the code installed copy the above-linked patch to build/patch/kernel/archive/sunxi-something/ and do the compile.

There is a patch. It doesn't appear to have reached mainline yet. Perhaps it could be added to Armbian builds. You probably want to go back to your original, working, kernel.

I believe the nand is not supported. This is not a great loss as it is flaky and unreliable. Not sure about the rtc. Do you have a battery?

This is likely a $PATH issue. usermod is in /usr/sbin which is probably not in your user's $PATH. If you su without adding - you do not get root's $PATH but with sudo you do.

That does look like a bad SD card. If another one works that would tend to confirm it.

I would guess you have fiddled with /etc/fstab or copied your root partition from elsewhere without fiddling with your /etc/fstab. Or maybe /boot/armbianEnv.txt At any rate, the kernel is looking for a partition with UUID=0b77.... to mount at / but isn't finding it. So you need to either change the UUID it is looking for to the one your root partition has, or change your root partition to have the UUID it is looking for.

You could set up a cron job to reboot it every so often. Log in with PuTTY and type sudo crontab -e This will open the default crontab in an editor, probably nano. At the end of the file add the line 0 * * * * systemctl reboot to reboot every hour on the hour. It needs to have a newline at the end, ie. a blank line at the bottom of the file. man 5 crontab will tell you more.

I haven't tried it lately but it didn't work last time I did. It looks like everything is in place but it does't actually work. My conclusion was it is a bug or at least a lack of support for the hardware.

A better power supply might fix 1 and 2, they can go bad over time. 3 is a bug, sometimes you will get a connection, but mostly no carrier.

CONFIG_GMAC_TX_DELAY seems to have been added to uboot in 2015 so the question is is it being set in armbian? I don't know if it can be set in bootEnv.txt or you have to set it at build time. I don't have access to my cubietruck right now...

That looks like it is working to me. I have been fiddling with my cubietruck recently and I notice that it doesn't always connect to the network too, so maybe the problem has nothing to do with your carrier board.

I have no clue, but maybe you will find one in the system logs.

I don't believe mainline kernels support the NAND, and aren't likely to as it is flaky. I would try whatever the current image is and see what you get.

Why not use libgpiod? Or try to port mraa?

You are probably going to need a share name after the IP address smb://10.10.2.101/sharename Running smbclient from the command line will give you more feedback and allow you to search for shares.

Normally your router will be responsible for translating the hostname to an IP address. So if it stops working you should look at your router's DHCP and DNS. Often both will be handled by dnsmasq. Rebooting your RockPro will renew its DHCP lease.

I haven't seen modules like those before but I've used the typical 'terminal server' in a metal box. They work, the only caveat I would mention is that they can have old and non-standard web interfaces for configuration. Some of the cheaper ones I've used can only be accessed with Konqueror, not Firefox or other more common browsers. I don't know about VLANs.

I would look at mraa and upm.

You should ask on the kiauh github, I think the problem is kiauh not armbian.

The last time I tried using my Cubieboard 2 I wanted to use SPI and had some trouble. This was 2 or 3 years ago. The main reason I gave up though was the 2mm pin spacing. Maybe you found a suitable cable. I would start by getting a current uboot on to it then watch it boot on the serial port. Inspect the default env, see what env file it is reading, check it is loading the overlays etc.

I don't know how it works but in my experience it does. The Prolific page here says "Flexible signal level requirement on the RS-232 like serial port side also allows the PL-2303HX to connect directly to 5V, 3.3V, or 2.5V devices."

I think the one you have will be fine. Just don't connect the red wire, even on boards which have 4 pins.

If /boot is not already a separate partition I would think there is not much advantage in making it one. The main problem is machines that need a FAT formatted boot partition, as FAT is so fragile. I don't know if your Tinkerboard is one. If /boot is on an ext4 partition then fscking at boot is going to be adequate protection in most cases. If you really want to mess with your partitions I think you will have to understand the boot process of your Tinkerboard in some detail. Does boot have to be the first partition? What filesystems are acceptable? What files need to be in it and what should they contain?