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 > <ddroko...@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 <ddroko...@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
