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

[Dmitry Rokosov]

Hello Simon,

On Tue, Jan 14, 2025 at 06:14:59AM -0700, Simon Glass wrote:
> 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.

Hmm, I wasn't aware of the OS-Request in VBE. I'll delve deeper into VBE
and the 'bootflow cmdline' for our internal board bootflow cases.
Thank you so much for the suggestion!

-- 
Thank you,
Dmitry