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

[fiery turtle]

with most ports

[slim panther]

(besides managarm)

[fiery turtle]

well yes

[kindred beacon]

ofc yes because MAMMOGRAM IS KING 

only semi joking

[torpid root]

Free95 will soon take over

[calm latch]

managram

[kind mantle]

BTW @fiery turtle what happened to the idea of you testing all the ISOs yourself for the leaderboard?

[torpid root]

it's test-by-request

[median crest]

Kinda sent that at 3 am feeling like crap but I still dont want it there

Not giving up just other reasons

[fiery turtle]

Hm okay

[slim panther]

:(

[fiery turtle]

I dont get enough new submissions to care atm, maybe later

[kindred beacon]

honest to god we should just typosquat this with a mirror of managarm that simply has s/managarm/managram/g

[kind mantle]

So I just run the benchmark myself?

[left orbit]

yes

or ask someone else to run it that has already been running tests for the leaderboard

[tacit escarp]

Hey I have a more general question about ACPI
As a side effect of my project, I'm invalidating the effect of the global lock: the global lock no longer provides synchronization between the OSPM and the firmware.
I was wondering how frequently is the global lock really used in modern ASL and firmware nowadays, and whether this synchronization invalidation is relevant?

I looked at uACPI's code, and I did not see any use of the global lock acquiring implementation, which led me to assume the global lock isn't really relevant.

[fiery turtle]

i tried to reply to your email but it was blocked by your proton thing

are you making a uacpi-like project or your own hardware?

I looked at uACPI's code, and I did not see any use of the global lock acquiring implementation, which led me to assume the global lock isn't really relevant.
You didn't look very well i guess

it's acquired whenever firmware accesses a locked field (pretty common) or does an Acquire(\_GL) (less common)

[tacit escarp]

I'm making a project that uses uacpi. It's just software, no hardware

[fiery turtle]

what do u mean by " I'm invalidating the effect of the global lock:"

https://github.com/uACPI/uACPI/blob/a6eb761f267eb83f3f05ef85005b646b23f9e2c7/source/mutex.c#L225 this is where the global lock is acquired

[tacit escarp]

Ah I see. I was looking for calls to uacpi_acquire_global_lock*, but it uses the global_lock_mutex

[tacit escarp]

Are you alright with moving to DM?

[fiery turtle]

this is to prevent the global lock from breaking if e.g. CopyObject(..., \_GL) happens, i have this for a few predefined objects

[fiery turtle]

any reason why this has to be in DMs? Is it like a secret project?

[tacit escarp]

Not secret, I'd just rather keep the internals low key atm until it's done

[fiery turtle]

okay

[fierce kiln]

yo hey uacpi people, this new qemu patch intentionally generates malformed ACPI tables as a workaround for a windows bug

https://gitlab.com/qemu-project/qemu/-/commit/0b053391985#eaf463cffb2377a83b4491abd809d5aa6a314493

here is the patch

it causes this behavior:

unable to lookup named object '���' within (or above) scope '\_SB_.PCI0': invalid AML name string

aborting method invocation due to previous error: invalid AML name string

And it seems like these lines of code from said patch are the culprit

aml_append(ifctx, aml_store(aml_call2("AIDX", bnum, sunum), acpi_index));
aml_append(ifctx, aml_store(pkg, ret));
/*
 * Windows calls func=7 without checking if it's available,
 * as workaround Microsoft has suggested to return invalid for func7
 * Package, so return 2 elements package but only initialize elements
 * when acpi_index is supported and leave them uninitialized, which
 * leads elements to being Uninitialized ObjectType and should trip
 * Windows into discarding result as an unexpected and prevent setting
 * bogus 'PCI Label' on the device.
 */
 ifctx1 = aml_if(aml_lnot(aml_lor(
                 aml_equal(acpi_index, zero), aml_equal(acpi_index, not_supp)
          )));
{
    aml_append(ifctx1, aml_store(acpi_index, aml_index(ret, zero)));
    /*
     * optional, if not impl. should return null string
     */
    aml_append(ifctx1, aml_store(aml_string("%s", ""),
                                        aml_index(ret, one)));
}

uacpi is correct for rejecting this and throwing the error but yea qemu ppl wrote some stuff that caused that to start happening, just putting this out there in case anyone else runs into this issue

qemu versions 10.0.3 and later are affected

[crude summit]

so much for qemu following the spec to the letter. imho such "features" in qemu should have toggles.

[fiery turtle]

Nah I dont think thats what it is

This makes a package, and uACPI seems to encounter a bogus name

Have you verified that this is actually what happens and this commit is at fault?

Also you're saying you call _DSM in your code?

I'm afraid that uACPI error is a bug in your code, not qemu generating malformed acpi

That patch just makes it return an empty package from _DSM to signify lack of support for some feature

[crude summit]

so, i know why uACPI was so slow in its 'benchmark' figure on init, its my allocator

my allocator is always O(n), correctness over speed. if i want speedy, i'd need to give uACPI its own allocation algorithm thats faster

[kind mantle]

O(n) where n is allocation size, or where n is allocation count?

Either way, that's slow enough you probably don't want to use it at all.

[fierce kiln]

I only encounter this bug on the one machine I have that uses the latest uacpi version

it only recently started appearing

before this version nothing was wrong

and I reverted to a known good commit and the bug was still here

it kind of doesn't make sense how this bug would start appearing when reverting to a known good version that used to work, but doesn't work on this new version

[crude summit]

allocation count

it doesnt matter for the most part, most of my stuff doesnt just indiscriminately call kmalloc()

[fierce kiln]

yea i reverted all the way back to a commit that i made from this machine on the new qemu version (meaning it should've worked fine) and uacpi is encountering this error

it works fine in CI/CD

nothing goes wrong there and that's on the older qemu versino

i'll try an OS that couldnt have broken code then

i'll try and boot managarm

[mortal yoke]

I don't get anything like that with uacpi on qemu 10.0.3

if you want something small to test

[fierce kiln]

hmmm yeah it seems ok with your image, i did notice that my logs show a different RSDP address from yours

[fierce kiln]

ohh yeah you're using a custom acpi parser

neat

ok yea my hunch is that something odd on my side is happening then, i'll see if this same behavior happens on linux x86 hosts running 10.0.3, since this is on my mac and it might be different here

I believe my other intel mac is using 10.0.3 since it runs arch which likes to run newer versions of packaegs, and it worked fine there, but i'll go home and double check (in a few days)

👍

[slim panther]

👍

[crude summit]

[0]: [uACPI] successfully loaded 1 AML blob, 1760 ops in 4ms (avg 375496/s)
[0]: [uACPI] namespace initialization done in 2ms: 44 devices, 0 thermal zones
[0]: init_uacpi done. Peak allocation: 259648 Current allocation: 240128

i should enter for your chart on the github.

processor       : 31
vendor_id       : GenuineIntel
cpu family      : 6
model           : 45
model name      : Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz
stepping        : 7
microcode       : 0x71a
cpu MHz         : 1200.000

[fiery turtle]

Yes

[fiery turtle]

i know grep is a very difficult tool to learn

[fiery turtle]

bro like

its literally the same exact fucking name

with a different suffix corresponding to the type

how can u be this bad at searching code

[sterile egret]

lmao

just ban him from the repo

[crude summit]

can i enter that figure onto the chart, how do i do so? do i just raise a PR?

[fiery turtle]

https://github.com/uACPI/uACPI/issues/135

[fiery turtle]

lol

[crude summit]

i just improved my allocator a bit more 😄

[0]: [uACPI] successfully loaded 1 AML blob, 1760 ops in 3ms (avg 441329/s)
[0]: [uACPI] namespace initialization done in 1ms: 44 devices, 0 thermal zones
[0]: init_uacpi done. Peak allocation: 268096 Current allocation: 259328

i'll be pushing this soon 😄

[fiery turtle]

That's cool

[fiery turtle]

he figured it out

[hollow scaffold]

Please explain uACPI in Factorio terms

[torpid root]

oil refinery

[crude summit]

biter

oh wait....

[frank canopy]

i hate how that immediately feels accurate lmao

[dense steppe]

@fiery turtle If I'm calling uacpi_setup_early_table_access at a point in time where I do have a functional kernel memory allocator and I want uACPI to allocate from there instead of using the internal buffer, is there any way to achieve that?

[fiery turtle]

uacpi_initialize

[frank canopy]

the only thing that happens in uacpi_initialize is tables yeah

[fiery turtle]

It allocates some stuff there mostly yeah

Just dont call early access

[dense steppe]

oh, nice

[frank canopy]

at the very least initialize doesnt do gpe/sci or namespace etc stuff afaik

[dense steppe]

yeah that sort of thing should not happen until much much later

"Enters ACPI mode." but there's a flag to disable that right?

[frank canopy]

i ended up thinking i was going to get rid of my early tables stuff and i still might tbh, depends on how i end up handling smp information (e.g. get from limine and give in and use limine's smp boot or get from acpi)

[fiery turtle]

Yes

[dense steppe]

Ok. great!

[fiery turtle]

Np

[crude summit]

how do i get the acpi pm timer port with uacpi?

i tried parsing it myself, but my real hardware returns a bogus address 0x4004 when it should give out 0x4008, i dont know if thats on me reading it wrong, or if thats on the machine. best thing would be for me to NOT read this myself and use the right tool for the job.

[fiery turtle]

uacpi_gas helpers

[crude summit]

any docs on that?

[fiery turtle]

It has map and read_mapped

[fiery turtle]

The header

[crude summit]

which header? 😄

uacpi/helpers.h?

[fiery turtle]

Idr off the top of my head

[crude summit]

found some reference in uacpi/io.h but its not really commented

[fiery turtle]

U just pass the gas to the map function and then use read_mapped

[crude summit]

how do i get the gas?

and dont say from a gas pipe

i mean in my code im parsing for the FACP

[fiery turtle]

from uacpi_get_fadt()

[crude summit]

fadt not facp?

[fiery turtle]

Facp is the signature

Fadt is what its called

[crude summit]

hmmm, i cant find that symbol

[fiery turtle]

Or just uacpi_fadt

[fiery turtle]

Tables.h

Just steal @torpid root code for it

[torpid root]

hm?

[crude summit]

uacpi_table_fadt?

you really dont wanna see my homebrew attempt for it btw, its horriffic

[torpid root]

oh acpi pm

[fiery turtle]

Pm timer management

[fiery turtle]

Ye

[crude summit]

what do i do with it, its opaque

struct acpi_fadt;

[fiery turtle]

acpi.h

Its just forward declared

[crude summit]

i want this, yes?

struct acpi_gas x_pm_tmr_blk;

[torpid root]

yes

map_gas it

then read mapped

24 bit timer overflows in like 4 seconds iirc

so use it only for calibrating other timers

[crude summit]

map_gas? is this a memory mapping function? (i wont need it if so)

[crude summit]

this is what im using it for

to calibrate my local apic timer

but, i get a bogus address on real hardware, qemu is fine (with my own code) which is why i want to check in uacpi to see if yet again my firmware is crap

[torpid root]

uacpi_map_gas

if it's using io, it won't map

if it uses mmio, it will

[fiery turtle]

The pm timer is a GAS, that means it can exist in any address space

This is why the function abstracts it away

[crude summit]

wdym by that?

everything is identity mapped

ah yes i rtfs'd

it calls uacpi_kernel_map, on my kernel its a nop

[fiery turtle]

This structure is a generic address structure, that means it has a field specifying the address space the register is located in, there are tons of various address spaces besides io

[crude summit]

i wrote this to replace my crappy table scan code

    struct acpi_fadt *fadt = NULL;
    st = uacpi_table_fadt(&fadt);
    if (!uacpi_unlikely_error(st) && fadt) {
        struct acpi_gas *gas = &fadt->x_pm_tmr_blk;

        if (gas->address_space_id == 1) {
            // System I/O
            pm_timer_port = (uint16_t)gas->address;
            pm_timer_is_io = true;
            kprintf("Using PM timer IO port 0x%04lx\n", pm_timer_port);
        } else if (gas->address_space_id == 0) {
            // System memory (MMIO)
            pm_timer_port = (uintptr_t)gas->address;
            pm_timer_is_io = false;
            kprintf("Using PM timer MMIO 0x%lx\n", pm_timer_port);
        } else {
            kprintf("Unsupported PM timer space_id %u\n", gas->address_space_id);
            pm_timer_port = 0;
        }

        pm_timer_32bit = (gas->register_bit_width == 32);
        kprintf("PM timer bit width=%u, offset=%u\n",
            gas->register_bit_width, gas->register_bit_offset);
    } else {
        kprintf("FADT not found, no PM timer available\n");
        pm_timer_port = 0;
    }

it works, on real hardware and in qemu

basically sets 3 static globals, pm_timer_port, pm_timer_is_io and pm_timer_32bit

which i then use in a timer read function:

uint32_t pm_timer_read(void) {
    if (pm_timer_port == 0) {
        return 0; // not available
    }

    uint32_t mask = pm_timer_32bit ? 0xFFFFFFFF : 0xFFFFFF;

    if (pm_timer_is_io) {
        // Always use a 32-bit port read
        return inl((uint16_t)pm_timer_port) & mask;
    } else {
        // MMIO read
        volatile uint32_t *reg = (volatile uint32_t *)(uintptr_t)pm_timer_port;
        return *reg & mask;
    }
}

i should fix that 'always use 32 bit'

because i really should be using the width from the gas

right?

its just convenient that right now both hardware and qemu give me 32

[fiery turtle]

Why not just map_gas/read_mapped?

[crude summit]

i dont need to map it

if its identity mapped, that function does nothing

[fiery turtle]

Yes, but the whole point is u dont have to read it yourself

[crude summit]

but ist it just reading a value from the struct?

or are you talking about read_mapped for the pm_timer_read function?

i cant there, i tear down uacpi when im done with it

[fiery turtle]

Eh anyway, whatever works

[crude summit]

thanks for putting up with my probing (see what i did there? port puns)

[dense steppe]

@fiery turtle I have a kernel spinlock which uses a percpu counter to disable interrupts. As a consequence of this, my kernel doesn't cope with not unlocking a spinlock (it leaves the caller with an unbalanced IRQ disable counter). Does uACPI free any spinlocks without first unlocking them?

[slim panther]

same here

[fiery turtle]

No ofc not, why would it do that?

That would break any kernel that disables interrupts

[dense steppe]

Without knowledge of this, it is easy to make the (faulty) assumption that if you are already holding some other ("outer") lock, it is fine to free an inner lock without unlocking it:

Spinlock *outer, *inner;

outer = new Spinlock;
inner = new Spinlock;

outer.lock();
inner.lock();
delete inner; // BUG!
outer.unlock();

[fiery turtle]

Nah that's not an assumption uACPI makes since its stupid af, also its spinlocks are mostly static lifetime

[dense steppe]

great

[fiery turtle]

If you encounter one let me know

[dense steppe]

I have the following in my uacpi_kernel_free_spinlock:

BUG_ON(!lock->trylock());
lock->unlock();

so I will catch this if you ever do it

[fiery turtle]

Sure lol

[vast kestrel]

This is what I do btw https://github.com/Itay2805/uACPI-OS/blob/51a7fe00221421c2156d4eb3a33f678123522624/kernel/acpi/acpi.c#L180

And couple lines below it you can see the stall function that actually uses the port

Technically I should be masking the timer to 24bit for this to correctly work but yeah

Aka I skip the gas :^)

[fiery turtle]

UACPI os lol

[slim panther]

ultra 2

[median crest]

what happened to that aml os

[vast kestrel]

too lazy so turned it into an example of uacpi

[median crest]

damn

[fiery turtle]

I think u even had a python to aml compiler?

[vast kestrel]

ye

or at least the start of it

[torpid root]

BUG_ON(! is such a nice replacement for assert

it actually tells you what an assert is for

not for if then panic s

[fiery turtle]

Yep

I also use WARN_ON

that u can use in if statements like if (WARN_ON(x)) ...

[torpid root]

mine is called ensure

not a great name tbh

[kindred beacon]

https://cdn.discordapp.com/attachments/1287456798407790684/1290809675943776298/assert.gif

[torpid root]

[calm latch]

But assert and ensure are different

[torpid root]

definitions are close enough

[dense steppe]

IMO this is better than ensure:

#define assume(expr) do { \
        if (expr)                  \
                ;                        \
        else                           \
                __builtin_unreachable(); \
} while(0)

because I think it is more obvious that assert and assume are different things.
assert - panic if a condition is not met
assume - invoke undefined behavior if a condition is not met

[gentle peak]

why the if else instead of if (!(expr)) __builtin_unreachable()

[dense steppe]

if expr expands to some C++ object whose type has no operator!, that might be needed, but idk

is that a thing

operator!?

I don't remember ever having implemented a custom operator! at least.

[gentle peak]

ah right c++ exists

[dense steppe]

(goddangit aligning the backslashes is hard to do on phone discord)

[dense steppe]

yeah, sorry for reminding you

[slim panther]

👎

[dense steppe]

C++ is actually a good language believe it or not.

That doesn't mean that you have to use it.

But C++ is not a bad language.

[kindred beacon]

prepend "modern" and you're unironically right

[gentle peak]

oh yeah no doubt about it, it's just not my preferred kind of language

[kindred beacon]

modern means >= C++20

in this case

[gentle peak]

I never use it and so for snippets that look more like C I tend not to consider its existence

[dense steppe]

well this is valid C, too.

[gentle peak]

yeah exactly

[dense steppe]

the "modern" parts of C++ that I use are mainly some constexpr and template stuff

otherwise most of the language features I use have been a thing in the standard since ~C++11 or even before

[gentle peak]

probably doesn't help that my only semi recent experiences with it have been porting mlibc (where i pretty much just treat it as c with namespaces) and trying to backport c++20 code to compile on OpenWatcom

[dense steppe]

Being able to template on a member field of a struct is sooooo useful. It allows me to do things like

struct ListHead { /* ... */ };

template<class T, ListHead T::*F>
class TypedList {
    /* ... */
    void insert(T *item)
    {
        m_list.insert(&(item->*F));
    }
    /* ... */
};

struct Foo {
    ListHead entry;
    /* ... */
};

typedef TypedList<Foo, &Foo::entry> FooList;

which lets me make so much better wrapper types around all sorts of data structures, primarily intrusive ones.

IIRC that is a relatively recent feature.

[crude summit]

why dont you just push the flags onto the stack, pop off into rax, then store IF when you lock the spinlock, and in the unlock spinlock function pass those flags back in and reverse the process

then after saving flags, do CLI

so that on exit from the spinlock, the IF state is preserved but interrupts are always disabled

this is what i do

[calm latch]

except when it breaks compilers (GCC)

[torpid root]

if you don't explicitly delete it, I believe implicit operator exists by default

even then, if it's convertible to bool, you can just do that

so if (!(bool)(x))

[flat badge]

The Message Proxy (MPXY) extension allows the supervisor software to send and receive messages through
the SBI implementation.
Will we finally get POST /pciroot/0/port/5/power < {"state": "on"} firmware?

[mortal yoke]

unironically that would be pretty nice

[flat badge]

This document describes the RISC-V Platform Management Interface (RPMI), which is an OS-agnostic, firmware-agnostic, scalable and extensible interface for platform management and control from dedicated microcontrollers (also referred to as platform microcontroller or PuC).

The RPMI defines a message based communication between multiple application processors (APs) and platform microcontrollers (PuCs) for system management and control. This message based communication can also be virtualized by the machine-mode firmware or hypervisors using the SBI MPXY extension cite:[SBI].

damn is RISC-V straight up stealing my ideas?

https://raw.githubusercontent.com/riscv-non-isa/riscv-rpmi/refs/heads/main/images/highlevel-arch.png

it's happening

[kindred beacon]

based based based based based

[dusky glade]

i really need to update uacpi for nyaux, id assume a lot of changes happened

[torpid root]

not to the api

[dusky glade]

i dont mean api

i mean features

[torpid root]

mostly bug fixes afaik

[dusky glade]

[torpid root]

I don't know how old your uacpi is

[dusky glade]

idk

i forgor

[fiery turtle]

Its been mostly bug fixes and support for bogus table sizes

[dusky glade]

fair

[fiery turtle]

i am gonna add new api soon

for subtable iteration

[dusky glade]

epic

[fiery turtle]

also maybe an api to iterate all existing tables

[safe epoch]

Has anybody compiled this on MSVC? Lots of compiler errors:

External\uACPI\source\default_handlers.c(128): error C2664: 'uacpi_status pci_region_attach(uacpi_region_attach_data *)': cannot convert argument 1 from 'uacpi_handle' to 'uacpi_region_attach_data *'
External\uACPI\source\default_handlers.c(128): note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast
External\uACPI\source\default_handlers.c(43): note: see declaration of 'pci_region_attach'
External\uACPI\source\default_handlers.c(128): note: while trying to match the argument list '(uacpi_handle)'

[loud ice]

i think it is meant to work

but maybe turn off whatever nonconformant bs that diagnostic comes from :^)

are you compiling in c++ mode?

[safe epoch]

I was when I got those errors, good catch. Compiling for C is giving another set of errors:

External\uACPI\include\uacpi/platform/types.h(55): error C2143: syntax error: missing ')' before '!'
External\uACPI\include\uacpi/platform/types.h(55): error C2143: syntax error: missing '{' before '!'
External\uACPI\include\uacpi/platform/types.h(55): error C2059: syntax error: '!'

I can see in the headers there are checks for _MSC_VER so I'm probably just missing something

[fiery turtle]

yes, uacpi definitely compiles under msvc with default flags

thats how i debug it exclusively

target_compile_options(
    ${NAME}
    PRIVATE
    /W3 /WX
    /wd4200 /wd4267 /wd4244
)

these are the flags i use

note: Conversion from 'void*' to pointer to non-'void' requires an explicit cast

you are compiling C code in C++ mode

[loud ice]

huh, why?

[fiery turtle]

because i daily drive windows

[loud ice]

sure, but clang-cl exists

[fiery turtle]

yeah, just extra effort to install and worse visual studio integration

[safe epoch]

Ok I found the issue with the syntax error:

diff --git a/include/uacpi/platform/compiler.h b/include/uacpi/platform/compiler.h
index 563a1c5..e9554bf 100644
--- a/include/uacpi/platform/compiler.h
+++ b/include/uacpi/platform/compiler.h
@@ -16,7 +16,7 @@
 #elif defined(__cplusplus)
 #define UACPI_STATIC_ASSERT static_assert
 #else
-#define UACPI_STATIC_ASSERT _Static_assert
+#define UACPI_STATIC_ASSERT static_assert
 #endif

[fiery turtle]

are you still compiling it in C++ mode?

[safe epoch]

cl /c Acpi/Acpi.c /Fo"..\build\moskrnl_acpi" -IExternal\uACPI\source -IExternal\uACPI\include

[fiery turtle]

strange

i've seen some msvc issues around static_assert before

idk how they work tho

[slim panther]

are there different editions?

[fiery turtle]

because this definitely compiles for me

[slim panther]

like vs19 vs 22

[fiery turtle]

and github CI as well

[fiery turtle]

yeah

[safe epoch]

If you're compile for C how is __cplusplus defined?

[fiery turtle]

it isnt

[slim panther]

it's undef

[fiery turtle]

hence why i said it was weird

because _Static_assert is a C version of static_assert

[safe epoch]

This is from ucrt:

#ifdef __cplusplus
    #ifndef _STATIC_ASSERT
        #define _STATIC_ASSERT(expr) static_assert((expr), #expr)
    #endif
#else
    #ifndef _STATIC_ASSERT
        #ifdef __clang__
            #define _STATIC_ASSERT(expr) _Static_assert((expr), #expr)
        #else
            #define _STATIC_ASSERT(expr) typedef char __static_assert_t[(expr) != 0]
        #endif
    #endif
#endif

[slim panther]

C23 has static_assert

[safe epoch]

And that just has 1 param?

[slim panther]

no, it should take either one or two params

[safe epoch]

I'm really not sure shrug sorry for all the Q's

[slim panther]

https://en.cppreference.com/w/c/language/_Static_assert.html

[fiery turtle]

its different between different msvc versions

the one i have allows two params

[slim panther]

c23 deprecates _Static_assert

[safe epoch]

with that change it does compile all for me.

C:\Users\todds\GitHub\toddsharpe\MetalOS\build>cl
Microsoft (R) C/C++ Optimizing Compiler Version 19.43.34810 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

[fiery turtle]

which change?

maybe if u set the C version to like C11/17

[safe epoch]

#1217009725711847465 message

[slim panther]

still, uacpi should work without changes on c23

[calm latch]

I think I compile it in c23 mode with clang

[slim panther]

my rewrite branch does too

no issues

but that's gcc

[fiery turtle]

Yeah dunno, ill investigate how msvc handles static assert at some point

[safe epoch]

No problem, thanks guys

[slim panther]

how do you switch to c23 on msvc?

/std=c23?

[safe epoch]

I'm in the process of porting my OS from ACPICA to uACPI

[hollow elm]

/std:c23 iirc

or at least that was the syntax for c++ standards iirc

[slim panther]

okay i just tried all three compilers in c23 mode

they all both accept the C11 and C23 form

https://godbolt.org/z/ef55ohKPv

also funny

nice static assert

[hollow elm]

did it turn it into an fn call with an implicit fn definition?

hence the error at global scope

[slim panther]

lmaoooo they interpret the old form as an implicit function call

[dense steppe]

yeah this is incorrect

idk about you but call __Static_assert doesn't look compile-time to me

this is MSVC?

[kindred beacon]

yes

[slim panther]

best msvc codegen

[dense steppe]

average MSVC experience

[slim panther]

never use this shit btw

clang-cl clears

[slim panther]

no actually

it's not even an error

[hollow elm]

i mean hence why a static assert outside a function is an error

[slim panther]

but still

why do they allow implicit function declarations

but then they don't recognize _Static_assert

that's like cherry picking shit from the spec

[safe epoch]

I also think the uses of: #include <intrin.h> need to be wrapped in UACPI_OVERRIDE_TYPES or else you risk pulling in all of vcruntime

in atomic.h and compiler.h

[fiery turtle]

Hm? Override is for overriding, why would it include something else?

The platform/ headers are meant to be overridable by platforms, so if intrin.h is a problem for your platform you are free to modify/make an override header as you see fit

[safe epoch]

Okay that works. My build doesn't use any vs headers, so ive got an intrin.h i populate as needed

[fiery turtle]

So it should include your version right?

Btw is your kernel nt like?

Since you use msvc

[slim panther]

inb4 unix like

just making it hard for the fun of it

[median crest]

unix-like
names functions with nt prefixes
uses mvsc
refuses to elaborate

[slim panther]

https://tenor.com/view/mog-statue-mogger-mogging-mewing-gif-4726236665805485045

[safe epoch]

Yep, I'm doing a big rewrite of my OS for a unity build, so just removing those includes is fine for now

My OS is NT like, the kernel/user images are all PE's

I'm doing a big rewrite for a number of reasons (I mostly hate how i did memory management). its on github:
https://github.com/toddsharpe/MetalOS

[hollow elm]

why do unity builds?

[fiery turtle]

Cool

[slim panther]

msvc lto

[hollow elm]

as if msvc can actually optimize

[safe epoch]

LTCG is nice for OPT, but not for build speed

[hollow elm]

in the first place

[fiery turtle]

Is it going for nt compat?

[safe epoch]

No, just inspired by it

[fiery turtle]

Ah

[safe epoch]

Though i did manage to get windbg working somehow, barely

[fiery turtle]

What does it require?

[safe epoch]

I had to read a lot of ReactOS source for that., hard part was getting the module lists and init structs correct. then finding out the subset of API that needed to be implemented

and then a kernel thread to handle the requests while the rest of the scheduler is halted of course

[fiery turtle]

Interesting

[sterile egret]

paging Dr @surreal current

[safe epoch]

Many thanks, working great:

\
    Name: \
    Desc: (null)
    HID : (null)
\_SB_
    Name: _SB_
    Desc: (null)
    HID : (null)
\_SB_.VMOD
    Name: VMOD
    Desc: Module Device
    HID : ACPI0004
\_SB_.VMOD.APIC
    Name: APIC
    Desc: IO-APIC Interrupt Controller
    HID : PNP0003
\_SB_.VMOD.VMBS
    Name: VMBS
    Desc: (null)
    HID : MSFT1000
\_SB_.UAR1
    Name: UAR1
    Desc: 16550A-compatible COM Serial Port
    HID : PNP0501
\_SB_.UAR2
    Name: UAR2
    Desc: 16550A-compatible COM Serial Port
    HID : PNP0501
\_SB_.GENC
    Name: GENC
    Desc: (null)
    HID : MSFT1002
\_SB_.RTC0
    Name: RTC0
    Desc: AT Real-Time Clock
    HID : PNP0B00
\P001
    Name: P001
    Desc: Processor Device
    HID : ACPI0007

[fiery turtle]

👍

[crude summit]

is it possible to use uacpi to detect if efi booting is possible? even if the OS didnt boot via UEFI. i want it as a simple check "is this machine UEFI boot capable?" before i lay down an ESP in my installer. if it isnt, the installer will say nope, retro rocket isnt for your retro hardware.

the live CD can boot in 'legacy' mode (as per limine) where it just uses el torito and no uefi stuff, but that doesnt mean the system itself is incapable

[left orbit]

i'm not aware of such possibility, i'd say if you really want to make sure people don't mess it up just build the limine iso without bios support to make sure it can't be booted on a legacy system :^)

[crude summit]

hah that's a good way to do it I guess

I heard though that there's a non standard ACPI table called _EFI or UEFI that you can scan for

added by uefi... but if it's non standard....

[left orbit]

not present on my system

i think you can look for the BGRT table

it's probably not gonna be present on non-uefi systems

but idk if it's guaranteed to be present on all uefi systems either

[kindred beacon]

I think you should be able to detect UEFI support via dmidecode

[left orbit]

you could combine that with an efi runtime services table limine request

or try what leo said

[left orbit]

actually, BGRT is probably stripped the moment you do CSM boot

smbios is stinky tho

[kindred beacon]

¯_(ツ)_/¯

[fiery turtle]

what leo said

[crude summit]

so is this reliable? if so how do i query for it?

[left orbit]

smbios

a bunch of variable length entries but it's well documented and standard

i'm too lazy to look for the spec sorry

[crude summit]

i can scan for that in the first meg cant i, just look for aligned _SM_

[hasty plinth]

Limine can give it to you as well 🙂

[crude summit]

nice, theres a request for it? i'll look into that

thanks!

[slim panther]

supported == actually booted?

[kindred beacon]

not sure, the spec probably tells you

[crude summit]

good question, idk, for example my spare pc boots my os cd from legacy boot, but supports uefi

so if it was just 'actually booted' this would evaluate to false

however, how many systems made in the past 15 years dont support uefi boot? pretty much none?

[slim panther]

why do you even care about !UEFI boot

[crude summit]

because i dont support MBR oldschool boot from hard disk at all

[slim panther]

yeah so

if you have uefi you will have gpt

[crude summit]

clean slate, decided i dont want to support legacy cruft

[slim panther]

neither do i, my solution is to just not install limine bios

[crude summit]

those two dont go side by side, do they? windows supported it way before uefi was standard, in windows 2000... just couldnt boot off it

[slim panther]

i always install an ESP and EFI loader in my images

[crude summit]

and only ESP/EFI?

[slim panther]

yes

[crude summit]

actually is the only sane choice imho, MBR is a clusterfudge, and the whole "pick a number from 1 to 200 for your OS to identify its filesystem" like what

[slim panther]

i mean my kernel only knows about memory blobs, it assumes the bootloader has already loaded the files into ram

[fiery turtle]

It is, limine can give it to you via a request

[fiery turtle]

No, smbios is static

Its just a bunch of structs describing the hardware and firmware

[slim panther]

yeah so it's not reliable for UEFI boot detection

[fiery turtle]

Well Linux uses it for quirk detection

[crude summit]

that would mean it is reliable, right? if its static, its there or not there, it doesnt 'go away' if you boot legacy

[slim panther]

yes but it doesn't actually tell you anything about how it's booted

[fiery turtle]

We have no way on knowing without checking out a collection of smbios dumps, but I would expect the UEFI bit to be set unconditionally

[fiery turtle]

Yeah

[crude summit]

for me that doesnt matter to know how the current boot was done, just if future boots are uefi capable

[fiery turtle]

But thats not what they want

For how it was booted limine can tell it

[crude summit]

its just an installer sanity check, so i dont waste my time flattening a drive that cant boot

[calm latch]

You can have GPT + MBR boot as well

(though it was broken with limine the last time I checked)

[crude summit]

yeah, its not something i want to support for hard disks

i have no reason to be supporting legacy cruft

[tired temple]

You first run in the loader, where you can get what is the environment and only then you get into the kernel where you observe acpi, why in your view it's all upside down?

[crude summit]

I don't understand your wording here

I'm not sure what you mean by loader, do you mean bootloader? that's limine I don't write that bit.

what do you mean by upside down?

[kind mantle]

I think instead of trying to detect this, you should just allow your kernel to panic on systems that don't meet minimum specifications.

[crude summit]

but then the user has already installed it and wasted their time

[tired temple]

The loader knows what firmware it ran in and it passes to the kernel that information, pretty sure limine does too. For example UEFI system table, where you can get not only the firmware type, but the version of it. Acpi is not the place to get what the firmware was, it can be either uefi or bios. You should get this info from the loader.

[kind mantle]

Wouldn't your installer, like, not work either if it uses your kernel?

[crude summit]

I don't care for what it used to boot the cd, this is not relavent to if the system can boot UEFI. for example my system boots CDs in legacy mode only but can boot hard disk from an esp

[crude summit]

no, there's a difference, the live cd uses limine and el torito, the bootable hard disk install boots only from gpt and an esp

[kind mantle]

Either way I think you're not helping yourself with this. It's not like 64-bit Linux will gracefully tell you you're using it on a 32-bit CPU, it'll just triple fault instantly.

[crude summit]

it's not quite as obvious as that

[kind mantle]

el torito has nothing to do with booting

[mortal yoke]

do you need an esp tho?

[crude summit]

the el torito boot cd will boot fine. but it doesn't mean the hard disk can

[kind mantle]

It's just how you made it

[crude summit]

it's all about user convenience

[mortal yoke]

because you can do legacy boot from gpt

[crude summit]

yes it's all I support for hard disks

legacy boot is ass

[kind mantle]

So install Limine to do it for you

[crude summit]

limine is not my installer.

[kind mantle]

I never said that

Install Limine on the hard disk as your bootloader

[mortal yoke]

ah are the files installed to the esp?

[crude summit]

then how can limine tell me if a device I didn't boot from is uefi capable

[kind mantle]

A device isn't UEFI capable, the firmware is (or is not)

[crude summit]

yes, my os has an installer on its live cd that flattens a hard disk and writes an esp and data partition to it

I don't want to do that if it isn't going to work after reboot

basically save the user trouble as a system requirements check

[kind mantle]

What boot protocol do you use for your kernel?

[crude summit]

but I can't just make the cd uefi only because some systems dont support that where they do support it for hard disks (like my older gigabyte board)

[crude summit]

limine boot protocol and limine 4

I'm probably going to update at some point but I really don't want to retest everything rn

[kind mantle]

Then you should literally just install the Limine bootloader, because it supports legacy boot

I don't see the problem here

[crude summit]

I don't want to support legacy boot

have you seen how limine does legacy boot...? it writes it's loader to spare space in the gpt

it's flaky. I'm sure they said they want to remove it

[kind mantle]

Yes, this is how Legacy boot works literally at all, GPT or MBR.

[kind mantle]

Haha no that's never happening

[crude summit]

well, I refuse to support legacy boot, can talk about that till the cows come home

I have a neat and tidy disk layout right now

legacy boot makes it unclean by making parts of the boot process not live on the esp

which makes it more complex to write and debug

[kind mantle]

Then you have two options:

1. Get over it and install Limine-BIOS anyway
2. Stop torturing yourself with trying to detect the incredibly weird edge case of a computer modern enough to run your kernel not having UEFI.

[crude summit]

remember I can't use limines tools to write the installer to disk

but surely "stop torturing" is a misnomer, we are osdevs we love torture

[kind mantle]

I personally like to think we do this for fun

[crude summit]

yeah same

but it can be challenging and frustrating, I wouldn't do it if it was easy id get bored

I kinda feel I'm whacking through weeds in rarely trodden territory tbh many hobby oses never made installers so don't have to worry about system requirements checks. you're right that if the kernel booted on the live cd it already passed 99% of any system requirements and the only one left is "got an ahci writeable device with enough space?"

and "you sure you want to do this?" as a final step

[kind mantle]

OK so fun fact: I'm pretty sure even Managarm can't install itself from scratch

Even funner fact: An installer is going to be the first major userspace goal of mine

[crude summit]

I mean I could ask further questions about timezone and keymap but these aren't requirements checks and more bout personalisation so that's a different discussion

[kind mantle]

You could put those in an OOBE

[crude summit]

the interesting bit is parts of it need to step outside userspace or have raw access to block devices you don't give to normal user apps, for writing the partition etc

[kind mantle]

parts of it need to step outside userspace
Well yes, those are called "syscalls"

[crude summit]

my installer is all in-kernel as the os doesn't support running native code as a user process, it checks a kernel command line and if it says installer it starts an install stub else it starts the multitasking scheduler and boots /programs/init (a BASIC program)

[kind mantle]

What

[crude summit]

I also have no syscall interface no privilege separation and no paying beyond identity map

intentionally... won't add them later

[dense steppe]

It's a BASIC kernel anyways.

[kind mantle]

Do you mean to tell me you don't have a proper userspace yet fuss about supporting BIOS boot?

In an esoteric kernel that runs BASIC, of all things?

[crude summit]

yes, it behaves like oldschool 8 and 16 bit systems. want to poke that address? glhf. you brick it you keep it. it's a learning experience

rather than protecting a user from themselves (also it's a single user system)

[kind mantle]

This is only more reason to support BIOS boot

[tired temple]

If you don't want to support legacy boot after installation, you should warn your users to not use it before. uefi only systems must support booting from cds (el torito). If some machine can't it's better off to give up on such. Installer is a user program it runs after the loader and os init, so it would know the environment. You shouldn't require the user: switch to legacy bios for booting installation session, then switch to uefi only after. It's request for troubles. Esp. given you don't use your loader nor even want to do a normal installer. Do you plan usung UEFI boot/load option (BOOTX variable) for installation persistence/recognizabilty?

[crude summit]

your idea of a "proper" userspace is influenced by Linux, windows, bsd. I was raised on OSes that let you do literally anything. people learned from it. it was fun.

you have a different target audience if paging, memory protection etc are important to your use case

[kind mantle]

No, I said this because your very idea of how you want your OS to be conflicts with the way you made your installer.

Logically, the entire installer should be in BASIC

[crude summit]

I don't see how.

[kind mantle]

Of course it needs to run commands that manipulate disks directly!

Leaving that to the kernel (which probably does this in C) is a cop-out IMO

[crude summit]

no? it could be, but I didn't want it to be. I could have just pivoted which basic program launches yes, like /programs/install. but I don't want to write basic keywords to write to raw hard disk sectors, at least not right now

[kind mantle]

Also we should probably stop hijacking this thread

[crude summit]

the idea is interesting, but something for a future contributor to raise a pr for

true lol

I suppose if someone has something to say re uacpi they'd speak up and ask

I'm not the gatekeeper

[kind mantle]

Yeah but this convo arguably should be in #esoterics

[crude summit]

I never even saw this channel, say hello to my new 2nd home

[calm latch]

It shows a message that you have wrong CPU

[calm latch]

Sometimes a device is UEFI capable, but it is broken and you're better off booting with BIOS..?

I had a laptop which came with a BIOS install of Windows, and while the firmware supported UEFI, its power management didn't work properly with UEFI install

[crude summit]

that's a them problem then, not really out to cover every eventuality of hardware, that's a losing battle I don't have enough lifetimes for

some would say "but an os has to support everything or nobody will use it", not too concerned

it's a slippery slope from there to "why don't you support mbr partitions"

[calm latch]

The "user has decided to boot with BIOS for some reason but the system supports UEFI so I'm gonna carry on" is gonna lead to a broken install

[calm latch]

Yes, why don't you support them?

[crude summit]

then they enable uefi

I'm not in the mindset of flexible

[calm latch]

Also, don't you need to add a boot entry for UEFI, which requires being booted with it?

[crude summit]

because I don't want to and therefore aren't forced to, I'm 43 and I have limited free time, if I try to support everything I'll never release anything

[calm latch]

Like if the user boots with BIOS, and you don't want to support that, you just don't

[crude summit]

so many dead projects on here that never got past a dummy shell that prints hello world this is why

[calm latch]

If UEFI booting from the CD is broken, can you really trust everything else?

[dense steppe]

no you can just:

1. depend on the user to do it, or:
2. plonk yourself in as BOOTX64.EFI.
   are these good solutions? no. but plausible?

[crude summit]

that's why I want to detect it not waste their time, there's a difference between not supporting it, and letting the user waste their time and not being honest up front

like if windows let you install windows 2000 on a machine with 4mb ram

[calm latch]

Like this detection is probably more effort than just supporting BIOS

[crude summit]

not for me

I seriously don't want to

[calm latch]

Yes, because people follow a (usually shitty) tutorial, which doesn't lead anywhere, and give up

Because a fancy "let's write a boot sector, target ia32, PS/2 driver that only works in QEMU and a kernel shell" YouTube tutorial is not cutting it

[dense steppe]

this is a reason, but it is not the only reason.

[calm latch]

It's the usual reason

[crude summit]

hey I started with a tutorial

like in 2009 or so

it didn't lead to what I wanted to create, just a other Unix clone, so I binned off 99% of it

I'm pretty sure that now 16 years later none of the tutorial remains

also the jamesm tutorial is full of bugs (that's the one I used)

[crude summit]

for many overreach is a reason, they go down a rabbit hole of supporting every single system feature every processor feature, every mmu feature, adding drivers for everything they can get spec sheets for.... and it eats time, we are mortal and have finite amounts of it. my approach is targeted to just get a stable system up as quickly as possible and encourage others to build on it

[dense steppe]

yup... exactly.

[crude summit]

that and they want a gui too and a window manager and ....

[dense steppe]

the fourth hardest thing in programming... scope creep

[crude summit]

osdev is a tunnel of scope creep

people here try and lead me down the scope creep tunnel every now and again and it's "is this detour worth it to me"

[tired temple]

They are not. 1. A really good load option would be invariant to the port where your disk is attached to, it's easy to achieve putting into the bootx variable a relative UEFI device path, that would identify your storage device, it's via HD() node, works both for mbr and gpt. How do you expect a user to do that? To write a bootx variable with a specific set of data. It's your installer work. 2. This is just lame. It's for live start for install. Moreso, it's only guaranteed to be processed for removable storages. For nonremovables, implementations may vote to not bother processing it, because it's a resort path if there are no other installations. Obviously, it won't work at all if the firmware will see boot variables from other installed oses. But eh, sigh, that's too "esoteric".

[mortal yoke]

it depends on boot order

also all decent firmwares should recognize BOOTX64.EFI even on non-removable and at least give it as an option when explicitly entering the boot menu, I usually install grub both as removable and as non-removable for the reason that even if the nvram vars get nuked then it can be booted (though on modern pc fw's that's not so big of an issue as you usually have an efi shell/other way of choosing the efi file from the fs)

[tired temple]

If a machine has at least 1 installation (bootx), the firmware will load it and will not load boot<arch>. efi in the "default" path. It's written out in the specification along with the optional nature of the "default" path processing for non removable storages. That is, it's optional even if the firmware didn't find anything "registered" to load (bootx). It's said, that then it should go and check for the default path on enumerated removable storages in no particular order and if there is nothing to load still, then, optionally, it may do the same for non removable ones. This far it's been put. Since it was not meant as a normal way for an OS installation (because of obvious reasons). Then if you are so inclined on using bootx64.efi allways, you'll have to break into firmware boot manager on every boot and go to that special entry. As of which, yes, it's very decent if the firmware has such, it's normally a "load from file" one, but then it doesn't need to be in the default path still, even better if it allows a full file system navigation through all the recognised partitions and allows to pick any efi file to start and still it's not an installation, it's rather a smart way of allowing for an OS to run the 1st time for the live or installation session. Oh, this reminded me how some vendors screw the boot manager, fkn aliens, yes, xiaomi, you, in the 1st place. 😂

[crude summit]

bootx64.efi is the recognised fallback. in the case of retro rocket I flatten the disk so there's no other os to worry about. I just write out the efi part to boot only that

i basically started out by making a bootable image with limines installer and customised it a bit, then I write that to the esp

[vocal geyser]

my pc have it

but why this table exists

[median crest]

@fiery turtle question

uacpi/types.h says UACPI_ITERATION_DECISION_NEXT_PEER is only applicable for uacpi_namespace_for_each_child, but in the wiki.osdev.org article its used in a uacpi_find_devices callback

which one is right

[median crest]

match_ps2k also should take an extra param

[fiery turtle]

both

uacpi_find_devices is a utility function

it just calls for_each_child under the hood

but ig the comment should be adjusted

to something like "only applicable for namespace iteration"

[fiery turtle]

yeah the wiki is slightly outdated

[median crest]

what is the difference

[fiery turtle]

.

or what are you asking

[median crest]

like between NEXT_PEER and CONTINUE

[fiery turtle]

continue makes it continue to the child, so depth first iteration

next_peer makes it ignore all children and move on to the next peer

for example if you detect that the parent is not present via _STA there's no reason to check children

[median crest]

ohhh

I see

ty infy

[fiery turtle]

np

[fiery turtle]

Finally added a uacpi_for_each_subtable API for uACPI, no more handrolling MADT iteration

also updated the leaderboard, and fixed a comment from mathewnd

drafting a 3.1.0 release now

[fiery turtle]

CC @dense steppe

[dense steppe]

good to know. thanks

[fiery turtle]

new release, finally

[median crest]

mom my complaint is in the uacpoi changelogs I'm famous

[fiery turtle]

real

[dusky glade]

real

[fiery turtle]

Lmfao

[slim panther]

@fiery turtle loongarch support wen

[fiery turtle]

Wdym? It works on loongarch

[rustic compass]

and uacpi-rs should work out of the box there too

[calm latch]

My OS supports it and it can shut the vm down with a power button press

[slim panther]

then my uacpi was outdated

[calm latch]

maybe there are more bugs in uACPI

[fiery turtle]

What happens

There isn't any special code for loongarch support

[slim panther]

i didnt see any code for the lpic

[fiery turtle]

What sort of code? Like tables or what

[slim panther]

yes

https://github.com/uACPI/uACPI/blob/b9c05aead150b3bc992f20f8668f53f2279c0147/include/uacpi/utilities.h#L54

ah nvm i'm just blind

[fiery turtle]

Yeah this was added very recently

[woven citrus]

Does this parse non-aml tables too in some way

so the kernel can get the data from them

or nah

@fiery turtle

im assuming no

[rustic compass]

Non aml? You mean acpi tables that don't contain aml?

Uacpi has helpers to access all acpi defined tables + maybe some more

[fiery turtle]

Of course

See tables.h

[woven citrus]

thanks

[fiery turtle]

It has a barebones mode that disables aml completely

[woven citrus]

kay

[pine leaf]

we have uACPI, when are we getting uDT - the next logical step

[left orbit]

i'm assuming it's another joke on the uXXX, but still - device tree support doesn't need much more than parsing a few fields, it honestly doesn't make much sense

[flat badge]

when do we get uClksAndRegulators

[sharp lichen]

nah, we need uKernel

[kind mantle]

LINuX

[median crest]

ulibc

[hollow crescent]

uDesktop & uBinutils

[crude summit]

uOperatingSystem!

all you need to do is #include the header and call uInit_OpSys() and it gives you a fully working SMP capable multitasking network enabled kernel with ext4

imagine how many people you'd get saying they "made an os"...

[rustic compass]

Then sue all of them for copyright infringement

Money life hack

[hollow crescent]

cosmos

[dark coyote]

https://includeos.org/

[kindred beacon]

their Recommendations section makes this look really sus ngl

[dark coyote]

oh yeah I didn't even see that

the blog has been updated since 2019 anyways

[loud ice]

im trying to understand what is going on in an acpi dump (not mine) but its like

very weird

there are tons of methods that are just, not implemented???

[fiery turtle]

Wdym by that

[loud ice]

like iasl -d has External (_SB_.PC00.LPCB.H_EC.DPTF.SFHE, MethodObj) // 1 Arguments

and ```
Method (SFHT, 1, Serialized)
{
_SB.PC00.LPCB.H_EC.DPTF.SFHE (Arg0)
}

and nothing else containing the literal string "SFHT" in the entire dump

[fiery turtle]

So you mean not called, not not implemented?

[loud ice]

no, its not implemented

unless i dont know what External does

oh sorry i meant SFHE

[fiery turtle]

You mean SFHE?

[loud ice]

not SHFT

yeye

[fiery turtle]

Have you looked at SSDTs

[loud ice]

whoever thought that four character names are a good idea

[loud ice]

well yeah i mean this is from the ssdt

or what do you mean

[fiery turtle]

Basically you've looked through every file but nothing contains the impl?

[loud ice]

yea i used grep -r

two hits for SFHE

zero for Load

[fiery turtle]

Load?

[loud ice]

like for LoadTable or whatever

[fiery turtle]

Is SFHT ever called?

[loud ice]

ok no

[fiery turtle]

Thats just common dead code then

There's tons usually

[loud ice]

but i have others that are called

[fiery turtle]

Called from where

[loud ice]

the OS

FN04._OFF looks like this: ```
Local0 = Acquire (FMT4, 0x03E8)
If ((Local0 == Zero))
{
CVF4 = Zero
Release (FMT4)
}

            FNCL ()

the last instruction in FNCL is \_SB.PC00.LPCB.UPFS (ETMD, Local0, Local1)

UPFS has no impl either

[fiery turtle]

What's FN04

[loud ice]

fan number 4

        Device (FAN4)
        {
            Name (_HID, EisaId ("PNP0C0B") /* Fan (Thermal Solution) */)  // _HID: Hardware ID
            Name (_UID, 0x04)  // _UID: Unique ID
            Name (_PR0, Package (0x01)  // _PR0: Power Resources for D0
            {
                FN04
            })
        }

[fiery turtle]

Its possible that either its STA will return 0, or that its never constructed in the first place because its behind some if

Or maybe its parents sta etc

[loud ice]

wait how does STA returning zero work

[fiery turtle]

Sta returning 0 means device doesnt exist

[loud ice]

lmao what

            Method (_STA, 0, Serialized)  // _STA: Status
            {
                Local1 = Zero
                Local0 = Acquire (FMT4, 0x03E8)
                If ((Local0 == Zero))
                {
                    Local1 = CVF4 /* \_TZ_.CVF4 */
                    Release (FMT4)
                }

                Return (Local1)
            }

            Method (_ON, 0, Serialized)  // _ON_: Power On
            {
                Local0 = Acquire (FMT4, 0x03E8)
                If ((Local0 == Zero))
                {
                    CVF4 = One
                    Release (FMT4)
                }

                FNCL ()
            }

            Method (_OFF, 0, Serialized)  // _OFF: Power Off
            {
                Local0 = Acquire (FMT4, 0x03E8)
                If ((Local0 == Zero))
                {
                    CVF4 = Zero
                    Release (FMT4)
                }

                FNCL ()
            }

[fiery turtle]

Yeah

[loud ice]

this is the full code for FN04

[fiery turtle]

Yeah as you can see its hardcoded as 0

[loud ice]

well no

[fiery turtle]

Or well

Depends on what it reads

But that will likely be 0

[loud ice]

acquire returns zero if it succeeded?

[fiery turtle]

Yeah

[loud ice]

yea

i mean CVF4 is controlled by _ON and _OFF

which is what makes it even more confusing lol

[fiery turtle]

Non present vs being off are different things

[loud ice]

yeah

[fiery turtle]

But yeah

But anyway

[loud ice]

which is also like. weird.

[fiery turtle]

Even if it returned 1

[loud ice]

but yea i think STA might read zero on startup

cursed

[fiery turtle]

Sure, _OFF will get aborted

At the end

The os will just ignore the error

No one gets hurt

Firmware devs wouldn't even notice

[loud ice]

wow

i love firmware

[fiery turtle]

Yeah errors like these are mostly silent, you can do anything

If it shuts down and boots just ship it

[loud ice]

also there is some sort of interaction between their magic special windows driver and presumably the embedded controller that makes fans work after suspend

[fiery turtle]

Thats quite possible

Via WMI as well

[loud ice]

WMI?

[fiery turtle]

Windows instrumentation stuff

[loud ice]

i see

[fiery turtle]

https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-start-page

Some platform control via an XML inside an aml blob

[loud ice]

do you know if there is some sort of api for doing EC stuff on windows?

[fiery turtle]

Or something like that

[fiery turtle]

Not that I know of

But there probably is

[loud ice]

i see

[fiery turtle]

@winter orbit might know more

[loud ice]

i was wondering if this is the kind of thing the os would maybe fill out but ig not?

[winter orbit]

It’s kinda dependent on the era of windows

What are you trying to do

[fiery turtle]

Nah thats not a thing

[loud ice]

im trying to figure out how the fan control stuff on windows fits together

[fiery turtle]

Like undefined references are very common on real hw, you just live with them

Especially on cutting edge stuff

[loud ice]

(its not my laptop)

im just curious about why fans break on suspend lol

[fiery turtle]

In windows?

[winter orbit]

There’s a few things,

But pretty much the most common one is a interface guid Po asks for from ACPI

[loud ice]

no on linux

ofc

[fiery turtle]

Ah

[loud ice]

they wouldnt ship broken fans on windows

[fiery turtle]

True lol

[flat badge]

Is there any example / TLDR on how to use table only mode?

[torpid root]

define UACPI_BAREBONES_MODE and use uacpi_setup_early_table_access

[flat badge]

UACPI doesn't compile in eir

since it includes intrin.h if _MSC_VER is set but the latter is true for UEFI binaries

and intrin.h is apparently unusable in freestanding

or wait, this may be a skill issue on my side

yeah nvm

[vast kestrel]

Isn't intrin.h freestanding

At least I think under clang it comes with the freestanding headers

[fiery turtle]

Intrin should definitely be freestanding

[flat badge]

yeah, ffreestanding was not passed correctly

[fiery turtle]

Ah

[flat badge]

uacpi in mscv mode on clang throws a lot of warnings

[fiery turtle]

What sort of warnings?

[fiery turtle]

how new is your uacpi?

fallthrough should be enabled under clang

[flat badge]

i'll update

we probably didn't update in a while

[fiery turtle]

i think all those should go away on latest aside from the mismatch sign check

maybe

[flat badge]

yeah, that's correct

only the mismatch sign persists

[fiery turtle]

ill fix it

i think its their atomic api or something

[flat badge]

i wonder why the warnings differ between msvc mode and non-msvc clang

becasue when compiling into thor we didn't get any warnings at all

[fiery turtle]

uacpi used to check for _MSC_VER and disable half of the attribute macros

which clang defines as well apparently

[flat badge]

ah

[fiery turtle]

so the checks were reordered to check clang first

[flat badge]

afaict uacpi has no definitions for dbg2 and spcr

should i add + upstream these?

[fiery turtle]

that would be appreciated

[flat badge]

There is a function to check the current init level but AFAICT there is no way to check if early table access is set up, is there?

Is that something that the OS itself needs to track or would it be reasonable to add this API?

This would be useful when creating kernel images that support both DT and ACPI

[fiery turtle]

Yeah might be worth adding

I'll take a look

[flat badge]

PR made for DBG2 and SPCR

I didn't add all uarts in the DBG2 definition as constants so far, just the most useful ones

namely ns16550 and pl011

[fiery turtle]

thanks, ill review them tomorrow

[kind mantle]

Wait what? Is this uACPI support for UARTs?

[fiery turtle]

uART

[vast kestrel]

uUART

[leaden fox]

How's uacpi-rs going

[fiery turtle]

@rustic compass

[flat badge]

well, uACPI doesn't get UART drivers, it just gets support for the ACPI tables that advertise UARTs

[rustic compass]

work for v1.0 is currently on hold until i finished my exams next week

[leaden fox]

Good luck

[rustic compass]

after that i try to focus on tables only mode first

however the table template code should already be finished, so you can implement tables if you want

[flat badge]

ping for the review

[fiery turtle]

Working atm

[fiery turtle]

reviewed

[calm latch]

those ACPI tables are horrible (not the implmenetation)

[flat badge]

why?

[calm latch]

They don't give you the full interrupt configuration

Stuff like polarity, if it's level triggered and so on

Unless I've missed something

[fiery turtle]

well they give u GSI from which u can derive that no?

[flat badge]

re:

Other tables in this file call this gsi
I tried to match the names in the Microsoft documentation for all field names. But I can also use gsi if consistency with the existing structs is more important

[fiery turtle]

yeah id say consistency vs existing is more important

but no strong opinion if u think otherwise

[flat badge]

no, that's fine

I'll update the PR later today

[fiery turtle]

nice

[calm latch]

How do I derive it?

[fiery turtle]

isa has default polarity/triggering

[flat badge]

well, you can drive them in polling mode until you have full ACPI set up

[fiery turtle]

which madt can override

[flat badge]

and then you can use the namespace name to get the proper node and look up the full configuration

[calm latch]

cool

[calm latch]

(On loongarch)

[flat badge]

uarts are not necessarily ISA though

[fiery turtle]

i thought GSIs were always default config which matches ISA

unless specified otherwise

[calm latch]

the issue with AML objects is that it gives you the UARTs, but you don't know if you can use them for logs

[fiery turtle]

wdym?

Why wouldnt u be able to use them

[calm latch]

What if you have something other than terminal connected to them

[flat badge]

yeah but both SPCR/DBG2 link to the AML nodes via the namespace_string field

[calm latch]

Oh, ok

[fiery turtle]

yeah

it gives u the path

Also why is DBG2 so weird

Why do they explicitly feel the need to specify the offset and count

[flat badge]

¯_(ツ)_/¯

[fiery turtle]

Or i guess its to make it easier for firmware devs

to disable stuff at runtime

[flat badge]

i also wonder if there is any uart in existence that has more than one base address

probably not

[fiery turtle]

lol

[fiery turtle]

like firmware can just say ->offset = end;

and basically disable the table without doing anything

[calm latch]

you can embed tables into tables

[flat badge]

i think it's more likely that it's done for forward compat

such that they could add fixed offset fields before the variable offset ones in a future revision

this has already been done in the past for SPCR if you look at the revision history

Changed Table Revision to 3 and created field for UART Clock Frequency. Edited formatting.

[fiery turtle]

ohhh

[flat badge]

for clarification: bit fields should still be #define, right?

[fiery turtle]

yep

[flat badge]

should i add all the obscure dbg2 uart types that are only found on weird boards? :^)

[fiery turtle]

The more the merrier

[sharp lichen]

Come on people, 1 more star till nice!

[flat badge]

done (the PR comments)

[fiery turtle]

Great thanks, in bed rn but will take a look tmrw

[flat badge]

ping

[frank canopy]

pong

[fiery turtle]

Reviewed like 10 hours ago lol

[flat badge]

ah didn't see that

damn, infy you're really anal about coding style lol

i'll fix it in a min

[kind mantle]

Just use clang-format

[fiery turtle]

Yes

[flat badge]

doesn't exist

[fiery turtle]

Its not possible to express in clang format

Because it suxks

[kind mantle]

Damn

I must invent my own C formatter

[flat badge]

atp it'd have been faster if you added the tables yourself lol

[fiery turtle]

Well r4 got it first try

Because they looked around the file and stuff

[flat badge]

well

[kind mantle]

What is it in uACPI style that clang-format can't express btw?

[flat badge]

i didn't know that adding // Constants for foo instead of // foo was harmful

[fiery turtle]

Code style violations cannot really be harmful

But why break existing code style where its not helpful

[flat badge]

fixed

[fiery turtle]

Thanks!

[fiery turtle]

I think u added an extra space in dbg2

Otherwise LGTM

[flat badge]

you can push to my branch and fix it

[fiery turtle]

I dont think I can push into a fork?

[flat badge]

you can push to PRd branches unless the PR owner opts out

[kindred beacon]

best gh feature hands down

[fiery turtle]

Ill read up on it

Isn't faster if u just do it if you're at your PC?

I'm on my phone atm

I can add you to the org if u want btw

So u get access to ci and branch creation etc

[flat badge]

done

you should be able to approve the CI anyway

[fiery turtle]

Yeah but id have to approve it every time, every force push and every pr etc

Started CI

[fiery turtle]

alright merged

@flat badge thanks for your work

[flat badge]

nice thank you!

[hasty plinth]

you know whats amusing is that it took me 3 attempts to get a PR merged into frigg because I (or rather my editor) kept stuffing up the whitespace 😅

[pine leaf]

neovim supremacy

[hasty plinth]

well yeah that was the problem lmao

[fiery turtle]

https://github.com/Zephkek/Asus-ROG-Aml-Deep-Dive

good read

[trim siren]

404?

[fiery turtle]

fixed

[trim siren]

ah

[median crest]

Insane

Least fucked up firmware

[steel inlet]

what in the actual fuck

this shouldn't be allowed

[kind mantle]

Jesus fucking christ this is bad

Who let the junior program an interrupt handler???

[fierce kiln]

only good use of chatgpt so far

[fiery turtle]

https://x.com/asus_rogna/status/1968404596658983013?s=46

ROG North America (@ASUS_ROGNA)

Your feedback has been heard 🤝

X · Sep 17, 2025, 8:00 PM

they fixed it since

https://x.com/ASUS_ROGNA/status/1971662996339646645

ROG North America (@ASUS_ROGNA)

X · Sep 26, 2025, 7:47 PM

They've had this bug for at least 3 years but are just now finding out about it

[steel inlet]

bruh

[fiery turtle]

just goes to show the only testing they do is booting and shutting down

[vast kestrel]

They don't always even shutdown

Or well, reboot

A friend of mine has an Asus laptop and when they warm reboot it will halt the entire os couple minutes after the boot

It could be in the bios menu, in Linux or windows

[kind mantle]

More proof the average firmware dev is a moron

[vast kestrel]

Btw the warm reboot problem doesn't affect Linux

[rustic compass]

jsut to make sure the Asus TUF GAMING B850-PLUS doesnt have such horrible aml or at least no (serious) problems are known?

[hollow scaffold]

How can I be sure that I implemented my uacpi glue correctly?

[winter orbit]

Hey buddy

Don’t reveal our secrets like that

[kind mantle]

You've been been doing a bad job guarding them, then

[winter orbit]

My job isn’t to guard them it’s to laugh at them

[hollow elm]

assuming it's not too far off from the tuf b650m-plus wifi then it's perfectly fine

[fiery turtle]

Initialization sequence and using the APIs

[hollow scaffold]

Ah then my kernel works correct. Thanks g

[fiery turtle]

Np

[vast kestrel]

Wakeup babe a new acpi impl has dropped https://github.com/KaiNorberg/PatchworkOS/tree/main/src/kernel/acpi/aml

Seems like it's single pass (?)

[torpid root]

uacpi in shambles

[fiery turtle]

https://www.reddit.com/r/osdev/comments/1nr14jf/comment/nghc7ct/ according to this list its pretty incomplete

also looks recursive(?)

[vast kestrel]

Yeah it looks incomplete

[flat badge]

Recursive is not that problematic

when i wrote lai i made sure that it was mostly iterative

but now in retrospect i think that was a mistake

And it would be better to just use recursion while limiting the recursion depth

[torpid root]

why is that?

[fiery turtle]

huh lol

it is very very problematic

[flat badge]

Because it's far more sane to always run acpi on a large stack

[fiery turtle]

there are real hardware blobs that have like 30 nested expressions

imo an aml interpreter shouldnt consume more stack than any other kernel thread

just throwing more stack at the problem doesnt solve it

it just delays the inveitable overflow

[flat badge]

I'm not saying that you should evaluate all expressions recursively

[calm latch]

because you were writing a microkernel?

[fiery turtle]

which part should be recursive then?

[flat badge]

Probably function calls and edge cases

[fiery turtle]

uacpi definitely has recursive edge cases

that are just too difficult to solve

[flat badge]

such as evaluation of _BBN when a opregion is initially used

[fiery turtle]

yeah

[flat badge]

It's just not worth it to make that iterative

[fiery turtle]

Index fields are another really hard to solve problem

since they require other field access which may in turn also be Index fields

so unless u make a queue of field accesses its recursive

[flat badge]

If we're talking about computational opcodes, these should ofc be iterative

[fiery turtle]

imo the core interpreter must be iterative, but stuff like edge cases that are near impossible to trigger in the real world shouldnt be

[flat badge]

yeah

[fiery turtle]

yeah

thats what i meant initially because uacpi doesnt even try to solve those iteratively

but a recursive interpretaion of opcodes is kinda insane imo

even though they are designed recursively

hell, acpica doesnt even try to do Load/LoadTable iteratively

which violates nt compat also

[flat badge]

yeah for most opcodes an iterative implementation is better

and probably even easier due to the context sensitivity of some aml

[fiery turtle]

but i get why beginners try to do it recursively since its just so easy to get stuff working that way

like u just

parse_add()
    val0 = parse_term_arg();
    val1 = parse_term_arg():
    return add(val0, val1)

[flat badge]

until you notice that for example the interpretation of names depends on the context

[fiery turtle]

yeah thats the fun part

callop is for the weak

there are also fields that are sometimes read and sometimes not read depending on context

you have to know what called you to know what to do

its insane stuff

[vast kestrel]

I refuse to believe they accidentally designed something so insane

It has to be intentional

[fiery turtle]

uacpi_aml_op new_op = UACPI_AML_OP_InternalOpNamedObject;
uacpi_object *obj;

if (item->node == UACPI_NULL) {
    if (!op_allows_unresolved(prev_op))
        ret = UACPI_STATUS_NOT_FOUND;
    break;
}

obj = uacpi_namespace_node_get_object(item->node);

switch (obj->type) {
case UACPI_OBJECT_METHOD: {
    uacpi_bool should_invoke;

    switch (prev_op) {
    case UACPI_PARSE_OP_TERM_ARG_OR_NAMED_OBJECT:
    case UACPI_PARSE_OP_TERM_ARG_OR_NAMED_OBJECT_OR_UNRESOLVED:
        should_invoke = UACPI_FALSE;
        break;
    default:
        should_invoke = !op_wants_supername(prev_op);
    }

    if (!should_invoke)
        break;

    new_op = UACPI_AML_OP_InternalOpMethodCall0Args;
    new_op += obj->method->args;
    break;
}

case UACPI_OBJECT_BUFFER_FIELD:
case UACPI_OBJECT_FIELD_UNIT: {
    uacpi_object_type type;

    if (!op_wants_term_arg_or_operand(prev_op))
        break;

    ret = field_get_read_type(obj, &type);
    if (uacpi_unlikely_error(ret)) {
        const uacpi_char *field_path;

        field_path = uacpi_namespace_node_generate_absolute_path(
            item->node
        );

        uacpi_error(
            "unable to perform a read from field %s: "
            "parent opregion gone\n", field_path
        );
        uacpi_free_absolute_path(field_path);
    }

    switch (type) {
    case UACPI_OBJECT_BUFFER:
        new_op = UACPI_AML_OP_InternalOpReadFieldAsBuffer;
        break;
    case UACPI_OBJECT_INTEGER:
        new_op = UACPI_AML_OP_InternalOpReadFieldAsInteger;
        break;
    default:
        ret = UACPI_STATUS_INVALID_ARGUMENT;
        continue;
    }
    break;
}
default:
    break;
}

op_ctx->pc = 0;
op_ctx->op = uacpi_get_op_spec(new_op);
break;

This is the bulk of logic in uACPI that decides what to do when it encounters a namestring, as u can see it only knows based on prev_op

[flat badge]

No, i think it's just incremental changes by Microsoft without thinking about the broader context

[vast kestrel]

How different is the current aml to acpi 1 aml

[flat badge]

I'm 100% convinced that they didn't realize that RefOp can be used to create reference cycles etc

[fiery turtle]

they didnt think about refofop at all

it works like shit

[vast kestrel]

Can we retcon acpi into wasm

[fiery turtle]

they didnt realize u can take a reference of a reference

[flat badge]

Or that the handling of names within packages is insane

[fiery turtle]

well tbh thats acpica shooting itself in the foot

nt doesnt handle names in a package

it just converts them to a string object

[flat badge]

well yeah but then the caller needs to eval them in same cases

[fiery turtle]

yep

at that point the objects that it references have already been created

so no two-pass etc needed