platforms: add support for Arduino UNO Q

[lool]

Add a a new qrb2210-unoq platform with two storage configurations and
corresponding partitions.conf files:

• emmc-16GB: identical to RB1, works with the Android version of the
  Agatti boot binaries and a chainloaded U-Boot
• emmc-16GB-arduino: same as emmc-16GB but with an extra userdata
  partition, as done in Arduino factory images; this partition can
  optionally be preserved when reflashing the OS

[lool]

Hi, this builds upon the commit from @SuMere in #46, but I can't push to his branch nor mark it as non-draft.

@ndechesne I've implemented the naming of emmc-16GB and emmc-16GB-arduino; however, I have NOT updated the list of partitions to match the ones from RB1; do we want to transition to the new names as to support upcoming boot firmware? we should probably discuss if there is a risk of end-user impact or for the AppLab upgrade steps

[ricardosalveti]

Unknown userdata.img referenced in platforms/qrb2210-unoq/emmc-16GB-arduino/partitions.xml
Unknown userdata.img referenced in platforms/qrb2210-unoq/emmc-16GB-arduino/rawprogram0.xml

[ricardosalveti]

We should probably align the partitions here, the new boot firmware is supposed to drop soon.

[lool]

NB: the only difference between the previous RB1 partitions.conf and the initial UNO Q one is that hyp_a and hyp_b were bumped from 5kiB to 8MiB:

--partition --name=hyp_a [---size=512KB-] {+--size=8192KB+} --type-guid=E1A6A689-0C8D-4CC6-B4E8-55A4320FBD8A --filename=hyp.mbn
--partition --name=hyp_b [---size=512KB-] {+--size=8192KB+} --type-guid=3D3E3AD2-8FF3-4975-A7E7-0E8A10B69F0D --filename=hyp.mbn

[ricardosalveti]

Break this one in a separated commit.

[lool]

done

[lool]

TBH I don't really like the fact we list the Arduino userdata partition. I think ptool should mix:

• list of partitions coming from the boot firmware / based on the features or versioned boot contract from the boot firmware
• list of partitions expected by HLOS (e.g. rootfs/esp)
• Arduino OS, meta-qcom, qcom-deb-images could be valid HLOSes implementations that add their partition definitions in a defined place of a partitions.conf.in template

I think we should address this globally in ptool at some point, but I lack the time to contribute this right now.

[lool]

We should probably align the partitions here, the new boot firmware is supposed to drop soon.

Yeah I agree; I did it in a separate commit to have the original (factory) partitions in the history, hope that makes sense

[lool]

Note from the other PR:
GUID seems wrong for the userdata partition, it should be 0fc63daf-8483-4772-8e79-3d69d8477de4, or perhaps 933ac7e1-2eb4-4f13-b844-0e14e2aef915 if we are ok to mount this as /home instead of /home/arduino. See https://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ for a table explaining the GUIDs and how systemd will interpret them.

[ricardosalveti]

I think 0fc63daf-8483-4772-8e79-3d69d8477de4 would be more generic.

[ndechesne]

TBH I don't really like the fact we list the Arduino userdata partition. I think ptool should mix:

• list of partitions coming from the boot firmware / based on the features or versioned boot contract from the boot firmware
• list of partitions expected by HLOS (e.g. rootfs/esp)
• Arduino OS, meta-qcom, qcom-deb-images could be valid HLOSes implementations that add their partition definitions in a defined place of a partitions.conf.in template

I think we should address this globally in ptool at some point, but I lack the time to contribute this right now.

I agree. ptool is supposed to be used to 'reset' a system in a "System Ready" like state. so even 'rootfs' arguably does not belong here. but as you said, we need something that works for us today.