From: Federico Giovanardi <fede.dev@giovanardi.dev>
To: linux-embedded@vger.kernel.org
Subject: Re: [RFC PATCH 0/1] Add driver for bootstage stash
Date: Fri, 23 May 2025 09:34:09 +0200 [thread overview]
Message-ID: <473a062e4f939bc58a5c0e636569b826@giovanardi.dev> (raw)
In-Reply-To: <PA4PR08MB604681FF6392B25A19926A11ED98A@PA4PR08MB6046.eurprd08.prod.outlook.com>
Hello,
The note about the data format also was my initial thought, by just
copying a C structure we might have issues as soon one party changes it,
and they might not be perfectly aligned.
To avoid inventing yet-another-data-format I've used msgpack in the past
for that (the format
https://github.com/msgpack/msgpack/blob/master/spec.md, not the library
); because the specs are so simple they can be implemented in a few
lines, and it's something with a reference. But I don't have a lot of
experience in upstreaming stuff on the kernel, so I don't know if it
might cause someone to don't be happy. Anyway, I can contribute the
implementation if needed.
Something as simple as an array of fixarray will give extensibility with
only a few bytes of overhead.
Which gets encoded as:
0xdc # lenght 16 bit << array header
# 0xB << 4 | ( array_size & 0xF) << fixarray header ( 3 elements,
simplest case)
# 0xce # time_us
# 0xce # start_us
# 0xc << 4 | strlen(name) # name
/*no flags, no id*/
# 0xB << 4 | ( array_size & 0xF) << fixarray header ( 5 elements
bigger case)
# 0xce # time_us
# 0xce # start_us
# 0xc << 4 | strlen(name) # name
# 0xcc # flags
# 0xcc # id
.. repeat ...
Since the goal is to use that in many different contexts, defining the
fields that we need early is important.
Bye
Federico
> -------------------------
>
> Da: Francesco Valla <francesco@valla.it>
> Inviato: venerdì 23 maggio 2025 00:42
> A: linux-embedded@vger.kernel.org <linux-embedded@vger.kernel.org>
> Oggetto: [RFC PATCH 0/1] Add driver for bootstage stash
>
> Questo messaggio proviene da un mittente esterno: fai attenzione ad
> allegati e link.
>
> Hello,
>
> after the discussion on the "Unified Boot Log" topic during the latest
> Boot Time SIG special meeting [1], I tried to mock up a driver that
> reads a bootstage stash saved by the U-Boot bootloader in a given
> memory
> area and exposes the data in a user- and machine- friendly through
> both
> sysfs and debugfs attributes. Details on the interfaces, as well as
> example output for the debugfs interfaces, can be found on the
> documentation that is part of the patchset.
>
> To use this driver, a memory area shall be reserved inside the Linux
> kernel devicetree as follows (possibly changing the address and the
> size
> of the memory area):
>
> bootstage@a4300000 {
> compatible = "bootstage";
> reg = <0 0xa4300000 0 0x1000>;
> no-map;
> };
>
> At U-Boot side, following configuration shall then be set:
>
> CONFIG_BOOTSTAGE=y
> CONFIG_BOOTSTAGE_STASH_ADDR=0xa4300000
> CONFIG_BOOTSTAGE_STASH_SIZE=0x1000
>
> Once booted, the bootstage data can will be found at:
>
> - /sys/devices/platform/a4300000.bootstage/
> - /sys/kernel/debug/bootstage/a4300000.bootstage/
>
> The device name is purposely part of the sysfs and debugfs paths to
> support multiple bootstage areas, as this _might_ then be used for
> multiple bootstage sources, e.g. bootloaders running on different
> cores inside a SoC with different architectures.
>
> Note that this is not really meant to be integrated as-is, not only
> because it's a single patch including code, documentation and
> devicetree
> bindings, but also because the bootstage stash format itself may need
> to
> be touched up a bit. In particular, fixed data type should probably be
> evaluated for the bootstage record, in order to increase compatibility
> with different data sources.
>
> Comments are of course welcome.
>
> Regards,
>
> Francesco
>
> [1]
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Flinux-embedded%2FMW5PR13MB5632B8FA3279D77F2F9217BBFD9CA%40MW5PR13MB5632.namprd13.prod.outlook.com%2F&data=05%7C02%7Cfederico.giovanardi%40cnh.com%7C68aacb29d80340fc5d3208dd99904415%7C79310fb0d39b486bb77b25f3e0c82a0e%7C0%7C0%7C638835567100175385%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Hrd3rjtJ7sLciUzkFymL7y2agCAMZSAKKF7evt20LQU%3D&reserved=0
> [1]
>
> Francesco Valla (1):
> drivers: misc: add driver for bootstage stash
>
> .../bindings/reserved-memory/bootstage.yaml | 44 +++
> Documentation/misc-devices/bootstage.rst | 53 ++++
> Documentation/misc-devices/index.rst | 1 +
> MAINTAINERS | 7 +
> drivers/misc/Kconfig | 10 +
> drivers/misc/Makefile | 1 +
> drivers/misc/bootstage.c | 292
> ++++++++++++++++++
> drivers/of/platform.c | 1 +
> 8 files changed, 409 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/reserved-memory/bootstage.yaml
> create mode 100644 Documentation/misc-devices/bootstage.rst
> create mode 100644 drivers/misc/bootstage.c
>
> --
> 2.49.0
>
>
>
> Links:
> ------
> [1]
> https://lore.kernel.org/linux-embedded/MW5PR13MB5632B8FA3279D77F2F9217BBFD9CA@MW5PR13MB5632.namprd13.prod.outlook.com/
next prev parent reply other threads:[~2025-05-23 7:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-22 22:42 [RFC PATCH 0/1] Add driver for bootstage stash Francesco Valla
2025-05-22 22:42 ` [PATCH 1/1] drivers: misc: add " Francesco Valla
2025-05-23 6:29 ` Krzysztof Kozlowski
2025-05-23 19:34 ` Rob Landley
2025-05-24 6:16 ` Krzysztof Kozlowski
2025-05-23 19:43 ` Francesco Valla
2025-05-24 6:15 ` Krzysztof Kozlowski
2025-05-23 23:43 ` Bird, Tim
2025-05-24 7:18 ` kernel test robot
2025-05-23 7:04 ` [RFC PATCH 0/1] Add " Geert Uytterhoeven
2025-05-23 20:06 ` Francesco Valla
[not found] ` <PA4PR08MB604681FF6392B25A19926A11ED98A@PA4PR08MB6046.eurprd08.prod.outlook.com>
2025-05-23 7:34 ` Federico Giovanardi [this message]
2025-05-23 19:43 ` Rob Landley
2025-05-23 20:11 ` Francesco Valla
2025-05-24 0:07 ` Bird, Tim
2025-05-24 0:28 ` Bird, Tim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=473a062e4f939bc58a5c0e636569b826@giovanardi.dev \
--to=fede.dev@giovanardi.dev \
--cc=linux-embedded@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).