CryBaby

Only build them if you actually want feedback, otherwise we'll just annoy you with bug reports.

Now I look at the contents of p2-station-update-uboot I see it has in fact not worked; the writing of the new uboot did not occur. Presumably the SPI must be erased first. So how do I do that safely?

root@station-p2:~# sudo /vendor/p2-station-update-uboot 16384+0 records in 16384+0 records out 8388608 bytes (8.4 MB, 8.0 MiB) copied, 0.378473 s, 22.2 MB/s 8192+0 records in 8192+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.159035 s, 26.4 MB/s I have had this P2 for a year and have updated to the latest Station OS, and enabled/disabled the OS Bootloader several times. I have of course studied that thread. I was hoping your fix was in the latest Station OS update but I guess not. It is not clear to me how to erase the SPI as you suggest. There are some advanced options that might do it in the OS Bootloader. I worry that I may end up unable to boot anything.

The image here does contain the p2-station-update-uboot script. It runs successfully but Armbian_22.05.3_Station-p2_bullseye_edge_5.18.0_xfce_desktop.img and Armbian_22.08.0-trunk_Station-p2_sid_edge_5.19.3_xfce_desktop.img do not boot.

The instructions at the P2 page cannot be followed. The image at the link does not contain the p2-station-update-uboot script. I have tried using the Station OS multi-boot thing but that didn't work either. What is the correct way to do it now?

I vaguely remember having trouble with this myself. The 2mm pins were a problem too so I switched to a different board. Are you absolutely sure you have shorted the right two pins? One of those $10 USB logic analysers from eBay can be handy to see if the TX is actually TXing. They work with Pulseview from Sigrok.

This will be the easiest approach, provided you have linux on your PC. If you don't then you could make another working sd card, boot your SBC with that and plug in the broken one using an adapter. Then you mount the broken card and undo whatever you did to break it. None of this is specific to a particular board.

For direct connection the PC will need to run a DHCP server if you don't want to set a static IP on the SBC. You don't want two DHCP servers on your network so you will have to configure it carefully or disconnect from the router while it is running.

Is your PC running a DHCP server?

You need to fix your network. Probably then ssh will work.

Can you ping it? What does ssh -v say?

It might help to use HostkeyAlgorithms +ssh-rsa in your .ssh/config stanza. Run ssh with -v for some debug output. I also have key exchange problems connecting to bullseye from newer Debian (and Windows) for which the only solution has been to use something else.

Unlikely, unless the PC is ancient. Most interfaces these days have auto-MDI-X.

It will probably be easiest to just set your Pi to use 192.168.137.x where x is a number between 1 and 254 that is not in use by any other device on your network. If you have more than one ethernet interface in use you may also need to set a route in your PC to use the right interface for the Pi.

You'll need a route from the 192.168.137 network to the 192.168.1 network, probably in your gateway. Hopefully you have a network administrator who will cooperate.

Is sshd running on your Pi? What do its logs say? Does your network have a route from 192.168.137.3 to 192.168.1.10? Can you ping it?

I would guess it would usually be the same as the address but with 0 in the last place. However, you probably don't want to be messing with that at all. network-manager

That's a bit inconvenient. You might be able to move the console to the external port by changing the kernel boot command. Not sure what to, maybe ttyS3 or ttyS4.

Are you using minicom? Sometimes the baud rate is set to 1000000 or something really high and minicom only goes up to 150000. Try tmux or screen.

It looks to me like your SPI is succeeding but the kernel then wants to use the pin for IR which is failing. So try disabling the IR. It would be easier to read text than images. Probably easier for you to post too.

I prefer to use LABEL= in my fstab rather than UUID. It is a little more forgiving of media changes, provided you remember to give your filesystems consistent labels. You probably don't want to have swap on an SD card. I thought Armbian used zram for that.

This does not mean it is normally mounted read-only. It means it will be mounted read-only if mounting it read-write fails.

If there is not already a line for /boot in your fstab then it is a subdirectory not a separate partition. In which case the read-only trick is not applicable. Just adding a line for it will not work. I would try adding fsck.mode=force fsck.type=repair to your kernel command line. In most cases that will be able to fix any corruption on boot. If you still have the problem overlayroot is the next thing to try. As I understand it that will make your real root filesystem read-only and any changes are only made to a copy of it in RAM. So a power loss will lose those changes but you are guaranteed a working root to boot off. Never set it up myself so Google it.

I don't know about Odroid, on the Raspberry Pi is certainly is a problem. (V)FAT is a very bad filesystem that was designed by idiots Microsoft in the 1980s. It is very prone to losing metadata if the power goes out. Raspberry Pi uses it as its proprietory boot loader cannot read anything else. Yes, that's why it prevents damage on loss of power. You usually only need to write to /boot when you update the kernel or bootloader. You can temporarily remount it read/write before doing an update then when you reboot it will be read-only again.

This sounds like a common problem seen with Raspberry Pi. There it is due to the boot partition being formatted as VFAT. If that is also the case with the Odroid then the solution is to modify /etc/fstab to mount /boot read only. It can also help to add fsck.mode=force to the kernel command line so the fs gets checked on every boot.