martinayotte

According to that, you seems to have crossed SDA/SCK ...

I've done a commit in Armbian patches so that in future nightly builds the UART3 will be disabled by default and people wishing to use UART3 will need to load "uart3" overlay... https://github.com/armbian/build/commit/eb61dc0fe4db222df8ebac4ac1f8086ac3e67f3a

Looking at the sources, it seems to be enabled in the Main DT... So, you will need to decompile it, edit to change the uart3 node status from "okay" to "disabled", then recompile it. Since NanoPi-Neo is a H3, use the DT compiler from http://ftp.debian.org/debian/pool/main/d/device-tree-compiler/device-tree-compiler_1.4.7-3_armhf.deb

Oh ! This means you should not load the "uart3" since it is using the same pins as SPI ...

Did you tried "spi-spidev" only without "spi-add-cs1" and "spi-jedec-nor" ? What "dmesg | grep spi" is reporting ?

No ! The 'm' means 'module' ...

This sector 0 dump is coming from which image ? Maybe it should be written on the eMMC first ? This didn't work either ... Maybe also @balbes150 has some clues ?

To my knowledge, providing multiple "skip" arguments will only override each others and only the last one will be taken into account ...

I was preparing myself to struggle again with this issue ... But in the meantime, upgrading first all my RK3399 to 5.1.y, I've discovered that we have random eth0 MAC on few ones (I didn't check this in past months, since I mostly running all those on WiFi) : The discovery is that random MAC are present on v2019.04, but not in Ayufan's v2017.09. It was missing the ethernet0 alias, I've added it, but it didn't fixed the issue... The sad thing is that is on the wrong side of the fence : if the issue were in v2017.09, I wouldn't bother trying to fix it, but it is under v2019.04 ... I don't have any other idea for now ...

Comparing that to original write_uboot_platform() doesn't show some relevant change since only "bs=512 skip=1" is repeated twice ... We don't have "u-boot.bin.sd.bin" installed in /usr/lib/linux-u-boot-dev-nanopik2-s905_5.89_arm64/, there is only "u-boot.bin" and "u-boot.img", but I will look again in the build tree itself. I've also search in https://wiki.odroid.com/odroid-c2/software/building_u-boot , and they say for eMMC "sudo dd if=u-boot.bin of=/dev/mmcblk0 bs=512 seek=97", followed by "You must use the u-boot.bin binary under the folder, “u-boot/sd_fuse/u-boot.bin” . This is confusing me since Armbian build process is different ...

Just as a side note : you can also do the reverse, installing Ubuntu as you main OS and use VirtualBox to run Win10 inside a VM ...

No, disabling the eMMC on Rock64 isn't done thru DTB, but by shorting 2 pins jumper nearby the recovery button. EDIT : Oh ! I´ve just saw that you were talking about "a55 tv box.Rk3328", not your Rock64 ... So, my answer isn't related ...

You can see at the end of boot.cmd these instructions : # Recompile with: # mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

It is almost unbelievable ! It must be something specific to your network/router ! I've more than 10 OPis of different flavors, some NanoPis annd someother boards, they are able to reach each others ...

I've received my eMMC module yesterday ! Although @Igor committed this https://github.com/armbian/build/commit/7c73d7a61f0724f9a4465604ffb683bcd18a997d , it doesn't work out-of-the-box ... I've tried to manually place u-boot on eMMC using : dd if=/usr/lib/linux-u-boot-dev-nanopik2-s905_5.89_arm64/u-boot.bin of=/dev/mmcblk0 bs=1 count=442 conv=fsync dd if=/usr/lib/linux-u-boot-dev-nanopik2-s905_5.89_arm64/u-boot.bin of=/dev/mmcblk0 bs=512 skip=1 seek=1 conv=fsync But still no luck ! We need to investigate more ... Maybe our Meson64 expert here, @TonyMac32 could give us some help here ?