Greetings everyone,
I came across the following paragraph while reading the 'Firmware Partition Filesystem' chapter from EBBR v2.2.0 and I would like to clarify my understanding: Where possible, firmware images and data should be stored in a filesystem. Firmware can be stored either in a dedicated firmware partition, or in certain circumstances in the UEFI System Partition (ESP). Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms.
Dedicated firmware partitions should be formatted with a FAT filesystem as defined in UEFI § 13.3 File System Format. Dedicated firmware partitions should use the same /FIRMWARE directory hierarchy. OS tools shall ignore dedicated firmware partitions, and shall not attempt to use a dedicated firmware partition as an ESP
Questions: 1. Does the above paragraph mean that, if the device allows, all firmware binaries (TF-A, U-Boot, and some others) must be stored in a dedicated firmware partition formatted with a FAT filesystem and GUID Partition Table (GPT) disk layout? 2. If so, would this also mean that, where possible, the BootROM or a (first stage) bootloader running before TF-A should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Regards, Ghennadi
On Fri, Jul 19, 2024 at 02:12:59PM +0000, Ghennadi Procopciuc wrote:
Greetings everyone,
I came across the following paragraph while reading the 'Firmware Partition Filesystem' chapter from EBBR v2.2.0 and I would like to clarify my understanding: Where possible, firmware images and data should be stored in a filesystem. Firmware can be stored either in a dedicated firmware partition, or in certain circumstances in the UEFI System Partition (ESP). Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms.
Dedicated firmware partitions should be formatted with a FAT filesystem as defined in UEFI § 13.3 File System Format. Dedicated firmware partitions should use the same /FIRMWARE directory hierarchy. OS tools shall ignore dedicated firmware partitions, and shall not attempt to use a dedicated firmware partition as an ESP
Questions: 1. Does the above paragraph mean that, if the device allows, all firmware binaries (TF-A, U-Boot, and some others) must be stored in a dedicated firmware partition formatted with a FAT filesystem and GUID Partition Table (GPT) disk layout?
Hi Ghennadi,
Yes, ideally this is what EBBR recommends as the second-best option (the best option being to use a dedicated storage).
2. If so, would this also mean that, where possible, the BootROM or a (first stage) bootloader running before TF-A should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Yes. This is not as crazy as it sounds; I know some Texan SoCs from a decade ago, which had FAT + MBR support in ROM. Alternatively, U-Boot SPL as a first stage bootloader, as you mentioned, would tick all the boxes, too. This might be easier to fit in a small, dedicated storage.
Best regards,
Vincent Stehlé System Architect - Arm
Regards, Ghennadi _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Questions: 1. Does the above paragraph mean that, if the device allows, all firmware
binaries (TF-A, U-Boot, and some others)
must be stored in a dedicated firmware partition formatted with a FATfilesystem and GUID Partition Table (GPT)
disk layout?Hi Ghennadi,
Hi Vincent,
Thank you for taking the time to provide the answers!
Yes, ideally this is what EBBR recommends as the second-best option (the best option being to use a dedicated storage).
Ok, I thought that the ideal case is when all firmware images are stored on a dedicated storage device or hardware logical unit (UFS LU or eMMC boot partition), and that device or LU is formatted with FAT filesystem where each file can be referenced by name rather than by an offset. At least this is what 'Where possible, firmware images and data should be stored in a filesystem' suggested to me, the reason being iterated later: ' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for various platforms.' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms'.
I understand there are cases when, due to various factors, everything will be placed on the same storage memory (no LU), as described in 'Partitioning of Shared Storage', but I was referring to cases when separate storage can be dedicated for firmware images.
2. If so, would this also mean that, where possible, the BootROM or a (firststage) bootloader running before TF-A
should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Yes. This is not as crazy as it sounds; I know some Texan SoCs from a decade ago, which had FAT + MBR support in ROM. Alternatively, U-Boot SPL as a first stage bootloader, as you mentioned, would tick all the boxes, too. This might be easier to fit in a small, dedicated storage.
In my question, I considered a case where the platform contains a System Control Processor that boots first and acts as a first-stage bootloader as well. I assumed that this bootloader runs on a different CPU/type of core than the TF-A and U-Boot and uses different storage than firmware images used for the core(s) involved in the second-stage bootloader's execution. Here is the assumed bootflow: BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> Linux
This way, the storage and the CPU execution are entirely isolated from each other.
On the other hand, from what I understand, the boot flow described in your reply looks like this: BootROM -> U-Boot SPL -> BL2 -> BL31 -> U-Boot -> Linux
In this example, the same core executes all bootloaders starting with U-Boot SPL. While the BL2, BL31, and U-Boot are somehow stored in a FAT32 partition, the U-Boot SPL is stored in a raw format and loaded by the BootROM by an offset.
I'm a bit puzzled because I assumed all firmware images, including U-Boot SPL, should be placed in the same FAT partition. Given that in this example, we have a mix of offset-based (U-Boot SPL) and filesystem-stored binaries, it seems that I misunderstood some aspects of EBBR.
Or, I may have wrongly interpreted your answer. Could you please provide more details? Maybe a dumb question: could you clarify what the term 'firmware' refers to when used in EBBR?
Regards, Ghennadi
On Fri, Jul 19, 2024 at 07:51:26PM +0000, Ghennadi Procopciuc wrote:
Yes, ideally this is what EBBR recommends as the second-best option (the best option being to use a dedicated storage).
Ok, I thought that the ideal case is when all firmware images are stored on a dedicated storage device or hardware logical unit (UFS LU or eMMC boot partition), and that device or LU is formatted with FAT filesystem where each file can be referenced by name rather than by an offset. At least this is what 'Where possible, firmware images and data should be stored in a filesystem' suggested to me, the reason being iterated later: ' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for various platforms.' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms'.
I think section 4.2 ends up being a rather unclear about what it applies to.
To be honest I have long thought that is only applied to shared storage (e.g. where firmware and OS are both included in partitions from a single GPT/MBR). However I can see it could be read differently.
In particular note that the ESP "belongs" to the OS so firmware stored in an ESP does imply shared storage or at least the that ESP exists on media that is controlled by the OS.
I understand there are cases when, due to various factors, everything will be placed on the same storage memory (no LU), as described in 'Partitioning of Shared Storage', but I was referring to cases when separate storage can be dedicated for firmware images.
2. If so, would this also mean that, where possible, the BootROM or a (firststage) bootloader running before TF-A
should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Yes. This is not as crazy as it sounds; I know some Texan SoCs from a decade ago, which had FAT + MBR support in ROM. Alternatively, U-Boot SPL as a first stage bootloader, as you mentioned, would tick all the boxes, too. This might be easier to fit in a small, dedicated storage.
In my question, I considered a case where the platform contains a System Control Processor that boots first and acts as a first-stage bootloader as well. I assumed that this bootloader runs on a different CPU/type of core than the TF-A and U-Boot and uses different storage than firmware images used for the core(s) involved in the second-stage bootloader's execution. Here is the assumed bootflow: BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> Linux
This way, the storage and the CPU execution are entirely isolated from each other.
On the other hand, from what I understand, the boot flow described in your reply looks like this: BootROM -> U-Boot SPL -> BL2 -> BL31 -> U-Boot -> Linux
In this example, the same core executes all bootloaders starting with U-Boot SPL. While the BL2, BL31, and U-Boot are somehow stored in a FAT32 partition, the U-Boot SPL is stored in a raw format and loaded by the BootROM by an offset.
I'm a bit puzzled because I assumed all firmware images, including U-Boot SPL, should be placed in the same FAT partition. Given that in this example, we have a mix of offset-based (U-Boot SPL) and filesystem-stored binaries, it seems that I misunderstood some aspects of EBBR.
I think what might be missed here is that some of what appears in section 4 is effectively advisory information for boot ROM authors. If you are working with a chip whose boot ROM is incompatible with these recommendations (by loading something from a fixed offset) it is impossible (or at least extremely impractical) to fully follow the advice w.r.t. loading firmware from a filesystem.
This need to work with chips whose boot ROMs prevent the use of a filesystem leads to a lot of the section 4 complexity. It is also why this section is merely recommended ("should") rather than required ("shall").
Or, I may have wrongly interpreted your answer. Could you please provide more details? Maybe a dumb question: could you clarify what the term 'firmware' refers to when used in EBBR?
EBBR separates the world into firmware and OS and the dividing line between them is EFI (exactly as it would be on a modern PC). Whether you boot on the main core or via a co-processor between boot ROM and OS is "firmware".
If I were to edit your first assumed bootflow as an example it becomes:
BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> grub -> Linux Provided by: ROM f/w f/w f/w f/w OS OS
Note that you can also replace "grub" with "systemd-boot", "UKI/systemd stub" or any other OS controlled bootloader[1].
Daniel
[1]: Strictly speaking the OS could also choose to have the firmware load Linux (which has a built-in EFI stub loader). However the key thing is that this is an OS choice, not a firmware choice. Also it is actually pretty rare in practice because directly booting the kernel makes it harder for the distro to provide recovery options if the kernel is bad.
On 7/22/2024 2:45 PM, Daniel Thompson wrote:
On Fri, Jul 19, 2024 at 07:51:26PM +0000, Ghennadi Procopciuc wrote:
Yes, ideally this is what EBBR recommends as the second-best option (the best option being to use a dedicated storage).
Ok, I thought that the ideal case is when all firmware images are stored on a dedicated storage device or hardware logical unit (UFS LU or eMMC boot partition), and that device or LU is formatted with FAT filesystem where each file can be referenced by name rather than by an offset. At least this is what 'Where possible, firmware images and data should be stored in a filesystem' suggested to me, the reason being iterated later: ' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for various platforms.' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms'.
I think section 4.2 ends up being a rather unclear about what it applies to.
To be honest I have long thought that is only applied to shared storage (e.g. where firmware and OS are both included in partitions from a single GPT/MBR). However I can see it could be read differently.
In particular note that the ESP "belongs" to the OS so firmware stored in an ESP does imply shared storage or at least the that ESP exists on media that is controlled by the OS.
Could this section be updated in order to reduce the number of different interpretations?
I understand there are cases when, due to various factors, everything will be placed on the same storage memory (no LU), as described in 'Partitioning of Shared Storage', but I was referring to cases when separate storage can be dedicated for firmware images.
2. If so, would this also mean that, where possible, the BootROM or a (firststage) bootloader running before TF-A
should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Yes. This is not as crazy as it sounds; I know some Texan SoCs from a decade ago, which had FAT + MBR support in ROM. Alternatively, U-Boot SPL as a first stage bootloader, as you mentioned, would tick all the boxes, too. This might be easier to fit in a small, dedicated storage.
In my question, I considered a case where the platform contains a System Control Processor that boots first and acts as a first-stage bootloader as well. I assumed that this bootloader runs on a different CPU/type of core than the TF-A and U-Boot and uses different storage than firmware images used for the core(s) involved in the second-stage bootloader's execution. Here is the assumed bootflow: BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> Linux
This way, the storage and the CPU execution are entirely isolated from each other.
On the other hand, from what I understand, the boot flow described in your reply looks like this: BootROM -> U-Boot SPL -> BL2 -> BL31 -> U-Boot -> Linux
In this example, the same core executes all bootloaders starting with U-Boot SPL. While the BL2, BL31, and U-Boot are somehow stored in a FAT32 partition, the U-Boot SPL is stored in a raw format and loaded by the BootROM by an offset.
I'm a bit puzzled because I assumed all firmware images, including U-Boot SPL, should be placed in the same FAT partition. Given that in this example, we have a mix of offset-based (U-Boot SPL) and filesystem-stored binaries, it seems that I misunderstood some aspects of EBBR.
I think what might be missed here is that some of what appears in section 4 is effectively advisory information for boot ROM authors. If you are working with a chip whose boot ROM is incompatible with these recommendations (by loading something from a fixed offset) it is impossible (or at least extremely impractical) to fully follow the advice w.r.t. loading firmware from a filesystem.
This need to work with chips whose boot ROMs prevent the use of a filesystem leads to a lot of the section 4 complexity. It is also why this section is merely recommended ("should") rather than required ("shall").
Or, I may have wrongly interpreted your answer. Could you please provide more details? Maybe a dumb question: could you clarify what the term 'firmware' refers to when used in EBBR?
EBBR separates the world into firmware and OS and the dividing line between them is EFI (exactly as it would be on a modern PC). Whether you boot on the main core or via a co-processor between boot ROM and OS is "firmware".
If I were to edit your first assumed bootflow as an example it becomes:
BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> grub -> LinuxProvided by: ROM f/w f/w f/w f/w OS OS
Note that you can also replace "grub" with "systemd-boot", "UKI/systemd stub" or any other OS controlled bootloader[1].
In this example, SCP, BL2, BL31 and U-Boot shall all be part of the FAT partition given their firmware classification. If so, then BootROM, SCP, and BL2, all of which can load images, must also be able to load their next stages from FAT. Is that right?
Regards, Ghennadi
a
On Mon, Jul 22, 2024 at 2:46 PM Ghennadi Procopciuc ghennadi.procopciuc@nxp.com wrote:
On 7/22/2024 2:45 PM, Daniel Thompson wrote:
On Fri, Jul 19, 2024 at 07:51:26PM +0000, Ghennadi Procopciuc wrote:
Yes, ideally this is what EBBR recommends as the second-best option (the best option being to use a dedicated storage).
Ok, I thought that the ideal case is when all firmware images are stored on a dedicated storage device or hardware logical unit (UFS LU or eMMC boot partition), and that device or LU is formatted with FAT filesystem where each file can be referenced by name rather than by an offset. At least this is what 'Where possible, firmware images and data should be stored in a filesystem' suggested to me, the reason being iterated later: ' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for various platforms.' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms'.
I think section 4.2 ends up being a rather unclear about what it applies to.
To be honest I have long thought that is only applied to shared storage (e.g. where firmware and OS are both included in partitions from a single GPT/MBR). However I can see it could be read differently.
In particular note that the ESP "belongs" to the OS so firmware stored in an ESP does imply shared storage or at least the that ESP exists on media that is controlled by the OS.
Could this section be updated in order to reduce the number of different interpretations?
Yes, it can be clarified. As Daniel says, this section is only intended for platforms where there is no other place to store firmware. If the OS and the firmware need to share a logical block device, and there is no way to protect the firmware bits, then this section describes how they can co-exist. e.g., you don't want an OS deployment to accidentally wipe out firmware.
It is preferred and encouraged to have firmware contained entirely in something separate from the main block storage. For example, in eMMC boot areas (separate from the primary area), or on a separate device entirely (SPI flash). I predict that a future version of EBBR will require this and drop the shared storage option entirely because it is necessary to protect against attacks against firmware (replacement or deletion)
g.
I understand there are cases when, due to various factors, everything will be placed on the same storage memory (no LU), as described in 'Partitioning of Shared Storage', but I was referring to cases when separate storage can be dedicated for firmware images.
2. If so, would this also mean that, where possible, the BootROM or a (firststage) bootloader running before TF-A
should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Yes. This is not as crazy as it sounds; I know some Texan SoCs from a decade ago, which had FAT + MBR support in ROM. Alternatively, U-Boot SPL as a first stage bootloader, as you mentioned, would tick all the boxes, too. This might be easier to fit in a small, dedicated storage.
In my question, I considered a case where the platform contains a System Control Processor that boots first and acts as a first-stage bootloader as well. I assumed that this bootloader runs on a different CPU/type of core than the TF-A and U-Boot and uses different storage than firmware images used for the core(s) involved in the second-stage bootloader's execution. Here is the assumed bootflow: BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> Linux
This way, the storage and the CPU execution are entirely isolated from each other.
On the other hand, from what I understand, the boot flow described in your reply looks like this: BootROM -> U-Boot SPL -> BL2 -> BL31 -> U-Boot -> Linux
In this example, the same core executes all bootloaders starting with U-Boot SPL. While the BL2, BL31, and U-Boot are somehow stored in a FAT32 partition, the U-Boot SPL is stored in a raw format and loaded by the BootROM by an offset.
I'm a bit puzzled because I assumed all firmware images, including U-Boot SPL, should be placed in the same FAT partition. Given that in this example, we have a mix of offset-based (U-Boot SPL) and filesystem-stored binaries, it seems that I misunderstood some aspects of EBBR.
I think what might be missed here is that some of what appears in section 4 is effectively advisory information for boot ROM authors. If you are working with a chip whose boot ROM is incompatible with these recommendations (by loading something from a fixed offset) it is impossible (or at least extremely impractical) to fully follow the advice w.r.t. loading firmware from a filesystem.
This need to work with chips whose boot ROMs prevent the use of a filesystem leads to a lot of the section 4 complexity. It is also why this section is merely recommended ("should") rather than required ("shall").
Or, I may have wrongly interpreted your answer. Could you please provide more details? Maybe a dumb question: could you clarify what the term 'firmware' refers to when used in EBBR?
EBBR separates the world into firmware and OS and the dividing line between them is EFI (exactly as it would be on a modern PC). Whether you boot on the main core or via a co-processor between boot ROM and OS is "firmware".
If I were to edit your first assumed bootflow as an example it becomes:
BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> grub -> LinuxProvided by: ROM f/w f/w f/w f/w OS OS
Note that you can also replace "grub" with "systemd-boot", "UKI/systemd stub" or any other OS controlled bootloader[1].
In this example, SCP, BL2, BL31 and U-Boot shall all be part of the FAT partition given their firmware classification. If so, then BootROM, SCP, and BL2, all of which can load images, must also be able to load their next stages from FAT. Is that right?
Regards, Ghennadi
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Hi
Just my 2cents on the below question.
Thanks, Manish Badarkhe
________________________________ From: Grant Likely via TF-A tf-a@lists.trustedfirmware.org Sent: 23 July 2024 10:06 To: Ghennadi Procopciuc ghennadi.procopciuc@nxp.com Cc: Daniel Thompson (daniel.thompson@linaro.org) daniel.thompson@linaro.org; Vincent Stehle Vincent.Stehle@arm.com; boot-architecture boot-architecture@lists.linaro.org; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org Subject: [TF-A] Re: Firmware Partition Filesystem query
a
On Mon, Jul 22, 2024 at 2:46 PM Ghennadi Procopciuc ghennadi.procopciuc@nxp.com wrote:
On 7/22/2024 2:45 PM, Daniel Thompson wrote:
On Fri, Jul 19, 2024 at 07:51:26PM +0000, Ghennadi Procopciuc wrote:
Yes, ideally this is what EBBR recommends as the second-best option (the best option being to use a dedicated storage).
Ok, I thought that the ideal case is when all firmware images are stored on a dedicated storage device or hardware logical unit (UFS LU or eMMC boot partition), and that device or LU is formatted with FAT filesystem where each file can be referenced by name rather than by an offset. At least this is what 'Where possible, firmware images and data should be stored in a filesystem' suggested to me, the reason being iterated later: ' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for various platforms.' Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms'.
I think section 4.2 ends up being a rather unclear about what it applies to.
To be honest I have long thought that is only applied to shared storage (e.g. where firmware and OS are both included in partitions from a single GPT/MBR). However I can see it could be read differently.
In particular note that the ESP "belongs" to the OS so firmware stored in an ESP does imply shared storage or at least the that ESP exists on media that is controlled by the OS.
Could this section be updated in order to reduce the number of different interpretations?
Yes, it can be clarified. As Daniel says, this section is only intended for platforms where there is no other place to store firmware. If the OS and the firmware need to share a logical block device, and there is no way to protect the firmware bits, then this section describes how they can co-exist. e.g., you don't want an OS deployment to accidentally wipe out firmware.
It is preferred and encouraged to have firmware contained entirely in something separate from the main block storage. For example, in eMMC boot areas (separate from the primary area), or on a separate device entirely (SPI flash). I predict that a future version of EBBR will require this and drop the shared storage option entirely because it is necessary to protect against attacks against firmware (replacement or deletion)
g.
I understand there are cases when, due to various factors, everything will be placed on the same storage memory (no LU), as described in 'Partitioning of Shared Storage', but I was referring to cases when separate storage can be dedicated for firmware images.
2. If so, would this also mean that, where possible, the BootROM or a (firststage) bootloader running before TF-A
should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)?
Yes. This is not as crazy as it sounds; I know some Texan SoCs from a decade ago, which had FAT + MBR support in ROM. Alternatively, U-Boot SPL as a first stage bootloader, as you mentioned, would tick all the boxes, too. This might be easier to fit in a small, dedicated storage.
In my question, I considered a case where the platform contains a System Control Processor that boots first and acts as a first-stage bootloader as well. I assumed that this bootloader runs on a different CPU/type of core than the TF-A and U-Boot and uses different storage than firmware images used for the core(s) involved in the second-stage bootloader's execution. Here is the assumed bootflow: BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> Linux
This way, the storage and the CPU execution are entirely isolated from each other.
On the other hand, from what I understand, the boot flow described in your reply looks like this: BootROM -> U-Boot SPL -> BL2 -> BL31 -> U-Boot -> Linux
In this example, the same core executes all bootloaders starting with U-Boot SPL. While the BL2, BL31, and U-Boot are somehow stored in a FAT32 partition, the U-Boot SPL is stored in a raw format and loaded by the BootROM by an offset.
I'm a bit puzzled because I assumed all firmware images, including U-Boot SPL, should be placed in the same FAT partition. Given that in this example, we have a mix of offset-based (U-Boot SPL) and filesystem-stored binaries, it seems that I misunderstood some aspects of EBBR.
I think what might be missed here is that some of what appears in section 4 is effectively advisory information for boot ROM authors. If you are working with a chip whose boot ROM is incompatible with these recommendations (by loading something from a fixed offset) it is impossible (or at least extremely impractical) to fully follow the advice w.r.t. loading firmware from a filesystem.
This need to work with chips whose boot ROMs prevent the use of a filesystem leads to a lot of the section 4 complexity. It is also why this section is merely recommended ("should") rather than required ("shall").
Or, I may have wrongly interpreted your answer. Could you please provide more details? Maybe a dumb question: could you clarify what the term 'firmware' refers to when used in EBBR?
EBBR separates the world into firmware and OS and the dividing line between them is EFI (exactly as it would be on a modern PC). Whether you boot on the main core or via a co-processor between boot ROM and OS is "firmware".
If I were to edit your first assumed bootflow as an example it becomes:
BootROM -> SCP -> BL2 -> BL31 -> U-Boot -> grub -> LinuxProvided by: ROM f/w f/w f/w f/w OS OS
Note that you can also replace "grub" with "systemd-boot", "UKI/systemd stub" or any other OS controlled bootloader[1].
In this example, SCP, BL2, BL31 and U-Boot shall all be part of the FAT partition given their firmware classification. If so, then BootROM, SCP, and BL2, all of which can load images, must also be able to load their next stages from FAT. Is that right?
If I recall correctly, on the Arm platform, A-BL1 (BootROM) and A-BL2 are responsible only for loading the images. SCP_BL2 is loaded by BL2 into trusted SRAM and then transferred to the SCP using the MHU protocol and I believe it is followed this way for other platforms also (?). In summary, A-BL1(BootROM) and A-BL2 need to be aware of their next stages to load those images properly: BootROM -> BL2 -> BL31 -> ... | v SCP
Regards, Ghennadi
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
-- TF-A mailing list -- tf-a@lists.trustedfirmware.org To unsubscribe send an email to tf-a-leave@lists.trustedfirmware.org
Could this section be updated in order to reduce the number of different interpretations?
Yes, it can be clarified. As Daniel says, this section is only intended for platforms where there is no other place to store firmware. If the OS and the firmware need to share a logical block device, and there is no way to protect the firmware bits, then this section describes how they can co-exist. e.g., you don't want an OS deployment to accidentally wipe out firmware.
It is preferred and encouraged to have firmware contained entirely in something separate from the main block storage. For example, in eMMC boot areas (separate from the primary area), or on a separate device entirely (SPI flash). I predict that a future version of EBBR will require this and drop the shared storage option entirely because it is necessary to protect against attacks against firmware (replacement or deletion)
g.
Thank you all contributing to this thread!
While most of the points in this thread are self-explanatory and should not need a summary, I want to extract the main points to avoid misinterpretations: 1. Chapters '4.1 Partitioning of Shared Storage' and '4.2 Firmware Partition Filesystem' refer to cases when shared storage is used for OS and firmware images. In this case, the block device needs to be partitioned using GPT and the firmware binaries should be stored in a FAT partition. The folder organization for this partition is described in the '4.2.1 The firmware directory hierarchy' chapter. Ideally, the BootROM should be able to load images from a FAT partition. However, a feature release of the EBBR is likely to drop this option in the future.
2. For scenarios involving dedicated storage, the organization of the underlying storage for firmware falls outside the scope of the EBBR and can be arranged according to the SoC vendor's discretion. This can include options such as offset addressing, without GPT, with MRB, with or without a partition, based on the platform's requirements or limitations.
Could you please confirm that this understanding is correct?
If I recall correctly, on the Arm platform, A-BL1 (BootROM) and A-BL2 are responsible only for loading the images. SCP_BL2 is loaded by BL2 into trusted SRAM and then transferred to the SCP using the MHU protocol and I believe it is followed this way for other platforms also (?). In summary, A-BL1(BootROM) and A-BL2 need to be aware of their next stages to load those images properly: BootROM -> BL2 -> BL31 -> ... | v SCP
If the above summary points are valid, then in the case of a shared device, the BL2 should be able to load the next image(s) (either FIP or BL31) from a FAT partition, I suppose.
Regards, Ghennadi
tf-a@lists.trustedfirmware.org
-
Daniel Thompson -
Ghennadi Procopciuc -
Grant Likely -
Manish Badarkhe -
Vincent Stehlé