PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT #545

FilkerZero · 2025-06-07T17:04:56Z

FilkerZero
Jun 7, 2025

This may have been answered many times before, but I didn't locate the discussion.

The pre-built Yocto SD card image (core-image-minimal-dev-mpfs-disco-kit.rootfs-20250328185614.wic) for the MPFS-DISCO-KIT (March, 2025) has a GPT partition table. I insert a freshly loaded uSD card programmed with the .wic file and connect the board to my PC via a USB 3.1 C socket (w/PD, if it matters) and a high quality USBC-USBC cable. I have 3 teraterm serial console windows, one connected to each of the MPFS-DISCO-KIT virtual com ports (though until I plug the USB-C cable into the DISCO's socket, they're not connected, they revive when the ports reappear.).

The HSS running on the Monitor core (E51) in the MSS recognizes the GPT partition table, loads the U-Boot image from the SD card into RAM and starts the E54 (at least one of the cores). This is exactly what is expected.
U-Boot starts, and all looks normal until it looks for the partition table on mmc0; it can't find a partition table, so goes on to try to boot from the network (I don't have that set up).

U-Boot 2023.07.02-linux4microchip+fpga-2025.03 (Mar 25 2025 - 10:59:43 +0000)

CPU:   rv64imafdc
Model: Microchip PolarFire-SoC Discovery Kit
DRAM:  1 GiB (effective 1.8 GiB)
Core:  50 devices, 12 uclasses, devicetree: separate
MMC:   mmc@20008000: 0
Loading Environment from FAT... ** No partition table - mmc 0 **
In:    serial@20106000
Out:   serial@20106000
Err:   serial@20106000
Net:   eth0: ethernet@20110000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
** No partition table - mmc 0 **
Couldn't find partition mmc 0:1

I stop the attempt to boot from the network, and at the command prompt, type the command "part types":

RISC-V # help part
part - disk partition related commands

Usage:
part uuid <interface> <dev>:<part>
    - print partition UUID
part uuid <interface> <dev>:<part> <varname>
    - set environment variable to partition UUID
part list <interface> <dev>
    - print a device's partition table
part list <interface> <dev> [flags] <varname>
    - set environment variable to the list of partitions
      flags can be -bootable (list only bootable partitions)
part start <interface> <dev> <part> <varname>
    - set environment variable to the start of the partition (in blocks)
      part can be either partition number or partition name
part size <interface> <dev> <part> <varname>
    - set environment variable to the size of the partition (in blocks)
      part can be either partition number or partition name
part number <interface> <dev> <part> <varname>
    - set environment variable to the partition number using the partition name
      part must be specified as partition name
part type <interface> <dev>:<part> <varname>
    - set environment variable to partition type
part types
    - list supported partition table types
RISC-V # part types
Supported partition tables: EFI, DOS, ISO
RISC-V #

I don't recognize any of those as being GPT, though maybe "EFI" is an alias for it.

It appears that the u-boot build in the pre-built SD card image for the MPFS-DISCO-KIT does not recognize the GPT partition table on the 32GB Samsung EVO U1 SD card I'm currently using. I tried it with a 16GB SanDisk Class 10 card as well and had the same results.

I saw one post that showed a similar problem that was solved by using a USB port on their PC that provided higher current, but I doubt that's the problem here. I often charge my phone using the same USB 3.1 C port on my PC, so I know it is capable of providing pretty high current. I do know that the cable can affect the current limiting on the port, so I've tried multiple C-to-C cables, including the one I use on my high-speed charger (60w), though I know that the DISCO board is probably only using the 5VDC.

Normally, if a U-Boot build supports GPT partitions, it also supports the "gpt" command (see https://docs.u-boot.org/en/v2024.10/usage/cmd/gpt.html), but the u-boot on the SD card does not recognize gpt as a command.

So to the specific question: Does the U-Boot build that is included in the pre-built Yocto image for the MPFS-DISCO-KIT reference design have GPT partition table support enabled? Did I miss something in the documentation?

Answered by FilkerZero

Jun 8, 2025

Dave:

Update: I went out and purchased a new 64GB microSD card (SanDisk "ImageMate microSDXC UHS-1), used the Linux dd command to copy the .wic file to the drive, went into fdisk to fix the problems that dd copying alone doesn't clear up (GPT PMBR size mismatch, backup GPT table not on the end of the device) by writing the "label" back out to the card, stuck it in the MPFS-DISCO-KIT board's microSD slot, and plugged it in. I now have a Linux login prompt.

I don't know if using dd was the solution, or whether it's the card itself, but I now have the ability to boot Linux in the MSS on the PolarFire SoC.

Thank you very much for all your support today.

Thanks again,
Daniel

View full answer

rockoguido · 2025-06-07T19:00:31Z

rockoguido
Jun 7, 2025

Hi Daniel, I just tried this same scenario you describe below and I am able to boot the pre-built Yocto image without an issue on the Disco Kit. One item you did not mention which is important is the version of the image deployed to the fabric. Since you are using Yocto 2025.03 you need to have that same version of the Disco Kit reference design deployed If you go to https://github.com/polarfire-soc/polarfire-soc-video-kit-reference-design/releases [https://opengraph.githubassets.com/d1abe7efe4e096c8340e71384dbe25167e8ea16c5ccfc855e5f8ca2080bcfb29/polarfire-soc/polarfire-soc-video-kit-reference-design]<https://github.com/polarfire-soc/polarfire-soc-video-kit-reference-design/releases> Releases: polarfire-soc/polarfire-soc-video-kit-reference-design<https://github.com/polarfire-soc/polarfire-soc-video-kit-reference-design/releases> SEV Kit Reference Design v2022.09. This design supports H.264 video streaming over ethernet using Microchip’s PolarFire SoC SEV Kit. Tested on PolarFire SoC SEV Kit with: github.com You'll find 2025.03 pre-built programming files you need to deploy, best bet is to use FP Express (a subset of Libero) to deploy. I'm not sure if you are familiar with Libero or FP Express. Regards, Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:9e242aca-c0d4-46cf-820e-ee9e84771a6d]

…

________________________________ From: Daniel A Glasser ***@***.***> Sent: Saturday, June 7, 2025 10:05 AM To: polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Subscribed ***@***.***> Subject: [PolarFire-SoC] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe This may have been answered many times before, but I didn't locate the discussion. The pre-built Yocto SD card image (core-image-minimal-dev-mpfs-disco-kit.rootfs-20250328185614.wic) for the MPFS-DISCO-KIT (March, 2025) has a GPT partition table. I insert a freshly loaded uSD card programmed with the .wic file and connect the board to my PC via a USB 3.1 C socket (w/PD, if it matters) and a high quality USBC-USBC cable. I have 3 teraterm serial console windows, one connected to each of the MPFS-DISCO-KIT virtual com ports (though until I plug the USB-C cable into the DISCO's socket, they're not connected, they revive when the ports reappear.). 1. The HSS running on the Monitor core (E51) in the MSS recognizes the GPT partition table, loads the U-Boot image from the SD card into RAM and starts the E54 (at least one of the cores). This is exactly what is expected. 2. U-Boot starts, and all looks normal until it looks for the partition table on mmc0; it can't find a partition table, so goes on to try to boot from the network (I don't have that set up). U-Boot 2023.07.02-linux4microchip+fpga-2025.03 (Mar 25 2025 - 10:59:43 +0000) CPU: rv64imafdc Model: Microchip PolarFire-SoC Discovery Kit DRAM: 1 GiB (effective 1.8 GiB) Core: 50 devices, 12 uclasses, devicetree: separate MMC: ***@***.***: 0 Loading Environment from FAT... ** No partition table - mmc 0 ** In: ***@***.*** Out: ***@***.*** Err: ***@***.*** Net: eth0: ***@***.*** Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** No partition table - mmc 0 ** Couldn't find partition mmc 0:1 1. I stop the attempt to boot from the network, and at the command prompt, type the command "part types": RISC-V # help part part - disk partition related commands Usage: part uuid <interface> <dev>:<part> - print partition UUID part uuid <interface> <dev>:<part> <varname> - set environment variable to partition UUID part list <interface> <dev> - print a device's partition table part list <interface> <dev> [flags] <varname> - set environment variable to the list of partitions flags can be -bootable (list only bootable partitions) part start <interface> <dev> <part> <varname> - set environment variable to the start of the partition (in blocks) part can be either partition number or partition name part size <interface> <dev> <part> <varname> - set environment variable to the size of the partition (in blocks) part can be either partition number or partition name part number <interface> <dev> <part> <varname> - set environment variable to the partition number using the partition name part must be specified as partition name part type <interface> <dev>:<part> <varname> - set environment variable to partition type part types - list supported partition table types RISC-V # part types Supported partition tables: EFI, DOS, ISO RISC-V # I don't recognize any of those as being GPT, though maybe "EFI" is an alias for it. It appears that the u-boot build in the pre-built SD card image for the MPFS-DISCO-KIT does not recognize the GPT partition table on the 32GB Samsung EVO U1 SD card I'm currently using. I tried it with a 16GB SanDisk Class 10 card as well and had the same results. I saw one post that showed a similar problem that was solved by using a USB port on their PC that provided higher current, but I doubt that's the problem here. I often charge my phone using the same USB 3.1 C port on my PC, so I know it is capable of providing pretty high current. I do know that the cable can affect the current limiting on the port, so I've tried multiple C-to-C cables, including the one I use on my high-speed charger (60w), though I know that the DISCO board is probably only using the 5VDC. Normally, if a U-Boot build supports GPT partitions, it also supports the "gpt" command (see https://docs.u-boot.org/en/v2024.10/usage/cmd/gpt.html), but the u-boot on the SD card does not recognize gpt as a command. So to the specific question: Does the U-Boot build that is included in the pre-built Yocto image for the MPFS-DISCO-KIT reference design have GPT partition table support enabled? Did I miss something in the documentation? — Reply to this email directly, view it on GitHub<#545>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJPF63NEQI745UWXTKLMLD3CMLVBAVCNFSM6AAAAAB62C33TKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGQZDQMJTHA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

0 replies

rockoguido · 2025-06-07T19:19:49Z

rockoguido
Jun 7, 2025

Apologies, the URL below is pointing to the wrong kit. You want to go to https://github.com/polarfire-soc/polarfire-soc-discovery-kit-reference-design/releases [https://opengraph.githubassets.com/283c8ea2290078c31022fc4613ef2bb42de0be96611768d461d39d191ff15238/polarfire-soc/polarfire-soc-discovery-kit-reference-design]<https://github.com/polarfire-soc/polarfire-soc-discovery-kit-reference-design/releases> Releases · polarfire-soc/polarfire-soc-discovery-kit-reference-design - GitHub<https://github.com/polarfire-soc/polarfire-soc-discovery-kit-reference-design/releases> Discovery Kit Reference Design Release 2024.04. This is the initial release of the PolarFire SoC Discovery Kit reference design. This design supports multiple configurations, consult the Argument based design generation of the repository readme for full details.. Getting started github.com Regards, Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:b3207ec0-45f7-45ff-b507-1ff2664409ff]

…

________________________________ From: Dave Campanella - C68141 ***@***.***> Sent: Saturday, June 7, 2025 12:00 PM To: polarfire-soc/polarfire-soc-documentation ***@***.***>; polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Subscribed ***@***.***> Subject: Re: [PolarFire-SoC] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) Hi Daniel, I just tried this same scenario you describe below and I am able to boot the pre-built Yocto image without an issue on the Disco Kit. One item you did not mention which is important is the version of the image deployed to the fabric. Since you are using Yocto 2025.03 you need to have that same version of the Disco Kit reference design deployed If you go to https://github.com/polarfire-soc/polarfire-soc-video-kit-reference-design/releases [https://opengraph.githubassets.com/d1abe7efe4e096c8340e71384dbe25167e8ea16c5ccfc855e5f8ca2080bcfb29/polarfire-soc/polarfire-soc-video-kit-reference-design]<https://github.com/polarfire-soc/polarfire-soc-video-kit-reference-design/releases> Releases: polarfire-soc/polarfire-soc-video-kit-reference-design<https://github.com/polarfire-soc/polarfire-soc-video-kit-reference-design/releases> SEV Kit Reference Design v2022.09. This design supports H.264 video streaming over ethernet using Microchip’s PolarFire SoC SEV Kit. Tested on PolarFire SoC SEV Kit with: github.com You'll find 2025.03 pre-built programming files you need to deploy, best bet is to use FP Express (a subset of Libero) to deploy. I'm not sure if you are familiar with Libero or FP Express. Regards, Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:9e242aca-c0d4-46cf-820e-ee9e84771a6d]

________________________________ From: Daniel A Glasser ***@***.***> Sent: Saturday, June 7, 2025 10:05 AM To: polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Subscribed ***@***.***> Subject: [PolarFire-SoC] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe This may have been answered many times before, but I didn't locate the discussion. The pre-built Yocto SD card image (core-image-minimal-dev-mpfs-disco-kit.rootfs-20250328185614.wic) for the MPFS-DISCO-KIT (March, 2025) has a GPT partition table. I insert a freshly loaded uSD card programmed with the .wic file and connect the board to my PC via a USB 3.1 C socket (w/PD, if it matters) and a high quality USBC-USBC cable. I have 3 teraterm serial console windows, one connected to each of the MPFS-DISCO-KIT virtual com ports (though until I plug the USB-C cable into the DISCO's socket, they're not connected, they revive when the ports reappear.). 1. The HSS running on the Monitor core (E51) in the MSS recognizes the GPT partition table, loads the U-Boot image from the SD card into RAM and starts the E54 (at least one of the cores). This is exactly what is expected. 2. U-Boot starts, and all looks normal until it looks for the partition table on mmc0; it can't find a partition table, so goes on to try to boot from the network (I don't have that set up). U-Boot 2023.07.02-linux4microchip+fpga-2025.03 (Mar 25 2025 - 10:59:43 +0000) CPU: rv64imafdc Model: Microchip PolarFire-SoC Discovery Kit DRAM: 1 GiB (effective 1.8 GiB) Core: 50 devices, 12 uclasses, devicetree: separate MMC: ***@***.***: 0 Loading Environment from FAT... ** No partition table - mmc 0 ** In: ***@***.*** Out: ***@***.*** Err: ***@***.*** Net: eth0: ***@***.*** Hit any key to stop autoboot: 0 switch to partitions #0, OK mmc0 is current device ** No partition table - mmc 0 ** Couldn't find partition mmc 0:1 1. I stop the attempt to boot from the network, and at the command prompt, type the command "part types": RISC-V # help part part - disk partition related commands Usage: part uuid <interface> <dev>:<part> - print partition UUID part uuid <interface> <dev>:<part> <varname> - set environment variable to partition UUID part list <interface> <dev> - print a device's partition table part list <interface> <dev> [flags] <varname> - set environment variable to the list of partitions flags can be -bootable (list only bootable partitions) part start <interface> <dev> <part> <varname> - set environment variable to the start of the partition (in blocks) part can be either partition number or partition name part size <interface> <dev> <part> <varname> - set environment variable to the size of the partition (in blocks) part can be either partition number or partition name part number <interface> <dev> <part> <varname> - set environment variable to the partition number using the partition name part must be specified as partition name part type <interface> <dev>:<part> <varname> - set environment variable to partition type part types - list supported partition table types RISC-V # part types Supported partition tables: EFI, DOS, ISO RISC-V # I don't recognize any of those as being GPT, though maybe "EFI" is an alias for it. It appears that the u-boot build in the pre-built SD card image for the MPFS-DISCO-KIT does not recognize the GPT partition table on the 32GB Samsung EVO U1 SD card I'm currently using. I tried it with a 16GB SanDisk Class 10 card as well and had the same results. I saw one post that showed a similar problem that was solved by using a USB port on their PC that provided higher current, but I doubt that's the problem here. I often charge my phone using the same USB 3.1 C port on my PC, so I know it is capable of providing pretty high current. I do know that the cable can affect the current limiting on the port, so I've tried multiple C-to-C cables, including the one I use on my high-speed charger (60w), though I know that the DISCO board is probably only using the 5VDC. Normally, if a U-Boot build supports GPT partitions, it also supports the "gpt" command (see https://docs.u-boot.org/en/v2024.10/usage/cmd/gpt.html), but the u-boot on the SD card does not recognize gpt as a command. So to the specific question: Does the U-Boot build that is included in the pre-built Yocto image for the MPFS-DISCO-KIT reference design have GPT partition table support enabled? Did I miss something in the documentation? — Reply to this email directly, view it on GitHub<#545>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJPF63NEQI745UWXTKLMLD3CMLVBAVCNFSM6AAAAAB62C33TKVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGQZDQMJTHA>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

0 replies

FilkerZero · 2025-06-07T21:33:48Z

FilkerZero
Jun 7, 2025
Author

Dave:

Thanks for the quick response. I just re-downloaded MPFS_DISCOVERY.zip from https://github.com/polarfire-soc/polarfire-soc-discovery-kit-reference-design/releases, used FlashPro Express (on Windows) to load it onto the board and saw the same behavior as before. For good measure, I redownloaded the ".wic.gz" file from https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp/releases/download/v2025.03/core-image-minimal-dev-mpfs-disco-kit.rootfs-20250328185614.wic.gz, uncompressed it, and used USBImager 1.0.10 to reprogram the Samsung 32GB EVO Plus U1 TF card (still on Windows), ejected the card, put it back in the slot on the DISCO board, and plugged it back in.

The behavior I'm seeing is identical. The E51 UART console didn't capture much at that point, but the E54 UART console did. I reset the board to get the full output from both, and am attaching the logs to this post.

HSS-20250607.log
UBOOT-20250607.log

After having tried the SD card in the MPFS-DISCO-KIT (when I captured the attached logs), I moved the SD card to the SD card reader on my Linux PC (currently headless). This is what I see in dmesg:

[1726655.789799] sd 6:0:0:0: [sdc] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB)
[1726655.790681] sdc: detected capacity change from 0 to 62521344
[1726655.815604]  sdc: sdc1 sdc2 sdc3

I went into fdisk and printed the partition table:

$ sudo fdisk /dev/sdc

Welcome to fdisk (util-linux 2.39.3).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdc: 29.81 GiB, 32010928128 bytes, 62521344 sectors
Disk model: Flash Reader
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0

Device      Start     End Sectors   Size Type
/dev/sdc1    8192  139263  131072    64M Microsoft basic data
/dev/sdc2  139264  155647   16384     8M BIOS boot
/dev/sdc3  155648 1493429 1337782 653.2M Linux filesystem

Command (m for help):

It appears that the SD card is formatted and partitioned using a GPT partition table that Linux recognizes.

This is my second MPFS-DISCO-KIT; the first one was unable to read anything in the SD card slot, so I never got as far as U-Boot on that one. It was sent back on an RMA and I ordered the one I'm now trying to get to boot.

Perhaps you might be able to spot what I'm doing wrong here from the output in the logs. I am assuming some sort of user error.

Thanks,
Daniel

0 replies

rockoguido · 2025-06-07T21:55:13Z

rockoguido
Jun 7, 2025

Hi Daniel, Ok, so we have the correct image in the fabric, can you share the log when HSS first comes up, looking for the version nunber that is displayed right after the "Meatball" is displayed. This has to align with everything else also. I have included the version number below that you need to align with... [0.789503] PolarFire(R) SoC Hart Software Services (HSS) - version 0.99.44-v2025.03 If your HSS requires an upgrade you have a few options.. https://github.com/polarfire-soc/hart-software-services/ This will get you the entire distribution and you are building your own which requires a few steps or.. https://github.com/polarfire-soc/hart-software-services/releases [https://opengraph.githubassets.com/971c748fe13207e21cc85a4820329100975072ffd80a1049a8a710f706828765/polarfire-soc/hart-software-services]<https://github.com/polarfire-soc/hart-software-services/releases> Releases · polarfire-soc/hart-software-services - GitHub<https://github.com/polarfire-soc/hart-software-services/releases> Hart Software Services Release v2024.09 Changes since last release. HSS: healthmon: Ensure that health monitoring monitor arrays are board/design specific github.com This gets you a prebuilt image that can be deployed as part of your Libero Design (designated for eMMC) It's up to you which path is easier but first order of business is to sort out if an upgrade is needed. Personally I prefer to build my own HSS but that requires a few changes in 2 Makefiles. One at the root level and the other in envm-wrapper. Probably not that important but one more data point. I use balenaEtcher https://etcher.balena.io [https://uploads-ssl.webflow.com/636ab6ba0e1bd250e3aaedaf/65ef146b4576693f0c5d825b_OG%20image.png]<https://etcher.balena.io/> balenaEtcher - Flash OS images to SD cards & USB drives<https://etcher.balena.io/> A cross-platform tool to flash OS images onto SD cards and USB drives safely and easily. Free and open source for makers around the world. etcher.balena.io To deploy my images onto a SD card. Since I move between Windoze and Linux frequently USBImager became inconvenient . Regards, Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:03e2456b-8a8a-447e-b95f-f22ef793fa69]

…

________________________________ From: Daniel A Glasser ***@***.***> Sent: Saturday, June 7, 2025 2:34 PM To: polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Dave Campanella - C68141 ***@***.***>; Comment ***@***.***> Subject: Re: [polarfire-soc/polarfire-soc-documentation] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Dave: Thanks for the quick response. I just re-downloaded MPFS_DISCOVERY.zip from https://github.com/polarfire-soc/polarfire-soc-discovery-kit-reference-design/releases, used FlashPro Express (on Windows) to load it onto the board and saw the same behavior as before. For good measure, I redownloaded the ".wic.gz" file from https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp/releases/download/v2025.03/core-image-minimal-dev-mpfs-disco-kit.rootfs-20250328185614.wic.gz, uncompressed it, and used USBImager 1.0.10 to reprogram the Samsung 32GB EVO Plus U1 TF card (still on Windows), ejected the card, put it back in the slot on the DISCO board, and plugged it back in. The behavior I'm seeing is identical. The E51 UART console didn't capture much at that point, but the E54 UART console did. I reset the board to get the full output from both, and am attaching the logs to this post. HSS-20250607.log<https://github.com/user-attachments/files/20641085/HSS-20250607.log> UBOOT-20250607.log<https://github.com/user-attachments/files/20641094/UBOOT-20250607.log> After having tried the SD card in the MPFS-DISCO-KIT (when I captured the attached logs), I moved the SD card to the SD card reader on my Linux PC (currently headless). This is what I see in dmesg: [1726655.789799] sd 6:0:0:0: [sdc] 62521344 512-byte logical blocks: (32.0 GB/29.8 GiB) [1726655.790681] sdc: detected capacity change from 0 to 62521344 [1726655.815604] sdc: sdc1 sdc2 sdc3 I went into fdisk and printed the partition table: $ sudo fdisk /dev/sdc Welcome to fdisk (util-linux 2.39.3). Changes will remain in memory only, until you decide to write them. Be careful before using the write command. Command (m for help): p Disk /dev/sdc: 29.81 GiB, 32010928128 bytes, 62521344 sectors Disk model: Flash Reader Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 00000000-0000-0000-0000-00004D9B9EF0 Device Start End Sectors Size Type /dev/sdc1 8192 139263 131072 64M Microsoft basic data /dev/sdc2 139264 155647 16384 8M BIOS boot /dev/sdc3 155648 1493429 1337782 653.2M Linux filesystem Command (m for help): It appears that the SD card is formatted and partitioned using a GPT partition table that Linux recognizes. This is my second MPFS-DISCO-KIT; the first one was unable to read anything in the SD card slot, so I never got as far as U-Boot on that one. It was sent back on an RMA and I ordered the one I'm now trying to get to boot. Perhaps you might be able to spot what I'm doing wrong here from the output in the logs. I am assuming some sort of user error. Thanks, Daniel — Reply to this email directly, view it on GitHub<#545 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJPF6YLL4IKZMGZZLJWXVL3CNLFBAVCNFSM6AAAAAB62C33TKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMZZHE2DKMA>. You are receiving this because you commented.Message ID: ***@***.***>

1 reply

FilkerZero Jun 7, 2025
Author

Dave:

The file HSS-20250607.log, attached to my previous post, contains this part of the output:

MPFS HAL version 2.3.102 / DDR Driver version 0.4.024 / Mi-V IHC version 0.1.1 / BOARD=mpfs-disco-kit
(c) Copyright 2017-2025 Microchip FPGA Embedded Systems Solutions.

incorporating OpenSBI - version 1.2
(c) Copyright 2019-2022 Western Digital Corporation.

[0.824565] Build ID: b1a79621ba421fb74486a33d97fb93a155811a08
[0.832108] Built with the following tools:
 - riscv64-unknown-elf-gcc (xPack GNU RISC-V Embedded GCC (Microsemi SoftConsole build), 64-bit) 8.3.0
 - GNU ld () 2.35.1

[0.849963] Serial Number: 
d75c948bc5839a2e5ff85122c752949a00000000000000000000000000000000000000000000000000000000000000000000
[0.863903] Segment Configuration:
        Cached: SEG0_0: offset 0x0080000000, physical DDR 0x00000000
        Cached: SEG0_1: offset 0x1000000000, physical DDR 0x00000000
    Non-cached: SEG1_2: offset 0x00c0000000, physical DDR 0x00000000
    Non-cached: SEG1_3: offset 0x1400000000, physical DDR 0x00000000
Non-cached WCB: SEG1_4: offset 0x00d0000000, physical DDR 0x00000000
Non-cached WCB: SEG1_5: offset 0x1800000000, physical DDR 0x00000000
[0.908874] L2 Cache Configuration:
    L2-Scratchpad:  4 ways (512 KiB)
         L2-Cache:  8 ways (1024 KiB)
           L2-LIM:  4 ways (512 KiB)
[0.924819] DESIGNID: MPFS_DISCOVERY_KIT
[0.930261] DESIGNVER: 0000
[0.934462] BACKLEVEL: 0000
[0.938664] startup_service :: [init] -> [boot]
[0.944774] ipi_poll_service :: [Init] -> [Monitoring]
Press a key to enter CLI, ESC to skip
Timeout in 1 second
..
[4.215416] CLI boot interrupt timeout
[4.220381] loop 315583 took 606533343 ticks (max 606533343 ticks)
[4.228305] Initializing Boot Image ...
[4.233366] Trying to get boot image via MMC ...
[4.239286] Attempting to select SDCARD ... Passed
[4.258321] Preparing to copy from MMC to DDR ...
[4.264718] Validated GPT Header ...
[4.304472] Validated GPT Partition Entries ...
[4.310904] Boot Partition found at index 1
[4.316676] Attempting to read image header (1632 bytes) ...
[4.324957] Copying 746200 bytes to 0x103fc00000
[4.362420] MMC: Boot Image registered ...
[4.367836] Boot image set name: "PolarFire-SoC-HSS::U-Boot"

This is a truncated version of that log file.

The corresponding U-Boot output is also attached to that response.

Thanks,
Daniel

rockoguido · 2025-06-07T22:04:56Z

rockoguido
Jun 7, 2025

Hi. Just need to see a bit more of HSS, it's a section that precedes what you shared. just one or 2 lines above. that's what I am looking for Regards, Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:4527d251-930f-4373-ad3b-4c5a0c5da6f9]

…

________________________________ From: Daniel A Glasser ***@***.***> Sent: Saturday, June 7, 2025 3:00 PM To: polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Dave Campanella - C68141 ***@***.***>; Comment ***@***.***> Subject: Re: [polarfire-soc/polarfire-soc-documentation] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Dave: The file HSS-20250607.log, attached to my previous post, contains this part of the output: MPFS HAL version 2.3.102 / DDR Driver version 0.4.024 / Mi-V IHC version 0.1.1 / BOARD=mpfs-disco-kit (c) Copyright 2017-2025 Microchip FPGA Embedded Systems Solutions. incorporating OpenSBI - version 1.2 (c) Copyright 2019-2022 Western Digital Corporation. [0.824565] Build ID: b1a79621ba421fb74486a33d97fb93a155811a08 [0.832108] Built with the following tools: - riscv64-unknown-elf-gcc (xPack GNU RISC-V Embedded GCC (Microsemi SoftConsole build), 64-bit) 8.3.0 - GNU ld () 2.35.1 [0.849963] Serial Number: d75c948bc5839a2e5ff85122c752949a00000000000000000000000000000000000000000000000000000000000000000000 [0.863903] Segment Configuration: Cached: SEG0_0: offset 0x0080000000, physical DDR 0x00000000 Cached: SEG0_1: offset 0x1000000000, physical DDR 0x00000000 Non-cached: SEG1_2: offset 0x00c0000000, physical DDR 0x00000000 Non-cached: SEG1_3: offset 0x1400000000, physical DDR 0x00000000 Non-cached WCB: SEG1_4: offset 0x00d0000000, physical DDR 0x00000000 Non-cached WCB: SEG1_5: offset 0x1800000000, physical DDR 0x00000000 [0.908874] L2 Cache Configuration: L2-Scratchpad: 4 ways (512 KiB) L2-Cache: 8 ways (1024 KiB) L2-LIM: 4 ways (512 KiB) [0.924819] DESIGNID: MPFS_DISCOVERY_KIT [0.930261] DESIGNVER: 0000 [0.934462] BACKLEVEL: 0000 [0.938664] startup_service :: [init] -> [boot] [0.944774] ipi_poll_service :: [Init] -> [Monitoring] Press a key to enter CLI, ESC to skip Timeout in 1 second .. [4.215416] CLI boot interrupt timeout [4.220381] loop 315583 took 606533343 ticks (max 606533343 ticks) [4.228305] Initializing Boot Image ... [4.233366] Trying to get boot image via MMC ... [4.239286] Attempting to select SDCARD ... Passed [4.258321] Preparing to copy from MMC to DDR ... [4.264718] Validated GPT Header ... [4.304472] Validated GPT Partition Entries ... [4.310904] Boot Partition found at index 1 [4.316676] Attempting to read image header (1632 bytes) ... [4.324957] Copying 746200 bytes to 0x103fc00000 [4.362420] MMC: Boot Image registered ... [4.367836] Boot image set name: "PolarFire-SoC-HSS::U-Boot" This is a truncated version of that log file. The corresponding U-Boot output is also attached to that response. Thanks, Daniel — Reply to this email directly, view it on GitHub<#545 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJPF6234PKXMWTFVTJ7T433CNOI3AVCNFSM6AAAAAB62C33TKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMZZHE2TEMI>. You are receiving this because you commented.Message ID: ***@***.***>

1 reply

FilkerZero Jun 7, 2025
Author

Dave:

I'm attaching the output captured from reset to when U-Boot started to try to do BOOTP in the other window. The first 4 lines in the file are from before I pressed the reset, and the blank section is the meatball, which doesn't show up in a text capture.

[877.648814] loop 115000000 took 4504 ticks (max 606529781 ticks)
[896.718566] loop 117500000 took 4520 ticks (max 606529781 ticks)
[915.793508] loop 120000000 took 4504 ticks (max 606529781 ticks)
[934.859606] loop 122500000 took 4548 ticks (max 606529781 ticks)

HSS: decompressing from eNVM to L2 Scratch ... Passed
[0.42579] wdog_service monitoring [u54_1] [u54_2] [u54_3] [u54_4]
[0.50218] beu_service :: [init] -> [monitoring]
[0.56424] Initializing Mi-V IHC
[0.60816] u54 State Change:  [Idle] [Idle] [Idle] [Idle]
[0.68932] loop 1 took 6363767 ticks (max 6363767 ticks)
[0.75902] Initializing IPI Queues (3304 bytes @ a027bf0)...

             
              
                             
                              
                                                                          
                                                                           
                                                                           
                                                                           
                                                                           
                                                                         
                                                                      
                 
                 
                
               
              
[0.752959] loop 3 took 401981778 ticks (max 401981778 ticks)
[0.760407] Initializing PMPs
[0.764512] PolarFire(R) SoC Hart Software Services (HSS) - version 0.99.44-v2025.03
MPFS HAL version 2.3.102 / DDR Driver version 0.4.024 / Mi-V IHC version 0.1.1 / BOARD=mpfs-disco-kit
(c) Copyright 2017-2025 Microchip FPGA Embedded Systems Solutions.

incorporating OpenSBI - version 1.2
(c) Copyright 2019-2022 Western Digital Corporation.

[0.799553] Build ID: b1a79621ba421fb74486a33d97fb93a155811a08
[0.807096] Built with the following tools:
 - riscv64-unknown-elf-gcc (xPack GNU RISC-V Embedded GCC (Microsemi SoftConsole build), 64-bit) 8.3.0
 - GNU ld () 2.35.1

[0.824951] Serial Number: 
d75c948bc5839a2e5ff85122c752949a00000000000000000000000000000000000000000000000000000000000000000000
[0.838891] Segment Configuration:
        Cached: SEG0_0: offset 0x0080000000, physical DDR 0x00000000
        Cached: SEG0_1: offset 0x1000000000, physical DDR 0x00000000
    Non-cached: SEG1_2: offset 0x00c0000000, physical DDR 0x00000000
    Non-cached: SEG1_3: offset 0x1400000000, physical DDR 0x00000000
Non-cached WCB: SEG1_4: offset 0x00d0000000, physical DDR 0x00000000
Non-cached WCB: SEG1_5: offset 0x1800000000, physical DDR 0x00000000
[0.883862] L2 Cache Configuration:
    L2-Scratchpad:  4 ways (512 KiB)
         L2-Cache:  8 ways (1024 KiB)
           L2-LIM:  4 ways (512 KiB)
[0.899807] DESIGNID: MPFS_DISCOVERY_KIT
[0.907611] DESIGNVER: 0000
[0.920448] BACKLEVEL: 0000
[0.933286] startup_service :: [init] -> [boot]
[0.943103] ipi_poll_service :: [Init] -> [Monitoring]
Press a key to enter CLI, ESC to skip
Timeout in 1 second
..

Hope this contains what you're looking for.

HSS-2025067-2.log

rockoguido · 2025-06-07T22:16:08Z

rockoguido
Jun 7, 2025

Hi Daniel, Let's try this. remove the SD card and just reboot the board and share what you see. Just want to verify that version of HSS that you have, this is important of the process Thx! Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:332979f1-50e6-4786-ad51-f8eeb185a41f]

…

________________________________ From: Daniel A Glasser ***@***.***> Sent: Saturday, June 7, 2025 3:14 PM To: polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Dave Campanella - C68141 ***@***.***>; Comment ***@***.***> Subject: Re: [polarfire-soc/polarfire-soc-documentation] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Dave: I'm attaching the output captured from reset to when U-Boot started to try to do BOOTP in the other window. The first 4 lines in the file are from before I pressed the reset, and the blank section is the meatball, which doesn't show up in a text capture. [877.648814] loop 115000000 took 4504 ticks (max 606529781 ticks) [896.718566] loop 117500000 took 4520 ticks (max 606529781 ticks) [915.793508] loop 120000000 took 4504 ticks (max 606529781 ticks) [934.859606] loop 122500000 took 4548 ticks (max 606529781 ticks) HSS: decompressing from eNVM to L2 Scratch ... Passed [0.42579] wdog_service monitoring [u54_1] [u54_2] [u54_3] [u54_4] [0.50218] beu_service :: [init] -> [monitoring] [0.56424] Initializing Mi-V IHC [0.60816] u54 State Change: [Idle] [Idle] [Idle] [Idle] [0.68932] loop 1 took 6363767 ticks (max 6363767 ticks) [0.75902] Initializing IPI Queues (3304 bytes @ a027bf0)... [0.752959] loop 3 took 401981778 ticks (max 401981778 ticks) [0.760407] Initializing PMPs [0.764512] PolarFire(R) SoC Hart Software Services (HSS) - version 0.99.44-v2025.03 MPFS HAL version 2.3.102 / DDR Driver version 0.4.024 / Mi-V IHC version 0.1.1 / BOARD=mpfs-disco-kit (c) Copyright 2017-2025 Microchip FPGA Embedded Systems Solutions. incorporating OpenSBI - version 1.2 (c) Copyright 2019-2022 Western Digital Corporation. [0.799553] Build ID: b1a79621ba421fb74486a33d97fb93a155811a08 [0.807096] Built with the following tools: - riscv64-unknown-elf-gcc (xPack GNU RISC-V Embedded GCC (Microsemi SoftConsole build), 64-bit) 8.3.0 - GNU ld () 2.35.1 [0.824951] Serial Number: d75c948bc5839a2e5ff85122c752949a00000000000000000000000000000000000000000000000000000000000000000000 [0.838891] Segment Configuration: Cached: SEG0_0: offset 0x0080000000, physical DDR 0x00000000 Cached: SEG0_1: offset 0x1000000000, physical DDR 0x00000000 Non-cached: SEG1_2: offset 0x00c0000000, physical DDR 0x00000000 Non-cached: SEG1_3: offset 0x1400000000, physical DDR 0x00000000 Non-cached WCB: SEG1_4: offset 0x00d0000000, physical DDR 0x00000000 Non-cached WCB: SEG1_5: offset 0x1800000000, physical DDR 0x00000000 [0.883862] L2 Cache Configuration: L2-Scratchpad: 4 ways (512 KiB) L2-Cache: 8 ways (1024 KiB) L2-LIM: 4 ways (512 KiB) [0.899807] DESIGNID: MPFS_DISCOVERY_KIT [0.907611] DESIGNVER: 0000 [0.920448] BACKLEVEL: 0000 [0.933286] startup_service :: [init] -> [boot] [0.943103] ipi_poll_service :: [Init] -> [Monitoring] Press a key to enter CLI, ESC to skip Timeout in 1 second .. Hope this contains what you're looking for. HSS-2025067-2.log<https://github.com/user-attachments/files/20641318/HSS-2025067-2.log> — Reply to this email directly, view it on GitHub<#545 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJPF627JEBCDPTV24GHEHL3CNP2RAVCNFSM6AAAAAB62C33TKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMZZHE2TMMA>. You are receiving this because you commented.Message ID: ***@***.***>

1 reply

FilkerZero Jun 7, 2025
Author

Dave:

Thank you for your continuing support. The attached log has two resets in it; the DDR training on the E54 console never completed after the first reset, so I pushed the reset button again, and it worked correctly.

The section from the second reset to the HSS prompt is:

HSS: decompressing from eNVM to L2 Scratch ... Passed
[0.42581] wdog_service monitoring [u54_1] [u54_2] [u54_3] [u54_4]
[0.50220] beu_service :: [init] -> [monitoring]
[0.56426] Initializing Mi-V IHC
[0.60818] u54 State Change:  [Idle] [Idle] [Idle] [Idle]
[0.68934] loop 1 took 6363775 ticks (max 6363775 ticks)
[0.75904] Initializing IPI Queues (3304 bytes @ a027bf0)...

















[0.777986] loop 3 took 416996416 ticks (max 416996416 ticks)
[0.785433] Initializing PMPs
[0.789539] PolarFire(R) SoC Hart Software Services (HSS) - version 0.99.44-v2025.03
MPFS HAL version 2.3.102 / DDR Driver version 0.4.024 / Mi-V IHC version 0.1.1 / BOARD=mpfs-disco-kit
(c) Copyright 2017-2025 Microchip FPGA Embedded Systems Solutions.

incorporating OpenSBI - version 1.2
(c) Copyright 2019-2022 Western Digital Corporation.

[0.824580] Build ID: b1a79621ba421fb74486a33d97fb93a155811a08
[0.832123] Built with the following tools:
 - riscv64-unknown-elf-gcc (xPack GNU RISC-V Embedded GCC (Microsemi SoftConsole build), 64-bit) 8.3.0
 - GNU ld () 2.35.1

[0.849977] Serial Number:
d75c948bc5839a2e5ff85122c752949a00000000000000000000000000000000000000000000000000000000000000000000
[0.863918] Segment Configuration:
        Cached: SEG0_0: offset 0x0080000000, physical DDR 0x00000000
        Cached: SEG0_1: offset 0x1000000000, physical DDR 0x00000000
    Non-cached: SEG1_2: offset 0x00c0000000, physical DDR 0x00000000
    Non-cached: SEG1_3: offset 0x1400000000, physical DDR 0x00000000
Non-cached WCB: SEG1_4: offset 0x00d0000000, physical DDR 0x00000000
Non-cached WCB: SEG1_5: offset 0x1800000000, physical DDR 0x00000000
[0.908889] L2 Cache Configuration:
    L2-Scratchpad:  4 ways (512 KiB)
         L2-Cache:  8 ways (1024 KiB)
           L2-LIM:  4 ways (512 KiB)
[0.924834] DESIGNID: MPFS_DISCOVERY_KIT
[0.930276] DESIGNVER: 0000
[0.934477] BACKLEVEL: 0000
[0.938678] startup_service :: [init] -> [boot]
[0.944789] ipi_poll_service :: [Init] -> [Monitoring]
Press a key to enter CLI, ESC to skip
Timeout in 1 second
..
[4.214128] CLI boot interrupt timeout
[4.219094] loop 314081 took 606532061 ticks (max 606532061 ticks)
[4.227018] Initializing Boot Image ...
[4.232079] Trying to get boot image via MMC ...
[4.237998] Attempting to select SDCARD ... Failed
>> [20.856683] loop 2500000 took 4425 ticks (max 606532061 ticks)

By the way, I also prefer BalenaEtcher, - I only installed the program I used because it was what is called out in the "Updating" instructions and thought maybe it was doing something beyond what other tools were offering.

Thanks,
Daniel Glasser
Principle SW Engineer, Collins Aerospace, (not posting from my work account, since this is my personal board)

HSS-2025067-no-SD.log

FilkerZero · 2025-06-07T22:41:22Z

FilkerZero
Jun 7, 2025
Author

Dave:

As an aside, I do have my own build of both the HSS and the reference design, however I have not made changes to the Makefiles, so my SmartConsole project probably needs updating and then I need to rebuild the JOB file in Libero 2024.2 with the new HSS.

I'm not using my builds yet because I want to make sure things work before I go breaking them. It's always been one of the "If it's not fixed, don't break it" adherents; I'm very happy to fix things that work; that's how you improve things.

Thanks,
Daniel

0 replies

rockoguido · 2025-06-07T23:18:21Z

rockoguido
Jun 7, 2025

HI Daniel, Ok thanks for the update. I recommend you just update HSS, when you need to, via SoftConsole. More direct control as opposed to using Libero but of course up to you.. Yes it is a good approach just to validate your environment to have things come up with default images. I think we covered all of the variables.. bitstream/HSS (all rolled into one) and then the prebuilt WIC. Only wildcard is what I stated before, tool used to deploy the image and the SD card itself, granted those are both a stretch and perhaps worth looking at.. Regards, Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:be3cbbea-3b84-4a57-b469-f77c0be2a9ea]

…

________________________________ From: Daniel A Glasser ***@***.***> Sent: Saturday, June 7, 2025 3:41 PM To: polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Dave Campanella - C68141 ***@***.***>; Comment ***@***.***> Subject: Re: [polarfire-soc/polarfire-soc-documentation] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Dave: As an aside, I do have my own build of both the HSS and the reference design, however I have not made changes to the Makefiles, so my SmartConsole project probably needs updating and then I need to rebuild the JOB file in Libero 2024.2 with the new HSS. I'm not using my builds yet because I want to make sure things work before I go breaking them. It's always been one of the "If it's not fixed, don't break it" adherents; I'm very happy to fix things that work; that's how you improve things. Thanks, Daniel — Reply to this email directly, view it on GitHub<#545 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJPF67FLWGWR3J4UGJZGE33CNTCPAVCNFSM6AAAAAB62C33TKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMZZHE3DGOA>. You are receiving this because you commented.Message ID: ***@***.***>

1 reply

FilkerZero Jun 7, 2025
Author

Dave:

Thanks for the confirmation that I'm using the right assets. I used Etcher to reprogram the microSD card, but I see the same output on both consoles. It's possible it's the geometry of the SD cards I've tried. The 8GB SanDisk Class 4 card I have tried seems to be too slow, since HSS never manages to get the u-boot image transferred off of it successfully. HSS seems happy with the16GB SanDisk Class 10 and 32GB Samsung EVO Plus U1 cards I have in my collection (and available for using on this), and I'm having the issue we've been talking about with both of them. I have several other TF cards in sizes from 4GB through 256GB, but those are all "precious", containing boot images and file systems for other development boards in my menagerie.

What are the Makefile changes that I need to make to my SoftConsole project to build a compatible HSS? I'm also tempted to pull down the Yocto project onto my Linux box and try to build my own SD card image with an extended set of commands enabled in U-Boot, however due to recent reshuffling of space in my house, I don't have room for a keyboard and monitor for the Linux box, and anything that expects to have a graphical display is a bit of a problem to run. (I know Yocto doesn't require a graphical display.) I'm an old "buildroot" guy, so I am not great with Yocto, however I have successfully built using a few SDKs based on Yocto.

I very much appreciate the help. It's got to be something different in how I'm trying to do this; if the released images work for you, it's unlikely that my DISCO board is sufficiently different that it shouldn't work here.

What is the brand and model of the SD card you've been using successfully? I could go out and try to find one locally, and see if that solves anything.

Thanks,
Daniel

PS: Have we corresponded before? I could swear I have your business card at work from Microsemi days, but I'm really bad at remembering names. I did a lot of software running on SmartFusion and SmartFusion2 FPGAs over the past 10 or so years. I apologize if I don't remember the circumstances - I discovered that I have a Microsemi business card for Ryan Dormody at home, but I didn't remember him when he visited our team on site a few months back. -- dag

rockoguido · 2025-06-08T00:25:27Z

rockoguido
Jun 8, 2025

Hi Daniel, Let's consider another path perhaps.. As you know the images from the SD card are expanded and loaded to the external DDR. You said something about some temperamental behavior regarding the 2nd console, that's U54_1 code that is initializing and training the external DDR. Would be worthwhile to bang on this DDR with one of our bare metal examples. This example.. https://github.com/polarfire-soc/polarfire-soc-bare-metal-examples/tree/main/driver-examples/mss/mpfs-hal/mpfs-hal-ddr-demo [https://opengraph.githubassets.com/c87ce721f9bb0eb847644ac937c37aae6a018097b5fb5b7fd5ce57e6593f0ff0/polarfire-soc/polarfire-soc-bare-metal-examples]<https://github.com/polarfire-soc/polarfire-soc-bare-metal-examples/tree/main/driver-examples/mss/mpfs-hal/mpfs-hal-ddr-demo> polarfire-soc-bare-metal-examples/driver-examples/mss/mpfs-hal/mpfs-hal-ddr-demo at main · polarfire-soc/polarfire-soc-bare-metal-examples<https://github.com/polarfire-soc/polarfire-soc-bare-metal-examples/tree/main/driver-examples/mss/mpfs-hal/mpfs-hal-ddr-demo> Bare metal example software projects for PolarFire SoC - polarfire-soc/polarfire-soc-bare-metal-examples github.com Does just that for many platforms, including the Disco Kit. I'm not sure how familiar you are with our bare metal examples and the work flow to get them loaded into SoftConsole and executed from LIM/Internal RAM. This is something I recommend to a lot of users having DDR goofiness, may or may not be relevant. As for building your own Yocto image (yes we still do Buildroot too.) check out https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp [https://opengraph.githubassets.com/b179aad2e1150a87f654f3ccb012ff8e05d1e953fc495ae60a0af76bc7b4f785/polarfire-soc/meta-polarfire-soc-yocto-bsp]<https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp> polarfire-soc/meta-polarfire-soc-yocto-bsp: PolarFire SoC yocto Board Support Package - GitHub<https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp> Collection of OpenEmbedded/Yocto layers for PolarFire SoC. meta-polarfire-soc-bsp: layer containing PolarFire SoC's evaluation boards' metadata such as machine configuration files and core recipes (Linux, U-Boot, etc.).. meta-polarfire-soc-community: layer containing Microchip's partners' evaluation kits' machine configuration files and associated configuration fragments. github.com There is a fair amount to it and lots of time required to build, 1st build about 4 hours... For Buildroot see https://github.com/linux4microchip/buildroot-external-microchip [https://opengraph.githubassets.com/501574d46caa158b92998333d59c4ee11253c0e36dd372f2556968fed2c09f7b/linux4microchip/buildroot-external-microchip]<https://github.com/linux4microchip/buildroot-external-microchip> linux4microchip/buildroot-external-microchip: Buildroot External for Microchip SoC - GitHub<https://github.com/linux4microchip/buildroot-external-microchip> This buildroot external includes Microchip packages, patches, setup, and configuration to work with Microchip provided software that is not included in mainline buildroot. This includes creating demo root filesystems. This project provides an extension to buildroot to support these customizations ... github.com Up to you which way you want to go, of course Buildroot is a bit simpler and more sane, might be a good place for you to start. Buildroot has info for both ARM and PolarFire, of course skip the ARM section.. BTW... you don't need menuconfig for Buildroot, you can go with the default .config and be fine for now. Well I don't have any Microsemi background to be honest. I'm more of a Linux guy than a FPGA/fabric guy but that seems to be an evolving story 🙂 I'll be off duty for a while but feel free to keep us posted.! Regards, Dave Campanella Principal Embedded Solutions Engineer / FAE Microchip Technology Inc. 165 Technology Dr Irvine, CA 92618 +1 925 989 0569 (mobile) +1 760 304 0172 (office) ***@***.******@***.***> [cid:7d2a1eba-7c96-4f73-9d72-c66a6fd0fa7d]

…

________________________________ From: Daniel A Glasser ***@***.***> Sent: Saturday, June 7, 2025 4:44 PM To: polarfire-soc/polarfire-soc-documentation ***@***.***> Cc: Dave Campanella - C68141 ***@***.***>; Comment ***@***.***> Subject: Re: [polarfire-soc/polarfire-soc-documentation] PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT (Discussion #545) EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe Dave: Thanks for the confirmation that I'm using the right assets. I used Etcher to reprogram the microSD card, but I see the same output on both consoles. It's possible it's the geometry of the SD cards I've tried. The 8GB SanDisk Class 4 card I have tried seems to be too slow, since HSS never manages to get the u-boot image transferred off of it successfully. HSS seems happy with the16GB SanDisk Class 10 and 32GB Samsung EVO Plus U1 cards I have in my collection (and available for using on this), and I'm having the issue we've been talking about with both of them. I have several other TF cards in sizes from 4GB through 256GB, but those are all "precious", containing boot images and file systems for other development boards in my menagerie. What are the Makefile changes that I need to make to my SoftConsole project to build a compatible HSS? I'm also tempted to pull down the Yocto project onto my Linux box and try to build my own SD card image with an extended set of commands enabled in U-Boot, however due to recent reshuffling of space in my house, I don't have room for a keyboard and monitor for the Linux box, and anything that expects to have a graphical display is a bit of a problem to run. (I know Yocto doesn't require a graphical display.) I'm an old "buildroot" guy, so I am not great with Yocto, however I have successfully built using a few SDKs based on Yocto. I very much appreciate the help. It's got to be something different in how I'm trying to do this; if the released images work for you, it's unlikely that my DISCO board is sufficiently different that it shouldn't work here. What is the brand and model of the SD card you've been using successfully? I could go out and try to find one locally, and see if that solves anything. Thanks, Daniel PS: Have we corresponded before? I could swear I have your business card at work from Microsemi days, but I'm really bad at remembering names. I did a lot of software running on SmartFusion and SmartFusion2 FPGAs over the past 10 or so years. I apologize if I don't remember the circumstances - I discovered that I have a Microsemi business card for Ryan Dormody at home, but I didn't remember him when he visited our team on site a few months back. -- dag — Reply to this email directly, view it on GitHub<#545 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AXJPF622CLTWTUBM7B2BI6L3CN2OPAVCNFSM6AAAAAB62C33TKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTGMZZHE3TKNA>. You are receiving this because you commented.Message ID: ***@***.***>

1 reply

FilkerZero Jun 8, 2025
Author

Dave:

Thanks for your help. Your name rings a bell somewhere back in my brain, which is why I though I might have had some correspondence at some point. My mind is a jumble of stuff, and it's sometimes hard to keep track of what's what.

I'll muddle through, and I will take a look at the bare metal examples.

Have a good weekend!

Thanks,
Daniel

FilkerZero · 2025-06-08T02:34:50Z

FilkerZero
Jun 8, 2025
Author

Dave:

Update: I went out and purchased a new 64GB microSD card (SanDisk "ImageMate microSDXC UHS-1), used the Linux dd command to copy the .wic file to the drive, went into fdisk to fix the problems that dd copying alone doesn't clear up (GPT PMBR size mismatch, backup GPT table not on the end of the device) by writing the "label" back out to the card, stuck it in the MPFS-DISCO-KIT board's microSD slot, and plugged it in. I now have a Linux login prompt.

I don't know if using dd was the solution, or whether it's the card itself, but I now have the ability to boot Linux in the MSS on the PolarFire SoC.

Thank you very much for all your support today.

Thanks again,
Daniel

1 reply

mschafer Jan 9, 2026

I'm seeing the same problem. Could you share the specific dd and fdisk command lines that you used to fix the problem?

PolarFire SoC Discovery Kit Reference Design and pre-built Yocto SD image - UBOOT vs. GPT #545

Uh oh!

Replies: 10 comments · 6 replies

Uh oh!

Uh oh!

Uh oh!

FilkerZero Jun 7, 2025 Author

Uh oh!

Uh oh!

FilkerZero Jun 7, 2025 Author

Uh oh!

Uh oh!

FilkerZero Jun 7, 2025 Author

Uh oh!

Uh oh!

FilkerZero Jun 7, 2025 Author

Uh oh!

FilkerZero Jun 7, 2025 Author

Uh oh!

Uh oh!

FilkerZero Jun 7, 2025 Author

Uh oh!

Uh oh!

FilkerZero Jun 8, 2025 Author

Uh oh!

FilkerZero Jun 8, 2025 Author

Uh oh!

Replies: 10 comments 6 replies

FilkerZero
Jun 7, 2025
Author

FilkerZero Jun 7, 2025
Author

FilkerZero Jun 7, 2025
Author

FilkerZero Jun 7, 2025
Author

FilkerZero
Jun 7, 2025
Author

FilkerZero Jun 7, 2025
Author

FilkerZero Jun 8, 2025
Author

FilkerZero
Jun 8, 2025
Author