libefi don't use TERM_EMU on arm

[manu]

Summary

Don't use TERM_EMU on arm as it does not work with u-boot efi implementation.

Test Plan

Tested on beaglebone black with u-boot efi implementation.

[andrew]

Can you also do this on aarch64.

[manu]

Add aarch64.

[andrew]

The commit message should say it's disabled on arm/arm64 as it's more likely we will use a serial console there where the terminal emulation doesn't work as well. Come to think of it this should also be in a comment above the .if.

[manu]

In D6783#143542, @andrew wrote:

The commit message should say it's disabled on arm/arm64 as it's more likely we will use a serial console there where the terminal emulation doesn't work as well. Come to think of it this should also be in a comment above the .if.

I'll update the diff soon to include this in the comment.
Is this something that you want commited for 11.0 ?

[brd]

Yes, please for 11 :)

[will]

I don't see how this patch is supposed to work when efi_console.c:CD() requires curx/cury, but is not protected by #ifdef TERM_EMU.

[will]

Never mind, I applied the patch against a slightly older version of head.

[emaste]

Don't use TERM_EMU on arm as it does not work with u-boot efi implementation.

Is it that u-boot EFI just does not implement SetAttribute, ClearScreen etc.?

The commit message should say it's disabled on arm/arm64 as it's more likely we will use a serial console there where the terminal emulation doesn't work as well.

I don't think disabling TERM_EMU in loader.efi is the right way to handle this case; the loader 4th bits shouldn't be using the full screen menus etc. in serial console mode. The TERM_EMU code path should be disabled only if it's not actually implemented.

Anyhow, I think the change is reasonable for now, particularly for ARM.

[andrew]

In D6783#144321, @emaste wrote:

I don't think disabling TERM_EMU in loader.efi is the right way to handle this case; the loader 4th bits shouldn't be using the full screen menus etc. in serial console mode. The TERM_EMU code path should be disabled only if it's not actually implemented.

It's not an issue with the boot menu. The command line also has issues with TERM_EMU.

[emaste]

It's not an issue with the boot menu. The command line also has issues with TERM_EMU.

Ok, we'll need to fix that as well.

Anyway, we should go ahead with this for now, and revisit after 11.0 is out.
@manu, how does it fail on u-boot EFI? Can we check for NULL SetAttribute etc.?

[manu]

In D6783#144336, @emaste wrote:

It's not an issue with the boot menu. The command line also has issues with TERM_EMU.

Ok, we'll need to fix that as well.

Anyway, we should go ahead with this for now, and revisit after 11.0 is out.
@manu, how does it fail on u-boot EFI? Can we check for NULL SetAttribute etc.?

Sorry I've been delayed by other stuff :)
So with U-Boot the output is just garbage.
We could refactor the code to not have TERM_EMU at all and just handle things at runtime by checking SetAttribute return value I guess.
I U-Boot SetAttribute exist, it just returns EFI_NOT_SUPPORTED.
Now that the 11 switch is almost over and that I have every bits needed to make u-boot->boot1.efi->loader.efi->kernel working, I'm not in a hurry to make loader.efi works with U-Boot so probably close this revision soon after I have everything in better shape.

[andrew]

You should commit this