yashsingh1/xdaforums huggingface dataset:
[G4 General] scholbert:
Thanks, i read about the trouble with the touch some days ago. So in the end i found some time yesterday to look a little deeper.

Anyway, i don't want to confuse people here by leaving obscure descriptors of components on the mainboard, but hopefully things got clear :D

So back on track...

After having a short look at some example code of aboot, i guess you're right. There are parts in bootcode which iniate the PMICs (general PM stuff as well) but that's not the task of aboot.

Would be intersting where the cmdline is derived from, because there are lots of different "key words".

At least there is (on my H815):

model.name=LG-H815

So this could be the key element in the end. There's nothing specific related to initiating touch controller or something.

The display is covered separately but there's no relation.

Another thing of interest would be the DTB file of course.

BTW, on the H815 the GPIO_63 pin is unused and left unconnected...

I didn't knew untill now (maybe i overread it), that you are able to mix up the bootloader stack and make it work.

BTW, this is really excellent work, congrats!!

Again to refer to the command line this could be fixed up in parts of kernel code where the ATAGs are read, but i guess you know :angel:

Maybe use ADB and after a fresh reboot you could try:

adb shell

dmesg > /sdcard/Documents/dmesg.txt

exit

adp pull /sdcard/Documents/dmesg.txt

At least on my H815 there's no root required and you could easily find the cmdline of the kernel in this text file.

... and there's the grep command of course :o

Cheers,

scholbert
[G4 General] muzadull:
LG 818P on Nougat V29 Dmesg
[G4 General] steadfasterX:
Absolutely... Hmm some months back where I started compiling TWRP I encountered an issue regarding this btw. They changed the way how they load the kernel and so I had to compile different on MM (dtb related). This cannot be an issue here as TWRP e.g. can be loaded so it's able to boot. If it would be a missing dtb it would reject to boot. If the dtb itself would be wrong the h818 stock boot image and ROM shouldn't have any issues. But they have the same problem!

I already found out that there is a check within the baseband files which expects a correct value in the boot cmdline and if not the modem crashes. So it's very likely that we have a similar behavior for the touch on the h818. It's good to know that there is some more hardware stuff different then thought btw. so thx for that.

Regarding the ATAGS I'm not sure but it's easy to just replace the cmdline in its whole on boot. If you know a better way lemme know..

Besides that I'm thinking of using the init stuff I use in TWRP to identify the different models. It's just a small init cpp which checks the UsU model and depending on that I set some props on TWRP but I will use that to set the cmdline later. This way we do not need a kernel for every device if not required.

Great thx! But it's not directly after booting to android. Pls try again directly after a fresh boot.
[G4 General] muzadull:
I hope this is it.
[G4 General] steadfasterX:
Perfect ;)
[G4 General] scholbert:
Yepp...

It seems to be all there... but something prevents it from getting activated. So search for lge.sim_num=2.

In:

arch/arm64/boot/dts/lge/msm8992-p1_global_com/msm8992-p1_global_com-panel.dtsi

There's:

...
lge,platform-touch-io = <&msm_gpio 63 0>;
...

In:

drivers/video/msm/mdss/mdss_dsi.c

There's:

...
#if defined(CONFIG_MACH_MSM8992_P1_GLOBAL_COM)
if (lge_get_sim_type() == 2) {//Dual Sim
if (!strcmp(st,global_dual_tpio)) {
pr_info("%s: Global dual sim doesn't register tpio ldo power\n", __func__);
mp->num_vreg--;
continue;
}
}
#endif
...

In:

drivers/video/msm/mdss/lge/panel/oem_mdss_dsi.c

There's:

...
#if defined(CONFIG_MACH_MSM8992_P1_CN) || defined(CONFIG_MACH_MSM8992_P1_GLOBAL_COM)
if (lge_get_sim_type() == 2) {
ctrl_pdata->lge_pan_data->touch_io = of_get_named_gpio(ctrl_pdev->dev.of_node,
"lge,platform-touch-io", 0);
}
#endif
...

In:

drivers/soc/qcom/lge/devices_lge.c

There's:

...
#if defined(CONFIG_MACH_MSM8992_P1_CN) || defined(CONFIG_MACH_MSM8992_P1_GLOBAL_COM)
static int __init lge_sim_setup(char *sim_num)
{
if (strncmp(sim_num, "1", 1) == 0) {
lge_sim_type = 1;
} else if (strncmp(sim_num, "2", 1) == 0) {
lge_sim_type = 2;
} else {
lge_sim_type = 0;
pr_err("%s : fail to read sim type\n", __func__);
}
pr_debug("lge_sim_type is %d, sim_num set %s= \n", lge_sim_type,sim_num);

return 1;
}
__setup("lge.sim_num=", lge_sim_setup);

int lge_get_sim_type(void)
{
return lge_sim_type;
}
#endif
...

In other words:

Only if lge.sim_num=2 is set in the cmdline, the LDO on H818 get's properly setup!

...or the other way round:

If lge.sim_num=1 is set on H818 it will fail to power up the touch IO-Voltage.

So this could be the missing/wrong parameter...

If this all doesn't make sense, you're welcome to correct me.

P.S.: Sorry for this code snippery :o

Cheers,

scholbert
[G4 General] steadfasterX:
Nope it makes totally sense and is just the proof for what I wrote :)

Thanks for the code snippets highly appreciated as I have no pc atm ;)

This can be solved easily.

Btw flashing UsU is a irreversible process. Usually..

But... I know a way to test UsU without actually flashing it. That means the risk is very low when I have setup all stuff when back..

Another great news right? ;)
[G4 General] AlexBodewig:
A keyboard/mouse combo over usb-otg could be used to do some things that normally can't be done without touch input on UsU H818 devices. I don't know if otg input works in twrp but maybe it would be useful to find out? Just a thought.
[G4 General] steadfasterX:
Thx but as said adb works fine ;)
[G4 General] mateus.sc:
Oh my.. so UsU is irreversible even in H815 with ARB 0?

I will be able to flash a kdz(from H815P wich is my version and/or a H815 one) if needed after unlocking with UsU?

thank you for the clarification
[G4 General] Vishnuisgod:
Amazing Grace!

So i have read all through 38 pages of this thread;

steadfastX; Sir you are as stubborn as I am, like a mule!

I thankyou for doing this amazing feat of mental gymnastics. It is a puzzle of the grandest scale!!

I am a bit dismayed though,

do I have to learn how to use linux (your FWUL) to use Salt? or should I just wait?

I have started to read the FWUL thread, Im feeling overwhelmed.

Ive tried to run Salt but come up with zilch. IM pretty good with computers, but this is a bit beyond my reach.
[G4 General] steadfasterX:
Once UsU is flashed no kdz can be used anymore. At least not with lgup. You will be able to flash a kdz later when it's available in SALT which will happen.

Keep in mind that UsU is different from the previous tries. It keeps your bootloader stack so the device model specific modem etc gets initialized correctly and everything else as well. The touch issue is different but will be solved for the h818 soon. When I have my device back the 5th time now from LG and when back from vacation I will try another method to see if I can workaround that but I guess not. We will see. Again UsU will let you initialize the hardware as it should be and if not we can fix it in the kernel. That's the good with UsU ;)

To be crystal clear: once flashed you have to use and keep UsU otherwise you will brick. That's all written in my (not yet released) guide too.

Plus: UsU will NOT increase or blown a ARB fuse! It will blow another but you can still use bootloader stacks with ARB 0 later. How will be explained when released.

Thanks. Yea my nickname is for a reason ;)

FWUL is made for users not familiar with Linux. So the only thing you need to learn is how to flash FWUL on an USB stick. Just try to boot it ( I recommend the nightlies v2.5 persistent. you can find the url to the nightlies in the FWUL OP). V2.5 has SALT included already so it's just a double click away.
[G4 General] spyknee:
Is this at all possible with a VS986 that has been updated to mm ver xxxxBA?

I hate my G4, had hoped in begining it would be unlocked. I unlocked all other vzw phones to major advantages. But LG decided to kiss vzw seat. Stifled there own product. Well if this is possible with my current VS986 LG G4 device, I would risk a bricking in a heart beat. I need to know if I should read all the stuff basically, which I will gladly do if theres a chance to free my LG G4.

ty
[G4 General] steadfasterX:
Ofc it works with your model!

If you want to participate and being the first vs986 device write me a pm with the model name in the subject
[G4 General] steadfasterX:
Sorry for being off topic but it will explain why everything will delay..

29.01.2018 - 12:05 AM

Our dog Nando ( https://bit.do/nandoline ).. 15.5 years old died today in our arms.. His heart had just stopped. We knew that this will happen one day but when it happens it comes too soon..

R.I.P. you was and will be the best which had happened to me

-
[G4 General] DoughMucker:
Nice looking dog. We lost our 13.5 year old "puppy" last September. I know what you are feeling.
[G4 General] mercury54:
Further to neutrondev's response above regarding Qualcomm's QFUSEs, here's a quote by cb474 in his post on another thread (https://xdaforums.com/showpost.php?p=63543970&postcount=4) which helps explain the relevance of a particular QFUSE to bootloader security:

Some members seem to draw an equivalence between (one or more) QFUSEs and the Anti-rollback Version number specific to a device's Android version ;however it remains unclear to me whether the two have anything to do with one another .

Edit:

As neutrondev has indicated below, it's conceivable that anti-rollback protection is implemented using QFUSEs on the G4. Note that, according to the source of the above quotation, QFUSEs are used to store a wide variety of information about the device (at least on the Motorola device under discussion), possibly including whether bootloader unlocking is permanently disabled.
[G4 General] neutrondev:
It depends on the manufacturer and on the use of the QFUSE, YES! Qfuses can be used and ARE USED for downgrade protection in some devices.
[G4 General] mercury54:
Thanks neutrondev for the information on that particular use of QFuses. Can you recommend any other internet resources that explain more about QFuses, especially in relation to the MSM8992 used in the G4?
[G4 General] BIG_BADASS:
Yes sir, you can confirm the AntiRollBack value by doing the following:

1. Open the phone app

2. In the dial-pad, enter the following code: *#546368#*(Insert last three digits of your model*number)#

In your case, it will be *#546368#*812#

3. Click SVC Menu

4. Click Version Info

5. At the very bottom, you should see the Anti-rollback value set to 0
[G4 General] steadfasterX:
thank you guys for those explanations!

I added your both posts to the OP and changed the title as well.

.
[G4 General] neutrondev:
You can see how they work by reading code in the kernel that accesses the tz. They are very undocumented.
[G4 General] steadfasterX:
1 Limitation solved

TWRP does not detect the device (easy to fix though)

(I will add the proper detection in the official TWRP once the other stuff is done or when I get bored before then earlier) - SOLVED (see post #)

see attached TWRP image. It will detect the device as LS991 atm which may change later but for the moment its better then <detectfailed>

.
[G4 General] onotor:
I got nothing to be shown in the Version Info.. At the bottom there's only the SEPolicy Version. Does that mean I cannot test the unlock attempt ?
[G4 General] steadfasterX:
The exact requirements for this are currently not completely known and proven

what device model do you own?

.
[G4 General] onotor:
H815 SEA V10C Rooted
[G4 General] steadfasterX:
then its very likely to work for you.

.
[G4 General] rockapoc:
I'm on an H812 running 5.1 rooted (LMY47D/H81210o) and my Version Info also ends at SEPolicy Version. No Anti-Rollback Value listed.
[G4 General] TheMadScientist:
I never woulda guessed a sprint g4 would bring any good to the world.

like i said if u need any help on a sprint g4 Im here, would love to see some wonderful things happen here.

might lead to a way to reflash my ls992 in the future to another model num to fix the hard brick,

The future of unlocked lg flashing rests in your hands brother. lol
[G4 General] stillsober:
hi, where did you get the v10c SEA image from? I've only found v10b from the storagecow repo. v10b has a bug where whenever you restart, the brightness goes to Maximum
[G4 General] onotor:
Actually it's an Europe KDZ and I don't know where to find it.. It's been a long time
[G4 General] steadfasterX:
Good news:

---------------------------

We have a h810 user [MENTION=8145367]Chebhou[/MENTION] whose device is now "unlocked", everything is working especially cell service working, mobile Internet working (no 4G test possible so we can say up to 3G only). And no he is not a sprint user and not in the US!

Thanks for all your time and continuous help again [MENTION=8145367]Chebhou[/MENTION] !

Bad news:

---------------------------

I tried the same way as done by chebhou but whatever I try I can't get my cell service working.

Box/Dongles:

---------------------------

The usage of this approach is just needed for the case that the other methods I'm trying doesn't work so at the end we may not need it but as we don't know atm..

Infinity box/dongle arrived. Doesn't work for me! 75 Euro for the trash.. :crying:

Ordered another dongle: octoplus LG lite! This dongle officially supports all h81x devices! That was not the case for the infinity dongle (only a generic qualcomm support) so I hope this one will work better..

ETA next week.

.
[G4 General] BIG_BADASS:
Is this reversible?
[G4 General] steadfasterX:
Really? Again? Asking things already answered in the OP?

To all who do not know this member:

He do this above all the time.. On many threads.. Besides giving advices which are not proven (without telling the users so) and simply wrong ones leading new users to damage their devices.

Last but not least his account gets disabled twice due abusive behavior.

That why I'm reacting this way.

.
[G4 General] BIG_BADASS:
If it doesn't explicitly state it, people are going to question before following any further steps.
[G4 General] steadfasterX:
I guess u havent read the OP at least once..

Do you have seen anyone here asking for this? No?

I'll tell you a secret: Its because they read the OP.

Do you have seen any explicit instructions a user has to do here?

No? Only some general one to get an idea what I currently do?

Its because this is a WIP (as stated in the title and OP).

Until this hasn't been finished no fully detailed instructions will be given.

.. but as u may irritating others here the mentioned excerpt of the OP (just for you as u are too lazy to read it) !

if you still not able to understand this, just leave it.

You do not own a device which needs to be unlocked and so stop irritating ppl.

thx

.
[G4 General] doop:
Condolences, losing a pet is like losing a best friend. :(
[G4 General] good4y0u:
Dogs are a amazing. I am so sorry for your loss.
[G4 General] Vishnuisgod:
My heart goes out to you and your family.

Losing a pet is heartbreaking. i wish my words brought you sollace.
[G4 General] augusto1024:
Any news on the release of UsU to the public? ☺
[G4 General] steadfasterX:
The current state and to-do list for the public release is (the major ones):

1) I need to fix or at least get a proof of a workaround if someone encounters issues like the h818. For this I work together with [MENTION=290214]JME[/MENTION]fcon as I do not own that device but we both have a real life so it takes its time

--> 50% finished

2) I need to prepare an UsU LAF partition to avoid users flashing a wrong kdz after UsU has been flashed

3) prepare a full debug LOS build for those encountering a bootloop after flashing

4) re-upload all UsU files for each model

5) creating release thread including the full glory guide

--> 90% finished

6) stuff that happens on the way..

Thx all for your patience

sfX
[G4 General] Pete_Mitchell:
Seriously I hope you can have the reward in money to root the lg g4... You damned deserve it.

I was wondering if the 29A rom has the code for the qualcom engineering mode which can be used to root the phone as pubblically known....Being a beta the chances can be very high... who can check it?
[G4 General] steadfasterX:
The current state and to-do list for the public release is (the major ones):

1) I need to fix or at least get a proof of a workaround if someone encounters issues like the h818. For this I work together with [MENTION=290214]JME[/MENTION]fcon as I do not own that device but we both have a real life so it takes its time

--> H818 kernel: 100%

--> H818 TWRP: 100%

--> Unbrick jmefcon's device (he accidentially bricked it before I was able to do anything): 80% (another remote session required)

--> Test H818 TWRP: 10% (boots up fine on my device but we need to test it on the h818 ofc)

2) I need to prepare an UsU LAF partition

selinux=permissive --> 100%

UsU stuff --> 100%

3) prepare a full debug LOS build for those encountering a bootloop after flashing

--> 0 %

4) re-upload all UsU files for each model

--> 0 %

5) creating release thread including the full glory guide

--> 90% finished

6) Test if we can workaround the baseband modem identifier (producing crashes if the device is not prepared)

override-kernel h815 --> 50%

override-kernel for every model? --> 0%

7) stuff that happens on the way..

currently my device bootloops into dl mode --> WTH?! - lol during all the journey I never had seen this behaviour but it seems it occurs when a partitions flashed is not compatible.. flashed back my whole stuff and back in the game. nice LG.

Thx all for your patience

sfX
[G4 General] steadfasterX:
current state and (unsorted) to-do list for the public release is (the major ones)

I need to fix or at least get a proof of a workaround if someone encounters issues like the h818. For this I work together with jmefcon as I do not own that device but we both have a real life so it takes its time

--> H818 override kernel: 100%

--> H818 TWRP: 100%

--> Unbrick jmefcon's device (he accidentially bricked it before I was able to do anything): 100%

--> Test H818 TWRP: 100%

--> analyzing root cause (again).

Current assumption: the lge.sim=2 is not enough ( [MENTION=557802]scholbert[/MENTION] ) and it seems it "just" can not load the firmware PLG468 as it is not able to identify the IC_product_id

If anyone wants to help:

Working

H818 dmesg,

Non-Working

H818 dmesg

H818 kernel sources

Product ID ident: here

I need to prepare an UsU LAF partition

selinux=permissive --> 100%

UsU stuff --> 100%

prepare a full debug LOS build for those encountering a bootloop after flashing

--> 50 % (build ready - test needed)

Enhance UsU flashing!... a

LOT

!

include UsU laf (dl mode) --> 100 %

include rawres (real model detection, boot logos) --> 100 % - ha ! that one is nice .. each model can have a different GPT and while laf and aboot are always at the same sectore for all the raw_resources one can be different. SALT will parse the current active GPT and so identifies the correct start sector for flashing..

creating release thread including the full glory guide

--> 90% finished

Test if we can workaround the baseband modem identifier (producing crashes if the device is not prepared)

override-kernel h815 --> 50%

override-kernel for every model? --> 0%

stuff that happens on the way..

currently my device bootloops into dl mode --> WTH?! - lol during all the journey I never had seen this behaviour but it seems it occurs when a partitions flashed is not compatible.. flashed back my whole stuff and back in the game. nice LG.

Reviewing new exploit: https://alephsecurity.com/2018/01/22/qualcomm-edl-1/

re-upload all UsU files for each model

--> 0 %

Thx all for your patience

sfX
[G4 General] Jonotjie:
I wish I could add to the work you do or be of any sort of help. I follow this thread closely and can't wait for you to be finished. I can't thank you enough for all the hard work you are putting into this.

Thank you!! :)
[G4 General] obvious:
Wow, that alephsecurity work is impressive
[G4 General] 01189998819991197253:
Donated. Been holding onto my G4 since 2015, hoping someone would eventually crack the bootloader. Thank you steadfasterX and co. for all your hard work! Can't wait for the public release! :good:
[G4 General] sushant_:
Will this enhanced method work with unlocking nougat versions as well(LG F500L).
[G4 General] terence.tan:
I only looked at this briefly. Here's some thoughts. There are 2 ways of doing this: the quick and dirty way, or the long and correct way.

The quick and dirty way: hard-code to return "2" from drivers/soc/qcom/lge/devices_lge.c:322 (this would require a separate branch for H818 but I suppose that's already required for "lge.sim_num=2")

The long and correct way: I suspect the modified aboot.bin is loading the device tree for LS991, which it then passes to the kernel. (Google's docs on how it works.) Given we can't change the board detection logic in aboot.bin, you'd could try copying the device tree overlay for H818 into the slot used for LS991. (Located in the boot partition, between the kernel code and the initial ramdisk.) This would require lots more debugging, but may be better for compatibility for other hardware devices too...

Someone else can analyse further...
[G4 General] steadfasterX:
UsU can be flashed in 4 ways:

- internal storage (SALT: LP, MM)

- external sdcard (SALT: LP, MM)

- direct (SALT: LP and all MM with laf v1)

- QFIL (LP, MM, N)

So yes UsU can be flashed when on N but QFIL is extremely(!) risky, can produce total loss of all data (recover possible when you have a SALT backup), can damage the device (when using the wrong programmer) and it will be released much later as a fallback method only.

Yes I already have a separate h818 branch and when i create the boot image for the h818 a dtb is build and will be used on boot. So I'm not sure if the dtb is the problem here I may be wrong?!

The hard coded return is worth to test anyways! Thanks for your help my C and C++ is very limited..
[G4 General] Ilaancue:
So, the ones who updated to the Nougat beta should downgrade to MM in order to use UsU in a "secure" way?
[G4 General] steadfasterX:
I hoped to break newer laf protocols for allowing me to write in download mode but many attempts to reach that all failed.

LG changed the protocol and so I cannot simply write anymore on N. I still try to reach this goal but it's not my main focus atm.

So the answer is:

yes N can NOT be used for a safe flashing. The newer SALT versions are displaying the LAF protocol version which identifies how you can flash. i. E. it must be 10001 for a direct flash. You CAN have a higher version (like 10002 or 10004) and flash via sdcard or internal storage method but all will fail when you have 10006 (N bootloader stack).

Btw SALT will show direct flashing method only when your device supports it. Every other option can be tried without a harm though as I have implemented a pre-check including verification for EVERY flashing method ;) I try to make it as safe as possible before the real flashing happens (due to all my past experience I made...)
[G4 General] Ilaancue:
So, once downgraded I will be able to flash through UsU method, and then, will I be able to flash a N custom rom or will I have to stay with a MM?

Thanks for your hard work and your dedication when answering doubts
[G4 General] steadfasterX:
Yes downgrade, flash UsU, then flash LP, MM, N, O.. whatever you like

All details about the "how" will be in the guide once released :)