Before flashing the latest snapshots onto this board I thought I would review the current state and I have found several confusing inconsistancies which I hope someone can resolve.
I suppose I have to attempt to reply here… since i built the bootloader packages here… however be aware that we are a bit in the dark here, and I don’t have all answers…
As delivered, the kernel reports that write protect is off on all UFS devices, but ufs-provision_toshiba.xml in dragonboard-820c-bootloader-ufs-linux-31 sets bLUWriteProtect=“1” for LUs 1 to 4. Does this tag have any effect or was it not set when my board was configured?
First note: There is no guarantee at this point that the board you received was flashed/provisioned with the file we released. While we want to ensure that Arrow uses our files during the board production, the process is not finalized yet. I would expect them to use the same xml file, since it originally comes from QCOM, but no guarantee. On the long term, the plan is to Arrow to use all our released files, but for this batch, the boards were flashed before we released them…
bLUWriteProtect=1 means power-on write protection, =2 would mean permanent write protection. See commit 57d104c153d3d6d7bea60089e80f37501851ed2c in kernel for an initial explanation.
As I understand it, bit 60 of the attribute flags of a GPT partition entry denotes read-only. lsblk does not seem to recognise this bit as meaning read only while reporting it set in the PARTFLAGS column in each partition of LUs 1 to 4 except partition 32 of LU 4, sti.
In addition, sti (partition 30 of LU 4 now as system and recovery have been removed), in gpt_both4.bin of dragonboard-820c-bootloader-ufs-linux-31 does not have bit 60 of the attribute flags set, whereas all the other partitions of LUs 1 to 4 do. Is sti special?
sti is not special, as far as i know… Note that all files released in the bootloader package are coming from here: https://git.linaro.org/landing-teams/working/qualcomm/db-boot-tools.git/tree/dragonboard820c you can see the changes we did in the partition table.
In patch.xml of dragonboard-820c-bootloader-ufs-linux-31, there is one instance of start_sector=“NUM_DISK_SECTORS-1.” for each LU which reads start_sector=“NUM_DISK_SECTORS-1”. Does the full stop (period) have any significance? If so, then the missing one may produce unexpected results, if not, then why include them at all?
yes, correct. I am seeing that now. from the documentation about the firehose protocol (which describes the patch command) it’s not obvious whether it’s needed or not… Looking at QCOM source code for their own flashing tools (not our open source variant), the ‘.’ is interpreted as a comma when doing string to number conversion, e.g. "// user did this 12.3, so return 12 " , so assuming we can trust that… it’s safe to ignore in this specific example.