<clever>
so linux tried to stripe its writes, between 2 instances of the same partition
<clever>
and instantly hosed its own writes!
<clever>
other users only got hosed writes when hda2 filled up, and it spilled over into sda2
<clever>
my rough understanding, is that when a usb device is plugged into any port, it generates an interrupt (hw for root ports, interrupt packet? for hubs)
<clever>
the host must then enable that port, and the device will be addr 0, then SETUP/control-0 packets can be used to query it, and call set-addr, to make it unique, before enabling another port in a similar state?
<clever>
and then your free to send/receive data to any device in the bus?
<geist>
you poll each hubs with an interrupt transfer for status changes
<geist>
also something ih8win8 is going to need to do
<clever>
yeah, same as polling a keyb/mouse for interrupt packets
<geist>
the hub will say 'i saw something on port X' and then you send it a control message to enable port X, and now if you send transfers to anything at device 0, you are intrinsically talking to the new device
<geist>
you decide to set it's address, and then you can start interrogating anothe device
<geist>
the host stack makes sure that at any point in time only one port on any hub is in this state so that transfers to address 0 dont get confused
<clever>
yep, makes sense
<ih8win8>
So, interrupt transfers (despite the name) are just regularly repeating transfers at a certain interval. They aren't a result of the device triggering an IRQ on the host, right?
<geist>
correct.
<clever>
i cant see any real reason why you couldnt just immediately do a set-address, as the very first thing you send to an addr-0 device?
<geist>
there is no 'device triggering irq on the host'
<clever>
but from what ive seen, things tend to read the descriptors first
<geist>
clever: usually you read the descriptor to see if it's compatible, and if it's even responding
<geist>
and if its going to ask for too much power, etc
<ih8win8>
Interesting. I know PS/2 keyboards and mice can generate IRQs. I guess USB ones can't do that.
<innegatives>
is developing os for raspberry pi easier than x86 or am i shit outta luck?
<clever>
what about the wake from suspend stuff in usb?
<clever>
is that a true interrupt, or still polling by the host?
<geist>
ih8win8: that's right, the IRQ stuff is all emulated. it's all polled by the host *but* of course based on the host controller it can convert transactions to interrupts
<geist>
so something like say with XHCI (or even UHCI/OHCI/EHCI) have a way to set up a repeating interrupt transfer
<geist>
and the HC only triggers a host IRQ if the device ACKs a packet
<ih8win8>
When the host is sleeping, the CPU is off, so it can't poll, so I assume that wake from suspend is an IRQ.
<geist>
every time the device NAKs it it just retries on the next polling interval, no software involved
<zid>
That's sort of like, "generically true" though right, the host controller can do whatever it wants, driver level wise
<geist>
the host controller can keep polling for you
<geist>
the cpu can go to sleep if it wants in that case
<clever>
innegatives: i think it depends on what part of the hw you want to interface with, i think rpi is easier, because there are only 4 models to deal with, while x86 is just a wild-west, and you must follow specs like acpi and pci to properly detect what the user has installed
<zid>
turn usb packets into MSIs, have a 115200 baud serial link to the host, etc
<ih8win8>
Yeah, the host controller and any downstream hubs remain powered when the host is asleep.
<geist>
ih8win8: but yes, in the case of the dwc2 everything must be scheduled manually, including interrupt transfers
<geist>
but with a smarter host controller, i think it can be put into a low level suspended state while the host cpu goes to some lower sleep state
<geist>
hence having things like mice waking up a computer
<clever>
so if i had a keyb&mouse plugged into an rpi, the driver would have to be scheduling at least 3 interrupt transfers constantly, to the hub, keyb, and mouse?
<ih8win8>
Input sure is easier on x86, since you can use PS/2 and USB controllers that don't suck.
<clever>
ih8win8: but there is also the question of what address is the ochi controller at? youll need to parse the acpi and pci to find it
<geist>
i dony know if its in the mice waking up the omputer case because the HC is still scheduling interrupt packets, or if the USB bus has some sort of suspend state where a device does something like tug on one of the data lines to signal attention
<geist>
but the HC would almost certainly be responsibile for noticing that and forcing a system wakeup
<ih8win8>
I've never done ACPI. Does it give you something similar to a device tree?
<geist>
yes
<clever>
> A USB device may also request the host to exit suspend mode or selective suspend by using electrical signaling to indicate remote wakeup.
<zid>
It tells you where the pci-e bus is, good enough
<clever>
from the usb 2 spec i'm reading
<zid>
everything you care about is on the pci-e bus
<geist>
clever: yeah that's what i figured. probably some sort of tug low on a data line or whatnot
<ih8win8>
PCI can be enumerated fairly easily.
<clever>
geist: ah wait, this is something slightly diff
<geist>
and the hubs i'm sure are responsible for forwarding that up the chain
<clever>
> In order to conserve power, USB devices automatically enter the Suspended state when the device has observed no bus traffic for a specified period (refer to Chapter 7).
<clever>
this is more about just turning the entire usb bus off, because its unused
<zid>
pci's like, legacy mapped in, but you can still ask the pci-e hub that it's behind to poke it for you
<clever>
and then something like a hub, would send this wake signal, because your not polling the interrupts
<clever>
but i can also see, how you can use that power-saving technique, when the cpu is in suspend/hibernate
gog has joined #osdev
<clever>
one of my old motherboards, was able to boot from "off" when you hit any key on the keyboard
<clever>
and you could adjust if its any, or power, in the bios
<clever>
but that motherboard could also say "no cpu found" via the onboard sound card
<clever>
so it definitely had an extra cpu on the motherboard
<ih8win8>
Hmm there's something I'm not doing right. I send an 8-byte SETUP packet, it's received with an ACK, then I ask for a 64-byte DATA0 IN packet, but that gives me a data toggle error.
<innegatives>
Is there anything easier than osdev you can do to prepare you for osdev?
<ih8win8>
homebrew game console programming is a pretty nice middle ground between app dev and OS dev.
nyah_ has quit [Quit: leaving]
<ih8win8>
If I instead ask for a 64-byte DATA1 IN packet, it's accepted.
<ih8win8>
Pretty sure the data stage of a control transfer is supposed to start with a DATA0 packet, right?
<clever>
still digging thru the usb2 specs to try and find that
slidercrank has quit [Ping timeout: 246 seconds]
<gog>
hi
<clever>
section 8.6.1, says that you sent a SETUP and DATA0, then receive an ACK
<clever>
hmm, but thats a "setup followed by OUT", so the DATA0 is the OUT?
<innegatives>
is going through xv6 book and doing exercises of it good way of learning this shite?
<ih8win8>
That's at the token level. The DATA0 is always an out for the SETUP transaction.
<clever>
so if i was to do something like a GET_DESCRIPTOR request, i would sent SETUP, DATA0 with 8 bytes, containing that GET_DESCRIPTOR command, then a DATA1 IN?
<geist>
yeah but maybe the DATA0 in the setup implicitly sets the toggle to 1 for the first transactiona after it
<clever>
or rather, just IN, and the device responds with DATA1?
<clever>
yeah, thats what i was thinking
<clever>
SETUP always sends a DATA0, so whatever follows that must be DATA1
<ih8win8>
That's what I'm thinking.
<geist>
i thimk it may litterally be that stupid
<geist>
like the toggle logic really doesn't care about transfers or anything, just raw packets
<bslsk05>
beyondlogic.org: USB in a NutShell - Chapter 4 - Endpoint Types
<clever>
ih8win8: ah, reading that, i remember a bit more, control transfers (endpoint 0) are always SETUP, 8 bytes of data, and then either an IN or OUT, with a variable sized block of data, does that sound right?
<ih8win8>
yes.
<geist>
iirc within that first 8 bytes of the main device descriptor you can get the max packet size and then read the larger descriptor using that
<geist>
i think thats also why you typically see the host read it twice
<clever>
yeah, i mentioned that a while back, but mis-remembered it as 64 bytes
<clever>
that is also related to an rpi rom bug
<ih8win8>
My SETUP is going through, and I get the ACK handshake. It's when I send that variable sized block of data (as a DATA0) that I get the data toggle error.
<clever>
the rpi bootrom, patches the usb device descriptor, based on some internal state
<clever>
but it patches the descritor, AFTER sending it to the host!!
<clever>
the problem only goes un-noticed, because the host only read the first 8 bytes, and didnt see the bulk of the patch
<clever>
just, the descriptor length changed between that 8-byte read, and the full-read
<ih8win8>
So, I assume during the SETUP phase, it's sending a 0-byte DATA0 packet, and then I guess the IN packet needs to be DATA1?
<geist>
that would make sense to me
<clever>
i think a GET_DESCRIPTOR call, would be SETUP, an 8-byte DATA0, then an IN?
<geist>
as in the toggle is at the 'physical' level
<clever>
and the 8-byte DATA0 contains the GET_DESCRIPTOR code
<geist>
if you're really stuck i can dig out a usb bus analyzer here and get some traces
<geist>
but i have to find it and set up the software and whatnot
<ih8win8>
I thought the toggle was supposed to be per direction, though. I'll just read through this spec again.
<clever>
i was thinking of just bodging the rpi-pico into a usb analyzer
<clever>
it can emulate any usb device, and if i just spam its tinyusb with printf's, it should log all packets it receives
<clever>
then just plug that into my host, and boom, analyzer!
<ih8win8>
IIRC, hubs just relay all packets to every downstream device, with the devices just accepting packets addressed to them, so it looks like you could just plug it into a hub with another device and capture stuff.
<clever>
re-reading the "standard device requests" chapter, a GET_DESCRIPTOR would involve, bmRequestType=0, bRequest=GET_DESCRIPTOR(6), wValue=1 and 0?, wIndex=0, wLength=8 at first
<clever>
all of those fields, get encoded into an 8 byte blob, and sent after SETUP
<clever>
and now the device knows it should respond with wLength bytes of the device descriptor
<clever>
ah wait, just noticed the "transaction examples" chapter, that may have a lot of answers
<clever>
nearly every single example involves split transactions, lol
<ih8win8>
"Synchronization is achieved via use of the DATA0 and DATA1 PIDs and separate data toggle sequence bits for the data transmitter and receiver."
<clever>
that makes it sound like each end has its own state, and is toggling seperately
<geist>
you could also just try the logic that seems to work
<geist>
and if it works, scratch your head and move on
<clever>
yep
<clever>
figure things out later
<ih8win8>
yeah, that's how I interpret it, but the example in that USB in a nutshell page contradicts that.
<geist>
not everything on the internet is correct
<ih8win8>
Well, it does go through, but I get a STALL response at the end of the whole transfer.
<ih8win8>
That means the device doesn't like it.
<clever>
ih8win8: reading thru the hub specs, it looks like you cant sniff everything
<clever>
when in "downstream connectivity" mode, it broadcasts packets from the host to every port
<clever>
but when in "upstream connectivity" mode, its sending a packet from 1 device to the host, and the other devices cant listen in
<clever>
and it probably switches mode, depending on IN and OUT tokens
<ih8win8>
oh right, you won't be able to capture IN packets.
<clever>
the dwc has a sniffer mode, and that makes me wonder if the pico also has one
<clever>
where it can be wired as a kind of 3rd-wheel, sharing a link with a device&hub
<clever>
and then it can decode everything and just not answer
<ih8win8>
huh I wonder if I can find a copy of the USB 1.1 specs. It won't have split transactions.
<clever>
i think ive also heard of using usb-over-ip, and a gadget port, to extend usb over wifi
<ih8win8>
yeah looks like that spec is available.
<clever>
if you did that, you could then sniff everything your forwarding, but ah yeah, abck to an issue i mentioned before, malformed packets wont show up
<ih8win8>
There's WebUSB in recent browsers.
<clever>
yep, ive used webusb to boot an rpi before
<ih8win8>
Yeah, let's tunnel everything through the web.
<clever>
the pi0/pi1/pi4/pi400 all support rpiboot, which is where the boot rom loads bootcode.bin over usb
<clever>
and i re-implemented rpiboot in webusb, so i can fetch bootcode.bin over http, and serve it to the pi
<ih8win8>
Still waiting on WebPCIe and WebAHCI, though.
<clever>
the official bootcode.bin then switches to a sort of reverse file-server, where the host sends a control transfer, and gets back a filename
<clever>
the host must then respond with the contents of that file
<clever>
and the pi then boots, by loading all of config.txt/start.elf/kernel.img over usb like that
MiningMarsh has quit [Remote host closed the connection]
<clever>
ih8win8: one thought i had, while reading these specs, are you sending SOF packets?
<clever>
how upset might a hub get, if your not sending SOF's at a regular interval?
klange has quit [Ping timeout: 246 seconds]
<ih8win8>
Pretty sure the controller does that automatically.
sprock has quit [Ping timeout: 246 seconds]
<clever>
yeah, i think that is automatic
<clever>
but there is still the frame interval in HFIR that you need to set correctly
<clever>
to tell it how often to send SOF's
klange has joined #osdev
MiningMarsh has joined #osdev
sprock has joined #osdev
<ih8win8>
looks like it computes it automatically if not set
<ih8win8>
I wonder how interrupt transfers would work with USB over IP. The latency of that seems like it would be a problem.
<clever>
my first guess, is that the remote host would just poll the interrupt on its own, and once it gets some data, forward it over usb, and answer when the real host next asks
<clever>
forward it over IP
innegatives has quit [Quit: WeeChat 4.0.1]
<geist>
yeah dunno there
<clever>
the only real-world use-case ive seen of usb-over-ip, was somebody running some windows only CNC software
<clever>
they ran the software in a VM on a box in another room
<clever>
then usb-over-ip'd the CNC from an rpi to the VM
<clever>
then VNC'd the VM back to the rpi!
<geist>
i suppose it's possible to emulate the interrupt stuff on the target
<clever>
so the rpi is now acting as a thin-client, sharing a usb-host port to the VM, and letting you control the windows-only software
<geist>
so that it only transfers data when there's an ACK, like a ost controller would
<bslsk05>
learn.microsoft.com: How to send a USB control transfer - Windows drivers | Microsoft Learn
goliath has quit [Quit: SIGSEGV]
<clever>
hmmm, the bInterval on an interrupt/HID descriptor, is that in ms?
edr has quit [Ping timeout: 240 seconds]
<Mutabah>
I think it's technically frames... which is milliseconds
<clever>
but HS has 125uSec frames
<Mutabah>
those are microframes
<clever>
ah, and those dont count i guess
<clever>
the device in question is also FS
<clever>
ah yeah, page 271 of this usb spec says frames or microframes
<clever>
but its also an exponent, a bInterval of 4, means a period of 2^(4-1)
<Mutabah>
oh, yeah, forgot that for a moment
<clever>
so when my keyboard claims bInterval=10, that means you can poll it as slow as 2Hz
<zid>
I have a device where I end up with 1000 hid packets a second
<zid>
I'm not quite sure *why* it does this
<clever>
but that feels like it would result in rather unusable levels of latency
<clever>
my mouse dongle does claim bInterval=1
<Mutabah>
... that is a very strange interval indeed
<ih8win8>
fuck yeah! I finally did a complete control transfer with no errors!
<Mutabah>
Nice!
<clever>
rough math from wireshark, its about 0.02 seconds between interrupt packets
<clever>
ih8win8: progress!!!
<clever>
Mutabah: oh, wait, isochronus has that weird 2^(10-1), but interrupt instead is just the number itself? and bulk instead uses it as the max number of NAK's?
<ih8win8>
Finally getting this shitty host controller to bend to my will.
<clever>
ih8win8: hard mode, implement OTG and try swapping a pi-zero between host and device without a reboot!
<clever>
its extra hard, because the zero is a bit lacking in capacitors on the 5v rail, and just plugging in a mouse will brown-out the whole system
<ih8win8>
lol, maybe in another year...
<ih8win8>
Can Linux do that?
<clever>
i think so
<clever>
there is a role param in the dwc overlay, host, device, or otg
<clever>
which implies linux can switch on the fly
<ih8win8>
Wow, Microsoft's USB documentation is quite good, actually.
<clever>
ih8win8: i forget which register, but one of them lets you read the OTG_ID pin, but you can also just ignore it, and force host or device mode
<clever>
but thats only wired up on the zero's and CM's
<clever>
usb-c does it differently, and the pi4(00) didnt wire te OTG_ID to anything
<ih8win8>
I assume there's no way to do device mode on a Pi 3, right?
<clever>
correct, the hub is in the way
<ih8win8>
Probably could've done it through the micro USB port, but I think that would require another USB controller.
<bslsk05>
hackaday.com: A Custom Raspberry Pi Spotted In The Wild | Hackaday
<clever>
that board has a usb MUX chip, between the SoC and hub
<clever>
and it can re-route the SoC to the micro-b in the top-right i think
<clever>
so you can still use it in device mode
<clever>
the CMIO boards also have such a mux chip
<ih8win8>
huh, that's an interesting pi. I'd never heard of that before.
<clever>
element14 had an rpi customization service, minimum of 5000 units
<clever>
so you could just ask them for some changes, and they would design a modified board
<clever>
and you can see from the photo, some of the lazy or "it works, dont change it" aspect, the dsi/csi/headphone stuff is all still on the pcb, they just didnt populate it
<ih8win8>
My Arcade1up cabinet has a PCB that resembles a Raspberry Pi, but it's some pretty generic Allwinner SBC. It even has GPIO pins.
slidercrank has quit [Quit: Why not ask me about Sevastopol's safety protocols?]
elastic_dog has joined #osdev
ss4 has quit [Read error: Connection reset by peer]
MiningMarsh has joined #osdev
zid has quit [Ping timeout: 246 seconds]
<ddevault>
what are some simple PCI devices supported by e.g. qemu that would be good targets for early PCI driver development
<ddevault>
I mean I could just go straight to IDE or AHCI, that's the first useful device I want to implement anyway
<Ermine>
I wannted to propose ahci too. Its spec is 150 pages long. I think it's relatively small
zid has joined #osdev
<gog>
PCI IDE is easier probably
<gog>
i've never implemented either, i've only played with PIO IDE
<gog>
but from what i've read PCI IDE is fairly straightforward
<Ermine>
I don't like the need to partition regions for dma though
<Ermine>
There are also PCMCIAs, idk how easy these are
<ddevault>
probably some virtio stuff is easy
rwb has quit [Ping timeout: 246 seconds]
rwb has joined #osdev
rorx has quit [Ping timeout: 246 seconds]
rorx has joined #osdev
<Mutabah>
rtl8139 is a simple-ish one
<Mutabah>
but PCI IDE is probably best
lg has joined #osdev
<clever>
i forget which model it was, but the 100mbit NIC in one of my old routers was as dumb as bricks in terms of interface
<clever>
it had a max of 4 outgoing packets, each one had a dma addr, a byte count, and some flags (start, busy, done)
<clever>
so you just find a slot that is free, fill in the addr&size, hit the start bit, and thats it
<Mutabah>
8139
<clever>
if all 4 slots are busy, you coudl either block, or wait for a tx-completion irq
<sham1>
How many Rx slots did it have
<Mutabah>
8k ring buffer
<Mutabah>
well, iirc it's just over 8KiB
<Mutabah>
The realtek 8139, quite a fun card to write for
<sham1>
It's a bit weird that it didn't use a ring buffer like that for tx
<clever>
i was mostly looking at the tx side, because i had a weird bug where packet tx would just halt randomly
<clever>
sham1: a ringbuffer for tx, would require copying the packets into the buffer
<sham1>
Hm, true
<sham1>
Doing a DMA transfer probably makes more sense
<sham1>
Was it IOMMU or did it use physical addresses
<clever>
but it lacks scatter/gather dma
<clever>
so your outbound packet must be psysically contiguous
<clever>
i think it was all physical
<sham1>
Ew
<sham1>
Annoying
<clever>
but the motherboard/cpu iommu could trick it
<Mutabah>
Dumb as a brick, but really simple
<clever>
related, the networking stack in linux is both event driven and polling driven
<sham1>
Horrifying
<clever>
when the rtl8139 has available tx slots, it operates in an event driven manner
<clever>
when the network stack wants to tx a packet, it calls the driver, which adds it to the queue, done
<clever>
but when it runs out of slots, that becomes a waste of cpu, it cant tx!
<clever>
so the driver flips into a polling mode, where the tx-complete irq will ask the network stack for another packet
<clever>
and if it fails to get another packet, it goes back to event driven mode
<clever>
and the bug i was looking into at the time, was actually in the ppp(oe) driver
<clever>
it had a 1 packet buffer, between the input, and the "serial output" (even with pppoe mode)
<clever>
so every single time you try to transmit, it flips to polling mode, and then back
<clever>
randomly, it would stay in polling mode, but not ask for a packet
<clever>
so the network stack just stops trying to transmit
<clever>
boom, 100% packet loss in the outbound direction
<clever>
but!, the pppoe ping packets, where write()'d to a char device, and bypass the network stack
<clever>
and when those complete, it goes back to event driven mode, and is fixed
<clever>
so it only has 100% packet loss for up to 20 seconds
<clever>
i was never able to properly fix the ppp bug, but there was a config file to change the ping interval, once/sec made the bug invisible
ih8win8 has joined #osdev
awita has quit [Remote host closed the connection]
heat has joined #osdev
<heat>
clever, that's not really polling mode
<heat>
polling would be to literally spin on some TXSTATUS waiting for completion
<clever>
maybe its better to call it push vs pull
<heat>
fwiw napi does indeed support polling
<heat>
as in "wait for rx to arrive by spinning on a reg"
<clever>
getting back into my usb-host drivers now
<clever>
ive not initialized the usb controller yet, but i'm already getting SOF interrupts
<clever>
at an interval of 125, so i think i'm in HS mode already
Left_Turn has quit [Read error: Connection reset by peer]
<heat>
also clever push + pull is really common for this stuff
<heat>
since this is entirely async, like e.g block io is
Left_Turn has joined #osdev
<heat>
you have no thread to wake up, so if you need to get more requests you better go fetch em
<clever>
so, i'm taking over a usb controller after a previous stage has just forgotten about it, the usb devices already have addresses, but there is no way for me to know them
<clever>
i think my goal, is to send a usb reset, to restore every device to addr 0?
[itchyjunk] has joined #osdev
d316d has joined #osdev
d316d is now known as innnnnnnnnnegati
innnnnnnnnnegati is now known as innnnegatives
<clever>
ah, thats likely under `host port control`
<clever>
yep, bit 8, port reset
vai_ has quit [Quit: hmm]
vai__ has joined #osdev
vai__ has quit [Client Quit]
<clever>
and now the SOF interrupts are gone
<clever>
before reset, i had the "device attached", "port enabled" and "port power on" flags, after the reset, its just "D- is high"
<clever>
i think i need to re-enable the port
<clever>
yep, turning on port power has helped, its now got the "port enable changed" flag, and SOF's are flying again
<clever>
so, i assume that the device (a hub) is now at addr 0, and i should be able to query its descriptors
innnnegatives has quit [Quit: WeeChat 3.8]
<gog>
hi
<sham1>
hi
<gog>
i'm writing a tutorial for everything my kernel does
<sham1>
Tutorial? Or docs?
<gog>
:P
<gog>
neither i'm just poking fun at our help vampire
<gog>
that's not nice tho
<gog>
i should chill out
<sham1>
This is the second channel I've heard the phrase "help vampire" and it's staring to concern me
<gog>
it's an unkind term
<gog>
idk how else to refer to people who repeatedly need help and don't seem to be really learning very much
<sham1>
I get that
<sham1>
It's just a weird coincidence
<ih8win8>
Alright, let's see if I understand this. So, interrupt transfers basically involve the host polling the device every n number of frames until the device decides to send data, right?
<clever>
ih8win8: thats my understanding as well
<sham1>
Why would you poll if you have an interrupt_
<sham1>
?
<clever>
sham1: because interrupts in usb are a lie
<sham1>
Well that's silly
<ih8win8>
Like many terms in USB, it's a confusing misnomer.
<clever>
thats why professional audio people dislike USB
<clever>
the latency is bounded by the hosts polling interval
vdamewood has joined #osdev
<sham1>
Damn it USB
<clever>
ih8win8: so, my bootloader left the usb controller fully initialized, and when i unmask the SOF interrupt, i get an SOF interrupt every 125 uSec
<gog>
oops, as it turns out my main branch is broken anyway
<gog>
just a quick merge with unstable will fix that
<clever>
ih8win8: if i then hit the port-reset bit, the port becomes disabled (and i cleared power by accident), and SOF's stop, if i ensure power stays enabled, the port also re-enables, and SOF's resume flying
<sham1>
gog: wait, you use main as the stable branch_
<sham1>
GOOD GRIEF
<ih8win8>
clever, yeah, if I understand right, it should generate SOFs every 125 usec in high speed mode.
<clever>
yep
<sham1>
I keep forgetting that I'm using the native keyboard layout and not EN-US
<ih8win8>
Though they are really start of microframes. You'll get 8 each with the same frame number.
<clever>
ih8win8: so, after having done that reset dance, i expect my hub to be at addr 0, so i'm one step behind you
<ih8win8>
you're trying host mode?
<gog>
wdym
<clever>
yeah
<sham1>
gog: you're not using main as the, well, main development branch?
<gog>
i guess i didn't consider whether there's a convention
<gog>
basically main has to work
<sham1>
There are multiple
<sham1>
Right
<gog>
everything else can be broken
<ih8win8>
The hub, like any device, will respond to addr 0 until you give it a SET_ADDRESS.
<gog>
that's the convention i came up with
<clever>
ih8win8: oh, one handy thing i have for debug: printf("masked irq's: 0x%x\n", *REG32(USB_GINTSTS) & ~(*REG32(USB_GINTMSK)));
<clever>
masked irq's: 0x54008825
<sham1>
At least @work we use our master-branch as just the unstable one we make releases out of from time to time, and then feature branches for bugfixes and such
<clever>
ih8win8: this would be every irq condition that is firing, but is masked by the irq mask
<clever>
so those are events that have happened, but the code is ignoring
<sham1>
Well, we also do have a separate "migration" branch for technological migration I've been doing a bunch of work for, but yeah
<gog>
at my work master is the production branch that's currently deployed
<clever>
i can then review the datasheet to see if any are interesting
<gog>
and then we have a development branch that's volatile
<gog>
then occasionally we do cross-merging with master and development
<gog>
when we have a hotfix that affects both
<sham1>
Github releases are neat
<ih8win8>
heh, you're getting bit 15 in GINTSTS as well, even though the datasheet says that bit is supposed to be device mode only.
<sham1>
Of course, sometimes the github workflow specifically can be a bit weird for a closed-source thing
<clever>
ih8win8: it may be something that was alreadu firing before my code even ran, from something the rom or bootloader did
<gog>
we use bitbucket :|
<ih8win8>
yeah, I get it on my pi 3, even though it doesn't support device mode at all!
<clever>
ih8win8: if i clear bit15 and then 50ms later check things, its not set anymore
<ih8win8>
I just ignore it.
<clever>
yeah, i'm just leaving it masked entirely
<clever>
ok, so next is step 4 of section 6.4.1, i need to set a transfer size, for my SETUP token
<sham1>
gog: oof
<ih8win8>
My GINTMSK is just 0x02000008. That's all I care about right now for control transfers to work.
<clever>
ih8win8: is SETUP only ever EP0 or can it be fired at other endpoints?
Turn_Left has joined #osdev
<sham1>
gog: let me guess, you also have JIRA
<ih8win8>
It's possible for other endpoints to support control transfers, so yes.
<clever>
`void control_in(int channel, int addr, int endpoint)` should do then
<ih8win8>
But devices are only required to support them for EP0.
<gog>
yeah
<gog>
yeah we do have jira
Left_Turn has quit [Ping timeout: 258 seconds]
<ih8win8>
The big picture of USB is transfers, of which there are four (control, bulk, interrupt, isochronous), and each transfer is broken down into transactions, which are further broken down into packets. The DWC2 seems to handle things at the transaction level.
<clever>
so, reading the descriptor, would be an 8byte control-out, then a 8 byte control-in?
<clever>
bit fuzzy on how to do the IN after the SETUP, and i think control means SETUP?
<Mutabah>
Control is SETUP,{IN,OUT|OUT,IN}
<Mutabah>
SETUP contains the request info
<ih8win8>
control transfers involve 3 transactions: setup, optional data transaction, then an ack transaction (which is just a 0-byte data packet).
<clever>
but on the dwc, you need to set a type, control/iso/bulk/int, and a direction of out/in
<clever>
and control-in is a weird cause of being both 8 out and variable-in
<ih8win8>
To start a transaction in DWC2, you set the appropriate bits in HCCHAR, HCTSIZ, HCSPLT, and HCDMA. Then, you set bit 31 of HCCHAR to 1 to actually make it do the transaction.
<clever>
yep
<ih8win8>
Once the transaction is complete, you'll get a channel IRQ and check HCINT for the status.
<clever>
but for the SETUP phase of control-in, is that as simple as control and out within HCCHAR
<clever>
and then a second control and in for the DATA phase?
<ih8win8>
So, control-in involves an OUT SETUP transaction, an IN DATA transaction, then an OUT 0-byte DATA transaction.
andydude has joined #osdev
Left_Turn has joined #osdev
<clever>
ih8win8: hmmm, no int fired when i enabled the channel...
Turn_Left has quit [Ping timeout: 246 seconds]
<clever>
*REG32(USB_GINTMSK) = BIT(1) | BIT(3) | BIT(25); that should enable channel interrupts
<clever>
*REG32(USB_HAINTMSK) = 0xffff; and that should just allow any channel to fire
Turn_Left has joined #osdev
<ih8win8>
and HCINTMSK needs to be unmasked as well
<clever>
yep, chan->hcintmsk = 0xffff; unmasks everything there
Left_Turn has quit [Ping timeout: 245 seconds]
<clever>
HCCHAR0 is 0, 100ms after trying to transmit
<ih8win8>
I had the same issue with ints not firing. Adding that mailbox command to turn on USB made it work, even though it makes no sense.
Left_Turn has joined #osdev
<clever>
trouble is, i cant use the mailbox, i replaced start.elf
<clever>
but i know the usb controller was just working, and nothing was de-initialized
<ih8win8>
What does your HPRT register look like?
<clever>
USB_HPRT: 0x100d
Turn_Left has quit [Ping timeout: 272 seconds]
<clever>
ok, just before enable was set, HCCHAR0: 0x8008, then i set enable, wait 100ms, and it becomes HCCHAR0: 0x0
xenos1984 has quit [Read error: Connection reset by peer]
<ih8win8>
Scheduling interrupt transactions seems like a nightmare on DWC2. I get the start of frame interrupt that I can use for timing, but the frame numbers only go up to 1023, then roll back to zero.
<geist>
ih8win8: yup
<geist>
basically up to you to build the data structures to queue them up
<geist>
isochornous is even worse
<ih8win8>
I suppose I can just store the frame number separately in a 64-bit int. That should only roll over after 584 million years.
<ih8win8>
or maybe I can just record the frame number when I send an interrupt transfer, and then calculate the next one from that.
<ih8win8>
wait, but I still have to deal with rollover.
vdamewood has quit [Quit: Life beckons]
nvmd has joined #osdev
Burgundy has joined #osdev
<immibis>
I don't know the system you're talking about but what's wrong with rollover? you just &1023?
nvmd has quit [Client Quit]
nvmd has joined #osdev
<sham1>
Or % 1024
danilogondolfo has quit [Remote host closed the connection]
nvmd has quit [Quit: WeeChat 3.8]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<ih8win8>
Well, say I'm on frame 1022, and I need to process an interrupt transaction 10 frames later.
<geist>
on every frame irq just bump a counter
<geist>
yeah you can do the 64bit thing, which would work fine, lets you schedule things in the future, but i think in the case of interrupt transfers the max delay is well within 1024 right?
<geist>
if so you can probably do something that's like treat the 1024 current counter as a signed integer
<geist>
so then you can do a <= comparison of 'is this the frame for me to send a transfer?'
<geist>
but really probably a 64bit counter (or 32bit really) is fine
<geist>
re:signed i think imean you can subtract the current counter value from the current scheduled time and treat the result as a signed integer
<geist>
that nets you something that works +/- 512 ticks from now
<geist>
a fairly common trick for these sort of things to deal nicely with rollover
<ih8win8>
oh, right.
<ih8win8>
gotta think about that for a minute to see if it works in all cases
<puck>
geist: oh hey i forget exactly what or how but i remember something linking you and hobbit bebox boot rom in "some" way
nvmd has joined #osdev
<geist>
well, i only say that because i have a friend of mine from the Be days that has a functional hobbit bebox
<geist>
and i think we was going to/did get a snapshot of the roms
<geist>
though i think there are existing rom images out there
<puck>
oh?
<puck>
i haven't encountered any
<puck>
there's a rom of the powerpc bebox because it was updatable
<geist>
someone here (maybe you) was trying to build an emulator i think
<puck>
yes
<puck>
i have: a fully functional emulator
<geist>
so you dont have the hobbit bebox roms and need one?
<geist>
i can ask him to get an image if they're easily obtainable
<puck>
i don't *need* them, loading the kernel is easy, but it'd be nice for completeness
<geist>
yeah i *assume* it's just a DIP and not a soldered on surface mount thing
<puck>
it'd be wild if the rom was soldered on in the prototype stage
<geist>
right
<puck>
worst case i could provide a disk image that could be booted from floppy to dump it
<ih8win8>
wait, that wouldn't work. If we're on frame 1023, and I need to schedule the transaction 10 frames in the future, I'll set that to 1033, but when I get there, 1033 - (1033&0x3FF) is still positive.
<puck>
also if it's one of the three beboxen not already disk-imaged, a disk image would be great
<puck>
(serial numbers 9, 44, 58)
<puck>
i have https://puck.moe/git/hobbitizer but it requires using an External Tool to extract the kernel from the disk image, and while i could just read OFS myself it'd be nice to emulate the boot rom too
<bslsk05>
puck.moe: hobbitizer - yup it's a hobbit emulator
<geist>
he has the disk image too
<geist>
okay, asking
<puck>
:3
<puck>
thank you
<geist>
also curious what his serial number is
<geist>
ih8win8: schedule it with % 1024
<puck>
also, someone had a hobbit bebox that apaprently once contained a powerpc card; though i think i can guess how i'd have to wire that up to the emulator infra i have now
<puck>
nope, that's the real deal, but i can replicate that picture pixel-perfect :)
<geist>
yeah he says he checked those images before and they're basically identical to his
<geist>
ie, the stock install of whatever it was
<puck>
hmm
<geist>
probably beos pr2 or so
<puck>
i should try and install the installer floppy
<puck>
geist: tbf there's a few artifacts in some of these (e.g. be3 has the "suite1" through suite8 thing)
<puck>
and there's a few things i haven't figured out yet (e.g. Edit on the earlier kernel doesn't work)
<geist>
yeah i dunno, never seen one run. i just have a pair of PPC beboxen
<puck>
PR2 is alse *years* after the hobbit was discontinued
<geist>
yeah you're right, i always forget the naming convention of the old stuff
<puck>
wikipedia claims there's DR1-DR5 for the hobbit, but i've only seen two versions total
<geist>
i think they also rewrote the kernel after hobbit. in the source tree the kernel was in a directory called 'nukernel'
<puck>
one very early (no Tracker-equiv, just a terminal)
<geist>
ah yeah DR* that's right
<puck>
be3 is labeled as "Be Labradors Kernel version of Mar 1 1994 time 14:53:41", and recognizes a so-called "rev3 motherboard"
<geist>
i wouldn't be surprised if the hobbit kernel was not much more than a glorified embedded thing
<geist>
dunno if it has full memory protection or whatnot
<puck>
it has!
<geist>
might be closer to mac classic. okay
<puck>
it's got a whole bunch of message passing already in there, and a copy of BMessage/etc
<geist>
yah but the time i started working with beos, it was the x86/ppc version, about 1997. R3 was my first exposure to it
<geist>
and by then it was a proper preemptive, SMP, etc thing
<puck>
e.g. it's got create_area/delete_area, spawn_thread, create_port, write_port/read_port, send_data/receive_data, most ofg which are things i could probably map directly to the beos kernel
duderonomy has quit [Remote host closed the connection]
<geist>
ah okay. dunno how much of 'nukernel' was a rewrite, or a reorg, or just some sort of name change for some reason
<puck>
probably a new kernel tbh
<geist>
i vaguely remember something about there being some older thing
<geist>
yah we also had some sun boxes around. at the time i started there, there wa a sun based perforce server, moved it over to freebsd while i was there
<geist>
kk, maybe the unixware thing was very very early, or some sort of attempt at using x86 based unix workstations, or whatnot
<puck>
yeah, i get that
<puck>
just mentioning what i have been able to figure out :p
<geist>
it was all way before i was there, since be had already been around like 8-9 years prior to me joining
<puck>
geist: oh one interesting question is: does their bebox boot up directly into Browser :p
<geist>
yah that makes sense, either way if it wasnt self hosting in say 1992 then there wasn't much else you were going to compile it on that was unixy
<puck>
the two disk images i have both have Browser located at /system/browser, not /system/Browser
<puck>
which makes it not start up at boot
<puck>
(that being the two images with "Be Labradors Kernel version of Nov 23 1994 time 12:11:01")
<puck>
yes this is a weird question and yes it probably has no real difference in everything but it's funny
<puck>
wait, these version dates are claimed to be pre-DR1 even? it's a bit unclear because there's like three total screenshots online and no good documentation on really early beos
<innnnegatives>
You can expect all x86 computers to have VGA mode, etc. but what abour RISC-V? Can you write an OS and expect it to work in most upcoming RISC-V boards?
<bslsk05>
www.haiku-os.org: Be Newsletters - Volume 1: 1995–1996
<puck>
innnnegatives: most bootloaders, including e.g. EFI on RISC-V, *usually* lets you receive a linear framebuffer
<innnnegatives>
but generally how uniform are RISC-V boards or will be? Do you need to retrofit your OS for each board like you do for ARM or can one reasonably expect it to work on all boards like x86?
\Test_User has quit [Quit: \Test_User]
\Test_User has joined #osdev
<puck>
i really enjoy the failures in the hobbit beos tho
<puck>
"Data written past end of allocated block, heap almost certainly dust. Don't worry; your program is about to die."
<geist>
innnnegatives: yes
<geist>
or more importantly, you have a different set of drivers and the boot methods are different
<geist>
but the vast majority of your kernel is boot agnostic
<geist>
as i was pointing out the other day, booting is no real big thing, it just seems like *everything* when you're first getting started
<sham1>
Hell, if you play your cards right, most of your kernel should be architecture agnostic
<geist>
dont stress about it, get your stuff working, and then worry about it
<geist>
correct
<sham1>
Although this doesn't always happen. Even more serious OSes struggle
<geist>
i seriously doubt you're really listening innnnegatives, since you seem to be perpetually stuck in this loop
<geist>
but i am trying to break you out of it
<geist>
'working on all boards like x86' is not really unique to x86. think of it as the architecutre (x86, arm, riscv) and 'standard' platforms (PC, raspberry pi, etc)
<geist>
the platforms imply a set of drivers or a mechanism to detect it (PCI, etc)
<geist>
but is generally independent of the architecture. or in the case of x86 there's basically a 1:1 correspondance, since basically all x86s imply the PC architecture
<geist>
but that's actually the exception to the rule
<geist>
on other arches, there tend to be multiple 'platforms'
<geist>
which is in some sense much more complicated and also kinda simpler, because they tend to not have 40 years of backwards compatibility and legacy to drag around
<geist>
so booting on a new riscv machine? use uboot to put your shit in ram and go. easy. but that's just defacto. not all boards *have* to have uboot, just most of them do
<innnnegatives>
ok thanks
<puck>
geist: okay so i found a list of beos syscalls and .. they match up scarily well with the hobbit kcall list
goliath has joined #osdev
<geist>
but this is all fine, because wha tyou do is you eventually write your kenrel so that there's a layer of code that deals with 'how did i get loaded and where is memory/video/etc' and then that's platform/arch specific
<geist>
and then the vast majority of the kernel doesn't care how it gets there or what it's running on
<geist>
that's the trick to building a portable kernel. it's mostly organizational and layering
<sham1>
Dependency injection
<geist>
but again, dont worry about building somehting portable when you're first getting started. it's far more important to get started, get some code written, learn some things, then you can throw it all away and do it properly
<ih8win8>
There were some x86 smartphones made by Asus around 2015-ish that were far from PC architecture.
<ih8win8>
Now I need to figure out how to consistently handle start of frame interrupts, because my debug messages take several milliseconds to print to the screen.
<ih8win8>
if only writing to the framebuffer wasn't so slow
<puck>
geist: lol i appeared a copy of beos developer edition 1.1 and i think it has your name under interns?
<geist>
yeah probably
<geist>
i should be in the r4 and above in the developer list
<puck>
i think the first few versions of the ppc beos use the old kernel, but developer edition (and maybe later) i don't think do?
<geist>
so actually no, i wasn't involved in the DR days
<puck>
geist: yeah i'm not sure where "Developer Edition" falls in the timeline lol
innnnegatives has quit [Ping timeout: 250 seconds]
<geist>
yeah there were a bunch of Rx DEs I think
<geist>
used to mail out cdroms with them
<geist>
i have a few somewhere
<puck>
. o O ( traditional intern job )
<geist>
well, *i* didn't mail them, but yeah. i'm guessing it was really like R4.5 DE1 or something
<geist>
beta 1, beta 2, maybe
Turn_Left has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
Left_Turn has quit [Ping timeout: 245 seconds]
heat has quit [Remote host closed the connection]
<puck>
DR8 is old kernel, R3 is .. huh. uhhh. i'm not sure!
heat has joined #osdev
<puck>
or well i guess it mentions nukernel so that answers it for me in the most boring way possible
<puck>
(got tricked by the term "kasr", which, to be fair, i still don't know what "asr" stands for)
<geist>
oh what mentions nukernel?
<geist>
DR8?
<puck>
R3
<geist>
yah that's when i got involved
<geist>
the version history link above is pretty clear on the timeline
<puck>
it still looks pretty derivative of the old kernel, though
<puck>
but i mean. i have proven this by way of syscall numbers lol
<geist>
R3 was the first real 'release' i guess, PR1 and 2 are just essentially beta before R3
<puck>
yeah. the numbering scheme makes no sense
<geist>
and the DR1-DR8 was the pre-PR numbering i guess
<puck>
i don't think anyone knows what developer relesas 1-5 entailed exactly
<geist>
so if there's any switching of things, it might be at the PR1 level
<geist>
so what i dunno is what version precisely if the hobbit OS releases you have there. is that DR5?
<geist>
probably, since the kernel is 1994
<geist>
or could be DR4, etc
<geist>
my guess is the changing of names from DR8 to PR and whatnot has to do with what be was doing at the time. trying to get bought by apple, etc
<geist>
anyway, afk for a bit
zxrom has quit [Remote host closed the connection]
zxrom has joined #osdev
vaartngvirf has joined #osdev
<nortti>
heat: tried booting up onyx in virtualbox on my surface. other/unknown (64-bit), 1 gig of ram, 2 cpus, EFI enabled, nightly build .iso as DVD. gets until "args: --root=/dev/sda1", and then virtualbox guru meditates
terminalpusher has joined #osdev
zxrom_ has joined #osdev
zxrom has quit [Ping timeout: 272 seconds]
<vaartngvirf>
Is there any reason to keep off using C23 in osdev instead of C11 (or C17)?
<Griwes>
not unless you need to support a compiler that doesn't support it
<nortti>
do compilers already have C23 support finished? aiui the standard is not out yet, but I guess they've been following the process along
<Griwes>
the C committee has been doing really good job recently, so I think I'd even recommend moving forward as soon as you don't need to support older compilers
<clever>
that looks like a successful read of a usb device descriptor!!
<vaartngvirf>
what about when you need to port a c library? would having c23 cause issues?
<Griwes>
C23 might as well be out, I think they either sent it for final ballot or are about to
<vaartngvirf>
i mean standard library
<Griwes>
the ballot hasn't reached me yet, but it may be in flight already
<nortti>
vaartngvirf: I don't see why it'd cause any. if your c library does not support all of c23 you can't use those features, but otherwise it should just work
goliath has quit [Quit: SIGSEGV]
gog has joined #osdev
wootehfoot has quit [Read error: Connection reset by peer]
<zid>
There's no such thing as C17 though?
<nortti>
what?
<nortti>
like, are you arguing that because C17 mostly consisted of fixed to C11 it doesn't count as a C standard revision, or?
<Griwes>
and fuck knows what WG14 will do with this change :V
<sham1>
Probably ape WG21 if C23 has been any indication
<gog>
hi
<Griwes>
I mean I'm all for WG14 just reusing our words :P
<sham1>
I just want statement expressions :(
<Griwes>
the less difference there is in the spec, the easier it is to make changes without having to spend hours thinking of whether a tweak in a common thing impacts C or not
<sham1>
Having actually real standard statement expressions would make macros very, very useful
<nortti>
< Griwes> [[noreturn]] should've always been a keyword ← doesn't C23 move the other way, deprecating _Noreturn in favour of [[noreturn]]?
<Griwes>
yes :|
<sham1>
WG14 did also have a lambda proposal which could have also helped, but eh. Closure-less lambdas would really only be useful for things like qsort, and adding closures would require an ABI break
<sham1>
Because suddenly one would have to ask "what is a function pointer"
<Griwes>
sham1, you may want to keep your eye on wg21.link/p2806, then
<nortti>
I thought the proposal was for a closureful lambdas to have a separate type from that of a function pointer
<Griwes>
a function pointer is a fake thing that the language pretends is a function
<Griwes>
(...don't even get me started on member function pointers in C++...)
<sham1>
Okay, but what would it be. C doesn't have templates, so every lambda with a closure would need an actual type
<sham1>
So unlike C++, the lambda type can't be unnamed
<nortti>
iirc, it would be unnamed and you'd need to use auto
<sham1>
Function parameters tho. I want to pass my lambdas to higher-order functions
<sham1>
Some qsort-like thing taking a closure so I can finally do Graham scan without needing to use globals like a non-reentrant caveman
<mcrod>
hi
<sham1>
Like I can make the global into a thread-local instead, but it's still icky, but it's also the C way
xenos1984 has quit [Read error: Connection reset by peer]
heat has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
<heat_>
sham1, qsort_r?
<gog>
mcrod: may i pet you
<mcrod>
yes
* gog
pet mcrod
* mcrod
prr
<geist>
proper
<heat_>
i didn't update my arch system for like 2 weeks and now i have 598 packages to be updated
<gog>
i have about 700
<gog>
i'm not updating tho
<heat_>
manjaro moment
<gog>
updating manjaro is dangerous
<heat_>
using manjaro is dangerous
<gog>
my middle name is danger 😎
<heat_>
adanger
<gog>
adanger crisistine
<heat_>
isn't it christine
<heat_>
u dumb dumb
<gog>
:|
<geist>
danger cat
<gog>
i put the word crisis in it
<heat_>
oh
<heat_>
i dumb dumb
<vaartngvirf>
my name is Cant Fucking OsDev
<gog>
same
<geist>
osdev is for closers
<gog>
huehuehue
heat_ is now known as heat
<heat>
linux
dza has quit [Remote host closed the connection]
dza has joined #osdev
<gog>
linux moment
xenos1984 has joined #osdev
dzwdz1 has quit [Ping timeout: 245 seconds]
heat has quit [Remote host closed the connection]
dzwdz1 has joined #osdev
heat has joined #osdev
<mcrod>
my cousin watched titanic for the first time in her life.
<mcrod>
i'm in danger.
heat has quit [Quit: Client closed]
<kazinsal>
hmm. weekend approaches, gotta choose a project to work on
<kazinsal>
new x86-64 kernel core, or 8088 microkernel? decisions decisions
<kazinsal>
one is useful. the other is not, but possibly more fun
<vaartngvirf>
x86-64 kernel core is a weekend project for you?
wblue has joined #osdev
<kazinsal>
laying down the skeleton of it and doing the basic MMU and hardware stuff should only take a couple days
<vaartngvirf>
dont steal my idea but what if i made real mode bare metal IRC client, would anyone use it?
sauce has quit [Ping timeout: 258 seconds]
<ih8win8>
how about getting Haiku running on Raspberry Pi?
sauce has joined #osdev
<vaartngvirf>
i dont want to wash someone else's dirty underwear
<gog>
a real mode irc client
<vaartngvirf>
gog: would it be good?
<gog>
you'll need a whole tcp stack somehow
<ih8win8>
A whole TCP stack, plus NIC drivers.
<ih8win8>
I suppose you could use DOS. That's real mode.
<gog>
that's not bare metal though
<gog>
DOS is a more reasonable choice
<gog>
because you can actually get a whole TCP stack for DOS
<gog>
as opposed to having to implement one entirely from scratch
<DragonFox>
how about an UEFI application IRC client?
<DragonFox>
finally a use for the network stack ^^
Turn_Left has quit [Read error: Connection reset by peer]
<gog>
that's also more feasible
<gog>
but it's not real mode
<ih8win8>
Does UEFI even count as bare metal?
<gog>
ehhhhhhhhhhhhhhhh
<DragonFox>
not really, yea
<DragonFox>
at least not while BootServices running
<vaartngvirf>
would anyone use it tho?
<gog>
is that the idea?
<gog>
other people using it?
<vaartngvirf>
yeah
<gog>
you're barking up the wrong tree with that i think
<ih8win8>
why would anyone use our custom OSes?
<DragonFox>
since I'm currently looking for a replacement for HexChat ... chance >0
<DragonFox>
but I actually want one that's better on wayland, soooo ... no x)
<kazinsal>
doing a TCP/IP stack in real mode is kind of an exercise in fiddling with tooling for real mode systems
goliath has joined #osdev
<kazinsal>
more than it really is an exercise in TCP/IP
<vaartngvirf>
i mean there are lots of IRC heads with 10 computers runninga the same time, you'd think they dedicate one to UEFI IRC client, no?
<gog>
i have one computer running
<DragonFox>
you can even just run the UEFI one in the edk2 emulator :>
<gog>
well two if you count my phone
<DragonFox>
if it had network support ... as it has on macOS
<kazinsal>
in theory a TCP/IP stack can be ported to just about anything assuming it works in X amount of memory. the pain in the "do it in 16-bit 8086" idea is, well, the toolchains for it are *fascinating*
<DragonFox>
and I have patches for linux for that, that I should upstream already ..
<CompanionCube>
funnier would be 'headless irc server booted from PXE'
<vaartngvirf>
kazinsal: what do you mean by toolchain? isnt gcc interface uniform?
<gog>
real mode isn't flat addressed
<DragonFox>
gcc can't do segmentation, right?
<DragonFox>
yea
<gog>
that makes running C on it nontrivial
<kazinsal>
gcc doesn't have real support for 16-bit real mode
<kazinsal>
.code16gcc is a myth
<gog>
you could use djgpp
<gog>
but then you lose the benefits of modern language constructs
<kazinsal>
recently I've been futzing with openwatcom
<gog>
does openwatcom support c23
<gog>
:3
<kazinsal>
I wish
<ih8win8>
nope
<gog>
smh my head
<ih8win8>
It can do 16-bit real mode, though
<DragonFox>
8086 and C23 sounds like a great combo
<DragonFox>
oh deer
<vaartngvirf>
cmon guys, we have to think of something someone will actually use
<gog>
why
<DragonFox>
users are horrible
<DragonFox>
you don't actually want users
<gog>
right
<gog>
my goals for osdevving aren't to have users
<DragonFox>
only worse thing are customers or something
<gog>
it's to push my boundaries as a programmer
<kazinsal>
customers are just users you have to listen to
<gog>
yes
<DragonFox>
(just joking of course... for legal reasons I guess)
<gog>
customers are users who can decide if you eat or have a house
<gog>
more or less
<DragonFox>
ouch
<Griwes>
kazinsal, but does gcc have protected support for 16-bit real mode?
foudfou has quit [Remote host closed the connection]
<gog>
16 bit protected mode?
<gog>
you still have segmentation
<kazinsal>
it does not have stairs in its house
foudfou has joined #osdev
<DragonFox>
unreal mode was 32bit real mode, right?
<gog>
yes
<DragonFox>
I mean, that could be an option perhaps?
<gog>
it's gonna perform like shit
<gog>
because you won't have interrupts
<gog>
so everything is polled
<vaartngvirf>
i guess the benefit of real mode IRC client is that it will use 1W of power
<vaartngvirf>
or will it
<gog>
even in real mode you stil have interrupts
<kazinsal>
if you're gonna do something in 16-bit real mode, go all out or not at all
<gog>
unreal mode isn't a mode it's a liminal space between modes that has many restrictions
<kazinsal>
it either runs on an actual IBM PC or XT or clone thereof or you aren't doing it right
<gog>
it's not feasible to run any kind of real application there imo
<Griwes>
the only thing sane people should be doing in real mode these days is the very first few instructions in their AP booting code
<Griwes>
s/booting/bootstrap/
<kazinsal>
correct. the only insane thing you should be doing in it is writing code for vintage machines
<gog>
also if you want an irc client that uses 1w of power you might as well just run it on a pi with e-ink display or smth
<kazinsal>
anything else is not sanity nor insanity, but either naivety or psychosis
* Griwes
nods
<DragonFox>
also I'm pretty sure real mode is not more energy efficient than long mode on modern CPUs
<gog>
yeah it lacks power management policy
<gog>
so it's sitting in one C state all the time
<kazinsal>
your power management in rmode is "hlt"
<gog>
and you can't hlt if you're polling
<vaartngvirf>
you cant halt for second then poll then halt again?
<gog>
i suppose
<gog>
you can hlt and set a timer
<gog>
set a timer and hlt
<gog>
so yeah
<kazinsal>
you could yeah. it doesn't seem like a sensible thing to do though if you have working interrupts
<vaartngvirf>
isnt hlt power management every second = extreme power savings?
<gog>
no
<Griwes>
yeah, if you can handle the timer interrupt, why are you polling in the first place?
<ih8win8>
Can't you access ACPI and cpu frequency in real mode?
<gog>
i think you need a working aml interpreter running to actually access power policy?
<gog>
idk
<kazinsal>
you do
<ih8win8>
oh, and you'll probably need USB drivers as well, if this thing is to run on any PS/2 -lacking machine from the last 15 years.
<kazinsal>
and if you write an AML interpreter in 8086 assembly I again refer you to the "naivety or psychosis" remark
<kazinsal>
in fact I don't think that would even work
<gog>
this is all a terrible idea
<kazinsal>
since a lot of ACPI stuff is memory mapped whiz bangs
<ih8win8>
ACPI is an overengineered piece of shit
<gog>
if you wish to make an irc client from scratch you must first invent the universe
<kazinsal>
and on a lot of said whiz bangs, MMIOs that are under 32 bits are undefined behaviour
<Griwes>
I meaaaaaaan you could be dipping into unreal mode
<gog>
dipping into
<gog>
yes
<kazinsal>
also you'd need to use unreal mode for ACPI whiz bangs anyways
<kazinsal>
since they're all at like, FF800000 and higher or sommat
* CompanionCube
is randomly reminded about AMD SVM making 'paged real mode' not a contradiction
<Griwes>
hmmmmm can you get into the not-long-mode-because-no-paging-but-64-bit-already from unreal mode with an ability to realistically go back?
<gog>
but what do you do from there lol
<gog>
you can't handle itnerrupts
<Griwes>
x86 has so goddamn many very weird states
<gog>
x86 is a disaster and she's just like me fr fr
<Griwes>
sure, disable interrupts, do MMIO necessary to execute AML, jump back :V
<kazinsal>
basically, this is one of those cases where the answer isn't "yes, you can probably do it", but rather "no, I don't care if it's technically feasible on paper, don't fucking do it"
<gog>
yes
<gog>
don't do it
<kazinsal>
this just in, gog is a love letter to PDP-11s
<gog>
whaa
<vaartngvirf>
UEFI IRC client it is then
<Griwes>
look, I just started new meds, I can have some theoretical psychosis, as a treat
<kazinsal>
some of early x86 ISA stuff is concerningly reminiscent of the ISA design of the later PDP-11s
<gog>
ohhh ok
<kazinsal>
just with a fantastically complicated not-quite-bank-switching system bolted on because late 70s engineering cocaine
<mcrod>
gog hi
<gog>
mcrod hi
<mcrod>
how do I sleep
<kazinsal>
get into bed, close eyes, honk shoo honk shoo
<gog>
why do you want to sleep it's friday
<gog>
gotta get down on friday
<vaartngvirf>
i see my friends!
<kazinsal>
vodka vodka vodka
andydude has joined #osdev
<gog>
don't write a uefi irc client either
<DragonFox>
sleeping isn't that easy
<vaartngvirf>
gog: why
Burgundy has quit [Ping timeout: 250 seconds]
<kazinsal>
no threading, single core only, stuck dealing with EFI interfaces
<kazinsal>
no power management
<kazinsal>
goddamn EFI interfaces
<gog>
i mean you can write it
<gog>
i write weird code too
<gog>
it's fine
<Griwes>
and if you do, probably just do it in kuroko, unless you want to demonstrate the aforementioned psychosis
<gog>
but people won't want to help you with such an oddly specific goal
<gog>
yes
<kazinsal>
<thing> But Make It Run As A UEFI Application is a comedy option for a thing that already exists basically
<gog>
doom but a uefi application but i bet somebody already did that
<gog>
doom is on everything
<DragonFox>
if you don't want EFI interfaces, just write your IRC client on LF OS (:
* Griwes
immediately went to google for doom but uefi
<Griwes>
gog, high five
<gog>
it exists?
<CompanionCube>
iirc UEFI has *some* level of multi-core functionality?
<bslsk05>
Cacodemon345/uefidoom - Port of Doom to UEFI. (9 forks/201 stargazers/GPL-2.0)
<gog>
global state means you're locked to the BSP
<gog>
UEFI isn't reentrant really
<gog>
much less thread-safe
<Griwes>
I meeeeeean it could be, SMM could well be using some of it, you never know
<gog>
fair
<Griwes>
did we mention that x86 is a mess already?
<gog>
she's just like me fr fr
<kazinsal>
the other day I dreamt up this insane idea for a multi-CPU 8086 board with custom chips for memory access management and somehow that's less insane to me than the idea of "multi-core UEFI application"
<gog>
lol
<gog>
god
<gog>
no thanks
<Griwes>
for your sake I hope it was actually a dream and not a conscious stream of thoughts
<gog>
i like long mode and interrupts and paging
<kazinsal>
probably easier than implementing an ISA-compatible system with MULTIBUS
<gog>
LEELOO DALLAS MULTIBUS
<kazinsal>
I've read the 8086 system implementers manual and it's a wild ride
<Griwes>
okay, for no reason other than someone mentioning getting usb bits working, I've now read enough of the spec to very roughly understand what kind of driver architecture for it I want
<gog>
neat
<Griwes>
mind you, I'm very far away from even starting PCIe, so this knowledge is completely useless for at least a couple of years more
<kazinsal>
I imagine the "easiest" way to do this would be to put another 8088 on an ISA card with some circuitry to wire the reset vector etc to your own little ROM so when the system powers on the ancillary 8088 waits for some signal from the OS running on the system board's 8088
<kazinsal>
then it starts executing code from wherever the OS tells it to
<Griwes>
"""easiest"""
<gog>
maybe i'll write a tiny irc client and then everything i need to run it
<vaartngvirf>
stole my idea regardless
<vaartngvirf>
can i be the ideas guy
<gog>
i mean write a tiny irc client targeting existing standard lbraries
<gog>
then write everything i need to replace it
<vaartngvirf>
damn
<kazinsal>
actually now I'm kinda wondering how difficult the circuitry would be for this...
<ih8win8>
write an IRC client in VHDL and put it on a FPGA
<gog>
now there's an idea
<DragonFox>
nice
<DragonFox>
yes please
<kazinsal>
if I were insane enough to do this I'd do it with 74-series TTL for sure
<DragonFox>
can never have remote code execution
<DragonFox>
because it has no code execution at all
<kazinsal>
gotta quadruple down like KFC
<ih8win8>
I'm sure there are FPGA NIC implementations, but an entire TCP stack in hardware seems tough.
<Griwes>
yeah, typically you'd embed a small ARM core or something to run the stack, I think
<vaartngvirf>
so still hackable
<kazinsal>
bah humbug. they don't make the 74x4078 in TTL logic level so I need more chips
<kazinsal>
(christ I can't believe I'm thinking this one through)
vaartngvirf has quit [Quit: WeeChat 3.8]
<Griwes>
lol
<Griwes>
level converters aren't _that_ bad
<kazinsal>
actually I can do this with two 74LS29s
<kazinsal>
and a 74LS08
<kazinsal>
actually need a 74LS11 instead of an 08
<kazinsal>
that should be enough to drive the CS line for a separate ROM for FFFxx for the add-in card's 8088