<kazinsal>
not sure exactly what my plan is going to be but probably three days in and around seattle
CaCode has joined #osdev
<zid>
oh good, google broke my account again
<zid>
they only just fixed the damn thing
<kazinsal>
there's a 72-hour limit for trips to the US before you have to get a full on sinus scrape covid test to re-enter canada without quarantining for two weeks so I'll probably do like, 8th to the 10th
CaCode- has joined #osdev
CaCode_ has quit [Ping timeout: 256 seconds]
CaCode has quit [Ping timeout: 252 seconds]
mimmy has joined #osdev
nvmd has quit [Quit: Later, nerds.]
<moon-child>
kazinsal: try not to die
<moon-child>
it's dangerous down south of the border
mimmy has quit [Ping timeout: 252 seconds]
gog has quit [Ping timeout: 250 seconds]
diamondbond has joined #osdev
Belxjander has quit [Ping timeout: 256 seconds]
nexgen has quit [Quit: Leaving]
xing_song1 has quit [Read error: Connection reset by peer]
* kazinsal
sighs and cracks open the Intel SDM -- it's time to teach a Cisco TAC engineer how to do his job
<zid>
If he upsets you, you could always throw it at him and kill him
hellstabber has joined #osdev
CaCode- has quit [Quit: Leaving]
gog has joined #osdev
diamondbond has quit [Quit: Leaving]
<kazinsal>
"hmm have you tried running a memtest" no you dick it's a machine check exception where the status code says internal timer fault, the CPU and/or the bus is fried
mimmy has joined #osdev
<zid>
yea bad ram doesn't cause MCEs, bad hardware does
<kazinsal>
IA32_MC3_* is for the L2 unified cache and for the APIC
<kazinsal>
so, RIP
nexgen2 has joined #osdev
mimmy has quit [Ping timeout: 252 seconds]
<junon>
I'm having a brain fart. If I have three matrices for a 3D scene - the model, view and projection - in which order do I need to multiply them with each other prior to multiplying by a vec4 to get the screen coordinate from a local coordinate?
<junon>
I know someone in here will know.
nexgen2 has quit [Remote host closed the connection]
nexgen2 has joined #osdev
Oli has quit [Quit: leaving]
<zid>
k so
<zid>
projection is basically about stretching the final output into 16:9 or 5:4 or whatever, so that's last
<zid>
the model matrix is about scaling/rotating the model around its local origin, so that's first
<zid>
view is about moving the model around in 3D space so place it within the screen
<zid>
so that's the middle one
<junon>
that's if I multiply the point against it though for each time
<zid>
you can also mutliply the matrices together to get a single MVP matrix
<junon>
which I could do. But to combine the matrices together first prior to multiplying the point.
<junon>
Right yeah, I have to do that multiplication in reverse order though right?
<moon-child>
junon: no deferred rendering? :)
<zid>
out = P * V * M * vec4;
<junon>
right yeah okay, thanks zid :D
<zid>
If you swap model and view, you will for example, translate the model to the left, then rotate it around the origin.. making it do wild swings around on the view
<zid>
rather than rotating it locally, then moving it to the left
<junon>
moon-child: No rendering at all at the moment, debugging the orthographic projection setup :|
<zid>
if you swap projection to be not-last, you'll squish and stretch the model itself
[itchyjunk] has quit [Ping timeout: 268 seconds]
<zid>
then after it's rotated, it'll be a fat little guy sitting sideways or whatever
<zid>
hope you could follow all that, if you can't I'll draw pictures
sortie has quit [Ping timeout: 260 seconds]
<junon>
I did :) Still not sure why my coordinates aren't right though. Gotta keep playing with it :|
<zid>
It's up to you if you want to set m/v/p as individual uniforms and multiply them in the shaders
<zid>
or if you want to multiply them on the cpu and upload the resulting MVP matric
<zid>
x
<zid>
Sometimes it's easier to just set a vec3 camera; or whatever as uniform and calculate the mvp from that inside the shader, etc
<zid>
junon: If this isn't webgl I recommend rendertoy
[itchyjunk] has joined #osdev
<zid>
if it's webgl good luck
<junon>
It's not webgl, it's a custom little engine thing with BGFX
<bslsk05>
www.newegg.com: Refurbished: HP Desktop Computer Slim S01-aF1006 Pentium Silver J5040 (2.00GHz) 8GB DDR4 256 GB PCIe SSD Windows 10 Home 64-bit - Newegg.com
wgrant has quit [Quit: WeeChat 2.8]
arandomcomrade has quit [Quit: Leaving]
kernelspace has quit [Quit: ZNC 1.7.2+deb3~bpo9+1 - https://znc.in]
<radens>
I'm trying to follow the raspberry pi 32 bit bare bones on the wiki. It says that the load address of the kernel image is at 0x8000, but when I run it in qemu it's loading at 0x10000
<bslsk05>
wiki.osdev.org: Raspberry Pi Bare Bones - OSDev Wiki
<radens>
I've debugged it and verified that the code is running there.
<klange>
Is that maybe one of the things qemu does wrong even with tie 'raspi2' machine option?
<klange>
iirc there's still a bunch of stuff that just doesn't work like the real hardware because Linux doesn't give a shit
<radens>
klange: It would just be screwball for qemu to be wrong but the wiki, which recommends this setup to be right
wgrant has joined #osdev
jafarlihi has joined #osdev
<jafarlihi>
In GDT Tutorial page there's this thing called "type": "GDT[1] = {.base=0, .limit=0xffffffff, .type=0x9A};". I wanted to ask what does this "type" correspond to in Segment Descriptor structure laid out in GDT page? Where there's "Limit", "Base", "Access Byte", "Flags" and such.
elderK has quit [Quit: Connection closed for inactivity]
divine has quit [Ping timeout: 250 seconds]
divine has joined #osdev
<jafarlihi>
Is this considered confidential info? Why Intel manuals tak about GDT in only few sentences?
<jafarlihi>
s/tak/talk/
<zid>
several tens of pages? O_o
<jafarlihi>
Which section?
<zid>
vol 3 chapter 3, chapter 5
<zid>
it's a few hundred pages, sorry, but not all of it is about the GDT
<zid>
it has to teach you a lot of concepts
<jafarlihi>
zid: Thanks! Don't know how I missed it.
jafarlihi has quit [Ping timeout: 256 seconds]
Coldberg has quit [Ping timeout: 256 seconds]
<zid>
If you're only dealing with 32bit I made a silly tool
<zid>
I've not 100% tested this but it was correct for the few things I did test ;)
<zid>
Geist was upset that I had written 0xcf920000000ffff into my assembly file for loading a temporary GDT, I said that if it broke I'd be looking it up in the manual anyway when I went to change it so I didn't believe commented or broken-out fields etc were necessary
<zid>
so I wrote the tool as a sort of compromise with myself
<zid>
(And I did introduce a bug by getting the math wrong trying to do it in a broken out way in C later, hah)
<moon-child>
‘<?php echo "Logic sucks"; ?>’
<jafarlihi>
I better master this because I don't have any other game left to play
Burgundy has joined #osdev
<gog>
weed overdose
<gog>
i injected too many marijuana needles
<geist>
zid: heh. well typing in the constant with a comment is fine in my book
<geist>
just keep it in sync
<geist>
radens: i think various versions of various firmware on various raspberry pis load it at different palces
<geist>
i've been burnewd by that
<jafarlihi>
GDT tutorial tells me to populate TSS segment descriptor at end as well. Can this be all zeroes?
<jafarlihi>
Sorry for stupid questions lol
radens has quit [Quit: Connection closed for inactivity]
<gog>
jafarlihi: no, tss needs to be valid if you're gonna ltr it
<gog>
and you need to have rsp0 pointing to a kernel stack or it'll GP when an interrupt happens
jafarlihi has quit [Ping timeout: 268 seconds]
<geist>
yah i forget offhand if any other fields have to be filled in at LTR time
gog has quit [Quit: byee]
GeDaMo has joined #osdev
Burgundy has quit [Ping timeout: 252 seconds]
dormito has quit [Ping timeout: 250 seconds]
mahmutov has quit [Ping timeout: 252 seconds]
<zid>
protected mode tss needs a lot more filling out I think
[itchyjunk] has joined #osdev
zhiayang has quit [Read error: Connection reset by peer]
regreg has joined #osdev
C-Man has joined #osdev
DutchIngraham has quit [Quit: WeeChat 3.3]
dormito has joined #osdev
zhiayang has joined #osdev
Burgundy has joined #osdev
isaacwoods has joined #osdev
zhiayang_ has joined #osdev
zhiayang has quit [Ping timeout: 260 seconds]
zhiayang_ is now known as zhiayang
gog has joined #osdev
Oli has joined #osdev
zhiayang_ has joined #osdev
zhiayang has quit [Ping timeout: 250 seconds]
zhiayang_ is now known as zhiayang
pretty_dumm_guy has joined #osdev
pretty_dumm_guy has quit [Client Quit]
pretty_dumm_guy has joined #osdev
mahmutov has joined #osdev
<GeDaMo>
"Ventoy is an open source tool to create bootable USB drive for ISO/WIM/IMG/VHD(x)/EFI files. You can copy many files at a time and ventoy will give you a boot menu to select them" https://www.ventoy.net/en/index.html
<bslsk05>
'Tom Waits - "Hell Broke Luce"' by ANTI- Records (00:04:07)
<jimbzy>
noice
<geist>
tom waits is a definitely unique guy
<gog>
yeah the tornado outbreak was crazy
rorx has joined #osdev
<jimbzy>
gog, Especially when you consider the fact that we're almost halfway through December.
radens has joined #osdev
<radens>
Alright, I just connected a raspberry pi B+ to an ftdi cable and did the bare bones tutorial, and it's not echoing out the right characters. screen was told to read at baud rate 115200 and the tutorial uses 115200 and I checked against the peripheral datasheet and the tutorial seems correct, assuming that the clock rate is what it says
<radens>
Any debugging advice
<gog>
jimbzy: the surface analysis during the storm's explosive buildup was pretty crazy. 30-40°F and a long salient of warm air reaching up the mississippi valley
<gog>
30-40°F temperature differential along the front*
<jimbzy>
Did you see the wind maps, too?
* alpha2023
mews
dutch has quit [Quit: WeeChat 3.3]
SpikeHeron has joined #osdev
<gog>
jimbzy: yep
kaitsh has joined #osdev
<geist>
radens: you haven't stated what the problem is
<geist>
you've simply stated the setup
<radens>
lol sorry my problem is that the characters aren't echoing back properly
<radens>
Ie I type a and get } and type b and get { and the number keys are all tofu
<radens>
Which is the sort of thing I might expect from a busted baud rate
sdfgsdfg has joined #osdev
fwg has quit [Quit: .oO( zzZzZzz ...]
dude12312414 has quit [Ping timeout: 276 seconds]
gxt has quit [Ping timeout: 276 seconds]
Vercas has quit [Ping timeout: 276 seconds]
wand has quit [Ping timeout: 276 seconds]
GeDaMo has quit [Remote host closed the connection]
wand has joined #osdev
Vercas has joined #osdev
gxt has joined #osdev
<geist>
do you have a scope?
<geist>
also iirc the pi2 (and some of the other ones) have some wonky configuration re which cpu has control over the serial port clock
<geist>
specifically the GPU 'owns' the clock that generates serial stuff on some models
<geist>
so it may work for a bit and then the GPU kicks in and the serial moves out from underneath you
<geist>
a scope would confirm it since you could just observe what the baud rate has shifted to, if it has
regreg has quit [Quit: Leaving]
<geist>
and yes. this is part of why i hate hacking on raspberry pis in general. there are tons of models and lots of little errata and wonkiness that a lot of software works around
<geist>
i find it to be generally one of the least friendly ARM boards to bare metal hack on
<geist>
rpi4 i think is somewhat 'cleaner'
gog has quit [Ping timeout: 252 seconds]
<jimbzy>
There are a lot of little "gotchas"
<geist>
but yeah the serial clk being owned by the GPU i remember being a big one
<heat>
isn't it the bluetooth or wifi or whatever it is?
<geist>
i think it depends on the model
<geist>
they weren't afraid to move things around a bit as long as the logical model as viewed by an app on linux sees basically the same thing
<geist>
whats worse is some of the 'hardware' behavior is defined by whatever version of GPU firmware is running at the time
<geist>
so i've been burned by getting LK running on a particular firmware revision and then some new one comes out and changes some fundamental thing
wand has quit [Remote host closed the connection]
<geist>
like, the load address. i vaguely remember that being a thing
<geist>
possible qemu is following some earlier revision of the firmware
<geist>
and i know the 64bit kernel is loaded at a different address for Some Reason
<geist>
ie, 0x80000 vs 0x8000
<jimbzy>
Yea
<geist>
most likely they needed more space for the FDT so someone just thought it'd be cute to add another 0 and move on
<jimbzy>
It was just a typo and nobody caught it.
<geist>
oh even better
<heat>
what
<heat>
imma need a sour
<jimbzy>
A bit of coffee under the 0 key.
<heat>
sauce on that
<geist>
well not gonna tell you you'll have a better time on any other arm soc though. rpi is like the IBM PC of arm boards. its easy to find, better 'documented' though there's a lot of defacto stuff that you have to just know, and seems to be sticking around for years and years
<geist>
so it's kinda the shit sandwich you can easily find at the local corner store
<jimbzy>
What would you recommend as an alternative?
<heat>
qemu virt :v
<jimbzy>
¯\_(ツ)_/¯
<geist>
qemu virt for emulator hackery. even if you have to support a different target, it's stable, easy to use, etc
<geist>
for real hackery, i've had pretty good luck with amlogic based stuff
<kazinsal>
or go grab an rpi4 and get yourself the least shit rpi to work with
<geist>
like odroid c2s or whatnot
<geist>
or, rpi4 indeed is a bit better than the other ones
<jimbzy>
I do need to get a 4.
<geist>
it's more standardized than the previous versions, and is at least 2.5x faster than previous ones
<geist>
plus, you can run ubuntu linux on it and easily run qemu + KVM on top of it
* jimbzy
throws his 2's and 3's into the garbage disposal.
<geist>
so you can get qemu virt on top of actual cpu hardware
<heat>
no 4s in stock here
<geist>
keep the 2s and 3s around though, they're perfectly fine for appliances
<geist>
i use them for octoprint, a pidp8, pidp11, etc
<heat>
i'm only able to get a zero 2 w which is a budget 3
<geist>
it's all bare metal hackery where the nonstandardness and hackiness of raspberry pis really shine through
<geist>
their cpus are at least standard though, so nothing funky there
<j`ey>
and 4 has a gic
<geist>
right, exactly that's the main 'standard' thing i'm talking about
<geist>
and you can and should use the built in ARM timers instead of theirs, etc. it begins to look like most other modern arm socs
<geist>
there's still some dumb shit with their L2 cache and it having weird addresses and whatnot i think though
<geist>
but baby steps
<jimbzy>
Every time I hear "baby steps" I think about that old movie "What About Bob?"
<geist>
also nice thing about using pi 2s or 3s for appliances or embedded use cases is they draw less power and need less cooling
<geist>
pi4s really want a fan on them, but you can toss a pi2 or 3 in a black sealed box and doesn't really have any issues
<geist>
jimbzy: that's 100% where i'm pulling it from
wand has joined #osdev
<geist>
keeping Bob alive
<jimbzy>
Dr. Marvinnnn!
<geist>
haha
<jimbzy>
8up like a sandwich.
<geist>
hah i barely remember it, i only really remember 'baby steps'
<jimbzy>
I watched a few months back.
<klange>
I suppose I should write up a blog post for the website today...
<radens>
I solved my uart confusion btw. I dumped the values linux was using and tried those and they worked. I tried to reverse the math to get the clock values linux was using but it turned out a higher number than the board is probably capable of, but I suck at math
<radens>
geist: it's possible I messed it up, but I couldn't get the arm timer to fire properly with qemu raspi 3, so I just used the soc local mailbox timer
Oli has quit [Quit: leaving]
<radens>
I don't have a scope. I'm wondering if I can hook my ftdi cables to the jtag pins and jtag debug it though.
<j`ey>
radens: linux seems to have the arm arch timer in the rpi3 dts, so it should work
gog has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
CryptoDavid has quit [Quit: Connection closed for inactivity]
mctpyt has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
mctpyt has quit [Ping timeout: 252 seconds]
noocsharp has quit [Quit: noocsharp]
nyah has quit [Remote host closed the connection]
mctpyt has joined #osdev
<Ameisen>
going off of the earlier AVR discussion, I haven't had a chance to look over the protocols for SPI/SD access, and SPI/SRAM access yet
<Ameisen>
I imagine that SRAM's would be simpler/have a more consistent turnaround time for an actual write/read - one that doesn't rely on using an ISR to write one byte at a time (with all of the overhead associated with setting up and returning from an ISR)?
<Ameisen>
SRAMs*
<Ameisen>
though, apparently, one person testing with AVR found that by using the dedicated SPI output _just for timing_, and then bit-banging four GPIOs, they were able to get quad-SPI working
<Ameisen>
which only applies to SRAM thoughh
nyah has joined #osdev
<Ameisen>
(i'm looking over the sd mmc/sdi docs now from kingston and sandisk)