lvmc

@balbes150 and @choco
 
1. I just wrote your image to sdcard and booted, I haven't copied any dtb file.
How can I extract dtb files from available Beelink Android images (GT1_104M0.img or GT1_104M0_AP6255.img)?
 
2. What are the differences from @balbes150 and @choco initiative?
 
3. What do you mean by "script in internal the internal memory"? What are the steps to test and help you?
 
4. I extracted newest Bluetooth and WiFi drivers for AP6255 from Beelink's GT1 Android image, it can be downloaded from:
https://dl.dropboxusercontent.com/u/11164079/GT1/bluetooth.tar.gz
https://dl.dropboxusercontent.com/u/11164079/GT1/wifi.tar.gz

Yes. I downloaded respective img from balbes150 link, wrote to sdcard.
 
To boot you have to insert sdcard, unplug power, hold the key near the capacitor / power plug, plug power and release key after some seconds.
 
On screen image will take a little bit to turn on.
 
@balbes150, nand-sata-install is writing upto 100%, but after reboot android is booting again, not the probably written armbian image.
 
Do you know what else we need to do?

@balbes150, could you provide us a step-by-step to test your armbian on GT1 / S912? I want to help you to support this hardware.

1. I understand that the system automatically used the correct dtb data (you not copied dtb) ?
2. It is the universal images, which are collected from my git if you select AmlogicS905X
3. The setup script in the internal memory is NOT working. It needs to be changed (I don't have time, something would have to change it and test). The main problem is that the script should NOT replace u-boot and should be able to embed the system into existing mtd-partitions without affecting functionality of an internal component (recovery env, etc).
4. For WiFi settings you need to perform several manual operations (I hope next versions will be added gradually need the infrastructure to support WiFi).
 
https://forum.armbian.com/index.php/topic/2419-armbian-for-amlogic-s905-and-s905x/?p=20730

@balbes150, yes it is working!
 
How are you generating / compiling this image? Is it integrate with Igor's lib building system? 
Have you tried to write to NAND chip using nand-sata-install from Armbian?
WiFi is not working by default, don't know if it is only a matter of loading the module or not. The WiFi chip is AP6255.

@balbes150, 
 
The Armbian_5.24_Amlogic-s905x_Ubuntu_xenial_3.14.29_desktop_20161125.img.xz image is booting on Beelink GT1. Please check the full dmesg:
 
https://gist.github.com/Grabber/5737a65926dfe18333a8b2cc26035139
 
What are the next steps?

@choco, I was trying to compile your branch and got this error:
From https://github.com/igorpecovnik/mt7601  * branch            old        -> FETCH_HEAD  * [new branch]      old        -> origin/old [ .... ] Checking out cp: missing destination file operand after '/home/lvmc/Projects/output/cache/sdcard/lib/modules/3.14.29-beelinkgt1/kernel/net/wireless/' Try 'cp --help' for more information. depmod: ERROR: could not open directory /home/lvmc/Projects/output/cache/sdcard//lib/modules/3.14.29-beelinkgt1: No such file or directory depmod: FATAL: could not search modules: No such file or directory What is the current stage / status of your fork. What is done, what is not working, what efforts we have to concentrate our force on?
 
@Igor, @tkaiser, is there a check list of things we have to get working to have a "stable" Armbian release?

@lordofduct, can you provide me remote SSH access to your board? I can check the ov5640 stuff for you. Me and @lex has been doing an extensive job to support cameras on cheap boards. Send me a private message, if you need help.

@garyang, how can I help you?

Check here, daily automated build, NanoPiAir was just added:
http://image.armbian.com/betaimages/

@chocho, I'm highly interested in helping you port Armbian to GT1. I have a few units in my hands now, how can I help you?

I have tested GT1 under extremely load cases and it is the best hardware and thermal design I've seen so far. I'm highly interested in helping Armbian support GT1.
 
@tkaiser, can you help me with steps to help it go faster?

Enhanced driver for OV5640 and vfe fix are now available on Armbian, thanks to lex and jules!
 
https://github.com/igorpecovnik/lib/commit/05456d07ea78780e17fbfbc0ec9a1e11703ddada

@tkaiser
 
@lex, @JulesThuillier and @lvmc (me, yeah) worked so hard last 2 weeks to solve most issues on OV5640. It is fully functional now and I will push the Armbian patches today or tomorrow.

I finished all tests on hardware level and it's confirmed that both GC2035 and OV5640 are now fully working!
 
@lex has been doing an incredible job on Linux drivers, now focusing on frame grabbing compatibility.

I finished all tests on hardware level and it's confirmed that both GC2035 and OV5640 are now fully working!
 
@lex has been doing an incredible job on Linux drivers, now focusing on frame grabbing compatibility.

@Nora Lee, thank you so much for supporting our effort!
 
We are actively working to solve all issues with GC2035 and OV5640 and as soon we finish software stuff, the code will be available for Armbian community.
 
The Armbian project has been doing and incredible job for community and TRUE collaboration is the way to go!

@tkaiser
 
Oranges
GC2035 FF/Xulong is working with @lex, already merged on Armbian;
From the original gc2035.c driver found typically on Linux, @lex driver provides much better FPS rates and resolutions.
modprobe gc2035 modprobe v4l2_vfe fswebcam --Hflip 1 -r 640x480 -p YUV420P - > cam640x480_1.jpg OV5640 AF/SinoVoip is working on Oranges, with the same drawbacks as explained for Bananas (see below).
 
Bananas
GC2035 FF/Xulong is working, same comments as for Oranges;
OV5640 AF/SinoVoip is working but there are several bugs on ov5640.c driver. To temporaly overcome these bugs, @lex modified fswebcam to retrieve frames bypassing driver missing features.
modprobe ov5640 modprobe v4l2_vfe fswebcam --Hflip 1 -r 640x480 -p YUV420P - > cam640x480_1.jpg Fixing all issues ov5640.c is complex and requires a lot of efforts, we don't have a fixed schedule to do it yet... but I report that multiple resolutions are currently working... will keep community updated as we move, if we move in that direction. My personal target would be to have the driver fixed to run a basic OpenCV frame grabbing code...
#include <iostream> #include <opencv2/opencv.hpp> using namespace std; int main() { Mat frame; VideoCapture cap; if (!cap.open("/dev/video0")) { cout << "Failed to OPEN /dev/video0" <<endl; return -1; } while(; { cap >> frame; if (frame.empty()) break; cout << "Failed to RETRIEVE frame from /dev/video0" <<endl; return -1; } return 0; } For both OV5640 AF / SinoVoip or GC2035 FF / Xulong, on both Oranges (except Orange Pi One or Orange Pi PC) or Bananas, you can connect modules directly to DVP camera connector (24pin connector), no extension board is required.
 
On the hardware side we discovered that both Oranges and Bananas adopted 180º reversed pins layout, when comparing to most of the camera modules that are available for sale from other suppliers. My guessing is that they have changed it to somehow force customers buy their own cameras.
 

 

 
To overcome that I personally partnered with camera factory to develop new GC2035 FF and OV5640 FF modules with the correct pin layout... it is under production right now. As soon I test the new modules next week, I will start selling cameras modules to help me amortize factory custom development costs and help community.
 
Note: FF stands for FIXED FOCUS, while AF stands for AUTO FOCUS.
 
By the way SinoVoip has been extremely supportive with me, proving me hardware as requested. On the other side Steven/Xulong seems to definitely not be interested in solving it... he just told me "It doesn't work, only with our own GC2035 cameras".

@lex
 
AF pins 23 and 24 need further investigation, it is maybe swapped too... especially on OV5640 AF / SinoVoip... but I will not focus on solving it for now.
 
I think a good idea would be to create a reference/comparison table with camera modules from different factories/brands.

@tkaiser
 
Oranges
GC2035 FF/Xulong is working with @lex, already merged on Armbian;
From the original gc2035.c driver found typically on Linux, @lex driver provides much better FPS rates and resolutions.
modprobe gc2035 modprobe v4l2_vfe fswebcam --Hflip 1 -r 640x480 -p YUV420P - > cam640x480_1.jpg OV5640 AF/SinoVoip is working on Oranges, with the same drawbacks as explained for Bananas (see below).
 
Bananas
GC2035 FF/Xulong is working, same comments as for Oranges;
OV5640 AF/SinoVoip is working but there are several bugs on ov5640.c driver. To temporaly overcome these bugs, @lex modified fswebcam to retrieve frames bypassing driver missing features.
modprobe ov5640 modprobe v4l2_vfe fswebcam --Hflip 1 -r 640x480 -p YUV420P - > cam640x480_1.jpg Fixing all issues ov5640.c is complex and requires a lot of efforts, we don't have a fixed schedule to do it yet... but I report that multiple resolutions are currently working... will keep community updated as we move, if we move in that direction. My personal target would be to have the driver fixed to run a basic OpenCV frame grabbing code...
#include <iostream> #include <opencv2/opencv.hpp> using namespace std; int main() { Mat frame; VideoCapture cap; if (!cap.open("/dev/video0")) { cout << "Failed to OPEN /dev/video0" <<endl; return -1; } while(; { cap >> frame; if (frame.empty()) break; cout << "Failed to RETRIEVE frame from /dev/video0" <<endl; return -1; } return 0; } For both OV5640 AF / SinoVoip or GC2035 FF / Xulong, on both Oranges (except Orange Pi One or Orange Pi PC) or Bananas, you can connect modules directly to DVP camera connector (24pin connector), no extension board is required.
 
On the hardware side we discovered that both Oranges and Bananas adopted 180º reversed pins layout, when comparing to most of the camera modules that are available for sale from other suppliers. My guessing is that they have changed it to somehow force customers buy their own cameras.
 

 

 
To overcome that I personally partnered with camera factory to develop new GC2035 FF and OV5640 FF modules with the correct pin layout... it is under production right now. As soon I test the new modules next week, I will start selling cameras modules to help me amortize factory custom development costs and help community.
 
Note: FF stands for FIXED FOCUS, while AF stands for AUTO FOCUS.
 
By the way SinoVoip has been extremely supportive with me, proving me hardware as requested. On the other side Steven/Xulong seems to definitely not be interested in solving it... he just told me "It doesn't work, only with our own GC2035 cameras".

@tkaiser
 
Oranges
GC2035 FF/Xulong is working with @lex, already merged on Armbian;
From the original gc2035.c driver found typically on Linux, @lex driver provides much better FPS rates and resolutions.
modprobe gc2035 modprobe v4l2_vfe fswebcam --Hflip 1 -r 640x480 -p YUV420P - > cam640x480_1.jpg OV5640 AF/SinoVoip is working on Oranges, with the same drawbacks as explained for Bananas (see below).
 
Bananas
GC2035 FF/Xulong is working, same comments as for Oranges;
OV5640 AF/SinoVoip is working but there are several bugs on ov5640.c driver. To temporaly overcome these bugs, @lex modified fswebcam to retrieve frames bypassing driver missing features.
modprobe ov5640 modprobe v4l2_vfe fswebcam --Hflip 1 -r 640x480 -p YUV420P - > cam640x480_1.jpg Fixing all issues ov5640.c is complex and requires a lot of efforts, we don't have a fixed schedule to do it yet... but I report that multiple resolutions are currently working... will keep community updated as we move, if we move in that direction. My personal target would be to have the driver fixed to run a basic OpenCV frame grabbing code...
#include <iostream> #include <opencv2/opencv.hpp> using namespace std; int main() { Mat frame; VideoCapture cap; if (!cap.open("/dev/video0")) { cout << "Failed to OPEN /dev/video0" <<endl; return -1; } while(; { cap >> frame; if (frame.empty()) break; cout << "Failed to RETRIEVE frame from /dev/video0" <<endl; return -1; } return 0; } For both OV5640 AF / SinoVoip or GC2035 FF / Xulong, on both Oranges (except Orange Pi One or Orange Pi PC) or Bananas, you can connect modules directly to DVP camera connector (24pin connector), no extension board is required.
 
On the hardware side we discovered that both Oranges and Bananas adopted 180º reversed pins layout, when comparing to most of the camera modules that are available for sale from other suppliers. My guessing is that they have changed it to somehow force customers buy their own cameras.
 

 

 
To overcome that I personally partnered with camera factory to develop new GC2035 FF and OV5640 FF modules with the correct pin layout... it is under production right now. As soon I test the new modules next week, I will start selling cameras modules to help me amortize factory custom development costs and help community.
 
Note: FF stands for FIXED FOCUS, while AF stands for AUTO FOCUS.
 
By the way SinoVoip has been extremely supportive with me, proving me hardware as requested. On the other side Steven/Xulong seems to definitely not be interested in solving it... he just told me "It doesn't work, only with our own GC2035 cameras".