@lex

Can you upload the SDK to GoogleDrive?

Waiting for the IPX RF cable to arrive and see how it will boost the signal, 12dBi Omni wifi antenna, $6.75 (now $7.50) on AliExpress. Will try to reproduce same test and post here.

Here is my take on this matter: Pine64 and BPI-M64 img does not boot on NanoPi A64 NanoPi A64 img boots on Pine64 and BPI-M64, but not without tons of errors Judging by the OPI Win Wifi/BT (AP6212) the best candidate to work out-of-the-box is BPI-M64 img. Better wait for the OPI Win Plus Plus (eMMC) and try mainline 4.10...

With power management off: ubuntu@bpi-m64:~$ sudo iwconfig wlan0 power off iwconfig: from board: other direction:

Results for bpi-m64, same condition: iwconfig: From the board: Other direction:

The results for nanoPi A64 - RTL8189es, 1 meter away, just the monitor between board and the wireless router/modem. tested against my ultra dual core pentium: *Update: no ehternet tune script this time! iwconfig: From the board: The other direction:

NanoPi A64 has RealTek 8189ETV so i have ported it to 3.10.104 to see how it would performs on the A64 arena. For the same distance, same antenna, no walls between i got the values below: bpi-m64 AP6212 with BT enabled: ~14 Mbits/sec nanopi a64 with RTL8189es: ~16 Mbits/sec Unfortunately i don't have Wifi on my Pin64+ to compare with, but i realized it is very hard to get the same values (average values) in different time of the day, for instance you get lower values during night. RTL8189ETV seems to have better signal strength and better performance ( ~ 15% faster ) however i have had a hard time to authenticate with some of my wifi router.

I have to ask, how do i change my "avatar"?

Thanks for the answer. What would be the boot order then? SD CARD, SPI-NOR, NAND and finally eMMC? Maybe a new BOOT0 would be needed?

Can someone check if it is possible to attach RTC Backup Battery? What is the real use for this?

My work on the u-boot is available here: https://github.com/avafinger/u-boot-m64, you can adapt to your need as you wish. You should set MAC address to BT in a similar way Armbian does. Find in the conf where it gets $MAC_ADDRESS and set it (something like this), also you have to patch firmware somehow. I use a High Speed USB 2.0 (not powered) with the mouse and keyboard attached to it and not to USB port, never had a problem, but i think BPI boards has this USB power issues you describe, @lvmc helped them to fix this in the M2+.

I am still on 5.23 on my board and this works. I would suggest to @Igor / @zador.blood.stained to build a dev image with all CSI / VFE debugging enabled , this could help to track down possible errors. I can't think anything else to try. I have searched for the commits that could possible break the CSI / VFE, but have not seen anything relevant. Don't know if a change on kernel defconfig could break it.

hmmm, ok. [ 5.938267] [CSI_ERR][GC2035]sensor_read err at sensor_detect! Is still a i2c issue, may be i2c has been updated on 5.25? Please, double check your fex, decompile fex from 5.23 and 5.25 and see if there are other changes.

Please, read and try this: https://forum.armbian.com/index.php/topic/3225-nanopi-neo-air-cam500b-issue/?p=22681 Update: You could also compile the gc2035 driver from source if the problem is the driver: https://github.com/avafinger/gc2035 https://forum.armbian.com/index.php/topic/3225-nanopi-neo-air-cam500b-issue/?p=22681

Things are evolving really fast, she is doing a great job. I don't have much experience with u-boot mainline but i think it is time to test it. @tkaiser, sorry to ask, is this the same kernel OPI PC2 is based and already running?

Just updated the kernel to 3.10.104 with the 'DIRTY COW' fix as promised i would do something. Releasing an Image (dev Image) comes responsibilities, bpi-m64 users are not left alone. I hope it works for you as it works for me. Have fun! Good luck. https://github.com/avafinger/bpi-m64-firmware#updating-kernel-to-310104

I have chosen to freeze on this version because there are some of my personal development stuff in there, it is not for production environment. This vulnerability was fixed on Oct, 21 on Armbian and Oct, 22 on 3.10.104 (longsleep), maybe just timezone here but after i frozen to make my mods. TBH, i have seen so many people running linux with 'root' that makes 'Dirty COW' a kid in a kindergarten... Anyway, you got me, shame on me, i will do something to fix the flaw.

Please, describe in details the steps you did, step by step so i can figure out what is "not working..."

1st you create SD card from a PC running any distro, you just need to install wget, fdisk and md5sum if you don't have it already installed. 2nd you boot M64 with this new SD card image and then you flash eMMC with the next instructions. The eMMC script has been fixed.

I just finished initial instructions, you can try and see if it works for you. https://github.com/avafinger/bpi-m64-firmware#installation

Feel free to try this ( https://github.com/avafinger/bpi-m64-firmware) if everything else fails, it is a WIP and i just need to make sure the instructions will actually "works".

The correct order to unload the driver is: modprobe -r gc2035 modprobe -r vfe_v4l2 Try Fex with: [twi2] twi_used = 0

Yes, i have the same legacy kernel for the Pine64 amd BPI-64. And most likely will work with NanoPi A64, that is what i will find out soon.

a) Yes, there is the new mmc driver. I worked on the same u-boot, i think a diff could suffice. Regarding Kernel source changes that depends on my modified mmc driver, if i did introduce a bug while i updated the mmc driver most likely the ugly hack should be discarded. b ) Ok, got it. I will update u-boot. How could i do something like this, will this be accepted coorect?: root=/dev/mmcblk${mmc_disk}p2 Edit: It is for my experiments.

In my way the first boot is from SD CARD how you would fix this? Booting from eMMC root=/dev/mmcblk0p2 Booting from SD CARD (edited) root=/dev/mmcblk1p2