yashsingh1/xdaforums huggingface dataset:
[Motorola Photon 4G] tdhite:
Got it!

The kexec binaries that operate (at least) can be found on my DropBox here.

The next step -- find some room in memory. The zImage I'm trying to load is from the Photon boot image (via splitimage.pl script). This will take some work to get loaded -- we need some space and by the time the things load up, no contiguous set exists sufficient to load the image:

# ls -l zImage

-rw-rw-rw- shell shell 3272392 2013-02-09 22:17 zImage

# ./kexec -l zImage

Could not find a free area of memory of 326ec8 bytes...

Cannot load zImage

baby steps ... BTW -- these are shared library linked execs. The NDK I'm using is version r7c (http://dl.google.com/android/ndk/android-ndk-r7c-linux-x86.tar.bz2)

I think the next tests I'll do is to really cheat -- modify the ueventd program to actually be kexec hard coded to attempt to load the kernel. The original kernel loads init from the initrd, and that calls ueventd very early in the boot process. That ought to mess up my phone for a few tries - LOL. To have a backup plan, of course, I'll make it hunt for zImage and if not found, just operate as normal (so I can at least boot in the event it all borks).

Note that you can build your own ueventd by the standard android build process, just target it as the output (after modifying it, of course). Then copy it (save the old) to /sbin on the phone and reboot (dangerous, to say the least, 'til you know your code works -- emulate it first). Anyway, that's next unless there's better ideas.
[Motorola Photon 4G] InsanePostman:
Thanks so much for the vast amount of time and effort you' re putting into this.
[Motorola Photon 4G] LightingZ:
What's up with electrify kexec executable?
[Motorola Photon 4G] tdhite:
Well, until I get the photon working correctly, I figure it's not overly important yet. It's a very easy build, though, so not to worry. The only difference is already in the code. More soon...
[Motorola Photon 4G] tdhite:
Thanks for the thanks, but from the Arm experts, I could use a second set of eyes for a sec. Below is output from debug logs I put in to test the memory ranges kexec is looking at to load the new kernel. In fact, there's *plenty* of room, but the (GCC bug???) compiled code appears to improperly compute the tests. Below, mstart and mend are the start/end of a range of memory kexec will look at to try loading. Interestingly, the test of mstart < mend fails, yet it clearly should not -- zero (0) is certainly less than 0xafd12c49 by way of example.

# ./kexec zImage

kernel: 0x40404008 kernel_size: 31eec8

testing mstart < mend ? 0 < afd12c49 ...

mstart < mend ? 1 : 0 evaluates to 0 ...

mend - mstart = 335544320 ...

ULONG_MAX = 4294967295 ...

testing mstart < mend ? 20000000 < afd12c49 ...

mstart < mend ? 1 : 0 evaluates to 0 ...

mend - mstart = 167772160 ...

ULONG_MAX = 4294967295 ...

testing mstart < mend ? 2a000000 < afd12c49 ...

mstart < mend ? 1 : 0 evaluates to 0 ...

mend - mstart = 369098752 ...

ULONG_MAX = 4294967295 ...

Could not find a free area of memory of 326ec8 bytes...

Cannot load zImage

That's pretty simple code doing the logs (I put it in the the memory range test loop of locate_hole function in kexec.c):

fprintf(stderr, "testing mstart < mend ? %Lx < %Lx ...\n",
mstart, mend);
fprintf(stderr, "mstart < mend ? 1 : 0 evaluates to %d ...\n",
mstart < mend ? 1 : 0);
fprintf(stderr, "mend - mstart = %Ld ...\n", mend - mstart);
fprintf(stderr, "ULONG_MAX = %lu ...\n", ULONG_MAX);

Anyone see what I'm missing here?
[Motorola Photon 4G] madgrizzle:
if you convert the differences from those three runs to hex, you see something interesting.. it appear mstart/mend aren't playing the game fairly.

Run 1: 14000000 (mstart = 0)

Run 2: 34000000 (mstart = 20000000)

Run 3: 36000000 (mstart = 2a000000)

how are mstart and mend defined?
[Motorola Photon 4G] tdhite:
It's all unsigned long long. Thus, my Lx print specs other than the difference.

Something is very odd here.
[Motorola Photon 4G] phatninja55:
Could this patch be modified to work with your kexec?

http://permalink.gmane.org/gmane.linux.kernel/1045124
[Motorola Photon 4G] tdhite:
I'll take a look at the shifts that poster did and see if it makes sense on our setup. It's a different section of the code than we're dealing with, but it's an interesting bit of info regardless.
[Motorola Photon 4G] gofd:
One of the possible reasons of this result is the mend is indeed signed and in negative value...Would you mind confirming the definition of the data type of mstart and mend or test with the code below?

fprintf(stderr, "mstart < mend ? 1 : 0 evaluates to %d ...\n", (unsigned long)mstart < (unsigned long)mend ? 1 : 0);
[Motorola Photon 4G] tdhite:
Turns out there's more to it than that. The kexec-tools code is mixing integer sizes in the math (not likely intended). The critical 'start' point is called 'hole_base,' which was defined as unsigned long, whereas all other vars in the computation were unsigned long long. In any event, fixing up the math the truth shows:

kernel: 0x40404008 kernel_size: 31eec8

testing mstart < mend ? afd12c4900000000 < 40000814000000 ...

mstart < mend ? 1 : 0 evaluates to 0 ...

mend - mstart = 5795802588100165632 ...

testing mstart < mend ? afd12c4920000000 < 4000082a000000 ...

mstart < mend ? 1 : 0 evaluates to 0 ...

mend - mstart = 5795802587932393472 ...

testing mstart < mend ? afd12c492a000000 < 40000840000000 ...

mstart < mend ? 1 : 0 evaluates to 0 ...

mend - mstart = 5795802588133720064 ...

Could not find a free area of memory of 326ec8 bytes...

Cannot load zImage

Now the question is why on earth we get backward holes (or at least invalid holes) -- that's the next debug. The kernel surely has holes, but there's some sort of disparity between what the kernel knows, as running, and what kexec asks for. I'll see about that later today, hopefully.
[Motorola Photon 4G] gofd:
I am not sure what do you mean by "holes" (seems not due to memory alignment problem) but comparing values between different data types could be quite tricky. How about declare another local "unsigned long long" variable mstart_ull, assign the "unsigned long" mstart to it and change to compare mstart_ull against mend?
[Motorola Photon 4G] tdhite:
A hole, in this context, means a contiguous set of bytes of physical memory. The second kernel must load into such a hole.

Math is no longer as problem. I think, right now anyway, the problem is not the hole locator math, rather an improper treatment of the data the running kernel says it has for holes. Still debugging, but kernel debugging is slow as I'm not (yet) an expert on the arm chips.
[Motorola Photon 4G] tdhite:
Sorry folks -- a slam of travel last week, so not much progress. Back at 'er this evening. Hang in a bit -- debugging going slow -- trying to setup an emulator to make life a tad easier than hardware/phone.
[Motorola Photon 4G] krrishvaid:
so where has the progress reached................ The developers involved in the project seem to be promising...... i hope u people make the bootloader to be unlocked one day..... or at least uboot:thumbup::rolleyes:
[Motorola Photon 4G] phatninja55:
It's neither uboot, or a way to unlock the bootloader. It's kexec.

kexec is a bypass, it will allow us to run custom kernels with a locked bootloader
[Motorola Photon 4G] Damanis1:
So we would be able to use 4g along with let's say a jelly bean rom?
[Motorola Photon 4G] Jakeroxs:
Following this thread... Don't even own this phone just think it's interesting x)
[Motorola Photon 4G] MarcquisDale:
What ever i can do to help out im interested
[Motorola Photon 4G] phatninja55:
No, the required files for 4g would not work with custom roms.
[Motorola Photon 4G] MarcquisDale:
Yeah i wonder why that question is constantly asked
[Motorola Photon 4G] Damanis1:
I thought it because he said it would go around the boot loader
[Motorola Photon 4G] Lightsword1942:
If anyone has the chance can they compile this https://code.google.com/p/lime-forensics/ against the photon's kernel.
[Motorola Photon 4G] tdhite:
Progress is *terrible* the last two weeks. I've just been crushed at work, so by the time I get into the kernel, my head simply wouldn't compute anymore. I'm back to normal life now, so will get back into it.

Sorry folks -- some times life just deals a deck not otherwise expected. :)
[Motorola Photon 4G] MarcquisDale:
All cool bro glad to see you back at
[Motorola Photon 4G] Chad The Pathfinder:
Make sure to take care of yourself and your family first. :)
[Motorola Photon 4G] tdhite:
Ok,

Looks like I have the holes issue figured (appears that way, anyway). The next step is getting the kernel to load without throwing up. It tries, alas -- panics.

So I think, at this moment, the issue lies in the differences between the module and the kernel code. The entry/exit assembly code in the kernel from Motorola is very different from that which is in the kexec-mod module I started with. Will have to spend a couple days figuring out how to merge them. But at least we have progress, for a change.

:)
[Motorola Photon 4G] tdhite:
I put up a more convenient building script here: https://www.dropbox.com/s/jcvk8qyihv4ont9/build_kernel -- the old one was a bit of a pain. Debugging so many iterations made me update it to let me build the kernels, modules, apps, etc. Much easier. Change the 'VENDOR" from tdhite to whatever you call yourself (and make as the ${HOME}/android/vendor/<your_vendor_name_here>.

Happy playing with the android repo/kernel code if you get there.
[Motorola Photon 4G] sandys1:
sorry for being off topic, but is anyone starting a bounty for this?

I would really want to contribute to it if there was one - the One X bounty was a spectacular success ;)
[Motorola Photon 4G] twaffle:
tdhite,

Do you need any information from Motorola regarding the current kernels assembly? I may be able to get more details, it may got shot down, but it's worth asking.
[Motorola Photon 4G] tdhite:
Hi,

No real need for Motorola info, the kernel is all there. All they challenged at the moment are around coercing the module to get the info to kexec tools properly. Each win usually is followed up by another prob, right now that's getting atags to work right.

Anyway, I know this all seems slow, and it is. Debugging the kernel and our module is painful given no debug symbols in the kernel.
[Motorola Photon 4G] kingtiger01:
Any update? Watching this thread/previous comment thread with great interest :D
[Motorola Photon 4G] AcIdSaMa:
Really hope you guys get this working ended up losting my first photon in a car wreak that was unlocked get it back from insurence and during actiavtion sprint pushed the 2.3.5 update to my phone without my consent really missing Jellybean :(

Got this far hopefully you guys can break that wall that Moto put up on us!!!
[Motorola Photon 4G] tdhite:
Still working on it in evenings. It's hard with no real debugging tools against the kernel, but just hang in. I wish I could give some strict time line, but it's just not in the cards for us.

I need to update the git repo with recent fixes, so will do that over the weekend.
[Motorola Photon 4G] R2DeeTard:
I may be drunk right now, but i wish tdhite was my dad.
[Motorola Photon 4G] MarcquisDale:
Lol
[Motorola Photon 4G] kingnfs:
thanks for the dev

i hope it will destroy the f*****n bootloader :)
[Motorola Photon 4G] Cooldevil1989:
Development is going on or stoped....????:confused:
[Motorola Photon 4G] R2DeeTard:
Honestly at this point I would not ask when it's going to be finished, tdhite keeps us updated as need be. If it were stopped, he would say so.
[Motorola Photon 4G] phatninja55:
People are not going to stop asking, its best to just politely tell them hes still working on it.
[Motorola Photon 4G] tdhite:
I got so sick of working over adb and emulators, I got a SMOKING SDHC 32gb card today and moved the compiler and android build back onto the phone.

Not sure that thrills anyone, but it does me. I now just run my debian mod for webtop, compile away on the device, and then, well, usually hang my phone on the tests. Lol, but yeah. Still fighting the war.

I know the time is frustrating, but those who fret should try compiling this stuff down and genuinely understand the degree of difficulty in hacking a kernel while its running without trashing file systems you don't want to trash. Each time you hit the enter key on another kexec test makes you wonder when the smoke billows. lol.

All good folks. I like that war. ;) I just hate the time and share the frustration for sure.
[Motorola Photon 4G] antipasto:
Is this on a public repository? Perhaps builds and tests could be automated, or maybe someone has a good idea how to prevent the fs hosing. Or programmatically derive a solution through random or repetitive tests.
[Motorola Photon 4G] tdhite:
The code is all on a public repo -- see the original post.
[Motorola Photon 4G] tdhite:
Finally -- some real progress (though not necessarily good news yet)

Just an update. Debugging through code, I've located the major problem causing my kernel load hangs. The kexec-tools code does extensive amounts of integer size conversions, alas they are not working correctly when going to/from unsigned long long. If you remember, I ran into these issues in the locate_hole, but it's worse than just that area -- it's more of a pervasive problem than I'd ever have wanted.

It'll take me a good few days to scour the code and rectify the conversions. Frankly, most of the integer size spread-outs are not necessary and just cause all sorts of problems. The arm code is *not* clearing the upper bits when expanding a 32-bit integer to 64-bit. That means we get garbage values. While I fixed the memory range locating code just to get the kernel to load at all, the remainder of the code needs the same repairs. There's many...

Progress, just not 'the deal' yet. But, progress...
[Motorola Photon 4G] InsanePostman:
The fact that you are still pushing forward on this is commendable.
[Motorola Photon 4G] kingnfs:
thanks for the update :))
[Motorola Photon 4G] pradeeppk:
Hope you will reach there... 2ndint and CWR...

Actualy we are devided in to two zone.

Unlocked and locked.

So much confusion for noobs.

Bootstrap and CWR, locked and unlocked etc.

If you get it working, all locked and unlocked users are able to flash all roms available here.

And another milestone to reach is 2ndboot roms which use custom kernels for locked bootloaders.

Waiting and thanks for your hardwork.
[Motorola Photon 4G] phatninja55:
If you need help fixing the unassigned long longs, you could get a team of devs together, and assign them a section of code to go through, then merge all of your changes.
[Motorola Photon 4G] pradeeppk:
I am not a dev. But we get source codes from the github of defy devs like Quarks, epsy, manic, walter79, kayant etc. We need to change the source code to match with photon. They are not trying to unlock the bootloader. They found other ways to overcome it. Like 2nd int roms that run all roms based on official kernel, 2nd boot roms based on custom kernels, 2nd system roms are run from sd card, so we swap roms during a reboot. You can flash roms directly to sd card and run from there. I have two roms (not flashable zips) in my sdcard and i can switch them accordind to my needs.

Hope our devs think that way.

May we get help from the defy devs
[Motorola Photon 4G] phatninja55:
Maybe tdhite can work with those devs to help them geg kexec, and they could help him get 2nd init and sdcard roms. Partnership gets things done.
[Motorola Photon 4G] tdhite:
Hi,

Not quite sure what the last couple posts are heading towards -- but agreed. The code basis for what we're doing here is the Eternity project -- many contributors. The work is kexec, so that appears consistent with what recent posters are pointing at. As for 2nd init -- that's the whole point (at least herein) of the kexec.

Let me explain a bit -- the kernel loads the init program during boot -- you don't get the chance to change it. Our kernel is packed with it's ramdisk (rdimage) as normal, alas the init program is part of the rdimage, not part of the file system. So in order to subvert loading that init (and get to a second init), we pretty much have to load a second kernel with a modified ability to load a '2nd init.'

So I'm all over learning a new way to subvert the init (and kernel) loading process given our locked bootloader. If someone can point to actual code that I can merge into our own repository (which of course is public, as I mentioned, and forked from the Eternity project so one day we can merge it back there), I'll be happy to do so.

As for folks digging in to fixing up the code here -- love to have help -- just lemme know who's up and I'll setup a Redmine or Jira server to assign folks with tasks.

With all that said -- if some folks want to work on a modified init configuration (it's also in the init.rd), that'd be *great*. It's easy enough to build the standard android init program and test in emulators -- it's also easy enough to generate a modified rc file. If you want to dig in there, just PM me and I can help get you setup.
[Motorola Photon 4G] tdhite:
ATAGS -- the next issue to solve

All,

the conversions all work now. In fact, the root of the problem was not so much the conversions in and of themselves, rather a poor mechamism for reading /proc/iomem to pick up memory range holes. Instead of mucking he entire code base in terms of conversions, I found I could just fixup up the get_memory_ranges function in kexec/arch/arm/kexec-arm.c. In fact, I suspect it would still have been broken even *if* I'd mucked all the code since the conversion was broken too. In any event, it's all good now (and I'll commit it this evening (later, after more testing) those looking to play -- just check for a pull of the kexec-arm.c file and you'll know you have the changes).

Next problem (really, where I've seen *many* kexec projects fail, so we have to solve it) -- no atags:

/data/local/tmp/kexec # insmod kexec_load.ko

/data/local/tmp/kexec # lsmod

Module Size Used by

kexec_load 21792 0 [permanent]

dhd 234647 0

bcmwimax 244037 4

bcmsdio 7864 1 bcmwimax

vpnclient 66748 1

/data/local/tmp/kexec # ./kexec -l zImage

Cannot open /proc/atags: No such file or directory

Opening CDT...

Error opening CDT

I have to ponder, but the solution to missing atags, to me, is create it. Duh? Well, not so easy, but since we have kexec_load.ko, seems to me

we can create it and properly populate it. Some reading for me, then I'll comment further.

quick update: looks like the Eternity project gave me a starter (never had to look there yet): kexec/arch/arm/kexec-zImage-arm.c

Not sure how the CDT file must exist (format), but I'll PM the author to see how that goes. If it works, cool!

-- Tom
[Motorola Photon 4G] phatninja55:
This maybe a shot in the dark considering I have no Idea what you are talking about.

But maybe moddify a Kexec_atags.patch to work?

http://svn.openmoko.org/branches/src/target/kernel/2.6.24.x/patches/kexec-atags.patch
[Motorola Photon 4G] pradeeppk:
Please look at this thread. It is a rom for defy. Locked bootloader but it using custom kernel, 2nd int, 2nd boot, and 2nd system (another rom) from sd card.

http://xdaforums.com/showthread.php?t=1140839
[Motorola Photon 4G] phatninja55:
If all else fails (referring to kexec atags missing) 2nd boot seems like a great alternative.

It itself is a module just like what he's trying to achieve here.

2nd boot is a miniature bootloader loaded by the kernel itself.

There is a binary, and an app that you would use to conrtol 2nd boot.

http://www.droid-developers.org/wiki/2ndboot

It's worth looking into.

Well maybe not, it also uses atags.

2 years ago a dev on xda made atags for the atrix 4g.

Edit: if you were to build the photon/electrify with kexec enabled would it build the atags? If so we could just cat them into /proc/atags
[Motorola Photon 4G] tdhite:
atags is the crusher unless we get them -- I have a request associated with that in just a sec ...

As for the dev who 'made atags' for the atrix -- can you point me to that person? Love to have a quick chat to see how.

The request: look at my next note -- if someone can try a few things out for me -- it'd be great! I have kernels now loading successfully, but can't risk a break ... see the next note.
[Motorola Photon 4G] tdhite:
Need a tester who is *not* locked ...

I have the kernel loading now. I modified kexec to try to parsing through some paritions to hunt down the atags by signature (it's weak, and frankly the same code as the 2ndboot and the Eternity project, but it's getting some 'hits').

What I have going is kernel load, no more hangs, and unloading the loaded kernel (I'm using the stock kernel to test).

What I need: I need someone who is not stuck on 2.3.5 (didn't accept the OTA). The reason is after loading with the 'hunted' atags, the next step is actually exucute the kernel and see what 'H' breaks loose. Since I don't have an expendable Photon (mine's locked and my primary phone), if someone who could recover would do me the favor of PM'ing me, if willing, to load a kernel, then execute it. I'm sure it won't just create magic and work perfectly, but if it goes bad, I have no way to recover.

Either that or someone just donate me a non-OTA upgraded photon so I can muck it to death while I debug the last stage of this work.

Anyway -- here's a log of load/unload with memory snapshots in between -- we're getting closer:

/data/local/tmp/kexec # free

total used free shared buffers

Mem: 836236 532796 303440 0 47332

-/+ buffers: 485464 350772

Swap: 0 0 0

/data/local/tmp/kexec # ./kexec_mmcblk0p1 -l zImage

Cannot open /proc/atags: No such file or directory

Opening CDT...

Parsing CDT for ATAGs...

/data/local/tmp/kexec # free

total used free shared buffers

Mem: 836236 536388 299848 0 47348

-/+ buffers: 489040 347196

Swap: 0 0 0

/data/local/tmp/kexec # ./kexec_mmcblk0p1 --unload

/data/local/tmp/kexec # free

total used free shared buffers

Mem: 836236 533336 302900 0 47376

-/+ buffers: 485960 350276

Swap: 0 0 0

Shows the right amount of memory eaten (on load), then freed up (on unload).

Closer ...
[Motorola Photon 4G] phatninja55:
http://xdaforums.com/showthread.php?t=1079097
[Motorola Photon 4G] kingnfs:
some one that have unlocked phone can please help him ?

if not how can donate something and we will collect to buy him a phone .
[Motorola Photon 4G] Lightsword1942:
I have a spare photon for testing that you can use remotely.
[Motorola Photon 4G] tdhite:
Thanks, if we get there, I'll come running. I got a PM from a good soul who will load up the code and see what happens.
[Motorola Photon 4G] kingnfs:
yesss something is moving :))
[Motorola Photon 4G] MarcquisDale:
Nice to see the progress i still have my photon as a backup or something

Sent from my Galaxy S4
[Motorola Photon 4G] phatninja55:
Any news on how the load went?
[Motorola Photon 4G] tdhite:
Didn't work. The older kernel in the non-OTA phones refuses to load the kexec module. Working on it this weekend -- needs a different jump vector so I have to build the old one to get the symbol map. Hang in, this is crappy work without recovery ability like non-OTA phones.
[Motorola Photon 4G] bosox04:
I sent a pm, please check.
[Motorola Photon 4G] tdhite:
Folks, our testing failed, but we are not dead yet. The phone reset (full reboot with Motorola logo, so not a simple kernel switch).

I am pretty sure the module setup the proper jump, but the atags from digging around the boot and image partitions were bogus. Back to finding the correct atags, but at least no bricks! That actually is progress.
[Motorola Photon 4G] technomike:
Just as a side comment. I think this tech who was trying to fix my screen, did the update to my phone and now I am stuck on the new update.

I was just getting ready to hook up the rooting and now I'm hosed. So I'm hoping for you all to make the final breakthrough!!
[Motorola Photon 4G] MarcquisDale:
You can still root