On Fri, 3 Jan 2025 07:50:50 -0800 (PST)
hipboi <
mr.h...@gmail.com> wrote:
Hi Tom,
welcome back and thanks for reaching out!
> Dear SUNXI community,
>
> It’s been a long time since I last wrote to this list.
Please note that the importance of this (googlegroups based) mailing list
has changed since then. For mainline kernel development we are using a
different mailing list, so all patches and mainline discussions (for the
kernel and U-Boot) go via the new list instead, it's "linux-sunxi" here:
https://subspace.kernel.org/lists.linux.dev.html
I guess this one here is still the right list for those kind of
announcements - as the
kernel.org list is really technical. I am just not
sure how many community member regularly read this list here still.
> As some of you may
> know, I left Cubieboard years ago due to internal power struggles and went
> on to found Radxa. Since then, Radxa hasn’t released any SBCs based on
> Allwinner platforms. There were a few reasons for this, but one of the
> biggest was that Allwinner seemed to have fallen behind on new ARM
> technology, and their SoCs weren’t as attractive compared to Rockchip’s.
>
> But now, things are starting to change:
> 1. *New leadership at Allwinner:* ....
> 2. *Strong business performance:* ....
> 3. *A renewed focus on open source:* While Rockchip has turned their focus
> on the EV market, Allwinner has recognized the power of the open-source
> community. They’ve formed a dedicated team and are putting resources into
> building a better open-source ecosystem.
So how does this manifest, really? I heard chatter about "mainline"
already around this OrangePi developer's summit last year, but haven't
seen the slightest efforts from their side (neither OrangePi nor
Allwinner) since. I wonder if this is about a misunderstanding about what
mainline really means: It would be about sending patches and engaging in
discussions and reviews on the official Linux kernel mailing lists.
Dropping undocumented, not properly formatted, not signed-off-by: code
with maybe even the wrong license in some random single-commit Github repo
is NOT mainline, even if the base kernel is something fairly recent.
So if you have a connection to Allwinner, I think this is a list of things
that would help us, as the sunxi mainline community:
- Provide access to SoC documentation: The situations is not too bad in
practice (compared to other vendors), since sooner or later the user
manuals leak via some board vendors, but there is often a delay - which
does not help. So it would be good to have the user manual, data sheet,
display engine documentation (which seems to be separate) and PRCM
documentation available early, with unrestricted access. We cannot do
anything Open Source under NDA easily. I never understood why silicon
vendors are so jealous about their documentation - after all I cannot
really make use of a complex SoC without decent documentation.
We have some stitched together user manual for the A523, but nothing for
the A527/T527, for instance, so are lacking some details about the second
EMAC and the PortI and PortJ pin banks, for instance. And the existing
A523 user manual lacks the bus clock tree for the regular CCU.
Also if anyone is supposed to make use of the NPU or DSP with mainline,
documentation for those would be essential.
And: hint, hint: we have no manual for the A733 whatsoever at the moment.
- Provide access to hardware EARLY: I very much appreciate your efforts in
getting hardware out to developers, but this often happens too late. The
A523 was released about mid 2023, which is now 1.5 years ago. And while I
got a tablet with that chip about a year ago, development could only
really start with more accessible devboards. A shout-out here to TL Lim and
Marek from Pine64 and Yuzuki for making this happen with shipping
Avaota-A1 boards to developers end of last year - this is what really
started the development on this SoC. But it's also at least one year late.
The problem with those delays is that mainlining a new SoC takes a lot of
time - probably about a year if done right - and by then the new SoC isn't
so new anymore. It either becomes slightly outdated in terms of features
and performance, or the board vendors moved on to new SoCs already, and the
supply somewhat dries up. Also the excitement about new boards is often
dampened by people realising the mainline kernel support is way out - which
often makes those devices much less attractive to people.
Another way to mitigate this would be releasing documentation very early,
so that development can start, then sending hardware once available, to
do the testing then.
- Provide a channel where we can ask technical questions. Often the
documentation is ambiguous, or lacking on particular topics. Or something
doesn't look quite right. It would be good to have some way we could ask
specific technical questions, that would be answered by *engineers*.
Within the mainline community we use the #linux-sunxi IRC channel (on
OFTC) for that purpose, though there is no one from "inside AW" in there.
- Provide code in mainline fashion and quality: We often find repositories
with drivers for new SoCs *somewhere*, for instance as part of some board
vendor Github repo, but the (Linux) code in there is basically unusable
for mainline, for multiple reasons:
- Mainline Linux requires separate patches, often even multiple ones for
a single driver. Having all the changes in one "initial commit" is
absolutely unusable. Even if one would invest the time to split those up,
there is one big problem:
- Have patches with an author name and email and a "Signed-off-by:" tag
by the author. The kernel development process really needs to attribute a
patch to an author, and this author MUST confirm that the patch is legally
acquired - so not taken from proprietary software, or not blocked by a
company for public release, for instance. This is done via the
Signed-off-by: tag, and is absolutely essential for mainline contribution.
- Have patches that adhere to the coding style and general Linux kernel
code quality. Running "scripts/
checkpatch.pl" would report most issues.
- Have patches that use existing kernel infrastructure and re-use
existing code frameworks and existing drivers. Good parts of the BSP code
seem to often invent their own framework, or duplicate work in the driver.
Or they duplicate existing drivers, as seen for the UART and MMC
controllers in sunxi, for instance.
- Actually post the patches to the mailing list and follow the
mainlining process. This can be tedious, but is mandatory for getting
code into the mainline kernel. It very often results in much better code,
over the various revisions posted on the list.
Somewhat related, but mostly targeting board vendors:
- Provide access to schematics: This is basically essential to create a
device tree, which these days should be the only thing you need to support
a new *board*, using an already supported SoC. There are a lot of details
that need to go into the DT, most prominently the connection of PMIC rails
to the various SoC power pins and on-board peripherals. Those can be best
and most reliably worked out with schematics. I cannot find the A5E
schematics on your website, for instance ;-)
I realise this email got quite long, sorry for that! I am happy to discuss
aspects of this separately. I would also be at FOSDEM, although I realise
this this both quite far away and during the Lunar New Year :-(
Cheers,
Andre
> 4.
>
> *Exciting new roadmap:* Allwinner has an aggressive roadmap and is
> working on a new chip with advanced process technology. They’ve been
> actively communicating with us about feature demands, including specific
> hardware and software requirements. We’ve provided feedback based on what
> makers and developers need, and I believe this new chip will exceed
> everyone’s expectations.
>
> With all of this happening, I’m thrilled to announce that *Cubieboard is
> back!*
>
> Radxa is officially launching its first Allwinner-based SBC: the *Cubie A5E*,
> powered by the Allwinner A527/T527 octa-core Cortex-A55 SoC.
>
> The Cubie A5E is incredibly compact, measuring just *56 x 69mm*, but it
> packs nearly all the essential interfaces you’d expect from an SBC:
>
> - Allwinner A527 or T527 (industrial version)
> - Dual Gigabit Ethernet (one with PoE support)
> - Full-size HDMI
> - USB 3.0 Type-A and USB 2.0 OTG (Type-C)
> - M.2 M Key for 2230 NVMe SSDs
> - 40-pin GPIO
>
> You can find more details on the SUNXI wiki page here:
>
>
https://linux-sunxi.org/Radxa_Cubie_A5E
>
> Allwinner has been incredibly supportive of Radxa’s return to the SUNXI
> community. They’ve even donated some chips to help us contribute to the
> community’s growth. We’re pleased to announce that we’re giving away free *Cubie
> A5E SBCs* to all developers in the SUNXI community who joined this mailing