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

DONE (updated 2018-02-14 a lot stuff finished and moved here):

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%

re-upload all UsU files for each model

prepare due to massive UsU changes --> 100 %

upload --> 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 => https://www.diffchecker.com/TDXZ6i6U

Porting & testing DirtySanta kernel patch --> 60%

NEW

: build kernel with 20g sources and checking defconfig! --> 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%

NEW

: Porting & testing DirtySanta kernel patch to

20g

--> 50% lol yea they had the same problem then UsU now has. and they fixed it! So I currently try to implement those for the G4.

stuff that happens on the way..

release FWUL v2.5 --> 90%

creating release thread including the full glory guide

Content --> 95% finished

Release thread --> 0% finished

Thx all for your patience

sfX