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:
1 Like
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)
1 Like
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. 
2 Likes
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.
1 Like
Our very first Dev images:
Minimal and XFCE editions, based on Unstable branch.
1 Like
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.
2 Likes
@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.
1 Like
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
Awesome, will try this.
That’s great. You might be in time for the linux517 merge window, if the patches get approved quickly.
Okay, I managed to get your git history over to the repos. 
1 Like
Looks great! I will re-orient to the Manjaro ARM repos as upstream now 
1 Like
That’s great. You might be in time for the linux517 merge window, if the patches get approved quickly.
update on the upstreaming progress: each of the ClockworkPi patches require a bit of reworking and cleanup to get into a state where they would likely be accepted. A lot of this is going through datasheets and making sure registers are properly documented and not magic values, etc., but there’s also some more complicated matters related to the correctness of some of the patches themselves.
The power management patches (i.e. for the axp288 and the rk808) have some changes which seem to only apply to the ClockworkPi DevTerm devices, so I will need to do more investigating to determine how to best limit the scope to avoid interfering with other devices using the rk808 or axp2xx drivers. These two drivers are fairly fundamental to the operation of the device, so they, at the very least, need to be working well for devicetree to be useful.
I have the display panel driver is mostly cleaned up, I just have a few lingering questions I need to ask the ClockworkPi folks.
The backlight driver may be replaceable with just pwm-backlight, which would be great. The underlying hardware supports a PWM mode over the same control-pin as the digital 1-wire mode implemented by the driver, so I want to play around with that a bit.
Finally, devicetree still needs a bit of cleanup. It’s mostly in good shape, but there’s a few things I know are setup wrong because they throw errors in dmesg.
So, just to set expectations: getting them in for 5.17 is not going to happen. I will do my best to get some stuff ready for 5.18 time frame, however.
3 Likes
Great work.
I can review the dts and follow the schematic.
Thanks.
2 Likes
I have a question/request.
I noticed that the DevTerm has a thermal printer. But I can’t get it to print after compiling and installing the thermal printer driver mentioned in the github repositoeries.
So is there gonna be any work put into getting that working as a “regular” printer on the system?