Image | NanoPi NEO2 Black

mrbluecoat commented 4 years ago

ADMIN EDIT

Latest beta image: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2Black-ARMv8-Buster.7z

Creating an image request

Formal device information

Device name | NanoPi NEO2 Black
Official product URL | https://www.friendlyarm.com/index.php?route=product/product&product_id=273
GitHub resource URL (if available) |
Image download URL | http://download.friendlyarm.com/nanopineo2black

Is the SBC officially supported by the Debian installer?

If not, is a reliable 3rd party Debian image available for this SBC?

https://www.armbian.com/nanopi-neo-2-black/

If not, are there install instructions for Debian available?

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_NEO2_Black

Vote for this image on FeatHub: https://feathub.com/MichaIng/DietPi/

MichaIng commented 4 years ago

@mrbluecoat Many thanks for your request.

Since SoC/CPU and RAM-type did not change, I think the regular NEO2 images should work just fine?

mrbluecoat commented 4 years ago

My only unknown is the new eMMC flash module but if that's handled already by the OS we should be good. I have mine on order and I'll test with the existing NEO2 image when it arrives.

MichaIng commented 4 years ago

@mrbluecoat It should be possible to flash the DietPi SDcard image directly to the eMMC, e.g. via adapter. Then this should be handled correctly. But I am not 100% sure, a simple test will show.

mrbluecoat commented 4 years ago

Here's a quick update:

My NanoPi NEO2 Black unit managed to ship out of China before the virus lockdown. (My heart goes out to our FriendlyArm friends in Shenzen!)

The unit works fine with a micro-SD card:

CPU Performance: Duration = 24.54 seconds (lower is faster)
CPU Temp: Idle = 36'c | Full load = 50'c
RootFS: Write = 3 MiB/s | Read = 14 MiB/s
RAM: Write = 479 MiB/s | Read = 659 MiB/s

Using the https://www.friendlyarm.com/index.php?route=product/product&product_id=209 8 GB eMMC module and FriendlyArm eMMC-to-microSD adapter, I was able to load the DietPi image no problem with Balena Etcher. However, I never got an SSH prompt (waited 10 minutes). I'll dig out my UART adapter later this week to probe further...

mrbluecoat commented 4 years ago

P.S. It works fine when I boot from the eMMC module when connected to the micro-SD adapter in the micro-SD slot so I know the eMMC module is operational.

MichaIng commented 4 years ago

@mrbluecoat I'll create a new NanoPi NEO2 image (Armbian Buster-based) today to test: #2979 SSH is still not working OOTB? I changed a lot in DietPi-PREP in combination with Armbian images, while creating a bunch of new images the last weeks, hence probably the version from dev branch fixes things.

MichaIng commented 4 years ago

New image ready, you might want to test it on NEO2 Black: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2-ARMv8-Buster.7z

mrbluecoat commented 4 years ago

Hmm.. no luck. Same behavior. I'll look into it over the weekend.

MichaIng commented 4 years ago

@mrbluecoat I am currently going through the script from Armbian which can be used to install the current system, booted from SDcard, to eMMC: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install On first view yesterday on the read, I couldn't see any change to system/configs done that would indicate that direct flash to eMMC is not possible 🤔. Buuuut, probably the NEO2 bootloader/kernel is shipped without eMMC support, since the non-Black version does not have one.

You could try it with the Armbian NEO2 Black image (Buster server): https://www.armbian.com/nanopi-neo-2-black/#kernels-archive-all I'll further did into this, since eMMC boot with our new Rock64 image seems to fail similarly. In the past there was a separate vfat boot partition required, but that's definitely not the case anymore. ext4 single partition is generally possible for eMMC as well 🤔.

mrbluecoat commented 4 years ago

Okay, here's the latest results:

The official FriendlyArm Xenial image based on UbuntuCore and Linux Kernel-4.14 works out of the box (booting directly from the eMMC drive).

In preparation to test the Armbian and DietPi images, their UART was a pain to figure out because after a lot of trial and error I discovered their UART1 pins are useless. The only working UART option is UART0 ("Debug UART" on their schematic) which has no 2pin-pads to connect to (lame!) and the ground/5v pins are on the other side of the board. I had some parts lying around to get it to work but people should be aware that UART is not an option out-of-the-box for the Black version (unlike its Blue sibling).

With all that said, I tried the Armbian NEO2 Black buster image you recommended and it briefly starts but then hangs:

Starting kernel ...

Loading, please wait...
Starting version 241
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 
/dev/mmcblk0p1: recovering journal
/dev/mmcblk0p1: clean, 37426/94848 files, 320911/378880 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

Welcome to Debian GNU/Linux 10 (buster)!

[  OK  ] Started Forward Password R…uests to Wall Directory Watch.
[  OK  ] Listening on Journal Socket (/dev/log).
[  OK  ] Reached target Swap.
[  OK  ] Listening on Syslog Socket.
[  OK  ] Reached target System Time Synchronized.
[  OK  ] Listening on udev Kernel Socket.
[  OK  ] Created slice User and Session Slice.
[  OK  ] Reached target Slices.
[  OK  ] Listening on Journal Audit Socket.
[  OK  ] Started Dispatch Password …ts to Console Directory Watch.
[  OK  ] Reached target Local Encrypted Volumes.
[  OK  ] Reached target Paths.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Listening on udev Control Socket.
[  OK  ] Reached target Remote File Systems.
[  OK  ] Listening on initctl Compatibility Named Pipe.
[  OK  ] Listening on fsck to fsckd communication Socket.
[  OK  ] Set up automount Arbitrary…s File System Automount Point.
[  OK  ] Listening on Journal Socket.
         Starting Load Kernel Modules...
         Mounting Huge Pages File System...
         Starting Set the console keyboard layout...
         Mounting Kernel Debug File System...
         Starting Journal Service...
         Starting Remount Root and Kernel File Systems...
         Starting Restore / save the current clock...
         Mounting POSIX Message Queue File System...
         Starting udev Coldplug all Devices...
         Starting Nameserver information manager...
         Starting Create list of re…odes for the current kernel...
[  OK  ] Started Load Kernel Modules.
[  OK  ] Mounted Huge Pages File System.
[  OK  ] Mounted Kernel Debug File System.
[  OK  ] Started Remount Root and Kernel File Systems.
[  OK  ] Started Restore / save the current clock.
[  OK  ] Mounted POSIX Message Queue File System.
[  OK  ] Started Journal Service.
[  OK  ] Started Create list of req… nodes for the current kernel.
[  OK  ] Started Nameserver information manager.
         Starting Flush Journal to Persistent Storage...
         Starting Create System Users...
         Starting Load/Save Random Seed...
         Mounting Kernel Configuration File System...
         Starting Apply Kernel Variables...
[  OK  ] Mounted Kernel Configuration File System.
[  OK  ] Started udev Coldplug all Devices.
[  OK  ] Started Load/Save Random Seed.
[  OK  ] Started Apply Kernel Variables.
[  OK  ] Started Set the console keyboard layout.
         Starting Helper to synchronize boot up for ifupdown...
[  OK  ] Started Flush Journal to Persistent Storage.
[  OK  ] Started Helper to synchronize boot up for ifupdown.
[  OK  ] Started Create System Users.
         Starting Create Static Device Nodes in /dev...
[  OK  ] Started Create Static Device Nodes in /dev.
[  OK  ] Reached target Local File Systems (Pre).
         Mounting /tmp...
         Starting udev Kernel Device Manager...
[  OK  ] Mounted /tmp.
[  OK  ] Reached target Local File Systems.
         Starting Create Volatile Files and Directories...
         Starting Armbian ZRAM config...
         Starting Set console font and keymap...
         Starting Raise network interfaces...
[  OK  ] Started Set console font and keymap.
[  OK  ] Started Create Volatile Files and Directories.
[  OK  ] Started Entropy daemon using the HAVEGE algorithm.
         Starting Update UTMP about System Boot/Shutdown...
[  OK  ] Started udev Kernel Device Manager.
[  OK  ] Started Update UTMP about System Boot/Shutdown.
{{ hangs }}

I'll try your nand-sata-install method next.

mrbluecoat commented 4 years ago

I was able to load the Armbian NEO2 Black image onto the SD card, use the nand-sata-install method to move it to the eMMC chip, remove the SD card and boot exclusively from the eMMC chip, then upgrade to DietPi using your PREP_SYSTEM_FOR_DIETPI.sh script, then image it using your dietpi-imager. I then loaded it onto the eMMC chip and it doesn't boot. Argh! UART doesn't even connect. The image works fine booting from the SD card, though. Too tired at this point...I'll try again next weekend.

MichaIng commented 4 years ago

@mrbluecoat So the Armbian NEO2 Black image finally booted? It might just take a while at start. I often saw the one or the other "start job is pending..." message when booting their images.

After using nand-sata-install, were you able to boot + reboot from eMMC, before running PREP_SYSTEM_FOR_DIETPI.sh on it? And were you able as well boot + reboot from that eMMC after running PREP_SYSTEM_FOR_DIETPI.sh before running DietPi-Imager?

Could you paste the following after running nand-sata-install and booting from eMMC:

df -T
fdisk -l
cat /etc/fstab /boot/{armbianEnv.txt,boot.cmd}

From what I found, the partitioning and filesystem should actually not change at all, but maybe I've overseen something:

main function runs: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L728
Menu option 2 to fully install the image to eMMC: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L629
emmccheck checks for any non-rootfs mmcblk* device, hence when booted from SDcard, this can only match the internal eMMC: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L48
eMMC is unmounted, formatted and Armbian system copied: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L660-L661
For format, first choice is ext4: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L429
In case of ext4, a single partition + file system is created: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L497-L501
The first sector for first partition btw does not depend on target drive but only on SoC, for non RockChip SoCs, its 8192 like on the SDcard images: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L37
... okay now I found something: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install#L271

/boot/boot.cmd contains:

setenv rootdev "/dev/mmcblk0p1"

which points to the SDcard. /boot/armbianEnv.txt contains:

rootdev=UUID=f362c325-4f84-479c-9494-4de8bcff221a

which points to whichever partition has this UUID, I am not sure whether this is correctly read from u-boot or not, even that it would not have any reason if not 🤔. However nand-sata-install changes this entry accordingly in the boot.cmd. What I see now as well is that at least kernel output on boot is done to serial console only, but not to tty1 (attached monitor)? This does not effect the final login prompt appearing on monitor, but for debugging, having boot messages on monitor as well of course helps.

Last step of the script is installing u-boot to the eMMC, via dd of the two files in /usr/lib/linux-u-boot-current-nanopineo2*/ to 8k and 40k block of the eMMC. This matches the sizes of the file, since the first is exactly 32k large, both together less than 1M, hence they fit right before the partition starts at 4M. However since the SDcard boots, this must exist on the image already, hence must be present on eMMC when flashing directly. Since there is no adjustment done afterwards to the uboot image, and there are no alternative files, this should not be a reason for eMMC to not boot.

I am now adjusting the entries in the image and verify its partition layout...

MichaIng commented 4 years ago

Uploaded new image to test with eMMC: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2-ARMv8-Buster_eMMC.7z At least the additional boot/kernel output on screen could help already.

mrbluecoat commented 4 years ago

No luck with that image, but here's the UART output in case it helps:

NanoPi NEO2 v1.1 detected
Net:   phy interface7
eth0: ethernet@1c30000
MMC: no card present
MMC: no card present
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1d000: USB EHCI 1.00
Bus usb@1c1d400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1d000 for devices... 1 USB Device(s) found
scanning bus usb@1c1d400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
MMC Device 1 not found
no mmc device at slot 1
MMC: no card present

Device 0: unknown device
ethernet@1c30000 Waiting for PHY auto negotiation to complete....... done
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 43
DHCP client bound to address 192.168.31.15 (676 ms)
*** Warning: no boot file name; using 'C0A81F0F.img'
Using ethernet@1c30000 device
TFTP from server 192.168.31.1; our IP address is 192.168.31.15
Filename 'C0A81F0F.img'.
Load address: 0x42000000
Loading: T T T T T T T T T T 
Retry count exceeded; starting again

I'll get the other data you requested soon.

mrbluecoat commented 4 years ago

Not sure why but the Armbian image never worked with the UART or eMMC connected. I would always hang on either Started Entropy daemon using the HAVEGE algorithm or Starting Update UTMP about System Boot/Shutdown. The only way I got it to boot was to use the micro-SD with the eMMC not connected and using the micro-USB power adapter plugged into the wall. Once it booted and I could access it via SSH I would shutdown, attach the eMMC module, and then power on again. Could be user error or impatience...not sure.

After using the nand-sata-install method to transfer from the micro-SD to the eMMC and shutdown when prompted, I was able to remove the micro-SD and boot successfully with just the eMMC attached. Here's the output you requested:

df -T

Filesystem     Type     1K-blocks    Used Available Use% Mounted on
udev           devtmpfs    436400       0    436400   0% /dev
tmpfs          tmpfs       101320    2924     98396   3% /run
/dev/mmcblk2p1 ext4       7370336 1267372   5708856  19% /
tmpfs          tmpfs       506596       0    506596   0% /dev/shm
tmpfs          tmpfs         5120       4      5116   1% /run/lock
tmpfs          tmpfs       506596       0    506596   0% /sys/fs/cgroup
tmpfs          tmpfs       506596       4    506592   1% /tmp
/dev/zram0     ext4         49584    1288     44712   3% /var/log
tmpfs          tmpfs       101316       0    101316   0% /run/user/0

fdisk -l

Disk /dev/mmcblk2: 7.3 GiB, 7818182656 bytes, 15269888 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xae9258ca

Device         Boot Start      End  Sectors  Size Id Type
/dev/mmcblk2p1       8192 15117183 15108992  7.2G 83 Linux

Disk /dev/zram0: 50 MiB, 52428800 bytes, 12800 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

Disk /dev/zram1: 494.7 MiB, 518758400 bytes, 126650 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes

cat /etc/fstab /boot/{armbianEnv.txt,boot.cmd}

# <file system>                                 <mount point>   <type>  <options>                                                       <dump>  <pass>
tmpfs                                           /tmp            tmpfs   defaults,nosuid                                                 0       0
UUID=d3e8166e-fbf5-4954-aff5-13311d4c98cc       /               ext4    defaults,noatime,nodiratime,commit=600,errors=remount-ro,x-gvfs-hide    0    1
verbosity=1
console=serial
overlay_prefix=sun50i-h5
overlays=usbhost1 usbhost2
rootdev=UUID=d3e8166e-fbf5-4954-aff5-13311d4c98cc
rootfstype=ext4
usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u
# DO NOT EDIT THIS FILE
#
# Please edit /boot/armbianEnv.txt to set supported parameters
#

# default values
setenv load_addr "0x44000000"
setenv rootdev "/dev/mmcblk0p1"
setenv verbosity "1"
setenv rootfstype "ext4"
setenv console "both"
setenv docker_optimizations "on"

# Print boot source
itest.b *0x10028 == 0x00 && echo "U-boot loaded from SD"
itest.b *0x10028 == 0x02 && echo "U-boot loaded from eMMC or secondary SD"
itest.b *0x10028 == 0x03 && echo "U-boot loaded from SPI"

echo "Boot script loaded from ${devtype}"

if test -e ${devtype} ${devnum} ${prefix}armbianEnv.txt; then
        load ${devtype} ${devnum} ${load_addr} ${prefix}armbianEnv.txt
        env import -t ${load_addr} ${filesize}
fi

if test "${console}" = "display" || test "${console}" = "both"; then setenv consoleargs "console=ttyS0,115200 console=tty1"; fi
if test "${console}" = "serial"; then setenv consoleargs "console=ttyS0,115200"; fi

# get PARTUUID of first partition on SD/eMMC it was loaded from
# mmc 0 is always mapped to device u-boot (2016.09+) was loaded from
if test "${devtype}" = "mmc"; then part uuid mmc 0:1 partuuid; fi

setenv bootargs "root=${rootdev} rootwait rootfstype=${rootfstype} ${consoleargs} consoleblank=0 loglevel=${verbosity} ubootpart=${partuuid} usb-storage.quirks=${usbstoragequirks} ${extraargs} ${extraboardargs}"

if test "${docker_optimizations}" = "on"; then setenv bootargs "${bootargs} cgroup_enable=memory swapaccount=1"; fi

load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
fdt addr ${fdt_addr_r}
fdt resize 65536
for overlay_file in ${overlays}; do
        if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-${overlay_file}.dtbo; then
                echo "Applying kernel provided DT overlay ${overlay_prefix}-${overlay_file}.dtbo"
                fdt apply ${load_addr} || setenv overlay_error "true"
        fi
done
for overlay_file in ${user_overlays}; do
        if load ${devtype} ${devnum} ${load_addr} ${prefix}overlay-user/${overlay_file}.dtbo; then
                echo "Applying user provided DT overlay ${overlay_file}.dtbo"
                fdt apply ${load_addr} || setenv overlay_error "true"
        fi
done
if test "${overlay_error}" = "true"; then
        echo "Error applying DT overlays, restoring original DT"
        load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}dtb/${fdtfile}
else
        if load ${devtype} ${devnum} ${load_addr} ${prefix}dtb/allwinner/overlay/${overlay_prefix}-fixup.scr; then
                echo "Applying kernel provided DT fixup script (${overlay_prefix}-fixup.scr)"
                source ${load_addr}
        fi
        if test -e ${devtype} ${devnum} ${prefix}fixup.scr; then
                load ${devtype} ${devnum} ${load_addr} ${prefix}fixup.scr
                echo "Applying user provided fixup script (fixup.scr)"
                source ${load_addr}
        fi
fi

load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd
load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image

booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

# Recompile with:
# mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

I was able to reboot successfully. No difference in output than listed above.

mrbluecoat commented 4 years ago

I was also able to boot and reboot from the eMMC after running PREP_SYSTEM_FOR_DIETPI.sh but before running DietPi-Imager. DietPi setup proceeded as normal. System seems operational so it looks like DietPi-Imager might be the culprit. I can try manually imaging and resizing if you'd like or I can repeat my earlier attempt going directly to DietPi-Imager after prep.

mrbluecoat commented 4 years ago

Here's the eMMC benchmark for comparison:

CPU Performance: Duration = 15.85 seconds (lower is faster)
CPU Temp: Idle = 48'c | Full load = 76'c
RootFS: Write = 36 MiB/s | Read = 42 MiB/s
RAM: Write = 466 MiB/s | Read = 736 MiB/s

MichaIng commented 4 years ago

@mrbluecoat Many thanks for testing.

I am dumb.. NEO2 has no video output, hence kernel/boot messages on tty1 have no reason 😄.

So partition setup is as expected, matching the case when you directly flash the image to eMMC. fstab entry is a bid different, but nothing related. What I find interesting is that setenv rootdev "/dev/mmcblk0p1" is still present in boot.cmd. Ah yeah now I see here the entry is only altered if the old UUID is present, not in case of present /dev/mmcblk0p1 entry. So means armbianEnv.txt works as expected in overriding the boot.cmd defaults.

System seems operational so it looks like DietPi-Imager might be the culprit.

On the other hand, the Armbian image fails the same when flashing to eMMC directly, right? So it might be true that for some reason the bootloader must be written to eMMC manually.

Just for reference:

DIR=/usr/lib/linux-u-boot-current-nanopineo2_20.05.0-trunk.038_arm64
write_uboot_platform () 
{ 
    [[ -f $1/sunxi-spl.bin ]] && dd if=$1/sunxi-spl.bin of=$2 bs=8k seek=1 conv=fsync > /dev/null 2>&1;
    [[ -f $1/u-boot.itb ]] && dd if=$1/u-boot.itb of=$2 bs=8k seek=5 conv=fsync > /dev/null 2>&1 || true
}

This is what nand-sata-install calls, $1 is $DIR $2 is the eMMC device, hence /dev/mmcblk2.
This exactly matches these docs: https://linux-sunxi.org/Hwpack
- The blocks where this is written to seem different, but this is only due to bs=1024 vs bs=8k, hence both write it to exactly the same positions.
This must be present on the SDcard image as well, otherwise it should not be able to boot for the same reason. However I will now extract that exact parts from the image and see if what I get matches /usr/lib/linux-u-boot-current-nanopineo2_*/.

Device 0: unknown device ethernet@1c30000 Waiting for PHY auto negotiation to complete....... done BOOTP broadcast 1 BOOTP broadcast 2 Unhandled DHCP Option in OFFER/ACK: 43 Unhandled DHCP Option in OFFER/ACK: 43 DHCP client bound to address 192.168.31.15 (676 ms) *** Warning: no boot file name; using 'C0A81F0F.img' Using ethernet@1c30000 device TFTP from server 192.168.31.1; our IP address is 192.168.31.15 Filename 'C0A81F0F.img'. Load address: 0x42000000 Loading: T T T T T T T T T T Retry count exceeded; starting again

It seems it tries to perform a network boot which fails.

MMC: no card present MMC: no card present

Not sure if this means it cannot find a "valid" card in both, external SD slot and internal eMMC.

EDIT

I compared the related bits from our image file with the uboot files and they match 100%:

root@VM-Building:/tmp# losetup
NAME       SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE                               DIO LOG-SEC
/dev/loop0         0      0         0  0 /tmp/DietPi_NanoPiNEO2-ARMv8-Buster.img   0     512
root@VM-Building:/tmp# df /dev/loop0p1
Filesystem     1K-blocks   Used Available Use% Mounted on
/dev/loop0p1      471076 460828         0 100% /root/m
root@VM-Building:/tmp# dd if=/dev/loop0 of=sunxi-spl.bin bs=8k skip=1 count=4
4+0 records in
4+0 records out
32768 bytes (33 kB, 32 KiB) copied, 0.000822211 s, 39.9 MB/s
root@VM-Building:/tmp# dd if=/dev/loop0 of=u-boot.itb bs=8k skip=5 count=82
82+0 records in
82+0 records out
671744 bytes (672 kB, 656 KiB) copied, 0.00187748 s, 358 MB/s
root@VM-Building:/tmp# l /root/m/usr/lib/linux-u-boot-current-nanopineo2_20.02.0-rc1_arm64/
total 688
-rw-rw-r-- 1 root root  32768 Jan 25 19:42 sunxi-spl.bin
-rw-rw-r-- 1 root root 669000 Jan 25 19:42 u-boot.itb
root@VM-Building:/tmp# truncate -s 669000 u-boot.itb
root@VM-Building:/tmp# diff sunxi-spl.bin /root/m/usr/lib/linux-u-boot-current-nanopineo2_20.02.0-rc1_arm64/sunxi-spl.bin
root@VM-Building:/tmp# diff u-boot.itb /root/m/usr/lib/linux-u-boot-current-nanopineo2_20.02.0-rc1_arm64/u-boot.itb

truncate done because u-boot.itb size is no even multiplier of 8k blocks.
So the image file definitely has uboot files at correct positions.
The question is now if this is preserved on all kind of flashing.
Currently using dd to flash to external drive and check back, however since dd copies bit per bit, this cannot result in a difference, actually. @mrbluecoat which program did you use to flash the image to eMMC?

EDIT: Related bits still match 100%. when using dd to flash to external drive.

EDIT

I recognised that our image for some reason contains the PARTUUID in fstab instead of the UUID. This should only be the case on RPi and redoing the fstab cleaning resulted in UUID as expected. I'll have a look into this, if other images are affected as well. I am not sure if there is any issue with PARTUUID + eMMC, but I updated the NEO2 image to contain UUID: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2-ARMv8-Buster.7z The _eMMC has been removed since it did not contain any relevant change.

mrbluecoat commented 4 years ago

On the other hand, the Armbian image fails the same when flashing to eMMC directly, right?

I think with all my variations in testing I somehow missed testing the Armbian image with the wall adapter directly because I loaded the Armbian black image using Balena Etcher onto the eMMC and then plugged the unit into the wall and it booted just fine. My guess is the UART wasn't providing enough power because when I connected the UART RX/TX/Ground but used the wall adapter for power it booted fine:

U-Boot SPL 2019.10-armbian (Jan 25 2020 - 19:45:24 +0100)
DRAM: 1024 MiB
Trying to boot from MMC2
NOTICE:  BL31: v2.2(debug):b253407-dirty
NOTICE:  BL31: Built : 19:45:13, Jan 25 2020
NOTICE:  BL31: Detected Allwinner H5 SoC (1718)
NOTICE:  BL31: Found U-Boot DTB at 0x40923e8, model: FriendlyARM NanoPi NEO Core 2
INFO:    ARM GICv2 driver initialized
INFO:    Configuring SPC Controller
NOTICE:  PMIC: Assuming H5 reference regulator design
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9

U-Boot 2019.10-armbian (Jan 25 2020 - 19:45:24 +0100) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: FriendlyARM NanoPi NEO Core 2
DRAM:  1 GiB
MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from EXT4... MMC: no card present
In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr
3033 bytes read in 2 ms (1.4 MiB/s)
## Executing script at 4fc00000
U-boot loaded from eMMC or secondary SD
Boot script loaded from mmc
145 bytes read in 1 ms (141.6 KiB/s)
MMC: no card present
28028 bytes read in 3 ms (8.9 MiB/s)
504 bytes read in 2 ms (246.1 KiB/s)
Applying kernel provided DT overlay sun50i-h5-usbhost1.dtbo
504 bytes read in 2 ms (246.1 KiB/s)
Applying kernel provided DT overlay sun50i-h5-usbhost2.dtbo
4161 bytes read in 2 ms (2 MiB/s)
Applying kernel provided DT fixup script (sun50i-h5-fixup.scr)
## Executing script at 44000000
8762397 bytes read in 420 ms (19.9 MiB/s)
15687688 bytes read in 750 ms (19.9 MiB/s)
## Loading init Ramdisk from Legacy Image at 4fe00000 ...
   Image Name:   uInitrd
   Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
   Data Size:    8762333 Bytes = 8.4 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 4fa00000
   Booting using the fdt blob at 0x4fa00000
   Loading Ramdisk to 497a4000, end 49fff3dd ... OK
   Loading Device Tree to 0000000049734000, end 00000000497a3fff ... OK

Starting kernel ...

Loading, please wait...
Starting version 241
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems
done.
Begin: Will now check root file system ... fsck from util-linux 2.33.1
[/sbin/fsck.ext4 (1) -- /dev/mmcblk2p1] fsck.ext4 -a -C0 /dev/mmcblk2p1 
/dev/mmcblk2p1: clean, 37420/94848 files, 320907/378880 blocks
done.
done.
Begin: Running /scripts/local-bottom ... done.
Begin: Running /scripts/init-bottom ... done.

Welcome to Debian GNU/Linux 10 (buster)!

[  OK  ] Reached target Swap.
[  OK  ] Created slice system-serial\x2dgetty.slice.
[  OK  ] Reached target Remote File Systems.
...
[  OK  ] Stopped OpenBSD Secure Shell server.
         Starting OpenBSD Secure Shell server...
[  OK  ] Started OpenBSD Secure Shell server.

Armbian 20.02.0-rc1 Buster ttyS0 

nanopineo2black login:

Using the same UART method, still no luck with your latest image:

U-Boot SPL 2019.10-armbian (Jan 25 2020 - 19:42:47 +0100)
DRAM: 1024 MiB
Trying to boot from MMC2
NOTICE:  BL31: v2.2(debug):b253407-dirty
NOTICE:  BL31: Built : 19:42:36, Jan 25 2020
NOTICE:  BL31: Detected Allwinner H5 SoC (1718)
NOTICE:  BL31: Found U-Boot DTB at 0x4094d90, model: FriendlyARM NanoPi NEO 2
INFO:    ARM GICv2 driver initialized
INFO:    Configuring SPC Controller
NOTICE:  PMIC: Assuming H5 reference regulator design
INFO:    BL31: Platform setup done
INFO:    BL31: Initializing runtime services
INFO:    BL31: cortex_a53: CPU workaround for 855873 was applied
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x4a000000
INFO:    SPSR = 0x3c9

U-Boot 2019.10-armbian (Jan 25 2020 - 19:42:47 +0100) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: FriendlyARM NanoPi NEO 2
DRAM:  1 GiB
MMC:   mmc@1c0f000: 0
Loading Environment from EXT4... MMC: no card present
In:    serial
Out:   serial
Err:   serial
NanoPi NEO2 v1.1 detected
Net:   phy interface7
eth0: ethernet@1c30000
MMC: no card present
MMC: no card present
starting USB...
Bus usb@1c1a000: USB EHCI 1.00
Bus usb@1c1a400: USB OHCI 1.0
Bus usb@1c1d000: USB EHCI 1.00
Bus usb@1c1d400: USB OHCI 1.0
scanning bus usb@1c1a000 for devices... 1 USB Device(s) found
scanning bus usb@1c1a400 for devices... 1 USB Device(s) found
scanning bus usb@1c1d000 for devices... 1 USB Device(s) found
scanning bus usb@1c1d400 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
Autoboot in 1 seconds, press <Space> to stop
MMC Device 1 not found
no mmc device at slot 1
MMC: no card present

Device 0: unknown device
ethernet@1c30000 Waiting for PHY auto negotiation to complete....... done
BOOTP broadcast 1
BOOTP broadcast 2
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 43
DHCP client bound to address 192.168.31.16 (730 ms)
*** Warning: no boot file name; using 'C0A81F10.img'
Using ethernet@1c30000 device
TFTP from server 192.168.31.1; our IP address is 192.168.31.16
Filename 'C0A81F10.img'.
Load address: 0x42000000
Loading: T T T T T T T T T T 
Retry count exceeded; starting again
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/01-02-01-9c-19-ce-99
Using ethernet@1c30000 device
TFTP from server 192.168.31.1; our IP address is 192.168.31.16
Filename 'pxelinux.cfg/01-02-01-9c-19-ce-99'.
Load address: 0x4fd00000
Loading: T T

I'll use my method from yesterday to get a working DietPi instance on the eMMC and then use dd to image and test.

mrbluecoat commented 4 years ago

I swear this eMMC chip is going to give me brain damage.. After trying your image I loaded Armbian back on, removed the UART, and plugged in the wall adapter just like I did less than an hour ago. It didn't boot. I unplugged and replugged in and it didn't boot. I unplugged, waited about 10 minutes, and then plugged in and it booted. Not sure if the chip is flaky or some residual electrons in the circuitry are causing the issue. I'll keep testing...

MichaIng commented 4 years ago

Hmm strange, probably the PSU does not provide stable voltage when eMMC and UART are both attached?

mrbluecoat commented 4 years ago

I used the process above to install DietPi on to the eMMC chip and then shut down. I waited a while and then plugged it into my computer using the micro-SD adapter. Using dcfldd (just a fancy dd) I was able to to image the eMMC chip. I then used Balena Etcher to write that image back on to the eMMC chip, connect it to the NEO2 Black unit, plugged it into the wall power outlet, and...it booted! Next I'll start optimizing the image and investigate DietPi-Imager.

mrbluecoat commented 4 years ago

Here's the result of my manual resizing: https://drive.google.com/file/d/1jTeHccp83_uaKSG8RoHV-P2GjeLdV85w/view?usp=sharing

It only works on the eMMC chip (not micro-SD) but I was able to consistently boot, shutdown, and reboot. I hope it helps with your troubleshooting.

mrbluecoat commented 4 years ago

No luck with DietPi-Imager with eMMC chip attached to micro-SD adapter. I get this error: umount: /dev/sdc1: not mounted When I try a local image I get ./dietpi-imager: line 113: /DietPi/dietpi/dietpi-explorer: Permission denied even though I'm running it as root.

MichaIng commented 4 years ago

@mrbluecoat Many thanks for all your testing.

I think the NEO2 non-black bootloader simply does not support eMMC, since non-black NEO2 does not have one. I totally forgot that as possible simple reason on the way. Looks quite clear:

Armbian NEO2 Black image

MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
Loading Environment from EXT4... MMC: no card present
In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Autoboot in 1 seconds, press <Space> to stop
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
Found U-Boot script /boot/boot.scr

Detects two MMC devices

Its "scans" mmc 1:1 and finds the bootloader config etc

DietPi NEO2 non-Black image

MMC:   mmc@1c0f000: 0
Loading Environment from EXT4... MMC: no card present
In:    serial
Out:   serial
Err:   serial
NanoPi NEO2 v1.1 detected
Net:   phy interface7
eth0: ethernet@1c30000
MMC: no card present
MMC: no card present
starting USB...

Detects only one MMC device
After not finding bootloader config, it tries USB and TFTP network boot, which of course fails

I'll redo a NEO2 Black image later.

Regarding your issue with DietPi-Imager, this is very strange indeed, since it works perfectly fine for all the new images I created. You used the most current dev version? https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-imager

The only unmount it does is: findmnt $i &> /dev/null && { umount -R $i || Exit_On_Fail; } Means it loops through all target drive mounts and sub-mounts and IF IT FINDS THEM (for this they must be mounted), it unmounts them. So the "not mounted" is actually not possible. However you could test it: findmnt /dev/sdc1 This must not print something without error code, if device is not currently mounted.
DietPi-Explorer is called like this: /DietPi/dietpi/dietpi-explorer 1 /root You could try it manually. Strange is that this is only done when choosing "Image" as source, while the above unmount is only done when choosing "Drive" as source. So both should not occur during the same run.

mrbluecoat commented 4 years ago

So both should not occur during the same run.

I should clarify that those errors were on separate runs

Removing -R from umount -R $i fixed the issue for me with imaging the eMMC chip.

Here's the result of that run: https://drive.google.com/open?id=1VQ5Dl8YJpYln49IhNpPKVrTPuNVPtN3t

Running chmod +x /DietPi/dietpi/dietpi-explorer fixed the issue with imaging the *.img file on local disk.

Here's the result of that run: https://drive.google.com/open?id=1aWUJjWZVhXeUHNpqXLzejmFbGytqHm1_

Interesting that the second method (local drive *.img file) produces a file that's is so much smaller than the first method (eMMC drive) even though they're both based on the same image.

MichaIng commented 4 years ago

@mrbluecoat Okay makes sense with the two separate run. umount -R should assure that all mounts below the parent eMMC mount are unmounted as well. E.g. if there was some /mnt/emmc/boot mount for a separate boot partition (not the case with Armbian images), it would be unmounted first. It should however not fail if there is no mount below that. Could be tested, probably with real eMMC devices there is something different. There is the -q option which suppresses the "not mounted" error message, but I am not sure if it as well exits without related error code then.

... ah I think I know why... If /etc/fstab contains an entry for the eMMC mount, then I think findmnt lists this, even if the drive is not currently mounted. Probably this was the case? In this case we need to use df instead to check only for actual mounted drives... although file systems from completely different drives could be mounted below eMMC mount point as well... I'll do some tests how to handle this best :wink:.

Interesting about the missing execute permissions. /DietPi/dietpi/dietpi-explorer and all other contained scripts are given execute permissions by dietpi-update automatically. Do all other scripts have them? ls -Al /DietPi/dietpi/

The image size depends a bid on how the data is layed out on the disk/img. There are usually holes when removing files e.g. and resize2fs simply shrinks the file system from the back til first present data, hence the gaps are included in the resulting image size. Sadly I don't know any method to move all data to the beginning of the partition/filesystem and close all gaps by this, via command line tools. Only solution would be to copy/move all files away, shrink the partition to the size that is able to hold the apparent file sizes and copy the files back into the partition. But it's kinda overhead for a moreless small benefit, hence I didn't add this to the imager script.

mrbluecoat commented 4 years ago

No worries on resize2fs - your script is way faster, more elegant, and produces smaller images than my manual method.

TBH I just did a git clone of your repo and made sure it was in the root DietPi directory. I'm sure there's a manual out there for properly setting up my system to create images that I was too lazy to read...

I'll await your final image for testing.

MichaIng commented 4 years ago

@mrbluecoat

TBH I just did a git clone of your repo and made sure it was in the root DietPi directory.

Ah, okay that's a good reason, fully functional DietPi requires some more install/setup steps for everything to work. However for quick access to some of the scripts of course it's sufficient 😉.

I'll await your final image for testing.

Will be done this evening.

MichaIng commented 4 years ago

@mrbluecoat NEO2 Black image ready for testing: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2Black-ARMv8-Buster.7z

mrbluecoat commented 4 years ago

Initial attempt with eMMC - it didn't boot (waited 5 minutes and no blinking green LED)
I unplugged unit from wall, counted to 10, plugged it back in and within a minute I got the blinking green LED and it ultimately booted and I was able to configure it as normal
I did a reboot which worked fine
I did a shutdown now which worked fine
I loaded the image onto a micro-SD card and it booted fine
I repeated the imaging of the eMMC and it booted fine on first try so I think my first experience was a fluke and your image is good to go. Thanks!

MichaIng commented 4 years ago

@mrbluecoat That is fantastic, many thanks for testing. I'll upload it into a separate NEO2 Black download file then, especially marked as eMMC-compatible.

MichaIng commented 4 years ago

Redid the NEO2 Black image with newest DietPi version and some minor image-wise fixes, e.g. forced 1.0.0.1 DNS nameserver: https://dietpi.com/downloads/images/DietPi_NanoPiNEO2Black-ARMv8-Buster.7z

Would be great if anyone could verify that it first boot setup works as fine as with the last one, then I'll move it to stable.

mrbluecoat commented 4 years ago

No luck with the eMMC chip but microSD was fine (both boot and reboot):

Benchmarks completed (Toshiba Exceria Pro M401):
│  - CPU Performance : Duration = 15.24 seconds (lower is faster)
│  - CPU Temp        : Idle = 47'c | Full load = 83'c
│  - RootFS          : Write = 20 MiB/s | Read = 21 MiB/s
│  - RAM             : Write = 475 MiB/s | Read = 759 MiB/s

I wouldn't spend more time on it, though, since FriendlyElec discontinued it :(

I have an Orange Pi One Plus on the way and we'll see if it gets comparable results...

MichaIng commented 4 years ago

No luck with the eMMC chip

The steps you did above did not work this time?

I unplugged unit from wall, counted to 10, plugged it back in and within a minute I got the blinking green LED and it ultimately booted and I was able to configure it as normal

It seams it gets a higher clock rate with the NEO2 Black image compared to the results you got with the regular NEO2 image: https://github.com/MichaIng/DietPi/issues/3333#issuecomment-582477795 CPU significantly faster but as well significantly hotter. The cpu command should provide the clock rates.

Probably the higher clock rate + power consumption also makes it a bid unstable with current PSU.

mrbluecoat commented 4 years ago

Re: eMMC, nope. Unplugged, waited 10 seconds. Unplugged, waited an hour. Reflashed using Etcher. Tried a number of ways.

MichaIng commented 4 years ago

If you find time for testing, does the current Armbian image work on eMMC? https://dl.armbian.com/nanopineo2black/archive/Armbian_20.02.1_Nanopineo2black_buster_current_5.4.20.7z

Would be good to have some other NEO2 Black user to check whether it is hardware-specific or not. Would be just great to have one reliably booting Buster image, as well from eMMC since that is the significant difference between Black and non-Black version.

mrbluecoat commented 4 years ago

Armbian loaded fine on eMMC:

Welcome to Armbian buster with Linux 5.4.20-sunxi64

System load:   0.71 0.28 0.10   Up time:       1 min
Memory usage:  10 % of 989MB    IP:            192.168.31.10
CPU temp:      32°C           
Usage of /:    17% of 7.0G

That said, I had to flash twice with Etcher because it failed the first time so my guess is the eMMC chip is flaky. I'll let others verify the image for more reliable results. Great work, by the way - I love DietPi!

mrbluecoat commented 4 years ago

P.S. Your earlier sha1sum 7dfc415bf9212de27078e8e0946243ff47e7e346 DietPi_NanoPiNEO2Black-ARMv8-Buster.img image works reliably every time for me.

MichaIng commented 4 years ago

apt update && apt full-upgrade + reboot does not break it, right? Yeah, I'll recheck the u-boot but I think finally we need to get a second test result before investing too much time 😉.

Many thanks in any case for all your testing effort 👍.

Sudrien commented 4 years ago

After reading https://github.com/armbian/build/issues/1838 - And having FriendlyWRT blow away my setup notes - I tried the Neo2 Black beta image on the NanoPi R1S-H5

Basic setup worked.

I've run into three caveats for the setup (a tunneling router) I'm trying to replace so far;

ip addr shows eth0, eth1, and wlan0 - but dietpi-config doesn't have any configuration for the 2nd ethernet interface.
dietpi-config has nothing about Wireless Access Point configuration.

Both of these probably merit separate issues.

It DOES run hot, as the armbian thread mentions. Currently mine is doing nothing but an SSH connection and sitting at 73C.

MichaIng commented 4 years ago

Jep, multiple/flexible network adapter setup is planned for next release (probably one more, as its a huge task), until then the second adapter should be setup manually via e.g. /etc/network/interfaces.d/eth1. Since this is not possible now we didn't release NanoPi R1/R2.

A wireless access point can be setup by installing WiFi Hotspot via dietpi-software, and can then be configure via dietpi-config. Making this available as config option right from the start is as well planned.

It DOES run hot, as the armbian thread mentions. Currently mine is doing nothing but an SSH connection and sitting at 73C.

I know that Armbian kernels have highest possible clocks enabled. Does CPU scheduling not working to clock it down in idle? I.e. what does the following show in your case (here example on RPi2):

2020-07-15 10:56:06 root@micha:/tmp# cat /sys/devices/system/cpu/cpufreq/policy0/affected_cpus
0 1 2 3 # means all 4 CPU are scheduled with this policy
2020-07-15 10:56:42 root@micha:/tmp# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_min_freq
150000 # hard limit for lowest frequency
2020-07-15 10:56:58 root@micha:/tmp# cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq
900000 # hard limit for highest frequency
2020-07-15 10:57:04 root@micha:/tmp# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
schedutil # governor
2020-07-15 10:57:16 root@micha:/tmp# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
150000 # governor limit for lowest frequency
2020-07-15 10:57:32 root@micha:/tmp# cat /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
900000 # governor limit for highest frequency
2020-07-15 10:57:41 root@micha:/tmp# cat /sys/devices/system/cpu/cpufreq/policy0/stats/time_in_state
150000 344461446 # Time in lowest frequency state
900000 30847066 # Time in highest frequency state

So my RPi2 has only two states (I always wanted to push the request for multiple states to RPi devs...) applied for all 4 CPUs together (single policy) and resides in only ~8% of the time at max 900 Mhz, else at very low 150 Mhz.

I would expect that CPUfreq-based scheduling works on Armbian kernel as well in general, so that temperatures are a question of related settings. Since even the upper clock can be limited via scaling_max_freq, it is reasonable to boot the board with highest possible (still stable) clocks and by this avoid any needs for boot/kernel config changes and reboots.

Sudrien commented 4 years ago

ls /sys/devices/system/cpu/cpufreq
[yeah, it's empty?]
root@yellowbox:~# ls /sys/devices/system/cpu
cpu0  cpu1  cpu2  cpu3  cpufreq  cpuidle  hotplug  isolated  kernel_max  modalias  offline  online  possible  power  present  smt  uevent  vulnerabilities
root@yellowbox:~# cat /sys/devices/system/cpu/cpuidle/current_driver 
none
root@yellowbox:~# cat /sys/devices/system/cpu/cpuidle/current_governor_ro 
menu
root@yellowbox:~# ls /sys/devices/system/cpu/cpu0/power/*
/sys/devices/system/cpu/cpu0/power/autosuspend_delay_ms  /sys/devices/system/cpu/cpu0/power/pm_qos_resume_latency_us  /sys/devices/system/cpu/cpu0/power/runtime_status
/sys/devices/system/cpu/cpu0/power/control               /sys/devices/system/cpu/cpu0/power/runtime_active_time       /sys/devices/system/cpu/cpu0/power/runtime_suspended_time
root@yellowbox:~# cat /sys/devices/system/cpu/cpu0/power/*
cat: /sys/devices/system/cpu/cpu0/power/autosuspend_delay_ms: Input/output error
auto
0
0
unsupported
0

While booting, it is apparently still quite messed up.

MichaIng commented 4 years ago

Does this exist or give an output?

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

In case not:

lsmod
modinfo acpi-cpufreq

Sudrien commented 4 years ago

I does not. And,

root@yellowbox:~# modinfo acpi-cpufreq
modinfo: ERROR: Module acpi-cpufreq not found.

MichaIng commented 4 years ago

Okay, no cpufreq scaling driver is active. Probably it is since the NanoPi NEO2 Black image does not fit 100% for R1S, not sure.

Just to be sure, but I guess this does not exist on (most) SBCs: ls -al /lib/modules/$(uname -r)/kernel/drivers/cpufreq I just checked cpufrequtils but the modules they are looking for are for x86 or PowerPC only with acpi-cpufreq as fallback. On most SBCs, the drive is built into the kernel (not a module) anyway.

However to assure that I did not oversee something, try:

apt install cpufrequtils
systemctl restart loadcpufreq
systemctl restart cpufrequtils

And see if any of the above files appeared now. But I don't think so and you should then purge the package again which otherwise does a lot of obsolete loading, checking, scraping at boot: apt purge cpufrequtils

Sudrien commented 4 years ago

root@yellowbox:~# ls -al /lib/modules/$(uname -r)/kernel/drivers/cpufreq
total 44
drwxr-xr-x  2 root root  4096 Jul 15 04:53 .
drwxr-xr-x 64 root root  4096 Jul 15 04:52 ..
-rw-r--r--  1 root root 17185 Jun  2 16:20 cpufreq-dt.ko
-rw-r--r--  1 root root 12961 Jun  2 16:20 scpi-cpufreq.ko

cpufrequtils got me nothing new, after service and system restart.

And just to confirm,

root@yellowbox:~# uname -r
5.4.43-sunxi64

MichaIng commented 4 years ago

Okay there we have two CPUFreq drivers, one more specific and one more generic from what I read, both for certain ARM chips. If you're prepared to get a system crash, you can try them:

modprobe scpi-cpufreq

If it does not throw an error, recheck if the sysfs files are available now, check temperatures and clock: cpu If it does not work, throws an error or such:

rmmod scpi-cpufreq
modprobe cpufreq-dt

Same procedure.

I totally forgot to check dmesg for any related driver load attempts: dmesg | grep cpufreq

Sudrien commented 4 years ago

From a clean boot:

root@yellowbox:~# dmesg | grep cpu
[    0.143741] cpuidle: using governor menu
[    0.162562] cryptd: max_cpu_qlen set to 1000
[    2.880643] ledtrig-cpu: registered to indicate activity on CPUs

root@yellowbox:~# lsmod | grep freq
cpufreq_dt             20480  0

root@yellowbox:~# ls -al /lib/modules/$(uname -r)/kernel/drivers/cpufreq
total 44
drwxr-xr-x  2 root root  4096 Jul 15 04:53 .
drwxr-xr-x 64 root root  4096 Jul 15 04:52 ..
-rw-r--r--  1 root root 17185 Jun  2 16:20 cpufreq-dt.ko
-rw-r--r--  1 root root 12961 Jun  2 16:20 scpi-cpufreq.ko

So cpufreq-dt is already loaded, with no obvious dmesg entries

scpi-cpufreq does load, no crashes, but only effects lsmod output, not dmesg, or anything in /sys/ that's been previously noted.

MichaIng commented 4 years ago

Okay, I think we have to accept that currently the Armbian H5 kernel (with the available device trees) does not fully support this device. Probably they publish a separate image in the future, we can keep an eye on it. From our end it also has not highest priority until our network setup scripts do not support router/multi-Ethernet systems in a reasonable way. However keep up investigation and research for this. Probably it makes sense to track this in a separate image request?

MichaIng / DietPi