On Fri, 3 Jan 2025 07:50:50 -0800 (PST) hipboi <mr.hip...@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 > list in 2024 or earlier. > > If you’re eligible, you can claim your free Cubie A5E here: > > https://forms.gle/NRcVtxT9j6c749rj6 > > We’ll start shipping the boards before the Lunar New Year, so please make > sure your shipping address is accurate. > > Let’s work together to bring back the glory of the SUNXI community! > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion, visit https://groups.google.com/d/msgid/linux-sunxi/20250115155547.0289eb65%40donnerap.manchester.arm.com.