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@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@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!