<heat>
ok so I need to get a solution to the "no GPIO header" problem
<clever>
you can buy 20x2 header pins, and just solder them in
<heat>
I'll probably get a solderless since I don't know how to solder/no soldering iron
<clever>
soldering them is pretty easy
<heat>
hammering them in sounds wayy easier :)
<clever>
sounds like an easy way to ruin a pi
<heat>
>All the GPIO pins can be reconfigured to provide alternate functions, SPI, PWM, I²C and so. <-- does this mean the mappings are BS? they're all GPIO pins?
<heat>
clever, *shrug*, I've never soldered before and I don't have equipment
<terminalpusher>
I think PDFs are harder to navigate
<terminalpusher>
wait that's the wrong thing yeah
<asymptotically>
terminalpusher: that's the acpi spec. on the same page you found that on, below is uefi
<gog>
phoenix used to have a wiki for the UEFI spec
<gog>
idk why it's gone now
<gog>
but i liked it
<terminalpusher>
ahh you are right. I didn't know they have multiple ones. I Just clicked on the first one
<gog>
but yeah the UEFI spec PDF is a monstrosity
<gog>
i find myself reading the header files from gnu-efi as often as the spec
<terminalpusher>
It doesn't look like there's an HTML version of the PDF
<moon-child>
poppler doesn't render teh code examples in the uefi spec correctly
<moon-child>
which is a complete pain
<gog>
yep
<terminalpusher>
My goal is to read the mouse pointer within the UEFI. Sadly the EFI Simple Pointer protocol turned out to be very unreliable as I heard and it doesn't work in my QEMU. I'm doing `WaitForEvent` and then `GetState` to read in the Simple Pointer State and it all seems to work except that it blocks on `WaitForEvent` forever.
<terminalpusher>
did anyone ever get the Simple Pointer protocol to work in QEMU+OVMF?
<moon-child>
never looked into it. But I would suggest trying on hardware in case of ovmf bug
<terminalpusher>
I'm now thinking about reading raw USB data using `EFI_USB_IO_PROTOCOL` instead and parsing the events myself
<terminalpusher>
oh that's going to be difficult. Is there an alternative to OVMF maybe? Or QEMU in general for UEFI emulation?
<gog>
nothing i know of or have tried
<moon-child>
should not be that hard. Just tedious, as you have to reboot twice for every change you make
<zid>
efi is for poofaces anyway
<zid>
full usb stack or riot
<gog>
ofc i haven't really tried to make any kind of serious app with uefi, i just use it to get to a usable environment
<zid>
and hid stack
<zid>
and pci-e stack to s upport the usb stack
* gog
stacks things on zid
* zid
buckaroos
zaquest has quit [Remote host closed the connection]
<terminalpusher>
moon-child: and I would have to write new data to the USB stick every time no?
<moon-child>
right
zaquest has joined #osdev
<moon-child>
but that's trivially automatable. 'make usb device=/dev/whatever' or some such
<terminalpusher>
I don't have any spare device though. All I know is that my own system's UEFI lets me use my mouse and I bet it uses the Simple Pointer protocol so it could be an OVMF bug but I have no idea.
<gog>
it's possiblethat the ovmf image isn't configured properly too. might be worth looking at the build file for your distro
<terminalpusher>
gog: the build file? I'm not sure where I would find that. IIRC I didn't build it myself, I did `sudo apt-get install ovmf` and then I got `/usr/share/ovmf` and `/usr/share/OVMF` with a bunch of OVMF files
<gog>
yeah, the build file for the dpkg
<gog>
debian has a whole repo for those
<terminalpusher>
also I've tried both /usr/share/OVMF/OVMF_CODE.fd and /usr/share/ovmf/OVMF.fd but same issue
<terminalpusher>
oh
<terminalpusher>
then it's a problem with the package itself? I didn't change any build configs
<gog>
this is just speculation on my part
<gog>
but you can apt-get source for ovmf
<gog>
and in the debian/ directory you should find the build script
<gog>
it is also certainly possible that ovmf is broken for mouse
<terminalpusher>
"Picking 'edk2' as source package instead of 'ovmf' E: Unable to find a source package for edk2"
<geist>
worked with him at google a few years ago, he's a character
<j`ey>
oh nice
<geist>
he did the whole ARM on AVR thing like 10 years ago. is this a new version of that?
<j`ey>
yup
<geist>
kinda curious what those 8 pin ram chips are
<geist>
well, says QSPI, but i dunno of any actual ram that's qspi, but there's 4 of them so i assume it's doing some sort of 4 way QSPI thing
<geist>
oh you know, i wonder if someone makes a ram that looks like QSPI flash, but is much faster. some of the microcontrollers support XIP QSPI flash mode
<j`ey>
from the comments it seems like some are optional, for extra ram
<geist>
if it were actually RAM you could then hae a nice solid block of many megabytes of ram
<heat>
well great I got rx working
<geist>
what ended up being the problem?
<heat>
now I just need to wire a tty
<heat>
weird interrupt stuff probably?
<heat>
I was installing the irq handler long after enabling interrupts
<heat>
I guess something got stuck
<geist>
ah maybe you weren't clearing old ones? i think it's usually a good idea to manually clear all pending irqs before enabling irqs on a particular vector
<geist>
since it might already be latched but wont fire or whatnot
<heat>
I did but I had a long period where the irqs the uart was sending weren't being enabled
<heat>
and I guess that was kind of making the int status stuck and so I wasn't getting interrupts
<geist>
if it was an edge triggered interrupt that fired a while ago but the irq controller didn't catch at the time and the hardware is still expecting you to handle it, for example, i guess
<geist>
various ways to have stuck irqs
<heat>
yea, exactly
<heat>
all the ISA irqs are edge triggered
<geist>
side note i did try the e1000 driver on a real i210 ryzen box the other day. everything seems to work except the MSIs aren't firing at all
<geist>
so that'll be fun to debug. probably some addl setup i gotta do somewhere. finding problems by omission are always a pain
<heat>
nice!
<heat>
I haven't tried out my code in real hardware too much
<GeDaMo>
A true computing scientist :P
<gog>
real hardware? never heard of it
<heat>
anyway this was good progress. now I just need a tty for the serial and hook up /bin/login to it and I've got myself a good headless interface
<heat>
my idea is to get CI running tests on qemu using the serial tty
<geist>
woot awesome
scoobydoo has quit [Read error: Connection timed out]
<gog>
what's that game board that has an fpga and can emulate a bunch of things
<gog>
MiSTer
<gog>
that thing looks pretty neat, wonder if in the future we'll see it combined with a project like this
<immibis>
or rather, has designed and is now livestreaming a presentation about. VoD will be available later I presume
<immibis>
well, doom won't need to run on a MiSTer FPGA, this is a project you do just because you can
<gog>
true
<GeDaMo>
Considering you can run Doom on a pregnancy test, does it really need a GPU? :P
<immibis>
hence, a project you do just because you can. It's designed for CPU rendering and don't need no GPU
scoobydoo has quit [Read error: Connection timed out]
<immibis>
but you make a custom GPU for it anyway
<gog>
wife: "why do you have a digital pregancy test?" me: "gotta play doom on something"
scoobydoo has joined #osdev
Oli has quit [Quit: leaving]
<gog>
aaay he's talking about mister now
<sham1>
Great evening everyone
* gog
gives sham1 a cookie
<immibis>
he says it's a much smaller FPGA than MiSTer and also not as fast
<gog>
yes
<jimbzy>
gog, 1 for pregnant, 0 for not pregnant?
<sham1>
Yay
<gog>
i'd be pretty shocked if i got pregnant
terminalpusher has quit [Remote host closed the connection]
<sham1>
Wait, is this a tracking cookie? Damn it!
<immibis>
if a man tests positive for pregnancy they probably have some type of cancer IIRC. don't discount it
<gog>
i wonder if it'd show positive if i took my progesterone a few hours before
<jimbzy>
Dunno?
<gog>
gonna have to try it
<sham1>
If you have to take the supplement anyway, go for it. But of course, not medical advice in the slightest
<gog>
:p
<jimbzy>
gog, That's trip your wife up for sure if it worked.
<immibis>
now he is talking about a whole bunch of stuff that I think doom doesn't actually do because you can't look up or down
<jimbzy>
Bust out of the bathroom all bewildered and show her the test.
jeaye has quit [Quit: WeeChat 3.1]
<gog>
sometimes i do tell her i'm pregnant and she just looks at me and rolls her eyes
ZombieChicken has joined #osdev
jeaye has joined #osdev
jeaye has quit [Client Quit]
<GreaseMonkey>
i recall doing a port from the 1997 source code release and if memory serves me correctly there's a framebuffer arranged as [row][column] inverted from what the normal framebuffer arrangement is
<GreaseMonkey>
erm... transposed moreso than inverted
smoke has joined #osdev
<smoke>
hello, anyone have any interesting projects they've been working on lately
<immibis>
you just missed a livestream about running doom on an fpga, but it will be available as a video later
smoke has quit [Ping timeout: 240 seconds]
<immibis>
only in germany: "Tech Dominatrix. Device control as a fetish. by Goddess Anisa"
<immibis>
i'm not kidding, that is one of the upcoming segments
<gog>
it's me
<immibis>
I know DOOM renders in column order because of the inability to look up and down. row order would work if you couldn't look left and right
smoke has joined #osdev
smoke has quit [Quit: Leaving]
scoobydoo has quit [Read error: Connection timed out]
mahmutov has quit [Ping timeout: 250 seconds]
scoobydoo has joined #osdev
GeDaMo has quit [Remote host closed the connection]
biblio has joined #osdev
scoobydoo has quit [Read error: Connection timed out]
scoobydoo has joined #osdev
sortie has quit [Ping timeout: 240 seconds]
sortie has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
sdfgsdfg has joined #osdev
<heat>
how do I know if the serial port is connected?