Context adjustments due to modifications in previous patches

Fix comments.

Add Xen guest assert.

Guess I had it easy as I had a system running Linux and arcanist was available as a package.

Add comment.

Upload diff with context.

In D43764#998154, @markj wrote:

In D43764#998147, @royger wrote:

In D43764#998144, @markj wrote:

Could you please upload diffs with context? i.e., add -U99999 or so to diff's parameters.

Hm, that's the output from git format-patch. I wonder why it doesn't pick the context automatically from the repo?

How are you uploading it? arc diff --create <revision> or git arc create will indeed fetch context automatically. If you're manually uploading diffs, then it won't. See https://wiki.freebsd.org/Phabricator#Create_a_Revision

Fix possaible use of init_fn uninitialized.

In D43764#998147, @royger wrote:

In D43764#998144, @markj wrote:

Could you please upload diffs with context? i.e., add -U99999 or so to diff's parameters.

Hm, that's the output from git format-patch. I wonder why it doesn't pick the context automatically from the repo?

In D43764#998144, @markj wrote:

Could you please upload diffs with context? i.e., add -U99999 or so to diff's parameters.

Could you please upload diffs with context? i.e., add -U99999 or so to diff's parameters.

• I've updated the code to follow the style as you mentioned.
• I've removed too wide CFLAGS from libsa Makefile.

As this was my first patch here I need to get familiar with the interface and the way how I can submit the changes. I also need to refresh my memory what I did as I did this in March.

In D34479#831843, @imp wrote:

Some general comments...

The style of indented #if isn't what we do in FreeBSD. Code should be indented as if the #if isn't present, and the # directives should be in column 1.
We don't add extra spaces around the ('s, as I've highlighted
We don't do if (foo) bar; on one line.
logical operators are at the end of the line, not the start of the continuation.

It's an interesting notion... You'll likely want to do something similar to the EFI boot loader as well.

Some general comments...

LGTM

In D25373#565381, @greg_unrelenting.technology wrote:

In D25373#565380, @markm wrote:

ECAM hacks? When are those likely to appear? :-)

https://unrelentingtech.s3.dualstack.eu-west-1.amazonaws.com/flash-image-2020-07-01.bin try this image, it has the ECAM offset removed

@mw promised to make a toggle for ECAM offset in the setup menu.. :)

OK to close again.

That works, thanks! I'm at latest CURRENT, no backouts, my console works and so do my PCI ethernet port.

In D25373#565380, @markm wrote:

ECAM hacks? When are those likely to appear? :-)

ECAM hacks? When are those likely to appear? :-)

In D25373#565376, @markm wrote:

With this patch in, AND the flashe given above, I get my console back!

But I lose my PCI ethernet ports.

With this patch in, AND the flashe given above, I get my console back!

In D25373#565370, @markm wrote:

Worse. Previously working console now broken. Current with this change backed out now broken.

Is the console supposed to work without this fix applied?

Worse. Previously working console now broken. Current with this change backed out now broken.

Trying now. In the meanwhile, is there some place where the Collected Wisdom™ of all current mcbin firmware statusses, hints, binaries etc are kept?

Add conv=sync for dd
If it's the old version that GregV posted a while ago it's normal that this commit "breaks" for you, this image have a patched SPCR table to cope with the old bug that this code fixes.

Yup - my flash is a couple of months old, and a hand-rolled debug-version (not by me). The image you pointed to fails with checksum errors at boot, but it may have something to do with the way I made it. With the same MBR as the old one, I did:

It works fine on mine, are you using an old edk2 build maybe ?
Try https://people.freebsd.org/~manu/flash-image-mcbin.bin
This is mainline edk2 (latest stable version) and Marvell TF-A, ports will land soon.

This change breaks my MacchiattoBin DoubleShot. I've bisected to get to commit r362574, which is this. The symptoms are a hang right at the beginning of the boot, at this point:

@cperciva I'm adding such note, thanks.

Looks good to me. Might be worth mentioning in the commit message that EFI_ACPI_6_0_UNDEFINED handling is needed to work around a buggy SPCR table on EC2 x86 "bare metal" instances, just in case someone looks at the code a few years from now and wonders why we're doing this.

Works on my mcbin with the official SPCR table! :) Might test on other things later.

@cperciva @greg_unrelenting.technology Hi! Before I do the commit, I'm looking forward to your testing and I'd really appreciate your input.

Thanks for finding this. We went round and round when it went in. Might not hurt to make sure it still works on other boards
.

Thanks !
I've talked with Greg about this last week, glad you did it before me :)

Now calling from IOAPIC suspend/resume functions (if there's any better place "close to the nexus" I haven't found it.)

DMARs must be suspended after, and resumed before any subordinate devices. Because DMARs do not participate in the newbus hierarchy, or rather, they are placed there in the arbitrary place determined by not relevant details of the driver implementation, newbus suspend/resume methods are really not appropriate to use. The methods should be nops, and actual suspend/resume done near nexus.

More proper temp calculatuion based on RangeUnajusted, according to "Preliminary BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 16h Models 00h-0Fh (Kabini) Processors".