OESF Portables Forum
Model Specific Forums => Gemini PDA => Gemini PDA - Linux => Topic started by: Murple2 on February 16, 2018, 02:56:31 pm
-
Ok so rather than me banging on in lots of tangential topics about how important upstream support is, I thought I would start a new thread to discuss efforts to bring mainline linux support to our Geminis.
At this time we have less than no information about what kernel our devices will be running when shipped. Hopefully this won't remain the case for much longer!
Taking a look at the latest mainline kernel sources we can see that there is no device tree for any Helio X27 devices, so there is no upstream support at present. There is support for a couple of closely related X20 SoC devices (MT6797) which is apparently identical to the X27, just with slower clock speeds.
Here is a useful reference for the X27 chip - https://en.wikichip.org/wiki/mediatek/helio/mt6797x (https://en.wikichip.org/wiki/mediatek/helio/mt6797x)
One likely stumbling block will be wireless drivers (WiFi/LTE/BT). If we are lucky we will just need to copy across the firmware blobs from the stock linux rootfs that is supplied with the Gemini to bring the wifi and BT up. LTE will be harder probably.
One definite stumbling block is the Mali GPU. We can just forget open source 3D hardware acceleration. There has been some open source development for earlier Mali hardware (Mali 400) but we won't be seeing anything for the T880 any time soon, probably ever. However framebuffer support will be fine for a lot of use cases, and the CPU is more that fast enough for software video playback. Of course the display panel will need to be supported first.
Another question is whether we can get access to UART. Probably not but it would be awesome if we could. This is why I should have bought a second device so I could take a soldering iron to it - oh well!
Bootloader - will this be littlekernel? Will we have sources and be able to build our own binaries? If we can build our own blobs, will they need signing with keys held by Mediatek/Planet Computers? It may be that we need to patch the bootloader to bring up mainline support e.g. for proper initialisation of various hardware - clock speeds, setting MAC address, enabling virtualisation etc etc
-
+1 for upstream support.
Varti
-
I have a question since others and long ago were able to bring the wireless drivers to work "LTE,WIFI,BT etc" why would it be hard on other distro regardless of planet computers choice, the N900/Maemo would be the ideal comparison and this was way before android was something to look for ...
-
I have a question since others and long ago were able to bring the wireless drivers to work "LTE,WIFI,BT etc" why would it be hard on other distro regardless of planet computers choice, the N900/Maemo would be the ideal comparison and this was way before android was something to look for ...
It won't be hard on other distros, if we use the same kernel that ships with the Gemini (and as long as Planet Computers don't make some really silly decisions). It may be hard to get it to work with a newer kernel as there may not be drivers available in the main linux kernel source code.
-
I guess Planet Computers would love to see their dual boot OSs work with all hardware presented in the Gemini, this would be awesome for the user to switch to any system he wants and have it fully functional at least i hope that's their intentions ...
-
I just hope that Planet will actually release the full kernel sources.. for both Linux and Android if they're different
-
There has been work done on getting an X20 device to boot mainline kernel. There is a basic wiki and extensive git repo with required patches. From the looks of it a lot of this stuff has been upstreamed since 4.12. It's interesting, especially the potential for getting EAS enabled kernel.
https://github.com/freedomtan/X20-96-board/...mainline-kernel (https://github.com/freedomtan/X20-96-board/wiki/booting-mainline-kernel)
https://developer.arm.com/open-source/energ...ware-scheduling (https://developer.arm.com/open-source/energy-aware-scheduling)
-
Just checked the kernel version in android and disappointingly its a 3.19 release at the very least it is a starting point
-
Just checked the kernel version in android and disappointingly its a 3.19 release at the very least it is a starting point
sadly, that'll be the Mediatek influence.
-
Ok so rather than me banging on in lots of tangential topics about how important upstream support is, I thought I would start a new thread to discuss efforts to bring mainline linux support to our Geminis.
...
Hello everyone,
Thank you for this post @Murple2
What is the significance of getting access to the UART module?
MediaTech is selling a dev board with the X20 on it.
https://www.mediatek.com/products/developme...-board-96boards (https://www.mediatek.com/products/developmentBoards/mediatek-x20-development-board-96boards)
The dev board does not mention any GSM connectivity, although the X20 it self does
https://www.mediatek.com/products/smartphon...t6797-helio-x20 (https://www.mediatek.com/products/smartphones/mt6797-helio-x20)
I have not played with a SoC dev board before. Does anyone have experience with a SoC api?
Do they give a well documented library that gives us full access to their hardware?
Why do companies like this not want to freely give out a well documented library for users to play with? I would like to be able to just go on their website and download this library.
How does a company like Planet Computers go about developing for a SoC? They have to sign NDA? A non public dev board for the X27 exists or the X family is so similar you just use the same code.
When you say there is no upstream support, what this means is that MediaTech has not submitted any code/drivers to the linux kernel that drives their hardware. Is this correct?
Please help me understand how this scene works.
----
admin edited to snip a lot of the huge quote ~~speculatrix
-
What is the significance of getting access to the UART module?
Helpful but not a major blocker, there are other ways to get data off the device and its common to have a serial via the usb connection if you have a special cable.
MediaTech is selling a dev board with the X20 on it.
https://www.mediatek.com/products/developme...-board-96boards (https://www.mediatek.com/products/developmentBoards/mediatek-x20-development-board-96boards)
The dev board does not mention any GSM connectivity, although the X20 it self does
https://www.mediatek.com/products/smartphon...t6797-helio-x20 (https://www.mediatek.com/products/smartphones/mt6797-helio-x20)
Our dev board is essentially the gemini itself, there will be enough differences that it will likely not be much of a gain to use a working dev board as these boards allow you to start software work before you have the hardware. as the gemini is delivered already we have the hardware to test on.
I have not played with a SoC dev board before. Does anyone have experience with a SoC api?
Do they give a well documented library that gives us full access to their hardware?
Why do companies like this not want to freely give out a well documented library for users to play with? I would like to be able to just go on their website and download this library.
How does a company like Planet Computers go about developing for a SoC? They have to sign NDA? A non public dev board for the X27 exists or the X family is so similar you just use the same code.
When you say there is no upstream support, what this means is that MediaTech has not submitted any code/drivers to the linux kernel that drives their hardware. Is this correct?
Please help me understand how this scene works.
Kernel development is a bit different to userspace development, there is no 'library' that we can drop in and use, and the quality of most chip vendors code is questionable at best. The major problems are that the 3.19 kernel is real old and has diverged significantly, in addition the android 3.19 kernel had a large amount of custom written parts in it that diverged from the base 3.19
There are some things we can leverage cross vendor, eg cpufreq stuff and some graphical/GPU stuff as this is mostly licesed cores that only really diffre by locaiton in memory. In addition the armv8 series came up with a spec that is sort of like the PC-XT spec and standardizes armv8 designs allowing a lot of power and boot code to be reused. the real issues will include the following
* Board specif cbring up
* memory timings
* SD reader driver
* usb type c drivers (still in flux in 4.15, will not really be stable 100% complete till 4.18 or end of this year)
* wif drivers (MT7610U/USB is supported but not confirmed this is the chip we use)
* 4g modem
* Keyboard driver
* IIO Sensors (gyroscope/compuss)
even once we do get access to the source (if we do) this si not going to be a simple copy and paste job and will likely be without vendor documentation
I would have paid 2x the current costs for an exynos based chip as i know samsung upstreams their drivers in mainline before devices hit production making ti a very simple affair to get a newer kernel working. there also would not be these limitations with the usb ports and chargng/displaying whihc is one of the major points of contention for me.
(mainline means that the kernels on kernel.org contain the drivers required to run the board)
still poking things at my end and hope to come up with a todo list soon but if anyone has a link to the kernel sources and is willing to share let me know as there are some drivers i would not mind having on hand
-
I think Linux on Gemini is using 3.18.41, not the android kernel
https://developer.planetcom.co.uk/showthrea...id=5&page=2 (https://developer.planetcom.co.uk/showthread.php?tid=5&page=2)
-
@Da_Blitz
Thank you for your response. I have a better understanding and a sense of direction.
-
Our dev board is essentially the gemini itself, there will be enough differences that it will likely not be much of a gain to use a working dev board as these boards allow you to start software work before you have the hardware. as the gemini is delivered already we have the hardware to test on.
Except to do kernel work (i.e. mainlining) you really need access to a UART console, which it looks like we won't have without soldering to test points (https://www.oesf.org/forum/index.php?s=&showtopic=35013&view=findpost&p=286153). That said, it looks like a lot of work has been done with the X20 on the 96 board so if the kernel is mainly brought up, you could work on drivers and such with kernel output going over a USB port or something, maybe even the MicroSD card port.
-
For info on Debian 9 for Gemini, check out the Gemian dev pages:
https://github.com/gemian/gemini-keyboard-apps/wiki/DebianTP (https://github.com/gemian/gemini-keyboard-apps/wiki/DebianTP)
For kernel compilation:
https://github.com/gemian/gemini-keyboard-a...rnelCompilation (https://github.com/gemian/gemini-keyboard-apps/wiki/KernelCompilation)
And if you see posts in the OESF, Gemini PDA, Linux OS forum section here by Adam Boardman, he's the lead for the project.
HTH,
Mark
-
For info on Debian 9 for Gemini
For kernel compilation
Hi Mark,
This thread is about mainling support for the Gemini. That means sending patches upstream to the Linux developers so that Linus' releases contain support for the Gemini. This can be a very involved and technical process and can take a long time.
Instructions on how to install Debian or compile the kernel aren't much help but thank you :-)
Cheers,
Bob
-
For info on Debian 9 for Gemini
For kernel compilation
Hi Mark,
This thread is about mainling support for the Gemini. That means sending patches upstream to the Linux developers so that Linus' releases contain support for the Gemini. This can be a very involved and technical process and can take a long time.
Instructions on how to install Debian or compile the kernel aren't much help but thank you :-)
Cheers,
Bob
Got it, Bob!
Thanks,
Mark
-
I had a look at whether any of the patches here
https://github.com/freedomtan/patches-mainl...ard/tree/master (https://github.com/freedomtan/patches-mainline-x20-96board/tree/master)
had been accepted in the kernel and indeed it looks like mainline now supports the X20 development board:
https://git.kernel.org/pub/scm/linux/kernel...ep&q=mt6797 (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/?qt=grep&q=mt6797)
https://git.kernel.org/pub/scm/linux/kernel.../mt6797-evb.dts (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt6797-evb.dts)
The X20 is MT6797, the X25 is MT6797T and the X27 is MT6797X (https://en.wikichip.org/wiki/Special:SearchByProperty/:family/Helio).
So the bulk of the basic work is done. According to wikichip.org, the X27 is "identical" to the X20. I'm curious as to just how "identical" and whether a kernel built for the X20 will run on an X27.
The board name is apparently "aeon6797_6m_n", according to the Lineage kernel config (https://github.com/lineage-geminipda/android_kernel_planet_mt6797/blob/cm-14.1/arch/arm64/configs/lineage_gemini_defconfig). The .dts file for the 3.18 Android kernel is here:
https://github.com/gemian/gemini-linux-kern...on6797_6m_n.dts (https://github.com/gemian/gemini-linux-kernel-3.18/blob/96a5383d8796a6a067cdf29cd5566dd54a84f06f/arch/arm64/boot/dts/aeon6797_6m_n.dts)
Unfortunately, nearly all of the entries are 'compatible = "mediatek,...";' meaning it's probably all mediatek hacks as drivers.
-
TheKit managed to boot a mainline X20 kernel at the gemini - almost, stuck at switching to user mode (or initrd)
I collected some informations at https://github.com/gemian/gemini-keyboard-a...LinuxMainlining (https://github.com/gemian/gemini-keyboard-apps/wiki/LinuxMainlining) . Here is also a boot log.
-
I'm hopeful we will see kernel 4.something for the Gemini, maybe along with a release of Android O or P, but I don't think it will be any time soon. Long term, we'll be reliant on third parties getting newer kernels to run on the Mediatek SoC, because Mediatek will have moved on.
-
I think that it is indeed possible to get all needed bits mainlined. Most, if not all components in kernel are OS, they need "only" to be fit to get into mainline kernel (and if only into staging as a first step) And for mali - the friends at panfrost are very active.
Overall I think we are at a position where the linux-sunxi.org people were a few years ago. And nowadays, almost all things are running with a mainline kernel.
-
This is a page that contains the state of the mainlining project (edit: didn't read the last page of comments it seems, mifritscher already mentioned this):
https://github.com/gemian/gemini-keyboard-a...LinuxMainlining (https://github.com/gemian/gemini-keyboard-apps/wiki/LinuxMainlining)
Also to point out that Omegamoon on irc managed to get UART console out of the kernel via a USB cable using a modified version of these instructions (using an FTDI): http://www.stevenhoneyman.co.uk/2014/11/mt...ebug-cable.html (http://www.stevenhoneyman.co.uk/2014/11/mtk-mediatek-debug-cable.html)
It also sounds like just getting a pound shop USB C charge+data cable and cutting it open and wiring to the serial port on a Raspberry Pi could also work for those without an FTDI but a RPi.
-
TheKit managed to boot a mainline X20 kernel at the gemini - almost, stuck at switching to user mode (or initrd)
I collected some informations at https://github.com/gemian/gemini-keyboard-a...LinuxMainlining (https://github.com/gemian/gemini-keyboard-apps/wiki/LinuxMainlining) . Here is also a boot log.
The bootlog is 404, does anyone have another link to it?
I have been trying to boot mainline now I have a UART cable but I keep getting device tree not found error. I was creating boot images with mkbootimg and using the --dt option to specify the dtb, but i've also tried appending the dtb to the kernel image. Both methods give me the same error. IMO appending the dtb to the kernel is hacky and very un-futureproof, does anyone know why we are doing this? Is it a limitation of our version of lk? I know old arm boards did this as a workaround for nonexistant or buggy device tree support in their bootloaders, but this is going back years. It shouldnt be required in the world of arm8 and mature multiplatform support in the kernel
-
I have been trying to boot mainline now I have a UART cable but I keep getting device tree not found error. I was creating boot images with mkbootimg and using the --dt option to specify the dtb, but i've also tried appending the dtb to the kernel image. Both methods give me the same error. IMO appending the dtb to the kernel is hacky and very un-futureproof, does anyone know why we are doing this? Is it a limitation of our version of lk? I know old arm boards did this as a workaround for nonexistant or buggy device tree support in their bootloaders, but this is going back years. It shouldnt be required in the world of arm8 and mature multiplatform support in the kernel
You need to append dtb to Image.gz. MediaTek's lk bootloader actually handles device tree (there is no appended dtb support for aarch64 in kernel), but in current implementation bootloader searches for appended device tree. The reason is that --dt option isn't/wasn't standard for abootimg format, it's generally used only by Qualcomm devices.
-
You need to append dtb to Image.gz. MediaTek's lk bootloader actually handles device tree (there is no appended dtb support for aarch64 in kernel), but in current implementation bootloader searches for appended device tree. The reason is that --dt option isn't/wasn't standard for abootimg format, it's generally used only by Qualcomm devices.
Thanks, I will give this another try. I was doing this:
cat Image.gz dtb_file > Image-dtb >
Is this correct? I also tried gunzipping the Image, appending and the gzipping it back up. But I dont think thats right..?
-
Thanks, I will give this another try. I was doing this:
cat Image.gz dtb_file > Image-dtb >
Is this correct? I also tried gunzipping the Image, appending and the gzipping it back up. But I dont think thats right..?
cat Image.gz dtb_file > Image.gz-dtb is the correct way, yes, this worked for me.
-
When I tried
make Image.gz-dtbit just worked
-
When I triedmake Image.gz-dtbit just worked
Is that with the mainline kernel source?
-
Hm, no.
-
hmm, 4.19 seems to have a lot of cool stuff for x20 /mt 6797 https://www.phoronix.com/scan.php?page=news...-4.19-ARM-Early (https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.19-ARM-Early)