<bslsk05>
github.com: lk/gfx.c at master · littlekernel/lk · GitHub
<clever>
alpha2023: for example, these functions are designed for a normal linear bitmap image, if you made a t-format version of that, and exclusively use that for drawing, then terminals in a 3d space is trivial
<zid>
sb16 is a huge range of actual devices I think
<wxwisiasdf>
right...
<zid>
gotta put your irq details into the setup screen of your game for a reason!
<alpha2023>
clever you seem to have some ntsc video noise there
<clever>
alpha2023: that noise is from having too many sprites in the same scanline, for the current clock rate
<clever>
i was underclocking it to find the limits
<alpha2023>
ah, the NES issue
<clever>
yep
<clever>
but i can raise the clock, to raise the limits
<clever>
> Yes, context memory (for display list) is embedded SRAM. It can do one pixel per cycle for palettised formats (compared to 4 pixels per cycle for unscaled, and 2 pixels per cycle scaled).
<clever>
alpha2023: the way the image is being displayed also impacts the cost
<clever>
the video with the tearing, was also down-scaling the image a decent amount, which halves the rate it can produce pixels
<clever>
using a pre-scaled sprite, would have let it render twice as many sprites
<alpha2023>
is that interlaced or progressive? I can't quite tell
<clever>
interlaced, 480i ntsc
<alpha2023>
neat
<clever>
the "interlacing fixed" in the title, is in reference to the fact that the 2d core was in progressive mode, but the phy was creating 480i
<clever>
so the 2d core created a new 240 high frame, using the first 240 lines of the "framebuffer", for each field
<alpha2023>
ah
<clever>
but when the 2d core is properly in interlaced mode, it creates a field, from all of the odd lines
<clever>
then another from the even lines
<clever>
the difference, is that it was stretching things 2x
<bslsk05>
github.com: lk-overlay/hvs.c at master · librerpi/lk-overlay · GitHub
<clever>
alpha2023: the hvs_channels array here, is a carefuly designed struct, that lives in MMIO memory, so those writes on 471-476 are directly configuring hardware
<clever>
while the channels array is just in .bss, so i can re-configure part of it later
<bslsk05>
github.com: lk-overlay/hvs.c at master · librerpi/lk-overlay · GitHub
<clever>
alpha2023: internally, the 2d core can drive up to 3 displays
<clever>
there is one big chunk of memory for holding the fully composited scanlines
<clever>
and this chunk of code partitions that up into 3 FIFO's
<clever>
any time a FIFO has room for 1 scanline (based on the width setup earlier), it will parse the sprite list, fetch image data from ram, and composite it directly into the FIFO ram
biblio has quit [Quit: Leaving]
<clever>
if a pixel is covered by 2 sprites, then it wastes clocks drawing to it twice
<clever>
if a pixel isnt covered by anything, it doesnt draw to it, and you get data from a few scanlines in the past, usually mis-aligned heavily
<clever>
there is a background fill to solve that, but it costs clock cycles to fill
<clever>
alpha2023: the pixel valve then reads that fifo at a defined pixel clock, and turns the flow off during blanking periods, creating a digital video signal, 24bits of color, h/v sync, pclock
<clever>
and that digital signal is then shipped off to one of many video encoders
<heat>
what's the inline asm constraint for a parameter that's both in and out?
<bslsk05>
'Controllers - Super Nintendo Entertainment System Features Pt. 08' by Retro Game Mechanics Explained (00:23:58)
<alpha2023>
The super scope filters out red phosphors (due to longer decay time), and sends a "on" signal whenever it sees the raster, and an "off" when it doesn't. The PPU then gets that signal, and sends the pixel number the scope is looking at back to the CPU
<alpha2023>
and ofc there's buttons
<clever>
yeah, the critical difference here, is that the PPU will latch the current XY coords when you whack that PIO line
<clever>
the c64 VIC can do the same
<clever>
while with the rpi, you have to just grab the timestamp in an edge triggered irq handler, and then compare to the hsync timestamps
<clever>
its not really meant to do it, but it could
<alpha2023>
on the SNES hw, the gpu is doing the math, so no hsync int needed :3
<clever>
the gpu isnt even doing math, its just latching whatever XY it was just drawing at
<alpha2023>
fair, even simpler
<clever>
and thats going to be slightly into the future, relative to where the scope just got a flash from the beam
<clever>
calibration solves that offset
<clever>
alpha2023: and from 20:28 in the vid i linked, the superscope will feed the raster info to the receiver, for ~5 frames, after you press any button
<alpha2023>
speaking of light pens / light guns... I really wish there was an equivilent for LCD screens for light pens
<clever>
so it first sends an encoded signal on what button you hit, then it just plumbs digital output of the sensor, into the ir led
<alpha2023>
like... I know penabled displays exist, but there arent many that arent attached to a tablet
<alpha2023>
mhm!
<alpha2023>
the IR is... finicky btw
<clever>
yeah
<alpha2023>
if you had incandescent lightbulbs in the line of sight of the receiver it would be intermittent
<clever>
tv ir remotes, use a 40khz blinking, that is turned on/off to transmit data
<clever>
so your AGC can tune in on the 40khz blink, and ignore the absolute level
saltd has quit [Remote host closed the connection]
<alpha2023>
yeah but wash out was a thing
<clever>
have you heard about how the wiimote worked?
<clever>
and what the "sensor bar" did?
_xor has quit [Quit: bbiab]
<clever>
alpha2023: the "sensor bar", is just a bunch of IR led's that are just permanently on!
<alpha2023>
The wiimote had an IR camera that was made 14 years after the super scope. And as someone who had one and a CRT at the launch of the wii, the glare of my high hat incandescent lights could be used instead of a sensor bar and would occasionally glitch out the real one. I had to play in the dark as a kid in some games that made heavy use of the sensor bar
<clever>
and people have even replaced it with candels
<clever>
heh
<clever>
alpha2023: one thing i still need to work on, i can only get ntsc and dpi/vga out of the rpi, hdmi relies on the closed firmware still
<alpha2023>
someone used the wiimote as a cheap way to do projector calibration
<clever>
yep, seen that guy
<clever>
amazing stuff he did
<clever>
including tracking a moving object with a projection in realtime
<bslsk05>
'EEVblog 1488 - Tilt Five Augmented Reality AR Glasses - First Reaction!' by EEVblog (00:35:52)
<alpha2023>
neat but uh
<alpha2023>
not commodity hw :P
<clever>
why do you say that?
<clever>
its a fully assembled product that is for sale
<alpha2023>
well. as a hobbyist, I can (could?) relatively pick up a wii remote, any projector capable of plugging into my computer, a few IR LED's and an arduino to strobe the LED's
<clever>
ah, yeah, that kind of thing
<alpha2023>
whereas the AR glasses require... well the AR glasses with special hardware
<clever>
you can see in the video, that you can still see the image outside of the frames
<zid>
production doesn't mean commodity
<clever>
because the trick is to have the projector light exiting along the axis your looking
<zid>
commodity means 'raw material' more or less, like copper or coffee, we use it to mean "has become basically abundant and fundamental"
<clever>
rather then the glasses being a special filter
<alpha2023>
$350 for the AR kit btw
<zid>
ar glasses are a product, not a commodity
<alpha2023>
ty zid
<alpha2023>
also if I'm gonna get an AR kit
<alpha2023>
I'm gonna get the one lenovo just announced
isaacwoods has quit [Quit: WeeChat 3.6]
<clever>
alpha2023: some of jonny lee's stuff didnt use a wiimote, but rather, some photo-diodes, and projecting a special blinking pattern with the projector itself
<alpha2023>
yep! that was a V1
<clever>
and the sensor could then tell where it is within that special pattern
<bslsk05>
'Head Tracking for Desktop VR Displays using the WiiRemote' by Johnny Lee (00:04:46)
<clever>
this one
<alpha2023>
the V1 did an optical only pattern. the V1.5 used dual polarized light in a modified 3d projector so it didn't require as much calibration time
<clever>
ah yeah, thats what it was
<alpha2023>
v2 was the wiimote which was much faster, and more passive on a per-screen basis at the expense of an IR camera (wiimote)
<clever>
but the head-tracking stuff, only works with 1 viewer
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<alpha2023>
playstation had a headtracking demo with the PS eye (ps3) back in the day that was like that too
<clever>
while the tilt5/castar stuff, can support multiple viewers on the same screen
<alpha2023>
clever: on a 3D tv, you could theoretically do 2 viewers with active shuttering
<alpha2023>
or more for reduced frame rate
<clever>
yeah
<alpha2023>
heck, 4 people at 30fps on a 120hz tv :3
<clever>
lol
<clever>
now youve given me ideas
<clever>
i ran my rpi at 10khz vsync rate by accident one day :P
<clever>
it was only 100x100, so it just scanned out more frames then i expected
<clever>
i could do 4 different videos, interleaved at 4x the frame rate
<alpha2023>
I remember my friend had a DLP tv that was 3D in like, 2009 or so
<clever>
but getting the shutters synced to that...
<alpha2023>
It was neat cause you could use passive 3d glasses like the movie theaters
<zid>
yea shuttered 3D was a thing for a while, and the sales gimmick was watching two shows at he same time
<clever>
yeah, polarized ones
<alpha2023>
that's what a shutter sync cable is for
<zid>
except you have to wear glasses and headphones lol
<clever>
alpha2023: and there is likely a delay between the vsync in the rpi, and the vsync on the tv
<alpha2023>
well, only one person needs headphones :P
<alpha2023>
clever: darn not CRT levels of latency!!!
<clever>
alpha2023: one guy on the forums has been trying to get ultra low latency video playback, and he is getting 1-2 frames of latency between the pageflip call, and the display updating
<clever>
plus a variable partial frame, depending on when within a frame he tried to flip
<clever>
with the gertvga666 board, i have gotten 120hz vga out of my pi as well, on a real crt display
<clever>
over 120hz, the crt just said no and blinked the power led orange
<alpha2023>
on a monitor or tv?
<clever>
a multi-sync vga crt monitor
<alpha2023>
ah that explains it
<clever>
if i feed the same vga signal into a more modern dvi/vga lcd panel, it wont even go above 70hz
<clever>
i also got funky results when i had an undefined variable
<clever>
by accident, the interlaced flag was set, but the odd timings where entirely garbage
<alpha2023>
if you ever are lucky enough to find a really old CRT that doesn't have a junglechip and just does straight output to the guns after decoding color, there is *zero* protection on the sync signals
<clever>
so the even frame was 1/60th of a second long, the odd frame was a WHOLE SECOND long!
<clever>
when the crt got 2 vsync's 1/60th apart, it came out of standby
<alpha2023>
careful you don't get yourself burn in
<clever>
repeat :P
<zid>
I still need a 15kHz display from somewhere
<clever>
then it didnt get a vsync within some timeout, so it went into standby
saltd has joined #osdev
<alpha2023>
zid: If you're in the states, I highly reccomend a later model that has component inputs (easy to convert to RGB in the analog domain, and componet to scart boxes exist)
<zid>
I am not, and I wouldn't use composite if you paid me
<clever>
alpha2023: well, i did also have another problem, the ntsc generator needs a pure 108mhz reference clock, even 108.1mhz is enough to break things
<clever>
alpha2023: with 108.1mhz, the color burst has the wrong freq, and a modern tv just gives up, and treats it as a greyscale signal: https://i.imgur.com/91e85dz.jpg
<alpha2023>
yep
<alpha2023>
analog QAM is finnicky
<clever>
alpha2023: but an older tv, tries to lock onto the colorburst, then drifts out of sync very fast: https://i.imgur.com/Kka5bQi.jpg
<clever>
thats suposed to be red/green/blue color bars
<alpha2023>
ntsc - Never the same color
<clever>
but because the rpi and tv dont agree on the color burst freq, they are drifting out of phase
<alpha2023>
yep!
<alpha2023>
it's less 108.1mhz is too fast, more the inter-signal timings are whacky
<clever>
i think the problem, is that the color reference clock in the rpi is too fast
<alpha2023>
mhm
<clever>
and while the tv did try to lock onto it, its generating a correct color reference
<alpha2023>
yeah
<clever>
and the phase difference between the ntsc signal, and the reference, is the color data
<alpha2023>
mhm
<clever>
and because the rpi is too fast, its not staying in phase
<alpha2023>
PAL fixes that kinda...
<alpha2023>
but yknow
Burgundy has quit [Ping timeout: 252 seconds]
<clever>
fixing my PLL divisors gave a perfect 108mhz, and then the problem went away
<alpha2023>
pal is just ntsc with a double color burst
<wxwisiasdf>
:-)
<wxwisiasdf>
SECAM moment
<zid>
PAL60 is the one true format
<clever>
wxwisiasdf: the rpi does also support secam output, but i dont have anything to test it against
<alpha2023>
SECAM is just france going "we wanna be different as usual"
<clever>
from what i remember, ntsc is encoding 3 things into the signal at once
<wxwisiasdf>
clever: well you an always go to france and le oui oui raspberrie pie
<zid>
some gamecube games let you put them into PAL60 which was nice
<clever>
the absolute (low-pass filtered) value, is the luma
<clever>
the amplitude of the noise ontop of that luma, is half the color signal
<clever>
and the phase offset between that noise, and the reference, is the other half of the color
<clever>
secam instead just puts half the color into into the scanline, and you must get 2 scanlines to recover the color data
<clever>
and the color data is at half res
<clever>
s/into into/into each/
<clever>
alpha2023: but then how is pal different? other then the 50 vs 60hz?
<clever>
and resolutions
<zid>
it's easier to implement cus it has nicer divisors? :P
<alpha2023>
PAL inverts the colorburst phase 180 degrees every line
<alpha2023>
to prevent phase shift due to OTA disturbances
<alpha2023>
otherwise it's NTSC
<alpha2023>
SECAM works the same way
<clever>
but does that do anything to combat the color burst being a hair too fast?
<alpha2023>
not sure!
<clever>
alpha2023: https://i.imgur.com/pknRNCH.jpg another problem ive seen on ntsc, see the red and blue artifacts on the slightly diagonal lines?
<alpha2023>
it's worth noting that PAL gets you some fun artifacts on B&W
<clever>
alpha2023: it must be a mode from the last image, but you could drop the low order bits of any channel
<clever>
alpha2023: https://elinux.org/RPi_BCM2835_GPIOs# the DPI peripheral gives you a everything in the ALT2 column, from gpio 0-27, which includes pixel clock, data-valid, vsync, hsync, and up to 24bits of color
<wxwisiasdf>
trying to run MS-DOS programs on v86 is messy
<klys>
that was one main w95 problem
<wxwisiasdf>
:-)
wxwisiasdf has quit [Quit: Lost terminal]
heat has quit [Ping timeout: 264 seconds]
ChanServ has quit [shutting down]
foudfou has quit [Quit: Bye]
<geist>
well, duh
<geist>
it's very messy
saltd has quit [Remote host closed the connection]
ChanServ has joined #osdev
foudfou has joined #osdev
nur has quit [*.net *.split]
pieguy128 has quit [*.net *.split]
bleb has quit [*.net *.split]
invalidopcode has quit [*.net *.split]
travisg has quit [*.net *.split]
Brnocrist has quit [*.net *.split]
zid has quit [*.net *.split]
aejsmith has quit [*.net *.split]
weinholt has quit [*.net *.split]
ornitorrincos_ has quit [*.net *.split]
antranigv has quit [*.net *.split]
tomaw has quit [*.net *.split]
HeTo has quit [*.net *.split]
darkstardev13 has quit [*.net *.split]
theruran has quit [*.net *.split]
ChanServ has quit [*.net *.split]
foudfou has quit [*.net *.split]
k0valski1889 has quit [*.net *.split]
gxt has quit [*.net *.split]
opal has quit [*.net *.split]
Irvise_ has quit [*.net *.split]
junon has quit [*.net *.split]
Terlisimo has quit [*.net *.split]
puck has quit [*.net *.split]
Ermine has quit [*.net *.split]
amine has quit [*.net *.split]
les_ has quit [*.net *.split]
lg has quit [*.net *.split]
jjuran has quit [*.net *.split]
Bonstra has quit [*.net *.split]
sortie has quit [*.net *.split]
varad has quit [*.net *.split]
thinkpol has quit [*.net *.split]
froggey has quit [*.net *.split]
LittleFox has quit [*.net *.split]
zaquest has quit [*.net *.split]
Celelibi has quit [*.net *.split]
stux has quit [*.net *.split]
Ram-Z has quit [*.net *.split]
jstoker has quit [*.net *.split]
Amanieu has quit [*.net *.split]
DanDan has quit [*.net *.split]
mavhq has quit [*.net *.split]
divine has quit [*.net *.split]
jimbzy has quit [*.net *.split]
mimmy has quit [*.net *.split]
manawyrm has quit [*.net *.split]
wereii has quit [*.net *.split]
Ameisen has quit [*.net *.split]
corecode has quit [*.net *.split]
MrBonkers has quit [*.net *.split]
sebonirc has quit [*.net *.split]
Affliction has quit [*.net *.split]
duckworld has quit [*.net *.split]
dminuoso has quit [*.net *.split]
Killy has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
MelMalik has quit [*.net *.split]
V has quit [*.net *.split]
Benjojo has quit [*.net *.split]
seds has quit [*.net *.split]
gdd1 has quit [*.net *.split]
arminweigl has quit [*.net *.split]
mzxtuelkl has quit [*.net *.split]
dequbed has quit [*.net *.split]
gaze___ has quit [*.net *.split]
lanodan has quit [*.net *.split]
torresjrjr has quit [*.net *.split]
immibis has quit [*.net *.split]
clever has quit [*.net *.split]
koolazer has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
mats1 has quit [*.net *.split]
kazinsal has quit [*.net *.split]
dutch has quit [*.net *.split]
epony has quit [*.net *.split]
leah_ has quit [*.net *.split]
nj0rd_ has quit [*.net *.split]
jeaye has quit [*.net *.split]
wolfshappen has quit [*.net *.split]
mrvn has quit [*.net *.split]
mjg_ has quit [*.net *.split]
sjs has quit [*.net *.split]
meisaka has quit [*.net *.split]
teroshan9 has quit [*.net *.split]
buffet has quit [*.net *.split]
bas1l has quit [*.net *.split]
pg12_ has quit [*.net *.split]
JerOfPanic has quit [*.net *.split]
rb has quit [*.net *.split]
rpnx has quit [*.net *.split]
ckie has quit [*.net *.split]
Mutabah has quit [*.net *.split]
\Test_User has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
justache has quit [*.net *.split]
andreas303 has quit [*.net *.split]
sprock has quit [*.net *.split]
kori has quit [*.net *.split]
night has quit [*.net *.split]
DonRichie has quit [*.net *.split]
thaumavorio has quit [*.net *.split]
klys has quit [*.net *.split]
scoobydoo has quit [*.net *.split]
smeso has quit [*.net *.split]
ozarker_ has quit [*.net *.split]
Piraty_ has quit [*.net *.split]
genpaku has quit [*.net *.split]
vin has quit [*.net *.split]
mrlemke has quit [*.net *.split]
fkrauthan has quit [*.net *.split]
nanovad has quit [*.net *.split]
joe9 has quit [*.net *.split]
eschaton has quit [*.net *.split]
Emil has quit [*.net *.split]
seer has quit [*.net *.split]
woky has quit [*.net *.split]
particleflux has quit [*.net *.split]
janemba has quit [*.net *.split]
moon-child has quit [*.net *.split]
qubasa has quit [*.net *.split]
JTL has quit [*.net *.split]
merry has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
eau has quit [*.net *.split]
energizer has quit [*.net *.split]
j`ey has quit [*.net *.split]
Stary has quit [*.net *.split]
arch-angel has quit [*.net *.split]
LambdaComplex has quit [*.net *.split]
brenns10 has quit [*.net *.split]
alexander has quit [*.net *.split]
Rubikoid has quit [*.net *.split]
zhiayang has quit [*.net *.split]
friedy has quit [*.net *.split]
GeneralDiscourse has quit [*.net *.split]
snickerbockers has quit [*.net *.split]
ebb has quit [*.net *.split]
kanzure has quit [*.net *.split]
paulbarker has quit [*.net *.split]
CompanionCube has quit [*.net *.split]
ThinkT510 has quit [*.net *.split]
ggherdov has quit [*.net *.split]
eck has quit [*.net *.split]
cultpony has quit [*.net *.split]
dragestil has quit [*.net *.split]
phr3ak has quit [*.net *.split]
griddle has quit [*.net *.split]
sbalmos has quit [*.net *.split]
XgF has quit [*.net *.split]
mxshift has quit [*.net *.split]
FireFly has quit [*.net *.split]
w41 has quit [*.net *.split]
Arsen has quit [*.net *.split]
pounce has quit [*.net *.split]
dennis95 has quit [*.net *.split]
dormito has quit [*.net *.split]
dennisschagt_ has quit [*.net *.split]
ZipCPU has quit [*.net *.split]
LostFrog has quit [*.net *.split]
terrorjack has quit [*.net *.split]
ptrc has quit [*.net *.split]
chibill has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
k4m1 has quit [*.net *.split]
amj has quit [*.net *.split]
klange has quit [*.net *.split]
danlarkin has quit [*.net *.split]
stephe has quit [*.net *.split]
amj has joined #osdev
gruetzkopf has joined #osdev
j`ey has joined #osdev
GeneralDiscourse has joined #osdev
energizer has joined #osdev
k4m1 has joined #osdev
klange has joined #osdev
griddle has joined #osdev
eau has joined #osdev
dragestil has joined #osdev
clever has joined #osdev
duckworld has joined #osdev
torresjrjr has joined #osdev
gaze___ has joined #osdev
lanodan has joined #osdev
dequbed has joined #osdev
immibis has joined #osdev
mzxtuelkl has joined #osdev
zhiayang has joined #osdev
brenns10 has joined #osdev
Rubikoid has joined #osdev
arminweigl has joined #osdev
janemba has joined #osdev
JTL has joined #osdev
particleflux has joined #osdev
friedy has joined #osdev
gdd1 has joined #osdev
moon-child has joined #osdev
seds has joined #osdev
Benjojo has joined #osdev
Amanieu has joined #osdev
V has joined #osdev
MelMalik has joined #osdev
SanchayanMaity has joined #osdev
cultpony has joined #osdev
sebonirc has joined #osdev
corecode has joined #osdev
MrBonkers has joined #osdev
Ameisen has joined #osdev
w41 has joined #osdev
mimmy has joined #osdev
manawyrm has joined #osdev
divine has joined #osdev
wereii has joined #osdev
mavhq has joined #osdev
jimbzy has joined #osdev
Ram-Z has joined #osdev
woky has joined #osdev
eck has joined #osdev
DanDan has joined #osdev
seer has joined #osdev
alexander has joined #osdev
Emil has joined #osdev
eschaton has joined #osdev
LittleFox has joined #osdev
froggey has joined #osdev
stux has joined #osdev
thinkpol has joined #osdev
sortie has joined #osdev
Bonstra has joined #osdev
foudfou has joined #osdev
ChanServ has joined #osdev
XgF has joined #osdev
paulbarker has joined #osdev
danlarkin has joined #osdev
kanzure has joined #osdev
ebb has joined #osdev
kazinsal has joined #osdev
merry has joined #osdev
mats1 has joined #osdev
phr3ak has joined #osdev
stephe has joined #osdev
mxshift has joined #osdev
FireFly has joined #osdev
Arsen has joined #osdev
Affliction has joined #osdev
koolazer has joined #osdev
DoubleJ has joined #osdev
snickerbockers has joined #osdev
joe9 has joined #osdev
DonRichie has joined #osdev
jjuran has joined #osdev
varad has joined #osdev
lg has joined #osdev
les_ has joined #osdev
amine has joined #osdev
jstoker has joined #osdev
thaumavorio has joined #osdev
Ermine has joined #osdev
nanovad has joined #osdev
Terlisimo has joined #osdev
night has joined #osdev
puck has joined #osdev
kori has joined #osdev
sprock has joined #osdev
bleb has joined #osdev
invalidopcode has joined #osdev
travisg has joined #osdev
Brnocrist has joined #osdev
zid has joined #osdev
weinholt has joined #osdev
ornitorrincos_ has joined #osdev
tomaw has joined #osdev
antranigv has joined #osdev
darkstardev13 has joined #osdev
theruran has joined #osdev
justache has joined #osdev
k0valski1889 has joined #osdev
andreas303 has joined #osdev
mcfrdy has joined #osdev
pieguy128 has joined #osdev
junon has joined #osdev
Raito_Bezarius has joined #osdev
Irvise_ has joined #osdev
chibill has joined #osdev
fkrauthan has joined #osdev
Mutabah has joined #osdev
\Test_User has joined #osdev
nur has joined #osdev
mrlemke has joined #osdev
ckie has joined #osdev
rpnx has joined #osdev
sbalmos has joined #osdev
meisaka has joined #osdev
nj0rd_ has joined #osdev
ggherdov has joined #osdev
leah_ has joined #osdev
smeso has joined #osdev
qubasa has joined #osdev
mjg_ has joined #osdev
ThinkT510 has joined #osdev
scoobydoo has joined #osdev
epony has joined #osdev
CompanionCube has joined #osdev
Celelibi has joined #osdev
Stary has joined #osdev
pounce has joined #osdev
dutch has joined #osdev
klys has joined #osdev
zaquest has joined #osdev
Killy has joined #osdev
sjs has joined #osdev
ozarker_ has joined #osdev
LostFrog has joined #osdev
buffet has joined #osdev
bas1l has joined #osdev
genpaku has joined #osdev
vin has joined #osdev
teroshan9 has joined #osdev
pg12_ has joined #osdev
JerOfPanic has joined #osdev
terrorjack has joined #osdev
rb has joined #osdev
mrvn has joined #osdev
ptrc has joined #osdev
dormito has joined #osdev
dminuoso has joined #osdev
arch-angel has joined #osdev
dennis95 has joined #osdev
gxt has joined #osdev
wolfshappen has joined #osdev
opal has joined #osdev
LambdaComplex has joined #osdev
dennisschagt_ has joined #osdev
Piraty_ has joined #osdev
ZipCPU has joined #osdev
jeaye has joined #osdev
aejsmith has joined #osdev
HeTo has joined #osdev
JerryXiao has quit [Max SendQ exceeded]
relipse has quit [Max SendQ exceeded]
elastic_dog has quit [Max SendQ exceeded]
wxwisiasdf has joined #osdev
scoobydoo_ has joined #osdev
<wxwisiasdf>
how did windows 9x dealt with ms-dos applications?
scoobydoo has quit [Max SendQ exceeded]
JerryXiao has joined #osdev
scoobydoo_ is now known as scoobydoo
Affliction has quit [*.net *.split]
duckworld has quit [*.net *.split]
Affliction has joined #osdev
duckworld has joined #osdev
Affliction has quit [Max SendQ exceeded]
duckworld has quit [Max SendQ exceeded]
kkd has quit [Ping timeout: 255 seconds]
relipse has joined #osdev
duckworld has joined #osdev
foudfou has quit [*.net *.split]
opal has quit [*.net *.split]
gxt has quit [*.net *.split]
opal has joined #osdev
gxt has joined #osdev
foudfou has joined #osdev
nur has quit [*.net *.split]
pieguy128 has quit [*.net *.split]
bleb has quit [*.net *.split]
invalidopcode has quit [*.net *.split]
travisg has quit [*.net *.split]
Brnocrist has quit [*.net *.split]
zid has quit [*.net *.split]
aejsmith has quit [*.net *.split]
weinholt has quit [*.net *.split]
ornitorrincos_ has quit [*.net *.split]
antranigv has quit [*.net *.split]
tomaw has quit [*.net *.split]
HeTo has quit [*.net *.split]
darkstardev13 has quit [*.net *.split]
theruran has quit [*.net *.split]
k0valski1889 has quit [*.net *.split]
foudfou has quit [*.net *.split]
opal has quit [*.net *.split]
gxt has quit [*.net *.split]
kkd has joined #osdev
foudfou has joined #osdev
opal has joined #osdev
gxt has joined #osdev
Affliction has joined #osdev
eroux has quit [Ping timeout: 244 seconds]
bleb has joined #osdev
Brnocrist has joined #osdev
zid has joined #osdev
nur has joined #osdev
ornitorrincos_ has joined #osdev
weinholt has joined #osdev
pieguy128 has joined #osdev
darkstardev13 has joined #osdev
theruran has joined #osdev
tomaw has joined #osdev
travisg has joined #osdev
antranigv has joined #osdev
aejsmith has joined #osdev
invalidopcode has joined #osdev
HeTo has joined #osdev
k0valski1889 has joined #osdev
Irvise_ has quit [*.net *.split]
junon has quit [*.net *.split]
puck has quit [*.net *.split]
Terlisimo has quit [*.net *.split]
amine has quit [*.net *.split]
Ermine has quit [*.net *.split]
les_ has quit [*.net *.split]
lg has quit [*.net *.split]
varad has quit [*.net *.split]
jjuran has quit [*.net *.split]
Bonstra has quit [*.net *.split]
sortie has quit [*.net *.split]
thinkpol has quit [*.net *.split]
froggey has quit [*.net *.split]
LittleFox has quit [*.net *.split]
relipse has quit [*.net *.split]
zaquest has quit [*.net *.split]
Celelibi has quit [*.net *.split]
jstoker has quit [*.net *.split]
stux has quit [*.net *.split]
Ram-Z has quit [*.net *.split]
mavhq has quit [*.net *.split]
DanDan has quit [*.net *.split]
jimbzy has quit [*.net *.split]
divine has quit [*.net *.split]
mimmy has quit [*.net *.split]
manawyrm has quit [*.net *.split]
wereii has quit [*.net *.split]
Ameisen has quit [*.net *.split]
corecode has quit [*.net *.split]
MrBonkers has quit [*.net *.split]
sebonirc has quit [*.net *.split]
dminuoso has quit [*.net *.split]
Killy has quit [*.net *.split]
V has quit [*.net *.split]
SanchayanMaity has quit [*.net *.split]
MelMalik has quit [*.net *.split]
Amanieu has quit [*.net *.split]
Benjojo has quit [*.net *.split]
seds has quit [*.net *.split]
gdd1 has quit [*.net *.split]
arminweigl has quit [*.net *.split]
mzxtuelkl has quit [*.net *.split]
immibis has quit [*.net *.split]
dequbed has quit [*.net *.split]
gaze___ has quit [*.net *.split]
lanodan has quit [*.net *.split]
clever has quit [*.net *.split]
koolazer has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
torresjrjr has quit [*.net *.split]
mats1 has quit [*.net *.split]
kazinsal has quit [*.net *.split]
elastic_dog has joined #osdev
klys has quit [*.net *.split]
Piraty_ has quit [*.net *.split]
genpaku has quit [*.net *.split]
smeso has quit [*.net *.split]
ozarker_ has quit [*.net *.split]
vin has quit [*.net *.split]
mrlemke has quit [*.net *.split]
fkrauthan has quit [*.net *.split]
joe9 has quit [*.net *.split]
nanovad has quit [*.net *.split]
Emil has quit [*.net *.split]
eschaton has quit [*.net *.split]
woky has quit [*.net *.split]
seer has quit [*.net *.split]
particleflux has quit [*.net *.split]
moon-child has quit [*.net *.split]
janemba has quit [*.net *.split]
JTL has quit [*.net *.split]
merry has quit [*.net *.split]
DoubleJ has quit [*.net *.split]
eau has quit [*.net *.split]
energizer has quit [*.net *.split]
j`ey has quit [*.net *.split]
Stary has quit [*.net *.split]
qubasa has quit [*.net *.split]
arch-angel has quit [*.net *.split]
LambdaComplex has quit [*.net *.split]
Rubikoid has quit [*.net *.split]
alexander has quit [*.net *.split]
brenns10 has quit [*.net *.split]
zhiayang has quit [*.net *.split]
friedy has quit [*.net *.split]
GeneralDiscourse has quit [*.net *.split]
snickerbockers has quit [*.net *.split]
ebb has quit [*.net *.split]
kanzure has quit [*.net *.split]
paulbarker has quit [*.net *.split]
elastic_dog has quit [*.net *.split]
CompanionCube has quit [*.net *.split]
ggherdov has quit [*.net *.split]
ThinkT510 has quit [*.net *.split]
eck has quit [*.net *.split]
cultpony has quit [*.net *.split]
XgF has quit [*.net *.split]
dragestil has quit [*.net *.split]
phr3ak has quit [*.net *.split]
griddle has quit [*.net *.split]
mxshift has quit [*.net *.split]
FireFly has quit [*.net *.split]
w41 has quit [*.net *.split]
Arsen has quit [*.net *.split]
Stary has joined #osdev
LambdaComplex has joined #osdev
arch-angel has joined #osdev
alexander has joined #osdev
friedy has joined #osdev
Rubikoid has joined #osdev
brenns10 has joined #osdev
zhiayang has joined #osdev
kanzure has joined #osdev
GeneralDiscourse has joined #osdev
ebb has joined #osdev
paulbarker has joined #osdev
qubasa has joined #osdev
snickerbockers has joined #osdev
CompanionCube has joined #osdev
elastic_dog has joined #osdev
ThinkT510 has joined #osdev
ggherdov has joined #osdev
eck has joined #osdev
phr3ak has joined #osdev
cultpony has joined #osdev
w41 has joined #osdev
XgF has joined #osdev
dragestil has joined #osdev
Arsen has joined #osdev
mxshift has joined #osdev
FireFly has joined #osdev
griddle has joined #osdev
elastic_dog has quit [Max SendQ exceeded]
pounce has quit [*.net *.split]
dennis95 has quit [*.net *.split]
sbalmos has quit [*.net *.split]
dormito has quit [*.net *.split]
LostFrog has quit [*.net *.split]
dennisschagt_ has quit [*.net *.split]
ZipCPU has quit [*.net *.split]
ptrc has quit [*.net *.split]
terrorjack has quit [*.net *.split]
chibill has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
k4m1 has quit [*.net *.split]
amj has quit [*.net *.split]
klange has quit [*.net *.split]
danlarkin has quit [*.net *.split]
stephe has quit [*.net *.split]
pounce has joined #osdev
sbalmos has joined #osdev
dennis95 has joined #osdev
dennisschagt_ has joined #osdev
dormito has joined #osdev
ZipCPU has joined #osdev
LostFrog has joined #osdev
terrorjack has joined #osdev
ptrc has joined #osdev
Raito_Bezarius has joined #osdev
k4m1 has joined #osdev
amj has joined #osdev
klange has joined #osdev
danlarkin has joined #osdev
stephe has joined #osdev
chibill has joined #osdev
chibill has quit [Ping timeout: 274 seconds]
Raito_Bezarius has quit [Max SendQ exceeded]
zaquest has joined #osdev
jstoker has joined #osdev
DanDan has joined #osdev
Celelibi has joined #osdev
Ram-Z has joined #osdev
jimbzy has joined #osdev
mavhq has joined #osdev
divine has joined #osdev
wereii has joined #osdev
mimmy has joined #osdev
MrBonkers has joined #osdev
Ameisen has joined #osdev
sebonirc has joined #osdev
corecode has joined #osdev
stux has joined #osdev
manawyrm has joined #osdev
relipse has joined #osdev
<geist>
wxwisiasdf: via lots of code. it's extremely complicated
<geist>
but the server seems to be netslplitting or something right now
puck has joined #osdev
Terlisimo has joined #osdev
Ermine has joined #osdev
amine has joined #osdev
les_ has joined #osdev
lg has joined #osdev
sortie has joined #osdev
froggey has joined #osdev
LittleFox has joined #osdev
Bonstra has joined #osdev
thinkpol has joined #osdev
jjuran has joined #osdev
varad has joined #osdev
<geist>
so might want to let it settle down
clever has joined #osdev
dminuoso has joined #osdev
MelMalik has joined #osdev
SanchayanMaity has joined #osdev
V has joined #osdev
Benjojo has joined #osdev
seds has joined #osdev
Amanieu has joined #osdev
arminweigl has joined #osdev
dequbed has joined #osdev
mzxtuelkl has joined #osdev
immibis has joined #osdev
koolazer has joined #osdev
gruetzkopf has joined #osdev
mats1 has joined #osdev
kazinsal has joined #osdev
lanodan has joined #osdev
gdd1 has joined #osdev
gaze___ has joined #osdev
torresjrjr has joined #osdev
gdd1 has quit [Max SendQ exceeded]
koolazer has quit [Max SendQ exceeded]
klys has joined #osdev
JTL has joined #osdev
merry has joined #osdev
j`ey has joined #osdev
genpaku has joined #osdev
mrlemke has joined #osdev
vin has joined #osdev
fkrauthan has joined #osdev
nanovad has joined #osdev
joe9 has joined #osdev
particleflux has joined #osdev
moon-child has joined #osdev
seer has joined #osdev
woky has joined #osdev
Emil has joined #osdev
eschaton has joined #osdev
DoubleJ has joined #osdev
energizer has joined #osdev
eau has joined #osdev
Piraty_ has joined #osdev
smeso has joined #osdev
janemba has joined #osdev
ozarker_ has joined #osdev
scoobydoo has quit [*.net *.split]
dutch has quit [*.net *.split]
epony has quit [*.net *.split]
leah_ has quit [*.net *.split]
nj0rd_ has quit [*.net *.split]
jeaye has quit [*.net *.split]
mrvn has quit [*.net *.split]
wolfshappen has quit [*.net *.split]
meisaka has quit [*.net *.split]
buffet has quit [*.net *.split]
teroshan9 has quit [*.net *.split]
sjs has quit [*.net *.split]
bas1l has quit [*.net *.split]
pg12_ has quit [*.net *.split]
JerOfPanic has quit [*.net *.split]
rb has quit [*.net *.split]
rpnx has quit [*.net *.split]
ckie has quit [*.net *.split]
Mutabah has quit [*.net *.split]
mjg_ has quit [*.net *.split]
\Test_User has quit [*.net *.split]
justache has quit [*.net *.split]
mcfrdy has quit [*.net *.split]
andreas303 has quit [*.net *.split]
sprock has quit [*.net *.split]
kori has quit [*.net *.split]
DonRichie has quit [*.net *.split]
thaumavorio has quit [*.net *.split]
night has quit [*.net *.split]
mrlemke has quit [Max SendQ exceeded]
energizer has quit [Max SendQ exceeded]
JTL has quit [Max SendQ exceeded]
woky has quit [Max SendQ exceeded]
gdd1 has joined #osdev
epony has joined #osdev
mjg_ has joined #osdev
scoobydoo has joined #osdev
woky_ has joined #osdev
mrlemke_ has joined #osdev
leah_ has joined #osdev
dutch has joined #osdev
nj0rd_ has joined #osdev
jeaye has joined #osdev
wolfshappen has joined #osdev
sjs has joined #osdev
DonRichie has joined #osdev
teroshan9 has joined #osdev
buffet has joined #osdev
pg12_ has joined #osdev
JerOfPanic has joined #osdev
rb has joined #osdev
mrvn has joined #osdev
meisaka has joined #osdev
Mutabah has joined #osdev
\Test_User has joined #osdev
mcfrdy has joined #osdev
andreas303 has joined #osdev
justache has joined #osdev
sprock has joined #osdev
thaumavorio has joined #osdev
kori has joined #osdev
night has joined #osdev
rpnx has joined #osdev
ckie has joined #osdev
bas1l has joined #osdev
basil has joined #osdev
<wxwisiasdf>
alright
bas1l has quit [Remote host closed the connection]
energizer has joined #osdev
<geist>
anyway i dunno what level of detail you want, but basically yes, it uses v86
elastic_dog has joined #osdev
JTL1 has joined #osdev
JTL1 is now known as JTL
<geist>
there's lots of 16 to 32 bit thunking going on, since parts of win95 were still 16bit as well. later versions of windows 9x series replaced more and more of that with native 32bit code
JTL is now known as JLT
JLT is now known as JTL
<geist>
it's my understanding that early win95 had lots of little v86 machines running various pieces of the OS, since at the time they released it they didn't have a chance to rewrite everything from the win3.1 era
<geist>
so i think running a MS-DOS machine was also not that different. presumably it ran a separate one per ms-dos program running at a time, and some other hidden ones to run TSRs and whatnot
<geist>
but it was all built on v86 mode for sure
koolazer has joined #osdev
<geist>
years ago i had some sort of win95 internals book, and it was fascinating. the level of hackery they did to pull it off is somewhat astonishing
<geist>
on one hand it's a horrible terrible hack, on the other hand it was genius how they pulled it off
Raito_Bezarius has joined #osdev
<wxwisiasdf>
well, i am more concerned with running MS-DOS applications on a 32-bit OS
<geist>
okay.
<wxwisiasdf>
right now I just give up total control to the MS-DOS program
<geist>
a 32bit os that you want to write?
<wxwisiasdf>
no, i have written, i just lack the part of "loading ms-dos things"
<geist>
so you have now taken on teh task of writing two oses at the same time
<wxwisiasdf>
?
<geist>
well anyway you'll need v86 mode
<wxwisiasdf>
no it's the same os using the task hw thing from yesterday
<geist>
basically run the msdos app in v86 machine
<wxwisiasdf>
fair, that is what i am doing
<wxwisiasdf>
however it locks up the entire system
<geist>
okay, so that sounds like a bug and/or missing features
<geist>
debug it
<wxwisiasdf>
Well I know why
<kazinsal>
printf debugging time
<geist>
and why?
<wxwisiasdf>
It's because I made it so each task switch modifies the IDT to point to the correct TSS
<geist>
okay
<wxwisiasdf>
Not sure if i am supposed to do it like that
<geist>
honestly i'm nto sure either. frankly you're pretty much in new territory for almost everyone here
<geist>
since more or less no one uses any of those old features anymroe
<wxwisiasdf>
:P
<geist>
but most likely you dont want to or ever need to modify your IDT at runtime like that
<geist>
so i'd probably start there and figure out how to do what you ened to do without doing that
<wxwisiasdf>
well the entire OS is cooperatively scheduler because I might be using the task hw mechanism wrong
<wxwisiasdf>
well
<geist>
yes, that's almost certainly not going to work
junon has joined #osdev
<wxwisiasdf>
every IDT gate is linked to a TSS
<geist>
since MS-DOS apps are not cooperative. they'll just run flat out, so you almost certainly need a preemptive system to take away the cpu from them
<wxwisiasdf>
mfw when PIC time
rpnx_ has joined #osdev
<geist>
not sure IDT in v86 really needs that, but honestly i dont really know
<wxwisiasdf>
i would set up PIC idt right away, however, if i do so, the IDT won't change, and if the selector jumps tot he same tss... oh boy
<geist>
i dont know precisely how the cpu decides to deliver irqs to either the v86 machine or trap out of it into protected mode
<geist>
what does the intel manual say here?
<wxwisiasdf>
hmm
<wxwisiasdf>
well it says that the tss stores the new task context and does blah blah normal task switching stuff
<wxwisiasdf>
doesn't detail whetever it automatically updates selectors through
<geist>
ah. well dunoo. sorry. i'd be kinda interested in it, but really not tonight
<wxwisiasdf>
:p
<CompanionCube>
geist: see also: 'how to make your app not run in windows 95'
<geist>
most esoteric x86 stuff is marginally interesting to me, but in general most stuff that pertanis to real mode or *especially* v86 mode is just not that exciting to me
<wxwisiasdf>
heh
<geist>
i'd rather spend those brain cells on something else
<wxwisiasdf>
well
<zid>
sane response tbh
<wxwisiasdf>
i have 3, protected modes rings
<wxwisiasdf>
i am gonna use all the rings
<zid>
It's *very* obsolete, and nothing even really used it for much or for long in any way you'd *need* to ever know, fixes or such
<wxwisiasdf>
zid: fair enough
arch-angel has quit [Ping timeout: 240 seconds]
<wxwisiasdf>
I just want to do something esoteric because why not
<zid>
aye
<zid>
it's going to be difficult to rope others in for help is all
<wxwisiasdf>
that's fine
<zid>
if it's long mode someone here can probably just tell you off the top of their head, or will deem it important enough to look it up for their own benefit then share
<geist>
yah honestly i'm actively trying not to look it up, because if i crack the intel manual then 5 hours of my life willb e lost
<geist>
since i *know* i can rathole in this sort of thing :)
<wxwisiasdf>
fair enough :^)
<zid>
but in practice, my guess is that the IDT knows, either directly or because it's loading a 16bit selector into CS, what is happening
theruran has quit [Quit: Connection closed for inactivity]
<geist>
that was my thought, though it's depends on if you want the IDT to task switch or just take an interrupt
<geist>
though i guess maybe you need a full task gate if you're in v86? thats the detail i dont know
<geist>
also maybe it's possible to just have the IDT set to a single thing but swap what the GDT is pointing to? i forget. but resisting the urge to look it up
<wxwisiasdf>
I just need the IDT to be dynamically changed
<wxwisiasdf>
i've looked onto storing it on the LDT
<wxwisiasdf>
but maybe that won't work as i would, since IDTR exists
<wxwisiasdf>
and unfortunely TR and LD registers are linear so doing segmentation tricks wont work
<geist>
well whatever it is you're going to need to be preemptive about it
<geist>
so maybe get that working first, without any v86 stuff
<geist>
then overlay the v86 stuff as an additional mode switch
<geist>
sicne you'll need the generic mechanism to preempt
<wxwisiasdf>
well yeah that is what i am trying to do
* geist
nods
<wxwisiasdf>
i could of course setup a 32-bit int entry on the IDT for the PIC and get preemtpable while manually forcing hw context switch
<geist>
right
dh` has joined #osdev
<geist>
that seems like the reasonable route
<geist>
always trap to 32bit mode, then decide to context switch your v86 based on what you're doing
rpnx_ has quit [Quit: This computer has gone to sleep]
wxwisiasdf has quit [Ping timeout: 244 seconds]
Patater has quit [Quit: Explodes into a thousand pieces]
jstoker has quit [Quit: *disappears in a cloud of bits*]
<ddevault>
any good resources for understanding ASIDs on x86_64?
<Mutabah>
The intel manuals?
<ddevault>
well, I'm knee deep in those, but those are more of reference material
<Mutabah>
From a quick search in - Vol3 4.10.1 "Process-Context Identifiers" covers them
wootehfoot has quit [Ping timeout: 260 seconds]
<ddevault>
ty
<Mutabah>
It seems relatively simple - if enabled, the TLB entries are assocaited with the PCID (in CR3's lower 12 bits) - and only invalidated if they match
saltd has joined #osdev
<ddevault>
I generally understand it as
<Mutabah>
hmm... I'd assume that it also interacts with the `G` bit in the page attributes
<Mutabah>
but haven't seen a reference to that yet
<ddevault>
the kernel maintains a pool of ASIDs (or PCIDs, w/e) and allocates them to threads
<froggey>
found my VBAR_EL1 issue. was a typo, not a barrier issue, I aligned it to 1024 instead of 2048
<ddevault>
then switches the active one during a context switch?
<Mutabah>
yep
<Mutabah>
I think you have to clear the entire TLB by disabling/enabling the PCID feature when you need to reallocate?
<ddevault>
do you know if all 12 bits are available, thus there are 1 << 12 TCB caches available on the system?
<Mutabah>
That seems to be the implication
<Mutabah>
Although, you'd be limited by TLB slots
<ddevault>
PCID and ASID seem to be different things
<ddevault>
PCID is better covered by the manual
<Mutabah>
Huh
<ddevault>
and ASID only appears in the AMD manual
<Mutabah>
Ah, same concept - different implementations?
<ddevault>
no, they seem to be different
<Mutabah>
or even same feature, different names
<ddevault>
and cpuid supposedly gives the maximum number of ASIDs
<ddevault>
ASIDs maybe have more to do with virtualization?
<Mutabah>
huh
<ddevault>
AMD manual covers PCID in 5.5.1 (vol 3) and it seems to be compatible with the Intel feature
<ddevault>
whereas ASID is not covered in any place in particular but references are dotted throughout
<ddevault>
vol 3 section 15.16 seems to be the most comprehensive details about ASIDs in the AMD manual
<Mutabah>
I don't have a copy of the AMD manuals downloaded, so can't check myself
<ddevault>
I think ASID is only relevant for virtualization so I'm just gonna shelve that for now
epony has quit [Ping timeout: 252 seconds]
antranigv has joined #osdev
bauen1 has quit [Ping timeout: 244 seconds]
bauen1 has joined #osdev
<geist>
what you're thinking about is PCID
<geist>
ARM and riscv call it ASID, but it's the same thing: an id that you set and change as you swap address spaces
<geist>
so that TLB entries get tagged
<Mutabah>
Ah, I knew that I had seen ASID as that concept - it was the ARM manuals
<geist>
but generally here and elsewhere folks will call it ASID, sicne it's the more common general name for it
<geist>
for virtualization ids lots of times you'll see it called VMID
<geist>
but then AMD calls their VMID ASID, so it's a bit confusing
<Mutabah>
bad AMD
<Mutabah>
they probably mean "physical" address spaace
<kazinsal>
"let's fuck with people who don't actually read our manuals and just assume that the intel manuals are canonically correct for AMD64 as well" - some cheeky AMD engineer
<ddevault>
thanks geist
antranigv has quit [Ping timeout: 264 seconds]
epony has joined #osdev
antranigv has joined #osdev
biblio has quit [Ping timeout: 260 seconds]
Burgundy has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
Terlisimo has quit [Quit: Connection reset by beer]
wootehfoot has quit [Read error: Connection reset by peer]
biblio has joined #osdev
gog has joined #osdev
Terlisimo has joined #osdev
gog has quit [Ping timeout: 260 seconds]
mykernel has joined #osdev
<mykernel>
is it possible to load tss in long mode?
<mykernel>
"The actual loading of the TSS must take place in protected mode and after the GDT has been loaded." - from wiki
[itchyjunk] has joined #osdev
dude12312414 has joined #osdev
Ali_A has joined #osdev
gog has joined #osdev
Ali_A has quit [Client Quit]
saltd has quit [Read error: Connection reset by peer]
wootehfoot has joined #osdev
<mykernel>
amd vol2 (12.2.5 64-Bit Task State Segment) System software must create at least one 64-bit TSS for use after
<mykernel>
activating long mode, and it must execute the LTR instruction, in 64-bit mode...
<mykernel>
why i get gpf(with segment code of tss) after loading tss in long mode
<gog>
is your descriptor formatted right
<mykernel>
yeah i have checked in bochs
<gog>
is the base address of your descripter a pointer to a TSS block
<gog>
which is itself formatted correctly
<mykernel>
it is pointing to tss addr, but there is no info on how to setup tss in long modoe
<gog>
it's in figure 12-
<gog>
12-8
<gog>
like the next page
saltd has joined #osdev
nyah has joined #osdev
<mykernel>
i mean is there some initial values to set to not get gpf
<gog>
can you show the code?
<mykernel>
i am just talking about loading tss, not yet jumping to ring3
<clever>
rpnx_: there is probably a simpler way, but ive used this in the past
<clever>
lookup the docs for each flag, and delete whatever you dont need
freakazoid333 has quit [Ping timeout: 260 seconds]
<rpnx_>
I don't need to add bios right?
<clever>
correct
<clever>
i was doing that specifically to test a custom bios
<geist>
oh related: i discovered https://rpilocator.com/ the other day. no idea if they're up to date, but the 2 or 3 places i chcked it links to seem to be
<bslsk05>
rpilocator.com: rpilocator - Find Raspberry Pi Computers in Stock
<geist>
shows you how hard it is to get ahold of one
<geist>
though i did see that adafruit had some rpi400s, which they dont seem to track
<clever>
plus scalpers buying pi's up and re-selling them at $200
<geist>
yah
<clever>
for official resellers, RPF has set price limits, so they cant be jacked up high
<clever>
but a kit with a psu, hdmi, mouse, keyboard, and pi, doesnt have to respect those limits
<clever>
because RPF cant say how much the rest cost
<geist>
yah that's where a lot of them get a huge markup
wootehfoot has quit [Read error: Connection reset by peer]
<geist>
anywhere, there ya go
<heat>
i think they dont make more 4b's
<heat>
all I see in stock are rpi400s
<heat>
which are literally 4b's but better
<heat>
(and it's not like you can't unscrew the chassis and get a regular 4b out of it)
<geist>
well, cpu wise. but they're pricey and you can't easily/... yeah
<geist>
usedful as a computer, but not in a project where you want the headers
<heat>
why not?
<geist>
honestly 4s have a annoying issue: they overheat. so for projects where you stuff one n a box or whatnot you have to consider that
<clever>
the pi400 does still have a gpio header, but it has some extra limitations, and its rather large
<geist>
yah you only get one of the two headers on a pi400, so can't take a hat, etc
<clever>
there is a mosfet for turning the +5v on the gpio header off
<clever>
but that also means you cant power the 400 via the gpio header
<geist>
oh wait, nly one header, am forgetting
<geist>
yah
<geist>
the pi400s dont hae a heat problemb ecause they just dissapate it over a large piece of metal
<geist>
my experience with regular rpi4s if a heat sink doesn't cut it, you need at fan on it of some type
<clever>
the pi400 also has a newer revision of the soc, that just generates less waste heat
<geist>
ah
<heat>
stop talking about heat kthxbye
<geist>
so yeah i use my pi400 has a generic linux thing, even headless most of the time
<geist>
and the other ones tend to get used in a project, like retropie or octoprint or whatnot
<dzwdz>
heat: if you think that's bad, i'm in a channel where there's a guy called asm
<heat>
we have a clever guy
<geist>
yeah i can't get to upset over people naming htemselves common english words
<geist>
heat is probably in the 100 simple english words too
<dzwdz>
no humble guy, though
<dzwdz>
no, definitely not
<geist>
well ten hundred words
<dzwdz>
my bet is 100-1000
<clever>
heat: my irc client at least only alerts if my name is at the start of a msg
<bslsk05>
splasho.com: The Up-Goer Five Text Editor
<heat>
yeah. mine pings me for every mention of the word
<geist>
yah at some point i had edited irssi to only trigger at the start of a line. dunno what client you have but if it's a regexp you can probably tweak it to be start of line
<dzwdz>
irssi uses regex for that?
<dzwdz>
seems like overkill
<geist>
well, it's nice for precisely this sort of thing
<geist>
also i guess you could get it to trigger on any number of topic words if you wanted
<geist>
there's no reason it has to be just because of your nick
<dzwdz>
regex for custom triggers is a great fit, it just feels weird to use it for your nick imo
<dzwdz>
because you'd have to escape the nick before turning it into a regex
<bslsk05>
irssi.org: hilight - Irssi dev help page
<heat>
hexchat doesn't seem to have that
<geist>
there's a switch for it to interp as regexp
<geist>
yeah irccloud i dont get to choose, but then i dont have a common word as my nick so yay
<geist>
what *is* annouing is if someone triggers it over and over again because i literally have like 5 devices in my house that will simultaneously ping every time
<geist>
and yes, i know i just let myself open to that
<heat>
you had said that previously
<geist>
all because irccloud is a proper android/ios/chrome app
<heat>
i'm already quite aware
<heat>
the power to ping you 5 times is enormous, but we wield it responsibly
<geist>
tis why i like to use a nick highlight only when the conversation is ambigious, or you're switching between conversations
<geist>
vs triggering it every time which some folks do
<heat>
yeah
<heat>
cant you just disable the audible ping?
<geist>
yah but usually that means going around and muting the devices. actually on weekends and whatnot is usually is, it's during the day that i have it set to not mute
<wxwisiasdf>
hmm
<geist>
i dont mind occasional notifications, or i would have just muted the notifications for the app altoghether
<geist>
but yeah in general if i'm not 'around' and you higlight my name i'm probably going to hear it
<wxwisiasdf>
that's why my nickname is specifically like this
<geist>
but weren't you someone else last night?
<wxwisiasdf>
no?
<geist>
oh no, never mind. yeah you're the 'trying to run msdos' person
<geist>
for some reason i was remembering you toggling between two differen tnicks. probably someone else
<wxwisiasdf>
the one using 286 tss'es yes
<wxwisiasdf>
and also the mainframe person
<geist>
right, and you *used* to be on another nick a while back
<geist>
like last year
<wxwisiasdf>
superleaf
<wxwisiasdf>
yes
<geist>
yep. that's why i have the bit in my brain that says you have multiple nicks
<heat>
oh
<wxwisiasdf>
Hehe, I am the risc-v osdev too
<wxwisiasdf>
the one who did pcie hotplugging and shit
<heat>
i am the warmth and have always been
<geist>
wxwisiasdf: oh reminds me, since you did that i actually wrote a full pci driver too, you had inspired me to do the same thing so i knew what i was talking about
<geist>
got the riscv and arm full pci setup working
<wxwisiasdf>
amazing!
<geist>
and yeah there are some little tricky details in there that aren't obvious until you actually do it
<geist>
as are in most things
<geist>
like bridges not being able to do 64bit prefetchable stuff, but if it's on the root bus it's okay, etc
<geist>
s/64/32
<geist>
or something like that, have to double check
<clever>
GPT PMBR size mismatch (1953525167 != 244190645) will be corrected by write.
<clever>
i just discovered, one of my usb<->sata adapters, is a little insane
<geist>
oooh that's not good. throw it away asap
<clever>
left #, is how many 512 byte sectors are in a 1tb disk
<clever>
right #, is how many 4096 byte sectors are in a 1tb disk
<geist>
flaky storage hardware that trashes your stuff is gonna hose you
<clever>
hexdump can see a gpt header, 512 bytes into the disk
<wxwisiasdf>
I have some q, what are some interesting oses to check out in the osdev community?
<clever>
fdisk is looking 1 sector into the disk, 4096 bytes
<geist>
clever: actually did you format that in a different enclosure?
<clever>
geist: it was last used directly on the motherboard sata
<geist>
that might not be the usb fault. t's possible it's reporting the disk as 512 byte sectors, but if you plug it into a native port it reports as 4k, etc
<clever>
but for some reason, having it plugged into that now, causes a hard reset
<geist>
one of the risks of moving between accessor mechanisms
<clever>
as-in, while the initrd of linux is probing for disks, *click*, back to the bios
<geist>
since it's translating sata to usb mass storage, whcih is at least one major method switch
<clever>
yeah
frkzoid has quit [Ping timeout: 260 seconds]
<geist>
well, it's kinda the enclosures fault, but only in the sense that if my theory is correct it is because it can't report native 4k sectors through
not_not has joined #osdev
<not_not>
hey all
<wxwisiasdf>
hello
<clever>
geist: i think this is a 512 sector disk
<not_not>
hmm im stuck at my jump into 32 bit mode on intel
<not_not>
immagine a computer, but it
<not_not>
isn't entirely comprized of regular matter
<geist>
that may be difficult
dude12312414 has joined #osdev
<heat>
wxwisiasdf, i'll shill for my os, github.com/heatd/Onyx
<bslsk05>
heatd/Onyx - UNIX-like operating system written in C and C++ (2 forks/52 stargazers/MIT)
<wxwisiasdf>
heat: o-o
<heat>
OwO
* geist
heads out to do some errands
<heat>
notices bulge
<not_not>
say there is some non-matter component to it, maybe space wich can create, manage and destroy matter particles of the computer on demand
<geist>
gotta take a car load of recycling to the recycling place
<geist>
yay
<heat>
taking good care of the extern char **environ;
<not_not>
you guys know what i heard?
<not_not>
that cognition is like computer software and you can program it as you want
<not_not>
and the human cognition has a very flawed operating system, runs on fear and greed alot
<j`ey>
seems off topic
<not_not>
think this is the wrong channel for this is there any philosophy channels?
<not_not>
*are
<heat>
sir, this is a wendy's
<heat>
or if you're in the UK, lad, 'tis a cheeky nandos innit
<wxwisiasdf>
heat: but, where iso
<wxwisiasdf>
i have to do like serenity?
<rpnx_>
Is there a reference for how uart works on ARM?
<rpnx_>
I decided to just make sure the kernel code is bootable, so I used the example code
<rpnx_>
but qemu gave me this:
<rpnx_>
HHHllo,keel Wrldd!
<rpnx_>
Instead of "Hello, kernel World!"
<j`ey>
rpnx_: what example code?
<j`ey>
and there's no 'uart on arm' it depends on what uart it is!
<clever>
when you run it, you can get a gui, with multiple tabs
<clever>
-S tells qemu to halt on startup, so it doesnt run a single instruction, and you can inspect the initial state
<rpnx_>
oh I didn't even notice there was a GUI window popping up, it wasn't being brought into focus, I was thinking I needed to install a separate qemu-gui or qemu-gtk or something like that
<clever>
now the monitor console is in my xterm window
<clever>
and the gui is only framebuffer + serial0
<rpnx_>
I am assuming I cannot use -serial stdio and -monitor stdio at the same time right?
<clever>
there is a trick for that, to mux them together
<clever>
i didnt mention it, because it makes it more complex to use both at once
<zid>
just serial to file, and then cat the file in another terminal :P
<rpnx_>
Can I make it create a gui window for serial?
<clever>
rpnx_: it creates one by default, just look in the view menu
<clever>
> Note that some other command line options may implicitly create multiplexed character backends; for instance -serial mon:stdio creates a multiplexed stdio backend connected to the serial port and the QEMU monitor, and -nographic also multiplexes the console and the monitor to stdio.
<bslsk05>
pastebin.com: ./build/rpnx-kernel.elf:file format elf64-littleaarch64Disassembly of sec - Pastebin.com
frkzoid has joined #osdev
<clever>
objdump doesnt consider that 0xd8 bytes to be code
<clever>
and nm says you have an _start and a __start
<clever>
what linker args did you use?
<zid>
no ___start? work on it
<clever>
oh wait
<clever>
the linker script generated the __start, thats why
<sham1>
______start
<zid>
sham1 is a six underscore programmer
<clever>
rpnx_: can you just upload the whole .elf somewhere?
_mrlemke_ has joined #osdev
mrlemke_ has quit [Read error: Connection reset by peer]
frkazoid333 has quit [Ping timeout: 260 seconds]
<clever>
rpnx_: `curl https://pastebin.com/raw/xKYsAWpC | sort | c++filt` is another useful trick, sorts the symbols so it makes more sense, and converts the c++ symbols back to a sane form
<bslsk05>
github.com: rpi-open-firmware/main.c at master · librerpi/rpi-open-firmware · GitHub
<clever>
rpnx_: so then c_entry() runs on all 4 cores in parallel, and each gets a diff corenr in that var, line 106 then runs main() and bss stuff, on only 1 core
<bslsk05>
developer.arm.com: Documentation – Arm Developer
<clever>
LK instead suspends 3 cores, and wakes them up later
<rpnx_>
looks like there are additional bits you need to pull in 64-bit mode as well
<clever>
yep
<clever>
and your already in 64bit mode
<rpnx_>
Yup, that makes sense.
<clever>
rpnx_: so, there are some slight differences i noticed while helping, if you use -kernel on a raw .bin file, qemu will boot as the rpi does, going thru the arm stub, and pausing 3 cores for you, then jumping to byte-0 of your binary
<clever>
but if you use -kernel on a .elf file, then the load-addr is respected, and qemu jumps all 4 cores to the entry-point defined in the elf headers
<clever>
which the rpi never does
<clever>
but your load addr is the same as on the rpi, so that difference shouldnt come into play
<clever>
and your entry-point is now the first byte of the binary, so that also doesnt matter
<clever>
so thats only leaving the smp difference, which youve handled
<clever>
rpnx_: but when you boot on a pi, the other 3 cores wont run _start, youll still have to deal with that if you want more cores
rpnx_ has quit [Ping timeout: 248 seconds]
rpnx_ has joined #osdev
<rpnx_>
is mmio_base supposed to come from DTS?
<rpnx_>
x0 is 0000000000000000 on qemu
<clever>
rpnx_: ideally, you should parse the DTS and get the base address for every single peripheral, and assume nothing
<clever>
but if you only care about supporting the rpi, you can ignore that and just hard-code everything
<rpnx_>
is the DTS at address 0 or is this problem qemu specific
<clever>
its probably because you didnt specify a dtb file with -dtb
<rpnx_>
hum
<heat>
wxwisiasdf, henlo, sory, wasnt here
<heat>
go to a github action
<rpnx_>
same result.. but I am not sure which core "info registers" shows registers for
<clever>
likely core 0
<clever>
but also, i dont think -dtb works with .elf
<bslsk05>
github.com: qemu/raspi.c at master · qemu/qemu · GitHub
<heat>
nightlies use the disk-image.img stuff (they expect to be on AHCI, cpu haswell), normal commit builds use the .iso (cpu haswell as well)
<clever>
rpnx_: when using -kernel foo.bin, this chunk of asm is put at arm addr 0, and it deals with putting the dtb addr into the right register for you
<clever>
and parking 3 of the cores
<clever>
rpnx_: if you just do `objcopy foo.elf -O binary foo.bin` and then run `-kernel foo.bin`, does it behave differently?
<heat>
for virt, you don't get the dtb in that register at entry with an elf
<heat>
although you can still find it. I think it's always at the DRAM base
<heat>
yeah
<heat>
"For guests booting as “bare-metal” (any other kind of boot), the DTB is at the start of RAM (0x4000_0000)"
<heat>
well, you need it if you want a pointer to the dtb
<rpnx_>
raspberry pi firmware does that for me I think? I guess that has to be done manually if using a virt image in qemu?
<heat>
flat binary with a linux arm64 boot protocol header
<heat>
i don't know what cursed crap rpi does
<heat>
this is *the* way to boot arm64, if you're not using EFI that is
<heat>
(and riscv too)
<geist>
remember, the '-machine virt' is a different system
<clever>
heat: i think the rpi just ignores those headers, and jams the dtb into a certain register always
<geist>
it's not emulating a raspberry pi there, it has differen tfirmware, different expectations
<heat>
yeah
<clever>
and yes, that
<rpnx_>
I don't have jtag, so I am not sure how to test that
<heat>
by default, the virt machine doesn't even have firmware
<rpnx_>
I should probably get one
<geist>
you are on qemu, it has better than jtag
<heat>
it's just a little blob of code they blat out to an address
<heat>
you can make it load EFI though, pretty easily
<geist>
right, with the virt machine it's far simpler than real hardware: -kernel just blats your kernel where it is linked (or at a fixed address if it's not ELF) and then branches into it
<geist>
so usually the first thing i do is make a start.S that has just a `b .` so that it goes into an infinite loop
<clever>
geist: i discovered today, that -kernel foo.elf on the raspi hw, also respects the link addr and entry-point
<heat>
geist, no fixed addressing
<geist>
then you can test if it loaded by starting it, then breaking into the command line and inspect the cpu state with `info registers`
<geist>
heat: hmm?
<clever>
which causes it to behave massively different from real hw
<geist>
yes. remember that -kernel is used to boot linux, it's assumed that the thing booting understands
<heat>
geist, the ""bootloader"" places you wherever it can
<geist>
heat: not true, depends on the machine and the arch
<geist>
if it's an ELF file it can parse it
<geist>
*on some machines*
<geist>
arm is one of them
<heat>
yes, I mean for linux
<heat>
linux arm64
<geist>
to be clear precisely what are we talking about?
<heat>
arm64 boot protocol
<rpnx_>
I think I don't want to fight QEMU too much, can anyone recommend a jtag adapter for me to buy?
<heat>
you're not fighting QEMU
<geist>
rpnx_: omg you have soooo muych better than jtag
<geist>
you're like one step away from having everything you want
<heat>
getting jtag is 10x harder than QEMU
<clever>
yep
<clever>
qemu debug is far far simpler
<geist>
seriously, do what i just suggested, put an infinite loop at the top of your binary
<geist>
now load it with -M virt -kernel <your binary>
<geist>
forget about all the sdcard stuff, etc
<geist>
now, if it loaded right it'll probably just hang, that's great. you can break into the command line (somehting you'll want to know how to run soon) and inspect the state manually
<geist>
unless you fed it complete garbage of a file it'll probably at least branch into your thing, and you can inspect where it loaded it, etc by looking at the info in the register dump
foudfou_ has quit [Remote host closed the connection]
<geist>
if you dont know how to get to the qemu console, perfect, now is the time to learn
<geist>
because it'll pay off in droves
<heat>
make sure your .text is at the top of your linker script :)
foudfou has joined #osdev
<clever>
heat: we already solved that
<clever>
there was a .eh_frame before it, originally
<rpnx_>
so, I can load it if I use elf, but
<heat>
go to qemu's monitor, x/8i the instruction pointer
<geist>
or if you feed it a proper elf file it'll just load the elf file
<bslsk05>
pastebin.com: (qemu) info registers PC=0000000000080000 X00=0000000000000000 X01=0000000000 - Pastebin.com
<heat>
info mtree generally tells you where binaries are in RAM
<rpnx_>
on virt, I have no dtb, it seems
<geist>
rpnx_: okay good. now where did you tell it to link at?
<geist>
baby steps
<rpnx_>
0x80000
<geist>
okay, virt machine has no code there
<geist>
virt machine puts DRAM at 0x4000.0000+
<heat>
yeah, that's wrong
<geist>
no problem. lets change the link address
<heat>
that's IMO the problem with ELF - you can't assume you can run at $addr
<rpnx_>
ok so... it seems like this would require separate steps for RP3 and QEMU-Virt
<geist>
yes. but again, we're just getting started
<klange>
yep, welcome to arm
<geist>
we can worry about that a bit later
<heat>
isn't the RPI super nonstandard?
<geist>
start with the emu virt, get your code going, then worry about rpi. it's not that far away, we're just starting off with the simple path right now
<klange>
that would require there to be a standard in the first place
<geist>
and yes, rpi is super nonstandard, which is why i'm pushing towards qemu virt right now
<heat>
klange, linux arm64 boot protocol kinda is standard
<geist>
i dont want to get itno that, but it's more like rpi is *weird*, much more so than the average board
<heat>
so is arm64 EFI, if you wanna go down that route
<geist>
but lets not get sidetracked
<geist>
rpnx_: so two strategies here: either you change your link address to a valid address (try 0x4080.0000)
<rpnx_>
Is there a way I can have a common process that supports both?
<heat>
geist, actually do you get a DTB in UEFI?
foudfou has quit [Ping timeout: 258 seconds]
<geist>
rpnx_: yes, but that's later on. it's more complicated
<rpnx_>
hum
<geist>
get one thing working first then can modify it to work with more than one
<clever>
heat: the rpi uefi i think hides the DTB in one of the ACPI tables?
<geist>
heat: no, officially
<clever>
its disabled by default
<geist>
rpnx_: the other strategy is to generate a flat binary and jump into that
<heat>
so does all of arm64 fuchsia rely on ACPI? or do you do something hacky?
<geist>
and then -kernel will decide it's a flat binary, and load it to a known address
<rpnx_>
ok, let me refactor my code a bit so I can set up two separate targets a bit more easily
<geist>
0x4008.0000 i think
<geist>
no o please
<geist>
again, lets just get this working, dont get side tracked trying to do stuff you dont understand yet
<klange>
0x40100000
<geist>
fix on one target right now, qemu virt. it's the simplest of all targets. get your code loaded and running
<klange>
qemu will happily just not load the dtb anywhere if you overlap with where it wants to put it by even one byte
<geist>
*then* figure out how to retarget it, so you have something to test against if it goes wrong
<geist>
klange: yeah, we're gonna get to that in a sec
<heat>
klange, yeah but that's for ELF only
foudfou has joined #osdev
* geist
is a sandworm emperor here, seeing the Golden Path to lead rpnx_ through
<heat>
for a blob it just picks a comfy spot for you
netbsduser has quit [Remote host closed the connection]
<geist>
where comfy spot is a fixed address
<geist>
klange: and yeah, you're right with the address
<geist>
the +8000 and +80000 is the rpi loader, i think
<geist>
(32 vs 64bit)
<klange>
i remember that one because i was trying to do 4008_ and you recommend 4010_, so I switched to what you were doing
<clever>
geist: yep, and we did have this partially working on the raspi3 machine
<clever>
but the dtb was mia
<heat>
geist, not necessarily fixed, at least the "spec"'s wording doesn't specify fixed at all. whether that's the case for QEMU or real hardware is beyond me though
<geist>
mia as in what did you test?
<geist>
heat: hmm?
<geist>
what are you referring to precisely?
<heat>
geist> where comfy spot is a fixed address
<clever>
geist: x0 was always zero
<geist>
yes its just according to what the code does
<clever>
we didnt try to brute-force the dtb load addr on raspi3
<geist>
clever: on a rpi?
<clever>
geist: on qemu
<heat>
you could've just looked at info mtree
<geist>
qemu machine virt?
<clever>
heat: oh yeah, forgot about that
<geist>
but yes. on qemu arm/arm64, machine virt, the device tree is at a fixed address. not passed in a register, for some reason
<geist>
i have it hard coded in the LK code, and i remember being baffled over that, but that's just how it is
<heat>
it is passed if you're linux-ish
<geist>
it's always at the base address of ram (0x4000.0000) which is why you have to link/run at some offset from that
<geist>
heat: okay, sure
<geist>
but we're assuming beginners here, where the total size of the code is .text; start_; b .
<heat>
yeah, in that case, no
<geist>
you can try tp pretend to be linux, but it's a bunch of nonsense boilerplate. we fiddled with it on fuchsia for a while before just deciding to quit it
<heat>
i found it to be pretty simple
<heat>
it's just a stupid header you have to add
<geist>
which arch?
<heat>
rv64 and arm64
<geist>
i found it to be fairly simple, but various bootloaders get really picky about it
<klange>
dtb doesn't show up in `info mtree` - it's copied in, not mapped, so you see `mach-virt.ram` but no device tree references
<geist>
and after fighting 2 or 3 different bootloaders which expected different stuff, abandoned it
<heat>
:|
saltd has quit [Remote host closed the connection]
<gog>
hi
<heat>
arm64 bootloaders bad
<heat>
come to efi, efi good
<geist>
what found in practice is various bootloaders are like 'oh this looks like linux, lemme <sanity check random fields and expect values to be exactly X>'
<geist>
basically base of ram (0x4000.0000) + 1MB, to clear the DTB, which qemu tosses down at base of ram
<heat>
gog, that part of efi isn't horrible. PEI is 5x more confusing
<gog>
yeah i dug around that a bit
<heat>
otoh, it kinda makes sense
<heat>
PEI is at the end of the day just a small kernel with extensible shit
<gog>
i understand why it is the way it is
<geist>
really any higher address would work too, that just seems to be a decent offset
<klange>
the hilarious bit is how much of the 1MB is just padding but qemu still nopes out and doesn't load any of it if you get in the way~
<heat>
DXE really blows up the complexity
<heat>
gog, yeah. it's understandable, but no one really tries to take complexity down a notch, and most EFI people have been there for a reaaaaallyy long time, so they don't mind
<gog>
i feel like it'd be difficult to do so while also maintaining the mostly platform-neutral intent of the API
<gog>
because the system has to be in a certain state to have that at all
<bslsk05>
github.com: qemu/virt.c at master · qemu/qemu · GitHub
<geist>
but that encompassing routing is where a lot of the sausage is made
<heat>
EFI itself doesn't require any particular state, just "paging on, registers passed in msabi style, direction flag off, SSE on" for x86_64 for instance
<heat>
PEI has more magic sauce for before RAM init and after RAM init
<heat>
gog, I think that a big issue is that there's a lot of duplicated crap, particularly because UEFI firmware isn't really "a kernel" but tiny modules all split apart
<bslsk05>
github.com: qemu/boot.c at b3cd3b5a66f0dddfe3d5ba2bef13cd4f5b89cde9 · qemu/qemu · GitHub
<geist>
basically it's already loaded the kernel, so it i think via a path ends up down here in the 'finish patching dtb and put in memory' but it is passed this aperture via those variables
<geist>
and so if the kernel loading trimmed the slot it can put it, it just aborts silently
<geist>
and yeah iirc the size of the dtb is padded out, as you say, presumably to give themselves some headroom in case a bunch of stuff is added here, like a long ass command line or whatnot
<heat>
gog, :P you're always welcome into the community if you'd like. i can help you out
<gog>
thanks
<heat>
although that's not quite what I meant - I meant something like consolidated like lk
<gog>
i might get back to work on my own things eventually
<bslsk05>
github.com: qemu/boot.c at b3cd3b5a66f0dddfe3d5ba2bef13cd4f5b89cde9 · qemu/qemu · GitHub
<geist>
oh you're right, it's more explicit
<geist>
side note, one thing i have found nice about loading an .elf file over .bin in qemu: qemu parses the symbol table and in some crash dumps and whatnot actually resolves it
<geist>
not mandatory, but it is kinda nice
<rpnx_>
Well, doing it like this, I got x0 is all 0s again
<rpnx_>
I think qemu doesn't include the firmware?
<geist>
that's right.
<geist>
there is no firmware. again: qemu -M virt is *not* emulating a raspberry pi
<geist>
it's emulating a fictitious piece of hardware designed to be simple to use (for virtual machines, using KVM mostly)
<klange>
-M rasbpi is barely emulating a raspberry pi to begin with!
<geist>
it simply plonks your kernel, a device tree, and any additional ramdisks and whatnot into memory and branches into you
<klange>
It was big news when the patches landed to support the mailbox interface.
<geist>
hat's why, for example, ram starts in a different location too: 0x4000.0000+ is 1GB, and all of the hardware mmio is mapped below that
<geist>
starting ram above devices is a really nice solution too, since you can just extend the ram out in one chunk, right over the 4GB boundary
theruran has joined #osdev
<heat>
you're really giving me motivation to add a new x86 platform just for funzies
<heat>
I don't know how hard that is though
<heat>
i'd like something newer than a freakin ICH9
<heat>
i would also like wifi at some point
<heat>
although you can just passthrough your existing thing and it works
<rpnx_>
but... if I develop for virt doesn't that mean I need to write my own bootloader as well?
<heat>
no
<heat>
you're already bootloaded
<geist>
that's the *point* of the virt machine. you just load-n-go
<heat>
the bootloader loads the kernel and the initrd, and jumps to it; qemu already does that for you
<rpnx_>
uh, linux expects dtb to be already set up by grub or whatever
<geist>
note you *can* load firmware into the virt machine, that's how you do UEFI ARM for example. but in the simple case like you have here it just runs
<rpnx_>
or firmware
<geist>
rpnx_: it already is!
<heat>
grub isn't used around these parts
<rpnx_>
I dont see it?
<geist>
it's there, in memory. qemu just doesn't pass it into x0
<geist>
it's there. look at 0x4000.0000
<rpnx_>
oh...
<heat>
is there a dtb header?
<heat>
like, magic number
<heat>
yeah
<heat>
0xd00dfeed
<klange>
I imagine that's a lots of peoples' twitters.
<heat>
lol
<geist>
yah i'd point you at my code but it's probably more confusing sincei t's lookinag for the virtual address that's already set up, etc
<geist>
but if you just point libfdt at it, it'll immediately reject it if it doesn't have the right magic
<geist>
all this aside it is lame that qemu doesn't pass it in the x0 arg. i guess it's assuming yolo because you're an ELF file and thus know what you're doing
<geist>
since to load properly you have to be intrinsically linked to run at qemu virts address, etc
<geist>
if you flatten to a binary does it assume you're linux and pass it?
FreeFull has quit []
<heat>
no
<heat>
you need to add the linux shitz
<geist>
starting to get flashbacks to the osdev discord where they totally went ballistic when i recommended this
<geist>
and thus i did not stay around
<heat>
why?
<heat>
hurr durr linux bad?
<rpnx_>
ok
<geist>
someone there who is 'in charge' was super anti- using -kernel
<geist>
like 'it just makes you dum, etc etc' or whatever their rationale is
<geist>
and i tried to make an argument that bootstrapping your osdev by skipping a few steps is not *bad*, but nope.
<heat>
geist, what's their workaround, set up a full uboot thing just for virt? lol
<geist>
yes.
<wxwisiasdf>
lmao
<rpnx_>
but it seems that's pc
<geist>
well to be fair this was x86
<heat>
hrm
<heat>
I usually like grub for that yeah
<geist>
their argument was you must use grub/etc or write your own floppy loader. using -kernel is hurr durr bad
<heat>
i barely trust grub to load me
<geist>
which okay. fine. i didn't really care that much about it, but whoever it was had a real bee in theor bonnnet and they went ballistic
<heat>
so I can't imagine what kind of bugs QEMU has
nyah has quit [Ping timeout: 252 seconds]
<geist>
so i was like okay, if thats how this place is gonna be...
<geist>
there was not really any discussions on !x86 going on there
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
<rpnx_>
seems QEMU only respects the load address if you use elf
<geist>
yes
<wxwisiasdf>
better use ELF
<geist>
otherwise it has it's own address it picks for you.i forget what it is
<geist>
if you're a flat binary, and dont have the linux signature then it doesn't know where to load you so it picks an address, but it always picks the same one
<heat>
yes, using a blob has its own set of disadvantages
<heat>
mainly, you need to write fully relocatable code at the beginning
<heat>
and bootstrap yourself there
<geist>
yah for now ELF is nice. it does make your binary intrinsically bound to qemu-virt, but that's okay for right now
<bslsk05>
www.amazon.com: Amazon.com: Sinkr ULINK2 Emulator Programmer Debugger for ARM Cortex-M4 Cortex-M3, Support for JTAG and SWD Debugging, Support for MDK5(KIT A) : Electronics
<geist>
what are you trying to debug?
<rpnx_>
I want to set it up so I can run on real hardware also
<geist>
yes but precisely what kind of real hardware?
<geist>
(it matters... a lot)
<rpnx_>
RPi3B / RPi4 or another ARM64 board that I can buy
<rpnx_>
maybe risc-v board at some point
<geist>
ah, yes the answer is maybe maybe, possibly, i don think so
<geist>
(for the 4 things you listed)
<geist>
honestly i dont even wanna step into thatone, but be prepared to spend a lot of money and fuck around with it forever
<geist>
start the opposite way: find someone that has done it before, for precisely the board you have, and then follow what they did
<klange>
When I was porting my kernel to the rpi, after doing some initial things in QEMU virt, the approach I took was to follow one of the barebones RPi tutorials until I had pixels on the framebuffer.
<heat>
wxwisiasdf, you just need to make sure your bss is at the end, so your kernel image's size doesn't blow up because of it
<rpnx_>
Has anyone used JTag on Raspberry pi 3B or raspberry pi 4?
<geist>
*probably* that jtag can work on some set of things that do jtag, with openocd. but in my experience it's also just as likely to Not Work for arbitrary reasons
<wxwisiasdf>
heat: sure
<wxwisiasdf>
but also that doesn't guarantee zero initialization
<heat>
sure doesn't
<geist>
thing is *real* jtags are very very expensive (many thoousands of dollars) so the stuff liek this is very cheap stuff
<klange>
(That was before I had purchased and bothered to use the max3232 adapter thingies)
<wxwisiasdf>
qemu initializes all memory to 0 anyways but e
<heat>
you should always clear it
<rpnx_>
geist: really? who makes them?
<geist>
lauterbach is the gold standard
<geist>
very very good stuff, but also very expensive
biblio has joined #osdev
<heat>
aren't jtags super low level for what we're looking at?
<geist>
nyway, if you can't ell we're all pretty aggressively pushing you away from using jtag
<geist>
or more to the point none of us are going to try to support you with it. my experience is jtags are *very* fiddly, and require constant futzing
<heat>
i had the impression they were for circuit level debugging
<geist>
unless it just happens to work beautifully, in which case yay for you
<geist>
heat: you can do cpu level tracing, if the board has a) brought the JTAG pins out b) has the JTAG bits unlocked and c) is an archiecture that has publically available JTAG scan chain documentation and d) there's software/hardware that speaks that particular prototocol
biblio has quit [Client Quit]
<heat>
tl;dr good luck you'll need it?
<geist>
so for embedded stuff, it's fairly easy. they're much more jtaggable (though cortex-m stuff uses a thing called SWD which is proprietary but documented)
<rpnx_>
Raspberry pi has an option to switch the pins to jtag mode
<geist>
again, *why* do you want jtag so bad?
<rpnx_>
the firmware will do that if you set an option in config.txt
<heat>
fwiw intel x86 doesn't really have it
<heat>
the firmware people have lots of issues debugging stuff at early boot
<geist>
and yes, x86's version is highly proprietary
<heat>
no, it's straight up non-existent from what I've heard
<geist>
jtag/swd for embedded stuff is fairly easy, if the board has the pins brought out and it's unlocked
<heat>
either that, or the firmware division is super defunded :P
<geist>
most socs have a way to fuse off jtag, that keeps you fromt being able to break into a consumer device
<geist>
but dev boards usually have it unlocked
<heat>
the latest breakthrough in "super early boot debugging" is I2C messages through intel iGPU's HDMI
<heat>
or good old serial of course
<geist>
but once you get into the 'big arm' category its' much pickier, in my experience. nothing else because the clock rates are higher to jtag it, and that gets much more fiddly
<rpnx_>
geist, because I mainly want to develop for a raspberry pi as my first targeted device, but qemu doesn't seem to load the same dtb that the real pi's bootloader is supposed to
<geist>
rpnx_: again, why do yo need jtag?
<geist>
or more specifically why do you *think* you need jtag?
<rpnx_>
well... how else would I debug the kernel if it's running on real hardware?
<heat>
rpnx_, if you get your thing going in qemu, it'll be much easier to get it working on real hw
<heat>
printf
<geist>
serial port. like *everyone here* does
<rpnx_>
hum
<geist>
no one here uses that stuff. it's a crutch, at worst