#OBOS (not vibecoded)
1 messages · Page 39 of 1
oh and while im making changes to the kernel im also gonna make it so that my tcp sockets can shutdown on close asynchronously to avoid having to send a reset
what I currently do on tcp socket close is reset the connection
Obos doesn't concern itself with stability 
Or maybe its stable now actually
depends on the moon phase
and what u r testing
for example it might hang on real hardware with smp
or maybe it will hang on real hardware with smp disabled
it may also crash if you blow on it wrong
but generally it is better
than it was in February
there have been more safety measures added for multithreading
mostly with initialization of waitable objects
i.e., mutexes, events, etc.
oh yeah a day or two ago I added file moving to the ext2 driver
what i did is i made it delete the old entry and replace it with a new entry in the new parent
and when im done my timer interface changes
I think i will finally
add usb support to obos
starting with xhci
That's good
maybe I'll also add ehci and uhci support once I understand how usb works
on a general basis
after that I might port sshd
or i might work on fvwm3
(I'll also add a usb keyboard driver)
bruh
why is cpuid 0x15 returning all zeroes
in qemu
cpuid leaf zero
reports
it exists
cpuid 0x80000007 reports invariant tsc as existent
ive mastered the art of zoning out
im not gonna be consciously aware of my actions at school until I get back home
its really convenient when I want to skip through parts of the day
currently i have a few hours left until I fade back into consciousness
i dont think its required to give nonzeros, and qemu doesnt implement it ever in any form ive done a ton of digging for that
you can get tsc freq on qemu from the hypervisor leaves if youre under a hypervisor instead of using tcg though
i spent like a week trying to figure this exact issue out and getting mad over it lmao
qemu just doesnt implement it for some reason shrug
it sucks
i implemented the thing
for calibration
and it's pretty accurate
and i just pushed the inv. tsc code
god i wish qemu implemented leaf 0x15
might try to make a patch for that sometime tbh
ok so i made doom use rdtsc
and the performance is exponentially better
and also the kernel feels a bit more responsive
kms
why
does
it
have
to
be so hard
for the kernel to keep track of a GODDAMN NUMBER
FHSDUGHJDSLIHNFDIP
ok fixed it
lol pi
yay
lol where
thats the only number i can think of that might be hard to track
unironically why did linux switch to iproute2 🥀
(this won't be similar to the actual ifconfig command)
configip 
i named it ||obos-ifconfig||
LoC update
to whomever it concerns (absolutely no one)
Crazy
Just FYI even this leaf is bunk on real hardware 
I forgot we cant have nice things on real hardware
oh well I'll just add a kernel cmdline option to allow using cpuid 0x15 for the tsc frequency
is it even worth it when calibration + maybe 3 rounds + average is fine?
that laptop is pretty new too. almost no CPUs properly support said leaf
this code will most likely not work due to an integer overflow
and due to integer division inaccuracy
instead of ecx * (ebx / eax) (which does a 32 bit multiplication with one of the operands being rounded) you should do ((uint64_t)ecx * ebx) / eax, which does a 64 bit multiplication and division and only rounds the final result
Oh wait
wait was that why? let me test that actually
It was close to an okay value
Oh wait my USB is missing
il test it later if i find it
But that is probably why it broke
Bonk me with a stick

i didnt actually think i would get this far
i haven't done driver dev
for basically a year
god damn it
these people are fucking crazy
this specification is insane
wtf is a trb and why do we need so much of them wtf
okok that makes sense now
im hoping by the end of the day ill have so much to show as like. a completed transfer on xhci, or at least port enumeration
i feel like the people at intel coulda designed the TCBs in xhci to be better
but i got no better suggestions rn so i cant really be talking
man its fun
you get to think for hours about what crap you put into a uint64

uint8 flag: 1
There it’s a single bit
And you can put more for more flags and it will pad it properly to not take up too much
And you can access them without bit shift ops

bad practice
Really?
in c yeah
compiler can do whatever the fuck it wants with that, in theory
although it does have to follow the abi

Of course it can
Of course
Would that cause issues for internal code and that’s all compiled by one compiler?
if the bitfield is only accessed by code you're compiling it's fine
the issues occur when you use bitfields for hardware stuff
like page table entries, device registers, acpi tables, etc
ik thats probably gcc (and also clang) only but like
xhci is making sense now
USB 
not it
idk either 😔
yeah trying to remember what it looks like is giving me SIGSEGV
OHHHHHHH it all makes sense now
You want to pack most things for external things anyways right
yes
even for internal things i do it sometimes
space savings 👍
That’s bad for some things because it slows things down with misaligned memory access or some shit?
id do anything to fit some fart into 64 kib of space ngl
i mean idk fair but still
wait so if im not mistaken:
command TRBs go in the command ring
while transfer TRBs go in the endpoint TRB
yeah that makes enough sense
how tf does the event ring work
specifically the "Event Ring Segment Table (ERST)"
ok i get it now
ok well im testing it
and im not getting any IRQs
idk if it's the xhci driver
or the msi-x implementation
i know that msi works
and when i use the PCI IRQ pins, the kernel constantly gets IRQs
but the xhci controller never reports any IRQs anywhere
i hate reading c++ code
yeah
what's up though?
like, what are you trying to do?
well im trying to get IRQs from the xhci controller
to no avail
idk if it's MSI-X or the xhci driver
and i have no way to test MSI-X
fuck it im just gonna debug qemu to see what's up
well it's not the xhci driver
it's MSI
it isn't MSI, nor the xhci driver
i am a dumbass
today I shall continue
with xhci
and i will be initializing ports today
and handling device connections and disconnections
and after that I will be adding an interface to send TRBs
of course this will be after school 
I will try to make it as controller independent as I can
I'll probably have some enums for the different packet types when an IRP is submitted
and I think it is safe to have the different packet types be the TRBs described by xhci spec section 3.3
and i will also start on the usb stack
starting with adding kernel functions like Drv_USBDeviceAttach and Drv_USBDeviceDetach
and i will also add a field to the driver header for recognized usb class codes nstuff
for pnp
and the usb stack will be responsible for making sure drivers know their device was detached
I will likely add a function to the driver function table like:
void(*on_detach)(dev_desc dev);
obos_status(*on_attach)(dev_desc dev);```
I might even use that for pci as well
I will also likely have a method for userspace to be signaled that a usb device was attached so that it can syscall and get the kernel to load the appropriate drivers
i don't think im gonna expose xhci controllers to devfs
at least not directly
I will also have equivalent functions for usb controllers
except those probably wont be hotpluggable
ok queuing TRBs works
im working on port initialization
topology defined
well thanks? now how do I FIND OUT THE GODDAMN TOPOLOGY, HUH XHCI?
Who knows
(the logs that are not prefixed with [ DEBUG ] logs are from qemu)
logs 👍
logs indeed
i mean i think your driver works
im writing the base for the usb stack rn
yeah the xhci driver can initialize a port now
and i think it can also initialize the control endpoint
and it can send control TRBs as well as endpoint TRBs
fire
anyway
i have no idea how usb hubs are supposed to work
but who needs those anyway?
me
i need them'
i need more usb ports than i have
Don’t some computers have internal hubs sometimes or some shit?
neat, i got another star
shoutout to the guy who just starred
me
and to everyone else who starred me
tis much appreciated
Meeee x3
For some reason I hadn't started it yet
typedef enum usb_trb_type {
USB_TRB_NORMAL,
// only legal for endpoint zero (control)
USB_TRB_SETUP,
USB_TRB_ISOCH,
USB_TRB_NOP,
USB_TRB_CONFIGURE_ENDPOINT,
} usb_trb_type;
// TRB Direction is defined by irp.op
typedef struct usb_irp_payload {
usb_trb_type trb_type;
union {
struct {
struct physical_region* regions;
size_t nRegions;
} normal;
struct {
struct physical_region* regions;
size_t nRegions;
} isoch;
struct {
struct {
uint8_t bmRequestType;
uint8_t bRequest;
uint16_t wValue;
uint16_t wIndex;
uint16_t wLength;
} OBOS_PACK;
struct physical_region* regions;
size_t nRegions;
// TODO: Return status in some way from the status stage TRB (xhci-only)?
} setup;
} payload;
} usb_irp_payload;```
this is what i have in mind
for the usb stack so far
i mean like
the first layer
or whatever
idk what configure endpoint will look like yet
Oh I probably was remembering starring the GitHub repo a while ago
just realised i somehow hadnt starred obos yet either lol
as you can see i fixed that
yes
marker
yay
anyway before i continue with the usb stack
i need to implement port detaching
in the xhci driver
i just pushed some code for the usb stack
as well as some xhci code
now time to implement xhci IRPs
but first
i want to add a submit IRP function for the USB stack
done that
glad im not the only one using IRPs for io
IRPs my beloved
its such a good pattern
so much so that the zig standard library is migrating to basically IRPs for io lmao, even outside of osdev context
todo for tomorrow: get endpoint transfers to actually work
you know which root port a device belongs to be keeping track of the whole tree of hubs until the root port
and on the root port you know which one it is because you got an event for it
oh ok thanks
endpoint transfers work now
but my control transfers are not working (qemu asserts and dies)
ok well
now i am getting CC_STALL_ERROR on my transfers
usb_xhci_fetch_trb addr 0x00000000620db000, TR_SETUP, p 0x0012000001000006, s 0x00000008, c 0x00030841
usb_xhci_fetch_trb addr 0x00000000620db010, TR_DATA, p 0x00000000618b8000, s 0x00020012, c 0x00000c01
usb_xhci_fetch_trb addr 0x00000000620db020, TR_STATUS, p 0x0000000000000000, s 0x00000000, c 0x00011021

for reference im tryna send a GET_DESCRIPTOR request
i think i see why now
ok fixed it
i now receive the device descriptor
but it seems incomplete
so im gonna actually properly initialize the device first and come back
(by this, i mean that the class codes are zero)
hm
i added some code so that
the kernel can attach drivers to usb devices
although, automatic driver loading for usb is not yet implemented
i need to implement aborting IRPs if the port is detached
im thinking of having an extra event pointer in the IRP for the controller to set when a port is detached
then Drv_USBIRPWait will wait on both events
(ill probably also do the same for normal IRPs)
did that
now
in theory
i have all i need to implement a keyboard driver
so ig that's what im gonna do
implement a usb keyboard driver
That basically seals the deal for being compatible with modern hardware imo right?
Because you don’t need a PS/2 keyboard
That’s gonna be so cool
Btw do you handle a keyboard that exposes there virtual keyboards?
(the kernel currently only boots on some haswell-era devices lmfao)
Because a lot of gaming ones
Mine boots on 5700xs and 12th gen intel and really old ones? What kind of stuff are you doing lmao
no clue 

i tell myself "ill get modern hardware to boot eventually"
hangs sometime in really early boot
like before the fb or gdt is initialized
(fb is inited before the gdt lol)
Do you use flanterm? You can use its bump allocator to have it before any kernel shit starts to print things
i think flanterm is the problem here btw
i think i dont give it enough memory for the bump allocator
Do you use a smaller font perchance?
(i made the bump allocator region configurable for flanterm)
I had this exact same issue
i use the default font currently
If the screen was bigger than 720p it would break
and flanterm gets 16M of memory
Because i had an 8x8 font
i might try allocating more memory
because if i dont see logs then it very well could be that
https://git.evalyngoemer.com/evalynOS/evalynOS/src/branch/master/src/patches/flanterm-fb-balloc-size-increase.patch
this is all i needed
well
Are you giving it too much memory??
I give 1.5mb
Aswell for the default font the normal amount should be fine because it scales on more then 1080p
On the BSS maybe?
especially when my fb is memory
i think this is why it’s breaking
static struct {
uintptr_t address;
uintptr_t size;
} Arch_FlantermBumpAllocator = {};
static void *flanterm_malloc(size_t sz)
{
static size_t bump_off = 0;
if ((bump_off + sz) > Arch_FlantermBumpAllocator.size)
return nullptr;
void* ret = (void*)(Arch_FlantermBumpAllocator.address + bump_off);
bump_off += sz;
return ret;
}
static void flanterm_free(void* blk, size_t sz)
{
OBOS_UNUSED(blk && sz);
return;
}```
Flanterm has an internal bump allocator it uses
x to doubt
not if you override it
i override it.
I’m gonna download OBOS and test it
And then make a PR of it works

gl
What’s the process for building it and shit
obos is known for having a shit build system
cmake -Bbuild -DCMAKE_BUILD_TYPE=Debug -DOBOS_USE_CLANG=1 -DOBOS_USE_LIMINE=ON --toolchain=src/build/x86_64/toolchain.cmake .
cmake --build build
should work
repo link?
should i use the xhci branch?
use master
lol
u can review the 65k loc of code if u want
im too lazy
tell me if u find bugs 
I cast: MIT License
this is fineee
oh shit
it booted a bit
with the bigger flanterm buffer
now it is hanging trying to initialize the scheduler timer
its mainly with userspace
how should i ignore it to get an ISO?
wdym
make[2]: *** No rule to make target '/home/evalyn/Documents/Programming/C/obos/config/initrd.tar', needed by '/home/evalyn/Documents/Programming/C/obos/out/obos.iso'. Stop.
create that file
then cd into scripts, run generate-initrd-x86_64.sh
then build again
then you should have a bootable iso
that should crash because it failed to load init
cp: -r not specified; omitting directory 'out/init' this stuff broke
dont make me fix it
im gonna have to fix this

why did u create a directory called out/init

it asked for it
doesnt mean its a directory lol
its the init program
which doesnt get compiled with clang enabled
wait what
what
yes
uhh I'll fix that
no thats a bug in the kernel on master
ahhh
i have amd and intel machines
then that wont work most likely
what wont?
btw how tf did you get build IDs to work?
they always fuck up on my kernel
amd
what messes up on AMD?
like the git commit
no clue, someone told me about a bug on amd cpus a while back
?
is it with systemcalls
no
this
it just doesnt boot
I just get cmake to run a command with git that defines a macro called GIT_HASH or something
idk
oh well
do it if u want
where do you init flanterm
im debugging that rn
if u want to try out obos u can use xbps to install packages btw
repo is http://obos-dev.ddns.net/current
@flint idol
Works on my machine
Let me try and
AMD
Yeah it really dosnt like AMD
damn
the fact that this is crashing because of that is weird
what clang version are you on?
My AMD 5700x hangs at startup on flanterm
not a number

what clang version
I got no clue
Same lmao
evalyn@EvalynPC ~ clang --version
clang version 21.1.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
thx
and you used this command right
im gonna try and reproduce this
yes
btw it still works on my laptop without the flanterm patch
just the same callback bug
im sorry to tell you this but your flanterm patch does nothing
on obos
on my pc, yes
Though wouldn’t stock flanterm use less memory than this idk?
Lmk if you need me to inspect anything else on my hardwares
the amount of memory it uses scales with the display resolution tmk
magnificent
and my display resolution is pretty massive
Stock flanterm has it fixed and it’s seperate from display resolution
It dosnt memory per pixel but somthing else iirc?
well flanterm does double buffer
The default buffer 100% could not fit a 1080p screen
Yeah but it stores it as charaters or other representation no?
I have no clue why giving it more memory fixes it
but it does
idk
im not mintsuki
maybe the memory you gave it at first wasnt enough???
wow really

They are using a seperate bump allocator seperate from flanterms built in one that’s backed by an empty file module from limine
Which I mean either way is fucking cursed as shit rather than just using the built in one imo
And idk how it interacts with other things but
how
flanterm init has the malloc and free parameters for a reason
Loading an empty file. And then binding it to a bump allocator for flanterm. Isn’t cursed?
Why not use standard malloc and frees?
terminal library's memory manager works better for terminal than other memory manager idk
what is this this is worse than i thought
because that is supposed to work
before anything is initialized?
So will the built in bump allocator 😭
its not empty, its all zeroes
This wastes disk space
ok cool
if you're fine with your fart wasting space then why aint you fine with mintsuki's almighty memory manager 9000
some1 get this guy outta here 🥀
I wonder how mint would react to this kind of usage of flanterm and limine
its not like he made the operating system
he aint important anyway 
cc @deep ember
Mint is on my friends list technically 
ANYWAY the kernel hangs sending an IPI
pretty sure I already told mint about this anyway
I told someone thats for sure
How did they react
for some reason this feels like a kindergartner saying they're friends with cthulu (admins are scary)
Did they say bravo good idea this is super good and intelligent
I lowkey just wana know why you don’t think this is cursed? And how it is better
Like what’s the reasoning
it isnt cursed because of its origins
monkey want, monkey do
the bootloader obos actually uses is hyper, which lets you have bootloader modules backed by memory
and the reason I ever overrode the flanterm bump allocator was because in some cases
flanterm would run out of memory
oh
and it is a non solution to patch flanterm to change the bump allocator size
I’ve never had that happen though i don’t use large monitors
What is your monitor size?
so my solution: a memory backed bootloader module so that the user can configure it to their needs
32 kilobytes
idr what caused this bug
i think it was a normal monitor
but a different font
was the font smaller
Yeah that’s why i needed my patch 
months ago
Can you try my kernel which uses the bump allocator
And see if it also crashes on you?
if you have an iso download sure
damn it now I actually have to do it

bad apple is everywhere
every time i see bad apple in the top right of the screen i get ptsd
Is my kernel just known as the bad apple kernel lmao
by me yes
no
Next kernel i make is gonna be called green apple 
serial: failed to init
And the kernel will be called bad apple
That’s normal
good apple
and then you're going to make a kernel for the apple mac 
I should make it a powerPC kernel
what am i supposed to react to lol
too late i did it first
all of it
This
^
wait why would you do that
Idk ask @flint idol
also please beware it's so horribly difficult you WILL hate your life
the docs are PAINFULLY hard to find
Isn’t that what OSdev is about
nono its genuinely horribler than what ANY limine or even mb2 kernel ends up being
it has been a week and i have found no actual way to get a hello world or a framebuffer
because flanterm would run out of memory and I didnt want to patch it to increase bump allocator size

the first thing you have to do is interface with PCI related crap, and also somehow figure out where your kernel is loaded because its actually in virtual memory
i want to run but i promised DO NOT DO IT
Try rebooting i think the TSC calibrated poorly because the ACPI timer sucks ass 
I keep having it do that
too much work
browhat
Atleast it dosnt match the frequency listen on Intels website for the base frequency
you don't need to patch it, i am fairly sure you can increase the bump alloc size with a flag lol
I have my own kernel to debug
They are giving it like 16+mb too
a compiler flag?
understandable
Maybe later 
@stark sigil why don’t you help me debug this
you didnt ask me to
(In the other Chanel)
I wanted it runtime configurable
I wonder if there could be a way for FT to bump alloc some logs to buffer until a proper malloc/free is hooked in
Or just buffer them yourself
Huh why is CR8 not zero? Do you set it to that?
because my kernel uses IRQLs
implemented on x8664 through cr8
Ahh
anyway I think the solution for my device will be to implement the x2apic
Oh yeah Intel arrow lake has no x1apic
that explains it
you served us well, x1apic
you will never be forgotten
im gonna continue with my usb keyboard driver now
because i need to "actually be careful with hotplugable devices" now
i am giving the usb keyboard struct a refcount
ok well i added some boilerplate code to the usb hid driver
for submitting IRPs to it
and doing I/O on it
but i am yet to actually add code for the driver itself
of curiosity, how does obos do device hierarchy internally? do all devices have (optional) parents in a unified way or is it a per-driver thing if a device has some parent/bus device it references, or are buses as devices not even a thing in obos?
it's a per-driver thing
and currently, no driver has a concept of device hierarchy
except, when I do USB hubs, such a concept will be added
none of that for pci-pci bridges?
devices on pci-pci bridges do not have anything like pci_bus* parent_bus
👍
side note as i scroll through irq.c, whats with these gotos that do nothing
also shouldIgnoreObjectCapacity is always false so this is always an infinite loop if it cant find a vector
those gotos at least do something near line 304ish but the shouldIgnoreObjectCapacity is still never modified so itll still be an infinite loop if it cant find one
no clue
(QOTD: "When I wrote this code, God and I knew what it does. Now, only God knows")
good catch
i think the first gotos i linked was copying from the other function, removing the continue, and then just not removing all the useless stuff that existed to skip the continue sometimes lol
lol
i need to fix a bug with xhci
when it reaches the end of a TRB queue
it fails to go back to the beginning
and so the HID driver hangs
nvm that's not the bug
but something in the xhci is breaking
causing the HID driver to hang
perhaps it's because the dequeue pointer is literally for a whole different queue...
fixed it
it turned out
i was trying to write the doorbell for the completely wrong endpoint
well i fixed that
and also added a link TRB at the end of each TRB ring
but now it hangs after receiving 2 pages worth of events
or well it doesnt hang
but the dequeue pointer becomes zero for some reason
nvm it isn't
the dequeue pointer somehow manages to become higher than the enqueue pointer
causing the trb queue function to return would_block
ok fixed that
now it hangs because it doesnt seem to find the link TRB anymore
fixed that
oh yeah
the HID driver can receive packets now
but it doesn't interpret any packets yet
which is a TODO for tomorrow
ill add mouse packet interpretation first because that is easier
then ill add keyboard packet processing code
and then ill test it ig
ill see if i can get a TTY working (in qemu) with it
then, i will implement usb hubs
and see if the HID+USB Hub+XHCI driver works on any of my devices
are you planning to do boot protocol or hid
boot protocol
L
well im gonna add the other protocol I just want smth basic to work first
this driver is currently only as a test for the xhci driver
anyway there is a bug
with the thing
if u detach an hid device after having submitted an IRP to it
then the kernel dies
use-after-free
i see the bug
well the mouse driver works
(barely)
input is really choppy for some weird reason
worse than the ps/2 mouse
I wonder what the polling rate is?
who knows
ok i fixed the choppiness
the driver wasn't polling the mouse fast enough
now for USB keyboards
ok well whoever designed this should kts
sudoku 
ok so im writing an algorithm to see what keys are released given the previous state of the keys and the new state
#define BITFIELD_DIFF(bitfield1, bitfield2, bitfield_out) \
do {\
for (int i = 0; i < (104/8); i++)\
bitfield_out[i] = ~bitfield1[i] & bitfield2[i];\
} while(0);
// ...
BITFIELD_DIFF(currently_pressed_keys, dev->pressed_keys, released_keys);
i think this works
time to implement usb hubs
i think i just get the hub descriptor and tell the xhci controller "probe these ports pls"?
this is schizophrenic
how do usb hubs work and interact with xhci
idk id assume usb hubs are just more usb ports
i mean that's objectively wrong
how they literally are 
at least physically
companies vs making the most reasonable solution for a problem
who the actual fuck designed this
i am currently reading a pirated usb book
that explains how usb works
and i am reading the usb hub section
and What The Fuck
actually
it's not that bad
this actually makes perfect sense
when a hub driver detects a device connected:
call enable slot to get a new slot
configure that slot to be associated with the port by setting the route string appropriately
profit
ok usb2 hubs work now
rn it goes: root hub->hub->hub->keyboard
hold on there is a bug
xhci: input slot context: 08000011 00010000 00000103 00000000
hm
this is supposed to represent 1.1.2
i removed the recursive hubs to make it easier to debug
but anyway
xhci: input slot context: 08000001 00010000 00000201 00000000
xhci: port 1.1 already assigned to slot 2
it's hacky
but it works
i think ive ironed out the last bug with the route strings and such
for tomorrow: finish usb hubs (implement the interrupt endpoint thingy), get root hub port enumeration to work on real hardware
the goal before i merge this branch is to get the xhci driver working as well as possible on my test subjects
and to have USB3 hubs implemented
and to make sure that hotplugging doesn't cause the kernel to shit itself
and after, ill add a usb block device driver
yo usb man how bad is usb to impelement (i think i have to implement that
)
fire
(also todo: implement isochronous trbs)
as long as you read the spec really carefully then you might be fine
cant
why, 2011 device?
2001 ibook
bruh

start with xhci anyway, test on qemu
i feel like xhci gave me a better way to grasp the concept of usb
cant do the second one either
you can't use qemu?
it cant emulate powermacs correctly

im gonna port my os to x86 but thats later
yehs
yeah understandable
it has like the worst firmware ever too
ehci made no sense to me, and you're going to be using uhci which is apparently even more schizo
oh no
im already a schizoid with picking osdev for powerpc i think ill be fine
thx
todo: fix this and make it use xor
nvm
I tested the logic, it doesnt make sense for this case
with xor, i found that if a key is pressed for one keystroke then it is reported as being released instantly
which actually might be correct behavior?
I'll test it after school ig
Portable C standard library. Contribute to OBOS-dev/mlibc development by creating an account on GitHub.
I need to fix this bug in my mlibc sysdep
yeah the xhci driver doesn't work on real hardware
i decided to try and submit a NOP COMMAND trb
and it just hangs
without so much as an irq
i will note that this device seems to use msi
for the xhci controller
reminder to self: fix the bug on line 602 of xhci.c
what's bug
its an if statement with the wrong condition
while the code is not technically wrong it makes the kernel have to do unnecessary stuff
oh and I also need to fix a bug on line 967 of xhci.c and line 975
not the waterloo of napoleonic (and abba) fame
I mean the same Waterloo that did this to stufents
yes
I dont go
Ohhh
im still in high school
Ahhh makes sense
its a contest for high schoolers nstuff
definitely
Ive wanted to participate before but I've never been to a school with a programming club or whatever that organizes these kinds of things
and you cant enter as an individual
yeah uwaterloo is one of the top CS/Eng unis
this is the first step to IOI btw
then there's CCO (canadian olympiads)
then if u win all of that you go to IOI
aight so either tomorrow or after exams im gonna find the teacher and register for this
i fixed the bug with TRBs on real hardware
fuckass xhci spec
"oh yeah on top of having to set the CCS bit in op_regs.crcr, you also have to set the cycle bit in the first trb because fuck you"
usb's a bitch

when i was doing xhci i had pain with real hw too
i just want the CCS bit to be set man

January 20th, 2026, at 2311: I am debugging XHCI, it is driving me insane. I can hear voices when I sleep telling me about TRBs and xhci stuff and I think I am going insane.
(diary entry end)
ok it is kind of almost getting there
wtf
i managed to make it try to initialize a disconnected port on qemu
i should git reset my changes and try again icl
like i managed to generate the bit out of thin air on qemu
so like
it hangs on waiting for the ADDRESS_DEVICE to finish
and one thing i noticed is that the portsc has the port link state as "compliance mode"
which seems suspicious
TODO for whenever i get back to this: rewrite the port attach and reset logic
after that i think ill have a working xhci implementation on real hardware
because TRBs work
and well that's pretty much all that matters
anyway gn yall
tomorrow im studying for an exam probably so
wont work on this most likely
and thursday im studying for my other exam on friday because well procrastination at its finest ig
and i will have time on the weekend
and on monday i will study for my exam on tuesday
then im done
and i will be free once again
god willing
send iso i can test it on my hw
when i actually get correct code, sure
fucking hate
xhci
and usb
WHY WONT YOU JUST REPORT A GODDAMN CONENCTION ON THE ROOT HUB
JOB HAD ONE BRO
AND BRO FAILED JOB
wtf is wrong with my hardware
there's an xhci controller
for no goddamn reason
i booted into linux
and the usb3 root hub is completely unused
wtf is wrong with hardware, who designed this shit
nvm
it's just a USB2 hub on the xhci controller
with all my devices connected on it

kms
what have i done to deserve this
all ports are in RxDetect
two ports never even get the reset bit cleared
sdfgsdjoikgfhdsfjkgdsfhjgkfdshngfd
i think there was no good luck with the usb rituals
i dont think so no
osdev 
(THAT'S NOT EVEN SUPPOSED TO BE FUCKING POSSIBLE)
qemu problem?
NO THIS IS ON REAL HARDWARE
it doesnt follow certain specifications correctly
(xhci spec) Only a USB3 protocol port may fail the bus reset sequence. USB2 protocol ports
never fail the bus reset sequence.
resets USB2 port
reset fails
fsdfdsklfsd
And that is why I'm not even going to touch the spec in a looong time
yknow what maybe the problem is with the bios handoff code
like maybe the bios still thinks it has control of xhci
and is doing evil shit
Never trust the bios
(this is not the case)
im reading freebsd code
it has gotten to this point
haiku maybe?
nvm
on qemu: amazingly
on real hardware: terribly
ok well ive an English exam tomorrow
its like there's an essay question on there and like I dont wanna write it but like I have to because like its worth 80% of the exam mark
so tomorrow after my exam: continue work on this, maybe ill try it on another device
(maybe I should study for my exam on Friday instead? hm)
I do remember seeing some youtube tutorials on XHCI that showd it worked on real hardware and how to get it working? Might be a long shot but maybe they have something?
idk about that
anyway im studying some stuff i mightve forgotten for my exam to make sure I dont blank tomorrow
im having absolutely no luck with this
so my solution: use the kernel gdb stub
this is my only hope
fack the gdbstub doesn't work anymore
or ig it's that the network stack is being doodoo
and not the gdbstub
maybe you could pass through the controller to qemu? though I guess it depends on what controller your keyboard/mouse are connected to if any, if they are connected to the same one then its probably not a good idea
nah, i dont think this pc has passthrough
(as in the test subject)
so that's not an option
it doesn't have an iommu?
nope, not to my knowledge
i mean there's no harm in checking
oh there is an iommu

usb hates me
i do passthrough, now instead of getting port reset errors
im getting trb completion code 4
"USB Transaction Error"
that is a really annoying error due to how many different things it can be caused by
wait apparently im supposed to send ADDRESS_DEVICE twice
twice ???
isnt it only one time
idk
let me check the spec, because as i know that always helps me with my problems /s
For some legacy USB devices it may be necessary to communicate with the
device when it is in the Default state, before transitioning it to the Address state.
To accomplish this system software shall issue an Address Device Command with
the BSR flag set to ‘1’. Setting the BSR flag enables the operation of the Default
Control Endpoint for the Device Slot but blocks the xHC from issuing a
SET_ADDRESS request to the device, which would transition it to the Address
state.
A USB Transaction Error shall be generated if an error is detected on the USB
SET_ADDRESS request and the Device Slot shall not transition to the Addressed
state.
amazing, very useful
(what was the goddamn error)
yo wtf is the xhci controller smoking
