From the look of it the note 2 has multirom support. Maybe they can help out with development.
MultiRoms kexec is built into the kernel which is custom. so u need an unlocked bootloader for thier version of kexec to workFrom the look of it the note 2 has multirom support. Maybe they can help out with development.
What about a Ubuntu convert? Would this make it possible
Let's wait for Ubuntu on phones to check if we could run it on locked devices!If it can Debian you can probably switch repos and mint or Ubuntu or whatever, but we're way getting ahead of ourselves.
Our NC2 kernel has Permissive SELinux by default & we can set it on NC4 using this init.d script.I know this is very basic but there is no mention of it here, but I assume that you got SE to permissive before trying to get the kexec module to run..
here's a link in the very unlikely case that you missed that..
thread by walter.white
The last time I tested my kexec, I had the same problem. However, you on T-Mobile have better options. Could you share more details about the configurations of your host & guest kernels?! Since you've unlocked bootloader, I think you may build a custom host & guest kernels with proper kexec implementations./patches. On Verizon, the bootloader is locked & we're trying to find a workaround for kexec to work on the stock kernel(s).So last I heard everyone was getting stuck when attempting to boot the new kernel out of kexec. Any updates on this front? That is where I got stuck with kexec-hardboot as well and I'm stumped as to where to go from here.
I'll look into your sources & let you know if I've any comments/suggestions.Here is my latest code. I applied the hardboot patches which should work on unlocked bootloader. I'm using the same kernel as both host and guest, though with different initramfs.
https://github.com/CalcProgrammer1/android_kernel_samsung_hlte/tree/kexec_hardboot_test1
Sure, that'd be a very useful tool for debugging. Let me know how it goes!I just found this:
http://www.de7ec7ed.com/2013/09/uart-dongle-samsung-galaxy-siii.html
The Note 3 may have a serial port (UART) hidden in the USB connector. If true (which I've heard mention of in other threads) this could mean a console to see kernel boot messages on. I have a sacrificial USB cord somewhere, might give it a go soon by splicing in the value of resistor necessary and scoping the line for serial comms on my oscilloscope. If successful and the voltage levels are usable with the 3.3V USB serial adapter I have I will hook it up and see if I get kernel messages. If so, this will be an invaluable tool to see if the kexec guest kernel is booting.
great job!! now fingers cross!!!Serial port works! I got a nice serial console that even shows bootloader messages before booting. Now we should be able to debug kernel boot-up easier.
You almost have me a heart attack lol! Keep up the good workSerial port works! I got a nice serial console that even shows bootloader messages before booting. Now we should be able to debug kernel boot-up easier.
I'm hoping that this research can help out on the VZW S4 side of things as well. As I own both the N3 and S4 it would be awesome to at least have KEXEC on them. Thanks everyone for the awesome work!Serial port works! I got a nice serial console that even shows bootloader messages before booting. Now we should be able to debug kernel boot-up easier.
It appears this "secret" serial port is present on all recent Galaxy devices. I found the guide which demonstrates it on the S3, heard about the possibility of the serial port reading a kexec thread in the S4 forum, tested it on my Note 3, and now I've gone back and plugged it into my Note 1 SGH-i717 just to see if it works and it did as well. So at least the Note 1 and everything since has it.I'm hoping that this research can help out on the VZW S4 side of things as well. As I own both the N3 and S4 it would be awesome to at least have KEXEC on them. Thanks everyone for the awesome work!![]()
Excelent :good: We may need to clean up the standard output/error if it has any pattern & even if the bootloader --or the host kernel?!-- overwrites the memory, it'd be great to know how it runs for debugging & finding a solution/workaround. It might be a series of patches for the host kernel/kexec-mod to fix booting the guest kernel step by step.Serial port works! I got a nice serial console that even shows bootloader messages before booting. Now we should be able to debug kernel boot-up easier.It appears this "secret" serial port is present on all recent Galaxy devices. I found the guide which demonstrates it on the S3, heard about the possibility of the serial port reading a kexec thread in the S4 forum, tested it on my Note 3, and now I've gone back and plugged it into my Note 1 SGH-i717 just to see if it works and it did as well. So at least the Note 1 and everything since has it.Ok, I got the hardware serial console hooked into my kexecboot initramfs so it opens a terminal on boot. Since my initramfs is very simple and limited there should be no other interference besides the kernel. I then used viewmem to record the first 256MB of RAM which I'm going to dig through now to see if there's an opening to put the kernel in. Apparently the kernel should be within the first 128MB of RAM according to some documentation I read online which may be an issue as the bootloader seems to write stuff there.
Also, whoever wrote the Android/CM kernel needs to learn how to clean up their debug messages. This is asinine how much utter garbage spam it spams out every few seconds. If it ain't upstream-quality it ain't release quality people!
I'm going to go back and try to figure out why normal non-hardboot kexec isn't working. If the bootloader is erasing memory hardboot may not be a good option. I was having an issue rebooting before and I'm not sure why.Excelent :good: We may need to clean up the standard output/error if it has any pattern & even if the bootloader --or the host kernel?!-- overwrites the memory, it'd be great to know how it runs for debugging & finding a solution/workaround. It might be a series of patches for the host kernel/kexec-mod to fix booting the guest kernel step by step.
On the other hand, I've looked into your kernel source & it seems pretty standard. I guess you could make use of the unlocked bootloader to tune the host kernel according to the output from your new debugging toolLet me know if you'd like to discuss any of the outputs, or shoot me a log to add my input on your case, if any. I feel that any progress will reflect on all devices, including the locked ones.
Good luck![]()