2023-01-24 03:38 PM
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.
2023-01-24 09:41 PM
Where would such huge offsets occur? You are leaving the 32-bit world....
hth
KnarfB
2023-01-24 11:03 PM
You are just doing something weird. Why would you use offset above 32 bits in a 32-bit MCU?
2023-01-25 08:51 AM
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
2023-01-30 02:41 AM
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 ?
2023-01-30 09:55 AM
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.
2023-01-30 11:40 PM
Ok I see thanks !
2023-02-01 07:33 AM
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.
2023-02-01 08:57 AM
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?
2023-02-01 11:52 PM
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.