It would be surely interesting to know more about it…If this quote is from another thread, could you tell the link?
no, it was in a private message about the failling 0.18 test by @ itsclarence,
@ Chimpthepimp said he will have a look into the sources some days after, but forgot or don’t find, i don’t know as i have no news since that (september 2021)
Ok, if it can be found in the sources, I can probably figure it out somehow. I am still a Linux newbie (since 30 years…), but I really love find and grep now…(no problem with millions of files )
There actually is one 64-bit object file bpf_kern.o in /system/etc/bpf/… I assume Android will stop immediately as soon as this file is loaded by the kernel. Funny that this 64-bit file also exist in the LOS 16 build, where it seems to do no harm. But maybe the LOS build does not touch the file on startup, while the e/OS build does? That brings up the question, if or how startup procedure of e/OS could be different from LOS using the same local manifest and hence the same kernel configuration…?
Edit: No: Deleting the folder /system/netd/bpfloader from the source tree will prevent the 64-bit file bpf_kern.o from being included in the build, but, unfortunately, e/OS will still not boot properly…
Actually, using LOS boot.img on the e/OS Rom makes the device reboot to recovery instead of bootloader. So likely the fault lies within the e/OS boot.img, but that was expected anyway. I wonder if it is possible to somehow catch some kind of boot log to see what’s really happening…
BTW: The recovery.img is the same with e/OS as with LOS, both working fine…
Don’t know if this still works, but you can try this: here
I think I managed to fetch the respective last_kmsg:
[ 16.170502] sec_jack_probe - defer as codec_probe_done is false
[ 16.244221] selinux: SELinux: Could not stat /metadata: No such file or directory.
[ 16.253819] msm8226-asoc-tapan sound.44: Looking up qcom, cdc-lineout-spkr-gpios property in node /soc/sound failed -22
[ 16.255524] msm8226_asoc_machine_probe Ear adc LDO node not available
[ 16.256564] sec_jack_populate_dt_pdata : can not find the earjack-micbias-gpio in the dt
[ 16.256689] sec_jack_populate_dt_pdata: can not find earjack-micbias-ldo in the dt
[ 16.257123] sec_jack_gpio_init : gpio_request failed for 435
[ 16.257700] snd_soc_dapm_force_enable_pin is still needed, do not turn off
[ 16.258126] snd_soc_dapm_force_enable_pin is still needed, do not turn off
[ 16.312555] cyttsp5_i2c_adapter 79-0024: [TSP] iovdd_vreg error 0
[ 16.438732] Restarting system with command ‘bootloader’.
[ 16.440155] Calling SCM to disable SPMI PMIC arbiter
Funny enough, all those messages also appear in the last_kmsg of the LOS build, so it remains an absolute mystery to me why the kernel initiates the restart to bootloader…
Ok, I will give it a final try, using the “android” repo instead of “releases” (never realised the difference anyway), and clear ccache before (because of the mysterious 64 bit file in the build - I did several 64-bit builts of e/OS with this setup…). If that won’t work I think I’ll give up on the S5 mini…
Hmm, even after building again with a clean ccache the rom still reboots to bootloader. I am running out of ideas.
@Manoj: I am beginning wondering if anyone lately succeeded in building a pie (or any) version for arm7 at all…?
Anyway, I will stick to the LOS 16 unofficial build for now. At least , now it has the e bootanimation (after testing if the bootanimation would cause the problem), so I at least can pretend it was e .
However, especially when using several devices, the e services do have their advantages…
Do you want to inspect the working pie boot for kminilte here
Would be interesting to try and build version 0.9, and see if it is booting. I assume now that the error somehow relates to the system.img, I will check the e/OS boot.img with the LOS build…
Edit: Yes, both boot.img are interchangeable with the LOS build, so there must be something wrong with the system.img… (system partition is 2.2 GB though, system.img is 1.5 GB, no error when flashing)
I think those patches were found here: android_device_samsung_smdk3470-common/patch at P · Spookcity/android_device_samsung_smdk3470-common · GitHub … I hope that helps
All the best and kind regards
Thanks for the link, much appreciated! I find references to G800F in some comments. I have G800H (qcom). Would the patches be applicable?
Best regards and a happy weekend!
Ah no the ones i used from spookcity are for Samsung Galaxy S5 mini - (G800F/G800M/G800Y) “Kminilte”, only. For the H version you will need different sources…
And that ? (s3neo)
( Qualcomm MSM8226 Snapdragon 400 / Quad-core Cortex-A7 - 1.6 GHz / Adreno 305 )
Thanks for the hint! I indeed missed the Pie versions for some Samsung devices. So it seems there is a special problem with my SM-G800H, not with e building Pie in general. This is good news in a way. However, the thought that it probably has a very simple solution (if you only know where to “tap”) annoys me… But know-how-wise I only scrached the surface of rom building.
The post on XDA I know very well, I made it myself
Hi @Manoj, although this has no priority at all, I would be very happy if it would be possible to have someone of the team give his opinion on what typical reasons in this case could be, or maybe if it makes sense at all to go on trying…?
One of the reason why some builds on LOS boot while the /e/OS ones do not is because the device manifests on /e/OS side are not updated. We /e/OS is not exactly a copy of LOS code. There are changes which at time do not work in builds. /e/OS not having dedicated maintainers for a number of devices is another issue.
Thank you, @Manoj, for giving your opinion, much appreciated!
After successfully building e for two other unsupported devices, always starting from an unofficial LOS build, I thought it to be the rule, that LOS device manifests would work with e. Now I understand from your reply that this is not necessarily the case.
I noticed there are about 40 repos (of about 700, depending on the version) in the default manifest specific to e, mostly forked from LineageOS. Are there “typical” (i.e. “e-specific”) issues to handle in such a case (just wondering what to look for)?