[GUIDE] [Future] [news and build Oreo] Oreo Go Older Oreo Device and or Trebel Dev

[tripLr]

Just wasting time even talking about "porting" treble to older devices that aren't already treble enabled, especially older devices. I mean really, what SoC manufacturers are going to waste their time rewriting code for older chipsets to make them treble capable? Guy's talking about how treble isolates the kernel from the hardware and other bs, he needs to read up a little on what treble does and does not do. Treble isolates the Android system (framework) from the hardware and enables device manufacturers to provide updates easier. With treble they can provide updates kernels and drivers without having to rewrite a lot of the Android framework every time, and they don't have to change any low level stuff to update the Android system, that's all it is. Kernels and device blobs are always going to be device specific, and since all those blobs are CLOSED source it ain't gonna happen.

Umm, no
Trebel forces standards of communication between drivers and operating system., And where the drivers are located in which partition,
And supports boot a, boot b, so if the update to boot b failed, boot a is fallback so theoretically it will be much harder to brick your device.

So let's assume a simple USB hardware driver in the side of your phone.

You plug in a USB Power and data cable to your phone.
An electric signal is sent on a wire to a chip.
The chip sends a code to the hardware interrupt

The kernel is constantly looking for things to do and scanning in order, driver a, driver b driver c, etc, and applying rules ( programming ) if x then n

Now a piece of code is constantly listening for a change in a hardware interrupt. ( Hardware driver )

The hardware driver sends a ( hey look at this ) to the cpu, the cpu reads the code ( what do I do if I see ”look at this")
And executes ( so that )

Let's say in the binary code
Qualcomm driver says OnUsbPlugIn send WakeUpBit to CPU hardware address 123abc
But
Samsung says ( hey let's run a security check before we do that ) hardware address 123ab1
But handset manufacturer xomami says ( we don't care, but let's send an update to some Chinese server that this device was hot plugged ) 123ab2

But now Verizon, AT+T , and TMobile all use the 3 different above , and compile a superduperCrapola driver for every different country they sell their handset.

Same chipset , many multiple different drivers

But now with Trebel, Google says no matter who makes the crap
OnUsbPlugIn must send 123abc to location TrebelOnUSBPlugin or You won't get our operating system and updates.

Forced standards ( free tools from Google to make your crapware drivers compliant )

So as an example..
So driver USBx.nougat just has to be pointed to Trebel.USB

I haven't coded this deep since Pascal, but the principal is the same

I think Google has a virtual Android Device , and there is a Trebel certification process.

So somewhere in the process ...

Qualcomm or whoever must release some basic hardware drivers source code or standards on it's IO specifications?

Also I saw a comment about partitions not being possible

You can partition any memory thing with any partition. Even virtual.

So yes it is possible to install Trebel partitions on my Note4 Verizon. It will be a brick, but it Can be done.

This boils down to
If Trebel has universal driver interfaces
So any ASOP ROM can run on any Trebel Device...

Could there ( not is ) be a universal Bootloader?

If the driver partition is separate
And the rexovery partition is separate
And the kernel and ROM are separate

Then we need to backbuild a universal Trebel to any device
Is a
Bootloader
And driver code

Now TWRP is as close to a universal recovery partition as we can get
It has a small operating system, ( probably Linux based ) and drivers built in.

The boot loader in any phone must provide some basic functions. It too must have some basic operating system as well. It will most likely be an EEPROM
On power up read hardware location x to y IN EEPROM
Copy x to y to PHYSICAL RAM memory location a to b
Excecute instruction is a to b
If no hardware interrupt load kernel and ROM
If hardware interrupt load recovery partition into memory and excute
If USB plug in display battery icon
If download display Android download screen
If bootloader lock bit set, deny write access


So all the Bootloaders do the same functions
These are all based on a physical program residing on a selectively flashable memory somewhere

Same as the BIOS on a Intel board.

Oh well I'm beat
Think more later

 

[Haxk20]

Umm, no
Trebel forces standards of communication between drivers and operating system., And where the drivers are located in which partition,
And supports boot a, boot b, so if the update to boot b failed, boot a is fallback so theoretically it will be much harder to brick your device.

So let's assume a simple USB hardware driver in the side of your phone.

You plug in a USB Power and data cable to your phone.
An electric signal is sent on a wire to a chip.
The chip sends a code to the hardware interrupt

The kernel is constantly looking for things to do and scanning in order, driver a, driver b driver c, etc, and applying rules ( programming ) if x then n

Now a piece of code is constantly listening for a change in a hardware interrupt. ( Hardware driver )

The hardware driver sends a ( hey look at this ) to the cpu, the cpu reads the code ( what do I do if I see ”look at this")
And executes ( so that )

Let's say in the binary code
Qualcomm driver says OnUsbPlugIn send WakeUpBit to CPU hardware address 123abc
But
Samsung says ( hey let's run a security check before we do that ) hardware address 123ab1
But handset manufacturer xomami says ( we don't care, but let's send an update to some Chinese server that this device was hot plugged ) 123ab2

But now Verizon, AT+T , and TMobile all use the 3 different above , and compile a superduperCrapola driver for every different country they sell their handset.

Same chipset , many multiple different drivers

But now with Trebel, Google says no matter who makes the crap
OnUsbPlugIn must send 123abc to location TrebelOnUSBPlugin or You won't get our operating system and updates.

Forced standards ( free tools from Google to make your crapware drivers compliant )

So as an example..
So driver USBx.nougat just has to be pointed to Trebel.USB

I haven't coded this deep since Pascal, but the principal is the same

I think Google has a virtual Android Device , and there is a Trebel certification process.

So somewhere in the process ...

Qualcomm or whoever must release some basic hardware drivers source code or standards on it's IO specifications?

Also I saw a comment about partitions not being possible

You can partition any memory thing with any partition. Even virtual.

So yes it is possible to install Trebel partitions on my Note4 Verizon. It will be a brick, but it Can be done.

This boils down to
If Trebel has universal driver interfaces
So any ASOP ROM can run on any Trebel Device...

Could there ( not is ) be a universal Bootloader?

If the driver partition is separate
And the rexovery partition is separate
And the kernel and ROM are separate

Then we need to backbuild a universal Trebel to any device
Is a
Bootloader
And driver code

Now TWRP is as close to a universal recovery partition as we can get
It has a small operating system, ( probably Linux based ) and drivers built in.

The boot loader in any phone must provide some basic functions. It too must have some basic operating system as well. It will most likely be an EEPROM
On power up read hardware location x to y IN EEPROM
Copy x to y to PHYSICAL RAM memory location a to b
Excecute instruction is a to b
If no hardware interrupt load kernel and ROM
If hardware interrupt load recovery partition into memory and excute
If USB plug in display battery icon
If download display Android download screen
If bootloader lock bit set, deny write access


So all the Bootloaders do the same functions
These are all based on a physical program residing on a selectively flashable memory somewhere

Same as the BIOS on a Intel board.

Oh well I'm beat
Think more later

Sure but where do you get vendor sources ?
Do you create your own ?
AlsoTWRP uses one 2 generic drivers for touch.
No matter the device touch is 95% sure that it will work.
So the question is are you going to create your vendor files ?
Or idk how you get them.
And if so you decide to make them then good luck with that.
If it was that easy ROM devs would make vendor files too to make the process sooooo much easier.

 

[2390]

Open GL will support any device that has open GL hardware and it's in Android Linux keenel

And what "no hardware acceleration" means is that the operating system "Android Linux Kernel" cannot see the OpenGL capable hardware because it needs code that belongs to the OEMs and GPU manufacturers that cannot, will not, ever, be made available to the public. The only, and I mean ONLY possible device I can think of that has a chance in hell of a community Treble port is the HTC HD2, because they've reverse engineered everything, and that's only because 1: HTC used to open source almost everything back in the day, and 2: they've had 8 years to work on it

---------- Post added at 12:35 AM ---------- Previous post was at 12:28 AM ----------

Think of it like this: imagine somebody paralyzed from the waist down due to a spinal injury. Do their legs work? Yes, in theory, but the body cannot access them. Could the body grow the spine? Sure, they grew one in utero but the cells lack the blueprints to do it again (look up how scar tissue works if you're interested). Porting Treble to older devices would be like that. Is the hardware there? Yes. Can the OS see or use them? No, because they (and we, the devs) lack the blueprints to rebuild things, which would be required. I know that analogy kinda went a bit off the rails, but I think it gets the general point across

 

[tripLr]

Ok, we have a new trebel article.

https://www.xda-developers.com/project-treble-aosp-android-oreo-huawei-mate-10-pro/

So in here is a chipset mention in different devices.
One of them is the Qualcomm snapdragon chip

Now I know most programmers ate mostly cut paste, tweak, library links, and scripting

Hardware driver however coders dread new families of hardware, but they all start with CPU architecture, buss addresses, memory IO addresses which represent physical connections.

So here we have a trebel snapdragon device.

By running the compiled drivers of trebel, through a code comparison with a non trebel driver should be able to identify

I/O address --->software code----> Trebel handle

Or visaversa

Trebel requirement ----->code------>device


Hardware development also follows lines.
Witness Intel CPUs and AMD, and the chipset to make them work on the motherboard.


So figure the easy stuff first
Buttons
Screen input sensor
GPS
Memory controller

Then harder stuff
GPU
CPU
Sensors
Camera

When a chipset maker makes x
Does the handset maker say, I want x and then adds the camera controller it wants, is there a standard IO for a camera in the chipset?

Is there a driver guru out there that understands the hardware itself ?

When u look at the comments for the kernel, you can see email addresss for contributors for things like the scsi controller etc for Linux. All these comments are in almost all the kernel.sources.

Anyway still figuring things out..

 

[tripLr]

As for not being open source drivers, who cares, the hardware has published specs.

Bluetooth is a spec
Arm is a spec. The patent owner in England licenses the arm tech to builders
So Arm has an instruction set
Arm 64 has an instruction set

Open GL is a open video spec

And Android is an open spec.

A compiled lineage os is about 334 megabytes
In there the Kernel is compiled about what , 3 megabytes?

The modem partition is what 15 megabytes?

What's this all compiled in C++ or what. Just askin

 

[revjamescarver]

Do you even bother to read?

Umm, no
Trebel forces standards of communication between drivers and operating system., And where the drivers are located in which partition,
And supports boot a, boot b, so if the update to boot b failed, boot a is fallback so theoretically it will be much harder to brick your device.

So let's assume a simple USB hardware driver in the side of your phone.

You plug in a USB Power and data cable to your phone.
An electric signal is sent on a wire to a chip.
The chip sends a code to the hardware interrupt

The kernel is constantly looking for things to do and scanning in order, driver a, driver b driver c, etc, and applying rules ( programming ) if x then n

Now a piece of code is constantly listening for a change in a hardware interrupt. ( Hardware driver )

The hardware driver sends a ( hey look at this ) to the cpu, the cpu reads the code ( what do I do if I see ”look at this")
And executes ( so that )

Let's say in the binary code
Qualcomm driver says OnUsbPlugIn send WakeUpBit to CPU hardware address 123abc
But
Samsung says ( hey let's run a security check before we do that ) hardware address 123ab1
But handset manufacturer xomami says ( we don't care, but let's send an update to some Chinese server that this device was hot plugged ) 123ab2

But now Verizon, AT+T , and TMobile all use the 3 different above , and compile a superduperCrapola driver for every different country they sell their handset.

Same chipset , many multiple different drivers

But now with Trebel, Google says no matter who makes the crap
OnUsbPlugIn must send 123abc to location TrebelOnUSBPlugin or You won't get our operating system and updates.

Forced standards ( free tools from Google to make your crapware drivers compliant )

So as an example..
So driver USBx.nougat just has to be pointed to Trebel.USB

I haven't coded this deep since Pascal, but the principal is the same

I think Google has a virtual Android Device , and there is a Trebel certification process.

So somewhere in the process ...

Qualcomm or whoever must release some basic hardware drivers source code or standards on it's IO specifications?

Also I saw a comment about partitions not being possible

You can partition any memory thing with any partition. Even virtual.

So yes it is possible to install Trebel partitions on my Note4 Verizon. It will be a brick, but it Can be done.

This boils down to
If Trebel has universal driver interfaces
So any ASOP ROM can run on any Trebel Device...

Could there ( not is ) be a universal Bootloader?

If the driver partition is separate
And the rexovery partition is separate
And the kernel and ROM are separate

Then we need to backbuild a universal Trebel to any device
Is a
Bootloader
And driver code

Now TWRP is as close to a universal recovery partition as we can get
It has a small operating system, ( probably Linux based ) and drivers built in.

The boot loader in any phone must provide some basic functions. It too must have some basic operating system as well. It will most likely be an EEPROM
On power up read hardware location x to y IN EEPROM
Copy x to y to PHYSICAL RAM memory location a to b
Excecute instruction is a to b
If no hardware interrupt load kernel and ROM
If hardware interrupt load recovery partition into memory and excute
If USB plug in display battery icon
If download display Android download screen
If bootloader lock bit set, deny write access


So all the Bootloaders do the same functions
These are all based on a physical program residing on a selectively flashable memory somewhere

Same as the BIOS on a Intel board.

Oh well I'm beat
Think more later

Do you even bother to read? There is no "backporting" to older non treble devices. First off you're not going to get closed source driver code from the SoC manufacturer, it just isn't going to happen. You also make a wrong assumption about twrp, there is nothing universal about it, as of oreo twrp no longer contains a kernel of any kind. There can never be a universal bootloader as those have and always be particular to the specific SoC, you can talk about code all you want and hope you haven't done it sonce pascal, but there are some simple facts that you refuse to grasp no matter how many people try to tell you. First off, treble REQUIRES driver and kernels that have been written to support it, second you are NEVER going to get the source code for the drivers from the SoC manufacturer, third you are comparing the android device to a pc and the two are as different as night and day, on a pc some of the low level functions are handled by the bios, whereas on any android device there is no bios, everything between the hardware is handled by the kernel, it's modules, the CLOSED SOURCE drivers, and then the android os. You trying to port treble to your device would be just like me getting to port it to my retired s5, a ton of time wasted on a futile effort. If you want to waste your time go for it, but realize that forest your going to have to port a complete kernel, write ALL your own drivers, rewrite a s***load of the android os, compile it all, repartition your device, at very minimum you're going to have a recovery, ram disk, kernel, vendor, system, and data partitions (kernel and ram disk because with oreo there is no boot partition anymore, it is /kernel and /ramdisk). So if you want to chase windmills get to coding. As some additional information, the phone manufacturer does not write their own drivers for the hardware on the SoC, those are provided in binary form from the SoC vendor, the carrier has nothing to do with drivers or low level software at all.

 

[mhedoc]

Do you even bother to read? There is no "backporting" to older non treble devices. First off you're not going to get closed source driver code from the SoC manufacturer, it just isn't going to happen. You also make a wrong assumption about twrp, there is nothing universal about it, as of oreo twrp no longer contains a kernel of any kind. There can never be a universal bootloader as those have and always be particular to the specific SoC, you can talk about code all you want and hope you haven't done it sonce pascal, but there are some simple facts that you refuse to grasp no matter how many people try to tell you. First off, treble REQUIRES driver and kernels that have been written to support it, second you are NEVER going to get the source code for the drivers from the SoC manufacturer, third you are comparing the android device to a pc and the two are as different as night and day, on a pc some of the low level functions are handled by the bios, whereas on any android device there is no bios, everything between the hardware is handled by the kernel, it's modules, the CLOSED SOURCE drivers, and then the android os. You trying to port treble to your device would be just like me getting to port it to my retired s5, a ton of time wasted on a futile effort. If you want to waste your time go for it, but realize that forest your going to have to port a complete kernel, write ALL your own drivers, rewrite a s***load of the android os, compile it all, repartition your device, at very minimum you're going to have a recovery, ram disk, kernel, vendor, system, and data partitions (kernel and ram disk because with oreo there is no boot partition anymore, it is /kernel and /ramdisk). So if you want to chase windmills get to coding. As some additional information, the phone manufacturer does not write their own drivers for the hardware on the SoC, those are provided in binary form from the SoC vendor, the carrier has nothing to do with drivers or low level software at all.

Hi,

why should the SoC/module vendor change the way on how a driver is writen for linux kernel?
Are the SoCs/modules only used for Android devices or also for other devices that maybe are also linux kernel driven?
If their SoCs/modules are used for other than android devices, are they really implementing different drivers for the same kernelversion?

I don't know, but maybe somebody, who knows how vendors create drivers for their SoCs, can tell us? Or maybe somebody can explain this picture mentioned in early post?
https://xdaforums.com/showpost.php?p=74993403&postcount=550

These are seriously meant questions!!!!! And i will appreciate somebody competent will answer them!!!

 

[revjamescarver]

Your questions

Hi,

why should the SoC/module vendor change the way on how a driver is writen for linux kernel?
Are the SoCs/modules only used for Android devices or also for other devices that maybe are also linux kernel driven?
If their SoCs/modules are used for other than android devices, are they really implementing different drivers for the same kernelversion?

I don't know, but maybe somebody, who knows how vendors create drivers for their SoCs, can tell us? Or maybe somebody can explain this picture mentioned in early post?
https://xdaforums.com/showpost.php?p=74993403&postcount=550

These are seriously meant questions!!!!! And i will appreciate somebody competent will answer them!!!

I can understand your questions, I suppose the best way to look at it that the kernel (and it's modules) live in one space, Android lives in another space, and the Hal occupies the space in-between, the SoC drivers are specific to Android devices. There are distributions of Linux that run on arm core devices (raspberry pi for example) but they generally rely on the kernel and it's own built in drivers to support hardware. The last Linux build I did for arm used broadcom for Wi-Fi, realtec for the sound, etc., All off the shelf chips, SoC's for phones are a different animal. As far as the how any why the SoC vendors do things the way they do, you are probably not going to find the answer you are looking for on XDA, you'll really have to talk to a software development person at the SoC you are looking to find out the answers about.

 

[o-l-a-v]

Can a Treble compatible driver for a SoC used by multiple devices, across OEMs, be used by another device with the same SOC?
Lets say a OEM ported Treble to a device using the same SOC as my OP3T, could my phone benefit from it later on?

 

[Haxk20]

Can a Treble compatible driver for a SoC used by multiple devices, across OEMs, be used by another device with the same SOC?
Lets say a OEM ported Treble to a device using the same SOC as my OP3T, could my phone benefit from it later on?

NOOO
The treble files are device specific and thats it.
There is no way to backport treble for older devices.

 

[tripLr]

Can a Treble compatible driver for a SoC used by multiple devices, across OEMs, be used by another device with the same SOC?
Lets say a OEM ported Treble to a device using the same SOC as my OP3T, could my phone benefit from it later on?

The answer is kinda maybe, it's gonna be hard.

As hard as making a driver from scratch from code like the original Linux.

1. You need to start by hoping your device has a list of all drivers
Here is a clue
All SOC makers have a standard they licence from the source of the ARM platform, the parents are owned by a company in England.
The next standards are all the IO standards. So far I am talking the actual hardware no software yet

Most SOC manufacturers like Qualcomm will sell a chip for hardware developers like watches, medical devices, display manufacturers, case manufacturers etc. These chips are then sold to a mother board maker that makes a ”phone" that sits on a open motherboard.

Qualcomm releases build able somewhat open source kernels and drivers for these hardware testers.

Older drivers are released as open source on the Qualcomm website, and some Samsung.

In a phone unlike a computer, there is only 1or 2 chips that have everything built together.

So these testbeds, just plug in screens with touch input and cameras .

These developers play around with the drivers to get their configuration to work

https://developer.qualcomm.com/hardware/snapdragon-835-hdk

 

[afridi.shahriar]

Hey!! I developed trebel for my phone, Xiaomi Mi max (hydrogen).
But, there are many limitations.

1: trebel is only for the same android SDK version.
Like, the trebel won't boot sdk27 roms, as it's only SDK26 supported.


2: t
With trebel, other ROMs booted, bur, baseband was showing error, and, many wireless related apps showed force close, like: com.android.phone.



Btw, i think, vendor/trebel also need to be upgraded in these trebel devices, which will bu automatically updated from Google services. So, it will be automatically supported to new android SDK versions.
Which won't be available in our custom trebel ports.
Or, we need to have a developer's site, who will upgrade trebel files like Google do, for unofficially trebel enabled phones.
As, now, we have lineageos, which provides custom roms, when we don't get official updates

 

[tripLr]

Hey!! I developed trebel for my phone, Xiaomi Mi max (hydrogen).
But, there are many limitations.

1: trebel is only for the same android SDK version.
Like, the trebel won't boot sdk27 roms, as it's only SDK26 supported.


2: t
With trebel, other ROMs booted, bur, baseband was showing error, and, many wireless related apps showed force close, like: com.android.phone.



Btw, i think, vendor/trebel also need to be upgraded in these trebel devices, which will bu automatically updated from Google services. So, it will be automatically supported to new android SDK versions.
Which won't be available in our custom trebel ports.
Or, we need to have a developer's site, who will upgrade trebel files like Google do, for unofficially trebel enabled phones.
As, now, we have lineageos, which provides custom roms, when we don't get official updates

That's awesome.
Thanks for sharing.

Can you post a thread in this zone on how you did it with your sources?
Please share this wonderful accomplishment

General steps are ok, post your steps.


I have been digging into building ROMs. To catch up on getting into building Oreo.

So for my progress which I will update in the OP


Learning Linux from scratch on an 6 year old dual hard drive 4 gb HP dual 64 gb laptop

Which further reinforces my ideas on Trebel and or oreo



https://www.xda-developers.com/android-go-old-android-8-1-oreo/

Sent from my SM-N910V using XDA Labs

 

[tripLr]

I will be closing this thread.

Many Aosp and lineageos Oreo builds are up for almost all note 4 devices.

GitHub.com/tripLr-dev

Thanks
Come visit out telegram group.

https://t.me/triplr_dev_users