thanks. I found the source of the weird strings. It’s google’s “brotli”
this is still weird, but at least now I know where the weirdness comes from.
thanks. I found the source of the weird strings. It’s google’s “brotli”
this is still weird, but at least now I know where the weirdness comes from.
anyone here interested into looking into this?
the FP3’s chipset is supposed to include a radio chip. The driver is in the kernel, but doesn’t show up in dmesg, so it might be a device tree / configuration issue. Since the “chip” is actually an integral part of the system-on-a-chip it might be possible to copy paste the config from another device with the same hardware (linked in linked thread)
tl;dr
I read a lot. but I couldn’t find an answer to: WHAT was the solution in the end? How did you get the kernel running? What was not working?
From https://source.codeaurora.org/quic/la/kernel/lk/tree/platform/msm_shared/avb/libavb/avb_slot_verify.c?h=LA.UM.7.6.2.r1-09200-89xx.0 line 694 :
if (vbmeta_header.flags & AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED) {
AvbSlotVerifyResult sub_ret;
avb_debugv(
full_partition_name, ": VERIFICATION_DISABLED bit is set.\n", NULL);
/* If load_requested_partitions() fail it is always a fatal
* failure (e.g. ERROR_INVALID_ARGUMENT, ERROR_OOM, etc.) rather
* than recoverable (e.g. one where result_should_continue()
* returns true) and we want to convey that error.
*/
sub_ret = load_requested_partitions(
ops, requested_partitions, ab_suffix, slot_data);
if (sub_ret != AVB_SLOT_VERIFY_RESULT_OK) {
ret = sub_ret;
}
goto out;
}
I guess that’s load_requested_partitions which is broken
the answer is chaos-magic
please elaborate in more detail
spell that @k4y0z - magic
@k4y0z managed to get it to work. Main changes:
in combo with @k4y0z own kernel modifications which in turn are based on @z3ntu kernel modifications of the fairphone released kernel sources which were needed to get the kernel to actually compile, boot in general and with TWRP in particular.
But a big factor was probably using the android build environment instead of kernel make files to package the image with device tree in the way aboot wanted it.
for more details you have to ask the lords of chaos
Actually using the android build environment ist just way more convenient, when building TWRP.
Im quite certain with my modifications and config it would also work using the build-scripts.
The main things to get it working where enabling (probably only needed for fastboot boot
, not when flashing the kernel)
CONFIG_BUILD_ARM64_DT_OVERLAY=y
Which got rid of the “dtb not found” error, but requires using an external device tree compiler (DTC_EXT).
And patching the kernel to ignore the skip_initramfs
flag the bootloader sets. (So it actually loads the TWRP initramfs instead of booting straight into the OS)
My config also enables the serial console (UART) which was usefull for debugging, but not required for it to work now.
I actually had tried that ( building the overlay with system installed dtb compiler ) but I still had eun into dtb not found, must have been how the dtbo was included unto the boot .img . There is aprox 5 different ways
I tried with @z3ntu a while ago with just that option enabled and built without android environment, and that made the error disappear.
Are you sure you used the Image.gz-dtb?
I am pretty certain. I tried several things:
I think it needs one of these Image with CONFIG_BUILD_ARM64_DT_OVERLAY=y
This with CONFIG_BUILD_ARM64_DT_OVERLAY=y
is what you need.
We used a 3.3V UART which worked fine (only connected TX and GND of course)
Hi, my FP3 just arrived here today. Is there anything I should do - that would be of help to the rest of you - before I turn it on, downloading OTAs and so on?
Hi, I let the others reply to your question. But I suggest you to do at least the following:
dd
in order to backup the following partitions:Doing this should guarantee that as long as you are careful to keep your system untouched in at least one of the two slots (you can experiment on the other), you would have a very hard time bricking your phone irreversibly. And if you are unhappy with some update, you should also be able to actually make a real “factory reset” of the phone.
Probably you don’t actually need to backup as much as that, but I preferred to keep on the safe side.
I second that. We haven’t had a backup of the original firmware of the phone, because by the time TWRP was available everyone had already installed OTA updates.
Hi,
Thanks for the advice! I was able to unlock the bootloader, enable USB debugging (to enable adb), run “adb boot bootloader” (to get to fastboot mode), and download TWRP from Releases · chaosmaster/android_device_fairphone_fp3 · GitHub
But when I tried:
$ fastboot boot twrp-3.3.1-0_k4y0z-20200202-02-fp3.img
downloading ‘boot.img’…
OKAY [ 0.841s]
booting…
FAILED (remote: unlock device to use this command)
finished. total time: 2.063s
Edit: Okay, apparently it worked the second time. It seemed to factory reset itself the first time, but it now booted into TWRP.
As for the version that came with the phone, it lists as 8901.2.A.0110.20200109 - so if you need something older than that, I’m afraid I can’t help you.
Really? I did not install any update, and kept the Fairphone in the box, and I went through all this process of making backups yesterday evening.
Actually, to be completely honest, that is not fully true. When trying to get the URL from one update, the system actually went through the whole download and started updating itself before I noticed it. However, before it finished, I interrupted it and did a factory reset. I could check that the version was kept the same as the original one.
However, now that I could open a shell as root on it by using the TWRP image, I checked the partition images from the a slot and compared them to those of the b slot. Some images were still the same (either the update was not intending to change them or did not had the time to do it), and some were different. I assumed the aborted update was responsible for changing the non-current slot (slot b), and that the current slot (slot a) was the original. I later cloned all images from slot a into slot b (mostly as an exercise), and checked that the phone properly booted also on slot b.
So it is my impression that I still have the original version (from September 2019) on my Fairphone. That said, I found something really weird. In the processes of learning how all of this works, I used TWRP to make backups before I actually went manually with the shell and used dd to make the backups myself of all the partitions (and not just those proposed by TWRP). Later on (but without connecting the phone to the internet or installing anything myself and after a factory reset), when I did the backups manually, I compared the backups from TWRP to those I had done manually. Well, they were all the same, except for modemst1
and modemst2
, that are called efs1
and efs2
by TWRP. Any idea why?
The TWRP for FP3 is still work in progress. Best to tell @k4y0z , if there’s a mismatch with one of the partitions, its likely that TWRP has a partition link wrong or something.