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?

preallocate buffer space for exit message.
factor out framebuffer cleanup.
we do not really return from efi_main.

thanks!

TBH, I would like to see whole loader being built with -Wall (and -Wextra;)

If you do not mind to do extra work, the function is supposed to return 0 or error code, could you replace the return(1) lines above with return (efi_status_to_errno(status)) or like:)

Good catch:)

The problem is, we do not really know exact blast zone. While preparing the possible work around, the font file is still there and can be scripted to be used with loadfont command.

Thanks.

one option is to leave font file in place but remove from INDEX. This way it is still possible to load it manually for those who want to use it, but it will not picked automatically.

thanks!

I think, it was used there just to verify the fact.

use ASHIFT_UBERBLOCK_SIZE().

In D7600#1184549, @imp wrote:

Not sure this is a good idea, not sure it isn't. Tagging for review by srcmgr unless original author thinks it should be abandoned.

use DEBUG_PRINTF.

few leftovers.

The testing (before and after patch) is posted on https://www.illumos.org/issues/15577

style fixes per review.

In D51593#1178387, @markj wrote:

Could you please describe the problematic scenario? I'd like to add a regression test for it.

Thanks!

In D50258#1147236, @adrian wrote:

This looks fine to me. Did you try it locally?

In D50258#1146493, @monwarez_mailoo.org wrote:

What happen if the reported size is plainly wrong ?
Like on my system, at the loader phase my screen is 800x600, and after the kms driver is loaded it goes to higher dimension: 1080p, 1440p.
Does the smallest font will work in this case ? Or there will be no font selected ?

Need to get confirmation from hw owners tho.

In D49077#1120387, @imp wrote:

I thought that we checked for raw because we couldn't guarantee that all other implementations had the right pre-req to allow this safely.
I remember getting burned by something similar because we weren't completely consistent... Maybe f->f_dev isn't always set? It's been a while.

In D49073#1119536, @jkim wrote:

I tried gop blt off on my old laptop and it worked there. Surprisingly, gop blt off case is significantly *slower* than gop blt on case.

In D49073#1119425, @kenrap_kennethraplee.com wrote:

I'm having this same problem with the GOP Blt rendering the framebuffer at my monitor's 4K resolution. It makes rendering to the next part of the loader crawl very slowly against my screen at a row-by-row basis.

I took a video recording and uploaded on Streamable to show as an example (skip to 26s to see it finally process the "2nd" row):

https://streamable.com/nj4mkb

At that speed, I feel it'll likely take 2 hours or more to get to the full rendering of the menu before I can hit enter to load the kernel.

I should note that not all graphics cards I've used on my system have this problem. Since I recently started using an RX 7800 XT GPU, it was the one that ramped up the Blt to 4K where as other GPUs would use 1080p even when they render 4K in X11/Wayland.

What I do to work around this problem is by using rEFInd as an intermediary and config it to lower the Blt resolution before transitioning to the loader. This dramatically speeds up the rendering to the menu which allows me to boot and finally use this graphics card for this system as shown in the following:

https://streamable.com/jlm7ig

I've also tested gop blt off and it doesn't solve my problem without rEFInd. And after using rEFInd and it just doesn't render the menu after a bit of time and goes right to showing the kernel being loaded, as shown here:

https://streamable.com/esgqn3

In D49073#1119317, @jkim wrote:

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

In D49073#1119151, @imp wrote:

it's ok I guess, but seems like yet another hack. Is there some way we can know if blt is slow?

thanks!

fix typo

This change should really posted to OpenZFS too.

Thanks!