[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