On Sat, Oct 12, 2024 at 01:45:10AM +0200, Heinrich Schuchardt wrote: > > > Am 12. Oktober 2024 00:54:38 MESZ schrieb Tom Rini <tr...@konsulko.com>: > >On Fri, Oct 11, 2024 at 04:18:07PM -0600, Simon Glass wrote: > > > >[snip] > >> No other subsystem generates ANSI characters when U-Boot starts. Why > >> are we creating this problem in the EFI implementation? > >> > >> So please, I very-much want to have a way to stop this output from > >> being generated, not to filter it afterwards. As above, we should > >> design U-Boot for easy testing, not treat it as a black box. Please do > >> seriously consider this as I believe this is an important testing > >> principle being violated here. > > > >This is, I think, a good point. Outside of user-facing interactive > >code, we don't use ANSI sequences for printing information in > >U-Boot anywhere else. Why are we doing it in the EFI_LOADER code outside > >of personal preference? And, can we just not instead? It does confuse > >matters (as my example showed) when problems do arise. > > Tests should be executable on any U-Boot instance. I see no virtue in a > sandbox only hack.
Right, and I want to know what the particular problematic escape sequences are because right now it does, on hardware, when things fail, put a bunch of un-rendered escape sequences on the console. That's why I was "What's going on?" and not seeing that it was the banner count issue. -- Tom
signature.asc
Description: PGP signature
