Hi!
It seems that with kernel 4.16 simple framebuffer should work on A64. See: https://mail-archive.com/linux-kernel@vger.kernel.org/msg1574304.html
So I'm thinking now might be a good time to try the mainline kernel on the teres - at least we should see something even without serial console / debug connection. However first thing I noticed is: There isn't even a device tree file for the teres1 yet. (Actually quite surprising: I recall olimex sending a number of prototype laptops to developers before sales started. How did these people get anything done without even a device tree file to boot the thing?)
I just checked and compared the devicetree files from the official software image (seems to be some general hardware definition from allwinner, not actually describing the real HW - but maybe some things have been tweaked to get the laptop working) and sun50i-a64-olinuxino.dts from mainline kernel. There seem to be lots of differences in regulator definitions for example. I guess merging these will not be entirely trivial. Has somebody already started working in this?
I guess I will start with sun50i-a64-olinuxino.dts and see what's different in a64-teres. What bothers me a bit is, that I basically need to get it right on the first attempt: If the kernel doesn't boot, I will get little feedback to figure out what's wrong, because I can't attach a serial cable to the laptop.
OTOH it probably would make sense for olimex to take the lead in this - after all you guys should know the information in the device tree file already. Actually it would be very reasonable if an open hardware product came with a proper device tree file by default. After all the device tree is just a machine readable description of the product.
Harald
Is this helpful at all? https://linux-sunxi.org/Linux_mainlining_effort
This page is very helpful - it is actually how I found the patch I linked in the first post.
However it doesn't provide any information about people working on a64-teres board support.
Why can't you attach a serial cable?
Quote from: khumarahn on February 18, 2018, 03:30:56 PM
Why can't you attach a serial cable?
How would you go about it?
AFAICS the debug connector is the headphone connector with some line (GPIO?) selecting the function. I don't know how setup debug output and even if I knew, I'd net to get the right connector somewhere and then I'm still not confident to do it right: I'd hate to fry my shiny new laptop because I got some wiring wrong.
But if you got a serial console/debug console working, maybe you can help me out with testing?
Have you seen the efforts of the Armbian guys on the Pine64: https://forum.armbian.com/topic/1917-armbian-running-on-pine64-and-other-a64h5-devices/?page=10&tab=comments#comment-34910 ?
The efforts around pine64 have provided lots of drivers that we need for the teres. We basically get a free ride here. However of course they wont write a device tree file for us: We need a proper device tree to tell the kernel to actually use these drivers ...
JFTR: User dddddd from the olimex irc channel (user deesix here on the forum) has figured out how to make a debug cable for the theres: (Log is here: https://www.olimex.com/irc?date=2018-01-20)
We are now working together to get mainline kernels booting.
Harald
Good news everybody: deesix and me got the debian kernel to boot (quite easy) and with a bit of tweaking things and enabling a few more drivers also got the display working on mainline kernel (a bit tedious) with simple framebuffer together with most of the hardware in the teres.
I will make a debian image available publicly after the weekend for everybody to test, develop on and use. Patches probably will be sent to linux (device tree file) and debian (enabling a few modules in the arm64 kernel package) soon, but early feedback might be helpful to find the less obvious issues.
great news! Can you share the kernel sources with compilation instructions?
What still does not work?
Quote from: khumarahn on March 10, 2018, 06:00:14 PM
great news! Can you share the kernel sources with compilation instructions?
I think a vanilla 4.15.x kernel should work (though actually we used different 4.16 release candidates most of the time).
I'm still in the process of cleaning up what we did (removing all the dead ends, etc.) - after that, I will send patches upstream and can link the kernel .config here. I can also link all patches here.
Quote
What still does not work?
On the annoying side:
- After the system goes into suspend (eg. the laptop lid is closed), the power button doesn't wake it up anymore, nor does plugging in power. (The power button is recognised as such by linux and to shut down the system works.) I have declared the AXP803 as wakeup-souce in DT, but either that doesn't work or suspend creates some broken state. (Probably the former, because I guess a broken suspend state would cause a reboot?). I didn't try other wakeup sources though.
- Many other features of the AXP803 and in particular fuel gauge (quite important for a mobile device IMO) haven't been activated yet. Mostly because it is unclear if they are compatible with older AXP version or need changes to the driver. The documentation is somewhat sparse on which featurs of which AXP version are actually supported. Shouldn't be too difficult to work on this however, if somebody is inclined to do so.
Other things:
- simple framebuffer on HDMI needs more work - especially on the bootloader side.
- I didn't look into sound at all. Might be easy, might not be easy. It works on H3, so might be possible to use the same drivers on A64 or at least easy to port.
JFTR: Here is the link to all the patches sent to linux:
https://lkml.org/lkml/2018/3/12/653
(Don't let that discourage you to report any problems. Would be the first time that such a patch from me passes review on the first attempt.)
Great, lambda. Icenowy sent a PR with a simplified ATF patch to apritzel's repo (https://github.com/apritzel/arm-trusted-firmware/pull/7).
Thanks! both!
Quote from: deesix on March 12, 2018, 10:27:37 PM
Great, lambda. Icenowy sent a PR with a simplified ATF patch to apritzel's repo (https://github.com/apritzel/arm-trusted-firmware/pull/7).
Nice, I wasn't aware of that. The calls to udelay() are missing though. I guess she knows what she is doing - she has worked on supporting this chip the most it seems.
Quote from: lambda on March 12, 2018, 09:29:16 PM
JFTR: Here is the link to all the patches sent to linux:
https://lkml.org/lkml/2018/3/12/653
v2 https://lkml.org/lkml/2018/3/15/664
Thanks!
I still did not have time to try the mainline kernel... but I really miss it. For example, it should have a good implementation of f2fs.....
How is the mainlining going? Am I correct that the mainline-kernel debian image is usable except for the sound?
Quote from: khumarahn on April 09, 2018, 03:21:23 PM
How is the mainlining going?
The mainlineing itself: Quite good. All of our work (or something equivalent by others) has been accepted by now except for a pwm DT node. So you will need a custom DT even with 4.17, to get a working backlight.
Also support of mainline u-boot is still missing, but that's other peoples work and their decision when to submit the patches ...
There is now a guide on the debian wiki with some extra details:
https://wiki.debian.org/InstallingDebianOn/Olimex/Teres-I
Quote
Am I correct that the mainline-kernel debian image is usable except for the sound?
usable: absolutely. I'm booting more often into the debien image then into preinstalled ubuntu these days.
missing: sound, HDMI (looks like this might come around soon), battery driver (might be easy, nobody looked into that yet), cpu frequency scaling.
Also currently there is no way to wake up the system from suspend - but nobody tried hard to get it working either, so might be something trivial.
HTH,
Harald
Quote
missing: sound, HDMI (looks like this might come around soon), battery driver (might be easy, nobody looked into that yet), cpu frequency scaling.
There are some patch around for battery driver:
https://lwn.net/Articles/734371/
But they are not yet in mainline kernel.