Mainstreaming efforts for midas platform (N7100/N7105/I9305/I9300/I317)

[tlaurion]

Anyone suggested the manifest to be taken by LineageOs directly so that it is automatically built, and picked up by LineageOs for microg? Can't wait to use this on a maintained OTA i9300 phone with Delta updates. Which would raise developer's attention. And keep that phone alive.

If any help is needed contact me.
Awesome work, btw.

You read that? That needs to fly and be upstreamed: https://blog.forkwhiletrue.me/posts/an-almost-fully-libre-galaxy-s3/

Sent from my Galaxy S3 using FastHub-Libre

[ChronoMonochrome]

Hi, @tlaurion.

Anyone suggested the manifest to be taken by LineageOs directly so that it is automatically built, and picked up by LineageOs for microg?

What exactly do you mean? The LineageOS manifest is used in these builds being unmodified (and always a recent version). All the modifications comes to these local manifests.

Can't wait to use this on a maintained OTA i9300 phone with Delta updates.

IIRC this would require a server for that. Anyway if anyone have some ideas on implementing OTA updates, pull requests are always welcome.

You read that? That needs to fly and be upstreamed: https://blog.forkwhiletrue.me/posts/an-almost-fully-libre-galaxy-s3/

Yup, before I ever started any works on S3 I began by reading these exciting articles :)

[tlaurion]

@ChronoMonochrome : i'm talking about making LineageOS build the rom themselves by asking them to pickup your manifest and changeset :)

The only reason why the exynos board phones (i9300, i9305 LTE, n7100...) were dropped from LineageOS was because they were supported by 14.1 only on which support was dropped following their "major version -2 support drop" which made 14.1 supported devices unsupported radically.

Now that you have a "working" build (frontal camera aside, on which I see that you are working on), proposing reintegration would make sense, and will make its way into microG for LineageOS as well which create build for the same supported devices, and will also be supported by /e/.

You have complementary/oppositional information?

[ChronoMonochrome]

@ChronoMonochrome : i'm talking about making LineageOS build the rom themselves by asking them to pickup your manifest and changeset :)

The only reason why the exynos board phones (i9300, i9305 LTE, n7100...) were dropped from LineageOS was because they were supported by 14.1 only on which support was dropped following their "major version -2 support drop" which made 14.1 supported devices unsupported radically.

It's not that easy, I'm afraid. Device doesn't yet meet all the requirements proposed by LineageOS charter plus some hacks that are still used in the sources aren't gonna be merged easily for us. I'm not saying to stop working on exynos stuff but rather saying we are probably (likely) still not ready to claim being OFFICIAL, so need more work on it to do so.

[tlaurion]

@ChronoMonochrome Could you refer to that list?

[ChronoMonochrome]

@ChronoMonochrome Could you refer to that list?

https://github.com/LineageOS/charter/blob/master/device-support-requirements.md

[tlaurion]

@ChronoMonochrome Don't hesitate to edit this post with references of work needing to be done after having checked everything you know meet requirements.

• Audio

  • All devices MUST support audio playback for media content.
  • Phones MUST support in-call audio.
  • Phones MUST support speaker audio.
  • Tablet devices capable of in-call audio/speaker audio MUST support in-call/speaker audio.
  • Devices SHOULD support any additional audio configuration inherent to their device (eg. echo cancellation, extra mics, etc).
  • All devices MUST support any other audio output supported by their stock OS (eg. headphone jack, USB-C, BT).
  • All devices with FM radio capabilities in their stock OS SHOULD support FM.

• RIL

  • All devices with RIL supported in their stock OS MUST support RIL for phone calls & data.
  • All devices with RIL supported in their stock OS MUST support emergency calling with a SIM inserted (112/911).
  • All devices with RIL supported in their stock OS SHOULD support emergency calling without a SIM inserted (112/911).
  • Data-only devices (defined as devices that have a RIL but do not support telephony stack due to hardware/firmware restrictions) are EXEMPTED from phone & emergency dialing requirements.

• Encryption

  • All devices that supported hardware-backed encryption on their stock OS MUST support hardware-backed encryption.
  • All devices that shipped stock as forceencrypt SHOULD default to forceencrypt enabled.
  • All devices MUST support software encryption.

• Wi-Fi

  • All devices with Wi-Fi supported in their stock OS MUST support Wi-Fi.
  • All devices with Wi-Fi MUST report same MAC address as on stock OS.
  • All devices with Wi-Fi hotspot capabilities MUST support Wi-Fi tethering.

• USB

  • All devices with a USB port MUST support file access via MTP.
  • All devices with USB tethering supported on their stock OS MUST support USB tethering.
  • All devices with a USB port & Data SHOULD support USB tethering.

• GPS

  • All devices with GPS supported in their stock OS MUST support GPS.

• Bluetooth

  • All devices with Bluetooth supported in their stock OS MUST support Bluetooth.
  • All devices with Bluetooth MUST report same MAC address as on stock OS.
  • All devices with Bluetooth SHOULD support Bluetooth tethering.
  • All devices with support for Qualcomm® aptX™, aptX™ HD, or any future variant of aptX™, in stock (non-beta releases) OS SHOULD support those variant of aptX™.
  • All devices without support for Qualcomm® aptX™, aptX™ HD, or any future variant of aptX™ in stock (non-beta releases) OS MUST NOT support those variants of aptX™.

• Camera

  • All devices with Camera supported in their stock OS MUST support Camera, in both front facing and rear camera configurations.
  • All devices with Dual (or more) Rear Cameras SHOULD support all rear cameras.
  • All devices with Dual (or more) Front Facing Cameras SHOULD support all front cameras.
  • All Camera HAL versions accessible with the device's Camera HAL MUST comply with the Camera and Video Recording requirements.

• Video Recording

  • All devices with Video Recording supported in their stock OS MUST support Video Recording, in both front facing and rear camera configurations.

• Codecs

  • All devices with hardware encoding/decoding support in their stock OS MUST support hardware encoding/decoding for all non-proprietary codecs supported by their stock OS.

• Display

  • All devices with a built-in Display MUST support the Display at the same resolution and density as the stock OS.
  • All devices that do not include a built-in Display MUST support Display output via the hardware’s supported outputs (eg. Android TV - HDMI).
  • All devices that support additional non-USB display interfaces SHOULD support those display output methods.
  • All devices that support a USB-out display in their stock OS SHOULD support this display output (eg. MHL/Miracast/OTG).
  • All devices that support HDR10 playback in their stock OS SHOULD support HDR10 playback.

• NFC

  • All devices with NFC supported in their stock OS MUST support NFC.

• Fingerprint Sensor

  • All devices with a Fingerprint Sensor MUST support the Fingerprint Sensor if the stock OS supports it with Marshmallow or higher Android versions.
  • All devices with a Fingerprint Sensor SHOULD support the Fingerprint Sensor if the stock OS supports it for all other Android versions.

• IR

  • All devices with an IR blaster SHOULD support IR blaster.

• Accelerometer

  • All devices with an accelerometer MUST support the accelerometer.

• Gyroscope

  • All devices with a gyroscope MUST support the gyroscope.

• Proximity

  • All devices with a proximity sensor MUST support the proximity sensor.

• Light

  • All devices with a light sensor MUST support the light sensor.

• Other Sensors

  • All other sensors supported by a device’s stock OS SHOULD be supported.

• Accessories

  • All devices with proprietary accessories SHOULD support those accessories (eg. O-Click, Essential 360 Camera).

• Hardware Deviations

  • Hardware deviations are defined as exemptions granted for hardware requirements above that worked in stock, but do not work in LineageOS.
  • All hardware deviations from stock MUST be reported on the Wiki page for the device, with a user understandable justification.

• Software support

  • Device tree structure
    • Device trees MUST contain a Lineage-specific makefile with device declaration of lineage_[devicename].
    • Device trees MUST support a lineage.dependencies file for breakfast command & roomservice to be functional.
    • This file MUST NOT include any dependencies outside of the "LineageOS" organization.

• Build type

  • All devices MUST be configured as userdebug releases.

• Kernel

  • All devices MUST NOT ship a prebuilt kernel.
  • All devices MUST NOT implement software based touchscreen wake features such as double tap to wake, swipe to wake or gestures if there is no hardware-backed support for them in the touchscreen firmware.
  • All devices MUST NOT implement forced fast charge over USB methods that violate the USB specifications.
  • All devices MUST NOT implement any form of clock manipulation (underclocking, overclocking, etc.) for any processor (CPU, GPU).
  • All devices MUST NOT implement any form of hardware voltage manipulation (undervolting, custom voltage tables, etc.).
  • All devices MUST NOT implement any form of hardware register manipulation (sound control, etc.).
  • All devices MUST NOT implement any form of custom KSM driver (UKSM, etc.).
  • All devices MUST NOT ship governors other than the ones specified in the following list:
    • conservative
    • interactive
    • ondemand
    • performance
    • powersave
    • sched
    • schedutil
    • userspace
  • All devices MUST NOT ship I/O schedulers other than the ones specified in the following list:
    • bfq
    • cfq
    • deadline
    • noop
    • row
  • All devices MUST only ship hotplugging drivers provided by the OEM or SoC vendor.

• SELinux status

• All devices MUST be configured for SELinux Enforcing.

• Verity

  • All devices MUST disable verity on the system image for userdebug builds.
  • All devices SHOULD support verity on the vendor image.

• Updater

  • All devices with a shipping build of LineageOS MUST support upgrades via the native LineageOS Updater application & the recovery documented on the Wiki for that device.

• FRP

  • All devices with stock support of Factory Reset Protection (FRP) SHOULD support FRP when Google Applications are installed by the user.

• SafetyNet

  • All devices MUST NOT alter SafetyNet validation responses.

• Binder

  • All devices MUST use the 64-bit Binder API.

• Root (su)

  • All devices MUST NOT ship with su included.
  • All devices MUST support su installation via LineageOS provided ‘Extras’ download.

• Non-PIE Blobs

  • Devices MUST NOT use non-PIE binaries.

• Proprietary files extraction

  • Devices MUST have a working proprietary files extraction script in their device tree (or device tree dependencies) that reproduces an exact copy of the binaries required to build LineageOS from an existing LineageOS installation.
  • Devices SHOULD use the global extraction script (located in vendor/lineage).
  • If a device maintainer elects to not use the common extraction script, the maintainer MUST ensure that the Wiki page for their device has valid instructions for operating the custom extraction script.

• CVE

  • Devices MUST support CVE patches for “high profile” exploits and vulnerabilities (if the media is reporting on it, then we must have it patched).
  • [NOTE: This will become a MUST once CVE autopatcher is live & automated]
  • Devices SHOULD receive regular CVE patches to the device kernel and dependencies.
  • [To be in effect once CVE autopatcher is live & automated]
  • Device maintainers MUST review and/or accept patches provided by the CVE autopatcher tool.

• Firmware Assert

  • All devices MUST assert on known to be working firmware versions if some firmware versions are known to be non-working.

• exFAT Support

  • LineageOS operates under the assumption that OEM device licensing for exFAT is attached to the device, not software. LineageOS will comply with all requests for removal of exFAT support from OEMs, Microsoft or their representatives upon contact to legal@lineageos.org.

    • All devices with exFAT support on stock MAY support exFAT with (and only with) a kernel based implementation.
    • All devices without exFAT support on stock MUST NOT support exFAT.

• Additional Features

  • All devices SHOULD support in-kernel (MDSS, MDNIE or similar) LiveDisplay colour adjustment.

• Software Deviations

  • Software deviations are defined as exemptions granted for software requirements above that worked in stock, but do not work in LineageOS.
    • All software deviations from other LineageOS devices of the same type MUST be approved by Directors (eg. if one wants to remove Music app, get approval).
    • All software deviations from other LineageOS devices of the same type MUST be reported on the Wiki page for the device, with a user understandable justification.
    • Device maintainers MUST ship Jelly or another LineageOS sourced web browser.

• Quality of life

  • Commit Authorship
    • All non-original commits MUST have proper authorship attribution from the source it was taken from or adapted from.

• Copyrights

  • All original contributions MUST be copyrighted as “(C) [YEAR] The LineageOS Project”.
  • All LineageOS copyrights MUST only be additive to the copyright header.
  • Do not remove copyrights from CyanogenMod, Cyanogen Inc or any other upstream.

• Workflow

  • Force pushing branches SHOULD be avoided.
  • In the event of a force pushed branch, backup branches of the pre-forced HEAD MUST be made.

• JIRA

  • Device maintainer(s) MUST have a JIRA account for bug tracking and cross-team collaboration.
  • Device maintainer(s) MUST routinely triage, answer and close JIRA reports.
  • Device maintainer(s) SHOULD make their JIRA name match their maintainer name as displayed on the Wiki.

• Licensing

  • All Kernel contributions MUST be GPLv2.
  • All Android contributions SHOULD be Apache 2.0 licensed.
  • Any contribution to an existing Apache 2.0 project MUST fall under Apache Compliance Category A.
  • Any contribution to an existing Apache 2.0 project MUST NOT be in Apache Compliance Category X.

• Wiki

  • All devices with a shipping build of LineageOS MUST have a Wiki page with valid installation instructions.
  • All devices with a shipping build of LineageOS MUST document Hardware Deviations from stock capabilities.
  • All devices with a shipping build of LineageOS MUST document Software Deviations from other LineageOS releases of the same device type.

• Stability

  • Issues like the "screen of death" MUST NOT affect the device.
  • The device MUST NOT have abnormal battery drain.

• Recovery

  • Maintainers MUST document for users on the Wiki a valid Recovery image by which to install LineageOS zip files.
  • Devices that do not have traditional Recovery images MUST support & document another means of installation for LineageOS zip files.
  • Maintainers SHOULD verify that Teamwin Recovery Project (TWRP) official distributions work for LineageOS installation.
  • Failures in official TWRP recoveries should be raised with the TWRP team or remedied by the maintainer.
  • Maintainers SHOULD provide a custom recovery link in Wiki documentation if TWRP does not officially support their device.

[ChronoMonochrome]

@tlaurion, nice idea! I thought of creating a fork of the charter repo to indicate the progress being done, though.

[tlaurion]

@ChronoMonochrome : Pinpoint where it's at! Interested in making this go forward.

Could do a CI and modify LineageOS Updater url to point to the updater backend on AWS (or whatever free server recommended) for the pre-official community to test this properly?

Never did that before but it seems to be the way to go! What do you think?

[ChronoMonochrome]

Could do a CI and modify LineageOS Updater url to point to the updater backend on AWS (or whatever free server recommended) for the pre-official community to test this properly?

Never did that before but it seems to be the way to go! What do you think?

Yes, that should do. Though I have no clues about which free servers can be suitable for LineageOS updater.

[pgarrity18]

Apologize if this is a dumb question...

And there we have it: we've successfully removed almost all blobs from the Exynos 4412 found in the i9300. The one blob remaining is probably not replaceable: it's both encrypted and signed by Samsung. However, since we have access to where the code is stored, it would be trivial to wipe every trace of it from RAM once U-Boot starts. (And similarly, it's easy to dump the code that's been loaded into RAM - it is not even remotely interesting...)

forkbomb calls this approach "almost fully libre". How does this differ from the approach used to deblob and remove the Intel ME on GM45 chipsets? Is this something that could ultimately get fsf RYF certification? Or is it just really close?

Just trying to understand how significant this is. Should I order my Note 2 before they all get scooped up? Thanks guys!

[tlaurion]

@pgarrity18: TLDR: i9300 won't get RYF certification, for the same reason the Lenovo x220 didn't under minifree attempt, and why Librem laptops won't ever receive it: the second CPU still runs binary blobs. From my understanding, that would not get RYF certification, just like Ivy bridge and Sandy bridge based platforms can't, since Intel ME is still present, boots, and pass control to main CPU, but without having any interface to interact with it from a booted system. RYF certification requires "complete removal" aka disablement. GM45 permitted that. For Ivy and Sandy bridges, we talk about neutering, since only ROMP and BUP modules are required to pass control to the main CPU. For later bridge implementation in platforms, we talk about disablement, since ME is "asked" to disable itself from discovered hidden instructions from positive research, while still requiring a bunch of other modules to be present in ROM to pass control to main CPU. They cannot be removed, me_cleaner can't trim the space. They are there. In current case, what @fourkbomb means there is that a complete bypass is possible, since there is a kexec happening, from which all memory mappings can be wiped. There is a possibility to remove any trace in memory of that blob, and that the other CPU having passed control doesn't know that its access had been revoqued. But that needs to be tested thoroughly. Note the absence of further posts on that blog. Would be nice if @fourkbomb replied to contact attempts. But didn't. _Sent from my Galaxy S3 using [FastHub-Libre](https://github.com/thermatk/FastHub-Libre/)_

[pgarrity18]

Thank you for the response. It is interesting indeed and I too wish that forkbomb was more engaged with the community. I am trying to wrap my brain around what he did, what these guys did ..

https://blog.fossencdi.org/u-boot-galaxys3.html,

and what other possibilities might still exist. For example, could you repackage the S3 after shorting the bridge and forcing a boot from the SD card via u-boot? Even without RYF certification, the work you guys are doing is exceptional!

[tlaurion]

@fourkbomb: can you help in accomplishing what is missing to mainstream this?

[tlaurion]

Attempted @fourkbomb contact by email.

Sent from my Galaxy S3 using FastHub-Libre