EmbeddedControl implementation research

[TabulateJarl8]

Hey! I was working on getting S5 sleep in my operating system, and my machine's AML seems to be running stuff from the embedded controller region when the \_PTS method is executed. I noticed a NoHandlerForRegionAccess(EmbeddedControl) error, and after digging through the source code it seems to me that this just isn't implemented yet.

It doesn't seem particularly simple to implement to me (although I haven't looked too far into it), so I was wondering if there's any resources or spec research that might be useful for someone trying to implement this. I am interested in contributing to more Rust osdev, so I'd be happy to do some research or aid in the implementation if that's something not too far in the weeds

[martin-hughes]

Thanks for your interest @TabulateJarl8! I'll bump this across to "discussions" since it's fairly open-ended.

[martin-hughes]

Hello again! You're right - Region Handlers aren't fully implemented yet, but I think if you do a "find all references" for Interpreter::region_handlers they're referenced in the relevant locations where code needs to be added.

You're definitely welcome to take a stab at it - if you've got something you want to discuss then open a draft PR and assign me, or mention me somewhere and we can talk about it in more detail.

I'm not sure if you'd consider it "far in the weeds" or not - in some ways it'll be higher level than a lot of OS stuff, but you might also end up thinking about some crazy hardware details 🤷

Before talking about specific documentation, a warning - I've found that AI can be a bit confused dealing with ACPI stuff, probably because of the lack of available docs. So take its suggestions with a pinch of salt.

Sadly, the documentation is a bit lacking. The main ACPI spec does have a bit of stuff about operation regions (this is probably the place to start, alongside here) but it's not the easiest to read and doesn't go into a great deal of detail about the Embedded Control region. That'd be my starting point anyway.

You might also be able to find a chip specification or developer guide for whichever bit of your motherboard it is... btw, what are you trying to run on? If it gives some idea of the signals it needs then you might be able to understand more about how your code should work.

Other than that, there'll just be a certain about of "try it and see" I'm afraid. Good luck 😄 (but feel free to ask questions. I'll do my best, but the OSDev Forum gets more views and has some smarter folks looking at it so might be worth a try)

[TabulateJarl8]

Thanks so much for the info! I might try and give it a shot to see what I come up with. I'm not super big into AI, so I should be fine with that part (thanks for the heads up though).

I'm currently trying to run it on an HP Pavilion cs0064st. I couldn't find anything online but I also didn't try for more than a few minutes. I also have an old Optiplex 9020 from 2014 that I might be able to test on, but I think that's running into different issues somewhere in my ACPI initialization (something about Aml(NoCurrentOp)), so it might not be as viable until I can look into that.

[martin-hughes]

something about Aml(NoCurrentOp)

Ah OK - if you aren't already: for now, it's best to use the most recent git revision in your Cargo.toml as there's loads of fixes since v6.1.1; for example #289 which got rid of a lot of NoCurrentOp errors

I guess we probably ought to add that to the instructions...

But do let us know if it's a different bug!

[TabulateJarl8]

I should be using the git version - my new serial adapter came in this morning so I'll try again tomorrow afternoon and file an issue if it still persists

[IsaacWoods]

Hey @TabulateJarl8!

I haven't got to implementing embedded controller bits yet, and as you note custom region handlers are still WIP (but I would like to get them working sooner rather than later; they shouldn't be too tricky I'm hoping!).

The embedded controller I think has a spec and is relatively generic. There are two ways of discovering one, either through a static ECDT table or via the AML namespace. You then read and write registers as you're told to via that, and execute various AML methods to indicate you've received events from the EC. I think the issue is that handling the EC properly (which I think is fairly asynchronous) requires a fair amount of other kernel infrastructure, so parts at least are outside the scope of this crate.

A good place to potentially start would be Managarm's EC driver - I don't think many other 'hobby' kernels have good support yet, but I haven't looked too closely yet.

[TabulateJarl8]

Ahh I see, this is super helpful! I see that Managarm uses uACPI, the API doesn't seem too bad so maybe I'll check that out a bit more closely and see how adaptable it is to Rust.

[TabulateJarl8]

I've been poking around this crate and the ACPI spec for a few hours and a few things came up that I was curious about/wanted a sanity check on:

• the EC driver would be implemented on the OS level rather than in this crate like managarm does so that it won't block the interpreter lock. looking at the region handlers, they're currently defined as a Box<R> inside of a Spinlock. Since EC calls can be slow, would this make sense to change to an Arc<R> so that the handler can be cloned out and the lock can be dropped before calling the handler?
• should the RegionHandler functions accept the offset param from do_native_region_*? Custom handlers dont seem to currently have a way of knowing what offset to R/W from/to.
  • Table 19.34 in the ACPI spec says that EC accesses are only by u8, and the chapter 12 intro defines the EC as a "flat byte-addressable I/O space" of 256 bytes, so I think the handlers would need that offset to know which register to hit
• I think this TODO would have to be implemented but looking at 6.5.4 in the spec it doesn't seem too bad:
  • // TODO: run all _REGs for globally-installed handlers (this might need more bookkeeping)

Just as a note - I noticed the _GLK object for global locking when accessing a device (6.5.7) and wanted to write it down before I forgot about it

[martin-hughes]

Isaac might correct me, but I think the answer to all your bullet points is "yes". Since Region Handlers haven't been implemented before there's wide scope for you to try stuff / prototype things and see what works.

would this make sense to change to an Arc

Off the top of my head, I can't see why not.

should the RegionHandler functions accept the offset param from do_native_region_*

I think so - I've had a brief think about the other OpRegion types and I believe an offset is required for at least a few of them.

I think this TODO would have to be implemented but looking at 6.5.4 in the spec it doesn't seem too bad

Agreed. I don't think it'll be an issue, but it's possible for the regions to become available and unavailable repeatedly - for example, during a PCI hotswap. So if you're sketching something out, just bear this need in mind. (Like I say, I don't think it'll be a problem)

[TabulateJarl8]

Ahh got it, thanks! I wasn't sure if a lot of this stuff was already set for some particular reason that I was missing. I'll try some stuff out and see how far I can get. If I get far enough I'll open a PR to see what we think