NEW - 1080P kernels for Finless KitKat 2.0 ROM

[Finless]

how do i umpack the rk header. ?

Sent from my GT-I9300 using Tapatalk

Just remove the first 8 bytes.

I use this command.

dd if=kernel.img of=kernel.bin skip=8 bs=1 count=200000000

Bob

[smic717394]

Just remove the first 8 bytes.

I use this command.

dd if=kernel.img of=kernel.bin skip=8 bs=1 count=200000000

Bob

Hi Bob,

Thank you, wow, you the men. I removed the signature fom the kernel, umpack and it produced a 90MB file, but without another 1080p kernel to compare i guess its not much I can do with it, right. I tried diferent kernels just to compare and they just have way too many diferences. Thank you for your help.

[observ]

I cant patch the kernel and I tried before. It is coded differently than any other kernel I have patched before. It would take more time than I want to spend to figure it out all over again.

Now you can find it yourself but it's a PAIN. This is exactly how I have done it!!
You have to decompile the kernel into text then looking through raw object code find the 1280 and 720 areas. Note the address location then go patch the binary at those locations.

To decompile a kernel you need 64 bit Ubuntu installed.

First unpack the RK header from kernel.img so you have kernel.bin

The command to decompile in Linux is:

/usr/bin/arm-linux-gnueabihf-objdump kernel.bin --target binary -marm -D > kernel.d

Kernel.d will be a huge text file.


Some tips would be to decompile 2 exact kernels with the only difference being 720 and 1080. Compare the 2 decompiled kernels using kdiff3. You can then easily find the locations between the 2.


Good luck!

Bob

Do you have guidance on what sorts of patterns to look for in the ARM assembly? Or maybe the assembly diffs from your changes?

The reason I ask is that the only KitKat ROM I've found that maintains hardware acceleration in video decoding and rendering in XBMC 13.0 "Gotham" on my Tronsmart MK908II is the T010 "official" ROM with a 720p kernel.

None of the kernels for the Finless 2.0 BETA for CX-919 did hardware acceleration, nor those kernels (or the d33 kernels) with Finless 2.0 ROM for the T428, nor the Finless 2.0 ROM for the A928 do hardware acceleration with XBMC "Gotham", whether 720p or 1080p. (To the extent that the thing was struggling with 640x352 SD content.)

Neomode ROM with 4.0, 4.1, 4.2 d33 kernels didn't finish booting, and the d33 kernels with the T010 ROM lose hardware accelerated rendering and/or decoding.

So I figure my best option is to try to patch the stock kernel that comes with that firmware to use a 1920x1080 framebuffer rather than 1280x720, if it really is just about changing parameters somewhere.

(Why not stick with a Jelly Bean ROM? Immersive mode, new with KitKat, is much better than using something like "Hide System Bar".)

Edit: looks like these comprise your changes. Pity the kernel I'm looking at seems to use a different mechanism.

   247a9c:      e1c0c0b0        strh    ip, [r0]
   247aa0:      e3a04021        mov     r4, #33 ; 0x21
   247aa4:      e1c0c0b2        strh    ip, [r0, #2]
-  247aa8:      e3a0cc05        mov     ip, #1280       ; 0x500
+  247aa8:      e3a0cd1e        mov     ip, #1920       ; 0x780
   247aac:      e5802014        str     r2, [r0, #20]
-  247ab0:      e3a02064        mov     r2, #100        ; 0x64
+  247ab0:      e3a0205a        mov     r2, #90 ; 0x5a
   247ab4:      e1c0c0b8        strh    ip, [r0, #8]
-  247ab8:      e3a0ce2d        mov     ip, #720        ; 0x2d0
+  247ab8:      e24ccfd2        sub     ip, ip, #840    ; 0x348
   247abc:      e1c021bc        strh    r2, [r0, #28]
-  247ac0:      e3a02012        mov     r2, #18
+  247ac0:      e3a02001        mov     r2, #1
   247ac4:      e1c0c0ba        strh    ip, [r0, #10]
   247ac8:      e3a0c0d8        mov     ip, #216        ; 0xd8
   247acc:      e1c021be        strh    r2, [r0, #30]
-  247ad0:      e3a0200a        mov     r2, #10
+  247ad0:      e3a02001        mov     r2, #1
   247ad4:      e1c0c0bc        strh    ip, [r0, #12]
   247ad8:      e3a0c087        mov     ip, #135        ; 0x87
   247adc:      e1c022b0        strh    r2, [r0, #32]
-  247ae0:      e3a02008        mov     r2, #8
+  247ae0:      e3a0200c        mov     r2, #12
   247ae4:      e1c040b4        strh    r4, [r0, #4]
   247ae8:      e1c022b2        strh    r2, [r0, #34]   ; 0x22
-  247aec:      e3a02006        mov     r2, #6
+  247aec:      e3a02001        mov     r2, #1
   247af0:      e1c0c0be        strh    ip, [r0, #14]
   247af4:      e1c022b4        strh    r2, [r0, #36]   ; 0x24
-  247af8:      e3a02002        mov     r2, #2
+  247af8:      e3a02001        mov     r2, #1
   247afc:      e580103c        str     r1, [r0, #60]   ; 0x3c
   247b00:      e1c022b6        strh    r2, [r0, #38]   ; 0x26
   247b04:      e5c03038        strb    r3, [r0, #56]   ; 0x38
@@ -591739,7 +591739,7 @@ Disassembly of section .data:
   247b24:      e5c03045        strb    r3, [r0, #69]   ; 0x45
   247b28:      e8bd0010        ldmfd   sp!, {r4}
   247b2c:      e12fff1e        bx      lr
-  247b30:      e3a0060b        mov     r0, #11534336   ; 0xb00000
+  247b30:      e3a00506        mov     r0, #25165824   ; 0x1800000
   247b34:      e12fff1e        bx      lr
   247b38:      e3033e10        movw    r3, #15888      ; 0x3e10
   247b3c:      e34c30d0        movt    r3, #49360      ; 0xc0d0

[LawlessPPC]

Do you have guidance on what sorts of patterns to look for in the ARM assembly? Or maybe the assembly diffs from your changes?

The reason I ask is that the only KitKat ROM I've found that maintains hardware acceleration in video decoding and rendering in XBMC 13.0 "Gotham" on my Tronsmart MK908II is the T010 "official" ROM with a 720p kernel.

None of the kernels for the Finless 2.0 BETA for CX-919 did hardware acceleration, nor those kernels (or the d33 kernels) with Finless 2.0 ROM for the T428, nor the Finless 2.0 ROM for the A928 do hardware acceleration with XBMC "Gotham", whether 720p or 1080p. (To the extent that the thing was struggling with 640x352 SD content.)

Neomode ROM with 4.0, 4.1, 4.2 d33 kernels didn't finish booting, and the d33 kernels with the T010 ROM lose hardware accelerated rendering and/or decoding.


So I figure my best option is to try to patch the stock kernel that comes with that firmware to use a 1920x1080 framebuffer rather than 1280x720, if it really is just about changing parameters somewhere.

(Why not stick with a Jelly Bean ROM? Immersive mode, new with KitKat, is much better than using something like "Hide System Bar".)

Edit: looks like these comprise your changes. Pity the kernel I'm looking at seems to use a different mechanism.

   247a9c:      e1c0c0b0        strh    ip, [r0]
   247aa0:      e3a04021        mov     r4, #33 ; 0x21
   247aa4:      e1c0c0b2        strh    ip, [r0, #2]
-  247aa8:      e3a0cc05        mov     ip, #1280       ; 0x500
+  247aa8:      e3a0cd1e        mov     ip, #1920       ; 0x780
   247aac:      e5802014        str     r2, [r0, #20]
-  247ab0:      e3a02064        mov     r2, #100        ; 0x64
+  247ab0:      e3a0205a        mov     r2, #90 ; 0x5a
   247ab4:      e1c0c0b8        strh    ip, [r0, #8]
-  247ab8:      e3a0ce2d        mov     ip, #720        ; 0x2d0
+  247ab8:      e24ccfd2        sub     ip, ip, #840    ; 0x348
   247abc:      e1c021bc        strh    r2, [r0, #28]
-  247ac0:      e3a02012        mov     r2, #18
+  247ac0:      e3a02001        mov     r2, #1
   247ac4:      e1c0c0ba        strh    ip, [r0, #10]
   247ac8:      e3a0c0d8        mov     ip, #216        ; 0xd8
   247acc:      e1c021be        strh    r2, [r0, #30]
-  247ad0:      e3a0200a        mov     r2, #10
+  247ad0:      e3a02001        mov     r2, #1
   247ad4:      e1c0c0bc        strh    ip, [r0, #12]
   247ad8:      e3a0c087        mov     ip, #135        ; 0x87
   247adc:      e1c022b0        strh    r2, [r0, #32]
-  247ae0:      e3a02008        mov     r2, #8
+  247ae0:      e3a0200c        mov     r2, #12
   247ae4:      e1c040b4        strh    r4, [r0, #4]
   247ae8:      e1c022b2        strh    r2, [r0, #34]   ; 0x22
-  247aec:      e3a02006        mov     r2, #6
+  247aec:      e3a02001        mov     r2, #1
   247af0:      e1c0c0be        strh    ip, [r0, #14]
   247af4:      e1c022b4        strh    r2, [r0, #36]   ; 0x24
-  247af8:      e3a02002        mov     r2, #2
+  247af8:      e3a02001        mov     r2, #1
   247afc:      e580103c        str     r1, [r0, #60]   ; 0x3c
   247b00:      e1c022b6        strh    r2, [r0, #38]   ; 0x26
   247b04:      e5c03038        strb    r3, [r0, #56]   ; 0x38
@@ -591739,7 +591739,7 @@ Disassembly of section .data:
   247b24:      e5c03045        strb    r3, [r0, #69]   ; 0x45
   247b28:      e8bd0010        ldmfd   sp!, {r4}
   247b2c:      e12fff1e        bx      lr
-  247b30:      e3a0060b        mov     r0, #11534336   ; 0xb00000
+  247b30:      e3a00506        mov     r0, #25165824   ; 0x1800000
   247b34:      e12fff1e        bx      lr
   247b38:      e3033e10        movw    r3, #15888      ; 0x3e10
   247b3c:      e34c30d0        movt    r3, #49360      ; 0xc0d0

The T010 rom if you use antutu does it show two cores asleep? Mine does and seeing as it at 1.4ghz is very hot

[observ]

The T010 rom if you use antutu does it show two cores asleep? Mine does and seeing as it at 1.4ghz is very hot

AnTuTu does show two of the cores sleeping when not testing (i.e. idle). I don't know what you mean by "very hot"; its performance and temperatures seemed reasonable to me. (AnTuTu score: 16,787 for an RK3188-T at the stock 1.4 GHz CPU/594 MHz GPU/300 MHz DDR).

I did a very simple test, running in the busybox shell three instances:

$ (while true; do true; done) &
$ (while true; do true; done) &
$ (while true; do true; done) &

This causes three infinite loops in parallel and should be able to consume up to three cores' worth of CPU completely.

On a dual core machine I would expect their total utilization to add up to 100%. On a quad core I would expect 75%.

When I run

$ top | grep -v ' 0% '

I see each instance of /system/bin/sh use 24-25%for a total of about 75%, which confirms for me the fact that the cores are all working. The fact that the OS shuts down two of the cores when idle is a good thing in my mind.

[observ]

For the T010 kernel I'm going to try this

--- kernel.S    2014-06-16 01:41:17.880242264 +0100
+++ kernel1080.S        2014-06-17 01:42:04.210591561 +0100
@@ -858454,53 +858454,53 @@ Disassembly of section .data:
   34b5c0:      15933154        ldrne   r3, [r3, #340]  ; 0x154
   34b5c4:      15832010        strne   r2, [r3, #16]
   34b5c8:      e12fff1e        bx      lr
   34b5cc:      e3a02000        mov     r2, #0
   34b5d0:      e3a01001        mov     r1, #1
   34b5d4:      e1a03002        mov     r3, r2
   34b5d8:      e1c020b4        strh    r2, [r0, #4]
   34b5dc:      e92d00f0        push    {r4, r5, r6, r7}
-  34b5e0:      e3a04005        mov     r4, #5
-  34b5e4:      e3a07c05        mov     r7, #1280       ; 0x500
+  34b5e0:      e3a04001        mov     r4, #1
+  34b5e4:      e3a07d1e        mov     r7, #1920       ; 0x780
   34b5e8:      e3a06cbe        mov     r6, #48640      ; 0xbe00
   34b5ec:      e30f5710        movw    r5, #63248      ; 0xf710
   34b5f0:      e3416298        movt    r6, #4760       ; 0x1298
   34b5f4:      e340546c        movt    r5, #1132       ; 0x46c
   34b5f8:      e1c020b2        strh    r2, [r0, #2]
   34b5fc:      e1c070b8        strh    r7, [r0, #8]
-  34b600:      e3a07e2d        mov     r7, #720        ; 0x2d0
+  34b600:      e2477fd2        sub     r7, r7, #840    ; 0x348
   34b604:      e1c020bc        strh    r2, [r0, #12]
   34b608:      e1c020be        strh    r2, [r0, #14]
-  34b60c:      e3a020dc        mov     r2, #220        ; 0xdc
+  34b60c:      e3a0205a        mov     r2, #90 ; 0x5a
   34b610:      e1c010b0        strh    r1, [r0]
   34b614:      e1c021bc        strh    r2, [r0, #28]
-  34b618:      e3a0206e        mov     r2, #110        ; 0x6e
+  34b618:      e3a02001        mov     r2, #1
   34b61c:      e1c070ba        strh    r7, [r0, #10]
   34b620:      e1c021be        strh    r2, [r0, #30]
-  34b624:      e3a02028        mov     r2, #40 ; 0x28
+  34b624:      e3a02001        mov     r2, #1
   34b628:      e580603c        str     r6, [r0, #60]   ; 0x3c
   34b62c:      e1c022b0        strh    r2, [r0, #32]
-  34b630:      e3a02014        mov     r2, #20
+  34b630:      e3a0200c        mov     r2, #12
   34b634:      e5805014        str     r5, [r0, #20]
   34b638:      e1c022b2        strh    r2, [r0, #34]   ; 0x22
   34b63c:      e1c042b4        strh    r4, [r0, #36]   ; 0x24
   34b640:      e1c042b6        strh    r4, [r0, #38]   ; 0x26
   34b644:      e5c01038        strb    r1, [r0, #56]   ; 0x38
   34b648:      e5c01039        strb    r1, [r0, #57]   ; 0x39
   34b64c:      e5c0303a        strb    r3, [r0, #58]   ; 0x3a
   34b650:      e5c0103b        strb    r1, [r0, #59]   ; 0x3b
   34b654:      e5c03043        strb    r3, [r0, #67]   ; 0x43
   34b658:      e5c03042        strb    r3, [r0, #66]   ; 0x42
   34b65c:      e5c03041        strb    r3, [r0, #65]   ; 0x41
   34b660:      e5c03044        strb    r3, [r0, #68]   ; 0x44
   34b664:      e5c03045        strb    r3, [r0, #69]   ; 0x45
   34b668:      e8bd00f0        pop     {r4, r5, r6, r7}
   34b66c:      e12fff1e        bx      lr
-  34b670:      e3a0060b        mov     r0, #11534336   ; 0xb00000
+  34b670:      e3a00506        mov     r0, #25165824   ; 0x1800000
   34b674:      e12fff1e        bx      lr
   34b678:      e3033e08        movw    r3, #15880      ; 0x3e08
   34b67c:      e34c30e0        movt    r3, #49376      ; 0xc0e0
   34b680:      e3a00002        mov     r0, #2
   34b684:      e5933000        ldr     r3, [r3]
   34b688:      e5933178        ldr     r3, [r3, #376]  ; 0x178
   34b68c:      e5932010        ldr     r2, [r3, #16]
   34b690:      e38220d0        orr     r2, r2, #208    ; 0xd0

Judging by the fact that the values decimal 1280 and 720 are stored in adjacent 16-bit halfword locations I'm guessing those need to be replaced with 1920 and 1080 (1920 - 840 as Finless did in his ROMs to keep with the compact ARM instruction encoding scheme) at minimum.

This has proven useful: http://www.scribd.com/doc/40069778/A...-Set-Reference

I'm guessing the other values set up display modes but I have no idea which each one is. I've copied the values from the Finless 1080p kernel changes given that r0 seems to point to the same location in each case:

r0 + # 8 := #1920
r0 + #10 := #1080
r0 + #28 := #90
r0 + #30 := #1
r0 + #32 := #1
r0 + #34 := #12
r0 + #36 := #1

Edit: Success! I get a 1920x1080 framebuffer with these changes. However, the video starts to become choppy in places, so I'm guessing either the device can't keep up, or I've lost acceleration again. I'm going to try to diff the Finless 1.6 kernels to see if I can't figure out the parameters, as I believe those used to accelerate decode and render.

[observ]

Looks like for Finless 1.6 these were the changes:

r0 + #8  := #1920
r0 + #10 := #1080
r0 + #24 := #148
r0 + #26 := #88
r0 + #28 := #44
r0 + #30 := #36

This seems to be a slightly different set of memory locations, with the only commonalities being the addresses represented by r0 + #8, r0 + #10, r0 + #28 and r0 + #30.

Edit: It seems the original 720p kernel also struggles at times with the particular video I was trying in XBMC, so all in all I think the kernel bytepatching did succeed. I've attached this 1080p kernel for the T010.

You can install it using adb to push the kernel image and the flash_image tool abdul_pt bundles with his recovery installer to the device, and flash via adb shell:

C:\Users\foo\Downloads>adb push kernel.img /sdcard/kernel.img
C:\Users\foo\Downloads>adb push flash_image /sdcard/flash_image
C:\Users\foo\Downloads>adb shell
# cp /sdcard/flash_image /dev/
# chmod 755 /dev/flash_image
# /dev/flash_image kernel /sdcard/kernel.img
# sync;sync;sync
# reboot

kernel-KK-T010-AP6210-public-20140403-1080p.zip

[sararmen]

help me,

http://www.freaktab.com/showthread.php?16423-HELP-!!!-Andersson-Ads-3-0-Problem&p=219121#post219121