Suggestion for Boot picker or OpenCanopy

[CobanRamo]

Hi guys

I would like to propose a function for the buildin picker and OpenCanopy. You probably know the "Uefi Firmware Settings" call from the Grub bootloader.

That should be possible with OpenCore too.

I would like to suggest this under an item in the advanced boot menu.

you could solve it like reboot and shutdown points or like menu point nvram reset. What do you think about that?

[mikebeaton]

As an additional entry (which could come from a tool, or from a Boot Entry Protocol compatible driver) this isn't such a bad idea. One difficulty which would need considering is what to do on supported systems such as Intel Macs, (most of) which do not have a UEFI settings menu. (It may be fine to reboot with no effect in those cases, so this may not need any special handling.)

I'd suggest we would consider a well-written (according to OC/EDK-II coding standards) PR - but otherwise it would be quite low priority, realistically, since essentially all machines using OC which have a UEFI menu already have a built in way, which the user knows, of accessing this.

[mikebeaton]

nice icon set, by the way! which one is it? (presumably @chris1111 or @blackosx... :) )

[CobanRamo]

I think for those who completely disable the legacy stuff in Uefi, it's not such a bad idea. If I completely deactivate legacy recognition in the Uefi, I have no keyboard until the OpenCore is loaded, so it would be nice to have this call.

nice icon set...

Oh, I derived it from the OpenCore "GoldenGate" and expanded it for my needs. You are of course welcome to have it if you want. :) https://github.com/CobanRamo/OpenCore-IconSet

[mikebeaton]

If I completely deactivate legacy recognition in the Uefi

Not quite sure why you would do that

You are of course welcome to have it if you want. :)

After arguing for and implementing the themes support, always on the lookout for other nice themes! ;)

[mikebeaton]

I think for those who completely disable the legacy stuff in Uefi, it's not such a bad idea. If I completely deactivate legacy recognition in the Uefi, I have no keyboard until the OpenCore is loaded, so it would be nice to have this call.

@CobanRamo - Apologies, on re-reading this, perhaps my initial comment was too dismissive. Sorry. I would agree that it is fair enough if you want UEFI boot and no Legacy boot. But - my revised comment is! - I'm not aware that it's normal that disabling legacy boot in a bios should stop the keyboard from working. Are you sure these (have to) go together? Which bios/system are you using?

[CobanRamo]

Oh Mike, there's nothing to apologize about. After reading about it several times, I noticed that I expressed myself incorrectly, or it's a stupid translation. That's just how it is when you can't speak decent English. :)

So, I have a Z590 platform here, where the UEFI boot process until OpenCore is kinda slow, it can take up to 10 seconds before I have the OpenCore menu in front of me. Therefore I deactivate all legacy stuff in the UEFI and activate the MSI Fast Boot. The result is of course that I have no keyboard and mouse until the start of the Opencore. Ergo, such a call point to the UEFI/Bios as with the Grub Loader is very convenient in my case. Hence the idea.

You must excuse me for the late reply, I'm on late duty this week and I'm extremely busy. :)

[mikebeaton]

Well equally of course you don't have anything to apologise for - certainly, we all reply when we have the time to!

I am pretty surprised that there is a system which boots fast, but with no keyboard support - I mean, I would accept no BlueTooth support, but no keyboard support?! I would have expected that all BIOSes would need it to be possible to break into them, e.g. what if the current boot entry becomes unbootable. Perhaps, to be clear, you could clarify how you do break into this BIOS, with those settings, if the boot entry does become unbootable - say just always hangs?

[CobanRamo]

I mean, I would accept no BlueTooth support, but no keyboard support?!

MSI itself even says that the USB, PS2 and Sata are skipped.. But I have to expressly mention here that with this option you only have no keyboard or mouse during the boot phase up to OpenCore or up to the operating system, under OpenCanopy or under the operating system everything is as it should be.

I would have expected that all BIOSes would need it to be possible to break into them, e.g. what if the current boot entry becomes unbootable.

I think in this case you can still activate the GoToBios option with a 4-second power button. I mean pretty much all biosses have that.

you can also use Windows recovery to uefi or even a Grub loader.

So there are already enough solutions, that's certainly not a problem in itself, but I think that also needs an OpenCore bootloader. If all else fails, you can always run cmos reset. :)

[MacNB]

Just to tag along with another suggestion if I may.

The whole concept of "tools" on the same row as Bootable OS's seems to defy logical view of that row. That is, Opencanopy displays "Shell", ResetNVRAM, BootKicker, etc next to bootable OS's even though they are NOT really bootable OS's. Yes OK they can be hidden as Auxiliary so they are not visible but still seems out of place.

My 2 cents would be that anything in OC's Tools folder to be displayed on the same row as the current Restart & Shutdown icons. If those two can be displayed there today, why not others (with a limit of course) ?.

So UEFI F/W, Restart, Shell, ToggleSIP, Whatever, etc would be on the bottom of the screen.

[mikebeaton]

Not likely to happen. And this is a new suggestion, so new issue if you want to raise it.

[mikebeaton]

I'll close this since we have an optional firmware settings entry now (as linked above).

The folders suggestion could be re-opened in a separate issue, but I think is unlikely to happen, particularly as one goal of OpenCanopy is to more-or-less match the look and feel of the native Apple bootpicker.