[Seine][pdx201/xqau52] cannot flash system and vendor images

[AngryGami]

Platform: Seine Device: xqau52 Kernel version: 4.14 Android version: 10 Software binaries version: Software binaries for AOSP Android 10.0 – Kernel 4.14 – Seine (latest) (from June 15 2020)

Description After I've build aosp tree (from branch android-10.0.0_r37 and no changes from my side, plain vanilla repo) and got image files I've tried to run following sequence of commands against my device:

fastboot flash boot boot.img
fastboot flash vbmeta vbmeta.img
fastboot flash dtbo dtbo.img
fastboot flash recovery recovery.img
fastboot flash system system.img
fastboot flash vendor vendor.img
fastboot flash userdata userdata.img

All of which succeeded except system and vendor parts with following messages:

Sending sparse 'system' 1/2 (785636 KB)            OKAY [ 18.369s]                                                      
Writing 'system'                                   FAILED (remote: 'No such partition.')                                
fastboot: error: Command failed 

Sending 'vendor' (43688 KB)                        OKAY [  0.961s]                                                      
Writing 'vendor'                                   FAILED (remote: 'No such partition.')                                
fastboot: error: Command failed                                                                                          

I've also tried to flash sysem_a and vendor_a as well as system_b and vendor_b partitions explicitly, but with same result. Fastboot I use is: fastboot version 29.0.5-5949299

What could possibly be wrong with this?

[MarijnS95]

You shall not flash recovery until we have fastbootd working there.

Then, use either fastboot flashall which reboots into fastbootd to flash vendor and system, or manually fastboot reboot fastboot before flashing vendor and system. Don't forget to restore stock recovery first though.

We'll need some official documentation updates for this...

If you think this is weird, refer back to https://github.com/sonyxperiadev/bug_tracker/issues/604.

[AngryGami]

If I understand correctly I need to:

1. restore stock recovery partition. (this is just because I've accidentally screwed up my device by flashing aosp recovery image)
2. do

   fastboot flash boot boot.img
   fastboot flash vbmeta vbmeta.img
   fastboot flash dtbo dtbo.img
   fastboot flash userdata userdata.img

3. restart into fastbootd by fastboot reboot fastboot
4. continue with following:

   fastboot flash system system.img
   fastboot flash vendor vendor.img

   There is also product.img present in aosp build results, should I be concerned with it?

[MarijnS95]

There's also vbmeta_system. Easiest for now is probably to:

1. Restore stock recovery;
2. Build the rom (already done);
3. Delete recovery.img (we have to see about disabling this from the build temporarily, or rather fix the issue with it. It boots but fastbootd acts up);
4. fastboot flashall;
5. Note down exactly what it flashes, when.

[AngryGami]

I'm sorry but I just get more confused after your last comment :( Why I need to delete recovery.img? I'm not going to reflash it anyway so how this matter? What exactly you mean by "Note down exactly what it flashes, when." and how this should help?

[MarijnS95]

Because I forgot to insert point 4., apparently. Fixed.

[AngryGami]

Now, when I've manage to flash everything, device fall into boot loop and eventually just complaints that image is corrupt and refuse to boot completely. Here is what I've did:

C:\images\seine-orig>ls 
android-info.txt
boot-debug.img
boot.img
dtbo.img
product.img
super_empty.img
SW_binaries_for_Xperia_Android_10.0.7.1_r1_v8b_seine.img
system.img
userdata.img
vbmeta.img
vbmeta_system.img
vendor.img

C:\images\seine-orig>fastboot flash oem SW_binaries_for_Xperia_Android_10.0.7.1_r1_v8b_seine.img 
Sending 'oem' (256392 KB)                          OKAY [  5.723s]
Writing 'oem'                                      OKAY [ 40.620s]
Finished. Total time: 46.547s

C:\images\seine-orig>fastboot flashall
--------------------------------------------
Bootloader Version...: 1320-2835_X_Boot_SM6125_LA2.0_Q_31
Baseband Version.....: 1320-5255_59.0.A.1.296
Serial Number........: QV710D9R3A
--------------------------------------------
Checking 'product'                                 OKAY [  0.000s]
Setting current slot to 'a'                        OKAY [  0.010s]
Sending 'boot_a' (65536 KB)                        OKAY [  1.496s]
Writing 'boot_a'                                   OKAY [  0.357s]
Sending 'dtbo' (8192 KB)                           OKAY [  0.182s]
Writing 'dtbo'                                     OKAY [  0.050s]
Sending 'vbmeta' (4 KB)                            OKAY [  0.000s]
Writing 'vbmeta'                                   OKAY [  0.000s]
Sending 'vbmeta_system' (4 KB)                     OKAY [  0.000s]
Writing 'vbmeta_system'                            OKAY [  0.000s]
Rebooting into fastboot                            OKAY [  0.007s]
< waiting for any device >
Sending 'super' (4 KB)                             OKAY [  0.000s]
Updating super partition                           OKAY [  0.009s]
Resizing 'product_a'                               OKAY [  0.006s]
Resizing 'system_a'                                OKAY [  0.000s]
Resizing 'system_b'                                OKAY [  0.010s]
Resizing 'vendor_a'                                OKAY [  0.006s]
Resizing 'vendor_b'                                OKAY [  0.010s]
Resizing 'product_a'                               OKAY [  0.010s]
Sending 'product_a' (302552 KB)                    OKAY [  7.119s]
Writing 'product_a'                                OKAY [  2.111s]
Resizing 'system_a'                                OKAY [  0.040s]
Sending sparse 'system_a' 1/2 (524284 KB)          OKAY [ 12.716s]
Writing 'system_a'                                 OKAY [  3.295s]
Sending sparse 'system_a' 2/2 (377752 KB)          OKAY [  9.162s]
Writing 'system_a'                                 OKAY [  2.510s]
Resizing 'vendor_a'                                OKAY [  0.041s]
Sending 'vendor_a' (43688 KB)                      OKAY [  1.016s]
Writing 'vendor_a'                                 OKAY [  0.554s]
Rebooting                                          OKAY [  0.000s]
Finished. Total time: 59.590s

[MarijnS95]

It shouldn't bootloop but rather sit on the Sony logo since https://github.com/sonyxperiadev/device-sony-seine/commit/8c27dcfc3e5a84a48235acf4863a57387b11521e

The breakage that prevents it from booting into android seems to be a recent change in the kernel, confirmed with a known-working ramdisk. We're on it.

[AngryGami]

Well it does boot loop :) I'm not making stuff up. It is not permanent loop, it tries couple times and then just shows "device is corrupt" message. ramdisk image doesn't seem to be included into above list of partitions... shouldn't it be there?

[MarijnS95]

That message implies - of course - to check if the linked commit is included in your build...

Ramdisk is combined with the kernel into boot.img. (And with a special-sauce recovery ramdisk into recovery.img).

[jerpelea]

@AngryGami there was a kernel regression that we discovered last night and was fixed. I will rebuild the kernel blobs and push them

The flash procedure will soon be updated on the build guide but for now please use the one from this page

[AngryGami]

Ok, thanks.

[AngryGami]

I've updated to latest source and now it won't build with following error:

FAILED: ninja: 'out/target/product/pdx201/obj/KERNEL_OBJ/usr', needed by 'out/target/product/pdx201/obj/EXECUTABLES/ipacm_intermediates/IPACM_Main.o', missing and no known rule to make it
11:46:43 ninja failed with: exit status 1

[jerpelea]

I just built the PDX201 and builds fine.

It looks like you are having issues building ipacm

Please run repo_update to get the needed patches .

[AngryGami]

Sorry, I forgot to run repo_update after repo sync :(

[AngryGami]

Almost there... Out of pure curiousity how long it takes for you to do full build from scratch? Now after I've managed to build everything and flash device it still refuse to boot. Now it stuck in "android" splash screen and logcat shows this:

03-09 22:53:16.040   787   793 I sensors.qti: handle_diag_settings:343, Setting SNS TX MODE to STREAMING
03-09 22:53:16.040   787   793 E Diag_Lib: diag: In diag_configure_peripheral_buffering_tx_mode, request for buffer configuring pd 3
03-09 22:53:16.041   787   793 E Diag_Lib: diag: In diag_configure_peripheral_buffering_tx_mode, unable to set peripheral buffering mode, ret: -1, error: 5
03-09 22:53:16.041   787   793 E Diag_Lib: diag: In diag_configure_peripheral_buffering_tx_mode, request for buffer configuring pd 10
03-09 22:53:16.042   787   793 I sensors.qti: handle_diag_settings:355, Set SNS TX MODE success and return val: 1
03-09 22:53:19.543   678   678 D Netd    : netd waited 5s for bpf.progs_loaded, still waiting...
03-09 22:53:22.332   701   701 I health@2.0-serv: type=1400 audit(0.0:293): avc: denied { read } for name="present" dev="sysfs" 
ino=52248 scontext=u:r:hal_health_default:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
03-09 22:53:22.332   701   701 I health@2.0-serv: type=1400 audit(0.0:294): avc: denied { open } for path="/sys/devices/platform
/soc/1c40000.qcom,spmi/spmi-0/spmi0-02/1c40000.qcom,spmi:qcom,pmi632@2:qcom,qpnp-smb5/power_supply/battery
/present" dev="sysfs" ino=52248 scontext=u:r:hal_health_default:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=1
03-09 22:53:24.545   678   678 D Netd    : netd waited 5s for bpf.progs_loaded, still waiting...
03-09 22:54:44.571   678   678 I chatty  : uid=0(root) netd identical 16 lines
03-09 22:54:49.572   678   678 D Netd    : netd waited 5s for bpf.progs_loaded, still waiting...

It's hard for me to tell if this log is enough to guess what is wrong but there are no obvious errors above that. These are just last messages I can see.

[MarijnS95]

Out of pure curiousity how long it takes for you to do full build from scratch?

That highly depends on the machine... But I can tell you a nice ThreadRipper with enough RAM and an SSD completes these in under 30 minutes. Overclocking not applied. Now, whether the saved hours in terms of build-time are worth the cost... That's an entirely different question.

We need more logs, this doesn't really tell anything except that something earlier failed to start.

[jerpelea]

@AngryGami
The Android logo bootloop was caused by the vibrator HAL Please sync and rebuild since the bug was fixed yesterday

PS.There wil be soon a new vendor release for July

[AngryGami]

I've rebuild from recent state of source and still got same behavior. This is not "bootloop" but something else. Phone is just stuck showing "android" splash screen. stuck.log Here is example full log.

[MarijnS95]

There have been many variations of crashes and hangs over the past week, at least you gets adb up as my device is still stuck on the Sony logo :grin: (perhaps the numerous local changes I have on top... sigh).

@AngryGami Would you mind creating another log, this time with logcat -b default,kernel? That includes dmesg so that we can see what init is doing. I don't immediately see what it's waiting for... Init will tell us that.

[AngryGami]

Sure stuck2.log Now it show some slow activity repeating:

03-10 20:26:50.551     0     0 I pmi632_charger: somc_aicl_irq_handler: IRQ: aicl-done
03-10 20:26:50.563     0     0 I ALG     : cap_learning_update: [SOMC CL][OFF] charge_status:1 bsoc_cp:10000
03-10 20:26:50.567     0     0 W healthd : battery l=100 v=4381 t=29.7 h=2 st=2 c=211 fc=3456000 cc=0 chg=u
03-10 20:26:51.358     0     0 E i2c_geni 4a88000.i2c: i2c error :-107

[jerpelea]

@AngryGami Please resync, build and flash the device with this script

fastboot reboot fastboot fastboot flash boot boot.img fastboot flash dtbo dtbo.img fastboot flash oem odm.img fastboot flash product product.img fastboot flash system system.img fastboot flash userdata userdata.img fastboot flash --disable-verity --disable-verification vbmeta vbmeta.img fastboot flash vbmeta_system vbmeta_system.img fastboot flash vendor vendor.img fastboot erase metadata

I have my device my device booted to Android and I am comparing the sleep battery usage

[AngryGami]

I understand that this is not your problem, but it takes 6 hours for me to rebuild android from scratch. So this "fast iteration" approach when I have to rebuild android every day kinda doesn't work for me. Could you please elaborate a bit why this new flashing procedure is needed suddenly?

[MarijnS95]

Incremental builds shouldn't take that long at all. But be sure to run make installclean before building, so that stray files aren't picked up.

[AngryGami]

@MarijnS95 Incremental builds doesn't take long, but I can't tell if these builds are actually include changes that are applied during sync. From my experience it is quite opposite (not only with this project but in general). I don't want to spend 6 hours trying to figure out that my results are invalid because build system either didn't take newer source or reused some old artifacts. What exactly make installclean does? I've just ran it and it deleted all images but leave everything under out/target/product/pdx201/obj/ and out/target/product/common, which means that next time I build it will just reuse whatever is there and won't try to rebuild changes made to source (unless *.mk file is changed/touched). In other words how can I be sure that after that whatever was applied during repo sync and repo_update will be actually rebuild and included into result?

[MarijnS95]

but I can't tell if these builds are actually include changes that are applied during sync

That would make no sense and inherently mean the build system is broken beyond repair. Are you sure? I use it more than daily and never ran into that: it has always been PEBKAC. Then again an incremental build doesn't take 6 hours, even if building every device currently supported in SODP.

installclean deletes both images and the packaging folders used to create these (out/target/product/pdx201/{root,system,vendor} etc), because the AOSP build system is too dumb to package only files that are explicitly included by the build: I guess because of old LOCAL_POST_INSTALL_CMD and the like, which might just blindly emit more files without telling the build system to see them as a dependency for the final image. If there's garbage from a previous build there which was deleted by us from device repos (eg. removed /{bt_,}firmware symlink) it'll persist in those folders and in the final images.

[jerpelea]

@AngryGami you can reduce build time by

rm -r out/target/product

then start the build This should reduce your build time by a noticeable margin

then make -j

NOTE: Depending on your amount of RAM and if you have too many cores and less RAM make -j<RAM GB/2>

ex a 8 core system (16 threads) with 16Gb ram 16/2=8 threads (limited by the amount of available RAM)

make -j8 while normally you whould use make -j16 for 32Gb RAM

[AngryGami]

@MarijnS95 Couple messages above you've said:

...device is still stuck on the Sony logo 😁 (perhaps the numerous local changes I have on top... sigh).

Are you sure that at least some of the problems you have not been caused by build system misbehaving? When I'm saying "how can I be sure" this not about my trust in build system :) this is literally means - how can I ensure that whatever had been changed during sync were included during rebuild? Maybe there is some log or maybe change in some ninja file or something that I can use to validate that?

@jerpelea Thanks for advice. I'm using 4 core (4 threads) 18Gb RAM virtual machine (in proxmox based cluster) and this is pretty much everything I can get for now :). I always run build using -j4 so this kinda match your suggestion already.

[AngryGami]

@jerpelea Btw, there is no "odm.img" image produced from build. To flash oem partition I've used image from here but only once... should I flash it every time I want to try new build?

[MarijnS95]

Are you sure that at least some of the problems you have not been caused by build system misbehaving?

I have tens... No... Hundreds of local changes in-flight, all in various stages of development, refactoring and validation, in favour of progressing SODP forward. There must be at least one change that conflicts (eg. not yet configured for that particular platform), and it might even be something as silly as sepolicy which I roll in enforcing at all times. I just haven't taken the 30 seconds to check out some sane branches and rebuild. If the build system would randomly decide to act up, how come all my other devices are absolutely fine whatsoever, on every build I throw at them (excluding known mistakes in our trees/locally, of course)?

how can I ensure that whatever had been changed during sync were included during rebuild?

Oh - if this was a real question, not a way to mock the build system: Look closely at the changes pulled in by repo sync, and in particular recently changed sonyxperiadev repositories. These usually entail changed files and newly added dependencies which you have to check yourself on-device, in the out directory, or simg2img and mounting the image. In terms of (compiled) code changes... I could write ten books and not cover 1%. There's no one-size-fits-all approach to validating, it heavily depends on the context. Trust me, I haven't hit a single case where a local change didn't end up on the device because of the build system: rather because of typos, me misinterpreting build rules, and that sort of stuff.

there is no "odm.img" image produced from build. To flash oem partition I've used image from here

Yep, you have to get the image from there. I think Alin's script assumes it's unzipped under that name there :)

but only once... should I flash it every time I want to try new build?

Once is fine, as long as you don't flash anything over it (like stock).

[AngryGami]

Finally :) it works! Thanks everybody.

[MarijnS95]

Yup, for me as well. As expected it was a local mess, together with unfinished sepolicy :tada:

[stefanhh0]

@AngryGami this can be closed then? If so, please close it.

Thanks and best regards Stefan

[DDzwiedziu]

We'll need some official documentation updates for this...

If anyone is interested (\s) then I've just tripped over those…

[jerpelea]

please run "fastboot reboot fastboot" before you try to flash the images

[DDzwiedziu]

I would like that very much, but it hangs on the Sony logo and < waiting for any device >.

I've tried [1] (twice, as for the first time I didn't erase metadata) and about to try [2].

P.S. Do you have any other channels for such communication? I'm not fond of being OT, beyond my first comment.

[1] https://github.com/sonyxperiadev/bug_tracker/issues/652#issue-743167311 [2] https://forum.xda-developers.com/t/rom-unofficial-lineageos-18-1-for-xperia-10-ii-gcam-performance.4219081/post-84883167

[jerpelea]

please use flashtool to flash the official SW https://developer.sony.com/develop/open-devices/get-started/flash-tool

then restart the flash procedure