#uACPI - a portable and easy-to-integrate ACPI implementation

1 messages ยท Page 52 of 1

fiery turtle
#

Still

fiery ice
#

just added a return

fiery turtle
#

You cant use aml on real hw if u have half of the api stubbed

fiery ice
#

i'll add the PCI driver then

fiery turtle
#

I swear I need to add api smart checking and prefix every log message with [BAD KAPI] or something lol

#

(If it detects stubbed stuff)

dense steppe
#

have a -DUACPI_SANITY_CHECK_KAPI and require any bug reports to run with it enabled

calm latch
#

Like not only if it's just stubbed

left orbit
#

no

#

kernel api is allowed to fail lol

#

it's your fault for not implementing it

#

the kernel api is there literally so you implement it

calm latch
#

that's why you make it a compile time option

left orbit
#

yeah but it's stupid lol

calm latch
#

The failures are usually because of OOM

left orbit
#

exactly

calm latch
#

A lot of kernels panic because of it anyway

left orbit
#

which the kernel should be able to either on its own or know that it had happened

calm latch
#

And if something returns NULL, it's usually because it's stubbed

#

So if you know that the kernel returns NULL when it's out of memory, you can silence it

#

And you can make it a debug/notice log level anyway

#

so a log message is harmless

left orbit
#

making it a debug log makes sense

calm latch
#

But I agree it's bad

left orbit
#

i agree

calm latch
#

Like the fault is on the kernel

left orbit
#

i take messages a bit literally sometimes

calm latch
#

and uACPI is a serious library and perhaps should be doing this stuff because some kernel doesn't follow the rules

#

out of 20 now?

#

You can have kernel api fail log level define or something, and make it a warning by default so it's obvious

#

And people could redefine it to debug/disable?

#

Idk

fiery turtle
#

Its true that its super unlikely that any of the uacpi allocation APIs fail in a serious kernel because those usually have tons of mechanisms to stall a kernel allocation by all means possible to satisfy it

#

Like call into page reclaim, dump page cache, invoke oom killer, use emergency pool, compact existing memory etc

#

But its still not an error to oom and uacpi should handle it gracefully

calm latch
#

i'm saying you could make it an explicit warning/log message

left orbit
#

i still think it's dumb to make a dedicated "feature" for this

#

i would say it's okay if uacpi logged a debug message every time a kernel api failed

#

like, the first line of debugging something is enabling debug logging

#

and that will tell you which kernel api failed and why

fiery turtle
#

Yeah, just too many places using kernel APIs and too annoying to maintain this

calm latch
#

You could perhaps make kernel API defines use different error codes?

#

Like set msb bit

left orbit
#

that's even more work than just logging failures lol

#

oh

#

like that

calm latch
#

Then you just go over the codebase with a giant replace

fiery turtle
#

U can do this right now, set the msb when returning errors from your api

left orbit
#

so users can differentiate between uacpi and kernel api errors i guess

fiery turtle
#

Sure it's not a valid enum but it is for you

#

The only difference is no error to string for uacpi

left orbit
#

uacpi will just say invalid error though

#

yup

fiery turtle
left orbit
#

that's the problem

calm latch
#

Error string can say returned by kernel in parenthesis

left orbit
#

i think the idea is that uacpi would treat it as a regular error without the msb

fiery turtle
#

And u can easily hack enum to string to pop the top bit

left orbit
#

but you can check that bit

fiery turtle
#

That's possible yeah

calm latch
#

Though what if it's null

left orbit
#

you'd need to either allocate the string then append based on the bit or duplicate all the cases

calm latch
#

Anyway

calm latch
#

These are solutions against dumb

left orbit
#

but i still think it's dumb for uacpi to add more code to catch someone returning not implemented from a kernel api lol

calm latch
#

Which shouldn't be needed in context of osdev

fiery turtle
#

Yeah like

#

Either use barebones or implement everything

#

The other use cases aren't supported officially

vast kestrel
#

tbh it just feels like having kapi checks and self test is a bit too much of hand holding

#

Do you have a uacpi test image btw?

left orbit
#

there's a test runner

vast kestrel
#

Fuck I replied to myself

left orbit
#

there's nothing iirc

#

you can grab a random kernel that uses uacpi

fiery turtle
#

nah, it's just too much work

left orbit
#

but ymmv

fiery turtle
#

but it will be the ultra kernel trl

vast kestrel
#

Fuck it, I will turn uacpi-os to a test image

left orbit
#

still waiting for the report threadโ„ข๏ธ

#

and the fancy logger

#

i need to star the repo actually

fiery turtle
left orbit
#

starred.

fiery turtle
#

thanks

fiery turtle
fiery turtle
left orbit
#

i wish my kernel would just appear out of thin air like that too

vast kestrel
#

yeah

#

I will just remove that part and turn it into a simple uacpi runner instead

#

it already has some basic threadig and stuff iirc

fiery turtle
#

nice

slim panther
#

@fiery turtle are uacpi_kernel_io_{read,write}* functions ever going to get called on !x86?

frank canopy
#

i think technically uncertain but almost certainly not

slim panther
#

i'm doing some refactoring to my abstraction layers and the question is if i do conditional compilation inside of those functions or only include a definition when compiling for x86_64

hollow crescent
left orbit
left orbit
#

wdym

#

would you rather have a boolean return value from functions that return status codes right now? lol

#

status codes have a great use case: they let you figure out what went wrong

hollow crescent
#

you said users

#

why would users care about who issued the error

#

and why would users have access to uACPI anyways

#

isnt that a kernel thing

frank canopy
#

i think what was meant was users of the library

#

not users as in usermode

hollow crescent
#

in that case, yes of course you should return your own error codes

#

and the kernel designer had better not confuse them with their own error codes

left orbit
#

๐Ÿ’€

#

i mean the return of the kernel api functions is a uacpi_status

hollow crescent
#

fine

left orbit
#

and, while it's an arbitrary integer, you should probably return one of the uacpi status codes

hollow crescent
#

yeah

#

so that uacpi knows what's wrong

frank canopy
#

technically not all arbitrary, the success value is set

hollow crescent
#

off the topic but i was definitely thinking how i could integrate uacpi into boron and i was thinking. if i'm going to make it a dll i should probably allow drivers to link against each other

slim panther
#

hm

#

what should it do on e.g. riscv?

#

or aarch

#

just mmio?

fiery turtle
#

u can return UACPI_STATUS_UNIMPLEMENTED

hollow crescent
fiery turtle
#

e.g. on linux it would read from pci io ports

frank canopy
#

yeah id return unimplemented for non-x86 io port things and if it ever trips that then figure out for that arch

slim panther
#

the problem is my abstraction layer rn ๐Ÿ˜“

#

i can't call asm wrapper functions outside of the arch/ module

#

maybe a skill issue on my end, but i really want to discourage using inline asm in generic code

frank canopy
#

you can always have per-arch impls in each arch/ module

#

and have the non-x86 ones return unimplemented for now

fiery turtle
frank canopy
#

can def have a driver module on top of it though, ala windows acpi.sys

#

which idk if that does all acpi or just the device stuff

fiery turtle
#

yeah but windows also has multiple smaller acpi drivers that are built into the kernel

frank canopy
#

yeah

fiery turtle
#

for earlier code

frank canopy
#

hence the driver module on top of it part, the driver running on top of the core kernel's uacpi stuff

fiery turtle
#

yeah thats possible

frank canopy
#

thats technically what i do except my drivers are just their own files that are part of the same compilation unit

#

my api can technically do separate modules for drivers except i dont support dynamic linking or loading rn lol

fiery turtle
#

i have yet to think about how im gonna resolve cross module dependencies

frank canopy
#

just have everything being compiled together as a single unit like i do and like is the norm for zig its easy

vast kestrel
#

ok, I have a "bare minimum" kernel that should be able to run uacpi properly

frank canopy
#

nice

vast kestrel
#

now to enable random stuff so you can test more than just the init

fiery turtle
#

Damn haiku PR got revived

#

After a few months

slim panther
#

and?

#

declined?

fiery turtle
slim panther
#

i'm blind

frank canopy
fiery turtle
#

So far the feedback is positive

vast kestrel
hollow elm
vast kestrel
#

so I can also implement a sleep function or something alike

#

to test sleep and wakeup from sleep

slim panther
#

i was actually hyped

vast kestrel
#

tbh I should before saying that my code works :^)

#

lemme try on my laptop

#

oh wait first I need to add a framebuffer thing

fiery ice
#

i still need to add PCI lol

vast kestrel
#

I am using 0xE9

frank canopy
#

at some point ill test my stuff on hardware lol

#

someday

#

im also using 0xE9 though lol

fiery ice
#

i'm working on threads now so i can run uACPI properly

fiery turtle
#

Very few people know that u can detect 0xE9 prescence by checking that in(0xE9) == 0xE9

#

Just a random fact

vast kestrel
#

yeah, its a cool thing

frank canopy
#

WAIT REALLY?

#

dang

vast kestrel
#

the sad thing tho

#

the sad thing is that you don't have input from e9

fiery turtle
#

Lol

vast kestrel
#

which is why I quickly switch to serial

#

I just realized

fiery turtle
vast kestrel
#

once you initialize acpi, the kernel won't have ps2 emulation

#

problems for later ig

fiery turtle
frank canopy
#

i kinda want to get an x86 SBC with a hardware serial port just to test osdev things on tbh

fiery turtle
#

Like eval methods, dump the namespace

vast kestrel
#

I want to have a c like repl

fiery turtle
#

Damn

vast kestrel
#

and have all the uacpi functions as symbols

fiery turtle
#

Nice

fiery ice
#

i just don't know if the OS can use it

frank canopy
fiery ice
#

for example, my motherboard exposes the pins for it

frank canopy
#

but either way i want an SBC that i can use normal basic serial to get info out of to then do osdev with

hollow crescent
hollow crescent
#

I see myself designing it like this at least

#

Kernel modules are compiled with the option that prevents the linker from throwing errors if functions are undefined

#

So I don't need to link one kernel driver to have it import another's functions

#

Which means that kernel drivers will be able to have circular dependencies and it would be allowed

#

The only thing that won't, is the kernel

calm latch
slim panther
#

does it have portio?

#

or working acpi meme

calm latch
calm latch
#

So I guess

fiery ice
#

mine doesn't even recognise S5 is even an option (i hope it's bc of the PCI api)

slim panther
#

real

calm latch
calm latch
tired temple
hollow crescent
#

i was talking about dlls as a concept rather than dlls as strictly PE format dynamic library objects

slim panther
#

bro is pushing msvc again ๐Ÿ˜ญ

#

get away with this slop

lofty dragon
#

๐Ÿ’€

tired temple
# hollow crescent i do not use msvc

I meant mechanism behind it. It's not compiler specific. I'm not pushing anything. I am just also thinking on integrating many things and shared my thoughts on the close subject. I'd make it a driver, boot time one, some kind of root enumerator. I'm actually close to start with it.

hollow crescent
#

so like, -lboron if you want to link against libboron.so

#

this works fine for user space but i kinda do not want the kernel to be a "shared object" (because idk if limine supports loading those and im not taking chances)

#

(although i could just create a libboronkernel.so which is literally just the kernel objects in library form and then link against that and serve it relocations from the boron kernel proper actually)

#

(because the modules only remember the names of imported functions and nothing else)

calm latch
#

just have a prekernel trl

hollow crescent
#

i wanted that for a while but just decided not to bother

tired temple
slim panther
#

lmao

hollow crescent
#

okay "phallometric contest" is funny

tired temple
# hollow crescent the way gcc works is you have to explicitly link against a shared object in orde...

yes, elf can't provide real dlls, so if you stick with it, you can't use this useful mechanism for driver intercomuniction. however clang can make PEs. For x86 and arm. And since they added mips pe support as I heard, maybe dllimport is available for it as well. And maybe even for loongarch too, since it's a mips clone. Fortunately, having picked what I really need for the wanted design, I don't have such issues. My issue is the extremely poor ACPI support for arm targets. So I need some kind of dtb engine equivalent to the acpi enumerator for machine topogy discovery. And that fdt is so fkn sucky, so demotivating.

slim panther
#

dtbs are easy

hollow crescent
#

PE DLLs have one feature that ELF shared objects don't have though which is that function imports are tied to a DLL within an application/DLL

#

while ELF just has a list of SOs that need to be loaded

tired temple
# slim panther dtbs are easy

Because they don't do anything. Without "bindings" they are just nothing. And those bindings in fact mean "just write a specific driver everytime for eachndevice". Still you won't have such nice things as s states transitions anything that aml does. Dtb are crap.

slim panther
#

dtbs are a solution for a different problem

#

they just describe a device

tired temple
tired temple
# slim panther dtbs are a solution for a different problem

Yet you don't get an equivalent for "everything else" dtbs are incapable of on dtb supplied machines. You just get this garbage dtb full of linuxisms and nothing working even in the stock linux. try to get an arm sbc with suspend to ram or hibernation. On freaking "power saving arm" platforms. You can fry eggs with them and linux. This is how it works without having acpi they are so arrogant towards. With the fdt pulled off cluelessly from openfirmware without much thinking.

slim panther
#

that's why x86 is the only real platform

tired temple
slim panther
#

what?

#

where does rh come in here

tired temple
jaunty fox
#

the alternative is to use that linker option that ignores undefined symbols

#

but i don't like that one

vast kestrel
#

the power button works on my laptop without needing an EC driver Smuggy

#

and its a really new laptop, so its quite surprising

#

there are some aml errors, not sure if its related to the ec or not, but I am gonna write an ec driver regardless

trim frost
fiery turtle
vast kestrel
#

But one of them is the bat0 complaining about undefined in op

fiery turtle
#

ah ive seen this already

vast kestrel
#

Now I checked the aml (I can send you later) but it does actually properly check for _REG in EC being called

fiery turtle
#

this is basically untested code brecause no ec driver

#

so it hits a path with undefined local

vast kestrel
#

Yeah but it's weirder

#

There is no ECDT

#

And this doesn't happen in Linux

fiery turtle
#

yeah but u run _REG before initialize usually

#

this is why it works fine

#

anyway yeah send the dump

#

but i think one of mishakov's laptop is like this

vast kestrel
#

Is there a chance you run _REG by accident with default handler?

fiery turtle
#

nope

#

there isnt a default handler for ec

vast kestrel
#

I'll check it again later then, I looked at it quickly and I didn't see it make a mistake, but I haven't looked too deep

fiery turtle
#

u say it checks for ECAV

vast kestrel
#

Yeah

fiery turtle
#

this is what ive seen on mishakovs laptop as well

#

but in the else

#

it forgets to initialize a local

vast kestrel
#

And it sets it in _REG

fiery turtle
#

so its undefined

vast kestrel
#

Could be then

fiery turtle
#

and then it uses it

vast kestrel
#

I really haven't looked too deep

#

But wait, if there is no ECDT, how does that work

fiery turtle
#

its a common untested thing they have in BAT0._STA

vast kestrel
#

Yeah it might be the same

#

Was it a Lenovo?

fiery turtle
#

linux doesnt call BAT0._STA because it knows it has no _INI since ACPICA does subtree prescan to speed up namespace_initialize()

#

basically its a cosmetic issue

fiery turtle
vast kestrel
#

I see

fiery turtle
#

but yeah u can just paste the code here later

#

to verify

vast kestrel
#

It is really weird to me that there is no ECDT tho

#

Like, when am I expected to install my own drivers?

fiery turtle
#

i mean not all laptops need early EC

vast kestrel
#

Yeah but the _STA needs it technically

fiery turtle
fiery turtle
vast kestrel
#

Ok so I am doing it in the right place

fiery turtle
#

when BAT0 driver is being probed

#

at that point EC is already live

vast kestrel
#

Wait so why do you call it?

fiery turtle
#

during namespace_initialize it expects all _INI to be called

#

_INI can only be called if _STA returns 0xF

#

and u cant go into child namespaces if _STA failed

#

so u kinda have to

#

or u can pre-scan to know what subtrees u can skip

#

but i just dont do it because its fast anyway

vast kestrel
#

I see

#

Is that what windows does as well?

#

Like, running untested acpi code paths is a bit scary 3sGudaEhehe

fiery turtle
#

u mean would windows call _STA there?

vast kestrel
#

Yeah

#

And it's not like it's a missing ec driver, it doesn't provide ECDT, so it would happen on windows as well

fiery turtle
#

it would probably have an EC driver at that point, but I doubt it has any sort of advanced tree pre-scan

#

windows just doesnt do any advanced things with aml

#

would be interesting to check I guess

vast kestrel
#

But it won't since the firmware doesn't provide ECDT you can't install the EC driver before initialize

fiery turtle
#

technically

#

the namespace is already loaded at that point

#

so u can find the EC device

vast kestrel
#

Yeah you could install the driver

fiery turtle
#

no one knows what order the windows driver does it

vast kestrel
#

But is that what I should do

#

Tru

fiery turtle
#

id have to re-check the code

#

but i should experiment to see what widnows does in this case

vast kestrel
#

Btw for the love of god can you add to the osdev docs the set interrupt controller function? I forgot it's name and had to search all the header files for it 3sGudaEhehe

fiery turtle
#

lol

#

yeah

vast kestrel
#

And given it's a pretty important part of the acpi init it could be helpful

fiery turtle
#

its in utilities.h

vast kestrel
#

Also I feel like the namespace iterations are missing a few docs, like I couldn't figure out of find_node gives you an existing reference or if you need to unref it (from the code it seems like an existing reference)

#

But if it gives an existing reference can't it be a bit dangerous?

fiery turtle
#

namespace nodes are permanent

#

u cant ref or unref them with public api

vast kestrel
#

I see

fiery turtle
#

but yeah a comment would be nice

vast kestrel
#

Right now the problem I had is that the second ec resource had a type of zero, so I might have a bug somewhere in there

fiery turtle
vast kestrel
#

Yeah I saw that

fiery turtle
#

aka only exist if theres currently aml being executed

vast kestrel
#

All the temporary node stuff

fiery turtle
vast kestrel
#

I am using the get_current_resources, which returns length + entries

#

I check the length >= 2, the first resource is IO as expected, the second has a type of zero, which idr what it is

fiery turtle
#

0 is IRQ

#

from the looks of it

vast kestrel
#

Yeah, and I looked at the aml and it doesn't have that, so probably did something funny in my code

fiery turtle
#

resources are variable length

#

2 means 2 bytes

#

not two resources

vast kestrel
#

Wait

#

But it returns an array of resource pointers?

#

it's uacpi_resources

fiery turtle
vast kestrel
#

Ok fuck

#

Ok ok I see how the api is supposed to be used

#

Lmao

#

more docs plz

fiery turtle
#

i tried to hint it by doing resources[]

#

or maybe not

#

yeah it needs a comment

vast kestrel
#

Nah, I would probably do the same

#

Might be worth a comment, but if I looked more than two seconds at the struct it would also tell me what I did wrong :^)

#

You just saved me from adding heap guards and expecting a bug with the allocator

fiery turtle
#

lol

#

to be fair that macro is also 1 line above the struct

#

btw it might be easier to just uacpi_for_each_device_resource

#

that does free on its own

#

u dont even have to keep a pointer

vast kestrel
#

It probably is

#

I haven't seen that, will def use it

fiery turtle
#

uacpi_for_each_device_resource(dev, "_CRS", lambda, ctx)

#

there's also uacpi_for_each_resource for an already existing resource buffer

vast kestrel
#

Yeah uacpi had a lot of helpers, really nice to use it

#

Even better when using it correctly

#

:^)

fiery turtle
#

thx

dense steppe
hollow crescent
#

(Although it's possible (but slim chances) that there is no need for UACPI to use the HAL or the HAL to use UACPI)

#

Also why would I not want to link uACPI with the HAL? LARPing purposes

dense steppe
#

because the kernel depends on the HAL

hollow crescent
#

yes

dense steppe
#

the HAL needs ACPI tables for initialization (MADT, etc)

#

and ACPI needs the kernel for memory allocations, IRQ handling, etc.

hollow crescent
#

if I really didn't want to have circular dependencies then I could ship my own implementation of ACPI tables for the HAL

#

in fact, I already do that

#

but this is a very good point. if uacpi and hal depend on each other what's the point of them being separated?

fiery turtle
#

btw uacpi has a mode that strips all code but table managment

#

u could reuse that

dense steppe
#

two uACPIs in one kernel? ๐Ÿคฏ

fiery turtle
#

lol

fiery turtle
hollow crescent
#

but nah

fiery turtle
#

we'll see what happens

hollow crescent
#

so a couple options

  • build in uACPI with my HAL (no separating the two)
  • the HAL and uACPI are circularly dependent (de facto no separating the two and only for larp purposes)
  • the HAL comes with its own ACPI table parser and uACPI doesn't directly depend on the HAL (the two can be separated but there is code redundancy and my ACPI table parser is probably inferior)
fiery turtle
#

What is LARP

fiery turtle
hollow crescent
hollow crescent
#

Pretending to be something you're not, in this case

fiery turtle
#

Does windows have a mode like this

hollow crescent
#

Just in case

hollow crescent
fiery turtle
hollow crescent
#

I know you can disable the ACPI shutdown and have it show the "It's now safe to turn off your computer" screen in the latest Windows 11 but I'm not sure that disables the entirety of ACPI

hollow crescent
#

Or you can just omit uacpi.sys from loading

fiery turtle
#

Like that would probably disable all of PCI and i2c as well

#

Potentially USB

hollow crescent
#

Why would it disable all of PCI? You can scan PCI devices the brute force way

#

By scanning every bus, slot, and function

fiery turtle
#

You can ofc lol, but I doubt windows has a brute force scan fallback

#

Its not safe either

#

Probing bogus busses might hang some controllers

hollow crescent
#

ah

#

I see

fiery turtle
#

In this case it also has to trust bios for bar window allocation

#

Which is probably fine but yeah idk

hollow crescent
#

It has to trust the firmware for a lot of things anyway

fiery turtle
#

Yeah basically it cant check any resource collisions

vast kestrel
#

what would be better, micropython + ipython shell, or a C like repl shell

#

both would have full access to uacpi functions and what not

fiery turtle
#

Python is probably way more powerful

vast kestrel
#

it would require some ffi glue but yeah

loud ice
#

also micropython is quite annoying

vast kestrel
#

no idea

loud ice
#

what about kuroko :^)

#

its also a better language

vast kestrel
#

"Kuroko's Basketball is a Japanese sports manga series written and illustrated by Tadatoshi Fujimaki"

loud ice
#

lol

#

its klange's not quite python

#

with sane variable binding rules

vast kestrel
#

its something someone on the server made?

#

is there a way to tell limine to use the highest resolution available? it annoys me that it doesn't use full screen on my laptop

fiery turtle
#

its likely that your laptop doesnt provide an edid via uefi

#

so limine just picks whatever is safe

#

although laptops usually do provide it so idk

vast kestrel
#

in the limine screen it is full, in the os screen it is not

#

or is this a flanterm thing

fiery turtle
#

limine probably doesnt do modesetting

#

and default gop is native res usually

#

but idk ask mint

vast kestrel
#

ever since the discord was killed its a bit harder to ask limine questions

trim frost
#

updated score on i5 12400f

vast kestrel
#

tru

lofty dragon
#

and no Limine itself doesn't do modesetting, it uses GOP or VBE

vast kestrel
#

tbf I rarely need limine help because it just works Smuggy

lofty dragon
#

if you use a proper allocator you can get full screen

vast kestrel
#

ooooooo

#

ok

#

then ill do that

#

thankss

lofty dragon
#

np

vast kestrel
#

@fiery turtle yeah its the exact same thing with the local not being initialized

fiery ice
vast kestrel
#

you will need to destroy the context and create a new one

torpid root
fiery ice
trim frost
#

and schedule stuff is unimplemented

lofty dragon
#

you have to create a new context

torpid root
#

@fiery turtle will anything break if I noop in spinlock/mutex acquire/release until the scheduler is initialised?

#

I assume it would not

fiery turtle
#

should be fine

frank canopy
#

further resource type support pushed to zuacpi

#

as well as actually accepting the existence of alignment in resources

fiery turtle
#

nice!

frank canopy
#

it now has enough resource types to handle everything that q35's acpi tables gives me

hollow scaffold
#

I love this project

frank canopy
#

(plus an nvme controller on top)

vast kestrel
#

I spent the entire day rewriting the threading and sync code because I thought I had a bug in it, only to release I got the order of the data and command port wrong in the CRS AMfacepalm

vast kestrel
#

I still have a bug in the scheduler tho, waking a thread from interrupt doesn't wakeup the core to actually run the thread I woke up Smuggy

fiery turtle
#

At least they're better now I hope

vast kestrel
#

they are simpler

vast kestrel
#

before I had a futex like primitive, and I switched it to just having a semaphore+cond as the primitives instead

#

smh

#

I actually removed a bunch of random from the kernel I based off since I want this to run on older hardware as well lol

#

I still depend on constant tsc, since that is the simplest time keeping, but I am not using tsc deadline for example

#

I use the lapic

fiery turtle
#

nice

frank canopy
#

reminds me i need a futex primitive

frank canopy
vast kestrel
#

yeah, its uacpi-os

#

I will need to implement the workqueue stuff eventually, I am starting to get TODO prints for wait_for_completion nervous_sweat_FB

#

also reminds me I haven't implemented timers at all yet, so there are no timeouts

fiery turtle
#

i wonder where thats called from for u

vast kestrel
#

I added a lid driver

#

so I register a notify

#

I think once I added that it started calling it

fiery turtle
#

ah yeah

vast kestrel
#

would it be more correct to clear the gpe inside of the gpe handler, or inside of the worker thread that handles it ASthink

#

wait I guess I need to clear it at the handler, in case it wasn't for SCI_EVT

fiery turtle
#

depends on the gpe

#

take a look when managarm clears it idr

#

or haiku is probably a better EC driver

trim frost
#

what's fixed event 3?

fiery turtle
#

see the enum in event.h

vast kestrel
#

sleep button I think

trim frost
#

yeah i get an error that that failed to enable when booting from my laptop and it makes sense

#

thanks

fiery turtle
#

u get a sleep button event?

vast kestrel
#

he tried to install a sleep button event

#

but it failed

fiery turtle
#

sleep button is routed via notify probably

vast kestrel
#

I think uacpi has some method to check if a specific fixed event is present in hardware

fiery turtle
#

its a bit in fadt

vast kestrel
#

oh wait no I confused it with uacpi_fixed_event_info

#

it has different stuff

trim frost
#

10883 ops lol

vast kestrel
#

ok I finally got to getting the query value from the EC

#

I now need to call QXX or something right

fiery turtle
#

_QXX

vast kestrel
#

It's doing stuff AmeliaEyes

#

I need to add the schedule work tho now

#

So sadge lif

fiery turtle
#

damn very cool

#

also first time seeing hardware with multiple GPE blocks

vast kestrel
#

Nice

#

It's called Intel ultra for a reason :^)

fiery turtle
#

tru

#

does it also not have S3?

vast kestrel
#

SS3 is set to zero it seems

fiery turtle
#

modern standby crap

vast kestrel
#

it has s4 :^)

#

but yeah pretty cringe

#

when ACPI rejects you

fiery turtle
#

oh yeah _OSC

#

no hobby os using it so far

vast kestrel
#

there are a ton of debug prints in this aml ngl

#

I think most of it is from a template being replicated for each root port tho

fiery turtle
#

fair

vast kestrel
#

ok time to implement the work queue thing

leaden fox
leaden fox
#

thx

hollow elm
#

did a bios update on my laptop and unfortunately there are no acpi table changes

#

or well, two tpm-related addresses changed, but no logic changes unlike the previous bios update

fiery turtle
#

because its already flawless clearly meme

hollow elm
#

yeah meme ```
[ 1.046741] ACPI Error: AE_NOT_FOUND, While resolving a named reference package element - _PR_.P000 (20240827/dspkginit-438)
[ 1.046762] ACPI: _TZ_.THRM: _PSL evaluation failure
[ 1.046792] ACPI: thermal: [Firmware Bug]: Invalid critical threshold (-274000)

fiery turtle
#

oh well

hollow elm
#

i assume the philosophy is the classic "if it boots windows it's good enough"

fiery turtle
#

windows also doesnt resolve named references in the interpreter

#

so maybe it works in the windows workflow somehow

vast kestrel
#

It worksssssss

fiery turtle
#

niice

fiery ice
#

wait, how did you detect the lid change?

vast kestrel
#

Also bonus thing, clicking the power button prints a process list

vast kestrel
fiery ice
#

oh cool

vast kestrel
#

It triggers a notification on a change and you can query it

hollow elm
vast kestrel
fiery ice
#

thx

fiery turtle
vast kestrel
#

it does need the EC in my case, but yeah

#

the problem is

#

that I fucking hate PS2

fiery ice
#

XD

#

PS2 is needed unfortunately

vast kestrel
#

especially with how they also mixed in the EC to it

#

its just a bunch of cancer to deal with correctly

#

I have no idea how my keyboard is connected on this laptop tho

#

the touchpad is i2c

#

from what I seen

hollow elm
#

ps/2 kbd and i2c touchpad seems like a common arrangement

vast kestrel
#

oh also I didn't actually implement the ec address space operations lol, since they were not needed yet

fiery ice
#

keyboard is prob ps2

hollow elm
#

that's how it is on my laptop

fiery ice
#

same

frank canopy
#

yeah its ps2 on my laptop as well

vast kestrel
#

its so freaking cancer

#

how am I supposed to know when stuff is keyboard and when stuff is ec

hollow elm
vast kestrel
#

the fuck is this

hollow elm
#

virutal

fiery ice
#

XDD

frank canopy
#

lmao

#

its an intel usbgpio device obviously

fiery ice
#

wtf is an intel usbgpio lol

hollow elm
#

drivers/usb/misc/usb-ljca.c

#

it looks like it's an internal usb device that has an i2c, spi and gpio controller?

#

good shit

#

i hope i can some day get the same crack that hw engineers get

vast kestrel
#

dafuq

#

why

#

whats wrong with the pch

#

the lpc exists for a reason

#

anyways I guess to actually continue and add a proper shell I will need an actual ps2 driver

#

sad lif

fiery turtle
#

make a uPS2 while you're at it meme

vast kestrel
#

glhf

#

ps2 is just too cancer

vast kestrel
#

Tho is uAPI a thing now

#

Did you ever continue working on it

fiery turtle
#

we collectively abandoned it

#

we decided its not worth it

vast kestrel
#

Sadge

#

So each driver should just request what it wants

#

With its own api

fiery turtle
#

basically

vast kestrel
#

At least lto is a thing

fiery turtle
#

attribute alias as well

vast kestrel
#

The main annoyance with PS2 is the fact that there is a lot of weird synchronization between the keyboard and mouse

#

And I think the data port is shared between the EC and PS2

#

Command port is different tho

fiery turtle
#

how would they synchronize it

vast kestrel
#

Like, verify me if I'm wrong, but from what I seen 0x64 is the data and 0x66 is the command for the EC on my PC, and PS2 is 0x64 data and 0x60 command iirc

fiery turtle
#

i mean yeah i think so

#

i just dont understand how that works

#

without race conditions

vast kestrel
#

Maybe if you are fully interrupt driven it won't fire multiple interrupts (?)

#

Or well, how does it know when you are done

fiery turtle
#

technically EC is entirely event driven

#

and irq driven

#

so idk

vast kestrel
#

It seems like Linux has multiple layers of abstractions

#

So you have the keyboard/mouse on top of libps2 which is on top of serio

fiery turtle
#

ofc it would have 10 layers for ps2 lol

#

its linux afterall

#

@vast kestrel should we put this kernel in the uacpi org after its done?

vast kestrel
#

Sure

fiery turtle
#

maybe I could add some CI runs at least in QEMU on every commit

vast kestrel
#

I mean define done :^)

fiery turtle
#

whenever u feel like its what u envision

vast kestrel
#

Yeah having some automated tests could be cool

fiery turtle
#

like i have tons of tests but none of them test kernel mode

vast kestrel
#

I want this to be enough to take a random computer and ensure that uacpi works on it with a known good kernel

fiery turtle
#

that would be cool yeah

vast kestrel
#

So if someone comes with some hardware error they can run it first and know if it's expected or not with uacpi

#

It's also why I want to keep the kernel pretty simple

#

Or well, as simple as something that can run acpi can be

#

Btw it seems that the acpi EC in Linux doesn't use any of these stuff, it just works directly against the controller

#

(the libps2/serio that is)

#

Maybe it's up to the controller to ensure it doesn't mix stuff, even tho it would be funny if as long as the EC is doing stuff keyboard doesn't work lol

fiery turtle
#

yeah its probably synchronized at chipset level

#

i like that u use uacpi_snprintf in your kernel

#

i was gonna do that as well lmao

hollow elm
#

if rip in range(windows_ps2_driver_start, windows_ps2_driver_size): dont_do_ec_stuff()

fiery turtle
#

I think both ps2 and ec have a bit that says if there's anything in the data port

#

So that's how they synchronize probably

#

Although I wonder if that means the keyboard hangs if ec is not handled

#

And its most likely also routed via i2c so you don't even have to use ps2

#

So maybe they assume if you have an ec driver u also have i2c

vast kestrel
#

But the keyboard stays as PS2 no?

vast kestrel
fiery turtle
#

But yeah the kernel is shaping up great so far

vast kestrel
#

Yeah I like how it's built, it's relatively clean

#

I need to cleanup the scheduler a little, since right now everything stays on the first core

fiery turtle
#

You could also add support for memory and CPU hotplug in qemu for fun

#

Well and PCI

vast kestrel
#

That could be fun

#

And I can test it in qemu unlike EC stuff

fiery turtle
#

Its a matter of installing notify

#

Yeah

vast kestrel
#

I think implementing most of the standard acpi devices could be nice

#

As a reference

fiery turtle
#

Yeah

#

And AMD GPIO chad

#

To support every way of routing a power button

vast kestrel
#

For a second I read it as AMD GPU 3sCoconaSweat

fiery turtle
#

Mishakov did it for his kernel

vast kestrel
#

Nice

fiery turtle
#

Its not that big of a driver

vast kestrel
#

90% of GPIO drivers is a bit mask of config and data :^)

fiery turtle
#

Yah

vast kestrel
#

Intel chipsets have a ton of stuff to route GPIO as gpes and smis and scis

fiery turtle
#

There's also GED on riscv

#

Which is like EC but simpler

vast kestrel
#

Having the kernel be multi-arch would be interesting

fiery turtle
#

Definitely

vast kestrel
#

Hardware reduced acpi support :^)

#

Well, I am not adding support for other arches so PRs are welcomed AMtoiletspin

fiery turtle
#

Lol

fiery turtle
vast kestrel
#

There is some random, like gpe devices or whatever it was

#

Tho no idea if any hardware actually uses it

fiery turtle
#

The ged yeah, but its 100 lines

#

Once you have all these helpers the drivers just fall into place

vast kestrel
#

I just remembered I wanted to suggest some uacpi helper function but I completely forgot what it was

fiery turtle
#

Lol

trim frost
calm latch
calm latch
leaden fox
#

uUSB when

fiery turtle
vast kestrel
#

Ok I think I realized something, because the command registers are different, it can know if what you are about to write is for keyboard or EC

fiery turtle
#

probably

vast kestrel
#

And assuming that the EC is not buggy, indeed the OBF can be set for either

#

So in the write case if you start a kbd/EC command it will wait for that one

#

And I guess it's the same for IBF

#

Wait no that's different

#

Even tho

#

I wonder if you write to the EC if the kbd will have IBF set as well

fiery turtle
#

that would most definitely break lol

vast kestrel
#

Also what if you write to one reg and then another

#

Because Linux doesn't lock it between them as we saw

fiery turtle
#

i mean u cant write there randomly

#

only if it tells u that its empty

vast kestrel
#

No I mean the command

#

Imagine writing command to EC and then KBD

fiery turtle
#

command regs arent shared

#

so

vast kestrel
#

It can work if that sets the IBF on the second command reg

fiery turtle
#

the order in which the "data full" bit wil be set should be synchronzed

vast kestrel
#

And it stays full until you are done with the other thing

fiery turtle
#

probably

#

like EC is not polled so u just wait for it to tell u via irq

vast kestrel
#

I wonder if there is any open source EC firmware

fiery turtle
#

i remember reading an implementation

#

someone posted a link

#

dont remember where

#

maybe in this thread

vast kestrel
#

I'll search when I get home

hasty plinth
#

the framework laptop ec firmware is open source

#

if thats of any use

vast kestrel
#

yeah that works

#

lets see

#

I sure do like it when the firmware asks a question

#

ok actually all the 3 cases are funny

#

it seems to run once every 1ms

#

which sounds a bit high ngl

#

the output will check if the state allows it to send back keyboard/touchpad/mouse data

#

so while you are doing a command it will not send keyboard data

#

but outside of a command it will

fiery turtle
#

Is there a KBC STATE EC?

vast kestrel
#

nope

#

do we have the acpi tables for System76 laptops?

fiery turtle
#

Maybe its not even shared on the framework

fiery turtle
vast kestrel
#

gib

fiery turtle
#

Scroll up

vast kestrel
#

actually lemme find the EC stuff

fiery turtle
vast kestrel
fiery turtle
#

linux would use the first two probably

#

the rest are just for bookkeeping

#

is 62/66 shared with kbd?

hollow elm
#

ps/2 uses 0x60 and 0x64

vast kestrel
#

nope those are not shared

#

maybe I was dreaming

#

hold on

#

yeah skill issue on my side AMfacepalm

#

its 0x62 as well

#

I remembered 0x60

#

ok so there is actually no problem

#

nice

#

does it actually use the GPIO instead of SCI on the system76 laptop?

hollow elm
#

if it's an amd laptop that's not unlikely

#

me and @calm latch have laptops that wire the power button through the amd gpio gunk

vast kestrel
#

ok so there is no problem with ps2 and ec, just me being completely blind

#

so time to add a ps2 driver for fun and profit

#

one thing I do wonder is how the ec handles the mouse stuff

hollow elm
#

wdym? if the touchpad is i2c it doesn't go through the ec

vast kestrel
#

wait fuck yeah it won't do the dual port mouse in there

hollow elm
#

you need an i2c controller driver and it just uses hid over i2c

vast kestrel
#

I was hoping to see how the controller handles it when ps2 has two devices Sad

hollow elm
vast kestrel
#

it seems on my laptop the i2c controllers are discoverable over pci/pcie

#

anyways I don't need mouse for this, keyboard is enough

hollow elm
vast kestrel
#

yeah it has a node in the AML

#

but that is standard PCI stuff

#

@fiery turtle is there some helper to lookup a pci node under a pci controller device?

fiery turtle
#

Nop

#

Your i2c mouse probably has ps2 emulation anyway

vast kestrel
#

ps2 emulation is turned off when you enable acpi

trim frost
#

my i2c touchpad didnt have ps2 emulation even before i added acpi to my kernel

vast kestrel
#

@fiery turtle do I need to call the _STA myself to ensure that I can deal with the device?

#

or well, that it exists

vast kestrel
#

for example in the acpi driver dispatcher

fiery turtle
#

uacpi_find_devices checks automatically

#

everything else u have to check yourself

vast kestrel
#

so because I am using uacpi_namespace_for_each_child I need to call _STA myself

#

got it

fiery turtle
#

in the main dispatcher u can just use uacpi_namespace_node_info

#

or actually, that doesnt have sta but yeah

#

sta u check yourself

#

uacpi_eval_sta

vast kestrel
#

ok cool

#

should I first check _STA and then HID/CID or the opposite ASthink

#

I feel like first check _STA

fiery turtle
#

_STA first, then namespace_node_info

#

which collects everything there is about a device

#

then u can just give that struct to probe for example

#

including uid, hid and cid

#

uacpi_get_namespace_node_info

vast kestrel
#

oh I just now noticed that the node info has the cid and hid

#

I called the others manually until now lol

fiery turtle
#

yeah u dont have to

vast kestrel
#

I used it to check if it has an hid and then called the eval manually

#

lmao

fiery turtle
#

theres also eval_{hid,cid} if u really want to do it manually

vast kestrel
#

yeah that is what I did

fiery turtle
#

u could also just unconditionally eval it and check against UACPI_STATUS_NOT_FOUND

vast kestrel
#

meh

fiery turtle
#

it cant collide with aml errors because aml errors have a separate enum value

vast kestrel
#

I already use the info so why not

fiery turtle
#

yea

trim frost
#

how can i get battery info from uacpi?

vast kestrel
#

there is acpi smart battery

fiery turtle
#

look at managarm

vast kestrel
#

heyyy ps2 works

#

ngl

#

its really clean to have ACPI as a device bus

#

you just see devices and initialize them

fiery turtle
#

nice

#

ultra progress this week: I made an atomic.h header

#

uacpios progress: full scheduler, work queues, every acpi driver in existance, allocators

vast kestrel
#

Tbf it helps to not care too much about performance or scalability

#

The sync primitives I made are based on go, so it's not too bad

slim panther
#

is it normal for hw to time out or is that my fault?

left orbit
#

bro flanterm looks so good

vast kestrel
#

most likely your fault

#

especially for changing modes

fiery ice
left orbit
#

i'm built different

slim panther
vast kestrel
#

lets see what uacpi does exactly

#

yeah it just writes an smi and waits for the mode to change

left orbit
#

it just pokes fadt registers

north hull
slim panther
#

no

left orbit
#

oh it writes an smi register

#

nvm

vast kestrel
slim panther
#

light sensor

north hull
#

ah

left orbit
#

makes sense

#
    [UACPI_REGISTER_SMI_CMD] = {
        .kind = REGISTER_KIND_IO,
        .access_kind = REGISTER_ACCESS_KIND_NORMAL,
        .access_width = 1,
        .accessors = { &g_uacpi_rt_ctx.fadt.smi_cmd, },
    },```
vast kestrel
#

it waits for the SCI_EN to be set

left orbit
#

so either your io kernel api is broken or fadt is garbage

#

i'm guessing the first one

#

bro WHATWEASJITYGSEROJHSRDOIJFUK

vast kestrel
#

lmao

left orbit
#

OH

#

OMG

#

wait

slim panther
#

?#

#

that's not there

#

anymore

left orbit
#

which branch am i supposed ot be

#

looking at

#

๐Ÿ˜ญ๐Ÿ˜ญ

slim panther
#

remove-talc

left orbit
#

THANK god

#

where tf is ur io_read

slim panther
#

arch

left orbit
#

bruh

#

this guy๐Ÿ’€

#

also ur not returning a handle

slim panther
#

well what tf am i supposed to return

#

0?

left orbit
#

u need to know

#

the base and length

#

well, the length might not be that important

slim panther
#

idfk what this function does man

left orbit
#

but the base yes

slim panther
#

i keep forgetting

left orbit
#

uacpi might map with base>0

#

and u need to keep track of that

fiery ice
vast kestrel
#

io_map takes the base, and io_read reads from the mapped relative to the mapped

slim panther
#

the io_map functions

vast kestrel
#

so if it maps 0x100, then read will read 0 to read the 0x100 port

left orbit
#

it's base+offset for io_read

fiery ice
#

for x86_64 basically nothing

vast kestrel
#

or will read 1 to read 0x101

left orbit
#

like ts so simple man

slim panther
#

oh yea i forgor to do this

fiery ice
slim panther
#

smh

left orbit
#
#[unsafe(no_mangle)]
extern "C" fn uacpi_kernel_io_read8(
    arg1: uacpi_handle,
    offset: uacpi_size,
    out_value: *mut uacpi_u8,
) -> uacpi_status {
    unsafe {
        (*out_value) = asm::read8((arg1 as usize + offset) as u16);
    }
    return UACPI_STATUS_OK;
}```
#

how did u implement it correctly

#

and then say

#

idk how it works...

#

also io_map/unmap should be arch specific too in that case

fiery ice
#

that is io_read

left orbit
#

no shit

#

i can read

#

but he uses the handle

fiery ice
#

ah

left orbit
#

and he never initializes it

#

he uses the handle as if it was the base

#

just like many kernels do

fiery ice
left orbit
#

if u wanna be cool then ```rs
#[unsafe(no_mangle)]
extern "C" fn uacpi_kernel_io_map(
base: uacpi_io_addr,
len: uacpi_size,
out_handle: *mut uacpi_handle,
) -> uacpi_status {
let io_window = Box::new((base, len));
unsafe {
out_handle.write(Box::into_raw(io_window));
}
return UACPI_STATUS_OK;
}

and then u can do bounds checking in io_read{8,16,32}
#

or you can just out_handle.write(base as uacpi_handle);

fiery turtle
slim panther
#

anyways

#

yes works now

left orbit
#

๐Ÿ—ฟ

#

nice

#

i'm assuming that "now" means after implementing io_map properly?

slim panther
left orbit
#

epic

fiery turtle
#

so basically previously u would write to random io registers

#

causing ur hw to do absolutely random shit

#

lol

slim panther
#

wow on the fw13 there are 0 acpi warnings or errors

left orbit
#

who would've thought that actually implementing kernel apis would make things work

vast kestrel
#

I think my battery is low :^)

#

It started spamming these notifications

#

Also when connecting to power it gave a response to the query that aml doesn't have a handler for ASthink

fiery turtle
#

Lol

fiery turtle
vast kestrel
#

every few seconds

#

like 2 seconds or so

fiery turtle
#

That's probably fine

#

Just discharge

vast kestrel
#

yeah yeah

fiery turtle
#

So u don't get a notify when plugging in?

vast kestrel
#

lemme quickly fix so it won't throw on it but warn instead

#

and see what it tried to call

#

Q37 and Q38

#

they were called

#

but they reference something that doesn't exist?

#

actually it doesn't have the same error as what I had before

#

oh wait

#

maybe because I threw in from this it caused the entire thread to abort

#

idk

#

anyways it seems to be working, and the PNOT not exists is true, its not defined anywhere

#

but its after the entire handler

#

or well, in Q38 its in the middle

#

I should add the smart battery device

#

but no first keyboard and shell

fiery turtle
vast kestrel
#

nope

fiery turtle
#

wh yis there a _Q4f lol

#

do u not upper case them

vast kestrel
fiery turtle
#

maybe SSDTs

vast kestrel
#

yeah I do it lower case think

#

wait is that a problem

fiery turtle
#

aml names are upper case so yes

vast kestrel
#

ok that probably explains the not found I had later

#

where did you even see 4f

fiery turtle
#

yep

vast kestrel
#

OHOHOH ok now I see it

#

that is what that failed before

#

and because I exited the thread from the failure it didn't continue to the other handler

#

ok time to fix