[DEV] [R&D] Linux 3.14 kernel for Exynos5420-based devices [WIP] [SM-P600/601] - Galaxy Note 10.1 (2014 Edition) Original Android D

I thought I'd post an update since some progress has been made, though there are still some things missing.
The current plan is to make a unified kernel for all Universal 5420-based devices, including our Note, the 12.2, and Tab S. I've managed to forward-port a lot of the necessary drivers to Linux 3.14. Most come from Samsung's Universal 5422, 5430, 5433 and 7420 kernels (Linux 3.10), while other stuff such as the Mali GPU drivers were taken from one of Linaro's 3.14 kernel trees along with Mali platform support for the Exynos5420-based Arndale Octa board. Currently I have only been focusing on SM-P600 support since that's the tablet I will be testing it on, but once I make sure it runs I'll be adding in support for other devices as well.
What's done so far:
* Maxim max77802 drivers (PMIC, regulator)
* Maxim max77888 drivers (PMIC, MUIC, LED, regulator, haptic)
- These will be used as a base for max77803 support since it's essentially the same driver
* Samsung's TN extension features
* Samsung's USB notify layer
* Samsung's battery/charger/fuelgauge drivers
Also:
* The sii8240 driver has been pulled in, though it doesn't compile yet
* The sensors are all supported in mainline so their drivers can easily be cherry-picked
Todo:
* Port over the LCD driver (LSL101DL01 / LSL122DL01)
- It needs to be adapted to the new display port driver (exynos-dp) instead of the old s5p-dp driver.
- It also requires device tree support, which is absent in 3.4, whereas board files are not supported in 3.14.
- This is beyond my skill and knowledge so if there's anyone reading this who can- and is willing to help please contact me.
* Write a board-specific DT blob.
* Probably a few more things that I'm forgetting.
Source/changelog: here
Feel free to fork this if you wish to help with development, just make sure to notify me if you do.
Original post:
Hi guys,
As some of you may know, the Linux kernel for ARM has long migrated from the use of board files to the use of device tree blobs for providing hardware descriptions to the kernel. Still, Samsung seems to insist on relying on all this unnecessary junk code instead of migrating to the use of device trees for their Exynos devices. Currently, the only Exynos5420-based device trees in existance are for development boards such as the Arndale Octa and the SMDK5420. No device tree exists for the UNIVERSAL5420 board and its variants which are found in the Galaxy Note and Tab series. So, I decided to write one.
I am no programming expert but seeing as the device tree syntax is not that complex, I thought, how hard can it be? The hardest part is basically combing through all the board files and searching for whatever stands up as being relevant in the device tree format as well as figuring out the correct unit-addresses, most of which seem to be listed in /arch/arm/mach-exynos/include/mach/map.h.
I'm using the SMDK5420 device tree as a base since it seems to be a watered-down development version of the UNIVERSAL5420 board. Still, there's a lot of stuff that needs to be added in and certain bits also need replacing. So far I have added in the nodes for the Maxim MAX77802 PMIC and its regulators as well as the nodes for the charger and a few 'skeletons' for the screen, the ARM Mali GPU and the Wolfson WM5102 codec. Some of these may still have incorrect unit addresses and other bits may still be incorrect or unnecessary.
If this project becomes successful it might:
Allow us to run higher kernel versions (i.e. above Linux 3.4) on our devices.
Make it easier to create ports of open source bootloaders such as u-boot or kexecboot for our devices.
Open up new doors in getting Global Task Scheduling (big.LITTLE MP) to work on the universal5420, as has been achieved on exynos5420-based development boards.
The project is located in my git repository here along with the SM-P600 board files and other references.
This is obviously still in early development but if anyone here who is familiar with the device tree syntax is willing to review my code and provide some constructive criticism it would be much appreciated.
For further information on the device tree and its syntax, here are some helpful links:
http://www.devicetree.org/Device_Tree_Usage
https://www.power.org/documentation/epapr-version-1-1/
https://www.kernel.org/doc/Documentation/devicetree/
http://lwn.net/Articles/572692/ (Device trees I: Are we having fun yet?)
http://lwn.net/Articles/573409/ (Device trees II: The harder parts)
Click to expand...
Click to collapse
XDA:DevDB Information
Unified Exynos 5420 Kernel, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain
Source Code: https://github.com/sigma-1/universal5420-device-tree
Kernel Special Features:
Version Information
Status: Testing
Created 2014-10-31
Last Updated 2015-08-27

---

Well ... Wish you luck with the Development ...
Andmoreagain said:
Hi guys,
As some of you may know, the Linux kernel for ARM has long migrated from the use of board files to the use of device tree blobs for providing hardware descriptions to the kernel. Still, Samsung seems to insist on relying on all this unnecessary junk code instead of migrating to the use of device trees for their Exynos devices. Currently, the only Exynos5420-based device trees in existance are for development boards such as the Arndale Octa and the SMDK5420. No device tree exists for the UNIVERSAL5420 board and its variants which are found in the Galaxy Note and Tab series. So, I decided to write one.
I am no programming expert but seeing as the device tree syntax is not that complex, I thought, how hard can it be? The hardest part is basically combing through all the board files and searching for whatever stands up as being relevant in the device tree format as well as figuring out the correct unit-addresses, most of which seem to be listed in /arch/arm/mach-exynos/include/mach/map.h.
I'm using the SMDK5420 device tree as a base since it seems to be a watered-down development version of the UNIVERSAL5420 board. Still, there's a lot of stuff that needs to be added in and certain bits also need replacing. So far I have added in the nodes for the Maxim MAX77802 PMIC and its regulators as well as the nodes for the charger and a few 'skeletons' for the screen, the ARM Mali GPU and the Wolfson WM5102 codec. Some of these may still have incorrect unit addresses and other bits may still be incorrect or unnecessary.
If this project becomes successful it might:
Allow us to run higher kernel versions (i.e. above Linux 3.4) on our devices.
Make it easier to create ports of open source bootloaders such as u-boot or kexecboot for our devices.
Open up new doors in getting Global Task Scheduling (big.LITTLE MP) to work on the universal5420, as has been achieved on exynos5420-based development boards.
The project is located in my git repository here along with the SM-P600 board files and other references.
This is obviously still in early development but if anyone here who is familiar with the device tree syntax is willing to review my code and provide some constructive criticism it would be much appreciated.
For further information on the device tree and its syntax, here are some helpful links:
http://www.devicetree.org/Device_Tree_Usage
https://www.power.org/documentation/epapr-version-1-1/
https://www.kernel.org/doc/Documentation/devicetree/
http://lwn.net/Articles/572692/ (Device trees I: Are we having fun yet?)
http://lwn.net/Articles/573409/ (Device trees II: The harder parts)
XDA:DevDB Information
UNIVERSAL5420 Device Tree, Kernel for the Samsung Galaxy Note 10.1 (2014 Edition)
Contributors
Andmoreagain
Kernel Special Features:
Version Information
Status: Testing
Created 2014-10-31
Last Updated 2014-11-01
Click to expand...
Click to collapse
Dear friend , maybe @xluco can help us get the device tree so that we can clear a way for AOSP and such ROMs to our SM-P600/1 ... Good Luck
With Best Wishes
Hitman1376​

---

hitman1376 said:
Dear friend , maybe @xluco can help us get the device tree so that we can clear a way for AOSP and such ROMs to our SM-P600/1 ... Good Luck
With Best Wishes
Hitman1376​
Click to expand...
Click to collapse
Thanks, unfortunately I'm not that familiar with the android source code. At least it will probably be easier to gather all the device information once we get everything into a single file.
But anyway, I did an adb pull of the /dev, /proc and /sys directories from my p600. Found lots of useful info, especially for calculating some of the interrupt values. The gpu node is also complete, although I have yet to update my repo.
I'm also going to grab myself a development board tomorrow in hopes of getting a better picture of what I'm doing. I need to be able to visualize things as I work on this stuff.

---

Well ... Finally Good news ...
Andmoreagain said:
Thanks, unfortunately I'm not that familiar with the android source code. At least it will probably be easier to gather all the device information once we get everything into a single file.
But anyway, I did an adb pull of the /dev, /proc and /sys directories from my p600. Found lots of useful info, especially for calculating some of the interrupt values. The gpu node is also complete, although I have yet to update my repo.
I'm also going to grab myself a development board tomorrow in hopes of getting a better picture of what I'm doing. I need to be able to visualize things as I work on this stuff.
Click to expand...
Click to collapse
Well ... seems like you know what to do ( And managed it out well :good: ... I took a look into the GitHub ... Good work :good: ) ... but , if there were any problems , I would be glad to help ( I own a P601 but it doesn't matter ... their almost the same ... ) ...
Wish you luck with the Development
Hitman1376​

---

Excellent project mate, good luck! I'd offer some support but I don't know a single thing about device trees

---

Some updates!
Hey guys!
I had to take a long break from this project due to school and other stuff, but I'm at it again. I have done some homework along the way, and since there now exists a flattened device tree for the universal5422 board and several newer Exynos devices, it makes this work much easier since the universal5420 and 5422 are identical in many aspects, though not completely.
Now, to better explain what this project is all about and to clear up some confusion, a flattened device tree or a device tree blob is not the same thing as the android "device tree", required for compiling android for a specific device. The so-called flattened device tree is compiled as a separate binary along the kernel and describes the hardware of the device to the kernel in order to load the correct device drivers. In the past, ARM devices had to rely on so-called board files, such as all the board-*.c and dev-*.c files found in the arch/arm/mach-exynos directory of the stock kernel's source code for our device. This was a problematic solution, mostly because:
A) It meant that each vendor had to throw together a special branch of linux for every single device, containing a huge amount of device-specific code in order to load the necessary drivers.​
B) There is an ongoing project, called the Android Mainlining Project, and I quote:
The goal of this project is to ultimately mainline all patches required to run the current released version of Android. The purpose of mainlining these patches is 3-fold:
to allow a developer to use the latest released version of the Linux kernel to run an Android system, without requiring patches to their kernel
to make it possible to develop drivers and board support features against either an Android kernel release or a kernel.org kernel release, with little or no modifications or conditional code
to reduce or eliminate the burden of maintaining independent patches from release to release for Android kernel developers
To "mainline" a patch means to have it included in Linus Torvalds' kernel.org kernel, in a released (non-rc) version.​
Click to expand...
Click to collapse
For some basic info regarding the Board File to Device Tree Migration, this document would be a good start.
"The Device Tree is a data structure for describing hardware. Rather than hard coding every detail of a device into an operating system, many aspects of the hardware can be described in a data structure that is passed to the operating system at boot time."
Click to expand...
Click to collapse
Now, some updates:​
I finally have a decent picture of each and every device available on our board, their addresses, and configurations. I have also documented which device is connected to which I2C (inter-integrated circuit) bus, but there are still several things that need to be figured out regarding this whole I2C labyrinth.
To begin with, the aliases listed in the generic exynos5420.dtsi device tree are as follows:
aliases {
mshc0 = &mmc_0;
mshc1 = &mmc_1;
mshc2 = &mmc_2;
pinctrl0 = &pinctrl_0;
pinctrl1 = &pinctrl_1;
pinctrl2 = &pinctrl_2;
pinctrl3 = &pinctrl_3;
pinctrl4 = &pinctrl_4;
i2c0 = &i2c_0;
i2c1 = &i2c_1;
i2c2 = &i2c_2;
i2c3 = &i2c_3;
i2c4 = &hsi2c_4;
i2c5 = &hsi2c_5;
i2c6 = &hsi2c_6;
i2c7 = &hsi2c_7;
i2c8 = &hsi2c_8;
i2c9 = &hsi2c_9;
i2c10 = &hsi2c_10;
gsc0 = &gsc_0;
gsc1 = &gsc_1;
spi0 = &spi_0;
spi1 = &spi_1;
spi2 = &spi_2;
usbdrdphy0 = &usbdrd_phy0;
usbdrdphy1 = &usbdrd_phy1;
};
Click to expand...
Click to collapse
As you can see, the I2C's are numbered from 0 to 10, making them 11 in total, where i2c's 4 - 10 apparently have the "high speed" or hs setting enabled.
This is a bit confusing to me, because the I2C buses that are actually in use, as seen in rootfs/sys/bus/i2c/devices, gives a different set of numbers:
i2c-0
i2c-1
i2c-3
i2c-7
i2c-8
i2c-10
i2c-17
i2c-18
i2c-22
i2c-24
Click to expand...
Click to collapse
And here are the devices assigned to them:
i2c-0
[email protected]
[email protected] (screen)
i2c-1
[email protected]
i2c-3
[email protected]
[email protected]
[email protected]
[email protected]
i2c-7
[email protected]
i2c-8
[email protected] (the digitizer or epen)
(?)@9 // device name not listed, but the address is the same as that of the maxim pmic on i2c-7 //
i2c-10
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
i2c-17
(?)@25
(?)@48
[email protected]
i2c-18
[email protected]
i2c-22
[email protected]
i2c-24
[email protected]
[email protected]
In the "drivers" folder I also found the following, but they were not assigned to a bus or an address:
exynos_edid
exynos_hdcp
ir-kbd-i2c
Click to expand...
Click to collapse
Anyway, if the i2c buses only go from 0 - 10 in the generic Exynos5420 device tree, then why do we also have 17, 18, 22 and 24 appearing here?
Furthermore, here is how their addresses are listed in the stock source code (arch/arm/mach-exynos/include/map.h)
#define EXYNOS5_PA_IIC(x) (0x12C60000 + ((x) * 0x10000))
#define EXYNOS5420_PA_HSIIC0 0x12CA0000
#define EXYNOS5420_PA_HSIIC1 0x12CB0000
#define EXYNOS5420_PA_HSIIC2 0x12CC0000
#define EXYNOS5420_PA_HSIIC3 0x12CD0000
#define EXYNOS5420_PA_HSIIC4 0x12E00000
#define EXYNOS5420_PA_HSIIC5 0x12E10000
#define EXYNOS5420_PA_HSIIC6 0x12E20000
Click to expand...
Click to collapse
Aaaand if we look into rootfs/proc/iomem, we find this:
12c60000-12c60fff : s3c2440-i2c
12c70000-12c70fff : s3c2440-i2c.1
12c70000-12c70fff : s3c2440-i2c
12c90000-12c90fff : s3c2440-i2c.3
12c90000-12c90fff : s3c2440-i2c
12cd0000-12cd0fff : exynos5-hs-i2c
12e00000-12e00fff : exynos5-hs-i2c
12e20000-12e20fff : exynos5-hs-i2c.6
12e20000-12e20fff : exynos5-hs-i2c
12c60000-12c60fff : s3c2440-i2c.0
12cd0000-12cd0fff : exynos5-hs-i2c.3
12e00000-12e00fff : exynos5-hs-i2c.4
Click to expand...
Click to collapse
I'm currently working on building CM12 with some additional packages such as i2c-tools and some extra kernel debugging features. But in the meantime, if anyone here can help solve this entire I2C puzzle then it would be of great help. We have the devices, their addresses, etc., but which bus is which compared to the generic Exynos5420 device tree "header" (for lack of a better term) is my biggest question at the moment.
If the final outcome of this project actually works, then there won't be anything standing in the way of compiling, say, linux-linaro-lsk-v3.10-android with full HMP support. Sure, some proprietary kernel drivers may have to be integrated such as the Mali drivers but I have already tried to bake them into linux 3.14 and it compiled without any errors whatsoever. Hell, we might even be able to finally upgrade them by grabbing the latest sources from ARM! In any case it's worth a try because f*ck the sammy police!

---

So as far as I can tell, Samsung have decided that despite having five free I2C ports, they're going to move four of their I2Cs to be bit-banged on GPIOs. I think this should be sufficient for those four (11, 17, 22 and 24) in a device tree:
Code:
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpd1 4 0 /* sda */
&gpd1 5 0 /* scl */
>;
i2c-gpio,delay-us = <1>;
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpb3 6 0 /* sda */
&gpb3 7 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa1 5 0 /* sda */
&gpa1 4 0 /* scl */
>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa2 2 0 /* sda */
&gpa2 3 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
};
The addresses of the other ports appear to agree with the existing code in exynos5420-pinctrl.dtsi:
Code:
s3c2440-i2c.0 = [email protected]
s3c2440-i2c.1 = [email protected]
s3c2440-i2c.2 = [email protected]
s3c2440-i2c.3 = [email protected]
exynos5-hs-i2c.0 = [email protected]
exynos5-hs-i2c.1 = [email protected]
exynos5-hs-i2c.2 = [email protected]
exynos5-hs-i2c.3 = [email protected]
exynos5-hs-i2c.4 = [email protected]
exynos5-hs-i2c.5 = [email protected]
exynos5-hs-i2c.6 = [email protected]
-d

---

Well, HMP is trully what's left missing from this tab. I mean we've got good roms, AOSP support, having its hardware completely unlocked would be the last piece of the puzzle at it were ... Personally it would give me smooth Linux via framebuffer, at it stands it's CPU (core) limited, often maxing all 4 cores, having 8 cores to stretch its legs even with throttling in place (it) would be a blessing. Smooth desktop OS on a Note tablet would be a first.
Hmmm, having no (significant) kernel experience my support would be confined to that of encouragement ... oh well. Good luck to you sir!

---

I'm out of town and left my laptop at home, but here's a new draft for the iic nodes I made on my phone:
Code:
[email protected] {
[email protected] {
};
[email protected] {
};
};
[email protected] {
[email protected] {
};
};
[email protected] {
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
};
[email protected] {
clock-frequency = <400000>;
status = "okay";
[email protected] {
compatible = "maxim,max77802";
interrupt-parent = <&gpx0>;
interrupts = <3 IRQ_TYPE_LEVEL_HIGH>;
pinctrl-names = "default";
pinctrl-0 = <&max77802_irq>;
wakeup-source;
reg = <0x9>;
voltage-regulators {
buck1_reg: BUCK1 {
regulator-name = "vdd_mif";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck2_reg: BUCK2 {
regulator-name = "vdd_arm";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1500000>;
regulator-apply-uV;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck3_reg: BUCK3 {
regulator-name = "vdd_int";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck4_reg: BUCK4 {
regulator-name = "vdd_g3d";
regulator-min-microvolt = <700000>;
regulator-max-microvolt = <1400000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
buck6_reg: BUCK6 {
regulator-name = "vdd_kfc";
regulator-min-microvolt = <800000>;
regulator-max-microvolt = <1500000>;
regulator-always-on;
regulator-boot-on;
regulator-ramp-delay = <12000>;
regulator-initial-mode = <1>;
};
ldo2_reg: LDO2 {
regulator-name ="VMEM2_1.2V_AP";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo3_reg: LDO3 {
regulator-name = "VCC_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo4_reg: LDO4 {
regulator-name = "VMMC2_2.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo5_reg: LDO5 {
regulator-name = "VHSIC_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo6_reg: LDO6 {
regulator-name = "VXPLL_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo8_reg: LDO8 {
regulator-name = "VMIPI_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo9_reg: LDO9 {
regulator-name = "VADC_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo10_reg: LDO10 {
regulator-name = "VMIPI_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo11_reg: LDO11 {
regulator-name = "VDDQ_PRE_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo12_reg: LDO12 {
regulator-name = "VUOTG_3.0V_AP";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo14_reg: LDO14 {
regulator-name = "VABB1_1.8V_AP";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo15_reg: LDO15 {
regulator-name = "VHSIC_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo17_reg: LDO17 {
regulator-name = "VG3DS_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo18_reg: LDO18 {
regulator-name = "CAM_ISP_SENSOR_IO_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo19_reg: LDO19 {
regulator-name = "VT_CAM_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo23_reg: LDO23 {
regulator-name = "KEY_LED_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo24_reg: LDO24 {
regulator-name = "CAM_AF_2.8_PM";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo25_reg: LDO25 {
regulator-name = "VCC_3.3V_MHL";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo26_reg: LDO26 {
regulator-name = "VCC_3.0V_MOTOR";
regulator-min-microvolt = <3000000>;
regulator-max-microvolt = <3000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo27_reg: LDO27 {
regulator-name = "VSIL_1.2A";
regulator-min-microvolt = <1200000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo28_reg: LDO28 {
regulator-name = "VCC_1.8V_MHL";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo29_reg: LDO29 {
regulator-name = "TSP_VDD_1.8V";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo30_reg: LDO30 {
regulator-name = "VMIFS_1.0V_AP";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1000000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo32_reg: LDO32 {
regulator-name = "IRLED_3.3V";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo33_reg: LDO33 {
regulator-name = "VCC_2.8V_AP";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <2800000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
ldo35_reg: LDO35 {
regulator-name = "CAM_SENSOR_CORE_1.2V";
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1200000>;
regulator-always-on;
regulator-initial-mode = <1>;
};
};
};
};
[email protected] {
[email protected] {
};
};
[email protected] {
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpd1 4 0 /* sda */
&gpd1 5 0 /* scl */
>;
i2c-gpio,delay-us = <1>;
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpb3 6 0 /* sda */
&gpb3 7 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa1 5 0 /* sda */
&gpa1 4 0 /* scl */
>;
i2c-gpio,delay-us = <2>;
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
};
[email protected] {
compatible = "i2c-gpio";
gpios = <&gpa2 2 0 /* sda */
&gpa2 3 0 /* scl */
>;
// i2c-gpio,delay-us not specified?
#address-cells = <1>;
#size-cells = <0>;
[email protected] {
};
[email protected] {
};
};
EDIT:
Oh and some great news! I just had a long and interesting conversation with a local who noticed me while I was writing this earlier and asked me about it. Surprisingly, after I told him about my project he said he knew exactly what I was talking about. Turned out he's a developer who specializes in embedded linux systems and has actual experience with writing flattened device trees. What's even better is that he's willing to help me with this!
This has just taken an interesting turn so stay tuned...

---

Hi mate!
I really want to help you but I don't know how to programming in Linux(for the moment) and I know little bit in Android. My hoght school profile is based on IT and programming but unfortunately i don't make on these langage, I'm making only C++ and C#.The point is: I want to help you and the CM devs to resolve the bugs. I'm waiting response form Sand Pox.
If u find me useful pm to me and I will try to help u. Good luck !

---

Good luck!

---

Kryptocid said:
Hi mate!
I really want to help you but I don't know how to programming in Linux(for the moment) and I know little bit in Android. My hoght school profile is based on IT and programming but unfortunately i don't make on these langage, I'm making only C++ and C#.The point is: I want to help you and the CM devs to resolve the bugs. I'm waiting response form Sand Pox.
If u find me useful pm to me and I will try to help u. Good luck !
Click to expand...
Click to collapse
Hey! I just sent you a PM
I just put up a new repo with the current progress. I'll add more reference stuff later on, but here's the link to the repo: https://bitbucket.org/sigma-1/exynos5420_lt03wifi_dts

---

Hallo?

---

So, I think it's time to declare my research on the flattened device tree officially over. What I have thrown together so far gives me a good idea of how the fdt should eventually look like, although it's not completely accurate.
What should happen now is basically device driver development. Since I'm aiming for Linux 3.18.y there are some things that need to be considered. The SM-P600 relies on certain drivers that are exclusively present in the stock kernel, but some of them can also be found in other Samsung kernels which range from v3.4 to 3.10.
Some of these drivers can be swapped out for generic drivers, while others need to be ported over. My current plan is to start by compiling a system with only just the minimal hardware support to make it boot.
Android's branch of the 3.18 kernel has much of the required support already, but there are at least two major drivers that must be implemented, namely the LCD driver and drivers for the max77803 pmic from Maxim Integrated. The latter does not play that much of an essential part as the max77802 pmic which is already supported in the kernel, but one of the things it controls is the charging mechanism which I believe is pretty much essential.
Also, there is no support for the proprietary battery/charger/fuelgauge drivers from Samsung. Hopefully the generic driver works just as well even though I literally have no idea how it will work out.
Our max17050 fuel gauge is already supported, it's just the max77803 "charger" part that needs to be figured out.
Once the device boots, the rest of the drivers can be implemented one by one as kernel modules once they have been adapted to linux 3.18. That's also where device tree overlays come in, which is one of the cool features of the device tree implementation.
So, I guess I'm off to learn how to write linux device drivers. Guess I'll just write the LCD driver from scratch. The Maxim drivers all look very similar so the 3.4 verson can probably just be upgraded in accordance with the ones already present in Linus' tree.
Another thing to note here is that the ARM Mali GPU drivers are not present in the upstream linux kernel. On the other hand, they have been reverse-engineered and implemented into the Direct Rendering Manager (DRM). What that means though is that the proprietary libs will no longer work. Instead, libdrm would have to be implemented into the android source along with its exynos-specific support libs.
The Mali/Midgard drivers could be implemented into the kernel source, but I personally like the open source alternative better as long as it works.

---

Andmoreagain said:
So, I think it's time to declare my research on the flattened device tree officially over. What I have thrown together so far gives me a good idea of how the fdt should eventually look like, although it's not completely accurate.
What should happen now is basically device driver development. Since I'm aiming for Linux 3.18.y there are some things that need to be considered. The SM-P600 relies on certain drivers that are exclusively present in the stock kernel, but some of them can also be found in other Samsung kernels which range from v3.4 to 3.10.
Some of these drivers can be swapped out for generic drivers, while others need to be ported over. My current plan is to start by compiling a system with only just the minimal hardware support to make it boot.
Android's branch of the 3.18 kernel has much of the required support already, but there are at least two major drivers that must be implemented, namely the LCD driver and drivers for the max77803 pmic from Maxim Integrated. The latter does not play that much of an essential part as the max77802 pmic which is already supported in the kernel, but one of the things it controls is the charging mechanism which I believe is pretty much essential.
Also, there is no support for the proprietary battery/charger/fuelgauge drivers from Samsung. Hopefully the generic driver works just as well even though I literally have no idea how it will work out.
Our max17050 fuel gauge is already supported, it's just the max77803 "charger" part that needs to be figured out.
Once the device boots, the rest of the drivers can be implemented one by one as kernel modules once they have been adapted to linux 3.18. That's also where device tree overlays come in, which is one of the cool features of the device tree implementation.
So, I guess I'm off to learn how to write linux device drivers. Guess I'll just write the LCD driver from scratch. The Maxim drivers all look very similar so the 3.4 verson can probably just be upgraded in accordance with the ones already present in Linus' tree.
Another thing to note here is that the ARM Mali GPU drivers are not present in the upstream linux kernel. On the other hand, they have been reverse-engineered and implemented into the Direct Rendering Manager (DRM). What that means though is that the proprietary libs will no longer work. Instead, libdrm would have to be implemented into the android source along with its exynos-specific support libs.
The Mali/Midgard drivers could be implemented into the kernel source, but I personally like the open source alternative better as long as it works.
Click to expand...
Click to collapse
Keep it up! Good work

---

Is it worth considering a possible arm port of Ubuntu? How about Ubuntu Touch to make use of SPEN?
So far it looks as though your effort has the depth and scope ... is it something you would consider worth exploring?

---

xda_nikita said:
Is it worth considering a possible arm port of Ubuntu? How about Ubuntu Touch to make use of SPEN?
So far it looks as though your effort has the depth and scope ... is it something you would consider worth exploring?
Click to expand...
Click to collapse
I actually intend on starting with building a regular Linux rootfs with a desktop distro such as Ubuntu before jumping on to a full android build. In regards to s-pen functionality, I won't be focusing on that until everything else is working as it should. I hope it can be supported eventually though. I myself would love to be able to draw directly in GIMP or InkScape with the s-pen.
My first aim is to get the u-boot bootloader up and running. That alone would open up a lot of possibilities for future development as well as true multi boot.

---

So I've been tinkering with this a bit, and I'm currently pulling in some Samsung drivers to a linux-linaro v3.13 tree. I decided to go with this particular kernel base since it's not too different from linux 3.10 and because it has native support for exynos5420 which upstream android/linux-3.10 doesn't. My original thought was to use linux 3.18, but it just presented me with too much incompatibility with the 3.10 drivers.
I've also found a suitable driver for the max77803 PMIC. It's actually for max77888, but our stock driver is based on the max77888 driver and they're almost identical for that matter. Pulled it in from a 3.10 tree along with the battery+motor drivers and a driver for the sii8240 chip. I'm still fixing up some missing includes before I start diffing it against the stock drivers. I'll post an update once it all compiles without an issue.
Edit:
Fixed up some build errors with the sec_battery driver, now running into some "field has incomplete type" error with max17050 fuelgauge driver. Not sure what to make of this so if anyone has any ideas it would be greatly appreciated.
Code:
LD drivers/base/built-in.o
CC drivers/battery/sec_battery.o
CC drivers/battery/sec_adc.o
CC drivers/battery/max17050_fuelgauge.o
In file included from drivers/battery/max17050_fuelgauge.c:15:0:
include/linux/battery/sec_fuelgauge.h:60:19: error: field 'fuel_alert_wake_lock' has incomplete type
struct wake_lock fuel_alert_wake_lock;
^
scripts/Makefile.build:308: recipe for target 'drivers/battery/max17050_fuelgauge.o' failed
make[2]: *** [drivers/battery/max17050_fuelgauge.o] Error 1
scripts/Makefile.build:455: recipe for target 'drivers/battery' failed
make[1]: *** [drivers/battery] Error 2
Makefile:816: recipe for target 'drivers' failed
make: *** [drivers] Error 2
Source code: https://bitbucket.org/sigma-1/linux-linaro-3.13-2014.01
I also find Samsung's 3.10 kernels a bit odd looking in some aspects. They still use deprecated macros such as __devinit and __devexit that shouldn't be present in 3.10 at all. Anyway, I'm gonna continue to try and sort this out.

---

Hi not a developer (so far) but did someone read about this device here?
There is a Linux running on an Samsung Exynos5422 Cortex™-A15
Its maybe helpfull to get some stuff thats not supported from Samsung opensource
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825

---

peterpan07 said:
Hi not a developer (so far) but did someone read about this device here?
There is a Linux running on an Samsung Exynos5422 Cortex™-A15
Its maybe helpfull to get some stuff thats not supported from Samsung opensource
http://www.hardkernel.com/main/products/prdt_info.php?g_code=G143452239825
Click to expand...
Click to collapse
Yeah, the Exynos series of SoC's are all supported upstream, including Exynos 5420. The current kernel base I'm using comes from Linaro and not Samsung OSRC and it has most of the required support already. The upstream kernel actually has much better and advanced support for the Exynos series than any of Samsung's stock kernels. They just seem to be more interested in actually providing upstream support for the development boards while end-user devices such as phones and tablets get no such support. It's understandable and in most cases this doesn't really make much difference to the end-user. Exynos 5420 is a special case though IMO because our stock kernel still doesn't properly support all the capabilities it has to offer.
The issue we're facing is basically that Samsung's phones and tablets rely on hardware that isn't entirely supported upstream. Like I've mentioned before, an example would be the PMICs that are commonly used in Samsung's products. Usually these are chips manufactured by Maxim Integrated and while a handful of these chips have upstream kernel support, most of them don't and their drivers are exclusively found in Samsung OSRC kernel trees. Thankfully the PMICs are the least of my worries in this context because these drivers are all based on one another and all look pretty similar for that matter. Basically the only thing that truly needs to be worked upon in this early phase is the driver for our LCD (LSL101DL01). If simply adding OF/Device Tree support to the driver doesn't work then it may have to be rewritten in order for it to work properly with linux v3.10 and higher. I simply haven't started looking into it enough to be able to say anything about it at this point.
The PMICs are my current priority, since support for max77802/803 will also be needed for the u-boot bootloader as far as my understanding goes. Otherwise it doesn't seem like u-boot requires much driver support compared to the kernel.
Current todo list:
- Apply upstream patches for max77802 support
- Get max77803 (muic, motor, leds, charger), max17050 (fuel gauge) and Samsung's battery drivers working
- Forward-port the LCD driver to play nicely with Linux v3.10 or higher
- Add device tree bindings for all of the above
Again, any help would be appreciated. I'm personally just learning things as I go along so if there's anyone here who has experience with C/kernel programming and might be willing to contribute to this project or even just provide some insight or ideas, then please let me know! The more, the merrier!