chwe

Wow, what a groundbreaking contribution to this thread. Especially cause you pointed clearly out 
What's childish the bigger picture what you think what should change [/sarcasm]
 
For your notes: I've this board at home,  I did some tests with it and finally lost the interest... I'm not a:
guy, so doing this stuff needs much more time for me than for a professional (and get false or not properly written stuff from professionals annoys me quite fast)... Even before I had the board at hand, we (as armbian community) pushed the vendor to:
Fix voltage regulation for CPU Release schematics Figured out that ETH is on CON4 (you could figure it out when reading the schematics carefully, but nowhere else) So even if this board does not get 'official armbian support', the childish armbian community helped to improve the situation for this board. To my knowledge, neither the boardmaker nor someone else sent a PR with the needed patches for full or csc support for this board to armbians github... 

one from the category: "Scientific Mob"
 
https://quillette.com/2018/09/07/academic-activists-send-a-published-paper-down-the-memory-hole/
 
Disclaimer,  I didn't read the paper fully, not my field of interest...  Only the blog post. But this one shows clearly what's IMO going wrong in the scientific community.  It's not a problem that they fight against papers they don't like/ or can't agree for whatever reasons. Scientific dispute is healthy for science. The way they choose is IMO wrong. You don't stand for your opinions if you do it behind the scenes.  You don't stand for them if you force half of a board to resign in case a publication gets not rejected. 
As soon as this gets public, no matter how valid your arguments are, as soon as it's becoming public that you used your standing and your power behind the scenes, your arguments are negligible. You loose IMO all your credibility for your arguments by choosing the wrong way. The other way will work for sure, but it harms credibility on more than one field. Not only for yours, but also for future disputes. It harms the scientific community when they use the same methods which are responsible for a decrease in trustiness of business, media or politics. If you  belief that the authors arguments and theories are so wrong it shouldn't be hard to fight with proper arguments right? We should be better than trash credibility only to get a paper not published which might be questionable. Not my field to properly sort out his nor his opponents arguments. A 'censorship'  of a paper which 'survived' the peer review process of a Journal is IMO wrong, or at least it needs a discussion with public statements how this could happen. 

No need.  I did some cleanup and we are back down to 210 files or 63G. It was a part of a preparation for the next major update.
 
 

Tried a fix with https://github.com/armbian/build/commit/f10acc0080825faf711eb6e6b7425910d75d840c
 
Would be great if you could try next nightly version and report back.

i worked on the BPI M1 Board (the first one) for quite a while now improving or more or less rewriting the A20 CSI camera driver.
there are no more artifact-ghost-frames any more.
The framerate goes from 5fps(full) to 120fps(crobbed small)
i also modified the camera-device driver for the ov5640.
disadvantage: existing camera device drivers would not be compatible any more.
 
maybe someone wants to give it a try and check it out.
 
it can be found here:
https://github.com/xenpac/OV5640-Sunxi-A20

On the RK3288 boards, if I am remembering correctly, the drive level is modified in the dts to avoid this issue.  Is that possible with the RK3328 at least?  I think the mmc IP is the same, but don't quote me on that.
 
[edit] 
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1432
 
This part of the dtsi shows the default 4 mA drive levels for the pins.
 
Tinker Board sets the equivalent RK3288 pins to 8 mA: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts#L429
 
It would stand to reason you could do the same with RK3328: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L979
 
 

Hi @TonyMac32
 
The HDMI script is very generic, I created it to handle most use cases for display output and is not SoC specific. I have an extended version that also covers LVDS and VGA output devices if you wanted to include a more generic version to cover all possible displays and SoC's for a generic Armbian script.
 
Im working with some students, teaching (and creating) an embedded systems course for my local tech college till the end of the year. We are using Tinkers and some RK3399 dev boards that I managed to pick up very cheaply. I have built them a minimalist OS (glibc, busybox, weston/wayland, gtk3: ~56MB image size, not debian/ubuntu based) to get started with and their project is to create working kernel images, bug fix, add features and build a simple cloud management solution. My next step was to get them to examine Armbian's kernels to use as a starting point, compare to RK-BSP and mainline and figure out how to package it in a single code base to work across multiple RK boards and generic armhf / aarch64 qemu targets. So I have 3 unskilled but willing students I can point to help on this if you like.

Here is this power supply's spec sheet: https://www.asus.com/Single-Board-Computer/Tinker-Power-Supply/specifications/
- DC 5.0V / 3.0A 15W
- 18AWG 150CM + Power Switch
- SCP, OVP, OCP, OTP, etc Power Protection.
- UL / CB / CE
- US DoE Level VI / EU CoC Tier 2
- LPS, etc lots of safety cert mark.
 
 
No, currently I don't think I have kind of this data, but I can provide the result from my simple test for refer:
- low current: avg. 4.99v
- high current: avg. 4.87v (CPU 4 core, 400%.)

I wish you all good health.
Using the "Armbian" build system, I noticed two bad points:
1 - incomplete cleaning of the source code before starting a new compilation, seen when patches add new files to the tree.
2 - Debian kernel source package includes the git directory.
 
1) All I do I'm fixing the version kernel (KERNELBRANCH="tag:v4.14.40") and collect several variants for one Board, changing the patchset for each version, adding or removing some.
Before each new compilation I'm doing a test of the purity of the source.
clean_repo() { display_alert "clean_repo $PWD" #git status -s git reset --hard HEAD # First, return the modified files. git clean -df # Then delete all new, added files. #git status } compile_kernel() { # A simple check ensures that we start with a clean slate. cd $SRC/cache/sources/$LINUXSOURCEDIR if [ "X$(git status -s)" != "X" ]; then clean_repo fi # ... ... }  
2) Manufacturer's code Debian package:      (--exclude='./.git/')
if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude='./.git/' --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude=='./.git/' | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi can be changed to view:    (--exclude="[.]git")
if [[ $BUILD_KSRC != no ]]; then display_alert "Compressing sources for the linux-source package" tar cp --directory="$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" --owner=root . \ | pv -p -b -r -s $(du -sb "$kerneldir" --exclude="[.]git" --exclude="[.]git[a-z]*" | cut -f1) \ | pixz -4 > $sources_pkg_dir/usr/src/linux-source-${version}-${LINUXFAMILY}.tar.xz cp COPYING $sources_pkg_dir/usr/share/doc/linux-source-${version}-${LINUXFAMILY}/LICENSE fi  

The R2 has an mt7623 which is for sure not a phone/tablet SoC...  
 
Actually, the R2 is quite well mainlined.. Not perfect but most features 'work' on mainline. I'm quite sure both SoCs could be maintained with one kernel (similar as we do for Sunxi in mainline). 
 
CSC boards for a SoC which doesn't have any wip or supported boards is IMO pointless. As shown in the 2G-IoT, nobody cares and maintains those boards/kernels. IMO this doesn't make sense, better the users chose a distro which maintains the board as they stick to a csc armbian which doesn't get maintained. Cause both SoCs are well mainlined I still hope that other boardmakers pick up these SoCs for some boards. Something like a HC1 could be made out of it..  

Thanks to help from Jernej, the magenta display issue is solved in U-Boot commit 79405999d7ee43f830825751b200d739b53f20f5 ("video: sunxi: de2/3: clear all BLD address space").

You could easily do that with any SBC discussed in this forum, e.g. k1plus dual screen + bluetooth keyboard, or a zero plus 2 h5, 5 inch hdmi + bluetooh keyboard, or a pi zero with double 18650 batteries and a 2.4" screen
 

Why so pessimistic/optimistic? (depends highly on point of view ) Just buy and add a cheap AI block, stick it to the SoC. RPi goes AI with Blockchain!!!1!  They will survive 2-3 years more with it..  
 
If you accept that the RPi isn't a high performance SBC made to 'learn' programming, not really low level stuff, more different sorts of 'hello world' with GPIOs and/or camera. The RPi is still an affordable board. For this use-case their last iteration is worthless (you still can do this with a RPi3) but that's part of the deal to keep the people happy who pay their rent (seems that they aren't that happy at the moment, but hey, they sold over 19M devices so they can't be wrong right?  At least it seems to be their main excuse for every thing they didn't do right).
 
Probably we should split the RPi rant part in the RPi thread, and @NicoDs 7zip results into this one?
 
 
 

Question out of curiosity.. What's a CPU only benchmark for else than miss information on the people reading it? Doesn't it lead to a situation which we still have? People buying CPU by:
the more cores it has the better the more GHz is written on the box the faster it must be! For me there are two sides in benchmarking which should be kept in mind. First it should be reliable, means others should get 'the same numbers out' when they repeat your benchmark (e.g. I could benchmark wifi sticks somewhere in the alps here, for sure throughput would be a way higher than in my hometown were I've actually around 20 others wifis visible. A 'good' benchmark would involve both situations with a comment on why and how performance differs..). You should also think about who reads your benchmark. For the '30 years in computer science guy' it might be obvious that ram-speed, general IO speed etc. matters too, for the average smartass probably not.
Things like "I bought *random sbc* cause *random guy* claimed that the CPU there is 10x faster than *random other boards CPU*. So others then have to explain the average smartass why this doesn't matter for his case due to someone smart enough to know it better decided to publish a benchmark which doesn't tell the full truth. Publish it with something like material and methods, discussion of this methods and a conclusion (somehow like a scientific paper). Otherwise your benchmark just lead to mis-assumptions which others had/have to correct.
Best example, with the average smartass: "I bought a 2A PSU cause the RPi guys said buy a 2A PSU and your SBC will run fine and microUSB is better than the outdated barrel plug cause my tiny tiny connector is gold plated and my outdated big barrel plug with a huge contact area is only nickel plated.. " The reality showed that barrel plug SBCs works 'in general' more reliable especially under high powerusage situations but the RPi guys seem to disagree on this, otherwise they would never release the 3B+, or they think it's funny to troll their own community and make some extra bucks by selling 5.15V RPi branded PSUs, a microUSB powered board which needs a 'special PSU' is IMO just error by design (5V on the microUSB output should be sufficient otherwise your PCB designer failed).. but different story...  
 
I tried once to 'benchmark' the CPU mostly with a tool called cachebench after reading through a paper written by Ulrich Drepper (and I'm quite sure, he knows what he's doing, for people interested, the paper is old but I think it's worth to read it) you could easily see if the benchmark happened in CPU cache or if it used RAM (as far as I've in mind, you could even distinguish between L1 or L2 cache mostly when it did memcpy) but I got results out of it which I could not explain, especially there were 'performance peaks' which shouldn't IMO be there which I couldn't explain in a rational matter. I decided to throw away the whole dataset and never published it cause it would only end in miss-assumptions (I think the bashscript which set-up the system reliable and converts data for analysis after its is still somewhere but I don't think it makes sense to work on it as long as I can't explain the results). 

'in theory' you  could do it on an asus tinkerboard with th 4.4 kernel. I got it working months ago, problem is that it breaks to much stuff and the kernel had so many issues that I kept the project 'on hold'.. From what I know, @JMCC tested it once with the ISP driver and it shouldn't perform that bad. Full HD recording should be possible...
But there's a bit too much 'should' and 'could' so if you need a solution which works now and well tested it's obviously a bad idea. For sure there's some stuff to get it working. And you might compile the one or the other kernel on your own to test it. The isp driver should also work for RK3399 boards with a mipi csi but everything is untested there. 

To late...   I think it makes more sense to split it yet otherwise it will be a hard nut to distinguish between what should be part of the research article and what's the left over from the original thread (this splitting often leads in headache for the one who has to do it). Feel free to change the title as soon as you think it's ready.  

Working on NanoPi M4 these days,  almost done, Here is the other side(not final version), would be available  in August, price is $79/99 (2GB/4GB RAM).
 
 
 

 

Learning by doing...  Nobody starts as a 'perfect' contributor doing everything right from the beginning. Read through this:
and probably this one:
H6 boards have plenty of stuff to step in. Try to fix something and then start to send patches. If you struggle somewhere report what you've tried, where you failed and maybe someone can give you some hints to solve it and maybe not, in case 42 isn't a sufficient answer.   The great thing armbian provides is the build-script which everybody can use, not only @Igor when he provides Images for a *random board*. It saves you in the beginning a lot of headache cause you don't have to deal with patch creation, applying those patches and choose a proper compiler for your tests (you'll understand the scirpt better and better as soon as you start to use it).  

Learning by doing...  Nobody starts as a 'perfect' contributor doing everything right from the beginning. Read through this:
and probably this one:
H6 boards have plenty of stuff to step in. Try to fix something and then start to send patches. If you struggle somewhere report what you've tried, where you failed and maybe someone can give you some hints to solve it and maybe not, in case 42 isn't a sufficient answer.   The great thing armbian provides is the build-script which everybody can use, not only @Igor when he provides Images for a *random board*. It saves you in the beginning a lot of headache cause you don't have to deal with patch creation, applying those patches and choose a proper compiler for your tests (you'll understand the scirpt better and better as soon as you start to use it).  

Already available: The official NAS enclosure which opens up plenty of opportunities for specific server and NAS use cases:
 

 
Please check the product page for details (e.g. what's included and what you need to purchase separately)
 
My understanding is that the drive cage can accomodate 2 x 3.5" disks and 2 x 2.5" disks though you can only use 2 of them at the same time with Pine's own SATA card (relying on an ASM1061 -- check performance numbers here, the tests were made on an ODROID-N1 which uses same SoC and SATA chip). The ASM1061 only provides 2 SATA ports (so eSATA and SATA can't be used at the same time) and is attached with just a single PCIe lane which is fine when connecting spinning rust but will already bottleneck two SSDs since PCIe will limit overall bandwidth then.
 
Performance fanatics might skip Pine's cheap ASM1061 card and search for a PCIe card based on either ASM1062 or Marvell's 88SE9230 (both using 2 PCIe 2.x lanes, the latter providing 4 SATA ports). If it's just about attaching 4 SATA devices cards based on Marvell 88SE9215 will also do it (for performance numbers see here)
 
External powering with one single 12V PSU (it's the common barrel plug with 5.5/2.1mm, centre positive) is sufficient. For 2 3.5" disks you should choose 5A.
 
If you want to add Wi-Fi to this setup you most probably need to drill 2 holes to attach good external antennas (recommended since Pine's Wi-Fi module is a pretty decent one: AP6359SA is dual-band and dual-antenna and even RSDB capable which allows to use both bands at the same time so providing more bandwidth but especially lower latency if the AP also supports it)

The "bs=" means "block size", it has nothing to do with "sector size" of a file system.
It is only the size of the buffer used between reading the source and writing destination.
Of course, a bs=4M will do the transfers faster than a bs=4096, which is not the same since the later means 4096 bytes.

my fault..  
Didn't have the 4.17 branch in mind (didn't know that you started with a 4.18 branch). So the statement is true for the masters branch where next is 4.14 and h6 boards only live in the dev branch. This is different for the 4.17/4.18 branch. So you might build your branch on top of them and then send PRs against those and not master.  @Igor will it make more sense to buid against 4.17 or 4.18?
 
IMO it actually makes sense to name it different than armbians default names in case your git-fu is on a similar level than mine (in case a PR gets rejected it's just less work to sort this stuff out than to revert the git-history from the working branch and sync it properly with armbians branchnames, I can, but it takes me more time than just kill a dedicated branch for my idea).

dev image only.. so you need a EXPERT="yes" tag set. Background: All sunxi boards share mostly the same kernel. Due to H6 initial support is based somewhere on top of 4.17 (probably partly 4.16), armbians "next" kernel (4.14) isn't an option for this board. 

Hi,
 
i changed Uart (Uart2=>ttyS0) and MMC (SD=0,emmc=1) from mainline to make my kernels compatible with official images (defined my images same way).
 
i see some definitions...maybe they can be used to define which uart is used for debug-uart without changing the order in dts(i)
aliases { serial2 = &uart2; }; chosen { stdout-path = "serial2:115200n8"; }; btw. 2nd gmac, hdmi, poweroff and some other stuff is working now in (my) 4.14...hnat is ported, but i don't know if it is working due to a "strange" test (cpu-interrupts increasing)