Cube Programmer can't handle numbers larger than 32 bits in the offset field

[Hammy]

There seems to be an issue with CubeProgrammer and parsing hex strings that are longer than 8 characters. For example, an offset of 0x05984400 will parse correctly but 0x105984400 will not. It will incorrectly parse as 0x05984400. I am trying to reference an offset that is past the 4GB mark so CubeProgrammer is truncating my offset value. Is it supposed to do that? What is the best way to reference partitions past the 2^32 bits mark? Are other people able to get it to work or am I just doing something weird?

Edit: Also the images in Kirkstone are defaut to a rootfs size of 4GiB.

[KnarfB]

Where would such huge offsets occur? You are leaving the 32-bit world....

hth

KnarfB

[gbm]

You are just doing something weird. Why would you use offset above 32 bits in a 32-bit MCU?

[Hammy]

I want to partition a 8GB eMMC and 8GB SDMMC. These are the numbers I am getting from my default build of Kirkstone on st-image-core. I need the bit in the 32nd place to be available (0-31 works fine) because I am doing a dual rootfs setup and am splitting the rootfs in to 3GB parts each. So I need to place a partition at around 0x165A0BC00 which CubeProgrammer is going to truncate to 0x65A0BC00 so it is going to the wrong place. If you guys do a test and put in a number for the flash layout offset on 2.12 CubeProgrammer that is greater than 0xFFFFFFFF will it get truncated as well?

Also I forgot to mention, I am using a stm32mp157c

[Bernard PUEL]

Could you please clarify your point ?

1/ If I look to the latest delivery last partition has offset > to 32bits long:

P   0x11   vendorfs   FileSystem   mmc0   0x04984400   st-image-vendorfs-openstlinux-weston-stm32mp1.ext4

P   0x12   rootfs   FileSystem   mmc0   0x05984400   st-image-weston-openstlinux-weston-stm32mp1.ext4

P   0x13   userfs   FileSystem   mmc0   0x105984400   st-image-userfs-openstlinux-weston-stm32mp1.ext4

2/ After flashing with cubeprogrammer on 16GB sd:

STM32MP> mmc list

STM32 SD/MMC: 0 (SD)

STM32 SD/MMC: 1

STM32MP> mmc info

Device: STM32 SD/MMC

Manufacturer ID: 3

OEM: 5344

Name: SS16G 

Bus Speed: 50000000

Mode: SD High Speed (50MHz)

Rd Block Len: 512

SD version 3.0

High Capacity: Yes

Capacity: 14.8 GiB

Bus Width: 4-bit

Erase Group Size: 512 Bytes

STM32MP> mmc part

Partition Map for MMC device 0 --  Partition Type: EFI

Part   Start LBA      End LBA        Name

       Attributes

       Type GUID

       Partition GUID

 1    0x00000022     0x00000221     "fsbl1"

       attrs: 0x0000000000000000

       type:  8da63339-0007-60c0-c436-083ac8230908

       guid:  a7c8cf2d-8a1b-434f-8bf0-8bb4064dc499

 2    0x00000222     0x00000421     "fsbl2"

       attrs: 0x0000000000000000

       type:  8da63339-0007-60c0-c436-083ac8230908

       guid:  81d4d4b5-4387-48c7-bb17-213150b41969

 3    0x00000422     0x00000621     "metadata1"

       attrs: 0x0000000000000000

       type:  8da63339-0007-60c0-c436-083ac8230908

       guid:  fc2c1b03-7e68-47b6-b23b-0838ade5b2d0

 4    0x00000622     0x00000821     "metadata2"

       attrs: 0x0000000000000000

       type:  8da63339-0007-60c0-c436-083ac8230908

       guid:  0f30b9af-b30e-4abe-ad30-fe10d880940b

 5    0x00000822     0x00002821     "fip-a"

       attrs: 0x0000000000000000

       type:  19d5df83-11b0-457b-be2c-7559c13142a5

       guid:  4fd84c93-54ef-463f-a7ef-ae25ff887087

 6    0x00002822     0x00004821     "fip-b"

       attrs: 0x0000000000000000

       type:  19d5df83-11b0-457b-be2c-7559c13142a5

       guid:  09c54952-d5bf-45af-acee-335303766fb3

 7    0x00004822     0x00004c21     "u-boot-env"

       attrs: 0x0000000000000000

       type:  8da63339-0007-60c0-c436-083ac8230908

       guid:  d5870724-cbf8-444b-8daf-f35d4073592b

 8    0x00004c22     0x00024c21     "bootfs"

       attrs: 0x0000000000000004

       type:  0fc63daf-8483-4772-8e79-3d69d8477de4

       type:  linux

       guid:  39d034b2-2060-4f2e-a521-2b8b6a33e10c

 9    0x00024c22     0x0002cc21     "vendorfs"

       attrs: 0x0000000000000000

       type:  0fc63daf-8483-4772-8e79-3d69d8477de4

       type:  linux

       guid:  0d0c3e3b-12fb-45ad-a1f2-d1560b2b297a

10    0x0002cc22     0x0082cc21     "rootfs"

       attrs: 0x0000000000000000

       type:  0fc63daf-8483-4772-8e79-3d69d8477de4

       type:  linux

       guid:  e91c4e10-16e6-4c0e-bd0e-77becf4a3582

11    0x0082cc22     0x01dacbdc     "userfs"

       attrs: 0x0000000000000000

       type:  0fc63daf-8483-4772-8e79-3d69d8477de4

       type:  linux

       guid:  e1588fa8-287c-4831-9601-d1f1438d9eec

3/ sd card has 0x200 blocs, then 0x0082cc22 x 0x200 = 0x105984400 offset flashed

4/ Do I miss anything ? Or the issue comes from Yocto tsv generation ?

[Hammy]

Hi @Bernard PUEL​ ,

Thanks for looking at this! Much appreciated. Yes, the Yocto TSV is correct. The file generated by my Yocto is correct as well. My issue is that when I load that file into cube programmer that it doesn't read in the offset values correctly. I attached a picture for reference. Notice that the last value for the userfs and what cube programmer reads is different.

[Bernard PUEL]

Ok I see thanks !

[Bernard PUEL]

We could reproduce the issue and the flashing is ok (with the right offset from the tsv file).

So the issue is only a UI effect and an internal ticket was submitted to solve it.

[Hammy]

Hi @Bernard PUEL​ ,

Awesome! Glad to hear that. What did your TSV look like? When I did this, I had an error thrown that there were two partitions with the same location. Were you able to validate the partition layout was correct after flashing? I think an error would only be thrown if they happen to line up or you might not notice it. What is the output of lsblk vs the TSV file?

[Bernard PUEL]

Hello Hammy,

Sorry we only tested with latest releases (V2.12 Cube Prog) on Windows:

So you can see the UI has wrong display but the userfs partition is well flashed on the board.