[aeruder]

I don't understand why they go through so much effort to churn out these boards that are made useless by lack of upstreaming.

Oh, wait, because idiots like me keep buying them and finding this out too late. Thanks for saving me $20 this time.

[ajross]

> I don't understand why they go through so much effort to churn out these boards that are made useless by lack of upstreaming.

Because the board vendor, generally, doesn't know any more about this stuff than you do. They buy an SoC from a manufacturer (Allwinner in this case) and drop it on the board. Whatever "Linux" BSP the vendor provides then gets hacked into form for their product and shipped. They aren't really in any sane position to take maintainership of this code or upstream it on their own.

And going further, Allwinner is themselves just assembling IP blocks from other vendors (companies like ARM and Synopsys) that they don't completely understand. They get a sample driver, drop it in a tree, fix bugs, and ship it.

It's a big mess. The bigger vendors (e.g. Intel and Qualcomm) do a decent job of putting together solid BSPs (even if they don't always play well with the community -- the packages received by board vendors usually work and come with solid docs). The little guys just aren't there yet.

[revelation]

They buy enough of them to get a datasheet. Just releasing that would be enough.

[ajross]

The datasheet is a copyrighted document received under NDA. They literally can't.

And again, a datasheet from Allwinner is going to just tell you what the instantiation parameters for all the various IPs are. To write a driver for, I dunno, the I2C controller (or whatever, I know nothing about this SoC in particular) you're going to need a Synopsys databook or something.

There's a framework in place for distributing all that stuff between OEMs and first-tier customers. But with the exception of a handful of hardware vendors, no one's ever cared about getting it out to the public.

[ssvb]

The datasheets are released and you can freely download them. For the Allwinner A64 documentation (another 64-bit SoC, which is very similar to H5) you can check https://linux-sunxi.org/A64#Documentation

And no, it is not a "stolen" or "leaked" documentation (I have actually seen such ridiculous claims in the phoronix forum). It is hosted on the Pine64 website with the permission from Allwinner. And the Pine64 people specifically asked Allwinner to remove the misleading "confidential" watermarks from the PDF files.

Allwinner H5 is very new and this Orange Pi PC 2 board is probably the very first piece of hardware using it. But I expect that the H5 documentation will become available in public access shortly. Just like the documentation for the older Allwinner chips. Maybe initially with the "confidential" watermark again, because the Allwinner people are a little bit lazy and don't seem to understand why the open source people are making so much fuss about this.

[johnchristopher]

Is banana pi among them ?

[geezerjay]

> I don't understand why they go through so much effort to churn out these boards that are made useless by lack of upstreaming.

I don't believe that this sort of business venture requires that much effort. It appears that in essence they only repackage a currently available soc, and hope that the market bites.

The main reason why these small boards come with a quad-core processor and 1GB of RAM is that currently that's precisely the standard for low to mid-end smartphones running Android.

Of course, the people behind the Raspberry Pi foundation do a bit more than repackaging a bare-bones SoC. Hence, they do manage to sell quality products that actually work.

[ainiriand]

HN just saved me money, another idiot here.

[alistproducer2]

Could you explain "lack of upstreaming?" I get, via context, and know what upstream is, I context of OSs, I've never read a "lack of."

[planteen]

The board requires custom modifications to the kernel. These modifications never get cleaned up and submitted as patches to the kernel. So you are stuck with a kernel frozen in time.

[jff]

And this is the situation with damn near every ARM board you can buy! It's depressing. I finally had to give up on my Efika MX smartbook because they never got past a 2.6 kernel, which IIRC eventually meant I couldn't upgrade libc past a certain point, which meant I couldn't upgrade anything else.

[planteen]

Yes it is and it is terrible. The lack of upstreaming also makes things like applying the PREEMPT_RT patches much more difficult than it should be. You might be stuck at a version of the kernel where PREEMPT_RT was never released, not to mention you will be missing the PREEMPT_RT changes in the custom code.

[yuhong]

BTW, just Linux "2.6" means nothing these days.

[jandrese]

Phone hardware is absolutely infuriating in this regard. People figured out how to standardize bootloaders and do drivers on the PC decades ago, why can't SBC and phone manufacturers figure this out?

Why can't their be a generic build of Android that will at least boot on every phone, even if there might be some driver issues on different devices? This situation has gone on for so long it is past the point of being a joke. And don't try to tell me that there is a good technical reason why it has to be this way, we're talking about machines that are as powerful as a mid 2000s PC, you can afford the overhead of a bootloader on there.

[revelation]

They have a bootloader, they just don't have a BIOS, or ACPI, which you would need for the operating system to detect and interface with peripherals.

I think right now they are trying to decide between Device Tree (FDT) and ACPI for ARM, in the mean time nothing gets done and I'm not confident anything will get done until ARM the IP holder itself mandates something.

[jandrese]

Shouldn't this have been done years ago? Do all of these manufacturers like reinventing the wheel every time they spin a new silicon? Didn't building custom bootloaders for every device get old a long long time ago?

[revelation]

The systems powered by these ARM processors were typically bespoke embedded software anyway, so not many people cared. Hardware vendor provides a bootloader of sorts and some shitty SDK or RTOS patch, you heap your own custom code on top and ship it. Never update any of the components, that's just asking for extra work.

Now that the processors are powerful enough to replace what would ordinarily run Windows or Linux it's very painful. The Linux code is littered with support files for a bazillion of different boards and hardware platforms.

[yuhong]

And even that is targeted at servers I think.

[ssvb]

I don't think that you know what you are talking about. Please check the https://linux-sunxi.org/Linux_mainlining_effort page.

Every new mainline kernel release includes improvements for Allwinner chips. Older Allwinner chips, such as A10 and A20, are already supported very well. The support for newer chips is progressing nicely, but there is always a bit of delay.

Yes, you can't expect this newly released Orange Pi PC 2 board to be already supported in the mainline kernel today. But maybe half a year later everything is likely going to be much better. And even right now, there should be some sort of a legacy 3.10 kernel available too, so it is not like you can't use the board at all.

[alistproducer2]

got it. thanks!

[photojosh]

"made useless by lack of upstreaming"

... only if you actually need particular features of the CPU. We're running a dozen of these boards with mainline bootloader, kernel, and Xenial.

But they're headless servers. We don't need the GPU, which is the major component lacking support in mainline. You have to run a legacy 3.4 kernel and binary driver for GPU acceleration and OpenGL. :(

[Florin_Andrei]

I think this chunk of industry is going right now through its enthusiastic adolescence. It's a phase. It will pass. It will eventually mature, and will separate the wheat from the chaff.