All of these steps and tools are massively helpful as someone working on supporting a new device!
Is there a process for getting a new device supported upstream? (Upstream meaning Manjaro ARM here) e.g. let’s say I have working u-boot, linux, post-install PKGBUILDs, and an arm-profiles fork w/ support to build it, and it’s based on a chip with broad support in Manjaro ARM already (RK3399)
The easiest for us would probably be something like:
Create an issue on the arm-profiles gitlab repository, where you post the PKGBUILD’s needed and a DEVICE profile.
The only issue I see is that we (the Manjaro ARM developers) don’t have a way to test the device, so you would have to do the testing of the device. We would likely maintain and update the packages it needs, but can’t really test them.
Hello @m4xm4n
Are you part of clockworkpi ?
A06 is an interesting piece of hardware, happy to know that you’re working on Manjaro Port for it.
IDK if it would be possible for Manjaro ARM developers to receive the device to maintain the device support officially.
Please share the PKGBUILD’s for this device, so we can look into it.
I’m not part of it, no. Me and another person from the community have been actively building out support for Manjaro based on patches and schematics published by Clockwork, as well as the large catalog of other RK3399 devices supported by you all (it’s similar to the pinebookpro in many ways, so the work there has been useful reference)
PKGBUILDs and other code for our efforts are available here (very slightly out of step w/ upstream Manjaro ARM, but trying to track as closely as time allows):
buildarmimg I need to commit somewhere)We have an ongoing thread on the ClockworkPI forums which might be interesting for context: Manjaro Linux support - #46 by m4xm4n - DevTerm - clockworkpi
It’s usable and supports almost all the hardware. The only device hold out is sound (trying to use the mainline es8328 codec driver instead of 4.14-ported-to-5.10-but-broken-on-5.15 es8323 driver), which I’m actively working on and a panel wake issue that affects the Clockwork-distributed Armbian build as well.
The Clockwork team maintains a repo w/ schematics, various userland tools, and patches for the Armbian distribution of which various sources can be found here:
GitHub - clockworkpi/DevTerm (patches live in Code/patch/armbian_build_a06/patch)
They’ve also re-opened orders for the A06 model it seems: https://www.clockworkpi.com/product-page/devterm-kit-a06-series
This is great.
So I think we can add this to our devices pretty easily.
Kernel:
Only requires a couple of patches. Any plans on upstreaming these patches? We can add those to our main kernel package if that’s the case.
Uboot:
Only requires a couple of patches too. So same question, any plans to upstream those?
Post Install:
The post install package looks good. We can easily add that.
Tools Edits:
I know where the tools would need to be modified to support this.
Profiles:
A simple device file. I like it. Easily implemented on our side.
But it all depends on the plans for upstreaming the patces are.
I would certainly like to upstream as much as possible and will try to make contact w/ the ClockworkPI folks to give them the opportunity to weight in and/or do it themselves (though I suspect this is not something they’re focused on / have the bandwidth for)
The kernel and u-boot devicetree side of things I suspect will be an easier time to upstream than some of the driver changes. The panel is of unknown origin (though I think I’ve determined the IC for it, at least), which might make it difficult to upstream. The device driver patches lack authorship information (though are explicitly GPL-2), and it seems likely they will require explicit sign-off from whoever originally authored them (easier if it’s the CPI dev, harder if it’s from some vendor tree somewhere)
Perhaps this is a common experience with vendor patch drops, so open to any experience/recommendations you might have.
This doesn’t sound good for long term hardware support.
Does the panel works and if yes then which driver is it using ?
CPI have agreed to send a sample for testing.
See this patch:
The panel and driver that CPI provided work just fine (other than a wake issue that might be a general MIPI DSI issue), it’s just a somewhat uncommon panel size due to the unique aspect ratio of the device, so unclear how applicable it would be upstream. (But I guess that would perhaps be the case with other panels too)
Hi @m4xm4n
I got my ClockworkPi assembled and it works fine using the default Armbian XFCE on the SD card.
Regarding the kernel patches. I would have no problem including them, if the original author is intending to upstream them. It’s 5 extra patches.
The issue is if they don’t intend to upstream. Then we would be better of, creating a kernel specific to the device.
The uboot patches are easier, as we need a separate package for it anyway.
So do you have any means of contacting the original author and asking them for upstreaming progress?
There is no authors mentioned in the patches you linked. If you are the original author, I will highly suggest/recommend that you start working on upstreaming the patches. 
Regarding the kernel patches. I would have no problem including them, if the original author is intending to upstream them. It’s 5 extra patches.
The issue is if they don’t intend to upstream. Then we would be better of, creating a kernel specific to the device.
Right now it’s setup as a device-specific kernel package, so I suppose we could start that way and see how far we get with upstreaming and merged back into the main linux package? Unless that’s more of a maintenance burden?
So do you have any means of contacting the original author and asking them for upstreaming progress?
There is no authors mentioned in the patches you linked. If you are the original author, I will highly suggest/recommend that you start working on upstreaming the patches.
I’m not the original author, but I’ve made a number of updates to the patches myself. I’ll reach out this week to the Clockwork folks / their developer (@cuu on GitHub) to see if they are the original authors and see if they can update those to reflect who the author is.
Ah cool. I’ll make a separate package for it for now then.
That would be great. Maybe ask if it’s okay for you to upstream the patches for them (while crediting them ofcourse), as you made chances to their work.
Sent them an email. Also linked them to this thread.
Our very first Dev images:
Minimal and XFCE editions, based on Unstable branch.
very exciting!
One thing: the model is a06 rather than a60 (the a06 referring to the six processor cores, I believe)
Damnit, I’ll have to redo it all then.
That’s for tomorrow.
Seems it was a quick change, so did it already, as the package names where already correct.
@Strit I noticed the repo copies in the Manjaro Gitlab don’t have the full history there. This is mostly okay as there are lots of intermediate commits in there that aren’t really useful to keep, but I’m still planning to make some changes in my original repos (probably mostly to clockworkpi-a06-post-install at this point) and it’s a little more difficult if the histories are different
possible to have those rebased off my original trees? And should I just submit patches as MRs/PRs in Gitlab for any additional work?
I think it’s mostly speaker amp switch-off on jack detection that remains, and then removing the X11 display rotation workaround that’s no longer needed, so I suppose one of you might get to that before I do, and I can focus on upstreaming (once I hear back from the CPI folks)
Not really sure how to do that, as I copied the files over and made a few changes so they are in line with the other rest of our packages. Sorry. Would it work if I just copy over the .git folder, after cloning your repositories?
You can submit patches via issues, since the Manjaro gitlab does not allow external users to fork. But if you request access to the gitlab repositories in question, you can create separate branches and MR’s that way.
Would it work if I just copy over the
.gitfolder, after cloning your repositories?
That might work if you copy the .git from mine into the copy you made. You’ll probably see whatever your changes are and be able to recommit them that way. Alternatively, you could freshly clone mine and then force push that to the Gitlab repo (e.g. git clone, then git remote origin set-url git@gitlab.manjaro.org:whatever-repo-name.git and git push origin master -f) and make whatever edits you need.
Either way, you’d probably need to force push to overwrite it.
Also I did hear back from CPI: it sounds like they’re on-board with upstreaming but are busy themselves working on some improvements to device sleep. They did provide authorship information so I will add missing attributions and cleanup the patches , and start the ball rolling on that sometime in the next week hopefully