Boot time logs for Qualcomm secondary boot-loader or XBL can help to
identify different set of information regarding firmware configuration,
SoC boot KPIs. A dedicated region is carved out in the memory map in order
to store this log in the memory.

The objective of this driver is to read the XBL boot log stored in
this memory region post boot-up, and provide an entry in debugfs, which
can be used to read back the logs and print them on to the console.

Further, this log can be parsed to extract different set of information
as required.

For example, one use case can be parsing boot time KPIs to calculate,
 - PBL End time
 - SBL End time
 - UEFI Start/Stop time

Corresponding log contents as captured in /sys/kernel/debug/xbl_log entry
which prints the above counters,

        S -     59378 - PBL, End
        B -     68198 - SBL1, Start
        B -   1308877 - SBL1, End
        UEFI Start     [ 3370]
         - 0x0AF001000 [ 3375] Sec.efi
        UEFI Total : 466 m
        POST Time      [ 3836] OS Loader
         - 0x0ABE10000 [ 3838] LinuxLoader.efi
        Exit EBS        [ 4878] UEFI End

        /* Note - these are few excerpts picked from the complete XBL log
         *        as tested on SA8775p
         */

Ninad Naik (1):
  soc: qcom: Add driver to read secondary bootloader (XBL) log

 drivers/soc/qcom/Kconfig        |  13 +++
 drivers/soc/qcom/Makefile       |   1 +
 drivers/soc/qcom/dump_xbl_log.c | 139 ++++++++++++++++++++++++++++++++
 3 files changed, 153 insertions(+)
 create mode 100644 drivers/soc/qcom/dump_xbl_log.c

-- 
2.41.0

On 8/22/2023 5:45 PM, Ninad Naik wrote:
> Boot time logs for Qualcomm secondary boot-loader or XBL can help to
> identify different set of information regarding firmware configuration,
> SoC boot KPIs. A dedicated region is carved out in the memory map in order
> to store this log in the memory.
> 
> The objective of this driver is to read the XBL boot log stored in
> this memory region post boot-up, and provide an entry in debugfs, which
> can be used to read back the logs and print them on to the console.
> 

I see couple of use cases for this kind of logging like logs from boot, 
Hypervisor, Trusted Execution environments and also one in upstream for 
chromeos EC console. Can this be made a generic driver which take log 
name, log memory buffer address and size to read from debugfs.
> Further, this log can be parsed to extract different set of information
> as required.
> 
> For example, one use case can be parsing boot time KPIs to calculate,
>   - PBL End time
>   - SBL End time
>   - UEFI Start/Stop time
> 
> Corresponding log contents as captured in /sys/kernel/debug/xbl_log entry
> which prints the above counters,
> 
>          S -     59378 - PBL, End
>          B -     68198 - SBL1, Start
>          B -   1308877 - SBL1, End
>          UEFI Start     [ 3370]
>           - 0x0AF001000 [ 3375] Sec.efi
>          UEFI Total : 466 m
>          POST Time      [ 3836] OS Loader
>           - 0x0ABE10000 [ 3838] LinuxLoader.efi
>          Exit EBS        [ 4878] UEFI End
> 
>          /* Note - these are few excerpts picked from the complete XBL log
>           *        as tested on SA8775p
>           */
> 
> Ninad Naik (1):
>    soc: qcom: Add driver to read secondary bootloader (XBL) log
> 
>   drivers/soc/qcom/Kconfig        |  13 +++
>   drivers/soc/qcom/Makefile       |   1 +
>   drivers/soc/qcom/dump_xbl_log.c | 139 ++++++++++++++++++++++++++++++++
>   3 files changed, 153 insertions(+)
>   create mode 100644 drivers/soc/qcom/dump_xbl_log.c
>

On 8/28/2023 10:19 AM, Arun Kumar Neelakantam wrote:
> 
> 
> On 8/22/2023 5:45 PM, Ninad Naik wrote:
>> Boot time logs for Qualcomm secondary boot-loader or XBL can help to
>> identify different set of information regarding firmware configuration,
>> SoC boot KPIs. A dedicated region is carved out in the memory map in order
>> to store this log in the memory.
>>
>> The objective of this driver is to read the XBL boot log stored in
>> this memory region post boot-up, and provide an entry in debugfs, which
>> can be used to read back the logs and print them on to the console.
>>
> 
> I see couple of use cases for this kind of logging like logs from boot, Hypervisor, Trusted Execution environments and also one in upstream for chromeos EC console. Can this be made a generic driver which take log name, log memory buffer address and size to read from debugfs.

The one downside of generic solution here is that log format may not be consistent. Some may have binary format of logs which will need further parsing in kernel or userspace. 

If we need to make such feature generic then it needs to be generic across arm64 / arm32 then and not SOC specific. 


-- 
---Trilok Soni

From: Nikunj Kela <quic_nkela@quicinc.com

I was planning something similar for dumping firmware VM's logs. These are in
ascii format too hence doesn't require any parsing/post processing. Can this
be little generic so I can use this driver?

On 9/12/2023 9:08 AM, Nikunj Kela wrote:
> From: Nikunj Kela <quic_nkela@quicinc.com
> 
> I was planning something similar for dumping firmware VM's logs. These are in
> ascii format too hence doesn't require any parsing/post processing. Can this
> be little generic so I can use this driver?

This is exactly I want to avoid too. The discussion internally lead us to look at the UEFI/EDK2 work done by Alexander Graf [1] and TPM EFI log driver. For EDK2 we should have generic approach coming from the EDK2 and not just SOC vendor specific approaches. 


[1]
https://edk2.groups.io/g/devel/message/90067
https://github.com/agraf/linux/commit/b1fe0c296ec923e9b1f544862b0eb9365a8da7cb

--
---Trilok Soni

On Mon, Aug 28, 2023 at 11:44:08AM -0700, Trilok Soni wrote:
> On 8/28/2023 10:19 AM, Arun Kumar Neelakantam wrote:
> > 
> > 
> > On 8/22/2023 5:45 PM, Ninad Naik wrote:
> >> Boot time logs for Qualcomm secondary boot-loader or XBL can help to
> >> identify different set of information regarding firmware configuration,
> >> SoC boot KPIs. A dedicated region is carved out in the memory map in order
> >> to store this log in the memory.
> >>
> >> The objective of this driver is to read the XBL boot log stored in
> >> this memory region post boot-up, and provide an entry in debugfs, which
> >> can be used to read back the logs and print them on to the console.
> >>
> > 
> > I see couple of use cases for this kind of logging like logs from
> > boot, Hypervisor, Trusted Execution environments and also one in
> > upstream for chromeos EC console. Can this be made a generic driver
> > which take log name, log memory buffer address and size to read from
> > debugfs.
> 
> The one downside of generic solution here is that log format may not
> be consistent. Some may have binary format of logs which will need
> further parsing in kernel or userspace. 
> 
> If we need to make such feature generic then it needs to be generic
> across arm64 / arm32 then and not SOC specific. 
> 

More importantly, it should provide a consistent interface towards the
consumer of the data, so that one wouldn't need a custom app to collect
every type of data.

Regards,
Bjorn