In D52833#1207111, @brooks wrote:

In D52833#1207103, @imp wrote:

Fun. Commit message could be better at explaining why this happens with the old code

There's no functional change. It's just that I copied and pasted without tabs.

Fun. Commit message could be better at explaining why this happens with the old code

I suspect this is fine. ISA is all the on boatd IO that's ioport mapped that's not part of pci. It most likely is lpc based and the ACPI enumeration of that jardware should hang off this bus, not the acpi bus for the software model. But practically, this is easier and there's not enough difference to mater.

PDP_ENDIAN was the spelling. It was also the order for a subset of pdp-11 compilers.

So internally to the build system, MACHINE and MACHINE_ARCH are used. When cross building, for various technical reasons, you have to set TARGET and/or TARGET_ARCH. When one can be guessed from the other (as is the case for all architectures except powerpc), you need only set one, the other one will be inferred. For powerpc, setting TARGET_ARCH alone is sufficient, so maybe we should recommend that for all cases. I'd put a cross reference to arch(7) since MACHINE and MACHINE_ARCH, and their allowed values, are explained in detail. The make target only lists a subset of allowed values at times when we've deprecated some targets but haven't yet removed them .

update comments, some minor tweaking

This looks good to me.

So this is a bit tricky for why we're doing this and how it solves the problem. See suggestion for a comment.

Aarch64 too

This is needed also for arm64

Python looks ok

I like base way better than packages, which has the sane issues as pkgbase, and it's too generic.

So is this the place to document the config files you need to fetch a custom repo?
Or what the distdir settings are for -current and -stable and how to get releases?
Or that if you pkg install all these things, you still need to do some flavoring to the system (fstab, rc.conf, loader.conf and a few others)

Spammy how? Unlike ports, UPDATING isn't automatically displayed. I imagine that they'd slow way down once we have the deck chairs just so...

You might want to look at ~imp/armv7-pkgbase-14.3-exp.sh which generates a bootable image w/o root for armv7 with the correct perms using pkgbase + pkg to create the system.

Might be a few more nits, but we're getting close to time to just accept what's done and do further refinement later.

W/o measuring it, or knowing what the NIC is doing, it's hard to say how good the results from this will be.

This looks better now. Doing things better next time is fine.

this is ready too!

This is ready!

There's a few of these elsewhere in the nanobsd tree.
It's also the only place in the tree we do this style, so this is good, I think.

I'm surprised this hasn't been done sooner

I didn't see anything in the implementation of the MI parts to give me heartburn.

Thanks for mopping up. I'm too bust emptying my shopvac after the sudden indoor waterfalls I had earlier.

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?

So this change is a bit larger than I like to review. But the moved code was simple (and I know I have comment about the moved code, and that maybe the NVMe driver isn't good about doing it true). In the future, though it would make it easiest if you had the 'move it' commits separate from the rest. The place I want a comment could get one later too, if that's easier to do.

I'd really rather not have efi_main depend on the frame buffer.

Also agreed with kevans: please add /src.conf to .gitignore

I'm also not sure about the first-stage / second-stage bit.... gptboot, gptzfsboot, isoboot and boot2 are all second-stage loaders, I think, though we've never been super clear about that in our docs.

This isn't entirely true. As with all things, it's stupidly complex when, perhaps, it shouldn't be.

Any chance there's a doc for this? Sound on a Chromebook i have doesn't work for similar reasons and i don't know where to start down the rabithole

Devmatch and devd are basically required