Hi Dmitry, On Thu, 19 Dec 2024 at 14:42, Dmitry Rokosov <[email protected]> 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 <[email protected]> > --- > 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
