Related
1. Usage
./editor.sh [place where the kernel is] [ place where your ramdisk is]
### you must let editor.sh know where your cross compiler is.
open "editor.sh" and edit COMPILER
2. Example
./editor.sh /home/zero/Desktop/test/zImage /home/zero/Desktop/test/my_initramfs.cpio
3. Info
- can not use an initramfs which is bigger than the stock initramfs.cpio's size
>> for instance, stock JM8's got an "initramfs.cpio" which is 3.4MB.
you can use reasonably bigger initramfs by gzipping the initramfs.cpio ->> initramfs.cpio.gz
this process reduces the initramfs.cpio's size but still can't use if initramfs.cpio.gz is bigger than 3.4MB
(this means that if a kernel already has gzipped initramfs, it is difficult to make it. you may want to remove something in order to have more room.)
- you can choose either your_initramfs.cpio or your_initramfs.cpio.gz
(this script compresses the ***.cpio if this is bigger than the stock.)
4. how to extract an initramfs from a kernel?
go to here
http://forum.xda-developers.com/wiki/index.php?title=Extract_initramfs_from_zImage
Thanks gshklover!
Thanks for this! I really appreciate the work you are doing
Sent from my GT-I9000 using Tapatalk
Sweet! Awesome work.
Any reason you now have TWO threads about this subject ? (Or: why not edit / add to your other thread about this ?)
Also, I have a toolset to do all this on Windoze without Linux and compilers... I used it to build the JPH root, but haven't tested it on enough kernels yet to consider it stable and publicly release it.
Hi,
I have tried these scripts on i9000WXJPA and '070701' is found 60 times and 'TRAILER!!!' is found 2 times! I find it a bit risky to assume that the first match is the right one!! z4ziggy's script doesn't even contain the -m 1 so I guess he believes there will always just be one entry!! There must be a safer way to extract initramfs from a zImage. Doesn't the header contain the exact entries where to find the partitions?
Thanks
JKay
Great script, thanks.
I'm trying to port this for use with the Galaxy 3.. uses s5p6442 processor.
Any idea what the mcpu and other flags/values would be when it's rebuilding the image?
Thanks
The eclair kernel compilation comes up with
-D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s
Click to expand...
Click to collapse
apparently s5p6442 is s5p6440's poorer cousin (the latter has at least a better CPU, arm1176jzf-s), but there's no information to be found on Samsung's website about it
good luck in making it boot and please share if you make it work, I didn't manage to get it working yet (I'm using z4mod and so far it's generating an invalid zImage)
Chainfire said:
Any reason you now have TWO threads about this subject ? (Or: why not edit / add to your other thread about this ?)
Also, I have a toolset to do all this on Windoze without Linux and compilers... I used it to build the JPH root, but haven't tested it on enough kernels yet to consider it stable and publicly release it.
Click to expand...
Click to collapse
Anyone mind to explain what the "compiling" is doing in a few words? It seems start and end are not changeable anyway.. checksums maybe? wild guess. Just curious. It works fine anyway.
Original thread here! >>http://www.neopeek.com/forum/Android-ROMs/5764-Ooops-WE-did-it-again!-Gingerbread-Alpha2-available <<
EDIT: Not for Sony Xperia X1. Works on my HTC Diamond so I can't say what other devices will do...Thanx everyone for testing the Pre-Alpha! I could fix several bugs! Now we are officially Alpha and it's quite usable on my HTC Diamond!
Ooops WE did it again...
My wife's still knocking my brain saying I am an idiot B) (while writing this she stands behind me). I spent some hours yesterday and several hours during the night cause I know everyone wanna try this out. I want especially say thanx to Chann who always is inspiring me with his ideas while I am doing some nice conversations with him on dev-section of this forum. It's really helpful to have such kind of member here.
More details later -> as always: I don't have time to test anything out on my own -> so I didn't! It's up to you to come back and report your experiences.
Alpha-release 26-12-2010
Before continuing be aware of: This is an Alpha release and now it seems usable (on my HTC Diamond it is!)! So before you do anything I suggest you to make a backup of your data / files! So read everything careful now :
What's inside ?? :
[ul]
[li]Gingerbread 2.3[/li]
[li]Working: Wifi, Data, Phone, SD-Card, Compcache 25%, automatic lcd-density settings and maybe more[/li]
[li]BT activating produces reboot (needs fix)[/li]
[/ul]
Important now!!!!!! Read:
[ul]
[li]First boot takes quite some time! [/li]
[li]I suggest you to open all apps and sync your account with google. Then reboot your device![/li]
For Download, click above link!
As always: Use this on your own risk!
Thanx go to: Balsat, XDAndroid-Project, Martin DZO and everyone else whom I forgot!
Download is a 1-file-download, again! Including everything you need!
EDIT: I need your experiences / feedback in this thread!
Installation:
[ul]
[li]Installation Instructions (Link) thanx to chase21[/li]
[li]Test-Kernels to try out (Link) thanx to hayabusa94[/li]
[/ul]
Please update your signature! It's always hard to find out which device / smartphone you use and which kernel(s) you are referring to!
Click to expand...
Click to collapse
-Neopeek!
Don't thank me! Thank Vatoloco/Neopeek!!
HTC raphael 800 can run but wifi not working (status: error) and battery drain fast.
I still waiting for Neopeek Team.
I am just instaling it... I can not wait for the final fully functioning version.
Cheers
Not stable enough for me at least (Fuze/RAPH110)... Guess I'll just have to deal with FRX03/FRX02 for now... ^_^
Kernel package: htc-msm-linux @ 20101204_005141
I have a Fuze and it works fine for me, but it is just a bit laggy (kernel does not support so well).
Remember he just hacked gingerbread to work with froyo settings but I can promise that future builds will be much better once every one else has started the development of gingebread on our devices
I kind of figured, just wanted to report my experience since it seems most of the newer kernels seems to half work on my Fuze with FRX03. Might just be something I'm looking over About to try again with newest kernel from Glemsom's site and see if the FCs are any less frequent.
Yeah, i'm using the latest glemsom kernel and it is slightly laggy but stability is much better. I have not tried any other kernels yet..
I'm using the old kernel & module 01238 from FRG83 R5 build in this Raph100 & it works just fine except for the known Android issues that we still have.
Some minor glitches in Gmail & root access rights reported by SetCPU, but overall a good build (stable) considering that it's still in Alpha stage. Anyway, we get to test run Gingerbread while most native Android devices are still running Eclair or Froyo!
hello, it runs fine with kernel 1190 from camera thread, for the keyboard use jap input. Reboot you can, do with the dev tools-bad behavior-crash system server. keep going man very good!
UPDATE
Gingerbread is working nicely! I have not tested everything but at least there are less FCs! I am using kernel package from Dec 26, 2010:
zImage & modules
NOTE: Check out F22's note about this specific kernel package from THIS post.
Better performance ?
Gingerbread is supposed to be faster than Froyo. I wonder whether this will translate into a better performance on the Diamond. The Diamond is a slow device (compared to the HD2) and there's not much that can be done about it, except overclocking.
HD2_addict said:
Gingerbread is supposed to be faster than Froyo. I wonder whether this will translate into a better performance on the Diamond.
(post trim)
Click to expand...
Click to collapse
Anyway we could interest you into test driving and giving it a once-over with your diamond?
I would love to try it myself on my touch pro cdma (raph800), but i can't afford to mess around with creating the separate partition to try this. Is there yet an alternative way, as i would love to test this out also?
I suppose I could try to make it into a .sqsh file so you can just boot off of it on sd card but no garuantee it will work...
I wouldn't mind trying it if you don't mind doing that. I keep my android2.2 in "setpath=android2.2" directory, and assume i could also do the same with this "setpath=android2.3" to keep them separate.
here it is: http://www.multiupload.com/6QEW8OFBMJ
*may or may not work*
Thank you much sir. I just unzip the sqsh file from that archive file into the main SD stick directory, correct? So far i followed the instructions and (at the time of writing this) was at the "run the install from the subdirectory, after it's done, it will reboot back into WM" part, and continuing.
Yes, that is correct. You don't need to run "install.exe" or need the npkinstall folder. It should be fully compatible with xdandroid and you don't need the files from neopeek.com.
Just boot it as if it were an xdandroid build and hopefully, it should display android logo. Ext2 is much faster.. give it a try when you can.
I might have to do that. All i get is the following (last 2 lines of the screen at boot)
"mmc1: error -22 whilst initialising SDIO card"
"Waiting for root device /dev/mmcblk0p2..."
and then just sits there for ever.
Are you using an xdandroid startup.txt or neopeek?
Hi all,
I have Fat Free Froyo installed with the latest 14th Jan 2011 kernel voguimg-240x320-2.6.32-froyo-14-01-11_14.nbh edited to froyo & panel type 2 from t029000.massey.ac.nz but Google Goggles needs ipv6 support.
Is this a kernel problem or a problem with the build itself? I am experienced in linux, so can modprobe or insmod the ipv6.ko but I don't know where to get it from
Any help would be appreciated!
(message for kernel's developers) take this man! he can dev ipv6!
Jumping the gun there a bit
I triage bugs and work on stuff for Ubuntu. Have also ported a few linux bits to ppc64 (PlayStation 3).
I'm pinching the ipv6.ko from slayhers latest kernel build, hopefully that will work insmod-ding or modprobing it into the kernel thru the terminal on the Kaiser itself.
So, fingers crossed, this may be solved in 5 minutes!!
Didn't work, it must be compiled for a different platform...
Anyone have or know where to get a kernel for the Kaiser with ipv6 support, or failing that the correctly built ipv6.ko for the Kaiser so that it can be insmodded?
Getting it compiled in the kernel is the easy bit, although it does use up a lot of space which is limited in the kaiser's kernel so a little tweaking is needed. Getting it to work with the Kaiser's modem and the builds we currently use is a different matter unfortunately. It will take a bit of modding for it to work but it's more then achievable with a bit of free time. Wish i could buy that stuff!!If i get a chance i will get you the ipv6 module for the kaiser's kernel or a kernel with support for it so you can have a play.
I definitely look forward to it! If I knew how and what to modify I'd do it myself, but I thought arch-specific kernels had to be compiled on the arch itself? If that's the case, I can see how free time would be needed, it'd take hours or days to compile the linux kernel at 400MHz
I have compiled kernels before so if/when I learn how to do it myself, I could start to use my own git repo for more recent daily builds or something.
I'm also thinking about starting working on some *buntu stuff (I know Ubuntu is there for the Kaiser, but soem tweaks would help if I get a chance.)
Hmm, a little Googling goes a long way http://www.androidonhtc.com/wiki/Get_Involved << was hard to find that,so hopefully I can add ipv6 somewhere in the 'make menuconfig' options for the kernel.
Are the standard kernel options used by "make vogue_defconfig" ok to use, i.e. will it build a normal useable kernel so that everything works?
xteejx said:
Hmm, a little Googling goes a long way http://www.androidonhtc.com/wiki/Get_Involved << was hard to find that,so hopefully I can add ipv6 somewhere in the 'make menuconfig' options for the kernel.
Are the standard kernel options used by "make vogue_defconfig" ok to use, i.e. will it build a normal useable kernel so that everything works?
Click to expand...
Click to collapse
Yes, that is th correct make file to use. I have built the kernel with IPV6 support, haven't tested it but have attached the module to the post for you to try
Brilliant! I'll try it sometime within the next couple of days, although I might myself be working on a blazing fast kernel specifically for the HTC Kaiser, and it is SERIOUSLY!!!! fast, even at 400MHz I can notice a massive increase in speed with the exact same build, but I haven't economised too much.
I can see the the options for ipv6 in the ncurses menuconfig, so I guess it's just a case of enabling it and building the zImage right?
I seem to be having the old problem with the wifi though, and I know it's kernel related, but there are only patches for it, i.e. the wlan.ko, but can't see how to implement it myself so it's an all-in-one solution
When I get the hang of the Kaiser hardware properly, I might just push through a newer kernel from the armlinux site so watch this space
xteejx said:
I might myself be working on a blazing fast kernel specifically for the HTC Kaiser, and it is SERIOUSLY!!!! fast, even at 400MHz I can notice a massive increase in speed with the exact same build
Click to expand...
Click to collapse
How have you managed that??? What have you done?
I have no idea how it happened, perhaps the other devs add a load of useless options, but all I did was follow the instructions at that link above and compiled a zImage from the 2.6.32 arm branch, using the 2010 arm tools. Used NBHeditor to edit it for Kaiser, panel 2, froyo, flashed it and bang (not literally thank god).
I can't answer any better than that. I used the default options (for now at least) that the vogue build script uses for the kernel, but bluetooth, camera and gps work. No internet connection as yet either through the network or wifi, dumno what I've missed there, and no ipv6 (but can add that easily enough). Wifi doesn't work either, but I'm working on it, although that MAY be the reason why it's so fast...maybe it's missing a few options...still unsure at this point.
I notice that although this is an open community, and people attach NBHs, there are no changelogs or anything showing what the people have done with the kernel to implement some options, so it's kinda holding me back at the minute.
xteejx said:
I notice that although this is an open community, and people attach NBHs, there are no changelogs or anything showing what the people have done with the kernel to implement some options, so it's kinda holding me back at the minute.
Click to expand...
Click to collapse
That isn't true, all tested changes are pushed to git, you can see what has been changed and how from here: http://androidhtc.git.sourceforge.n....git;a=shortlog;h=refs/heads/htc-vogue-2.6.32
*facepalm!*
Didn't see that, will bookmark it and keep an eye on it, perhaps work with it. Thanks for the link
the androidhtc.com site is not related directly to the develop project because no developer is connected to it. Also the git repository it not hosted in linux to go but on sourceforge (so download the correct git). That site is very outdated.
wifi works if you use the correct branch (on sourceforge) and modules.
Am I right in thinking that http://androidhtc.git.sourceforge.n...7c0bf5edc4f5c6d64ce4df29254e8332ce26b;hb=HEAD is the prebuilt kernels and nbhs from the source at http://androidhtc.git.sourceforge.n...og;h=62f075ddd13f378fd252be94c77e4f93d12584fb ??
I think I'm looking at the right tree now.
Flashing the latest NBH: VOGUIMG-320-FROYO-01-16-11.NBH still gives me the wifi error. Do I need to manually add the wlan.ko to it or ??
I could've sworn that an NBH I flashed before had all that in the NBH and it worked fine.
Ok, got it back to how I had it:
Flashed latest.NBH from http://androidhtc.git.sourceforge.n...7c0bf5edc4f5c6d64ce4df29254e8332ce26b;hb=HEAD and dropped androidupdate.tgz to the /andboot folder of the SD card, installed update thru the boot menu and done.
So in reality there's nothing stopping me grabbing the same kernel source, building it and adding ipv6 support in the ncurses kernel config menu and making an NBH from it and flashing that over, and then doing the androidupdate.tgz, although I think with HTCFlasherGUI you can flash a zImage directly right??
Is there something wrong with the git at http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/kernel.git;a=summary I can't get access, it's showing old stuff. It looks closed since git clone rejects me
xteejx said:
Is there something wrong with the git at http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/kernel.git;a=summary I can't get access, it's showing old stuff. It looks closed since git clone rejects me
Click to expand...
Click to collapse
No, nothing wrong with it. Just do:
git clone git://androidhtc.git.sourceforge.net/androidhtc/kernel.git
You then need to set it to the correct branch using 'git checkout -b <branch you want> '
It's the 2.6.32 branch you are interested in, you can find out exactly what it's called using 'git branch -a' which will list the available branches.
Cool. Knew something went wrong somewhere, had to be me lol!
I added that ipv6.ko to the NAND via a androidupdate.tgz (only way I could do it), and it didn't work, something about incorrect module format (or something like that).
Are there any prebuilt kernels or NBHs for the Kaiser that include ipv6? Either as a module that I can insmod it in the terminal or built-in?
I hate being upstaged by people that can use Goggles without any problems.
I know slayher's kernels have ipv6, but I flashed the new stock one from http://forum.cyanogenmod.com/topic/4434-froyo-kernels-by-slayher/ and it didn't work. I mean the kernel did, but Goggles didn't - couldn't insmod it either - same invalid module format as the ipv6.ko scooter did for me
Also the git clone didn't work:
Initialized empty Git repository in /home/name/android-git/kernel/.git/
fatal: The remote end hung up unexpectedly
CPUFreq Successfully Installed and Running
Please visit my website for additional information
After receiving alot of positive results from my Kernel and several releases later. We have arrived at RLS 5.9, a prototype build incorporating CPUFreq for CPU Scaling and Idle control, and a modified version of Power Management. We are at a release stage of this Alpha build, and approaching Beta, where it is as follows:
Each build that is released that has an update to CPUFreq will have an update to the first subversion in the build version (eg. RLS5.9.1.0)
Each build that is released that has an update to Power Management will have an update to the second subversion in the build version (eg. RLS 5.9.0.1)
And of course each upgrade to a specific subsystem of the Kernel will up the version number of that specific subversion.
Current Release: RLS 5.9.2.2
RLS 5.9.2.2 will mark the beginning of the Beta stage out of Alpha stage. This release is showing far more promising results than my initial CPUFreq release.
I just want to personally thank all who have been supporting me and reporting any and all bugs that have been coming in, as I have been squashing them left and right in preparation to improve our Kernel for our phones to make them more feasible for everyday use.
Currently Being Tested:
Power Management - Reverted some old changes to the power management code, switched too Apps Sleep. Made some minor changes to the original pm.c source code and results are promising. Running VanijlEclair RLS11, and in rare cases the phone still crashes while sleeping, which I believe is related to the phone hiccuping when going to sleep, which in theory could completely blow up the timer that Apps Sleep uses for sleeping. I will investigate this part further, but so far, RLS 5.9.2.2 is much more stable than my previous release.
CPUFreq - No changes to the source code, still attempting to modify permissions so Android can modify the files that are required.
HAReT Users - Thanks in large part to V3rt!g(o) HAReT users can now boot the Kernel. I have made a slight modification to the default.txt file provided in the RLS 5.9 HAReT archive that uses Apps Sleep instead of Power Collapse. From what was reported, the Kernel takes about 2 minutes to initialize from WinMo, but after about 1min30sec to 2min, Android should begin loading.
Radio ROM - Currently Testing Radio 1.71.09.01, and so far it seems very stable and provides better battery usage.
Current Release (RLS5.9.2.2):
Kernel - HTC Polaris support re-introduced.
CPUFreq - Has been installed, and working inside the Kernel only. Android does not recognize CPUFreq correctly.
Processor - MSM-7201 processor increased from 384MHz to 528MHz
Stability - Has been improved further. Phone correctly sleeps and wakes properly. Still occasional crash occurs, but is random. Could go a full day without a crash, or could crash every 4hrs. Issue might be related to how much the CPU is being utilized at the time of wake up.
Power Management - Power Management restored to near WinMo states, still not as good as RLS5.7, but within range. Phone will last a full day of occasional use, and about 80% of the day on moderate use.
Initrd - New BootLogo has been made, and inserted into initrd. Unfortunately boot menu is not accessible. Made install scripts to compensate.
YAFFS2 - Exclusively does ECC checking on it's own without any help from the NAND driver. This should help with data corruption, but is not a permanent solution.
YAFFS2 - Disabled Forced erase chunk checking, slight increase in response time and decrease in read-time.
MTD - Disabled Verify NAND Page Writes
MTD - Disabled GPIO NAND Driver
EXT - EXT2 is currently disabled inside the Kernel. EXT4 has been fully enabled, aside from journaling, and is fully supported in the kernel and install scripts.
System - Switched from DG (High Resolution) Timer, to GP (Low Resolution) Timer.
System - Fully disabled High Resolution Timer -- Provided a decrease in kernel size without loss of performance.
sysfs - Enabled configfs. This will unavoidably increase RAM usage, but allow easier access to sysfs.
MSM - Performance Counter Driver enabled.
FrameBuffer Driver - Decreased fake-vsync delay from 10 to 5. Less times snow effect appears.
Known Issues:
Internal CPUFreq coding is unable to scale the processor, but the hacked msm_cpufreq_* functions are able to control the processor speeds. This will explain why CPUTuner and other Android software is reporting the CPU running at max speed. Will continue to investigate and work out problems with the coding.
JIT Compiler causes issues with framework.acore. Avoid using if possible.
CompCache not the cause of untracked PID errors -- Still investigating cause, though now understanding that it is related to data corruption.
Possibly depending on Radio, GPS takes quite awhile to acquire if not at all. -- Will investigate by flashing an older/newer radio.
Standby code not fully working due to being incompatible with clock code changes. Attempting to re-write power management code to be better compatible with the new clocks code.
CPUFreq Specifics:
Governors - Currently CPUFreq supports the following governors and can be changed while in Android using the Terminal: ondemand, conservative, powersave, performance. Userspace is currently disabled inside the Kernel.
Frequencies - Baseline frequencies the CPU will scale to but not limited too are: 81920 (82MHz), 122880 (123MHz), 245760 (246MHz), 384000 (384MHz). These are just placeholders to control where the CPU needs to scale too base on usage, it will go between lets say 82MHz and 123MHz or use one of the two.
Userspace - Until I can verify CPUFreq is fully operational without any issues, I will not enable Userspace Governor at this time.
Kernel Modules
File Attached to this Post, see below.
This Kernel has been tested with the AT&T Tilt variant of the Kaiser. Using it on any other Kaiser would in theory produce the same results, but due to minor changes in the hardware of each variant of the Kaiser, I'm still going to stress caution when using this Kernel with any other variant of the Kaiser
Things to note about EXT4: This file system will increase read/write cycles to your SD Card. Use with caution as it will decrease the life of your SD Card. Though since Journaling is disabled, read/write cycles will have decreased, but they are still higher than what they would be if EXT2 was used. If you do not feel comfortable having EXT4 on your SD Card, do not use this Kernel as there is no way to use EXT2. You have been warned.
Things to take note with this Kernel: Do not enable JIT compiler under Settings, as this has produced constant FCs with the acore framework. It is recommended that you enable CompCache and set it to the default 18%, as this provides a significant performance boost, and decreases Home screen closures while running other apps.
USE THIS KERNEL AT YOUR OWN RISK. I TAKE NO RESPONSIBILITY FOR ANY DAMAGES DONE TO YOUR PHONE WHILE USING THIS KERNEL.
Woohoo ! First Post!
Thank you Krazy-Killa! Will definitely try this now will post after testing!
I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?
Hello Krazy-Killa,
Appreciate your effort !
I just installed it on my TYTN II and so far going well -edited .ngh to change the key mapping to normal.
3G works fine. yet to see BT,WiFi &GPS and overall otherwise.
I have tried Scoot's CM7 RLS1 build 2 days ago.is there any major changes you did - i feel some audio notification alerts changed w. r. t. Scoots.
how can i use those audio files if reqd-i mean can copy&dump to a specific folder and repack.
but its not really matter..
At the moment 'push' works fine and eager to see any 'server connection' problem will occur later with the email client.
i have radio 1.70.19.09
Thanks once again for the post.
Cheers !
cerebralgenius said:
I am liking what I am seeing. Thanks for putting the effort into creating this. I'm just curious about one thing, you said that Scoot's CM7 RLS1 build has the modules for this kernel included. Is there a separate download of the modules for anyone that might not be using this build?
Click to expand...
Click to collapse
I will release the modules as a seperate androidupdate file this evening.
@chandra_100,
All my testing shows BT, WiFi, and GPS working. This Scoots CM7 build I released is just repackaged with my built modules for easy install.
Sent from my AT&T Tilt using XDA App
“Removed support for HTC Polaris”
That’s too bad，poor Polaris，555555555555555~
The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault
dark_prince said:
The untracked PID errors are related to froyo only (maybe Gingerbread too). And its related to init.rc provided with each build. Not kernel's fault
Click to expand...
Click to collapse
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.
Krazy-Killa said:
Interesting... Well, I had a looping untracked PID this morning, had to reinstall, but that's mainly the only problem I'm now having... If I could I would build a new init, but the bootenv isn't updated.
Click to expand...
Click to collapse
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.
for me kernel can't find data.img
Ive go some kind of problem. Im using fresh froyo and when I installed your modules update than I got hang in boot. Excatly at "adb_open" line. Without update everything is ok except wifi.
Sorry for my poor english
Neo2SHYAlien said:
for me kernel can't find data.img
Click to expand...
Click to collapse
I'll look into it. Though I may know the reason why, so I'll do some more testing, and will release once I have it fixed.
scooter1556 said:
The bootenv is fully up to date The untracked PID's aren't caused by the init.rc, they are caused by corrupt filesystems or files which mean that the paths that sysinit.rc is trying to mount aren't there or it can't change permissions on a file because it is corrupt.
Click to expand...
Click to collapse
I'll update my local bootenv, thanks.
Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device
MaRekRM said:
Good release. Slightly slower than Clemsyn's kernel (tested in quadrant), but good stability. One thing drives me crazy - I have to wait 5-10 seconds after pressing power button to wake device
Click to expand...
Click to collapse
That was mentioned in the known issues, don't worry my next release will fix that (currently testing). Plus it'll add full EXT4 support like with clemsyn's kernel but you can format your SD card with the device now as I have updated initrd.
Sent from my AT&T Tilt using XDA App
Flashing
I'll try... flashing right now.
what about ipv6 support?
*EDIT* nevermind, i just saw that ipv6 is implemented.
Cannot restore databackup.img trough install menu...
I think this kernel canot handle the img fs. Mount is failing.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.
Backup FS
Krazy-Killa said:
It's because of EXT2 support being turned off... I'm currently testing a new kernel that'll be using EXT4. Running into the same problem you are having with img mounting.
I'm working on isolating the issue why img mounting isn't working.. It's possibly an issue with the init scripts. I'll dig more into it and hopefully get it isolated.
Click to expand...
Click to collapse
Probably the script that is generating databackup.img still using ext2.
tiagoclc said:
Probably the script that is generating databackup.img still using ext2.
Click to expand...
Click to collapse
Yep, it was exactly that. Just made the necessary changes, and compiled a new kernel. I'll go ahead and throw it out, but for now I'll point out that I haven't tested it so, please let me know the results.
Init itself is already setup to mount all loopback and SDcard partitions as EXT4 where applicable.
Just use atools to configure the kernel to use /system and/or /data on NAND or SDCard.
Why did you remove polaris support? I think that are plenty of polaris users that want to test your kernel
Thanks
First things first: THANK YOU to all those involved in the coding of this, especially the msm8660-common kernel that so many folks have put so much effort into, and Mr. Cyanogen for the device tree, etc etc. NONE of this would be possible without your efforts. I stand on the shoulders of giants in providing these instructions, the code is NOT mine, I'm just documenting this so you all can help contribute. Kindest regards to everyone who has contributed to make this possible. Your work has enabled the community to beat the vendor to the punch, yet again!
DISCLAIMER: This contains information on working with very early code as well as hacking together a completely unsupported Frankenstein build with some proprietary samsung binaries from another device (ATT Note) and I will warn you: If you aren't willing to risk bricking your device, don't even think about this. Also, I'm not so much a coder as I am a QA engineer, so I know enough to be dangerous, but I couldn't code C++ get myself out of a virtual crashing airplane if I had to. I also might not be able to help you out of a sticky situation, so... have fun at your own risk! But do have fun
Looking for binaries? See post #2
That said, it's honestly not likely any of this will brick your tab, if you know what you're doing, but... early software always carries danger, and using binaries from a similar yet different device can do who knows what.
Also of note: you should probably back up your EFS partition if you're going to hose with the radios to get cellular data working... hasn't been an issue for me, but... corrupt EFS partition = no more cellular data for you. ever.
Cyanogen has added initial support for the i957 to the CM10 repository, and it's looking good so far! But, there are no nightly builds yet, probably because Cyanogen would like to do some more work on it before handing out binary packages... Or maybe he hasn't figured out how to get things quite functional yet. I considered releasing a binary package for you to toy with, but then realized that would defeat the purpose of helping along the development of an official Cyanogen i957 (p5att) release, and lock you into something I already built from "pre-alpha" code. It's best to check out the latest source tree and do your own build, then you can easily test and contribute your modifications, should you find any.
So with that, here's some instructions on how to build CM10 for your SGH-I957 ("p5att") device from source code. This will also ensure time is spent doing development work, not hand-holding the faint of heart (sorry, sue me!)
These instructions assume you've successfully built Cyanogenmod for a supported device and understand the basics of getting things going. If not, start with that first, then come back to this. I'm also assuming you've got the android tools that you get from any build of cyanogen (like mkbootimg) in your path for some of the "optional" steps, which is of course elementary...
I'm also going to assume you know what to do with the resulting zip... You know... backup, factory reset, wipe system, flashy the zippy...
I really recommend doing the boot image modifications after the build, without ADB on boot, if something goes wrong, you'll have no way of knowing whats going on. If you get the boot image modified properly as detailed below, you will be able to ADB to the device as soon as the second boot logo disappears. Also, there's probably a cleaner way (like changing something somewhere to invoke one of the other case statements in init.qcom.usb.rc), but I didn't have any luck with that. Feel free to school me! :laugh:
EDIT: If you don't feel like hacking the boot image, just flash the one attached (ps: none of the zips below are TWRP/CWM flashable, just zipped up files.. dd if=bootimagefilename of=/dev/block/mmcblk0p8 from a root shell to flash the boot partition on the i957)
I've attached the initlogo.rle file to this post so you don't have to fish it out of the ramdisk embedded in the stock boot image. Adding initlogo.rle to the ramdisk gives you confirmation the kernel is bootstrapping, and it's disappearance indicates ADB is now available. Also, use a linux box for ADB! silly wabbit, windoze is for kids.
According to comments in system.prop, the cyanogenmod boot animation is disabled because the framebuffer is "weird". Strangely, it sometimes displays for me, one in 10 boots maybe. Weird!
Here goes.
----
Initialize Repo:
repo init -u git://github.com/CyanogenMod/android.git -b jellybean
Sync Repo:
repo sync -j6
... Coffee Break!
Breakfast for p5att:
. build/envsetup.sh && breakfast cm_p5att-userdebug
Modify device/samsung/p5att/BoardConfig.mk to clean up a few things:
Comment out:
#BOARD_SDCARD_DEVICE_PRIMARY := /dev/block/mmcblk1p1
#BOARD_SDCARD_DEVICE_SECONDARY := /dev/block/mmcblk0p28
#BOARD_SDEXT_DEVICE := /dev/block/mmcblk1p2
Add above these lines:
BOARD_HAS_SDCARD_INTERNAL := true
Modify device/samsung/p5att/device-proprietary-files.txt:
Comment out all the entries, because they aren't really needed and probably dont work with jellybean. Worry about this later, blah blah.
Modify device/samsung/msm8660-common/common-proprietary-files.txt:
Comment out all the WiFi stuff, that is, like:
# Wi-Fi
# etc/wifi/bcm4330_apsta.bin
#etc/wifi/wl
#etc/wifi/nvram_net.txt
#etc/wifi/wpa_supplicant.conf
#etc/wifi/bcm4330_p2p.bin
#etc/wifi/bcm4330_sta.bin
#etc/wifi/bcm4330_mfg.bin
#etc/wifi/nvram_mfg.txt
To get WiFi working later, you need /system/etc/wifi/* from your honeycomb image. Go save them to /sdcard/wifi or something like that now, so you can just copy them over after CM10 boots
Edit: attached the files
Extract proprietary files from i717 Note CM10 image, since I have no idea where else to get these files, and they work:
from device/samsung/p5att, run ./extract-files.sh <path to an extracted CM10 i717 nightly .zip>
... The path you provide should contain the "system" folder.. IE the root of the extracted nightly zipfile.
I had used the 0831 nightly with luck here.
Get prebuilts:
run vendor/cm/get-prebuilts
Do the build:
from the system directory of your CM10 source tree run:
. build/envsetup.sh && brunch p5att
Go find something or someone to do, this is going to take a while...
You'll end up with a .zip file to flash.
After you flash, you'll need to, manually:
1) Copy back the /system/etc/wifi/* files (wifi firmware/tools, the note ones dont seem to work).
2) Install a Skyrocket ICS AT&T radio if you want cellular data, the honeycomb radio doesn't seem to work with CM10. UCLF6 works for me, although it's slower to acquire LTE than the official samsung HC image... but it works great once it finds a cell, and HSPA comes up pretty fast.
3) Consider doing the stuff below to enable early ADB and add back the second samsung logo, for debugging purposes, if you care...
----
Things you might want to do after the build, start by unzipping the resulting .zip pacakge...
Edit: I attached a the resulting boot.img to this post so you don't have to do all this if you so desire. Bonus: working i957 JB kernel binary for whatever else you might want to do with it..
Remove the assert for platform type if your TWRP recovery, like mine, thinks it's a i717 Note:
Edit META-INF/com/google/android/updater-script, remove the assert lines (first two lines of that file)
Do some handy ramdisk hacks:
First, unpack the boot image. From the root of what you unzipped:
mkdir boot
unpackbootimg -i boot.img -o boot
cd boot
Then Unpack the initial ramdisk:
mkdir rd
cd rd
zcat ../boot.img-ramdisk.gz | cpio -id
Edit init.qcom.usb.rc to enable early adb:
Search for "on property:sys.usb.config=mtp", you'll find: (line 340, for me)
on property:sys.usb.config=mtp
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 04E8
write /sys/class/android_usb/android0/idProduct 6860
write /sys/class/android_usb/android0/f_acm/acm_transports tty
write /sys/class/android_usb/android0/functions mtp,acm
write /sys/class/android_usb/android0/enable 1
setprop sys.usb.state $sys.usb.config
Make this section like:
on property:sys.usb.config=mtp
write /sys/class/android_usb/android0/enable 0
write /sys/class/android_usb/android0/idVendor 04E8
write /sys/class/android_usb/android0/idProduct 6860
write /sys/class/android_usb/android0/f_acm/acm_transports tty
write /sys/class/android_usb/android0/functions mtp,acm,adb
write /sys/class/android_usb/android0/enable 1
start adbd
setprop sys.usb.state $sys.usb.config
Add the glowing samsung initlogo:
Copy initlogo.rle from the root of a stock ramdisk to the root of this ramdisk
... So you'll get the second samsung logo, so you know the kernel is bootstrapping... if you care.
Turn off ro.secure:
Edit default.prop in the root of the ramdisk and change:
ro.secure=1
to
ro.secure=0
Repack the ramdisk:
find . | cpio -o -H newc | gzip > ../boot.img-ramdisk.gz
(you may want to save the original, if you care)
Make the new boot.img:
cd .. (ie get back to the directory with the files listed in the next line)
rm ../boot.img
mkbootimg --kernel boot.img-zImage --ramdisk boot.img-ramdisk.gz --cmdline "console=ttyHSL0,115200,n8 androidboot.hardware=qcom" --base 48000000 --ramdiskaddr 49400000 --pagesize 2048 -o ../boot.img
Repack the flashable zip:
cd .. (ie get back to where you unzipped the original flashable .zip)
rm -rf boot (remove the extracted boot.img and ramdisk under it, save it somewhere if you care)
(also remove the original .zip from here if you extracted it in the cwd)
zip -r ../somezipname.zip .
Then flash somezipname.zip or whatever you called it..
(Remember you'll need to put the Honeycomb files from /system/etc/wifi into /system/etc/wifi of the running image after you boot if you want wifi
(And flash a Skyrocket ATT radio if you want cellular data!)
WARNING: FOR SAMSUNG SGH-I957 NORTH AMERICAN DEVICES ONLY
GT-SERIES (IE: GT-7320, etc) ARE NOT SUITABLE FOR THIS RELEASE
UPDATE ZIP DOES _NOT_ CHECK YOUR PRODUCT CODE, WILL HAPPILY EAT OTHER DEVICES
THIS IS A TEST RELEASE FOR EXPERIENCED ANDROID HACKERS
SOME FEATURES MAY NOT BE USABLE OR WORK AS INTENDED
BOOTLOOP ISSUE? USE TWRP 2.1.4: https://www.dropbox.com/s/u07zrx808a5ae2z/i957_twrp_recovery.img.tar
Latest Flashable .ZIP, update 7: http://droid.arm.ee/957/cm10_p5att_nrvate_testrelease7.zip
Use TWRP, factory reset and wipe /system if you are coming from another ROM. Don't forget to install google apps http://wiki.cyanogenmod.com/index.php?title=Latest_Version/Google_Apps
Update 2
* h264 hardware decode fixes for youtube HQ and other hardware-decode enabled apps (vidc/yamato firmware update)
* camera fixes from kunals.shah -- thanks!! (camera library in system/lib/hw)
* wifi address fix - get MAC from EFS, no more random address (insert proper path to .nvmac.info in dhd.ko kernel module)
* move /mnt/secure to internal sdcard to fix asec apps (asec folder linked to /sdcard/.asec)
* disable adb on early boot -- fix mtp maybe? (change to init scripts in ramdisk)
* remove a couple of (probably) harmless references to sdcard1 in init scripts
* update vold.fstab with the correct partition for the sdcard (26), not sure if anything even uses that, but...
Update 3
* Kernel Lovins ->
--- Picked up slew of bugfixes from msm8660-common cyanogenmod jellybean kernel tree -- up to and including 09/13/2012 commits.
--- Enabled CONFIG_USB_ANDROID_SAMSUNG_MTP and CONFIG_SPI_QUP kernel options to match SHV-140 ICS samsung kernel config
--- Disabled CONFIG_XVMALLOC and CONFIG_ZRAM kernel options, also to match up to SHV-140 ICS samsung kernel config
--- Now compiled with newest Sourcery cross-compiler
--- Modified dhd.ko (Broadcom WiFi kernel module) -- you can now create file /data/.ranmac if you want your MAC address randomized on each reboot (ignores MAC on EFS partition, random generation expanded to 5 bytes)
* symlink for light sensor (/dev/i2c11 -> /dev/i2c-11) -- Doesn't fix auto brightness, but at least things that access the light sensor via the standard API will get values back now, FWTW.
* RIL stuff from SHV-140S (korean Tab 8.9 LTE) -- An attempt to resolve SIM_NOT_READY error -> Files replaced:
/system/lib/libril-qcril-hook-oem.so
/system/lib/libsecril-client.so
/system/lib/libreference-ril.so
/system/lib/libril.so
/system/lib/libril-qc-qmi-1.so
/system/bin/qmuxd
/system/bin/qmiproxy
/system/bin/netmgrd
* Update /system/etc/wifi stuff -- newer broadcom firmware images, wpa_supplicant.conf with p2p parameters
* Reenable early ADB since it appears MTP issues likely related to lack of CONFIG_USB_ANDROID_SAMSUNG_MTP kernel option -- Maybe someone who uses MTP can tell me whats up now?
Update 4
* Fix A2DP bitrate (48000 -> 44100 in /system/etc/audio_policy.conf)
* More invasive ASEC fix that might actually fix this jellybean nonsense (modified vold to use /data/secure locations, create /data/secure directory tree in init.emmc.rc)
* Revert SHV-140 RIL change, back to Note CM10 RIL libraries
Update 5
* Android 4.1.2 - Complete rebuild from CM10 tree retrieved on October 12th. Includes ASEC hack as in update4.
* SGH-i957 Radio Information Libraries (RIL) from official Telus ICS image - Thanks Dan!
Update 6
* Rebuilt from CM10 source code retrieved Nov 10 2012. ASEC hack applied.
* Update to latest msm8660-common kernel. Kernel unmodified (ie: no overclocking).
Update 7
* Rebuilt from CM10 source code retrieved Dec 20 2012. ASEC hack applied.
* Update to latest msm8660-common kernel. Kernel unmodified (ie: no overclocking).
Fantastic!
Are you saying everything seems to work pretty well except the 4G radio? (No guarantees, at my own risk, etc. etc. I know, I won't blame you)
If so, I'm going to try this right away. I don't have a data plan for my SIM, and haven't used the 4G yet. (Got a free upgrade from the wifi version after some shipping trouble with the vendor.)
The Galaxy Tab has been kind of a letdown when I have JB on my Galaxy Nexus and Kindle Fire both, and the "upgrade" is a bit disappointing since I checked on custom ROMs *before* I ordered, but the AT&T version is further behind.
Thanks for your hard work! I'll let you know what happens.
YellowRex said:
Fantastic!
Are you saying everything seems to work pretty well except the 4G radio? (No guarantees, at my own risk, etc. etc. I know, I won't blame you)
Thanks for your hard work! I'll let you know what happens.
Click to expand...
Click to collapse
I haven't had time to try "everything", but the stuff that I use on a regular basis is mostly functional. There's quirks, but... It's usable!
For example, one thing I just found out.. the Adreno (qualcomm MSM graphics) drivers aren't production-build.. There's no such thing available -- The current drivers available from qualcomm are "early sample" binaries for jellybean bringup testing, which is what this is... So, I've seen the random screen flicker, etc. Remember there are only a few devices with tested jellybean images, and most of them are google devices... And the i957 will probably never see an official JB release.
https://developer.qualcomm.com/mobi...phics-optimization-adreno/tools-and-resources
This release contains an early sample of the user-mode driver binaries for Qualcomm's Adreno 2xx GPU on Google Android 4.1 Jelly Bean. It has been tested with the CAF release M8960AAAAANLGD105210.1 and supports any Adreno 2xx GPU on Android 4.1 Jelly Bean. This release is intended only for developers that work on Jelly Bean bring-up work. It is an early release sample which will be replaced by a new driver binary in the future.
Click to expand...
Click to collapse
I'm sure there's plenty of little quirks you can find if you "twiddle all the knobs and flip all the switches" -- But it's certainly testable, and way closer to the "usable" end of the spectrum than the "barely functions" end.
Cheers!
PRE-ALFA CM10 Build
You did a great job nrvate !!. you inspired me to get ICS/JB on my SGH-i957. I did try your method and seems everything (3G, SMS, GPS, Bluetooth, Camera etc..) works except wifi. I am surprised that Voice calling is also working in this build !!! I will update you once I fix wifi issue. and also provide CWM/TWRP/ODIN flashable build if time permits.
Cheers !!
-KS
Its so exciting to see some real pregress.
Sent from my SAMSUNG-SGH-I957 using xda app-developers app
Ditto. This is really good news. Thanks.
Cheers, y'all!
Only thing I had to do to get wifi working was stuff the original stuff (from honeycomb) in /system/etc/wifi.
first thing I'd do is make sure the dhd module is getting loaded.. dmesg will print your kernel log that'll show problems with loading that module.. also, try rmmod dhd and insmod dhd, see what happens.
If the DHD module doesn't report symbol errors or some nasty like that, make sure it's loading the firmware -- That'll probably leave an error in dmesg also if it's broke.
also check logcat for wifi-related nastiness
If you can find a specific problem post it and I'll try to help reproduce/solve.
Also working on hacking together a build of ICS based on what's been done with JB, but no idea how that's going to turn out yet. It'd be nice to have as a daily until qualcomm releases production-grade adreno graphics drivers (and, the CM9 ICS tree is now "final", might as well build it!)
update: due to needing the "late model" msm8660-common kernel for proper i957 device support, the later qualcomm (JB) graphics drivers are required too.. drat! however, looks like I'll still be able to hack together a build of CM9 based on the current "final" ics branch using the JB kernel and beta qualcomm graphics. got 'er booted, working out the kinks now. I'll start another thread for that when it's done
i wish i knew half as much as you do, keep up the good work!
orlandoxpolice said:
i wish i knew half as much as you do, keep up the good work!
Click to expand...
Click to collapse
Thanks! Learning as I go with half this.. It's just bits, try one way, get dirt.. try another way, get bacon!
Some of this is so touchy.. ie kernel versions vs adreno drivers, blah blah.. seeing what the SHV-140 kernel does.. it boots CM9, now to see if it'll play nice with video decoders. might forget CM9, i <3 jelly beans anyways!
nrvate said:
Thanks! Learning as I go with half this.. It's just bits, try one way, get dirt.. try another way, get bacon!
Some of this is so touchy.. ie kernel versions vs adreno drivers, blah blah.. seeing what the SHV-140 kernel does.. it boots CM9, now to see if it'll play nice with video decoders. might forget CM9, i <3 jelly beans anyways!
Click to expand...
Click to collapse
Solid work/mashery my friend. This indeed great news. I am currently waiting for my zip file to spit out, do a few mods and then give it a flash when I complete those things.
As far as the adreno drivers have you checked the site for them? I recall reading about them on another msm8660 device and perhaps may pertain to this project as well. The screen flicker has a few work arounds based on other devices that may relate to this device as well. Either to get rid of the flicker entirely or at least minimize them. Worth trying (here are a few I have seen work on some devices.. dev options, disable HW overlay, another is adjusting the debug.mdpcomp.maxlayer value in build.prop from 3 to 2, another is to set the min CPU freq to 486mhz).. last but not least, this was posted on cyanogenmod review, and can be cherry picked if not merged already: http://review.cyanogenmod.com/#/c/22782/ and may work. As far as getting LTE to light up in a more prompt manner, it may be worth exploring different modems (I see you are using UCLF6 from the i717 note), there are many others from the i717 leaks (ie. UCLF5, UCLE2/3, etc etc) and also of course any other Skyrocket ICS+ modems, as well as i717m (canadian, rogers modems such as XLA2 (gingerbread but worked on the i717 note in the US) and various others. If you cannot located them I will post links when I have more time. This is a great start, and I will help out when I have time to contribute to this project (I have a few on my plate plus a full time job so sometimes having the time is a difficult venture). In any case, great start and I can see this will progress very well in due time. Congrats and thanks for your contribution to the base of this, as this progresses and we work to manage these small issues, we will have something even solid
Regards,
th3g1z
th3g1z said:
Solid work/mashery my friend. This indeed great news. I am currently waiting for my zip file to spit out, do a few mods and then give it a flash when I complete those things.
As far as the adreno drivers have you checked the site for them? I recall reading about them on another msm8660 device and perhaps may pertain to this project as well. The screen flicker has a few work arounds based on other devices that may relate to this device as well. Either to get rid of the flicker entirely or at least minimize them. Worth trying (here are a few I have seen work on some devices.. dev options, disable HW overlay, another is adjusting the debug.mdpcomp.maxlayer value in build.prop from 3 to 2, another is to set the min CPU freq to 486mhz).. last but not least, this was posted on cyanogenmod review, and can be cherry picked if not merged already: http://review.cyanogenmod.com/#/c/22782/ and may work. As far as getting LTE to light up in a more prompt manner, it may be worth exploring different modems (I see you are using UCLF6 from the i717 note), there are many others from the i717 leaks (ie. UCLF5, UCLE2/3, etc etc) and also of course any other Skyrocket ICS+ modems, as well as i717m (canadian, rogers modems such as XLA2 (gingerbread but worked on the i717 note in the US) and various others. If you cannot located them I will post links when I have more time. This is a great start, and I will help out when I have time to contribute to this project (I have a few on my plate plus a full time job so sometimes having the time is a difficult venture). In any case, great start and I can see this will progress very well in due time. Congrats and thanks for your contribution to the base of this, as this progresses and we work to manage these small issues, we will have something even solid
Regards,
th3g1z
Click to expand...
Click to collapse
Thanks for the input! The flicker, as is, is really minor. It only really seems to happen, for me atleast, in the main launcher window and sometimes when scrolling in maps. It's intermittent, actually. I will have a look at that change you linked, nice catch!
Qualcomm's dev site is linked in post #4, hopefully they will post the final drivers soon. Do they have another site that would receive them faster, or with incremental builds? I really wish OEMs would share engineering builds more openly with the community, but I guess I'm just used to being on an engineering team, lol. I've been spoiled with working for a few of the larger OEMs and getting all the cool toys first...hehe.
I tried a few of the note ICS radios, got nothing at all from them besides errors in logcat -b radio, wouldn't bring up the SIM.
All the skyrocket radios seem to work to varying degrees.
Also, it may be more of the RIL -- The UCLF6 skyrocket modem works very nicely on the stock honeycomb image, insta-LTE and everything.
I have not tried any of the non-ATT radios... wasn't sure how that'd work out. I'll give some of the non-ATT radios a go, why not! Besides Skyrocket or Note, any other similar devices? Only thing I can think of is the SGS II LTE HD (SGH-i757) but not much is available for that device as AT&T punted it for the S III (747) and it never got popular.. If you want the HD screen, you get a S-III, which came out about a month later, which is just why ATT punted it all together.
I hear you on the job. I've got an interview lined up for a better one, too! Man, I'm hoping that works out!
nrvate said:
Thanks for the input! The flicker, as is, is really minor. It only really seems to happen, for me atleast, in the main launcher window and sometimes when scrolling in maps. It's intermittent, actually. I will have a look at that change you linked, nice catch!
Qualcomm's dev site is linked in post #4, hopefully they will post the final drivers soon. Do they have another site that would receive them faster, or with incremental builds? I really wish OEMs would share engineering builds more openly with the community, but I guess I'm just used to being on an engineering team, lol. I've been spoiled with working for a few of the larger OEMs and getting all the cool toys first...hehe.
I tried a few of the note ICS radios, got nothing at all from them besides errors in logcat -b radio, wouldn't bring up the SIM.
All the skyrocket radios seem to work to varying degrees.
Also, it may be more of the RIL -- The UCLF6 skyrocket modem works very nicely on the stock honeycomb image, insta-LTE and everything.
I have not tried any of the non-ATT radios... wasn't sure how that'd work out. I'll give some of the non-ATT radios a go, why not! Besides Skyrocket or Note, any other similar devices? Only thing I can think of is the SGS II LTE HD (SGH-i757) but not much is available for that device as AT&T punted it for the S III (747) and it never got popular.. If you want the HD screen, you get a S-III, which came out about a month later, which is just why ATT punted it all together.
I hear you on the job. I've got an interview lined up for a better one, too! Man, I'm hoping that works out!
Click to expand...
Click to collapse
I hear you on OEM not releasing the drivers in a timely fashion, and it is frustrating when you have sources for it as "leaks" .. pertaining to your question I did see a link to update drivers but in my 5 min search (short on time atm, work early in the morning), I didn't find it yet, but I will look a bit deeper and hopefully can find it. I recall it related to CM10 and addressing said drivers for a particular device or devices. I will see what I can find tomorrow, and hope that it pertains.
No harm in trying a few other modems, I would look at the i717/i717m (m is the canadian model, same device though and the modems from rogers work with the i717 as well as the skyrocket).. and obviously the skyrocket various modems which it seems you have tried at least a few of. They vary so much and your location has a lot to do with it. Some work better in certain areas, and others in other areas as I'm sure you know already. Worst case, even after trying a few you can always go back to UCLF6. I found it a bit odd that the rogers modems worked with ATT but hey I'm not complaining about that one I believe you are correct, however, pertaining to the RIL as being the issue, not so much the modem's themselves. (no telling though without trial/error)
I'm not sure the i747 modems would work or not, but, it will not hurt to try, as you can return to UCLF6 if it is a dead end. the i757 I have yet to even see, so I can't comment on that in particular.
I'd like to chat a bit more when we both have some time, not sure if you get on IRC (freenode network) at all but if you do look me up, same handle as here on XDA. It would be easier to chat that way.
I have more to say but having to be away in about 4 hours, I will have to get back to you. Good luck w/ the interview bud.
Take care, we'll catch up soon.
~th3g1z
th3g1z said:
I hear you on OEM not releasing the drivers in a timely fashion, and it is frustrating when you have sources for it as "leaks" .. pertaining to your question I did see a link to update drivers but in my 5 min search (short on time atm, work early in the morning), I didn't find it yet, but I will look a bit deeper and hopefully can find it. I recall it related to CM10 and addressing said drivers for a particular device or devices. I will see what I can find tomorrow, and hope that it pertains.
No harm in trying a few other modems, I would look at the i717/i717m (m is the canadian model, same device though and the modems from rogers work with the i717 as well as the skyrocket).. and obviously the skyrocket various modems which it seems you have tried at least a few of. They vary so much and your location has a lot to do with it. Some work better in certain areas, and others in other areas as I'm sure you know already. Worst case, even after trying a few you can always go back to UCLF6. I found it a bit odd that the rogers modems worked with ATT but hey I'm not complaining about that one I believe you are correct, however, pertaining to the RIL as being the issue, not so much the modem's themselves. (no telling though without trial/error)
I'm not sure the i747 modems would work or not, but, it will not hurt to try, as you can return to UCLF6 if it is a dead end. the i757 I have yet to even see, so I can't comment on that in particular.
I'd like to chat a bit more when we both have some time, not sure if you get on IRC (freenode network) at all but if you do look me up, same handle as here on XDA. It would be easier to chat that way.
I have more to say but having to be away in about 4 hours, I will have to get back to you. Good luck w/ the interview bud.
Take care, we'll catch up soon.
~th3g1z
Click to expand...
Click to collapse
I'll hit you up on IRC at some point for sure
So I sort of figured it out... Found how to get the radio to play nice, still don't know why... The kernel! Went back to the 3.0.8 kernel as provided by samsung for the SHV-140 (replaced zImage in boot.img, reflashed mmcblk0p8) and BAM. Nice quick 4G. Nothing in /system changed (so a bunch of other stuff broke) but the radio sure got happy.
Not sure what the difference is, quite yet... Should be an interesting needle in the hackstack for sure.
Is the package manager a problem with this the same as cm9?
Sent from my SGH-I727 using xda premium
orlandoxpolice said:
Is the package manager a problem with this the same as cm9?
Click to expand...
Click to collapse
yes, the issue actually originated with jellybean -- since there's no device tree in the cm9 repo for the p5att, i jammed the cm10 p5att device tree into cm9 source to make it happen. the device tree includes the init scripts, so the problem actually originated from cm10, lol.
same fix works.. mount tmpfs on /mnt/secure (in addition to /tmp/asec) and use wide-open (777) permissions.
nrvate said:
same fix works.. mount tmpfs on /mnt/secure (in addition to /tmp/asec) and use wide-open (777) permissions.
Click to expand...
Click to collapse
Heh! Is it just me or does that feel a little less than 'secure'? :silly:
i feel like a english lit major walking into an advanced calculus class with this jargon
This is how the sausage gets made.
Speaking of making sausage, I'm starting to think this is stable enough to share a binary build...
1) Camera is borked. I'm at a bit of a loss to figure it out, maybe I'll try again next week -- Suggestions very welcome, I'd like to get this working for video chat ala skype / gtalk.
2) MTP is borked. Again, at a bit of a loss, I suppose I'd care if I used it... Silly MTP.
3) New kernel fixes radio issues (mostly) - I've had it completely refuse to come up, showing no signal, fixed by rebooting the tablet. Goes right to LTE, but defaults to HSPA only. Change to LTE / GSM / WCDMA in mobile network settings -> network mode.
4) /mnt/asec / /mnt/secure issue (play store install problems) resolved.
5) FC in Settings -> Storage resolved by removing sdcard1 (which will never exist) from the build config
6) Boot animation is disabled due to framebuffer problems (supposedly) -- i know the spinny thing is cool, but you'll have to live with a black screen. Strangely, it comes up on some boots. lol.
7) Qualcomm graphics drivers are still the pre-release version. They seem to work pretty nice though. Haven't seen any of the flickering since some mdp changes in the kernel.
8) Video codecs aren't as screwed up as they are in the ICS build I did -- IE youtube works for all the videos I tried and bsplayer for android nicely plays my favorite x264 720P tv shows (win! gotta keep myself entertained at work some how...)
9) overclocked kernel HACK WARNING for you purists -- Modifed the kernel slightly, it now recognizes all MSM8660's as having the higher binned speed (1.66 vs 1.50 ghz) -- I didn't touch the frequency tables or anything, since it made more sense to just recognize the parts as 1.66ghz parts. Also, removed the logic that limited single-core mode to 1.2ghz (why?!). Gabe put out a OC kernel and most people reported stability at 1.7+ ghz, so... 1.66 seemed good. Hasn't borked for me. If you want stock speeds bad enough or run into problems.. http://d-h.st/8mB
Usual procedure, TWRP.. factory reset, wipe system, flash zip, receive bacon.
Bacon: http://d-h.st/Klu
I've been using this as my daily the past few days, and unless it starts behaving badly for some reason, it's probably going to be my daily for the foreseeable future. Really want to get the cams working, though!
Please share other issues. There has to be something else horribly broken I haven't noticed.
Usual "may make zombies run out of your tablet" warning applies to this test software.
Enjoy!