gounthar

Now that this is getting closer to physically existing (ideally I'll have one soon, whether we support it here or not)
 
1) No SD initially worried me because of the normal proprietary loaders/etc.  However we support FEL on Sunxi, UMS on Tinker, and @Neil Armstrong / BayLibre is shoving a ton of patches to get the Amlogic USB boot support into u-boot (2018.11?)
 
2) SPI flash for u-boot, or at least the u-boot environment.  I don't have all the details, but if done correctly this board could keep a consistent hardware profile across distros (MAC address/etc).  ASUS tried this halfway, but didn't go full on for a SPI flash boot.
 
3) The SoC is a Meson64, and has nothing to do with an S805, so think low-power S905X
 
4) This thing should be able to run in very low power mode, assuming the Amlogic blob behaves. 
 
 
 
 
 

I was chatting with @tido about ways to help the Armbian community and I came up with the idea of a common C library to access the I2C, SPI and GPIOs of all supported boards. There are of course kernel drivers to communicate with these things, but there are differences between boards that this API could help smooth out. For example, different CPUs (and boards) map the GPIO pins very differently. Projects such as WiringOP and WiringNP try to copy the Raspberry Pi library, but this is also flawed because it's based on the BCM283x GPIO numbering. What I propose is to create a set of simple functions for accessing GPIO pins using the physical pin number as a reference. On all boards, the 5V pin will be considered pin 2 and the numbering goes from there. There are also sometimes pushbuttons present on the board which are mapped to GPIO inputs. These are also covered by my API. Much of the code is already written and I will release it shortly.  I'm posting this topic to get feedback and to reach out to people who might make use of this. Here is a list of the functions so far:
 
int AIOInit(void);
void AIOShutdown(void);
const char * AIOGetBoardName(void);
int AIOOpenI2C(int iChannel, int iAddress);
int AIOOpenSPI(int iChannel, int iSpeed);
int AIOCloseI2C(int iHandle);
int AIOCloseSPI(int iHandle);
int AIOReadI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
int AIOWriteI2C(int iHandle, int iRegister, unsigned char *buf, int iCount);
int AIOReadSPI(int iHandle, unsigned char *buf, int iCount);
int AIOWriteSPI(int iHandle, unsigned char *buf, int iCount);
int AIOReadWriteSPI(int iHandle, unsigned char *inbuf, unsigned char *outbuf, int iCount);
int AIOReadButton(void);
int AIOAddPin(int iPin, int iDirection);
int AIORemovePin(int iPin);
int AIOReadPin(int iPin);
int AIOWritePin(int iPin, int iValue);

Almost none. https://www.armbian.com/get-involved

I've got a NanoPi Neo Core 2, with the NAS kit.  It lets me attach a 2.5" SATA SSD drive, all contained in an aluminium case (which elevates it above "toy", to my eyes).  The whole kit, minus SSD hard drive, was about $80 (and I'd call this a good value, worth it), however shipping from China took a long time (like a few weeks to a month).  Disk performance isn't stellar, but it doesn't suck either.  Much more performant-feeling than a Raspberry Pi.  It's adequate, to make your own personal LAN server, like say OpenMediaVault (for serving SMB file shares), or Nextcloud (DAV file shares, with SSL encryption, work great in Gnome Nautilus out-of-the-box, or Linux Mint's file manager, Nemo, once you install the package "davfs2"). 
 
Small home offices should be a good fit for this kit, where LAN file-share usage day-to-day is light-to-mediumly demanding.
 
What I love about this kit is that the H5 CPU has decent mainline kernel support.  This helps to assure me that this board won't just be a "flash in the pan", and I'll very likely be able to get kernel security updates for at least a few years into the future.
 
I mention this all to underscore my earlier point that to get something minimally sturdy, performant, long-lasting and above all useful in a way that goes beyond a tinkerer's toy (which can be a great starting point for many, don't get me wrong), then to me, this $80 kit is about the lowest I'd personally go.  For $20, I'd rather go eat a pizza or something.

Why not La Frite?
Quad 64-bit ARM Cortex-A53 CPU Cores at 1.2GHz
2 Geometry + 3 Pixel ARM Mali-450 GPU Cores
1GB DDR4 @ 2400MHz
128Mb SPI NOR
HDMI 1.4 with 1080P Output
100Mb Fast Ethernet
USB 2.0 Host
USB 2.0 OTG
IR Sensor
Currently at $35+shipping at KickStarter. The naked board is at $15...

People of firefox don't care about Linux on ARM devices. It's been broken for a long time on armhf. Even on arm64 it crashes constantly.
This is a fork of Chromium. But better optimised for ARM. I don't know how, but on most arm devices the video playback is a lot better than Chromium. This without using hardware acceleration.

For example, on my NanoPi M4 I get 2/3 lost frames 1080p. While on Vivaldi it's only 1/3 lost frames.
I use it to surf on most devices since it's fast and stable.
Greetings.
 

Works in firefox. Even in Armbian. I don't know how. But it does. But Firefox does suck for surfing.
For that I use Vivaldi. There 1/3 lost frames in 1080p Youtube. Chromium 2/3 lost frames. Firefox 0 frames lost. All video works perfect. I even use it as video player on the NanoPi M4.
For me the NanoPi M4 is the perfect 2nd desktop pc. It's very fast. It's got an amazing heatsink. It's stable, haven't had 1 crash with it in hundreds of hours use. I've tried many different sbc's on there desktop capabillity's. The Odroid C2 was the best until the NanoPi M4.
Tinker board does ok in video, but many things don't work. I've tried it again this week, and it even got worse. I need 3 different OS'es to be able to do everything.
To my knowledge not many others than the C2, tinker, rasp and RK3399 have HW acc in Linux. The Raspberry sucks to work with.

if you go higher than 60$ anyway, then I would have a look into the RK3399 based ones. Towards 'evil inside'.. it depends on your needs, I assume once HW acceleration on RK3399 works properly they may even beat the Atoms on desktop.. For me desktop means >30 tabs in browser.. No 2GB ram desktop can deal with that.. 4GB ones maybe.. For my work I just had to deal with windows 7 again.. Seems they've a crappy OOM handling there..
 
The preview picture from the RPi thread @Igor posted is an 'industrial grade' board (or at least near to industrial grade). Question here.. do you need it? This guy sent a Odroid C2 2600m deep.. For sure not an 'industrial grade' board:
an OPi Zero (with USB wifi, cause XR819 is crappy) together with a few ESPs currently manage a lot of monitoring stuff in my Lab - for sure not industrial grade, but they do what they're supposed to do. So, even a 10$ toy can do serious work..
 
RK3288/tinker is IMO outdated, performs probably not that bad for desktop scenarios due to 32bit with 2GB ram may be ok-ish. If desktop means some web-surfing and watching youtube.. I assume an android driven one may fit better, normally those SoCs are supposed to run android and hardware acceleration works there a way earlier than in Ubuntu/Debian.

there you go..
 
https://forum.armbian.com/forum/29-reviews/
and
https://forum.armbian.com/forum/26-research-guides-tutorials/
 
is always a good starting point to get useful informations.

there you go.

I'm currently running a Beelink GT1 ultimate (S912, 3Go DDR4, 32Go) with your armbian 5.37 based on 3.14.29 debian stretch without specifying any dtb file.  It is used as a server with openmediavault and homeassistant. I'm running armbian from sd card.
I just made upgrades and got armbian-config 5.64 with an uptime of 70 days.

Yeah - but for OP - it's perhaps a challenge to contribute
 
Keep NAND sane and untouched - makes it possible to continue to use the TV box as an Android - and 7.x isn't a bad place to be there for the intended apps...
 
Worst case - one can always run termux in the android space - which isn't bad actually - I do that with my little chromebook, and it's debian like enough...

doesn't need FEL, bootorder for H3 is SD-->NAND-->SPI if I've it right in mind.. The print-screens from the opi-zero image show clearly that he's booting armbians 2018 u-boot..  
 
But without the 16GB 'ROM' the most interesting part of this board IMO disappears.. A 16GB eMMC 2GB RAM box with an acceptable wifi chips for 30 bucks in an nice looking case could be interesting. NAND and  XR819 makes it rather uninteresting (at least for me)..
 

Ignore the NAND
 
Once he gets serial up and running, he can play around with FEL, and take things from there.
 
Totally possible, IMHO, to just run everything Armbian off the SDCard, and leave Android as the secondary option if the card is removed.

then it should be a real 'proposal' with an intention to contribute to the board bring up process.. If it's just an 'I want armbian on it' but don't even summarize specs and a pro/cons, better keep it here..  @constantius thread was merged from development subforum (but not board bring up) by myself to this one cause it didn't make sense to have a second thread with the same infos yo get here.  We have a search engine to spot such threads before you've to open a new one:

 
Before the board isn't on the table it IMO doesn't make sense to discuss a 'board bring up'.. 

moved the thread to p2p.. Probably TV boxes subforum would also fit.. 
 
Well I do in organic chemistry.. Before we're arguing back and forth for days we collect the infos we think are needed and then go to the bench and start an practical experiment.. Sometimes I feel dump that I missed something mostly I get more information to babbling/working with.. The original goal was running 'Armbian' on it:
and @gounthar realized that dram initialization with the default armbian bootloader seems to fail:
 
well at least for @lucastriches, seems that @gounthar never provided a bootlog but that's why I said:
 
Allwinner is failsafe! you can try whatever you want without messing up the stock OS... Insert some SD-Card try it and if it fails.. shit happens, next bootloader, next idea.. It doesn't matter if this is some sort of a new iteration of H3 (IMO unlikely but can be..). Or how good the Android support is.. If the goal is still bringing up 'Armbian' you shouldn't waste time with hypothetical issues.. First try the obvious ones.. Search for an UART cause debugging low-level issues without is blind flying.  Start with the lowest possible DRAM clock speed assuming that routing on the board is crap.. and try do extract the device tree to see if you get some information from there cause it will be the only source of information you'll likely get for this thingie.. As long as you're not an expert on 'board bring up' you'll probably fail 10 times before you get a step further but it doesn't matter.. You'll learn from your failures.. 
After: 
and:
you're done with android... 
The first tells you it is an H3/H2+ the second tells you (likely) it's based on this kernel:
https://github.com/Allwinner-Homlet/H3-BSP4.4-linux/blob/ddcfef77177e66f73db94c9be4090ab6ff9ccef8/Makefile#L1-L3
so there's not much interesting left here.. (expect an DT). Boot loader is likely based on this bits here:
https://github.com/Allwinner-Homlet/H3-BSP4.4-bootloader
 
Everything was there with the third post.. after then.. it was mostly babbling but not much progress..
 
IMO now it's time to open this thingie and get access to a UART otherwise.. Have fun with blind flying.. Most of the interesting stuff happens before HDMI is initialized.. 
 
Before you build up your dreams what it could be, you need to know what it actually is.. At the moment it's an boring Android box with an outdated 4.4.55 kernel which likely never gets updates....

Yes and no - It's not H3 actually - one can have L1 even on H3 or any chipset - it's more the ARM TEE and requirements there - and with Android, this means full-on GMS compliance, which means that the OEM/ODM has to have written agreements with Google, and do all the compliance/conformance testing around those requirements.
 
Widevine L3 limits output to sub-HD, and sounds like Netflix from Google Play likely won't work (there are ways around this with a patched apk there) - this is not unexpected with AOSP, even with Play Store hacked in...
 
L1 is full on compliance with Widevine, all keys are good, and everything runs inside the ARM Trust Environment - most NA/EU mobile phones have that, but cheap TV boxes, and AOSP handsets likely don't.
 
Many AOSP TV boxes will have test keys installed, but TEE and the APK's know this - grrr... DRM, and I understand why content distributors want this, but still...
 
Anyways - Widevine is an android thing - and android support does mean that the box is still useful if mainline support is lacking...
 
 
16GB - most likely eMMC, IMHO...  if one is going to put 16GB on the board, might as well be eMMC.
 
One could have 'naked' NAND and run it as a MTD device I suppose, but mmcblk is less work, and more flexibility with supply chain,  besides, eMMC prices are probably better, and eMMC has knockon benefits later on with OS level support...
 
Anyways - good res pics of the board, along with RAM, WiFi, eMMC, that's a good start - high resolution of just the board - top and bottom, goes a long way - there's only so many ways to do a H3 board, and now that the chip in question is pretty old, most of the options have been refined to a narrow set of choices...
 
Good example of board pix - http://linux-sunxi.org/HYH-TBH3
 
 

I still fail to understand what you want to achieve... 
A correct DTB, together with 2-3 pictures of the opened box (e.g. wifi chip, eMMC or nand - in case nand forget about the 16GB 'storage' cause nand not supported in mainline) and you're done. You may then adjust the DTB to mainline-style and finished. Assuming AW 4.4 kernel is really based on DT not some fex style anymore (the had it with 3.4, but from what I've in mind 4.4 is now also DT based). You now that this thingie is H3 based, so it's only figuring out where and how stuff is connected to it... 

Someone sends me one I'll look at the prospects, but a proposal for support needs to be under the board bringup thread

Today I did try my very best... Opened the R69 (without breaking anything), solder the TTL-Pins, connecting USB-TTL -
BUT when I power on with the u-boot button pressed I didnt get any output to disable the u-boot boot-sequence
(normally counting 3.2.1 on other boards and you have to press a key)
 
So I can - today - only deliver the boot-log from android on the R69 and two find commands for *.bin and *.fex as android-root on the filesystem:
 
 

I did get my R69 today (my birthday) - but did buy it myself
I also got a reboot problem with a old 8GB Samsung Class 4 uSD. It doesnt boot after filesystem-resizing (and after reconnect power),
but with a 16GB Sandisk Ultra Class 10 it does boot after resizing and power reconnecting
 
login as: root root@192.168.6.151's password: ____ _ _ ____ __ ___ / ___| _ _ _ ____ _____| | | | _ \ / /_ / _ \ \___ \| | | | '_ \ \ / / _ \ | | | |_) | '_ \ (_) | ___) | |_| | | | \ V / __/ | | | _ <| (_) \__, | |____/ \__,_|_| |_|\_/ \___|_|_| |_| \_\\___/ /_/ Welcome to ARMBIAN 5.31 stable Ubuntu 16.04.3 LTS 3.4.113-sun8i System load: 0.23 0.26 0.12 Up time: 3 min Memory usage: 4 % of 1000MB IP: 192.168.6.151 CPU temp: 69°C Usage of /: 9% of 15G [ General system configuration: armbian-config ] Last login: Thu Oct 19 12:41:47 2017 from 192.168.6.17 root@beelinkx2:~# for the ASCII-Logo I changed the file /etc/update-motd.d/more 10-header
first apt update & upgrade is finsihed

used for my display (1280x1024)  h3disp -m33 
 
 
dmesg.txt

La Frite will be avalaible on november 2018. Now you can back it on kickstarter web page.  specs.; https://libre.computer/products/boards/aml-s805x-ac/ This is my proposal to support.
Best regards

Injection molded housing: cheap as hell when you produce enough
Aluminium/metal housing: not that cheap
 
As a premium tv box SoC, you either make a SoC which has high decoding capabilities with low heat generation or you force the tv-box makers that they do it properly (means higher housing costs due to metal cases)..  IMO there's a market for such devices either implemented in the TV or as a standalone box in addition. 
 
For the buy as cheap as possible fraction, you're right they buy by the bigger the better.. But as on other fields, there's a 'premium sector' where people care about things work properly and things get updated for a longer therm.. The only reason I would ever buy an Iphone again is the fact that I get a phone which is updated at least for the next 2 to 3 years... If you don't want to be a premium SoC supplier, fine cheat your customers sell it to every shitty TV-Box maker which doesn't give a fuck about updates and make your bucks there.. 
 
I guess, and that's just a guess that also their closed source SoCs benefit from the expertise they have now inside the company how to do it properly.. They might or might not cheat you with the closed source ones (I've no clue). But at least their in-house knowledge is grown. Google may switch to fuchsia to solve this problem with the shitty 'phone get's no update' situation or make it harder to install the google app store, e.g only if the SoC and the installed kernel fulfills some requirements. And google showed it on other fields that they can be harsh when they decide that something has to change (e.g Symantec in case of https). Mess up with google is for sure not fun for an SoC maker which is focused on android devices and I think google will use this power more and more to solve some of the issues they have. 
People start to care when they realize that their dick pic collection isn't save anymore cause there's a security hole which makes your data accessible for others [^1]...  
It's clear to me that the average user doesn't care what works behind the scenes/ opensourceness (as a 'windows for my daily tasks' -user, I'm also not part of the 'Stallman Church'). But more and more people are concerned about their data and how save they are... Solutions like home cloud, own cloud (whatever cloud which is not hosted by google or dropbox ) may get more attention.
Premium users may not pay attention to 'stupid specs' as long as the thing works the way work as they expect but they care about other things. Otherwise nobody would buy an macbook pro anymore cause from specs the xiaomi mi pro notebook throws every macbook in the bin, except display resolution (16gb ram, Samsung SSD + second m2 slot, i7-8550U and NVIDIA GeForce MX150 2GB for ~1000$) and it also looks 'somehow similar': 
 
But your apple macbook pro does the things you want and you don't care about maximum performance as long as it performs well on OSX. From a homecloud/nas/tv-box thingie in the higher price range you expect that it performs well for tv streaming, a little bit of BS gaming and that your dick pics are save. The easiest way to achieve this is by don't have your box open to the internet (which makes it shitty for a streaming box with integrated cloud thingie) or you have a your code peer reviewed by others who care about security... And I think the cheapest way to peer review your kernel code is to have it mainlined.  You need developers which code properly (higher costs) so that your PRs are accepted by the kernel maintainers but you get a peer review for free (lowers costs).
In the science world where I'm involved you've to possibilities to get your results published. You can either pay a fee to the journal so that they do the peer review process for you (normally ~2000-3000$ per article) or they do it for free but then every reader has to pay a fee to read your article (and those fees are horrible high around 5-10$ for read once or 50$ to get a pdf)..  Or you publish it in a low reputation publication where nobody will notice your results... Free open access journals with a good reputation barely exists (and mostly they're part of a series where you have to pay for all their other journals)... 
 
 
[^1]:
 
 
Edit: Maybe we should rename the topic again, moving it to General chit chat? Cause It's hijacked again for a lot of other stuff...  

Only some 'MHz fanatics' were really concerned. Or to be more precise: people who do not understand the difference between performance and clockspeeds and who also do not understand the challenges to run chips at high clockspeeds (both consumption and heat increase a lot). Again: https://www.cnx-software.com/2016/08/28/amlogic-s905-and-s912-processors-appear-to-be-limited-to-1-5-ghz-not-2-ghz-as-advertised/#comment-530956 (there you can also read what happened then in detail to get more control over clockspeeds on C2)
 
If I'm concerned about performance I need a use case first and then I test for performance with this use case (and don't rely on theoretical clockspeeds since this is plain stupid). That's what both Willy Tarreau and @willmore did unlike those people who for whatever reasons bought an ODROID-C2 instead of an RPi 3 due to '2 GHz' vs. '1.2 GHz' (those people exist en masse). So it was pretty obvious once that happened that an A53 'clocked at 2 GHz' performing like one clocked at 1.5 GHz is just that: limited to 1.5 GHz. So what? This is on those devices always the result of consumption and thermal constraints so why bother?
 
Since I mentioned 'use case' and Raspberry Pi 3:
If you need the performance for a use case called 'AES encryption' (VPN, full disk encryption, stuff like that) then looking at clockspeeds is what? Plain stupid as usual! Both ODROID-C2 regardless of being able to clock at 2 GHz or just 1.5 GHz performs as crappy as the RPi 3. They both do not support ARMv8 Crypto Extensions and perform magnitudes slower than any cheap NanoPi NEO2 or Orange Pi Zero Plus running at below 1 GHz CPU clockspeed: https://forum.armbian.com/topic/4583-rock64/?do=findComment&comment=37829 RPi 3 is the SBC with the most screwed up DVFS/cpufreq/clockspeed situation. The problem should be well known since 2015: an awful lot of RPi suffer from underpowering and run then frequency capped (limited to 600 MHz). But just like in situations when throttling is happening the kernel has not the slightest idea at which clockspeed the CPU cores are running and reports bogus values like 900 MHz on RPi 2, 1200 MHz on RPI 3 and 1400 MHz on RPi 3+ while in reality being limited to 600 MHz. Is this 'cheating' or at least a problem? Not when your target audience is only absolutely clueless people (RPi users). They're happy to achieve top clockspeeds only in idle and being limited to 600 MHz once performance would be needed and even start to complain once they are made aware of the real problem (seriously: check this link, it's unbelievable)