I meant to comment on this. It's a good change.

In D14551#305421, @chuck wrote:

In D14551#305406, @imp wrote:

In D14551#305404, @chuck wrote:

When deciding how to export data from CAM, can you describe when using a XPT_KV_GET is preferred over XPT_DEV_ADVINFO?

DEV_ADVINFO is more for servicing GEOM attribute requests about the device. There seems to be a fair amount of glue at the xpt layer to know about what GEOM wants to be returned.

My stuff is more for the PERIPH asking the SIM for info, as well as set stuff. However, you ask a fair question.

So is the intent to support Object storage (as opposed to Block) via this new CCB type?

In D14551#305404, @chuck wrote:

When deciding how to export data from CAM, can you describe when using a XPT_KV_GET is preferred over XPT_DEV_ADVINFO?

Just to document a conversation Scott and I had:
(1) What about multiple keys?
(2) What about multiple returns?
(3) Should we just assume this is 1 page?
(4) How do we do chaining when we send CCBs from userland: not allow it at all or force userland to use less efficient methods
(5) How do SIMs deal with packing and unpacking?

update with wrapper function.

rebase

consider https://reviews.freebsd.org/D14546 instead :)

In D14465#304593, @imp wrote:

my only concern is with 64-bytes being long enough.

my only concern is with 64-bytes being long enough.

looks good to me, but I've not deeply studied the network code to know for sure it's totally cool.

In D14465#304163, @ian wrote:

It would actually be nice to export the board/system model string from FDT data as well, but we'd have to make a new hw.<something> oid name for it since the obvious name was already taken to mean "cpu type".

OK.

With all the comments, this has gotten hard to follow, but from what I am reading it looks good to me.

In D14494#303930, @marcel wrote:

This is opposite the direction taken already. The low-level console is defined in terms of hardware resources only. The uart(4) driver will map the low-level console to the newbus device during bus enumeration. The unit number is not a hardware resource. It's a newbus device property.

As such, the changes are architecturally wrong. Instead, we need support for setting or changing the name in the consider structure during bus enumeration. If that basic support is already there (say, by virtue of the kernel not using the name until after bus enumeration) then the fix is to set the name during bus enumeration when we have a device that maps the the low-level console.

OK. This was caused by loading uart int the boot loader and having it in the kernel. Abandoning.

Looks good to me.

great start

In D14471#303486, @ian wrote:

ubldr will find an unused block of space large enough to load the kernel into, and is smart enough to avoid loading it over top of itself or its own heap. There's nothing that prevents running into the stack (which is uboot's stack, at the very top of physical ram), but generally $loadaddr in uboot is somewhere near the bottom of ram and the vast majority of the memory on the board is available between the ubldr heap and stack.

Whether 8mb is a good number depends on whether ubldr is used on any small-memory systems. When I said "even 8mb would work fine" in irc the other day, I was thinking in terms of doing a smoke-test to see if increasing the heap fixed the problem. It might be interesting to see how much ubldr is really using, which can probably be done by defining ZALLOCDEBUG and calling zallocstats() just before launching the kernel. Maybe 2mb is more than enough.

I think this is fine, but what does it do to the minimum sized we can boot on? And does this interfere with where we load the kernel? Is there an overlap? Of is that just a u-boot issue?

You need to do runtime CPU detection, and do it for all the other SoC families.

daerror should be called with the periph lock held, assert it rather
than take it.

Basically, the project doesn't have the bandwidth to support multiple versions of u-boot, unless there's a demonstrated actual need (not a theoretical need) to do so.
All board use the same version. Any board / SoC family that can will get a one or two release in upstream to get it fixed, then cut loose. We don't have the resources to support something so 'backwater' as to lose upstream u-boot support.
We depend heavily on upstream support, and if that ceases, the solution isn't to freeze that version. The solution is to delete the ports affected and drop support for the board.
To date, we've had no issues since the big switch supporting one version, though the infrastructure allows for one per family if needed.
I want only one version of packages. It greatly increases the support load to deal with old versions of u-boot and we get fewer complaints of breakage if recovery from breakage is easy. Since breakage is rare, we bias to fast discovery rather than bending over backwards to keep the user up and running. The cost/benefit ratio is far too low for this platform to be able to do that absent some compelling, as yet to be articulated, benefit.

In an ideal world, you'd have a richer set of Lua functionality for the ZFS module. However, our current build system make that a bit of a challenge. So for the moment, this is fine.

In D14198#299943, @trasz wrote:

I tried digging a little, and unfortunately the loop comes from before our repo history starts - r1593, which is some RCS repo surgery by rgrimes@. I have no idea what's the original purpose of it, and given there's some esoteric functionality there - mostly related to chat scripts - that I'm not able to easily test, I'd prefer to leave it as it is. It is been there forever, someone might depend on it.

Regarding init(8) looping - that's true, but it's intended to be used with "onifexists", which won't loop when the device disappears.

So - is it ok? Can you mark it as accepted? Thanks!

Should have ticked OK sooner. There's some issues, as noted, but the new bugs introduced have been fixed so they can wait for another day.

In D14242#302984, @jhb wrote:

In D14242#302969, @imp wrote:

In D14242#302968, @emaste wrote:

In D14242#302967, @imp wrote:

Since kernel config files set 'makeoptions' it should use WITH/WITHOUT.

This is really what the question was about - should WITH_RETPOLINE be set in GENERIC, or via src.conf?

I'd set it in GENERIC which makes it default. People can turn it off if they need to.

Just to be clear, if you are using an external toolchain that doesn't support retpoline can you disable it from the command line or do you have to use a custom kernel config if it is in GENERIC? Should be easy to test today with 'pkg install amd64-xtoolchain-gcc' and 'make CROSS_TOOLCHAIN=amd64-gcc' with a patched source tree and updated GENERIC. Ideally you can use 'make WITHOUT_RETPOLINE=yes buildkernel' to override it, but it makes it a bit more of a PITA if you have to have a modified kernel config.

In D14242#302968, @emaste wrote:

In D14242#302967, @imp wrote:

Since kernel config files set 'makeoptions' it should use WITH/WITHOUT.

This is really what the question was about - should WITH_RETPOLINE be set in GENERIC, or via src.conf?

In D14242#302964, @emaste wrote:

In D14242#302122, @dim wrote:

Well, if there is only one setting, users will have the choice to compile *everything* with, or without retpoline mitigation. Not sure if there is a scenario where one would want to have a mitigated kernel with a non-mitigated userland, or vice versa?

Intel has a whitepaper at https://software.intel.com/sites/default/files/managed/1d/46/Retpoline-A-Branch-Target-Injection-Mitigation.pdf that explains where retpoline fits in and where it's needed. We want a retpoline-enabled kernel to protect kernel secret data, while there may be cases in userland where after evaluation we decide it is not necessary to apply retpoline.

On the other hand, I now understand that the MK_ settings are normally not how kernel options are configured, they're more supposed to go into the config files like GENERIC, right?

This is one of the things I'm not completely sure of. We do have an existing case in MK_CTF - it is set in kernel configs via WITH_CTF=1. I could commit this change now and we could adjust it before MFC if necessary.

These are fine, but I wonder if it might not be better to have a MD module in the loader that exports attributes of the architecture.... If we use this for more than a few things, we should consider that path instead...

I'm good either way, but if you keep what you have a quick comment wouldn't be terrible.

I'd honestly feel better if we did this in Lua instead.

Just a comment on uint64_t: ps is 10^12, which is 36 bits to represent 1s, so switching to uint64_t will gives the most safety, especially given that the howmany macro isn't careful about overflow. Since it's just used in DELAY, and we know n for delay is usually small except in some crazy old ISA drivers, it likely worked or closely worked with 32-bit types. It wouldn't hit problems until several hundred or maybe thousand milliseconds if the back of the envelop numbers I just ran are right....
I'd be tempted in DELAY to s/u_quad_t/uint64_t/g since the quad name for that type is discouraged, but it's not a bug deal either way.
Quibbles aside, this was a good change before the change to 64-bit, and is a better change with that change as clocks will only get faster from here.

In D14230#302519, @manu wrote:

In D14230#302461, @linimon wrote:

In D14230#302395, @lwhsu wrote:

Just be curious, this patch would affect many u-boot-* which are slave port of this

There are a couple of ways I can see going forward.

My proposal (which imp dislikes intensly) is to have:

• one u-boot-master-foo port that works exactly like the current one (tracks the FreeBSD u-boot fork). This remains the default masterport. All the packages we build on the cluster will be from this one.

As the one who updated u-boot the last 3 or 4 time, I can say that using the freebsd fork is much harder than using upstream directly.
It also not motivate us to upstream our change and I believe we will soon be in the same case than before, having a lot of patches (except that instead of being in ports repo they will be in the fork repo).
Using config Fragment and U-Boot script is much easier than patches as this will not break (unless something shitty happens in U-Boot).

Hey, I'm out today. Do not commit this until I sign off. I have some worries that I don't have time to articulate. I'll get to it first thing in the morning. I think it might be OK, but it might not, so I want to study it carefully. Thanks.

This looks perfect. EDK2 definintions in Include/Protocol/DevicePath.h have it just like this.

Love it.

My lua extension fu is weak, but this looks decent to me.

This looks really cool!