Please compile, if possible, your embedded recovery kernels without the sensorhub defconfig options.
CONFIG_SENSORS_SSP=y
CONFIG_SENSORS_SYSFS=y
CONFIG_SENSORS_SSP_ACCELEROMETER_POSITION=7
CONFIG_SENSORS_SSP_GYROSCOPE_POSITION=7
CONFIG_SENSORS_SSP_MAGNETOMETER_POSITION=7
CONFIG_SENSORS_SSP_LSM330=y
CONFIG_SENSORS_SSP_CM36651=y
CONFIG_SENSORS_SSP_AK8963C=y
CONFIG_SENSORS_SSP_BMP182=y
CONFIG_SENSORS_SSP_AT32UC3L0128=y
CONFIG_SENSORS_SSP_SENSORHUB=y
The kernel flashes over the sensorhub firmware on every single entry of recovery, and rebooting into the normal kernel, if the embedded kernel firmware mismatches the live hardware firmware. I consider this dangerous because firstly I don't know what happens if a firmware flash fails on boot, and secondly, the whole procedure is done over the I2C bus and takes about 22 seconds, increasing the boot time (and recovery entry) dramatically. The firmware changes relatively often and we have like 4 different versions out there in the wild at this moment and they will surely increase.
Off-topic: The sensorhub is a new dedicated micro-controller chip found on the Note 2 which handles all device sensors, instead of them being handled by the main CPU itself. The point of the thing is to offload that work from the CPU to vastly improve battery life.
Thank you a lot for the feedback and input about this issue
When compiling recoveries, we get the binary (recovery file) and the kernel. Sorry if I seem noob here, but I do not compile kernels, I am only used to cwm source. And in the recovery binary sources, there is no sensors flashed, it is the kernel that is repacked with it.
Now, if I take a recovery.img as it is outputted when compiled from cm10 sources, that is packed with a cm10 kernel, the recovery will boot without a delay.
However, that will break exfat support since we cannot insmod the external modules
So, the only choice is to repack the recovery ramdisk with a stock Samsung kernel, and that's what I do in my recoveries. However, this seems to induce the boot delay for people using custom kernels built around some sources (redpill, Perseus)
These recoveries repacked with a Samsung kernel will run fine along stock kernels and Note2core custom kernel (also a 4.1.2 source).
One of the potential causes is this part of code I believe (have no Note 2 to debug it)
drivers/sensor/ak8963.c
Code:
if (retry_count < 5) {
retry_count++;
pr_warn("############################################");
pr_warn("%s, retry_count=%d\n", __func__, retry_count);
pr_warn("############################################");
goto retry;
} else {
There is a check routine repeated 5 times, and on each repeat count a goto loop. The retry loop restarts much above in the code
retry:
Code:
#ifdef FACTORY_TESTstatic int ak8963c_selftest(struct akm8963_data *ak_data, int *sf){
.
.
.
retry:
/* read device info */
i2c_smbus_read_i2c_block_data(ak_data->this_client,
AK8963_REG_WIA, 2, buf);
pr_info("%s: device id = 0x%x, info = 0x%x\n",
__func__, buf[0], buf[1]);
/* set ATSC self test bit to 1 */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_ASTC, 0x40);
/* start self test */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_CNTL1,
AK8963_CNTL1_SELF_TEST);
/* wait for data ready */
while (1) {
msleep(20);
if (i2c_smbus_read_byte_data(ak_data->this_client,
AK8963_REG_ST1) == 1) {
break;
}
}
i2c_smbus_read_i2c_block_data(ak_data->this_client,
AK8963_REG_HXL, sizeof(buf), buf);
/* set ATSC self test bit to 0 */
i2c_smbus_write_byte_data(ak_data->this_client,
AK8963_REG_ASTC, 0x00);
x = buf[0] | (buf[1] << 8);
y = buf[2] | (buf[3] << 8);
z = buf[4] | (buf[5] << 8);
/* Hadj = (H*(Asa+128))/256 */
x = (x*(ak_data->asa[0] + 128)) >> 8;
y = (y*(ak_data->asa[1] + 128)) >> 8;
z = (z*(ak_data->asa[2] + 128)) >> 8;
pr_info("%s: self test x = %d, y = %d, z = %d\n",
__func__, x, y, z);
if ((x >= -200) && (x <= 200))
pr_info("%s: x passed self test, expect -200<=x<=200\n",
__func__);
else
pr_info("%s: x failed self test, expect -200<=x<=200\n",
__func__);
if ((y >= -200) && (y <= 200))
pr_info("%s: y passed self test, expect -200<=y<=200\n",
__func__);
else
pr_info("%s: y failed self test, expect -200<=y<=200\n",
__func__);
if ((z >= -3200) && (z <= -800))
pr_info("%s: z passed self test, expect -3200<=z<=-800\n",
__func__);
else
pr_info("%s: z failed self test, expect -3200<=z<=-800\n",
__func__);
sf[0] = x;
sf[1] = y;
sf[2] = z;
if (((x >= -200) && (x <= 200)) &&
((y >= -200) && (y <= 200)) &&
((z >= -3200) && (z <= -800))) {
pr_info("%s, Selftest is successful.\n", __func__);
return 1;
} else {
if (retry_count < 5) {
retry_count++;
pr_warn("############################################");
pr_warn("%s, retry_count=%d\n", __func__, retry_count);
pr_warn("############################################");
goto retry;
}
These are many retries using a non efficient goto loop.
Basically, here's the current possibilities I see:
- if we repack the recovery with your kernel or redpill, people will get delay issues on stock ROMs/Kernels
- if we use cm10 kernel: no delays but we loose exfat support
- if we use note2core kernel we'll probably loose exfat support
- if I recompile kernel from samsung sources without the sensors, it seems it will also break exfat
So, at the end I do not see a good choice that will satisfy every one. Either I wait for Samsung to release their sources so that you fix the kernel or I repack with 2 kernels: Samsung stock and redpill, so people can chose
Hope I am not getting it all wrong, but that's how I understand it
All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.
The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.
And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.
And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.
Phil3759 said:
Either I wait for Samsung to release their sources so that you fix the kernel
Click to expand...
Click to collapse
There is nothing to fix from the live kernel side, I hope you understand that...
AndreiLux said:
All that code is totally irrelevant and has nothing to do with the issue. I also don't understand what you want to say about that loop? Goto is inefficient? Nonsense.
The firmware flash and logic happens in /drivers/sensorhub/ssp_firmware.c and its just a few lines of code. The whole flash process is logged in kmsg at boot so you can just retrieve that and see for yourself.
And you're missing the point, as long as you embed ANY kernel with the sensorhub drivers, they will flash it. There are stock kernels out there with versions 91100, 92600, 92800, 102600 (just from the top of my head, might differ). If you use any recovery kernel whose version mismatches the boot.img kernel firmware, you will get the issue.
And to be honest, I don't understand what the fuss is about fixing it, TWRP includes now a kernel with exFat and removed sensor drivers. You just have to do the same.
There is nothing to fix from the live kernel side, I hope you understand that...
Click to expand...
Click to collapse
AndreiLux said:
Sorry but you're a bit out of bound here with accusing kernel developers and doing such claims about the source of the issue while you seem pretty ignorant about the technical aspects of the problem.
As I said and explained in the thread you linked, the problem lies with the recovery and not the boot kernel. You're the one who will have to adapt your embedded kernel that you include here.
Click to expand...
Click to collapse
You also seem a bit ignorant about recoveries
TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.
TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support
So, not an easy decision / move as you suggest
Phil3759 said:
TWRP doesn't included any custom kernel with exfat support. It comes with cm9 kernel and maybe now cm10.1 since they moved sources to 4.2 recently. Their source is just the android/bootable/recovery part built around cyanogenmod source. CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay. That's the only reason why twrp won't have the delay. I can also include cm10 kernel and no more delays, but say good bye to exfat.
TWRP includes native exfat support where as CM and AOKP choose to not include it in their source (thus cwm) because it is not legal (MS patent). Only thing cwm devs can do:
- import twrp source for exfat support and break the MS patent
- use Samsung genuine kernel to get exfat support
So, not an easy decision / move as you suggest
Click to expand...
Click to collapse
Sorry but almost everything you said its wrong.
TWRP includes a modified CM kernel with added exFat and since I've made Bigbiff aware, also removes the sensorhub drivers.
CM kernel, as I said in my answer, doesn't flash the sensors that's why there is no delay.
Click to expand...
Click to collapse
The CM kernel is based on the Samsung sources and has the flash logic intact, because it's obviously needed in the OS to even have functioning sensors. It's not flashing in your case because you have matching firmwares, and that's all.
Sorry but I suggest you inform yourself here a bit more, I've explained it pretty clearly yet you seem to be ranting about things which are just not correct.
delete
Related
In this post, I would like to explain what kexec-hardboot patch is and also bring it to light a bit more since until now, it was only burried in MultiROM thread.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows me to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
Standard kexec call unfortunatelly does not work on Nexus 7. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a commong thing among Android devices, which is why kexec-hardboot was made.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Another difference is that both kernels must be patched. The "host" kernel requires a full patch, the one which is being kexecd' requires only two small compatibility patches.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Full kernel patch: https://gist.github.com/4558647, 4.1 kernel repo, cm 10.1 kernel repo
This is the full kernel patch. Kernels with this patch can be both "host" and "guest" kernels.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
CONFIG_GROUPER_HARDBOOT_RECOVERY=n
First three options must be enabled. Last one, GROUPER_HARDBOOT_RECOVERY, specifies if the kexec call should reboot to normal mode or to recovery. This can be useful if you don't have the kernel in boot partition but only as kernel in recovery partition. You usualy want to disable this option.
Compatibility patch: https://gist.github.com/4458581
This patch only makes the kernel bootable via kexec, ie. it can't be the host kernel. This was made for Ubuntu kernel (and it was accepted), because I did not want to drag the whole patch in there. If your kernel is for Android ROMs, you should use the full patch.
Userspace kexec binary: View attachment kexec-tools.zip
That ZIP file contains kexec source, patches and README. It is from the original patch from Mike Kasick. It also contains precompiled, statically linked kexec binary, so you probably just want to use that.
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x85000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Currently used by:
MultiROM - I use it to boot different kernels (eg. Ubuntu).
MOSLO - Part of Plasma Active for Nexus 7, also usefull tool for every N7 developer - read more: http://ruedigergad.com/2012/12/09/nexus-7-easily-flashaccess-entire-userdata-partition/
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.
Hi Tasssadar,
im trying to get this to work on the HOX in order to have a shot at multiboot,
the patched applied with no problem... however on compiling i gett this error
"Adress for kexec hardboot page not defined"
ask this error naturely defined to kick in with every device beside N7 i that comment completely....
and that ended up giving me an error about KEXEC_HB_PAGE_ADDR not defined,
so i readded it, but i removed the "#if defined(CONFIG_MACH_GROUPER)"
now trying to compile it, its gets pretty close to the end... but failed with unexpected string error at line OUTPUT_ARCH(arm) in file linux/arch/arm/boot/compressed/vmlinux.lds
Code:
/*
* linux/arch/arm/boot/compressed/vmlinux.lds.in
*
* Copyright (C) 2000 Russell King
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
OUTPUT_ARCH(arm)
ENTRY(_start)
SECTIONS
{
/DISCARD/ : {
*(.ARM.exidx*)
*(.ARM.extab*)
/*
* Discard any r/w data - this produces a link error if we have any,
* which is required for PIC decompression. Local data generates
* GOTOFF relocations, which prevents it being relocated independently
* of the text/got segments.
*/
*(.data)
}
. = 0;
_text = .;
.text : {
_start = .;
*(.start)
*(.text)
*(.text.*)
*(.fixup)
*(.gnu.warning)
*(.glue_7t)
*(.glue_7)
}
.rodata : {
*(.rodata)
*(.rodata.*)
}
.piggydata : {
*(.piggydata)
}
. = ALIGN(4);
_etext = .;
.got.plt : { *(.got.plt) }
_got_start = .;
.got : { *(.got) }
_got_end = .;
_edata = .;
. = ALIGN(8);
__bss_start = .;
.bss : { *(.bss) }
_end = .;
. = ALIGN(8); /* the stack must be 64-bit aligned */
.stack : { *(.stack) }
.stab 0 : { *(.stab) }
.stabstr 0 : { *(.stabstr) }
.stab.excl 0 : { *(.stab.excl) }
.stab.exclstr 0 : { *(.stab.exclstr) }
.stab.index 0 : { *(.stab.index) }
.stab.indexstr 0 : { *(.stab.indexstr) }
.comment 0 : { *(.comment) }
}
also, im booted into windows now... so i can't provide the exact error.
I'm afraid "comment everything which doesn't work" won't work here. The KEXEC_HB_PAGE_ADDR and END_MEM is device-specific, it will most likely be different for HTC One X. You can find out what address is it supposed to be by examining /proc/iomem on your device. For example, here's memory map from grouper:
Code:
...
80000000-be9fffff : System RAM
80008000-808faba7 : Kernel text
80940000-80b8228f : Kernel data
beb00000-bebfffff : ram_console
...
So, for grouper, END_MEM is 0xbe9fffff + 1 = 0xbea00000.
KEXEC_HB_PAGE_ADDR is located 1MB before console RAM, which is in this case also immediatelly after System RAM, so for grouper, it is also 0xbea00000.
but failed with unexpected string error at line OUTPUT_ARCH(arm) in file linux/arch/arm/boot/compressed/vmlinux.lds
Click to expand...
Click to collapse
That doesn't seem to be related to this patch. Are you using correct cross-compiler?
Tasssadar said:
I'm afraid "comment everything which doesn't work" won't work here. The KEXEC_HB_PAGE_ADDR and END_MEM is device-specific, it will most likely be different for HTC One X.
Click to expand...
Click to collapse
i figured
but im walking you through what i did.
You can find out what address is it supposed to be by examining /proc/iomem on your device. For example, here's memory map from grouper:
Code:
...
80000000-be9fffff : System RAM
80008000-808faba7 : Kernel text
80940000-80b8228f : Kernel data
beb00000-bebfffff : ram_console
...
So, for grouper, END_MEM is 0xbe9fffff + 1 = 0xbea00000.
KEXEC_HB_PAGE_ADDR is located 1MB before console RAM, which is in this case also immediatelly after System RAM, so for grouper, it is also 0xbea00000.
Click to expand...
Click to collapse
Code:
7d000000-7d003fff : tegra-udc.0
7d000000-7d003fff : tegra-otg
7d000000-7d003fff : tegra-udc
7d004000-7d007fff : tegra-ehci.1
80000000-beafffff : System RAM
80008000-8094000f : Kernel text
809a8000-810b940f : Kernel data
beb00000-bebfffff : ram_console
bec00000-beffffff : fbmem
bf000000-bf7fffff : fbmem
0xbeafffff + 1 = 0xbeb00000
grrr that would put me inside the ram_console...
aaaa would it wok if i used the address before??
7d00800
Edit:
or did your ram RAM end earlier because you set you END_MEM 0xbea00000
in that case, it works out just the same with the HOX
That doesn't seem to be related to this patch. Are you using correct cross-compiler?
Click to expand...
Click to collapse
i would have guessed so, but the kernel compiled and is working before the patch.
im using the one provided by google (Android NDK r9) while it contains booth gcc 4.6/4.8 im using 4.6 (arm-linux-androideabi-)
The patch will move ram_console 1MB further, see https://gist.github.com/Tasssadar/4558647#file-n7_hardboot-diff-L387 . You'll have to modify this part of the patch, it will be in different file for your device.
Tasssadar said:
The patch will move ram_console 1MB further, see https://gist.github.com/Tasssadar/4558647#file-n7_hardboot-diff-L387 . You'll have to modify this part of the patch, it will be in different file for your device.
Click to expand...
Click to collapse
HOX is also a Tegra 3 device... so im guessing i wont need to touch a thing?
also note... that iomem provided is from an unpatched kernel (as i cant compile a patched one)
also,
im currently on freenode #htc-one-x
if you dont mind joining.
I've been looking through the kexec-hardboot patch these last few days, trying to actually understand it instead of just blindly porting it and after several hours of messing with assembler with no means to debug it, I've managed to remove the need for guest kernel to be patched. This is not really useful for grouper, since thanks to multirom and accepting kernel devs, nearly every third-party kernel has the proper patches. But, if I'll port multirom to some other device (hello, flo), it will be very useful
To know more see the changes in this commit, but you'll probably need to understand how the patch does things: https://github.com/Tasssadar/androi...mmit/2ce4130061f72430a8ddfde25346c4e528c5c30b
@mkasick: Could you please look over this? I'm afraid there's some good reason why you didn't do this in the first place, like rewriting some part of memory which shouldn't be rewritten or something like that. Thank you.
Tasssadar said:
I've been looking through the kexec-hardboot patch these last few days, trying to actually understand it instead of just blindly porting it and after several hours of messing with assembler with no means to debug it, I've managed to remove the need for guest kernel to be patched. This is not really useful for grouper, since thanks to multirom and accepting kernel devs, nearly every third-party kernel has the proper patches. But, if I'll port multirom to some other device (hello, flo), it will be very useful
To know more see the changes in this commit, but you'll probably need to understand how the patch does things: https://github.com/Tasssadar/androi...mmit/2ce4130061f72430a8ddfde25346c4e528c5c30b
@mkasick: Could you please look over this? I'm afraid there's some good reason why you didn't do this in the first place, like rewriting some part of memory which shouldn't be rewritten or something like that. Thank you.
Click to expand...
Click to collapse
Perfect timing, just finished my last exam
Edit:
Also, this applies on top of the original patch right??
Edit2:
i can't seem to get it to kexec boot, but i didn't do much testing, maybe 2morrow night!
Edit3:
fixed, it was a problem with min-addr,
changed it to 0x82000000 and it worked
One more question...
TEGRA_PMC_BASE is also device specific, ain't it???
So, for a Qualcomm device, what should I be using? I am guessing it is MSM_RPM_BASE, which I got from here: http://forum.xda-developers.com/showpost.php?p=31127486&postcount=7
Yes, it is SoC-specific. This is using some special register to reset the chip, I'm not sure if that is available on msm chips - probably yes, but in some different form. Your best chance is to examine restart sequence in arch/arm/mach-msm/restart.c and port it to assembler.
Tasssadar said:
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0xA0000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Click to expand...
Click to collapse
The address of 0xA0000000 is not necessarily the best choice going forward. It originally made perfect sense, as it is well above everything else. But now that we can boot unpatched guest kernels, we can hit the interesting situation where the guest decompression may take a full minute. At least it's when I've seen on the Ouya game console that's running the next chip after Grouper.
When I realized what's going on, I changed to 0x8E000000, as it gets me just below the 256 MB limit of cache-enabled memory that's present on a typical guest at that early decompression stage. It's enough to hold a typical 8 MB boot image kernel/ramdisk. Now the guest kernel startup is fast in all cases.
Thank you Tasssadar for continuing your work in this area, especially with finding that way to allow unpatched guests.
Indeed, that's actually what I'm using in MultiROM for flo and mako (and grouper, but it is useless 'cause not all 3rd-party kernels have been updated), I just kinda "forgot" to update these threads.
Would it work on devices with locked bootloaders (Xperias). I mean :does the idea of this patch would also work on bootloader unlock allowed :no devices?
Sent from my LT22i using xda app-developers app
I am trying to build a kexec patched kernel integrated into a ROM. I make sure that the following code is there in the defconfig:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
The ROM works well, except that it does not boot my secondary ROMs - kexec hardboot patch missing. I have multi ROM and TWRP recovery installed
What am I missing?
Logs or it didn't happen.
Show me dmesg from normal boot into android, with MultiROM and your kernel installed.
Code:
adb shell
su
dmesg > /data/local/tmp/dmesg.txt
exit
exit
adb pull /data/local/tmp/dmesg.txt
Porting?
Tassadar which things do I need to boot kexec kernel on my device (Motorola Electrify 2) .
@Tasssadar, Sorry for picking up this kinda "old topic" but I'm sadly experiencing some problems while trying to port kexec-hardboot to the Sony Xperia Z2 (aka sirius). I applyed all needed commits (cherry-picked from a apparently working Z1 repo for stock kernel) to my CM based custom kernel (https://github.com/Myself5/android_kernel_sony_msm8974/tree/kexec-cm-12.0) and it does not boot at all. It's stuck on the Sony Logo, and it seems like I can't get any log either. I also tryed the stock cm kernel with the patch (https://github.com/Myself5/android_kernel_sony_msm8974-kexec) cause I tought it might be some incompatibility, but sadly it wasn't. Hope you have any ideas to solve my problems, cause I'm out of ideas ATM. I also checked the kexec commits for other devices (namely the One Plus One) and it seems like I got everything needed.
Thanks in Advance
Tasssadar said:
In this post, I would like to explain what kexec-hardboot patch is and also bring it to light a bit more since until now, it was only burried in MultiROM thread.
@kernel developers: I would like to ask you to merge this patch to your kernels, because it is essential part of MultiROM - it allows me to boot any kernel without changing the boot partition. I realize that it is no small request, but the patch is not big, touches relatively stable parts of kernel and should not cause any problems. Thank you.
What is kexec?
It is syscall of Linux kernel, which allows you to boot another Linux kernel without restarting the device - "Linux boots itself". The functionality is equivalent to fastboot -c *cmdline* boot zImage initrd.img, but without PC and fastboot. It is fairly known thing, so more info at wikipedia and man kexec.
Standard kexec call unfortunatelly does not work on Nexus 7. It freezes somewhere, and it is very difficult to find out where - probably some of the drivers are not shut down/re-initialized properly, it is a commong thing among Android devices, which is why kexec-hardboot was made.
What is the difference between normal and hardboot exec?
Kexec-hardboot patch adds a real device restart to that process, so that all the drivers can be properly reinitialized. It stores new kernel to RAM, reboots the device as usual, and kernel from boot partition immediately jumps to the one which was stored to RAM before reboot.
Another difference is that both kernels must be patched. The "host" kernel requires a full patch, the one which is being kexecd' requires only two small compatibility patches.
To sumarize the process:
kexec --load-hardboot.... is called and kernel it loaded into RAM.
kexec -e is called. Special info is written to memory (to area which is not overwritten on reboot) and the device is rebooted.
After reboot, very early in the boot process, kernel checks if that special info is present in RAM and if so, it loads new kernel from RAM and jumps to it.
Kexecd' kernel starts and boots.
For more info, read the original thread.
Patches:
Full kernel patch: https://gist.github.com/4558647, 4.1 kernel repo, cm 10.1 kernel repo
This is the full kernel patch. Kernels with this patch can be both "host" and "guest" kernels.
Related CONFIG options:
CONFIG_KEXEC=y
CONFIG_KEXEC_HARDBOOT=y
CONFIG_ATAGS_PROC=y
CONFIG_GROUPER_HARDBOOT_RECOVERY=n
First three options must be enabled. Last one, GROUPER_HARDBOOT_RECOVERY, specifies if the kexec call should reboot to normal mode or to recovery. This can be useful if you don't have the kernel in boot partition but only as kernel in recovery partition. You usualy want to disable this option.
Compatibility patch: https://gist.github.com/4458581
This patch only makes the kernel bootable via kexec, ie. it can't be the host kernel. This was made for Ubuntu kernel (and it was accepted), because I did not want to drag the whole patch in there. If your kernel is for Android ROMs, you should use the full patch.
Userspace kexec binary: View attachment 1653562
That ZIP file contains kexec source, patches and README. It is from the original patch from Mike Kasick. It also contains precompiled, statically linked kexec binary, so you probably just want to use that.
Usage:
Once you have the kernel patches and kexec userspace binary in place, just run following command to boot into new kernel:
Code:
kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x85000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Note the command line parameter - cmdline from bootloader is not added automatically, you have to put it there by yourself.
Currently used by:
MultiROM - I use it to boot different kernels (eg. Ubuntu).
MOSLO - Part of Plasma Active for Nexus 7, also usefull tool for every N7 developer - read more: http://ruedigergad.com/2012/12/09/nexus-7-easily-flashaccess-entire-userdata-partition/
Authors:
This patch was made by Mike Kasick for Samsung Epic 4G. Since that, it was ported to several devices, one of them is Asus Transformer TF201 - I used patch from TF201 and modified it a bit (basically just changed few SoC specific constants). People at #ubuntu-arm helped me out with that, thanks.
Click to expand...
Click to collapse
I'm sorry for picking up this older topic as well, but I always played with the thought of merging kexec support into a kernel and I'm doing one right now.. But my secondary device is a LG G2 and since the era of Lollipop began, somehow MultiBoot just stopped working and nobody can figure out why. I think they even started to build some new concept now.. So before I spark a heated debated by Note 4 users I'd love to know if you have any idea if this patch is still applicable? Altough the only way to find out is to probably just try it lol.
Tasssadar said:
In this post, ....
Click to expand...
Click to collapse
Bro can you please mention on your wiki that kexec isnt supported for x64 devices? It will be great help and save developers hours! I was porting for oneplus 2 when a dev told me that kexec isnt there for x64. I was shocked
Is any alternative available for that? Please reply! Thanks.
All other devs, who cant make multirom to work (lollipop is the x64 era) stop working. Kexec isnt supported for x64. Find an alternative for it.
Can Anyone help me to port this? Here is my patched kernel (ignore arch/arm64) and this is /proc/iomem.
Code:
80000000-854fffff : System RAM
80008000-80fa43ef : Kernel code
81112000-817bf797 : Kernel data
8cb00000-9fefffff : System RAM
9ff00000-9ff3ffff : persistent_ram
9ff40000-9ff7ffff : persistent_ram
9ff80000-9fffffff : persistent_ram
a0000000-ffffefff : System RAM
For kexec_hb_page_addr the value i inseted is 85500000 coz as tasssadar said 884fffff + 1 = 85500000, but I don't know what value add for
Code:
#elif defined(CONFIG_ARCH_MSM8916)
/* Restart using the PMIC chip, see mach-msm/restart.c */
ldr r0, =MSM8916_HARDBOOT
mov r1, #0
str r1, [r0, #0]
loop: b loop
MSM8916_HARDBOOT, and if I compile the kernel it stucks on samsung logo.
Hi good people of N7 land,
I wanted to ask if it's possible to make keys get detected at boot-time so that a certain function is carried out. If so how?
For example:
The N7 is booting up. I press the Vol + key, and due to a script executed by the init.delta.rc, /system is mounted to a IMG file in the sdcard. A dual-boot mod.
I also ask if this is the best way to do this, and please for the love of God, don't point me to MultiROM. I want to work on my own mod.
I expect helpful answers. And if you can't answer my question, don't even bother posting here.
Although this is a question, this is more dev-related than anything I've encountered in the Q/A section. So I thought of posting it here.
Please move this if this is not the right place, and accept my apologies.
sgt. meow
I don't think this is possible using just some script - init has no way to get input events from keys, so you would have to either edit the init binary or use exec init command.
You could use it to run another binary, which would check if volwhatever is pressed and either did nothing or did the dual-boot stuff.
It depends on when you want to check for the keypress, because if it is after the /system partition is mounted, you could use busybox and run bash script, otherwise it would have to be real binary, because when init is started, you have pretty much "just" kernel running and no userspace.
Or you could pack busybox to boot.img, but if you can code, the binary is pretty easy to make.
@up
Exactly the kind of answer I was hoping to find. Sucks to realize that I still don't know a lot of coding. But I'm willing to learn if you could point me to the right direction.
sgt. meow said:
Hi good people of N7 land,
I wanted to ask if it's possible to make keys get detected at boot-time so that a certain function is carried out. If so how?
For example:
The N7 is booting up. I press the Vol + key, and due to a script executed by the init.delta.rc, /system is mounted to a IMG file in the sdcard. A dual-boot mod.
I also ask if this is the best way to do this, and please for the love of God, don't point me to MultiROM. I want to work on my own mod.
I expect helpful answers. And if you can't answer my question, don't even bother posting here.
Although this is a question, this is more dev-related than anything I've encountered in the Q/A section. So I thought of posting it here.
Please move this if this is not the right place, and accept my apologies.
sgt. meow
Click to expand...
Click to collapse
The first idea that comes to my mind would be to code a simple no-UI app which would use a Service executed by a BroadCastReceiver set to BOOT_COMPLETED.
Then, when triggered (=at boot-time), the service would wait for the user to press a defined key (i.e : volume up). When the service receives the key press, it would mount /system or whatever you wanna do, then stop running (so that other volume up presses don't trigger this event again).
The code could be something like :
Your AndroidManifest.xml :
Code:
< ?xml version="1.0" encoding="utf-8"?>
< manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.sgtmeow.boot.service"
android:versionCode="1"
android:versionName="1.0">
< uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED" />
< application android:icon="@drawable/icon" android:label="@string/app_name">
< service android:name=".BootService">
< intent-filter>
< action
android:name = "com.sgtmeow.boot.service.BootService">
< /action>
< /intent-filter>
< /service>
< receiver android:name=".BootReceiver">
< intent-filter>
< action
android:name ="android.intent.action.BOOT_COMPLETED">
< /action>
< /intent-filter>
< /receiver>
< /application>
< uses-sdk android:minSdkVersion="8"
android:targetSdkVersion="17"android:targetSdkVersion="17" />
< /manifest>
BootReceiver.java :
Code:
package com.sgtmeow.boot.service;
import android.content.BroadcastReceiver;
import android.content.Context;
import android.content.Intent;
public class BootDemoReceiver extends BroadcastReceiver {
@Override
public void onReceive(final Context context, final Intent bootintent) {
Intent mServiceIntent = new Intent();
mServiceIntent.setAction("com.sgtmeow.boot.service.BootService");
context.startService(mServiceIntent);
}
}
BootService.java
Code:
package com.sgtmeow.boot.service;
import java.io.DataOutputStream;
import android.app.Service;
import android.content.Intent;
import android.os.IBinder;
import android.util.Log;
import android.view.KeyEvent;
import com.sgtmeow.boot.service.BootReceiver;
public class BootService extends Service {
Runtime mRuntime;
Process mProcess = null;
DataOutputStream mOutput = null;
@Override
public IBinder onBind(final Intent intent) {
return null;
}
@Override
public void onCreate() {
super.onCreate();
}
public boolean onKeyDown(int keyCode, KeyEvent event) {
super.onKeyDown(keyCode, event);
if (keyCode == KeyEvent.KEYCODE_VOLUME_UP) {
mountSystem();
Log.w("SGT.MEOW", "Volume Up has been pressed");
return true;
}
return true;
}
public void onStartCommand(final Intent intent, final int startId) {
super.onStartCommand(intent, startId, startId);
mountSystem();
}
private void mountSystem() {
Runtime.getRuntime();
// The service is now started, ask for root and mount /system using
// busybox (or not)
try {
mProcess = mRuntime.exec("su");
mOutput = new DataOutputStream(mProcess.getOutputStream());
mOutput.writeBytes("busybox mount -o remount,rw /system");
mOutput.flush();
stopService(new Intent(BootService.this, BootReceiver.class));
} catch (Exception e) {
Log.e("SGT.MEOW", "An Error Has Occured", e);
e.printStackTrace();
}
}
}
EDIT : unfortunately after some research I found out that Services cannot act as an onKeyListener, you'll have to call an activity to actually listen to the keypress so maybe just a dialog or something, but you won't be able to do it completely UI-less this way, my bad.
This is not something i would attempt to if you dont know what your doing due to the chance of bricks. but your best bet would be to luanch a binary from early init in the ram disk
aaronpoweruser said:
This is not something i would attempt to if you dont know what your doing due to the chance of bricks. but your best bet would be to luanch a binary from early init in the ram disk
Click to expand...
Click to collapse
I know how to launch the binary during init. The binary is the problem I am running into.
Thanks though.
You might want to take a look at how custom recoveries on the Xperia T handles the initial recovery vs. boot selection. On that device, there is no recovery partition, so a single kernel image must support both recovery and normal operation. The bootloader doesn't support an "enter recovery" poweron keycombo, so on the T there are some tricks so that at boot, it:
Sets the LED to purple
Waits 3 seconds or so
If the VolUp key is pressed during those 3 seconds, boot to recovery
Otherwise, boot normally
I believe the same approach is also used on the Xperia Z.
Maybe you could have a custom recovery that allows this? TWRP and CWM Touch both have source code available that you can check out so you can make your own recovery, which could allow booting of separate ROMS. Recoveries generally boot faster than full ROMs.
That's not what I was aiming to achieve. If I can manage to map the keys and find a way to detect them at boot-time, the rest is easy as pie. . Thanks though.
Entropy512 said:
You might want to take a look at how custom recoveries on the Xperia T handles the initial recovery vs. boot selection. On that device, there is no recovery partition, so a single kernel image must support both recovery and normal operation. The bootloader doesn't support an "enter recovery" poweron keycombo, so on the T there are some tricks so that at boot, it:
Sets the LED to purple
Waits 3 seconds or so
If the VolUp key is pressed during those 3 seconds, boot to recovery
Otherwise, boot normally
I believe the same approach is also used on the Xperia Z.
Click to expand...
Click to collapse
sgt. meow said:
That's not what I was aiming to achieve. If I can manage to map the keys and find a way to detect them at boot-time, the rest is easy as pie. . Thanks though.
Click to expand...
Click to collapse
None of the phones made by Sony have a recovery partition so they have to use a work around to detect keys on boot up. This is what all Xperia devices do to get into recovery: on boot check to see if the desired key is being pressed and if it is unzip the recovery, if it isn't being pressed unzip the normal ramdisk. (I'll post the ramdisk here for you to see how everything works yourself) So with the Xperia Play CyanogenMod kernel that I have how it works is it has two .cpio files. One for the ramdisk and one for the recovery. It uses a .sh file in the sbin to check if keys are being pressed by using /dev/input/event# which in most cases is event1 for volume down (on Nexus 7 the is event0, event1, and event2. My guess is 0 = power button and one and two are vol + and vol -). It then has a link to the init.sh in the root of the ramdisk called init so that when the kernel starts and calls init it starts the script. So what you could do is the same but instead of having two .cpio files you could rename the init file to something else then place the script and link in your ramdisk so that when the key is pressed it calls both what you want to do and the rename init executable. (Not sure how well this would work this is just an idea, if not depending on what you want to do you can keep the compressed ramdisk idea...)
Here is a ramdisk of what I've been talking about that is pulled from my kernel (extracted from an already compiled kernel to make it easy read.):
Link
It's made for the Xperia Play so it also tries to start the LED and vibrator to tell you when to click the Vol - key so how you would tell people to click it on the Nexus 7 I'm not sure...probably just have to have people will just have to spam the key. If you have any questions feel free to ask or if this didn't help I'm sorry just an idea.
Also what it seems like you want to do with the dual boot mod being with the SDCard sounds a lot like what a guy named CosmicDan did on the Xperia Play. You had to change the updater-script in your flashable zip but it worked. Here is the thread: Turbo Kernel and the source code to his kernel: GitHub
I know what he did with his kernel. I am working on something similar to the HD2 dual boot method. Haven't had any success yet.
Sent from my Nexus 7 using xda app-developers app
sgt. meow said:
I know what he did with his kernel. I am working on something similar to the HD2 dual boot method. Haven't had any success yet.
Sent from my Nexus 7 using xda app-developers app
Click to expand...
Click to collapse
hi! were you able to solve this?
thanks!
I was wondering if maybe someone here can maybe help me out with this. ive been working on it on and off for about 8 months now.
I am The lead developer for Team Osiris.
currently, still finishing up cm10 for the Zte warp.
Which is MSM8655 / MSM7X30 based
512mb ram
the problem iam having is with the 3.0.8 kernel iam developing.
we took the kernel source for the warp sequent. and modified it, and got it to boot on the warp.
we were using a moddified board-msm-7x30, but i recently made a new board file from scratch based on a Code Aurora generic board-msm-7x30.
i reworked the entire board, added and removed what needed to be done.
then i get to the real issue ive been trying to solve forever.
it seems no matter what i do. the system only sees 116mb ram. i know some is reserved for the os and what not. so i know thats not the issue.
on stock gb we had 512 physical, with 378 free.
this very same problem was also encounterd and fixed when we started cm10 using the 2.6.35.7 source for the phone.
that one turned out that memory4 was not online.. simple fix.
ive tried that on the 3x kernel with no luck.
memory4 doesnt even exist.
only memory0. using either board file.
Here is a snipet of the code iam trying to get memory online in the board.
Code:
// MEMBANKS
#define DDR_BANK1 0X20000000
#define DDR_BANK1_SIZE 0x00000100
#define DDR_BANK2 0X40000000
#define DDR_BANK2_SIZE 0x00000100
/// DO AWAY WITH ZTE FIXUP, IN FAVOR OF MSM7X30_FIXUP
static void __init msm7x30_fixup(struct machine_desc *desc,
struct tag *tags,
char **cmdline,
struct meminfo *mi)
{
mi->bank[0].start = DDR_BANK1 + PHYS_OFFSET;
mi->bank[0].size = DDR_BANK1_SIZE;
mi->bank[1].start = DDR_BANK2;
mi->bank[1].size = DDR_BANK2_SIZE;
return ;
}
static void __init msm7x30_init_early(void)
{
msm7x30_allocate_memory_regions();
}
again, the hex values may not be right.
ive done my research and iam kind of at a loss right now. in 2.6 it seems everything was in ebi0
and also with 8655 cpus everything is in ebi0.
ive tried other memory layouts from phones with the same hardware. no luck..
any help or direction would be appreciated
If you wish to request omni forks a repository from AOSP, in order to implement a patch into omni, please post this request here. Eventually this will be carried out via jira (http://jira.omnirom.org)
When posting, please give the path to the repository, and a link to what you want to merge, or a description.
For example if you wish to cherry pick a patch into it, a link to the patch and brief description of the reason for the patch.
We'll then have that repository forked and made available on github and gerrit, permitting you to submit your change.
Before you request, please check on github to ensure it isn't already forked!
For example :
frameworks/base - Needing forked so I can introduce multi window functionality (link here to information)
hardware/broadcom/libbt - Mainly for board-specific configurations (link), but newer CM commits also look promising.
If new device bringups aren't planned yet, ignore the followings:
device/lge/p880 and kernel/lge/p880 - Device bringup (kernel has a non-standard naming at CM repo, it should be android_kernel_lge_x3 (x3 is the board name))
vendor/lge (maybe Omni should create one from scratch)
Adam77Root said:
hardware/broadcom/libbt - Mainly for board-specific configurations (link), but newer CM commits also look promising.
If new device bringups aren't planned yet, ignore the followings:
device/lge/p880 and kernel/lge/p880 - Device bringup (kernel has a non-standard naming at CM repo, it should be android_kernel_lge_x3 (x3 is the board name))
vendor/lge (maybe Omni should create one from scratch)
Click to expand...
Click to collapse
We do have a vendor/lge with just mako, although I'm not sure if its current location.
Vendor blob repos are a legal mess, which is why CM kept them at TheMuppets. We'll likely do something similar if we haven't already (I haven't synced since coming home.) Among other reasons to keep them separate is in the case of a DMCA takedown - usually that happens only to a single repo (see the HTC vendor repos earlier this year) but there's always the risk that damage might be more widespread.
android_external_clang
http://review.cyanogenmod.org/#/c/29799/2
Needed for building my msm8960 device (Motorola Photon Q, xt897c).
arrrghhh said:
android_external_clang
http://review.cyanogenmod.org/#/c/29799/2
Needed for building my msm8960 device (Motorola Photon Q, xt897c).
Click to expand...
Click to collapse
CM bootable recovery and some commits over system core
Black_Prince said:
CM bootable recovery and some commits over system core
Click to expand...
Click to collapse
No for CWM - We're working on forking TWRP in, but some fixes still need to be made to allow it to work on devices with unified recovery/boot image. (Probably one of the biggest holdups for the exynos 4210 family - Sonys with unified boot/recovery can at least use Dees_Troy's FOTAKernel trick).
Getting CWM to build in a tree requires hacks all over the tree in multiple repositories. TWRP is much more self-contained, but needs some tweaks to the build system in order to get it to build properly on a userdebug (as opposed to eng) build.
Entropy512 said:
No for CWM - We're working on forking TWRP in, but some fixes still need to be made to allow it to work on devices with unified recovery/boot image. (Probably one of the biggest holdups for the exynos 4210 family - Sonys with unified boot/recovery can at least use Dees_Troy's FOTAKernel trick).
Getting CWM to build in a tree requires hacks all over the tree in multiple repositories. TWRP is much more self-contained, but needs some tweaks to the build system in order to get it to build properly on a userdebug (as opposed to eng) build.
Click to expand...
Click to collapse
Hmm but until the twrp is ported should i test build for some galaxy devices like SG S2 note 1 with cwm ?
It will make me to push changes to git in device tree ... and will be easy to add support
Black_Prince said:
Hmm but until the twrp is ported should i test build for some galaxy devices like SG S2 note 1 with cwm ?
It will make me to push changes to git in device tree ... and will be easy to add support
Click to expand...
Click to collapse
I'll pull up a remote to use for bootable/recovery until we fork (unless plodey already forked it) from TWRP, won't be able to provide it until tonight.
However, right now, it will only build a working recovery if you do an eng build instead of userdebug. If Dees_Troy's talk at BABBQ is ever posted, that's what I was talking about when I trolled him at the end.
Something like:
Code:
. build/envsetup.sh && brunch custom_n7000-eng
or something like that.
Old
def WriteRawImage(self, mount_point, fn):
"""Write the given package file into the partition for the given
mount point."""
fstab = self.info["fstab"]
if fstab:
p = fstab[mount_point]
partition_type = common.PARTITION_TYPES[p.fs_type]
args = {'device': p.device, 'fn': fn}
if partition_type == "MTD":
self.script.append(
'write_raw_image(package_extract_file("%(fn)s"), "%(device)s");'
% args)
elif partition_type == "EMMC":
self.script.append(
'package_extract_file("%(fn)s", "%(device)s");' % args)
Requested
def WriteRawImage(self, mount_point, fn):
"""Write the given package file into the partition for the given
mount point."""
fstab = self.info["fstab"]
if fstab:
p = fstab[mount_point]
partition_type = common.PARTITION_TYPES[p.fs_type]
args = {'device': p.device, 'fn': fn}
if partition_type == "MTD":
self.script.append(
'package_extract_file("%(fn)s", "/tmp/boot.img");'
'write_raw_image("/tmp/boot.img", "%(device)s");' % args
% args)
elif partition_type == "EMMC":
self.script.append(
'package_extract_file("%(fn)s", "%(device)s");' % args)
elif partition_type == "BML":
self.script.append(
('assert(package_extract_file("%(fn)s", "/tmp/%(device)s.img"),\n'
' write_raw_image("/tmp/%(device)s.img", "%(device)s"),\n'
' delete("/tmp/%(device)s.img"));') % args)
else:
raise ValueError("don't know how to write \"%s\" partitions" % (p.fs_type,))
Flash error in write raw image ...
Also can u cherry pick these commits https://github.com/CyanogenMod/android_system_core/commits/cm-10.2/mkbootimg/unpackbootimg.c
My internal SD card isnt got recognsied , there must be some commits missing in vold ...
I dont even know it got formatted or what in flashing ...
All things working WIFI BLUTOOTH TETHERING CALL DATA MSG MMS OMNITORCH
Also u may have look over https://github.com/CyanogenMod/andr...mmit/f22626cdbecfe27c96f205710173458eab14e1a1
and https://github.com/CyanogenMod/andr...mmit/aee5f78ddec238cec016849acaf1d3007b8b1507
https://android.googlesource.com/platform/hardware/broadcom/libbt
Must haz patch:
https://github.com/CyanogenMod/andr...mmit/4028192a4fe8289bf9b7fb202a2bb2c0d85d98c3
//edit: xplod sorted it out already.
android_packages_apps_PackageInstaller
For
HALO and a feat which enables us to see version of the installed and gonna install app
I need this to make it work with my Samsung galaxy s4
I'm not sure if this is the correct thread, but the following two would be great for i9305 support
smdk4412-qcom-common -> needed for i9305 and t0lte (EDIT: I see this one has now been added)
Thanks!
Hey @pulser_g2,
wondering if i could have the following repositories added in for jf devices,
all features are fully functional with these repositories : branch: cm-10.2 for all
device_samsung_jf-common
android_device_samsung_jflteatt
android_kernel_samsung_jf
CyanogenMod/android_hardware_samsung
CyanogenMod/android_device_samsung_msm8960-common
CyanogenMod/android_device_samsung_qcom-common
@pulser_g2
I just talked to @maxwen and he told me i should post here the needed stuff:
I managed to fix the radio issues today on m7, but i need additionally these commits:
https://github.com/TheMuppets/proprietary_vendor_htc/commit/7bbbe83823525090e7d94c47b439c09a254b380f
https://github.com/TheMuppets/proprietary_vendor_htc/commit/19ed957678d13b489da78d704b27811030688078
https://github.com/TheMuppets/proprietary_vendor_htc/commit/51b006bc8f05757c7dd82361ce6d985e996af360
and please DO NOT merge this: https://github.com/TheMuppets/proprietary_vendor_htc/commit/2b86687a460030199fa42d49207957ce285c1a53
as its not needed and breaks build (I allready have everything in m7-common so no need for vendor)
Thanks in advance
@pulser_g2
we dont need to update anything, please forget my post above, i managed to get it working without all these commits and the right vendor
hardware/qcom/gps - Needing forked so I can build the needed GPS module into my Omnirom build.
The link to this repository is: https://github.com/CyanogenMod/android_hardware_qcom_gps/tree/cm-10.2
I hope it gets included, this saves me a ton of time pulling stuff from other repositories.
Greetings PsychoGame
Galaxy S I9000 (galaxysmtd)
@pulser_g2 Device repos are already forked. Kernel is missing: https://github.com/OmniGalaxyS/android_kernel_samsung_aries
It has android-4.3 and android-4.4 branches up.
Device rocking with Omni!
See you!
Fail
PsychoGame said:
hardware/qcom/gps - Needing forked so I can build the needed GPS module into my Omnirom build.
The link to this repository is: https://github.com/CyanogenMod/android_hardware_qcom_gps/tree/cm-10.2
I hope it gets included, this saves me a ton of time pulling stuff from other repositories.
Greetings PsychoGame
Click to expand...
Click to collapse
I also need android_hardware_qcom_gps (probably best from https://github.com/markcs/android_hardware_qcom_gps/tree/cm-11.0)
I get a lot of question that my custom kernel breaks support their own AOSP-based ROMs.
So I'm here to how to fix that from your side.
The culprit is CyanogenMod's /init.environ.rc.
CM has been messing around that in recent months.
Changing BOOTCLASSPATH does not break cross-compatibility between different AOSP forks, as long as they don't remove stuffs and just adds stuff.
The problem is SYSTEMSERVERCLASSPATH. If any new stuffs are added, Android RunTime will just abort itself and refuse to boot.
And recently, CyanogenMod added Cyanogen Platform API.
That additionally adds /system/framework/org.cyanogenmod.platform.jar to the /init.environ.rc's SYSTEMSERVERCLASSPATH.
That breaks other AOSP-forks that doesn't use Cyanogen Platform API.
So those ROM developers have 3 options.
They can..
1. Just go and use Cyanogen Platform API. Undoubtedly, this would be super hard if your ROM is not already based on CyanogenMod.
2. Ask custom kernel developers to release a separate version just for your ROM. Very unlikely.
3. Solution below.
Most elegant solution I ended up so far is patch your Android RunTime(android_art) to just bypass extra SYSTEMSERVERCLASSPATH.
Just go to art/runtime/native/dalvik_system_DexFile.cc.
Around line 380..
Code:
diff --git a/runtime/native/dalvik_system_DexFile.cc b/runtime/native/dalvik_system_DexFile.cc
index 3298b46..50aa44c 100644
--- a/runtime/native/dalvik_system_DexFile.cc
+++ b/runtime/native/dalvik_system_DexFile.cc
@@ -382,14 +382,6 @@ static jbyte IsDexOptNeededInternal(JNIEnv* env, const char* filename,
// Logging of reason for returning kDexoptNeeded or kPatchoatNeeded.
const bool kReasonLogging = true;
- if ((filename == nullptr) || !OS::FileExists(filename)) {
- LOG(ERROR) << "DexFile_isDexOptNeeded file '" << filename << "' does not exist";
- ScopedLocalRef<jclass> fnfe(env, env->FindClass("java/io/FileNotFoundException"));
- const char* message = (filename == nullptr) ? "<empty file name>" : filename;
- env->ThrowNew(fnfe.get(), message);
- return kUpToDate;
- }
-
// Always treat elements of the bootclasspath as up-to-date. The
// fact that code is running at all means that this should be true.
Runtime* runtime = Runtime::Current();
Remove those 7 lines and your ROM will be now compatible with custom kernels targeting CyanogenMod.
(Git style patch is added for 'git am' command. I'd appreciate it if you maintain Git repository, apply that Git patch for authorship.)
The only problem so far would be that this will break compatibility with Xposed, which replaces Android RunTime thus reverting this modification.