Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot. Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is "When firmware should erase or delete bert records from non-volatile memory"?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory. But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware? Can generic SMC call from Kernel to firmware be a solution? Any other suggestion?
Thanks
Regards, Jaiprakash
Hi,
In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6?
-Varun
From: Jaiprakash Singh jaiprakashs@marvell.com Date: Tuesday, 17 March 2026 at 10:26 To: tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org, Manish Pandey manish.pandey2@arm.com Cc: Varun Wadekar vwadekar@nvidia.com, George Cherian gcherian@marvell.com, Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: BERT Record Erase Only After Kernel Consumes
You don't often get email from jaiprakashs@marvell.com. Learn why this is importanthttps://aka.ms/LearnAboutSenderIdentification External email: Use caution opening links or attachments
Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot. Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is “When firmware should erase or delete bert records from non-volatile memory”?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory. But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware? Can generic SMC call from Kernel to firmware be a solution? Any other suggestion?
Thanks
Regards, Jaiprakash
Hi Varun,
Yes, that’s possible.
But if firmware deletes Bert records from non-volatile memory before Kernel boots, there is a possibility that Kernel gets crash even before it can dump bert records and bert records will be lost forever.
Proper solution would be – Kernel let firmware know that it has consumed bert or in some other way firmware can confirm that Kernel is booted till prompt and now it is safe to delete all bert records.
Thanks
Regards, Jaiprakash
From: Varun Wadekar vwadekar@nvidia.com Sent: Tuesday, March 17, 2026 10:18 PM To: Jaiprakash Singh jaiprakashs@marvell.com; tf-a@lists.trustedfirmware.org; Manish Pandey manish.pandey2@arm.com Cc: George Cherian gcherian@marvell.com; Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: [EXTERNAL] Re: BERT Record Erase Only After Kernel Consumes
Hi, In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6? -Varun From: Jaiprakash Singh <jaiprakashs@ marvell. com> Date: Tuesday, 17 March 2026 at 10: 26 To: ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!uq3XGZ_4rnsUuiHyGP00LrjAUK815a_yzvENdn41oDuqQ5gTDQQCJPKfQ29Iy2Ocz756SeisftJOPM9UgGpHHkfzLVKA82ifAK8YajPvWIZKJ2zno5snEAOtLkp584PPDRMm_r11Wxx1ibpnQqA$ ZjQcmQRYFpfptBannerEnd Hi,
In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6?
-Varun
From: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com> Date: Tuesday, 17 March 2026 at 10:26 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>, Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>, George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>, Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: BERT Record Erase Only After Kernel Consumes You don't often get email from jaiprakashs@marvell.commailto:jaiprakashs@marvell.com. Learn why this is importanthttps://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_LearnAboutSenderIdentification&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=QWd9tGUeeYV7m6YUDocvBXWB4Z1ufj2tqyn5CF4LN5Z3R5Yi9PQ3sjuVT1bhSZsk&s=945qbPnXTeGe13JZDinzHzPR5UICKWtE8xHbDbf03yI&e=
External email: Use caution opening links or attachments
Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot. Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is “When firmware should erase or delete bert records from non-volatile memory”?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory. But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware? Can generic SMC call from Kernel to firmware be a solution? Any other suggestion?
Thanks
Regards, Jaiprakash
Hi Jaiprakash
The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed.
Is this the handshake you are after?
Regards, Jose
[1] https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#platform-wide-o...
From: Jaiprakash Singh via TF-A tf-a@lists.trustedfirmware.org Sent: Wednesday, March 18, 2026 4:09 AM To: Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org; Manish Pandey2 Manish.Pandey2@arm.com Cc: George Cherian gcherian@marvell.com; Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: [TF-A] Re: BERT Record Erase Only After Kernel Consumes
Hi Varun,
Yes, that’s possible.
But if firmware deletes Bert records from non-volatile memory before Kernel boots, there is a possibility that Kernel gets crash even before it can dump bert records and bert records will be lost forever.
Proper solution would be – Kernel let firmware know that it has consumed bert or in some other way firmware can confirm that Kernel is booted till prompt and now it is safe to delete all bert records.
Thanks
Regards, Jaiprakash
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Sent: Tuesday, March 17, 2026 10:18 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] Re: BERT Record Erase Only After Kernel Consumes
Hi, In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6? -Varun From: Jaiprakash Singh <jaiprakashs@ marvell. com> Date: Tuesday, 17 March 2026 at 10: 26 To: ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!uq3XGZ_4rnsUuiHyGP00LrjAUK815a_yzvENdn41oDuqQ5gTDQQCJPKfQ29Iy2Ocz756SeisftJOPM9UgGpHHkfzLVKA82ifAK8YajPvWIZKJ2zno5snEAOtLkp584PPDRMm_r11Wxx1ibpnQqA$ ZjQcmQRYFpfptBannerEnd Hi,
In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6?
-Varun
From: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com> Date: Tuesday, 17 March 2026 at 10:26 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>, Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>, George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>, Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: BERT Record Erase Only After Kernel Consumes You don't often get email from jaiprakashs@marvell.commailto:jaiprakashs@marvell.com. Learn why this is importanthttps://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_LearnAboutSenderIdentification&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=QWd9tGUeeYV7m6YUDocvBXWB4Z1ufj2tqyn5CF4LN5Z3R5Yi9PQ3sjuVT1bhSZsk&s=945qbPnXTeGe13JZDinzHzPR5UICKWtE8xHbDbf03yI&e=
External email: Use caution opening links or attachments
Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot. Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is “When firmware should erase or delete bert records from non-volatile memory”?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory. But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware? Can generic SMC call from Kernel to firmware be a solution? Any other suggestion?
Thanks
Regards, Jaiprakash
Hi Jose,
Thanks for reply.
Can you share more details? How and when OSPM can share _OSC flag with firmware?
Thanks
Regards, Jaiprakash
From: Jose Marinho Jose.Marinho@arm.com Sent: Wednesday, March 18, 2026 2:23 PM To: Jaiprakash Singh jaiprakashs@marvell.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org; Manish Pandey2 Manish.Pandey2@arm.com Cc: George Cherian gcherian@marvell.com; Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: [EXTERNAL] RE: BERT Record Erase Only After Kernel Consumes
Hi Jaiprakash The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed. Is this the handshake you are after? Regards, Jose [1] https: //uefi. org/specs/ACPI/6. 6/06_Device_Configuration. html#platform-wide-osc-capabilities-dword-2 ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!ui3XG754rjXb-6H9uT0aDkvSRZ_RyOVrpNZ-4vVg040_uCoFl0xnaM-phq1_xDd_1D8Xl9_Ipr3I2Yh4ZEaN6fYdoYmK-MRLjryzSWl-sz2wbriWnBaFiLQ4bKRN0HFpbyOFqV7LX1AEWQ$ ZjQcmQRYFpfptBannerEnd Hi Jaiprakash
The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed.
Is this the handshake you are after?
Regards, Jose
[1] https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#platform-wide-o...https://urldefense.proofpoint.com/v2/url?u=https-3A__uefi.org_specs_ACPI_6.6_06-5FDevice-5FConfiguration.html-23platform-2Dwide-2Dosc-2Dcapabilities-2Ddword-2D2&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=h6dI7AypK-PICWgBWy30w0lgKDbfn7PMY8mc6z__5YIdcn3OwENygJsOtAm2PZIz&s=25t-iwRfVT2Czi-qZadVDppusanUDVz4QkI6f2AN-0U&e=
From: Jaiprakash Singh via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Sent: Wednesday, March 18, 2026 4:09 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [TF-A] Re: BERT Record Erase Only After Kernel Consumes
Hi Varun,
Yes, that’s possible.
But if firmware deletes Bert records from non-volatile memory before Kernel boots, there is a possibility that Kernel gets crash even before it can dump bert records and bert records will be lost forever.
Proper solution would be – Kernel let firmware know that it has consumed bert or in some other way firmware can confirm that Kernel is booted till prompt and now it is safe to delete all bert records.
Thanks
Regards, Jaiprakash
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Sent: Tuesday, March 17, 2026 10:18 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] Re: BERT Record Erase Only After Kernel Consumes
Hi, In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6? -Varun From: Jaiprakash Singh <jaiprakashs@ marvell. com> Date: Tuesday, 17 March 2026 at 10: 26 To: ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!uq3XGZ_4rnsUuiHyGP00LrjAUK815a_yzvENdn41oDuqQ5gTDQQCJPKfQ29Iy2Ocz756SeisftJOPM9UgGpHHkfzLVKA82ifAK8YajPvWIZKJ2zno5snEAOtLkp584PPDRMm_r11Wxx1ibpnQqA$ ZjQcmQRYFpfptBannerEnd Hi,
In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6?
-Varun
From: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com> Date: Tuesday, 17 March 2026 at 10:26 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>, Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>, George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>, Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: BERT Record Erase Only After Kernel Consumes You don't often get email from jaiprakashs@marvell.commailto:jaiprakashs@marvell.com. Learn why this is importanthttps://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_LearnAboutSenderIdentification&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=QWd9tGUeeYV7m6YUDocvBXWB4Z1ufj2tqyn5CF4LN5Z3R5Yi9PQ3sjuVT1bhSZsk&s=945qbPnXTeGe13JZDinzHzPR5UICKWtE8xHbDbf03yI&e=
External email: Use caution opening links or attachments
Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot. Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is “When firmware should erase or delete bert records from non-volatile memory”?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory. But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware? Can generic SMC call from Kernel to firmware be a solution? Any other suggestion?
Thanks
Regards, Jaiprakash
Hi,
Can you share more details? How and when OSPM can share _OSC flag with firmware?
I believe this may vary across operating systems.
For Linux, the APEI _OSC bit is set here [1]. The actual _OSC method call happens in acpi_osc_handshake(). On ACPI platforms, that bit just depends on CONFIG_ACPI_APEI_GHES being enabled.
Regards, Jose
[1] https://github.com/torvalds/linux/blob/master/drivers/acpi/bus.c#L489
From: Jaiprakash Singh jaiprakashs@marvell.com Sent: Wednesday, March 18, 2026 10:17 AM To: Jose Marinho Jose.Marinho@arm.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org; Manish Pandey2 Manish.Pandey2@arm.com Cc: George Cherian gcherian@marvell.com; Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: RE: BERT Record Erase Only After Kernel Consumes
Hi Jose,
Thanks for reply.
Can you share more details? How and when OSPM can share _OSC flag with firmware?
Thanks
Regards, Jaiprakash
From: Jose Marinho <Jose.Marinho@arm.commailto:Jose.Marinho@arm.com> Sent: Wednesday, March 18, 2026 2:23 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] RE: BERT Record Erase Only After Kernel Consumes
Hi Jaiprakash The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed. Is this the handshake you are after? Regards, Jose [1] https: //uefi. org/specs/ACPI/6. 6/06_Device_Configuration. html#platform-wide-osc-capabilities-dword-2 ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!ui3XG754rjXb-6H9uT0aDkvSRZ_RyOVrpNZ-4vVg040_uCoFl0xnaM-phq1_xDd_1D8Xl9_Ipr3I2Yh4ZEaN6fYdoYmK-MRLjryzSWl-sz2wbriWnBaFiLQ4bKRN0HFpbyOFqV7LX1AEWQ$ ZjQcmQRYFpfptBannerEnd Hi Jaiprakash
The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed.
Is this the handshake you are after?
Regards, Jose
[1] https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#platform-wide-o...https://urldefense.proofpoint.com/v2/url?u=https-3A__uefi.org_specs_ACPI_6.6_06-5FDevice-5FConfiguration.html-23platform-2Dwide-2Dosc-2Dcapabilities-2Ddword-2D2&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=h6dI7AypK-PICWgBWy30w0lgKDbfn7PMY8mc6z__5YIdcn3OwENygJsOtAm2PZIz&s=25t-iwRfVT2Czi-qZadVDppusanUDVz4QkI6f2AN-0U&e=
From: Jaiprakash Singh via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Sent: Wednesday, March 18, 2026 4:09 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [TF-A] Re: BERT Record Erase Only After Kernel Consumes
Hi Varun,
Yes, that’s possible.
But if firmware deletes Bert records from non-volatile memory before Kernel boots, there is a possibility that Kernel gets crash even before it can dump bert records and bert records will be lost forever.
Proper solution would be – Kernel let firmware know that it has consumed bert or in some other way firmware can confirm that Kernel is booted till prompt and now it is safe to delete all bert records.
Thanks
Regards, Jaiprakash
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Sent: Tuesday, March 17, 2026 10:18 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] Re: BERT Record Erase Only After Kernel Consumes
Hi, In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6? -Varun From: Jaiprakash Singh <jaiprakashs@ marvell. com> Date: Tuesday, 17 March 2026 at 10: 26 To: ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicious https://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!uq3XGZ_4rnsUuiHyGP00LrjAUK815a_yzvENdn41oDuqQ5gTDQQCJPKfQ29Iy2Ocz756SeisftJOPM9UgGpHHkfzLVKA82ifAK8YajPvWIZKJ2zno5snEAOtLkp584PPDRMm_r11Wxx1ibpnQqA$ ZjQcmQRYFpfptBannerEnd Hi,
In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6?
-Varun
From: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com> Date: Tuesday, 17 March 2026 at 10:26 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>, Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>, George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>, Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: BERT Record Erase Only After Kernel Consumes You don't often get email from jaiprakashs@marvell.commailto:jaiprakashs@marvell.com. Learn why this is importanthttps://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_LearnAboutSenderIdentification&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=QWd9tGUeeYV7m6YUDocvBXWB4Z1ufj2tqyn5CF4LN5Z3R5Yi9PQ3sjuVT1bhSZsk&s=945qbPnXTeGe13JZDinzHzPR5UICKWtE8xHbDbf03yI&e=
External email: Use caution opening links or attachments
Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot. Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is “When firmware should erase or delete bert records from non-volatile memory”?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory. But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware? Can generic SMC call from Kernel to firmware be a solution? Any other suggestion?
Thanks
Regards, Jaiprakash
Hi Jose,
Doesn't the _OSC method tell whether the GHES is enabled on the running kernel? But in Jaiprakash case he would need a notification till TF-A so that he can remove the stored BERT records from the persistent storage.
Regards, -George
________________________________ From: Jose Marinho Jose.Marinho@arm.com Sent: Wednesday, March 18, 2026 16:26 To: Jaiprakash Singh jaiprakashs@marvell.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org tf-a@lists.trustedfirmware.org; Manish Pandey2 Manish.Pandey2@arm.com Cc: George Cherian gcherian@marvell.com; Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: [EXTERNAL] RE: BERT Record Erase Only After Kernel Consumes
Hi, > Can you share more details? How and when OSPM can share _OSC flag with firmware? I believe this may vary across operating systems. For Linux, the APEI _OSC bit is set here [1]. The actual _OSC method call happens in acpi_osc_handshake(). ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicioushttps://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!ui3XG754rjXb-6H9uT0aAGKcVQv1WzPVowE00SYrZB_wPy4dZ3Y3BhnNUEZGZBHxmHJMNJMfKgYVUu1zzuep-M7s7JOElajXjPVzWQCO8N45aODxCPAAV0gH0kuPg6wp34f93usjiE8$
ZjQcmQRYFpfptBannerEnd
Hi,
Can you share more details? How and when OSPM can share _OSC flag with firmware?
I believe this may vary across operating systems.
For Linux, the APEI _OSC bit is set here [1]. The actual _OSC method call happens in acpi_osc_handshake().
On ACPI platforms, that bit just depends on CONFIG_ACPI_APEI_GHES being enabled.
Regards, Jose
[1] https://github.com/torvalds/linux/blob/master/drivers/acpi/bus.c#L489https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux_blob_master_drivers_acpi_bus.c-23L489&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=npgTSgHrUSLmXpBZJKVhk0lE_XNvtVDl8ZA2zBvBqPw&m=_ovVjcgoz8k_ib1eit_G3WArggNy1F11_-gU_ZsusBPzeE64F_egp3qdZbpFfvni&s=QQAMRFSy9pU69cbBxJZfq8Emxv3GTTtKB5S4BPbPRLg&e=
From: Jaiprakash Singh jaiprakashs@marvell.com Sent: Wednesday, March 18, 2026 10:17 AM To: Jose Marinho Jose.Marinho@arm.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org; Manish Pandey2 Manish.Pandey2@arm.com Cc: George Cherian gcherian@marvell.com; Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: RE: BERT Record Erase Only After Kernel Consumes
Hi Jose,
Thanks for reply.
Can you share more details? How and when OSPM can share _OSC flag with firmware?
Thanks
Regards,
Jaiprakash
From: Jose Marinho <Jose.Marinho@arm.commailto:Jose.Marinho@arm.com> Sent: Wednesday, March 18, 2026 2:23 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] RE: BERT Record Erase Only After Kernel Consumes
Hi Jaiprakash The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed. Is this the handshake you are after? Regards, Jose [1] https: //uefi. org/specs/ACPI/6. 6/06_Device_Configuration. html#platform-wide-osc-capabilities-dword-2
ZjQcmQRYFpfptBannerStart
Prioritize security for external emails:
Confirm sender and content safety before clicking links or opening attachments
ZjQcmQRYFpfptBannerEnd
Hi Jaiprakash
The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed.
Is this the handshake you are after?
Regards,
Jose
[1] https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#platform-wide-o...https://urldefense.proofpoint.com/v2/url?u=https-3A__uefi.org_specs_ACPI_6.6_06-5FDevice-5FConfiguration.html-23platform-2Dwide-2Dosc-2Dcapabilities-2Ddword-2D2&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=h6dI7AypK-PICWgBWy30w0lgKDbfn7PMY8mc6z__5YIdcn3OwENygJsOtAm2PZIz&s=25t-iwRfVT2Czi-qZadVDppusanUDVz4QkI6f2AN-0U&e=
From: Jaiprakash Singh via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Sent: Wednesday, March 18, 2026 4:09 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [TF-A] Re: BERT Record Erase Only After Kernel Consumes
Hi Varun,
Yes, that’s possible.
But if firmware deletes Bert records from non-volatile memory before Kernel boots, there is a possibility
that Kernel gets crash even before it can dump bert records and bert records will be lost forever.
Proper solution would be – Kernel let firmware know that it has consumed bert or in some other way
firmware can confirm that Kernel is booted till prompt and now it is safe to delete all bert records.
Thanks
Regards,
Jaiprakash
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Sent: Tuesday, March 17, 2026 10:18 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] Re: BERT Record Erase Only After Kernel Consumes
Hi, In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6? -Varun From: Jaiprakash Singh <jaiprakashs@ marvell. com> Date: Tuesday, 17 March 2026 at 10: 26 To:
ZjQcmQRYFpfptBannerStart
Prioritize security for external emails:
Confirm sender and content safety before clicking links or opening attachments
ZjQcmQRYFpfptBannerEnd
Hi,
In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6?
-Varun
From: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com> Date: Tuesday, 17 March 2026 at 10:26 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>, Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>, George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>, Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: BERT Record Erase Only After Kernel Consumes
You don't often get email from jaiprakashs@marvell.commailto:jaiprakashs@marvell.com. Learn why this is importanthttps://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_LearnAboutSenderIdentification&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=QWd9tGUeeYV7m6YUDocvBXWB4Z1ufj2tqyn5CF4LN5Z3R5Yi9PQ3sjuVT1bhSZsk&s=945qbPnXTeGe13JZDinzHzPR5UICKWtE8xHbDbf03yI&e=
External email: Use caution opening links or attachments
Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot.
Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is “When firmware should erase or delete bert records from non-volatile memory”?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory.
But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware?
Can generic SMC call from Kernel to firmware be a solution?
Any other suggestion?
Thanks
Regards,
Jaiprakash
Hi George,
Doesn't the _OSC method tell whether the GHES is enabled on the running kernel?
The ACPI spec defines the APEI _OSC bit as: “This bit is set if OSPM supports the ACPI Platform Error Interfaces. “ On the _OSC implementation further platform-specific actions can be taken.
Note that the intent was to simply point out the existence of _OSC APEI, but understand if it cannot be easily leveraged.
Regards, Jose
From: George Cherian gcherian@marvell.com Sent: Wednesday, March 18, 2026 1:30 PM To: Jose Marinho Jose.Marinho@arm.com; Jaiprakash Singh jaiprakashs@marvell.com; Varun Wadekar vwadekar@nvidia.com; tf-a@lists.trustedfirmware.org; Manish Pandey2 Manish.Pandey2@arm.com Cc: Ashwin Kumar Sundararamakrishnan asundararama@marvell.com Subject: Re: BERT Record Erase Only After Kernel Consumes
Hi Jose,
Doesn't the _OSC method tell whether the GHES is enabled on the running kernel? But in Jaiprakash case he would need a notification till TF-A so that he can remove the stored BERT records from the persistent storage.
Regards, -George
________________________________ From: Jose Marinho <Jose.Marinho@arm.commailto:Jose.Marinho@arm.com> Sent: Wednesday, March 18, 2026 16:26 To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] RE: BERT Record Erase Only After Kernel Consumes
Hi, > Can you share more details? How and when OSPM can share _OSC flag with firmware? I believe this may vary across operating systems. For Linux, the APEI _OSC bit is set here [1]. The actual _OSC method call happens in acpi_osc_handshake(). ZjQcmQRYFpfptBannerStart Prioritize security for external emails: Confirm sender and content safety before clicking links or opening attachments Report Suspicioushttps://us-phishalarm-ewt.proofpoint.com/EWT/v1/CRVmXkqW!ui3XG754rjXb-6H9uT0aAGKcVQv1WzPVowE00SYrZB_wPy4dZ3Y3BhnNUEZGZBHxmHJMNJMfKgYVUu1zzuep-M7s7JOElajXjPVzWQCO8N45aODxCPAAV0gH0kuPg6wp34f93usjiE8$
ZjQcmQRYFpfptBannerEnd
Hi,
Can you share more details? How and when OSPM can share _OSC flag with firmware?
I believe this may vary across operating systems.
For Linux, the APEI _OSC bit is set here [1]. The actual _OSC method call happens in acpi_osc_handshake().
On ACPI platforms, that bit just depends on CONFIG_ACPI_APEI_GHES being enabled.
Regards, Jose
[1] https://github.com/torvalds/linux/blob/master/drivers/acpi/bus.c#L489https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_torvalds_linux_blob_master_drivers_acpi_bus.c-23L489&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=npgTSgHrUSLmXpBZJKVhk0lE_XNvtVDl8ZA2zBvBqPw&m=_ovVjcgoz8k_ib1eit_G3WArggNy1F11_-gU_ZsusBPzeE64F_egp3qdZbpFfvni&s=QQAMRFSy9pU69cbBxJZfq8Emxv3GTTtKB5S4BPbPRLg&e=
From: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com> Sent: Wednesday, March 18, 2026 10:17 AM To: Jose Marinho <Jose.Marinho@arm.commailto:Jose.Marinho@arm.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: RE: BERT Record Erase Only After Kernel Consumes
Hi Jose,
Thanks for reply.
Can you share more details? How and when OSPM can share _OSC flag with firmware?
Thanks
Regards,
Jaiprakash
From: Jose Marinho <Jose.Marinho@arm.commailto:Jose.Marinho@arm.com> Sent: Wednesday, March 18, 2026 2:23 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] RE: BERT Record Erase Only After Kernel Consumes
Hi Jaiprakash The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed. Is this the handshake you are after? Regards, Jose [1] https: //uefi. org/specs/ACPI/6. 6/06_Device_Configuration. html#platform-wide-osc-capabilities-dword-2
ZjQcmQRYFpfptBannerStart
Prioritize security for external emails:
Confirm sender and content safety before clicking links or opening attachments
ZjQcmQRYFpfptBannerEnd
Hi Jaiprakash
The OS tells firmware it will consume BERT by setting the APEI bit in the _OSC [1]. The platform firmware can propagate this signal where needed.
Is this the handshake you are after?
Regards,
Jose
[1] https://uefi.org/specs/ACPI/6.6/06_Device_Configuration.html#platform-wide-o...https://urldefense.proofpoint.com/v2/url?u=https-3A__uefi.org_specs_ACPI_6.6_06-5FDevice-5FConfiguration.html-23platform-2Dwide-2Dosc-2Dcapabilities-2Ddword-2D2&d=DwMGaQ&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=h6dI7AypK-PICWgBWy30w0lgKDbfn7PMY8mc6z__5YIdcn3OwENygJsOtAm2PZIz&s=25t-iwRfVT2Czi-qZadVDppusanUDVz4QkI6f2AN-0U&e=
From: Jaiprakash Singh via TF-A <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org> Sent: Wednesday, March 18, 2026 4:09 AM To: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey2 <Manish.Pandey2@arm.commailto:Manish.Pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [TF-A] Re: BERT Record Erase Only After Kernel Consumes
Hi Varun,
Yes, that’s possible.
But if firmware deletes Bert records from non-volatile memory before Kernel boots, there is a possibility
that Kernel gets crash even before it can dump bert records and bert records will be lost forever.
Proper solution would be – Kernel let firmware know that it has consumed bert or in some other way
firmware can confirm that Kernel is booted till prompt and now it is safe to delete all bert records.
Thanks
Regards,
Jaiprakash
From: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com> Sent: Tuesday, March 17, 2026 10:18 PM To: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com>; tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org; Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>; Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: [EXTERNAL] Re: BERT Record Erase Only After Kernel Consumes
Hi, In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6? -Varun From: Jaiprakash Singh <jaiprakashs@ marvell. com> Date: Tuesday, 17 March 2026 at 10: 26 To:
ZjQcmQRYFpfptBannerStart
Prioritize security for external emails:
Confirm sender and content safety before clicking links or opening attachments
ZjQcmQRYFpfptBannerEnd
Hi,
In this sequence, is it possible for firmware to delete the non-volatile memory contents after copying to GHES DRAM buffer in step 6?
-Varun
From: Jaiprakash Singh <jaiprakashs@marvell.commailto:jaiprakashs@marvell.com> Date: Tuesday, 17 March 2026 at 10:26 To: tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org <tf-a@lists.trustedfirmware.orgmailto:tf-a@lists.trustedfirmware.org>, Manish Pandey <manish.pandey2@arm.commailto:manish.pandey2@arm.com> Cc: Varun Wadekar <vwadekar@nvidia.commailto:vwadekar@nvidia.com>, George Cherian <gcherian@marvell.commailto:gcherian@marvell.com>, Ashwin Kumar Sundararamakrishnan <asundararama@marvell.commailto:asundararama@marvell.com> Subject: BERT Record Erase Only After Kernel Consumes
You don't often get email from jaiprakashs@marvell.commailto:jaiprakashs@marvell.com. Learn why this is importanthttps://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_LearnAboutSenderIdentification&d=DwMF-g&c=nKjWec2b6R0mOyPaz7xtfQ&r=oC3FSC8uKqkQZthB7ZhljxVkk_bnBa8SpNx7QV21n9Y&m=QWd9tGUeeYV7m6YUDocvBXWB4Z1ufj2tqyn5CF4LN5Z3R5Yi9PQ3sjuVT1bhSZsk&s=945qbPnXTeGe13JZDinzHzPR5UICKWtE8xHbDbf03yI&e=
External email: Use caution opening links or attachments
Hi All,
BERT (Boot Error Record Table) captures errors which occurred in previous boot.
Below is the Flow with FFH (firmware first handling)
1. Kernel is running 2. Fatal error happens, which requires reboot 3. Firmware decides to reboot system, before that capture current snapshot and save it as bert record on non-volatile memory 4. System reboot 5. On next boot, firmware read bert record from non-volatile memory 6. Copy bert record to ghes dram buffer 7. Kernel boots 8. Kernel reads ghes dram buffer and prints bert record.
Problem in this flow is “When firmware should erase or delete bert records from non-volatile memory”?
Ideally, when Kernel has consumed Bert record after that only firmware should erase them from non-volatile memory.
But there is no communication from Kernel to firmware that it has consume bert record and now it is safe to erase them.
Is there already a solution for this problem available in Kernel or firmware?
Can generic SMC call from Kernel to firmware be a solution?
Any other suggestion?
Thanks
Regards,
Jaiprakash
tf-a@lists.trustedfirmware.org
-
George Cherian -
Jaiprakash Singh -
Jose Marinho -
Varun Wadekar