We only had it one time too, but one time is enough to scare me further
This whole blob stuff just is crap
I agree with you Diamondback, even the blob process for samsung has issues.
We only had it one time too, but one time is enough to scare me further
This whole blob stuff just is crap
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.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.
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.
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
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'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.
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 .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.
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
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
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.
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....