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=4
02:25:00 <ZetItUp> with PE file's, it says it need to be put at a location X in virtual address space, do i need to reserve some space which is only for PE files, or am i overthinking it and it is fine to put it at any location, just add it to the image base address?
02:26:00 <ZetItUp> im just wondering about, what if two or more files wants the same virtual address
02:28:00 <clever> ZetItUp: if runtime relocation data is included, the dynamic linker can patch the binary as it moves it to a different address
02:28:00 <moon-child> ZetItUp: each process gets its own personal virtual address space
02:28:00 <clever> windows will also cache the patched versions somewhere, to speed that up
02:29:00 <clever> and yeah, each process gets its own private virtual space, so a collision can only happen between 2 dynamic libraries loaded by the same process
02:29:00 <ZetItUp> ooh that makes sense
02:29:00 <clever> but that relocation patching can prevent sharing of the read-only chunks of a .dll
02:29:00 <clever> so the system winds up having to store 2 copies of the same .text
02:30:00 <clever> in ram
02:31:00 <ZetItUp> yeah i was thinking of having some kind of lookup table in memory which has the name and at what address the file is located at, not sure if that would be a good design thou
02:32:00 <clever> cygwin will also track what virtual address it has used in every dynamic library it builds
02:32:00 <clever> and ensure there is no collisions between any lib it produces
02:33:00 <clever> that then entirely eliminates the need to do runtime relocation
02:33:00 <clever> but thats only really feasible on a 64bit system
02:34:00 <ZetItUp> i wonder if that would cause any errors in multi-threading though, if like several processes uses the same memory location for a library
02:34:00 <ZetItUp> be careful with locks i guess hehe
02:36:00 <moon-child> yeah, starting up a process is rare/slow enough that even if you go for fine-grained concurrency, lock on cache miss is fine
04:26:00 <gorgonical> That's the feeling we're all looking for -- the "holy shit it works!" moment. After like four days I got it lol
04:26:00 <AmyMalik> idk, i'm just looking for the feeling of soft fuzziness
04:27:00 <gorgonical> I have that feeling too from my wool socks
04:29:00 <AmyMalik> I mean like, a feeling like "I'm safe here"
04:36:00 <Affliction> geist: I'd expect it would free the bus to allow the controller to talk to another bank group or rank? Could make things faster that way.
04:36:00 <Affliction> Assuming DDR5's addressing works the same way, maybe I should actually look into how it works at some point
07:37:00 <geist> hmm, yeah
07:37:00 <geist> re: the overlapping zeros
07:37:00 <geist> cpus definitely know about writing zeros optimally, so it should be easy to wire up
07:38:00 <geist> actually wikipedia says the DDR5 thing is even more intersting. there are something like 256 registers on the chip, and you can tell it to write the contents of one of them
07:38:00 <clever> i saw something about that in the arm docs
07:38:00 <geist> so presumably that means you can fill in whatever bit pattern you want ahead of time
07:39:00 <geist> clever: yah ARM and now AMD explicitly have zeroing instructions, thouh i have no doubt that other arches already have ways to sense that a cache line is full of zeros and bypass certain steps
07:39:00 <geist> it would be easy enough to at least sense a zeroed cache line
07:39:00 <clever> what did arm call it again?
07:40:00 <geist> the arm64 instruction is `dc zva`
07:40:00 <geist> dunno if they back ported it to arm32, came along in armv8
07:40:00 <geist> AMD now has `clzero`
07:40:00 <clever> ah
07:40:00 <clever> that feels different from what i saw before
07:41:00 <geist> that's explicit zeros at least. i wouldn't be surprised if they sense a zero automatically in some cases. especially x86 where you have a rep stos you can fairly easily detect a zeroing operation
07:41:00 <geist> the big difference i think with dc zva and clzero is they explicitly write thru the cache
07:44:00 <clever> but i did stumble upon the vector opcodes in the armv7 docs, i should look into that later
07:45:00 * clever checks something
07:45:00 <clever> one of the rpi engineers claimed that NEON should be faster then the VPU vector stuff (but my math shows 1.5 mill/sec vs 6.6 mill/sec)
07:46:00 <clever> but they also appear to be mixing up the different vector things the rpi can do (vpu vs 3d core)
07:46:00 <clever> and i dont know how well optimized the gnuradio neon code is
07:46:00 <clever> i feel like some hand-optimized neon asm would give a more fair comparison of the 2
07:47:00 <geist> yeah
07:47:00 <clever> because it feels wrong, that a 500mhz single core with vector extensions
07:47:00 <clever> can out-compute a cortex-a72? in aarch64 mode at 1.8ghz
07:48:00 <clever> but also, that 1.5 million sample/sec, was running the whole gnuradio pipeline, and using float based math
07:48:00 <clever> while the 6.6 million/sec, is based on profiling 10k runs of the function, computing cycle cost, and dividing with clock rate, and using int16 math!
07:48:00 <clever> and assumes the L1 cache will play ball
07:49:00 <clever> so i'm both comparing vectors of floats to vectors of int16, while also stripping a large amount of the complex problem out
07:50:00 <clever> but sleep time first
07:51:00 <clever> geist: oh, and one last thing, what are your thoughts on getting ext4 write support? push that off until later or try to include it in the same pr?
07:51:00 <geist> well, both. getting write is great, but also breaking things into a series of CLs would be great
07:51:00 <geist> uber CLs are always hard to deal with
07:53:00 <clever> and i cant cheat like grub does, modifying only the data blocks
07:53:00 <clever> because my intended goal requires creating files where the name isnt known ahead of time
07:53:00 <geist> it's a *substantial* amount of engineering
07:53:00 <geist> hence why getting things in as pieces is helpful
07:54:00 <clever> basically, i want to boot a file on a random rpi, and then dump everything of use (otp, maskrom), to a file on the sd card, named after the serial#
07:54:00 <clever> extracting hex out of the uart and turning it back into binary is a pain
07:54:00 <clever> creating binary directly on the card would make it so much simpler
07:55:00 <clever> i can think of several layers that would be involved, 1: selecting free blocks, 2: creating the extent tree to reference the data blocks, 3: updating the directory listings, 4: updating the free space maps
07:56:00 * clever heads off to bed
08:58:00 <HeTo> via rep stos*, x86 has had instructions for filling the memory with a certain bit pattern since the beginning
11:04:00 <Maka_Albarn> anyone know what's up with osdev. org?
11:06:00 <klange> it's definitely quite unhappy
11:07:00 <ThinkT510> timed out for me
11:08:00 <Maka_Albarn> same
12:06:00 <junon> Yeah :(
12:06:00 <junon> Who hosts it?
12:08:00 <klange> It's all a single Linode instance run by chase [who is not here and does not generally do IRC these days]
15:37:00 <Ermine> Uh oh
16:10:00 <ksp> Hello
16:17:00 <ksp> Epic ping failure
16:29:00 <kingoffrance> if they pinged back, youd know their ip is real </sarcastic security>
16:43:00 <ksp> Yeah true
17:46:00 <ksp> RISC-V phone running FreeBSD based OS 🗿
19:23:00 <sikki> Anyone know how to load a custom kernel(as simple as writing Hello World to UART) at the addres other than default(0x80000
19:23:00 <sikki> on raspberry pi 4
19:26:00 <sikki> I have simple kernel which can write hello world to UART only if it was loaded at 0x80000, it doesn't run at other addresses
19:26:00 <sikki> but standard kernel is able to run at 0x200000, how is that possible?
19:28:00 <sikki> I have also tried changing the load address in the linker, but still, it only runs if both address(in linker and config.txt on rpi) are 0x80000. How can I load it at different addresses.
19:30:00 <clever> sikki: there is a config.txt flag to set the load address
19:30:00 <Maka_Albarn> can anyone tell me how to handle the fact that the APIC accepts interrupt vectors ox10-0x1F when those are Intel exceptions?
19:30:00 <clever> sikki: you also need to tell the linker what address you will be loading at, or write pure PIC asm
19:46:00 <geist> and/or you could write some PIC asm at the very start of your kernel that relocates itself via copying to final location and then branching into it
19:46:00 <geist> it's tricky to do the first time, but quite simple once you understand it
19:52:00 <chibill[m]> is the wiki acting really weird for anyone else? It keeps every now and then hanging when changing what page I am on then timing out.
19:53:00 <sikki> I have wrote the load address in the linker script at the start and also in kernel_address in config.txt
19:54:00 <sikki> @clever, can you elaborate further on kenrel relocating itself? or point me towards the resources to learn more about it.
19:57:00 <geist> chibill[m]: i think it's been down most of the day
19:57:00 <geist> suprised you're getting anything at all
19:58:00 <chibill[m]> It works on and off right now.
19:58:00 <geist> yah wont even load for me
20:01:00 <chibill[m]> I am actually working on writing the code for my Homebrew CPU / Computer. Using what I learned from OS Dev to make the design for some of the hardware like the screen.
20:04:00 <clever> sikki: option 1, write your kernel to be 100% PC-relative, so it doesnt care about whre its loaded
20:04:00 <clever> sikki: option 2, use some PC-relative code to copy it to the right address on startup
20:05:00 <clever> sikki: option 3 (what most things do), use some PC-relative code to configure the MMU, so it looks like it was at the right address the whole time, without moving it
20:05:00 <ksp> Oh hello
20:16:00 <sikki> @clever, for option 1, how can it be done? Even if I don't sepecify any address in the linker script, it doesn't run at address other than 0x80000. Can option 1 work for raspberry pi 4, it's default address is 0x80000 for 64 bit kernels.
20:18:00 <clever> sikki: you need to only use opcodes that are pc-relative
20:24:00 <Maka_Albarn> repeat question: how do you remap irq's 0-7 with the apic?
20:24:00 <Maka_Albarn> make that 0-15.
20:35:00 <ksp> Hello
20:39:00 <geist> Maka_Albarn: the ioapic? I think the base register is just in there somewhere
20:39:00 <geist> ksp: hola
20:40:00 <kazinsal> should put that on my to-do list for vacation coding
21:54:00 <geist> i assume the bios maps the ioapic to somewhere reasonable at boot, never looked into it
21:55:00 <geist> also.. now that i think about it it may be that you can configure each vector independently. now that i remember it i think zircon dynamically assigns them as drivers claim the vectors
21:55:00 <geist> so they tend to get packed in, allocated sequentially by which driver claims first