Dualboot/partitions

Issues
1

In the specification you mention the UFS has size of 128GB.

Based on the lsblk most of the space is allocated on sda5.

Is there a possibility to change this and split the partition in two (or more) to allow booting multiple systems or to create the A/B layout typical for embedded (well also mobile) environment.

Could you also expand on the purpose of those partitions? Just brief description of those from the list.

lsblk
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda       8:0    0 114.4G  0 disk 
|-sda1    8:1    0     8K  0 part 
|-sda2    8:2    0   512K  0 part 
|-sda3    8:3    0   512M  0 part 
|-sda4    8:4    0    30M  0 part 
`-sda5    8:5    0 113.8G  0 part /
sdb       8:16   0    20M  0 disk 
|-sdb1    8:17   0   3.5M  0 part 
`-sdb2    8:18   0   512K  0 part 
sdc       8:32   0    20M  0 disk 
|-sdc1    8:33   0   3.5M  0 part 
`-sdc2    8:34   0   512K  0 part 
sdd       8:48   0    32M  0 disk 
|-sdd1    8:49   0   104K  0 part 
|-sdd2    8:50   0   128K  0 part 
|-sdd3    8:51   0     1M  0 part 
`-sdd4    8:52   0     1M  0 part 
sde       8:64   0   2.5G  0 disk 
|-sde1    8:65   0   512K  0 part 
|-sde2    8:66   0     4K  0 part 
|-sde3    8:67   0    64M  0 part 
|-sde4    8:68   0    64M  0 part 
|-sde5    8:69   0     2M  0 part 
|-sde6    8:70   0     2M  0 part 
|-sde7    8:71   0     5M  0 part 
|-sde8    8:72   0     5M  0 part 
|-sde9    8:73   0     4M  0 part 
|-sde10   8:74   0     8M  0 part 
|-sde11   8:75   0     4M  0 part 
|-sde12   8:76   0    32M  0 part 
|-sde13   8:77   0   128K  0 part 
|-sde14   8:78   0    80K  0 part 
|-sde15   8:79   0     2M  0 part 
|-sde16 259:0    0     2M  0 part 
|-sde17 259:1    0   128K  0 part 
|-sde18 259:2    0    32K  0 part 
|-sde19 259:3    0     1M  0 part 
|-sde20 259:4    0    30M  0 part 
|-sde21 259:5    0   256K  0 part 
|-sde22 259:6    0   512K  0 part 
|-sde23 259:7    0     4M  0 part 
|-sde24 259:8    0     8M  0 part 
|-sde25 259:9    0     4M  0 part 
|-sde26 259:10   0    32M  0 part 
|-sde27 259:11   0   128K  0 part 
|-sde28 259:12   0    80K  0 part 
|-sde29 259:13   0     2M  0 part 
|-sde30 259:14   0     2M  0 part 
|-sde31 259:15   0   128K  0 part 
|-sde32 259:16   0    32K  0 part 
|-sde33 259:17   0     1M  0 part 
|-sde34 259:18   0   256K  0 part 
|-sde35 259:19   0     4K  0 part 
|-sde36 259:20   0     1M  0 part 
|-sde37 259:21   0   256K  0 part 
|-sde38 259:22   0  32.6M  0 part 
|-sde39 259:23   0     4K  0 part 
|-sde40 259:24   0     4K  0 part 
|-sde41 259:25   0     1M  0 part 
|-sde42 259:26   0     8M  0 part 
|-sde43 259:27   0    40M  0 part 
|-sde44 259:28   0   512M  0 part 
|-sde45 259:29   0   512K  0 part 
|-sde46 259:30   0    28K  0 part 
|-sde47 259:31   0   512K  0 part 
|-sde48 259:32   0     1M  0 part 
`-sde49 259:33   0  32.6M  0 part 
sdf       8:80   0   200M  0 disk 
|-sdf1    8:81   0   104K  0 part 
|-sdf2    8:82   0     3M  0 part 
|-sdf3    8:83   0     3M  0 part 
|-sdf4    8:84   0     3M  0 part 
`-sdf5    8:85   0   128K  0 part 
sdg       8:96   0     1G  0 disk 
|-sdg1    8:97   0     8M  0 part /var/rubikpi_config
|-sdg2    8:98   0   200M  0 part /var/devcfg
`-sdg3    8:99   0    68M  0 part /var/rubikpi_dtso
sdh       8:112  0     1G  0 disk 
zram0   253:0    0   5.3G  0 disk [SWAP]
2

I guess the file provision_ufs_1_3.xml would have to be modified, right?

Is there any chance of bricking the UFS due to faulty provisioning?

If so can the EDL mode fix that since the code lives inside the maskROM?

<?xml version="1.0" ?> 
<data>
    <ufs bNumberLU="0" bBootEnable="1" bDescrAccessEn="0" bInitPowerMode="1" bHighPriorityLUN="0x5" bSecureRemovalType="0" bInitActiveICCLevel="0" wPeriodicRTCUpdate="0" bConfigDescrLock="0" bWriteBoosterBufferPreserveUserSpaceEn="1" bWriteBoosterBufferType="1" shared_wb_buffer_size_in_kb="4194304" />

    <ufs LUNum="0" bLUEnable="1" bBootLunID="0" size_in_kb="4096"     bDataReliability="0" bLUWriteProtect="0" bMemoryType="0" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 0 - User LUN - Rest of the device" />
    <ufs LUNum="1" bLUEnable="1" bBootLunID="1" size_in_kb="16416"     bDataReliability="0" bLUWriteProtect="1" bMemoryType="3" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 1 - Boot LUN A, 16MB" />
    <ufs LUNum="2" bLUEnable="1" bBootLunID="2" size_in_kb="16416"     bDataReliability="0" bLUWriteProtect="1" bMemoryType="3" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 2 - Boot LUN B, 16MB" />
    <ufs LUNum="3" bLUEnable="1" bBootLunID="0" size_in_kb="32768"    bDataReliability="0" bLUWriteProtect="1" bMemoryType="0" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 3 - OTP LUN, 32MB" />
    <ufs LUNum="4" bLUEnable="1" bBootLunID="0" size_in_kb="2621440"  bDataReliability="0" bLUWriteProtect="1" bMemoryType="0" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 4 - Protected Read-only LUN-6GB" />
    <ufs LUNum="5" bLUEnable="1" bBootLunID="0" size_in_kb="204800"    bDataReliability="0" bLUWriteProtect="0" bMemoryType="0" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 5 - Protected Read-write LUN, 32MB" />
    <ufs LUNum="6" bLUEnable="1" bBootLunID="0" size_in_kb="1048576"  bDataReliability="0" bLUWriteProtect="0" bMemoryType="0" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 6 - Internal Test LUN-1, 4GB" />
    <ufs LUNum="7" bLUEnable="1" bBootLunID="0" size_in_kb="1048576"  bDataReliability="0" bLUWriteProtect="0" bMemoryType="0" bLogicalBlockSize="0x0c" bProvisioningType="2" wContextCapabilities="0" wb_buffer_size_in_kb="0" desc="LU 7 - Internal Test LUN-2, 4GB" />
    
    <ufs LUNtoGrow="0" commit="1"/>

</data>
3

Could you point me in Yocto to the recipe that creates this file?

Have not found it in the build dir.

4

provision file is not in yocto recipe.
you can find provision in our flashable image release, or upstream’s release note:

And yes, updating provision is always risky. We just use the exact same provision file as upstream. So we don’t know what will happen if you update it.

5

Thanks for the link. I took the provision file from the Debian image, but it’s good to have upstream reference.

And yes, updating provision is always risky. We just use the exact same provision file as upstream. So we don’t know what will happen if you update it.

Could you open ticket with Qualcomm on the topic?

It’s just about splitting the one partition, not changing the whole layout.

Know on some Snapdragon phones it’s possible to split it and in bootloader (like Towboot) select the system to boot.

Also it would help as then the rootfs could be read-only and another partition would host the overlay.

And yes, updating provision is always risky.

Is this addressable to some extent by the EDL? I understand it’s the UFS that stores the logical volume information so it will depend on the storage vendor how the re-provisioning ends.

6

You can ask QCOM on their forum:

I think it’s common question to Qualcomm Linux, whatever for RB3Gen2 or RubikPi.

7

Thanks linking the question from QCOM forum.

https://mysupport.qualcomm.com/supportforums/s/question/0D5dK000007gClASAU/split-ufs-partition