You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug This seems to indicate that BOINC falls back to arm-android-linux-gnu (aarch32) if a project doesn't support aarch64-android-linux-gnu. Is that correct and always the case? If so, it shouldn't be since as of ARMv9-A aarch32 support is optional and not implemented on the Cortex-A520, for instance.
Steps To Reproduce
Use a device with a Cortex-A520
Attach BOINC to Einstein@Home (supporting arm-android-linux-gnu only)
Receive an aarch32 app
Run into an exec format error (8)
Expected behavior
BOINC should not fall back to aarch32 on Cortex-A520
System Information
OS: Android 14 (Samsung)
BOINC Version: 8.0.2
Additional context
This was observed on a volunteer's Samsung S24+
Problem: the CPU identifies as [Impl 0x41 Arch8 Variant 0x0 Paart 0xd80 Rev 1] (also notice the unrelated 'Paart' typo) which doesn't indicate that it's in fact architecture 9. Use a static list of part IDs that don't support aarch32 anymore also seems error prone. Maybe simply drop the fallback?
The text was updated successfully, but these errors were encountered:
brevilo
changed the title
[Android] aarch64 client requests aarch32 app version even when CPU doesn't support it
[Android] aarch64 client requests aarch32 app version even when CPU and project don't support it
Oct 4, 2024
FYI: the CPU architecture reported by /proc/cpuinfo does not indicate the actual architecture, according to this LKML thread. IOW, the 8 above does not refer to ARMv8 and should thus rather be ignored.
To make things even worse, we're seeing S24 devices which clearly have ARMv9.2-A cores in them, yet do not support their full instruction set. Looking at the CPU features reveals that they are effectively crippled down to armv8.6-a in case of the S24 Ultra. Interestingly enough BOINC reports ABI: arm64-v8a in host.product_name, which is closer to the truth but not that helpful (there).
Another related observation: I rebuilt the binary for ARMv8-A since this is the first ISA with AArch64 support and should thus be the lowest common denominator to fix (well, work around) the mess from my previous comment. However, while I could execute the binary on my ARMv8 test device (BOINC 8.0.3, Android 11, AArch64 kernel) directly in an adb shell, it immediately errored out under BOINC's anonymous platform (GitHub wiki entry is broken) with an execv: Exec format error. Back to square one. This doesn't make sense. Even if BOINC would run a AArch32 client for some reason, it should still be able to execv a AArch64 app, no? 🤷♂
Can someone confirm that anonymous platform is fully supported by BOINC on Android? Just to exclude the error above being a red herring...
Describe the bug
This seems to indicate that BOINC falls back to
arm-android-linux-gnu
(aarch32
) if a project doesn't supportaarch64-android-linux-gnu
. Is that correct and always the case? If so, it shouldn't be since as of ARMv9-Aaarch32
support is optional and not implemented on the Cortex-A520, for instance.Steps To Reproduce
arm-android-linux-gnu
only)aarch32
appexec format error (8)
Expected behavior
BOINC should not fall back to
aarch32
on Cortex-A520System Information
Additional context
[Impl 0x41 Arch8 Variant 0x0 Paart 0xd80 Rev 1]
(also notice the unrelated 'Paart' typo) which doesn't indicate that it's in fact architecture 9. Use a static list of part IDs that don't supportaarch32
anymore also seems error prone. Maybe simply drop the fallback?The text was updated successfully, but these errors were encountered: