Build went great! Got an install completed, very much thanks to @veritazz’s changes!
Noticing that there’s some hardware not working yet, namely WiFi. I suspect there’s a module we might not be loading up front, but admittedly I cannot determine which chip it uses from the devicetree. will probably need to probe the armbian build. This is probably the biggest blocker, because it’s not much useful without it!
Haven’t tested sound yet, but saw something about no ALSA devices found, so suspect there’s still something missing for my attempt to have it use the es8328 driver with its es8323 (supposedly they’re pin-compatible).
There’s also some kernel stacktraces related to IRQ handling, so possible that’s related to the above issues or something else entirely.
Yes, the wifi is not working indeed. As you said, I cannot see an attempt to load a driver/firmware for it so something is missing here.
The IRQ stacktrace I have also seen. It is associated to the RK808 PMIC and this stacktrace also happens on the Armbian build. I have not checked the devicetree but I would assume this IRQ should be linked to the PMIC driver. If it is, then the driver is potentially ignoring it by not having a handler registered. Maybe this can be fixed later.
I have pushed a change to:
to permanently set the screen rotation for the X11 display. For xfce it is now fine. Not sure if this is the right way to do it or if the repo I have pushed it to is correct but maybe it is useful.
The Manjaro splash screen is also not at the right orientation but I believe this needs to come from fbcon. I have not checked the kernel command line but probably that is also easy to fix.
Another big thing I believe is the suspend to RAM and hibernation. Suspend to RAM seem to be able to enter but not exit correctly. The backlight turns on after resume but the screen stays blank. Some other people in the forum have reported similar issues for Armbian so that might be also some more fun. Hibernation does not seem to work because swap space is missing. I am not really into this but it sounds if it is possible to add some swap partition it might start working.
Sound is also an issue. Do you know in which schematic I can find the soundchip?
Regarding the IRQ backtrace. I have looked at the rk808 driver and it seems it is not making use of devm_regulator_irq_helper. So if I got it right it is not handling any interrupts from the PMIC. The datasheet indicates (just flew over it) that there are a few events that are enabled by default so this is probably the reason we see this trace. Also strange is that the default interrupt polarity is low although in the datasheet is says high. At other places also “low” is mentioned, so it looks without further digging in the datasheet this cannot be fixed easily. I wonder why the interrupt is not used. Furthermore the RTC of this chip is also not used right now in the dts files. No issue but might come in handy at later stages when we could make use of that RTC.
Ok I have checked the datasheet a little further. Active low is indeed the default for the interrupt line. There are just two different mentions in the document. Later in the register defaults it mentions active low which is correct I believe.
Sound is also an issue. Do you know in which schematic I can find the soundchip?
I believe this is the one for the latest revision: http://www.everest-semi.com/pdf/ES8323S%20DS.pdf but there’s also an earlier model datasheet mirror here: http://www.sunnyqi.com/upLoad/product/month_1306/ES8323.pdf which carries the interesting line “ES8323 is pin and size compatible to WM8988.” The “S” model just looks to have some additional inputs and different labeling, but otherwise seems to be pin compatible. I’ll pop mine open to see if it’s the “S” model or not (but it looks like that’s maybe too new to be in it) Will look more into the WM8988 codec driver and spec sheets to see just how compatible they are.
This is the best I’ve found for the es8328 (the one with mainline support): (PDF) ES8328 Datasheet - Low Power Stereo Audio CODEC (suggest going through and downloading the PDF because the preview they show is incomplete) It claims “ES8328 is pin compatible to WM8988 except the yellow highlighted pins in the following table.” which are consequently the notable differences between it and the es8323, but from a high-level it appears to be largely compatible.
Opened my DevTerm back up to try and get a closer look and figure out what chip is being used for WiFi. Not surprising, but the answer is an ap6256, same as the Pinebook Pro and a few other RK3399-based boards. Built another build, and we now have working WiFi (!!!) (probably bluetooth too, but I don’t have any easily tested BT hardware)
Yes this is probably a custom panel but I hope the changes they had to make to the driver are minimal and probably the #if 0 code can be taken in. But yeah, it needs more understanding why it was taken out. can we find out who was the original author?
Cool. It would be nice if it is possible to use some upstream driver instead. Many thanks for all the links. It is quite some reading and you seem to be very well informed. I am struggling a bit because I still do not have the schematics for the core module. It is hard to understand if the dts files are correct (or can be changed) when I do not see what is connected to where. Especially the wiring of the audio devices and the rk808. I hope the clockwork people will share these soon.
Regarding the swap I found that the created swap (zram0) is not suitable for hibernation. It looks like it is required to create a swapfile without compression or the like. So maybe just a user choice or something that can be created during image build. I will shift this aside for now.
Wow that’s cool. I was also searching but only found this link indicating some firmware issue (my dmesg output looked the same)
Good you found the solution before I would have fallen into this hole
Amazing progress. I will try to build with your profile today and try on my device.
Many thanks for all the great work!
Update: Ok I build the new image and yeah, WiFi and BT are working just great. I paired it with JBL Charge 3 speakers and played some music via soundcloud. Very nice.
The init sequence and some of the msleeps in the driver source seem to align with much of what I’ve looked at in there, and it looks like there is a sort of teardown sequence too that the driver is missing, but that the datasheet discusses.
I think I’ve ruled out the EK79030, which is used in many other 480x1280 6.86" in. MIPI displays I’ve seen on Alibaba/AliExpress, etc.
Brief update! The recently-posted schematics for the CPU and many other devices on the board (posted here) have made things a lot more clear, and there’s a few assumptions that require changing:
It’s LPDDR4, not LPDDR3 like the website says (we already figured that out though)
The audio codec is actually an es8388 and not an es8323. The es8323 driver in clockworkpi’s Armbian seems to have come forward from (I think) the rockchip 4.14 kernel back when that was the mainline driver, rather than the es8328 one. This is good news, as the es8388 is explicitly listed as compatible with the mainline es8328 driver and the datasheet is easily available. The setup for it on the device though, is a bit complex. I’ve been hacking around on the devicetree trying to get it to work, and so far I’ve gotten the headphone jack to register, but no audio yet (there’s slight white noise correlated to sound playing but nothing resembling actual audio) The codec itself is only wired to output on LOUT2 and ROUT2. the actual device switching between speaker and headphone is handled by an analog switch, which I found the datasheet for and shows up in the schematic. I am having a hard time translating it into devicetree, though, and might just in the meantime add the switching code from the es8323 drivers to the es8328 driver as a patch.
Panel wake issue has been fixed by way of a patchset sitting on the linux-rockchip tree awaiting review for mainline (fixes unbalanced clock enable/disabling). See this patchset: Rockchip SoC list - Patchwork (kernel.org) This has been applied to my tree. Display suspend and resume works smoothly. I suspect this same patch could be applied to the official Armbian port as well to fix the same display issue.
Audio is also mostly working now using the mainline es8328 driver. I need to get the mixer settings into clockworkpi-a06-post-install, but it’s all working except the switching between headphone and speaker. Right now it outputs to both. Hoping to figure this last piece out this week. (Haven’t tested microphone, but I suspect that’s working fine as there’s nothing really special there as far as I can tell.) Might require some sort of userland daemon to manage the switching if there’s not a way to model it in devicetree after all (kernel driver would also work, but would like to avoid it)
I think this is probably mostly the case. I’m using the pinebookpro setup in devicetree and ALSA UCM for reference.
the hard part has been modeling it for ALSA in devicetree. Could do something hacky and toggle the amplifier GPIO on headphone detect, but it should be working this way already when toggling “Speaker Switch” on the device. I think I connected the simple-audio-amplifier and setup pin-switches correctly on the devicetree, but “Speaker Switch” stills ends up turning off both headphone and speaker output anyway.
Perhaps it’s possible to use pin-switches for Speaker Amplifier instead? However, pinebookpro does not do that and I’d be curious as to why it would function differently if it worked that way
Afair pbp have a single amplifier which is used by speaker and also the headphone jack.
So the only way we could make it work was by alsa muting speaker when hp is detected.
Idk how it’s the audio done on devterm. Will have to look into the schematic to understand better. But if you’re saying it is the same like pbp then idk how we can control it at kernel level.
I will get the device on this weekend hopefully.
Dan recieved his device and build all the packages @m4xm4n had prepared and everything booted just fine.
He is testing xfce next. Patches are being added to the mainline kernel pkg until they’re upstreamed.