FORUMS
Remove All Ads from XDA

[Solved] Reverse Engineering a 32A Kernel [Updated 28th August]

n/a posts
Thanks Meter: 0
 
By TigerTael, Guest on 14th August 2009, 02:34 PM
Post Reply Email Thread
New 32A Magic Kernel Patches Thread, Please upgrade to V3 patch!

Apparently HTC have released their kernel sources for the 32A magic @ http://developer.htc.com/

Thank you for your help everyone!

I have just reviewed the HTC kernel source and it looks like HTC actually pulled their thumbs out of their arse! Apart from the two different memory locations below, HTC have also added some logic to their kernel source which will probably be of great benefit to everyone.

There are two differences between my kernel patch and HTC's. They are:

Mine:
VMALLOC_END (PAGE_OFFSET + 0x19200000)

Theirs:
VMALLOC_END (PAGE_OFFSET + 0x20000000)

Mine:
MSM_EBI_SIZE 0x0CE00000

Theirs:
MSM_EBI_SMI32_256MB_SIZE 0x0C600000

You can't really blame me too much for these as they were impossible to reverse engineer. I could only come to a size based on differential calculation from the 32B source.

Also, those who know, will recall that I wasn't too sure about my EBI size.

:::PROLOGUE:::
After many countless hours that I have spent bashing away at the keyboard, and many tears of blood, sweat and sorrow, we seem to finally have a booting 32A Kernel which seems to behave properly.

If anybody has any problems with the kernel and/or memory addresses, please can you forward them to me and I will look into it. OR you can post the details here, I'm sure we'll look at it. I'm sad to have to say this, but any memory location problems/kernel errors relating to memory issues are probably my fault. I did the best that I could. I am fairly confident that the memory addresses are correct, although there is that niggling in the back of my mind that there is something not right but judging by the response and dmesg and logcats, I have found no such evidence. If there are any problems with memory addresses and something ends up happening, burning down your house or whatever, I'm not responsible. Sure, I'll be more than happy to fix any mistakes (if there are any), but come on, cut me some slack.

In fact, blame HTC for not releasing the kernel patches (They are legally obliged to). I think that perhaps when they do end up releasing the kernel patches, only then will I find out how good my calculations were and even then, some things you would not be able to found out purely by calculations alone. Also, the memory layout for the 32A kernels is quite the opposite to the 32B kernels. Did they do this on purpose or was it a rush job?

Why HTC, WHY?
:::END:::

Result: GREAT SUCCESS!

What this means for the layman is that we will be able to finally get tethering support and any future kernel developments (ROM features) that are in 32B ROM's and we 32A users could not use them!

Developers, please note, after you apply this kernel patch, you will NOT be able to build 32B kernels from the same source. There have been quite a few forks.

Thank you rayman84 for the help! Special thanks to zinx @Freenode for your awesome diagnostic app to help discover ADSP/Camera!

To everyone with a 32A handset that is looking forward to this, feel free to try compile your own kernel but also remember that things are likely to change as more discoveries are made. If you want a stable 32A kernel with iptables and netfilter with all features working, you're going to have to wait a little longer. I'm working on this as much as I can and ALL help is appreciated from everyone! Fixing the kernel for the 32A platform will benefit everyone! If you feel you can help, please do! Any changes you make or suggestions will be taken seriously.

I have posted my own kernel patch for the latest 2.6.27 kernel. This is still experimental but everything seems to be working!

- - - - - This is for developers only and is very experimental! Backup your files, patch is (un)likely to change. - - - - -

2.6.27 Kernel Patch v2 - Link removed to prevent people downloading this for the time being. Please check the new thread for files.

- - - - - This is for developers only and is very experimental! Backup your files, patch is (un)likely to change. - - - - -

* Changelog:

V3 - COMING SOON
Changed Makefile.boot back to V1 - initrd_phys-y := 0x19A00000
Changed EBI_SIZE to the same size as the HTC released kernel source.
Changed VMALLOC to the same size as the HTC released kernel source.

V2
Changed Makefile.boot - changed to initrd_phys-y := 0x1A200000 (credit to rayman84)

---------------------------------------------------------------------------------------------------------------------
Credits:

* TigerTael - That's me! I spent hours picking away at the kernel, doing differential calculations, picking through dmesg's and logcat's. No donations necessary! This is for you guys!
* rayman84 - Thanks for your help! If you had not come along when you did, I might've spent countless hours without results if it weren't for you. (I forgot to edit my Makefile.boot)
* Radix999 - Thanks for your help man! I appreciated all the support.
* zinx @ Freenode - Thanks man! Your help made this possible!
* setenza01, kingchris, Wysie, thanks for all your dmesg/logcat/other herlp! We would've not gotten this far.
* gboddina -
gboddina's kernel with his kernel config and wlan module, iptables, etc. (Note: This includes a ramdisk, may not work properly on all ROMS. Have the ROM cooker integrate this kernel for you!). V4 apparently works just fine. V5 was giving me time issues.
* #android @ Freenode
* biktor_gj - Thanks for chipping in and general help!
* Maxisma - Thanks bud!
* Thank you everyone else! We still need your help! (The Android community as well as any bug reports)


Things that are working:

* SDCard
* Memory - (All memory)
* Camera - (Special thanks to zinx @ Freenode!)
* GPU1 - (Pretty sure this is right)
* ADSP - (Pretty sure this is right)
* MDP - (Untested)
* LED's - working fine.
* GPS -working fine.
* Bluetooth - working fine.
* WLAN - Working 100%


Things that are not working yet:

* Unkown (Hopefully none)
 
 
14th August 2009, 02:39 PM |#2  
Senior Member
Flag Sion
Thanks Meter: 1
 
More
Sapphire 32B :

cat /proc/iomem
00700000-007fffff : msm_panel.0
10000000-164fffff : System RAM
10024000-10352fff : Kernel text
10354000-104293b7 : Kernel data
16d00000-16d1ffff : ram_console
a0200000-a0200fff : msm_serial_hs.0
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : msm_sdcc.2
a0800000-a0801000 : msm_hsusb
a9900000-a9900fff : msm_i2c.0
a9900000-a9900fff : msm_i2c
a9a00000-a9a00fff : msm_serial.0
a9a00000-a9a00fff : msm_serial
aa200000-aa2effff : mdp
aa600000-aa600fff : msm_mddi.0
e8100010-e8100017 : leds-cpld
TigerTael
14th August 2009, 03:07 PM |#3  
Guest
Thanks Meter: 0
 
More
@setenza01,

Thanks for that, it will help...

Could you possibly do 'dmesg' and pastebin it please? This is also important!
14th August 2009, 03:19 PM |#4  
Senior Member
Flag Sion
Thanks Meter: 1
 
More
Fore dmesg : http://pastebin.com/m14bad41a
TigerTael
14th August 2009, 03:21 PM |#5  
Guest
Thanks Meter: 0
 
More
@setenza01,

Thank you again. Hopefully with this I can backwards calculate the memory locations with the current sapphire source and then examine the dmesg from a working 32A kernel and calculate the differences.
14th August 2009, 03:40 PM |#6  
Senior Member
Thanks Meter: 6
 
More
Good luck and thanks for the hard work! Are you working with biktor_gj?
14th August 2009, 06:13 PM |#7  
*child's Avatar
Senior Member
Thanks Meter: 314
 
More
Godspeed
TigerTael
14th August 2009, 06:36 PM |#8  
Guest
Thanks Meter: 0
 
More
Quote:
Originally Posted by Wysie

Good luck and thanks for the hard work! Are you working with biktor_gj?

At the moment, I'm not working with biktor_gj, but we have exchanged words in other threads and I found his other thread where he is attempting to get a 32A flashed with a 32B radio, up and running with all its memory.

My attempt is the opposite of this as I am trying to actually compile the kernel purely for a 32A with a radio that is made for 32A devices (I.E. stock radio). We're not exactly working together, but I will be keeping an eye on his attempts. Perhaps we can learn from each other and may end up cooperating. I'll be working on this tomorrow afternoon I think, as I have studies in the morning.
14th August 2009, 07:00 PM |#9  
Senior Member
Thanks Meter: 6
 
More
Ah ok, thanks for the hard work ! Haha. Hopefully both of you or one of you find a way!
14th August 2009, 10:44 PM |#10  
shwan_3's Avatar
Senior Member
Flag gothenburg
Thanks Meter: 0
 
More
Quote:
Originally Posted by TigerTael

At the moment, I'm not working with biktor_gj, but we have exchanged words in other threads and I found his other thread where he is attempting to get a 32A flashed with a 32B radio, up and running with all its memory.

My attempt is the opposite of this as I am trying to actually compile the kernel purely for a 32A with a radio that is made for 32A devices (I.E. stock radio). We're not exactly working together, but I will be keeping an eye on his attempts. Perhaps we can learn from each other and may end up cooperating. I'll be working on this tomorrow afternoon I think, as I have studies in the morning.

Thnak you man! make it work and we (I) will donate you a drink for sure!
TigerTael
15th August 2009, 10:24 AM |#11  
Guest
Thanks Meter: 0
 
More
Thanks to setenza01 for the previous dmesg.

However, I need somebody else to do a 'dmesg' for me. setenza is using a newer kernel, 2.6.29, and I am currently trying to reverse engineer a 2.6.27 kernel.

I will try and use this dmesg, but one that is running a true 2.6.27 would be more beneficial.
Post Reply Subscribe to Thread

Tags
32a kernel help

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes