In D7589#180667, @tsoome wrote:

ok, got it built, and initial test. And there is this problem...

OK lsdev

EFI0:    EFI(SIMPLE_FILE_SYSTEM)
EFI1:    EFI(SIMPLE_FILE_SYSTEM)
EFI2:    EFI(SIMPLE_FILE_SYSTEM)
EFI3:    EFI(SIMPLE_FILE_SYSTEM)
EFI4:    EFI(SIMPLE_FILE_SYSTEM)
EFI5:    EFI(SIMPLE_FILE_SYSTEM)
EFI6:    EFI(SIMPLE_FILE_SYSTEM)
EFI7:    EFI(SIMPLE_FILE_SYSTEM)

net devices:

net0:

OK

Yep, we can skip dosfs there, and for very simple reason - if the firmware is not able to read system partition, there is no boot anyhow.

OK, based on others' reproduction of tsoome's issue on -hackers, I have a credible diagnostic theory.

tsoome, can I get you to build and test with the extra_logging branch on my github repo: https://github.com/emc2/freebsd

I've posted a CFT to -hackers, -current, and -amd64.

In D7589#180054, @tsoome wrote:

In D7589#180052, @eric_metricspace.net wrote:

In D7589#180051, @tsoome wrote:

I am getting rejects on patch, could you rebase on current head?:)

tsoome@freebsd-2:/usr/eric % find . -name \*.rej
./lib/libstand/stand.h.rej
./sys/boot/efi/boot1/zfs_module.c.rej
./sys/boot/efi/boot1/ufs_module.c.rej
./sys/boot/efi/boot1/boot_module.h.rej
tsoome@freebsd-2:/usr/eric %

Strange. I had rebased just before I sent this up. I am rebasing from the github master, if that changes things at all. The last commit in the history is an hour ago.

My github repo for this is here: https://github.com/emc2/freebsd/tree/efize_new

Be aware: I'm using rebase -i to squash everything down to one commit at this point, so there's a lot of forced pushes going into efize_new

that may explain, as my fbsd source instances are all against svn ... so could it be the git has been missing some updates?

There's probably some lag going on somewhere. I see Ed Maste did push a change to the EFI loaders.

It might make more sense to build off of my repo in order to diagnose the issue your setup found.

Note, i may have been hit also by my own bug... see D8644

In D7589#180051, @tsoome wrote:

I am getting rejects on patch, could you rebase on current head?:)

tsoome@freebsd-2:/usr/eric % find . -name \*.rej
./lib/libstand/stand.h.rej
./sys/boot/efi/boot1/zfs_module.c.rej
./sys/boot/efi/boot1/ufs_module.c.rej
./sys/boot/efi/boot1/boot_module.h.rej
tsoome@freebsd-2:/usr/eric %

Strange. I had rebased just before I sent this up. I am rebasing from the github master, if that changes things at all. The last commit in the history is an hour ago.

My github repo for this is here: https://github.com/emc2/freebsd/tree/efize_new

Be aware: I'm using rebase -i to squash everything down to one commit at this point, so there's a lot of forced pushes going into efize_new

that may explain, as my fbsd source instances are all against svn ... so could it be the git has been missing some updates?

In D7589#180049, @tsoome wrote:

I did build from current state, the patch did apply clean, build faile due to -lstand issue noted before, thats simple to fix.

Unfortunately the boot is not going well, last message is:

Initializing modules: FS Backend-

the '-' is spinner it seems. The VM has 4 disks, illumos mirror zfs on first 2, third has fbsd, 4th (for this test) has EFI system partition, and zfs and ufs partitions, zfs partition has bootfs with /boot directory.

In D7589#178522, @eric_metricspace.net wrote:

In D7589#178521, @tsoome wrote:

I did build from current state, the patch did apply clean, build faile due to -lstand issue noted before, thats simple to fix.

Unfortunately the boot is not going well, last message is:

Initializing modules: FS Backend-

the '-' is spinner it seems. The VM has 4 disks, illumos mirror zfs on first 2, third has fbsd, 4th (for this test) has EFI system partition, and zfs and ufs partitions, zfs partition has bootfs with /boot directory.

Failing in FS Backend would indicate that something's going wrong with the filesystem attach phase. The FS Backend initialization scans all device handles and attaches the right filesystem drivers.

If have been testing on my own laptops with 2 disks, one with an EFI system partition and a ZFS zolume, one with a ZFS cache and log.

Therefore, the most likely culprit is UFS, though multiple ZFS volumes or the illumos mirror could be a problem.

What VM are you using? The easiest way to hunt this down would be to replicate your setup locally. The second easiest would be to get you a patch with extra logging.

vmware fusion. The illumos zfs mirror by itself should not be problem as loader zfs reader can read it both ways without problems (illumos loader can access fbsd pools and vice versa), also multiple pools should not be an issue as such - and definitely is scenario for tests. UFS may be issue, altho in this test setup, its just empty, I had that idea to create /boot on it as next step:) There is also another potential pain point - the memory allocations - as boot1 is now linked with libstand, could it be the malloc/free used all around are interfering somehow...

In D7589#180037, @eric_metricspace.net wrote:

Replaced uses of AllocatePool with malloc. Tested with a UFS partition, no problem.

tsoome, could you see if this affects anything? If not, then email me directly to coordinate diagnosis of the bug your setup found.

I am getting rejects on patch, could you rebase on current head?:)

tsoome@freebsd-2:/usr/eric % find . -name \*.rej
./lib/libstand/stand.h.rej
./sys/boot/efi/boot1/zfs_module.c.rej
./sys/boot/efi/boot1/ufs_module.c.rej
./sys/boot/efi/boot1/boot_module.h.rej
tsoome@freebsd-2:/usr/eric %

Replaced uses of AllocatePool with malloc. Tested with a UFS partition, no problem.

In D7589#178527, @tsoome wrote:

I did build from current state, the patch did apply clean, build faile due to -lstand issue noted before, thats simple to fix.

Unfortunately the boot is not going well, last message is:

Initializing modules: FS Backend-

the '-' is spinner it seems. The VM has 4 disks, illumos mirror zfs on first 2, third has fbsd, 4th (for this test) has EFI system partition, and zfs and ufs partitions, zfs partition has bootfs with /boot directory.

In D7589#178522, @eric_metricspace.net wrote:

In D7589#178521, @tsoome wrote:

I did build from current state, the patch did apply clean, build faile due to -lstand issue noted before, thats simple to fix.

Unfortunately the boot is not going well, last message is:

Initializing modules: FS Backend-

the '-' is spinner it seems. The VM has 4 disks, illumos mirror zfs on first 2, third has fbsd, 4th (for this test) has EFI system partition, and zfs and ufs partitions, zfs partition has bootfs with /boot directory.

Failing in FS Backend would indicate that something's going wrong with the filesystem attach phase. The FS Backend initialization scans all device handles and attaches the right filesystem drivers.

If have been testing on my own laptops with 2 disks, one with an EFI system partition and a ZFS zolume, one with a ZFS cache and log.

Therefore, the most likely culprit is UFS, though multiple ZFS volumes or the illumos mirror could be a problem.

What VM are you using? The easiest way to hunt this down would be to replicate your setup locally. The second easiest would be to get you a patch with extra logging.

vmware fusion. The illumos zfs mirror by itself should not be problem as loader zfs reader can read it both ways without problems (illumos loader can access fbsd pools and vice versa), also multiple pools should not be an issue as such - and definitely is scenario for tests. UFS may be issue, altho in this test setup, its just empty, I had that idea to create /boot on it as next step:) There is also another potential pain point - the memory allocations - as boot1 is now linked with libstand, could it be the malloc/free used all around are interfering somehow...

In D7589#178521, @tsoome wrote:

I did build from current state, the patch did apply clean, build faile due to -lstand issue noted before, thats simple to fix.

Unfortunately the boot is not going well, last message is:

Initializing modules: FS Backend-

the '-' is spinner it seems. The VM has 4 disks, illumos mirror zfs on first 2, third has fbsd, 4th (for this test) has EFI system partition, and zfs and ufs partitions, zfs partition has bootfs with /boot directory.

IFC, also properly restored preferred functionality

The preferred partition functionality is restored. The boot1 program now obtains the device handle from the loaded image handle, and checks for the presence of an EFI_SIMPLE_FILE_SYSTEM interface after attaching all drivers before scanning all partitions. This will have the effect of preferring the boot device on which the boot1 program resides.

To proceed, I need guidance on what exactly should be done to restore the preferred functionality.

In D7589#162680, @manu wrote:

In D7589#162585, @imp wrote:

In D7589#162441, @manu wrote:

In D7589#157807, @andrew wrote:

In D7589#157710, @imp wrote:

It has by far caused us no end of pain. What's part10:? Our systems have 4 drives with 9 partitions on each one (except the ones that have 2, surprise!). The ordering is absolutely random as well, it seems. Some systems get part10 being the boot disk, others get part 2. Totally nuts.

I would like it if loader.efi understood partitions. @manu looked into it at BSDCan, however from my understanding, he found it was easier to teach U-Boot to expose partitions to loader.efi than add the existing GPT/MBR code to loader.efi.

If someone was to get it working I would imagine we could rename the partitions to be something like disk0p0 or disk1s3. The device name may be different than the kernel, however the partition id should be the same.

I think that the problem I got during bsdcan was boot1 unable to work well with unaligned partition so I would need to find time to look at this again (because of course I don't have the patches anymore).

On the review itself I'm a bit concerned about what this would mean for U-Boot.
I admit that I haven't read all the code but it seems that with this patch the UEFI implementation would need to support EFI_SIMPLE_FILE_SYSTEM (which U-Boot doesn't).
This is true that arm/arm64 aren't Tier-1 arch like AMD64 and that one UEFI implementation is required to support this protocol (from my understanding of the spec) but all the effort I've put on running boot1.efi/loader.efi on arm/arm64 (because this is the right way to take) would be useless if this is the case.

Erik: Can you confirm or not that EFI_SIMPLE_FILE_SYSTEM is needed ?
If this is the case we would need a fallback on what boot1/loader is currently doing.

Since we're implementing a EFI_SIMPLE_FILE_SYSTEM for UFS and ZFS, why would u-boot not supporting it matter?

Warner

In D7589#162756, @cem wrote:

My biggest concern is that this is a giant patch that does a bunch of different things. I'd like to see smaller commits that do one thing at a time.

Fix a bunch of style issues. Still need to restore preferred partition support.

The preferred stuff probably got squashed in a merge. A question worth asking: should I reinstate it as-is, or is there any minor improvement that could be done opportunistically?

RE: device names- There are options here. EFI has a protocol that can be used to attach an arbitrary string as a description. It wouldn't be too hard to print that name out if it's present on a handle. You could generate those names from a number of sources, in fact: filesystem labels, ZFS UUID's, or EFI device paths as a fallback mechanism.

There isn't a need to clean up memory after boot1, and in fact, that will probably break things. Once an EFI driver is initialized and attached to handles, it stays around until ExitBootServices or until the driver is unloaded (which currently isn't done ever).

I closed the other review. What exactly remains to be done on this?

Closing. Conduct all review on https://reviews.freebsd.org/D4515

Work on this has moved to https://reviews.freebsd.org/D4515. Please make any requests for revision there.

Thanks for taking care of the remaining cleanup.

Thanks for submitting the update. I am currently tied up dealing with year-end stuff, so not much time to work on it. I will have more time after mid next week.

Fixed strlen bug

Also, it should cleanly apply to the current head and build in make world now.

Updated diff to address many issues.

General cleanup, address style issues. Also slight edits to makefiles.