Need Code guru to help with bootloader code.... - LG Optimus L9 P760, P765, P768, P769
The latest update to 20f pushes the same unlock files to the phone as the (euro?) open kdz. That is the libunlock.so file. From what I see it appears that the phone checks the nv partition for the unlocked or locked "token" for the bootloader. I am trying to find out where in the nv partition this flag resides but I am not so good with this type of code. I will post some of the code (this is pertaining to the unlock checks) and im asking someone to help me figure out where this flag is so we can hex edit it and be done with this silly flashing back and forth to unlock. So here :
.text:0000098C EXPORT write_nv
.text:0000098C write_nv ; CODE XREF: bootloader_unlock_handler+F2p
.text:0000098C
.text:0000098C buf = -0x14
.text:0000098C
.text:0000098C PUSH {R0-R2,R4,R5,LR}
.text:0000098E MOV R5, R1
.text:00000990 STR R0, [SP,#0x18+buf]
.text:00000992 MOVS R1, #2 ; oflag
.text:00000994 LDR R0, =0x4E7
.text:00000996 ADD R0, PC ; "/dev/block/platform/omap/omap_hsmmc.1/b"...
.text:00000998 BLX open
.text:0000099C CMP R0, #0
.text:0000099E MOV R4, R0
.text:000009A0 BGE loc_9B0
.text:000009A2 LDR R1, =(aCanTOpenNvdata - 0x9AC)
.text:000009A4 MOVS R0, #3
.text:000009A6 MOV R2, R4
.text:000009A8 ADD R1, PC ; "Can't open NVDATA partition ret = %d \n"
.text:000009AA BL logger
.text:000009AE B loc_9CC
.text:000009B0 ; ---------------------------------------------------------------------------
.text:000009B0
.text:000009B0 loc_9B0 ; CODE XREF: write_nv+14j
.text:000009B0 MOVS R2, #0 ; whence
.text:000009B2 MOV R1, R5 ; offset
.text:000009B4 BLX lseek
.text:000009B8 CMP R0, #0
.text:000009BA BGE loc_9D0
.text:000009BC LDR R1, =(aCannotSeekToRe - 0x9C2)
.text:000009BE ADD R1, PC ; "Cannot seek to real block device footer"...
.text:000009C0
.text:000009C0 loc_9C0 ; CODE XREF: write_nv+56j
.text:000009C0 MOVS R0, #3
.text:000009C2 BL logger
.text:000009C6 MOV R0, R4 ; fd
.text:000009C8 BLX close
.text:000009CC
.text:000009CC loc_9CC ; CODE XREF: write_nv+22j
.text:000009CC MOVS R0, #0
.text:000009CE B locret_9EC
.text:000009D0 ; ---------------------------------------------------------------------------
.text:000009D0
.text:000009D0 loc_9D0 ; CODE XREF: write_nv+2Ej
.text:000009D0 MOVS R2, #4 ; n
.text:000009D2 MOV R0, R4 ; fd
.text:000009D4 ADD R1, SP, #0x18+buf ; buf
.text:000009D6 BLX write
.text:000009DA CMP R0, #0
.text:000009DC BGE loc_9E4
.text:000009DE LDR R1, =(aCanTReadUnlock - 0x9E4)
.text:000009E0 ADD R1, PC ; "Can't read unlock bit.\n"
.text:000009E2 B loc_9C0
.text:000009E4 ; ---------------------------------------------------------------------------
.text:000009E4
.text:000009E4 loc_9E4 ; CODE XREF: write_nv+50j
.text:000009E4 MOV R0, R4 ; fd
.text:000009E6 BLX close
.text:000009EA MOVS R0, #1
.text:000009EC
.text:000009EC locret_9EC ; CODE XREF: write_nv+42j
.text:000009EC POP {R1-R5,PC}
.text:000009EC ; End of function write_nv
.text:000009EC
I can go to any function or bit of code you need. I've reverse engineered this file.
omgbossis21 said:
The latest update to 20f pushes the same unlock files to the phone as the (euro?) open kdz. That is the libunlock.so file. From what I see it appears that the phone checks the nv partition for the unlocked or locked "token" for the bootloader. I am trying to find out where in the nv partition this flag resides but I am not so good with this type of code. I will post some of the code (this is pertaining to the unlock checks) and im asking someone to help me figure out where this flag is so we can hex edit it and be done with this silly flashing back and forth to unlock. So here :
.text:0000098C EXPORT write_nv
.text:0000098C write_nv ; CODE XREF: bootloader_unlock_handler+F2p
.text:0000098C
.text:0000098C buf = -0x14
.text:0000098C
.text:0000098C PUSH {R0-R2,R4,R5,LR}
.text:0000098E MOV R5, R1
.text:00000990 STR R0, [SP,#0x18+buf]
.text:00000992 MOVS R1, #2 ; oflag
.text:00000994 LDR R0, =0x4E7
.text:00000996 ADD R0, PC ; "/dev/block/platform/omap/omap_hsmmc.1/b"...
.text:00000998 BLX open
.text:0000099C CMP R0, #0
.text:0000099E MOV R4, R0
.text:000009A0 BGE loc_9B0
.text:000009A2 LDR R1, =(aCanTOpenNvdata - 0x9AC)
.text:000009A4 MOVS R0, #3
.text:000009A6 MOV R2, R4
.text:000009A8 ADD R1, PC ; "Can't open NVDATA partition ret = %d \n"
.text:000009AA BL logger
.text:000009AE B loc_9CC
.text:000009B0 ; ---------------------------------------------------------------------------
.text:000009B0
.text:000009B0 loc_9B0 ; CODE XREF: write_nv+14j
.text:000009B0 MOVS R2, #0 ; whence
.text:000009B2 MOV R1, R5 ; offset
.text:000009B4 BLX lseek
.text:000009B8 CMP R0, #0
.text:000009BA BGE loc_9D0
.text:000009BC LDR R1, =(aCannotSeekToRe - 0x9C2)
.text:000009BE ADD R1, PC ; "Cannot seek to real block device footer"...
.text:000009C0
.text:000009C0 loc_9C0 ; CODE XREF: write_nv+56j
.text:000009C0 MOVS R0, #3
.text:000009C2 BL logger
.text:000009C6 MOV R0, R4 ; fd
.text:000009C8 BLX close
.text:000009CC
.text:000009CC loc_9CC ; CODE XREF: write_nv+22j
.text:000009CC MOVS R0, #0
.text:000009CE B locret_9EC
.text:000009D0 ; ---------------------------------------------------------------------------
.text:000009D0
.text:000009D0 loc_9D0 ; CODE XREF: write_nv+2Ej
.text:000009D0 MOVS R2, #4 ; n
.text:000009D2 MOV R0, R4 ; fd
.text:000009D4 ADD R1, SP, #0x18+buf ; buf
.text:000009D6 BLX write
.text:000009DA CMP R0, #0
.text:000009DC BGE loc_9E4
.text:000009DE LDR R1, =(aCanTReadUnlock - 0x9E4)
.text:000009E0 ADD R1, PC ; "Can't read unlock bit.\n"
.text:000009E2 B loc_9C0
.text:000009E4 ; ---------------------------------------------------------------------------
.text:000009E4
.text:000009E4 loc_9E4 ; CODE XREF: write_nv+50j
.text:000009E4 MOV R0, R4 ; fd
.text:000009E6 BLX close
.text:000009EA MOVS R0, #1
.text:000009EC
.text:000009EC locret_9EC ; CODE XREF: write_nv+42j
.text:000009EC POP {R1-R5,PC}
.text:000009EC ; End of function write_nv
.text:000009EC
I can go to any function or bit of code you need. I've reverse engineered this file.
Click to expand...
Click to collapse
nv contains very little data, why not dump 10g , 20f and euro open and compare what going on
Lelus said:
nv contains very little data, why not dump 10g , 20f and euro open and compare what going on
Click to expand...
Click to collapse
Yes I've already examined the nv partition from 20f on my phone. I will flash to 10g and pull it now. Just hoping someone understood the coding a bit better than me and could tell me where abouts to look in the nv partition.
Im assuming its in this bit here :
.........LGP769A
T-01-V20d-310-26
0-MAR-16-2013+00
omgbossis21 said:
Yes I've already examined the nv partition from 20f on my phone. I will flash to 10g and pull it now. Just hoping someone understood the coding a bit better than me and could tell me where abouts to look in the nv partition.
LGP769A
T-01-V20d-310-26
0-MAR-16-2013+00
Click to expand...
Click to collapse
310-260 are t-mobile network codes
Keep in mind that non of 769 stock kernels allow passing "oem-unlock" or "bootloader" command to uboot during the reboot and that's the reason why phones just reboot.
Lelus said:
310-260 are t-mobile network codes
Keep in mind that non of 769 stock kernels allow passing oem-unlock or bootloader to uboot during the reboot and that's the reason why phones just reboot.
Click to expand...
Click to collapse
My fault the last bit was from d and this one from f :
LGP769AT-01-V20d
-310-260-MAR-16-
2013+00.........
I just flashed a unlocked u and boot. Img to my phone. It did the same thing flashing the open kdz does, inverts the image and wonky touch screen. I wonder how we can clear the NV partition to reset the flag...
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
I just flashed a unlocked u and boot. Img to my phone. It did the same thing flashing the open kdz does, inverts the image and wonky touch screen. I wonder how we can clear the NV partition to reset the flag...
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
It looks to me like something prevents that unlock bit(token) form being generated or written to the nv.
Lelus said:
It looks to me like something prevents that unlock bit(token) form being generated or written to the nv.
Click to expand...
Click to collapse
I believe the token is definitely generated as their is a value for multiple boot loader states :
.text:00000CC2 loc_CC2 ; CODE XREF: main+8Ej
.text:00000CC2 MOVW R3, #0x2774
.text:00000CC6 CMP R5, R3
.text:00000CC8 BNE loc_CDC
.text:00000CCA LDR R5, =(asc_1008 - 0xCD2)
.text:00000CCC MOVS R0, #6
.text:00000CCE ADD R5, PC ; "---------------------------------------"...
.text:00000CD0 MOV R1, R5
.text:00000CD2 BL logger
.text:00000CD6 LDR R1, =(aDeviceUnlockIs - 0xCDC)
.text:00000CD8 ADD R1, PC ; "Device Unlock is permitted. But, unlock"...
.text:00000CDA B loc_D24
.text:00000CDC ; ---------------------------------------------------------------------------
.text:00000CDC
.text:00000CDC loc_CDC ; CODE XREF: main+ECj
.text:00000CDC MOVW R0, #0x277F
.text:00000CE0 CMP R5, R0
.text:00000CE2 BNE loc_CF6
.text:00000CE4 LDR R5, =(asc_1008 - 0xCEC)
.text:00000CE6 MOVS R0, #6
.text:00000CE8 ADD R5, PC ; "---------------------------------------"...
.text:00000CEA MOV R1, R5
.text:00000CEC BL logger
.text:00000CF0 LDR R1, =(aDeviceIsAlread - 0xCF6)
.text:00000CF2 ADD R1, PC ; "Device is already unlocked\n"
.text:00000CF4 B loc_D24
.text:00000CF6 ; ---------------------------------------------------------------------------
.text:00000CF6
.text:00000CF6 loc_CF6 ; CODE XREF: main+106j
.text:00000CF6 MOVW R2, #0x2AF8
.text:00000CFA CMP R5, R2
.text:00000CFC BNE loc_D10
.text:00000CFE LDR R5, =(asc_1008 - 0xD06)
.text:00000D00 MOVS R0, #6
.text:00000D02 ADD R5, PC ; "---------------------------------------"...
.text:00000D04 MOV R1, R5
.text:00000D06 BL logger
.text:00000D0A LDR R1, =(aBootloaderUnlo - 0xD10)
.text:00000D0C ADD R1, PC ; "Bootloader Unlock is prohibited\n"
.text:00000D0E B loc_D24
.text:00000D10 ; ---------------------------------------------------------------------------
.text:00000D10
.text:00000D10 loc_D10 ; CODE XREF: main+120j
.text:00000D10 CMP R5, #0xDE
.text:00000D12 BNE loc_D32
.text:00000D14 LDR R5, =(asc_1008 - 0xD1C)
.text:00000D16 MOVS R0, #6
.text:00000D18 ADD R5, PC ; "---------------------------------------"...
.text:00000D1A MOV R1, R5
.text:00000D1C BL logger
.text:00000D20 LDR R1, =(aUnlockBitIsFul - 0xD26)
.text:00000D22 ADD R1, PC ; "Unlock bit is full!!!\n"
.text:00000D24
.text:00000D24 loc_D24 ; CODE XREF: main+FEj
.text:00000D24 ; main+118j ...
.text:00000D24 MOVS R0, #6
.text:00000D26 BL logger
.text:00000D2A MOVS R0, #6
.text:00000D2C MOV R1, R5
.text:00000D2E BL logger
.text:00000D32
.text:00000D32 loc_D32 ; CODE XREF: main+CCj
.text:00000D32 ; main+E4j ...
.text:00000D32 MOV R0, R4
.text:00000D34 ADD SP, SP, #0x14
.text:00000D36 POP {R4,R5,PC}
.text:00000D36 ; End of function main
.text:00000D36
Do you guys need my nvram before and right after UL? I currently got no time, otherwise I d probably try to help you out and compare it myself.
Sent from my LG-P760 using xda app-developers app
I think the kernel is the key, but we can't mod it. I noticed Lg is quite lazy when it comes to making changes for different kdz versions. I have found files and scripts that do not belong to that kdz version, and I think that is the case here. The u-boot for 20f recognizes our unlock status, but maybe that's it. Lol, I guess they didn't think people would root and dissect everything or, they knew what they were doing, and wanted us to find it
Sent from my LG-P769 using xda app-developers app
Might it be just about the bootargs? Cause on my old OB, it was enough to set force_bootarg=y or something like this before building. Anyone who tested it already? Oh and sorry, but my nvram partition is empty... Dunno, what went wrong on the backup.
Sent from my LG-P760 using xda app-developers app
Edit:
I made a backup of all partitions before and after I unlocked the phone.
Didnt yet have time to properly check all those files, but what I found is, that only the following partitions got changed:
nvram
persist
mlt
& divxkey
Wondering, what happend at those partitions...
nvram might be the key here. Persist seems to log a lot... Will have a closer look at that as well. Maybe it somehow stores, if BL has been unlocked or not.
mlt... Well who knows, what we'll still find there... Hello NSA
divxkey... This seems really strange to me, but I ll also have a look into this one as well, as soon, as I find some time off
Edit 2:
Uploaded a zip files of those files to my devhost account. If anyone else wants to have a look, PM me please, because I dont want to share the files in public, because of my IMEI and other private stuff.
The divx key likely changes BC wallpaper bin file checks those files and after unlocking the wallpaper bin is usually one of the first things to go. I examined persist block on my other phone, basically its a persisted log lol. As mentioned above NV contains very little data (modem version/software version and what I believe to be the CPU serial). Libunlock writes and reads there for bootloader status though just got to find out where. I will pm you
Sent from my LG-P769 using xda app-developers app
I really need the NV partition of a already unlocked phone.
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
I really need the NV partition of a already unlocked phone.
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
I ll PM you. But please dont flash it! Also contains IMEI and other information specific for each device!
Sent from my LG-P760 using xda app-developers app
I didn't see An imei anywhere in it. For that matter I switched my NV partition to the one from another version I had and it was fine. I then deleted the NV partition and rebooted, it just recreated it. I won't flash it though. I will change my software version to match yours run the libunlock.so and try to unlock.
Sent from my LG-P769 using xda app-developers app
Well for starters the NV partition on the unlocked version is called nvdata where as our jellybean its just NV. I bet 10g has nvdata and jellybean changed it to NV (though I'm not sure at the moment). Changing the name to nvdata and using unlock command on jellybean did not work even with a unlocked boot and u. Now I will dissect these files to find that one minor change so we know where the flag is stored and what variables are.
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
Well for starters the NV partition on the unlocked version is called nvdata where as our jellybean its just NV. I bet 10g has nvdata and jellybean changed it to NV (though I'm not sure at the moment). Changing the name to nvdata and using unlock command on jellybean did not work even with a unlocked boot and u. Now I will dissect these files to find that one minor change so we know where the flag is stored and what variables are.
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
Have you tried changing /system/build.prop : ro.build.target_operator to OPEN ?
Just tried that's it didn't work, thanks though. I'm now gonna try a hex edited NV partition. It appears before and after lock his NV partition did not change. I think it would have if he ran the command again.
Sent from my LG-P769 using xda app-developers app
omgbossis21 said:
Just tried that's it didn't work, thanks though. I'm now gonna try a hex edited NV partition. It appears before and after lock his NV partition did not change. I think it would have if he ran the command again.
Sent from my LG-P769 using xda app-developers app
Click to expand...
Click to collapse
Take a look at the very end of /data/dontpanic/last_kmsg.txt right after reboot oem-unlock
Interested rebooting in non supported mode. When I dissassembled libunlock it listed its dependancies. I pulled the full system/lib folder from the open version. . I may try copying over the lib unlock and its dependancies.
Sent from my LG-P769 using xda app-developers app
Related
XDA DVLPRS - please help! [himalaya not entering bootloader]
My iMATE is no longer entering Bootloader mode. Not by pressing hardware buttons, not by initiating bootloader mode by upgrade programm. It just restarts device. I am afraid, that I am going to stuck with the ROM version I currently have, wich is bummer because Second Edition is coming out soon. Any suggestions how to fix this? I remember that by Bootloader was version 1.03. I have a serial cable, SD reader and SD card as my tools. Please, help. Regards. I wonder, if similar tool exist for himalaya: http://forum.xda-developers.com/viewtopic.php?t=2079&highlight=bootloader+fix
OK, I did some research and found following utilities: savebootlader.exe pnewbootloader.exe Please, tell me. If I'll get dump of bootloader 1.03 ( the one I've had on my machine) from working XDA2 and then upload it by pnewbootloader IT WILL FIX MY PROBLEM? and does it really necessary to have the same bootloader version or I can use any, 1.01, 1.06? TIA I really hope that it will
got bootloader dumped by people here (thanks a lot again!), but when I try to put it back to machine I am getting C:\Program Files\XDAtools\binaries>pnewbootloader bootloader.nb0 this is possibly not a bootloader!! 80000000: ea0003fe 00000000 00000000 00000000 ................ 80000010: 00000000 00000000 00000000 00000000 ................ 80000020: 00000000 00000000 00000000 00000000 ................ 80000030: 00000000 00000000 00000000 00000000 ................ 80000040: 43454345 90064000 00000000 00000000 [email protected] C:\Program Files\XDAtools\binaries>pnewbootloader -f bootloader.nb0 Unable to find flash info offset, cannot disable bootloader writeprotect Looks like this utility is not designed for XDA2.
Anyone? :roll:
ID64... How to use those tools? And from where to use it? I've got all the tools but i dunno how and where to use it? Sorry for asking...
[SOLVED] need help reversing proprietary syscall [ARM]
Hello, I'm trying to properly invoke a proprietary syscall on ARM architecture. Target is an ELF recovery executable (ARM Big Endian) whose sources are not available, and which has been modded from AOSP (device is Meizu MX 4-core). I have attached my progress in a rar archive : View attachment MX4_recovery.rar. It includes the target executable along with a .IDC script that defines a few names for IDA (works for demo version as well). - private SWI number is 0xF0066 - the sub invoking syscall is @00009350 getRcvKeyFrmKrnSYSCALL recovery_printkey is my lame attempt at invoking the SVC 0 in C+ASM. Code: .global _myasmfunc _myasmfunc: .func _myasmfunc @ RcvKeyFrmKrn syscall ldr r7, =0xF0066 ldr r2, =_g_ptrfd ldr r0, [r2] ldr r1, =_g_buf ldr r2, =_g_mode swi #0 bx lr .endfunc After compiling (utility script in homedir), transferring and running on the device, RC=0 but all buffers are unchanged. I tried various combinations. I wish I could breakpoint right before the SVC 0 instruction, but sadly cannot. I am not too well-versed and probably made a mistake in analysing how parameters are set. What I need to know: [Q] What goes into the ARM registers, based on sub_CAB0 execution? Can you please help?
Situation solved. Only R0 register is used for 0xF0066 in the swi call site (0x400 buffer).
[ROM][JB][AOSP][4.1.2/JZO54K][DEV] Project Jellyzeus r5
What is it? A pure(-ish) build of AOSP (code-frozen 4.1.2_r1/jb-mr0-release, a.k.a JZO54K) for the Xperia Play. It's as pure as can be, there are some fixes from CM10 (thanks J), SlimRom and myself needed to get everything working. But the framework and apps are 99% 90% AOSP, with changes specific to solving known Jellybean issues on our device. There are however some more extras, such as Google Apps preinstalled and maybe some other slight changes. What's the point? Designed for developers/chefs and testers, this has three major goals: Provide a good base to port other Jellybean ROM's to (in particular, my Turbo UI ROM) A good comparison with other JB ROM's to see what is and isn't broken (great for the second or third multiboot slot). E.g. if something crashes in Slimbean or PAC, try in this. Because it is "feature frozen" whereas CM10 and other JB ROM's keep adding new things that may break something (you know, it happens). Forward-port ICS/GB code to get more things working - like native xLoud and better Touchpad support. This ROM is feature frozen. I will not add Notification Toggles. I will not add a Reboot option to power menu. I will not add *anything* unless it will benefit other JB ROM's/Developers or Turbo UI. Please don't request new fancy features that other JB ROM's already have - this is not the point of this ROM. Many of my developments have already made their way into wedgess PAC, cj360's SlimBean and/or FXP's CyanogenMod. Jellyzeus is a platform for my own research and improvements and I only released it for educational, development and comparison purposes. If you want a more serious and useful ROM that is directly based on this, check out my MIUI based PatchROM build - Turbo UI. Status? Green: Complete Brown: Has issues or untested Red: Broken or not finished yet Calls, texts, 3G for GSM (have not done heavy testing, needs more) Multiboot-aware All sensors (including proximity) CDMA addon (beta, needs logcats if any problems) Camera (Legacy) (Thanks to Wedgess) (No Panorama) Browser and Web rendering Sound with with decent stock-like headphone volume xLOUD enabled (uses ICS Audio blobs from stock/prebuilt) (hack) Google Apps included Wifi GPS / Location services Touchpads (Lag reduced but not eliminated) Bluetooth Native Wifi Tether Google Now Voice Search/Recognition Video Recording (480p only - don't ask about 720p, not possible) ? Bugs/Important Info? On a fresh install, all the tones are set to silent. Ringtone, Notification Tone and Alarm tone must be manually set. I have no idea what is causing this. Fixed. Sources? All of my source changes can, as always, be found on my GitHub (see my signature). Additionally, here are the details of my repo's - they are all original AOSP from 4.1.2_r1 tag, with the exception of these mentioned repo's - mostly for compatibility with QCOM hardware, as well as additional fixes and improvement's I've made. There are also various small patches to make to get it to build. Instructions for building from my sources can be found in post #2. Source repo/patch details: Code: cosmicdan: bootable/recovery/ (forked from cyanogenmod) device/semc/msm7x30-common/ (forked from garwedgess) frameworks/av/ (forked from AOSP) frameworks/base/ (forked from AOSP) (jellyzeus branch) frameworks/native/ (forked from AOSP) hardware/libhardware/ (forked from slimroms, jb branch) hardware/libhardware_legacy/ (forked from slimroms, jb branch) libcore (forked from AOSP) system/core/ (forked from AOSP) (jellyzeus branch) vendor/semc/ (forked from garwedgess) cyanogenmod: build/ external/busybox/ external/bluetooth/bluez/ external/yaffs2/ external/zlib/ hardware/broadcom/wlan/ hardware/ril/ hardware/sony/DASH/ packages/apps/Gallery2/ packages/apps/LegacyCamera/ vendor/cm/ system/bluetooth/ system/netd/ system/vold/ garwedgess: device/semc/msm7x30-common/ device/semc/zeus/ device/semc/zeus-common/ SlimRoms (branch): external/chromium/ (jellybean) external/webcore/ (jellybean) hardware/msm7k/ (jb) hardware/qcom/audio/ (jb) hardware/qcom/gps/ (jb) hardware/qcom/media/ (jb) hardware/qcom/display/ (jellybean) This patch for Guava incompatibility with OpenJDK - https://github.com/CyanogenMod/android_external_guava/commit/c8b97210aa31c9b80b5fd136d8617ebe4e731e09 Use prebuilt kernel to save time and fix build complaining from missing kernel sources - Open /device/semc/zeus/BoardConfig.mk and remove the comment (#) symbol from TARGET_PREBUILT_KERNEL Open vendor/cm/config/common.mk and comment out the three lines for Terminal, like so: [code]#PRODUCT_COPY_FILES += \ #vendor/cm/proprietary/Term.apk:system/app/Term.apk \ #vendor/cm/proprietary/lib/armeabi/libjackpal-androidterm4.so:system/lib/libjackpal-androidterm4.so [/code] Credits? CosmicDan, Kamarush and Irii for Turbo JB Kernel Cyanogenmod and Jerpelea (FreeXperia) Wedgess, cj360, paxChristos, KeiranFTW, Nickholtus, SuperVenom and Farenheith Fellow members of MIUI Australia - LennyKano, FusionJack and Dekky Special thanks to Amarullz (creator of Aroma Installer) and the XDA community Download and Instructions? Flash Turbo JB kernel (recommended) and be sure to follow the instructions there. This ROM is multiboot-aware already, so feel free to install the ZIP from Slot 2 or 3. Install the ROM normally (in any slot you like if using multiboot) Download latest ROM: zeus_aosp_412_r5.zip @ Mediafire Download CDMA addon: zeus_aosp_412_cdma_r3.zip @ Mediafire (install after main ROM) Changelog? Code: r5 -- - Overhaul Telephony, Webkit, Bluetooth and Net framework - Additional property support from CyanogenMod (performance related) - Reverted Camera changes in r4 - More things I can't remember. It's all on GitHub. r4 -- - Fixed Camera recording (480p only, 720p permanently removed due to bugs) - Fixed native App2SD - Numerous fixes/optimizations to Telephony and Media framework - Reverted ICS audio blobs r3 -- - New - hold volume buttons to skip music tracks - Fixed various Google App issues (e.g. Calendar sync, Location services) - Reduced touchpad lag by about half (best I can do until we learn more...) - Fixed touchpad recognition (Farenheith's Touchpad Fix v1.1) - Fixed default tones being silent (Random fix) - Fixed Wifi signal indicator on statusbar (Framework issue) - Fixed GPS (was it ever broken? Google Maps and GPS Status lock fine) - Fixed Bluetooth (Update sources for BCM interface from CM10) - Patched services to not force minfree or adj values - Basic tweaks added to init.d, same used in MIUI Australia (minfree/adj/kernel tuning) - Updated Google Now to latest version (no longer crashes on voice input but simply fails) r2 -- - Additional video and audio native decoding support, thanks to CAF (such as H.263, WMV, MP3, etc) - Fixed root (replaced with Chainfire's SuperSU v0.99) - Fixed Proximity Sensor - Fixed rotation (accelerometer/orientation) - Fixed compass - Fixed ALS (automatic brightness) - Fixed Browser (replaced webKit core with prebuilt from SlimBean port, thanks cj360!) - Disable some debugging parameters to improve performance - Native Sony sound blobs and full xLoud support enabled - Replaced AOSP Keyboard with Nexus 4.2 version (smaller APK) - Removed unused content accidently included from CM10 - Removed Google Calendar and returned original (more compatible with widgets, can get Google Calendar from Play Store anyway) r1 -- - Initial release Screenshots? No. It looks like AOSP (like CM10 but with much less features). If you only want to see what this ROM looks like, please move along it's for dev's and research purposes after all.
This post is reserved for build instructions.
Really looking forward for this! First! Sent from my R800i using xda app-developers app ---------- Post added at 05:15 AM ---------- Previous post was at 04:28 AM ---------- I don't really have any ideas on the kernel panic, but I'll keep thinking. Sent from my R800i using xda app-developers app
I figured it out, same problem as the webcore glitches. QCOM tile renderer is not fully ported yet. WOOO one-man think tank!
CosmicDan said: I figured it out, same problem as the webcore glitches. QCOM tile renderer is not fully ported yet. WOOO one-man think tank! Click to expand... Click to collapse + A Half Wit Sent from my R800i using xda app-developers app
You're only a halfwit when you complain or flame the dev's
The camera works fine. The automatic rotation doesn't work.
Binary_File said: The camera works fine. The automatic rotation doesn't work. Click to expand... Click to collapse Erm... Camera doesn't work. Automatic rotation is a minor framework issue, not a priority right now. Main things are camera and web browser (which are graphics related).
CosmicDan said: This post is for detailed status and (when available) source-code links and summaries of changes. kmsg dump of the kernel panic when trying to start legacy camera: Code: Switching from ACPU rate 768000 KHz -> 1024000 KHz Enabling PLL 2 Disabling PLL 1 ACPU speed change complete msm_enqueue: queue event new max is 1 msm_enqueue: queue control new max is 1 msm_pp_release: pp not in progress for 0 Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = 81180000 [00000000] *pgd=01376031, *pte=00000000, *ppte=00000000 Internal error: Oops: 80000007 [#1] PREEMPT last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state Modules linked in: CPU: 0 Tainted: G W (2.6.32.9-KRsH-irii #1) PC is at 0x0 LR is at msm_ioctl_config+0x10d8/0x12b4 pc : [<00000000>] lr : [<803e5198>] psr: 60000013 sp : 8c135e68 ip : 00000014 fp : 8c135edc r10: 2c72490c r9 : 8c134000 r8 : 8003712c r7 : 40046d1b r6 : 2c72490c r5 : 2c72490c r4 : 80e6d0d8 r3 : 00000000 r2 : 0000002b r1 : 00000000 r0 : 8c135e84 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c57c7d Table: 01380059 DAC: 00000015 LR: 0x803e5118: 5118 fffffe00 e1a0200d e3c23d7f e3c3303f e24b0070 e5933008 e2952004 30d22003 5138 33a03000 e3530000 1a000005 e1a01005 e3a02004 ebfaf31b e3500000 0a000008 5158 ea000001 e3a01004 ebfafc46 e51f0064 e3002854 e51f1074 e51f3068 eb06ce30 5178 ea00003e e5943000 e51b1070 e5932080 e59330c4 e592205c e5920000 e12fff33 5198 eafffc1e e51f00a0 e5947000 e3500010 9a000004 e3a010d0 ebf5798b e2506000 51b8 1a000001 ea000002 e1a06000 e3a03001 e5863030 e1a0c00d e3cc3d7f e3c3303f 51d8 e286003c e5933008 e2952004 30d22003 33a03000 e3530000 1a000005 e1a01005 51f8 e3a02004 ebfaf2ef e2504000 0a000017 ea000001 e3a01004 ebfafc1a e51f0114 SP: 0x8c135de8: 5de8 00000000 80d9c000 800d8624 80114318 80c0ca40 00000000 ffffffff 8c135e54 5e08 2c72490c 40046d1b 8c135edc 8c135e20 80036bb0 80036308 8c135e84 00000000 5e28 0000002b 00000000 80e6d0d8 2c72490c 2c72490c 40046d1b 8003712c 8c134000 5e48 2c72490c 8c135edc 00000014 8c135e68 803e5198 00000000 60000013 ffffffff 5e68 8c135ecc 8c135e78 801303fc 8012d1bc 00000032 00000000 00000000 0000002b 5e88 2c57000c 2c724900 000004cc 81180b10 00000133 00000000 00000000 8c130128 5ea8 00000200 8c156420 8c135ecc 8c029a00 803e40c0 2c72490c 40046d1b 8003712c 5ec8 8c134000 2c72490c 8c135efc 8c135ee0 80157698 803e40cc 2c72490c 8c029a00 FP: 0x8c135e5c: 5e5c 00000000 60000013 ffffffff 8c135ecc 8c135e78 801303fc 8012d1bc 00000032 5e7c 00000000 00000000 0000002b 2c57000c 2c724900 000004cc 81180b10 00000133 5e9c 00000000 00000000 8c130128 00000200 8c156420 8c135ecc 8c029a00 803e40c0 5ebc 2c72490c 40046d1b 8003712c 8c134000 2c72490c 8c135efc 8c135ee0 80157698 5edc 803e40cc 2c72490c 8c029a00 40046d1b 0000001b 8c135f7c 8c135f00 80158160 5efc 80157668 80036340 8003eb18 80e2b6c0 00000002 8017a404 801482c4 cf397500 5f1c 00000020 00000000 00000000 00000003 2c7245b0 ceaa1b00 2c7245b0 00000003 5f3c 00000000 8c135f6c 8c135f50 ceaa1b00 00000002 0000001b 2c72490c 8c029a00 R0: 0x8c135e04: 5e04 8c135e54 2c72490c 40046d1b 8c135edc 8c135e20 80036bb0 80036308 8c135e84 5e24 00000000 0000002b 00000000 80e6d0d8 2c72490c 2c72490c 40046d1b 8003712c 5e44 8c134000 2c72490c 8c135edc 00000014 8c135e68 803e5198 00000000 60000013 5e64 ffffffff 8c135ecc 8c135e78 801303fc 8012d1bc 00000032 00000000 00000000 5e84 0000002b 2c57000c 2c724900 000004cc 81180b10 00000133 00000000 00000000 5ea4 8c130128 00000200 8c156420 8c135ecc 8c029a00 803e40c0 2c72490c 40046d1b 5ec4 8003712c 8c134000 2c72490c 8c135efc 8c135ee0 80157698 803e40cc 2c72490c 5ee4 8c029a00 40046d1b 0000001b 8c135f7c 8c135f00 80158160 80157668 80036340 R4: 0x80e6d058: d058 80e6d054 00000000 00000000 8080e260 00000000 00000002 00000001 00000000 d078 805d9458 80e2b7a4 80e2b7a4 0ee00001 00000001 00000001 80e6d0d8 00000000 d098 00000000 80e6d09c 80e6d09c 00000000 00000000 8080e260 00000000 00000001 d0b8 00000001 00000000 805d94c0 80e6d0c4 80e6d0c4 0ee00002 00000001 00000000 d0d8 cb099500 00000000 80e6d0e0 80e6d0e0 80e6d0e8 80e6d0e8 00000001 00000000 d0f8 80719017 80e6d0fc 80e6d0fc 80e6d104 80e6d104 00000000 00000000 80728fea d118 00000000 80e6d11c 80e6d11c 80e6d124 80e6d124 00000000 00000000 80728ff0 d138 00000000 80e6d13c 80e6d13c 80e6d144 80e6d144 00000000 00000000 80728ff5 R8: 0x800370ac: 70ac e24fef6d 3798f107 e28d1008 e3a08000 e357080f e2270000 2a0011ff ea02873c 70cc e1a02007 e28d1008 e3a00000 eb000925 e28fe014 e1a07000 e28d1008 e3570e17 70ec 3891000f 3798f107 eaffffef e5ad0008 e1a02007 e1a0100d e3a00001 eb000919 710c eaffff90 e320f000 e320f000 e320f000 e320f000 807e8a98 8080bf00 800377a8 712c 800ceacc 800bf904 80037714 80148fcc 80149048 801482f0 80146848 800d8dc0 714c 80148340 801560cc 80155e88 80037724 80147c5c 800d8dc0 80155cec 80147f4c 716c 800eb148 800d8dc0 800d8dc0 801488f4 800cb73c 80164720 800d8dc0 800eb230 718c 800eb644 800d8dc0 800c70b4 800d8dc0 800d8dc0 800cfc0c 800d8dc0 800d8dc0 R9: 0x8c133f80: 3f80 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fa0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fc0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 3fe0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 4000 00000000 00000002 00000000 8c156420 807fdff8 00000000 00000017 8119faa0 4020 8119faa0 8c134000 8c1565cc 811fa1c0 00000000 8c156420 8c135e6c 8c135e20 4040 8059e334 00000000 00000000 00000000 00000000 00000000 01010000 00000000 4060 2c724f00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 Process Binder_1 (pid: 1156, stack limit = 0x8c1342f0) Stack: (0x8c135e68 to 0x8c136000) 5e60: 8c135ecc 8c135e78 801303fc 8012d1bc 00000032 00000000 5e80: 00000000 0000002b 2c57000c 2c724900 000004cc 81180b10 00000133 00000000 5ea0: 00000000 8c130128 00000200 8c156420 8c135ecc 8c029a00 803e40c0 2c72490c 5ec0: 40046d1b 8003712c 8c134000 2c72490c 8c135efc 8c135ee0 80157698 803e40cc 5ee0: 2c72490c 8c029a00 40046d1b 0000001b 8c135f7c 8c135f00 80158160 80157668 5f00: 80036340 8003eb18 80e2b6c0 00000002 8017a404 801482c4 cf397500 00000020 5f20: 00000000 00000000 00000003 2c7245b0 ceaa1b00 2c7245b0 00000003 00000000 5f40: 8c135f6c 8c135f50 ceaa1b00 00000002 0000001b 2c72490c 8c029a00 40046d1b 5f60: 0000001b 8003712c 8c134000 00000000 8c135fa4 8c135f80 801581f8 80157c28 5f80: 00000001 00000001 2c5762d8 2c569740 2c724934 00000036 00000000 8c135fa8 5fa0: 80036f00 801581c0 2c5762d8 2c569740 0000001b 40046d1b 2c72490c 2c7248fc 5fc0: 2c5762d8 2c569740 2c724934 00000036 2c574dd8 000e1000 0006ae00 000002f8 5fe0: 2c53930c 2c7248e0 2ab49cfd 2ab2ebd4 00000010 0000001b ff706766 ff746a6a Code: bad PC value [audio_out.c:audio_dsp_event] PCMDMAMISSED 32 Nnvh vdnnbolllicb.o vk ---[ end trace 1b75b31a2719ed1e ]--- Kernel panijbimvhyc - not syncing: Fatal exception [<8003d83c>] (unwind_backtrace+0x0/0xd8) from [<80598164>] (dump_stack+0x20/0x24) [<80598164>] (dump_stack+0x20/0x24) from [<80598978>] (panic+0x6c/0x130) [<80598978>] (panic+0x6c/0x130) from [<8003b5c4>] (die+0x17c/0x1a8) [<8003b5c4>] (die+0x17c/0x1a8) from [<805981cc>] (__do_kernel_fault.part.2+0x64/0x74) [<805981cc>] (__do_kernel_fault.part.2+0x64/0x74) from [<8003ecf8>] (do_page_fault+0x1ec/0x204) [<8003ecf8>] (do_page_fault+0x1ec/0x204) from [<80036340>] (do_PrefetchAbort+0x44/0xa8) [<80036340>] (do_PrefetchAbort+0x44/0xa8) from [<80036bb0>] (__pabt_svc+0x50/0xa0) Exception stack(0x8c135e20 to 0x8c135e68) 5e20: 8c135e84 00000000 0000002b 00000000 80e6d0d8 2c72490c 2c72490c 40046d1b 5e40: 8003712c 8c134000 2c72490c 8c135edc 00000014 8c135e68 803e5198 00000000 5e60: 60000013 ffffffff [<80036bb0>] (__pabt_svc+0xiy. Mkz50/0xa0) fro . [<803e5198>] (msm_ioctl_config+0x10d8/0x12b4) [<803e5198>must (msm_ioctl_config+0x10d8/0x12b4) from [<80157698>] (vfs_ioctl+0x3c/0x9c) Mk [<80157x cg:banghead: mixvkok698>] (vfs_ioctl+0x3c/0x9c) from [<80158160>]r (do_vfs_ioctl+0x54oftu 4/0x598) ? Ggbf yourself g6c6uukt:rolleyes:lmng [<80158160>] (do_vfsvkrjvj_ioctl+0x544/0x598) from [<8y01581f8>]y (sys_ioctl+0x44/0x70) [<801581f8>] (sys_ioctl+0x44/0x70) from [<80036f00>] (ret_fast_syscall+0x0/0x2c) : &@[email protected]:*Binder_1* Gvnm .:df Rebooteing in 1 seconds.. smd_close(RPCCALL)mm l nuik :what::thumbdown: I think the interesting part is this: Code: Code: bad PC value [audio_out.c:audio_dsp_evju:jnj çgigyaent] PCMDMAMISSED 32 d .mzk Y I've done some research and apparently this is some kind of deadlock, but from what i do nott know. Click to expand... Click to collapse Sent from my FIH-FB0 using xda premium
I found the problem, both camera and browser should be fixed this weekend. Was not using latest fixed QCOM hardware sources for display (specifically, TileRendering support).
Proximity mught be in the libs. /system/lib/libssensorservice.so Or something like that. Maybe.. Sent from my Xperia Play using xda app-developers app
JunDavis said: Proximity mught be in the libs. /system/lib/libssensorservice.so Or something like that. Maybe.. Sent from my Xperia Play using xda app-developers app Click to expand... Click to collapse Well yeah, and the sensor hardware static object. Finding the actual code and getting the ICS sensor framework working in JB is no as simple as copy/paste though. On a lighter note, I've already implemented the groundwork for using Sony stock ICS audio libs. Which means that getting full xLoud support (actually reliably unlike Turbo UI and, in future, with a toggle) should be relatively easy. Yay!
CosmicDan said: Well yeah, and the sensor hardware static object. Finding the actual code and getting the ICS sensor framework working in JB is no as simple as copy/paste though. On a lighter note, I've already implemented the groundwork for using Sony stock ICS audio libs. Which means that getting full xLoud support (actually reliably unlike Turbo UI and, in future, with a toggle) should be relatively easy. Yay! Click to expand... Click to collapse Yea :/, I knew you can't just copy and paste. I just posted that because I thought it was somewhat relevant. Also, yay! xLoud Sent from my Xperia Play using xda app-developers app
Besides, why do we need proximity sensor anyway? It only goes up to 1 cm. Guess it would be nice to have every tiny thing working though. Sent from my Xperia Play using xda app-developers app
JunDavis said: Besides, why do we need proximity sensor anyway? It only goes up to 1 cm. Guess it would be nice to have every tiny thing working though. Sent from my Xperia Play using xda app-developers app Click to expand... Click to collapse Because it's annoying that your face can touch buttons when you're in a call lol.
CosmicDan said: Because it's annoying that your face can touch buttons when you're in a call lol. Click to expand... Click to collapse Never had that problem o.o lol Sent from my Xperia Play using xda app-developers app
CosmicDan said: Because it's annoying that your face can touch buttons when you're in a call lol. Click to expand... Click to collapse Yeah lol Sent from my R800i using Tapatalk 2
And also battery. If you're in a long call you want to save as much battery as possible, and the screen is the biggest offender of battery use. I know you can always press power button to turn screen on/off, but that's quite annoying when you want to (e.g) quickly check how long the call has gone for.
CosmicDan said: And also battery. If you're in a long call you want to save as much battery as possible, and the screen is the biggest offender of battery use. I know you can always press power button to turn screen on/off, but that's quite annoying when you want to (e.g) quickly check how long the call has gone for. Click to expand... Click to collapse Agreed, I already had to upgrade my battery a while back :/ Sent from my Xperia Play using xda app-developers app
Make sure you keep your old one for whenever you do flashing or logcat and other USB stuff. Constantly plugging/unplugging USB tends to wear-out a battery quicker that usual. And as usual, only charge when essential _don't top it up every night if not needed). But sometimes that's not realistic, so use "Fast Discharge" app on Play Store to help quickly drain battery fully, then recharge to max over night (from flat). That will help recondition the battery. But yeah, my "dev battery" barely lasts two hours lol. That's the original one from my old X10.
[Q] IDA Pro : how to set option for use data xref ?
Hi, I use ida pro for cortex m3, get code: LDR R0, =(loc_8001D74+1) BX R0 ; loc_8001D74 off_80000F8 DCD loc_8001D74+1 ; DATA XREF: sub_80000F4r how to get code like this: LDR R0, off_80000F8 BX R0 ; loc_8001D74 off_80000F8 DCD loc_8001D74+1 ; DATA XREF: sub_80000F4r Thanks.
Do you press hotkey "O" - Make Offset?
Joker XT said: Do you press hotkey "O" - Make Offset? Click to expand... Click to collapse Press "O": "dword_80000FC DCD 0x20000308" switch to "off_80000FC DCD 0x20000308" "LDR.W SP, =0x20000308" cannot change to "LDR.W SP, dword_80000FC " thanks.
I find the result: change ida.cfg: ARM_NO_PTR_DEREF = YES // Disable using of =label notation then it's ok!
Porting kexec hardboot to LG L1 II
Hi, I've read the porting kexec hardboot wiki: https://github.com/Tasssadar/multirom/wiki/Porting-kexec-hardboot and, in particular, the following step: Hard-reboot in arch/arm/kernel/relocate_kernel.S Can be found here in the patch for mako. This can often be the hardest thing to find out. Try to look for restart.c or reboot.c or something like that in your device's arch/arm/mach-xxx folder and port the restart sequence from that file to assembler. If you are using Tegra 2/3 or MSM SoC, chances are reboot methods currently (or very similar to them) in the patch will work. Click to expand... Click to collapse So, the porting guide says the restart sequence should be ported from restart.c to relocate_kernel.S. Exactly, what function I've to port from restart.c? Any ideas?
Ok, I've ported the restart sequence into relocate_kernel.S. The patch just needs the following changes: Code: #elif defined(CONFIG_ARCH_MSM7X27) #include <mach/msm_iomap.h> Code: #elif defined(CONFIG_ARCH_MSM7X27) /* Restart using the PMIC chip, see mach-msm/restart.c */ mov r0, #3 ldr r1, =0x00100000 str r0, [r1] ldr r0, =0x77665501 str r0, [r1, #0x08] mov r0, #0 str r0, [r1, #0x0C] mov r0, #1 ldr r1, =0xc0100418 str r0, [r1] loop: b loop Many thanks to a msm dev guy for the help and explanations, which I've translated into assembly code shown above :good: Now, the next part of the porting kexec hardboot wiki says: Reserving memory for kexec-hardboot page Can be found here in the patch for mako. You need to find a place where reserving memory is safe, typicaly somewhere around where memory for ram_console is reserved. It probably will be in the board's file. I usually register the page just before the ram_console, which is before the end of the first memory bank. Click to expand... Click to collapse So, my question is: what board's file is the porting guide pointing to? Any ideas?
Ok, I've reserved memory for kexec-hardboot page. This part can be done if board-msm7x27a_v1.c board's file (located into arch/arm/mach-msm/lge/v1 directory) is changed as follows:
Code:
static void __init msm7x27a_reserve(void)
{
reserve_info = &msm7x27a_reserve_info;
msm_reserve();
#ifdef CONFIG_KEXEC_HARDBOOT
// Reserve space for hardboot page, just before the ram_console
struct membank* bank = &meminfo.bank[0];
phys_addr_t start = bank->start + bank->size - SZ_1M - SZ_1M;
int ret = memblock_remove(start, SZ_1M);
if(!ret)
pr_info("Hardboot page reserved at 0x%X\n", start);
else
pr_err("Failed to reserve space for hardboot page at 0x%X!\n", start);
#endif
}
Now, the next part of the porting kexec hardboot wiki says:
Setting KEXEC_HB_PAGE_ADDR
Can be found here in the patch for mako. This is highly device-specific. Either apply the patch without this value (-> set it to beggining of the System RAM) and grep dmesg for the value you printk in memory reservation ("Hardboot page reserved at 0x%X") or look into /proc/iomem to see where the first bank of System RAM ends, substract size of ram_console ram and size of the hardboot page from that and you should get the right address.
Click to expand...
Click to collapse
This is my /proc/iomem:
Code:
00200000-0fefffff : System RAM
00208000-0098207b : Kernel code
009b2000-00c03f87 : Kernel data
0ff3e000-0ff3efff : crash_log
20000000-2b4fffff : System RAM
98000000-9807ffff : lcd01
9c000000-9c07ffff : lcd02
a0000000-a001ffff : kgsl_3d0_reg_memory
a0000000-a001ffff : kgsl-3d0
a0200000-a0200fff : msm_serial_hs.0
a0300000-a0300fff : uartdm_resource
a0400000-a0400fff : msm_sdcc.1
a0500000-a0500fff : msm_sdcc.2
a0600000-a0600fff : msm_sdcc.3
a0800000-a08003ff : msm_hsusb_host.0
a0800000-a08003ff : msm_hsusb
a0800000-a08003ff : msm_otg
a0d00000-a0d00fff : base
a0e00000-a0e00fff : pbus_phys_addr
a0f00000-a0ffffff : csic
a0f00000-a0ffffff : msm_csic
a1000000-a10fffff : csic
a1000000-a10fffff : msm_csic
a1200000-a1200fff : gsbi_qup_i2c_addr
a1200000-a1200fff : qup_i2c
a1280000-a1280fff : qup_phys_addr
a1280000-a1280fff : qup_i2c
a1300000-a1300fff : gsbi_qup_i2c_addr
a1300000-a1300fff : qup_i2c
a1380000-a1380fff : qup_phys_addr
a1380000-a1380fff : qup_i2c
a8600000-a8600fff : clk_ctl
a9700000-a9700fff : msm_dmov
a9a00000-a9a00fff : msm_serial.0
a9a00000-a9a00fff : msm_serial
aa200000-aa2f1007 : mdp
c0400000-c0400fff : pl310_erp
In particular, line related to the first bank of System RAM says:
Code:
00200000-0fefffff : System RAM
So, should I subtract size of ram_console ram and size of the hardboot page from 0fefffff in order to get the right value for KEXEC_HB_PAGE_ADDR? And, should I use SZ_1M for the size of hardboot page? Any ideas?
Ok, I've set KEXEC_HB_PAGE_ADDR. Briefly, I've subtracted size of the hardboot page (SZ_1M) and size of ram_console (LGE_RAM_CONSOLE_SIZE) from the end address of the System RAM first bank (0ff00000 = 0fefffff + 1). This part can be done if memory.h (located into arch/arm/mach-msm/include/mach directory) is changed as follows: Code: #if defined(CONFIG_KEXEC_HARDBOOT) #if defined(CONFIG_MACH_MSM7X25A_V1) #define KEXEC_HB_PAGE_ADDR UL(0x0FDC2000) #else #error "Adress for kexec hardboot page not defined" #endif #endif Now, the next part of the porting kexec hardboot wiki says: Setting kexec_hardboot_hook Can be found here in the patch for mako. This method should contain some device-specific code which needs to be executed during the reboot sequence. Again, can be found in restart.c or reboot.c or something like that in your device's arch/arm/mach-xxx. Chances are you don't need to set anything in here. Click to expand... Click to collapse So, what device-specific code (which needs to be executed during the reboot sequence) should this method contain, in my particular case? Can I just use only pm8xxx_reset_pwr_off function, as in the patch for mako? Any ideas?