y52

It is unable sustaining a day or two without a sporadic reboot. It doesn't leave any error logs. It just reboots on its own. I am not sure if this is a U-Boot preset settings, which lead to instability or a current running Linux system. The latter one is : Linux espressobin 4.19.56-mvebu64 #5.89 SMP PREEMPT Tue Jun 25 22:27:47 CEST 2019 aarch64 GNU/Linux

Thank you Pali. It was good to finally discover the SoC chip frequency. My chip shows something like (difficult to read): 66F3720-XX C100 ?? thus a C100 1 GHz part. It was not advertised as this, as GlobalScale sold it as a 1.2 GHz board. Those who were supplied a 800 MHz variant could have been surprised badly. I believe it is a bad practice leading to confusion as well as it brings users more challenges finding the right implementation. Having said that, my 1 GHz board still remains unstable with the 1 GHz firmware variant. I understand, that some progress was made with u-boot settings. Where could a new version with patches be found?

I have a 2Gb espressobin V5 board. Where could the SOC variant be found on the board? I also had trouble with the board CPU and unable mounting to 1.2GHz. I am currently running with 1.0GHz, but the board is rebooting on its own every day or two. Here are my board pictures : https://mega.nz/folder/OpRDwRCa#lKtPNqEUyTHB5V_HZJEiew

Thanks to everybody. 'apt install busybox' indeed fixed the issue. I was not sure that initramfs image is regenerated on this arm board, as the kernel remains static and boot process is dependent on u-boot settings. A side note : It is not feasible not rebooting My espressobin is rebooting on its own every day or two and it happens since I bought it. I've never been able finding out what causes those intempestive reboots. The system doesn't raise any errors. It would be interesting finding in Peer to Peer Support someone's experience upgrading from Stretch to something more modern. Has anybody achieved it?

Hello, I was trying updating/upgrading Armbian on espressobin v.5 Linux kernel 4.19.56-mvebu64 #5.89 SMP PREEMPT Tue Jun 25 22:27:47 CEST 2019 aarch64 GNU/Linux and ran into confusion with initramfs-tools package. updating packages raises an error : Processing triggers for initramfs-tools (0.130) ... update-initramfs: Generating /boot/initrd.img-4.19.56-mvebu64 E: busybox or busybox-static, version 1:1.22.0-17~ or later, is required but not installed update-initramfs: failed for /boot/initrd.img-4.19.56-mvebu64 with 1. dpkg: error processing package initramfs-tools (--configure): subprocess installed post-installation script returned error exit status 1 Errors were encountered while processing: initramfs-tools E: Sub-process /usr/bin/dpkg returned an error code (1) root@espressobin:~# dpkg -C The following packages are only half configured, probably due to problems configuring them the first time. The configuration should be retried using dpkg --configure <package> or the configure menu option in dselect: initramfs-tools generic modular initramfs generator (automation) root@espressobin:~# apt-cache show initramfs-tools Package: initramfs-tools Version: 0.130 Installed-Size: 105 Maintainer: Debian kernel team <debian-kernel@lists.debian.org> Architecture: all Provides: linux-initramfs-tool Depends: initramfs-tools-core (= 0.130), linux-base Suggests: bash-completion Conflicts: linux-initramfs-tool, usplash (<< 0.5.50) Breaks: console-setup (<< 1.72), cryptsetup (<< 2:1.6.6-4~), e2fsprogs (<< 1.42.13), elilo (<< 3.12-3.1~), initscripts (<< 2.88dsf-59.3~), lilo (<< 22.8-8.2~), lvm2 (<< 2.02.111-2.1~), s390-tools (<< 1.8.3-2~), systemd-sysv (<< 186), upstart Description: generic modular initramfs generator (automation) Description-md5: f406a6ad4452bdc36e9957a711143c2e Multi-Arch: foreign Tag: admin::boot, admin::filesystem, admin::install, admin::kernel, implemented-in::shell, interface::commandline, role::program, scope::application, scope::utility, works-with::archive Section: utils Priority: optional Filename: pool/main/i/initramfs-tools/initramfs-tools_0.130_all.deb Size: 65976 MD5sum: 19760d5fe943a82127871846bf188e76 SHA256: b5a2071f6d5bd25d894097717e1efd9441b6253c238220d014511e01ae81cbff Is initramfs-tools required on that system? 'apt autoremove' suggests removing other packages, including linux-stretch-root-next-espressobin : root@espressobin:~# apt remove initramfs-tools Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: initramfs-tools-core klibc-utils libklibc Use 'apt autoremove' to remove them. The following packages will be REMOVED: initramfs-tools linux-stretch-root-next-espressobin 0 upgraded, 0 newly installed, 2 to remove and 174 not upgraded. 1 not fully installed or removed. After this operation, 109 kB disk space will be freed. Do you want to continue? [Y/n] Y^C root@espressobin:~# apt-cache show linux-stretch-root-next-espressobin Package: linux-stretch-root-next-espressobin Status: install ok installed Priority: optional Section: kernel Installed-Size: 1 Maintainer: Igor Pecovnik <igor.pecovnik@****l.com> Architecture: arm64 Version: 5.90 Replaces: zram-config, base-files, armbian-tools-stretch Provides: armbian-bsp Depends: bash, linux-base, u-boot-tools, initramfs-tools, python3-apt Recommends: bsdutils, parted, util-linux, toilet Suggests: armbian-config Conflicts: armbian-bsp Description: Armbian tweaks for stretch on espressobin (next branch) Description-md5: 89a961dbb58e2aad95259300d73b63b8 How could initramfs-tools dependency on busybox be overcome? Could initramfs-tools and linux-stretch-root-next-espressobin be removed at all from the running system? My /boot directory content : root@espressobin:~# ls -al /boot total 31716 drwxr-xr-x 3 root root 4096 Sep 25 17:05 . drwxr-xr-x 25 root root 4096 Jul 2 22:34 .. -rw-r--r-- 1 root root 221 Sep 25 07:17 armbianEnv.txt -rw-r--r-- 1 root root 1536 Feb 9 2019 armbian_first_run.txt.template -rw-r--r-- 1 root root 38518 Feb 9 2019 boot.bmp -rw-rw-r-- 1 root root 1047 Feb 9 2019 boot.cmd -rw-r--r-- 1 root root 4882 Feb 9 2019 boot-desktop.png -rw-rw-r-- 1 root root 1119 Feb 9 2019 boot.scr -rw-r--r-- 1 root root 139058 Jun 25 2019 config-4.19.56-mvebu64 lrwxrwxrwx 1 root root 19 Aug 8 2019 dtb -> dtb-4.19.56-mvebu64 drwxr-xr-x 3 root root 4096 Aug 8 2019 dtb-4.19.56-mvebu64 lrwxrwxrwx 1 root root 19 Feb 9 2019 dtb.old -> dtb-4.19.20-mvebu64 lrwxrwxrwx 1 root root 23 Aug 8 2019 Image -> vmlinuz-4.19.56-mvebu64 -rw-r--r-- 1 root root 6200589 Sep 28 2020 initrd.img-4.19.56-mvebu64 -rw-r--r-- 1 root root 0 Aug 8 2019 .next -rw-r--r-- 1 root root 3366255 Jun 25 2019 System.map-4.19.56-mvebu64 lrwxrwxrwx 1 root root 23 Sep 28 2020 uInitrd -> uInitrd-4.19.56-mvebu64 -rw-r--r-- 1 root root 6200653 Sep 28 2020 uInitrd-4.19.56-mvebu64 -rwxr-xr-x 1 root root 16488960 Jun 25 2019 vmlinuz-4.19.56-mvebu64

My UART cable hasn't arrived yet, it should has been lost on its way to complete the setback with the W2 itself. Meanwhile I have decided sending the BPI-W2 back to the supplier, as no achievement has been made with the broken ethernet and it looks, that nobody interested from the Sinovoip side. Thus I shall not be able dumping mtd. The hardware components are good for different applications, but the absence of drivers and kernel support makes it a handicap.

Out of curiosity I cloned the Andreas Färber's repo branch rtd1295-next and looked into the kernel configs. There isn't a lot about the rtd1296 inside. What I found : | | [*] Realtek Platforms | | <*> Realtek chip info (NEW) | | | | [*] Realtek SB2 (NEW) | | | | [*] Realtek SCPU Wrapper (NEW) | | | | [ ] Realtek power domains (NEW) | | SOC (System On Chip) specific Drivers ---> Nothing in this section. There is no dts tree for the W2 board, nor the drivers for the r8169 NIC. The only Realtek SOC support I found was : DTC arch/arm64/boot/dts/realtek/rtd1293-ds418j.dtb DTC arch/arm64/boot/dts/realtek/rtd1295-mele-v9.dtb DTC arch/arm64/boot/dts/realtek/rtd1295-probox2-ava.dtb DTC arch/arm64/boot/dts/realtek/rtd1295-xnano-x5.dtb DTC arch/arm64/boot/dts/realtek/rtd1295-zidoo-x9s.dtb DTC arch/arm64/boot/dts/realtek/rtd1296-ds418.dtb DTC arch/arm64/boot/dts/realtek/rtd1395-bpi-m4.dtb DTC arch/arm64/boot/dts/realtek/rtd1395-lionskin.dtb DTC arch/arm64/boot/dts/realtek/rtd1619-mjolnir.dtb Kernel builds successfully from this repository directly on the W2 @ 4.9.119-BPI-W2-Kernel, without any toolchain and rather quickly - in 21 minutes, with make ARCH=arm64 -j $(nproc). Anyway, it will be useless, taken the absence of essential drivers.

I can not but agree. I've tried several kernel branches for now: mainline, next, legacy BPI-SINOVOIP. In the absence of Realtek's support, accessibility to the board features is very poor. Even basic ethernet NIC's are not operational, even with the legacy BPI-SINOVOIP, which is supposed meeting this basic task. I do not even mention the video Mali T820 support, which is probably far from being thought of.

Does somebody know how to implement the following solution ? https://lkml.org/lkml/2019/7/7/39

I believe, this method will require an access through a serial console. I am waiting for the UART cable to get delivered. I shall try making more series of tests.

It was quite an upset discovering, that the 2nd ethernet port is left unsupported and disabled. The ethX signaling LEDs do no work either. Will the issue with proper ethX support be resolved to make the board functional? https://github.com/BPI-SINOVOIP/BPI-W2-bsp/issues/5 It has been constantly reported to BPi through different posts, but it seems, that no action is taken so far.

I am currently booting from SD card.

root@bpi-iot-ros-ai:~# ls -al /dev/mtd0 crw------- 1 root root 90, 0 Dec 21 21:09 /dev/mtd0 root@bpi-iot-ros-ai:~# dd if=/dev/mtd0 of=dump.dd doesn't complete. root@bpi-iot-ros-ai:~# journalctl -f shows a lot of Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 17 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 8 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 11 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 12 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 11 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 14 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 16 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 18 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] sb2 get int 0x00000002 from SB2_INV_INTSTAT Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 8 kernel messages Dec 21 21:42:49 bpi-iot-ros-ai kernel: [RTK_SB2_DBG] Invalid access issued by SCPU Dec 21 21:42:49 bpi-iot-ros-ai systemd-journald[1956]: Missed 14 kernel messages root@bpi-iot-ros-ai:~# ls -al /root/dump.dd -rw-r--r-- 1 root root 0 Dec 21 21:42 /root/dump.dd

It's quite a long list : root@bpi-iot-ros-ai:~# ls -al /dev |less total 4 drwxr-xr-x 15 root root 14560 Dec 21 12:39 . drwxr-xr-x 23 root root 4096 Dec 21 13:52 .. crw------- 1 root root 10, 55 Dec 21 12:39 ashmem crw------- 1 root root 10, 235 Dec 21 12:39 autofs crw------- 1 root root 10, 54 Dec 21 12:39 binder drwxr-xr-x 2 root root 700 Dec 21 12:38 block crw-rw---- 1 root disk 10, 234 Dec 21 12:39 btrfs-control drwxr-xr-x 3 root root 60 Jan 1 1970 bus crw------- 1 root root 246, 0 Dec 21 12:39 cec-0 drwxr-xr-x 2 root root 13920 Dec 21 12:39 char crw------- 1 root root 10, 59 Dec 21 12:39 chip crw------- 1 root root 5, 1 Dec 21 12:39 console lrwxrwxrwx 1 root root 11 Dec 21 12:38 core -> /proc/kcore crw------- 1 root root 10, 52 Dec 21 12:39 cpu_dma_latency crw------- 1 root root 10, 203 Dec 21 12:39 cuse drwxr-xr-x 7 root root 140 Dec 21 12:38 disk crw-rw-rw- 1 root root 10, 56 Dec 21 12:39 dptx crw-rw---- 1 root video 29, 0 Dec 21 12:39 fb0 lrwxrwxrwx 1 root root 13 Dec 21 12:38 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Dec 21 12:39 full crw-rw-rw- 1 root root 10, 229 Dec 21 12:49 fuse crw------- 1 root root 254, 0 Dec 21 12:39 gpiochip0 crw------- 1 root root 254, 1 Dec 21 12:39 gpiochip1 drwxr-xr-x 2 root root 60 Dec 21 12:39 graphics crw-rw-rw- 1 root root 10, 57 Dec 21 12:39 hdmitx crw------- 1 root root 245, 0 Dec 21 12:39 hidraw0 crw------- 1 root root 245, 1 Dec 21 12:39 hidraw1 drwxr-xr-x 2 root root 0 Dec 21 12:38 hugepages crw------- 1 root root 10, 183 Dec 21 12:39 hwrng crw------- 1 root root 89, 0 Dec 21 12:39 i2c-0 crw------- 1 root root 89, 1 Dec 21 12:39 i2c-1 crw------- 1 root root 89, 2 Dec 21 12:39 i2c-2 crw------- 1 root root 89, 3 Dec 21 12:39 i2c-3 crw------- 1 root root 89, 4 Dec 21 12:39 i2c-4 crw------- 1 root root 89, 5 Dec 21 12:39 i2c-5 lrwxrwxrwx 1 root root 12 Dec 21 12:38 initctl -> /run/initctl drwxr-xr-x 4 root root 180 Dec 21 12:39 input crw-rw---- 1 root video 10, 61 Dec 21 12:39 ion crw------- 1 root root 10, 107 Dec 21 12:39 jpu crw-r--r-- 1 root root 1, 11 Dec 21 12:39 kmsg lrwxrwxrwx 1 root root 28 Dec 21 12:38 log -> /run/systemd/journal/dev-log crw-rw---- 1 root disk 10, 237 Dec 21 12:49 loop-control brw-rw---- 1 root disk 7, 0 Dec 21 12:39 loop0 brw-rw---- 1 root disk 7, 1 Dec 21 12:39 loop1 brw-rw---- 1 root disk 7, 2 Dec 21 12:39 loop2 brw-rw---- 1 root disk 7, 3 Dec 21 12:39 loop3 brw-rw---- 1 root disk 7, 4 Dec 21 12:39 loop4 brw-rw---- 1 root disk 7, 5 Dec 21 12:39 loop5 brw-rw---- 1 root disk 7, 6 Dec 21 12:39 loop6 brw-rw---- 1 root disk 7, 7 Dec 21 12:39 loop7 crw------- 1 root root 10, 47 Dec 21 12:39 mali0 drwxr-xr-x 2 root root 60 Jan 1 1970 mapper crw------- 1 root root 249, 0 Dec 21 12:39 mcp_core crw------- 1 root root 10, 49 Dec 21 12:39 memory_bandwidth brw-rw---- 1 root disk 179, 32 Dec 21 12:39 mmcblk0 brw-rw---- 1 root disk 179, 33 Dec 21 12:39 mmcblk0p1 brw-rw---- 1 root disk 179, 34 Dec 21 12:39 mmcblk0p2 brw-rw---- 1 root disk 179, 0 Dec 21 12:39 mmcblk1 brw-rw---- 1 root disk 179, 8 Dec 21 12:39 mmcblk1boot0 brw-rw---- 1 root disk 179, 16 Dec 21 12:39 mmcblk1boot1 brw-rw---- 1 root disk 179, 1 Dec 21 12:39 mmcblk1p1 brw-rw---- 1 root disk 179, 24 Dec 21 12:39 mmcblk1rpmb drwxrwxrwt 2 root root 40 Jan 1 1970 mqueue crw------- 1 root root 90, 0 Dec 21 12:39 mtd0 crw------- 1 root root 90, 1 Dec 21 12:39 mtd0ro drwxr-xr-x 2 root root 60 Jan 1 1970 net crw------- 1 root root 10, 51 Dec 21 12:39 network_latency crw------- 1 root root 10, 50 Dec 21 12:39 network_throughput crw-rw-rw- 1 root root 1, 3 Dec 21 12:39 null crw-r----- 1 root kmem 1, 4 Dec 21 12:39 port crw------- 1 root root 108, 0 Dec 21 12:39 ppp crw------- 1 root root 10, 1 Dec 21 12:39 psaux crw-rw-rw- 1 root tty 5, 2 Dec 21 18:15 ptmx drwxr-xr-x 2 root root 0 Dec 21 12:38 pts crw------- 1 root root 2, 176 Dec 21 12:39 ptya0 crw------- 1 root root 2, 177 Dec 21 12:39 ptya1 .... crw------- 1 root root 2, 174 Dec 21 12:39 ptyze crw------- 1 root root 2, 175 Dec 21 12:39 ptyzf brw-rw---- 1 root disk 1, 0 Dec 21 12:39 ram0 brw-rw---- 1 root disk 1, 1 Dec 21 12:39 ram1 brw-rw---- 1 root disk 1, 10 Dec 21 12:39 ram10 brw-rw---- 1 root disk 1, 11 Dec 21 12:39 ram11 brw-rw---- 1 root disk 1, 12 Dec 21 12:39 ram12 brw-rw---- 1 root disk 1, 13 Dec 21 12:39 ram13 brw-rw---- 1 root disk 1, 14 Dec 21 12:39 ram14 brw-rw---- 1 root disk 1, 15 Dec 21 12:39 ram15 brw-rw---- 1 root disk 1, 2 Dec 21 12:39 ram2 brw-rw---- 1 root disk 1, 3 Dec 21 12:39 ram3 brw-rw---- 1 root disk 1, 4 Dec 21 12:39 ram4 brw-rw---- 1 root disk 1, 5 Dec 21 12:39 ram5 brw-rw---- 1 root disk 1, 6 Dec 21 12:39 ram6 brw-rw---- 1 root disk 1, 7 Dec 21 12:39 ram7 brw-rw---- 1 root disk 1, 8 Dec 21 12:39 ram8 brw-rw---- 1 root disk 1, 9 Dec 21 12:39 ram9 crw-rw-rw- 1 root root 1, 8 Dec 21 12:39 random crw-rw-r-- 1 root netdev 10, 62 Dec 21 12:39 rfkill crw-rw-rw- 1 root root 240, 0 Dec 21 12:39 rpc0 crw-rw-rw- 1 root root 240, 1 Dec 21 12:39 rpc1 crw-rw-rw- 1 root root 240, 100 Dec 21 12:39 rpc100 crw-rw-rw- 1 root root 240, 2 Dec 21 12:39 rpc2 crw-rw-rw- 1 root root 240, 3 Dec 21 12:39 rpc3 crw-rw-rw- 1 root root 240, 4 Dec 21 12:39 rpc4 crw-rw-rw- 1 root root 240, 5 Dec 21 12:39 rpc5 crw-rw-rw- 1 root root 240, 6 Dec 21 12:39 rpc6 crw-rw-rw- 1 root root 240, 7 Dec 21 12:39 rpc7 lrwxrwxrwx 1 root root 4 Dec 21 12:39 rtc -> rtc0 crw------- 1 root root 253, 0 Dec 21 12:39 rtc0 crw------- 1 root root 10, 60 Dec 21 12:39 rtk_lockapi drwxrwxrwt 2 root root 40 Dec 21 12:38 shm drwxr-xr-x 3 root root 200 Dec 21 12:39 snd lrwxrwxrwx 1 root root 15 Dec 21 12:38 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Dec 21 12:38 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Dec 21 12:38 stdout -> /proc/self/fd/1 crw------- 1 root root 10, 58 Dec 21 12:39 sw_sync crw-rw-rw- 1 root tty 5, 0 Dec 21 12:39 tty crw--w---- 1 root tty 4, 0 Dec 21 12:39 tty0 crw--w---- 1 root tty 4, 1 Dec 21 12:50 tty1 ... crw------- 1 root root 3, 175 Dec 21 12:39 ttyzf crw------- 1 root root 10, 48 Dec 21 12:39 uctrl crw------- 1 root root 10, 239 Dec 21 12:39 uhid crw------- 1 root root 10, 223 Dec 21 12:39 uinput crw------- 1 root root 248, 250 Dec 21 12:39 uio250 crw------- 1 root root 248, 251 Dec 21 12:39 uio251 crw------- 1 root root 248, 252 Dec 21 12:39 uio252 crw------- 1 root root 248, 253 Dec 21 12:39 uio253 crw-rw-rw- 1 root root 1, 9 Dec 21 12:39 urandom crw------- 1 root root 247, 0 Dec 21 12:39 usbmon0 crw------- 1 root root 247, 1 Dec 21 12:39 usbmon1 crw------- 1 root root 247, 2 Dec 21 12:39 usbmon2 crw------- 1 root root 247, 3 Dec 21 12:39 usbmon3 crw------- 1 root root 247, 4 Dec 21 12:39 usbmon4 crw------- 1 root root 247, 5 Dec 21 12:39 usbmon5 crw------- 1 root root 247, 6 Dec 21 12:39 usbmon6 crw-rw---- 1 root tty 7, 0 Dec 21 12:39 vcs crw-rw---- 1 root tty 7, 1 Dec 21 12:39 vcs1 ... crw-rw---- 1 root tty 7, 134 Dec 21 12:39 vcsa6 crw------- 1 root root 234, 50 Dec 21 12:39 venus_ir crw------- 1 root root 10, 63 Dec 21 12:39 vga_arbiter crw------- 1 root root 10, 110 Dec 21 12:39 vpu crw------- 1 root root 10, 130 Dec 21 12:39 watchdog crw------- 1 root root 251, 0 Dec 21 12:39 watchdog0 crw------- 1 root root 10, 53 Dec 21 12:39 xt_qtaguid crw-rw-rw- 1 root root 1, 5 Dec 21 12:39 zero brw-rw---- 1 root disk 253, 0 Dec 21 12:39 zram0

Having received the board, I've tried the available image from the BPi downloads. Interestingly enough, that the image 2019-08-02-debian-10-buster-lite-preview-aarch64-bpi-w2-m4-sd-emmc.img provides an Armbian distro, although built by somebody else : root@bpi-iot-ros-ai:~# dmesg |less [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 4.9.119-BPI-W2-Kernel (root@bpi-iot-ros-ai) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #4 SMP PREEMPT Mon Apr 29 15:13:32 CST 2019 [ 0.000000] Boot CPU: AArch64 Processor [410fd034] Welcome to Debian Buster with Armbian Linux 4.9.119-BPI-W2-Kernel root@bpi-iot-ros-ai:~# cat /proc/version Linux version 4.9.119-BPI-W2-Kernel (root@bpi-iot-ros-ai) (gcc version 7.3.1 20180425 [linaro-7.3-2018.05 revision d29120a424ecfbc167ef90065c0eeb7f91977701] (Linaro GCC 7.3-2018.05) ) #4 SMP PREEMPT Mon Apr 29 15:13:32 CST 2019 I haven't yet exhaustively tested it. The two immediately visible problems, which have been discovered so far, are with the built-in video system and the 2nd ethernet port. The video on console in a text mode is generated with significant delay and distortions as well as the terminal needs to be evoked with CTL+F2 to be available after the boot. It seems, that Mali T820 driver is missing. I understand, that mainstream Kernel 5.2 already includes its support, but this image is built with a legacy 4.9 kernel. The 2nd ethernet port doesn't bring up, which is quite a deception. Besides, the network signaling LEDs on the 1st ethernet port are always shut off, while only yellow led blinks on the 2nd port, but it remains in a down state all the time. The /boot partition is located on a separate FAT volume, as I understand, that the implemented U-boot is a proprietary one from Realtek. I've also discovered from this forum, that other similar boards exist with the Realtek SOC (although it is a different 1295) and some efforts are made to mainline kernel migration: Is there any progress in the mainline kernel migration for this board?

I've just get W2 delivered. How could the SPI dump be made? Being a couple of years Armbian's follower, I share the interest implementing the mainstream kernel build for W2 and ultimately put an Armbian on it.

Hello, I've managed building uboot and kernel from the sources, which gives me : root@06e63d8891fd:/Source/BPI-W2-bsp/SD/bpi-w2# ls -alh total 109M drwxr-xr-x 5 root root 4.0K Nov 24 22:08 . drwxr-xr-x 3 root root 4.0K Nov 24 22:07 .. drwxr-xr-x 2 root root 4.0K Nov 24 22:07 100MB -rw-r--r-- 1 root root 76M Nov 24 22:08 4.9.119-BPI-W2-Kernel.tgz -rw-r--r-- 1 root root 266 Nov 24 22:08 BOOTLOADER-bpi-w2.tgz drwxr-xr-x 3 root root 4.0K Nov 24 22:07 BPI-BOOT -rw-r--r-- 1 root root 18M Nov 24 22:07 BPI-BOOT-bpi-w2.tgz drwxr-xr-x 4 root root 4.0K Nov 24 22:07 BPI-ROOT -rw-r--r-- 1 root root 15M Nov 24 22:08 linux-headers-4.9.119-BPI-W2-Kernel.tgz root@06e63d8891fd:/Source/BPI-W2-bsp/SD/bpi-w2# ls -alh BPI-BOOT/bananapi/bpi-w2/linux/ total 32M drwxr-xr-x 2 root root 4.0K Nov 24 22:07 . drwxr-xr-x 3 root root 4.0K Nov 24 22:07 .. -rw-r--r-- 1 root root 3.8M Nov 24 20:13 bluecore.audio -rw-r--r-- 1 root root 48K Nov 24 20:49 rtd-1296-bananapi-w2-2GB.dtb -rw-r--r-- 1 root root 1.3K Nov 24 20:13 uEnv.txt -rwxr-xr-x 1 root root 22M Nov 24 21:32 uImage -rw-r--r-- 1 root root 7.2M Nov 24 20:13 uInitrd What's the next procedure to try them as part of the Armbian distro ? Despite many concerns regarding the SBC manufacturer, there is probably a potential with this board, which would be interesting to discover. If some guidelines are given, I can try and share the experience.

I am upgrading the OrangePI plus bought in 2016 to Buster and moved the system to eMMC with "armbian-config". / _ \| _ \(_) _ | | | | |_) | |_| |_ | |_| | __/| |_ _| \___/|_| |_| |_| Welcome to Debian Buster with Armbian Linux 4.19.57-sunxi Does armbian-config update the u-boot firmware? Or should I run it manually as described? $ sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk1 bs=1024 seek=8 How could the current firmware version be checked and backed up before updating it ? Where is an appropriate latest firmware file? Is the one below good for OrangePI? https://d-i.debian.org/daily-images/armhf/daily/u-boot/orangepi_plus/ [ ] orangepi_plus.sdcard.img.gz 2019-07-12 00:11 245K [ ] u-boot-sunxi-with-spl.bin.gz 2019-07-12 00:11 245K Incidentally, is the boot from SATA supported on OrangePI plus ?

I can't mount the eMMC : root@orangepiplus:~# lsblk -o model,name,type,fstype,size,label MODEL NAME TYPE FSTYPE SIZE LABEL mmcblk1boot0 disk 4M mmcblk1boot1 disk 4M mmcblk0 disk 60G └─mmcblk0p1 part ext4 60G <- @ SDCard mmcblk1 disk 7.3G └─mmcblk1p1 part ext4 7.2G <- eMM #mount /dev/mmcblk1p1 /mnt/mountpoint [34182.366277] EXT4-fs (mmcblk1p1): couldn't mount RDWR because of unsupported optional features (400) Is there a reason for that?

I followed the Rasbian Jessy to Stretch migration link (above). It doesn't allow for the kernel upgrade. The migration ends up with the root@orangepiplus:/# uname -a Linux orangepiplus 3.4.113-sun8i #8 SMP PREEMPT Sat Feb 9 20:17:57 CET 2019 armv7l GNU/Linux The fresh installation from scratch allows for the Linux 4.19.20. Thus at least the kernel upgrade procedure needs to be thought of. The other question for Orange PI : how could different boot device be chosen? How could I choose booting from Nand or SD Card of USB?

Hello, I have the same issue : my SD Card died all of a sudden, leaving me an option to update the Debian distribution. The previous installed one was: ARMBIAN Debian GNU/Linux 8 (jessie) 3.4.113-sun8i It is still left in a Nand and could be booted off it. What is the procedure to update the whole system to Debian Stretch? Thank you.

I added this setting to give (boot log): [ 0.000000] Kernel command line: console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=cdf86afe-e235-4b45-a02b-7954f2bbdaaa rootfstype=ext4 rootwait loglevel=1 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u mtdparts=spi0.0:1536k(uboot),64k(uboot-environment),-(reserved) rootdelay=3 [ 0.000000] Memory: 2026008K/2097152K available (10684K kernel code, 730K rwdata, 3244K rodata, 640K init, 502K bss, 54760K reserved, 16384K cma-reserved) However, the board didn't show up after "shutdown -r now". It was still necessary unplugging it and power up back for it to reboot. "rootwait" and "rootdelay=3", are those rootargs not conflicting and self excluding?

Good suggestion. Which file the boot arguments are set? I looked into armbianEnv.txt, but "rootwait" is not there. Otherwise, are you suggesting changing the variable in the bootloader ? I looked into the current U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian last Marvell>> printenv the rootarg is not set either. Could you be more specific?

Have you seen this https://github.com/armbian/build/commit/9c7ce48f2b6cef71080ee6f04cca6f521f98df96 ? Yes. I understood it. It goes in line with the changes made to boot.cmd You should still replace the wrong boot.scr on your download page. Have you tried # cat /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table ? I have this table in place : root@karmae:~# cat /sys/devices/system/cpu/cpu1/cpufreq/stats/trans_table From : To : 200000 250000 500000 1000000 200000: 0 1 2 0 250000: 1 0 1846 3910 500000: 2 1822 0 85 1000000: 0 3934 61 0 What should be necessary to check more ? globalscale technologies turns a deaf year to such claims. They consider their boards to fully meet the specifications. I could have sent the board at my own risk for the cost of 50 USD, which is not worth it. globalscale technologies doesn't even guaranty the replacement. Once, the RMA guy told, that they may check it, but since then he doesn't even dare responding. It is really not up to the mark handling so badly technical claims for their boards.

I've recompiled boot.scr from boot.cmd and, this time, the boot with the U-Boot 2017.03-armada-18.09.1-ga92bd86-armbian (Sep 05 2018 - 21:49:34 +0200) went without a hitch. Still the absence of CPU scaling persists. I shall observe how stable the board is with this U-Boot. The previous configuration resulted in hazardous reboots each couple of days.