[PATCH 3/3] common: fdt: hand over original fdt bootargs into board chosen handler

[Simon Glass]

Hi Dmitry,

On Thu, 19 Dec 2024 at 14:42, Dmitry Rokosov
<ddrokosov at salutedevices.com> wrote:
>
> Sometimes, it is necessary to provide an additional bootargs string to
> the kernel command line.
>
> We have a real scenario where one U-Boot blob needs to boot several
> kernel images: the vendor-patched kernel image and the latest upstream
> kernel image. The Amlogic (Meson architecture) tty driver has different
> tty suffixes in these kernels: the vendor uses 'ttySx', while the
> upstream implementation uses 'ttyAMLx'. The initial console setup is
> provided to the kernel using the kernel command line (bootargs). For the
> vendor kernel, we should use 'console=ttyS0,115200', while for the
> upstream kernel, it must be 'console=ttyAML0,115200'. This means we have
> to use different command line strings depending on the kernel version.
>
> To resolve this issue, we cannot use the CMDLINE_EXTEND kernel
> configuration because it is considered legacy and is not supported for
> the arm64 architecture. CMDLINE_EXTEND is outdated primarily because we
> can provide additional command line strings through the
> 'chosen/bootargs' FDT node. However, U-Boot uses this node to inject the
> U-Boot bootargs environment variable content, which results in U-Boot
> silently overriding all data in the 'chosen/bootargs' node. While we do
> have the board_fdt_chosen_bootargs() board hook to address such issues,
> this function lacks any FDT context, such as the original value of the
> 'chosen/bootargs' node.
>
> This patch introduces a read-only (RO) fdt_property argument to
> board_fdt_chosen_bootargs() to share the original 'chosen/bootargs' data
> with the board code. Consequently, the board developer can decide how to
> handle this information for their board setup: whether to drop it or
> merge it with the bootargs environment.
>
> Signed-off-by: Dmitry Rokosov <ddrokosov at salutedevices.com>
> ---
>  boot/fdt_support.c    | 5 +++--
>  include/fdt_support.h | 4 +++-
>  2 files changed, 6 insertions(+), 3 deletions(-)
>

You could look at 'bootflow cmdline' which allows changing individual
parts of the bootargs. It uses library functions which can do
insertion and deletion, etc.

Another longer-term point to make is that there is the concept of 'OS
requests' in VBE. So long as the kernel is packaged in a FIT we could
have an OS-Request property indicating the serial port that it needs.

Anyway, my comments are just some thoughts on how to solve this more generally.

Regards,
Simon