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
dormito has joined #osdev
rb has quit [Ping timeout: 250 seconds]
bxh7 has quit [Ping timeout: 256 seconds]
ShahNaim has quit [Ping timeout: 240 seconds]
k8yun has joined #osdev
rwb has joined #osdev
k8yun has quit [Quit: Leaving]
<geist> re: pdos. i remember kerravan. they used to be around the channel a bit
<geist> and i just now got that that's probably a silly way to write 'caravan'
<geist> had to say it out loud
<klys> wan't he kerravon?
<geist> oh maybe
<geist> well then maybe not
<klys> all my logs say kerravon
ElectronApps has joined #osdev
Preddy has quit [Quit: Leaving]
<klange> this lovely shade of blue means I haven't completely messed up build this bootstrap stub for the rpi https://cdn.discordapp.com/attachments/783369041661394995/942945714311397406/IMG_8658.jpg
heat has joined #osdev
xenos1984 has quit [Read error: Connection reset by peer]
<klange> Kernel needs some fixups, want to move the ramdisk loading to boot shim so the kernel doesn't need to care and the qemu one can keep doing fw-cfg while the rpi one will just have it embedded
<clever> the rpi firmware can also load a ramdisk, and place it into the DT at the standard location
<mrvn> klange: you can attach the ramdisk to the kernel
<klange> I like the ramdisk being as separate as possible, I'll look into the firmware-provided option
<klange> going to go ramdiskless to start, though, just to make sure I can get things working before I start running init, weed out all the assumptions from qemu
<clever> `initramfs initramf.gz 0x00800000` or `initramfs initrd.img-3.18.7+ followkernel` in config.txt
<clever> and it will either place the initrd at the specified addr, or after the kernel
<klange> can it do more than one?
<clever> i believe it can only accept one, you have to concat them yourself
<clever> like `cat a b c > many` and then `initramfs many followkernel`
<mrvn> clever: don't you forget the padding?
<clever> yeah, your a/b/c files would need any padding required to reconstruct it
<klange> provide your own padding ;) or avoid needing it
<clever> yep
<clever> the pi4 also has a firmware ramdisk
<clever> if you set boot_ramdisk=1 in config.txt, then it will load boot.img from the fat32 partition
<clever> and all other files (config.txt, start4.elf, kernel.img, your own initrd) are coming from boot.img (which is another fat32 fs)
<klange> I don't like making fats, already enough pain from efi there :)
<Griwes> hmmmmm just realized that I haven't actually implemented preemption yet, when trying to spin up a kernel thread to read what the initial userspace process sends as its logs
<Griwes> implementing exactly what is necessary for the next step has its ups but it also has its surprises, like this one
<klange> I discovered during my initial aarch64 bringup that my system could do a surprising lot of stuff without any tick
<klange> until idle ran, most things would block on ipc enough to get to a semi-working gui
<clever> the pi4 also has a 2d hw composition unit, so you could have pop-up windows running from their own bitmap images in ram
<Griwes> I mean the only reason I have timers right now is because booting APs is slightly saner when you don't spin and try to divine if enough time has passed
<klange> clever: I really do want to try to get a hardware backend for my compositor
<klange> especially on an rpi where I already know my pure-C alphablit stuff is slow
<Griwes> but I'm now trying to handle things that come in over a non-blocking syscall and, well, now I need preemption
<Griwes> (I guess I don't technically need it because I could forcefully schedule to another core, but then booting with a single core would hang... ;p)
<mrvn> if it's doing a syscall why don't you wake up the other thread?
<klange> Speaking of SMP, I think I'm running a new enough firmware that my other cores should be blocked on a firmware spinlock waiting for an address, so my PSCI bringup should be easily adaptable.
<klange> But first, a bit of work-work. I'll probably copy over some framebuffer text blitting into this stub loader during lunch, and get the MMU init running.
<klange> Then I'll poke around at the previously discussed options for getting the actual kernel loaded.
<Griwes> I am considering changing the naming of my syscall handlers already, because now I have a kernel thread that calls those interfaces directly, and having a direct call to "syscall_*_handler" looks a bit weird
<klange> most of mine are lightweight wrappers that do userspace interfacy things and then call a regular kernel function... except the poll-related ones, those need cleanups
<Griwes> well, I'm talking about that layer that is called by the userspace interfacy things
<Griwes> though maybe I ought to have normal functions that support putting a thread to sleep on read too, without going through the ones dedicated for the syscalls
<Griwes> s/read/read from a mailbox/
<klange> i still need to implement some real synchronization apis :) misaka inherited toaru32's terrible 'wakeup queues' and only barely got a 'real' mutex API that thus far has only been used by some block storage drivers
xenos1984 has joined #osdev
<heat> i got my system call tables in json and I have a python script that generates syscall stubs and a syscall.h header with all the syscall numbers
<heat> initially I needed to scan every kernel file for a sys_* using libclang
<heat> it was a fun little project
<heat> geist, in the plic is a context a hart?
<geist> yes
<geist> there's a plic doc on the riscv github though it's pretty simple
<geist> but it mentions a little bit of verbiage about what the terms are
<heat> yeah I'm reading it but I was unsure of the meaning of "Hart context"
<heat> hmm why does the plic have #address-cells = 0
<heat> there's very clearly an address there
<mrvn> heat: no child address, only parent?
<klange> [dog with ball in mouth] no address, only size
<heat> mrvn, wdym?
<mrvn> heat: A range could only have one address I think
<bslsk05> ​gist.github.com: plic · GitHub
<heat> this is what I'm seeing
<heat> there's very clearly a 64-bit address followed by a 64-bit size in reg
<klange> reg on a node uses address-cells/size from the parent; if it defines a new one, it applies to children
<mrvn> heat: and the parent has size = 2, right?
<heat> yes
<heat> ah, only children?
diamondbond has quit [Ping timeout: 252 seconds]
<klange> children, and various things within itself
<klange> but not reg, that's going to be parent-based
<mrvn> it's annoyingly vague which address/size-cells statement counts in a node
<klange> some things have stuff that uses both, like pci interrupt-map
<heat> wtf
<klange> er, pci ranges?
<klange> yeah that one
<geist> heat: welcome to broken device trees
<geist> wait. what? # things only modify children?
<geist> oh wait, but reg is always parent? huh. that's strang,ebut maybe explains why i keep finding 'broken' FDTs
<geist> my fdtwalk code i had basically given up and would jsut check the length of the key and then assume it's 32 or 64 based on that
<geist> ie, if i know it has two values and it seeps to be 4 words long then it's 64bit, etc
<geist> heat: any infos on how to parse that interrupts-extended field? haven't looked to see if there's a spec for the plic FDT entry
<geist> lookslike every pair of bytes is something, like a tag, value
<geist> 0x8:0xb 0x8:0x9, 0x6:0xb, 0x6:0x9, etc
<heat> I think the interrupts-extended field is phandle, <stuff that depends on the phandle>
<heat> would describe the connection using an interrupts-extended property. pic is an interrupt controller with an
<heat> This example shows how a device with two interrupt outputs connected to two separate interrupt controllers
<heat> #interrupt-cells specifier of 2, while gic is an interrupt controller with an #interrupts-cells specifier of 1.
<heat> interrupts-extended = <&pic 0xA 8>, <&gic 0xda>;
<clever> yeah, the source makes it much more obvious
heat has quit [Remote host closed the connection]
nyah has quit [Quit: leaving]
heat has joined #osdev
<heat> the plic ones seem to point to interrupt-controller nodes in each cpu
<clever> exynos4412.dtsi: interrupts-extended = <&gic GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>,
<clever> in some cases, it looks like gic-irq-type, irq#, and level
joe9 has joined #osdev
<clever> but nothing on the rpi range seems to use interrupts-extended
<clever> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt may say more
<clever> ah, extended looks like a "better" version of interrupts
<heat> ok this is horribly depressing
<heat> interrupts-extended in riscv's case contains <phandle to cpu's interrupt-controller>, cause of trap
<heat> where cause of trap is only 11 (machine external interrupts) and 9 (supervisor external interrupts)
<heat> it doesn't tell me shit
<heat> oh, do you think the local interrupt controller's interrupts-extended might have something useful?
<heat> no, it just tells you it generates machine IPIs and machine timer interrupts
<heat> something you could've figured out if you read the fucking spec
<geist> well, sure
<geist> sounds like they're just followig the rules
<heat> sorry arm stans, acpi is better
<heat> this settles it
<geist> id say yes *except* the needing to run byte code
<geist> that's a deal breaker for me
<geist> though i suppose it'd be an intersting exercise to write a bytecode interpreter, so i'd at least know what the scope of it is
<klange> dtb is just "hardcode everything" but fancier
<geist> may be simpler than i think
<heat> I think it's hard enough that everyone uses ACPICA
<heat> except windows
<gog> i will reimplement ACPI
<gog> :D
<gog> (no i won't)
<klange> i will simply stop caring about my x86-64 port, consider it sufficiently done, and focus on rpi400 solely :P
<clever> i think the official firmware de-init's the bcm2711 pci-e controller before running kernel.img, so you will need to refer to the linux source to know how to bring the pci-e back online
<heat> wha
<clever> the vl805 on the pi4 series also needs you to send a mailbox command to initialize its firmware, after the pci-e bar's are assigned
<gog> i actually might begin to attempt to integrate acpica into my code
<gog> but keep it in its own yucky little module
<gog> i still have some infrastructure to put in to make that feasible
<geist> yah and apica is fairly simple to port. my main complaint is it's huge. last i checked it compiles to something like 300KB text
<gog> gross
<gog> i'll kee it in its own yucky big module then
<heat> 170KB here
diamondbond has joined #osdev
<klange> "newer firmwares allow the loading of multiple files by comma-separating their names." neat
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
[_] has joined #osdev
[itchyjunk] has quit [Ping timeout: 240 seconds]
sonny has joined #osdev
skipwich has quit [Quit: DISCONNECT]
skipwich has joined #osdev
heat has quit [Ping timeout: 250 seconds]
heat has joined #osdev
heat has quit [Client Quit]
pretty_dumm_guy has quit [Quit: WeeChat 3.4]
<clever> text!
<gog> hello, world?
<clever> i had full 2d animations before i had text
<klange> well I'm hoping to dump a bunch of debug output, and I didn't want to fiddle with a flakey uart after the horrible experience I've had with the ttl adapter I picked up
<clever> my ftdi seems to randomly reconnect at the usb layer, sometimes just because a nearby fridge turned on/off
<klange> and I have this little tiny terminal emulator (it even speaks a bit of dec/ansi) :P
<clever> i got another 8086 branded uart adapter that fits directly onto the gpio header, it deadlocks if you send malformed uart data, until you closed and reopen the tty
<clever> the only bug-free uart ive had so far, is connecting one pi directly to another pi
k8yun has joined #osdev
<clever> abusing a pico might work, but ive not tried it yet
<nanovad> I have some random FT232R based board that has worked great for the times I've used it as aux UART on Arduino stuff
<bslsk05> ​www.pishop.ca: USB Console Stub - Serial adaptor for Raspberry Pi - PiShop.ca
sonny has quit [Remote host closed the connection]
diamondbond has quit [Ping timeout: 240 seconds]
dude12312414 has joined #osdev
Jari-- has joined #osdev
ElectronApps has quit [Remote host closed the connection]
<Jari--> morning all /s /w /p
<Jari--> hi friends
[_] is now known as [itchyjunk]
<Jari--> checked out the MS-DOS multitasking apparatus DR-DOS etc. .. it basically divided the CPU equally to all MS-DOS tasks, it multitasked, but it also made the applications equally slow
<Jari--> so guys, what basically I am aiming to do is a CP/M compatible system, 32-bit / 64-bit and etcs.
<Jari--> MP/M actually, because it is multitasking
<Jari--> some guys could write me a MS-DOS wrapper for VM86 etc. virtualization
gog has quit [Ping timeout: 260 seconds]
zaquest has quit [Remote host closed the connection]
smeso has quit [Quit: smeso]
zaquest has joined #osdev
smeso has joined #osdev
<klys> jari--, have a look at vm86plus, it's in linux
<bslsk05> ​github.com: linux/vm86_32.c at master · torvalds/linux · GitHub
<klys> jari--, I've noticed mainly about cpm, mpm, ccpm, that there is some difficulty in copying the files to your disk. do you have a way to do this?
<klys> jari--, I have a few dos related bookmarks up at http://show.ing.me/ in case you want to browse more
<bslsk05> ​redirect -> show.ing.me: now seeing...
[itchyjunk] has quit [Read error: Connection reset by peer]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
rustyy has quit [Client Quit]
rustyy has joined #osdev
k8yun has quit [Quit: Leaving]
k8yun has joined #osdev
sonny has joined #osdev
<sonny> Why bother with an OS if you can develop applications on UEFI?
<Mutabah> In that case, the UEFI runtime is the OS
<sonny> interesting
<sonny> is anyone doing this yet? like running server programs on uefi?
<sonny> I guess it doesn't do much in terms of seperation
<Mutabah> Unlikely, the firmware interface is pretty limited - and likely the implementation is unoptimised
<sonny> hmm
<CompanionCube> iirc UEFI is also single-threaded
<sonny> oh :/
<sonny> is it a big spec? how would you describe it?
<CompanionCube> modernised DOS in firmware?
matrice64 has joined #osdev
<sonny> ah
k8yun has quit [Quit: Leaving]
<CompanionCube> it's definitely modern, and there's enough MS influence to make it a DOS even if the command.com equiv isn't used much.
<sonny> so, how did they get the big operating systems to agree on it? like why use it?
<Mutabah> *shudder* guids and ucs-2 everywhere
<klys> it seems clever developed efivim, an editor
<CompanionCube> sonny: because intel and ms collaborated on it?
<sonny> yeah but I'm trying to understand, it makes it easier to provide firmware for hardware vendors?
<klys> I have a new allwinner d1 nezha dev board, and it came with a microsf card with 8 gpt partitions and uboot/opensbi
<klys> s/microsf/microsd/
<CompanionCube> or was it just intel
<CompanionCube> hm
<Mutabah> There is lots of MS in that spec
<Mutabah> nobody else nowadays would make those decisions
<CompanionCube> Mutabah: yes but was it put there by intel or MS themselves@
<klys> the "bios" or "firmware" now has to be standardized so tightly it's provided by a standards body, and these days the standards bodies include acpica.org and tianocore.
<sonny> I see, so if you want to develop an OS for say amd64 and such, you have to start here?
<CompanionCube> sonny: it meets the very low bar of not being the classical bios
<klys> major kernels such as linux link acpica's tarball into the kernel itself
<CompanionCube> (and also was originally for itanium, not x86)
<sonny> when I read about classical bios they don't go into much detail
<klys> the bios was originally documented this way: http://www.ctyme.com/rbrown.htm
<bslsk05> ​www.ctyme.com: Ralf Brown's Interrupt List - HTML Version
<sonny> I'm not even sure what is means for ACPICA to exist, since OSes already implement ACPI?
<CompanionCube> yeah, there's no 'real' spec for that
<CompanionCube> sonny: ACPI is a ..big standard
<sonny> :/
<CompanionCube> yeah it sucka
<bslsk05> ​github.com: ralf-brown-interrupt-list/PORTS.A at master · cirosantilli/ralf-brown-interrupt-list · GitHub
<sonny> klys: they really let this go on for 20 years? lol
<klys> sonny, from 1986-2006? sure
<sonny> ok, it's a good thing I'm going to study hardware then
<sonny> easier to start over
<klys> sonny, do you have an fpga dev board?
<sonny> no, I have not done fpga yet
<sonny> I only have a microbit
ElectronApps has joined #osdev
<sonny> I hear fpga isn't cost effective anyways
<sonny> hardware languages look fun though
<sonny> 6 buttons and lots of pins
<sonny> 2 microusb? and one usb
<klys> they were programming it with nmigen, which uses python to produce verilator code
<sonny> not sure which parts are the fpga
<sonny> klys: why is that so popular? compilers from a typical programming language to a hardware language?
<sonny> they are working on those at intel and ibm
<klys> here's a manual for the above: https://github.com/emard/ulx3s/blob/master/doc/MANUAL.md
<bslsk05> ​github.com: ulx3s/MANUAL.md at master · emard/ulx3s · GitHub
<klys> well it's less easy to make mistakes if you're programming in a higher level language
<sonny> oh, there's a lot more on it that I thought
<geist> klys: yeah i have one of those. it's. nice board
<sonny> klys: sure, but you think they'd just make a better hardware language
<sonny> what is gained from c -> verilog? :P
<geist> i admit i haven't done much with it, but it's main nicety is you can use open source tools against it
<geist> since it's a lattice fpga, iirc
<klys> sonny, well verilog did come around over a decade ago to replace vhdl
<sonny> I see
the_lanetly_052 has joined #osdev
<geist> verilog goes back much farther than that. early 80s iirc
<geist> but it got standardized a bit after that
<geist> was mostly some proprietary thing before that
<sonny> klys: have you seen this? https://github.com/j-core/jcore-soc
<bslsk05> ​j-core/jcore-soc - J-Core SoC Base Platfrom. Top level for FPGA platforms, pulls in CPU, BootROM and various IP blocks. (6 forks/16 stargazers/NOASSERTION)
<klys> naw I haven't see it yet
<sonny> seems similar in spirit, except this one is kinda fancy
<klys> it runs jave bytecode?
<klys> java*
<sonny> no, I don't know why the name is j-core
<sonny> "J-core is a clean-room open source processor and SOC design using the SuperH instruction set, implemented in VHDL"
<geist> wow, superh
<geist> that is... strange. maybe the 'j' stands for japan?
<geist> where superh is i think still somewhat prevalent?
<sonny> it caught my eye cause superh has a harvard architecture
<klys> a soc is a modern type of cpu (with onboard peripherals), so an fpga dev board is for an ee project, and an soc dev board is for running and creating programming.
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<geist> well, superh is nothing special, it was just hitachi's thing back in the 90s
<geist> lots of arches are harvard in that they have separate I and D ports, but then you jsut make them point at the same back
<geist> bank
<kazinsal> looks like jcore was unveiled at LinuxCon Japan so yeah maybe that's the etymology
<sonny> oh
<geist> yah hitachi spun it off into Renesas and AFAICT it hasn't developed much since SH5
<geist> but i occasionally see it floating around, but almost exclusively in japanese things
<sonny> I don't like microops but it is interesting to me
<geist> cameras, etc
<kazinsal> and SH5 didn't seem to get any physical release
<geist> yah
<geist> and of course Dreamcast, which is where i fiddled with it first. ported my first OS to it from x86
<sonny> oh woah
<geist> it's about as different from x86 as you can get
<sonny> x86 is crazy
<sonny> imagine segments ... lol
<geist> why imagine? they are there!
<sonny> tried to do some DOS programming and boy was I confused
<sonny> well, that's over now :D
<geist> anyway, a little surprised doing a clean room superh is not fraught with some amount of legal heat
<geist> aaah on wikipedia: As of 2015, many of the original patents for the SuperH architecture are expiring and the SH-2 CPU has been reimplemented as open source hardware under the name J2.
<sonny> it's cool that clean rooms still happen
<sonny> openocd seems to be everwhere, what on earth did people do before?
<geist> for jtag? they do what they do without openocd: use tools that are not openocd
<sonny> oh
<sonny> prorbably proprietary
<geist> they might have to pay for them though
<geist> right
<sonny> I think these toolchains could be organized better, I just can't accept the complexity ...
<sonny> anyways, nice to have all these options
<sonny> why choose j-core for a project with all this risc-v stuff?
<geist> because it was done like 8 years ago
<klys> riscv is a fledgeling arch with a clean implementation yet some difficulty expressing itself
<sonny> ohhh
<geist> and also why not
<sonny> seemed easier to design risc-v products but if nothings available then yeah
<klys> openpower is also available for free now
<sonny> is that related to power9?
<klys> yes
<sonny> ok, so openpower is the overall class of processors or something?
<geist> also sparc
<klys> geist how free is sparc now? what licensing?
<geist> i think it's pretty free
<geist> i jsut know there are some pretty free cores out there and some used in things like space exploration and whatnot
<klys> do you have an fpga lineup for it?
<geist> me? no
<klys> mebby there's one on opencores
<CompanionCube> also openrisc exists
<bslsk05> ​opencores.org: Overview :: S1 Core :: OpenCores
<geist> it seems that riscv has just sucked the air out of that particular room
<klys> > In recent years the project has not been actively worked on, so users are strongly advised to use Princeton University's OpenPiton project instead: http://parallel.princeton.edu/openpiton/
<bslsk05> ​parallel.princeton.edu <no title>
<klys> > With OpenPiton Release 10, the new OpenPiton+Ariane brings the 64-bit Ariane RISC-V core to OpenPiton!
<klys> it's still OpenSPARC in the intro to the documentation
sprock has quit [Ping timeout: 252 seconds]
<vdamewood> Food?
<vdamewood> Oops, rong channel.
<vdamewood> wrong*
<geist> noms are good
<vdamewood> I'm thinking various chopped up vegetables with vinegar and oil on top.
<kazinsal> I had a bacon cheeseburger. om nom nom
rustyy has quit [Ping timeout: 272 seconds]
rustyy has joined #osdev
<klys> yea happy valentine's. for supper I went to a formal activity. was p.sweet.
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
sonny has quit [Remote host closed the connection]
<geist> huh surprising. virtualbox doesn't seem to really like to use MSI-X
<geist> and doesn't assign MSI for even things like e1000
<geist> yah with all of the virtio stuff it understands, and e1000 and ahci, it only seems to give MSI to AHCI
<kazinsal> yeah, they stubbed out the e1000 MSI stuff
<kazinsal> oracle kinda doesn't give a shit
<geist> well, at least they seem to give MSI-x to nvme
<geist> of course oracle not giving a shit is not surprising
<geist> i'm honestly surprised the whole thing wasn't just shit canned years ago
<CompanionCube> how virtualbox has avoided the sidam touch i'll never know
<kazinsal> it's been in maintenance mode for years unfortunately
<kazinsal> it's just useful enough to keep fixing bugs in
<geist> yah i eventually actually ended up paying for vmware for windows, but the cross platformness of virtualbox is still very enticing
<kazinsal> when windows 10 was still in technical preview it took moooonths before they patched it to work properly
<kazinsal> and had to do multiple patches as things changed in the technical preview because they were just doing something atrocious with calling windows' secure libraries or something
<kazinsal> VMs would mysteriously fail to start with an incomprehensible error because they were basically doing the equivalent of raw syscalls
<geist> yah there was a period maybe 3 or 4 years ago where virtualbox was broken on linux too
<geist> which was when is stopped running it as my VM solution on my server, piddled with ESXi for a few years, and then switched back to just QEMU
<CompanionCube> full replacement of vbox is libvirt no?
<geist> i dont think there's a full replcaement for vbox in certain axis
<geist> most notably it being portable to mac/windows/linux
<geist> OTOH the mac stuff is quickly falling away as newer macs are ARM and i seriously doubt vbox will even attempt that
xenos1984 has quit [Remote host closed the connection]
<kazinsal> yeah, I feel like vbox's core still gets updates because it's used in their cloud virtualization offerings
<kazinsal> which exist primarily to SaaS-ize their database software
<kazinsal> (because they wanted to charge even MORE money for it...)
xenos1984 has joined #osdev
jjuran has quit [Quit: Killing Colloquy first, before it kills me…]
jjuran has joined #osdev
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
m5zs7k has quit [Read error: Connection reset by peer]
m5zs7k_ has joined #osdev
m5zs7k_ is now known as m5zs7k
GeDaMo has joined #osdev
eroux has joined #osdev
dormito has quit [Quit: WeeChat 3.3]
ElectronApps has quit [Remote host closed the connection]
dormito has joined #osdev
CaCode has joined #osdev
ElectronApps has joined #osdev
<klange> I am getting to userspace, ld.so is loading init, I'm getting all the way through several syscalls, but fork() fails on return in the child process with an unknown exception... fun times
[itchyjunk] has joined #osdev
the_lanetly_052 has quit [Remote host closed the connection]
the_lanetly_052 has joined #osdev
the_lanetly_052 has quit [Ping timeout: 252 seconds]
diamondbond has joined #osdev
dennis95 has joined #osdev
CaCode has left #osdev [Leaving]
<klange> i'm calling it a night; seems all I'm doing at this point is fighting over caching, so I'm on the cusp of a working system...
<klange> maybe I need to adjust some control register things; rpi is dropping me off in el2 and I'm not sure I dropped down to el1 entirely correctly for what I expect out of the mmu
* klange yawns loudly and steps away from the keyboard
diamondbond has quit [Ping timeout: 272 seconds]
lkurusa has joined #osdev
diamondbond has joined #osdev
gog has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
diamondbond has quit [Ping timeout: 272 seconds]
heat has joined #osdev
nyah has joined #osdev
sonny has joined #osdev
sonny has left #osdev [#osdev]
<zid`> The problem with my capacity for error is that it's purely theoretical
<gog> do i need any special initialization semantics for an atomic type? ATOMIC_VAR_INIT() is deprecated apparently and it seems to generate the right code when i do an increment
<heat> no
<gog> cool
<g1n> hello
<g1n> what would you recommend to implement next after page frame allocator (didn't have time to ask yesterday)
<g1n> i am not sure yet when i am going to start implementing it, but would be cool to know for future :)
<gog> a malloc()-type interface is a good thing to have for small objects
<mjg> g1n: have you read the slab paper by bonwick
<g1n> mjg: no
<mjg> the key concept behind it is how everyone is doing memory allocation today
<g1n> ok thanks :)
<g1n> gog: so i am ready for that? i found this page - https://wiki.osdev.org/Writing_a_memory_manager , i think will be helpful. Also, i am not making anything virtual yet (i mean i am not really using paging for page frame allocator)
<bslsk05> ​wiki.osdev.org: Writing a memory manager - OSDev Wiki
<gog> idk maybe
<g1n> gog: ok thanks, i will try
<g1n> i think i need to jump to my other GRU projects, i hope for not very long time
<zid`> next step imo is mmap that can't take NULL for left side
<zid`> so just map arbitrary virtual address into memory, and pulls physical pages to do it off your stack
<g1n> zid`: this could help? https://wiki.osdev.org/Paging#Manipulation
<bslsk05> ​wiki.osdev.org: Paging - OSDev Wiki
<zid`> looks like it, I've never done 32bit paging to know if that's good or not
<g1n> ok
<g1n> thanks
ElectronApps has quit [Remote host closed the connection]
dude12312414 has joined #osdev
sonny has joined #osdev
<mrvn> g1n: After your page frame allocator you should change it to use a struct phys_add_t or struct page_frame_t for added safety. And then start on a virtual address space allocator and a MMU module to map/unmap memory.
<gog> ok i'm getting an intermittent #GP weird
matrice64 has joined #osdev
<gog> it works sometimes, other times it faults trying to write an io port
<mrvn> I would ignore malloc and slabs and such for now. You don't need to allocate small objects for quite a while yet. You can do threads, interrupts, preemption, syscalls and basic user space tasks before you need it.
<gog> i wonder if my host system is fucky
matrice64 has quit [Client Quit]
<mrvn> g1n: One other really really important thing: setting up the exception handlers so they print some diagnostics.
<zid`> "Your host system is funky" is a pretty good insult
<mrvn> gog: are you maybe writing the wrong size?
<mrvn> gog: or forgot volatile so the compiler optiomizes it out?
<gog> it's a byte write, it's volatile, and it's happening without recompiliations
<gog> i ran it 10 times in a row and it #GP'd twice
<zid`> You'll have to take it out back and shoot it
<zid`> nothing else to do
<gog> probably
<zid`> what are you writing to?
<j`ey> gog: try a different emulator
<mrvn> pretty sure it's not the outb. You can write to any port and the cpu won't care unless you've setup the IO bitmap to protect ports.
<gog> zid`: 8259 pic
<zid`> ah yea that's super weird
<zid`> like.. *really* super weird
<gog> i think it's the host
<mrvn> gog: are you maybe getting an interrupt and that GPs?
<zid`> ooh
<zid`> yea, what if your write is enabling interrupts
<zid`> and it immediately faults if one is pending
<gog> that _could_ be it
<zid`> which is.. sometimes a thing because of key repeat from grub or something
<gog> maybe i should clear the irr
<mrvn> you have to reset the PIC
<gog> yeah
<gog> i can see how there'd be a race happening there
<zid`> I actually had that 'issue' on my pic impl at first, grub would keep an interrupt pending from the keyboard when I selected my OS sometimes
<zid`> so I had to hit the key real fast :p
<gog> yknow what i'm gonna tap some keys while it starts and see if it does it
<zid`> I was just too lazy to not write a crashy handler until I'd done writing the code I was writing
<gog> i can't seem to trigger it again
<gog> ¯\_(ツ)_/¯
<mrvn> Are you getting a tripple fault?
<mrvn> Heisenbug, don't look at it or it gets scared.
<gog> no, my gp handler is installed at this point and it just stops dead
<gog> but i haven't been able to trigger it again
<mrvn> so what's the address that faults?
<zid`> sounds fixed to me
<gog> the address that faults is inside pic8259_init()
<gog> and it's an inb not an outb
<zid`> inb in a pic code?
<mrvn> strange
<gog> it's in the delay thing
<gog> just read from 0x80 and discard
<gog> although idek if that's actually necessary, i just did what the tutorial does
<zid`> I just write 17 17 32 40 4 2 1 1 0 0 3 and it works in qemu at least :p
<mrvn> what if you do "*(volatile int *)(0x12345678) = 23;"? Does it show the right PC and fault address?
<gog> ehh i'm not gonna waste anymore energy trying to dig this up rn
<mrvn> gog: just trying to test your GP handler.
<gog> oh ok hold on
<gog> well, what you're proposing won't GP, it'll PF, PF and DF
<mrvn> right, my bad. oehm, how do you GP in kernel?
<gog> i guess i could write a bad segment descriptor and do that
<zid`> I just look at -d int
<zid`> it's easier than writing handlers :P
<mrvn> zid`: cheater :)
<_eryjus> my guess is zid` is lazy -- and laziness has its motivations!
<gog> lol ok idk i can't make it happen
<gog> giving up this diversion now
<gog> i suspect there's a race happening in there somewhere
<gog> but i cba, i'm hungry and need more caffeine
matrice64 has joined #osdev
<gog> omg it happened again
<gog> ok
<mrvn> did you try qemu and bochs?
<gog> no just qemu
<mrvn> kvm?
<gog> no kvm
<mrvn> All 3 behave differently in subtle ways. Sometimes one can highlight a problem better than the other.
<gog> offset 1dec, first byte of inb()
<gog> old excetption is -1 on int trace
<gog> so it's a straight #GP
<mrvn> did you install a TSS?
<gog> yes my tss is installed at this point
<mrvn> and you didn't block any IO ports?
<gog> nope, iopb is 0
<gog> the instruction is a push rbp
<mrvn> your inb() isn't static inline?
<gog> it's not
<gog> probably should be?
<gog> or are you teasing me
<mrvn> performance wise it's irelevant, inb/outb take forever. But code wise doing a function call for a single asm opcode is just wstefull.
<mrvn> also prevents the compiler from picking the best register to use for the opcode.
<mrvn> anyway, if the push fails then it's probably a bad stack pointer
<gog> stack pointer and segment are correct
<gog> stack is in an rw memory region, mapped in
<_eryjus> gog, what do you do before your inb() call? anything that might clobber your GDT?
<gog> i don't think it should
<mrvn> _eryjus: a bad gdt would fault when loading segment registers I believe, not on push
<gog> error code is 2, so write
<gog> which yeah
<gog> obv
<mrvn> and your SP is correct and not underflowing?
<_eryjus> mrvn: i was wondering if it was clobbered after the load. i believe that fact is hidden for some time without faulting -- which is probably what you are describing
<gog> it's in identity-mapped memory and it has way more than enough space
vdamewood has quit [Read error: Connection reset by peer]
vdamewood has joined #osdev
<_eryjus> wait, can push throw anything other than #GP(0)?
<GeDaMo> #GP(0) If the memory address is in a non-canonical form. #SS(0) If the stack address is in a non-canonical form. #PF(fault-code) If a page fault occurs. #AC(0) If alignment checking is enabled and an unaligned memory reference is made while the current privilege level is 3. #UD If the LOCK prefix is used. If the PUSH is of CS, SS, DS, or ES.
<bslsk05> ​www.felixcloutier.com: PUSH — Push Word, Doubleword or Quadword Onto the Stack
<_eryjus> but not #GP(2)...
<g1n> mrvn: ok thanks, i noted it for future myself
<gog> yeah i'm actually not sure if that's the faulting instruction now
<gog> i'm digging through the stack right now trying to find any inconsistencies
sonny has quit [Remote host closed the connection]
sonny has joined #osdev
<gog> 0x0000000107f115f0 that 0x1 in the upper dword doesn't make sense
<gog> at 24($rsp)
sonny has quit [Remote host closed the connection]
lkurusa has joined #osdev
<gog> ok apparently i tried to execute data?
<gog> that can't be right
dormito has quit [Ping timeout: 250 seconds]
mahmutov has joined #osdev
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
diamondbond has joined #osdev
lkurusa has quit [Quit: I probably fell asleep (or went out). Who will ever know.]
<bslsk05> ​gist.github.com: backtrace of mysterious #GP · GitHub
<gog> not sure i can trust this backtrace after #3
heat has quit [Remote host closed the connection]
heat has joined #osdev
diamondbond has quit [Quit: Leaving]
<_eryjus> what is the instruction at 0xffffffff800055c0? is that your data?
<gog> that's data yeah
<gog> there's no path that should go through it
<gog> the one possibility is a page fault in my .text but there was no page fault before the gp
<_eryjus> stack symmetry problem on an iret?
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<gog> that's my intuition i'm digging into that rn
dennis95 has quit [Quit: Leaving]
pretty_dumm_guy has joined #osdev
<mrvn> you should start your kernel with gdb attached and single step it
mahmutov has quit [Ping timeout: 252 seconds]
<_eryjus> that's a pain when it faults < 20% of the time.
mahmutov has joined #osdev
<mrvn> it's likely to be wrong more often and just not fault.
<gog> idk i can't make sense of it
<gog> my last few runs didn't fault
<gog> can i tell qemu to ignore certain vectors with -d int?
<gog> it'd be a lot more helpful without all the spam
lkurusa has joined #osdev
<mrvn> What's at or around 0xffffffff800055c0? That is probably a register that got spilled onto the stack.
<gog> it's core_image_node, virtual memory range for the kernel image
<mrvn> so the fault must after you used that somewhere in your code
<gog> it is, it's after memory_init() is complete
<gog> all the data structures look correct
<mrvn> check all your interrupt code that they don't return from the wrong position on the stack
<j`ey> along with -d int, you can use: -d cpu,in_asm
<j`ey> and singlestep if you want to go even further..
<gog> that doesn't help my terminal spam problem :p
<j`ey> write it to a file :P
<_eryjus> gog: suggestion: use `>qemu.log` and then download glogg and use that to review the file.
<_eryjus> then you can use all the flags without terminal ptsd
<gog> if i can make it fucken DO THE THIGN
* gog throws her coffee mug through the wall
<_eryjus> i have about a dozen of those bugs.
<gog> it's cosmic rays
<gog> it's the earth's magnetosphere
<gog> i saw aurorae the other night
<gog> stands to reason
<mrvn> close the double walled faraday cage, leave your tin foil hat on
<gog> but then i can't use irc
<gog> i don't have ethernet anywhere in the house XD
<j`ey> you also dont have a CPU with VT-x?
<gog> is that vmx in /proc/cpuinfo ?
<gog> i have it
<j`ey> how come you arent using kvm then?
<j`ey> I mean, tcg is better for debugging, just wondering
<sham1> gog: wait, through the wall?
<gog> _THROUGH_ the wall
<gog> wallhack
rwb is now known as rb
mahmutov_ has joined #osdev
masoudd has joined #osdev
mahmutov has quit [Ping timeout: 252 seconds]
myon98 has quit [Ping timeout: 250 seconds]
<gog> j`ey: if i don't specify -no-kvm does it do by default?
<gog> because if so then i am using kvm
<j`ey> dont think so, cos otherwise -d int doesnt work. I think?
<gog> oh i'm not it says kvm support: disabled
<zid`> qemu-x86_64_system -cdrom gog_smells.iso -machine -q35 -m 1G -d int -no-shutdown
* gog sniffs
<gog> yeah i'm a little smelly
<zid`> not as much as meee
<mrvn> can one combine valgrind with qemu?
<Bitweasil> What do you want to valgrind? qmeu, or what's running in qemu?
<Bitweasil> Presumably the second...
<mrvn> the kernel. find uninitialized access and such
<Bitweasil> But I'm not sure how that would work.
<Bitweasil> valgrind instruments the allocators and such, you'd probably have to add valgrind support to your kernel.
<Bitweasil> And IIRC there are other kernel memory sanity tools that are better suited to kernel work.
<mrvn> like?
mahmutov_ is now known as mahmutov
<Bitweasil> Hm, https://www.kernel.org/doc/html/v4.14/dev-tools/kasan.html is pretty Linux kernel specific.
<bslsk05> ​www.kernel.org: The Kernel Address Sanitizer (KASAN) — The Linux Kernel documentation
<Bitweasil> There's probably a way to make it work, but I'd imagine it involves a good bit of custom plumbing.
<Bitweasil> Because you're not "requesting memory from something else," you *are* that something else.
<zid`> Basically, it's only going to work at a decently high level.
<zid`> Otherwise you're just.. writing an allocator that supports auditing itself a little.
<j`ey> Bitweasil: I think heat added kasan to his kernel
<gog> ok i managed to stand up long enough for a shower
<mrvn> loks like it just adds some canaries in shadow memory
xenos1984 has quit [Remote host closed the connection]
<mrvn> should be easy to port to your own kernel
xenos1984 has joined #osdev
<heat> yes I added kasan to my kernel
<heat> there's a standard layout + docs for asan if you want to agressively inline asan checks and whatnot (clang does this by default for example), but if you turn that off you can use essentially anything you want
<heat> as long as it tracks memory
<heat> you just need to implement the kasan callbacks
<heat> s/kasan/asan/
<bslsk05> ​github.com: Onyx/asan.cpp at master · heatd/Onyx · GitHub
<heat> not perfect (and doesn't work with inlined asan rn, which is not great) but it does the job
<mrvn> It would be nice if gcc had an option to have every pointer store the valid range too.
<mrvn> 192 bit pointers
freakazoid333 has joined #osdev
<Bitweasil> How would you do that? I guess if you make every pointer 3 [size]...
<Bitweasil> Yeah.
<mrvn> Nothing in C says what a pointer should look like.
<Bitweasil> It's legal, just would break all sorts of interesting things.
<Bitweasil> Which would also be interesting.
<mrvn> struct { void *p; void *start; void *end; }; is a perfectly valid representation of a pointer
<Bitweasil> Years and years ago, I ran SGIs, and it was interesting how many things big endian 64-bit broke in the open source world.
<mrvn> Bitweasil: what would break?
<Bitweasil> If you're doing the standard pointer-to-int and int-to-pointer conversions.
<Bitweasil> You'd skip the range things.
<mrvn> Bitweasil: intptr_t is the only type allowed for that and would have to be 192bit large
<Bitweasil> hm.
<Bitweasil> Yeah, you'd break stuff that was never guaranteed to work anyway.
<mrvn> arithmatic on intptr_t could be tricky.
<Bitweasil> Hey, we've found a way to make Chrome use even more RAM!
matrice64 has joined #osdev
<gog> ugh it's happened once more in like 50 attempts
<gog> it has to be a race during pic initialization
<gog> but why
<zid`> gog why don't you have guilty gear x2 on your website anymore
<gog> :(
<zid`> steam doesn't have it either
<j`ey> gog: a race? you have threads or?
<bslsk05> ​www.gog.com: Guilty Gear X2 Reload removal from catalog, page 1 - Forum - GOG.com
<gog> j`ey: hardware race, because UEFI uses the timer and the PIC before i re-initialize it
<j`ey> ah
<gog> because it's happening in pic8259_init() every time
<gog> just not always the same place
<mrvn> don't enable interrupts which source haven't initialized yet.
<mrvn> +you
<zid`> gog: Just write it so it doesn't race?
<zid`> by which I mean, why isn't the first possible instruction in your os 'cli'
<gog> it is
<zid`> how's it doing anything then?
<gog> interrupts are clear until task_init()
<gog> idek
<_eryjus> im still leaning toward a stack symmetry concern -- iret setting IF
<_eryjus> or the like
<gog> but why isn't it determinisitc then
<heat> what's the problem really?
<zid`> catching a gp at random during pic initialization code, afaik?
<gog> yes
<heat> do your interrupts work?
<gog> yes
<heat> you sure?
<zid`> and interrupts are supposedly off anyway
<heat> run with -d int and see the first interrupt you get
<gog> when it doesn't do the GP thing it runs right through init, page faults and returns from them correctly and the timer fires
<gog> im doing that heat wtf do you think i've been doing
<heat> what do you get then?
<zid`> I never actually got as far as setting up the timer, I decided to start parsing the ioapic acpi table instead
<gog> most of the time, sails right through to my idle task
<zid`> going to *attempt* to use those timers
<mrvn> how do you get any interrupts if they are supposed to be disabled?
<dmh> what happened to xr2 reload :(
<heat> how does your rflags look like
<dmh> nm just read that thread lol
<dmh> still have it in library
<bslsk05> ​gist.github.com: gist:d78c4279e91710d7a75474214a01fa9c · GitHub
<gog> that was the last one
<gog> 0xffffffff800044f3 is inside pic8259_init()
<gog> but that was like 60 attempts ago
<mrvn> gog: How about the first? That's where interrupts get enabled wrongly
<gog> hasn't happened again and i've changed nothing
<heat> 1) weird GDT layout
<zid`> e=0f02 is weird
<gog> yes it is weird
<heat> oh yeah good catch
<heat> bet you tried to load crap into a segment register
<heat> either through iret or a mov
<zid`> gp should only have an error code if you loaded it as a segment selector
<zid`> like.. mov ax, 0x0f02; mov ds, ax
<heat> why is your stack so low?
<gog> kernel stack is created during task_init()
<gog> this is directly from UEFI and still mapped in
<gog> ...
<gog> hm
<heat> did you reserve it
<gog> i think so
<zid`> can you x /1i 0xffffffff800044f3
Burgundy has joined #osdev
<mrvn> isn't 0xffffffff800044f3 awfully low in memory?
<gog> 0xffffffff800044f3: e8 55 ff ff ff callq 0xffffffff8000444d
<zid`> how the fuck does a callq generate a gp with an error code
<zid`> unless.. stack descriptor got corrupted, and it decided to reload it there and then
<zid`> but that seems highly unlikely
<gog> and it ran right through to entering the idle thread this attempt too
<mrvn> gog: are you mapping 0x100000 physical to 0x0xffffffff80000000 virtual?
<gog> no
<gog> ffffffff80000000: 0000000006c34000 ----A----
<mrvn> ?
<gog> that's the first page of my kernel image
heat has quit [Ping timeout: 250 seconds]
heat has joined #osdev
<mrvn> most people map 0 -> 0x0xffffffff80000000 so they can use 1G or 2M pages.
<gog> ok
<mrvn> and make phys_to_virt mapping simpler
<zid`> My kernel image is like 8kB, they can keep their 2MB page :p
<heat> mrvn, it's a poor idea in lots of cases
<mrvn> heat: mapping 2M pages?
<heat> mapping 0 to -2G
<heat> like when you're not sure where you'll be in physical memory
<zid`> and it's the virtual address that has to be 2M aligned, does that constraint actually apply to the physical as well? O_O
<heat> if you say your kernel runs on -2GB virtual, you don't need to relocate yourself
<heat> zid`, yes
<gog> what's wrong with my GDT layout anyway?
<zid`> huh, didn't know that
<_eryjus> what is at 0xffffffff8000444d? Want to do a sanity check here....
<gog> it's an instruction inside the function pic8259_init()
<mrvn> heat: you know you are at 0x100000 and you link your kernel to run at 0x0xffffffff80100000
<heat> gog, should be 0x8 - kernel CS, 0x10 - kernel DS, 0x18 user CS, 0x20 user DS
<mrvn> heat: + TSS
<gog> does that order matter?
<heat> mrvn, what if you don't?
<heat> gog, yes
<_eryjus> so you are calling an instruction location? -- not the actual start of a function?
<zid`> yea, it just.. has more reserved bits in the fields, TIL
<mrvn> heat: then nothing will boot
<heat> mrvn, or you can build a physical-address-independent kernel
<gog> my kernel is physical-address-independent
<mrvn> heat, gog: I bet your bootstrap code isn't and will break with other addresses
<zid`> gog: syscall/sysret vaguely care about the order, I rebuild my GDT from C later on before I drop into userspace
<gog> zid`: hm ok i'll consider that
<zid`> plus it nicely relocates the GDT into kernel space from 'random grub address'
<heat> mrvn, my x86 bootstrap code isn't because my kernel isn't
<heat> but my riscv bootstrap code definitely is
<heat> i'm linking that whole section with base = -2GB, and running it on a physical address
<gog> _eryjus: no, that just was the saved RIP from the GP info that qemu spat out
<gog> where it was when the GP came through
<_eryjus> gog> 0xffffffff800044f3: e8 55 ff ff ff callq 0xffffffff8000444d
<heat> gog, can you link the full log?
GeDaMo has quit [Remote host closed the connection]
<zid`> I still haven't had any bright ideas as to how e != 0
<gog> heat: there was no prior exception, it's all timer interrupts from UEFI
<gog> v=68 etc
<gog> _eryjus: e8 55 ff ff ff call 444d <wait>
<gog> is from objdump
<mrvn> gog: why are you enabling interrupts before initializing the pic?
<gog> i'm not
<mrvn> gog: then you should get exactly 0 interrupts in the log
<mrvn> Check the first interrupt. everything past that is irrelevant since something corrupted your cpu state
<gog> interrupts are disabled before ExitBootServices() and remain disabled until task_init() calls irq_unlock()
<mrvn> gog: you said you are getting too many interrupts in the log. So clearly they are not disabled.
<gog> yeah, i'm getting interrupt spam from the UEFI TIMER INTERRUPT
<zid`> grub also does interrupts
<zid`> also qemu does a bunch of smm
<zid`> the top of the log will *never* be the first exception
<mrvn> if you use multiboot then just load the kernel via qemu directly. forget about the bios / uefi.
<gog> lol
<zid`> qemu can't load 64bit ELF
<gog> ok. forget about it
dormito has joined #osdev
<gog> i give up for now
<heat> no
<mrvn> zid`: nothing can load 64bit ELF so that point is moot
<heat> grub can
<zid`> except uefi and grub
<mrvn> zid`: uefi loades 64bit PE
<zid`> uefi -> grub -> 32bit stub -> load lilo -> load linux -> kexec into 64bit elf
<zid`> duh
<heat> gog: are you setting up your IDT right?
<heat> in such a way that cli is already done?
<zid`> IDT shouldn't be relevent unless sti
gog has left #osdev [byee]
<heat> bye
<heat> :|
<heat> zid`: btw uefi -> load linux is directly possible
<zid`> the joke is now deeply wounded
<mrvn> zid`: and you can load that 32bit stub directly with qemu. That's what I did all the time to test the kernel.
<heat> you also can't kexec arbitrary 64-bit ELFs
<zid`> I wrote a 32bit bootstrap and add my kernel as a module in grub
<zid`> -kernel can't handle modules :(
<zid`> or 64bit elf directly
<mrvn> zid`: -kernel 32bit-stub and your kernel as initrd
<zid`> and using a 32bit elf makes fucky images that are hard to use tools on so bleh
<heat> can you not pass it -initrd?
<zid`> yea I could initrd but I'd have to rewrite what I already wrote to do that, so I just shoved grub in
<mrvn> zid`: both qemu and grub do multiboot. YOur 32bit stub wouldn't even notice.
<heat> anyway the bikeshedding is intense here
<zid`> My 32bit stub will absolutely notice if its modules disappear :P
<mrvn> zid`: you need more than the kernel as module?
<zid`> no, just the kernel
<heat> zid`, ya know you don't need to have a separate 32-bit bootstub right?
<mrvn> zid`: then it works because you pass the kernel as module.
<zid`> no shit?
<zid`> I told You that
<mrvn> heat: it's simpler with a separate stub
<heat> how?
<heat> you have to load another kernel
<zid`> grub loads it :D
<mrvn> heat: no objcpy to turn the 64bit elf to 32bit
<heat> what
<zid`> I mean, go try it, get a native 64bit elf loading without doing tricks to embed a 64bit elf into a 32bit one in grub
<zid`> if you solve that I am all ears as to how you did it
<heat> ok I did it
<heat> what now
<zid`> >all ears as to how you did it
<heat> make elf64 executable
<heat> get 32-bit entry code
<heat> use multiboot2
<mrvn> zid`: I believe modern grub loads a 64bit elf just like a 32bit elf.
<heat> party
<zid`> I don't have multiboot2, could look into it
<mrvn> heat: multiboot2 doesn't allow that, it's a grub extension
<heat> ok so it allows that
<heat> since grub is like the only implementation of mb2
<mrvn> heat: except for all the other implementations, like qemu.
<heat> they implement mb2 now?
<zid`> qemu can mb2? afaik it just hard exits if you give it a 64bit elf, claiming it isn't OVH compatible
<mrvn> zid`: it can do mb2, but not elf64.
<zid`> kinda pointless then eh? considering it checks the elf header first int hat piece of code I think having looked at it, giving you the OVH error
<zid`> ovmf?
<zid`> whatever it is
<heat> pvh
<mrvn> As said mb2, last I checked, doesn't allow ELF64. The arch is x86 and that means ELF32.
<zid`> that's the one, thanks
<heat> the arch isn't explicitly x86
<heat> you can actually run as an EFI application booted by multiboot2
<mrvn> heat: it certainly isn't ARM or MIPS
<heat> you can theoretically run x86_64 code directly since the entry point
<heat> and if that isn't ELF64 I dunno what is
<zid`> is the filesystem crap you need to do for grub2 the same, just stage2_eltorito and a conf?
<mrvn> heat: if it's efi then it's PE.
<heat> dunno I use grub-mkrescue
<heat> mrvn, it's not, it's multiboot2
<mrvn> heat: Note that, like linux, you can be PE and ELF64 at the same time.
<bslsk05> ​github.com: bootstrap/Makefile at master · zid/bootstrap · GitHub
<zid`> That's the only thing I do to prep grub, which is nice
<heat> mrvn: you can boot using multiboot2 AND still be in EFI land (aka boot services)
<heat> nothing in EFI tells you you need to use PE except for the image loader
<heat> in fact nothing tells you you need to use MSABI either, except for the EFI api
ahlk has joined #osdev
<mrvn> yeah, nothing tells you you need PE and MSABI except for all the things that do. :)
<zid`> Is hybrid mb1/mb2 possible? :D
<heat> yes
<zid`> or is it first come first serve
<mrvn> zid`: plenty of space in the first 8KB.
<zid`> it's nothing to do with space
<mrvn> zid`: you can fit both signatures in there
<zid`> it's *nothing* to do with space.
<zid`> I could fit 400 of them
<mrvn> you could, that was the point about having plenty of space.
<heat> i dont see why they would go out their way to stop it
<zid`> you have to go out of your way to make it work that's why heat
<heat> no?
<heat> if (!mb1_boot_kernel()) mb2_boot_kernel();
<heat> (probably reversed)
<zid`> see, an entire 1 line
<zid`> and it's buggy
<zid`> sounds like you went out of your way to make it work to me lol
<zid`> checking your tickets, responding to the bug report, making a patch :P
<mrvn> zid`: you can not set the ELF bit in the multiboot header and specifiy your on mb1 and mb2 entry points.
<heat> uh also
<heat> there's no issue here
<heat> it's a separate command
<heat> multiboot2 and module2 vs multiboot and module
<zid`> bear in mind I've not seen the mb2 header, but you'd expect just ordering them 2 -> 1 made it fallback nicely
<zid`> unless the code was buggy and checked for 1 before 2
<heat> code doesn't check, you tell it explicitly in the grub.cfg
<zid`> oh so you can't do real hybrids then
<mrvn> zid`: hey, you didn't say you want to prefer one over the other. That's a totally different issue.
<zid`> automatic hybrid
<zid`> the image has to be different
<heat> zid`, why do you want mb1 support anyway? it's pretty dead
<heat> mb2 is also horribly dead but that's another issue
<zid`> because I happen to know it and support it
<mrvn> zid`: are you 100% sure you are not meaning mb2?
<zid`> mrvn: i'd appreciate it if you didn't second guess *everything* I said, making me repeat everything 3 times, ngl
<zid`> This is like.. the 5th time in this single convo
<mrvn> zid`: the specs are a bit confusing about what is mb2. And the first multiboot has been dead for a decade or so
<zid`> I've never even seen the mb2 spec
<heat> except for osdev
<zid`> Which I stated
<zid`> out loud, you were here
<heat> mb2 is pretty freaking dead too
<heat> everyone is on proprietary boot protocols or UEFI
<zid`> I've never even owned an install of grub2
<mrvn> zid`: unless you read the V0.96 specs or whatever it is and didn't realize that's mb2
<heat> what
<zid`> what, I installed grub 20 years and and left it there? :P
<heat> jeez
<heat> update that
<zid`> It.. works fine?
<heat> old
<heat> also had CVEs
<zid`> is that CVE the 'press e' CVE I keep hearing about
<zid`> I know it exists but it's annoying to patch
<heat> anyway beautiful bikeshedding we're doing here
<zid`> I mean, it was supposed to be me asking you if mb2 would let me do what I wanted
<zid`> but you didn't know how to install grub 2, and mrvn kept distracting everything
<heat> if you want to support mb2, you can; it's pretty dead, like all multiboots ever, but it's better
<bslsk05> ​github.com: Onyx/iso.sh at master · heatd/Onyx · GitHub
<zid`> yea I don't actually have grub as a dep on my stuff the way I do it, just mkisofs
<zid`> so I wanted to know how to do it manually
<bslsk05> ​github.com: Onyx/build_grub_efi_image.sh at master · heatd/Onyx · GitHub
<bauen1> iirc klanges bootloader is somewhat mb (or mb2 ??) compatible, so it's not that dead, there's at least two implementations i know of :D
<zid`> hmm, looking at mb2 spec, it's really similar
<zid`> but apparently.. still 32bit?
<heat> gives you a .efi you can use
<heat> zid`, yes
<heat> it's very different though
<heat> completely different way of parsing things
<heat> it can also give you a bunch more stuff
<zid`> at least they rewrote it not to use negative indexing
<zid`> I only use the e820 and module list (to get the kernel elf, which I may not need this way)
<heat> it can pass you the EFI runtime table, it can give you the RSDP (which you need if you're on UEFI)
<heat> also it can relocate the kernel in physical memory for you
<zid`> never touched uefi, don't have the tooling for you
<zid`> and I don't need it to relocate me I just need a stub that maps -2GB to phys_load_addr and enters long mode
<mrvn> " The field ‘architecture’ specifies the Central Processing Unit Instruction Set Architecture. Since ‘magic’ isn’t a palindrome it already specifies the endianness ISAs differing only in endianness recieve the same ID. ‘0’ means 32-bit (protected) mode of i386. ‘4’ means 32-bit MIPS.
<mrvn> " The official specs don't even list ARM or PPC.
<heat> ok
<zid`> so atm I just have a stub that'd be there either way given a 32bit entry point, but becuase of mb1 they're split into two files
<zid`> rather than embedding one into the other
<heat> you can have 32-bit code inside a 64-bit elf
<zid`> yes
<zid`> >rather than embedding one into the other
<mrvn> zid`: that part is 100% identical with mb2. You just parse the boot infos differently and have a few new options for efi.
<zid`> which is what this line signifies
<heat> in mb2 since it can load ELF64s you don't need an objcopy, you don't need anything
<heat> just make your cute little elf64
<heat> and boot it
<mrvn> heat: mb2 can't load ELF64, only grub can
<zid`> what sorta page tables do I get?
<heat> none
<mrvn> zid`: none, it's still 32bit on entry. You still need the stub
<zid`> So I get a 32bit entry?
<heat> the boot state is the same as multiboot
<zid`> yea so literally the only difference
<zid`> is whether one is inside the other or not
<heat> sí
<zid`> so Cons: I have to rewrite it, I lose multiboot support
<zid`> Pro: One small files ends up inside another
<heat> you don't need a separate stage
vin has joined #osdev
<mrvn> zid`: you don't have to include it. The benefit for you could be to have a EFI stub as alternative.
<zid`> I could write an EFI stub regardless though?
<heat> you get more portability (because you can't legally scan the RSDP in UEFI)
<mrvn> zid`: efi + mb1 doesn't work.
<zid`> what
<zid`> why would I need *both*
<zid`> I said I could write an *efi* stub
<heat> well you can
<zid`> not.. do silly hacks to boot my mb1 stub via efi.
<heat> but the efi stub is also a silly hack
<mrvn> zid`: oh, you mean a real efi PE stub. You don't have the tooling for that.
<zid`> Yes, so I won't, but I could
<zid`> mb2 won't change that point
<mrvn> zid`: I meant you can write an mb2 stub that copes with EFI tags.
<heat> ok so, why would you want mb2: it's like mb1 but portable
<mrvn> zid`: efi -> grub-efi -> mb2
<heat> and boots you in BIOS systems and EFI systems without a need to write a silly EFI stub
<mrvn> zid`: no need for new tooling there
<zid`> Okay that's an actual reason :D
<zid`> so maybe if I ever go toward efi I will make mb2 handle the efi parts
<heat> there are no explicit EFI parts for booting, really
<zid`> someone still has to make a valid efi image
<zid`> and it isn't going to be me
<heat> no.
<mrvn> zid`: grub-efi did that
<zid`> so if grub wants to include one on their end in grub2 and chain load my crap, I'm willing to let them
<zid`> mrvn: yes, welcome to the conversation
<zid`> it was even your suggestion
<heat> the only difference for efi in mb2 is that it can pass you the runtime table (so you can write variables and whatnot)
<zid`> not sure you how you forgot
<heat> but you don't really realistically need that unless you're installing a bootloader
<zid`> yea I won't actually *touch* the efi crap
<zid`> but if I ever want to be bootable from an efi env, I will just let grub2 do it
<zid`> via, as mrvn loves repeating, efi-grub :p
<zid`> grub-efi*
<heat> okay no, there's a small adjustment: mb2 passes you the rsdp
<mrvn> and you want to exit bootservices
<heat> it saves you from scanning memory and it's the only way to get the rsdp in UEFI (it's not definied to be in any memory region)
<zid`> that's completely fine
<zid`> why are you suddenly trying to talk me *out* of grub2/
<mrvn> all crap you handle in your stub
<zid`> You were the one trying to talk me into it
<mrvn> heat: have you tried booting a ELF64 with mb1 signature in grub?
<heat> yes
<zid`> adding a sometimes-null pointer to a copy of the rdsp to pass to acpi_init isn't much of a deal
<mrvn> heat: and?
<heat> it does not do the beep boop
<zid`> if(p) parse_rsdp(p); else parse_rsdp(find_rsdp());
<mrvn> heat: who added ELF64 to the mb2 code without adding it to the mb1 code too? That's just stupid.
<zid`> it's all stupid
<zid`> nobody wants to take charge of dealing with page table prisons
<heat> zid`, parse_rsdp(p ?: find_rsdp())
<heat> ftfy :P
<zid`> no thanks
<zid`> I'd actually just re-assign the pointer irl
<zid`> if(!p) p = find_rsdp(); parse_rsdp(p);
JanC has quit [Remote host closed the connection]
JanC has joined #osdev
gog has joined #osdev
<geist> right, and even after the if you can check that it's not still null
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
<heat> i've found that on OVMF you can even find bogus rsdp's if you search through memory
<gog> ok so i've narrowed it down to _when_ it happens, and it happens after i tell PIC0 the ICW1, the IMR and IRR are cleared to 0, RFLAGS.IF is clear
<gog> and then booop, cpu gets vectors to e=00
<zid`> heat: bogus as in, the string rdsp, or bogus as in matching checksum?
<gog> even with RFLAGS.IF clear
xenos1984 has quit [Remote host closed the connection]
<gog> i have verified that they are clear before the command is sent to the pic
<zid`> The former you'd sorta expect just from.. the code that filled out the rdsp maybe doing mov eax, rdsp so it appears in the .text of your bios somewhere or whatever
<heat> zid`, can't remember. but it's totally undefined
xenos1984 has joined #osdev
<heat> you're not actually going through fw .text when you search
<zid`> If the checksum matches then that's just a boog
<heat> gog, how do you get interrupt 0?
<zid`> that's error code 0
<gog> no, it's interrupt 0
<zid`> oh did I misread
<gog> or rather, it's either 00 OR f0 depending on when the CPU gets vectored
<gog> if it's after the PIC is remapped it's f0
<_eryjus> interrupt 0 not IRQ0
<heat> no it's not
<heat> it's error 0
<zid`> kek
<heat> the v= says the vector
<gog> ok
<gog> in the two times i was able to trigger it i got both
<heat> wait you still get v=00?
<gog> v=00
<gog> and v=f0
<gog> the first time was before the pic was remapped
<heat> wtf
<gog> the second time after
<heat> wtf
<heat> wtf
<gog> yes
<heat> this is cursed
<gog> and RFLAGS.IF is clear
<gog> this is because the timer is firing
<gog> but why is the CPU getting vectored????
<heat> conspiracy theory
<gog> i have triple and quadruple checked RFLAGS
<gog> and i can make this happen consistently if i step it with gdb
<gog> but sometimes it happens before and sometimes after PIC irq_base is changed
heat_ has joined #osdev
<heat_> cheers internet
<heat_> <heat> you're not programming the PIC correctly, the PIC's base is 0 and the internal qemu/KVM code doesn't check for IF in interrupts within the exception range
<heat_> this is my conspiracy theory
heat has quit [Ping timeout: 250 seconds]
<gog> but how do i avoid it? when you send ICW1 the irq_base and imr get cleared
<gog> and evn still, it happens after the irq_base is set sometimes
<gog> and the interrupt output shows v=f0
<zid`> I mean, these should all just set some 'pending' pins
<zid`> which you are ignoring because cli
<zid`> it shouldn't affect internal cpu sstate, it's emulating an external chip that has an interrupt line
<bslsk05> ​github.com: Onyx/pic.cpp at master · heatd/Onyx · GitHub
<heat_> try that
heat_ is now known as heat
<gog> that's exactly the same as what i do except for the offsets
<heat> well does it work
<zid`> I don't even do the io wait, I doubt anything that can do long mode is not gunna handle 1MHz :P
<heat> yeah that's like stolen directly from the wiki
<zid`> but yea, exact same values, but I did write them myself from a document!
<zid`> I learned about the ICW1 ICW2 blah blah
<heat> my pic.cpp files has cobwebs
<bslsk05> ​github.com: boros/interrupt.c at master · zid/boros · GitHub
<zid`> the bottom bit probably isn't needed, but I figure it cou;ldn't hurt
<heat> no need for the nops
<heat> ok maybe technically one nop I think
<heat> but not 2
<heat> (in practice, 0)
<zid`> gotta be safe though!
<bslsk05> ​gist.github.com: gist:85cc9a148c43ed0f4ae32b7578d2c5cc · GitHub
dormito has quit [Quit: WeeChat 3.3]
<zid`> are you 100% sure it isn't the lidt doing it
<zid`> that's the only thing that should be messing with selectors
<zid`> and is relevent to pic code
<gog> :| wait why is rflags 0x2xx
<zid`> time to.. add random while(1)s to check? :P
<heat> oh wait good point
<heat> lol
<gog> ok apparently interrupts are enabled here omg i'm a dumbass but when
<zid`> Time to add a while(1) approximately half way between this code and entry point :P
<zid`> after greeping source for sti I guess
heat_ has joined #osdev
<heat_> oh fuck off
<heat_> why is my internet garbo on linux
<zid`> heat: I'll sell you some internet if you like
<heat_> <heat> --> irq_unlock --> sti
<heat_> <heat> gog checkmates gog
<heat_> <heat> here
<bslsk05> ​github.com: sophia/task.c at 5fc386102380e6c15c81df4fd750f54641535eaa · adachristine/sophia · GitHub
xenos1984 has quit [Remote host closed the connection]
<heat_> heat, fuck you
heat has quit [Ping timeout: 250 seconds]
heat_ is now known as heat
<heat> danke
zid` is now known as zid
<gog> heat: nope
<gog> it's happening during memory_init somewhere
xenos1984 has joined #osdev
<bslsk05> ​github.com: sophia/irq.c at 5fc386102380e6c15c81df4fd750f54641535eaa · adachristine/sophia · GitHub
<gog> what you pointed out is where irqs are supposed to be re-enabled
mrvn has quit [Ping timeout: 256 seconds]
<zid> mmu_get_map
<heat> i guarantee you its in one of those functions
<zid> enables interrupts
<zid> that seems.. strange
<heat> you can't irq_lock and irq_unlock just like that
mrvn has joined #osdev
<heat> you need to save state
<heat> unsigned long flags = irq_save_and_disable(); irq_restore(flags);
<bslsk05> ​github.com: Onyx/irq.h at master · heatd/Onyx · GitHub
<gog> oh fuck that's what did it
<zid> memory_init
<zid> is the callchain
<gog> yep
<zid> memory_init -> init_create_page_array -> pm3 -> pm4 -> get_map_page -> irq_unlock -> sti
<zid> or something
<heat> you don't need to disable interrupts btw
<heat> in that specific part
<heat> implement a spinlock
<gog> idek why i did irq_lock and irq_unlock there
<heat> gog still checkmates gog
<zid> this is why you shouldn't write code
<zid> Just, in general.
<gog> yeah
<mrvn> gog: you should implement macros to do RAII
<zid> Leave everything unimplemented then it can't be implemented badly.
<gog> i'm a terrible programmer
<heat> you know what would stop this?
<zid> That's my trick, anyway
<heat> rust
<heat> rewrite it in rust
<zid> I mean.. no it wouldn't? :P
<heat> why would it not
<zid> asm("sti"); in the wrong place is always going to enable interrupts
<zid> not a lot you can do about that
<heat> rust saves everything
<zid> ah sorry my mistake
<mrvn> zid: hard to do that accidentally
<heat> rust made me fertile again
<zid> Rust cured my baldness
<zid> now my hair is filling my room and suffocating me, help
<mrvn> zid: knot a rope and climb out of the window
<zid> I'm not sure that's how topology works
<zid> if you tie your own hair to yourself then jump out of a window
<zid> you're going full eggshell
<mrvn> who said jump? I said climb
<zid> yea sitll not 100% sure you see the problem
<gog> well i fixed it now
<gog> thanks everybody for trying to help even though i insisited the problem wasn't my code :|
<zid> I believed in you.
<zid> (That you'd put an sti somewhere and forgot, I 100% believed this)
<gog> in my defense i've been on some mildly powerful painkillers?
<j`ey> *brainkillers
<zid> yes that is worrying, why not proper full strength ones that let you see time
<heat> you can write rust on those
<heat> C? not so much
<zid> rust kills pain anyway
<zid> It makes you invulnerable to stabbing weapons too
<gog> they wouldn't give me the good shit
<heat> i believe that if you find a bug you should rewrite code in rust, and every code has a bug if you look hard enough
<zid> The trick is to mention your rampant painkiller abuse as a teenager
<zid> and how high your tolerance is
<gog> lol
<zid> see how rewarding not lying to your doctor is
<gog> i'll never not lie again
<gog> i mean, i'm always going to tell the truth from now on :)
<zid> If I asked the other guard, how would he respond?
<gog> he would t-- li----
<gog> ¯\_(ツ)_/¯
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
masoudd has quit [Ping timeout: 252 seconds]
mahmutov has quit [Ping timeout: 252 seconds]
sonny has joined #osdev
sonny has left #osdev [#osdev]
<clever> geist: oh, random idea, related to superscalar processor talk from earlier, could the i-cache also be caching a pre-decoded form of opcodes, and tracking what opcodes are non-conflicting?
<mrvn> clever: would that be worth it? Each bit is expensive in i-cache
<clever> mrvn: was thinking more that instead of an icache slot holding a 32bit opcode, it would hold a pre-decoded result, so the pipeline can be 1 stage shorter
<clever> the slots would just be a different size
<clever> and yeah, that may wind up using more bits per 32bit addr
<mrvn> How would that work with branch targets? The opcode could conflict with any of the opcodes before a jump to the target.
<clever> anything + branch will basically not conflict, since the branch is just setting PC
<clever> and whatever you jumped to, runs in another clock, and gets checked seperately, as another opcode pair
<clever> and pc-relative stuff just has to use the right pc, from that anything+branch pair
<heat> hmm
<heat> why is tcg so much slower than rosetta?
<zid> It has to open loads of card packs to get the opcodes it needs
<mrvn> Say you have: op1; l: op2; op3; b l op1 and op2 don't conflict but op3 and op2 do. But you cached that op2 has no conflicts and just run it after the branch and BOOM
<clever> mrvn: i was thinking, you could have a bool that kind of exists between addresses
<clever> so it would be more like op1, bool1, op2, bool2, op3
<clever> bool1 means op1/op2 dont conflict
<clever> and bool2 means op2/op3 dont conflict
<clever> so any time you get to an address, you can check the bool between addr and addr+1, and then run both opcodes at once
<mrvn> op1; l: op2; op3; op4; op5; b l, op5 ... op3 might conflict while op1 op2 op3 does not.
<clever> mrvn: i would consider `b l` to be another opcode, and it can only run `op5 + b l` in a given clock
<mrvn> clever: you can't just look at the opcode before to determine conflicts.
<clever> so op2/op3 doesnt come into play until after the branch
<clever> i'm thinking conflicts in terms of running 2 opcodes in the same clock, not conflicts from running it back2back in 2 clocks
<mrvn> clever: so you limit yourself to a CPU that can decode at most 2 opcodes?
<clever> if its dual-issue, and can run 2 at once, and has no ooo
<mrvn> clever: if you are limited to 2 and always in fixed pairs then that would work.
<mrvn> clever: if you execute "b l + op2" then you have to ignore the cached bit.
<clever> that starts to get into branch prediction, but if those are in the same cache line, i could see how you could pre-determine that the branch is to a fixed or predictable addr, and that `op2` doesnt conflict
<clever> and store that in the cache line
<mrvn> clever: if you don't have some complex "decrement reg + jump if > 0" opcode then I guess a branch can never conflict with anything.
<clever> addcmpbne r10,-1,0x0,c40086f8 <set_pll_freq+0x1c2>
<mrvn> yeah, you are screwed with that one
<clever> this is an opcode ive used on the VPU (and gcc uses it too), add, compare, branch not equal
<clever> in this case, its basically `if (r10-- == 0) goto` but i may have the -- on the wrong side
<clever> ah, and !=
<mrvn> I think on early alphas the cpu would decode 2 opcodes at a time but always an aligned pair. Branching into the middle of a pair would waste the first slot.
dormito has joined #osdev
<clever> that gives me an idea
<heat> addcmpbne is absolutely spooky
<clever> the VPU is dual-issue, and i have observed 2 opcodes running in the exact same time as 1 opcode could run in
<clever> but, if i change the alignment, what happens?
<clever> i'm guessing nothing in this case, since it accepts 16bit, 32bit, 48bit, and 80bit opcodes
<clever> alignment is already whack
<mrvn> m68k had a decrement and branch, an "if (i-- > 0) goto label"
<clever> arm has it far better
<clever> addcmpbls r1,r6,r0,c4008f64 <novm_free_pages+0x44>
<clever> the thing your adding can also be another register, and it supports different conditionals
<mrvn> There is a reason why modern cpus are basically all RISC and not CISC
<clever> oh, and its even comparing to a register, not an immediate
<mrvn> immediate takes too many bits
<heat> x86 is cisc?
<clever> `addcmpbne r9,-4,r6,c4002f6e` and it can do more then +1 or -1
<zid> No modern cpus are risc in the least
<mrvn> heat: x86 is also from the stone age. And most x86 cpus translate to risc internaly.
<heat> arm64 is also really un-riscy
<clever> mrvn: keep in mind, the VPU has 16bit, 32bit, and 48bit opcodes, to allow the immediate to grow
<heat> >modern CPUs
<heat> the fastest, most modern CPUs are x86 ones
<zid> everything violates at least one definition, if not almost all of them at the same time
<clever> `mov r0, 0x12345678` can trivially accept a 32bit immediate, by just using a 48bit opcode
<clever> zid: how does arm/thumb violate risc?
<zid> complex instructions
<mrvn> zid: stop seeing just black and white
<zid> stop strawmanning
<zid> >everything violates at least one definition, if not almost all of them at the same time
dmh has quit [Quit: ZNC - https://znc.in]
<clever> zid: got an example of a complex opcode in arm?
<zid> What made 'risc vs cisc' a thing was that risc cpus had very dumb opcodes they could run up to the speed of the memory
* mrvn fails to find a "solve this quadratic equation" opcode in ARM.
<zid> we have *incredibly* slow memory now, relatively
<zid> so now all these "it's totally risc I swear" cpus now have huge icaches and complex instructions
<bslsk05> ​developer.arm.com: Documentation – Arm Developer
<clever> zid: 6502 opcodes where pretty damn dumb from what i can remember
<zid> other than the 14 addressing modes?
<clever> oh, right, lol
<mrvn> heat: well, to be fair CRC32 is a rather simple instruction.
<zid> bye goalposts
<clever> zid: ah, but those are also optional extensions, the rpi soc for example doesnt have any of the crypto opcodes
<clever> so it depends on which implementation your talking about
<mrvn> All the vector opcodes are probably a bigger risc violation
<zid> not saying you can't build a more riscy version of an arm isa'd cpu by cutting out more of the complex crap
<zid> but it has icache so you're always fighting an uphill battle
<clever> i still think arm is far more risc then x86, because the opcodes are all the same size
<mrvn> Maybe it's easier to talk about load/store architecture vs. tons of opcodes that access memory directly.
<clever> no guessing game of where an opcode starts
<zid> yea it's more riscy in that it shares design elements with actually risc cpus from the 70s
<bslsk05> ​developer.arm.com: Documentation – Arm Developer
<zid> but none of them are actually risc
<mrvn> clever: That's my strongest indicator for being risc: the fixed opcode size.
<heat> riscv has no fixed opcode size
simpl_e has joined #osdev
<j`ey> cisc-v then
<mrvn> heat: riscv is a lopad/store arch, right?
<heat> yes
<nomagno> heat: I just took a look at RV32I yesterday and I didn't really get that impression
<nomagno> It has variable length instructions, but it's fairly easily decidable
<clever> nomagno: thumb vs arm32 kind of has similar?
<zid> risc is a dead term since the 80s
<nomagno> No, my bad... It has 32-bit fixed size instructions? See I never understood this
<zid> nothing has been risc, we're just on a very narrow window of 'extremely cisc' and 'almost entirely cisc' :p
<clever> where opcodes can be either 16bit or 32bit, and bit0 of the addr (during a branch) signals what size your using
<mrvn> clever: never used thumb on arm.
<clever> mrvn: when mixing, the assembler will tag each function as thumb or arm, and the linker will then set bit0 of the addr to tell the cpu if your branching to thumb or arm code, you can then freely mix both in any 32bit arm binary
<nomagno> How can you fit 32 bit address space in 32-bit fixed size instructions?
<clever> gcc can be told to generate thumb or arm, -mthumb i think it was
<nomagno> You can never refer to the entire address space
<kazinsal> register indirects
<mrvn> nomagno: by not having any 32bit immediates
<clever> nomagno: arm solves that with ldr, where you load a 32bit constant from a pc-relative address
<clever> and then you have a small table of 32bit constants after each function
<mrvn> nomagno: you can't actually access memory by address, only by register.
<clever> yeah, ldr just puts that 32bit constant into a register
<clever> and then you load by addr in reg
<nomagno> That sounds very cumbersome
<mrvn> Or you load the high and low 16 bit values in 2 opcodes.
<clever> nomagno: the assembler generates the constant table automatically
<mrvn> nomagno: you hardly ever have a fixed address to access. You usualy access some pointer you have in a register with a small offset.
<nomagno> I went for an extremely simple approach for my P-code CPU: 0 operand instruction -> 1 byte; 1 operand instruction -> 3 bytes; 2 operand instruction -> 5 bytes;
<clever> nomagno: `ldr r8, =SLCR_BASE` for example, says that you want the addr of a symbol in r8, the assembler will generate a constant table later in the .o, and then generate a pc-relative load opcode
<mrvn> nomagno: remember: RISC was designed so the compiler can generate fast code. Not for you to have nice ASM.
<nomagno> mrvn: that's fair
<clever> so the above turns into a pair of 32bit products, one in your .text, and one in your .ltorg (literal origin)
<mrvn> nomagno: looking at it in C term you can't do *(int*)0x1234 = 23; You have to do: int *p = 0x1234; *p = 23; It's not really hard to write asm for ARM.
<mrvn> 99% of the time you need p a few times in a function and would make that variable anway.
xenos1984 has quit [*.net *.split]
heat has quit [*.net *.split]
rorx has quit [*.net *.split]
PapaFrog has quit [*.net *.split]
woky has quit [*.net *.split]
LambdaComplex has quit [*.net *.split]
kleinweby has quit [*.net *.split]
onering has quit [*.net *.split]
<clever> and we lost the heat!
<clever> i just fixed the furnace too! lol
xenos1984 has joined #osdev
rorx has joined #osdev
LambdaComplex has joined #osdev
PapaFrog has joined #osdev
woky has joined #osdev
kleinweby has joined #osdev
onering has joined #osdev
<clever> weird, still isnt back, lol
<zid> The highest order CISC cpu has exactly one instruction 'dwiw', pronounced 'do what I want'
<gog> need that cpu
<klange> I am going to put the RPi away until the weekend. I am growing aggravated over... presumably caching.
<clever> klange: the 2d scan-out isnt coherent with the arm caches
<clever> so you need to either write-combine or cache-flush for the framebuffer to become visible
[itchyjunk] has quit [Ping timeout: 272 seconds]
<clever> and if your doing any kind of dma from hw->ram, you have to discard the arm caches for the area dma wrote to
<graphitemaster> Should've put it away last weekend, that way this weekend you could've saved on time.
<graphitemaster> Cached RPi
[itchyjunk] has joined #osdev
matrice64 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<geist> re: mixed 16 and 32 bit instructions. riscv does a good job with it. the bottom few bits of the opcode itself is the size of the instruction
<mrvn> clever: isn't that normal for frame buffers?
<geist> so it actually fairly nicely mixes the two,much better than thumb did
<zid> how do you find them if they're at the bottom
<geist> little endian
<zid> I always neglect to consider that a cpu might store things as *words* in a VLE
<mrvn> Can you do 16bit 32bit 16bit?
<geist> yes
<zid> being sane, and all
<moon-child> VLE?
<moon-child> variable length encoding?
<zid> variable length enc
<clever> mrvn: i thought that x86 dma was almost always coherent with the caches, but that framebuffer tends to be in gpu ram, so the card isnt actually using dma normally
<geist> so for example you get pretty good usage of it:
<bslsk05> ​IRCCloud pastebin | Raw link: https://irccloud.com/pastebin/raw/cZ6yjwli
<geist> just an arbitrary slice of riscv code
Mutabah has quit [Ping timeout: 256 seconds]
<nomagno> My CPU is... Uh, big-endian, 8-bit words, pure Harvard architecture, 16-bit address space, 16 instructions {halt, nop, set, jmp, jcz, jcnz, add, sub, cmp, and, or, xor, rot, func, ret, call}. Instructions are composed of: [literal/pointer mask (4 bits), opcode (4 bits), 0-2 operands (16 bits each)]. Each operand can be an address which is read from / written to, a literal (usually only the lower 8 bits go used in this case, but for jumping the full
<nomagno> 16 go used), or a pointer (Interpret the ((ADDRESS << 8) | (ADDRESS+1)) as an address). No registers or anything
<mrvn> clever: well, x86 is quite the execption with coherence.
Mutabah has joined #osdev
<nomagno> As you can see... It's quite non classifiable in terms of physical/real RISC/CISC distinction
<geist> re: getting large values into registers on riscv, line 22 and 23 in that paste is a good example of that
<geist> ie, auipc/addi pair
<zid> nomagno: The classification I would use is "micro", where it doesn't apply
<mrvn> nomagno: I would say that is clearly CISC
<mrvn> nomagno: not load/store, not fixed opcode size, complex address modes
<geist> from that descriptio, sounds like a lot of mainframes and minis in the 60s and 70s
<geist> that particular pattern of word with opcode + register + immediate/address i've seen a lot
<geist> ie, say PDP-10 or so
<geist> though actually re-reading what you wrote that's variable sized instructions, which is different than what i just dedscribed
<nomagno> It's fairly fun to toy around with specially because I provide a preprocessor script along with the VM implementation
<nomagno> I guess it's fine for what it's meant to: User generated content engine
matrice64 has joined #osdev