Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mainstream 16.1 for midas platform (N7100/N7105/I9305/I9300) #1

Open
tlaurion opened this issue May 2, 2019 · 49 comments
Open

Mainstream 16.1 for midas platform (N7100/N7105/I9305/I9300) #1

tlaurion opened this issue May 2, 2019 · 49 comments
Labels

Comments

@tlaurion
Copy link

@tlaurion tlaurion commented May 2, 2019

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

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented May 2, 2019

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

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented May 2, 2019

@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

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented May 2, 2019

@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

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented May 2, 2019

@ChronoMonochrome Could you refer to that list?

@ChronoMonochrome

This comment has been minimized.

@tlaurion

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented May 2, 2019

@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

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented May 3, 2019

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

@tlaurion

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented May 3, 2019

@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

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented May 3, 2019

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

This comment has been minimized.

Copy link

@pgarrity18 pgarrity18 commented May 3, 2019

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

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented May 3, 2019

@pgarrity18

This comment has been minimized.

Copy link

@pgarrity18 pgarrity18 commented May 3, 2019

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

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented May 4, 2019

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

@tlaurion

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented May 24, 2019

Attempted @fourkbomb contact by email.

Sent from my Galaxy S3 using FastHub-Libre

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Jun 10, 2019

The Replicant project is working to port the i9305/i9300 to LineageOS 16.1 using the mainline Linux kernel. Help is wanted. https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9/#LineageOS-16

Hit us up on IRC or our email list if you want to join in the fun: https://redmine.replicant.us/projects/replicant/wiki#Contact

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Jun 10, 2019

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Jun 11, 2019

@herbsmn, it's nice to see other people also working on Midas! I've attempted to build LineageOS 15.1 with Lima userspace libs, but shortly gave up.
Will try out a Replicant OS build to see if I can get it work on I9300.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Jun 11, 2019

@ChronoMonochrome are you able to jump in #Replicant on Freenode's IRC to chat with us as you go? ping GNUtoo, Putti, or sensiblemn if you do.

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Jun 11, 2019

@herbsmn, I've successfully built a i9300 ROM and got to the bootanimation (as article states, it's very slow). Is there any interest to work on it until graphics issues are resolved? I gave another try to Lima driver, but it seems like Lima userspace lib doesn't implement DRI API methods thus it fails to load.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Jun 11, 2019

The Replicant project has a large interest on continuing to work on mainline LineageOS on midas for a long time. We also plan on replacing the proprietary s-boot with mainline u-boot. Anytime you want to jump in and help out, we would be glad to collaborate with you.

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Jun 11, 2019

Okay, if I'll get anything useful, I'll contact. Though I'm not sure if I'm able to fix graphics issue, which seems to be the most crucial (unless folks supporting Lima can fix it), but I'll give a try.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Jun 11, 2019

Sounds great! Here's a bit of an outline on our plan of attack. https://redmine.replicant.us/projects/replicant/wiki/TasksFunding#Graphics-acceleration Any questions or comments you might have would be very welcome.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Jun 13, 2019

Graphics are now working, but it is very very slow. We were able to get to the homescreen though and we confirmed that the touchscreen is working. We now will be working on graphics acceleration, but perhaps other work can be done now too even though the graphics are super slow.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Aug 16, 2019

Replicant just had a bit of a breakthrough today on the graphics using a somewhat big hack that needs to be fleshed out. You can see the speed of our new build with the hack on the devices on the left of the videos here, with the devices on the right being what we were previously experiencing: https://grimkriegor.zalkeen.net/public/alaunch.mp4 https://grimkriegor.zalkeen.net/public/slides.mp4 We hope to be pushing code that impliments this new user experience soon, so that anyone can build it.

If anyone wants to help us run LineageOS 16 with a mainline kernel and a mainline bootloader (with proprietary s-boot and proprietary TrustZone removed), with nearly zero proprietary blobs you can contact us here: https://redmine.replicant.us/projects/replicant/wiki#Contact

Documentation on the porting work to Android 9 for the i9300 (and other midas devices) can be found here: https://redmine.replicant.us/projects/replicant/wiki/Porting_Replicant_to_Android_9

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Aug 16, 2019

@herbsmn,

wow, such a nice progress. I was trying to bring up either Lima or Mali drivers to the mainline kernel, but didn't got any progress so far.
I'm still quite busy with other projects, but I'll rebuild it as soon as I have enough time.

@tlaurion

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented Aug 16, 2019

Awesome guys. Have a n7100, no i9305 yet. Will contact once I equipped myself. Thanks for your awesome work guys!

@tlaurion

This comment has been minimized.

Copy link
Author

@tlaurion tlaurion commented Aug 16, 2019

Hmmm. Is it a n7100 I see in the video? 😀

@dllud

This comment has been minimized.

Copy link

@dllud dllud commented Aug 17, 2019

@tlaurion it is two i9305 in the video.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Aug 19, 2019

@ChronoMonochrome @tlaurion glad to hear that you two are interested in Replicant's progress and want to join in the fun! here's our blog post about the awesome work that @dllud and others are doing on the graphics side of things: https://blog.replicant.us/2019/07/graphics-support-for-replicant-9/

@tlaurion tlaurion changed the title Mainstream 16.1 for i9300 Mainstream 16.1 for midas platform (N7100/N7105/I9305/I9300) Aug 20, 2019
@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Aug 22, 2019

@ChronoMonochrome I noticed someone over at the ODROID forums tested the lima driver on an Exynos4412 dev board with kernel 5.3-rc3 and it didn't result in a fatal error: https://forum.odroid.com/viewtopic.php?f=55&t=3691&sid=f73a6ad3052ead98bb90fa7854d061db&start=400#p264856

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Aug 22, 2019

@herbsmn,
AndroX (Note 2 developer) claimed that he got Lima drivers running on 4.9 (with a huge support from Simon and other people from Code Aurora Forum). There are several screenshots posted in Note2 Telegram group:

Screenshots

Screenshot from 2019-08-22 20-39-00.png
photo6249219910542666525.jpg
Screenshot from 2019-08-22 20-37-39.png

Unfortunately, for now no sources are available publicly, and even not clear whether they are going to be released (at least not earlier than first test builds are released).
Maybe someone could ping those people from Code Aurora Forum or Simon for getting some help on this.

About Lima driver:
I don't really know what is so special about LK 4.9. I've tried myself running 4.9, it seems that it boots but without any graphics. The oldest mainline-ish kernel that still has a working DRM subsystem for me was 4.11 (with a several backports from 4.12). I don't know if that makes sense to go deeper and trying to lower the kernel version to match exactly 4.9 (it will still have to rely on 4.12 backports in order to get DRM working).

By the way, some months ago I found that Samsung has a kernel source code for their Tizen OS (which is almost mainline, the newest version I could find was 4.1):
https://git.tizen.org/cgit/platform/kernel/linux-exynos/log/?h=tizen_5.0

It has Mali graphics support integrated, I have some suspects that the platform specific changes may be useful for Lima as well. By itself, LK 4.1 doesn't boot on ReplicantOS (it seems to be the same issues with DRM subsystem), so rebasing changes on top of at least 4.4 or 4.9 is needed (I will try that if I don't succeed with Lima bringup on LK 5.2 / 5.3).

EDIT:
Gave it a more attempts to boot up with a different kernel version.
On 5.3-rc5 I have:

[    0.872750] exynos-dsi 11c80000.dsi: failed to get regulators: -517
[    0.875231] lima 13000000.gpu: bus rate = 24000000
[    0.875263] lima 13000000.gpu: mod rate = 50000000
[    0.875313] lima 13000000.gpu: failed to get regulator: -517
[    0.875341] lima 13000000.gpu: regulator init fail -517
[    0.875371] lima 13000000.gpu: Fatal error during GPU init

4.17 is a bit more informative:

[    3.123287] exynos-dsi 11c80000.dsi: Failed to get supply 'vddcore': -517
[    3.130099] exynos-dsi 11c80000.dsi: failed to get regulators: -517
[    3.138778] lima 13000000.gpu: bus rate = 160000000
[    3.142192] lima 13000000.gpu: mod rate = 24000000
[    3.146982] lima 13000000.gpu: failed to get regulator: 0
[    3.152374] lima 13000000.gpu: regulator init fail -517
[    3.157556] lima 13000000.gpu: Fatal error during GPU init

4.13 and 4.11 just hangs so I couldn't get any logs here.

For some reason the voltage regulator is not initialized.
I'm quite new to this stuff, yet googling for a similar issues didn't give any results so far.
Maybe checking how the stock kernel initializes this regulator can give some hints why the mainline kernel fails to do so.

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Aug 23, 2019

Lima kernel driver is now loading with hacks:
https://github.com/ReplicantOS-midas/android_kernel_samsung_smdk4412/commits/master

08-23 05:08:05.858     0     0 I exynos-dsi 11c80000.dsi: failed to get regulators: -517
08-23 05:08:05.860     0     0 I lima 13000000.gpu: bus rate = 24000000
08-23 05:08:05.860     0     0 I lima 13000000.gpu: mod rate = 50000000
08-23 05:08:05.860     0     0 E lima 13000000.gpu: failed to get regulator: -517
08-23 05:08:05.861     0     0 I lima 13000000.gpu: gp - mali400 version major 1 minor 1
08-23 05:08:05.861     0     0 I lima 13000000.gpu: pp0 - mali400 version major 1 minor 1
08-23 05:08:05.861     0     0 I lima 13000000.gpu: pp1 - mali400 version major 1 minor 1
08-23 05:08:05.861     0     0 I lima 13000000.gpu: pp2 - mali400 version major 1 minor 1
08-23 05:08:05.861     0     0 I lima 13000000.gpu: pp3 - mali400 version major 1 minor 1
08-23 05:08:05.861     0     0 I lima 13000000.gpu: l2 cache 128K, 4-way, 64byte cache line, 64bit external bus
08-23 05:08:05.862     0     0 I         : [drm] Initialized lima 1.0.0 20190217 for 13000000.gpu on minor 0
...
08-23 05:08:05.973     0     0 E regulator_load_fn: init
08-23 05:08:05.973     0     0 E regulator_load_fn: enabled DSI regulator, ret=0
...

It seems to be ok, according to kernel log, this voltage regulator can be loaded but needs a time to initialize (and it's initialized at least without any error codes).

But now there is another problem, it doesn't look like drm hwcomposer is compatible with Lima:

08-23 05:08:14.964   331   331 E hwc-drm-device: Failed to set universal plane cap -1
08-23 05:08:14.964   331   331 E hwc-resource-manager: Failed to initialize any displays
08-23 05:08:14.964   331   331 E hwc-drm-two: Can't initialize the resource manager -22
08-23 05:08:14.964   331   331 E hwc-drm-two: Failed to initialize DrmHwcTwo err=6
08-23 05:08:14.964   331   331 E ComposerHal: failed to open hwcomposer device: Invalid argument
08-23 05:08:14.965   331   331 E android.hardware.graphics.composer@2.1-service: Could not get passthrough implementation for android.hardware.graphics.composer@2.1::IComposer/default.

In the case if anyone interesting, here is the full boot log:
https://gist.github.com/ChronoMonochrome/3ea0ab3bfc6677f412810e100ac9a6da

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Aug 23, 2019

Very exciting! Thanks for sharing!

I'm curious, are you using freedesktop's version of drm hwcomposer? https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer

@dllud

This comment has been minimized.

Copy link

@dllud dllud commented Aug 23, 2019

Great news @ChronoMonochrome !

It is normal for drm_hwcomposer to not work with Lima. AFAIK Lima should only expose a render node (the Mali GPU is not connected to a display). You will have to use drm_hwcomposer with the master node from drm/exynos. drm/exynos and drm/lima can then share buffers through PRIME.

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Aug 23, 2019

@herbsmn,
Yes, I'm using the same drm hwcomposer as posted in the ReplicantOS manifest (so it's freedesktop version).
I had to update mesa3d repo and rebase a few patches on top of it (building with original repo was giving errors with Lima enabled).

@dllud,
oh, seems to be complicated. I have left DRM_EXYNOS enabled in kernel, but I guess, some extra changes are still needed in drm_hwcomposer?

@dllud

This comment has been minimized.

Copy link

@dllud dllud commented Aug 23, 2019

It should just be a matter of pointing drm_hwcomposer to the correct dri node on your system (probably /dev/dri/card0). You can take a look at our system.prop.

I haven't tried the buffer sharing part yet, so I am helpless at that. Before diving into Lima we will first try to have drm_hwcomposer and gbm_gralloc working properly with DRM Magic (more info is available at the Replicant wiki: Graphics on Replicant 9).

PS. If you feel that sharing ideas live will help you, please drop by at Replicant's IRC channel on Freenode (#replicant).

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Sep 17, 2019

Here's some pictures of a person successfully running Android on MALI-400 using lima with a Orange Pi Plus 2E: https://gitlab.freedesktop.org/lima/mesa/issues/120

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Sep 17, 2019

Here's some pictures of a person successfully running Android on MALI-400 using lima with a Orange Pi Plus 2E: https://gitlab.freedesktop.org/lima/mesa/issues/120

These are exciting news to hear!
Finally I was myself able to get Lima running on S3 too (thanks to changes proposed in OrangePi Plus 2E repos), have a look at https://github.com/ReplicantOS-midas (had to update mesa3d, device tree and kernel).
It's running a somewhat better than with a software rendering (still it could be probably much faster, because for now Mali seems to be running at 50 MHz).
Having the same issues described in the link above (graphic artifacts and freezes), gonna try a fix proposed.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Sep 17, 2019

This is all very exciting indeed! Thanks for the news! Looking forward to hearing if the proposed fix for the artifacts and freezes worked for you.

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Sep 17, 2019

@herbsmn,

applying the suggested fix indeed fixed some textures being not rendered (however, some UI elements are still missing or rendered not properly).
Freezes seems to have a different nature. It's quite difficult for me to get any logs at this point, because when it freezes, the ADB connection drops as well, and after a hard reboot it's impossible to get logs from a previous boot.
So far I was able to get just one log (https://gist.github.com/ChronoMonochrome/5e72ed87061f46539863c1fd572ebd63) which seems to be related to some sort of memory allocations issues.
I've applied a patch that hopefully should resolve memory allocation issues - ReplicantOS-midas/android_kernel_samsung_smdk4412@0a1164f (I can't recall right now where exactly to find an original patch, but this idea of hacking the MAX_ORDER was present in some of Samsung kernel sources).

Still having a frequent freezes though (and sometimes they occur even when issuing a dmesg or logcat in ADB - I've also took USB configs from Orange PI Plus 2E device tree, but have no clues if it's anyhow a cause of freezes).

@fourkbomb

This comment has been minimized.

Copy link

@fourkbomb fourkbomb commented Sep 18, 2019

As far as I know, lima should be able to use non-contiguous memory on exynos. Make sure you have Exynos IOMMU enabled in the kernel? You might also have to tweak the way gralloc allocates memory to get it working.

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Sep 18, 2019

@fourkbomb, thanks for participation in a discussion!

Make sure you have Exynos IOMMU enabled in the kernel?

Yeah, I think it should be already enabled.
I might've wrongly assumed that memory allocation issue I faced was the only problem. There probably should be something else causing UI freezes. Anyway I'll check how frequently allocation errors appears in log (without MAX _ORDER hack).

You might also have to tweak the way gralloc allocates memory to get it working.

Umm, honestly, I don't know what exactly to look for. Anyway I'll try to log how much memory it needs to allocate at once to see if we indeed exceeding the limit set by MAX_ORDER.

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Sep 18, 2019

Here's a video of lima running on Replicant 9: http://www.belg.in/replicant_9.webm

@javifo

This comment has been minimized.

Copy link

@javifo javifo commented Sep 26, 2019

Wow! I'm impressed with the progress!

I would like to build it and test it. I have to organize me to get a couple hours/week free to fix things. I'm interested mainly in gralloc/hwcomposer.

@javifo

This comment has been minimized.

Copy link

@javifo javifo commented Sep 27, 2019

Lima driver do allow non-cma memory

https://gitlab.freedesktop.org/lima/mesa/issues/29

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Nov 26, 2019

Hi @ChronoMonochrome. I just wanted to check in to see if you've been working on this at all.

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Nov 27, 2019

Hi, @herbsmn

Last time I attempted using LOS16.0 on a mainline (it was about month ago), I can say it's already much better than it was before (I got rid of kernel crash / freeze issue, I think it was totally unrelated to Lima).
There's also some progress implementing audio support (again, only thanks to @fourkbomb work).
Managed to get the speaker to work (but that's all, neither headphones nor microphones do work).
I switched for now to the non-mainline kernel because of issues I can't solve (Lima still has crashes in userspace + audio-related issues). I'm planning to check soon if the headset can be fixed by using a proper audio policy config.
I'll leave the link to the audio patches in the case anyone can find it useful: https://github.com/ReplicantOS-midas/android_kernel_samsung_smdk4412/commits/lk-5.3

@herbsmn

This comment has been minimized.

Copy link

@herbsmn herbsmn commented Nov 27, 2019

Hi @ChronoMonochrome,

Replicant would love to work more collaboratively on this project with you, if you'd be interested. Please don't hesitate to pop into our IRC or email list from time to time to provide us with details of small victories or frustrating problems. Otherwise, at least two of us are following this github thread if you prefer to post updates here. Thanks so much for continuing this important endevour! Cheers!

@ChronoMonochrome

This comment has been minimized.

Copy link
Contributor

@ChronoMonochrome ChronoMonochrome commented Nov 27, 2019

@herbsmn

I was planning to post on IRC that aforementioned kernel freezes are resolved now
(but since it appeared they aren't related to the Lima at all, but rather caused by my mods to the device tree, I thought that doesn't even worth mentioning).
I don't know if I will return to the mainline kernel any soon, but if I'll find anything that worth any interest (either it's a win or a fail), I'll post it on IRC.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.