di11i kernel beta .01 (unsecure boot.img- root shell, adb remount) ext4 tweaks/init.d

Search This thread

di11igaf

Inactive Recognized Developer
Sep 6, 2010
1,898
739
East Coast
No problem. I'm surprised it didn't work for you after you made changes.



Flashing them to staging seems to work perfectly for me. That's how I made my insecure boot.blob and flashed it. It doesn't matter whether you're on unofficial CWM or Official since if you start your updater-script with unmounting staging, it doesn't hurt anything if staging wasn't mounted. Then you can either dd the blob to mmcblk0p4 or you can directly flash it via:
Code:
package_extract_file("boot.blob", "/dev/block/mmcblk0p4");

I have not found an occasion where this didn't work. You need to make sure that you don't add any --cmdline parameters when you mkbootimg or you will get a bootloop. Staging is definitely the safest way to flash to any partitions on the Prime.



The kernel versions seem to be the same with the latest .15 build as the previous one. I wonder if they just recompiled the same source and that's why the host name changed to Mercury.

EDIT: I'm going to pack this kernel into a flashable blob and attach it here.
How are you packaging the blobs? For me, blob tools for linux,( id say windows as well, since i also compiled with cmake) seems to have an issue with the blob signature. Idid read about new version, so ill check git and recompile.
If you beat me to it ill update op with yours andi do appreciate that. Thanks
If not ill update op when i test the new blob after i get it packaged up.
 

jermaine151

Senior Member
Jun 19, 2010
4,237
3,690
Columbus, Ohio
How are you packaging the blobs? For me, blob tools for linux,( id say windows as well, since i also compiled with cmake) seems to have an issue with the blob signature. Idid read about new version, so ill check git and recompile.
If you beat me to it ill update op with yours andi do appreciate that. Thanks
If not ill update op when i test the new blob after i get it packaged up.

I already packaged it and posted it for you here. To fix the signature issue, download and build the source from the attachment in this post.
 
Last edited:
  • Like
Reactions: di11igaf

MasterZen88

Senior Member
I already packaged it and posted it for you here. To fix the signature issue, download and build the source from the attachment in this post.

Well its working now. I made some changes to default.prop and they applied.


Not sure what did it but I re-did my Linux environment (using Linux Mint). Then added the blobtools and boottools to my $PATH. Used your kernel template. And it worked... Now I can go have fun... Thanks to all for your help.
 

MasterZen88

Senior Member
Hmm... That all looks good. What happens after you attempt to flash this and what changes did you make to the ramdisk?

EDIT: Hey, I just re-read your PM. It sounds like you're editing the wrong file in the ramdisk. To make an insecure boot image, you should be editing init.rc, NOT init.cardhu.rc.

Here's a great guide to follow. It's the same procedure for the Prime as the original Transformer:

http://xdaforums.com/showthread.php?t=1193737

I'm not sure but to me I dont think init.rc is the right place.... Take a look at how its mounting within the init.rc:

Code:
on fs
# mount mtd partitions
    # Mount /system rw first to give the filesystem a chance to save a checkpoint
    mount yaffs2 mtd@system /system
    mount yaffs2 mtd@system /system ro remount
    mount yaffs2 mtd@userdata /data nosuid nodev
    mount yaffs2 mtd@cache /cache nosuid nodev

I don't see anywhere within the init.rc that talks about ext4. This is why I made changes to init.cardhu.rc. But please feel free to correct me if I'm wrong. That's the only way anyone will learn.
 

di11igaf

Inactive Recognized Developer
Sep 6, 2010
1,898
739
East Coast
I'm not sure but to me I dont think init.rc is the right place.... Take a look at how its mounting within the init.rc:

Code:
on fs
# mount mtd partitions
    # Mount /system rw first to give the filesystem a chance to save a checkpoint
    mount yaffs2 mtd@system /system
    mount yaffs2 mtd@system /system ro remount
    mount yaffs2 mtd@userdata /data nosuid nodev
    mount yaffs2 mtd@cache /cache nosuid nodev

I don't see anywhere within the init.rc that talks about ext4. This is why I made changes to init.cardhu.rc. But please feel free to correct me if I'm wrong. That's the only way anyone will learn.

Youll see he made another reply saying he meant to say default.prop(correct), not init.rc for an unsecure boot.img. init.cardhu would be where to edit the mount points.
 
Last edited:

Lock-N-Load

Senior Member
Aug 25, 2010
1,618
392
Under Your Skin
you going to cook in the ability to grab the battery usage data and corrects Asus's bug of only reporting system resources in Settings / Battery
 

PapaSmurf6768

Senior Member
Jul 29, 2011
284
84
Flashed this kernel, but had 2 concerns:
1. Right after boot I had a android.process.acore force close, not sure what causes that
2. This kernel seems to be based on an earlier kernel, not the current 003 kernel in the 15 update

Any comments on that?

Sent from my ROOTED Transformer Prime
 

di11igaf

Inactive Recognized Developer
Sep 6, 2010
1,898
739
East Coast
Flashed this kernel, but had 2 concerns:
1. Right after boot I had a android.process.acore force close, not sure what causes that
2. This kernel seems to be based on an earlier kernel, not the current 003 kernel in the 15 update

Any comments on that?

Sent from my ROOTED Transformer Prime
1- im guessing you didn't wipe, which is fine, but these are file system tweaks so a fresh start would be better. If it only happened once, and is not happening over and over you're probably fine. If you don't fully wipe /data, it wouldn't hurt to at least wipe cache and dalvik-cache .
You won't lose anything by wiping those but the first reboot will take a long time while dalvik-cache rebuilds.
2- there is no source for newest kernel, the kernel image I will be releasing soon will be this version, so it makes sense to make sure everything works with what I will be releasing.
I don't think much changed in the newer kernel version(nothing significant ) if anything

Also, this is NOT compatible with cm9, I will update op for new users who may not realize that.
 
Last edited:

PapaSmurf6768

Senior Member
Jul 29, 2011
284
84
1- im guessing you didn't wipe, which is fine, but these are file system tweaks so a fresh start would be better. If it only happened once, and is not happening over and over you're probably fine. If you don't fully wipe /data, it wouldn't hurt to at least wipe cache and dalvik-cache .
You won't lose anything by wiping those but the first reboot will take a long time while dalvik-cache rebuilds.
2- there is no source for newest kernel, the kernel image I will be releasing soon will be this version, so it makes sense to make sure everything works with what I will be releasing.
I don't think much changed in the newer kernel version(nothing significant ) if anything

Also, this is NOT compatible with cm9, I will update op for new users who may not realize that.

Gotcha, thanks for the clarification. I wiped cache and dalvik like I always do before I flash a kernel but I guess that wasn't enough. Thanks for your work!

Sent from my ROOTED Transformer Prime
 

Striatum_bdr

Senior Member
May 29, 2011
4,650
2,176
Marseille
UV is most of the times placebo, unless you UV by big values, that are most if the time not supported by CPU.

It's generally a source if instability rather than longevity. Some of our kernel devs made extensive tests and with secure UV there wasn't any difference in battery life (I speak of my phone if course but it's the same thing).

Calculate in % what does represent 25, 50 75mV less compared to CPU voltage....
 

benefit14snake

Senior Member
Dec 23, 2011
819
174
Henrico, VA
UV is most of the times placebo, unless you UV by big values, that are most if the time not supported by CPU.

It's generally a source if instability rather than longevity. Some of our kernel devs made extensive tests and with secure UV there wasn't any difference in battery life (I speak of my phone if course but it's the same thing).

Calculate in % what does represent 25, 50 75mV less compared to CPU voltage....

Maybe its different for phones but on desktop lower voltage means lower temps and power. Lower temps means lower amp draw which means lower power usage. Voltage usually means exponentially higher power draw. Although with these chips being produced as low voltage devices to begin with, there may be significantly less wiggle room.

Sent from my Transformer Prime TF201 using Tapatalk
 

Striatum_bdr

Senior Member
May 29, 2011
4,650
2,176
Marseille
Maybe its different for phones but on desktop lower voltage means lower temps and power. Lower temps means lower amp draw which means lower power usage. Voltage usually means exponentially higher power draw. Although with these chips being produced as low voltage devices to begin with, there may be significantly less wiggle room.

Sent from my Transformer Prime TF201 using Tapatalk

Well then be ready to see many reports about bootloops, BSOD..

To limit that, please choose standard voltage table, and do not undervolt by default

Tablets are more phones than desktops despite their abilities, and CPU design is not the same.
 
Last edited:

di11igaf

Inactive Recognized Developer
Sep 6, 2010
1,898
739
East Coast
Well, I seriously doubt any under volt will be in the first few versions unless I get lucky. One of the source files where I believe I may be able to get a simple over clock is well over 4000 lines of code. If it doesn't work as planned, who knows when . This isn't even accounting for any voltages, just clock speed. Tegra 3 is DEFINITELY a complex beast.
Hopefully someone like bumblebee has already been looking into it and has a better grasp than me.(edit just looked at his git, nothing for tf-201. I'm sure there's more people than me looking into it)
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 6
    This basically (for right now) the stock kernel image with some tweaks to init.
    -unsecure boot.img-(perma- rooted adb shell)
    -adb remount(mount /system r/w)
    -init.d support added in for init scripts(survive after reboot)
    -ext4 filesystem mount tweaks-/system/data/cache(faster I/O)
    (Actually have a full ext2 version for,****s and giggles, but it boots into the encryption error screen, so cant release that. May have a fix though)
    -mem and cache tweaks coming soon

    still working on the actual kernel, will release that next, still have lots of work to do

    boot.img MD5- fca41dba8f4699b67fd461a1632b65cf

    MAKE BACKUP FIRST

    You will not have issues if you wipe data, chances are youll be fine if you dont, but if anything starts acting up just wipe data, then install boot.img
    This is the actual boot.img and for now has to be flashed with adb with these EXACT commands--
    Code:
    adb push boot.img /sdcard/
    adb shell
    su
    dd if=/sdcard/boot.img of=/dev/block/mmcblk0 seek=3968 bs=4096 count=2048
    reboot
    
    
    #Thanks Diamondback and friends for offsets




    This is not the ideal way to flash this, but i can not get the blob file to staging partition to actually write the image. Im pretty sure its an issue with the signature of the blob file, so if someone wants to pack this into a blob id be glad test it and then update the OP.
    My primes been using this boot.img for a few days, along with one other. Flash at your own risk.
    NOT COMPATIBLE WITH CM-9
    3
    if you copy the blob, while p4 is mounted to staging in cwm, you will have a problem when you reboot, as the filesystem umount, and that cause a small change to the mounted filesystem, to indicate it is umounted normally. and the p4 partition becomes invalid.

    so it can easily become a problem if p4 is mounted.

    at least thats how i experienced the problem when seen initially.

    That's why I said to always add an unmount("/staging"); to the top of your script. The attached flashable zip works perfectly on the official CWM; staging is not mounted by default, but I told the script to unmount it anyway in case someone with the unofficial CWM tries to flash it. If it's already unmounted, the script just continues.

    Anyone may use this as a template for consistently flashing a kernel to staging.
    2
    UV is most of the times placebo, unless you UV by big values, that are most if the time not supported by CPU.

    It's generally a source if instability rather than longevity. Some of our kernel devs made extensive tests and with secure UV there wasn't any difference in battery life (I speak of my phone if course but it's the same thing).

    Calculate in % what does represent 25, 50 75mV less compared to CPU voltage....

    Agreed 100%.
    My team has quite some experience over a wide range of different devices and UV never really showed any improvement over stock voltage tables.

    It's not the CPU that drains the major power, it's the display and the radio.
    Try putting you phone to airplane mode and just let it rest on table until it's dead. Then do the same test with wifi and data enabled.
    You will be schocked :p

    I for one won't use any UV'ed kernels at all for my ROMs, they only induce major stability problems to a device that has these problems already without UV ;)
    Undervolting kernels is a huge myth, someone from google (Dianne?!) should really clear this up.
    2
    Well, I seriously doubt any under volt will be in the first few versions unless I get lucky. One of the source files where I believe I may be able to get a simple over clock is well over 4000 lines of code. If it doesn't work as planned, who knows when . This isn't even accounting for any voltages, just clock speed. Tegra 3 is DEFINITELY a complex beast.
    Hopefully someone like bumblebee has already been looking into it and has a better grasp than me.(edit just looked at his git, nothing for tf-201. I'm sure there's more people than me looking into it)
    2
    Hopefully have the optimised kernel out soon, hopefully tomorrow depending how late I stay up tonight.