Originally posted by smic717394
View Post
I use this command.
dd if=kernel.img of=kernel.bin skip=8 bs=1 count=200000000
Bob
-
Just remove the first 8 bytes.
I use this command.
dd if=kernel.img of=kernel.bin skip=8 bs=1 count=200000000
Bob"Pzebacz im, bo nie wiedzą, co czynią"
"Прости им, они не ведают, что творят"
"Perdona loro perché non sanno quello che fanno"
"Vergib ihnen, denn sie wissen nicht, was sie tun"
"Vergeef hen want ze weten niet wat ze doen"
"Pardonne-leur car ils ne savent pas ce qu'ils font"
"Perdónalos porque no saben que lo que hacen"
"Oprosti im, jer ne znaju što čine"
"Forgive them as they know not what they do" -
Hi Bob,Originally posted by Finless View Post
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.For all your computer problems...
http://www.salvamipc.esComment
-
Originally posted by Finless View Post
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.
Code: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 ; 0xc0d0Last edited by observ; 06-16-2014, 01:38.Comment
-
Originally posted by observ View Post
The T010 rom if you use antutu does it show two cores asleep? Mine does and seeing as it at 1.4ghz is very hotComment
-
Originally posted by LawlessPPC View Post
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:
This causes three infinite loops in parallel and should be able to consume up to three cores' worth of CPU completely.Code:$ (while true; do true; done) & $ (while true; do true; done) & $ (while true; do true; done) &
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
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.Code:$ top | grep -v ' 0% '
Comment
-
For the T010 kernel I'm going to try this
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.Code:--- 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
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:
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.Code:r0 + # 8 := #1920 r0 + #10 := #1080 r0 + #28 := #90 r0 + #30 := #1 r0 + #32 := #1 r0 + #34 := #12 r0 + #36 := #1
Last edited by observ; 06-17-2014, 21:16.Comment
-
Looks like for Finless 1.6 these were the changes:
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.Code:r0 + #8 := #1920 r0 + #10 := #1080 r0 + #24 := #148 r0 + #26 := #88 r0 + #28 := #44 r0 + #30 := #36
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:
kernel-KK-T010-AP6210-public-20140403-1080p.zipCode: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
Last edited by observ; 06-18-2014, 02:03.Comment
There are currently 11868 users online. 5 members and 11863 guests.
Most users ever online was 16,134 at 08:28 on 08-11-2023.
Comment