potash has quit [Read error: Connection reset by peer]
potash has joined #osdev
epony has quit [Remote host closed the connection]
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
epony has joined #osdev
Vercas6 has joined #osdev
Vercas6 has quit [Client Quit]
Vercas6 has joined #osdev
gildasio has quit [Ping timeout: 258 seconds]
gildasio has joined #osdev
Vercas6 has quit [Remote host closed the connection]
Vercas6 has joined #osdev
eroux has quit [Read error: Connection reset by peer]
eroux has joined #osdev
GeDaMo has joined #osdev
bauen1 has quit [Ping timeout: 252 seconds]
lkurusa has joined #osdev
ThinkT510 has quit [Quit: WeeChat 3.6]
Ali_A has joined #osdev
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ThinkT510 has joined #osdev
bauen1 has joined #osdev
Vercas6 has quit [Quit: Ping timeout (120 seconds)]
Vercas6 has joined #osdev
MelMalik has quit [Quit: Bye Open Projects!]
Ellenor has joined #osdev
Ellenor is now known as MelMalik
MelMalik has quit [Quit: Bye Open Projects!]
jjuran has quit [Ping timeout: 265 seconds]
MelMalik has joined #osdev
jjuran has joined #osdev
marshmallow has quit [Quit: ZNC 1.9.x-git-170-9be0cae1 - https://znc.in]
[itchyjunk] has joined #osdev
epony has quit [Ping timeout: 252 seconds]
epony has joined #osdev
Ali_A has quit [Ping timeout: 252 seconds]
eroux has quit [Ping timeout: 252 seconds]
opal has quit [Ping timeout: 258 seconds]
eroux has joined #osdev
srjek has joined #osdev
opal has joined #osdev
<zhiayang>
does x86 instruction decoding depend on cs, cr0, or both?
<zhiayang>
having an issue where i'm in unreal mode (cr0[0] is unset, but cs and ds are 4gb segments), and qemu is decoding instructions wrongly
<Mutabah>
both
<zhiayang>
hm, i see
<Mutabah>
Well, it depends on the code size flag of CS's hidden state
<zhiayang>
right
<zhiayang>
i tried a far ret to get out of unreal-code-mode, but that didn't appear to reset the cached state (at least from qemu's monitor -- the limit still shows 4G)
<zhiayang>
`CS =0000 00000000 ffffffff 00cf9a00`
<mrvn>
if CR0 doesn't have long mode enabled then a 64bit CS won't work and the like.
MelMalik has quit [Ping timeout: 268 seconds]
<mrvn>
but you should get a fault in those cases
<zhiayang>
in my case, the 0x66 prefix turns a 32-bit immediate operand into a 16-bit one, rather than the other way around
<zhiayang>
which leads me to believe that i'm not setting the mode correctly
<zhiayang>
i push 0x0:0x4000 to the stack and do an lret after disabling prot mode on cr0, which *should* have done the trick
<mrvn>
and the GDT entry 0 isn't the dummy disabled entry?
<zhiayang>
it is the null descriptor, but if i am no longer in protected mode that shouldn't matter right?
<zhiayang>
i lret after disabling prot mode
<mrvn>
Not sure what loading the null descriptor does for real mode
<mrvn>
or virtual real mode
<mrvn>
getting back from protected mode isn't easy
<zhiayang>
hmmmm
<zhiayang>
i'll try making another gdt entry with a 16-bit descriptor and using that for cs
<zid>
Might wanna look up unreal mode
<zid>
it might have some info you need
<zid>
as afaik dropping back into real mode from protected ends up using cached descriptors or something
<zid>
I don't know the exact details though, it's not something you'd ever need to do
<geist>
HELO FRONDS.
* GeDaMo
ferns
<geist>
yah my ancient 16 bit floppy loader uses unreal. it's interesting if nothing else
<jjuran>
fiends
<geist>
it was my first real experience with the whole 'hardware has a hidden internal descriptor it loads' thing
<zhiayang>
hmm, that didn't work either
<zhiayang>
i'm already successfully in unreal mode, is the thing
Ellenor has joined #osdev
<zid>
You're never not, on a pmode capable cpu as far as I know, it just puts 'real mode looking selectors' into cs on reset
<geist>
todays fixation: getting a good Mean Well power supply
<geist>
but they have so many!
<zid>
I just got a new sexy psu, it has graphs
<geist>
noice. are you still using it to drive a 12 year old computer?
<zid>
ofc
<geist>
actally this does remind me i should fire up the old Nehalem dual socket machine, which i had retired as my main server with a newer ryzen
<zid>
I swapped to my good cpu too
<geist>
but it was generating failures pretty frequently
<zid>
having proved all my issues were psu related
<geist>
but never really did sit down to try to debug what it was. possibly PSU related
<geist>
indeed
<zid>
I had the option to swap to a 6700k but that's even more garbo than my system
<GeDaMo>
I'm thinking about getting more RAM for my 13 year old computer :|
<zid>
GeDaMo: same, toss 2x8GB of PC3-14900 into your order for me
<geist>
depends on how you see it. almost certaly more single threaded, but if you have high MT loads yeah
<zid>
not even more single thread
<geist>
okay, what did you replace it with?
<geist>
(not that i particularly want to wade into this argument again)
<zid>
unlocked E5-1650
<zid>
with a good bin so the voltage stays low
* geist
nods
<geist>
are you overclocking it?
<zid>
a lot, yes
<geist>
sandy bridges were great for that. i still have an unused 2600k floating around that i ran *hard* for the time it was my main
<zid>
The WR for this cpu is 6GHz
ornxka is now known as ornx
<geist>
i think it easily took a OC to 4.5 without any voltage shenanigans
<zid>
idk on what though, dry ice, ln2, water, etc
<geist>
that begins said i replaced it with a 6700k and that was a pretty decent upgrade at the time
<geist>
it was the appropriate jump such that an un-OCed 6700k was > a moderately OCed 2600k
<zid>
yea the 2600k is good but it's not a god xeon bin with bonus memory channels etc
<geist>
though not by a tremendous amount
<zid>
this is a.. 3690x or something, if you take the ecc off
<geist>
yah if you for some reason want a ton of memory channelsl, you'll be forever in the expensive, old xeon territory
<geist>
i'd challenge you to rethink this strategy
<zid>
anything *beyond* 6xxx is faster by a lot
<zid>
6700 is about even
<zid>
but I lose out on some features
<geist>
such as?
<zid>
ecc, pci-e lanes, my expensive-as-fuck-mobo
<zid>
the thing with the 6700 wasn't as good as mine
<zid>
memory bw
<geist>
ws gonna suggest used Zen 1 or 2s, which should be generally flooding the market
<zid>
yea I like the x600 ryzens a lot
<geist>
you get most of those things, though depending on what you're actually doing with PCI-E you may not have as much lanes
<zid>
but no friends have those 2nd hand atm
<geist>
probably should be hitting ebay and whatnot
<geist>
aaah so you're generally relying on teh five finger discount?
<zid>
4 and a half
<geist>
fair enough
<zid>
pay shipping and stuff :P
<geist>
honestly if i had one floating around i might. i'd rather have something of mine that i dont need in use than just sitting there
<zid>
6700k is what's sat in a garage doing nothing atm
<zid>
until it becomes so obsolete it goes in the trash, probably
<geist>
yah my 6700k i donated to my niece so she can play Valorant, ad it does an admirable job of that
<geist>
that's baout the best outcome i can think of for a retired old gaming rig for me
<zid>
yea I am the niece :p
<geist>
she has higher priority
<geist>
the 780ti vid card i had donated eventually hit its limits though, they had to get a replacement for it
<geist>
mostly in the 3GB that the 780 had. otherwise it'd still keep up just fine
<zid>
yea I struggled to find anything to replace a 670, because it had 4GB
<zid>
and a lot of the cheap cards were 2 or 3GB
<geist>
but it generally follows my strategy of getting fairly high end gear, right at the left side of the knee where stuff statrs getting outrageously expensive
<zid>
It's almost identical to a 1050 ti
<geist>
and then it lasts a long time
<geist>
i do remember the 780ti was short on ram, even at the time. was kinda a dud
<zid>
My strat is to take what I can get, or make incredibly canny purchases like my £20 xeon
<geist>
i replaced it with a 980ti fairly quickly, which i still use on my living room gaming rig. can drive 4K nicely
<zid>
980 ti is still a super useful card
<zid>
it's the most powerful gpu you can buy with a RAMDAC
<geist>
and yeah i know it's still a lot of $$. i'm mostly just pointing out that i dont by *stupid* expensive stuff for it, there's a logic to my purchases :)
<geist>
except maybe the 3950x -> 5950x upgrade i did last year, which in retrospect was simply unnecessary
<zid>
I very almost bought one
<zid>
because I saw a stupid cheap one cross my path
<zid>
crypto hadn't kicked off yet and they just wanted rid of it
<geist>
hmm, what do you mean by it having a RAMDAC? did the later ones move from it?
<zid>
a few months later it was 4x the price on ebay
<zid>
no 10+ cards have a ramdac
<zid>
digital outputs only
<geist>
huh ooooh you mean.. yeah okay
<zid>
amd lost their non-digital outputs prior to nvidia's 9 series
<geist>
yah i vaguely remember that now tha tyou mention it, the 10 series was the first all digital
<zid>
so the 980ti is literally the most powerful gpu you can use to drive anything analogue
<geist>
yah i had replaced the 980ti with a 1080ti, which i still use on my main gaming rig. that has turned out to be a total gem
<geist>
and basically the last time any of the *80tis have been 'reasonably' priced
<zid>
yea 1080ti had like 20% market share on steam still when I looked a short while ago
<geist>
also sadness: i've been an exclusive EVGA buyer for the last 10-15 years, now i dunno what to do afterwards
<zid>
(which was like 3x the % of any other card, 1650 ti, 1050 ti, 3080, 3070, 2060, 2070 etc all with 2% each)
<zid>
It was the optimal spot on powerful / price, but also had a low price
<zid>
people not wanting to spend £800 on a 2060 had the option of a GT210, a 2nd hand 6/7/8/9 series, or a 1080 ti, realistically
<geist>
yah at the time the 80tis were expensive but about right on price/performance. after that in the 20 and 30 series nvidia cranked up the prices for the high end tis to ridiculous price
<geist>
presumably to milk enthusiasts
<zid>
yea ti has varied between "last gen's best card on the new process and cheap" and "an extended version of a normal card"
<zid>
It sometimes mean what 'Ultra' used to mean, it sometimes means what 'GT' used to mean
<geist>
yah in the 700/900/1000 it was basically 'the fully unlocked version of the gpu with all of the CUs enabled, priced only slightly as a premiun'
<zid>
the 1650 and 1050 and 1030 ti are all cut-downs though
<geist>
now i dunno what it means anymore. they started slapping tis on anything, and then charing like a 2x premium for the very high end stuff
<geist>
exactly
<zid>
which used to be 'GT'
<zid>
and the 'premium' was Ultra or GTX
<geist>
oh well, at this rate i'll milk the 1080ti another year or two, will have to see how the EVGA and 40x series shakes out
<zid>
I need a new monitor before I need a new gpu tbh
<geist>
and *probably* wont get an AMD gpu again. last one i got was a dud and i was unhappy with
<geist>
not performance wise, but driver wise.
<geist>
possible they've fixed their stuff in the last 10 years, but i'm not holding my breath
<geist>
i dont mind using their built in APU gpus though, just i dont try to game on those
<zid>
I'd honestly be 95%+ happy with an apu
<zid>
The only thing I've played recently that needed jrafics was sekiro
<geist>
oh yeah totally. except for computers i use explicitly for gaming, i am generally happy with built in stuff
<zid>
like, the latest games I've played have been like
<zid>
last call bbs, holocure, factorio, terraria etc
<zid>
which just.. don't need a gpu beyond 'do you have some vram'
<zid>
I already didn't play elden ring because my gpu would not have handled it, and I still would be unable to play it on an apu, so no difference there
<geist>
yah though i dont play shooters i do play enough things that involve actual 3D stuff that it's nice it runs at 100fps or so
<geist>
ie, FF14, Astroneer, etc
<zid>
if I play something 3d these days it's generally like, old
<zid>
As much as I hate to admit it, I'd probably be better off with like, a playstation, for gaming
<zid>
with gpu prices being what they were recently
<geist>
yah, i tend to do that more often than now nowadays really
<zid>
they may tank enough that I can pick something up though
<geist>
yah
<zid>
I'll have to finally update windows :P
<geist>
i wonder if EVGA second hand cards will turn into some sort of premium
<geist>
i honestly have no idea if/how EVGA is considered to be quality wise vs the other stuff
<geist>
but i've been 100% happy with their cards
<zid>
Normal, but their warrenty/customer service etc was good
<zid>
which made them worth buying from over others like gigabyte etc
<geist>
yah i'll probably fall back to ASUS, which have been generally okay for me mobo wise. i tend to stick with them there
<zid>
I wonder how much the latest version of my mobo costs, speaking of asus
<zid>
oof, £600
<zid>
good news, the extreme is £1100
<zhiayang>
right, i managed to get it working: (1) far jump to a 16-bit protected segment; (2) disable protected mode; (3) far jump to the actual code with CS=0
pretty_dumm_guy has joined #osdev
moberg has quit [Ping timeout: 252 seconds]
heat has joined #osdev
<geist>
woot
<heat>
woot
<heat>
oh boy, 16-bit fuckery?
<heat>
good job!
<zhiayang>
indeed, though i'm not doing this by choice
<heat>
who's pointing a gun at you?
<zhiayang>
my university
<zhiayang>
heh
<heat>
16-bit in university? fuckin hell
<heat>
it's $CURRENT_YEAR!
<geist>
still gotta deal with it to boot a damn secondary cpu
<geist>
rassin frassin
<heat>
not anymore, remember that new ACPI thing?
<heat>
i wonder if OVMF supports that
<geist>
well, if i involves writing bytecode it's Right Out
<geist>
and of course the problem is unless you can rely on it, you now need two mechanisms in your kernel
<geist>
tis always the curse of a new implementation of a thing that replcaes the old one, when the old one doesn't have a strict deprecation policy
xenos1984 has quit [Ping timeout: 260 seconds]
<geist>
ARM does it fairly well, though they're deprecation and replacement policies operate out at the 5-10 year range, and then there are always some boards that violate the rules (ike all of the raspberry pis) that keep old mechanisms around
bauen1 has quit [Ping timeout: 244 seconds]
<geist>
but they'll be fairly clear that X is the new mechanism, and Y is now considered deprecated and will be removed in version N+2 of the spec
xenos1984 has joined #osdev
<geist>
if only intel would actually start doing that. start the ball rolling! at least try to get the industry to roll with it
<geist>
(like the removal of 16bit support)
<heat>
geist, no bytecode, just a simple table + mailbox
<geist>
ah that. i wonder if anything implements it. newest machine i have is the alder lake, will look in its acpi dump to see
<geist>
though i seriously doubt it
bauen1 has joined #osdev
<heat>
you'll need a MADT dump
<geist>
yah i always gather one on all my machines. have a little database of full acpi dumps
<heat>
entry type 0x10 apparently
<geist>
lemme check.
<heat>
this should be trivial to implement
<heat>
just hold the CPUs in an mwait for the address
<geist>
aaaaand nope.
<geist>
does it define what mode it starts the cpu in when you do?
<geist>
32bit protected mode?
<geist>
things would be so much simpler of 64bit x86 mode could run with the mmu off. that's one of the mistakes AMD made with the 64bit extension, IMO
<geist>
(that and the swapgs nonsense)
<heat>
geist, yes
<heat>
for x86, long mode enabled and paging identity mapped
<geist>
so then the question is where does the page live where the mailbox is, and where are the page tables located. they'd have to be carved out by the OS or the mechanism would get corrupted
<geist>
so depends in which type the pages are marked by the UEFI memory region stuff
<clever>
that reminds me, does efi run with the mmu on or off? ive seen signs that the mmu is always on with identity paging, but linux wants to be ran with the mmu off, would identity be enough to make it happy?
<geist>
clever: depends on the arch, but it's defined by the UEFI spec
<heat>
geist, ACPI non volatile storage
<geist>
heat: word.
<heat>
aka the piece of memory ACPI requires (I don't think it's required to be non-volatile)
<geist>
yah i forget if that's one of the memory types we keep around for fuchsia or not
<heat>
you must
<geist>
probaby, because ACPI
<heat>
the memory for this stuff is obviously volatile
<geist>
the code for that would be in the physboot styff, which i honestly can't comprehend so i can't point you where the code is
<bslsk05>
github.com: linux/booting.rst at master · torvalds/linux · GitHub
<geist>
this is talking explicitly about that state of the cpu when UEFI is running
<heat>
anyway re: caching
<geist>
handoff is up to the boot shim to do it
<heat>
caching is super important in firmware for performance
<geist>
and post ExitBootServices it can turn off the mmu
<heat>
x86 doesn't require paging for good performance cuz mtrr, which you always set up and should set up correctly
<clever>
yeah, so either the bootloader does ExitBootServices, mmu off, chainload linux
<clever>
or linux itself is a valid efi binary and does that internally
<geist>
yep
<clever>
there is also a runtime service function, to setup the FINAL virtual address for the runtime services, which can only be ran once
<heat>
yes
<clever>
so once you ExitBootServices, you can only decide once, on where the runtime services will live
<clever>
i could see that being a problem with kexec?
<heat>
yeah erm
<heat>
good question
<geist>
fwiw, the spec says that riscv runs with paging off, also it can run in machine mode, so that makes sense
<geist>
because paging is not implemented at machine mode
<clever>
is the mmu partially implemented in software?
<heat>
no
<geist>
what context is that question in?
<heat>
probably riscv
<clever>
risc-v and machine mode
<heat>
riscv has no mmu in M mode
<clever>
i'm guessing its more like EL3, where they just decided no paging in that mode
<geist>
ah no. there's simply no hardware paging mmu at that level
<heat>
it does have a weird PMP think IIRC
<geist>
except EL3 does have a paging mmu
<geist>
it just doesn't nest with the other levels
<clever>
ah, i must just be mis-remembering
eroux has quit [Ping timeout: 265 seconds]
<geist>
yah i was wrong about that for a long time too until one of the conversations here forced me to re-read it
<clever>
could be that i learned it from you, heh
<clever>
but then again, i also remember talking about just running LK in EL3, and replacing all of the EL1's with EL3
<geist>
right what riscv has is a simple segmentation based protection thing at machine mode, which the paging system nests with
<geist>
used to mark ranges of system off limits, etc
<geist>
clever: yes which is totally doable if i had a concrete reason for doing so
<clever>
ive also filed 2 PR's against LK, very simple changes
demindiro has joined #osdev
<geist>
<bowl of petunias>: oh no not again
<clever>
lol
<clever>
i'm trying out using your overlays more heavily, rather then trying to maintain my improvements in a fork of LK, i just let the overlays overlay LK
<clever>
so i copy a module out of LK and into the overlay, and mess with it there
<clever>
then copy it back into a fresh LK master when its ready to upstream
<geist>
uh okay. i'm not sure that works
<geist>
there be dargons there
<clever>
it hasnt bitten me, yet...
<geist>
but again if you have some deep fork of the code and keep customizing it, it's kinda your doing to do that
<geist>
either you push stuff back to mainine, or you maintain a fork. i can't keep following whatever you changes are
<clever>
yeah
eroux has joined #osdev
<geist>
this is the curse of most LK users: they fork and then never look back. which is why i rarely get changes back
<clever>
and the overlay just makes it easier for me to keep up with master
<geist>
but then i am not responsive to them either, so it's also my doing
<geist>
so <shrug>
<geist>
clever: that's also what git rebase is for
<clever>
i still run into merge conflicts with that
<heat>
you should unfork yourself as much as possible
<geist>
well whatever lets quit spamming this channel with more of this stuf
<heat>
your situation has early android kernel vibes
<zid>
So the solution is to become so important that ignoring upstream doesn't work?
<geist>
there ya go
<geist>
main ssue with LK and taking PRs from folks is LK doesn't have a clear goal. it serves many masters, and in like 80% of the cases a PR someone sends me works for them but breaks something else
<zid>
Nod, that's why you should never write 'kicking off points' I guess :P
<geist>
it also tends to somewhat grind development to a halt on core stuff, since it's generally a compromise here and there
<geist>
and all of the compromises for all of the users should be considered
<zid>
You at least end up with a library of awful solutions for future development!
<clever>
yeah, some of the changes i have in mind are a bit of a major change to the fs core, and only serve a benefit to zfs and open the option of virtual fs's
<clever>
but the BE64SWAP pr, is just a single #define followint the existing pattern, and would have zero impact on people not needing it
<geist>
but it is why i dream of doing Yet Another Straightforward OS sometimes
<heat>
geist, have you considered just doing releases?
<geist>
where the goal is clear: implement a posix kernel. or something
<geist>
not really, but i guess that could at least provide some structure
<heat>
it could give you some headroom to break things
<geist>
and/or i should just worry less about breaking things
<zid>
if they're not bothering to pull/merge upstream, it shouldn't matter so much
<geist>
the hardest thing to deal with is embedded (ie, 32KB machines, cortex-m) and big cpus (x86-64, arm64, SMP) at the same time, in the same codebase
<zid>
that you break them
<geist>
that is a pretty tough set of goals to deal with
<j`ey>
and old cpus (m68k)
<geist>
and i have strong evidence that the big and embedded are being actively used by real stuff
<clever>
the more drastic change i have in mind, is a way to just stuff a `struct fs_mount` at a given path, and skip the mount call and need for a bio
<heat>
how are you forgetting the mighty vax
<geist>
yah to be honest i'm fairly clear that the old stuff like 68k is a second tier. if i have to break it i dont mind that too much
<geist>
i never merged vax into mainline, precisely because ti has some rough breaking edges
<j`ey>
heat: vax isnt supported by LK?
<geist>
especially around things like lack of atomics
<bslsk05>
github.com: GitHub - littlekernel/lk at vax
<j`ey>
neat
<geist>
yah i would need to sit down and figure out the atomic issue properly, but it's working counter to one of my goals to move to C standard atomics, instead of these maintained atomic_* routines
<geist>
but then that's a real ossue with old or more embedded arches, since GCC doesn't implement all of those
<clever>
i need to investigate atomics on the vpu more, i have yet to enable LK SMP on that
<geist>
ie, t's a no brainer for big and modern cpus, but harder for all the arches
<geist>
keep in mind atomics are not just for SMP. atomics also are mandatory in any preemptive situation
<heat>
you can do a cheap emulation of it with irqs_off(); do_op(...); irqs_on();
<clever>
yep
<heat>
for non-SMP that is
<geist>
right, which is basically what i have to stub out on vax
<geist>
it's a slightly different arch than the others, becaue at some point i bottomed out the atomics with compiler builtins
<clever>
i suspect that the VPU entirely lacks proper atomics, but it does have a small number of hw spinlocks
<geist>
which at least most of the arches implement with at least a function call you must fill in
<clever>
so i would need to turn the irq's off, and grab a hw lock, to block the other core
<geist>
but for whatever reason the vax gcc port just bombs out of the compiler, iirc
<geist>
so it's one of those 'ugh, do i really want a special case for this' sort of things
<geist>
which is i think what halted dev at the time on vax to get it merged into mainline
<geist>
but really most of this stuff is just decision paralysis, and having too many open projects at the same time. need to burn down a few before picking up new ones
<geist>
sicne i'm very goo at getting things to 80% and then stopping
<clever>
and i avoid working on project-1, by working on project-10
<clever>
and when i get tired of project-10, i jump to project-2
<geist>
yep.
<geist>
at least 3 of the recent projects have been because of someting your or mawk brought up on #lk
<geist>
and then i'm like 'ugh, that is lame, lemme rewrite that'
<clever>
i'm reminded of a meme, where somebody got hired at some place, rewrote a chunk of code, and then put in his 2 week notice
bauen1 has quit [Ping timeout: 244 seconds]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
<clever>
and now i'm trying to wrap my head around how i might abuse LK to make efi runtime services, lol
<clever>
relocating a running kernel could be tricky, so it might be simpler to have a second stripped down kernel with some relocation data attached to it
<heat>
Bad Idea
<clever>
but irq's and scheduling would be tricky to hide within runtime services
<clever>
was about to ask you, lol
<heat>
lk is a lot fancier than tianocore/UEFI
<heat>
UEFI doesn't have IRQs (except timer IRQs), doesn't have threads
<clever>
somebody else did mention LK would be a good option for uefi, and i can see how it would work well for the boot services
<heat>
that was probably also me
<heat>
I say a lot of things
<clever>
it was in another channel, #libreboot i think
<heat>
hrm
<heat>
anyway, yeah, it would work, but you'd need to ruin lk in the process
<clever>
for the runtime services, yeah
<clever>
boot services seem far more feasible
<heat>
runtime services would be ok if you know what you're doing
<geist>
yah booting it sdirectly as a PE binary that runs post UEFI makes sense. ie, grub or u-boot
<heat>
you'd need to segregate them essentially
<geist>
probably been done on one of the many bootloader forks of LK
<heat>
I've thought of a different idea
<heat>
lk running UEFI as a payload
<heat>
s/UEFI/EDK2/g
<heat>
or maybe the opposite, coreboot running lk as a payload
<clever>
heat: i was thinking more crazy, implement uefi with lk, where lk loads PE.efi files, and provides boot services to it
<heat>
so many damn ideas god damn it why is lk so versatile
<clever>
that reminds me, i looked into grub as a coreboot payload a bit
<heat>
that's not super crazy
<heat>
uefi itself is relatively simple
<clever>
coreboot has its own filesystem (cbfs), and grub has a filesystem driver to mount a block device as a cbfs, but i dont think its in the fs type table
<clever>
so platform code has to then find the cbfs blob, make a block dev, and call that mount routine, i think
<heat>
handles are things, you can attach protocols to the handles, you then look for protocols
<clever>
yeah, ive seen that mentioned as a way of versioning too
<clever>
rather then having multiple symbols for the same func
<heat>
right
<heat>
uefi is super modular and there's no dynamic linking
<clever>
and i have been bitten by mmap vs mmap64, and running the wrong symbol
<heat>
it's the solution to "lets get all these proprietary modules from different vendors, plus an open core into the same firmware image"
<clever>
yeah, the lack of dynamic linking makes module loading far simpler
<clever>
you only need relocation and nothing more
<clever>
which reminds me, getting ld to generate relocation data on a static kernel is a bit tricky
vdamewood has joined #osdev
<clever>
i think the trick ive seen, is to link it as a dynamic library instead, and then objcopy it over?
<heat>
the idea is that protocols are GUIDs (so unique, no collision there), are versioned, and if they weren't, you create a new protocol
<clever>
guid's for gpt type codes are also a major improvement
<clever>
guid all the things!
<heat>
uefi is made entirely out of guids
<heat>
thanks to microsoft probably
<heat>
even the build system is full of guids
<heat>
modules don't have names but rather GUIDs
vinleod has joined #osdev
<heat>
files have fucking guids, protocols have guids
<j`ey>
at least guids dont have guids
<heat>
that's asking for an EFI_GUID_PROTOCOL, with its own EFI_GUID_PROTOCOL_GUID
<clever>
j`ey: but what if there was a service to generate guid's?
<j`ey>
clever: that'd have a guid yes :P
demindiro has quit [Quit: Client closed]
<heat>
j`ey, can I pick your ARM UEFI brain for a bit?
<clever>
part uuid's also solve the problem of finding a partition without having the fs drivers loaded yet
vdamewood has quit [Ping timeout: 264 seconds]
<heat>
clever, it would but unfortunately that's not how it works
<j`ey>
heat: i uh, have mostly forgot everything I learnt..
<heat>
aw shit
<j`ey>
heat: probably better to join #armlinux and ask there
<clever>
heat: hmmm, once you find a partition you want to mount, and have the gpt type-guid of it, how do you find the service that turns a blockdev into an fs? is there a link between the type uuid, and the fs driver uuid?
<j`ey>
ard b is there
<heat>
ooooooh
gog has joined #osdev
<heat>
i mean, my questions are way too firmware for armlinux I think
<heat>
but I'll consider it
<j`ey>
heat: meh it's a low traffic channel, i think it'd be ok
<heat>
clever, ok so the way UEFI drivers work is that they install themselves as drivers (install the EFI_DRIVER_BINDING_PROTOCOL protocol on its imagehandle)
<heat>
you have some drivers (root bus drivers) that don't follow that because they have no device/handle to attach to, as you may imagine
Burgundy has joined #osdev
<clever>
ah, so a fat32 driver might install itself as supporting the efi system partition uuid?, oh, but what about edge cases like apple, where the ESP doesnt have to be fat....
<heat>
those create handles and EFI_DEVICE_PATH_PROTOCOLs on them
<clever>
purpose vs type breaks down there
<heat>
so, when BDS comes around, it connects whatever it wants (usually everything)
<heat>
connecting is the process of sending a handle with an EFI_DEVICE_PATH_PROTOCOL to an EFI_DRIVER_BINDING_PROTOCOL
<heat>
the driver binding protocol has a Start(), Stop(), Supported(). Supported checks if the handle you sent it is supported, usually by querying protocols and, if a filesystem, reading the superblock or whatever
<heat>
so long story short every efi driver tries to drive every handle and needs to test it manually
<heat>
the gpt UUID is irrelevant
<clever>
ah, so multiple drivers (fat, HFS+) could claim the ESP< and then you query the Supported() on each?
<clever>
oh
<clever>
so the type uuid is basically pointless, lol
<heat>
yes
<heat>
you could do something smart in BDS (like fastboot can do)
<clever>
purely rules that the non-efi software sets
<heat>
there's headroom in the UEFI spec for whatever policy you may want in BDS
<clever>
and there is the slightly fuzzy question of how much of this you need to implement to boot a given bootloader+os
<heat>
yes, so fastboot
xenos1984 has quit [Ping timeout: 250 seconds]
<heat>
the really funny path comes in S3
<heat>
there's a cool boot chart I'm trying to find
<clever>
which leads back to one of my crazy plans for the rpi, adding suspend to ram to it
<heat>
but essentially S3 resumes work like a regular boot path but early in PEI you detect it's an S3 resume and execute the boot script
<clever>
ive confirmed how you put an lpddr2 chip into self refresh mode, so you can turn the dram controller off
<heat>
the boot script being something in ACPI NVS that gets written out when suspending
<clever>
ive found a bit in the dram controller that MIGHT do that
<clever>
the hard part then, is testing it, and potentially probing the lpddr2 bus with a scope
<heat>
also ideally you hide the S3 boot script behind an SMM lockbox so you can't dick around with the boot script
<clever>
i have 2 rough plans on that
<clever>
1: just power down every peripheral i can, and run from cache-as-ram until i wake again
<clever>
2: set the ram to self-refresh, and then just kill the cpu entirely (sever power or hold it in reset), detect that on the next boot, an restore
<clever>
i have a sorta-SMM like state, a cpu core seperate from the arm
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
heat_ has joined #osdev
heat has quit [Ping timeout: 250 seconds]
moberg has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.5]
heat_ is now known as heat
<heat>
gog, wtf are you doing
lkurusa has joined #osdev
lkurusa has quit [Client Quit]
<gog>
heat: nothing don't worry about it
<heat>
ok sgtm
<mrvn>
windows supports tghe linux abi so why not just compile for that?
<gog>
because
<heat>
because windows doesn't support the linux abi
<gog>
what about wsl2 heat
<gog>
what about wsl1
<heat>
it's not part of the core windows OS
<heat>
also only covers recent windows 10+
<heat>
also wsl1 is bad and slow, wsl2 is bad and under a hypervisor
<mrvn>
so anything that's still supported
<heat>
well, wsl2 is not bad
<mrvn>
only the last I would accept as argument
<heat>
it's just under a hypervisor and therefore not nearly as optimal or fast as a native solution
<heat>
also any GUI stuff would need to use X, etc
<heat>
all of them are absolutely valid arguments
<gog>
better than using linux
<heat>
"to use my program, please go to the control panel and install this thing called "WSL""
<gog>
yes
<gog>
this is a normal thing that ordinary people can understand
<gog>
unlike linux, which is for dweebs
<heat>
it is
<gog>
and i'm the biggest dweeb here ftr
<heat>
freebsd is for chads
* mrvn
would assume someone that can write a kernel can install WSL
<heat>
why are you assuming this is for kernel-devs?
<gog>
here's a fact: i cannot write a kernel
<gog>
i've tried a lot
<mrvn>
heat: the nature of this channel
<heat>
gog, yes you can
<heat>
Just Do It(r)
<gog>
if that were true don't you think i'd have done it by now
<dh`>
lots of people never get around to things they're perfectly capable of
<heat>
no
<heat>
who the fuck writes a kernel - me after spending way too much time writing a kernel
<mrvn>
gog: you might not e able to write an OS but a kernel? That's mostly for lack of trying.
<gog>
why do you want to encourage me :'(
<heat>
writing a kernel is harder than an OS
<heat>
and this is a fact
<heat>
writing user apps ez, writing kernel code hard
<mrvn>
heat: depends on what the kernel should be able to do. if it needs to run an OS that's hard.
<gog>
i can't even write user apps
<heat>
wrong
<dh`>
meh, kernels are just user apps with a scary rep
<gog>
lol
<gog>
a kernel is just an application that got too arrogant
<sbalmos>
we can't write kernels. we just like to pontificate and act like we know what we're talking about with lots of weird hardware bit-fiddling
<heat>
they're user apps but with signals all over the place and lots of locks and requirements for performance and complexity and you need to build everything from the ground up
<gog>
i'm not even a human being
<gog>
i'm a cat
<heat>
and they're also heavily multithreaded
<dh`>
apps are heavily multithreaded as well since the 90s
<mrvn>
heat: you are demanding far too much
<sbalmos>
there are no threads
<dh`>
also there's no performance requirement for a private experimental kernel
<mrvn>
and nobody needs locks
<mrvn>
what would you lock things from? The is only the kernel
<sbalmos>
yourself
<sbalmos>
the kernel knows you better than you do
<mrvn>
timesharing? A luxury, don't need that.
<sbalmos>
timeshares never worked out anyway. I never got my free meal from the last kernel
<sbalmos>
and that kernel was waaaaaay chatty. took way longer than the 1 hour boot time, very pushy
<geist>
timesharing is for losers that can't afford more cpu cores
<sbalmos>
and multitasking? I'm highly uncooperative. My work is important. The kernel's work isn't.
<mrvn>
every app gets a timeslice. It ends on exit()
<zid>
That's true, given that we no longer use cooperative multitasking
<zid>
we must all be using uncooperative multi tasking
LittleFox has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
frkazoid333 has quit [Remote host closed the connection]
LittleFox has joined #osdev
frkazoid333 has joined #osdev
<mats1>
multitasking is an illusion
<heat>
uefi can execute programs with no multitasking at all, dos style
<heat>
you execute and wait
divine has joined #osdev
Vercas6 has quit [Ping timeout: 258 seconds]
Vercas6 has joined #osdev
frkazoid333 has quit [Ping timeout: 244 seconds]
Ellenor is now known as MelMalik
Burgundy has quit [Remote host closed the connection]
<heat>
geist, I think the new ACPI wakeup thing is for tdx
<heat>
at least, that seems to be the only usage of it in EDK2
nanovad has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
nanovad has joined #osdev
FreeFull has quit [Ping timeout: 264 seconds]
<geist>
hmm, whst is tdx?
<geist>
i was just talking about it at work a minute ago as if it might be a new thing
FreeFull has joined #osdev
<heat>
something new from intel for VMs: trust domain extensions
<j`ey>
like amd sev and arm realms
<heat>
it's designed to protect the vm from the hypervisor
<heat>
no idea how it works though
<heat>
I just know there's some extra fuckery you need to do for SEV/TDX
<geist>
was hoping this was some new thing the predate some sort of new solution for boostrappiung cores
<heat>
there's absolutely no reason this shouldn't work to bootstrap cores
<heat>
APs are woken up multiple times when booting anyway
<heat>
just make the last wake up mwait on the mailbox
<geist>
i guess the main downside is it implies the OS will want to boot the cores (which it probably does) because it actually starts them, even if the OS doesn't need to
<geist>
vs holding them in actual x86ish true stop state
<heat>
but that's already the case
<geist>
ie, prior to sending a STARTUP signal
<heat>
firmware already wakes them up multiple times to perform various tasks
<geist>
sure but it can park them again, perhaps in a deeper state than this mailbox thing
<geist>
honestly what i'd expect if there was a true ACPI based cpu boot thing is for it to be acpi bytecode based
<mjg>
(:
<geist>
which i wouldn't like, but it seems to be The Way
<mjg>
fucking acpi (that's all my input)
<geist>
one reason i think the deeper park is a thing is there's some blerbiage about it in the AMD BKDG about how resouerces are shared on the cpu in a SMT situation
<geist>
and it mentions in general that not exactly everything is competitively shared between threads. there is some static partitioning (i forget what. TLBs?)
<geist>
so there's some incentive to not even start the second half of the core if you're really not using it
<geist>
seems that booting it and holding it in mwait in that case is not exactly the same thing as not having it started, and it's entirely possible a OS would simply choose not to start the SMT pairs for legit reasons
<geist>
*that being said* it may be this static partitioning is atually higher up: at the bios level where the user has selected to disable SMT may be where the static partitios happen, beause then the bios might initialize the cores differently. the BKDG docs are written at that level, including magic MSRs to set this sort of stuff up
<heat>
ok so
<heat>
there's no deeper sleep you can't reach through mwait
<geist>
depends. depends on if not starting the core in the first place is deeper or not
<geist>
seems like being in a state where even the registers aren't retained is deeper than something mwait can get to right? aren't all mwait states at least intrinsically register-saving, so that the cpu can at least run the next instruction?
<geist>
(i honestly dont really know)
<heat>
what happens is APs get woken up, they enter a loop, and start serving requests for MP_SERVICES (so essentially functions you give the protocol, which are then executed on the other cpu)
<heat>
then they mwait, or hlt
<heat>
i believe so
<heat>
CR0, 3 and 4, and all the debug registers seem to be volatile cross-INIT
<bslsk05>
github.com: edk2/MpLib.c at master · tianocore/edk2 · GitHub
<heat>
and yes the code looks horrific and hard to follow, i know
<geist>
hmm, so then that means once you exitbootservices() on the BSP the APs are still sitting around in this loop, but no one will ever tell them to start?
<geist>
but if the OS does a standard STARTUP/INIT thing it'll just whack the APs out of it?
<geist>
i guess that'd be fine, as long as it still quacks like a classic PC
<heat>
yup, seems like it
<heat>
they seem to just always send INIT-SIPI-SIPI
<heat>
but when the OS does it, it gives it another entry point, so it Just Works(tm)
<heat>
and since the APs are all just halted in hlt/mwait, you can unmap it all you like
<heat>
since the next INIT-SIPI-SIPI just sends you to the reset vector
<geist>
interesting. i assumed a INIT-SIPI would just reset the AP back to scratch
<geist>
but i guess that's not how that sausage is made anymore
<heat>
i think it does?
<heat>
INIT-SIPI just sends it back to the bootstrap entrypoint again
<geist>
yeah, but the one you pass it, IIRC
<heat>
yeah
<heat>
when EFI does it, they always pass the same one, keeping some sort of loop
<heat>
when you do it, you break the loop
<geist>
yah, though that does mean that post exit boot services the code for the loop has to at least be in a reservewd memory area, i guess
<geist>
for the APs. or the APs are put back to real sleep
<heat>
yeah im.... confused
<heat>
theoretically, you're just sleeping in a hlt/mwait, you can unmap the code no problem
<geist>
unless you ever accidentally it
<heat>
the issue is SMIs, but I assume those just autohlt back to sleep and no one ever reads the opcode again
<geist>
but i guss for that you'd have to monitor that exact variable
<geist>
for some reason i wanna read Neuromancer again
<geist>
a thing i do every few years. still as good as the first time i read it
<heat>
what's that?
<geist>
The canonical cyberpunk novel. 1984. Coined the phrase cyberspace, tc