lanefu

I've been studying and working on Dynamic Device-Tree Overlays since awhile, but after hard work, I've finally got a working prototype using the work from Pantelis Antoniou.
 
During last few days, I was doing debugging to find out why it wasn't working, even if I got the ConfigFS working, it was refusing to grab my simple overlay test.
I've finally figured out this afternoon : the Root/Base DTB need also to be compiled with the "symbols" list generated with the Antoniou's version of "dtc".
 
So, I will probably prepare a patch soon and submit it thru a PR.
 

Yes, until 24th. No hard work in the mean time 

Hi to All,
 
I decided to start this new tread for searching of the best solution for unification of the boot process from any available media.
 
Main target is Armbian next and development branches and mainline Kernel and U-Boot.
Boot device can be eMMC, SD/MMC, USB Flash/HDD and SATA HDD/SSD probed in given order.
In case of booting from eMMC, SD/MMC and USB Flash Read-Only Root FS can be used optionally.
In case of booting from SD/MMC or USB Flash eMMC and / or SATA devices can be updated automatically.
 
Some effort in this direction was done by me and described in Armbian Customization thread.
The tests was done on Olimex' A20-Olimexino-Lime2-eMMC (HW rev. E) board with following additional staff:
60GB SATA SSD with SATA-CABLE-SET MOD-WIFI-R5370 mounted on the rear panel - only antenna outside USB-ETHERNET-AX88772B - optional BATTERY-LIPO6600mAh ALUMINIUM-HEATSINK-20x20x6MM later changed with special high efficient cooling system A10-OLinuXino-LIME-BOX later changed to water and dust resistant solution based on Aluminum box FTDI FT4232H based USB Hi-Speed Serial/Hub Module AC/DC 5V/4A wall adapter Dual LED Red + Blue Display Digital Voltmeter Ammeter DC 3.5-28V 3A Additional User Push Button and 3 LEDs are connected via Lime2 GPIO-1 connector 1-Wire GPIO based Master and additional Device Boot control is implemented via Lime2 GPIO-1 connector Reset, Power On/Off buttons and Charge LED are wired to front panel doubles Console, DC-IN, USB and Ethernet connectors are wired to rear panel doubles The current status is:
U-Boot is patched to:recognize eMMC; search a boot-able device on SATA, USB, SD/MMC, eMMC etc.; boot from the boot-able device with the highest priority; send to the kernel via the command line right root=PARTUUID=${uuid}; Kernel is patched to recognize eMMC; firstrun script is modified to resize right MMC device (mmcblk0 or mmcblk1); eMMC and SATA device experimental update scripts are implemented and tested; it is investigated the classical and overlayfs way to run Debian on RO Root FS; Described staff is working fine on latest Armbian (5.17), Kernel (4.6.3) and U-Boot (2016.05). Not solved issues are:
to mount root accordingly without explicit setting in /etc/fstab; to resize root partition from firstrun script in case of USB and / or SATA devices; to prepare and use Read-Only Root FS on eMMC, SD/MMC and USB Flash optionally; to start eMMC and /or SATA device update procedure from firstrun script if boot from SD/MMC or USB Flash. The main use case will include following steps:
If the system will be setup for the first time SD/MMC has to be used for been able to install U-Boot on empty eMMC; In case of next FW update USB Flash will be used to boot from by installed on eMMC U-Boot; Booting from SD/MMC will be forced by pushing of user button or renaming of /boot/boot.scr file on the devices with higher priority; Booting from USB Flash will be done always when present because of highest priority; firstrun script will be executed always if booting from image cloned device and the system will reboot if necessary; At the end of firstrun script eMMC and / or SATA device update scripts will be executed to update them from image or SD/MMC or USB Flash itself. The following staff was used to customize Armbian:
 
Mainline U-Boot patch to enable eMMC:
 
 
 
Mainline U-Boot patch to change boot order:
 
 
 
Mainline U-Boot boot script:
 
 
 
Mainline Kernel patch to enable eMMC:
 
 
 
Change in do_expand_rootfs() function of firstrun script to recognize right MMC device to resize:
# DEVICE="/dev/"$(lsblk -idn -o NAME | grep -w mmcblk0) DEVICE=$(mount|grep ' / '|cut -d' ' -f 1 | cut -dp -f1) Reboot script and service looking for user button push:
 
 
 
Experimental script to update eMMC from image:
 
 
 
Experimental script to update SATA SSD from image:
 
 
 
Whole customization process with more details and test results can be found on Armbian Customization thread.
Latest prototype insides and test results can be found in the attached files.
 
Any ideas, comments and references are welcome.
 
Best regards
Chris
 

Lime2-rev-C-E-comp-06-p8.pdf
Lime2-rev-C-E-comp-06-7p.pdf

@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".

-

Please stop spreading such nonsense. The correct answer is "Use Armbian defaults and you're done". We spent days of work developing sane dvfs and throttling settings. There's no need to fiddle around with settings since throttling prevents from overheating!
 
If you use a heatsink, throttling jumps in later, if you use a large heatsink even later and if you combine it with a fan maybe never. It's that simple. Statically downclocking is bullshit since why not allowing the CPU to run single threaded stuff at maximum clockspeeds?
 
H3 on this board can run at 1200 MHz (or even higher clockspeeds when reliability has been tested individually), heat dissipation might not be that great as we already know from NanoPi M1 but since the kernel throttles all the user has to do to is to think about the workloads he wants to run and then choose an appropriate heatsink.
 
BTW: Since H3 is on the lower PCB side this small board is perfect for actively cooled clusters. Simply design a tube with 120 mm diameter, put one large 120mm fan on the bottom and one on the top and use 8 NanoPi NEO per row. The PCB side with H3 and huge heatsink mounted towards the inner side of the tube will make heat dissipation as effective as possible while still allowing easy access to SD card, USB and Ethernet on the outside.
 
This way you can use 8 NanoPi NEO (40x40mm) per row and at a height of 200 mm you get already 40 boards or 160 CPU cores. What makes such a 'cluster design' somewhat moronic is the needed amount of network switches and room for Ethernet/power cabling, also amount of DRAM and type (only one module so 16 bit access and DDR3 instead of DDR3L) so maybe we should think about an IoT device instead of cluster node.
 
Would be interesting whether SPI pins are routed to the connectors (didn't checked schematics already) since Allwinner SoCs could boot from cheap SPI NOR flash (if board vendors would get the idea) and then implement PXE: http://linux-sunxi.org/Bootable_SPI_flash
 
(really looking forward to Xunlong's Orange Pi Zero -- maybe this comes with SPI flash, allows passive PoE and netbooting and so on -- ok, just dreaming )

I've added a welcome message to the docs Home, to temporarily minimally address some UX issues.
 
There are several use cases for the documentation:
 
1. New users, who might easily give up and try something else unless they're walked through everything right from the start.
- Getting Started should be prominent for them.
- "What is the current state of Armbian?" might need to be answered in the docs, since outdated info about hardware acceleration, HDMI etc. can be found elsewhere and may deter these users (or maybe that should be left to the main armbian.com site)
 
2. Users of all levels who have frequently asked questions.
- Do people still look for FAQ sections? If so one should exist and be easily seen.
 
3. People who've run into problems
- FAQ and/or Troubleshooting should be easily found.
 
4. Serious users who will actually read through the ToC and documentation

I believe it polls the repo every few minutes and if there's a change it rebuilds.

I found the whole soldering action to the test points way to iffy. Alternative idea: Using pogo-pins on a proto board with 40 pin female header - provides the necessary pressure and long term stability as well as +5V and GND. Here used with OPi lite to add an extra USB port for "internal" bluetooth. On the Opi Lite, the test point closer to the CPU is USB D-. If I had a 3D printer, it could also look nicer as the holes for the pogo pins could be more precise :-). Thanks to the Armbian team for including bluetooth drivers in the distro - the whole thing works like a charm.

 
 

Updated.

yeah lets go static. was a fun attempt at least
 
Tapatalk thinks its important to tell you im using tapatalk from a phone.

Well then, i have some news about OV5640, it is working on m2p, finally. On Armbian!

I'm not actively doing anything at the moment, to avoid stepping on toes.
I would like to QA/edit the organization and navigation of the docs (within the current tools/layout). I could probably do that now?
I might add to some of the content, for beginner readers, but only after others' rewrite tasks are done.

So far,
 
i've a minimized tarball with the compiled drivers that can be installed via make. for the .deb, im still to find out how the install script determines to which subdirs one module belongs. it could be the x of x_y*.ko but nor sure

Ok found the solution, have to supply now the architecture manually:
 
make ARCH=arm
 
Wonder what changed, anyway this is the solution.

Not sure if this would help. On H3 U-Boot is actually responsible for bringing up all cores through PSCI interface.

For the 1 core in /proc/cpuinfo, I've just figured out now (I didn't noticed before) that all my newer kernels (4.6.2) on orangepilite/orangepipcplus/orangepiplus2e have only 1 core while older ones 4.6.0+ on orangpipc/orangepione have 4 core. So, maybe a bug introduced recently somehow ...
 
EDIT : Oh ! looking at the root DTS, there wasn't any of this clock stuff defined in 4.6.0+, and in the 4.6.2 it is defined but only for cpu0. So, I wonder if only duplicating it for cpu1/cpu2/cpu3 will do the job.

Yes, that's right. I think we're fortunate in that the same kernel features required for running Docker overlap with those to do cross-compiling, I was very pleasantly surprised.
 
I've found a few mistakes in the above Dockerfile. The mknod commands don't seem to do anything, and apt-cacher-ng isn't running for the compile. So it's probably best to just go as far as the apt-get commands, then do the rest in the actual running container, and then commit the result as a new image. Then each time you can just run a build.
 
I'm now working on folding our application into the build so we can build an image from scratch with just a few commands. But first trying to get this eMMC working on the Lime2 boards... argh!

Hi, 
after a long search, I found how to use the display driver without fbtft
https://www.raspberrypi.org/forums/viewtopic.php?t=124961
I used the display 3.5in TFT witch SPI on the OPi PC on Armbian jessie. 
 
lcd on ali:
http://www.aliexpress.com/item/High-end-3-5-LCD-Touch-Screen-Display-Module-Board-320x480-RGB-For-Raspberry-Pi-2/32611946526.html?spm=2114.30010308.3.21.j1gFEx&ws_ab_test=searchweb201556_8,searchweb201602_2_10048_10047_10037_10017_10046_10033_10045_406_10032,searchweb201603_1&btsid=057be304-5a97-4dff-9905-87cf320dcb67
 
After some refinement
 

 
because this interface is very very slow
 

 
my modified code is attach
 
https://github.com/maxk9/3.5-TFT-LCD-KeDei.git
 
sorry for my bad english
 

Extra security  ... fixed. One minute cron, so you don't need to wait long.
 
It looks better now. PDF check, some Youtube solution ... working on content. 

It turns out that that version of FFmpeg does not work because the video engine version in the H3 is different to the A20. According to nove on #cedrus IRC: 'the way that the hardware is initialized changed, and also the way that h264 encoding subengine is enabled changed'
 
Obviously I am still eager for more information regarding this.

great..  BTW there's a task topic already created for you.   It'll inspire others if you can show status there
 
 http://forum.armbian.com/index.php/topic/1532-392-documentation-rework/

Thanks, I'll forked a little while ago, so I'll re-base my fork and start submitting.
 
Thanks!!
 
Kriston

Ok, for the THS, adding back the 1008000 entry is a kind of ugly workaround : during boot FREQ switch is crashing, but at least it continue to boot completely.
I presume that real fix would not be adding it, but change the value at the origin of that 1008000, which is probably in u-boot, but this is outside of my knowledge.
@Tkaiser, the patches you mentioned, and even Megi's change doesn't seem to be part of the Armbian build process. Maybe patches are not applied for some reason.
 
@jernej, I started doing what you've said, I got some part done, but now I'm a bit lost about platform files searching for the legacy sys_config.h

Cool, I also did few things on the way:
 
- docs.armbian.com is updated auto when new commit is done to lib.docs, checking via cron at the moment
- wiki @lib is closed
- I moved main documentation link to docs.armbian.com since it's better than what we have right now in any case.
BTW: Do we really need brackets [ ] in URL? They are URL unfriendly ... any other option?