- _"I know that my power supply is good", "it worked yesterday", "it works with a different device",_ etc. are **not objective reasons** to skip powering related diagnostics
- _"I know that my SD card is good", "it worked yesterday", "it works with a different device",_ etc. are **not objective reasons** to skip storage related diagnostics
- undervoltage can cause symptoms related to SD card problems such as filesystem corruptions and data loss, so powering has to be checked first
- Most boards, even ones fitted with PMIC (power management integrated circuit) do not have any measures to react to undervoltage that could prevent instability
- It does not matter what voltage your power supply outputs, it matters what voltage will reach the onboard voltage regulators
- Peak power consumption of popular boards can vary from 0.9A at 5V (H3 based Orange Pi PC) to 1.7A at 5V (RK3288 based Tinkerboard), both without any attached peripherials like USB devices
- Due to the Ohm's law voltage drop due to cable and connector resistance will be proportional to the electric current, so most of the time problems will be experienced at current spikes caused by CPU load or peripherials like spinning up HDDs
- MicroUSB connector is rated for the maximum current of 1.8A, but even this number cannot be guaranteed. Trying to pass larger current (even momentarily) may result in a voltage dropping below USB specifications
- A SD card is a complex storage device with an embedded controller that processes read, erase and write operations, wear leveling, error and corruption detection, but it does not provide any diagnostic protocols like S.M.A.R.T.
- SD cards will degrade over time and may fail in the end in different ways - become completely or partially read-only or cause a silent data corruption
- SD card speed class and size does not influence the reliability directly, but larger size means larger amount of lifetime data written, even if you are using 10-20% of the cards space
- If you wrote an image to the card it does not mean that it was written successfully without any errors
- so always verify images after write using some tools like _balenaEtcher_ which is currently the only popular and cross-platform tool that does mandatory verify on write (more lightweight alternatives may be added to this page in the future)
If you experience strange network problems, especially if you are running several of these SOC-boards with the same operating system, then the problems may be sourced by not having a real hardware MAC address. The operating systems try to generate a hardware MAC address from the CPUid, but what if that SOC has no CPUid either?
Then you have to do it manually. Depending on system and network installation, there are several possibilities:
- the preferred way: change `/boot/armbianEnv.txt` and add a line:
ethaddr=XX:XX:XX:XX:XX:XX
but that file is interpreted by u-boot, which happens early in boot process, but not every u-boot is able to read that file.
- next possibility to set mac-address is changing network configuration. On systems with **ifupdown** you can do that by changing `/etc/network/interfaces`. Add these lines:
- if the above does not work, then your network is probably controlled by **Network-manager** . In directory `/etc/Networkmanager/system-connections` is a file `Wired connection 1.nmconnection`. Change entry _cloned-mac-address_ of group **[ethernet]** :
Some combination of boards/kernel versions does not support 4k resolution. This may cause black screen on connecting the board to 4k resolution devices. A workaround to solve this without changing the kernel is forcing the video mode to 1080p. Add this directive to the `/boot/armbianEnv.txt` and reboot your system:
extraargs=video=HDMI-A-1:1920x1080@60
- Despite of this config, some apps may try to use 4k resolution, example: _Retroarch_. In this case you have to change app configuration to use the 1080p resolution.
- To edit files without video you could connect to the board using ssh. Other option is mount the sd card in another device.
