Page MenuHomeFreeBSD
Differential D52494

loader: simplify efi_cons_poll()
Needs ReviewPublic
Actions

Authored by tsoome on Thu, Sep 11, 8:24 PM.
Tags
None
Referenced Files
F131697266: D52494.diff
Fri, Oct 10, 10:37 AM
F131666186: D52494.diff
Fri, Oct 10, 4:20 AM
F131651015: D52494.id.diff
Fri, Oct 10, 1:31 AM
Unknown Object (File)
Wed, Oct 8, 2:54 AM
Unknown Object (File)
Tue, Oct 7, 12:10 PM
Unknown Object (File)
Fri, Oct 3, 11:53 AM
Unknown Object (File)
Fri, Oct 3, 7:17 AM
Unknown Object (File)
Thu, Oct 2, 2:19 PM
View All 18 Files
Subscribers
bcran
dab
imp

Details

Reviewers
manu
Summary

EFI_SIMPLE_TEXT_INPUT_PROTOCOL.ReadKeyStroke() does return
with EFI_NOT_READY error if there is no pending keystroke.

And the same is true with
EFI_SIMPLE_TEXT_INPUT_PROTOCOL.ReadKeyStrokeEx().

12.2.3 EFI_SIMPLE_TEXT_INPUT_PROTOCOL.ReadKeyStrokeEx()
UEFI_Spec_Final_2.11.pdf, page 405
12.3.3 EFI_SIMPLE_TEXT_INPUT_PROTOCOL.ReadKeyStroke()
UEFI_Spec_Final_2.11.pdf, page 411

This means, we can use just those functions in efi_cons_poll(),
and if there was key stroke, record it in our local key buffer.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 66981
Build 63864: arc lint + arc unit

Event Timeline

tsoome created this revision.Thu, Sep 11, 8:24 PM
Herald added a reviewer: manu. · View Herald TranscriptThu, Sep 11, 8:24 PM
Herald added subscribers: dab, bcran, imp. · View Herald Transcript
tsoome requested review of this revision.Thu, Sep 11, 8:24 PM
Harbormaster completed remote builds in B66981: Diff 161929.Thu, Sep 11, 8:24 PM
imp added a comment.Thu, Sep 11, 10:41 PM

So does this work with our arm64 boards that use a u-boot provied EFI image? The comment are for this case, though we really only care about the last u-boot or two, not ancient history.
And will this eat CPU? We've had issues in the past where the boot loader would end up in a tight loop. What assurances are that that this won't happen?

manu added a comment.Fri, Sep 12, 5:43 AM
In D52494#1198878, @imp wrote:

So does this work with our arm64 boards that use a u-boot provied EFI image? The comment are for this case, though we really only care about the last u-boot or two, not ancient history.

Should be ok, u-boot seems to have waitforkey for quite some times now https://github.com/u-boot/u-boot/blob/master/lib/efi_loader/efi_console.c#L1345

And will this eat CPU? We've had issues in the past where the boot loader would end up in a tight loop. What assurances are that that this won't happen?

tsoome added a comment.Fri, Sep 12, 7:00 AM
In D52494#1198878, @imp wrote:

So does this work with our arm64 boards that use a u-boot provied EFI image? The comment are for this case, though we really only care about the last u-boot or two, not ancient history.
And will this eat CPU? We've had issues in the past where the boot loader would end up in a tight loop. What assurances are that that this won't happen?

hm, I do not think its a problem with uboot because we are not using WaitForKey(), I still need to check about CPU burn; This change has a bit deeper background and *if* at all, should probably land with followup, but I wanted to collect other opinions and reminders first - the CPU burn issue is something I did forgot about.

Revision Contents
Changeset List

PathSize
stand/
efi/
libefi/
29 lines

Diff 161929

View Options

stand/efi/libefi/efi_console.c

Loading...