klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
* Ermine turns fans on
eau has joined #osdev
<gog> hi heat i'm gog
<gog> i did not oil them no
<gog> they are not in need of oil
Vercas694 has quit [Remote host closed the connection]
Vercas694 has joined #osdev
<heat> hi gog
<heat> i'm slightly fucked and eating churros
<heat> no churros in iceland eh? 2bad5u
<jimbzy> I can think of worst ways to spend an evening.
<moon-child> gog: hmmm
<moon-child> have you tried oiling them?
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<gog> they are not in need of oil
<jimbzy> Dang it. I wired up my LM386 wrong.
<moon-child> yeah but have you tried oiling them?
<gog> i didn't try oiling them no
<jimbzy> What kind of oil would you use?
Left_Turn has quit [Read error: Connection reset by peer]
<gog> the oily kind
* jimbzy facepalms.
<gog> :3
<jimbzy> I was working on my receiver following the schematic and I forget everything was backwards because I'm building it dead bug style...
* jimbzy is not sharp.
<nortti> oh, what kind of receiver are you building?
<jimbzy> 40m regen.
<nortti> neat
<nortti> myself still need to find a place where I can solder together my http://www.4sqrp.com/cricket40.php
<bslsk05> ​www.4sqrp.com: Four State QRP Group
<jimbzy> I love that PCB design.
<jimbzy> Winding toroids is a pain in the neck.
<nortti> yeah, can imagine
<jimbzy> Mine is based on N1BYT's WRB receiver, but I've made a couple of modifications to hopefully spice it up a bit.
<jimbzy> Yeah, you need to get that baby assembled, nortti
<jimbzy> Are you licensed?
<nortti> aye, OH1CAU
<nortti> been doing VHF/UHF stuff
<jimbzy> right on. KF0JCR here.
<jimbzy> Yeah, same. Unfortunately, my U/V rig is FM only, so I don't get to use it much.
<jimbzy> And, I was being serious. What kind of oil would one use on a fan?
<nortti> there's a couple 2m repeaters where I live, so I can just use a baofeng to get on there
<nortti> also sometimes do 2m simplex with another local ham
<jimbzy> Nice. I monitor the ones around here, but it's rare to hear people talking.
antranigv has quit [Ping timeout: 255 seconds]
goliath has quit [Quit: SIGSEGV]
Brain___ has joined #osdev
<gog> jimbzy: depends on the bearing
<gog> but usually some kind of light to medium viscosity machine oil
Brain__ has quit [Ping timeout: 240 seconds]
dutch has quit [Quit: WeeChat 3.8]
Gooberpatrol_66 has quit [Ping timeout: 265 seconds]
<jimbzy> Probably something like SAE-20
<junon> is there a way to get gdb to load a file and purge/reload symbols for the currently running debug session?
<junon> I have replaced cr3 to now reflect a new ELF at boot time and after setting cr3 GDB is showing all the symbols for the original binary
<heat> you can use add-symbol-file to add more symbols from other files
<junon> does it replace the symbols though?
<heat> i don't see why you'd want to replace
<heat> i guess "file" does it for you, but, erm, xy problem?
<junon> No, not xy problem
<junon> I have a boot stage that completely re-maps the memory to use a module as the kernel
<junon> once it jumps to a cr3-set stub, it wipes out (and reclaims) all bootloader memory/structures/etc.
<junon> the kernel in this case requests to load in the same spot as the boot stage does (though it isn't mandatory) and I need to replace the symbols
<heat> use file, file should work
<heat> or reattach gdb with another file
<junon> It's not file, file replaces it
<junon> and reattaching isn't possible, it'll kill qemu
<heat> reattaching is possible
<junon> it's symbol-file -readnow ./path/to/next/exe
<heat> don't you want to replace it?
<junon> then confirm with the prompt
<junon> file kills the debug session
<junon> it doesn't just reload symbols
<heat> huh
<heat> ok
<junon> I thought so too but was getting frustrated that it kept killing the session lol
<junon> and when I'm debugging the trampoline, re-attaching without the instruction pointer flying away was nearly impossible
dutch has joined #osdev
antranigv has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
heat_ has joined #osdev
heat has quit [Ping timeout: 265 seconds]
elastic_dog has quit [Read error: Connection reset by peer]
elastic_dog has joined #osdev
heat_ has quit [Ping timeout: 260 seconds]
Burgundy has quit [Ping timeout: 276 seconds]
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
dtd-123 has joined #osdev
<dtd-123> hello
dtd-123 has quit [Quit: Client closed]
wlemuel has quit [Quit: Ping timeout (120 seconds)]
wlemuel has joined #osdev
pmaz has joined #osdev
gog has quit [Ping timeout: 264 seconds]
pmaz has quit [Ping timeout: 252 seconds]
pmaz has joined #osdev
ZombieChicken has joined #osdev
valshaped has quit [Quit: Gone]
valshaped has joined #osdev
pmaz has quit [Remote host closed the connection]
pmaz has joined #osdev
gnulinuxuser has joined #osdev
antranigv has quit [Ping timeout: 255 seconds]
Jari-- has joined #osdev
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
terrorjack has quit [Client Quit]
terrorjack has joined #osdev
sjs has quit [Quit: sjs]
slidercrank has joined #osdev
sjs has joined #osdev
GeDaMo has joined #osdev
<pmaz> about how long would it take me to make an "operating system" that just displays "hello world" on the screen? would that take hours or months? sorry for the vague question
xenos1984 has quit [Ping timeout: 260 seconds]
<zid> scales with how much you know what you're doing
<zid> from 30 seconds to 3 days
xenos1984 has joined #osdev
xenos1984 has quit [Ping timeout: 260 seconds]
<pmaz> i think 3 days is pretty optimistic for me
<pmaz> things started to get pretty complicated somewhere between babystep tutorial 1 and babystep tutorial 2
xenos1984 has joined #osdev
wlemuel has quit [Ping timeout: 252 seconds]
<Mutabah> For a bootsector, just using BIOS or VGA, it'd be a few hours.
ZombieChicken has quit [Quit: WeeChat 3.8]
<Mutabah> For a 64-bit kernel using a framebuffer, probably a week or so (for a beginner)
<Mutabah> but then, either of those are really an "operation system", and not really a kernel either
<Mutabah> Maybe the smallest I'd call an OS/kernel would be having a working userland with a "print to console" syscall
wlemuel has joined #osdev
<zid> "freestanding program" at best, but yea
<GeDaMo> Forth! :P
<zid> Mutabah: Mine has a 'print zelda to fb' syscall but no print
<Mutabah> What zid said for an OS... for a "kernel" I'd accept loading a fixed program into userland
<zid> (literally that's me)
<Mutabah> for an "OS" it would have to load a replacable program (of disk, or from a module)
<zid> Mutabah: can you make my kernel an OS for me
<Mutabah> pmaz: Does that help answer your question?
<zid> So far it runs zelda stored in a grub module
* Mutabah glares at zid
<zid> literally fixed program into userspace
<Mutabah> Since it's from a module, I'd say it crossed the line between "bare kernel" into "OS" :D
<Mutabah> But this is all personal semantics
<zid> you're just trying to not need to do any work!
<Mutabah> ... have you seen my work? :)
<bslsk05> ​9to5linux.com: QEMU 8.0 Virtualization Software Released with New ARM and RISC-V Features - 9to5Linux
<zid> 8.1 is already out though?
<zid> to be fair it seems the only real change is arm pointer auth info for gdb, and removing python 3.7
<zid> 3.6*
bradd has joined #osdev
epony has quit [Quit: QUIT]
<pmaz> Mutabah: yes it does help, sorry i was away when you were answering
<Mutabah> No biggie.
SerHack has left #osdev [#osdev]
<pmaz> if i wrote it for a bootsector, would it then be hard to expand upon?
<zid> yes
<zid> because now what you have is a bootstrap, which is a completely different project to an OS
<zid> you either rewrite grub, or you rewrite unix, pick one
<zid> but at the same time
<zid> without experience doing at least a tiny bit of the former, you might struggle with the latter
<zid> you just need to throw some hours at this figuring things out
<zid> if you get stuck just move onto some other random approach
<pmaz> alright, thanks
<pmaz> what i really want to do is get access to a pixel framebuffer, is there anything i should know about that?
<zid> grub offers that
<pmaz> in what way?
<zid> I mean, it offers it?
<zid> grub boots you, with an FB already set up
<zid> and tells you the linear address
<moon-child> it's part of the multiboot2 protocol
<moon-child> which grub implements
<pmaz> that sounds a lot easier than building it from scratch
<zid> moon-child: and mb1, which things can actually boot ;)
<moon-child> oh, were there problems with multiboot2?
<zid> many fewer things can actually load it
* moon-child beelined straight for efi and never looked back
<zid> qemu, for one
<moon-child> oh yea, sounds familiar
<moon-child> qemu -kernel or so right
<moon-child> that could be convenient
<zid> you'd need to make a grub disk image
<zid> -kernel can do multiboot1
<pmaz> if i wanted to swap out the grub framebuffer setup for something i wrote, would i have to change much of the rest of the os?
<zid> no, but that's hard btw
<zid> grub has the benefit of being able to talk to the bios trivially (no environment is set up yet etc) and can use your video bios' helper routines
<zid> an OS *should* be using proper drivers, but good luck writing an nvidia driver
<zid> (so most projects don't, for obvious reasons)
<pmaz> when i searched "mb1 grub framebuffer" i didn't get many obvious results, is there documentation or a guide somewhere?
<zid> mb was 'multiboot'
<bslsk05> ​www.gnu.org: Multiboot Specification version 0.6.96
<zid> which was updated into multiboot 2.0 that grub2 supports, but.. that's about it
<zid> other things also support the regular multiboot proto
<zid> importantly for us, qemu
<zid> multiboot is just having a small data structure near the start of what you tell grub to load, and it sees it when it loads you and sets up the environment for you in specific ways
<pmaz> it's probably obvious, but why is it called multiboot?
<zid> it's a boot protocol that does.. various things?
<moon-child> I assumed it was because it could boot multiple different oses
<GeDaMo> Mooltipass!
<moon-child> or multiple different bootloaders
<moon-child> rather than being a protocol specific to a single os and bootloader
invalidopcode has joined #osdev
<pmaz> so it wouldn't actually have to use grub, just a bootloader compliant with multiboot?
<zid> yes, like, as mentioned, qemu can just do it directly via -kernel
<pmaz> oh nice
<pmaz> so the os would have to 1. tell whatever it's running on to set up a framebuffer and 2. get the location of the framebuffer and change it so pixels in the shape of "hello world" appear on the screen
Burgundy has joined #osdev
<pmaz> is that right?
<zid> if you wanted to do pixels, yea
<zid> text mode is much more trivial
<zid> 'don't ask, just write text to 0xb8000'
<pmaz> i think i want to use pixels so i can build on it easier
<pmaz> thanks for all the info
<pmaz> i have to go for now
wlemuel has quit [Ping timeout: 252 seconds]
wlemuel has joined #osdev
elastic_dog has quit [Ping timeout: 240 seconds]
elastic_dog has joined #osdev
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
gildasio2 has quit [Remote host closed the connection]
gildasio2 has joined #osdev
<ddevault> anyone have a simple NS16550 driver hanging around
gog has joined #osdev
<ddevault> also, on ARM, if I have a device tree with no memory cells... how do I determine available general purpose physical memory?
<Mutabah> That seems odd.
<ddevault> oh I'm on EFI, right
<zid> Using EFI instantly explains all insanity as usual
<ddevault> ah, uboot has a relatively simple driver
<ddevault> and the linux driver is not... not as bad as most linux drivers
<Ermine> most are bad?
<ddevault> if I liked linux too much I wouldn't be writing a kernel myself, eh
Jari-- has quit [Remote host closed the connection]
gnulinuxuser has quit [Ping timeout: 260 seconds]
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
bnchs has joined #osdev
nyah has joined #osdev
eroux has joined #osdev
theboringkid has joined #osdev
slidercrank has quit [Ping timeout: 252 seconds]
pmaz has quit [Quit: Konversation terminated!]
bauen1 has quit [Ping timeout: 240 seconds]
goliath has joined #osdev
bauen1 has joined #osdev
dennis95 has joined #osdev
theboringkid has quit [Quit: Bye]
bnchs has quit [Remote host closed the connection]
Left_Turn has joined #osdev
awita has joined #osdev
<sortie> https://pub.sortix.org/sortix/release/volatile/man/man5/autoinstall.conf.5.html ← I'm working on making it easy to automatically install my OS, but with full power of customization
<bslsk05> ​pub.sortix.org: autoinstall.conf(5)
dutch has quit [Quit: WeeChat 3.8]
antranigv has joined #osdev
Burgundy has quit [Ping timeout: 264 seconds]
dutch has joined #osdev
m5zs7k has quit [Ping timeout: 264 seconds]
m5zs7k has joined #osdev
Halofreak1990 has joined #osdev
blockhead has quit []
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
epony has joined #osdev
Brnocrist has quit [Read error: Connection reset by peer]
Vercas694 has quit [Remote host closed the connection]
Vercas694 has joined #osdev
vdamewood has joined #osdev
Arthuria has joined #osdev
Arthuria has quit [Killed (NickServ (GHOST command used by Guest684531))]
Arthuria has joined #osdev
Arthuria has quit [Remote host closed the connection]
Brnocrist has joined #osdev
kof123 has quit [Ping timeout: 268 seconds]
<netbsduser`> xorg today drew its first checkerboard and 'X' cursor on my os
<netbsduser`> and i am now in touching distance (i think) of getting xeyes to run
<vdamewood> (o)(o)
<vdamewood> Too bad I can't make the 'eyes' look up.
<nortti> (°)(°)
<vdamewood> Much better
<vdamewood> Are those degree markers, or romantic ordinal suffixes?
<zid> (>O_o)>
<vdamewood> Google says degree markers
<zid> romantic.. ordinal.. suffix? whaa
<zid> oh romantic as in from rome I guess not smutty
<vdamewood> zid: segundo --> 2º
<zid> heh neat, it's gendered
<zid> that's literally an o, as opposed to a ª
<vdamewood> Yep, so you can also do 2ª
<vdamewood> zid: FWIW, I've heard of these symbols being used in Spanish and Portuguese. Because French doesn't use a/o for gender, they don't use these symbols. I'm not sure about Italian or Romanian.
<zid> This is the same confusion I got when the word digital is used
wootehfoot has joined #osdev
<vdamewood> zid: Confusing fingers and number positions?
<zid> vdamewood: I'm going to fuck you up, digitally
<zid> So either over the internet, or I'm going to poke you to death, you get to live in fear until you find out
<vdamewood> zid: At leat you're not going to fuck me digitally
<FireFly> Gender: [ ] a [ ] o
bgs has joined #osdev
jcmdln has left #osdev [#osdev]
[itchyjunk] has joined #osdev
bauen1 has quit [Ping timeout: 255 seconds]
bauen1 has joined #osdev
kof123 has joined #osdev
wootehfoot has quit [Quit: Leaving]
Brnocrist has quit [Ping timeout: 240 seconds]
wootehfoot has joined #osdev
Brnocrist has joined #osdev
joe9 has joined #osdev
Burgundy has joined #osdev
Brnocrist has quit [Ping timeout: 255 seconds]
heat_ has joined #osdev
heat_ is now known as heat
<heat> hello
<sakasama> vdamewood: ... but that's the best kind. :(
* sakasama hands heat a random pastry.
<heat> you motherfuckers just found out about o/a
<heat> cringºª
<heat> thank you sakasama
<heat> is it poisoned
<sakasama> Not yet.
* sakasama winks.
awita has quit [Ping timeout: 240 seconds]
Brnocrist has joined #osdev
<zid> heat: I have more vindaloo
<zid> are you proud that the goans fixed your cuisine and made it edible
xenos1984 has quit [Ping timeout: 265 seconds]
xenos1984 has joined #osdev
wlemuel has quit [Ping timeout: 252 seconds]
<heat> yes
invalidopcode has quit [Remote host closed the connection]
invalidopcode has joined #osdev
xenos1984 has quit [Ping timeout: 246 seconds]
<heat> my new lenses will take a few days to be ready :( i thought i was going to see well yesterday, but nope
<heat> i've had poor-ish eyesight for 2-3 years now
wlemuel has joined #osdev
<heat> the eyestrain has sucked :(
<GeDaMo> Glasses or contacts?
<heat> glasses
<heat> i find contacts yucky eye shit so
<zid> Have you considered getting new eyes
<heat> yes
<zid> some nice pretty ones out of a young girl, i'm sure you've got the people who can sort it
alexander has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
<bslsk05> ​'Gary Gilmore's Eyes (Radio Edit)' by The Adverts - Topic (00:02:14)
alexander has joined #osdev
xenos1984 has joined #osdev
alturmann1729 has quit [Ping timeout: 255 seconds]
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<heat> i didn't know the shitty HTML docs on arm's website can be downloaded as proper pdfs
<heat> lifechanger
<netbsduser`> this is terribly frustrating, trying to run xeyes, libX11/xcb just waits forever on a socket waiting for a message from the X server which never comes (they do exchange a few messages before this)
<heat> yes I've had similar issues
<heat> probably a broken UNIX sockets impl?
<netbsduser`> it's certainly possible
<netbsduser`> i can't find any immediate issue though
<netbsduser`> someone connects, all goes well, one guy sends, another guy receives, poll/select/read wait for the needful
<netbsduser`> i don't know enough about x11 architecture to comment but it does appear that xeyes is waiting for a message at a time after it's already received data, when i wouldn't expect any further data to arrive since it has not sent any further data to the x server
<netbsduser`> i built with XTHREADS 0 which i wonder whether that might be causing any problems, perhaps the threadless codepaths are bit rotted
<heat> time to get threads? :v
<heat> straying from linux/bsd codepaths sounds like it could go terribly wrong
<netbsduser`> i think it might indeed be time
<netbsduser`> i have kernel threads but don't expose the concept to userland so it hopefully wouldn't be *too* much effort
<heat> haha
<heat> so, erm, it depends on how you want to do things. also if your libc is your own, etc
<heat> writing a pthreads impl is not trivial
<netbsduser`> it's mlibc, which has the remarkable ability to turn a few basic sysdeps into a pthreads imlpementation good enough for managarm to run xorg
<heat> ofc there's also the question if you want to do things a-la linux/BSD(?) with the processes that share a lot of shit
<zid> heat wtf someone put spices in this vindaloo
<heat> thank you goa
<zid> like, it's REALLY hot, even for a vindaloo, wtf
awita has joined #osdev
Arthuria has joined #osdev
wootehfoot has quit [Ping timeout: 255 seconds]
vismie has left #osdev [#osdev]
invalidopcode has quit [Read error: Connection reset by peer]
invalidopcode has joined #osdev
slidercrank has joined #osdev
duthils has quit [Read error: Connection reset by peer]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
vdamewood has joined #osdev
<geist> mmmm vindaloo
<geist> haven't had good vindaloo in a while
<jimbzy> Same, and it's my own fault. I was working at an restaurant a couple of weeks ago and they offered me a free meal, but I had other calls to run. :(
<jimbzy> a, not an
<heat> geist, how do you know what IRQ the generic timer triggers? device tree/soc datasheet?
<geist> heat: arm64 i assume. the 4 different timer vectors will map to 4 in the PPI space
<geist> almost always something like 28-31 or something like that
<geist> technically the device tree describes it, in practice i think it's pretty much the same 4 everywhere
<heat> I think it's "compatible = "arm,armv7-timer";"
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<heat> and i assume the interrupts property then properly describes it
<bslsk05> ​github.com: lk/qemu-virt.h at f1431b81d0318b1c33d9ef01268efb773a93217f · littlekernel/lk · GitHub
<geist> but yeah it's more properly described in the device tree, i dont remember how
<geist> 27-30 i guess. i dont know what tends to map to 31
<heat> yeah but that's cringe because generic kernel images are kooooooool
<geist> sure. if you wanna go that route by all means, just means you gotta parse more device tree
<heat> device trees kind of suck but tis the way
<zid> your one kernel image should support every single arm soc
<geist> LK is torn between the two, because it's also frequently used *as* the bootloader that reads and/or configures the device tree
<geist> so it has to also operate in the mode where it doesn't get to read it
<heat> yeah totally
<zid> even ones with less memory than the size of the kernel, due to how much shit you put in it
<geist> but if i had the time/energy i'd probably do kinda what we did for zircon which is define a new platform called 'generic arm' and then have that one platform read everything from the device tree
<geist> and then you get the best of both worlds, as long as each driver generically gets its config from somewhere else
<geist> ie, no assumption of device tree or static or whatnot outside of the platform layer which is responsible for getting that info from somewhere
<heat> yeah
<heat> i have several drivers that take their info from ACPI and/or device tree, depending on what CONFIG features were enabled
<geist> anywya for the ZBI structure for zircon in the generic timer case i think it basically passes on two pieces of info: which timer to use (virtual, physical, etc) and what IRQ its mapped to
<heat> doesn't make sense to include device tree code for x86_64 builds
<heat> likewise, may not make much sense to include ACPI on smaller arm/riscv boards
<geist> yah same principle applies though: x86 generic platform would get its info from somewhere else (ACPI/etc) and the rest of the code would be pretty agnostic
<geist> totally
<heat> kernel PC is a weird mix of fully static + dynamic (ACPI)
<geist> note that you can decide not to do that and end up smashing arch and platform together. there's even some folks asking at work why we maintain the two layers in zircon since there's now a 1:1 mapping of a single platform (arm generic) to an arch (arch arm)
<geist> but i think the layering still helps, since it helps you logically separate the two
<geist> other folks dont see the need for the distinction
<geist> but that's debatable. that's basically the linux strategy: mash arch and platform together. id ont like it, but it works reasonably well in practice
<zid> that's because linux is ruthlessly practical
<geist> it's very x86 centric, where realistically there always was one platform for x86 arch
<zid> rather than idealistic
<heat> arch and platform aren't really together?
<heat> the difference is that platform bits are spread out across drivers/ and (maybe) arch/
<geist> yah the drivers are out of arch, which is good
<geist> more like the core logic that says 'where does the config come from, how do i initially set up the hardware, etc' tends to live in arch/something
<heat> like the gic stuff is in drivers/irqchip/, and you as the guy making the .config just say CONFIG_IRQCHIP_GICV3=y and dun
<geist> arch/arm/board/... or whatnot
<heat> hmm yes
<geist> the BSDs tend to split the platform and arch like i do in LK, just with different names
<geist> i like to think of arch as more of a leaf node library too, but that's just my pref
<geist> probably because early on when was doing osdev back in the formative years i actually had in my possession a few machines (that i never really wrote code for but planned to) that were basically PCs with non x86s in them
<geist> notably the Pegasos II PPC machine and a Sun Blade 100
<geist> both of those were standard PC south bridges with a PPC and a sparc where the cpu was. so that had taught me that you could make a generic PC platform and arch was not quite dynamic, but at least a build config option
<geist> they had PICs and PITs and 640k memory hole and everything
<heat> woah
<heat> that is something
<heat> all the drawbacks of PC and none of the advantages of non-x86
<zid> Try a PS3 then
<heat> erm, advantages of x86
<zid> It's x86 but isn't a P
<zid> PS4*
<zid> It's x86 but isn't PC
<geist> i think that was more popular in the 2000s before x86 stuff started getting merged into the main x86 SOC. when the x86 was still just sitting on a bus and there was a proper northbridge (cpu bus + memory controller) and a southbridge (everything that was a PC) you could just buy a southbridge chip and build a machine around it
<heat> isn't it still very-PC?
invalidopcode has quit [Read error: Connection reset by peer]
<geist> PS3? no not at all
<jimbzy> Ahh, I was gonna say.
<heat> no, PS4
invalidopcode has joined #osdev
<geist> PS4 is pretty PC
<jimbzy> I thought the ps3 used cell microprocessors.
<geist> yah ps3 was hella not PC
<geist> PS4 still has some wonkyness where as a big PCI device there's this Marvell ARM chip that acts like a secondary IO processor kinda thingy
<geist> i bet the got rid of that nonsense in PS5. haven't looke dat a good architectural teardown of that
<zid> marvell aeoila
<zid> it shows up as every single pci device
<zid> and all the "normal" PC stuff that still wasn't onboard by then isn't there
<jimbzy> One of the worst I've ever heard of is the Atari Jaguar.
<geist> yah basically they're running some RTOS on the marvell cpu, and it shows up on PCI, which is a feature of that particular marvell chip
<zid> like some of the PIT/PIC/etc stuff
<jimbzy> I used to chat with a programmer and he absolutely loathed that console.
<geist> also allows the PS4 main cpu to power off while the PS4 downloads stuff in the background, etc
<zid> so the serial ports are over pci, not io ports, etc
<zid> no superio thingy
<geist> main storage and i think eth are over on the marvell too
<geist> iirc that was one of the reasons it didn't really help to install a SSD on a PS4, the bandwidth was capped by the marvell SOC
<geist> iirc ps4pro fixed some of that design, but i dunno how
<nortti> < jimbzy> I used to chat with a programmer and he absolutely loathed that console. ← the hardware bugs list (https://www.hillsoftware.com/files/atari/jaguar/jag_v8.pdf page 133) is always fun to read
<nortti> "The data of indexed store instructions is not subject to any score-board protection. This means that the data written may not reflect what the programmer intended if the data is the result of a long latency instruction, that is divide or external load."
<jimbzy> That's funky.
<geist> yay manually scheduling instructions to avoid hazards!
<nortti> "Description: The blitter pointer registers, which are written at addresses F0220C and F02230, appear for read at F02204 and F0222C. This error was also present on version 1 silicon.
<nortti> Work-around: Read them at the incorrect addresses."
<jimbzy> I always wanted to try one, though. That, and the Commodore CD32.
<jimbzy> Erm Amiga CD32
<nortti> "If either a JUMP or JR instruction is executed from external memory it is possible for this to align with the memory interface in such a way that the pre-fetch queue ends up holding invalid data. This means that these instructions can not be safely executed out of external memory."
<nortti> "There is a bug in the divider: if it tries to do two consecutive divides without there being one clock cycle of idle between them, then the result of the second divide will be wrong."
<Griwes> "we'll just fix that in software", said every hardware engineer ever
wlemuel has quit [Ping timeout: 240 seconds]
<geist> thats why low level software folks continue to have jerbs!
<zid> Imagine writing a compiler and then unwriting it
<zid> because the software said your compiler is too perfect
rnicholl1 has joined #osdev
wlemuel has joined #osdev
dennis95 has quit [Quit: Leaving]
<heat> geist, qemu tcg doesn't speculate does it? does it even have a tlb?
<heat> well, speculate beyond what the native CPU does
<heat> like if I map something on arm64 and don't dsb + isb
<heat> heck, i don't even do proper break-before-make atm
<moon-child> I wonder if there is a good strategy for emulating tso arches on non-tso arches
<moon-child> taking advantage of the fact that most data is only ever touched by one thread. Maybe you make exclusive accesses way cheaper but concurrent accesses way more expensive
<zid> make shm page fault
<zid> deal with it there
<moon-child> yeah something like that. I mean, not that, but something like that
<moon-child> (mainly because threads)
bauen1 has quit [Ping timeout: 248 seconds]
bauen1 has joined #osdev
dude12312414 has joined #osdev
awita has quit [Ping timeout: 252 seconds]
<geist> heat: i think it has a TLB. the page translation definiteily doesn't run on every access
<geist> unclear exactly how big it is and/or how much you're likely to hit a TLB mis-management issue
<geist> but it stands to reason you absolutely could
<geist> as far as speculation, naw
<geist> oh reminds me, qemu 8.0 was release
<geist> as well as gcc 13.1
<geist> kinda recently both
<geist> qemu i didn't catch because i think they moved to a new git repo, and the github mirror hasn't been updated in some time
<geist> (qemu moved over to gitlab it seems)
rnicholl1 has quit [Quit: My laptop has gone to sleep.]
<heat> oh gcc 13 is out?
<heat> "GCC now supports AMD CPUs based on the znver4 core via -march=znver4. The switch makes GCC consider using 512 bit vectors when auto-vectorizing."
<zid> no?
<heat> hahaha
<zid> they build the changelog as they go, but afaik they have not cut a release have they?
<geist> oh oh. sorry not out yet
<geist> frozen for release. sorry
<heat> thank you geist now im sad
<geist> <pat pat>
<zid> you can build it heat, we believe in you
<geist> but qemu 8!
<zid> If make's jobserver is active, parallel LTO WPA streaming communicates with it and thus avoids system overcommitting.
<heat> https://www.youtube.com/watch?v=-50NdPawLVY me when new toolchain is out
<bslsk05> ​'Crab Rave 10 Hours' by 10HoursMovies (10:00:00)
<geist> i went ahead and stuck my foot in it and asked on the qemu IRC channel why github isn't updated anymore
<geist> i see no mention anywhere about it on the mailing lists
<geist> i wouldn't care so much excep the github repo lists itself as the official mirror, etc
bgs has quit [Remote host closed the connection]
<heat> because microsoft is poopy and smell and m$
<geist> sure, but if so at least replace the old repo with a note saying go to the new one
<moon-child> 'Previously we use __bfloat16 which is typedef of short. Now we introduced real __bf16 type to x86 psABI' they broke abi? D:
<heat> same alignment and same size
<heat> just a more proper type
<heat> ok so RISCV extension names fucking SUCK
<moon-child> it doesn't go in an xmm register rather than a gpr?
<zid> that'd kinda blow surely
<heat> probably not
<heat> find out what any of these mean challenge: https://i.imgur.com/nbMvz3g.png
<zid> it's for the weird neural net 16 bit float nonsense, you'd wanna use intrinsics on arrays of them
<zid> but packing them into memory and regs etc probably wants short
<moon-child> well sure, but if you _were_ passing just one around
<moon-child> you'd want it in an xmm reg rather than a gpr, the ops for them come from the vector isa
<heat> bf16 are passed in sse regs yes
<nortti> heat: Zksh, for hardware accelerated korn shell
<geist> heat: at least they're unique. easy to search for because those combinations of letters never show up
slidercrank has quit [Ping timeout: 248 seconds]
<heat> Zicbop!
<zid> are we sure they're not youtube uris
<heat> no and at this point I'm afraid to ask
<moon-child> oh no not abi break, because they changed the name
<geist> everyone go to the Zicbop
<moon-child> so if you had __bfloat16 f(__bfloat16 x), it'll still work the same
<heat> Zksed
<bslsk05> ​'Ramones - Blitzkrieg Bop (Official Music Video)' by RHINO (00:01:56)
<heat> i'm seriously concerned about the future of riscv
<moon-child> Zombocom best riscv extension
<geist> cant not thing that every time is see something that ends with 'bop'
<heat> omg Zombocom when??
<zid> mmmbop.swf is what I think of
<zid> but I am ancient and memey
<geist> moon-child: haha omg if that doesn't exist i'll have to work on making that happen
<geist> oooh yeah mmbop
<geist> i hadforgotten that
goliath has quit [Quit: SIGSEGV]
<geist> heat: but in all seriousness, i'd keep a list to a set of urls and https://wiki.riscv.org/display/HOME/Recently+Ratified+Extensions is very useful
<bslsk05> ​wiki.riscv.org: Recently Ratified Extensions - Home - RISC-V International
<geist> i keep a local cache of most of those docs for reference
<heat> they're opengling riscv
<heat> this seriously sucks
xenos1984 has quit [Read error: Connection reset by peer]
<nortti> how much do people include optimized routines for stuff outside of the G set?
<heat> but the extension naming sucks even harder
<heat> what's the G set?
<nortti> IAMFD
<geist> nortti: i think this is an open question, and one that will change over time
<heat> atm, no one
<geist> but also there's an attempt to standardize that with the RVA* extension list
<nortti> oh apparently a bit more
<heat> although I think linux has optimized strops in the kernel
<nortti> "Shorthand for the IMAFDZicsr_Zifencei base and extensions"
<bslsk05> ​github.com: riscv-profiles/profiles.adoc at main · riscv/riscv-profiles · GitHub
<geist> basically currently we're at RVA20 for the most part. which is not much more than rvXgc
<geist> also keep n mind there are dfferent sets of profiles for embedded vs supervisor vs user
<heat> Zicsr, because ofc having CSR instructions was too much
<heat> it must be a whole separate extension, thou shalt not have system registers!
<geist> well, Zicsr exists as a separate thing because some deeply embedded machiens dont necessarily need CSR
<geist> so they pulled it out of the base requirements
<geist> yes, that's precisely why.
<geist> there's logic to this
<heat> the logic is deeply broken IMO
<geist> disagree
<heat> you either design something for deeply embedded or you design something more general purpose
<geist> the problem is in general trying to encompass all teh way to deeply embedded up through 64bit big
<heat> not stupid amounts of fragmentation
<geist> it gets complicated
<geist> that's what the profiles are trying to solve: split into N types, where N is like 2 and then define standard extensions
<geist> so that everyone doesn't just instantly fragment
<geist> and i think that makes a lot of sense
<geist> as time goes on you can describe what the cpu supports by listing the profile + any additional extensions
<geist> presumably compilers will start taking profile nomenclature ont he command line too
<heat> honestly, i don't know
<heat> a single feature can get like 3 separate extensions, each named with wild keyboard mashing
<geist> well, no
<geist> if so that is someone misbehaving and not doing the right thing
<geist> will that happen? maybe. is that correct? no
<geist> the obvious current issue being the nonstandard vector stuff that the Thead cores have/had
<geist> that was bad. but they're at least putting their nonstandard extensions under the Xthead... space, whcih is correct
<heat> that has already happened
<heat> RISC-V Cryptography Extensions Volume I: Scalar & Entropy Source InstructionsNovember 2021Zbkb, Zbkc, Zbkx, Zknd, Zkne, Zknh, Zksed, Zksh, Zkn, Zks, Zkt, Zk, Zkr
<geist> yes?
<heat> stupid amounts of tiny little options for tiny little features, each randomly named
<heat> exactly what I was complaining about
<geist> it's not random
<geist> you just have tos pend liek 5 minutes looking at the docs to see what they mean
<heat> i imagine its not, but it 100% seems like it
<geist> then you're just being lazy and whining
<heat> versus, i dunno, just calling it "crypto"
<heat> yes, that's exactly what I'm being, I 100% admit it
<geist> i mean yeah it does look like extension soup, but then so does ARM64 and x86 would look exactly the same if you put a name to every feature
<geist> effectively it is. call out every bit in CPUID on a list and you'll say the same thing
<geist> like `flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce
<geist> topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic
<geist> v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm`
<geist> OMG what is that!
<mjg> /kick geist no spam
<geist> stupid client for splitting the line
<geist> but really the problem i have with RV is the fact that there's no way to detect this feature set. it relies on the string being found in device tree, etc and parsed
<mjg> geist: irc has a line limit, i don't rmeember what it is. chances are the message would have been turncated otherwise
<geist> so as a result *everything* needs a name, because you have to be able to discover it at run time by parsing that string
<geist> technically it's more forward thinking than bitmaps in a register i guess, because new extensions can appear and you can ignore them
<geist> and it can grow arbitrarily large
<geist> and you avoid the mess that is layers of cpuid
<geist> but still. it has it's own annoyance
xenos1984 has joined #osdev
<epony> I sort my flags by year of addition to the arch..
<moon-child> 512 chars i think?
<moon-child> or, no, 510 for some reason
<moon-child> including the entire command, not just the content of the message
Halofreak1990 has quit [Quit: Konversation terminated!]
<geist> built qemu 8 and ran some stuff on it. seems to work, not that i expected it not to
<moon-child> why does having bitmaps in a register prevent you from ignoring extensions? I mean, some bits are reserved for future stuff, but that's fine, and you just don't look at those bits
<moon-child> one thing I wonder about is
<moon-child> whenever an extension is added that adds some new core-local state, the kernel needs to know about it, in order to save/restore that state per thread, so userspace can't just start using it right away
<geist> yeah i know, but eventually you run out of registers so you have to add more, etc
<moon-child> why not just have the core say the size of all the core-local state dynamically, and handle saving/restoring on its own?
<moon-child> I guess one issue is the format isn't portable, so you can't easily do stuff like criu
<geist> that's what x86 eventually arrived at after 4 or 5 variants of it
<geist> (xsave, etc)
<geist> but of course you need to save all the previous ones
<moon-child> but that's not dynamically sized, is it?
<geist> it is
<geist> you have to do this dance of querying it to figure out the size, add extensions, etc
<geist> it's a PITA but relatively clean. the hard part is then writing code to go inspect the contents
<geist> since it's dynamically sized
<moon-child> it looks like the format is basically tied down
<moon-child> and the kernel has to say what stuff it wants to save/restore
<geist> at least in the case of xsave it is tied down in the sense that there's a mechanism to discover where the subsections of the save state starts/ends
<geist> right
<moon-child> I'm saying it should just give you an opaque size, and the format is completely unspecified
<geist> that's not usable, because softwaere frequently *does* want to inspect the contents
<moon-child> if the cpu wants to add new registers later on, userspace software has to know about them if it wants ot use them, but the kernel should work unmodified
<geist> it, reading the state of the vector state you saved
<geist> alas it doesn't work that way in practice
<heat> gcc 13 is coming out on the 26th
<heat> we're almost there fellas
<heat> we're this close to avx512 auto vectorization
<moon-child> don't you have that already
<moon-child> also autovec meh
<geist> i dont have any machines with avx512 so it hasn't really excited me much
<mrvn> moon-child: You mean like the way x86 saves FPU state?
<mrvn> Could one say that PUSHA wasn't one of those too?
bauen1 has quit [Ping timeout: 265 seconds]
<mrvn> s/wasn't/was/
<moon-child> mrvn: no because both of those are fully defined architecturally
<mrvn> heat: is that auto vectorization as in you specify the size of the vector you have and loop and it works in the max chunk size it can handle?
DynamiteDan has quit [Excess Flood]
<moon-child> if you added a general-purpose register, you wouldn't be able to change pusha after the fact to push that register too
bauen1 has joined #osdev
<mrvn> moon-child: sure you could. You would just have to have a register somewhere declaring the size PUSHA needs so kernels can reserve enough space.
<heat> i hate device trees
DynamiteDan has joined #osdev
<mrvn> moon-child: and all previous registers should end up in the same location as before.
<moon-child> mrvn: you could make something like that
<moon-child> but it's not what pusha is
<epony> arm likes these
<mrvn> push already does one thing for 16bit and another for 32bit
<epony> seems to be adopting that from Windows device driver tree
<moon-child> sure
<moon-child> lots of things are different
<geist> it's all sort of moot. neither arm nor riscv will ever add an instruction that does a huge pile of undefined microcoded work
<epony> same mistakes and failures
<geist> that is Not The Way
<moon-child> mrvn: but pusha does the same thing for sse and avx
<mrvn> as in nothing
<heat> aktushally, i get it now. i love device trees
<epony> no, you hate tables
<heat> geist, have you seen a need for "proper" irqchip support or nah?
<mrvn> Did x86 task gates save the FPU state when the fpu is enabled?
<heat> i think the current scheme I have (similar to yours) with platform_unmask_irq, etc doesn't really model the hardware properly
<heat> in some circumstances, that is
<geist> heat: what do you mean irqchip that is?
<geist> is that linux style nomenclature?
<heat> yes-ish, also device-tree style
<heat> irq controller, really
<geist> so can you rephrase the question?
<geist> sorry there's just a lot of implied something in the way you were asking it, and i can't tell what yuo mean precisely
<heat> have you seen a need to properly model interrupt controllers in-kernel such that they make more topological sense instead of having an automagical platform_unmask/mask_irq
<geist> topological as in heirarchial?
<heat> yes
<geist> or do you generally mean 'pluggable with a device model'
<geist> ah. well, note that the platform* strategy doesn't not imply the heirarchial model
<geist> it just becomes the platforms problem to sort that out
<heat> for instance, in theory you can have two or more interrupt controllers in a system
<geist> ie, question is does a *device driver* need to know about the way irq chips are wired up
awita has joined #osdev
<geist> if not, then the api should be flat. but the sausage is made behind the api
<klange> please do not make sausage with a computer
<heat> the device driver? probably not. but the PCI driver, etc? maybe
<geist> could be called something else other than platform, but something like irq_... and then there's some subsystem that sorts out the heirarchy (or not)
<geist> perhaps in that model most drivers use the simple function that just takes an ordinal and does the job, and more complicated ones can reach in and grab a handle to the IRQ controller. probably still abstract, but.. you knwo
<geist> LK is most certainly not a good model for any of this. it's far too simple for large systems
<heat> yes
<heat> I wanted to at least introduce the concept of an "irqchip" I could expose to userspace
<heat> particularly because of irq rebalancing
<heat> and pinning
* geist nods
awita has quit [Remote host closed the connection]
<heat> like, lets imagine a large system with 2 IO APICs. each IO APIC would have a single, internal irqchip representation. things like pci_get_irqn(device) would walk the firmware data (in the x86 PC case, MADT data), which would map INTA-INTD into a GSI, and then from the GSI you would be able to get the irqchip responsible for that
<heat> i think this largely makes sense
<heat> although I don't have enough experience to know if this maps mostly everywhere. for instance, I don't think device tree systems would enjoy the GSI idea
<heat> as in those systems, you'd just have a different interrupt-parent. what's a GSI? who knows
<geist> yeah though i think in the GSI case it's just flat outsode of PCs
<geist> thats' just some layer of translation that you can hopefully hide away
<geist> AFAIK pretty much no other modern arch has any sort of nonsense like that. external irq numbers are just flat
<mrvn> or model it after the device tree.
<mrvn> the device tree tells the driver where to get it interrupt from
Left_Turn has quit [Read error: Connection reset by peer]
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
rnicholl1 has joined #osdev
rnicholl1 has quit [Client Quit]
Jari-- has joined #osdev
nyah has quit [Quit: leaving]
<heat> geist, 1) does inner/outer shareable, etc matter for qemu tcg? 2) what do I need to set for uncached device mem?
wlemuel has quit [Ping timeout: 246 seconds]
wlemuel has joined #osdev
terrorjack has joined #osdev
<Griwes> > the lack of Liedtke-style masochism required for micro-optimising every bit of code
<Griwes> presented without context
<Griwes> are there any (actual or research) OS projects that attempt to allow for priority delegation through *asynchronous* IPC? I'm at a point where I'm wondering if I want synchronous APIs in the IPC thing most userspace ought to be using, and "can I do delegation without them" is one of the major questions I'm trying to wrap my head around, and google results aren't particularly helpful (the other major question is "are direct context switches necessary
<Griwes> for good perf", but that one seems both more nebulous and also more of a "try it and see" question)
<heat> ok i had a bug in my dt parsing code
<heat> but I still need to figure out mmu attributes for uncached stuff out