[DEV][ROM][UNOFFICIAL] LineageOS 19 (Android 12L) for Raspberry Pi 4 B

[masscream]

Hello, I've installed the LOS 19.0 20211104 with TWRP 3.5.2_11-0 via Pinn OS, and I fully understand that the issue could be in their part of setup, however, I've spend some hours on this problem and so far without any success. I booted simply into TWRP and now I can't get out of it, because every single reboot leads to TWRP again. It may have something in common with difficulties mounting /system_root partition, as I've described here. If the issue is not in the LOS itself but Pinn OS's part, please can you tell me at least if there's any temp workaround until they fix it? (Restoring the right boot img via cmdline, in older versions there used to be a sh script as I've read about...) Thank you.

 

[KonstaT]

Hello, I've installed the LOS 19.0 20211104 with TWRP 3.5.2_11-0 via Pinn OS, and I fully understand that the issue could be in their part of setup, however, I've spend some hours on this problem and so far without any success. I booted simply into TWRP and now I can't get out of it, because every single reboot leads to TWRP again. It may have something in common with difficulties mounting /system_root partition, as I've described here. If the issue is not in the LOS itself but Pinn OS's part, please can you tell me at least if there's any temp workaround until they fix it? (Restoring the right boot img via cmdline, in older versions there used to be a sh script as I've read about...) Thank you.

I'm not supporting any multi-boot solutions so you need to report this to PINN developer procount (as I see you already have https://github.com/procount/pinn/issues/598). Also previously discussed on my site (http://disq.us/p/2l29q40).

But yes, this is definitely broken on PINN side. Booting out of TWRP requires changes on the boot partition which (most likely) is not /dev/block/mmcblk0p1 on multi-boot. Kevin (procount) should be aware of the changes needed for TWRP so I don't know why they are not there for LineageOS 19 (as TWRP works on PINN with previous LineageOS versions).

There is still a shell script (/vendor/bin/rpi4-recovery.sh). You can check what it does and make the changes manually on the boot partition.

 

[EthanRIP]

@KonstaT
@EpicLPer

Hello! I seems as you have had success on getting the official 7" touchscreen working for Android 12. I have had the 16.0 version working but would like to switch to 19.0 I have tried and tried to get it working without success, with different Android os as well. Nobody seems to know how or have clear instructions, and I would be very grateful to get this working.

 

[rabbited]

logcat2.txt

drive.google.com

I really appreciate your efforts in assisting with this project! No luck so far, but the logcat has changed. It does look like ANQP is still initializing.

In TWRP I went to the Install tab and selected the attached file, I assume that that's the proper procedure (using a fresh install)?

The RPOS test was more just to see if the hardware was definitively supported. Obviously, it's possible the chip could work with Passpoint and that RPOS isn't implementing it properly but I was checking for proof that it DID work before recommending that the package be removed.

 

[KonstaT]

@KonstaT
@EpicLPer

Hello! I seems as you have had success on getting the official 7" touchscreen working for Android 12. I have had the 16.0 version working but would like to switch to 19.0 I have tried and tried to get it working without success, with different Android os as well. Nobody seems to know how or have clear instructions, and I would be very grateful to get this working.

Current steps are to install the 5.10 kernel add-on (in TWRP), run a script in rooted shell (in Android) and attach the official display. https://forum.xda-developers.com/t/...raspberry-pi-4-b.4356891/page-2#post-86008217 already has the info.

If/when there's another release it will come with 5.10 kernel by default and there is a settings option to enable the necessary configs for the official display.

 

[KonstaT]

logcat2.txt

drive.google.com

I really appreciate your efforts in assisting with this project! No luck so far, but the logcat has changed. It does look like ANQP is still initializing.

In TWRP I went to the Install tab and selected the attached file, I assume that that's the proper procedure (using a fresh install)?

The RPOS test was more just to see if the hardware was definitively supported. Obviously, it's possible the chip could work with Passpoint and that RPOS isn't implementing it properly but I was checking for proof that it DID work before recommending that the package be removed.

It's a long-standing issue with my builds so of course I would like to have it resolved in one way or another. If it was something I could reproduce it likely would have been fixed ages ago.

Yes, just install the zip in TWRP. I attached another one to test that should disable making ANQP requests. Please test and report back.

I don't see how Raspberry Pi OS would imply anything in this regard (hw might support it but software doesn't or neither supports it). So, Raspberry Pi OS can display the SSID of the Hotspot 2.0 network but that's it. Android doesn't have any problem getting the BSSID/SSID either (as you can see them in the logs) but something goes wrong with ANQP requests which Android automatically wants to send whenever it sees a Hotspot 2.0 network(?).

 

[rabbited]

It's a long-standing issue with my builds so of course I would like to have it resolved in one way or another. If it was something I could reproduce it likely would have been fixed ages ago.

Yes, just install the zip in TWRP. I attached another one to test that should disable making ANQP requests. Please test and report back.

I don't see how Raspberry Pi OS would imply anything in this regard (hw might support it but software doesn't or neither supports it). So, Raspberry Pi OS can display the SSID of the Hotspot 2.0 network but that's it. Android doesn't have any problem getting the BSSID/SSID either (as you can see them in the logs) but something goes wrong with ANQP requests which Android automatically wants to send whenever it sees a Hotspot 2.0 network(?).

Right! What I was trying to say was that the test would only be useful if Passpoint DID work on RPOS because that would prove that the hardware can potentially work (ie the chip itself supports Passpoint). Outside of that, any other outcome doesn't provide useful info. I will try this now and edit my post with results! Thanks again!

Edit: Unfortunately, I'm not seeing any difference with the new version. I will check the two logcats to see if there's any difference.

Just to confirm, I go the the install tab in TWRP, install the provided file, wipe Dalvik and reboot and there are no other required steps?

logcat3.txt

drive.google.com

 

[KonstaT]

Right! What I was trying to say was that the test would only be useful if Passpoint DID work on RPOS because that would prove that the hardware can potentially work (ie the chip itself supports Passpoint). Outside of that, any other outcome doesn't provide useful info. I will try this now and edit my post with results! Thanks again!

Edit: Unfortunately, I'm not seeing any difference with the new version. I will check the two logcats to see if there's any difference.

Just to confirm, I go the the install tab in TWRP, install the provided file, wipe Dalvik and reboot and there are no other required steps?

logcat3.txt

drive.google.com

Most definitely something wrong getting this to your device now. The code block where you get the 'ANQP initiated on ...' log is commented out so you couldn't possibly see that. I can leave this to next build for testing (doesn't seem to break anything for me) but not sure if there's any point in providing patches to test. Exactly why I don't like to deal with issues I can't reproduce myself.

Yes, just the flash the zip in TWRP. You can e.g. 'ls -l /system/apex/com.android.wifi/javalib/' before/after to see that the file date/size have changed.

On the subject of wiping dalvik cache, I have probably never in my life wiped dalvik cache. Android is perfectly capable of rebuilding the Dalvik/ART executables whenever something is changed. IMO that option should have been removed from recoveries years ago (and it's also been years since Android moved to using ART).

 

[masscream]

I'm not supporting any multi-boot solutions so you need to report this to PINN developer procount (as I see you already have https://github.com/procount/pinn/issues/598). Also previously discussed on my site (http://disq.us/p/2l29q40).

But yes, this is definitely broken on PINN side. Booting out of TWRP requires changes on the boot partition which (most likely) is not /dev/block/mmcblk0p1 on multi-boot. Kevin (procount) should be aware of the changes needed for TWRP so I don't know why they are not there for LineageOS 19 (as TWRP works on PINN with previous LineageOS versions).

There is still a shell script (/vendor/bin/rpi4-recovery.sh). You can check what it does and make the changes manually on the boot partition.

Thank you, with the info you gave me I was able to move forward. procount is now working on the permanent fix.

 

[rabbited]

Most definitely something wrong getting this to your device now. The code block where you get the 'ANQP initiated on ...' log is commented out so you couldn't possibly see that. I can leave this to next build for testing (doesn't seem to break anything for me) but not sure if there's any point in providing patches to test. Exactly why I don't like to deal with issues I can't reproduce myself.

Yes, just the flash the zip in TWRP. You can e.g. 'ls -l /system/apex/com.android.wifi/javalib/' before/after to see that the file date/size have changed.

On the subject of wiping dalvik cache, I have probably never in my life wiped dalvik cache. Android is perfectly capable of rebuilding the Dalvik/ART executables whenever something is changed. IMO that option should have been removed from recoveries years ago (and it's also been years since Android moved to using ART).

Thanks again! I will try to sort out what it is I'm doing wrong and get back to you after trying each patch once sorted out. Would you recommend just sticking to trying to solve it with the second patch?

 

[rabbited]

SUCCESS! I manually replaced the service-wifi.jar file via ADB and for the first time in a year of trying to figure out a way to get WiFi to work on my RPi I am finally able to use it without issue! Thank you so much for your amazing work!

I'm not sure why the flashable zip didn't work but is replacing the service-wifi.jar file the only change that needed to be made? Do I need to replace META-INF? I'm new to the inner workings of the Android file system so I'm just starting to research what this is for.

 

[KonstaT]

SUCCESS! I manually replaced the service-wifi.jar file via ADB and for the first time in a year of trying to figure out a way to get WiFi to work on my RPi I am finally able to use it without issue! Thank you so much for your amazing work!

I'm not sure why the flashable zip didn't work but is replacing the service-wifi.jar file the only change that needed to be made? Do I need to replace META-INF? I'm new to the inner workings of the Android file system so I'm just starting to research what this is for.

That's great news! Thanks for testing.

At least there's now a little better understanding what the issue actually is (automatic ANQP requests). Still needs some figuring out what is the best way to handle this on a device that doesn't support that.

Yeah, IDK what went wrong with that zip, seems to replace the file just fine for me. service-wifi.jar is the only file that gets replaced in the system. I'll include this change in the next build anyway.

 

[KonstaT]

New build.

LineageOS 19 (Android 12L)

for Raspberry Pi 4

konstakang.com

-switch to Linux 5.10 kernel by default
-fix VC4 HDMI audio with 5.10 kernel (3.5mm jack is now used by default so select the right HDMI device from the settings)
-add support for the official 7" touchscreen display with hw accelerated graphics (enable configurations for the touchscreen from the settings)
-minor brightness fixes for the official 7" display
-add support for Pi camera modules using libcamera, preview & photos work - camcorder doesn't (thanks to Roman Stratiienko)
-fix UVC USB webcams that use external camera HAL (camera needs to support MJPG format - preview, photos & camcorder works)
-add option to enable currently very WIP H.264 hardware video decoding using v4l2_codec2 (enable experimental feature from the settings)
-fix reboots related to Hotspot 2.0 networks/ANQP requests (see issue #6)
-Vulkan 1.1 (thanks to people at Igalia for Vulkan 1.1 conformance and Roman Stratiienko for latest Mesa fixes)
-update to Mesa 21.3.1
-update to Linux 5.10.83 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
-Android security patch level: 5 December 2021 (merged)

 

[EthanRIP]

New build.

LineageOS 19 (Android 12L)

for Raspberry Pi 4

konstakang.com

-switch to Linux 5.10 kernel by default
-fix VC4 HDMI audio with 5.10 kernel (3.5mm jack is now used by default so select the right HDMI device from the settings)
-add support for the official 7" touchscreen display with hw accelerated graphics (enable configurations for the touchscreen from the settings)
-minor brightness fixes for the official 7" display
-add support for Pi camera modules using libcamera, preview & photos work - camcorder doesn't (thanks to Roman Stratiienko)
-fix UVC USB webcams that use external camera HAL (camera needs to support MJPG format - preview, photos & camcorder works)
-add option to enable currently very WIP H.264 hardware video decoding using v4l2_codec2 (enable experimental feature from the settings)
-fix reboots related to Hotspot 2.0 networks/ANQP requests (see issue #6)
-Vulkan 1.1 (thanks to people at Igalia for Vulkan 1.1 conformance and Roman Stratiienko for latest Mesa fixes)
-update to Mesa 21.3.1
-update to Linux 5.10.83 kernel and patch known vulnerabilities (CVE-xxxx-xxxx, and more)
-Android security patch level: 5 December 2021 (merged)

Downloaded new build, flashed to 32gb sd card (using belena etcher). Plugged into 7" official rpi touchscreen. Got rainbow splashscreen - white animation - then blank screen (still lit up) with faint grey lines and nothing else. I tried changing the resolution.txt to 800x480 and deleting resolution.txt completely. Both resulted in the same issue. Anything i'm missing here?

 

[KonstaT]

Downloaded new build, flashed to 32gb sd card (using belena etcher). Plugged into 7" official rpi touchscreen. Got rainbow splashscreen - white animation - then blank screen (still lit up) with faint grey lines and nothing else. I tried changing the resolution.txt to 800x480 and deleting resolution.txt completely. Both resulted in the same issue. Anything i'm missing here?

At least you missed reading the FAQ, reading my reply when you asked the last time, reading the link I gave in that reply, and so on.

As stated in the FAQ there is a settings option to enable the configurations for the official 7" display so you also need to have another display. If you want to enable these configurations manually, there's two things to do - uncomment 'dtoverlay=vc4-kms-dsi-7inch' in /boot/config.txt & set 800x480 in /boot/resolution.txt (or remove the file altogether). You also need to change display density to adjust to the smaller display resolution somehow (go and enable the settings option as it also does this for you).

 

[rabbited]

After the wifi fix I installed Lineage19 on my CM4 for the first time and noticed that there are a few core issues. Opening the browser leads to a white screen with a search bar but no "webpage not available" message as expected if it was simply lack of ethernet or wifi (testing on 4B by turning off wifi shows a "webpage not available" message). When trying to add a new user in Settings the button is unresponsive. I will try to make some logcats later tonight. I reverted to the first build of Lineage19 to see if this has been a problem since then and experienced the same issues.

 

[KonstaT]

After the wifi fix I installed Lineage19 on my CM4 for the first time and noticed that there are a few core issues. Opening the browser leads to a white screen with a search bar but no "webpage not available" message as expected if it was simply lack of ethernet or wifi (testing on 4B by turning off wifi shows a "webpage not available" message). When trying to add a new user in Settings the button is unresponsive. I will try to make some logcats later tonight. I reverted to the first build of Lineage19 to see if this has been a problem since then and experienced the same issues.

Logcat on the browser issue? Seems strange that this would be something CM4 specific.

 

[rabbited]

The browser issue appears to be graphics related. This is clear in the logcat but I also realized it when the search bar would autofill with different search options as I typed (the search bar being the only part of the browser that shows up, the rest is a white screen). Here is the logcat:

browser.rtf

drive.google.com

I'm using an HDMI dummy plug here but the behavior was the same when plugged into my monitor as it is over VNC w/dummy plug. I will still try to get another logcat when hooked up to my monitor in case theres any variation in messages.

 

[MystKid]

what gapps to install with this release?

 

[KonstaT]

The browser issue appears to be graphics related. This is clear in the logcat but I also realized it when the search bar would autofill with different search options as I typed (the search bar being the only part of the browser that shows up, the rest is a white screen). Here is the logcat:

browser.rtf

drive.google.com

I'm using an HDMI dummy plug here but the behavior was the same when plugged into my monitor as it is over VNC w/dummy plug. I will still try to get another logcat when hooked up to my monitor in case theres any variation in messages.

Thanks. What resolution are you using? It's hard to think this could be something CM4 specific. There's nothing in the log that would give exact clue why this is happening. I can see some USB related issues there that are CM4 specific (and also I know audio is an issue with CM4). I probably need to stop advertising any CM4 support (again). Probably not much I can do without having the hardware myself (and couldn't really get it either as it's out of stock everywhere).