yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S 4] :
I believe you will figure out all the hang ups here soon. You are working pretty quickly now on getting thing moving forward. We are alot closer now than we were just a month ago. Keep up the good work.
[Verizon Samsung Galaxy S 4] Surge1223:
So ive re-enabled module loading in the ramdisk, and we're about at the same point Hash was, so everything from here on out is uncharted territory unless theres other arm devices with a non hardboot kexec implementation.

P.s. i know the atags address is wrong, and thats something we'll have to deal with in the future, not sure how to get atags but were not there yet either..
[Verizon Samsung Galaxy S 4] DX.Deception:
So how much of a good thing is this? Lol
[Verizon Samsung Galaxy S 4] Walter.White:
Found something that might help you.

This is how they got kexec working on Samsung Epic 4G. http://xdaforums.com/showthread.php?t=1266827

And based on the above, they also got it working on S3. http://www.epiccm.org/2012/07/kexec-and-proof-of-concept-source-built.html

Also here is someone trying to get it working on Note 8.0 http://xdaforums.com/showthread.php?t=2558903

MultiROM (Kexec for International S4, Look at the Step 3/where it talks about Patched kernel) http://www.droidviews.com/enjoy-multirom-samsung-galaxy-s4-gt-i9505/, http://xdaforums.com/galaxy-s4/i950...ltirom-v28-t2864469/post55177853#post55177853

LG G2 Patch https://gist.github.com/PatrikKT/50faf32e8931d51c0c9a

Note 3 WIP http://xdaforums.com/note-3-tmobile/orig-development/dev-wip-kexecboot-bootloader-galaxy-t2864109
[Verizon Samsung Galaxy S 4] sokrboot:
[MENTION=4939386]Surge1223[/MENTION] could the kexec callback issues be related to this...

https://www.mail-archive.com/kexec@lists.infradead.org/msg11464.html

Commit 4362bfaca4d8d2a4380532880f0d08c2bf14184e changed

kexec_iomem_for_each_line() to pass 'base' and 'length' parameters of

the callback function as unsigned long long integers instead of unsigned

longs. Some of the functions were not updated. This patch corrects the

remaining instances.
[Verizon Samsung Galaxy S 4] waiters:
Not sure what's really going on here since it's way over my head but recently went through finances and decided I'm not getting a new phone for a while. So thank you for still working at unlocking this thing!! I'll probably have it a long time lol
[Verizon Samsung Galaxy S 4] ryanbg:
Unfortunately, most retail kernels are compiled (for VZW/ATT) without kernel module loading support. So inherently, it won't ever work, however I'm sure it's possible although incredibly difficult to get around. If you have ATT N3 with root, however, I might have a possible exploit/hack put together to enable Permissive mode on ATT kernels. Someone with an ATT device contact me and we'll try.
[Verizon Samsung Galaxy S 4] Walter.White:
http://xdaforums.com/note-3-att/development/change-selinux-status-to-permissive-t2899648 :)
[Verizon Samsung Galaxy S 4] clothednblack:
I would be willing to try, I tried Walters but it didn't work for me and several others.
[Verizon Samsung Galaxy S 4] MorrisC2010:
Usually located at 0x100 from the beginning of memory. But is more likely to be stored into the machine record structure. When the kernel boots, it looks up into a table of all the machine records that have been compiled into the kernel for the one that corresponds with the machine ID passed into r1. That lookup is performed in the very early boot stage from assembly code.

Unless we have the new DT standard, which I'm unsure of but highly doubt.
[Verizon Samsung Galaxy S 4] sokrboot:
So here are a few things I've run across repeatedly as I have been doing more research on why our kexec hangs...

1. Poor Handling of unsigned long longs. See one example -> http://xdaforums.com/showpost.php?p=40415281&postcount=91

2. Jumping addresses into/out of the first 128MB of memory. i.e. stock kernel resides IN this region and we are pointing to values OUTSIDE of that region.

3. Taking non-boot CPUs offline then back online (various issues like doing either too early, too late, using Machine_kexec instead of kexec "poke")

Yes I am throwing stuff against the wall to see if it sticks. I'm trying to teach myself what we are doing and also trying to be helpful in the process
[Verizon Samsung Galaxy S 4] Walter.White:
[MENTION=4939386]Surge1223[/MENTION]

Is this what you were talking about? (to enable kernel module support on ATT N3)

https://en.wikipedia.org/wiki/Kinsmod

http://www.frameip.com/firewall/kinsmod.php

http://s8.invisionfree.com/QHSOFT_SECURITY/ar/t14.htm
[Verizon Samsung Galaxy S 4] Surge1223:
Ive gotten to a part where kexec hangs and i believe it has to do with wrong machine code being used (relocate_kernel.S) seems that i wont be able to get any more debug log output without a serial connection to the phone (luckily thanks to Hash's code implementation we have it reporting output via serial console) so ill have to set up a serial console (a trip to radioshack) or one of you who has serial ability can get me output after i send you the kexec enabled Safestrap and current kexec module build.

Thanks, i love the mindset that's how i learned things too. Will look into whether those effect us or not.
[Verizon Samsung Galaxy S 4] clothednblack:
Hate to QUOTE myself but the permissive issue has been solved, just needed SuperSU version 2.13 to make it work. Thanks to all those that helped.
[Verizon Samsung Galaxy S 4] sokrboot:
This page seems to have some relevant info, especially the bit at the end that let them write to read only memory

https://gist.github.com/Tasssadar/7833796

This is for a device which "uses device tree binary instead of atags". And also "its bootloader erases first 128MB of RAM on reboot", so following hacks had

to be applied:

* Copy dtb to location passed in r2 before jumping to kexecd' kernel,

the kernel would just freeze when I left dtb above 128MB of RAM.

* Copy kexecd' kernel to location in the first 128MB before jumping to it, the decompressor operates very slowly if the kernel is above the cached area, copying it lower and decompressing it afterwards is much faster.

Same as my mako/flo patches, the guest kernel does not require any

modifications, kexec-hardboot is equivalent to standard kexec.

To support dtb, following commit was backported from the mainline:

commit 4cabd1d9625c7d88acd143f4021fbef75394f154

Author: Matthew Leach

Date: Fri Sep 21 18:56:02 2012 +0100

ARM: 7539/1: kexec: scan for dtb magic in segments

This patch allows a dtb to be passed to a new kernel using the kexec mechinism.

When loading segments from userspace, scan each segment's first four

bytes for the dtb magic. If this is found set the kexec_boot_atags

parameter to the relocate_kernel code to the phyical address of this

segment.

and fixes of this commit:

c564df4db85aac8d1d65a56176a0a25f46138064

2456f44dd7a9aaffc2cd21a13f78198b3d94da08

ayysir :

kexec: use mem_text_write_kernel_word to set reboot_code_buffer args

in order to avoid protection faults (writes to read-only

kernel memory) when CONFIG_STRICT_MEMORY_RWX is enabled.
[Verizon Samsung Galaxy S 4] CalcProgrammer1:
Does the Note 3 have a serial port? I think I'm stuck at the same spot as you on my kexec-hardboot implementation. I tried both hardbooting and normal kexec and it hangs on both. I enabled RAM console, but to no avail, nothing showed up other than the previous kexec host kernel's log. If it has a hardware serial port that will allow us to see the early boot messages and be super helpful, but I don't feel like tearing mine apart to access the serial port. If it's one of those that has the serial port pinned out on the headphone jack I could be debugging it right now as I have all the components to level shift and build an adapter.
[Verizon Samsung Galaxy S 4] Surge1223:
Edit: Also I've started a twitter campaign against Verizon lol. But more importantly I'm going to swallow my pride and seek out help from the photon and xperia devs, maybe see if jonpry will help too, he was able to help hash extensively in the past.

Not sure, I think you're having more luck than me with the hardboot implementation, maybe sometime this week we both upload our latest sources (mine have significantly changed since I first posted) and we can see how each other implemented code? About serial connection I'm not sure im not really a hardware guy [MENTION=766721]ryanbg[/MENTION] might know for sure (I was going to have him help me set up serial connection for the s4 anyways as I think he's done it before).
[Verizon Samsung Galaxy S 4] gsciullo17:
I don't know if this helps at all but it seems like someone figured out how to get rom slots working on safestrap v3.75. The post is located here: http://xdaforums.com/showpost.php?p=56030788&postcount=2281 Hopefully this leads to something. I know this was an issue trying to be fixed by some developers on here.
[Verizon Samsung Galaxy S 4] muniz_ri:
Thx for sharing but the issue preventing rom slots was not related to the bootloader unlock.
[Verizon Samsung Galaxy S 4] gsciullo:
Yes I know that. I posted this for the sake of the developers working on kexec. Not the actual boot loader unlock.
[Verizon Samsung Galaxy S 4] scryan:
Its reasonably unrelated to that too, other then the fact that hopefully kexec can be added to safestrap once it is working.

But oh well, better people post stuff that doesn't help rather than hold back something that does...
[Verizon Samsung Galaxy S 4] munjeni:
I have some problems in kexec loadable module on locked bootloader (its working when hard boot kexec is built inside kernel, but not working when it is compiled as an external module, I have no idea why:(), maybe somebody help us or found something usefull from my implementation here -> http://xdaforums.com/showpost.php?p=55670702&postcount=222
[Verizon Samsung Galaxy S 4] Surge1223:
Hey good work so far mate, I'm looking over your code, I don't want you to think we're ignoring you, and I see you guys have made some amazing progress over in the xperia forums.
[Verizon Samsung Galaxy S 4] CalcProgrammer1:
Here is my code if you want to take a look. I had to comment a few shutdown things out because they were crashing the shutdown process and preventing kexec from happening. I also added RAM console.

Edit: The code...

https://github.com/CalcProgrammer1/android_kernel_samsung_hlte/tree/kexec_hardboot_test1
[Verizon Samsung Galaxy S 4] munjeni:
S4 uses atags or dtb? If atags, this one will work for you I am sure -> https://github.com/munjeni/android_kernel_xperiago/commit/7d504cd6135666a4dace273e402560c79402e073 after that look into other commits from here -> https://github.com/munjeni/android_kernel_xperiago/commits/jb-dev?page=2
[Verizon Samsung Galaxy S 4] CalcProgrammer1:
I think I may have found info on the potential serial port. Apparently on some Galaxy devices there is a UART available on the USB connector if you use a special cable.

http://www.de7ec7ed.com/2013/09/uart-dongle-samsung-galaxy-siii.html

I don't know if the Note 3 has this but I want to give it a try, just have to find a spare USB cable I don't mind sacrificing. If this is true and there is a UART, it will be absolutely invaluable to getting kexec to work as it means early kernel messages can be seen! Going to post this in hsbadr's thread as well.
[Verizon Samsung Galaxy S 4] Surge1223:
I'm going to be trying this but something tells me [MENTION=766721]ryanbg[/MENTION] already has...
[Verizon Samsung Galaxy S 4] Walter.White:
Or you can do what [MENTION=4939386]Surge1223[/MENTION] pointed out here http://xdaforums.com/showthread.php?t=2691420
[Verizon Samsung Galaxy S 4] CalcProgrammer1:
I'll try it. I don't have Samsung's secret menus since I run CM though, and using it as is gives no output. Are the addresses different on the Note 3? I have some lines sec_log= and sec_dbg= in kernel cmdline with addresses.
[Verizon Samsung Galaxy S 4] Surge1223:
Yeah your addresses will be different (the address to dump is sec_log which you'll find in cmdline like you said) but whenever I try to test kexec, the output of sec_log is unintelligible, I mean it exists but I can't get any valuable info out of it like usual on normal boots. But maybe you'll have better luck.
[Verizon Samsung Galaxy S 4] ryanbg:
Feel free to PM me. I've researched this area extensively. 619k resistor between ID and GND pins on USB, with VCC grounded. 3.3v pull-up 115200bps, 8, n1. Still experiementing with hardware flow control and such. I think 150k worked for some kernel output, but 619k seemed to be the sweetspot. Of course, 301k will work for Download mode per usual. I use a bus pirate, and have used my Raspberry Pi in the past (I've also JTAG'd my router with my Raspberry Pi, best $30 for learning about hardware I/O.) I am having some issues with CTS/Flow Control so if you could help figure it out, that'd be great! I get kernel output, but with lots of other 'garbage'/flow control bytes.
[Verizon Samsung Galaxy S 4] CalcProgrammer1:
Sounds good, I'll experiment with this tonight or over the weekend. I need to find my sacrificial USB cable and figure out a combination of resistors for 619K. If it's 3.3V I have some PL2303 breakout boards from eBay that do USB to 3.3V serial so that's perfect.
[Verizon Samsung Galaxy S 4] CalcProgrammer1:
Just tried viewmem with the address 0x10000008 and length 0x100000 as is the sec_log= in cmdline. I got the bootloader log which contains the kernel, ramdisk, and dt addresses. No Linux kernel log though unfortunately.
[Verizon Samsung Galaxy S 4] CalcProgrammer1:
I just got it working as well! I didn't have a 619K resistor, nor did I have even 100K so I scavenged through a box of old parts and have a string of various resistors, pots, etc. to add up to 615 or so K. Then I whacked in my PL2303 breakout board and got data spewing out. I'm not seeing any flow control issues with this setup (using GTKTerm on Linux). I still haven't hooked up the tx pin yet but I did get a prompt.
[Verizon Samsung Galaxy S 4] biglil1:
So for all the uneducated ( us noobs ) what does that mean?
[Verizon Samsung Galaxy S 4] sokrboot:
Progress. Slow but steady progress. We will see lots of "we need to find x" and "we were able to find x" posts as the devs continue their amazing search and work. It kind of like searching a dark room with a flashlight... We know what we are looking for, we just need to keep searching until we uncover it.

---------- Post added at 07:36 AM ---------- Previous post was at 07:30 AM ----------

[MENTION=4939386]Surge1223[/MENTION] any idea if it is worth me putting more energy into researching the issues I brought up a few posts back? Just don't want to waste time/energy...

Thanks.
[Verizon Samsung Galaxy S 4] NighthawkXL:
It's never a waste of time to learn new things, even if nothing pans out from it. I personally would continue looking into those possibilities...
[Verizon Samsung Galaxy S 4] ryanbg:
I've got a few resistors combing up to roughly 619k (there's a decent range of tolerance so it doesn't have to be perfect.) They're on a small breadboard connected to my MicroUSB jig with D+/D- connected to MISO/MOSI on my Buspirate. I honestly think it's either my resistance/soldering on breakout MicroUSB board, Buspirate itself and some sort of CTS, or my terminal. I've tried RealTerm which I get the best results on, and identifies the junk bytes I'm getting as CTS, and mixed success with Minicom/PuTTY. I might try a different TTL or use my Raspberry Pi. Maybe I should disconnect my TX line. Have you seen anything interesting while attempting to load a kernel via kexec? My binary needs to be rebuilt with proper DTB support, so I haven't had much opportunity on the Note 3.
[Verizon Samsung Galaxy S 4] scryan:
I'm betting you have way more experience then me, and may have better parts then me...

If you are trying to find issues with connections or sources of interference/noise/whatever and your using a breadboard I have had cases where one rail will bleed into the next... If everything else turns out fine perhaps try and get a couple rails between different lines if possible.
[Verizon Samsung Galaxy S 4] MorrisC2010:
New Update just hit my phone this morning Build: jfltevzw/4.4.2/KOT49H/I545VRUFNG6 KITKAT
[Verizon Samsung Galaxy S 4] skepticmisfit:
yeah this has been out for about two weeks. expect bad things to happen. people have reported things breaking with this update, also no ROMs are going to support this update.
[Verizon Samsung Galaxy S 4] michaely123:
It's not even worth it to update to the firmware, especially those random reboots that most people are getting.
[Verizon Samsung Galaxy S 4] Surge1223:
Happy one year anniversary. I can't believe I wrote the OP one year ago today, I've learned so much since then, in fact im embarrassed to read the OP because reading it now I realize I didnt know much back when this thread started however ive learned a lot since then and thats mostly due to the contributions made in this thread and the people I have met here, so I just wanted to take a moment and say Thanks. :)

#stillfightin
[Verizon Samsung Galaxy S 4] MorrisC2010:
There is no Knox flag in NG6....
[Verizon Samsung Galaxy S 4] Sczar:
I have noticed that too. But I wasn't sure!!
[Verizon Samsung Galaxy S 4] toaster22:
Has it actually been removed or is it just hidden until it gets tripped now? I could see them making it hidden by default so they know right away by it just showing that it's been tripped. Other then tripping it, I'm guessing looking at the code would be the only way to figure this out?
[Verizon Samsung Galaxy S 4] DX.Deception:
I would guess that they just hidden the Knox flag because in the update details for NG6 it says Knox updated to Knox 2.0
[Verizon Samsung Galaxy S 4] NighthawkXL:
This would seem to be the case. We really haven't gotten much information on what's included in KNOX 2.0. If anyone knows more info feel free to post here or better yet on a new thread.
[Verizon Samsung Galaxy S 4] sokrboot:
Your wish is my command...

http://xdaforums.com/showthread.php?t=2920810

[Info][resource] Knox 2.0

---------- Post added at 06:03 AM ---------- Previous post was at 05:49 AM ----------

Also ran across this blog on K2.0 http://mobilesecurityares.blogspot.co.uk/2014/10/why-samsung-knox-isnt-really-fort-knox.html?m=1
[Verizon Samsung Galaxy S 4] jmgib:
I'm not sure the Knox 2.0 included with the Verizon update is the complete update. It is supposed to include the Google Play Store but it does. It appear to do so.
[Verizon Samsung Galaxy S 4] ryanbg:
This is an excellent suggestion. I'm still learning too, just like you guys. I'm just at a different place.
[Verizon Samsung Galaxy S 4] Surge1223:
FOR DEVS ONLY

NC5 Kexec Source

https://github.com/surge1223/kernel_samsung-jfltevzw-VRUFNC5

Also made kexec-tools 2.08 and merged hardboot and dtb support while retaining atags support so this might be step toward a unified kexec-tools lol

https://github.com/surge1223/kexec-tools-2.08-android

To test/debug Kexec:

1. Flash modload in recovery: Download modload

2. Install Safestrap-JFLTEVZW-3.82-KEXEC-TESTING.apk

3. You can download the modules and scripts from here if you didnt build the kernel, push them to /data/local/tmp

4. Reboot into Safestrap, mount system, go to advanced open terminal emulator in /data/local/tmp then type

modload
sh push.sh
sh setup.sh

It currently hangs at MKEXEC: kexec_call_with_stack
[Verizon Samsung Galaxy S 4] michaely123:
Getting closer by the day.
[Verizon Samsung Galaxy S 4] sokrboot:
My laptop took a crap last week, Could someone PM me a dump/log up to the point it hangs. I ran across a couple of things I'd like to compare. Thanks.
[Verizon Samsung Galaxy S 4] SnyderGuy:
I wouldn't be so sure, I am hoping we don't need NG6 to unlock it. Because I have a mixed version of it. (NC5 with the new NG6 stuff, however, I get to keep root and keep Knox2.0 out of my system)
[Verizon Samsung Galaxy S 4] npjohnson:
Wow. Can't wait to get on this and see if I can help any with debugging. Does 3.82 also retain normal SS abilities? Like Flash/Backup/Restore? Or is it strictly for kexec right now?
[Verizon Samsung Galaxy S 4] Surge1223:
[ 198.929656] kexec: kexec: KEXEC_IOC_LOAD
[ 201.055480] kexec: kexec: KEXEC_IOC_CHECK_LOADED (1)
[ 201.115417] kexec: kexec: KEXEC_IOC_REBOOT
[ 201.115509] KEXEC: preempt_disable
[ 201.115631] KEXEC: disable interrupts
[ 201.115722] KEXEC: kernel_restart_prepare_ptr
[ 201.115783] set_dload_mode <0> ( c00788e4 )
[ 201.115936] (sec_debug_set_upload_magic) 0
[ 201.121337] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.134979] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.155181] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.174865] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.195098] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.214843] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.234954] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.255340] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.276275] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.295318] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.315307] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.335418] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.355285] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.357696] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.375274] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.427337] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.427581] qup_i2c qup_i2c.2: QUP: I2C status flags :0x1300c8, irq:228
[ 201.429626] qup_i2c qup_i2c.2: I2C slave addr:0x26 not connected
[ 201.430206] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.447265] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.451995] BUG: scheduling while atomic: kexec/664/0x00000003
[ 201.454193] KEXEC: machine_shutdown
[ 201.455383] MKEXEC: found gic_raise_softirq: c001e914
[ 201.455596] MKEXEC: waiting for CPUs ...(1000000)
[ 201.455718] KEXEC: machine_kexec
[ 201.455841] MKEXEC: va: da3c9000
[ 201.456054] MKEXEC: kexec_start_address: 80208000
[ 201.456176] MKEXEC: kexec_indirection_page: 9b825000
[ 201.456390] MKEXEC: kexec_mach_type: 00000f6d
[ 201.456512] MKEXEC: kexec_boot_atags: 80201000
[ 201.456604] MKEXEC: copy relocate code: addr=0xda3c9000, len==136
[ 201.456817] MKEXEC: kexec_reinit
[ 201.456939] MKEXEC: soft_restart
[ 201.457061] MKEXEC: outer_flush_all
[ 201.457275] MKEXEC: outer_disable
[ 201.457366] MKEXEC: kexec_identity_mapping_add 0x16640000-0x16641000
[ 201.457580] MKEXEC: end mappings end==0x16641000
[ 201.457702] MKEXEC: flush_cache_all()
[ 201.458007] MKEXEC: local_flush_tlb_all()
[ 201.458251] MKEXEC: kexec_call_with_stack (va: 0xbf0046c0, __soft_reset: 0xbf00416c, addr: 0x9b8c9000, stack: 0xbf004fc8)

Then it just hangs there until I reboot.
[Verizon Samsung Galaxy S 4] DX.Deception:
So is this good news?
[Verizon Samsung Galaxy S 4] skepticmisfit:
Yes, but this isn't a user thing yet so don't hold your breath.. yet
[Verizon Samsung Galaxy S 4] Raymondlikesroot:
Yeah I believe so! Surge is getting closer. CM days are coming :)
[Verizon Samsung Galaxy S 4] DX.Deception:
Absolutely cannot wait.
[Verizon Samsung Galaxy S 4] skepticmisfit:
it's not just surge, I'm sure you know this. the other people here have been extremely helpful and without them I'm pretty sure we wouldn't even be this far

also considering the "CM days are coming" comment, Android L has a lot of protection in place (SELinux, encryption) and I would assume we would have to do the same workarounds as usual to get properly working ROMs, and they've said that without those protections in place, a device technically isn't supported by them (though cm isn't the only ROM out there)
[Verizon Samsung Galaxy S 4] Raymondlikesroot:
Yeah, I should acknowledge the other devs. I just thought Surge was the man guy leading the charge. And my understanding of kexec and CM was that CM could run with kexec with further development. I'm talking about kitkat. I'm not very knowledgeable in this area, however.