I love this

OK. I've had a chance to review this, and this should work. I had misread it before (since my memory of my objection doesn't match the code and there's nothing in the revision history). My profuse apologies for sitting on this so long... it had fallen off my list of things to review a couple of times accidentally (I gotta do a better job at that list).

Driver looks fairly straightforward. One question, but looking at other drivers after I wrote it, maybe the answer is 'that's just the pattern' which is fine.

I think this has implemented the suggested changes to my suggested changes that @jrtc27 suggested.

This is cool functionality. Are there any of the tagged data times that the boot loader should be looking at to pass into the kernel via its metadata interface that we get from other locations and coreboot doesn't provide those interfaces so we leave it blank?
Or are we already doing this, and this commit just exposes the data in a new way.
love 'dmesg for coreboot' parts especially.

In D55472#1273784, @ngie wrote:

Out of curiosity, how much of the Linux driver did you use as a reference for this driver? I'm concerned about licensing of the new code.

In D55597#1272248, @mcq_disroot.org wrote:

Generated with U99999 for full context.

A couple of small suggestions, and one question that needs to be answered.

So the first level is BootXXXX. I think that's well in hand.
The next level is 'I want to boot this other thing.' that's harder. Though kevans pointed me at something he'd started that will help that a lot...

can you either use git arc to update this patch, or generate the diff with -U99999 please? I need a little more context to review it.

So there's two competing mechanism now for usb: the kernel config file (which better not be setting this) and the user WITH/WITHOUT mechanism. This is a bit weird and novel for the kernel and may or may not be easy to support in configng.

I think @jrtc27 is right about the observation that we don't need the bools.

In D55559#1271247, @stephane.rochoy_stormshield.eu wrote:

In D55559#1271244, @imp wrote:

My big problem with this is three fold. 1. Gpt bootme is non standard, so I don't want to build anything on it. 2 all menu stuff should be in lua, not c. The part protocol is not a good base to start from. And I guess 3: it ignore the BootXXXX protocol, so locks out all other oses. It is a big reason I never merged the boot1 changes in that pr. It is too limited in what it can boot and isn't scriptable.

Well, let's split the big problem into smaller ones then ;)

1. The use of BOOTME is something we use here at Stormshield. I should be able to remove it from the patch. Not a big deal I guess.

My big problem with this is three fold. 1. Gpt bootme is non standard, so I don't want to build anything on it. 2 all menu stuff should be in lua, not c. The part protocol is not a good base to start from. And I guess 3: it ignore the b9otXXXX protocol, so locks out all other oses. 8t is a b8g reason I never merged the boot1 changes in that pr. It is too limited in what it can boot and isn't scriptable.

This will work as is, but I have a couple of comments to make it a bit better.

I'm going to punt and try again later. Thanks for looking at this...

have claude gen a man page that I then tweaked a bit

just the meat of the commit

claude can be told to do the right thing...

OK. --libxo is one path (it produces data from -v), everything else goes through
the old code paths...

fix a number of regressions

typo found by claude