LS1028A partitioning scheme

[pb3]

Hello, is it possible to use GPT partitioning scheme on LS1028A or only MBR is available?

[June_Lu]

Please kindly follow the https://docs.nxp.com/bundle/LLDPUG_L6.1.36_2.1.0/page/topics/deploy_layerscape_images_with_flex-inst...

Deploying the LDP images using flex-installer.

https://github.com/nxp-imx/meta-nxp-desktop/blob/rel_lf_6.1.36_2.1.0_ldp/scripts/flex-installer_1.14...

You could refer this, and in the flex-installer, it's only support 1 GPT which will be considered as safe.

Thanks

[pb3]

Will all due respect but this is not the answer. I clearly asked about the GPT partitioning scheme. If it's possible please show me the example on how to configure 6 (e.g. 2 bootfs copies, 2 rootfs copies, one data partition, and one let's say vendorfs) partitions on LS1028A, because in my opinion it's not possible, as the SoC only supports MBR due to the requirement of PBL location.

[michelle]

Hi Patryk,

I see where you are going with this and you are correct, for an SD card boot, the block for the RCW/PBL are dedicated via the boot rom.  Our standard release will have a pointer to the initial code that runs out of on chip RAM in that and we always package them as a "BL2" these days.  That said, you can put the BL2 anywhere, but the SoC is still going to look at device pins and decide what media has the RCW/PBL combo. 

Also the Boot up is only going to run core 0 first, other cores can be run in parallel but it would run the same code pointed at by your RCW/PBL.  To accomplish different load sequences you would need to add code to get the Core ID and execute different paths accordingly.  For SD/eMMC boot there isnt a way to avoid using the fixed block short of messing with the SDCard's FTL firmware which I'd not advise doing. 

If your application require a pure GPT style file system on an SDcard, you might consider booting the LS1028a from an XSPI NOR device or even a small I2C based EEPROM which could contain the RCW/PBL and subsequently jump into some running code.  

Hope this helps!

Michelle

[June_Lu]

Check the GPT related command with LS1028A LSDK2108, it support GPT, see below.

=> part list mmc 1

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

Part    Start LBA       End LBA         Name

        Attributes

        Type GUID

        Partition GUID

  1     0x00000800      0x002007ff      "primary"

        attrs:  0x0000000000000000

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

        guid:   43c8970e-9907-48ef-8eef-c585d2c76ef3

=> gpt verify mmc 1

No partition list provided - only basic check

Verify GPT: success!

=> help gpt

gpt - GUID Partition Table

Usage:

gpt <command> <interface> <dev> <partitions_list>

 - GUID partition table restoration and validity check

 Restore or verify GPT information on a device connected

 to interface

 Example usage:

 gpt write mmc 0 $partitions

    - write the GPT to device

 gpt verify mmc 0 $partitions

    - verify the GPT on device against $partitions

 gpt setenv mmc 0 $name

    - setup environment variables for partition $name:

      gpt_partition_addr, gpt_partition_size,

      gpt_partition_name, gpt_partition_entry

 gpt enumerate mmc 0

    - store list of partitions to gpt_partition_list environment variable

 read <interface> <dev>

    - read GPT into a data structure for manipulation

 gpt guid <interface> <dev>

    - print disk GUID

 gpt guid <interface> <dev> <varname>

    - set environment variable to disk GUID

 Example usage:

 gpt guid mmc 0

 gpt guid mmc 0 varname

[pb3]

Hi,
Thank you for confirming that GPT is supported on LS1028A with LSDK2108.
However, I'm trying to understand how this works from a technical standpoint, and I'm confused about the memory layout conflict.
According to NXP documentation (https://docs.nxp.com/bundle/LLDPUG_L6.1.36_2.1.0/page/topics/lsdk_memory_layout_and_userland.html#GU...), the PBL (BL2) must be written starting at block 8 (4KB offset) on SD card - this is hardcoded in the processor's boot ROM and cannot be changed.
At the same time, a standard GPT layout looks like this:
- LBA 0: Protective MBR
- LBA 1: GPT Header
- LBA 2-33: GPT Partition Entry Array (128 entries × 128 bytes = 16KB)
- LBA 34+: First usable sector for partitions

This means the PBL/firmware area (starting at LBA directly overlaps with the GPT Partition Entry Array (LBA 2-33).
My questions:

How does LSDK resolve this conflict? Does NXP use a reduced number of GPT entries (e.g., only 4 entries ending at LBA 5) to avoid the overlap?
Is the GPT on your example image created with some special tool or modified partition table layout?
Could you share how the GPT header is configured (specifically the NumberOfPartitionEntries and PartitionEntryLBA fields)?