Just learnt something that to my knowledge isn't documented anywhere that I know of and thought I'd share it - I'm not the greatest kernel hacker, but I'm okay at documenting sh*t - the wiki is proof of that
For anyone who's ever built a 32a kernel using TigerTael's patches - well it turns out we've been doing it all wrong and Zinx (from #android) has finally set me straight on it all.
Firstly, we've kinda missed the boat a bit with our existing kernel patches and it's had one casualty so far - Rogers Dream users. These users use the same Radio as HTC Magic 32a
Instead of using that 32a/32b as an discerning factor for kernels what we should really be using is RADIO VERSION.
Phones with radios with 1.xxx or 2.xxx versions are EBI0 - or what we think of as 32b - these are limited to 128MB ram.
Phones with radios with 3.xxx versions require EBI1 - this has a special fix to allow up to 256MB ram.
HTC actually released code in their kernels allowing us to switch between EBI0 and EBI1 with a single kernel config option while using the same codebase - unfortunately it was in the 2.6.27 kernel and since most of us have switched to 2.6.29 we stuck with TigerTael's patch.
TigerTael's patch doesn't work for Rogers Dream users though!
Zinx has extracted a HTC's code and it can now be applied to any kernel tree quite easily - and since its implemented as a kernel config option you're not breaking your code by including it.
You can download Zinx's kernel patch here:
http://zenthought.org/tmp/MSM_AMSS_SUPPORT_256MB_EBI1.diff
You can apply this to your source tree the same way TT's patch was done:
cd kernel_dir
patch -p1 < MSM_AMSS_SUPPORT_256MB_EBI1.diff
Click to expand...
Click to collapse
And then you enable MSM_AMSS_SUPPORT_256MB_EBI1 in your kernel config if you want to build for all EBI1 phones (or disable if you want EBI0 for older Dreams and 32B sapphires).
I'm thinking this should replace the 32a/32b stuff we've named everything up until now - and instead of getting people to check that in the wiki we should be just going by radio versions.. but it depends what you all think really.
I'll be doing all my CyanogenMod ports this way from now on - and hope to get this patch put directly in his github repo to make it easier in future.
If you use this patch - I think it should be specified as EBI1 and EBI0 from now on - perhaps that's expecting too much, but it will let everyone know.
I hope that the rest of you who build your own kernels can do the same!
Awesome - Looks like Cyanogen's going to update his github source to include the MSM_AMSS_SUPPORT_256MB_EBI1 patch according to his latest tweet:
Cyanogen: @Radix999 yes ill patch it in tomorrow
Click to expand...
Click to collapse
This should make it veeeery simple to build a EBI1 compatible kernel in future - just one kernel config option!
Radix999 said:
Just learnt something that to my knowledge isn't documented anywhere that I know of and thought I'd share it - I'm not the greatest kernel hacker, but I'm okay at documenting sh*t - the wiki is proof of that
For anyone who's ever built a 32a kernel using TigerTael's patches - well it turns out we've been doing it all wrong and Zinx (from #android) has finally set me straight on it all.
Firstly, we've kinda missed the boat a bit with our existing kernel patches and it's had one casualty so far - Rogers Dream users. These users use the same Radio as HTC Magic 32a
Instead of using that 32a/32b as an discerning factor for kernels what we should really be using is RADIO VERSION.
Phones with radios with 1.xxx or 2.xxx versions are EBI0 - or what we think of as 32b - these are limited to 128MB ram.
Phones with radios with 3.xxx versions require EBI1 - this has a special fix to allow up to 256MB ram.
HTC actually released code in their kernels allowing us to switch between EBI0 and EBI1 with a single kernel config option while using the same codebase - unfortunately it was in the 2.6.27 kernel and since most of us have switched to 2.6.29 we stuck with TigerTael's patch.
TigerTael's patch doesn't work for Rogers Dream users though!
Zinx has extracted a HTC's code and it can now be applied to any kernel tree quite easily - and since its implemented as a kernel config option you're not breaking your code by including it.
You can download Zinx's kernel patch here:
http://zenthought.org/tmp/MSM_AMSS_SUPPORT_256MB_EBI1.diff
You can apply this to your source tree the same way TT's patch was done:
And then you enable MSM_AMSS_SUPPORT_256MB_EBI1 in your kernel config if you want to build for all EBI1 phones (or disable if you want EBI0 for older Dreams and 32B sapphires).
I'm thinking this should replace the 32a/32b stuff we've named everything up until now - and instead of getting people to check that in the wiki we should be just going by radio versions.. but it depends what you all think really.
I'll be doing all my CyanogenMod ports this way from now on - and hope to get this patch put directly in his github repo to make it easier in future.
If you use this patch - I think it should be specified as EBI1 and EBI0 from now on - perhaps that's expecting too much, but it will let everyone know.
I hope that the rest of you who build your own kernels can do the same!
Click to expand...
Click to collapse
how will all this help out the end user?
We can use the kernel that the rom devs use for their rom, instead of using a 32A kernel from a 32A rom, which may not be 100% compatible
The biggest change will be that all Rogers Dream users will be able to start using our kernels without having to rebuild their own all the time.
Previously they were unable to use G1/Dream/32B kernels, nor our hacked TT-32a kernels because of the way we were doing it.
Very little change for anyone else - though for kernel developers it will instantly mean we can have a single unified kernel source for all kernel builds (still not unified roms yet, but we'll get there!).
One boot.img for Dream/32b magic
One boot.img for Rogers Dream/32a Magic
Thanks for all these doc although I'm not a developer hence don't understand it fully
however anyone implemented this on 32A kernel for Hero ROM?? Am very eagerly expecting it
Hey that's a good question.. what does the Hero use?
Anyone willing to try my cyanogenmod port to see if it works for Hero too?
It may well mean Hero roms can use the same boot kernel as 32a too.
Edit: Bleh.. I worded that really badly. I mean HERO Owners.. ie. actual Hero hardware. Not people using Hero roms on their magic or dream.
This code comes from the HTC release kernel source. It's been around for a while.
It think it's a little misleading to say that the patches prepared by TigerTael were doing it all wrong. His patches did essentially the same thing without giving the option to switch in .config
I don't see what this has to do with the radio version? The memory map depends on two things. The size of the SMI memory (32 or 64) and the size of the EBI1 memory (128 or 256).
As far as I know:
Dream (classic) SMI = 64 EBI1 = 128 TOTAL = 192
Dream (rogers) SMI = 32 ? EBI1 = 256 TOTAL = 288 ?
Magic/Sapphire 32a SMI = 32 EBI1 = 256 TOTAL = 288
Magic/Sapphire 32b SMI = 64 EBI1 = 128 TOTAL = 192
Radix999 said:
J...
Zinx has extracted a HTC's code and it can now be applied to any kernel tree quite easily - and since its implemented as a kernel config option you're not breaking your code by including it.
...
Click to expand...
Click to collapse
When you say "any kernel tree", does this mean we are no longer restricted to 2.6.29? Not that I'm aware of any exciting newer kernel features for embedded devices (but there very well could be), but does this make it easier to try out Android with 2.6.31.x? Is there any value in doing so?
Raydicks I love you
Hi,
could you please give us a more detailed guide about the patch use?
You wrote:
cd kernel_dir
patch -p1 < MSM_AMSS_SUPPORT_256MB_EBI1.diff
Which is the kernel dir?
Thanks
If you're not a kernel developer then this doesn't apply to you and you're just cluttering up this thread.
You apply it only if you're actually BUILDING a kernel - ie from Android's git or Cyanogen's github source tree (though as Cyanogen is applying it tomorrow you won't need to soon).
If you are a kernel developer, then you should know where your kernel source is.. sheesh!
Thanks for the info and patch, will definitely try!
TheStrider said:
Hey Radix. Just trying to understand what it actually means to enable this config option in the kernel (well I know what that means but what's the outcome).
Does the config option allow you to build a kernel that supports both 32a and 32b devices?
From your comments I understood that it will help Rogers 32b users out, but does nothing really for us 32a users (Rogers). So tomorrow if Cyanogen adds the option it doesn't mean I can go and flash his ROM without doing a kernerl port first....
Can you set me straight..
Cheers.
Click to expand...
Click to collapse
Yeah, unless Cyanogen's new trick for the new release is 'detecting radio version at runtime and installing appropriate boot.img' then no - You're still going to need a kernel port - there's no unified kernel (yet anyway).
But on the upside, the kernel port will be:
a hell of a lot simpler as it's the same code base, just a EBI0/EBI1 toggle - and Cyanogen may himself provide the port because he can.
now support Rogers Dream users as well with all EBI1 ports
not so hacky
daproy said:
This code comes from the HTC release kernel source. It's been around for a while.
It think it's a little misleading to say that the patches prepared by TigerTael were doing it all wrong. His patches did essentially the same thing without giving the option to switch in .config
Click to expand...
Click to collapse
Unfortunately this is not true, TigerTael's patches were NOT working for other EBI1 handsets - namely Rogers Dream. His code was a quick hack to get things working for 32a only.
Zinx's patch adds HTC's own code which does it properly for all EBI1 handsets.
Does anyone has a EBI1 kernel I could test on Hero please?
Lox_Dev: I can package one up for you, but I'll need the ramdisk from whatever rom/kernel you're currently using. If you have an existing boot.img - let me know where it is and I can package one up for you to try.
No guarantees it'll work on a Hero, but you never know!
Radix999 said:
J
HTC actually released code in their kernels allowing us to switch between EBI0 and EBI1 with a single kernel config option while using the same codebase - unfortunately it was in the 2.6.27
Click to expand...
Click to collapse
The developers from HTC were probably laughing at our efforts to develop the 32A kernels. Now, if they had just released a patch for the AOSP code, then everything would have been much easier.
This sound interesting, has anybody been able to get it to work?
I'm using it for my cyanogenmod port already... After checking out the Hero kernel dump that htc just did I'm not so sure about it actually working on Hero hardware tho.
Related
I was talking with people on #android and they mentioned that stock kernels are not working on sapphire 32A boards. I went poking through google's repository and didn't see any code specific to sapphire at all. But I did find some in codeaurora's fork. I don't have a sapphire device so I can't test any of this, but perhaps it would be a useful starting point for someone trying to build kernels for the Magic.
https://www.codeaurora.org/
A list of projects in their git repository:
https://www.codeaurora.org/gitweb/quic/la/
here's a more direct link to the sapphire-related setup.
I notice that linux/arch/arm/mach-msm/board-sapphire.h has a header which lists Thomas Tsai <[email protected]> as the author, which seems authoritative enough.
Nevermind. That fork appears to be missing patches that HTC is using in their kernels too. Sorry.
That repo just looks like a clone from Google with some added stuff for more Qualcomm MSM boards.
If you look closely in the Google tree you will see the same board-sapphire stuff in the exactly same place, ie kernel/arch/arm/mach-msm
I'll give a try with this one:
https://www.codeaurora.org/gitweb/quic/le/
on my sapphire 32A board.
Maybe ?
gboddina said:
I'll give a try with this one:
https://www.codeaurora.org/gitweb/quic/le/
on my sapphire 32A board.
Maybe ?
Click to expand...
Click to collapse
Those changes are pretty recent, give it a try and report back man =D
Damn! It don't want to compile !
I used HEAD code... I'll try another release later...
BTW, in this version seems to have a lot of qualcomm specific configuration. I guess if we find the right values (and we compile it), maybe we can boot it .
Kernel builds without any problem, will give it a try to see if it boots.
edit: seems i was to quick about the build. complains on some damn halibut file, will remove from config and try again.
Yes exactly the same problem.
Changing it into the config don't change anything, the build process include it anyway.
I blanked the files (board-trout.c will give the same result) but then, there is a problem in board-sapphire.c ...
Ported JACMAN_xROM_v1.4r3 to Magic [32a] with Tiger Tael Cyanogen 2.6.29-htc kernel
2nd Splash Screen (animated) may be black...(if you know how to fix this, point an answer my way)
Appears stable.
JACMAN_xROM_1.4r3_[32a]_sapphire_signed.zip
I'm new to 4shared, so if bandwidth limits are going to be a problem, someone should probably mirror it right away.
If the ROM cookers could give you a 32B kernel config for their ROMS, I could compile a 2.6.29 kernel for 32A handsets instead of trying to use the one from Cyanogen's kernel config. He has extra modules and stuff which may cause problems with other ROMS. Also, just to note that this kernel isn't compiled from an official HTC source, it is using the Google kernel source with my own kernel patches.
TigerTael is right. I cooked a Hero ROM with this kernel, and the results after a few minutes of use were: extreme chopiness and overall slow experience!
Be aware!
Great!
Thanks, Nolsen! This ROM looks great.
the only issues I have noticed so far are:
1. Web Browser force closes on start
2. Home screens default to 3 on reboot - have to go back into Extended menu and then it restores to the selected number
B.
I'm trying to compile the source (from the Sapphire link), but am running into compile errors in the iptables/netfilter subsystem
Seems there are filename case issues.. Which I resolved, but now getting an undefined symbol IPT_DSCP_MASK
It's not defined anywhere in the kernel source.
----
Subsequently tried the hero source and get
http://member.america.htc.com/download/RomCode/Source_and_Binaries/kernel_hero_0078c992.tar.bz2
This fails on undefd:
CC arch/arm/mach-msm/htc_battery.o
arch/arm/mach-msm/htc_battery.c: In function 'htc_set_smem_cable_type':
arch/arm/mach-msm/htc_battery.c:405: error: 'ENOTSUP' undeclared (first use in this function)
----
Can HTC really say that they released the source when it won't compile out of the box?
Anyone else have these issues?
Apparently, no one ever compiled the 2.6.27 kernel... simply amazing! (well, also, everybody is doing their stuff for their specific device, so you'll have to ask around in multiple forums like Dream, Hero, Nexus, etc.)
I didn't either.. but here is a nice starter guide.
The errors you get are probably due to missing files (they are available from your device).
In that starter guide he is building android itself, not the kernel...
I've been through every kernel build doc that google can reference...
The errors could be due to missing files... Why they are a missing is a mystery; as the kernel sources were those officially released by HTC for the device...
I even replaced the .config with that from my device.
Will try to pull a 2.6.27 kernel from the git this weekend and go at it again...
magicdroid said:
Apparently, no one ever compiled the 2.6.27 kernel... simply amazing! (well, also, everybody is doing their stuff for their specific device, so you'll have to ask around in multiple forums like Dream, Hero, Nexus, etc.)
I didn't either.. but here is a nice starter guide.
The errors you get are probably due to missing files (they are available from your device).
Click to expand...
Click to collapse
Stupid HTC kernel source...
I tried dozens of times to get it to compile and it never wanted to work.
Try this kernel source. Works for HTC Magic 6.35 radio and the HTC Hero (different .config)
http://github.com/cursordroid/HTC-CCR-Kernel
Thanks CD,
I was trying to compile for the old radio/SPL... There is an interlacing issue we are running into with this 32A on 2.6.29 so I want to build s 2.6.27 as it is supposed to be ok there, then figure out what has changed; or what is the difference with the board/chip variant in this version of the Rogers 32A...
Thx!
Kernels 32A
Questions for the enlightened:
1) If I want to build a Donut rom for the 32A, I need to compile a 2.6.29 kernel?
2) And if I want to build an Eclair rom for the 32A, I need to compile a 2.6.30+ kernel?
3) And these specific kernels need to be configured (forward-ported) for the 32A?
I think I'm getting there.. or not?
magicdroid said:
Questions for the enlightened:
1) If I want to build a Donut rom for the 32A, I need to compile a 2.6.29 kernel?
2) And if I want to build an Eclair rom for the 32A, I need to compile a 2.6.30+ kernel?
3) And these specific kernels need to be configured (forward-ported) for the 32A?
I think I'm getting there.. or not?
Click to expand...
Click to collapse
Donut and Eclair both require 2.6.29 kernels.
Eclair can run on a 2.6.30+ kernel
And you're right, we need specific kernel source for the 32A to get 2.6.29 or higher kernels.
Thanks for the input Cursor!
Maybe I'm wrong, but it seems to me that Magic kernel development is something that is mostly done solo. I know there are custom kernel sources available, but you have like a dozen to choose from, there doesn't seem to be any (community) effort to build one single kernel that could be used for all roms.
Wouldn't it help getting more result if people just would share their precious little spare-time and work together?
I'm thinking of starting an xda-msm-2.6.29 branch based on android-msm-2.6.29-donut..
Wait.. that would be yet another branch
I built the android2.1 rom from the official source code for my htc magic 32A. But the wifi doesn't work. So I want to compile the kernel and the wifi driver. Could somebody tell me the detail step to do this? And I want to know which kernel should be used for android2.1? Any help will be appreciated!
http://androidspin.com/forum/showthread.php?t=2207
http://wiki.cyanogenmod.com/index.php/How_to_build_a_kernel_port
I would recommend to build from cyanogen .33 source for eclair as it is complete and works 100% with eclair - he updates and fixes bugs regularly as well
Thanks for your reply! Do you mean I should use the origin/android-msm-2.6.33 branch to compile the kernel?
Many people want to run a working froyo on their devices.
This won't be possible in a clean way without compiling a new kernel.
To archive this goal, we need to merge the Huawei specific device drivers (which are for 2.6.29) into a new kernel tree, the 2.6.32.9 one (or even 2.6.35 but 2.6.32.9 comes first since it is stable and thus important to us).
I did some research and preliminary work which I will explain here:
- The base kernel Huawei started with is available here (gitweb) - also check their wiki.
- Huawei started with the Q8650BSDCANLYA324020 tag on the donut_glazed branch (see instructions at the end of the post)
- Huawei has written it's own board driver (note they have used a Q8650 kernel release not a MSM7x25 one, most likely because this board driver is a little older and was not available for the version they wanted)
- After they were finished writing their drivers they released the kernel source (as you can download it from Huawei)
I have checked out the Q8650BSDCANLYA324020 base kernel version and diffed it against the kernel release of Huawei, generated a patch file (and stripped out the DOS linebreaks wtf) which can be applied to the base kernel.
Applying this patch to a more recent kernel (2.6.32.9) is not possible without merging the code into the new kernel tree (and since I'm not a programmer I can't do it - this is were your help is needed).
The other question is in which kernel tree we can port the patch I have extracted. I think we can use Q8650BSDCANLYA504005 on the froyo_almond branch since Huawei used an older version of it. Merging it into the AOSP msm-2.6.32.9 tree may be possible too (but the code aurora msm kernel is an improved AOSP version, so I guess we want that one).
My patch (and some non-pulse-mini fixup patch) alongside with a freshly extracted and fixed .config for the U8120 can be found at http://nico.core.ws/misc/huawei_kernel_u8100_8110_8120/
To port the source you need to checkout the original source (Q8650BSDCANLYA324020), create a new branch in which you apply the Huawei patch, then checkout the froyo kernel (Q8650BSDCANLYA504005) and merge your branch containing the changes from the patch into it.
Another way may be porting the froyo kernel tree back to the eclair one with Huawei patches.
Please post any results/questions/etc. here!
If we should get this working we can also enable the GPU driver (Adreno 200) as requested by many people (and much more (CyanogenMOD anyone? )).
Appendix:
Instructions on how to get the original source:
$ git clone git://codeaurora.org/kernel/msm.git
$ git checkout Q8650BSDCANLYA324020
Instructions on how to apply the patch (assuming "msm" is the kernel tree):
$ cp diff_kernel_msm_aurora_Q8650BSDCANLYA324020.diff msm/
$ cd msm/
$ patch -p1 < diff_kernel_msm_aurora_Q8650BSDCANLYA324020.diff
If you are compiling for U8100 or U8120 phones, you need to apply another
patch which fixes sensors (otherwise your phone won't be able to read battery
level and stuff):
$ cp needed_fixes_for_non_u8110_devices.diff msm/
$ cd msm/
$ patch -p1 < needed_fixes_for_non_u8110_devices.diff
Note that the above instructions will get you nothing new, only the kernel already running on your device.
This thread is about porting the Huawei patch to a froyo kernel.
Very nice! Thank you for this topic!
I hope this will be successfull
Are the Atheros sources included aswell?
[GER]Roxxor said:
Are the Atheros sources included aswell?
Click to expand...
Click to collapse
To be honest, I don't know. They should be in there though (maybe under a more generic driver name or integrated in the board driver) otherwise Huawei would have violated the GPL.
The problems with the fixes:
wifi
They got almost wifi working in other post
radio
FM radio too with an 3rd party app
dpad
dpad crash in this post too 2 pages back just disable this
screen calibration
calibration fix can meaby be fixed with HTC calibrate??(its an calibration app)
sound
I solve the sound problem with my phone is to replace the libaudio.so from 2.1rom,maybe you can try.\
cedric123 said:
here is an source for the adreno drivers.
https://www.codeaurora.org/gitweb/q...b819424af4be;hb=refs/heads/android-msm-2.6.32
Click to expand...
Click to collapse
Basically this is the complete kernel source for froyo without Huawei patches (it's the wrong tag too).
When we have ported the drivers we easily can enable that driver.
cedric123 said:
the froyo kernel source: http://www.huaweidevice.com/tcpsdow...&attachmentName=kernel-2.6.32-U8150-Froyo.zip
Click to expand...
Click to collapse
Thats the source for the U8150, not the ones we want. The only thing which may help us at a future point in there is the kernel config.
cedric123 said:
If you compile a kernel right now you'd get a kernel that won't read the batterylevel and the magnetic compass won't work so we need to make a few adjustments.
Click to expand...
Click to collapse
This is in needed_fixes_for_non_u8110_devices.diff
So nothing new here.
So what can we do to help?
Is there a way to chat in XDA?
Any news on this?
cedric123 said:
here is an source for the adreno drivers.
LINK REMOVED
Here are some are adreno 200 drivers from a Custom nexus one ROM:
Areno Drivers package contains the adreno rivers only(i could miss some drivers here so look for the package above contains all drivers from the nexus rom
LINK REMOVED
Click to expand...
Click to collapse
Possible to make an update.zip for this Adreno 200 driver on 2.1 while 2.2 is not working?
editeditediteditediteditedit
Maybe he's working on the project.
Leito92 said:
Maybe he's working on the project.
Click to expand...
Click to collapse
I dont think so he's not saying anything about it for 1 week now...
But even if he doesnt say anything, this topic can be useful.
Someone with git/kernel/c knowledge need to port the patch.
nicoderboss said:
Someone with git/kernel/c knowledge need to port the patch.
Click to expand...
Click to collapse
Who can do That?
Kallt_kaffe meaby?
nicoderboss said:
Someone with git/kernel/c knowledge need to port the patch.
Click to expand...
Click to collapse
You need some elemental knowledge in C and then simply cut and paste the text in the files.
However, I think that it is more important to be able to compile from source and install the existing Huawei Linux kernel for the U8120. That is, can we compile from source all the code for Android 2.1-update1 and install on the U8120?
It might be good to try to get CyanogenMod on the U8120 for the kernel version that Huawei provides. Then, we can cut down the 1.5MB patch into smaller parts, and even try to get the drivers included in the Linux kernel.
I have not idea how to compile Android 2.1-update1 and get the plain old android source on the phone. I am willing to invest the CPU clocks to compile it, though.
cedric123 said:
Who can do That?
Kallt_kaffe meaby?
Click to expand...
Click to collapse
Dunno, it's quite a huge and advanced task.
Sent from my Vodafone 845 using XDA App
maybe we can get some kernel developers from the desire topic to help us?
I have send Benee, deovferreira, Kali- a PM maybe they could help us
nicoderboss said:
Dunno, it's quite a huge and advanced task.
Sent from my Vodafone 845 using XDA App
Click to expand...
Click to collapse
Can we just replace the normal kernel in the command list for the new kernel so you apply patch in the new kernel(u8150)froyo kernel?
I have had contact with benee a kernel developer for the htc desire. He is willing to help but he needs a device so he can test kernels he build. It is not possible to build kernels without a device because this is a huge project without a good base.
Maybe we can setup a fund raiser to get him a device?