Related
Kernel Development Tutorials
Important Links:
Ubuntu - http://www.ubuntu.com/download/ubuntu/download
Sourcery G++ Lite 2011.03-42 for ARM EABI - http://www.codesourcery.com/sgpp/lite/arm/portal/release1802
Stock Samsung Source - https://github.com/dharamg3/kernel_stock_g3 OR https://opensource.samsung.com/
Github for the Tutorials - https://github.com/dharamg3/g3_tuts
Source of Other Kernels to Compare:
G3MOD - Galaxy 3 - https://github.com/dharamg3/G3MOD
FuguMod - Galaxy 3 - https://github.com/sdadier/froyo
I will explain everything Step by Step.
If you got time to learn/develop join in.
If you get some step working and a fellow developer cant get it, please help each other by answering everyone's doubts.I cant reply to each and every query always.
Most of the code is to be run in the terminal. So I wont be mentioning to Open terminal every time.
I would like to thank marcellusbe who was the first one to make a proper custom Kernel for G3, who taught me how to build a kernel, and also lot of other help.
Note:
Please do not post useless messages.
If you dont know coding, please learn that first.
Do not flood my inbox with PM's. I will not respond to PM's regarding Kernel Development. Please post in the thread.
[*]I AM NOT RESPONSIBLE IF YOU HARDBRICK YOUR PHONE, DOING ANY OF THE FOLLOWING STEPS
Install Ubuntu(x86/x64)
1. Install a virtual machine software.(VMware/Virtualbox)
2. Create a new Virtual Machine.
3. Use Ubuntu ISO to install. Download from here - http://www.ubuntu.com/download/ubuntu/download - I use Ubuntu 10.10 x86
4. Allocate enough space for the Virtual machine as the source is itself around 500mb for Kernel. And if you are like me, then you will want to keep backups at each stage.
5. Recommended RAM is 1GB.
6. Let Ubuntu be installed (VMware and Virtualbox have Easy Install which installs Ubuntu itself)
Logging In As Root
1. When Ubuntu first boots, login with the username and password you mentioned while installing.
2. Open Terminal
3. Use following command.(Always the code after $/# is the one to be used. The one before that just specifies [email protected]:~)
## Anything after ## is a comment by me.
Code:
[email protected]:~$ sudo passwd
[sudo] password for dharammaniar: ## Enter password which you used to login.
Enter new UNIX password: ## Enter Password for root(it can be same as your prev password)
Retype new UNIX password: ## Re-Enter Password for root
passwd: password updated successfully
[email protected]:~$ su
Password: ## Enter the root password
[email protected]:/home/dharammaniar#
4. Once you get the last line as above means you now have root access.
5. Now logout from this user and login with username as root
6. On starting Terminal now, you should get
Code:
[email protected]:~#
Setting Up Build Environment
1. You should always be running as root.
2. Go To System->Administration->Synaptic Package Manager
3. Search for ncurses-devel
4. Install libncurses5-dev.
5. Go to http://www.codesourcery.com/sgpp/lite/arm/portal/release1802
6. Download IA32 GNU/Linux Installer. Keep the arm-2011.03-42-arm-none-eabi.bin file on the desktop.(I like to keep everything on the desktop for faster access)
7. Run code and select NO
Code:
dpkg-reconfigure -plow dash
8. Run Installer using code
Code:
apt-get install ia32-libs ## FOR THOSE WHO HAVE x64 Ubuntu installed
/bin/sh /root/Desktop/arm-2011.03-42-arm-none-eabi.bin ## THANKS TO cdesai for the tip :)
9. Do the usual Next Next Next Next.Dont change any paths.Install as typical.
10. Wait till it is installing
11. Wait more
12. Still waiting
13. Again Next -> Done.
14. You now have the development environment ready.
Downloading Sources
1. Download Samsung Source from https://opensource.samsung.com/ or https://github.com/dharamg3/kernel_stock_g3
2. If you download from https://opensource.samsung.com/ then you will not have the initramfs.
3. To get stock initramfs, you need to extract it from one of the stock kernel(I will explain it later).
Extracting initramfs from zImageBased on script from mizch - http://forum.xda-developers.com/showthread.php?t=901152
Download Files from the attachments.
1. Extract files from initramfs-utils.zip to /bin/
2. Make a folder on the Desktop named unpack.
3. Extract the repack-zImage.sh file from repack-zImage.v6.zip in the unpack folder on Desktop.
4. Add your zImage from which you want to extract initramfs in the unpack folder.
5. Run Command
Code:
cd /root/Desktop/unpack
sh repack-zImage.sh -u
6. You will get the unpacked zImage in the same folder which will contain the initramfs folder also.
Note: To make things simple, i use a script to unpack.
Download from attachment.
Add this unpack.sh file to your unpack folder and run it by double clicking
Building Kernel
1. Download Source as mentioned in the above tutorial.
2. Create a folder on the Desktop. I have named it g3.
3. Add initramfs folder and Kernel folder in that folder.
4. Run Code to make initramfs.cpio
Code:
cd initramfs
find . -print0 | cpio --null -ov --format=newc > ../initramfs.cpio
5. You can also use the script named initramfs.sh from attachments. Copy it to the g3 folder and run it by double clicking.
6. By doing step 4 or 5 you will get initramfs.cpio in the g3 folder.
7. Next you need to do is modify the makefile in Kernel folder.
Original is
Code:
ARCH := arm
CROSS_COMPILE := /opt/toolchains/arm-2009q3/bin/arm-none-linux-gnueabi-
Change to
Code:
ARCH := arm
CROSS_COMPILE := /root/CodeSourcery/Sourcery_G++_Lite/bin/arm-none-eabi-
8. Now you need the configuration file.
9. Copy the apollo_rev_02_android_defconfig file from /Kernel/arch/arm/configs to /Kernel/
10. Rename it to .config (Note: It should be only .config and not apollo_rev_02_android_defconfig.config)
11. Now in Terminal run the following code.
Code:
cd /root/Desktop/g3/Kernel
make menuconfig
12. You will get a GUI menu.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
13. Go to General Setup
14. Next go to Initramfs source file(s)
15. Press Enter and give path as
Code:
../initramfs.cpio
16. Exit from menuconfig
17. Enter Code
Code:
make
OR
Code:
make -j4 ## THIS ONE ONLY IF YOU GOT A GOOD CPU THAT SUPPORTS MULTI-THREADING :)
18. Building will start. There will be many warnings. Ignore them.
19. After building is finished, you will get zImage at /Kernel/arch/arm/boot/
20. Add this zImage to a test.tar(attachment) using Total Commander.
21. Flash as One Package in Odin.
22. Enjoy
Note: This is the stock kernel and supports only rfs filesystem. So before flashing it, please change filesystem to rfs and then flash.
Kernel Basics
The Kernel is basically divided into 2 parts.
The Kernel and the initramfs.Those are the two folders in your g3folder.
initramfs
initramfs is a root filesystem which is embedded into the kernel and loaded at an early stage of the boot process. It is the successor of initrd. It provides early userspace which lets you do things that the kernel can't easily do by itself during the boot process.
GIT Commits
I will commit my source every time i make a tutorial. You can check out all the commits on my github for the tutorials - https://github.com/dharamg3/g3_tuts
Fixed Sound Click Bug During Calls - https://github.com/dharamg3/g3_tuts/commit/2f623a5fb88062deb5dbc7d8d1040c05f43b3d91
1% Battery MOD - https://github.com/dharamg3/g3_tuts/commit/f5259a58f14351ccffee49e9fc235b9670369b90
Voodoo Sound v10 - https://github.com/dharamg3/g3_tuts/commit/0bb0f9a538fdb59138e0bcc957d33aa15fd39155
ADB Root and BusyBox - https://github.com/dharamg3/g3_tuts/commit/57424d6a122e6ff219165fd718de8555029a1079
FileSystem Support - https://github.com/dharamg3/g3_tuts/commit/5db762b1402f7775af4ef7da395d5c9d0b99ed0f
Kernel Modding - Part 1
PLEASE DONT ASK HOW OR WHY ANY PART IS DONE. I WILL EXPLAIN ALL THAT I KNOW. BUT SOME PART OF THIS HAS BEEN DONE BY TRIAL AND ERROR METHOD, WHEREAS SOME PART MAYBE OUT OF MY SCOPE OF KNOWLEDGE.
Removing The Sound Click Bug During Calls
We all know that this is the most basic bug found out in the Kernel of Samsung. The clicking sound we get during calls. Many of you may complain that this bug is solved in the newer ROM's, but remember we are building from the original Samsung Source, which is modified in the newer kernel's. We dont have those modifications so here it goes, the Sound Click Bug.
We to find out this bug you need to check the dmesg when you are in a call.
It shows you that there is some sound routing done during the call. So you know that this is something related to the sound driver.
Now the sound driver for Galaxy 3 is the wm8994 driver, which is present at Kernel/sound/soc/codecs/
So the changes to be made are in the file wm8994.c
In the function static int wm8994_resume(struct platform_device *pdev)
Originally the code was
Code:
if (wm8994_power == 0) {
audio_power(1); /* Board Specific function */
wm8994_power = 1;
}
wm8994_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
wm8994_enable_path(codec, wm8994_curr_path);
After editing the code is
Code:
if (wm8994_power == 0) {
audio_power(1); /* Board Specific function */
wm8994_power = 1;
wm8994_set_bias_level(codec, SND_SOC_BIAS_STANDBY);
wm8994_enable_path(codec, wm8994_curr_path);
}
1% Battery MOD
The battery driver for galaxy 3 is found at Kernel/drivers/power/
The file to be added is s5p6442_battery.c
The Samsung battery driver originally divides battery in the following Steps:
100,90,80,70,60,50,40,30,20,15,5,3,1
If you look at the source code, you should be able to find that out easily.
We need to make it return each value in between also so that we get the 1% MOD that is required.
So now, the original code was
Code:
if (bat_vol > batt_full)
{
int temp = (batt_max - batt_full);
if (bat_vol > (batt_full + temp) ||
s3c_bat_info.bat_info.batt_is_full)
bat_level = 100;
else
bat_level = 90;
#ifdef __CHECK_CHG_CURRENT__
if (s3c_bat_info.bat_info.charging_enabled) {
check_chg_current(bat_ps);
if (!s3c_bat_info.bat_info.batt_is_full)
bat_level = 90;
}
#endif /* __CHECK_CHG_CURRENT__ */
dev_dbg(dev, "%s: (full)level = %d\n", __func__, bat_level );
}
else if (batt_full >= bat_vol && bat_vol > batt_almost)
{
int temp = (batt_full - batt_almost) / 2;
if (bat_vol > (batt_almost + 86))
bat_level = 80;
else
bat_level = 70;
dev_dbg(dev, "%s: (almost)level = %d\n", __func__, bat_level);
}
else if (batt_almost >= bat_vol && bat_vol > batt_high)
{
int temp = (batt_almost - batt_high) / 2;
if (bat_vol > (batt_high + 62))
bat_level = 60;
else
bat_level = 50;
dev_dbg(dev, "%s: (high)level = %d\n", __func__, bat_level );
}
else if (batt_high >= bat_vol && bat_vol > batt_medium)
{
int temp = (batt_high - batt_medium) / 2;
if (bat_vol > (batt_medium + 26))
bat_level = 40;
else
bat_level = 30;
dev_dbg(dev, "%s: (med)level = %d\n", __func__, bat_level);
}
else if (batt_medium >= bat_vol && bat_vol > batt_low)
{
int temp = (batt_medium - batt_low) / 2;
if (bat_vol > (batt_low + 50))
bat_level = 20;
else
bat_level = 15;
dev_dbg(dev, "%s: (low)level = %d\n", __func__, bat_level);
}
else if (batt_low >= bat_vol && bat_vol > batt_critical)
{
bat_level = 5;
dev_dbg(dev, "%s: (cri)level = %d, vol = %d\n", __func__,
bat_level, bat_vol);
}
else if (batt_critical >= bat_vol && bat_vol > batt_min)
{
bat_level = 3;
dev_info(dev, "%s: (min)level = %d, vol = %d\n", __func__,
bat_level, bat_vol);
}
else if (batt_min >= bat_vol && bat_vol > batt_off)
{
bat_level = 1;
dev_info(dev, "%s: (off)level = %d, vol = %d\n", __func__,
bat_level, bat_vol);
}
else if (batt_off >= bat_vol)
{
bat_level = 0;
dev_info(dev, "%s: (off)level = %d, vol = %d", __func__,
bat_level, bat_vol);
}
We need to edit it to make
Code:
if (bat_vol > batt_full)
{
int temp = (batt_max - batt_full);
if (bat_vol > (batt_full + temp) ||
s3c_bat_info.bat_info.batt_is_full)
bat_level = 100;
else
{
bat_level = 90 + (((bat_vol - batt_full) *10) / temp);
}
#ifdef __CHECK_CHG_CURRENT__
if (s3c_bat_info.bat_info.charging_enabled) {
check_chg_current(bat_ps);
if (!s3c_bat_info.bat_info.batt_is_full)
bat_level = 90;
}
#endif /* __CHECK_CHG_CURRENT__ */
dev_dbg(dev, "%s: (full)level = %d\n", __func__, bat_level );
}
else if (batt_full >= bat_vol && bat_vol > batt_almost)
{
int temp = (batt_full - batt_almost) / 2;
bat_level = 70 + (((bat_vol - batt_almost) *10) / temp);
dev_dbg(dev, "%s: (almost)level = %d\n", __func__, bat_level);
}
else if (batt_almost >= bat_vol && bat_vol > batt_high)
{
int temp = (batt_almost - batt_high) / 2;
bat_level = 50 + (((bat_vol - batt_high) *10) / temp);
dev_dbg(dev, "%s: (high)level = %d\n", __func__, bat_level );
}
else if (batt_high >= bat_vol && bat_vol > batt_medium)
{
int temp = (batt_high - batt_medium) / 2;
bat_level = 30 + (((bat_vol - batt_medium) *10) / temp);
dev_dbg(dev, "%s: (med)level = %d\n", __func__, bat_level);
}
else if (batt_medium >= bat_vol && bat_vol > batt_low)
{
int temp = (batt_medium - batt_low) / 2;
bat_level = 15 + ((( bat_vol - batt_low) *5) / temp);
dev_dbg(dev, "%s: (low)level = %d\n", __func__, bat_level);
}
else if (batt_low >= bat_vol && bat_vol > batt_critical)
{
bat_level = 5;
dev_dbg(dev, "%s: (cri)level = %d, vol = %d\n", __func__,
bat_level, bat_vol);
}
else if (batt_critical >= bat_vol && bat_vol > batt_min)
{
bat_level = 3;
dev_info(dev, "%s: (min)level = %d, vol = %d\n", __func__,
bat_level, bat_vol);
}
else if (batt_min >= bat_vol && bat_vol > batt_off)
{
bat_level = 1;
dev_info(dev, "%s: (off)level = %d, vol = %d\n", __func__,
bat_level, bat_vol);
}
else if (batt_off >= bat_vol)
{
bat_level = 0;
dev_info(dev, "%s: (off)level = %d, vol = %d", __func__,
bat_level, bat_vol);
}
and also we need to change the Total ADC count
Originally
Code:
#define ADC_TOTAL_COUNT 20
Change it to
Code:
#define ADC_TOTAL_COUNT 100
Voodoo Sound Driver
The Sound Driver for Galaxy 3 is the wm8994 Wolfson Microelectronics Codec.
The WM8994 is a highly integrated ultra-low power hi-fi CODEC designed for smartphones and other portable devices rich in multimedia features.
Features
Hi-Fi 24-bit 4-channel DAC and 2-channel ADC
100dB SNR during stereo DAC playback (‘A’ weighted)
Smart MIC interface
- Power, clocking and data input for up to four digital MICs
- High performance analogue MIC interface
- MIC activity monitor & interrupt allows processor to sleep
1W stereo / 2W mono class D/AB speaker driver
Capless class W headphone drivers
- Integrated charge pump
- 6mW total power for DAC playback to headphones
4 line outputs (single-ended or differential)
BTL earpiece driver
Digital audio interfaces for multi-processor architecture
- Asynchronous stereo duplex sample rate conversion
- Powerful mixing and digital loopback functions
ReTune™ Mobile 5-band, 6-channel parametric EQ
Programmable dynamic range controller
Dual FLL provides all necessary clocks
- Self-clocking modes allows processor to sleep
- All standard sample rates from 8kHz to 96kHz
Active noise reduction circuits
- DC offset correction removes pops and clicks
- Ground loop noise cancellation
Integrated LDO regulators
72-ball W-CSP package (4.511mm x 4.023mm x 0.7mm)
The Voodoo Driver is developed by supercurio.
The changes to be made for the voodoo driver are at sound/soc/codec/
The Changes are as the following Commit. (Please ignore the /Kernel/scripts part....I forgot to do a make clean -i before commiting )
RootADB and BusyBox
Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:
A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.
A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.
A daemon, which runs as a background process on each emulator or device instance.
You can find the adb tool in <sdk>/platform-tools/.
RootADB gives you root access while performing adb functions.
BusyBox combines tiny versions of many common UNIX utilities into a single small executable. It provides replacements for most of the utilities you usually find in GNU fileutils, shellutils, etc. The utilities in BusyBox generally have fewer options than their full-featured GNU cousins; however, the options that are included provide the expected functionality and behave very much like their GNU counterparts. BusyBox provides a fairly complete environment for any small or embedded system.
BusyBox has been written with size-optimization and limited resources in mind. It is also extremely modular so you can easily include or exclude commands (or features) at compile time. This makes it easy to customize your embedded systems. To create a working system, just add some device nodes in /dev, a few configuration files in /etc, and a Linux kernel.
The Changes to be made for these are in the initramfs.
These can be found in this Commit.
Kernel Modding - Part 2
PLEASE DONT ASK HOW OR WHY ANY PART IS DONE. I WILL EXPLAIN ALL THAT I KNOW. BUT SOME PART OF THIS HAS BEEN DONE BY TRIAL AND ERROR METHOD, WHEREAS SOME PART MAYBE OUT OF MY SCOPE OF KNOWLEDGE.
File System Support: rfs/ext2/ext3/ext4
RFS
SAMSUNG RFS (Robust File System) is an embedded flash file system that uses SAMSUNG OneNAND flash memory as storage on any consumer electronic devices.
SAMSUNG RFS runs in the Linux kernel and is fully compatible with FAT file system standards (FAT16/32).
EXT2
http://en.wikipedia.org/wiki/Ext2
EXT3
http://en.wikipedia.org/wiki/Ext3
EXT4
http://en.wikipedia.org/wiki/Ext4
[DEV] Debate: ext2 vs ext3 vs ext4 : http://forum.xda-developers.com/showthread.php?t=800353
[REF] Information About Filesystems : http://forum.xda-developers.com/showthread.php?t=1058095
The changes to be done are as in the commit.
Reserved
Reserved
Reserved
Too many reserved post as usual (all you need is one post to explain all )
Anyways I'll make videos on this soon..
all the users need to know is to install Ubuntu by themself.. everything else will be covered in the video.
well, i intend to add everything here...including where to mod, which code and stuff...
nice to see your post.... XD
dharam can you post some information about overlocking and undervolt?i need it indeed
dxdiag32 said:
nice to see your post.... XD
dharam can you post some information about overlocking and undervolt?i need it indeed
Click to expand...
Click to collapse
everything will come in time...
Thks man, i have never known how to make a kernal before
Sent from my GT-I5801 using XDA App
I hav one question. This tutorial wil b in general or this is specifically for g3?
rudolf895 said:
Too many reserved post as usual (all you need is one post to explain all )
Anyways I'll make videos on this soon..
all the users need to know is to install Ubuntu by themself.. everything else will be covered in the video.
Click to expand...
Click to collapse
the big advantage of having multiple posts reserved is that you can have som kind of directory on the first post linking to the sections in the other posts, this is of big use in a massive theme like kernel development. also i do not see why nobody does this here as of now, always they reserve multiple posts and nobody links them in first post, what makes the use of them obsolete...
vikraam said:
I hav one question. This tutorial wil b in general or this is specifically for g3?
Click to expand...
Click to collapse
well, specifically for g3...the basic steps are same for all phones, but the code and stuff will be more specific for g3...
dharamg3 said:
well, specifically for g3...the basic steps are same for all phones, but the code and stuff will be more specific for g3...
Click to expand...
Click to collapse
I wud like to thank u a million times. Thanq very very much
Hey first a great Karnel now How to make one!!! good going!!! Thanks Mate
I've made some modifications to drivers/usb/otg/msm_otg.c in order to support usb host mode for the Nexus 4: http://forum.xda-developers.com/showthread.php?t=2181820
So far, I've been building off Franco's sources, since I was using his kernel anyway. But this has its problems. I'm not looking to have to constantly keep up with Franco's nightlies. A good amount of posts from people are asking if I could compile a different kernel with the otg modifications, or if they could flash a different kernel on top. Franco's been getting requests to implement the modifications, and I didn't mean to put any onus on him.
I've been trying to do some research on creating a kernel module that could somehow hijack/hook/wrap the static functions I've made changes to in msm_otg.c. This is all way, way over my head though, and I could really use some help here. I've done some reading so far, but it hasn't gotten me anywhere. I got some good help on IRC, but am stuck again.
To get things rolling, I've manually found the address from /proc/kallsyms of static function msm_chg_detect_work to be 0xc03b4950. I'm trying to make a jump from here to my own function. I was provided make_jump_op for this purpose, although I have no understanding of how it works. Here is more or less what I've got so far (relevant bits..):
Code:
// max distance: 0x02000000
unsigned int make_jump_op(unsigned int src, unsigned int dst) {
unsigned int o;
int distance;
distance = (int)( ((long long)dst) - (((long long)src) + 8) );
if (distance > 32*1024*1024 || distance < -32*1024*1024) {
printk(KERN_ERR "distance too big!\n");
return 0; // crash, BOOOOM!
}
distance = distance / 4; // read: ">>2"
o = *((unsigned int *)(&distance)); // is there a proper way to do this, too?
o = (o & 0x00ffffff) + 0xea000000;
return o;
}
static void msm_chg_detect_work_MOD(struct work_struct *w) {
printk(KERN_INFO "TEST\n");
}
static int ziddey_otg_init(void) {
unsigned int *origcall;
printk(KERN_INFO "Loading kernel module '%s'\n", MODULE_NAME);
// 0xc03b4950: msm_chg_detect_work
origcall = (unsigned int *) 0xc03b4950;
preempt_disable();
*origcall = make_jump_op(0xc03b4950, (unsigned int)(void*)msm_chg_detect_work_MOD);
preempt_enable();
printk(KERN_INFO "Loaded kernel module '%s'\n", MODULE_NAME);
return 0;
}
Can anyone make sense of this? I get an Oops error and kernel panic.
Thank you
Code:
$ grep msm_chg_detect_work /proc/kallsyms
c03b4950 t msm_chg_detect_work
Hello guys. i have been trying to compile cwm recovery for my phone. its using msm7627a board. am using the prebuilt kernel. i succeded compiling but when i flash its not displaying anything. i tried to see whats wrong , from the recovery log i found the frame buffer /dev/graphics is not available. Everything else works i can do a backup from ROM manager, even keystrokes work..adb shell works .. just the display not working..any ideas. ????
i also realise some other devices are not loaded.
how can i make the fb0 graphics loaded or any other fix.. ???
for those who have access to the source code ..
Code:
.................................................................................part of the concerned ui code..........................................................
int gr_init(void)
{
gglInit(&gr_context);
GGLContext *gl = gr_context;
gr_init_font();
gr_vt_fd = open("/dev/tty0", O_RDWR | O_SYNC);
if (gr_vt_fd < 0) {
// This is non-fatal; post-Cupcake kernels don't have tty0.
perror("can't open /dev/tty0");
}
else
{
if (ioctl(gr_vt_fd, KDSETMODE, (void*) KD_GRAPHICS)) {
// However, if we do open tty0, we expect the ioctl to work.
perror("failed KDSETMODE to KD_GRAPHICS on tty0");
gr_exit();
return -1;
}
}
gr_fb_fd = get_framebuffer(gr_framebuffer); // this is the call that fails because it tries opening /dev/graphics/fb0 which does then exists
if (gr_fb_fd < 0) {
gr_exit();
perror("cant get framebuffer");
return -1;
}
get_memory_surface(&gr_mem_surface);
fprintf(stderr, "framebuffer: fd %d (%d x %d)\n",
gr_fb_fd, gr_framebuffer[0].width, gr_framebuffer[0].height);
/* start with 0 as front (displayed) and 1 as back (drawing) */
gr_active_fb = 0;
set_active_framebuffer(0);
gl->colorBuffer(gl, &gr_mem_surface);
gl->activeTexture(gl, 0);
gl->enable(gl, GGL_BLEND);
gl->blendFunc(gl, GGL_SRC_ALPHA, GGL_ONE_MINUS_SRC_ALPHA);
gr_fb_blank(true);
gr_fb_blank(false);
return 0;
}
............................................................code,.........................................................
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!
Basically, there has been an app ported to Android that allows even unrooted(stock) devices to deliver a bootrom exploit to the Nintendo Switch via USB-OTG and a USB cable (or C-to-C). USB 3.0 (xHCI) devices have no issues and deliver the exploit just fine. Apparently it is not even a USB 2.0 problem but rather how the EHCI performs, as certain USB 2.0 phones actually have the xHCI controller and can run the exploit just fine. What happens is that although it can detect the connected Switch in Tegra Recovery Mode, it just doesn't do anything and gives an error in the logs, "SUMBITURB failed".
On Linux desktop systems it is similar, but the exploit can still work with a kernel patch provided by a hacking group that discovered the exploit in the first place:
Code:
--- linux-4.14.27/drivers/usb/host/ehci-hcd.c.old 2018-04-17 18:00:00.000000000 +0000
+++ linux-4.14.27/drivers/usb/host/ehci-hcd.c 2018-04-17 18:00:00.000000000 +0000
@@ -873,14 +873,6 @@
INIT_LIST_HEAD (&qtd_list);
switch (usb_pipetype (urb->pipe)) {
- case PIPE_CONTROL:
- /* qh_completions() code doesn't handle all the fault cases
- * in multi-TD control transfers. Even 1KB is rare anyway.
- */
- if (urb->transfer_buffer_length > (16 * 1024))
- return -EMSGSIZE;
- /* FALLTHROUGH */
- /* case PIPE_BULK: */
default:
if (!qh_urb_transaction (ehci, urb, &qtd_list, mem_flags))
return -ENOMEM;
The author of the Android port had also written a Python "hotpatch" script for desktop Linux systems:
Code:
#!/usr/bin/env python3
import os
"""
Cursed Code.
This code literally patches your kernel memory, proceed at your own risk.
Tested on Ubuntu 17.10 and Arch, x86_64. Should work on other distros, maybe even other architectures!
Run fusee-launcher.py with the "--override-checks" argument.
If you'd rather patch your drivers properly:
https://github.com/fail0verflow/shofel2/blob/master/linux-ehci-enable-large-ctl-xfers.patch
"""
ksyms = {
line[2]: int(line[0], 16)
for line in
map(lambda l: l.strip().split(),
open("/proc/kallsyms", "r").readlines())}
print(hex(ksyms["ehci_urb_enqueue"]))
patch_c = """
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/pgtable.h>
static u32 ORIG_MAX = 16*1024;
static u32 NEW_MAX = 0x1000000;
/* borrowed from MUSL because I'm lazy AF */
static char *fourbyte_memmem(const unsigned char *h, size_t k, const unsigned char *n)
{
uint32_t nw = n[0]<<24 | n[1]<<16 | n[2]<<8 | n[3];
uint32_t hw = h[0]<<24 | h[1]<<16 | h[2]<<8 | h[3];
for (h+=3, k-=3; k; k--, hw = hw<<8 | *++h)
if (hw == nw) return (char *)h-3;
return 0;
}
static pte_t* (*lookup_addr)(unsigned long, unsigned int*) = (void *) PLACE2;
static void set_addr_rw(unsigned long addr) {
unsigned int level;
pte_t *pte = lookup_addr(addr, &level);
set_pte_atomic(pte, pte_mkwrite(*pte));
}
int init_module(void) {
void * ehci_urb_enqueue_start = (void *) PLACEHOLDER;
u32 * patch_addr;
printk(KERN_INFO "Patch module loaded\\n");
patch_addr = (u32 *) fourbyte_memmem(ehci_urb_enqueue_start, 0x400, (void *)&ORIG_MAX);
if (patch_addr == NULL) {
printk(KERN_INFO "Failed to find patch site :(\\n");
return -1;
}
printk(KERN_INFO "patch_addr: 0x%px\\n", patch_addr);
set_addr_rw((unsigned long)patch_addr);
*patch_addr = NEW_MAX;
printk(KERN_INFO "Patching done!\\n");
return -1;
}
""".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2", hex(ksyms["lookup_address"]))
makefile = """
obj-m += patch.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
"""
with open("patch.c", "w") as patchfile:
patchfile.write(patch_c)
with open("Makefile", "w") as mf:
mf.write(makefile)
os.system("make")
print("About to insert patch module, 'Operation not permitted' means it probably worked, check dmesg output.")
os.system("insmod patch.ko")
I tried to see if running it in Termux would do anything but I got the following error:
Code:
0x0
Traceback (most recent call last):
File "ehci_patch.py", line 70, in <module>
" " ".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2" hex(ksyms["lookup_address"]))
KeyError: 'lookup_address'
I know that script isn't meant for use on Android anyway but maybe it can lead to a solution. The author of it does not know how to go about it at this time either, but believes an entire recompile of the kernel would be necessary. I am hoping that something like a systemless Magisk module would be the easiest solution for users but do not know if that is possible. I am only guessing it might be possible to create a Magisk module because of audio drivers like VIPER4Android. If indeed a custom kernel is needed, does anyone know how to go about it? It could be difficult to implement for everyone because not everyone has a device where the source to the kernel is available, etc. I am willing, however, to test anything on my tablet which is USB 2.0 and gives the error in the app. Any advice for how to go about this will be greatly appreciated.
I feel ya man, i need this stuff too. NXLoader doesn't work on my Galaxy Grand Prime (G530T) and i really need it to Dx