@lex

Would you mind elaborating how a fixed 1.1v for all frequencies on H5 works on mainline and not on legacy? I would like to understand how this should work, from a hardware point of view an then from a software point of view, may i suggest a specific thread? Yes i know you have discussed this for the H3.... Feel free to move, delete or whatever.

I thought this call __aeabi_uldivmod was eabi soft float?

Have you checked with armhf?

Try this: Edit: if you can't make it from source, download 5.20 image and check script.bin if twi2 is disabled so the camera module can detect the sensor. There is a thread about this. See

I was curious to see how Mainline kernel performs on GbE test against a Legacy kernel. For the Armbian side i chose the nightly dev Armbian_5.27.170602_Orangepiwin_Ubuntu_xenial_dev_4.11.1_desktop.img (Desktop) and for the Legacy i chose my own build with all "Bells and whistles" (full Desktop, hdmi, camera, bt and wifi). I did not optimized Armbian Mainline, just installed and run stock. For the Legacy i optimized as usual. If there is some optimization to do on Mainline side, i missed. I have some observations about the board and results: * Board is without Heat-sink, * Legacy subsequent test got lower values, i suspect it runs hotter than Mainline, maybe due to HDMI, camera and BT enabled, drops about 30~50 MBits/sec, * After Mainline installation, the next boot came without HDMI output, so i had to guess which IP was assigned without looking at router (OK, we know it is a development Image), * Board act as a Server (iperf3 -s) and my ultra fast Duo core Intel box as a client. * Both Image are build with gcc 6.3 Armbian Mainline kernel 4.11.1 results: Legacy kernel 3.10.105 results:

Just to correct my info, we agreed PL7/PL8 is the correct one!

PL02 and PL03. Can you please point where you are pulling the u-boot and kernel? I can't find your DTS.

Just FYI, OPi Win use AP6212A. WiFi & BT works fine on legacy kernel, just do as @igor say, enable uart and load the firmware for the A series. Small tip: if you are using TTL debug BT does not work.

Here you have: Lubuntu with 1080P, no QT, just raw image. If you are interested and want to get your hands dirty i can manage to provide my POC image, will try to do it during weekend... Be aware it will be in a very unusual way... no fastboot way.

Can you type github.com in the address bar (firefox) and see it gets resolved? If not you probably have eth0 and wifi both enabled and both with IP assigned. Turn on one or the other, not both. And better clone the new repo: https://github.com/avafinger/bpi-m64-firmware-v2 which has support for the 7" LCD panel.

Ouch, i got it wrong...sorry. Just for curiosity, did you enabled uart3? i was looking at buddy dts and schematic for the uart3, PH4,PH5,PH6,PH7 can't be acquired on legacy kernel and PH7 is shared with codec (may be multiplexed?).

I would like to ask if you mean STATUS-LED the one beside the Power Led (RED)? I am trying to understand the schematic and the Pins, if i understand anything PA15 is used on uart3 according to Fex (opi PC2) and the STATUS-LED is PA20, for opi-win schematic is PH11 (GPIO asssignment).... obvioulsy wrong.

Add this to the confusion:

Attached is the FPC pinout for analysis. From the manual (CSI connector): Your link just confirm the sensor is GC0309 (the one attached to the LCD panel) and that is 0.3 MP sensor. If the metallic contacts face down, OV5640 seems to fit but there is no OV5640 driver in the kernel only OV5642. But i am not sure the connector representation is at the board side or at the LCD side (that would means it needs an extension/conversion of signals), i leave this review to the HW guys.

Just a small comment, looking at the manual the CSI pins looks like they are not reversed as usually on all OPIs which is a good thing, if that is correct no way to use the OPI camera, but there is ov5642 driver that may be in good shape. If they release the LCD with the attached camera as in manual it will be of good use but is only 0.3 MP.

Good to hear there are others working on it also... Thanks.

So, the WiP can actually build a working Image?

I am confused, did you give up cleaning the code? I was waiting for you and parrotgeek1 to do the hard work and then jump in to try to build the image. I don't have the board but was just readying the environment when i get one. Can you please clarify your roadmap on this device?

not sure i would work but try and cross your finger: sudo dpkg --add-architecture armhf sudo apt-get update sync sudo apt-get install libc6:armhf sync sudo reboot * update: you may need some other lib, just use package:armf when install * Update2: you may need also this: sudo apt-get install libstdc++6:armhf if some other 32 lib is required to run teamviewer, try: file teamviewer (the binary) to find more about.

Read: https://community.teamviewer.com/t5/Knowledge-Base/How-do-I-install-TeamViewer-on-my-Linux-distribution/ta-p/4351#toc-hId-850221972 You need ARM64 not armhf deb packages if there is one. * i have not found teamviewer arm64, maybe you need to install some 32 bit support.

running sudo while you are root is redundant, sudo (superuser do) is intended for normal users to run some commands as root to fix DNS issue add this to the file /etc/hosts 127.0.0.1 localhost 127.0.1.1 bpi-iot-ros-ai # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters for the eMMC i think there is a tool they call bpi-copy as they state: "support bpi-copy to write SD/eMMC with img.zip file" but as @martinayotte already told your "dd" worked and you copied to eMMC.

Theoretically you can take from 25 to 30 pictures per second (fps = frames per second) with picture size of 640x480, depending on sensor you use, OV5640 CMOS sensor or GC2035 CMOS sensor (OrangePi camea), YUV format. USB cameras are usually slower than this but has the advantage of delivering the pictures in JPG format, reducing cpu usage and bandwidth. Choosing the right one depends on your application requirements and price target. You can do a benchmark analysis using any v4l2 capture program, for CMOS sensor you can try this: https://github.com/avafinger/cap-v4l2 , it may also works for USB cameras with little change.

That works, thanks.

Whatever you can share, thanks! Looks like who Ziped that SDK ziped img, obj, temp files, etc... Sure a clean would reduce that to half. Mega is a pain for me, over quota every time.

Please, full SDK would be better to get inside info, thank you! Later we wipe Android Just in time: @zador.blood.stained Unless you already built an image without full SDK and could share your inside info on how to build it.