channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched
#osdev2 = #osdev @ Libera from 23may2021 to present
#osdev @ OPN/FreeNode from 3apr2001 to 23may2021
all other channels are on OPN/FreeNode from 2004 to present
http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=11&d=20
04:24:00 <moon-child> https://twitter.com/iquilezles/status/1263316059743940608 TIL people are making uefi demos
04:24:00 <bslsk05> twitter: <iquilezles> So, on the bootloader experiment from a couple of days ago, I changed the approach to EFI, which is the only thing my laptop seems to implement (no more BIOS, I'll miss you).   This is a 4 kilobyte (uncompressed) boot loader running at 1080p, RGBA8. Pretty neat! https://video.twimg.com/ext_tw_video/1263306723407745025/pu/vid/1280x720/ZoSr6vZKa3Xq37qD.mp4?tag=10
04:33:00 <geist> hmm, implement it in uefi bytecode for extra credit
04:33:00 <geist> might actually compress better
04:33:00 <geist> though that begs the question: can you run a straight UEFI app in bytecode, or is that reserved only for drivers or whatnot?
06:11:00 <geist> also if so, does that mean you could hypothetically write an arch independent bootloader...
09:41:00 <geist> noice, finally got around to writing the pci bus enumerator stuff that walks things and puts it in a tree
09:41:00 <geist> https://www.irccloud.com/pastebin/5qEDqtkC/
09:41:00 <bslsk05> IRCCloud pastebin | Raw link: https://irccloud.com/pastebin/raw/5qEDqtkC
09:41:00 <geist> etc
09:42:00 <geist> need to feed it more complicated things, and add code to actually configure it if it isn't already (assign bars, etc)
09:42:00 <geist> but the basics is to get it into a tree like structure of objects so can manipulate it
09:44:00 <zid> yea I don't store the tree, but that's neat
09:45:00 <zid> I will probably eventually have a need to
09:45:00 <zid> but for now I just broadcast the device/vendor IDs of things I find
09:45:00 <geist> yah was debating but since i generally deal with ARM and RISCV most of the time, and qemu doesn't initialize those busses on bootup
09:45:00 <geist> i'm going to pretty quickly need to add code to actually assign BARs and whatnot
09:46:00 <zid> you'll need to write lspci at some point
09:46:00 <geist> and for that it probably helsp to have a tree like structure so you can walk up and down the tree and compute the envelope of addresses, etc
09:46:00 <zid> I really wanna get my shit to the point where I can write this webserver
09:46:00 <zid> Then I can have lots of fun making display windows
09:46:00 <geist> yah i'm just tyring to get this shit to the point where i can write some more PCI drivers, really
09:46:00 <zid> like lspci.cgi.bin etc
09:47:00 <zid> and a memory map viewer, etc
09:47:00 <geist> like e1000, xhci. been meaning to do those so i know what i'm talking about
09:47:00 <zid> dumping that stuff to the console is no good, you really want visualizations
09:47:00 <geist> been mostly fiddling with non pci based things like virtio-mmu
09:47:00 <geist> virtio-mmio that is
09:47:00 <geist> which is fine for ARM and riscv, but doesn't work on x86 PC
09:48:00 <geist> plus always kinda wanted to *actually* write an ahci or nvme or e1000 driver just to actually know what i'm talking about
09:48:00 <geist> and those all work on non x86 too, so kills a bunch of birbs
09:49:00 <zid> I have e1000 but it's pretty janko in terms of interface
09:49:00 <zid> cus my network stack is still just a few if()s hardcoded against the e1000 :p
09:49:00 <geist> noice
09:49:00 <geist> yah mostly that with virtio-net on this end
09:50:00 <geist> like stack is abstract fromthe nic, but only in that the virtio-net driver populates a send/receive function ptr and then stack goes to down
09:50:00 <geist> funny how my old stac from 20 something years ago in newos was more robust there
09:50:00 <zid> yea I don't have the ptrs
09:50:00 <zid> mainly because I don't have a decent enough allocator to have things like.. linked lists or stacks
09:50:00 <geist> oh get that going so you unblock yourself
09:51:00 <zid> I've just been avoiding it rather than writing it
09:51:00 <moon-child> I did a really shitty allocator in like a couple pages of code
09:51:00 <geist> do it!
09:51:00 <zid> who needs dynamtic allocations when you can use statics!
09:51:00 <geist> yah i was actually using legit new a while ago
09:51:00 <geist> i figure a machine with pci is probably big enough to handle some heap allocations
09:51:00 <geist> it aint no embedded device
09:51:00 <moon-child> linked list of variable-sized buffers, k&r style < linked list of blocks in 0.5k increments under 4k < freelist every 16-byte increment under 0.5k
09:51:00 <moon-child> ezpz
09:52:00 <zid> I just didn't wanna think about how to initialize it :p
09:53:00 <geist> anyway, fun to just sit down and do some hackery on a concrete thing like parsing pci
09:54:00 <geist> also managed to actually get into The Zone there for a couple hours
09:54:00 <geist> so far and few between these days. got some lo-fi girl going on the TV and just hack away
09:54:00 <geist> she's still studying
09:56:00 <kazinsal> ever vigilant
09:57:00 <geist> it's either lo-fi girl or Kid A
09:58:00 <j`ey> geist: what machine is this?
09:58:00 <geist> but Kid A is only like 45 minutes long
09:58:00 <geist> j`ey: qemu, was piddling with trying to configure it with some pci bridges or whatnot
09:58:00 <j`ey> arm? x86?
09:58:00 <geist> by default it tends to toss everyone on bus 0 which isn't that interesting
09:58:00 <geist> j`ey: yes.
09:58:00 <j`ey> hah
09:59:00 <geist> i wrote bus accessors for 3 methods: bios32, classic PC x86 type 1, and ecam
09:59:00 <geist> and obviously only the last one is supported on arm and riscv
10:00:00 <geist> that's why i was piddling around with ACPI and device tree the other day, need to read the ECAM location out of those
10:04:00 <zid> vmware's got a decent spread of shit on different busses
10:04:00 <klange> geist: vmware sti-
10:04:00 <klange> what zid said
10:04:00 <geist> yeah should try that next
10:04:00 <kazinsal> yeah, ESXi by default spits out an enormous number of bridges
10:05:00 <geist> if you screw around you can more or less configure what you want on qemu but it's a pain
10:05:00 <geist> you have to explicitly call otu root busses and whatnot and manually assign devices
10:05:00 <kazinsal> https://www.irccloud.com/pastebin/4UDQxsbw/
10:05:00 <bslsk05> IRCCloud pastebin | Raw link: https://irccloud.com/pastebin/raw/4UDQxsbw
10:05:00 <kazinsal> basic output on my test VM
10:05:00 <zid> hmm weird, it uses bus 0 and bus 2
10:06:00 <kazinsal> most interesting imo is each of the e1000es being on separate buses
10:06:00 <zid> 0:1 -> 1:0 -> nothing, 0:11 -> 2:00 -> ethernet / usb / sound
10:07:00 <zid> I wonder if 1:0 is a pci-e to pci bus
10:07:00 <geist> a lot of that depends on how much they follow the pcie spec. i think in general with pcie (Vs pci) you're supposed to create a bridge with a single device behind each one
10:07:00 <zid> ah yes, it is
10:07:00 <kazinsal> yeah
10:07:00 <geist> but i think bus 0 is somewhat grandfathered in to having 'built in' devices
10:07:00 <geist> including of course root port bridges themselves
10:07:00 <zid> so device 1 on bus 0 is the PCI bus, device 11 on bus 0 is the pci-e 'stuff you added in config'
10:08:00 <geist> if you dig around in something like the AMD BKDG you see that you can configure the 24 lanes of the SOC in a bunch of ways, and i thik the worst case scenario is something like 8 root ports of 4x lanes a piece
10:08:00 <geist> so there's a root port slot reserved for each, though the bios probably configures it elsewhere, so those devices end up looking dark on a real machine
10:09:00 <kazinsal> 15AD:07A0 is the VMware PCIe root ports
10:09:00 <geist> but then you can pretty much see how the south bridge chip will chew up a 4x lane, add their own bridge and then build secondary busses
10:09:00 <geist> kinda neat that it basically lines up with reality
10:09:00 <kazinsal> iirc the number of root ports it spawns is in the vmx, one sec
10:10:00 <klange> sure hope you like pcie https://klange.dev/s/Screenshot%20from%202021-11-20%2019-10-08.png
10:10:00 <klange> that
10:10:00 <klange> is the wrong screenshot
10:10:00 <geist> what is big clive doing today
10:11:00 <klange> thank you so much gnome screenshot tool
10:11:00 <geist> haha was wondering how that had ro do with it
10:11:00 <kazinsal> terrible, terrible things
10:11:00 <geist> i mean, i'm sure big clive could definitely do terrible things to pcie
10:11:00 <klange> gdi it did it again
10:12:00 <klange> aw screw it, enjoy this https://klange.dev/s/Screenshot%20from%202021-11-20%2019-11-41.png
10:12:00 <geist> ah yeah i remember that. vmware loves it some root ports
10:13:00 <kazinsal> https://www.irccloud.com/pastebin/il0ARr0w/
10:13:00 <bslsk05> IRCCloud pastebin | Raw link: https://irccloud.com/pastebin/raw/il0ARr0w
10:13:00 <geist> iirc its ACPI also calls out something like 32 com ports, with 31 of them disabled. that caused some trouble with fuchsia at some point
10:15:00 <kazinsal> I should look at the vmx file for a Windows VM to see if it does something different with the PCI config
10:16:00 <kazinsal> wonder if VMware just makes up different "base configurations" for different expected guest OSes
10:16:00 <geist> i wouldn't be surprised
10:16:00 <klange> it does
10:16:00 <geist> like it might not matter to linux, but probably matters to windows
10:16:00 <kazinsal> oh yeah, those PCI slot numbers are way different
10:16:00 <klange> you get different NICs between the "Other, 32-bit" and "Other, 64-bit" options
10:16:00 <geist> one off the top of my head that i know is to this day windows still cares about socket vs cores on a socket
10:17:00 <geist> like, come on seriously?
10:17:00 <kazinsal> licensing thing, yeah
10:17:00 <geist> i have a windows 10 qemu instance that i had to explicitly tweak for that. <eyes roll>
10:17:00 <kazinsal> oracle DB cares about it too
10:18:00 <geist> yah just figured that sort of thing is so 90s
10:18:00 <geist> but alas.
10:18:00 <klange> ooooh I see what happened, vmware you little shit...
10:19:00 <klange> If you click in the guest without capture, it does something to make it not actually focus the window
10:19:00 <kazinsal> should also be noted I'm working several versions of ESXi behind so I'd bet it does something different if you specify Server 2022 as the OS instead of "Server 2016 or newer"
10:21:00 <klange> oh snap, I don't even need to click, it's just taking input for the guest whenever the cursor is over it, but not to its window in general, and then leaving it restores focus to whatever was focused previously
10:21:00 <klange> and clicking the guest doesn't focus the vmware window (but clicking its menubar or decorations does)
10:22:00 <klange> I'm still on X here, and I literally did wm/compositor stuff for ages, and I have no idea what they're doing here or _why_, but, ew
10:23:00 <geist> one day i thought it might be interesting to actually try to grok precisely what goes on in a modern X + compositor + wm thing
10:23:00 <klange> so between qemu, virtualbox, and vmware, they all do input _very_ differently
10:23:00 <geist> like, which code does what
10:23:00 <geist> but... i dunno
10:23:00 <klange> demons
10:23:00 <klange> demons and GLX_EXT_texture_from_pixmap
10:24:00 <geist> i have a basic understanding of the old school X stuff, but how the compositor fits into it i dont know
10:25:00 <klange> so there's the composite extension, which essentially has X itself stop rendering to the screen directly and lets a client application do it instead
10:26:00 <klange> that extension takes care of the basic "render to a pixmap for each window" thing that is the fundamental operation of compositing vs. the traditional pen-and-primitives approach that X still supports
10:26:00 <klange> and if you just want to do 2d stuff, that's fine and you can throw the results at, like, Cairo or your bitblitting.
10:26:00 <geist> hmmm, makes sense
10:27:00 <klange> I have no idea what's state of the art and I last was into this stuff a decade ago, but the thing that allowed for OpenGL to come into the picture was GLX_EXT_texture_from_pixmap.
10:27:00 <geist> figured it fakes out the app at that level
10:27:00 <klange> So you can get a GL texture out of the pixmaps representing the windows and now you can put them on a cube.
10:27:00 <klange> Though X is still managing the idea of where a window is and it only understands aligned rectangles
10:28:00 <gog> mew
10:28:00 <klange> So while we can put the windows, visually, on a cube, if you want to interact with them like they were on a cube... tough shit
10:28:00 <klange> A bunch of hacks were tried back in the late oughties to get around that, but in the end no one cared enough and Wayland was right around the corner
10:31:00 <klange> With Wayland, since it's just a protocol, you can do whatever the hell you want as a compositor because you're also the input manager. If you want to map windows onto walls in a virtual room and have the mouse by a VR lightsaber, you can do that because you decide where clicks go, or that a click is happening at all
10:32:00 <klange> another important X extension was the damage extension
10:33:00 <klange> the more common term for that is dirty rects, but "XDamage" was such a fundamental thing to Compiz not effectively sitting around constantly rendering the whole screen [or screens] at full resolution and 60fps and burning a whole in your GPU... that I still use the term "damage" when I talk about dirty rects.
10:34:00 <klange> [though the term I use in yutani is just 'flip', which is... also kind of a minsomer, but it does the thing]
10:34:00 <geist> makes sense
10:35:00 <klange> thinking back to all the different ways we tried to cheat at input redirection in X...
10:36:00 <klange> The most hilarious approach in retrospect was _to use VNC instead_.
10:38:00 <klange> For Yutani, I support transformed input mapping, though just for rotation at the moment. It's my one neat parlor trick. Shame I don't have a good drawing app right now...
13:12:00 <ksp> imagine not using IRC from some random OS made in Lisp
13:16:00 <ksp> lol
13:16:00 <ksp> it even has a doom fork
15:54:00 <froggey> "some random OS" hrpmh
18:48:00 <heat> geist, you can also run EFI apps on EBC
18:48:00 <heat> you just need a $900 compiler from intel to actually compile them
18:49:00 <zid> EBC?
18:49:00 <heat> also, SIZEOFS ARE FUCKING DYNAMIC CALLS
18:49:00 <heat> zid, efi bytecode
18:49:00 <zid> ah
18:49:00 <heat> sizeof(UINTN) and sizeof(VOID *) can't be resolved at compile time, etc
18:49:00 <zid> sizeof is an operator btw :P
18:49:00 <zid> oh you mean in efi lang?
18:49:00 <heat> so it's actually done dynamically
18:50:00 <heat> what efi lang?
18:50:00 <zid> EBC?
18:50:00 <zid> cus in C it's definitely an operator
18:50:00 <heat> efi bytecode is compiled from C using the aforementioned $900 intel compiler
18:50:00 <heat> there's no special language
18:53:00 <heat> structure sizes can also change
18:53:00 <heat> god this is cursed
18:53:00 <heat> thank fuck this is dead
18:54:00 <HeTo> if sizeof isn't a constant expression, it's not C, but sounds like it's a C-like language
18:54:00 <zid> sounds like.. completely normal program to me
18:54:00 <zid> HeTo: VLAs made it non-constant
18:54:00 <zid> not that the spec required the compiler to emit a constant load and optimize it all out etc in the first place
18:55:00 <heat> i wonder if non-x86 UEFI firmware have the x86 emulator built in
18:55:00 <HeTo> unless they push even more steps of the translation down to the part that you would normally call running the program
18:56:00 <HeTo> zid: if the expression isn't a VLA, it can still be used in an integer constant expression
18:56:00 <zid> okay?
18:56:00 <zid> I was directly responding to something you said
18:57:00 <HeTo> so, if you can't use sizeof (SomeStruct) somewhere where an integer constant expression is required, the language isn't C
18:57:00 <HeTo> e.g. a case label
18:58:00 <heat> HeTo, dunno how that works
18:58:00 <zid> except, the compiler doesn't *have* to be able to resolve expressions to constants
18:58:00 <zid> so again, that isn't true
18:58:00 <heat> not that we have a way to test of course
18:59:00 <heat> zid, cppreference says sizeof operators may be used in an integer constant expression
18:59:00 <heat> when not VLA
18:59:00 <heat> i assume this is in the standard as well
18:59:00 <zid> can be used in
18:59:00 <zid> the compiler does not have to be clever
19:00:00 <HeTo> zid: the compiler has to permit you to use sizeof with a non-VLA type wherever the standard says a constant expression is required. it's true that the implementation can implement it however it wishes, but while you can't do case somefunc(): in C, you need to be able to do case sizeof (SomeStruct): for example, or make a global (so, non-VLA) array with size sizeof (SomeStruct)
19:01:00 <zid> *exactly* that yes
19:01:00 <zid> but not 'arbitrary express you believe to be constant'
19:01:00 <zid> expression*
19:11:00 <heat> ebc uses some really weird indexing
19:12:00 <heat> it takes in constant units (bytes), then natural units (whatever is the machine's word size)
19:12:00 <heat> offset = constant + natural * sizeof(void *)
19:13:00 <wikan> do you know osdev related youtube channels? can you share?
19:14:00 <GeDaMo> https://www.youtube.com/c/AndreasKling
19:14:00 <bslsk05> 'Andreas Kling - Home' - 'Hello friends! I'm building SerenityOS, a new from-scratch graphical operating system for desktop computers.'
19:17:00 <heat> I think sizeof is implemented using the weird indexing they have
20:37:00 <geist> heat: yah that was my impression of it. I guess the whole C compiler for bytecode never made it into mainstream. Seems like LLVM/clang could deal with it nicely now, but the moment has probably passed and no one is going back and doing the work
20:38:00 <geist> i suppose hypothetically with more ARM devices running UEFI it might be worth it, but IIRC you can also just provide multiple drivers (different arches) for devices in the rom image
20:38:00 <geist> and the UEFI system just picks the right one. so not necessarily a need for a bytecode driver
21:33:00 <heat> geist, i saw a project in tianocore's wiki about porting llvm to EBC
21:33:00 <heat> but they said multiple times that it's almost dead
21:34:00 <geist> seems like that would be the only chance for survival
21:34:00 <geist> yah
21:34:00 <heat> it's not demanded by the spec anymore, it's optional
21:34:00 <geist> one of those interesting ideas but the moment has passed
21:34:00 <geist> and now things like embedding interpreters in large code bases is considered harmful
21:35:00 <heat> they have a package in edk2-non-osi I think which is an x86 emulator, literally qemu tcg inside your fw
21:35:00 <heat> that might be the way
21:35:00 <geist> alas we're still stuck with the ACPI runtime that large things have to do
21:35:00 <geist> but it came from that era of thinking at least
21:36:00 <heat> I remember they also found a bunch of option ROMs which dereferenced the NULL pointer
21:36:00 <heat> including an nvidia one lol
21:37:00 <heat> that should totally break any ARM device I would guess
21:37:00 <heat> since there's probably no ram at 0x0
21:39:00 <geist> depends. i'd say 50/50 but the general trend nowadays is to put peripherals at the bottom, then ram from then on out
21:39:00 <geist> so yeah
21:39:00 <geist> lots of times ROM is still at 0 though
21:40:00 <geist> but yeah 0 as a valid physical address is a thing
22:04:00 <kingoffrance> https://www.lysator.liu.se/c/ten-commandments.html A null pointer doth not point to a 0 of any type, despite some blasphemous old code which impiously assumes this.
22:04:00 <bslsk05> www.lysator.liu.se: The Ten Commandments for C Programmers (Annotated Edition)
22:04:00 <kingoffrance> ive kind of ...happy that's still a thing. not all things age so well
22:04:00 <kingoffrance> Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.
22:12:00 <heat> NULL is also invalid in UEFI
22:12:00 <heat> but mostly works since it's mapped and valid memory in x86
22:14:00 <geist> yah in places where 0 is a valid physical address i usually just 'burn' that page
22:14:00 <geist> ie, have the PMM returning page 0 being invalid and that's okay. that way you can still do a quickie assert that phys_addr != 0
22:15:00 <heat> if your allocator returns struct page * you don't have that issue
22:16:00 <geist> yah, but then you have a 'translate this to paddr', etc
22:16:00 <geist> lots of cases where the paddr goes around, and if you can just arrange for 0 to be the invalid value you h ave an additional thing to assert against
22:18:00 <geist> you can make the initial allocation api return an error or whatnot, which is generally a good idea (vs returning a pointer or whatnot) but down stream code many times translates to physiocal address and then deals with that (constructing new page tables, for example) so it's nice if deep in their code they can do something like ASSERT(paddr != 0);
22:18:00 <geist> just one of those things i've found along the way
22:21:00 <heat> kind of unrelated but have you tried out initialising the page allocator in parallel? in order to reduce boot times
22:21:00 <geist> it is a thing i've thought about for sure
22:21:00 <geist> at the moment it's the biggest pole in the tent for zircon boot
22:22:00 <geist> since it explicitly constructs the pmm page structures at boot, so it scales with the number of pages
22:22:00 <heat> I remember intel tried it out, they got to a point where they initialised X pages (so the system can boot comfortably) and then hotplug the rest
22:22:00 <geist> i think linux has something like that now. makes a difference for really huge systems
22:22:00 <heat> yup
22:22:00 <geist> at the moment, for example, zircon kernel boots in something like 50ms on an intel nuc and like 30ms of that is initialzing the pmm
22:23:00 <geist> on say a 16GB system
22:23:00 <geist> the numbers are made up, but it's something like that. like 3/5 of the boot time is this one phase
22:24:00 <geist> it's kinda a tricky problem when you think about it. you could do somehting like just preinitialize a subset of pages you think are good enough to start the system booting, say up to 1GB of pages
22:24:00 <geist> and then toss the rest in some sort of worker thread that runs post-SMP
22:24:00 <heat> what happens if you touch the pages with no-caching hints? movnti or whatever that is
22:24:00 <geist> so that you get some actual parallelism, vs some sort of false notion where a worker thread is just competing with system startup
22:25:00 <geist> well, it's not the pages themselves, but the vm_page_ts which are these little structures
22:25:00 <heat> yeah
22:25:00 <geist> so you cant just slam zeros into them. they're actually intiailized to a particular value
22:25:00 <heat> but won't touching every page in the system cause cache thrashing?
22:25:00 <geist> what do you mean?
22:25:00 <heat> when setting up the linked list of pages
22:26:00 <heat> unless you don't do that but I think you do?
22:26:00 <geist> possibly, though if you're walking through them in order you can kinda guarantee that the last page you're adding is linked to the one you just touched
22:26:00 <geist> so you're walking through them in order
22:27:00 <geist> since you're walking through them as an array (ideal) and then just chaining them together in a linked list in order it should be totally fine
22:27:00 <geist> NUMA may be a thing, since hypothetically you want to construct a pmm node on a cpu that's within the same node
22:28:00 <geist> but that's like a hard mode achievement
22:31:00 <geist> all this side i haven't tried optimizing the page construction code, so it's possible there's some low hanging fruit in there that's easy to fix up
22:32:00 <geist> possibly one of those C++ doing way too much stuff things that can be easily worked around
22:32:00 <geist> i think we basically just placement new each page out of the pre-allocated array, so it's possible the constructor for the page does a lot more work than it strictly needs to
22:32:00 <geist> especially since we have so many extra checks and whatnot enabled for the compiler that does a lot of extra work in a lot of cases
22:33:00 <geist> basically the same code on LK, except in C so I should take a look there and see what's up
22:34:00 <j`ey> Im guessing LK doesnt usually have 16GB of ram to init :P
22:34:00 <geist> if you boot on a machine with that much, sure
22:35:00 <geist> i think the max size is set by the amount of physmap that's allocated, which is per arch
22:35:00 <geist> for zircon it's limited to 64GB for x86 and 512GB for arm64. basically arbitrary, and can bump it
22:38:00 <heat> why so little for x86?
22:39:00 <geist> mostly because of the page tables. it can be bumped, but was expediant at the time
22:39:00 <j`ey> 64GB should be enough for anyone /s
22:39:00 <geist> a) at the moment only use one top level page table in the PML4, thus the total kernel address space is 512GB
22:39:00 <geist> this 64GB is a reasonable carve out for that
22:40:00 <geist> b) at the time it didn't rely on 1GB pages existing, though i think that's not the case anymore. we basically decided screw it you need 1GB page support
22:40:00 <geist> on arm64 the whole 'sharing 2nd level page tables with all aspaces' doesn't exist like it does on x86 and riscv so it's trivial to enable the full 48 bits of kernel space
22:41:00 <geist> and thus i use an entire 512GB 2nd level 'slot' for the physmap
22:42:00 <geist> so in short still need to fix the problem to expand x86-64 kernel aspace out to 47 bits and use the whole space
22:42:00 <geist> then can easily enable a huge physmap
22:42:00 <geist> but it's just on the todo list
22:43:00 <geist> that reminds me, i once wrote a reasonably decent internal doc about zircon kernel memory management. always meant to publish that on the external site
22:43:00 <geist> should do that once vacation is over then i can just point at it
22:43:00 <heat> yesss
22:44:00 <geist> i super suck at writing docs though, or more specifically i generally hate writing docs
22:44:00 <geist> only every once in a while i suddenly get the urge
22:48:00 <heat> la a0, %1; add a0, a0, tp; ld %0, a0 <-- does this look wrong?
22:48:00 <j`ey> linux's doc for aarch64 mem layout https://www.kernel.org/doc/html/latest/arm64/memory.html (I assume its similar to what you wrote)
22:48:00 <bslsk05> www.kernel.org: Memory Layout on AArch64 Linux — The Linux Kernel documentation
22:48:00 <heat> i'm getting a lot of undefined reference to a0
22:50:00 <geist> heat: for what arch is that?
22:50:00 <heat> riscv64
22:50:00 <geist> okay good, right arch :)
22:50:00 <heat> i forgot risc architectures are a bit too similar lol
22:50:00 <geist> is this in inline asm? I assume so because of the %
22:50:00 <heat> yeah
22:51:00 <heat> it's a get_per_cpu() implementation
22:51:00 <geist> i forgot if you needed % for registers or not. looking at my code
22:52:00 <heat> godbolt says no
22:52:00 <geist> oh i think it's the ld that is the problem
22:52:00 <heat> how? it's a cross toolchain
22:52:00 <geist> syntax for ld is `ld reg, (...)`
22:53:00 <heat> AH LOL
22:53:00 <geist> well more specifically `ld reg, N(reg)`
22:53:00 <heat> N is an offset?
22:53:00 <geist> er wait does it even have the N offset?
22:53:00 <geist> i always forget precisely how limited riscv is
22:53:00 <geist> all i see in my code is (reg) so may be it doesn't do offset
22:53:00 <geist> anyway, that's why
22:54:00 <geist> what's interesting is why it didn't say it was a malformed instruction. maybe it was trying to construct a pseudoinstruction and then it was looking for the a0 label
22:55:00 <heat> alright! no a0 undefined references now! thanks :)
22:55:00 <geist> there are lots of pseudo instructions on riscv that are really worth having a read over and/or a page up and handy, since the assembler has pretty much full authority to do what it needs to do including replacing instructions with compressed forms, etc
22:55:00 <heat> now I only have like 200 undefined references
22:55:00 <geist> noice
22:55:00 <heat> i need to stub everything out
22:56:00 <geist> yay new port
22:56:00 <geist> these are always fun
22:56:00 <geist> anyway if you need help ask, but i'm going to avoid just pasting urls to my port so you can figure it out on your own :)
22:56:00 <heat> never did one before
22:56:00 <heat> ofc :)
22:56:00 <heat> riscv seems easier but arm64 seems more useful
22:57:00 <geist> yah riscv is pretty EZ mode
22:57:00 <heat> since getting my hands on a riscv64 board is pretty expensive
22:57:00 <geist> if anything simply because for a lot of the tricky tasks (how exceptions work, etc) there's so limited features available there's really only One Way to do things
22:57:00 <geist> that took me some time to accept. I was hoping for more flexibility but nope. here it is. this is your exception, deal with it
22:58:00 <geist> also things like delivering IPIs and whatnot. one way
22:58:00 <geist> the hard part is like lots of arch manuals there's not an example chapter that says 'here's probably waht you want to do for X'
22:59:00 <sham1> Well isn't the manual more like a reference and a spec than a programmer's manual as such
22:59:00 <geist> it's like being given all the pieces for some lego set and no manual, but theres only like 20 pieces so you can kinda figure out how it fits together once you've examined all of them
22:59:00 <geist> sham1: exactly
23:00:00 <heat> intel gpu docs say "programmer's manual" iirc and they're mostly just a datasheet
23:00:00 <geist> that's part of the fun of porting things to new arches. it's different lego sets with different types of pieces each of them, but you start to get a real feeling for how different types of lego like things work
23:00:00 <geist> ie, duplos work kinda like legos kinda like capsellas, etc
23:01:00 <geist> x86 is like a 10k lego set with 1/2 of the pieces not even being part of the final thing
23:02:00 <heat> i like x86
23:02:00 <heat> probably because it feels like home
23:02:00 <heat> riscv and arm feels uncomfortable
23:02:00 <heat> it's like learning a new programming language
23:03:00 <geist> yah i get that. it's one of the reasons i like to work with other arches. i'm always into alternate ways to do the same thing. feels interesting
23:03:00 <geist> i think it gives you some sort of perspective which can occasionally be useful
23:06:00 <geist> posted in #riscv: https://www.youtube.com/watch?v=1OfeswjPZuw
23:06:00 <bslsk05> 'Hand Drawing a RISC V CPU and Playing Bad Apple on It' by -T.K.- (00:05:41)
23:08:00 <geist> i should look at that one more closely. i think i know that hardware simulator. what i dont get is the high rez display vs the low rez one
23:08:00 <geist> the low rez one i get, that can basically just be a direct view of the register file, actually, and then you could write like a 5 instruction program that just reads it out of a memory bank
23:09:00 <heat> hey that's pretty cool
23:10:00 <heat> https://github.com/T-K-233/RISC-V-Single-Cycle-CPU/blob/master/bad_apple.s
23:10:00 <bslsk05> github.com: RISC-V-Single-Cycle-CPU/bad_apple.s at master · T-K-233/RISC-V-Single-Cycle-CPU · GitHub
23:11:00 <geist> hah that's exactly what it's doing
23:12:00 <geist> the huge grid on the right is basically 32 registers, notice the top left one is different? that's the zero register
23:12:00 <geist> so basically it's walking through a data file, loading up 16 of the registesr it seems and then there's a set of latches to put them into some sort of i guess 16x16 display there
23:13:00 <geist> ah yeah dumping it into what is pointed to by the gp register (at 0x4000)
23:13:00 <geist> anyway, cute. the high rez vid must just be an overlay, not part of the simulation)
23:13:00 <heat> yeah
23:20:00 <gog> oh hey that's a tohou project thing
23:20:00 <gog> my wife loves tohou project :p
23:24:00 <heat> geist, it's hard to use builtins without libgcc/compiler-rt right?
23:25:00 <heat> the linker was complaining about double-float vs soft-float so I took out libgcc plus crtbegin/end from the link and now I'm getting __bswapsi2, __ctzdi2, etc
23:25:00 <heat> undefined references to them that is
23:27:00 <gog> yep i played the video and as soon as the music started she looked over :p
23:42:00 <geist> heat: yes it is
23:43:00 <geist> depends on the arch of course
23:43:00 <geist> but since riscv doesn't have a lot of those fancy instructions it tends to lean on it more
23:47:00 <heat> sucks
23:47:00 <heat> i wish I could link libgcc but it's not compiled for soft-float
23:53:00 <heat> ah I probably need to enable multilib