Non-kernel kernel hacking

Search This thread
By:
Advanced…
A

appagom

Senior Member
Sep 18, 2010
670
45
hellmonger asked me to repost this as a new thread. I'm not entirely sure he wasn't pulling my chain.. but whatever... here it is.

There's development going on for kernel's that can't be flashed anyway. So every time you boot your phone you need your PC handy for fastboot... fun experiment, but no thanks.

Support for ext2/3/4, and any of the other modular changes the kernel mods do can probably be made (and possibly even made useful) without changing the actual kernel image (flashed or otherwise).

I now see it's not like nobody here thought of this (and I didn't mean to presume otherwise), example here:
http://xdaforums.com/showthread.php?t=929871

The point that I did add was:
From my samsung experience, one click lag fix mounted /data without modifying the kernel by replacing the splash screen binary, which came up before data was mounted needed (other things used this trick too). It's not near as elegant but it may be possible to place kernel modules in /system/extramodules or whatever load them at some time like that, and then get support from then on.

The file on samsung was called playlogos or playlogos1 depending on the device. It did more than just play a logo I think.. and actually it had to be moved, replaced with a script.. and the script then should run the moved copy in the end. I don't see this file on the Motorola, but maybe there is something similar. If being clever, you make the script copy another script in from the sd card, chmod it and run it. Then if you make changes to the real script that cause boot loops, you can just modify it on the sd card, or pull it.

This would then be something that doesn't require a PC to do. Obviously anything requiring changing the actual kernel zImage won't work.
It's not beautiful, but neither is fastboot. For korean sgs it was possible to compile kernel modules for ext4 that would run on the stock kernel. (you should read through that thread I linked though.. some good point made there about that).

If you want to use another filesystem for your primary (as opposed to linked) /data there are some important details that I'm no longer remembering perfectly. The typical boot loop check for /data happened after this splash screen so that was ok, but it was I think still necessary to have the kernel not fail to mount /data before that (Probably the partition will get reformatted if it can't be mounted). If so, one possibility may be to repartition to make a tiny fake data partition and then remount the real one, just and idea. The reason things worked for OCLF was that OCLF left /data partition unmodified, but mounted an ext2 image file sitting on /data, arguably not an appealing thing to do, but it had its uses on Samsung devices depending who you asked.

Mioze7ae since pointed out in passing though that partition tables are burned into the kernel, so this repartition trick may still be a no-go. Anyway I don't know exactly what goals people have for using various filesystems on XT720 devices, and filesystems are not the only modular changes being made to some of these kernels that maybe don't need to be in-kernel, in a flashing sense.

I probably don't intend to be a primary developer on anything this involved... no time, just ideas, testing, etc at most.
 
Last edited:
  • Like
Reactions: hellmonger
P

peshovec

Senior Member
Nov 11, 2010
305
343
about mtd partitions

Actually they are passed as parameters to the kernel...


Code: 
/$ cat /proc/cmdline 
console=ttyS2,115200n8 console=ttyMTD10 rw mem=244M@0x80C00000 init=/init ip=off brdrev=P3_TABLET_SKT androidboot.bootloader=0x0000 mtdparts=omap2-nand.0:1536k@2176k(pds),384k@4480k(cid),640k@6784k(logo),384k(misc),3584k(boot)ro,4608k@15232k(recovery),8960k(cdrom),204416k@29184k(system),106m@233984k(cache),177280k(userdata),1536k(cust),2m@521728k(kpanic)

and then they are visible
Code: 
/$  cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00180000 00020000 "pds"
mtd1: 00060000 00020000 "cid"
mtd2: 000a0000 00020000 "logo"
mtd3: 00060000 00020000 "misc"
mtd4: 00380000 00020000 "boot"
mtd5: 00480000 00020000 "recovery"
mtd6: 008c0000 00020000 "cdrom"
mtd7: 0c7a0000 00020000 "system"
mtd8: 06a00000 00020000 "cache"
mtd9: 0ad20000 00020000 "userdata"
mtd10: 00180000 00020000 "cust"
mtd11: 00200000 00020000 "kpanic"

for example hex 0xad20000 is decimal 181534720, which divided by 1024 equals to 177280 (e.g. the 177280k(userdata) )



about modules, i use following not included in the stock:
jbd, ext*, overclock, tun, (and some cpu governors)

Also when i was on eclair, i used jit, dalvik-cache was on /cache partition, was able to move all the apps on sdcard (slow), was able to "link" selected (usually big and not often used ones) files to the sdcard.
 
fjfalcon

fjfalcon

Retired Recognized Developer
Jan 19, 2011
844
1,263
Schelkovo
All kernel modules loaded without kernel.
But some kernel features like swap or thumbee are not kernel-module... they in kernel itself...
So..
 
Mioze7Ae

Mioze7Ae

Retired Recognized Developer
Dec 27, 2010
2,153
2,053
Queen City of the West
Google Pixel 7
peshovec said:
Actually they are passed as parameters to the kernel...


Code: 
/$ cat /proc/cmdline 
console=ttyS2,115200n8 console=ttyMTD10 rw mem=244M@0x80C00000 init=/init ip=off brdrev=P3_TABLET_SKT androidboot.bootloader=0x0000 mtdparts=omap2-nand.0:1536k@2176k(pds),384k@4480k(cid),640k@6784k(logo),384k(misc),3584k(boot)ro,4608k@15232k(recovery),8960k(cdrom),204416k@29184k(system),106m@233984k(cache),177280k(userdata),1536k(cust),2m@521728k(kpanic)

and then they are visible
Code: 
/$  cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00180000 00020000 "pds"
mtd1: 00060000 00020000 "cid"
mtd2: 000a0000 00020000 "logo"
mtd3: 00060000 00020000 "misc"
mtd4: 00380000 00020000 "boot"
mtd5: 00480000 00020000 "recovery"
mtd6: 008c0000 00020000 "cdrom"
mtd7: 0c7a0000 00020000 "system"
mtd8: 06a00000 00020000 "cache"
mtd9: 0ad20000 00020000 "userdata"
mtd10: 00180000 00020000 "cust"
mtd11: 00200000 00020000 "kpanic"

for example hex 0xad20000 is decimal 181534720, which divided by 1024 equals to 177280 (e.g. the 177280k(userdata) )
Click to expand...
Click to collapse

I don't think we have any way to change boot parameters because they are signed. :D In fact when I was testing with fastboot, I tried changing the kernel parameters in Motorola's boot.img and nothing changed. I decided that Motorola's kernels also ignore boot parameters entirely. Other than fastboot, the first point we can hijack anything is when the boot process first executes something from /system which limits our ability to repartition...

Sent from my XT720 using XDA Premium App
 
P

peshovec

Senior Member
Nov 11, 2010
305
343
agree...

with my limited experience with embedded devices i suppose folowing:

the bootloader loads the so called initrd.img and kernel.img.

Then in very early boot process the mtd partition are created (if needed:).

After that the control is passed to the kernel...


In fact when I was testing with fastboot, I tried changing the kernel parameters in Motorola's boot.img and nothing changed
Click to expand...
Click to collapse

:) may be that was not bad:) i mean if you give different layout of the mtd flash, then your filesystem data will be very likely mismatched (e.g. not useful readable).
But let me clarify: You have tried to modify the mtd parameters? and nothing happens?
 
A

appagom

Senior Member
Sep 18, 2010
670
45
If these things are like samsung, if the filesystem is not readable,they get reformatted early on bootup (at least /data and probably /cache). So early repartitioning /cache and /data wouldn't cause big problems if you managed out how to do it. But doing it with fastboot doesn't interest me much anyway. Of course that reformatting is also big part of the problem. If you manage to repartition later in the bootup (which should be possible right?) things will get reformatted on next bootup before you can get control again.

One bad idea is to hijack recovery mode (which maybe doesn't do that?) and use it as a normal boot mode. Pressing some key combo is better than needing a PC, however, if you ever forgot to press the combo, you get reformatted.. ouch. There does seem to be no nice way out if you're interested in changing the /data or /cache partitioning or fs. For everything else, work on user-friendly late module loading schemes seems much more useful than fastboot. Ok not everything.. fjfaclon makes a good point clearly, but fastboot is not solution as far as I care (of course if others find it useful, I have not complaint).

I get that Mioze7ae probably wants to reallocate memory for /cache and /data, but is there a compelling reason to reformat /data on this device to ext or something? On samsung, rfs (their proprietary fs) was a bit slow (I'm not as critical of it as many, I think it was just set up very safe.. in the end ext4 is not that much faster if setup just as safe... but that's a flame war for another forum) .
 
Last edited:
A

appagom

Senior Member
Sep 18, 2010
670
45
Oh one more point... Even if boot paramters aren't doing the partitioning is it entirely clear that it's in the kernel image? Maybe it's hidden somewhere else. With samsung's flash tool there was a pit file separate from the kernel image and not usually required for flashes. That was responsible for defining the partitioning, but it was never clear to me that anyone ever really understood how.
 
Last edited:
Mioze7Ae

Mioze7Ae

Retired Recognized Developer
Dec 27, 2010
2,153
2,053
Queen City of the West
Google Pixel 7
Well, I don't know definitively, but this is why I'm pessimistic about the theory that the partition table is stored outside boot.img. I work a lot with two sbfs. The CBW 2.1 Milestone XT720 and the SKT 2.2.1 Motoroi XT720. These differ in partition structures. Both will run fine on Milestone XT720 if you flash the entire image, but if you take the kernel from one and use nandroid to install it on the other, it doesn't work. To me this indicates that the partition table structure is inside boot.img somewhere. As a practical matter whether it's inside the kernel or the initramfs doesn't matter. A long time ago, I tried using boot parameters on fastboot to get the kernels to boot on the opposite sbfs and I couldn't get it to work. It's possible I was doing it wrong though. At the time we were using the mot_boot_mode hijack (that's still widely used here). There is a sh_hijack that I've been using later that happens very much earlier in boot. Perhaps that could make a difference, but at the time I didn't know to investigate that.

Also, recovery is signature checked on XT720, so we can't touch it. The security on XT720 is much closer to DroidX than it is to Milestone A853.
 
Last edited:
A

appagom

Senior Member
Sep 18, 2010
670
45
sh sounds like a really good hijack, might be early enough to mess with /data and /cache. mount might also work. Clearly if filesystems are checked/reformatted before /system is mounted, then there's no hope.

I thought recovery called stuff from /system, but that's probably my ignorance. Anyway, probably no need to beat this bad idea (the recovery idea) any more dead regardless.
 
Last edited:
V

Vistaus

Guest
Mioze7Ae said:
Well, I don't know definitively, but this is why I'm pessimistic about the theory that the partition table is stored outside boot.img. I work a lot with two sbfs. The CBW 2.1 Milestone XT720 and the SKT 2.2.1 Motoroi XT720. These differ in partition structures. Both will run fine on Milestone XT720 if you flash the entire image, but if you take the kernel from one and use nandroid to install it on the other, it doesn't work. To me this indicates that the partition table structure is inside boot.img somewhere. As a practical matter whether it's inside the kernel or the initramfs doesn't matter. A long time ago, I tried using boot parameters on fastboot to get the kernels to boot on the opposite sbfs and I couldn't get it to work. It's possible I was doing it wrong though. At the time we were using the mot_boot_mode hijack (that's still widely used here). There is a sh_hijack that I've been using later that happens very much earlier in boot. Perhaps that could make a difference, but at the time I didn't know to investigate that.

Also, recovery is signature checked on XT720, so we can't touch it. The security on XT720 is much closer to DroidX than it is to Milestone A853.
Click to expand...
Click to collapse

Have you ever deodexed the thing? On the Defy they deodexed everything on some ROMS. Have you tried that on our XT720 already?
 
Mioze7Ae

Mioze7Ae

Retired Recognized Developer
Dec 27, 2010
2,153
2,053
Queen City of the West
Google Pixel 7
Vistaus said:
Have you ever deodexed the thing? On the Defy they deodexed everything on some ROMS. Have you tried that on our XT720 already?
Click to expand...
Click to collapse

I've never quite understood what is meant with deodexing. From what I understand an odexed ROM has *.odex files external to the apks instead of *.dex inside the apks? Is that right? If so, I don't think any of the XT720 ROMs are odexed. None of the XT720, XT701 or A853 ROMs I have contain *.odex files. I did download a stock Defy ROM at one point and it did have *.odex files. Maybe Motorola only odexes MotoBlur ROMs? Or am I totally on the wrong path? The disadvantage of odex is that they're difficult to theme? Or is there another disadvantage?
 
hellmonger

hellmonger

Senior Member
Oct 9, 2010
778
263
Laval
Mioze7Ae said:
I've never quite understood what is meant with deodexing. From what I understand an odexed ROM has *.odex files external to the apks instead of *.dex inside the apks? Is that right? If so, I don't think any of the XT720 ROMs are odexed. None of the XT720, XT701 or A853 ROMs I have contain *.odex files. I did download a stock Defy ROM at one point and it did have *.odex files. Maybe Motorola only odexes MotoBlur ROMs? Or am I totally on the wrong path? The disadvantage of odex is that they're difficult to theme? Or is there another disadvantage?
Click to expand...
Click to collapse

WanHu Deodex already no?

see this
http://www.droidforums.net/forum/xeudoxus/47283-release-xultimate.html
 
You must log in or register to reply here.

Similar threads

R
[KERNEL][OC] custom kernel for Motoroi rom + Dexter's rom
Replies
92
Views
33K
R
resar
R
[REF] Kernel compiled from Source boots with fastboot [CONFIRMED]
Replies
107
Views
37K
B
B_e_n
fjfalcon
[hack][2ndboot] Custom kernel (no radio)
Replies
38
Views
11K
Z
Zachary57
J.Y.Daddy
[ROM][2011.12.07] CyanogenMod, HO!NO!, iceandfire(Ultimate), Cronos Ginger X
Replies
671
Views
180K
P
pilev
P
[dev] fastboot kernel + patches
Replies
36
Views
9K
Mioze7Ae
Mioze7Ae

Top Liked Posts

24 Hours All time
  • There are no posts matching your filters.
  • 1
    A
    appagom
    hellmonger asked me to repost this as a new thread. I'm not entirely sure he wasn't pulling my chain.. but whatever... here it is.

    There's development going on for kernel's that can't be flashed anyway. So every time you boot your phone you need your PC handy for fastboot... fun experiment, but no thanks.

    Support for ext2/3/4, and any of the other modular changes the kernel mods do can probably be made (and possibly even made useful) without changing the actual kernel image (flashed or otherwise).

    I now see it's not like nobody here thought of this (and I didn't mean to presume otherwise), example here:
    http://xdaforums.com/showthread.php?t=929871

    The point that I did add was:
    From my samsung experience, one click lag fix mounted /data without modifying the kernel by replacing the splash screen binary, which came up before data was mounted needed (other things used this trick too). It's not near as elegant but it may be possible to place kernel modules in /system/extramodules or whatever load them at some time like that, and then get support from then on.

    The file on samsung was called playlogos or playlogos1 depending on the device. It did more than just play a logo I think.. and actually it had to be moved, replaced with a script.. and the script then should run the moved copy in the end. I don't see this file on the Motorola, but maybe there is something similar. If being clever, you make the script copy another script in from the sd card, chmod it and run it. Then if you make changes to the real script that cause boot loops, you can just modify it on the sd card, or pull it.

    This would then be something that doesn't require a PC to do. Obviously anything requiring changing the actual kernel zImage won't work.
    It's not beautiful, but neither is fastboot. For korean sgs it was possible to compile kernel modules for ext4 that would run on the stock kernel. (you should read through that thread I linked though.. some good point made there about that).

    If you want to use another filesystem for your primary (as opposed to linked) /data there are some important details that I'm no longer remembering perfectly. The typical boot loop check for /data happened after this splash screen so that was ok, but it was I think still necessary to have the kernel not fail to mount /data before that (Probably the partition will get reformatted if it can't be mounted). If so, one possibility may be to repartition to make a tiny fake data partition and then remount the real one, just and idea. The reason things worked for OCLF was that OCLF left /data partition unmodified, but mounted an ext2 image file sitting on /data, arguably not an appealing thing to do, but it had its uses on Samsung devices depending who you asked.

    Mioze7ae since pointed out in passing though that partition tables are burned into the kernel, so this repartition trick may still be a no-go. Anyway I don't know exactly what goals people have for using various filesystems on XT720 devices, and filesystems are not the only modular changes being made to some of these kernels that maybe don't need to be in-kernel, in a flashing sense.

    I probably don't intend to be a primary developer on anything this involved... no time, just ideas, testing, etc at most.
    View

New posts