Fingel has quit [Remote host closed the connection]
Fingel has joined #osdev
simjnd has joined #osdev
simjnd has quit [Ping timeout: 252 seconds]
_whitelogger has joined #osdev
simjnd has quit [Ping timeout: 260 seconds]
simjnd has joined #osdev
Matt|home has quit [Read error: Connection reset by peer]
simjnd has quit [Ping timeout: 248 seconds]
<dumb0>
is limine that good? just grub it, scrub
<Mutabah>
Afaik, limine has a boot protocol that puts you immediately in long mode, which can be nice
pabs3 has quit [Ping timeout: 252 seconds]
simjnd has joined #osdev
simjnd has quit [Ping timeout: 260 seconds]
arminweigl has quit [Ping timeout: 265 seconds]
m3a has quit [Ping timeout: 260 seconds]
<parabirb>
im more of a multiboot enjoyer
<dumb0>
TIL
<dumb0>
im so new to this stuff
<dumb0>
good thing to know that almost every aspect of osdev is standardized
<zid>
multiboot 1 for life
<zid>
bootloaders are very very not standardized
<dumb0>
ah
<zid>
The good thing about boot standards for x86 is that there are so many to pick from
<dumb0>
boot standards as in boot protocols?
<zid>
I should go back to using LILO
<dumb0>
multiboot has just two versions
<dumb0>
slack still uses LILO
<zid>
and lilo and linload and kexec and limine and pxe and and and
<dumb0>
:3
<dumb0>
i see
<dumb0>
thanks zid
<zid>
I boot my shit via multiboot by using a 32bit 'kernel' that is just a bootstrap for my 64bit 'module', cus I am weird
<kof673>
Jul 8, 2012 · Try to start Linux with the linld.com command. It can handle big kernel images (>4 MB) and a big initrd (>10 MB)
<kof673>
'big'
<kof673>
loadlin is a Linux boot loader that runs under 16-bit real-mode DOS loadlin.exe versus linld.com ..........
simjnd has joined #osdev
<dumb0>
LOL i just opened the old logs file from 2018 (52Mb) and it crashed my sweet little vi
<dumb0>
kof673: do you like limine?
<dumb0>
what do you use for your kernel?
<kof673>
no kernel yet, i just made a thing with nasm though and pxe functions
<kof673>
i will try to run in userland hosted elsewhere and ............interceptor pattern to bare metal eventually
<kof673>
c89 doesn't know the difference :D
<dumb0>
btw stage0-posix is really cool, it starts from hex0, it's pure wizardry
<kof673>
i really want a vm and bunch of other stuff...i just jump around as long as i am making progress on one thing or another...want an fs too, have an untested malloc, etc.
<dumb0>
sweet
<kof673>
i mean that can all be tested in userland on existing os
<dumb0>
qemu gdbstub?
<dumb0>
thats what you mean, right
<kof673>
no, i mean you can make a filesystem and just use FILE * until you get to real hw
<kof673>
instead of a real actual disk/talking to hw directly
arminweigl has joined #osdev
<kof673>
or a "memory fs" that lives in ram
<kof673>
or something like dos...likely puts few barriers between a "userland program" and talking to hardware :D
<dumb0>
i think i understand what you're getting at, ring0 application
<dumb0>
we can a ring0 application in userspace
<dumb0>
write*
<dumb0>
isn't a FS just a data structure sitting on the disk?
<bslsk05>
wiki.osdev.org: Richard Theseus - OSDev Wiki
<kof673>
i mean formerly a disk was perhaps just viewed as permanent memory
<dumb0>
how does ext2 work
<dumb0>
i have no idea
<dumb0>
:-(
<the_oz>
in freebsd anything that implements a GEOM interface is disklikeish
<the_oz>
better abstraction
<kof673>
^^^^ geom is nice, arbitrary stackable ordering. how do you access ext2? via ls cp mv ? i mean at some level you *could* just have to implement whatever system calls those use
<kof673>
i mean a normal ext2 user doesn't need to know anything, they use commands, that use an api, that use system calls, etc.
<dumb0>
hmmm
<kof673>
what i mean is oo-wise...you can say just need to implement whatever api, e.g. posix, and the rest can arguably be a black box, how it actually works
<kof673>
i'm not being evasive, i just mean there are layers between what a normal user sees, and what actually is going on :D
<dumb0>
i see
<dumb0>
i dont do OO however
<kof673>
sure, just at some level have to decide how much you want to split kernel land and userland perhaps
<kof673>
what access should a normal program have
<dumb0>
run in protected mode? sorry im dumb
<dumb0>
for ext2, wikipedia says
<dumb0>
> Each block group contains a copy of the superblock and block group descriptor table, and all block groups contain a block bitmap, an inode bitmap, an inode table, and finally the actual data blocks.
<dumb0>
> The superblock contains important information that is crucial to the booting of the operating system
<dumb0>
also inodes are a thing
<dumb0>
lol
<kof673>
gxemul has some ...imaginary machines with imaginary hardware, but should be easy to get C code going there on simulated "bare metal" with imaginary hardware so i may look at that more :D
<Mutabah>
Normal programs don't tend to interact with the on-disk filesystem structures, instead the OS exposes an open/read/write/close API that abstracts that away from the user
<kof673>
^^^^^^^
<dumb0>
thanx Mutabah :3
<Mutabah>
So `open` would split the provided path on `/` and ask the filesystem driver "in the directory with inode X, what's the inode of the file named Y"
<Mutabah>
(and keep going until you've run out of components in the path)
<dumb0>
so like a tree traversal, not sure what kind of tree lol
<dumb0>
kof673: have you tried mmix?
<kof673>
no, but i believe gcc can target it :D
<kof673>
i just meant gxemul likes dead simple to get a framebuffer and a few other fake devices for its simulated machines :D
<kof673>
*looks
<kof673>
and you can do something similar to qemu -kernel i believe too, so don't need a bootloader either
<kof673>
just pass it an elf or whatever...
<dumb0>
gotta try it, sounds fun
<kof673>
the gxemul source code has samples for those fake machines and fake hw, need to build a proper toolchain of course :D
<kof673>
i'm not gdb and stuff, but ...does playstation 1 have it? dreamcast? n64? i tend to just do printf debugging :D
<kof673>
*not against
<kof673>
i have no idea how much work it would be to make a "stub"
<kof673>
atari jaguar :D
<the_oz>
I assume it's just as easy as defining a name in the first place?
<the_oz>
but that's based on how I wqould implement a stub
<the_oz>
whst does it mean
<dumb0>
i think it only makes sense if you're going to use the gdb remote serial protocol, kof673, like qemu does
<dumb0>
basically it allows you to put that functionality into any application
<bslsk05>
mborgerson/gdbstub - Simple, single-file, dependency-free GDB stub that can be easily dropped in to your project. (29 forks/234 stargazers/MIT)
<kof673>
my understanding is you can add the ability for gdb to talk to any kernel, just did someone write the needed bits yet or not :D i was just saying in general i try not to rely on gdb being present -- anywhere
<kof673>
those types of places you might have a serial-type link, so i believe it is possible, just a question if someone implemented it yet or not :D
<kof673>
real hw i mean :D
remn has quit [Ping timeout: 252 seconds]
goliath has joined #osdev
_whitelogger has joined #osdev
<Mutabah>
yay! Making progress on real hardware.
<GeDaMo>
No more blank screen?
<zid>
I gave up on real hardware, usb devices are mean
netbsduser`` has joined #osdev
<Mutabah>
GeDaMo: yep. It was hitting a panic in parsing the multiboot memory map
<Mutabah>
zid: netboot ftw
<zid>
had a similar issue on nikolar's laptop
<zid>
his e820 was a *mess*
<zid>
had zillions of holes in it
<zid>
like they'd given the tables static bases, and left 32kB gaps for them in case they were 'big'
<zid>
then reclaimed all the unused space
<zid>
so it was 4k table, 28k free, 4k table, 28k free, etc
<Mutabah>
Heh, this was lazy code looking at the lomem/himem fields, and had an assert that lomem was basically all available
<zid>
I just didn't have enough buffer space, oops
<Mutabah>
Now it's having trouble finding the IOAPIC in the ACPI tables
<Mutabah>
Ooof, that is a complex one... not sure how my logic would handle it
<Mutabah>
I _think_ I have coalescing logic
<zid>
I only care about APIC (MADT) and MCFG
<zid>
ioapic is for fancy people
xenos1984 has quit [Ping timeout: 248 seconds]
xenos1984 has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 245 seconds]
<Mutabah>
I went fancy, unfortunately
<zid>
I don't think nikolar's eeeeeepc has an ioapic :P
<nikolar>
zid: : i think it was your laptop that had a sucky e820
<zid>
oh was it, maybe
<nikolar>
Yeah kek
<zid>
and yours had 4k only
<zid>
well, 4k/2M, was lacking 1G importantly
<nikolar>
Ye
<zid>
Kin of Ralo, how did your F1 practice go
<zid>
who practiced the best?
xenos1984 has quit [Ping timeout: 276 seconds]
<nikolar>
Norris qualifies best
<nikolar>
*qualified
xenos1984 has joined #osdev
karenw has joined #osdev
goliath has quit [Quit: SIGSEGV]
<zid>
nikolar: What trac was it?
<nikolar>
Monaco
<zid>
oh, so the race is already finished then
<zid>
everybody finishes in quali order the end
<nikolar>
they have to change tires twice this time
<nikolar>
might mix things up
<zid>
my god
<zid>
so whoever has a bad stop gets to lose places in the 'race'
<zid>
amaee
<zid>
amez
<nikolar>
indeed
msv has quit [Remote host closed the connection]
msv has joined #osdev
msv has quit [Remote host closed the connection]
msv has joined #osdev
simjnd has quit [Remote host closed the connection]
simjnd has joined #osdev
simjnd has quit [Remote host closed the connection]
<Mutabah>
Anyone here worked with XHCI? Any ideas on why I'd get what seems to be a deadlock upon starting the controller
<Mutabah>
(... MIGHT be that it immediately generates an interrupt, and then deadlocks somewhere in interrupt handling?)
<sortie>
Interesting
simjnd has joined #osdev
<sortie>
I wonder if you could reproduce it in a VM, that'd make it easier to see the registers
simjnd has quit [Ping timeout: 252 seconds]
simjnd has joined #osdev
<Mutabah>
sortie: Might be a good idea
simjnd has quit [Ping timeout: 276 seconds]
<zid>
Mutabah: I did EHCI :(
<zid>
I never actually used interrupts, I just polled the interrupt bit to see if forward progress had been made
<zid>
which was just status & 1
karenw has quit [Ping timeout: 252 seconds]
<zid>
I'll only do interrupts for the periodic events, async shit I just poll, and I've only been doing async shit so far
<zid>
(no HID reports, basically)
<zid>
I had a bear of a time actually getting the controller playing ball and not getting stuck etc, so.. gl hf
<Mutabah>
xhci is nice... but complex
<Mutabah>
it does all USB versions on its own, so no need for uhci/ohci and ehci
<zid>
yea
<zid>
it exposes ehci again though, but via 'rate matching hubs'
<zid>
and I don't have hub support, rip
<zid>
so I can't actually use xhci controllers even in ehci mode
<zid>
I was getting random failures and lockups for a long while, eventually realized I had left bios legacy keyboard emulation enabled, and when I was poking the controller, it was upsetting the SMM code and crashing it :P
karenw has joined #osdev
<zid>
(I was acking things and the controller then spin-looped to try do the same thing, I'd guess)
<zid>
err the smm code then*
simjnd has joined #osdev
simjnd has quit [Remote host closed the connection]
simjnd has joined #osdev
benlyn has joined #osdev
kneskade has joined #osdev
<clever>
zid: hub is pretty simple, read an interrupt endpoint to get hotplug events, and a few control packets to enable/reset a port
<clever>
the interrupt report is just a bitfield, where bit N represents port N
<nikolar>
zid: also no usb device we tried wanted to get along
goliath has joined #osdev
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 252 seconds]
<zid>
clever: okay, how do I route?
karenw has quit [Ping timeout: 276 seconds]
<zid>
port is just a device, do I need to give the hub an address?
<zid>
hub is just*
<Mutabah>
Hubs get addresses
<Mutabah>
You assign the hub an address, then send control packets to it to turn the downstream ports on and enumerate devices on those
<zid>
yea so a bunch of code
<zid>
that I didn't write
<zid>
hardly a 'just'
<zid>
also I think once hubs are involved you have to deal with split transactions?
remn has joined #osdev
<zid>
(which sound absolutely awful)
<zid>
nikolar: one device, your ADATA thing :p
remn has quit [Quit: WeeChat 4.6.0]
remn has joined #osdev
<clever>
zid: for a usb2 only network, once you enable a downstream port, there will be a device at addr 0, where you can send normal control packets like SetAddress
<clever>
and once an addr is set, you can basically ignore the hub
<nikolar>
zid: tried multiple drives, remember
<clever>
just send packets to the right addr and it works
<nikolar>
each one acted differently
<zid>
clever: how do I address device 0 given I can't sub-address ports?
<clever>
all usb transfers have a 7bit device address in them
<clever>
you just need to assign a unique address to each device on a controller
<zid>
yes, and device address 0 is the one I want, but n devices will have that
<zid>
until they are configured
<clever>
all ports are disabled by default
<zid>
the way you get around that on the controller is that you have n *ports*, one per device
<clever>
using control packets to the hub, you enable one port at a time
<zid>
so you can enable each port in turn yea
<clever>
then SetAddress whatever is there, before moving to the next one
<zid>
right, so I can do the same on a hub
<zid>
as long as I can port control the hub
<zid>
however you do that
<clever>
normal control transfers to the addr of the hub
<zid>
with what data
<clever>
i forget exactly, but its all in the usb specs, and wireshark helps greatly
<clever>
on a linux machine, just do `modprobe usbmon ; wireshark` and you can see every control transfer (and others)
<clever>
ok, there it is, an interrupt IN transfer from the hub returned a 4, which is just 1<<2, so port 2 had an event
<clever>
linux then does a control-in with bmRequestType=0xa3, bRequest=0 (GET_STATUS), wIndex 2 (the port its querying), and wLength of 4 (the length of the reply)
<clever>
the hub then responds with a 32bit long bitfield of status flags
<clever>
SET_FEATURE PORT_RESET (bRequest=3 wValue=4) is then used to initiate a port-reset on the downstream port
<clever>
and then CLEAR_FEATURE (bRequest=1) is used to release that
<clever>
i think the standard says reset has to be held for 50ms?
<clever>
my memory is fuzzy, but i think after exiting reset, the port is active, and the device responds to addr 0
<zid>
yea fair, it's just
<zid>
a lot of code I never wrote
<zid>
plus I'd have to add the concept of a hub to the code, which means indirection on the devices
<zid>
which is a lot of support code to write
<clever>
split transactions is the nightmare i havent started yet
<clever>
to talk to a usb1 device behind a usb2 hub, you have to send a split-start packet to the hub addr, with the port# and speed
<clever>
and then after enough time has passed, send a split-complete to the hub
<clever>
that frees the bus up to do usb2 transfers while the usb1 device is busy
<clever>
lets say your moving a 64 byte packet to/from a low-speed (1.5mbit) device, thats about 6.6 uSec of bus time
<zid>
you're
<zid>
This is why you should just poll
<zid>
and wait for the devices to go ready etc :P
<clever>
in that timespan, usb2 could have moved 400 bytes
<zid>
or spin
<zid>
much easier, fuck usb1
<zid>
so yea, I got as far as doing a bunch of SATA commands
<clever>
so you could do a start-split to a usb1 device, a 512 byte mass-storage to a usb2 device, and then a split-complete to the usb1
<zid>
but it'd only return 64 bytes of the 512 byte sector, then I'd never get the completion
<clever>
are you handling the max packet size correctly?
<zid>
and I can't ask the sata end why it's upset, because it tells you why it's upset by adding 13 bytes to the *end* of the transfer
<zid>
controller does that
<zid>
I just have to set 512 as my max
<clever>
ah, when i was dealing with dwc2, it wasnt as handled
<zid>
"wasn(')t as handled"?
<clever>
that would be a 512+13 byte transfer, so you have to program the dwc2 to expect 525 bytes and 2 packets
<clever>
if you get the packet number wrong, you run into problems
<zid>
I don't have to deal with packet numbers
<clever>
also, 512 bytes, with a max of 512, is 512 bytes and 2 packets
<clever>
because its 512+0 on the wire
<zid>
yea it sends a 0
<zid>
if it exactly matches
<zid>
but the packet size is 64
<zid>
so it's actually sending.. 8 anyway
<clever>
yep, and a transfer only ends when the size isnt max
<zid>
and maybe 9 or 10, depending on whether it sends the csw as part of the final part of the transfer or sends it separately
<clever>
so thats 8 sets of 64, and a zero
<zid>
it either sends 64*8 + 13, or it sends 64*8 + 0 + 13
<zid>
but I only get the first one then it stalls somewhere
<clever>
probably 64*8 + 13
<zid>
and I have no usb analyzer to know how it's stalling
<clever>
qemu?
<zid>
qemu is the most
<zid>
easy bitch
<zid>
ever to live
<clever>
then the "host" can log your usb transfers
<zid>
qemu was working with *everything* I tried
<zid>
even intentionally wrong things
<clever>
ah
<clever>
yeah
<clever>
ive chcked the source, and qemu serial, basically ignores all init
<clever>
at any time, you can just write to the data reg, and it works
<zid>
the controller accepted nearly nothing, but I eventually got it working, and then the sata end accepted nearly nothing, but eventually I.. almost got it working :P
<zid>
now there's a weird issue between the sata and the usb, and I can't tell what
<zid>
without proto analyser
<clever>
another problem i ran into
<zid>
idk if the sata end even attempts to send more than one packet, or if it doesn't think it sent the first one right then freezes etc
<clever>
basically all HID devices, are usb1
<zid>
and it isn't setting error bits on the controller, it's just.. sending 64 then going silent
<zid>
which hangs my recv
<clever>
so, if i have a usb2 hub, then i cant do HID
<zid>
there's a proper STALL mechanism
<zid>
that it can do, which the controller can then tell me
<zid>
but I don't even get that
<zid>
if I check the qTD after a few ms, the transfer size has shrunk by 64, and I have some disk contents in memory, but everything else is 'fine'
<zid>
surely I don't have to create 8x64 qtds?
<zid>
nothing I saw suggested that was required
<zid>
it has space for 32kB of transfer
<clever>
oh, that reminds me, on the dwc2 controller, endpoint zero only supports 1 packet, device mode only i think
<zid>
it has 5 base addresses for each page so they don't even have to be contiguous etc
<clever>
and nearly all of the online documentation, makes no mention of that
<clever>
so you do wind up having to do 8 x 64 transfers, and the hw lacks a queue
<clever>
so you have to wait for each 64 byte transfer to finish, then start another
<zid>
EHCI spec says you have 5*4kB all individually addressed, kinda cool (and we're using intel ICH7, so a good chip)
<zid>
so it's definitely "wrong", to do 8x64, imo
<clever>
something i still need to get around to, is emulating ehci and ohci
<zid>
but
<clever>
oh right, how do the 2 interact?
<zid>
it'd be identical anyway
<clever>
what happens if a usb1 device is plugged into a usb2 capable controller?
<zid>
cus I *still have a pending 448 byte transfer descriptor*
<clever>
can the ehci side even interact with it? or must you speak ohci?
<zid>
there's things called companion controllers
<zid>
each set of 2 ports is also a usb1 controller
<zid>
so when you do device enumeration you'll see an 8 port ehci controller, and 4 two port OHCI
<zid>
and when you do device detection for ehci, you can unset a bit to 'release' that port
<zid>
to the ochi controller
<clever>
ah
<zid>
if you see a non high-speed device
<clever>
so basically, you need to detect the speed of the device via reset, then move the port to the right controller?
<zid>
yea
<zid>
there's 2 bits and 1 1 is illegal, 1 0 is high speed, 0 1 is full speed, 0 0 is not plugged in, or something, idk
<zid>
it does some crap with the J and K lines, holding them high or low to tell you what the device is
<clever>
yeah, let me find that, one min
<zid>
and the controller b asically just mirrors those to those two bits in the port control reg
<clever>
there it is, a low-speed device has a pull-up resistor on the D- pin
<clever>
a full-speed or high-speed device has the pull-up on D+ instead
<clever>
and the host has pull-down's on both
<clever>
so upon insertion, the 2 resistors form a voltage divider, and that unique voltage signals a new device, and it being on D+ or D- signals the speed
<clever>
during the reset signal, the host will send a 480mbit chirp down the pair
<clever>
a full-speed device wont respond, but a high-speed device will respong with its own 480mbit chirp
<zid>
ah there we go, bit 13
<clever>
so thats how it tells the difference between FS and HS
<zid>
System software uses this field to release ownership of the port to a selected host
<zid>
writes a 1 to this bit when the attached device is not a high-speed device. A 1 in this bit
<zid>
means that a companion host controller owns and controls the port. See Section 4 of
<zid>
controller (in the event that the attached device is not a high-speed device). Software
<zid>
the EHCI Specification for operational details.
<clever>
i would assume that by default, the OHCI is in control of all ports?
<zid>
no
<zid>
[13:53] <zid> so when you do device enumeration you'll see an 8 port ehci controller, and 4 two port OHCI
<zid>
[13:53] <zid> and when you do device detection for ehci, you can unset a bit to 'release' that port
<clever>
but what if the host only has OHCI drivers?
<zid>
ohci driver would have to know about ehci
<clever>
isnt this whole mess for backwards compat?
<zid>
to do it the other way around
<clever>
ah, do i have the 2 mixed up again....
<zid>
you can do just a 'stub' ich7 driver this way, and only support usb 1 + releasing ports
<clever>
i dont think so
<clever>
EHCI is usb2
<clever>
while OHCI is usb1
<zid>
you still need a controller driver
<zid>
no matter which version of usb you support
<clever>
and i believe there are also OHCI only cards?
<clever>
from the pre-usb2 days
<clever>
and i thought the whole point of this mess, is that an OHCI+EHCI card, can function with just OHCI drivers, in usb1 only mode
<zid>
it can
<zid>
but it still needs *ICH* drivers
<zid>
to enable the usb controller etc, regardless
<clever>
ah
<zid>
and disable usb legacy unless you want hardlocks at random, etc
<clever>
i was considering a non-intel case, where you just have a generic OHCI+EHCI pcie device
<zid>
usually those just have hardcoded ports
<clever>
spefically, i'm working on the xbox 360
<zid>
the ICH is special for having the ports be multiplexed imo
<clever>
specifically*
<zid>
I actually had to buy an OHCI card
<zid>
to get my PS3 peripherals working on PC
<clever>
the 360 has 2 pci(e?) devices with 4 functions
<clever>
oh, that reminds me, my main desktop is dual-boot between nixos and win7
<zid>
UHCI*
<clever>
a year or 2 ago, i upgraded the motherboard/cpu/ram/gpu
<clever>
then one day, i tried booting win7, only to discover, no usb
<zid>
VIA VTL6216 or whatever it is, ICH works fine with them, and that one via chipset does
<zid>
but nothing else
<clever>
the motherboard is XHCI only, a single controller
<clever>
and win7 lacks XHCI drivers
<clever>
and the motherboard lacks PS2
<zid>
win7 does not lack xhci drivers
<zid>
it lacks *your* driver
<zid>
:D
<clever>
i tried and failed to find it :P
<zid>
did you use sp2 or whatever
<zid>
or the grotty old original disk
<clever>
it was fully up to date
<clever>
at the time of last booting
<zid>
anyway, everything that is xhci, is xhci only
<clever>
i did also boot the nvme in qemu, with an xhci device
<zid>
unless it has extra usb controllers
<clever>
except the rpi
<zid>
xhci just makes you deal with ehci/ochi via rate matching hubs
<clever>
the usb-c port on the pi4/pi5, is shared between dwc2 and xhci
<zid>
most of my boards have had like 12 usb ports though, so they've had 4x xhci, and entirely separate ehci controllers for the other 8
<zid>
because it's cheaper
<zid>
and the ports are all colour coded to let you know which ones are the xhci ones
<clever>
yeah, the usual blue stuff
<zid>
I have a fuckin
<zid>
red one
<zid>
on this board
<clever>
lol
<zid>
usb 3.2
<clever>
i also recently found on hackaday, a blue usb2 port
<zid>
my last board before this one had 2 xhci, and 8 ehci just on the back
<zid>
plus another set of 2 xhci for the front
<zid>
and it was a fuckign microatx
<zid>
Those one has.. two red, 3 blue, 1 white, and is full sized. rip
<zid>
oh and a type-c, weird
<clever>
according to my notes, pci device 4/5 are the usb controllers on the southbridge of the xbox 360, both have function 0 as OHCI, and function 1 as EHCI
<clever>
device 4, is a 4-port controller, and device 5 is a 5-port controller
<clever>
where each port goes, varies by model, with some of them having an internal usb wifi, all of them having an internal usb controller dongle, and some having usb in a custom connector for "memory cards"
<clever>
plus regular usb-a
<clever>
so i assume that a normal OS, would do an EHCI reset signal, any time a port has a device, and then use a muxing thing to pass the device off to either EHCI or OHCI?
<clever>
and then the right driver handles things from there
<zid>
yea init for ich7 looks like resetting the controller, then resetting each port, and checking what shows up device wise, then if it's not full-speed you chuck a 1 into bit9 or whatever it was
<zid>
and then it'll show up when you enumerate ohci after
<zid>
presumably
<zid>
as being connected to one of *its* ports
<clever>
from what i remember, you dont need to reset each port on init
<zid>
probably not, but I was told to
<clever>
there is a port status register, that tells you if something is connected (with irq's on changes)
<clever>
and then you can reset only the things with a device present
<zid>
and you only ever want one port out of reset
<zid>
while you enumerate devices
<clever>
yeah, because that gets addr 0
<zid>
so you're walking each port regardless
<zid>
and you just reset the controller, so it's forgotten all the port details
<clever>
once you SetAddress, you could move on to the next port, and get more async
<zid>
so resetting the device makes sense, maybe the controller was in debug mode before the reset?
<zid>
reset the port end too to tell it to stop that shit
<clever>
i think xhci also automates the whole SetAddress for you?
<bslsk05>
github.com: tinyusb/src/host/usbh.c at master · hathach/tinyusb · GitHub
<clever>
ah, there it is, if the hub address is 0, then its the hub within the controller, and it should do reset via an HCD call
<zid>
If you wanna leave your devices in a shitted-up state because the controller went offline for 10ms that's on you I guess :P
xenos1984 has quit [Read error: Connection reset by peer]
<clever>
but if the hub-addr is non-zero and hub support is enabled, it will use a control-in to query the hub status, and the state machine will then do another control transfer to reset
<zid>
hey I bet at least *most* of the time they won't notice! Just hope the last guy to touch those devices didn't leave them in a strange state I gues.
<clever>
my thinking, is that no matter the state, a LS or FS device always has the pull-up resistor
<clever>
so after some time, it will stop transmitting, and then the controller will detect that as an insertion and then you reset it
<zid>
you are the controller
<zid>
and you do the resets
<clever>
but now that i think of it, HS disables the pulls, so i'm not sure what that will do
<zid>
not sure what resistors have to do with it though
<clever>
the D+ and D- have pull-down resistors, so an unused port will have 0v on both pins
<zid>
great, but it doesn't have anything to do with anything
<clever>
a low-speed device has a pull-up on D-, so when you plug that in, D- will have some voltage on it, a mid-point
<clever>
and a full-speed or high-speed device, has the same pull-up on D+
<zid>
the controller spazzes out for 10ms because I reset it, this has somehow.. connected and disconencted resistors?
<clever>
the resistors will still be present, so the HCI will report a device as being present in the port
<clever>
and only if a device is present, do you need to reset the port
<zid>
yes, resetting a port without a device there is ultimately not fruitful
<zid>
but that is not what we were talking about
<clever>
what i was saying, is to just reset ports with devices, rather then resetting every port
<zid>
But I can't actually rule out that the data isn't valid in the portscr register until you reset it
<zid>
either
<zid>
idk why you'd risk it
<zid>
it says to do it, it makes the code honestly simpler to do it
<zid>
and it risks it randomly not working if you don't
Turn_Left has joined #osdev
<zid>
If I've learned anything from fucking with hardware, it's to be overly anal as shit even if you have real hw to test on, cus it WILL do the dumb on *someone's* machine :p
<clever>
yeah
<clever>
that reminds me, the vl805 pcie<->xhci controller found on the pi4, has a hardware bug
<zid>
blame via
<clever>
under certain conditions, something with the usb transfer will fail and retry
<clever>
but it wont properly rewind the data fifo
<clever>
but, it only occurs when writing 512 byte blocks to mass-storage, and only with certain timings on usb3
<zid>
nice
<clever>
as a result, fat32 with 512 byte clusters, will just corrupt the shit out of your files
<clever>
but ext4 with a larger cluster size, just never notices
Left_Turn has quit [Ping timeout: 265 seconds]
<clever>
from memory, i think that needed at least a usb3 analyzer to zero in on
bauen1 has quit [Ping timeout: 252 seconds]
<clever>
but once it was fully identified, linux was patched to avoid the problematic XHCI patterns
<zid>
good news, MSD devices are also buggy as shit
<zid>
so even if your controller isn't fucky, your devices probably will be :P
<clever>
yeah, ive seen numerous UAS bugs too
<clever>
rpi has gotten new vl805 firmware to fix some of those bugs
<zid>
half the sata set will just freeze the device
<clever>
but, the vl805 is also found on pcie expansion cards for x86
<clever>
and those often dont get firmware updates
<zid>
the other half reports bullshit default values
<clever>
xhci is meant to "just work", and the whole firmware update thing is hidden
<zid>
you basically have to send it exactly what windows will send it or it'll go to shit, if it's a cheap chinese usb drive, it seems
<clever>
one guy i talked to, was able to use the rpi vl805 blob, to update a PC vl805 card
<clever>
and while it did fix the UAS bug, it also downgraded 2 ports to usb2 speeds
<zid>
I found a partial wireshark trace to see what linux sends, at least
<clever>
when i `modprobe usbmon`, i get 3 of these, and then i can select one in wireshark
<clever>
but when i do it on an rpi thats acting as a usb device, i get 2 of them, and it only has a single usb controller, so what is happening...
<zid>
I wonder if I am just.. not waiting long enough between commands or whatever, and it's lying about being ready
<clever>
maybe?
<zid>
and linux, because it sends a bunch of bonus double commands
<zid>
ends up waiting longer
<clever>
looks like thats a bust, usbmon doesnt seem to work in device mode
<clever>
but i did at least learn how to use it over ssh
<clever>
`dumpcap -i usbmon1` just works, heh
remn has quit [Quit: WeeChat 4.6.0]
remn has joined #osdev
frkzoid has joined #osdev
<untitled>
Hello all. I am writing an OS for RISC-V arch (currently only in qemu) and am a little stuck with virtual memory. The whole code is here https://github.com/nastonen/SystemN/ if someone could be kind enough to point me in the right direction, I'll be happy to walk you thru the problem
<bslsk05>
nastonen/SystemN - My take on RISC-V UNIX clone (0 forks/0 stargazers/BSD-2-Clause)
<heat>
what's the question?
<zid>
what's the question?
<zid>
"I am making a car from scratch, but I'm having trouble with ENGINE"
<untitled>
I'd have to walk you thru the code, but if you want a question: why I can't access kernel_pagetable from a user process's context in schedule()? sched.c line 56. I get a 0x0d trap
<zid>
did you map it in? with permissions that a user can access?
<untitled>
yes
<untitled>
in create_proc() in proc.c
<zid>
does qemu agree? I assume info tlb or whatever works for riscv
<heat>
info mem
<untitled>
I can get into the scheduler, so yes, it can read the kernel memory
<heat>
ok so it's just the kernel_pagetable variable you can't access?
<untitled>
if you want to follow, start.c s_mode_main() is the starting point
<untitled>
heat: it seems so...
<zid>
bad relocation, not all of kernel mapped (.data/.bss missing) etc?
<untitled>
zid: doesn't look like it, it's all in kernel.ld and should be fine
<heat>
general tip: use info mem + info registers (inspecting scause, tval is particularly important)
<zid>
untitled: you need to actually check
<heat>
it might be that something weird is happening
<zid>
what address is faulting
<zid>
is that address a 'good' address
<heat>
^^
<zid>
and where is it supposed to be mapped to
<zid>
The thing is with code not doing what you expected, is that it's not doing what you expected :P Which means inspecting all your expectations and verifying them against reality.
<heat>
yeah
<heat>
your kernel seems advanced enough and proper enough that 1) I can't quickly see if something is stupidly wrong and 2) you seem to be on the right track
<zid>
at least you got a crash
<zid>
and not random nonsense that makes no sense!
simjnd has quit [Ping timeout: 260 seconds]
<untitled>
the trap 0x0d (Load Page Fault) occurs just when I try to load_pagetable(kernel_pagetable), so I figure I don't understand something about memory protection in RISC-V, it's not just a stupid bug. I've been fighting with it for days
<zid>
okay but
<zid>
what instruction traps
<zid>
what value does it have
<zid>
where does that value come form
<heat>
tval and epc from the trap pls
<zid>
does that value look right
<untitled>
0 schedule() run...
<untitled>
0 switching to idle
<untitled>
Trap: 0x000000000000000d
<untitled>
sepc: 0x0000000080002c00
<untitled>
stval: 0x000000008000a1a0
<untitled>
Trap on idle core? Should not happen, Halting...
<untitled>
if you want to clone it and run, you should see the same
<zid>
if it's the page table enabling instruction (however that works on riscv) then presumably the page tables themselves are incorrectly structured, but if it's just a fault accessing memory while setting them up, or the classic "I forgot to identity map my bootstrap" issue
<zid>
(where the first instruction after enabling paging faults because you mapped the higher half, but not the .text page containing load_pagetable in the lower)
<untitled>
the thing is, everything works right up to the moment when a user process tries to access kernel_pagetable to switch to idle process. I map everything correctly and the pagetables work fine before that. So it's a privilege issue I guess
<untitled>
but I really need a risc-v specialist here :)
<heat>
i hope you're not in user mode while doing that?
<untitled>
it's in schedule(), so no, it's S-mode, but in user context (still using user proc's pagetable)
<nikolar>
are you sure it's using the user's page tables
<untitled>
there is no pagetable switching before that so yes
<nikolar>
i don't know how riscv does it, but is it possible that it automatically switches to the kernel's page tables
<heat>
no
<zid>
I'd laugh if there's a pending irq and the switch consistently unblocks it and instacrashes
simjnd has joined #osdev
bauen1 has quit [Ping timeout: 276 seconds]
<untitled>
I already ruled out all the easy reasons before coming here. It would take some effort to follow the code really =\ I'm here to guide anyone who is willing to weigh in
<zid>
well, I asked questions to my guide
<zid>
and got nothing
bauen1 has joined #osdev
<heat>
info mem
<heat>
post it
netbsduser`` has quit [Ping timeout: 276 seconds]
<heat>
that swtch() function is super broken btw
<dumb0>
kof673: > those types of places you might have a serial-type link
<dumb0>
uart debugging? if there's no gdb in that case, how do you poke memory?
<untitled>
heat: it worked with flat memory before I enabled mmu
<kof673>
no, i meant gdb can probably be made to work with any serial-type link
<heat>
untitled: you're not saving/restoring status
<dumb0>
i see, ignore me being silly :P
<kof673>
bigger problem is probably what if !elf :D
<dumb0>
yeah, well and that's just basic IPL no?
<dumb0>
initial program load
<untitled>
heat: mm.. it's a kernel-level context switch, it's expected. The actual switch is in trap_vec.S
<untitled>
in trap dir
<heat>
ok so this schedule() call isn't analogous to the linux schedule()?
<untitled>
haha, I don't know, I haven't read linux sources
<heat>
if you're doing any sort of code execution with another thread's context
<heat>
hmmmmm actually this is fine, i guess
m3a has joined #osdev
dumb0_ has joined #osdev
netbsduser`` has joined #osdev
dumb0_ has quit [Quit: leaving]
<dumb0>
elf is complicated, can we just start with a simpler format for a kernel? T_T
<dumb0>
can't*
<dumb0>
com, mz, ne were all from microsoft, interesting
<heat>
ELF is seriously uncomplicated
<zid>
ELF is trivial lol
<zid>
header with pointer to two tables, one is an array of memcpys details that you need to do to load the thing, the other is a table of sections, for linkers to use
<heat>
the table of sections is useless for a loader
<heat>
so really it's just a pointer to an array of memcpy/mmap calls
<heat>
ofc you can go more complex if you start using fancier features (dynamic linking, relocation, PIE/PIC, etc)
<heat>
but the basic ELF format is pretty minimal
<zid>
yea I've never used the sections, I am not a linker
<zid>
I am an loader
<sortie>
https://en.wikipedia.org/wiki/Universally_unique_identifier#Endianness ← you got to be fucking kidding me there's two ways to encode uuids (apparently big endian) or guids (apparently 'little endian' but actually mixed endian) and Sortix partitioning has been doing GPT wrong
<zid>
all I remember about gpt labels is that the text comes out fucky for the joke entries
<zid>
that spell things out
<dumb0>
thanks zid and heat :3
<dumb0>
yall are so smart
<heat>
personally i'm an idiot
<sortie>
don't listen to heat, he's a meanie, heat is very smart
<dumb0>
guess you're right sortie :P
<zid>
nah heat is dumb
<heat>
facts
<zid>
he's actually a meathead who likes footballers
<zid>
he's just memorized half of linux/kernel/src/mm.c
<zid>
and pretends to understand it
<heat>
mm.c isnt a real file sir
<dumb0>
LOL
<zid>
see how he pretends to understand? It didn't match his factoids, so he couldn't form a useful response.
<dumb0>
> meathead: An enormously muscular guy who cannot hold a conversation about anything other than weight-lifting and protein shakes LMAO
<kof673>
it was what archie bunker called the "liberal" son "meathead"
<zid>
"ERR DOES NOT COMPUTE, NO SUCH FILE"
m3a has quit [Ping timeout: 276 seconds]
<kof673>
i am not that old, but :D "meathead"
<kof673>
i always thought itwas like "blockhead"
<heat>
zid: yeah i mean otherwise you're really spot on
<heat>
but i memorized all of mm/
m3a has joined #osdev
<dumb0>
why are there so many allocators, slab, slub, vmalloc, jemalloc, dlmalloc
<dumb0>
wtf
<heat>
because they're all for different purposes
<dumb0>
:3
<heat>
jemalloc and dlmalloc are userspace malloc libraries
<dumb0>
ahh
<heat>
vmalloc allocates virtual memory for the linux kernel
<dumb0>
yay
<heat>
slab and slub (both linux kernel) are analogous (and implement the same interface), but have different designs and different tradeoffs
<heat>
as of a few releases slab no longer exists, it's just slub
<kof673>
dumb0, [Villain] Final Fantasy VI - Ultros Classic lines include "Seafood soup!" when you hit him with a fire spell, and "Muscle heads? Hate 'em." when he targets Sabin
<kof673>
i don't know if anyone actually says that, may just be a engrish translation
the_oz has quit [Remote host closed the connection]