martinayotte

BTW, since this behaviour was found when I stopped using Stretch and using Buster, I may look at this issue again with Bulleye instead of Buster...

That was true six months ago, but there recent months, that is not true any more : I'm using "old school" /etc/network/interfaces since years, in the old days, if "old school" was used, NetworkManager simply ignored those devices, but since few months, probably when I switched from Stretch to newer dist, it is still trying to use the devices although defined in /etc/network/interfaces. To make "old school" working again, I've to do specifically "systemctl disable NetworkManager". So, my conclusion is that a bug has been introduced in NetworkManager ...

I've not done the commit yet, "time is the missing ingredient" ... But feel free to compile above DT overlay !

I've done a small SPI module attached on my Pine64, and I'm using a user-patch for U-Boot Pine64 DTS, along with an DT overlay for the kernel that provide MTD partition, which I can then push the U-Boot image on the SPI flash.

You need to change "verbosity=1" to "verbosity=7" in /boot/armbianEnv.txt, then kernel will be more verbose ...

After having built a kernel with the above patch to get half-duplex emulation, you also need to initialize the port with proper flags, with either "-i" or not, depending of ActiveHigh or ActiveLow output.

After transferring Armbian from SDCard to eMMC, next time you wish to boot SDCard, it will be less painful, no more needs of TP50265 ... Simply stop U-Boot with spacebar, then you can select SD with "setenv devnum 1" followed by "run mmc_boot". You need to switch firmware to another version : mv /lib/firmware/brcm/brcmfmac4356-sdio.bin /lib/firmware/brcm/brcmfmac4356-sdio.bin-ORIG mv /lib/firmware/brcm/brcmfmac4356-sdio.txt /lib/firmware/brcm/brcmfmac4356-sdio.txt-ORIG cp /lib/firmware/brcm/brcmfmac4356-sdio-nanopi-m4v2.bin /lib/firmware/brcm/brcmfmac4356-sdio.bin cp /lib/firmware/brcm/brcmfmac4356-sdio-nanopi-m4v2.txt /lib/firmware/brcm/brcmfmac4356-sdio.txt

You should change the "verbosity=1" to "verbosity=7" in /boot/armbianEnv.txt

Are you sure your short is correctly done ?

As I said, after doing "git clone", simply commenting the whole detection code from line 328 to 449, and then hardcode the OdroidN2 definition mentioned above, then compile the library ...

Here it is : https://mega.nz/file/fS5XhTQI#_7bZ_jw4XdqFWc_9x6wAI1s07sEnKoamqOBqhMf_hc8

I've decided to take a look at the WiringPi issue, and I figured out that "cat /proc/cpuinfo" doesn't give same output under Armbian that WiringPi is expecting with HardKernel version. But I figured out to comment out all the Hardware/Revision parsing of /proc/cpuinfo, and hard coded the the result as a OdroidN2 board, and the rest of the library is working fine. I didn't the same with WiringPi python wrapper too ... This is the recipe : Comment out those lines : https://github.com/hardkernel/wiringPi/blob/master/wiringPi/wiringPi.c#L328-L449 and hardcode the following, just after the commenting : libwiring.model = MODEL_ODROID_N2; libwiring.maker = MAKER_AMLOGIC; libwiring.mem = 4; libwiring.rev = 1; EDIT: Now, I will go back to gpio sysfs issue, but there is less hurry ...

This U-Boot seems to be pretty old ... The one I built recently is booting fine 5.6.2 from eMMC : DDR Version 1.24 20191016 In soft reset SRX Channel 0: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB Channel 1: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB 256B stride ch 0 ddrconfig = 0x101, ddrsize = 0x20 ch 1 ddrconfig = 0x101, ddrsize = 0x20 pmugrf_os_reg[2] = 0x32817281, stride = 0x9 OUT Boot1: 2019-03-14, version: 1.19 CPUId = 0x0 ChipType = 0x10, 307 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 SdmmcInit=0 1 StorageInit ok = 67497 SecureMode = 0 SecureInit read PBA: 0x4 SecureInit read PBA: 0x404 SecureInit read PBA: 0x804 SecureInit read PBA: 0xc04 SecureInit read PBA: 0x1004 SecureInit read PBA: 0x1404 SecureInit read PBA: 0x1804 SecureInit read PBA: 0x1c04 SecureInit ret = 0, SecureMode = 0 atags_set_bootdev: ret:(0) GPT 0x3380ec0 signature is wrong recovery gpt... GPT 0x3380ec0 signature is wrong recovery gpt fail! LoadTrust Addr:0x4000 No find bl30.bin No find bl32.bin Load uboot, ReadLba = 2000 Load OK, addr=0x200000, size=0xa5d94 RunBL31 0x40000 NOTICE: BL31: v1.3(debug):42583b6 NOTICE: BL31: Built : 07:55:13, Oct 15 2019 NOTICE: BL31: Rockchip release version: v1.1 INFO: GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3 INFO: Using opteed sec cpu_context! INFO: boot cpu mask: 0 INFO: plat_rockchip_pmu_init(1190): pd status 3e INFO: BL31: Initializing runtime services WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK ERROR: Error initializing runtime service opteed_fast INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2020.01-armbian (Apr 06 2020 - 16:14:46 -0400) Model: Orange Pi RK3399 Board DRAM: 2 GiB PMIC: RK808 MMC: dwmmc@fe310000: 2, dwmmc@fe320000: 1, sdhci@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial@ff1a0000 Out: serial@ff1a0000 Err: serial@ff1a0000 Model: Orange Pi RK3399 Board rockchip_dnl_key_pressed: adc_channel_single_shot fail! Net: eth0: ethernet@fe300000 Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 2940 bytes read in 19 ms (150.4 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 0 209 bytes read in 16 ms (12.7 KiB/s) 7746799 bytes read in 755 ms (9.8 MiB/s) 22217216 bytes read in 2122 ms (10 MiB/s) 74021 bytes read in 38 ms (1.9 MiB/s) 1266 bytes read in 33 ms (37.1 KiB/s) Applying kernel provided DT overlay rockchip-spi-spidev.dtbo 2698 bytes read in 33 ms (79.1 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 39000000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 7746735 Bytes = 7.4 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to 7d7be000, end 7df214af ... OK Loading Device Tree to 000000007d743000, end 000000007d7bdfff ... OK Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 5.6.2-rockchip64 (root@giroles-hpel8300) (gcc version 8.3.0 (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36))) #trunk SMP PREEMPT Mon Apr 6 16:26:34 EDT 2020 [ 0.000000] Machine model: Orange Pi RK3399 Board ...

Right ! I've corrected my reply, (jumper was in the case of RockPro64, TP50265 test point in case of OrangePi-RK3399) ...

Again, some "file not found" ... Could be that you have an incompatible U-Boot present in the eMMC which prevent reading properly the SDCard images. Make sure that you have TP50265 shorted to GND to disable the eMMC completely, and then it will boot using the U-Boot present on the SDCard.

It seems to be clear that DTB is missing ...

/etc/default/armbian-ramlog

Is that SDCard is formatted EXT4, because if it is a FAT partition, you can't have multiple owners ...

Yes, and that is true also for sunxi-dev ...

Of course, I've shown the source located in kernel tree, not a decompiled version ... I've also said something wrong : I've a local patch not included in Armbian tree : You can use that patch if you are doing you own build ... ... or you can tweak your decompile DT to make sure that USB nodes are matching that, or use my own DTB attached, of course after backing up yours first ... sun8i-h3-orangepi-lite.dtb

I think the 2 last parts, 74LS151 and 74LS157, should be HC not LS, since HC is 3.3V compatible but not LS which are 5V only ...

You should have it working already since DTS sources contains the following : &reg_usb0_vbus { gpio = <&r_pio 0 2 GPIO_ACTIVE_HIGH>; /* PL2 */ status = "okay"; }; &usb_otg { dr_mode = "host"; status = "okay"; }; &usbphy { /* USB VBUS is always on */ usb0_id_det-gpios = <&pio 6 12 GPIO_ACTIVE_HIGH>; /* PG12 */ usb0_vbus-supply = <&reg_usb0_vbus>; status = "okay"; }; Maybe it is a cable problem ? I'm using a microusb-2-usb-otg such as this one : https://www.ebay.ca/itm/Micro-USB-Cable-Male-Host-to-USB-Female-OTG-Adapter-Android-Tablet-Phone-PDA-PC/122327249468 And it is working as is under Armbian sunxi-dev 5.6.2 ...

To load the overlay ? Yes, it requires to be loaded at every boot, for example thru calls from /etc/rc.local, or using useroverlays variable in /boot/armbianEnv.txt. I don't know, I've not used the WiringPi mentioned above, but you can try using sysfs gpio. EDIT: Something looks a bit fishy : I've not been able to make gpio sysfs working ...

There is not other solution to wait receiving this serial dongle.

What change did you do ? Changing VCC pins ? This maybe means that this board react strangely if powered from 5V ...