umiddelb

IMHO some of the recent mainline u-boot versions had difficulties to save the u-boot environment, which means that `saveenv´ will override not only the environment itself but also code-parts nearby, rendering the firmware unusable. Therefore changes to the u-boot environment can only performed at build time for some boards.

You need to add the relevant executables echo \ '#!/bin/sh . /usr/share/initramfs-tools/hook-functions copy_exec /sbin/e2fsck /sbin copy_exec /sbin/fsck /sbin copy_exec /sbin/fsck.ext2 /sbin copy_exec /sbin/fsck.ext4 /sbin copy_exec /sbin/logsave /sbin' \ | sudo dd of=/etc/initramfs-tools/hooks/e2fsck.sh sudo chmod +x /etc/initramfs-tools/hooks/e2fsck.sh before building the initrd sudo update-initramfs -c -k ${kver}

You may try to load an uImage instead of the vmlinuz image. This incorporates with the vendor u-boot firmware.

This is the pin layout of the serial console adapter for all Odroid models. The Amlogic and Rockchip boards run the serial console with a 3.3 V UART therefore ...

I can get in touch with the odroid guys to change this situation if you want.

see here ...

I've talked to some Turris people at FOSDEM 2019, they are using the same SoC and they've published the kernel source code and u-boot source code. Chances are that the EspressoBin might benefit from the MOX kernel, as the Turris people have added support for some additional hardware the SoC comes with.

There is a similar issue here: "... Figured it out. Two kernel configuration options were in play: CONFIG_COMPAT=y CONFIG_LSM_MMAP_MIN_ADDR=32768 Above is what is required to run armv5tel and armv7hl chroots on aarch64. Default for the latter option is 65535, which prevents 32-bit binaries from running. Up and running with 4.9.153 now. ..."

Here's a reference for an open source project using jira ...

Atlassian offers free-of-charge licenses for Open Source projects ...

Any 3.3 V level UART USB dongle will do the job (for the C0/C1/C1+/C2), you can even use standard breadboard female cables to connect to the Odroid serial console pins:

I plan to attend FOSDEM 2019, anyone else too?

You can disable logging to ram by setting `ENABLED=false´ in `/etc/default/armbian-ramlog´.

You won't be able to build one universal image. Many boards load their firmware from uSD or eMMC, so the board's firmware has to be part of the image. And even if they share a common SoC platform like the AmLogic GX S9**, the firmware blobs are different. And even if you manage to build an universal image for boards with flash memory based firmware, you still want to impose some kind of standard like SBSA. And even then you have to become specific at some point in order to apply the appropriate optimization / configuration for the board. In other words, you're just carrying complexity from 'build time' to 'run time'.

If it is not placed in /etc/NetworkManager/system-connections, where can I find the magic behind the NM configuration. The user guide pages aren't going too much into detail.

Even if I remove the bogus configuration called `eth0´, it is going to be recreated during next boot.

I'm very new to Network Manager (which seems to be less confusing than Netplan) ... nmtui shows two connections (which aren't present at /etc/NetworkManager/system-connections) ┌───────────────────────────┤ Edit Connection ├───────────────────────────┐ │ ↑│ │ Profile name eth0____________________________________ ▮│ │ Device eth0 (D0:63:B4:00:83:30)________________ ▒│ │ ▒│ │ ═ ETHERNET <Show> ▒│ │ ▒│ │ ═ IPv4 CONFIGURATION <Disabled> <Show> ▒│ │ ╤ IPv6 CONFIGURATION <Manual> <Hide> ▒│ │ │ Addresses 0:d263:b4ff:fe00:8330/64_ <Remove> ▒│ │ │ <Add...> ▒│ │ │ Gateway _________________________ ▒│ │ │ DNS servers <Add...> ▒│ │ │ Search domains <Add...> ▒│ │ │ Routing (No custom routes) <Edit...> ▒│ │ │ [ ] Never use this network for default route ▒│ │ │ [ ] Ignore automatically obtained routes ▒│ │ │ [ ] Ignore automatically obtained DNS parameters ▒│ │ │ ▒│ │ │ [ ] Require IPv6 addressing for this connection ▒│ │ └ ▒│ │ ↓│ └─────────────────────────────────────────────────────────────────────────┘ ┌───────────────────────────┤ Edit Connection ├───────────────────────────┐ │ │ │ Profile name Wired connection 1______________________ │ │ Device D0:63:B4:00:83:30 (eth0)________________ │ │ │ │ ═ ETHERNET <Show> │ │ │ │ ═ IPv4 CONFIGURATION <Automatic> <Show> │ │ ═ IPv6 CONFIGURATION <Automatic> <Show> │ │ │ │ [X] Automatically connect │ │ [X] Available to all users │ │ │ │ <Cancel> <OK> │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ └─────────────────────────────────────────────────────────────────────────┘ What is supposed to be the Armbian default, where are the configuration files located?

What is the preferred way to configure the network interfaces in Armbian/Bionic?

I've a similar problem with my Cubox-i after updating to 5.60 (ARMBIAN 5.60 stable Ubuntu 18.04.1 LTS 4.14.70-cubox). The eth0 interface comes up with an ipv6 address only: uli@cubox:~$ ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet6 fe80::d263:b4ff:fe00:8330 prefixlen 64 scopeid 0x20<link> inet6 fd97:40e:e79f:0:d263:b4ff:fe00:8330 prefixlen 64 scopeid 0x0<gl> ether d0:63:b4:00:83:30 txqueuelen 1000 (Ethernet) RX packets 22 bytes 3230 (3.2 KB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 24 bytes 3427 (3.4 KB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

I own another imx6 based device (utilite pro) which doesn't boot the armbian image for the cubox-i out of the box. After some bisects I've found a common mainline kernel configuration for both of them. The mainline kernel comes with device tree source files for various imx6 based boards, but obviously not for yours, so you are bound to the kernel releases issued by advantech. If you have a more or less working setup (i.e. u-boot boots up a kernel from a certain root device and the kernel is able load its modules && you can watch this from your serial console), then you may replace the existing userland by something different of your choice.

I'd recommend a Freescale/NXP SoC as well. As they are selling their chips to industrial clients the product longevity is substantially better compared to chips used in tablets, phones or set-top boxes, see here for more details. But product longevity has it's price ...

I've found a workaround but only for the traditional way of configuring network interfaces via /etc/network/interfaces.d: auto eth0 iface eth0 inet manual auto lan0 iface lan0 inet dhcp pre-up /sbin/ifup eth0

The new firmware prohibits the address usage between 0x4000000 and 0x54f0000, therefore you need to adjust the load addresses for initrd, kernel and dtb.

Many Open WRT devices use a similar architecture with one CPU port and a VLAN capable ethernet switch, they don't seem to need an extra NIC. IMHO pcie support has improved a lot in recent kernels. You may try a mainline kernel instead.