[PATCH] efi_loader: Allow disabling ANSI console queries via env variable
Michal Simek
michal.simek at amd.com
Mon Mar 16 08:45:12 CET 2026
Hi Heinrich and Ilias,
On 3/16/26 03:43, Simon Glass wrote:
> Hi,
>
> On Fri, 13 Mar 2026 at 09:50, Michal Simek <michal.simek at amd.com> wrote:
>>
>>
>>
>> On 3/13/26 16:47, Peter Robinson wrote:
>>> On Fri, 13 Mar 2026 at 12:55, Ilias Apalodimas
>>> <ilias.apalodimas at linaro.org> wrote:
>>>>
>>>> Hi Michal
>>>>
>>>> On Tue, 10 Mar 2026 at 15:50, Michal Simek <michal.simek at amd.com> 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 <sjg at chromium.org>
>
> It might also be worth reconsidering this old patch:
>
> https://patchwork.ozlabs.org/project/uboot/patch/20231121113557.800353-5-sjg@chromium.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20240815202424.766778-11-sjg@chromium.org/
> https://patchwork.ozlabs.org/project/uboot/patch/20240902011825.746421-11-sjg@chromium.org/
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/SJ0PR12MB66857BFB90475FE74294CF0482C22@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.
Thanks,
Michal
More information about the U-Boot
mailing list