Jump to content


Photo

[Q] OC kernel for GPU or CPU


  • Please log in to reply
76 replies to this topic

#21
KonstaT

KonstaT

    Hardcore

  • Developer Team
  • PipPipPipPipPipPip
  • 2,769 posts
  • Gender:Male
  • Location:Finland
  • Devices:Moto G, ZTE Open C
  • Twitter:@konstatuomio

So what you're saying is that some really clever person needs to build us a CWM that skips the checking of install-recovery.sh...  :)

Well, if someone was clever enough to do that then they'd probably just add the init.d support to ramdisk directly. :P Should be a lot easier than hacking the recovery, I think there's even some "kitchen" solutions to do that. Here's a good guide for splitting the boot.img at least.
 
Command to repack Blade V boot.img with all the correct parameters is:
mkbootimg --kernel zImage --ramdisk ramdisk.cpio.gz --cmdline 'console=ttyHSL0,115200,n8 androidboot.hardware=qcom vmalloc=200M' --base 0x00200000 --pagesize 4096 --ramdisk_offset 0x01300000 -o boot.img
I did actually build the Blade V kernel from source once. I uploaded it for someone to test and it got downloaded exactly zero times during couple of months. I've since removed the kernel sources (intentionally) and all recovery sources (accidentally, when removing CM10.1 sources :() from my computer. So before anyone asks, it's not going to be me.

  • 1

#22
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

The Int2Ext script (which I used on the Blade 1) doesn't seem to do much even though its log file says it has.  D2Ext takes out the OS. :D

That's progress though!  Both are clearly actually running. :D


  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#23
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

 

Well, if someone was clever enough to do that then they'd probably just add the init.d support to ramdisk directly. :P Should be a lot easier than hacking the recovery, I think there's even some "kitchen" solutions to do that. Here's a good guide for splitting the boot.img at least.
 
Command to repack Blade V boot.img with all the correct parameters is:
mkbootimg --kernel zImage --ramdisk ramdisk.cpio.gz --cmdline 'console=ttyHSL0,115200,n8 androidboot.hardware=qcom vmalloc=200M' --base 0x00200000 --pagesize 4096 --ramdisk_offset 0x01300000 -o boot.img
I did actually build the Blade V kernel from source once. I uploaded it for someone to test and it got downloaded exactly zero times during couple of months. I've since removed the kernel sources (intentionally) and all recovery sources (accidentally, when removing CM10.1 sources :() from my computer. So before anyone asks, it's not going to be me.

 

 

Thanks, I did successfully extract the ramdisk already today from stock but I stopped because it seemed unnecessary (and more risky) to modify boot.img.  I mean risky because someone here would need to test it and my knowledge is... limited!

 

I've also tried to build the kernel from source today, it's currently failing on a #include of a header file that it can't find, I'm not sure why because it's present.  But anyway I've run out of time today so I may pick it up again tomorrow.

 

Dunno why I'm bothering if target can't get his script working anyway lol  ;)


  • 0

#24
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

Trashing the OS playing with this is incredibly inconvenient because I don't have enough room on the SD for the android_secure folder, an ext partition big enough to handle the contents of the android_secure folder, and my CWM backup at the same time.

 

So to restore my phone, I have to plug the sd card into my PC, delete the ext partition and enlarge the fat, copy the CWM backup to it. Restore the CWM backup on the phone, put the sd card back into the pc, delete the CWM backup, add an ext partition. *sigh*. lol


Edited by targetbsp, 18 March 2014 - 05:44 PM.

  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#25
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

If you install "v2" of KonstaT's CWM, you can restore your nandroid backup directly from your SD.


  • 0

#26
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

There's just not enough room for it.  My backup is 6GB.  There's a reason i need ext support.  I have a lot of stuff. :D


Edited by targetbsp, 18 March 2014 - 06:00 PM.

  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#27
KonstaT

KonstaT

    Hardcore

  • Developer Team
  • PipPipPipPipPipPip
  • 2,769 posts
  • Gender:Male
  • Location:Finland
  • Devices:Moto G, ZTE Open C
  • Twitter:@konstatuomio

Thanks, I did successfully extract the ramdisk already today from stock but I stopped because it seemed unnecessary (and more risky) to modify boot.img.  I mean risky because someone here would need to test it and my knowledge is... limited!

 

I've also tried to build the kernel from source today, it's currently failing on a #include of a header file that it can't find, I'm not sure why because it's present.  But anyway I've run out of time today so I may pick it up again tomorrow.

 

Dunno why I'm bothering if target can't get his script working anyway lol  ;)

No, it's not risky at all. :P You don't even have to flash it to your device until you've tested that it works for sure and even then there's still nandroid backups. Just use 'fastboot boot boot.img'.

 

Yeah, it doesn't compile as usual. Change <header.h> to "header.h" (or vice versa, can't remember) on the line that it errors out.


  • 1

#28
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

No, it's not risky at all. :P You don't even have to flash it to your device until you've tested that it works for sure and even then there's still nandroid backups. Just use 'fastboot boot boot.img'.

 

Yeah, it doesn't compile as usual. Change <header.h> to "header.h" (or vice versa, can't remember) on the line that it errors out.

 

Thanks for the encouragement!  And thanks for the tip, I'll look for that tomorrow when I'm back at the computer with the source.  Although my preference would be to write a script that modifies init.rc, that way it would work for any kernel version and I wouldn't have to worry about making source available for GPL for a one-line change!  But I suspect that's beyond my skills.

 

Whilst I have your attention, may I please ask what the advantage would be of using

/system/xbin/busybox run-parts /system/etc/init.d

rather than simply

/system/etc/init.d/*

which seems to give the same result?  I ask because I can see a couple of possible disadvantages with the busybox route:

 

1) It requires a new enough version of busybox to have run-parts support, and

2) There is potentially this issue

 

Thanks for all your help.


  • 0

#29
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

There's just not enough room for it.  My backup is 6GB.  There's a reason i need ext support.  I have a lot of stuff. :D

 

If you're going to need to restore repeatedly why not flash stock, de-bloat and back that up?  That should be enough to prove whether your changes work, you don't really need to restore 6GB every time do you?


  • 0

#30
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

Well.. I didn't plan on breaking it. :D

 

run-parts works with the included busybox - you don't need to update it,  It was just something I tried yesterday when the real problem was the permissions.

 

[edit]

Mind you, I already have a small backup I could be playing with I spose: http://www.modaco.co...update-for-cwm/

Perhaps I'll have more luck with the scripts on a clean rom?


Edited by targetbsp, 18 March 2014 - 08:39 PM.

  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#31
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

Perhaps I'll have more luck with the scripts on a clean rom?

 

Not sure what difference it would make but certainly worth a try.

 

I mistakenly thought you'd written your own script.  Do you mean you're trying something like one of these?  If so, how far does it get according to the log file before failing?


  • 0

#32
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

Those are the ones.  The log files for Int2Ext (both v1 and v2) seem to think they have worked but nothing has happened.  Data was still the data partition.

I've no idea how far the older D2Ext got as the phone stopped booting. :D

 

The reason I'm wondering about a clean system is that the scripts attempt to move your existing data when they run.  It's possible D2Ext got stuck there.  I left it a good while but...

 

Int2Ext didn't even try that as the boot time was unaffected so it went pear shaped before that but continued on past there to claim it had completed successfully.


Edited by targetbsp, 18 March 2014 - 11:42 PM.

  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#33
KonstaT

KonstaT

    Hardcore

  • Developer Team
  • PipPipPipPipPipPip
  • 2,769 posts
  • Gender:Male
  • Location:Finland
  • Devices:Moto G, ZTE Open C
  • Twitter:@konstatuomio

Thanks for the encouragement!  And thanks for the tip, I'll look for that tomorrow when I'm back at the computer with the source.  Although my preference would be to write a script that modifies init.rc, that way it would work for any kernel version and I wouldn't have to worry about making source available for GPL for a one-line change!  But I suspect that's beyond my skills.

 

Whilst I have your attention, may I please ask what the advantage would be of using

/system/xbin/busybox run-parts /system/etc/init.d

rather than simply

/system/etc/init.d/*

which seems to give the same result?  I ask because I can see a couple of possible disadvantages with the busybox route:

 

1) It requires a new enough version of busybox to have run-parts support, and

2) There is potentially this issue

 

Thanks for all your help.

Well, I wouldn't worry too much about GPL if the vendor has released a kernel source that doesn't even compile and you're only fixing that. GPL states that the full source code needs to be made available but it doesn't say how. Link to ZTE site and a diff patch if/when requested should be enough to comply with GPL in this case. Iirc there's another small issue that needs to be fixed to compile as well. If you only want to add the init.d support, you can of course just use the stock kernel too. Split the boot.img and make your modifications to the ramdisk and put it back together with the stock zImage.
 
Using run-parts only executes scripts in given location, * would try to execute everything including directories and symlinks. Calling 'busybox run-parts' executes it directly from the busybox, it doesn't matter where it's been symlinked and it makes no sense why it would get called twice.

  • 1

#34
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

Thanks a lot - all makes sense.

 

I've given up trying to compile the source, every time I fixed one error, it found another.

 

If you only want to add the init.d support, you can of course just use the stock kernel too. Split the boot.img and make your modifications to the ramdisk and put it back together with the stock zImage.

 

That's exactly what I've just done.  I booted from the new image using fastboot and I got a picture of a dead android and the stock recovery :P But I think that's because I tried to be too clever and added a few more things, so I'll try again with pure init.d support.


  • 0

#35
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

So here's the script: 

#!/system/bin/sh
######################################
##  CronMod INT2EXTV2+ - 02/28/2013 ##
##    Written by CronicCorey @xda   ##
##             40int2ext            ##
######################################
## Thanks to vvFICKvv, DK75, and Dark Passenger @xda for help to fix compatibility issues with Android 4.2.x
## Thanks to Mortaromarcello @github for code to check if mmcblk0p2 exists

VER=INT2EXTV2+
LOG=/data/$VER.log

## Only continue if mmcblk0p2 exists
if [ ! -e /dev/block/mmcblk0p2 ]
then
busybox echo "mmcblk0p2 does not exist, $VER cannot start" > $LOG;
exit
else
busybox echo "Starting $VER" > $LOG;
fi;

## Set SD cache size
SD_CACHE=/sys/devices/virtual/bdi/179:0/read_ahead_kb
if [ -e $SD_CACHE ]
then
busybox echo "Setting SD_CACHE to 2MB" >> $LOG;
busybox echo "2048" > $SD_CACHE;
else
busybox echo "Setting SD_CACHE failed " >> $LOG;
fi;

## Make /sd-ext directory if needed and unmount /sd-ext if it already mounted
if [ ! -e /sd-ext ]
then
busybox echo "/sd-ext directory does not exist, making it now" >> $LOG;
busybox mount -o remount,rw /;
busybox mkdir /sd-ext;
busybox mount -o remount,ro /;
else
busybox echo "Unmounting /sd-ext in case it mounted already" >> $LOG;
busybox umount /sd-ext;
fi;

## Move /data mount point to /sd-ext
busybox echo "Moving /data mount point to /sd-ext" >> $LOG;
INT_DATA=$(busybox mountpoint -n /data | cut -d ' ' -f1)
busybox umount /data;
busybox mount $INT_DATA /sd-ext;

## Mount mmcblk0p2 to /data
busybox echo "Mounting sd-ext to /data" >> /sd-ext/$VER.log;
busybox mount -o noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
busybox chown 1000:1000 /data;
busybox chmod 771 /data;

## Move log file back to /data
busybox mv /sd-ext/$VER.log /data;

## Move existing files
for i in app app-private dalvik-cache;
do
if [ ! -e /data/$i ]
then
busybox echo "Moving /sd-ext/$i to /data" >> $LOG;
busybox mv /sd-ext/$i /data;
fi;

## Setup directorys for binds
if [ -e /sd-ext/$i ]
then
busybox echo "Removing /sd-ext/$i so it wont get binded" >> $LOG;
busybox rm -rf /sd-ext/$i;
fi;
done;

for i in `ls /sd-ext`;
do
if [ ! -e /data/$i ]
then
busybox echo "Making /data/$i directory for bind" >> $LOG;
busybox mkdir /data/$i;
fi;

## Make binds
if [ -e /data/$i ]
then
busybox echo "Binding /sd-ext/$i to /data/$i" >> $LOG;
busybox mount -o bind /sd-ext/$i /data/$i;
fi;
done;

## Unmount /sd-ext, if swap2int is installed leave it mounted until it activates
if [ ! -e /system/bin/swap2int ] && [ ! -e /system/etc/init.d/45swap2int ]
then
busybox echo "Unmounting /sd-ext" >> $LOG;
busybox umount /sd-ext;
else
busybox echo "Leaving /sd-ext mounted so SWAP2INT can activate" >> $LOG;
fi;

busybox echo "Started $VER successfully" >> $LOG;

sync;

And here's the log:

Starting INT2EXTV2+
Setting SD_CACHE to 2MB
/sd-ext directory does not exist, making it now
Moving /data mount point to /sd-ext
Unmounting /sd-ext
Started INT2EXTV2+ successfully

Sd-Ext exists. That bit works.

But the data mount isn't being moved to sd-ext, it's failing there.


Edited by targetbsp, 19 March 2014 - 02:20 PM.

  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#36
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

Are there any files in /sd-ext?  Specifically, a file called INT2EXTV2+.log?

 

I think I'm giving up on trying to add init.d support to the kernel.  I have a boot.img that boots fine but it doesn't seem to do anything different to stock.  It's certainly not running my init.d scripts.  How 1 line of code can not work is beyond me.

 

Still, I can add it to my list of Blade V failures: failed to port CM10, failed to build CWM, failed to compile the kernel and now failed to mod the kernel ramdisk.  Go me!


  • 0

#37
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

No, that log is from /data on internal.

sd-ext is completely empty.

 

D2Ext+ is at least doing something on a wiped phone.  Specifically it's making the phone app crash over and over. :D


Edited by targetbsp, 19 March 2014 - 02:40 PM.

  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#38
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

Well if you look at this snippet:

## Move /data mount point to /sd-ext
busybox echo "Moving /data mount point to /sd-ext" >> $LOG;
INT_DATA=$(busybox mountpoint -n /data | cut -d ' ' -f1)
busybox umount /data;
busybox mount $INT_DATA /sd-ext;

## Mount mmcblk0p2 to /data
busybox echo "Mounting sd-ext to /data" >> /sd-ext/$VER.log;

The first busybox echo is working, but the second one isn't; which means the mount is failing.  Can you add the following after the "INT_DATA=..." line, then try again and post what the log contains?

busybox echo $INT_DATA >> $LOG;

  • 1

#39
targetbsp

targetbsp

    Hardcore

  • MoDaCo Silver
  • PipPipPipPipPipPip
  • 4,017 posts
  • Gender:Male
  • Devices:Hudl 2, Blade V

Will do in a bit.  One thing though, why does it skip that log entry (mounting sd-ext) but reach the two at the end?

 

[edit]

Ah, I just saw, it's trying to output that line to a different log.


Edited by targetbsp, 19 March 2014 - 03:00 PM.

  • 0
My Blade site - includes vanilla KANGS's of CM7. Also available: modified GB Gapps with various market versions, mini ICS Gapps for 160mb system partitions and Flash for ARMv6
CM7 Blade changelog

#40
shiftyc

shiftyc

    Regular

  • Members
  • PipPip
  • 92 posts
  • Gender:Male

Because it's outputting it to a different log file - $VER.log, which equates to /sd-ext/INT2EXTV2+.log.  That's why I asked if that file was there :)

 

I think what you'll get is an extra line in the log saying "/dev/block/mmcblk0p13". If that's the original mount point for /data, then I don't see why the script isn't working.  And this is the point where we sit and hope someone that knows what they're talking about (hi KonstaT!) re-joins the discussion.


  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users