Closed kowalski100 closed 2 years ago
Hi @kowalski100,
$ sudo losetup -vfP --show core-image-minimal-dev.wic
This will print out the new loop device number to the console, e.g., something like ...
/dev/loop31
Extract the HSS payload.bin
from this... It is usually partition 2 -- you can use fdisk /dev/loopXX
to be sure, where //dev/loopXX
corresponds to the loop device number previously printed to the console.
For the rest of this example, I'm going to use /dev/loop31
, but make sure to substitute the correct loop device for your system.
$ sudo fdisk -l /dev/loop31
Disk /dev/loop31: 6.48 GiB, 6947813376 bytes, 13569948 sectors
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: CA845C1B-DFCA-4AB7-8686-DCB4827DC157
Device Start End Sectors Size Type
/dev/loop31p1 8192 47685 39494 19.3M Microsoft basic data
/dev/loop31p2 47686 64069 16384 8M BIOS boot
/dev/loop31p3 65536 13569913 13504378 6.4G Linux filesystem
You can see from the above fdisk output that /dev/loop31p2
is the "BIOS boot" partition type used by the HSS to find the payload.bin.
Next, copy payload.bin
from the loopback partition to a file, and delete the loopback device (as we're finished with it).
$ sudo dd if=/dev/loop31p2 of=payload.bin
$ sudo losetup -d /dev/loop31
The resulting payload.bin
file will be the size of partition /dev/loop31p2
, so it could be longer than the original payload.bin
-- but you mightn't really care about the stuff at the end... If you do, follow the next few steps...
OPTIONAL: Use the payload generator -d flag to make sure that it is a payload.bin.:
$ hss-payload-generator -d payload.bin
Hart Software Service formatted boot image generator v0.99.26
Copyright (c) 2021 Microchip FPGA Embedded Systems Solutions.
opening >>payload.bin<<
magic: 0xb007c0de
headerLength: 0x678
chunkTableOffset: 0x610
ziChunkTableOffset: 0x660
name[0]: >>u-boot.bin<<
entryPoint[0]: 0x80200000
privMode[0]: 1 (PRV_S)
flags[0]: 0
firstChunk[0] 0
lastChunk[0] 0
numChunks[0] 1
name[1]: >><<
entryPoint[1]: 0x80200000
privMode[1]: 1 (PRV_S)
flags[1]: 0
firstChunk[1] 0
lastChunk[1] 0
numChunks[1] 0
name[2]: >><<
entryPoint[2]: 0x80200000
privMode[2]: 1 (PRV_S)
flags[2]: 0
firstChunk[2] 0
lastChunk[2] 0
numChunks[2] 0
name[3]: >><<
entryPoint[3]: 0x80200000
privMode[3]: 1 (PRV_S)
flags[3]: 0
firstChunk[3] 0
lastChunk[3] 0
numChunks[3] 0
set_name >>PolarFire-SoC-HSS::U-Boot<<
bootImageLength: 497976
headerCrc: 0x6b5bf69b
- 1 chunk found for owner 1
Boot Chunks: total of 2 chunks found
ZI Chunks: total of 1 chunk found
OPTIONAL: Truncate the payload.bin size: - In this case, the HSS Payload Generator tool has told us that the payload.bin
file is 496976 bytes long (bootImageLength: 497976
above) so we can truncate the file we created using dd...
$ truncate -s 497976 payload.bin
Hi @griffini,
Thank you so much for taking time to provide such a detail answer. I was able to extract payload.bin file. I have following followup questions:
Sure. We want our software to run on icicle after uboot instead of linux kernel. So we need flow till uboot.
Regarding your questions:
payload.bin
contains the U-Boot binary, plus some additional formatting/header information needed by the HSS. The file can contan any application image you want - or indeed, multiple images, and describes how they are assigned to the various U54 harts. I don't know what uboot.img is (in the context of PolarFire SoC) -- where was this file?
Yes, you can use a standalone payload.bin
that you program to the eMMC and have the HSS load it. By default, the HSS with search for a partition on the eMMC (if no SDCard is inserted) with a GUID of 21686148-6449-6E6F-744E-656564454649 and if it finds one attempt to load a payload.bin
image from it.
If it doesn't find a BIOS boot partition, it will also search the start of the eMMC (sector zero) for its payload.bin
image.
You can follow the same flow to write the payload.bin
file directly instead of the full .wic image if you do not need Linux.
Yes, OpenSBI is provided as part of the HSS. The binary file you build as part of your custom payload.bin
file will be started using OpenSBI.
See https://github.com/polarfire-soc/hart-software-services/tree/master/tools/hss-payload-generator#readme for more information on how to create a payload.bin
file that is bootable via the HSS.
What you describe is simpler than using Linux, so your flow will be probably something like:
hss-payload-generator
with your .bin or .elf to create a payload.bin
fileUSBDMSC
command to program the payload.bin
directly to the eMMCpayload.bin
@griffini Thank you so much for the detail answer.
We need uboot and openSBI image from the following version:
https://github.com/polarfire-soc/meta-polarfire-soc-yocto-bsp/releases/tag/v2021.04