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

For stuff already

DONE

(only release stuff not the whole story which would break XDA.. ;) ) click the button:

build kernel with 20a sources and checking defconfig! --> 100%

I need to prepare an UsU LAF partition

selinux=permissive --> 100%

UsU stuff --> 100%

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..

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

build and test --> 100 %

TWRP

add new UsU kernel (correction of backup path etc) --> 100%

adapt TWRP UsU detection to new UsU kernel --> 100%

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/ --> 100% (nothing I can do - and its not needed due to UsU)

adding UsU kernel configs for every model --> 100% introduced by this commit

release SALT v3.6 --> 100%

[/U]release FWUL v2.5 --> 100%

YEA! finally. FWUL v2.5 contains latest and full working SALT release so if you wanna prepare yourself download FWUL v2.5 (I

highly

recommend to use any of the

persistent

variants!)

re-upload all UsU files for each model

prepare due to massive UsU changes --> 100 %

upload --> 100 %

release FWUL v2.5 --> 100%

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

override-kernel h815 --> 100% Unfortunately modifying the kernel cmdline does not fix the modem crash :(

dtb appended kernel test --> 100%

H818 Touch is not working (this will

not

delay the release - I very likely will release without support for the h818 first)

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) and identify the real issue -> 20%

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

Besides that the 2 dmesg files are from different devices and they seem to have a different LCD panel?! wtf..

If anyone wants to help:

Working

H818 dmesg,

Non-Working

H818 dmesg

H818 kernel sources

Product ID ident: here

The complete diff 1 (left = working, right = not working) => https://www.diffchecker.com/TDXZ6i6U

NEW

:The complete diff 2 (left = working, right = not working) => https://www.diffchecker.com/0kaYDl9h

Porting & testing DirtySanta kernel patch on 20g/h --> 60%

build kernel with 20g sources and checking defconfig! --> 100%

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

NEW

: Porting DirtySanta kernel patch to

h815 TITAN

--> 100%

AMAZING break through here! Actually dirtysanta does

NOT

(fully) work atm.....but! based on it I was able to use hardcoded values to modify SMEM.

In plain words: After flashing UsU it was not possible to use the basebands of N modem - now

it IS

!

NEW

: I have only one issue left: writing the model name not hardcoded but based on the kernel defconfig. --> 100%

As this is a kernel change the ROMs will need to apply this ofc. Regardless UsU will be released together with a workaround TWRP zip which can be flashed for ROMs not having my kernel patch.

NEW

: unified UsU kernel --> 20% will be based on the unify TWRP code and ensures we do not need to create just a new ROM because of a kernel variable. well unfortunately this requires a COMPLETE new implementation as it will run as a driver in the kernel. Very hard for me but finally I solved all compilation errors for a first PoC of this. This first test will just print the real model nothing else. State atm: kernel panic :rolleyes: well as said this one will be hard for someone with only a very limited C know-how but it's worth it.. If i can't get it working I need to build for every model it's own kernel and so ROM. Anyone here with C knowledge willing to help?

stuff that happens on the way..

Create generic laf partition for SALT (enable flashing) --> 0%

creating release thread including the full glory guide

Content --> 95%

Release thread --> 0%

Thx all for your patience

sfX