Librecomputer Tritium H3

[zador.blood.stained]

4 hours ago, lanefu said:

Is there anything out there now that is as exciting as the H3 was?   

RK3399? At least from more or less cheap and common ones, obviously things like Armada 8040 can be also exciting but expensive and thus less popular.

[TonyMac32]

Well, to be honest I'm not too excited by most of the boards being released short of the rk3399/H6 ones, from the standpoint of a new brand coming into an already crowded marketplace, it might be best to release a series of "minimum risk" boards first.  And given that everyone has tried to put their own spin on the RPi form factor (MiQi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi), it's not unexpected that someone tried to go as conservative as possible with it, sticking to current SoC mfg recommendations and minimal peripheral sets.  (I might have to register "Spaghetti Pi", seems like a good idea...)

 

The lack of voltage scaling I agree is a negative, and thank you for the history on that, my Allwinner background isn't the strongest, I've obviously only seen the bad examples...  .   

 

The website, well...  Schematics are there and so far haven't had any demonstrated issues (not an exhaustive analysis), and the device trees added to the mainline kernel look complete.  But yes, it needs work, looks not the best when everything is "coming soon".  

 

Cost.  I agree I'd like to see them closer to the crowdsourcing values, but it's likely the crowdsourcing was a manufacutrer-cost introductory price to help get some startup capital/attention.  Probably a projected market price during the campaign would have helped (I haven't checked to see if it is there)

 

To my (intended) point, the boards are basically breakouts for the SoC only, so while there aren't hugely compelling reasons from a "wow that is interesting" standpoint, there is almost no support requirements for this board series.  I think of all the "uninformed RPi convert" boards it should cause the least trouble.  Stick with mainline only on it and, if anything really bad surfaces, we end support.  

[zador.blood.stained]

12 minutes ago, TonyMac32 said:

And given that everyone has tried to put their own spin on the RPi form factor (MiQi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi, ? Pi), it's not unexpected that someone tried to go as conservative as possible with it, sticking to current SoC mfg recommendations and minimal peripheral sets.  (I might have to register "Spaghetti Pi", seems like a good idea...)

And producing a generic ? Pi as a result in some cases 

[TonyMac32]

5 minutes ago, zador.blood.stained said:

generic ? Pi 

 

I'm ok with generic, most industrial and control situations require boring and generic because it's stable and easy to replace, it is the ?? that causes the issues.  I haven't seen any actual technical failures baked in so far, unless you count being artistically inspired by a credit card sized computer a technical requirement.

[tkaiser]

49 minutes ago, zador.blood.stained said:

RK3399?

 

Agree. Interesting feature set (and my RockPro64 just arrived few hours ago).

 

Also agree on Marvell Armada and hope that we do not only see more designs like ClearFog GT 8K but also some others based on less expensive Armada 7K.

 

Wrt Allwinner... I as many others have fooled myself thinking A20 would be a great SoC in terms of storage performance and a great fit for the NAS use case. When H3 arrived at least the board prices looked interesting (OPi PC for 15 bucks) and once some H3 and later H5 boards were released with Gigabit Ethernet and all 4 USB2 ports exposed we could do some interesting things with those (25 months ago we started to deploy H3 GbE capable boards equipped with some USB attached flash modules in RAID mode to replace huge NAS devices -- based on mainline kernel with early @montjoie Ethernet patches -- still not everything landed upstream which pretty much illustrates why situation with Allwinner SoCs sucks). But in the meantime there's RK3328 with USB3 so really no reason to look at any Allwinner device exceeding $15 any more (for me).

 

It was fun to turn something known as 'overheating and consuming way too much energy' (Allwinner H3) into those Linux SBC with minimal consumption. Learned a lot. But it's 2018 now and almost all Allwinner devices except H6 based are just boring as hell. But obviously it's all about 'use case'. I'm interested in cameras (RPi), sensors (low consumption and as cheap as possible) and servers/NAS (good performance). So more or less done with Allwinner if the board exceeds 15 bucks.

[TonyMac32]

17 minutes ago, tkaiser said:

Interesting feature set (and my RockPro64 just arrived few hours ago).

 

 

Jealous.  

[tkaiser]

4 hours ago, TonyMac32 said:

To my (intended) point, the boards are basically breakouts for the SoC only, so while there aren't hugely compelling reasons from a "wow that is interesting" standpoint, there is almost no support requirements for this board series.  I think of all the "uninformed RPi convert" boards it should cause the least trouble.  Stick with mainline only on it and, if anything really bad surfaces, we end support. 

 

Not against this proposal but I fear it won't work that way (at least not now).

 

As you already said there will be support issues with people mounting the heatsink and later on complaining about H5 OS image not running on H2/H3 and vice versa. Same with 'what about Mali and video decoding?!1!!?!' questions (mainline only)... If unnecessary support issues are what Armbian is about... why not?

 

I still wonder what happened... Armbian started as a project of ours to get situation with SBC fixed to fit our needs since vendor OS images were horrible/unusable. Now it's only about what board makers (or their end users) might want?

[chwe]

40 minutes ago, tkaiser said:

As you already said there will be support issues with people mounting the heatsink and later on complaining about H5 OS image not running on H2/H3 and vice versa. Same with 'what about Mali and video decoding?!1!!?!' questions (mainline only)... 

That's what 'known issues' are for.. We can't avoid that people will not notice it but that's also true for all the boards we currently support. For me, there's no reason to provide the BSP kernel for new boards anymore. IMO the goal must be to get the BSP kernel dropped, as soon as the VPU works on mainline. Then, the only use case which comes to my mind for the BSP kernel would be 'camera' but the last time I looked into it, camera (ov5640 only cause there's no mainlinedriver for the gc2035) on mainline seems to work too (somebody here ever tried it here?). Adding more boards to the BSP kernel would only mean that we have to convince more people that they should switch to mainline as soon as we drop the BSP kernel.

 

59 minutes ago, tkaiser said:

I still wonder what happened... Armbian started as a project of ours to get situation with SBC fixed to fit our needs since vendor OS images were horrible/unusable.

Armbian got popular...  (I'm one of the guys dropped into it when H2+/H3 boards worked more or less without major issues). Cause initial boardsupport was relatively easy in the past for H3 boards (add a board.conf, fex-file, patching u-boot with adding one defconfig more, mostly copy paste from another one - as long as it isn't a BPi-M2-Zero ) adding more boards was easy, armbian gets more popular --> more boards of the same SoC came to the table. Maintaining all those H3 boards is what needs a lot of resources. More or less every boardmaker selling H3 devices writes the Allwinner specs for the SoC (maybe possible with Android, I don't know, I don't care) and not "what is possible/works with Linux" on their boarddescription, so most people. And people don't do research first for a board which cost 8-20$, they buy it and they expect that this works. Why not? The Raspberry was able to play Kodi with minor issues ~2012, so why should a board which is sold in 2018 not be able to do what's written in the description (don't hang me on the exact date, I'm to lazy do to the research when the RPi was able to run Kodi 'smoothly' )? I can somehow understand people that this should work in 2018.

Spoiler

Quote

What can I do with Orange Pi One?

A computer

A wireless server

Games

Music and sounds

HD video

Quote

M2plus-H3 uses H3 powerful CPU which supports H.265/H.264.

Quote

ALL-H3-CC H3 1GB

Allwinner Display Engine 2.0

Decoders
VP8 1080P60
H.265 4K30/1080P60
H.264 1080P60
JPEG / MJPEG 1080P30

Encoders
H.264 1080P30

 

 

To lazy to go through all boardmakers (I think friendlyarm doesn't advertise 'videocapability' but I can be wrong)... 

 

What about: 

• Having them as .csc until one of the GitHub maintainers decide to take care/responsibility for it (doesn't mean that the others should avoid working on/with it, but that at leas one maintainer knows how good the board works/ what's currently not working etc.)
• all CSC boards have their separate patch folder so that they can't harm board we support (may need some rework of patches when they get moved to wip or supported) but then the maintainer decided to take responsibility for that new board knows what to do. 

I think even boards which are initially supported by a maintainer should start as csc first, to get 'a feeling' if it's worth to level the board up to wip or supported.. People expect active work on wip boards and we have currently 7 boards (master branch) which are labeled wip (rock64 will switch to supported, and olinuxino A64 disappeared in development). Do we have (at the moment) enough resources to bring more boards to wip (isn't there some work related to the merge of development --> master which might be of higher priority  - I happily help with everything I committed to the dev branch)? 

 

 

[tkaiser]

6 hours ago, chwe said:

isn't there some work related to the merge of development --> master which might be of higher priority

 

I give up.

 

A development branch has been created out of nowhere, master has been abandoned and all active work happened in development with nothing 'stable' merged into master any more. At the same time stuff that would need testing still landed in master as part of PRs (so splitting development from master was absolutely useless at all). Zador wasted his time to rebase development few days ago and now in huge commits changes that have been made in development are 'ported' to master? At the same time PRs that destroy the whole build system (and my settings) get merged for no reason...

 

Smells just like a huge waste of time again and again...

[Tido]

2 hours ago, tkaiser said:

Smells just like a huge waste of time again

This thread goes offside.

However, if development rules are written down for example in here (needs to be created)  or in the documentation. Than this wouldn't have to happen, or am I wrong ?

[lanefu]

12 hours ago, Tido said:

This thread goes offside.

However, if development rules are written down for example in here (needs to be created)  or in the documentation. Than this wouldn't have to happen, or am I wrong ?

 

It does appear the project is now at a size where discipline around feature branches and merges.

 

Who are the principle contributors at this point... cuz it used to be like Igor, Zador and Tkaiser, so a flat branch was managable

 

 

 

[TonyMac32]

Well, that's still more or less it, with me working on Meson64 and rk3288.  PR's have increased a little in recent weeks I think, and sometimes they aren't being thoroughly reviewed, but that's a situation where the only solution is to hold ourselves to having people review and acknowledge a PR before it can be merged.

 

I think the variety of "special needs" boards is a problem, an example is the amount of time I have to spend simply keeping Tinker adjustments from breaking MiQi before rolling them out (and with that I'm not 100% successful).  I can't imagine the array of "same but different" Allwinner boards, and looking at the patch directories kind of shows it easily.  It's one of the reasons I was willing to suggest the Tritium boards, so far they have no special needs, other than the likely mistaken identity issues that could surface.  (And honestly, with the naming conventions of OPi and BPi, they have the same issue, if for different reasons)

[chwe]

On 5/24/2018 at 10:51 PM, tkaiser said:

As you already said there will be support issues with people mounting the heatsink and later on complaining about H5 OS image not running on H2/H3 and vice versa

 

2 hours ago, TonyMac32 said:

(And honestly, with the naming conventions of OPi and BPi, they have the same issue, if for different reasons)

doesn't need a heatsink on it that people expect raspberry experience..

 

 

17 hours ago, tkaiser said:

.At the same time stuff that would need testing still landed in master as part of PRs (so splitting development from master was absolutely useless at all).

Acked by, reviewed by might help? If it was useless until now, than we better make it to something useful before considering to add new boards.. If the development branch is to hard to maintain than let's figure out how we can have them in one master branch. Maybe boardspecific patchfolders might help? Not that they should be used to solve nasty issues which are boardspecific, more to test patches in a 'isolated area' to ensure that they don't harm a full boardfamily during testing. 

 

 

 

[TonyMac32]

13 minutes ago, chwe said:

If the development branch is to hard to maintain than let's figure out how we can have them in one master branch. Maybe boardspecific patchfolders might help?

 

I keep coming up with either a "wip" branch or a branch per SoC/big change.  It seems more complex at the surface, but they are temporary branches.  Easier to maintain than a fork, less confusing/scattered/mixed up than a single dev branch.  Should have dev-rockchip, dev-sunxi, dev-meson64, etc.  When we decide it is stable, we flatten it out and put in a PR and someone who isn't the PR requester needs to review/ack it before it can be merged.  Incremental kernel patches should be applied to "master" since they should only ever break one family, and should be fairly consistent across all members.  But, is off topic for this thread.

 

[lanefu]

RE: BRANCHING, STRUCTURE, WORKFLOW -- GO HERE GO HERE