[UNOFFICIAL] LineageOS 19.1 for Amlogic G12*/SM1 Family Devices

[npjohnson]

So that means that for the supported devices that use encrypted bootloaders, the bootrom keys for each device were extracted so as to be able encrypt each supported device's "own newest boot loader" for each of these builds?

None of these devices have encrypted. Bootloaders or boot rom passwords except for Sabrina, which has a whole write up on how we did it

 

[RDS5]

For what device? dopinder is broken at the moment. yes.

That's... bad. I'll fix it.

Yes, each device has it's own newest boot loader packed in which matching TEE applets.

im using wade, trying the same exact procedure on both 18.1 and 19.1 is different.
when i flash and then boot into 18.1 recovery, it all works as expected.
when i flash and then TRY to boot into 19.1 recovery, nothing happens.
if i try flashing 19.1 from 18.1 recovery, it starts acting up in the os, and if i try rebooting into recovery after that, it gets stuck on the boot logo (probably because it freezes up when trying to boot into 19.1 recovery).

 

[goapy]

None of these devices have encrypted. Bootloaders or boot rom passwords except for Sabrina, which has a whole write up on how we did it

When looking at a factory original bootloader.img for the deadpool (adt-3) in a hex viewer, at offset 10h there is:

@AML (hex: 40 41 4D 4C)

While for the dopinder (onn) bootloader.img at offset 0h there is:

hex: 9B DF 1A 47, with no sign of the AML magic anywhere to be found.

For wade (dynalink) it's the same, no AML magic, but different hex values at the start of bootloader.img.

What distinguishes the deadpool bootloader.img (with AML magic) from the dopinder and wade bootloader.img contents?

Are the dopinder and wade bootloader.img contents just compressed rather than encrypted, or else why is the raw hex structure so different as compared to deadpool?

 

[npjohnson]

When looking at a factory original bootloader.img for the deadpool (adt-3) in a hex viewer, at offset 10h there is:

@AML (hex: 40 41 4D 4C)

While for dopinder (onn) bootloader.img at offset 0h. there is:

hex: 9B DF 1A 47, with no sign of the AML magic anywhere to be found.

For wade (dynalink) it's the same, no AML magic, but different hex values at the start of bootloader.img.

What distinguishes the deadpool bootloader.img (with AML magic) from the dopinder and wade bootloader.img contents?

Are the the dopinder and wade bootloader.img contents just compressed rather than encrypted, or else why is the raw hex structure so different as compared to deadpool?

They're entirely different.

BL2 on wade/dopinder is older, newer on Deadpool, u-boot is built on completely different revisions for BL33.

They are stored in a proprietary format. See Sabrina writeup on how to tear them apart (minus the encryption).

 

[goapy]

They're entirely different.

BL2 on wade/dopinder is older, newer on Deadpool, u-boot is built on completely different revisions for BL33.

They are stored in a proprietary format. See Sabrina writeup on how to tear them apart (minus the encryption).

I've read the sabrina writeup, both yours and fred's, dozens (if not hundreds) of times.

My prior understanding and experience has been that if the AML magic was present at the start of bootloader.img, then that bootloader would at least boot on just about any generic amlogic device that wasn't configured to use an encrypted bootloader.

But if the AML magic wasn't present, then only a bootloader.img that started with the same string of bytes as the original would ever boot. I assumed this was because the bootloaders were differently encrypted. This was the case even of differently branded variants of the same device that were otherwise physically identical and most likely used the same revision of BL33.

It appears that I was wrong and I need to reassess my understanding.

 

[npjohnson]

I've read the sabrina writeup, both yours and fred's, dozens (if not hundreds) of times.

My prior understanding and experience has been that if that AML magic was present at the start of bootloader.img, then that bootloader would at least boot on just about any generic amlogic device that wasn't configured to use an encrypted bootloader.

But if the AML magic wasn't present, then only a bootloader.img that started with the same string of bytes as the original would ever boot. I assumed that was because the bootloaders were differently encrypted. This was the case even of differently branded variants of the same device that were otherwise physically identical and most likely used the same revision of BL33.

It appears that I was wrong and I need to reassess my understanding.

That isn't true in the android box world sadly - u-boots need different configurations, and different board files per device often.

 

[goapy]

That isn't true in the android box world sadly - u-boots need different configurations, and different board files per device often.

Aren't wade and dopinder close enough hardware-wise that they should be able to at least boot each other's bootloader minimally?

Or to put it another way, why does the wade bootloader.img (for all versions) start with hex "A7 5B 38 30" while the dopinder bootloader.img starts with "9B DF 1A 47"? Is this because of the proprietary formatting that you referenced? Could working bootloaders for these devices (respectively) ever start with anything else, in terms of raw hex values?

For other devices, even after an update across PI -> Q -> R, the first couple hundred bytes of the bootloader will always be the same. I imagine that the u-boot components probably changed a lot across android 9, 10, and 11.

 

[npjohnson]

Aren't wade and dopinder close enough hardware-wise that they should be able to at least boot each other's bootloader minimally?

Or to put it another way, why does the wade bootloader.img (for all versions) start with hex "A7 5B 38 30" while the dopinder bootloader.img starts with "9B DF 1A 47"? Is this because of the proprietary formatting that you referenced? Could working bootloaders for these devices (respectively) ever start with anything else, in terms of raw hex values?

For other devices, even after an update across PI -> Q -> R, the first couple hundred bytes of the bootloader will always be the same. I imagine that the u-boot components probably changed a lot across android 9, 10, and 11.

I wouldn't do that - no reason to.

They're signed by different OEM sets - so I'd anticipate it's that - or just a versioned header.

And eh - it's really just security stuff from pie to R in terms of u-boot - S changes things more tho.

 

[goapy]

They're signed by different OEM sets - so I'd anticipate it's that - or just a versioned header.

Ah, this may be what I'm trying to understand.

What is an OEM set? How is a bootloader signed by one? This is different than encryption?

When you make a bootloader for use with your LOS build that supports wade/dopinder, do you have to sign each bootloader differently based on its OEM set? Where in the build process does this happen, and how is it done?

 

[npjohnson]

Ah, this may be what I'm trying to understand.

What is an OEM set? How is a bootloader signed by one? This is different than encryption?

When you make a bootloader for use with your LOS build that supports wade/dopinder, do you have to sign each bootloader differently based on its OEM set? Where in the build process does this happen, and how is it done?

I meant a "different OEMs set of keys". It is signed with proprietary amlogic tools. Yes it's much different. Digital signage verifies source of distro/who approved it in the header, not encrypts it.

We don't make boot loaders for these devices for lineage. Only for development boards, not production devices.

We just package the stock one to make sure it matches the TEE applets we include.

 

[goapy]

We don't make boot loaders for these devices for lineage. Only for development boards, not production devices.

We just package the stock one to make sure it matches the TEE applets we include.

I took your earlier response to mean the opposite.

Now I'm back to being convinced that the bootloaders for wade/dopinder are encrypted while the bootloader for deadpool is not encrypted. The deadpool bootloader has text strings and large stretches of unused space (00 hex). Neither wade or dopinder do.

 

[RDS5]

Anyway, sorry for the distraction. My original reason for asking was noble though. I was trying to understand why some users were having trouble with 19.1 on wade (I had no trouble), and I thought the pre-install bootloader on the device might be relevant.

wait a minute, wade works on 19.1 for you?
how. why doesnt it work for me! no matter how many different things i try, its always the recovery that manages to have some issue. it never wants to boot into 19.1 recovery, so how come it works fine for you?
yes i have tried flashing 19.1 from 18.1 recovery, that completely breaks 19.1 and renders it practically unusable (every menu popup that wants to fade the display background literally causes the entire screen to go black) and rebooting into recovery mode from 19.1 (which is supposed to overwrite the 18.1 recovery with the 19.1 recovery) causes it to get stuck on the androidtv screen (most likely because it cant even boot into the recovery!!), effectively softbricking it and forcing me to use amlogic's tools to fix it.

what was your install process? was it the exact same as 18.1? because i tried flashing 19.1 the same way i did for 18.1 and it worked fine with 18.1
i thought all wades werent booting, but now im really really confused. mine's from amazon not from walmart, so that might be the difference, although flashing the factory walmart images worked fine and i dont think wade ever had any major changes that locked it down, especially since, as ive already mentioned, 18.1 works completely fine.
i just want 19.1 because of the omx support, since this box is basically a glorified youtube machine without it, and at that point i might aswell be using a desktop if it werent for the fact that hdcp doesnt even work right on desktops either... neither does it stop piracy

 

[goapy]

wait a minute, wade works on 19.1 for you?
how. why doesnt it work for me! no matter how many different things i try, its always the recovery that manages to have some issue. it never wants to boot into 19.1 recovery, so how come it works fine for you?

Yes. I was about to reply to your post just before I got started down that bootloader rabbit hole.

I was pondering what might be different about my device as compared to yours, if anything.

I have several wades (dynalinks). I'll do another, and document my steps, including the version of the firmware that I started with prior to the install. I'll let you know whether it works or not, and if it does, the exact steps I followed.

 

[npjohnson]

wait a minute, wade works on 19.1 for you?
how. why doesnt it work for me! no matter how many different things i try, its always the recovery that manages to have some issue. it never wants to boot into 19.1 recovery, so how come it works fine for you?
yes i have tried flashing 19.1 from 18.1 recovery, that completely breaks 19.1 and renders it practically unusable (every menu popup that wants to fade the display background literally causes the entire screen to go black) and rebooting into recovery mode from 19.1 (which is supposed to overwrite the 18.1 recovery with the 19.1 recovery) causes it to get stuck on the androidtv screen (most likely because it cant even boot into the recovery!!), effectively softbricking it and forcing me to use amlogic's tools to fix it.

what was your install process? was it the exact same as 18.1? because i tried flashing 19.1 the same way i did for 18.1 and it worked fine with 18.1
i thought all wades werent booting, but now im really really confused. mine's from amazon not from walmart, so that might be the difference, although flashing the factory walmart images worked fine and i dont think wade ever had any major changes that locked it down, especially since, as ive already mentioned, 18.1 works completely fine.
i just want 19.1 because of the omx support, since this box is basically a glorified youtube machine without it, and at that point i might aswell be using a desktop if it werent for the fact that hdcp doesnt even work right on desktops either... neither does it stop piracy

the black screen flash it expected at the moment - we fixed it along with hardware OMX.

Focused on shipping it officially at the moment, so haven't had time to update XDA builds.

 

[RDS5]

Yes. I was about to reply to your post just before I got started down that bootloader rabbit hole.

I was pondering what might be different about my device as compared to yours, if anything.

I have several wades (dynalinks). I'll do another, and document my steps, including the version of the firmware that I started with prior to the install. I'll let you know whether it works or not, and if it does, the exact steps I followed.

thanks! just in case our models are different, mine's a "DT-ATV36" although i highly doubt they are different. i forgot the firmware i started with before i installed, but i later flashed the walmart firmware (from the factory images provided in this post), so thats what it is for me right now.

 

[RDS5]

the black screen flash it expected at the moment - we fixed it along with hardware OMX.

Focused on shipping it officially at the moment, so haven't had time to update XDA builds.

wait, so the screen is supposed to stay black whenever popups happen? because that sorta renders the entire thing unusable, or do you mean you fixed it?
tho if your shipping it officially, its fine. theres no real need to update the XDA builds if the update we were gonna get is just going to end up as lineageos official. i get it takes a while to get things shipped officially (if im not wrong, the only thing stopping you guys is the sepolicy being incomplete), so its fine.
only thing im confused with is how others are fine, but im having so much trouble. i THINK i have the right model and everything, but in case im doing something wrong, i wanna figure that out.
anyways, i wanted to thank you and everyone else for all the great work you guys have been doing, and all the help you've provided me, and everyone else.

 

[npjohnson]

wait, so the screen is supposed to stay black whenever popups happen? because that sorta renders the entire thing unusable, or do you mean you fixed it?
tho if your shipping it officially, its fine. theres no real need to update the XDA builds if the update we were gonna get is just going to end up as lineageos official. i get it takes a while to get things shipped officially (if im not wrong, the only thing stopping you guys is the sepolicy being incomplete), so its fine.
only thing im confused with is how others are fine, but im having so much trouble. i THINK i have the right model and everything, but in case im doing something wrong, i wanna figure that out.
anyways, i wanted to thank you and everyone else for all the great work you guys have been doing, and all the help you've provided me, and everyone else.

yea, we fixed the black screen - just haven't pushed new builds.

And yes official ETA soon.

 

[RDS5]

yea, we fixed the black screen - just haven't pushed new builds.

And yes official ETA soon.

ohhhh ok, would it be possible for me to compile these builds myself? although im quite a noob at compiling, and if the official builds are right around the corner it sorta wouldnt be worth the trouble, i would just like to know if it is possible to build these, or if the changes havent been published yet.

 

[kennkanniff]

ohhhh ok, would it be possible for me to compile these builds myself? although im quite a noob at compiling, and if the official builds are right around the corner it sorta wouldnt be worth the trouble, i would just like to know if it is possible to build these, or if the changes havent been published yet.

Yes it is possible. Changes are there. But I decided to wait for official before building anything myself. ETA soon is great news!

 

[RDS5]

Yes it is possible. Changes are there. But I decided to wait for official before building anything myself. ETA soon is great news!

it makes sense that its coming soon tho, as he already did all the work previously, and making it official is just a matter of making the sepolicy and likely just some small code cleanup and testing here and there.