#uACPI - a portable and easy-to-integrate ACPI implementation
1 messages Β· Page 4 of 1
ub
or more like
stuff that you wouldnt expect from your program
also the lto is enabled by default
some might find that to be nice, but it tends to be too good
also clashes with inline assembly nuking half of the symbols from the binary :^)
but that is most likely a zig bug, hopefully fixed in the future
and of course the compiler is very pedantic, for example if a variable is never written to it will emit an ERROR that you HAVE to make it const
or if you have unused parameters/variables... but you can use _ = expr; syntax for that, basically discarding them... which turns into an error if you use them later lol
i hope you can see how that might get a bit annoying after a while
</rant> sorry for hijacking thread :p
Even Linux has a hard time with that
there's a reason it's 0.13, not 1.x i guess
Np lol
Yeah
found some funkiness with pointer const-ness in uacpi apis, zig's translate-c translates const char ** in uacpi_device_matches_pnp_id as a non-const array of [*c]const uacpi_char, which would make sense if it wasn't for the fact it tells zig that uacpi will mutate the array :p
i am going to solve this with a @constCast for now but it would be really nice if you could go over the apis that take read-only null terminated arrays, like uacpi_device_matches_pnp_id does, and make sure it is properly marked as const
Oh yeah that sounds useful
Thanks for bringing that up
happy to help!
c interop from zig is such a chore lol, but i "finished" implementing uacpi support in my kernel, now i discover pcie root buses and ps2 keyboard controllers by calling uacpi_device_matches_pnp_id :^)
Isnt find_devices easier?
But nice
I have an example of usage on the wiki
Also you might be interested in get_namespace_node_info instead of calling matches twice (again examples available on the wiki if you're interested)
Not that what you're doing is wrong, just some suggestions
Strangest uACPI usage I've seen
This guy copied some files and split some of them into other files, rewrote some of it
ucapi
Made his own structures for some reason
And still does the _S5 manual scan from osdev hacks
Outrageous commit names
Folder structure also dumb it's dozens of folders each with one or two one function files in most cases it's disgusting
it's all like that, not just that pr :^)
Indeed
This arsehole also too much of a bastard devoid of scruples to follow the SINGLE requirement of Mit licence
He stripped it our. You can't do that it's a violation
True lol
dmca time 
He didn't do it out of ill intent tho
I mean he does have the repo starred
So probably just doesn't know how these things work
lmao
what a knob
and of course he has a shitty borked BIOS bootsector "bootloader"
Lol
all rights will be reserved!
Starting the Kheap...
Starting the Kheap..
Kheap is getting started...
i WILL steal your code and i WILL reserve my rights!
What the hell
worse code than @dusky glade's code
time for me to randomly rewrite the entirety of uacpi to make it slower
bruh
Finally, the uACPI interpreter reduced from 5k to 50 loc
https://github.com/MirMohammadd/AliNix/blob/main/kernel/Makefile best makefile ever
minor patch
Lol
lol wtf is this kernel
This is some cursed stuff
the description looks AI generated
fr
Yeah it does
So many words that carry 0 information
especially considering his other two repos' descriptions are gramatically incorrect
Like no joke wtf
This code is too shitty to be AI generated
Yeah the code is hand written
ByteSmart-Compiler Public
A compiler which calculates a mathematical/human readable data and convert it to bit code.
Dafuq does that even mean xD
Maybe with copilot
arch/alpha? what the fuck
what the actual fuck is this naming ""convention""
it's just taken from a bunch of other projects
Yeah that^
oh hm, heisen kernel is apparently the old name of alinix? https://uwu.foundation/Q5byAN6.png
From: Heisenberg <[email protected]> that explains the previous name
What the
wtf
wtf
Is this like a meme project or what
And I thought my 2 files were a lot 
Or is this guy mentally ill
yeah i'm thinking this has to be bait
This has 2500 commits
andesaurux is still worse
Brooo
who would spend that much time just to troll
at least this seems to somewhat build and do something
fractals of stupidity
What is that?
a meme kernel made by some Russian child that i have also gotten banned off github 3 times for harassment
Lol
""""kernel""""
it did not actually build
it was just a random mish mash of nonsense
Have you actually verified that this builds 
no lol
Oh
also
Just really weird stuff
nvm "first commit" was misleading
Uhh
grujb????

Wtf
Straight up feels like that one kid who made a shader from scratch, which totally wasn't stolen from cherno O_O
I have lost too many brain cells as a result of this to continue looking at the code
Has to be either a child or mentally ill person
"Hey I'll give you my solution, just don't straight up copy it"
"Yeah sure I'll change some things"
Changes only the filename
why the fuck does it have a Makefile.am that isn't automake and there is no autotools usage that i can tell
this is literally just random shit
Im actually laughing out loud lmao
lol
This shits insane
abbreiviation fail
how did you even find out about this
This guy starred uACPI and has a fork apparently
I just saw it
ah
Lol
ok good my kernel isn't here
I read ToaruOS as "A certain OS" O_O
so @rain nimbus, when you making kernel?
that is indeed why it's called that
There's so many different kernels in this repo lol
Well rn I'm doing some rendering stuff, wanting to make a path tracing based engine using wavelengths for more beautiful renderings 
And then once I'm done with the next two exams I'll go back to finishing HTTP1.1, HTTP2, HTTP3 and TLS1.3 implementations for my secrets manager (well more like a shared library I use in most of my C++ projects). And once I'm fully done with the secrets manager I'll go back to working on the kernel :>
Give it like 3 months, or roughly to august
Then maybe I'm done xD
Hmm, are they toaru fans perhaps :>
warning: struct demoted to opaque type - has bitfield π
translate-c doesn't seem to like that atm
Bitfields aren't a thing in zig?
not really, at least not in the C sense
Damn
zig has it's own packed structs, which is basically a struct backed by a single integer type
but they aren't abi compatible with C
so i'll just have to manually mask out bits from that field it seems Lol
But for native C code this is more convenient
that would be nice
yeah definitely
i wonder how rust handles that
with regards to C interop
oh god the string length includes the null terminator
Yeah
i hope that it's consistent at least, but imo string lengths shouldn't include the null terminator
So that all api that has lengths is consistent and also no empty strings
Yeah I just copied that api aspect from acpica
a bit unrelated but what is the pci host bus "segment"? it seems that they it's not part of the address, what is it used for?
Just another level
Its new in pcie
Look at osdev wiki I guess
It used to be BDF now its SBDF
ahh PCIe stuff, my knowledge when it comes to that is minimal unfortunately
i still access the config space using port io, i should probably work on that!
ECAM is better yeah
looks like i can discover the base address for MMIO from the MCFG table
i need the segment and bus numbers for that..?
and then i can use that address to poke certain device/function's config space
Yeah
should i use MCFG to find the config space base address?
or can i find those using acpi?
uacpi_table_find(MCFG)
so MCFG is the way to go, got it
Ye
and now my PCI addresses should take the segment into consideration as well
Yup
i feel like i can learn a lot by looking at the aml, what do you use to decompile it?
also where i can get a copy of qemu's DSDT? im assuming that's what i need
iasl <file>
ah, iasl
Unfortunately its generated at runtime soo
You have to dump it yourself
Or write it to serial
oh right, it just a table right?
do i just feed the raw bytes of the table to iasl?
well, save it to a file then pass it to iasl
Yup
czapek@raptor-wsl:~/source/zigux$ file dsdt.bin
dsdt.bin: ACPI Machine Language file 'DSDT' BXPC 1 by BOCHS, revision 1, 8389 bytes, created by BXPC 1
czapek@raptor-wsl:~/source/zigux$ iasl dsdt.bin
Intel ACPI Component Architecture
ASL+ Optimizing Compiler/Disassembler version 20230628
Copyright (c) 2000 - 2023 Intel Corporation
File appears to be binary: found 81 non-ASCII characters, disassembling
Table [DSDT] is too long for file - needs: 0x20C5, remaining in file: 0xF3
Binary file does not contain a valid standard ACPI table
Compilation successful. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations```
hmmm
i am dumping sdt_hdr.length bytes starting at the header
Hmm
That should be correct
libmagic says it's an AML file, so there's that
czapek@raptor-wsl:~/source/zigux$ file dsdt.bin
dsdt.bin: ACPI Machine Language file 'DSDT' BXPC 1 by BOCHS, revision 1, 8389 bytes, created by BXPC 1```
Well it just reads the header
It doesn't do sanity checking of length
well thats fair
Can you show the dump code?
const dsdt_table = findTable(uacpi.ACPI_DSDT_SIGNATURE);
if (dsdt_table != null) {
logger.info("DSDT: {any}", .{std.fmt.fmtSliceHexUpper(dsdt_table.?.getData())});
}```
pub fn getData(self: *const @This()) []const u8 {
const hdr: *uacpi.acpi_sdt_hdr = @ptrCast(self.uacpi_table.unnamed_0.hdr);
const data: [*]const u8 = @ptrCast(hdr);
return data[0..hdr.length];
}```
sorry for zig lol hope it's not too much of a trouble
How do you get the pointer to it from uACPI?
var table: ?*uacpi.uacpi_table = null;
uacpi.uacpi_table_find_by_signature(signature, &table)```
and then i pass that table pointer around wrapped in a struct
it works for MADT
Yeah but what is GetData
.
Oh thats wrong
it just constructs a byte slice starting at the sdt header spanning hdr.length bytes
hdr is the header
oh?
U need virt_addr
Hmm yeah I guess, maybe its some zig meme
i cast it to a u8* later
Strange
Do you have the test runner handy?
the uacpi one?
i can clone and build it
czapek@raptor-wsl:~/source/uACPI/tests/runner$ ./build/test-runner ../../../zigux/dsdt.bin
unexpected error: DSDT declares that it's bigger than ../../../zigux/dsdt.bin```
i guess im not dumping enough bytes?
so that should be fine
Yeah
Should, yeah
let me log what im getting
What?
Lol
8389 bytes
OH
i am dumb, let me just log to e9 instead
my print has a length limit...
Lol
that was very dumb lmao
Why do u even have a limit lmao
im using zig's fmt library which needs a buffer to format stuff into
and instead of having a global buffer that's big + a lock around it i just have a buffer on stack
and it cant be too big for obvious reasons
I see
ill see if i can somehow use zig's fmt with some writer thing that will let me avoid buffering
Cant u just byte bang to e9
the dsdt? i am doing that right now
Disassembly completed
ASL Output: dsdt.dsl - 88563 bytes```
wooo
time to figure out how the pci host bridges are defined in there
ohh the bridge's _HID is PNP0A08 but the _CID is PNP0A03, i see
there doesn't seem to be a _CBA anywhere unfortunately
-M q35?
Interesting, someone did mention it existed on qemy
Maybe yours is old or they were wrong
Anyway its not mandatory and mcfg is used as fallback
i am on 8.2.3
9 is the current release
Yeah give that a try
do βtarget-list=x86_64-softmmu
Or you will be compiling that shit for an hour
yeah i was gonna do just x86_64, but qemu takes like a minute for me anyway
or maybe thats with the target list
i cant remember
For all 9k files?
yeah
Are you on a NASA server
Lol
already at 3k
Target list is only 2k files
i am building master so i hope thats recent enough
well then that'd be done in 20 seconds
anyway im at 7.5k right now
ok its done now, lets see
i could try looking into that but i dont think its a well supported zig target lol
aarch64 is bad enough
hmm for some reason the build got stuck at 9401/9437
Nah it was fine
czapek@raptor-wsl:~/source/zigux$ diff dsdt.bin dsdt-9.bin
czapek@raptor-wsl:~/source/zigux$ diff dsdt.dsl dsdt-9.dsl
8c8
< * Disassembly of dsdt.bin
---
> * Disassembly of dsdt-9.bin
no but let me check lol
yeah there is an MCFG table
Damn
sooo lack of _CBA is fine then?
Its not mandatory yeah
alright
Mcfg is the fallback
Unironicallly
a patch to qemu?
It should be 3 lines of code in qemu
Ye
should it be available on i440fx?
Aml objects are sort of typeless in bytecode perspective , or rather methods are transparent
There isnt a method call operator
So its automatically invoked
So method or named object is same thing
Nope, its q35 only
Old chipset is pci only
lol it doesnt work
i think im regarded or smth
if (mcfg_valid) {
printf("adding _CBA %zx\n", mcfg.base);
aml_append(dev, aml_name_decl("_CBA", aml_int(mcfg.base)));
}```
the printf gets printed but the name doesn't appear in the decompiled aml
nvm im blind
Name (_CBA, 0xB0000000) // _CBA: Configuration Base Address
seems to have worked?
time to become a qemu contributor
hmm there is already a method called acpi_dsdt_add_gpex which adds a pci bus device to the aml, and that adds does add a _CBA thing
it's only called for loongarch
i did try without smm and there wasn't a _CBA anyway
Yeah ok
nvm the acpi_dsdt_add_gpex is called from multiple places, including i386 from a file called acpi-microvm.c
also from whatever the hell hw/pci-host is
ah that's where the method is defined lmao nvm
microvm is amazon firecracker
Why the hell is it not called for you
good question! thanks qemu
Lol
i think its because it checks if its q35 or i440fx?
Dont u specify q35
yeah i do
Huh
but q35 builds its own dsdt
Strange
honestly i'm going to leave that for someone who actually knows what they are doing, especially since it looks like i need to send a patch to a mailing list (!!!) and i've never done that before lol
yeah it is trivial, but like you said maybe it's a bug or a regression and in that case the patch is pretty useless
I guess
#define ACPI_MADT_POLARITY_MASK 0b11
#define ACPI_MADT_POLARITY_CONFORMING 0b00
#define ACPI_MADT_POLARITY_ACTIVE_HIGH 0b01
#define ACPI_MADT_POLARITY_ACTIVE_LOW 0b11```
how does that work? why are both mask and active_low 0b11?
spec says
Polarity of the APIC I/O input signals:
00 Conforms to the specifications of the bus (for example,
EISA is active-low for level-triggered interrupts).
01 Active high
10 Reserved
11 Active low
mask is the mask of the bit field
its not some other value lol
value & MASK == ACITIVE_LOW etc
The only "feature" uacpi is currently missing is basically thread safety
and its so fkn boring
but i guess i have to bite the bullet and just do it
namespace & table should be easy to protect with just a mutex
interpreter is more complicated
particularly the only edge cases where something does a CopyObject
Which either needs an RCU-like object replacement thing or some other bs
Anyway, made an issue https://github.com/UltraOS/uACPI/issues/74
@hollow elm btw I finally cleaned up & merged While timeouts
any fuzzer timeout is now considered a bug
also since the test runner with --enumerate-namespace now runs _PRS and _CRS we might uncover new conversion bugs with fuzzer especially against real hw blobs
if fuzzer generates bogus resource lengths or offsets
i do have validation there but i doubt its perfect
i was too lazy to write out a dumper for each resource, but at least it prints out the length
wtf is this
Because you plug it in and play
real
No idea, some legacy standard
In general the idea is that you just plug the hardware and the os can automatically detect it
At least afaik
Like pcie is plug and play since you as the user don't need to configure anything be it in the hardware or the software
unlike legacy hardware which is just assumed to exist or you need to properly configure the ids/addresses for devices
soo im working on mutexes and im a bit unsure
this_id = uacpi_kernel_get_thread_id();
if (mutex->owner == this_id) {
mutex->depth++;
return UACPI_TRUE;
}
since mutexes are recursive i have to do this
but owner is 0 by default
and technically thread_id of 0 is also valid
so there must be some sentinel value that corresponds to no owner
i could just say that 0 is that value, or maybe make it customizable by the client
or maybe thats bad api in general
like i have no idea
why do you give a mutex a owner?
.
ok ACPICA just does this #define ACPI_MUTEX_NOT_ACQUIRED ((ACPI_THREAD_ID) -1)
i think ill just do this as well but make it customizable as well
that does not look correct
how?
that's not how you usually do concurrent algorithms
read: this is definitely broken
what algorithms
well, if the mutex is currently held by yourself, then it ought not to be pulled out from under you
yeah i dont understand
looks correct to me
other than missing relaxed atomic load
if owner is larger than the word size it might potentially be write in progress
but other than that i think its ok
its always one of two values: sentiel no owner placeholder, a valid thread id
well also depth overflow, i should check for that
I mean it's not very atomic that's for sure...
does that matter if owner is less than or equal to word size
but the proper way is to define atomic helpers 
does msvc even have them
InterlockedOrNoFence
lmao
its only used for userspace tests so i dont care to be honest
but odd how?
ACPICA:
/* Support for multiple acquires by the owning thread */
if (ObjDesc->Mutex.ThreadId == ThreadId)
{
/*
* The mutex is already owned by this thread, just increment the
* acquisition depth
*/
ObjDesc->Mutex.AcquisitionDepth++;
return_ACPI_STATUS (AE_OK);
}
0 fucks given
overflow, atomicity
tbh if your thread_id is larger than word size just take the L
nvm
They're atomic operations yet they're not called atomic 
They used the Interlocked word instead xD
welll who cares its just a name\
the meaning is quite clear and the usage is traditional
UUIDs for thread_id would be funny 
bruh
It's just not a commonly used word for the concept of atomicity, that's all xD
except for with msvc I suppose
i don't know of any kernel where there isn't at least part of the thread structure that's always resident and i can't immediately think of any where the thread structure is relocated, so the pointer to it is a reasonable thread id
I don't think anyone has thread_id's larger than 32 bits...
Tbf even 16 bits is enough
until you're like windows and spawn a separate thread for every window regardless and you spawn like 100k windows...
yeah i think a pointer or a 32-bit value is reasonable
i will say i was actually a bit surprised
"atomic read" does return significantly more results than does "interlocked read" searching published articles indexed on google scholar prior to 1986
interlocked is more of a legacy term I guess
enjoy this use of it by the people who invented Mach then
amd doesn't use the term in their amd64 docs
NT does have spiritual lineage to Mach so it's not overly surprising
Shouldn't this be fully offloaded to the implementer?
Also because of single copy atomicity on any sane architecture it's actually completely fine (obviously as long as the size and alignment allow for it )
It will never have a case where you see your own thread id when the lock is taken by someone else because you had to reset it yourself and a thread is in sync with itself (alpha doesn't exist and can't hurt me)
Obviously assuming that the compiler will do it nicely is not the correct thing to do so using a relaxed atomic is the correct thing to do
But Microsoft be Microsoft, and Microsoft loves doing this kind of shit all over
yeah offloading to the OSΒ seems like a good choice
Its more convenient this way, because mutexes are sort of intertwined with AML and this way its easier for me to deal with recursive acquires
Not to mention there's e.g. a global lock that has special acquire semantics
But offloading would work with a few extra helpers on top I guess
I still think the recursive part should be handled by the kernel, it makes sure that if anything strange needs to happen it does
And the global lock works very different to an os lock
Your wakeup is using an interrupt
And tbh that requires very specific semantics from the OS
That uses a combination of events and mutexes
Your primitives should be cond var + mutex
Yeah thats basically what it is
I could even force the os to implement RCU
I just think less is better
no it's not, because the compiler is allowed to break that
Where rcu doesn't make much sense
Yeah that's why I said the nice thing would be to use relaxed atomic, but if you look at Microsoft's code they do that all the time
Yup
If I do a relaxed load I need to force the os to use a specific type for thread id
Of force it to specify an atomic helper to use to load it
you could just
Its just all super annoying
Which stack?
the stack of mutexes you have acquired
That works well for managed mutexes in aml
the one you maintain already
But not the mutexes that could be taken by me or the os
you could just ban those uses from being recursive?
Technically there's still one mutex that is shared by aml and user
So it must be recursive
Or maybe it could be only recursive in AML side idk
But thats a good idea
which one?
_GL
oh global lock?
Yeah
yeah just make it exclusive on the kernel side only
yeah i think this should work actually
i dont even need an owner pointer in this case
and a thread id helper
the only problem is i have to iterate the entire array so it could be more expensive
but aml usually just acquires one mutex
if any at all
so yeah
its not that bad
you can do another thing tho
instead of a thread id
you can use the stack pointer at interpreter entry
as a "thread id"
true
but yeah i think this should be fine
and i can use an atomic load helper for it
since its a pointer
can i run uapci in userspace?
cd tests && ./run_tests.py or compile runner manually with cmake
so i could run uacpi as a userspace driver in my microkernel?
absolutely
your kernel must provide capabilities to map memory or io ports if you're a microkernel anyway
is the irq passed to uacpi_kernel_install_interrupt_handler an ISA irq? or is it just a vector that uacpi wants it to be registered at?
so i would route it through ioapic, right?
taking ISOs into account and all that
if there happens to be one for that irq of course
yeah
thanks!
np!
also one more question, what is the return value of the interrupt handler meant to be?
oh, whether it was handled or not
i guess i can just ignore it if i dont plan on sharing that vector then
yeah its just handled/unhandled
sorry for stupid questions but what is this sci interrupt used for?
is it just a way for firmware/acpi to callback into the operating system?
when like the power button is pressed or whatever
its called the system control interrupt
and its a replacement of the SMM interrupt
its used by the firmware to make the acpi subsystem do something
ah interesting
sometimes its just something simple like power button press
sometimes more involved like a general purpose event to execute arbitrary AML
qemu doesnt generate an sci interrupt for me when i press "power off" in the menu
unfortunate
it does!
then i guess i broke something :p
i call these functions in this order:
uacpi_initialize
uacpi_install_notify_handler
uacpi_namespace_load
uacpi_namespace_initialize
uacpi_set_interrupt_model
i will, one sec
ah i need a fixed event handler
i was expecting an sci at the very least though
yeah, the status bit for the power button must be set
otherwise a SCI is not generated
its a mask register
ahhh that makes sense
let me do that real quick!
woooo
thanks :^)
hmm, repeat power button presses are not generating sci interrupts though
is this some flag i have to clear?
oh wait my kernel seems to have hung
its cleared automatically
yeah then i think something went horribly wrong because all of a sudden everything died lol
qemu might spam it forever, but note that real hardware generally doesnt
there's a timeout before it sends the event again
it waits for the os to enter some sleep state for a bit
wait, does uacpi_enter_sleep_state(UACPI_SLEEP_STATE_S5); perform the actual shutdown?
lol cool
so simple
fair
did you figure out why it hangs? 
nope, but i dont really care since i'm not gonna be scheduling after that anymore 
lol
yeah but like it says there calling these from an interrupt context is really fragile
especially for real hw
it might call like Sleep() or try to grab a mutex
MS even has annotations to prevent you from calling stuff at the wrong irql
linux also with __might_sleep or whatever
ms sal is really cool
yeah yeah my stuff is shit though
also has in/out params and length
yeah
i love the annotations on windows apis
but when i accidentally go to definition of some function
i tend to reconsider my life choices
i wonder who at microsoft willingly decided to sit down and annotate all the parameters
there's probably a policy that you have to annotate them from the start nowadays
usb support, very nice
yeah, qookie and nooby helped me out a lot :^)
i have entertained the thought of trying to do something like that, maybe with, what do you call it
libclang
Okay I think i implemented global lock stuff, now i just need to hook it up to the interpreter and that's it
that will mark the end of missing ACPI-specific features
everything else is done
remarkable work
what will you work on next? ultraOS?
https://github.com/UltraOS/UltraLegacy/tree/master/Kernel looks like it was already a reasonable amount of work done on it
There's still this unfortunately https://github.com/UltraOS/uACPI/issues/74
Thank you
This one is archived, its in c++ and kind of what I used to learn the general idea, im not going to work on it anymore
Either that or igpu 3d driver
you could link up with leo of LiL fame
Lil is focused on modesetting but yeah
as i understand it that's just the beginning
Cool project idea
not necessarily, I'd like to get 3d accel working there too
right now, however, yeah
modesetting comes first 
seems like the kind of thing where collaboration would be the best way forward
Mostly I want to encourage this so that there's a good option for hobby os 3d accel, because I sure as hell can't write a modern GPU driver 
yeah I can definitely see value in that, but lil is C++ and just sort of different from how I would approach this
will see if i even get anywhere anyway
i might make a library similar to uacpi or i might make it coupled to my kernel
@mortal yoke btw if u still work on your acpi interpreter, i now have --large for tests, which runs 354 real hardware blobs against the interpreter
nice, maybe I should try running those
yeah definitely
some of them will run forever for you unless you have while timeouts implemented
do they use loadtable tho? because I still don't have that
nah
speaking of which I also lack ToString lol
LoadTable is only used if you're _OSC'ing advanced capabilities
should be fairly rare
yeah I haven't seen it being used in any of the real hw/virtual machines I have tried it on
β― grep -rn 'ToString' ./ --exclude \*.bin | wc -l
1169
well
looks like its somewhat common
but probably not during init
okay looks like global lock stuff passes the tests
im not yet 100% confident about this pr and interface, but will see
ill definitely test this in managarm before merging
uacpi works on my old ass dell optiplex together with the power button, very nice :^)
Pog
@fiery turtle does the U in uACPI stand for micro or Ultra?
i'm going to address this in the latest PR
as well as bitfields in the public API
since obviously it makes interop kind of annoying
based
I tried it and this is the result 
lol
now I just need to go through the test outputs and look what exactly they are all about
hey you got two of them passing 
actually I realized that I didn't update the test runner's function that gets object type enum from an object variant, that seems to be why a lot of them failed
so Ill run it again and see what the actual number of failures is
try it
not bad
looks like 60 of them are either timeouts, bufferacc being unsupported or using connectfield which I apparently implemented wrong (and idk how should I actually implement it in a good way because the data is stuff that would need to be parsed using the main interpreter so I couldn't just parse the fields in a loop like I do now) and the other 2 were a mistake in the amount of args/locals as I had the counts the wrong way around
well I guess I could like have a new frame type for the field list and then have a separate opcode block table + handlers for that or smth, anyway I probably shouldn't be posting about this in here as this is for uACPI 
Lol
oh man 
i wonder what the heck is my firmware doing that it wants events for
@fiery turtle btw there are a few usages of PRIu64 in source/utilities.c that should probably be UACPI_PRIu64
ffs
i doubt it will actually be used
just make create return something like 0x1
and then panic if its used
thanks
i fixed that and nyaux warning in the PR
im not merging that today but anyway
wtaf
lol
i wonder whats so special about this dsdt that makes uacpi fail
it doesnt seem to be on an error path though, maybe its just some zig stupidity
i think its making your allocator fail
do you know of any tool for windows that can dump the dsdt?
acpidump -b
on windows?
yes
yup
thanks
u always love blaming everyones allocators lol
it is my allocator tho
lol because its almost always the case
but ofc lets see what the test runner has to say
how is it allocating an event in free() code lmao
[uACPI][INFO] namespace initialization done: 295 devices, 0 thermal zones, 0 processors
[uACPI][TRACE] _STA calls: 105 (1 errors), _INI calls: 30 (0 errors)```
yeah looks like it works
it's not, it's just a log from earlier i believe
the error is probably related to an undefined reference (because u didnt load SSDTs obviously)
but other than that looks like it works
u cant, it only accepts one blob at a time
nah
time to look into the god damned allocator
what was the _STA related error?
[uACPI][ERROR] unable to lookup named object '\_SB_.PC00.LPCB.H_EC._STA.^^^GFX0.CLID': not found
[uACPI][ERROR] aborting method invocation due to previous error: AML referenced an undefined object
[uACPI][ERROR] #0 in \_SB_.PC00.LPCB.H_EC._STA()
[uACPI][WARN] aborted execution of '\_SB_.PC00.LPCB.H_EC._STA' due to an error: AML referenced an undefined object```
anyway yeah do that
assert(old_mem.len != 0);

thats the assert it fails on
apparently uacpi passes in a zero size
i guess ill just @min(size, 8) on both alloc and free
hmm i dont think thats a code path that exists
maybe assert that size != 0 during allocation
// 2. Release the object array
uacpi_free(pkg->objects, sizeof(*pkg->objects) * pkg->count);
technically it could that the package is empty ofc
how unlikely is that?
okay so the @max(...) is already done by the allocator

const new_aligned_size = @max(len, @as(usize, 1) << @as(Allocator.Log2Align, @intCast(log2_ptr_align)));
uacpi_bool uacpi_package_fill(uacpi_package *pkg, uacpi_size num_elements)
{
uacpi_size i;
pkg->objects = uacpi_kernel_calloc(num_elements, sizeof(uacpi_handle));
if its indeed an empty package you will see this
send
can i just send it here?
yea
is that a package of size 0?
yup
oh i didnt know the size was right there lmao
i was looking for one with empty {}
sooooo my aml is kinda weird
but thats okay
im just going to align size up to 8 :)
yeah i mean, alloc(0), free(0), should work i think?
well not in zig, here we usually dont allocate 0 bytes for anything lol
yup
yea true, i just never hit that so i didnt think of it
now with that accounted for its time for another bare metal run
thats absolutely giant dsdt tho
this time i enabled memory space access and bus mastering in my xhci driver
its 120k lines of asl
so hopefully? it gives some sign of life
yeah i thought it was a bit of a chonker too
ohh i see
this machine i had some issues with because it has too much memory 
how modern is this hw?
i was getting a page fault inside a page fault and ended up smashing the stack
z790 board
last intel gen
if you want to look at them here u go
thanks
i could add it to the large tests that uacpi runs
as long as that's legal, sure
i mean anyone can dump them i guess
but since they are binaries idk what rules apply to redistributing them
I mean, if this is legal https://github.com/linuxhw/ACPI
right, fair enough
I have a fork of this with some fixes
im glad i can contribute at least in that way
can u do acpidump > res.txt and send that so its more of a standard format
yeah thats definitely appreciated
that dump lacks latest hardware
i mean the repo
lol
oh right i forgot, the allocator interface accepts "log 2 of align" and i was passing the align itself, i fixed that for alloc but forgot to update for free
so instead of 8 i should be passing 3 (1 << 3 == 8)
ofc the god damn scheduler dies, ill tackle that another time, im glad i got uacpi to work
yep, just dies when doing some xhci stuff, presumably because of the scheduler or whatever else
that didnt work but im not sure if it wasnt working or because it was dead
i can try without spawning any thread to rule that out
can u do this btw
all other dumps in that repo are that format so
Control Method Sleep Button (V1) : 1
Control Method Power Button (V1) : 0
yeah should be working as a fixed event
yup works!
Nice!
that was also the case with lai lol
people would complain about heap corruption or whatever
but in the end it was their allocator shitting itself
always blame the tools 
if anyone else wants to volunteer to be a part of uACPI test suite, im open to acpidump > res.txt submissions 
currently have 355 blobs
Thanks
wait
it has some MSDM
table
which apparently contains some windows licensing info
I doubt that matters but u can remove it if u want
Thats probably encoded to only work on your motherboard
I would hope
Yeah not that simple lmao
Yeah doubt
at least you can usually transfer retail windows licenses between pc's (at least when you have signed in with an ms acc)
it's an oem key so it's probably not usable outside the acpi table?
i was just kidding anyway, but people do make it seem that easy
Huh
Yeah but can you use it?
no idea, should i try? 
π
(because I am not going to pay 100β¬ to ms when I can just transfer it from an old prebuilt pc that cost less than that)
Lol
||massgrave.dev||
Anyway oberrow delete it I guess and reupload without that table
Don't forget to send us the output
I mean yeah but I like to do it legally
for educational purposes
or at least what I consider legal enough
.
Yep u can have it
just realised this has the MSDM table
we have the windows installation keys for a couple hundred computers
Probably all 500 public dumps have it
Its ascii
there we go:
Thanks! Were now at 356
What
what are we doing here exactly
Im expanding the test suite
now how do we tell ms to get their shit together and stop putting activation keys as plain text in acpi tables
bru
activation keys in plain text
in acpi tables
π
