i think the trick is to do an adb logdump when you get the update offered - before you install it, and you get the URL/identifier
there is some information useful: aboot.img: no update ever touched the area between 0x0000 and 0x10a8 - the kernel image probably starts at 0x800
0x3000 start a lot of (true) zeroes - there is nothing there up until
0x8000 starts anothe area that remained untouched by all patches, up to
0x77000 start another batch of true zeroes up to
0x78000 (that means something was there but is no longer) untouched area
0x8714e there are some bytes changed - something must be there
…
i only see dtb data fragments between
0x192010 and
0x1926d8
that’s an incredibly small range. if that is all, then the boot image holds only a fraction of the dtb’s, maybe only a single one
there might be a ramdisk present but with no changes to it whatsoever between updates
forget that. aboot.img is too small to include a kernel, its only 1.6 MB
so boot.img must be “it” but it has not a single human readable string. unfortunately I cannot apply “unpackbootimg” since I’m missing the headers.
if aboot.img is the bootloader, then why is it full of device tree information. it shouldn’t be there, this looks pretty non-standard.
and why does the bootloader say "“dtb not found” when the dtb’s are in fact within the bootloader config partition?
does that mean you have to reflash aboot if you need to change the device tree? that could brick the bootloader, wouldn’t it?
critical info to keep in mind:
aboot.img IS the bootloader. The boot sequence is as follows:
ROM bootloader (hardwired into CPU) checks checksum of SBL and executes it if correct (CPU’s can be in debug mode so they won’t check it and you can in fact update it to try a new SBL, but that’s usually a “fuse” register. you can only blow it but not re-enable it. once its blown, it will only load the SBL with the set checksum - point of no return.
SBL (secondary bootloader) loaded from a partition. it includes a cryptographic public key. with it, it checks if the actual “bootloader” in the aboot partition is correctly signed, it reads out the aboot header to see how to load that bootloader
aboot - has a user interface and vendor specific apps. can be updated (which ROM and SBL can NOT) but the update needs to be signed with the same key!
aboot can include any number of “apps” (read - vendor specific extensions that do all sorts of things - including charging the phone and displaying charge state when in bootloader mode, talk fastboot protocol via USB, …, …, … oem specific commands, too - some allow unlocking and/or changes to aboots configuration - this configuration is stored in other partitions, since aboot needs to be signed again if changed)
because of this, seeing .dtb -ish data in the aboot partition is worrysome. this could mean, kernels that do not use the same symbols can not be loaded without a matching (and vendor signed) bootloader!
Actually, it misses 2 things : the kernel size and the ramdisk size. But even if we had them, they are gunzip compressed. So they’ll be corrupted.
I had a few guess for the end of the kernel part but it is useless.
it looks like aboot decides based on the size of “tags” in the boot image if there’s a device tree database, or a “appended device tree”
tags must be 0 for appended device tree.
imgonnabuildabootimagerioghtnowandtestthat
where did you find that? i googled for that exact string and found Nothing at All
its too bad we don’t get the debug prints.
no matter what the error, if there is no dtb, no dtb database, or simply no matching entry in it, the fastboot error message is always the same.
maybe someone needs to open a phone and probe the debug pins. I bet one of them is a serial UART and those aboot debug prints get printed on it. the code to do exactly that is there!
well for starters, that aprticular aboot expects a msm-id with 3 entries, while all the ones that come with fairphone kernel only have 2 (which would cause that bootloader to bail
but I looked at the other branches of that same repo, and the aboots differ drastically, even though they are only for a different qualcomm chip series.
so there is no guarantee (quite the contrary, its unlikely) that because the qcom-dima-8x74 aboot does it like this, that ours would do it the same.
btw fastboot getvar all reports:
(bootloader) hw-chip:SDM632
(bootloader) hw-revision:10000
Edit: just found a counter example - another aboot for another qualcomm chip, in this case for the Lumia smartphone with qualcomm msm8227 CPU:
prop = fdt_getprop(dtb, root_offset, "model", &len);
if (prop && len > 0) {
model = (char *) malloc(sizeof(char) * len);
ASSERT(model);
strlcpy(model, prop, len);
} else {
dprintf(INFO, "model does not exist in device tree\n");
}
/* Find the pmic-id prop from DTB , if pmic-id is present then
* the DTB is version 3, otherwise find the board-id prop from DTB ,
* if board-id is present then the DTB is version 2 */
pmic_prop = (const char *)fdt_getprop(dtb, root_offset, "qcom,pmic-id", &len_pmic_id);
board_prop = (const char *)fdt_getprop(dtb, root_offset, "qcom,board-id", &len_board_id);
if (pmic_prop && (len_pmic_id > 0) && board_prop && (len_board_id > 0)) {
the sdm400 and 600 series will likely have yet another bootloader version. It’s really hard to fix this without knowing what our bootloader is looking for and having no debug output
your guess is as good as mine. I marked some pins that are potential candidate, but there are many more. Before connecting anything to them I’d suggest probing them with an oscilloscope during early device boot to see of they show any signal. In my last job we had a lab where I could have easily done so, but right now I’m a bit hardware limited
I didn’t even think about UART on the headphone jack, I didn’t realise that was a thing. It’s definitely worth finding out.
We DO definitely know there IS a debug UART, because the kernel command line puts a debug console on one
So you’d see a 115.2 kHz binary signal on the TX pin during boot.
I would assume it’s likely a 1.8 volt signal, that’s what most modern chips use, but better verify that with a high resistance probe (oscilloscope) before connecting anything and worst case frying the board
This would be a perfect experiment for one of the gentlemen that already bricked heir phones and cannot boot a kernel anymore
But if anyone has a cable to test for debugging on the headphone jack, that needs to be tested. How can we find out if the FP3 has that? Ask support?
Breaks before? You can’t even get into fastboot? How did you manage that?
The first step would be to recreate k65onyx test setup - so FP3 opened on a bench, without the back-case, but still as many modules connected as possible (possibly even the screen). Then connect USB (this will get it into fastboot for charging, even if you can’t press the power button). As the pads are now exposed, you can “probe” them with the probe input of an oscilloscope to measure not just the steady voltage but visualize the signal. The UART should be very distinct with its rectangular bit-stream at 115200 Hz. Knowing which pin is the UART (if there is one) would be a great help.
Same possibly with the headphone jack. As a first step I’d just connect a split headphone cable and probe it with the oscilloscope during boot, see if there’s anything there.
I have to admit I don’t really know how a headphone-jack debugging signal looks like and how it might need to be decoded … ?
but when you say “fastboot boot <boot.img>” it should ignore what stuff is on the phone and just try to boot it - unless your bootloader thinks its locked or is actually broken.
I found this as a circuit plan for headphone debugging. It’s for a Nexus4, but that’s also msm based. I have no idea if that’s compatible.
Edit: reading more about that, it looks like there needs to be support from the sound circuitry, and the Nexus4 definitely has a different audio solution than FP3, so we have no indication yet if that would work or not
The device ignores the boot partition with fastboot boot img, but I’ve changed the vbmeta and system (not boot). The verification chain is probably broken. So I have to wait for a dump of these two partitions.
Why I did that? The device is treble compatible, so : https://source.android.com/setup/build/gsi
I think, once we have the original vbmeta, flashing it with the option --disable-verity and/or --disable-verification should be enough to port a gsi (and have a custom ROM or AOSP without gapps)
