Welcome to Eternity Project!
So... as most of you know I'm working on the Atrix solution from TOO MUCH time.
With the collaboration of people on #moto-atrix I've stated that FUSES on Tegra2 are really OTP, so there isn't any way to CRACK the BL, but we can still BYPASS it.
So... what is it?:
kexec is a "fastreboot" that won't pass through the Moto Bootloader, so with it it's possible to use custom kernels and, with some other development, custom Android systems like CM7 and many others.
Where's the poop?
Okay, that's it: I've successfully compiled and ran kexec on the Atrix 4G, so that kexec works, but it needs a kernel that can boot with kexec. On x86 we can build a relocatable kernel so no problems... but not on ARM and obviously not on Tegra.
The thing that is missing is exactly... _the address of the boot params_!
And now?
I'm only searching for help for completing the project and make a kernel that is bootable from my god-it-is-really-working-kexec. Any devs around?
Downloads:
- Kexec pack V0.01: DOWNLOAD
Kexec pack contains:
- ATAGS for MB860 (ATRIX_atags.tar)
- ATAGS hack module (eternity_procfs.tar)
- kexec module (eternity_kexec.tar)
- kexec tools/binaries (kexec-tools.tar)
- Kernel....that doesn't work. (eternity_kexec_kernel.tar)
So, what does work and what does not?
- ATAGS hacky hack: WORKING
- kexec module: WORKING
- kexec tools/binaries WORKING
- Kernel ToDo
How to run it:
0. FLASH AT&T 1.2.6 SBF PRIOR DOING ANYTHING
1. Extract all the archives
2. Insert the procfs_rw.ko module
3. cat atags > /proc/atags
4. Insert the kexec module
5. Run kexec for loading the kernel and jumping to it.
6. Boot! :|
P.S.: I won't release detailed how-tos because at this state I only need a DEVELOPER that can help me to build the kernel.
Thanks to:
- PAulyHoffman (special thanks!)
- unknown
- Sogarth
- the2dcour
- cranch
- eval-
- and many, many others....!
Awesome, i can verify that this kexec is working and will continue testing until we succeed.
random boot animation I made for eternity project
http://diamantephoto.com/bootanimation_red.zip
Also: 1.2.6 without losing /data, in case you were wondering exactly why I made this
http://forum.xda-developers.com/showthread.php?t=1073439
kexec pack updated. now kexec-tools is included
@kholk: Hai;
so basically this is a port of the unix kexec to run on tegra based devices?
From my understanding the android system uses a boot image that has the ramdisk and kernel combined together and they are dependent on each other... so won't overwriting the kernel at runtime give you us some issues since the core initialization of the system is ran from the ramdisk???
wouldn't be a better idea to tackle this issue too? but then again the only reason we can't flash boot images is because of the bootloader but ofcourse this is definitely a step forward for the tegra users.
now about the kernel, theoretically if we build an aosp tegra kernel from http://android.git.kernel.org/?p=kernel/tegra.git;a=summary shouldn't it work?
I can try building us a kernel if that would work
PS: people let's keep this dev ONLY if you want us to get some progress we need able to read through the thread without useless posts.
edit: also found this https://opensource.motorola.com/sf/frs/do/listReleases/projects.atrix/frs.olympus I'm sure having the source for the kernel we are currently running is also helpful
I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was
Ratchet556 said:
I know we should keep this dev only but please don't tell me this is for ATT only i already feel shafted enough being a Bell user and that would make it a hell of a lot worse if it was
Click to expand...
Click to collapse
When a kernel that works will be deployed I'll personally port it to Bell Atrix. This will take only some seconds.
kholk, perhaps we can ask a defy developer (or any of the phones that have kexec working) to help us build the kernel.
it's too bad da_g isn't around, he did a custom kernel but wasn't able to boot it.
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?
lostinbeta said:
I'm not a developer so I am hoping someone can help me understand this process better. From my understanding kexec is used as a reboot method that skips initial bootloader and hardware loading so how will this effect if we turn our phone off or pull the battery? Will the device need to be rebooted after initial startup to reactivate the kexec? Sorry to sound like the newbie that I am, I'm just interested in learning more.
Click to expand...
Click to collapse
thebeardedchild said:
Yeah, I'm also a little confused as to what exactly this means for all of us people who want to just flash Custom ROMs and such? In what ways is this different than just an unlocked bootloader and such?
Click to expand...
Click to collapse
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.
Jotokun said:
Assuming my understanding of kexec is correct, this would survive battery pulls. Basically, a custom rom would need to include two kernels: a Motorola kernel in addition to the custom one. The bootloader would run the Motorola kernel, which should pass any checks the bootloader would make. From there, the kernel would use kexec to load the custom kernel over itself in memory, effectively replacing itself. From there the custom kernel can continue loading the rom.
If the booloader were unlocked, the phone could directly boot the custom kernel. The downside of loading the custom one on top of the Motorola one is that the state of the phone might not be entirely known, so it would need to do more work checking what's been initialized and what hasn't. Its a little more work for the kernel/rom developer, but the end result is the same.
Click to expand...
Click to collapse
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Boot time will be about twice as long. Other then that, everything will run about the same
Yes thank you very much for that explanation... though I do also have the question about stability. By replacing the current kernel in memory with the new modified kernel the phone state may get confused as you mentioned... could this cause instability as a whole or increase risk of kernel panics? Or once everything is loaded and complete does it stabilize with the modified kernel?
Again sorry for the questions. This topic intrigues me and I love learning how stuff works.
thebeardedchild said:
I see, thanks for the explanation! So, on the user end, would there be any noticeable differences? This kind of makes it sound like the phone will be doing a lot more work, so could we see performance decrease or perhaps startup lag or something of the sort? Or would this all pretty much function on the surface as if we had flashed a custom ROM on some phone without a locked bootloader?
Click to expand...
Click to collapse
Only difference would be that it might take slightly longer to boot up. Once the phone is finished booting, there's no difference in terms of performance because by that point the Motorola kernel isnt running, or even loaded.
thebeardedchild said:
Haha yeah I'm checking every like 2 seconds now. What exactly do we wait for then? Someone to just create the custom kernel, and then of course wait for some Custom ROMs to be created? I hope we get CM7!
Click to expand...
Click to collapse
Kexec isn't fully operational yet, still need to find boot params. Then custom kernel.
How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?
Ratchet556 said:
How easy will this be to install on our phones? will it just be something we need to flash through CWM or will it require some more work then that to install?
Click to expand...
Click to collapse
I imagine some of the preliminary stuff may need to be pushed with ADB but devs are always nice and give us very clear guides. And I'm sure either a dev or active member could easily create a batch script.
Even though I'm comfortable with ADB I always make scripts for myself because I regularly wipe me phone and whatnot. Because it's so engaging some people might want to wait until a few normal community members test this out so we can see if there are any glaring challenges with the instructions. Just remember to back things up, read instructions clearly and I'm sure we'll all be fine. We've got SBFs and all that good stuff to cover our asses too.
Would it be possible to bring fastboot off the htc to this? Then we won't have to worry about boot time at all. Even if it did double the boot time...
Sent from my MB860 using XDA App
PixoNova said:
This bypasses the bootloader
Swyped from my Motorola Atrix 4g using XDA Premium App
Click to expand...
Click to collapse
Correct this method has nothing to do with unlocking the bootloader and previous attempts at that proved it maybe impossible.
Related
Hi,
I'm very new to android and have never made any custom roms before so I'm sorry if I sound too much like a noob, but I am a developer and have many years of programming experience so hopefully that will make up for it.
I've been working on porting ICS to the bionic from the AOSP for a little while now and I think I almost have it. I've gotten it to build for the bionic and flashed it via CWM (I can't use Safestrap because it doesn't support custom functions inside updater-script). Unfortunately I am now stuck at the initial Motorola Dual Core technology screen. I'm not sure how to access the logs from this. Because I can't get past the boot screen I have to reflash the stock OS with fastboot everytime. I've checked /data/dontpanic and /data/kernelpanics and /data/panicreports but there is nothing there. I'm not sure if this is because it get's wiped or because the failure is before the init.rc script runs (though I suspect it is the latter because I'm not wiping /data when I flash the stock ROM).
Does anybody know if there is a way for me to see any sort of boot log to see what's causing it to freeze on this screen? Is it releated to the locked bootloader? LIke I said I'm a complete noob when it comes to ROM development but thought I would give this a shot and I think I'm really close. Any advice would be much appreciated.
P.S. sorry for not posting in the dev forum but apparently I'm not allowed to.
Contact dhacker29 or hashcode. Both on twitter and Rootz. They are doing similar stuff and I'm sure they could/would help.
Sent from my DROID BIONIC using xda premium
This thread is left here only for historical purposes ! Now that the device has been released, easier and better methods have been developed to gain root, like CF-Root.
.
.
.
.
.
Check your device model ! Settings -> About device -> Model number. This stuff is made for the GT-I9300, if your model number has a suffix, it may not work, or if it is a totally different model, it will not work (may even brick) !
Ladies and gentlemen, we have root on the SGS3 (!)
This will all be common knowledge in the near future, but here's some info I though various devs, chefs, and users will be dying to know!
Unfortunately, I am not able to share the "insecure" kernel with you at the moment, because of fears it is traceable to the leaker (this is said to be the last traceable firmware revision).
Update: The kernel is linked at the bottom of the post.
Update: The easiest way for rooting is now CF-Root
This root is, as expected, trivial. It was a simple matter of repacking the stock kernel, with a modified adbd binary that thinks ro.secure=0 (even if ro.secure=1). This gives access to all adb root commands (see screenshots). Then SuperSU was installed manually.
Kernel
The modification was trivial, because this time around, Samsung is using the standard boot.img format, instead of the zImage format used for SGS1, SGS2, SGNote, etc, that is much harder to repackage.
This is also why I don't feel particularly bad about not giving you the insecure kernel - any serious dev on this board can do the same thing in 10 minutes.
Recovery
The recovery partition is also being used this time around. And thus we can flash recoveries separately from the kernel.
Bootloaders
There was no warning triangle at boot-up after flashing the modified kernel, but download mode did show a custom kernel flash counter which increased. Whether or not flashing a custom recovery also triggers this counter is as of yet unknown. Both flashing kernel and/or flashing recovery will trigger the flash counter!
Final note
This was all tested on a current (release candidate) SGS3 firmware. There may be a newer firmware on true retail/production devices. Though some things may change, it is unlikely to change much. Let's hope nothing
Also, Triangle Away did not work. They have hidden the boot partitions again as on the latest SGNote firmwares.
(No, I don't have an SGS3 yet, everything was done remotely)
Now, everybody say thanks to Samsung! I don't always agree with them, but so far they have been the first and IMHO still are the only high-end Android OEM who aren't complete douchebags in the unlock department!
Download
The instructions below assume some basic knowledge about Samsung devices. This is not a noob-proof guide.
Here's the "insecure" kernel, based on XX NEE ALE8 firmware:
CF-Insecure-SGS3_XX_NEE_ALE8-v1.2.zip
- Extract the linked file (you will get a .tar file)
- Use the ODIN version attached below to that .tar file to your SGS3 as "PDA"
Going from insecure to full root
After having flashed the insecure kernel, boot your phone, and make sure USB debugging is enabled.
Your device is now insecure, so you can use the adb root commands. This does not allow your on-device apps to get superuser access, though. For that, you need to install SuperSU:
Download and extract the sgs3-root-install.zip file, containing SuperSU v0.89. Make sure adb is running correctly, then just double click install.bat (this will reboot your phone).
Wow, that was fast!
Chainfire said:
Ladies and gentlemen, we have root on the SGS3 (!)
(No, I don't have an SGS3 yet, everything was done remotely)
Click to expand...
Click to collapse
bravo my friend i hope the candle wasnt the inspiration or errr turpitude dayyyyymn.....nough said....thanks for leading the way
Appreciate
Finally boot.img/recovery.img about time samsung(on their flasg ship that is)
Remotely! Good work, i can't wait to get the device .
Sent from my GT-I9100 using Tapatalk 2
thats great. i hope they don't 180 on the boot.img format.
So is the GSIII bootloader unlocked from factory or did it require a bootloader unlock?
Phistachio said:
So is the GSIII bootloader unlocked from factory or did it require a bootloader unlock?
Click to expand...
Click to collapse
As with the SGS1, SGS2, and SGNote, it was never locked to begin with.
Awesome!
Awesome work man. Maybe triangle issue can be solved with usb jig
There u go
Sent from my GT-I9100 using Tapatalk 2
Great news!
Can you work any magic with Asus TF300T
Quick work, well done.
Chainfire said:
As with the SGS1, SGS2, and SGNote, it was never locked to begin with.
Click to expand...
Click to collapse
Props to Samsung!
That was fast!
That's 11 days before the device is available commercially! WHoa! That was fast!
W0W. There we meet again. Nice one dude !
I'd be very reserved with yelling "Tjohoo" at this point. Things can change a lot between a developer version (which I assume is the one on Chainfire's hands) and a fully commercial shipper version. Let's just hope Samsung stay cool, and don't cause us more trouble than necessary, like has happened with the HTC One X...
Grats on the fast work man, and even more impressive is that it was done remotely on Windows 8! I've heard a lot of people having issues just getting ADB to work on Windows 8, and yet you managed to root a device for the first time ever using it without even physically having the device!
You truly are an inspiration to this community.
---------- Post added at 02:06 PM ---------- Previous post was at 02:05 PM ----------
E:V:A said:
I'd be very reserved with yelling "Tjohoo" at this point. Things can change a lot between a developer version (which I assume is the one on Chainfire's hands) and a fully commercial shipper version. Let's just hope Samsung stay cool, and don't cause us more trouble than necessary, like has happened with the HTC One X...
Click to expand...
Click to collapse
He doesn't have any device in his hands, that's what makes this even more impressive!
Very nice work, thank you and congratulations!
Granted, it has been a while since I've built CM, and never ported it to a new device, but figure this might give some smarter people a head start or at least provide a place for others to collaborate.
I've not gotten very far past the initial vendor setup per http://wiki.cyanogenmod.org/w/Doc:_porting_intro.
A lot of the work is based off the similar ASUS TF700T, https://github.com/CyanogenMod/android_device_asus_tf700t.
I've not messed with the kernel at all at this point, https://github.com/ouya/ouya_1_1-kernel.
I've uploaded everything so far to github, https://github.com/vinny75/android_device_ouya_ouya_1_1
Packages included with official build:
OUYA Framework, Launcher, and Store
Code:
app\OUYAKeyboard.apk
app\OUYALauncher.apk
app\OUYAOOBE.apk
app\OUYAWallpaper.apk
app\ouya-framework.apk
note: some media files I haven't list
CWiid for Android: http://cvpcs.org/projects/android/cwiid4android and https://github.com/cvpcs/android_external_cwiid[.
Code:
bin\wminput
lib\libcwiid.so
etc\acc_led
etc\acc_ptr
etc\buttons
etc\gamepad
etc\ir_ptr
etc\neverball
etc\nunchuk_acc_ptr
etc\nunchuk_stick2btn
Sixpair for PS3 controllers http://www.blog.kaiserapps.com/2012/10/setting-up-sixaxis-controller-android.html.
Code:
/bin/ps3service
/bin/sixpair
I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Sent from my Nexus 7 using xda premium
mybook4 said:
I noticed that the recovery.fstab committed is from the Ouya stock recovery partition. When getting cwm to work properly with the internal sdcard, we ended up having to change the sdcard line.
I made the change and submitted a pull request.
Edit: I saw you merged the change.
Click to expand...
Click to collapse
Thanks, appreciate the help, hopefully, we'll have a working build soonish
If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!
Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"
mybook4 said:
Vinny75,
What method did you use to create the files?
"Method 1: Use mkvendor.sh to generate skeleton files"
"Method 2: Fork a similar device's git repository"
or "Method 3: create the directories and files manually"
Click to expand...
Click to collapse
I started out with Method 1 then moved over files and settings from the ASUS TF700T.
professorpoptart said:
If you need any help with kernel debugging/boot issues, I'll be happy to offer up the assistance of my bus pirate.
I was looking at building CM also, but there was always that step in every tut I looked at for "how to port CM to a new device" that basically said "select your device from the build tree"... well if it was in the device tree it wouldn't really be a "new" device then would it!
Also you may want to look at building 10 instead of 10.1, might have less kernel issues as its 4.1.2 jb... at least so we can get some alternative rom working then go for 10.1 after that.
Good luck!
Click to expand...
Click to collapse
Yes, building the new device tree has been... uhm... educational... and I am still learning. If I don't make any headway on 10.1, I might drop back to 10 - at least most of the legwork will be done.
Ok, so I'm in the middle of a build
Have a vendor tree on my git and I forked Vinny75's device tree, modified it some
Also a kernel tree up there, which is required for my device tree (prefer to build the kernel myself =) I've booted a custom-built kernel on it already, so that shouldn't be an issue)
I'm nervous to flash this though. I did a bit of searching but couldn't come up with a way to get back into recovery should this thing not boot. You guys know of anything?
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium
mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Sent from my Nexus 7 using xda premium
Click to expand...
Click to collapse
Yea, that's what I'm seeing.
So here's my 'solution'
Since we have fastboot, we can boot a boot.img without having to worry about flashing it.
I've successfully booted my cm boot.img, with ro.secure=0 and ro.adb.secure=0, I can adb reboot it when it fails miserably to boot
Quick and dirty script to unsecure a boot.img:
http://pastie.org/8033076
It assume that unpackbootimg and mkbootimg are in your path, you can get them here: http://invisiblek.org/mkbootfs_tools.zip
Getting closer...
THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?
dibblebill said:
THere's a keyboard solution in the Ouya Questions forum in the thread, [Q] Is My Ouya Dead?
Click to expand...
Click to collapse
Yeah, I think that is the same solution posted earlier:
mybook4 said:
Other than using adb to reboot to recovery, http://forums.ouya.tv/discussion/1380/recovery-mode is all I've seen so far to force into recovery mode.
Click to expand...
Click to collapse
THis might be another option too:
tylerwhall said:
I started looking into bootloader-level recovery tonight before messing with the file system too much and potentially getting into a bad state. I couldn't find this information anywhere else.
Bootloader strap
On the back of the board in the center, there is an unpopulated button (U33). When jumped while the power button is pressed, this appears to put the bootloader into USB recovery mode. It enumerates with an nvidia vendor id. Presumably nvflash or tegrarcm could be used to unbrick the device.
I haven't done anything with the bootloader recovery since I haven't yet made a backup. I'm not sure how much of the functionality is allowed given the state of the production fuse, but I would think we could use this to at least get back to a stock state.
Click to expand...
Click to collapse
Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium
mybook4 said:
Some NVidia devices lock access out at the nvflash level unless you've got the manufacturer's key. I believe you get locked out with a 0x4 (nvflash's way of saying "go away").
Using fastboot is probably the quickest, easiest, and safest way to test new kernels.
Sent from my SCH-I535 using xda premium
Click to expand...
Click to collapse
ah he makes it sound like it puts you in USB recovery mode fo you could ADB in to push an update.
Just wanted to say I'm totally stoked on this guys! Can't wait to see what you do with this. Wish I could help, but I'm really not a developer.
i agree with rebel! but when you guys have it readyish ill test flash it and tell you what happens!!
So, OUYA isn't really as interested in being an open console as they suggest.
I'm keeping a track of how many requests we get relating custom firmware, and from what I'm seeing the user base is not as interested in custom firmware as you might think, which is echoed by this thread (we've shipped 60,000+ units, and less than 10 people have commented in the last month in this thread about getting access to recovery mode).
That doesn't mean that we're shooting the idea down, you need to keep in mind that in terms of priorities this is way down the list as you'd expect from any feature where it's being requested by less than one tenth of one percent of the user-base.
I'm sure @Wajeemba is familiar with CM requests that a very small minority of the user-base are very passionate about, so hopefully you can understand why we're not rushing to work on this.
Click to expand...
Click to collapse
Go to this thread and let them know we want support:
http://forums.ouya.tv/discussion/1380/recovery-mode
That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...
sonofskywalker3 said:
That's not even slightly surprising. If every user demanded CM10 they still wouldn't comply, because then they'd lose their one means of profit (ouya store), the fact that "nobody is asking for it" is their excuse, and they'll think of another one if that ever changes.
This is why we just need to proceed without them. I'm on week two of who knows how many weeks away from home on work, so my efforts at porting CM have been put on hold. Have you been able to make any progress? I'd totally loan my Ouya to Fattire or Dalingrin, or another whiz porter if they'd be willing to work on it...
Click to expand...
Click to collapse
I'd check with invisiblek about how to avoid bricking the OUYA. Apparently his is bricked. It's stuck in nvflash mode. I think it was a kernel written with a bad init.rc that did it. not sure though.
Sent from my Nexus 7 using xda premium
For anyone that is building their own kernels, I highly recommend grabbing this patch:
https://github.com/invisiblek/andro...mmit/f745249b52cab9feb5b7821b54d47176ae093617
Details in the commit comments.
You know what I've been hacking phones for awhile and I forgot about fastboot booting a boot.img
Haven't tried it, but sounds like nice work!
I had another idea for adding some safety - early in the boot process set the bootlloader message to tell the bootloader to boot into recovery mode (but don't actually reboot), then later when the boot is complete, reset the message. That way if the user reboots anywhere in between, they will boot into recovery.
Hope that makes sense, I brainstormed over the idea in another thread: http://forum.xda-developers.com/showpost.php?p=44030783&postcount=8
Feel free to implement any of my ideas you like - I don't have as much time for Android development as I would like.
~Troop
Trooper_Max said:
Haven't tried it, but sounds like nice work!
I had another idea for adding some safety - early in the boot process set the bootlloader message to tell the bootloader to boot into recovery mode (but don't actually reboot), then later when the boot is complete, reset the message. That way if the user reboots anywhere in between, they will boot into recovery.
Hope that makes sense, I brainstormed over the idea in another thread: http://forum.xda-developers.com/showpost.php?p=44030783&postcount=8
Feel free to implement any of my ideas you like - I don't have as much time for Android development as I would like.
~Troop
Click to expand...
Click to collapse
Yea, you could probably make the kernel write to scratch right away, in the case that it panics, dump it into recovery or bootloader, then clear it upon a full, successful boot. But that sounds like a lot more work and in the end, you really don't get anything more than this. This patch will save you from anything except a kernel panic that happens way early. (or of course blatantly flashing crap to the wrong partitions )
invisiblek said:
Yea, you could probably make the kernel write to scratch right away, in the case that it panics, dump it into recovery or bootloader, then clear it upon a full, successful boot. But that sounds like a lot more work and in the end, you really don't get anything more than this. This patch will save you from anything except a kernel panic that happens way early. (or of course blatantly flashing crap to the wrong partitions )
Click to expand...
Click to collapse
Ah, I was just thinking maybe it would be possible to write to scratch earlier than the sysrq method becomes available and thus be a little bit safer. It also wouldn't require a keyboard though that point would be a bit moot as you'd need a keyboard once you reboot into recovery. So you're right, it probably doesn't make much difference.
Have you ever done anything with kexec? That was the next thing I wanted to look into once we got something like this for booting more safely. I know people use it for multi-boot methods and someone even came up with a way to hardboot a Nexus 7 with kexec:
http://forum.xda-developers.com/showthread.php?t=2104706
Eventually, I'd like to develop something like that into a boot image that could be stored on the boot or recovery partitions and function as an extra bootloader to allow booting images stored elsewhere.
Anyway, thanks again for sharing your work, and I don't mean to hijack your thread - if you want to discuss ideas I had hoped more people would join in on brainstorming in my thread: http://forum.xda-developers.com/showthread.php?t=2380314
~Troop
Trooper_Max said:
Ah, I was just thinking maybe it would be possible to write to scratch earlier than the sysrq method becomes available and thus be a little bit safer. It also wouldn't require a keyboard though that point would be a bit moot as you'd need a keyboard once you reboot into recovery. So you're right, it probably doesn't make much difference.
Have you ever done anything with kexec? That was the next thing I wanted to look into once we got something like this for booting more safely. I know people use it for multi-boot methods and someone even came up with a way to hardboot a Nexus 7 with kexec:
http://forum.xda-developers.com/showthread.php?t=2104706
Eventually, I'd like to develop something like that into a boot image that could be stored on the boot or recovery partitions and function as an extra bootloader to allow booting images stored elsewhere.
Anyway, thanks again for sharing your work, and I don't mean to hijack your thread - if you want to discuss ideas I had hoped more people would join in on brainstorming in my thread: http://forum.xda-developers.com/showthread.php?t=2380314
~Troop
Click to expand...
Click to collapse
We used kexec on the vzw sgs3. It may be useful here but really probably isn't too necessary
Sent from my HTC6435LVW using Tapatalk 4
Hello! So, I've tried creating a device tree for the Leon LTE (H340n) based on ms345, and after some changes I've compiled TWRP for this specific model, with it identifying as c50n, which should allow for custom ROMs(I'm building LineageOS 13 right now, but don't get your hopes up) Also, there's a way to flash TWRP and get root on 6.0, here's a guide (https://forum.xda-developers.com/showpost.php?p=72501544&postcount=25) and you can flash my recovery instead.
Link: https://www.androidfilehost.com/?fid=961840155545578919
Sources: https://github.com/dadziokPL/android_.repo_local_manifests
Also, this recovery wouldn't work if it wasn't for Charles-IV's help on Github, a huuuuge thanks to him!
dadziokPL said:
Hello! So, I've tried creating a device tree for the Leon LTE (H340n) based on ms345, and after some changes I've compiled TWRP for this specific model, with it identifying as c50n, which should allow for custom ROMs(I'm building LineageOS 13 right now, but don't get your hopes up) Also, there's a way to flash TWRP and get root on 6.0, here's a guide (https://forum.xda-developers.com/showpost.php?p=72501544&postcount=25) and you can flash my recovery instead.
Link: https://www.androidfilehost.com/?fid=961840155545578919
Sources: https://github.com/dadziokPL/android_.repo_local_manifests
Also, this recovery wouldn't work if it wasn't for Charles-IV's help on Github, a huuuuge thanks to him!
Click to expand...
Click to collapse
Hi? The metro pcs version is what model? C50n? Also I found anoth4r version of twrp on 5he site twrp.me.. I saw twrp-3.1.1-0-c50.img... Is this appropriate? I hav the metro version and I'm confused what to use
jazzdglass said:
Hi? The metro pcs version is what model? C50n? Also I found anoth4r version of twrp on 5he site twrp.me.. I saw twrp-3.1.1-0-c50.img... Is this appropriate? I hav the metro version and I'm confused what to use
Click to expand...
Click to collapse
the official twrp one is for all c50 devices, but this one is specifically for the c50n, but im not sure how much of a difference it makes.
You can find out if yours is c50n or not in about phone.
Strange thing is its twrp 3.0.2 , and i cant find anything about this on the internet
Charles IV said:
the official twrp one is for all c50 devices, but this one is specifically for the c50n, but im not sure how much of a difference it makes.
You can find out if yours is c50n or not in about phone.
Strange thing is its twrp 3.0.2 , and i cant find anything about this on the internet
Click to expand...
Click to collapse
The difference is that the c50n did not have a device tree, there was no way to build custom ROMs, so I started working on a tree, and TWRP now compiles with it. It also identifies as c50n inside the recovery when checking compatibility with a ROM, so if I ever manage to get Lineage working, it will flash properly, being meant for THIS specific phone, the LG Leon 4G LTE aka H340n aka C50n. Previous TWRP was for all LG Leons, built on a common tree. With a specific tree, it allows for specific fixes for this device if needed in the future. The version is older since I used TWRP android6.0 branch, I could build an updated version, but right now I'm taking a break.
jazzdglass said:
Hi? The metro pcs version is what model? C50n? Also I found anoth4r version of twrp on 5he site twrp.me.. I saw twrp-3.1.1-0-c50.img... Is this appropriate? I hav the metro version and I'm confused what to use
Click to expand...
Click to collapse
MetroPCS is ms345, I just needed a base for C50n, the international LG Leon 4G LTE. The devices are similiar, so I thought I could use the existing ms345 tree to create a tree for the C50n. I don't know if there is a specific TWRP for the ms345, if there is, you should find it and use it. If not, the C50 from twrp.me should work. Also, my recovery for C50n should work too, just try flashing, if some **** goes sideways, just flash another one and try again. The difference is basically what TWRP thinks your device is, and if you flash a ROM for ms345 it would expect your recovery to be for ms345, and not anything else. Get it?
Hey, I'm from Brazil and I own a H342 model of this cellphone.
I was thinking about installing the v20b marshmallow kdz released for H340 because I'm done with the ***ty, ugly and laggy 5.0.1 build, but I know that even if the processor is the same for both devices the baseband will still differ.
You know how can I install 6.0 and flash the baseband from the H342 after?
Sorry for any concordances errors and thank u for your time
mateus.sc said:
Hey, I'm from Brazil and I own a H342 model of this cellphone.
I was thinking about installing the v20b marshmallow kdz released for H340 because I'm done with the ***ty, ugly and laggy 5.0.1 build, but I know that even if the processor is the same for both devices the baseband will still differ.
You know how can I install 6.0 and flash the baseband from the H342 after?
Sorry for any concordances errors and thank u for your time
Click to expand...
Click to collapse
Sorry about the lateness, but don't do it.
The baseband was built with code specifically for lollipop, flashing it on top of marshmallow will most likely lead to incompatibility.
What about LineageOS?
rusiu559 said:
What about LineageOS?
Click to expand...
Click to collapse
Any news ?
rusiu559 said:
Any news ?
Click to expand...
Click to collapse
None other than it might take a long time. @dadziokPL has a lead on what the current error is though.
Charles IV said:
None other than it might take a long time. @dadziokPL has a lead on what the current error is though.
Click to expand...
Click to collapse
It's all going so terribly wrong tho. I've managed to get it to compile, but it does not boot. Goes to "AP Watchdog bark" green screen, so probably can't even boot into the Linux kernel, since if it did we'd get some boot animation and logcats. I'm totally stuck.
Also, the recovery does not boot anymore, I'm gonna revert some commits up until you merged all the common trees, modular approach is much better
dadziokPL said:
It's all going so terribly wrong tho. I've managed to get it to compile, but it does not boot. Goes to "AP Watchdog bark" green screen, so probably can't even boot into the Linux kernel, since if it did we'd get some boot animation and logcats. I'm totally stuck.
Also, the recovery does not boot anymore, I'm gonna revert some commits up until you merged all the common trees, modular approach is much better
Click to expand...
Click to collapse
Yes, I was worried that I might break something with the merging, but we can re-merge when everything's working to see if it does break things.
The kernel might need to be modified - all I did is went onto lg leon's source code site and downloaded the H340N one. It contained two zips, one with the kernel in, and one supposedly with the rest in, but it was really messed up and I couldn't get it working.
I'll build the kernel in that tree using their instructions (not sure what I'll get!) and we'll see if we can use that as a prebuilt kernel.
Is your bootloader definitely unlocked? I remember getting a greenscreen when I was messing about with the partitions, trying to put the recovery on it etc.
Charles IV said:
Yes, I was worried that I might break something with the merging, but we can re-merge when everything's working to see if it does break things.
The kernel might need to be modified - all I did is went onto lg leon's source code site and downloaded the H340N one. It contained two zips, one with the kernel in, and one supposedly with the rest in, but it was really messed up and I couldn't get it working.
I'll build the kernel in that tree using their instructions (not sure what I'll get!) and we'll see if we can use that as a prebuilt kernel.
Is your bootloader definitely unlocked? I remember getting a greenscreen when I was messing about with the partitions, trying to put the recovery on it etc.
Click to expand...
Click to collapse
Yeah, the bootloader's got to be unlocked since old TWRP boots fine
dadziokPL said:
Yeah, the bootloader's got to be unlocked since old TWRP boots fine
Click to expand...
Click to collapse
I'm trying to figure out a way of how to unmerge, and restore the combined branch it was on - i spent so long on that! -_-
To me it looks like the error is to do with the bootloader rejecting it. Could it me something to do with the system.prop. Fingerprints, maybe?
Charles IV said:
I'm trying to figure out a way of how to unmerge, and restore the combined branch it was on - i spent so long on that! -_-
To me it looks like the error is to do with the bootloader rejecting it. Could it me something to do with the system.prop. Fingerprints, maybe?
Click to expand...
Click to collapse
I have completely no idea what the problem is. I'm gonna hard reset the repo to the last commit before the merge, but we'll lose all commit history after the merge. We'll have to start over from before you merged it all. Why'd you even do it? It was totally fine being modular
dadziokPL said:
I have completely no idea what the problem is. I'm gonna hard reset the repo to the last commit before the merge, but we'll lose all commit history after the merge. We'll have to start over from before you merged it all. Why'd you even do it? It was totally fine being modular
Click to expand...
Click to collapse
Well I'm used to a single device repo, so I tried merging it, to see if it worked. Personally I didn't like having 3 repos to look at, but three of each file is also hard!
Tbh I was surprised when you pulled it, I just did it as an experiment.
Charles IV said:
Well I'm used to a single device repo, so I tried merging it, to see if it worked. Personally I didn't like having 3 repos to look at, but three of each file is also hard!
Tbh I was surprised when you pulled it, I just did it as an experiment.
Click to expand...
Click to collapse
I thought maybe you did something important with the merge and just pulled it, but it seems like it broke it. Anyway, now I know how to revert commits, so I'll be building the recovery, and if it does not work, I'll just revert one commit back and gradually figure out at what point it broke.
dadziokPL said:
I thought maybe you did something important with the merge and just pulled it, but it seems like it broke it. Anyway, now I know how to revert commits, so I'll be building the recovery, and if it does not work, I'll just revert one commit back and gradually figure out at what point it broke.
Click to expand...
Click to collapse
When you've got recovery working, if booting still doesn't work, let me know, I've noticed a minor difference in fingerprints and build description (the same difference) in my build.prop compared to the build prop overrides. It is probably because they are different builds, and shouldn't make a difference, but if it's not working, I'll try it.
On a side note - if we change the overrides, in theory, with suhide, it should pass safetynet!
Charles IV said:
When you've got recovery working, if booting still doesn't work, let me know, I've noticed a minor difference in fingerprints and build description (the same difference) in my build.prop compared to the build prop overrides. It is probably because they are different builds, and shouldn't make a difference, but if it's not working, I'll try it.
On a side note - if we change the overrides, in theory, with suhide, it should pass safetynet!
Click to expand...
Click to collapse
Okay, so the merge must have screwed something up, since recovery works perfect now! I'll be back to building now. Also, I'm not building Lineage anymore, I switched over to RessurectionRemix, it's totally awesome.
Edit: You know what. I'm actually going to build the kernel itself for now and see if it works, since I'm on a CM12.1 ROM for ms345, it works but is quite bugged. I'll do an experiment and try to flash the kernel I'll build. Probably won't work, but I'll see what will happen
Edit 2: Okay, green screen again, I'll try to build the full ROM again, if that happens again, that is bad news, since I have no idea how to fix this thing.
Just another edit: I have an idea. I just downloaded the Qualcomm QPST tool, I might be able to debug this. No promises tho, we'll see.
dadziokPL said:
Okay, so the merge must have screwed something up, since recovery works perfect now! I'll be back to building now. Also, I'm not building Lineage anymore, I switched over to RessurectionRemix, it's totally awesome.
Edit: You know what. I'm actually going to build the kernel itself for now and see if it works, since I'm on a CM12.1 ROM for ms345, it works but is quite bugged. I'll do an experiment and try to flash the kernel I'll build. Probably won't work, but I'll see what will happen
Edit 2: Okay, green screen again, I'll try to build the full ROM again, if that happens again, that is bad news, since I have no idea how to fix this thing.
Just another edit: I have an idea. I just downloaded the Qualcomm QPST tool, I might be able to debug this. No promises tho, we'll see.
Click to expand...
Click to collapse
The kernel is probably originally for aosp 6.0.
Personally I think Lineage is better, but then I've never personally used RR.
I'll also make the fingerprint commits.
edit: trying to figure out how to only make a pr of one commit to your tree.