On Mon, Mar 16, 2026 at 08:45:12AM +0100, Michal Simek wrote: > Hi Heinrich and Ilias, > > On 3/16/26 03:43, Simon Glass wrote: > > Hi, > > > > On Fri, 13 Mar 2026 at 09:50, Michal Simek <[email protected]> wrote: > > > > > > > > > > > > On 3/13/26 16:47, Peter Robinson wrote: > > > > On Fri, 13 Mar 2026 at 12:55, Ilias Apalodimas > > > > <[email protected]> wrote: > > > > > > > > > > Hi Michal > > > > > > > > > > On Tue, 10 Mar 2026 at 15:50, Michal Simek <[email protected]> > > > > > wrote: > > > > > > > > > > > > Commit 4cb724364030 ("efi_loader: Disable ANSI output for tests") > > > > > > introduced efi_console_set_ansi() to suppress ANSI escape sequences > > > > > > during unit tests. Extend this mechanism to be runtime-configurable > > > > > > via > > > > > > the 'no_ansi' U-Boot environment variable. > > > > > > > > > > > > When 'no_ansi' is set to 'yes', efi_console_set_ansi(false) is > > > > > > called > > > > > > at the start of efi_setup_console_size(). This prevents > > > > > > query_console_serial() from sending ANSI escape sequences to the > > > > > > terminal, using default 25x80 dimensions instead. This is useful for > > > > > > platforms where the serial console cannot handle ANSI queries. > > > > > > > > > > I am fine with the patch, but the no_ansi is a bit misleading reading > > > > > the code. > > > > > It really means don't use ANSI queries to detect the console. So > > > > > before creating an ABI to the cmd line should we really call it > > > > > "no_ansi" or perhaps "no_detect" and in the future clean up the > > > > > variable names as well? > > > > > > > > I wonder whether this should be a Kconfig option too, a maker of a > > > > device likely knows when this is an issue on their device and > > > > explicitly enabling it via a config as opposed to an environment > > > > variable would likely be useful when there's a menu enabled and the > > > > shell possibly disabled? > > > > > > There are a lot of Kconfig options and variable which can aligned it. > > > It means we can create Kconfig option for it but likely we should also > > > have > > > variable way as common way in uboot. > > > > > > > Reviewed-by: Simon Glass <[email protected]> > > > > It might also be worth reconsidering this old patch: > > > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > > https://patchwork.ozlabs.org/project/uboot/patch/[email protected]/ > > We have met with this problem on real HW last year and based on it we > created this internal patch. > https://github.com/Xilinx/u-boot-xlnx/commit/29b1330570543056188e5c065f1ea1be064b3a4b > > And we also send it out > https://lore.kernel.org/all/sj0pr12mb66857bfb90475fe74294cf0482...@sj0pr12mb6685.namprd12.prod.outlook.com/ > > That's why I would like to get clear guidance which way you want to go and > how things should be changed. If you are fine with having variable/Kconfig > symbol to disable it, then I am happy to create a patch for it. > > From my perspective this is unwanted feature and I would like to fix it > clearly to make sure that I don't need to handle that origin one line > incorrect fix in our u-boot tree.
So re-reading your thread from about this time last year, it seems to me there was agreement that yes, a broader re-organization would be good but is a time consuming task that it seems isn't urgent enough for anyone else to pick up, It was also never addressed as to why this fails in the first place, as it should not. And we are generally resistant to making it easy to make our EFI implementation spec-non-compliant. I'll defer to whatever Heinrich and Ilias agree on but there's good reasons we haven't "just" picked up one of the previously suggested patches. -- Tom
signature.asc
Description: PGP signature
