Skip to content

Conversation

@48cf
Copy link
Contributor

@48cf 48cf commented Jun 2, 2025

Most uACPI kernel APIs are stubbed out but they are not essential for what we need, which is basically evaluating AML methods to discover PCI root bridges and their resources

Most uACPI kernel APIs are stubbed out but they are not
essential for what we need, which is basically evaluating
AML methods to discover PCI root bridges and their resources
@mintsuki mintsuki requested a review from FlyGoat June 2, 2025 18:58
@FlyGoat
Copy link
Owner

FlyGoat commented Jun 2, 2025

Thanks! Build failing on IA32, @mintsuki maybe cc-runtime should provide libatomic symbols?

@mintsuki
Copy link
Collaborator

mintsuki commented Jun 2, 2025

Nah. The main issue here is that we use -march=i386 and that is why this is failing, another commit is incoming to change it to -march=i686, which we shouldn't have a problem with anyways since pretty much all IA32 systems are at least i686 (aka Pentium Pro and newer).

@mintsuki
Copy link
Collaborator

mintsuki commented Jun 2, 2025

@FlyGoat it's ready now!

@FlyGoat
Copy link
Owner

FlyGoat commented Jun 2, 2025

I do fell like EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL is a better way to get bridge information, bus and mmio ranges are all in Configuration.

I want to avoid evaluating aml if it's possible. I know a handful of platforms, even including Kabylake CRB that are doing wired stuff in AML that will render hardware in to a non-PC compatible state, and the path going back is never validated by vendors so god knows if it will work.

Probably I'm paranoid but I strongly feel this should be optional. I'm happy to merge this with a global switch flag.

@NS-Clone
Copy link

NS-Clone commented Jun 2, 2025

which we shouldn't have a problem with anyways since pretty much all IA32 systems are at least i686 (aka Pentium Pro and newer).

and how many pentium pro machines has uefi without csm? 🤣

@48cf
Copy link
Contributor Author

48cf commented Jun 2, 2025

It seems like EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL provides the same set of information as evaluating _CRS would, but I am wondering how widely supported it is knowing how bad UEFI implementations can be.

I think we could use the protocol with a fallback to fully initializing uACPI and evaluating _CRS in case the protocol is not present, what do you think @FlyGoat?

I'll get back to this PR in a bit if that's okay, I spent most of the time today basically working on PCI scanning + remapping code and we decided to upstream this separately first.

@FlyGoat
Copy link
Owner

FlyGoat commented Jun 2, 2025

@48cf Yes for sure, you are always welcomed :-)

Main concern for doing that is that running AML might put the
hardware into a non-PC compatible state with no reliable way
to reverse that (as per comment on FlyGoat#54).

For now `acpi_init` only sets up "early table access", as it
previously did, to allow ACPI table enumeration, but if the need
arises one can call `acpi_full_init` to be able to call into
uACPI functions that require the namespace to be loaded and initialized.
@mintsuki
Copy link
Collaborator

mintsuki commented Jun 3, 2025

@FlyGoat please take a look now

@48cf
Copy link
Contributor Author

48cf commented Jun 3, 2025

For the record, I plan to add the code for conditionally fully initializing uACPI when needed in my next PR that will introduce remapping PCI BARs

@FlyGoat
Copy link
Owner

FlyGoat commented Jun 3, 2025

LGTM, thanks for your contribution!

@FlyGoat FlyGoat merged commit b688880 into FlyGoat:main Jun 3, 2025
1 check passed
mintsuki added a commit to mintsuki/csmwrap that referenced this pull request Jun 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants