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=osdev&y=18&m=7&d=11
00:00:00 --- log: started osdev/18.07.11
00:05:38 --- join: zeus1 (~zeus@197.239.5.1) joined #osdev
00:06:35 --- join: isaac_ (~isaac@host81-129-159-113.range81-129.btcentralplus.com) joined #osdev
00:06:43 --- nick: isaac_ -> isaacwoods
00:11:01 --- quit: adam4813 (Quit: Connection closed for inactivity)
00:11:09 <klange> got it!
00:11:16 <klange> succesful boot from a 64-bit EFI
00:13:11 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
00:13:21 <klange> neat, so now my boot CD supports BIOS w/ native ATAPI, or both IA32 and X64 EFI w/ EFI filesystem
00:16:44 <klange> Only thing I need now is some initial modesetting for EFI and I might be able to plop this on my desktop for testing...
00:18:06 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
00:18:48 --- quit: zeus1 (Ping timeout: 240 seconds)
00:23:34 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
00:27:25 --- quit: trout (Ping timeout: 265 seconds)
00:34:02 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
00:34:28 --- join: pie_ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
00:34:56 --- quit: Xal (Ping timeout: 240 seconds)
00:37:56 --- join: zeus1 (~zeus@197.239.5.126) joined #osdev
00:45:18 --- quit: zeus1 (Ping timeout: 244 seconds)
00:45:26 --- quit: nortega (Quit: Vivu lante, vivu feliĉe!)
00:47:07 --- join: ebrasca (~user@librepanther.com) joined #osdev
00:47:39 <ebrasca> Hi how to find inode table in ext2?
00:48:02 <Mutabah> There's multiple, one per block group
00:48:18 <Mutabah> I think they're the first table in a block group "header"?
00:49:00 <klange> each block group descriptor has an entry for the first block of its inode table
00:50:28 --- quit: X-Scale (Ping timeout: 244 seconds)
00:54:08 --- quit: celadon (Quit: ZNC 1.7.0+deb1+b1 - https://znc.in)
00:55:30 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
00:55:34 --- join: celadon (~celadon@66.157-14-84.ripe.coltfrance.com) joined #osdev
00:58:26 --- quit: variable (Ping timeout: 276 seconds)
00:59:46 --- quit: celadon (Ping timeout: 244 seconds)
01:05:05 --- join: antkit (uid256318@gateway/web/irccloud.com/x-cgootgcfcjgwjkby) joined #osdev
01:13:26 --- join: light2yellow (~l2y@185.220.70.144) joined #osdev
01:15:18 --- quit: isaacwoods (Quit: isaacwoods)
01:15:47 --- quit: w41 (Ping timeout: 244 seconds)
01:25:51 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
01:26:40 <[Orchestra]> will try the new version some day!
01:28:50 --- quit: ybyourmom (Quit: Lost terminal)
01:29:46 --- quit: trout (Ping timeout: 265 seconds)
01:39:30 --- join: Bjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:42:20 --- quit: Belxjander (Ping timeout: 260 seconds)
01:44:29 --- quit: Bjander (Ping timeout: 268 seconds)
01:45:05 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:50:53 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
01:50:57 --- quit: hmmmm (Remote host closed the connection)
01:52:23 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
01:55:52 --- quit: ZipCPU (Ping timeout: 256 seconds)
01:58:10 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
01:59:10 --- join: Asu (~sdelang@AMarseille-658-1-113-20.w86-219.abo.wanadoo.fr) joined #osdev
01:59:20 --- join: celadon (~celadon@66.157-14-84.ripe.coltfrance.com) joined #osdev
02:00:11 --- quit: Asu (Client Quit)
02:00:29 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
02:00:46 --- join: ZipCPU (~ZipCPU@pool-72-73-32-213.clppva.fios.verizon.net) joined #osdev
02:00:56 --- join: Asu (~sdelang@252.196.136.77.rev.sfr.net) joined #osdev
02:01:12 --- quit: variable (Ping timeout: 240 seconds)
02:02:11 --- quit: spare (Quit: leaving)
02:03:07 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
02:04:42 --- quit: Goplat (Remote host closed the connection)
02:16:26 --- quit: ebrasca (Ping timeout: 240 seconds)
02:19:05 <myvar> hey
02:22:37 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-xnmcfrmyzjkbqace) joined #osdev
02:29:03 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
02:29:52 --- join: Kimundi_ (~Kimundi@87.122.155.255) joined #osdev
02:32:41 --- quit: trout (Ping timeout: 276 seconds)
02:38:09 --- quit: graphene (Remote host closed the connection)
02:39:06 --- join: X-Scale (~ARM@83.223.224.42) joined #osdev
02:50:59 <zxq2> hello
02:57:03 --- quit: nwm (Ping timeout: 244 seconds)
02:58:46 --- join: Xal (~Xal@174.1.170.232) joined #osdev
03:00:40 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
03:01:23 --- quit: sysfault (Read error: Connection reset by peer)
03:03:42 --- quit: variable (Ping timeout: 240 seconds)
03:07:53 --- quit: nj0rd (Ping timeout: 265 seconds)
03:15:45 --- join: froggey (~froggey@unaffiliated/froggey) joined #osdev
03:25:27 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
03:32:33 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
03:35:44 --- quit: trout (Ping timeout: 276 seconds)
03:44:21 --- quit: amj (Ping timeout: 256 seconds)
03:57:04 --- quit: shymega (Ping timeout: 268 seconds)
03:58:51 --- quit: S_Gautam (Quit: Connection closed for inactivity)
04:00:38 --- join: shymega (~shymega@torbaytechjam/shymega) joined #osdev
04:03:44 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
04:06:22 --- quit: variable (Ping timeout: 265 seconds)
04:07:44 --- quit: return0e_ (Remote host closed the connection)
04:17:04 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
04:18:16 --- join: nj0rd (~nj0rd@2a02:8109:8e40:a9b:db94:fc41:974a:999f) joined #osdev
04:18:23 --- join: Kimundi__ (~Kimundi@i577A9D6E.versanet.de) joined #osdev
04:18:33 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
04:21:48 --- quit: Kimundi_ (Ping timeout: 240 seconds)
04:25:40 --- quit: Kimundi__ (Ping timeout: 260 seconds)
04:30:00 --- join: CheckDavid (uid14990@gateway/web/irccloud.com/x-zyzoynoeyldtbrsz) joined #osdev
04:30:59 --- quit: nj0rd (Ping timeout: 276 seconds)
04:32:20 --- join: Philpax (~Philpax@n175-34-175-169.sun1.vic.optusnet.com.au) joined #osdev
04:34:28 --- join: nj0rd (~nj0rd@2a02:8109:8e40:a9b:db94:fc41:974a:999f) joined #osdev
04:35:56 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
04:39:26 --- quit: trout (Ping timeout: 276 seconds)
04:39:34 --- join: Philpax_ (~Philpax@n175-34-175-169.sun1.vic.optusnet.com.au) joined #osdev
04:40:26 --- quit: Philpax (Ping timeout: 240 seconds)
04:47:53 --- join: vmlinuz (~vmlinuz@2804:431:f724:6100:2b8d:5c0e:8c9a:19f) joined #osdev
04:47:53 --- quit: vmlinuz (Changing host)
04:47:54 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
05:00:41 --- quit: Barrett (Read error: Connection reset by peer)
05:03:52 --- join: glauxosdever (~alex@athedsl-4474628.home.otenet.gr) joined #osdev
05:03:58 --- join: Kimundi__ (~Kimundi@dynip-129-217-096-185.wifi.tu-dortmund.de) joined #osdev
05:07:51 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
05:10:39 --- quit: variable (Ping timeout: 265 seconds)
05:11:28 --- join: isaac_ (~isaac@host81-129-159-113.range81-129.btcentralplus.com) joined #osdev
05:11:55 --- quit: Amaan (Quit: Connection closed for inactivity)
05:13:04 --- quit: nj0rd (Ping timeout: 265 seconds)
05:14:04 <myvar> intresting side not, i have been working on running byte code in my os, and i need some way to get the bytecode loaded at run time and i have not yet botherd to make a ram disk or fs, the way i did it is my imbeding it in my elf file using the linker
05:14:52 <myvar> then the os gets loaded by bootloader with the byte code it self, i just appended it to the .rodata section
05:14:58 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
05:15:03 <myvar> will this come back to byte me in the ass ?
05:16:36 --- join: dennis95 (~dennis@i577BCEA8.versanet.de) joined #osdev
05:22:02 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
05:23:39 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:28:12 --- join: CrystalMath (~coderain@reactos/developer/theflash) joined #osdev
05:28:28 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
05:29:35 --- quit: Belxjander (Read error: Connection reset by peer)
05:30:10 --- join: Bjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
05:30:44 --- nick: Bjander -> Belxjander
05:31:25 --- join: nur (~hussein@124.82.73.13) joined #osdev
05:33:43 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
05:35:05 --- quit: Barrett (Ping timeout: 260 seconds)
05:38:41 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
05:41:14 --- nick: isaac_ -> isaacwoods
05:42:10 <geist> myvar: that's a good starting point
05:42:29 --- quit: trout (Ping timeout: 276 seconds)
05:42:42 <geist> embedded hard coded binary stuff like that in a larger image is a perfectly finde way to d it
05:55:15 <myvar> good
05:56:57 --- quit: vmlinuz (Ping timeout: 256 seconds)
06:04:34 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
06:05:20 --- quit: myvar (Remote host closed the connection)
06:09:56 --- join: Barrett (~barrett@unaffiliated/barrett) joined #osdev
06:10:04 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
06:11:36 --- join: nj0rd (~nj0rd@2a02:8109:8e40:a9b:db94:fc41:974a:999f) joined #osdev
06:13:29 --- quit: variable (Ping timeout: 265 seconds)
06:13:42 --- join: vmlinuz (~vmlinuz@187.56.94.23) joined #osdev
06:13:43 --- quit: vmlinuz (Changing host)
06:13:43 --- join: vmlinuz (~vmlinuz@unaffiliated/vmlinuz) joined #osdev
06:19:36 --- join: ebrasca (~user@librepanther.com) joined #osdev
06:27:13 --- join: prokbird (~shams@45.125.178.140) joined #osdev
06:27:46 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
06:31:39 --- join: MDude (~MDude@pa-67-234-83-197.dhcp.embarqhsd.net) joined #osdev
06:40:15 --- quit: xenos1984 (Ping timeout: 244 seconds)
06:41:12 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
06:42:15 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
06:44:53 --- quit: trout (Ping timeout: 276 seconds)
06:48:54 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
06:53:05 --- join: graphene (~graphene@46.101.134.251) joined #osdev
06:54:53 --- quit: antkit (Quit: Connection closed for inactivity)
06:57:38 --- quit: jordyd (Quit: Bye!)
06:59:15 --- join: Amaan (uid4967@gateway/web/irccloud.com/x-yqitxbnaldtrttur) joined #osdev
07:00:06 --- join: jordyd (~jordyd@pampanic/co-maintainer/jordyd) joined #osdev
07:07:50 --- quit: Kimundi__ (Ping timeout: 260 seconds)
07:08:13 --- join: Kimundi__ (~Kimundi@dynip-129-217-096-185.wifi.tu-dortmund.de) joined #osdev
07:12:09 --- quit: graphene (Read error: Connection reset by peer)
07:13:02 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
07:13:38 --- join: alexge50 (~alexge50@5-12-204-217.residential.rdsnet.ro) joined #osdev
07:15:50 --- quit: variable (Ping timeout: 265 seconds)
07:22:25 --- quit: JusticeEX (Ping timeout: 260 seconds)
07:35:11 --- join: hmmmm (~sdfgsf@pool-72-79-160-252.sctnpa.east.verizon.net) joined #osdev
07:38:59 --- join: graphene (~graphene@46.101.134.251) joined #osdev
07:41:54 --- join: alphawarrior (~alphawarr@96.30.64.70) joined #osdev
07:42:28 <alphawarrior> Hello everyone! Are they are lower half kernels in production systems these days or are they all higher half ones?
07:45:05 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
07:46:33 --- join: antkit (uid256318@gateway/web/irccloud.com/x-wmrtihpgcqvzajcs) joined #osdev
07:47:25 --- quit: graphene (Ping timeout: 244 seconds)
07:47:42 --- quit: trout (Ping timeout: 240 seconds)
07:49:33 <Mutabah> No idea
07:49:52 <Mutabah> but, there's pretty much no reason to have the kernel be in the lower half if you have paging
07:49:59 --- mode: Mutabah set -o Mutabah
07:52:20 --- join: return0e (~return0e@5-198-102-244.static.kc.net.uk) joined #osdev
07:52:39 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-gbqqduujqsaeoknf) joined #osdev
07:55:05 --- quit: alphawarrior (Ping timeout: 260 seconds)
07:56:26 --- join: alphawarrior (~alphawarr@96.30.64.70) joined #osdev
07:57:00 <alphawarrior> what kind of assembler is https://wiki.osdev.org/Higher_Half_x86_Bare_Bones written for?
07:57:02 <bslsk05> wiki.osdev.org: Higher Half x86 Bare Bones - OSDev Wiki
07:57:21 --- join: graphene (~graphene@46.101.134.251) joined #osdev
07:57:27 <doug16k> alphawarrior, some of the practical reasons that kernels tend to be higher half: 0) it is simpler to share all of the kernel space across all processes that way. 2) if there were fragments of kernel things strewn wherever, then all those ranges would fragment user space, and 2) it would be more difficult to implement a separate virtual address allocator for each process when there are bits of kernel in the way in every process
07:58:00 <alphawarrior> oh thanks for explaining
08:01:01 --- quit: epony (Quit: snapshot upgrades)
08:03:34 <lava> however
08:03:44 <lava> most operating systems no don't share the address space anymore
08:05:43 --- quit: graphene (Read error: Connection reset by peer)
08:07:54 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
08:08:35 <alphawarrior> in the higher half barebones there is a "loader equ (_loader - 0xC0000000)" what does that do? What's the equ for? and what does it define?
08:09:11 --- join: graphene (~graphene@46.101.134.251) joined #osdev
08:09:40 --- quit: dormito (Ping timeout: 260 seconds)
08:10:20 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:10:40 --- quit: graphene (Read error: Connection reset by peer)
08:10:41 --- quit: nj0rd (Ping timeout: 256 seconds)
08:12:12 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
08:12:37 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
08:15:33 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
08:15:52 --- join: jakogut (~jakogut@162.251.69.147) joined #osdev
08:19:08 --- quit: variable (Ping timeout: 276 seconds)
08:19:15 --- join: graphene (~graphene@46.101.134.251) joined #osdev
08:19:29 --- quit: Barrett (Read error: Connection reset by peer)
08:21:04 --- part: prokbird left #osdev
08:27:44 <doug16k> alphawarrior, 0xC0000000 is the 3GB line, so it sounds like the high "half" is actually the top 1/4 (1GB) of address space, with the bottom 3/4 (3GB) allocated to user processes
08:27:55 <doug16k> without more context I can't infer much more than that
08:28:28 <alphawarrior> https://wiki.osdev.org/Higher_Half_x86_Bare_Bones full code there but I use gnu asm so at&t syntax and i have to convert somehow
08:28:39 --- quit: grouse (Quit: Leaving)
08:30:21 --- join: lkurusa_ (~pi@BC06AE14.catv.pool.telekom.hu) joined #osdev
08:31:01 <glauxosdever> https://wiki.osdev.org/User:Glauxosdever/Higher_Half_x86_Bare_Bones <- Here is another relevant page I wrote. It uses the AT&T syntax (because Bare Bones does use it too, not because I prefer it), and it fixes some issues with the original (the one you are looking at)
08:31:03 <bslsk05> wiki.osdev.org: User - OSDev Wiki
08:31:51 <glauxosdever> But it would be nice if GRUB enabled paging and loaded the kernel at any virtual address you request
08:32:16 <glauxosdever> (Except it doesn't and it will probably never do)
08:32:45 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:33:17 <doug16k> glauxosdever, my bootloader does exactly that, for x86_64, and it also respects the e820 map right from step 1, avoiding arbitrary unusable ranges appropriately. it enters the kernel with paging fully set up and the sections loaded to the virtual addresses specified in the linker script (program headers)
08:33:36 --- quit: karlguy (Quit: Konversation terminated!)
08:33:50 --- join: karlguy (~karlguy@ool-4a5a3082.dyn.optonline.net) joined #osdev
08:33:52 <glauxosdever> doug16k: Cool :-)
08:34:04 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
08:35:20 <glauxosdever> Hm, does your 1st stage get the memory map from the BIOS?
08:35:21 <alphawarrior> so that other code (the newer one) leaves %eax and %ebx untouched but how can i get the current location of the multiboot memory map (ebx)? is it even mapped anywhere?
08:37:33 <glauxosdever> Do you actually map it? If so, you save a (virtual) pointer to wherever it's mapped
08:37:44 <glauxosdever> If you don't map it, then map it.
08:40:24 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:41:56 --- quit: graphene (Remote host closed the connection)
08:43:24 --- join: graphene (~graphene@46.101.134.251) joined #osdev
08:43:25 <alphawarrior> well that code doesn't map it i guess
08:43:34 <alphawarrior> and i'm no asm pro sadly
08:46:20 --- quit: karlguy (Quit: Konversation terminated!)
08:46:37 --- join: karlguy (~karlguy@ool-4a5a3082.dyn.optonline.net) joined #osdev
08:47:40 <glauxosdever> https://wiki.osdev.org/User:Glauxosdever/Higher_Half_x86_Bare_Bones (at label 3:) -- it does map the video memory to specifically 0xC03FF000. The same can be done for the multiboot structure and thus the memory map.
08:48:11 <glauxosdever> It's usual that, initially, you have some page tables reserved so you can map some things before the memory manager is initialised
08:48:49 <glauxosdever> E.g. with 4 initial page tables, you can map up to 16 MiB of data
08:48:57 <hgoel> oof, seems like the virtio-net docs are slightly incorrect :(
08:49:22 <glauxosdever> The page I linked to sets up exactly one reserved page table.
08:49:30 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
08:49:31 <glauxosdever> Which is used to map the kernel
08:49:51 <glauxosdever> hgoel: I wanted to ask you, how is the Intel GPU driver going?
08:50:05 <glauxosdever> Because I want to undertake it as a challenge
08:51:19 <hgoel> haven't gotten to it yet
08:51:28 <hgoel> although I have a basic virtio-gpu driver ^-^
08:52:01 <hgoel> modesetting and some 3d acceleration in VMs
08:52:30 --- quit: trout (Ping timeout: 265 seconds)
08:52:31 <glauxosdever> Cool. 3D acceleration is what I want to attempt
08:52:38 <doug16k> hgoel, where is that documented? I don't see it under qemu/docs
08:53:13 <hgoel> this is where virtio is documented: docs.oasis-open.org/virtio/virtio/v1.0/csprd04/virtio-v1.0-csprd04.html
08:53:17 <bslsk05> docs.oasis-open.org: Virtual I/O Device (VIRTIO) Version 1.0
08:53:41 <doug16k> thanks
08:53:49 <hgoel> all the virtio devices use a virtq system, so you can relatively quickly implement the various devices after implementing the common layer
08:54:09 <hgoel> and then, for 3d acceleration, the documentation is at https://github.com/Keenuts/virtio-gpu-documentation/blob/master/src/virtio-gpu.md
08:54:11 <bslsk05> github.com: virtio-gpu-documentation/virtio-gpu.md at master · Keenuts/virtio-gpu-documentation · GitHub
08:54:28 --- quit: manzerbredes (Quit: WeeChat 2.1)
08:54:36 <hgoel> it's not too well documented, so you'll also have to occasionally do some digging around in mesa's code
08:54:58 <hgoel> like regarding the shader language, which is TGSI
08:55:55 <hgoel> and the virtio-net documentation is slightly incorrect, in that the num_buffers field is not present anymore, just noticed that and then confirmed in another os's implementation
08:56:41 <hgoel> glauxosdever, I'm aiming to get networking working before I do native gpu drivers, so I have some way to get debugging information out
08:57:16 <hgoel> that said, I can help at least with getting started, assuming you have something for which you're writing the driver, and something to test on
08:57:57 --- quit: debug (Quit: leaving)
08:58:05 <doug16k> that only says the gpu is device ID 16. is that really it?
08:58:07 <hgoel> since obviously you'll still have to do things like read the edid and configure the display before you can start trying to figure out the 3d stuff
08:58:29 <doug16k> oh didn't see 2nd link
08:58:33 <glauxosdever> hgoel: I've got an Intel HD 620. In some time (maybe a month), I'll be able to test it
08:59:07 <glauxosdever> Now I'm writing the bootloader -- will read the EDID and set up a framebuffer using the BIOS
08:59:29 <hgoel> doug16k, wait, I think I gave you the wrong version of the documentation, didn't realize there were multiple versions
09:00:12 <doug16k> yeah there's a link to latest in the 1st one you gave -> http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.html
09:00:17 <bslsk05> docs.oasis-open.org: Virtual I/O Device (VIRTIO) Version 1.0
09:00:19 <doug16k> is that what you meant?
09:00:29 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
09:00:46 <doug16k> anyway, virtio-gpu looks fantastic
09:01:00 <hgoel> doug16k, ah yes, here it is https://www.kraxel.org/virtio/virtio-v1.0-cs03-virtio-gpu.pdf
09:01:15 <hgoel> latest one there didn't appear to have the gpu documentation tho?
09:01:50 <doug16k> awesome
09:01:51 <doug16k> right
09:01:54 <hgoel> yeah, the one I just linked has the gpu documentation, regarding the 2d stuff
09:02:56 <hgoel> glauxosdever, I'm not too familiar with the HD 620, which generation chip is it? Skylake?
09:04:04 <glauxosdever> Ninth
09:04:34 --- join: nj0rd (~nj0rd@200116b8459e860051fd85195904c18c.dip.versatel-1u1.de) joined #osdev
09:04:38 <glauxosdever> Hm
09:05:24 <glauxosdever> https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units#Ninth_generation
09:05:25 <hgoel> couldn't be 9th gen though? that'd be coffee lake, which apparently isn't out yet
09:05:26 <bslsk05> en.wikipedia.org: List of Intel graphics processing units - Wikipedia
09:05:37 <hgoel> which cpu is it with?
09:06:00 <hgoel> the model numbers on Intel's graphics chipsets are basically useless
09:06:14 <glauxosdever> Let me check
09:06:24 <glauxosdever> I honestly can't remember my CPU type
09:06:31 <hgoel> lol
09:06:33 <doug16k> intel likes to play games with part numbers. they get a consistent thing going, then break that consistency for a laugh
09:06:43 <hgoel> yep
09:06:56 <glauxosdever> It's a i5-7200U
09:06:59 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
09:07:23 <hgoel> so 7th gen
09:07:40 <hgoel> so Kaby lake
09:07:49 --- join: zeus1 (~zeus@81.199.19.241) joined #osdev
09:08:18 <glauxosdever> Which do you have?
09:08:23 <hgoel> these would be the manuals you'd need to look at: https://01.org/linuxgraphics/hardware-specification-prms/2016-intelr-processors-based-kaby-lake-platform
09:08:29 <hgoel> I have Haswell and Ironlake
09:08:31 <bslsk05> 01.org: 2016 - 2017 Intel Core™ Processors, Celeron™ Processors, and Pentium™ Processors based on the "Kaby Lake" Platform | 01.org
09:08:57 <hgoel> iirc there were some pretty major changes in the design for skylake, but it shouldn't be that bad
09:09:43 <hgoel> looks like reading the EDID is the same
09:10:04 <hgoel> actually seems like the docs might be better now
09:11:06 --- quit: sixand (Remote host closed the connection)
09:11:24 --- join: sixand (~Thunderbi@222.84.223.232) joined #osdev
09:12:21 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
09:12:28 <hgoel> so, to get started, you can read https://wiki.osdev.org/Native_Intel_graphics and https://wiki.osdev.org/Intel_HD_Graphics as well as the recommended reading in the latter
09:12:29 <bslsk05> wiki.osdev.org: Native Intel graphics - OSDev Wiki
09:12:30 <bslsk05> wiki.osdev.org: Intel HD Graphics - OSDev Wiki
09:13:04 <glauxosdever> Well, it will be probably some weeks until I'll be ready to start developing a driver
09:13:50 <glauxosdever> I restarted about a month ago (after a veeery long break), took also breaks in the meanwhile doing mostly graphics programming, and I returned today
09:14:51 <hgoel> ah okay, that should help make it easier to figure out some of the stuff, since Intel's gpus map pretty directly to opengl/directx
09:16:24 <glauxosdever> Didn't achieve very much though, I did some 2D triangles (although I'm aware I'd do matrix transformations for 3D ones) and I used a shader of a specific colour
09:17:46 --- join: Tazmain (~Tazmain@unaffiliated/tazmain) joined #osdev
09:18:32 --- quit: Kimundi__ (Remote host closed the connection)
09:18:44 --- join: Kimundi__ (~Kimundi@dynip-129-217-096-185.wifi.tu-dortmund.de) joined #osdev
09:19:40 <hgoel> I'm assuming you did get into vertex buffers, blending, framebuffers etc?
09:20:41 <glauxosdever> Vertex buffers only, assuming opengl. Although I wrote data to the linux framebuffer directly in another experiment
09:21:34 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
09:22:59 <hgoel> I guess we'll just see when you get there :P still a while to go from the sound of it
09:24:12 --- quit: variable (Ping timeout: 240 seconds)
09:24:48 --- quit: Kimundi__ (Ping timeout: 240 seconds)
09:26:19 --- quit: epony (Quit: upgrades)
09:27:14 --- quit: freakazoid0223 (Read error: Connection reset by peer)
09:31:05 <doug16k> it'll be nice to have accelerated bitblt API at all with virtio-gpu, let alone full shader compilation, buffer binding, and command queues, lol
09:31:51 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-dtuzgnezkgrgvxar) joined #osdev
09:32:09 <hgoel> yep ^-^
09:32:46 <hgoel> if you handle the display resize event, you can have the framebuffer auto-resize to fit the VM window
09:33:14 <hgoel> and I think you can configure multiple displays as well, I think that's what the scanouts refer to
09:33:26 <doug16k> yeah that's awesome to have
09:34:49 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
09:34:54 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:36:06 <hgoel> been working on a network stack lately, it's starting to come together nicely now that I can finally view the packets sent/received by virtio-net
09:37:29 <hgoel> ideally I can passthrough my wifi card and get it working too, making the testing on my laptop a lot easier
09:38:04 <hgoel> freebsd's intel wifi driver is a lot easier to read compared to the linux one
09:41:41 --- join: bauen1 (~bauen1@ipbcc18c77.dynamic.kabel-deutschland.de) joined #osdev
09:41:45 --- join: Ranhir (~Ranhir@157.97.53.139) joined #osdev
09:42:54 --- join: epony (~nym@77-85-141-166.ip.btc-net.bg) joined #osdev
09:44:28 --- quit: promach_ (Quit: WeeChat 2.1)
09:44:52 <doug16k> really EFI? I really have to dig through the DHCP ack DHCP option bytes to get the TFTP client and server port numbers so I can echo them back when I open a TFTP file transfer? gimme a break
09:45:02 --- quit: graphene (Remote host closed the connection)
09:46:34 --- join: graphene (~graphene@46.101.134.251) joined #osdev
09:48:43 <doug16k> there's already a whole matrix of scenarios you have to deal with in a tree of if (ipv4) { if (proxy dhcp server) then A else B } else { if (proxy dhcp server) C else D }
09:49:02 <doug16k> now I have to parse 2 different formats of dhcp option bytes from 4 different scenarios?
09:51:52 <doug16k> I want GetFileSizeFromSameDamnTFTPThisBootProgramCameFrom and ReadFileFromSameDamnTFTPThisBootProgramCameFrom, lol
09:52:55 --- join: MrOnlineCoder (~MrOnlineC@195.225.231.218) joined #osdev
09:53:01 --- join: kimundi (~Kimundi@i577A9D6E.versanet.de) joined #osdev
09:53:24 <doug16k> with a flag parameter COULDNT_CARE_LESS_IF_IT_IS_IPV4_OR_IPV6_OR_MULTICAST_KTHX
09:53:34 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
09:56:18 --- quit: trout (Ping timeout: 265 seconds)
09:56:23 --- quit: andrei-n (Read error: Connection reset by peer)
09:56:45 --- join: andrei-n (~andrei@208.8-64-87.adsl-dyn.isp.belgacom.be) joined #osdev
09:59:18 --- quit: vaibhav|gone (Ping timeout: 240 seconds)
10:02:52 <doug16k> the way it is explains why proxy dhcp pxe is hit or miss. if people don't specifically handle it, it won't work
10:03:48 <hgoel> oof
10:07:25 --- quit: nur (Ping timeout: 265 seconds)
10:07:25 --- quit: nwm (Ping timeout: 256 seconds)
10:12:41 --- quit: SopaXorzTaker (Remote host closed the connection)
10:13:54 --- quit: alexge50 (Remote host closed the connection)
10:14:17 <MrOnlineCoder> hi, can someone please point me if this way of dynamic memory allocation (heap) is good enough to fit first needs: when malloc(16) is called (for example), my allocator searches for avaliable block and sets first byte to 1, the second one to the size of the allocation (16 in this case), and returns the address to the third byte. So memory looks like this: 1 | 16 | .. 16 bytes of data for use .. | free memory. When free is called, we go back 2
10:14:17 <MrOnlineCoder> bytes back in memory (ptr-2) and check if this byte is set (1). If yes then we set it to 0. So memory will look like this: 0 | 16 | ...16 bytes... | free memory. Next time if larger block is requested, it is inserted after the first 16-byte block. Otherwise, the 16 byte block is divided into 2 blocks. Hope you understood that correctly.
10:18:33 --- join: baschdel (~baschdel@2a01:5c0:1c:6201:bb0:858:a281:6ed8) joined #osdev
10:24:41 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
10:27:27 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
10:27:50 --- quit: variable (Ping timeout: 276 seconds)
10:33:54 <hgoel> that's decent, but if the allocation is larger than 255 bytes, then a single byte won't be enough for the size
10:34:28 <hgoel> plus, it might be good to include some sort of magic number so you can detect memory corruption
10:35:26 <hgoel> so like, allocations might have 8 byte headers, DEADBEEF | SIZE32 | DATA for when the block is in use
10:35:42 <hgoel> and then just change the magic number when it's free
10:36:46 <hgoel> so maybe, B16B00B5 | SIZE32 | SPACE when free
10:36:47 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
10:37:34 <hgoel> that way, the chances of something corrupting the size value are much lower
10:37:55 <hgoel> corrupting it by accident that is
10:39:26 --- quit: banisterfiend (Client Quit)
10:41:41 <MrOnlineCoder> thanks
10:41:56 <MrOnlineCoder> by size32 you mean 32 bit number for size?
10:42:20 --- join: lldd_ (~atrapado@unaffiliated/atrapado) joined #osdev
10:43:04 <hgoel> yeah
10:43:24 --- join: manzerbredes (~loic@2a01cb0885e31500cfc30bb534d5bc37.ipv6.abo.wanadoo.fr) joined #osdev
10:43:39 <hgoel> that way you can have allocations larger than 255 bytes (that you'd otherwise have if you only use 1 byte)
10:43:53 <hgoel> also, remember to consider alignment rules
10:44:52 <MrOnlineCoder> haha, i can play with bit wise magic so only first bit will mark block as free/used an use other 15 bits for size
10:45:05 <MrOnlineCoder> *and
10:46:07 <MrOnlineCoder> so, if I implement your hints (maigc number, alignment) will this heap/allocator be just OK for paging and first-time VFS?
10:46:35 --- quit: zeus1 (Ping timeout: 260 seconds)
10:52:49 --- join: debug (~debug@m176-68-199-14.cust.tele2.se) joined #osdev
10:52:54 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
10:54:21 --- join: w41 (~w41@unaffiliated/w41) joined #osdev
10:56:28 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
10:59:03 --- join: bm371613 (~bartek@2a02:a317:603f:9800:3d21:d4ea:8e13:962a) joined #osdev
10:59:12 --- quit: trout (Ping timeout: 240 seconds)
11:00:14 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
11:00:33 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
11:03:42 <hgoel> MrOnlineCoder, ah, are you planning to use this for physical memory allocation?
11:04:01 <hgoel> because this won't work for that
11:04:11 <hgoel> it'll do for a VFS though
11:04:12 <MrOnlineCoder> ?
11:04:35 <hgoel> you asked if it'd be ok for paging, I'm not sure what you mean by that
11:04:56 <MrOnlineCoder> ah, sorry, I wanted to get a working heap for dynamic allocations in code, like scheduler, vfs nodes etc
11:05:27 <hgoel> this will work for those
11:05:47 <MrOnlineCoder> ok thanks
11:06:25 --- quit: alphawarrior (Remote host closed the connection)
11:09:57 --- join: jmpf (~eyberg@50-197-181-22-static.hfc.comcastbusiness.net) joined #osdev
11:10:05 --- quit: rain1 (Quit: WeeChat 1.9.1)
11:12:04 --- join: rain1 (~rain1@unaffiliated/rain1) joined #osdev
11:12:24 --- quit: Tobba (Read error: Connection reset by peer)
11:16:48 --- join: w17t (~w17t@unaffiliated/w17t) joined #osdev
11:16:50 --- quit: w17t (Max SendQ exceeded)
11:17:00 --- join: Tobba (~Tobba@h-25-157.A159.priv.bahnhof.se) joined #osdev
11:17:16 <jmpf> looking for some contractors for os work - hit me up if interested
11:18:26 --- quit: w41 (Ping timeout: 240 seconds)
11:19:22 --- join: w17t (~w17t@unaffiliated/w17t) joined #osdev
11:19:24 --- quit: w17t (Max SendQ exceeded)
11:23:19 --- quit: kimundi (Quit: quit)
11:24:18 <doug16k> MrOnlineCoder, my bootloader has a simple (imho) first-fit malloc implementation (with arbitrary alignment), and corruption detection, if you want to look at something simple to get started -> https://github.com/doug65536/dgos/blob/master/boot/malloc.cc
11:24:21 <bslsk05> github.com: dgos/malloc.cc at master · doug65536/dgos · GitHub
11:25:17 <doug16k> you point it at a range of memory (malloc_init) and it sets itself up to allocate memory from that range
11:26:22 --- nick: dude12312414 -> FexinFlexin
11:27:57 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
11:28:44 --- nick: FexinFlexin -> dude12312414
11:31:31 --- quit: variable (Ping timeout: 265 seconds)
11:35:22 --- join: theseb (~user@47-220-211-42.cnrocmta03.res.dyn.suddenlink.net) joined #osdev
11:35:33 <doug16k> it works when compiled as 32 bit or 64 bit code btw
11:35:43 <theseb> logic gate circuit question....what if input to logic gate B is the output of logic gate A?..then they can't both be activated by the clock pulse!? How stagger their execution?
11:36:23 --- quit: jakogut (Ping timeout: 256 seconds)
11:36:28 <doug16k> theseb, a flip flop, aka register in HDL terminology
11:36:54 --- quit: [Orchestra] (Quit: There are paranoid crossroads and shipwreck alleys.)
11:37:08 --- join: tacco| (~tacco@i59F5F399.versanet.de) joined #osdev
11:38:01 --- join: [Sphere] (~while@unaffiliated/awaxx/x-0928682) joined #osdev
11:38:30 <theseb> doug16k: flip flops store values..how does that fix race conditions?
11:38:34 <theseb> doug16k: thank btw
11:38:40 <doug16k> raw gates are combinatorial logic. you have lumps of combinatorial logic between registers. the flip flop outputs whatever its input was at each clock edge and holds that value until the next clock edge, at which point it outputs whatever value was at its input in the previous clock cycle, etc
11:40:05 <doug16k> let's say in cycle 0 your gates drive 0x55 into the input of a register, at the clock edge, the output of that register becomes 0x55. during this second cycle your logic drives 0xAA into the register, at the next clock edge, 0xAA becomes the register output
11:40:55 <doug16k> exactly what you need to implement a pipeline. each clock sends the data down the pipeline one stage
11:43:41 <doug16k> theseb, https://en.wikipedia.org/wiki/Sequential_logic <-- explains registers (flip flops) and how they allow processing to flow through intervening combinatorial logic at each clock edge
11:43:42 <bslsk05> en.wikipedia.org: Sequential logic - Wikipedia
11:46:02 <theseb> doug16k: i think i found my mistake....a clock signal activates gates for a specific *time interval* right? I was thinking everything happened virtually instantaneously at clock edge
11:46:07 <theseb> which was confusing to me
11:47:16 <doug16k> the gates between flip flops take time to settle into the correct state. the clock cycle must be wide enough for the worst case in the pipeline to fully settle. the flip flops step the data down the pipeline and hold it steady for the entire clock cycle
11:48:13 <doug16k> they capture whatever the value was at its input at the end of each cycle and hold it on the output
11:49:19 --- join: kimundi (~Kimundi@i577A9D6E.versanet.de) joined #osdev
11:49:40 <doug16k> this is off topic though, so I recommend looking up sequential logic and combinatorial logic online :)
11:50:22 --- join: rawste (~rawste@static-176-182-199-171.ncc.abo.bbox.fr) joined #osdev
11:51:11 <doug16k> theseb, there's also ##fpga - you can presumably talk about pipelines and registers and logic gates there all day
11:52:59 <theseb> doug16k: lol..ok...thanks
11:54:36 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
11:55:26 --- join: volat__ (4dac8cd3@gateway/web/freenode/ip.77.172.140.211) joined #osdev
11:55:34 <volat__> h
11:56:18 <volat__> does make sense to not share core with other process for a critical process to avoid TLBleed?
11:59:03 --- quit: SopaXorzTaker (Read error: Connection reset by peer)
11:59:54 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
12:00:04 --- part: theseb left #osdev
12:00:58 --- quit: S_Gautam (Quit: Connection closed for inactivity)
12:02:53 --- quit: trout (Ping timeout: 256 seconds)
12:08:47 <_mjg_> burp
12:13:51 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
12:22:09 --- quit: graphene (Remote host closed the connection)
12:23:34 --- join: graphene (~graphene@46.101.134.251) joined #osdev
12:31:10 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
12:31:30 --- nick: ZeDestructor -> Aeso_
12:31:45 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
12:31:47 --- nick: Aeso_ -> ZeDestructor
12:32:25 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
12:32:42 --- quit: manzerbredes (Ping timeout: 240 seconds)
12:32:48 --- nick: ZeDestructor -> ZeDestruct0r
12:33:02 --- nick: ZeDestruct0r -> ZeDestructor
12:33:42 --- quit: variable (Ping timeout: 240 seconds)
12:34:05 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
12:37:19 --- quit: andrei-n (Ping timeout: 264 seconds)
12:52:19 --- quit: adam4813 (Quit: Connection closed for inactivity)
13:00:07 --- join: jakogut (~jakogut_@162.251.69.147) joined #osdev
13:00:31 --- join: Sanctified (~Sanctifie@host-85-30-181-143.sydskane.nu) joined #osdev
13:01:38 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
13:02:01 --- quit: lldd_ (Quit: Leaving)
13:02:30 --- quit: andrewrk (Ping timeout: 264 seconds)
13:03:13 <Sanctified> so I'm having a bit of a makefile conundrum
13:05:30 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
13:05:47 --- quit: trout (Ping timeout: 276 seconds)
13:06:02 --- quit: Lucretia (Remote host closed the connection)
13:07:31 --- join: Lucretia (~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5) joined #osdev
13:07:31 --- quit: Lucretia (Changing host)
13:07:31 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
13:10:03 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
13:10:26 <Sanctified> my directory structure looks like this https://pastebin.com/2EMqttcA where the developer is supposed to just execute the makefile in the base directory which then traverses into the correct directory (e.g. bootloader) and executes that makefile. The .mk files in mkinclude define things like the compiler command, compiler flags, etc. asm.mk, cpp.mk and lnk.mk are all dependent on cross.mk, which defines the cross-compilation target
13:10:27 <Sanctified> (i.e. x86_64-elf) and cross-compilation chain install dir. This means those three files all start by including cross.mk. So bootloader/Makefile includes ../mkinclude/asm.mk which then includes just cross.mk. However, it seems that it doesn't actually change directory for the include, so asm.mk looks for cross.mk in bootloader/. Am I stuck just including cross.mk manually from each individual makefile or can I do something sneaky?
13:10:27 <bslsk05> pastebin.com: dir structure - Pastebin.com
13:10:34 --- nick: Asu -> Asu`afk
13:12:34 --- join: andrewrk (~andrewrk@cpe-68-175-109-180.nyc.res.rr.com) joined #osdev
13:22:56 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
13:25:33 --- quit: banisterfiend (Client Quit)
13:27:17 <Sanctified> fuck it, I'll just define a variable in the base make file containing the full path to the base directory
13:29:43 --- quit: baschdel (Ping timeout: 256 seconds)
13:29:58 --- nick: Asu`afk -> Asu
13:34:08 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
13:34:35 --- quit: JusticeEX (Ping timeout: 260 seconds)
13:36:48 --- join: sixand1 (~Thunderbi@222.217.229.196) joined #osdev
13:37:11 --- quit: variable (Ping timeout: 265 seconds)
13:37:38 --- quit: Lucretia (Remote host closed the connection)
13:38:18 --- quit: sixand (Ping timeout: 240 seconds)
13:38:19 --- nick: sixand1 -> sixand
13:39:06 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
13:43:45 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
13:46:21 --- join: bemeurer (~bemeurer@stdcognition.static.monkeybrains.net) joined #osdev
13:47:22 --- join: Shamar (~giacomote@unaffiliated/giacomotesio) joined #osdev
13:49:26 --- quit: azonenberg (Ping timeout: 276 seconds)
13:51:09 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
13:57:47 --- join: Lucretia (~laguest@2a02:c7d:3c35:b000:325a:3aff:fe0f:37a5) joined #osdev
13:57:47 --- quit: Lucretia (Changing host)
13:57:47 --- join: Lucretia (~laguest@pdpc/supporter/active/lucretia) joined #osdev
13:58:57 --- quit: plonk (Remote host closed the connection)
13:59:13 --- quit: rawste (Quit: Quit...)
14:02:18 --- quit: Belxjander (Quit: AmigaOSv4.1.6+//PowerPC native)
14:03:00 --- join: Belxjander (~Belxjande@sourcemage/Mage/Abh-Elementalist) joined #osdev
14:05:03 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
14:08:12 --- quit: trout (Ping timeout: 240 seconds)
14:09:24 --- quit: glauxosdever (Quit: leaving)
14:12:00 --- quit: drakonis (Remote host closed the connection)
14:21:18 --- quit: bemeurer (Ping timeout: 240 seconds)
14:24:33 --- join: bemeurer (~bemeurer@stdcognition.static.monkeybrains.net) joined #osdev
14:26:27 --- quit: graphene (Remote host closed the connection)
14:27:28 --- quit: bemeurer (Max SendQ exceeded)
14:27:52 --- join: graphene (~graphene@46.101.134.251) joined #osdev
14:30:01 --- join: bemeurer (~bemeurer@199.83.221.197) joined #osdev
14:30:14 --- quit: macdonag2 (Quit: macdonag2)
14:36:54 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
14:38:18 <doug16k> Sanctified, do you have a configure script? something like that belongs in there, it could generate a .mk that has that "hardcoded" assignment
14:39:33 <doug16k> doing something like that can enable out-of-source builds, so you can have different builds side-by-side and no binaries dumped into your source tree at all
14:40:02 --- quit: variable (Ping timeout: 276 seconds)
14:41:46 <doug16k> the configure script can determine the full path to which directory it is in, and use that as the top source directory
14:41:58 --- join: MarcinWieczorek (~MarcinWie@2a00:f41:1cbb:2d45:b65:d609:fa97:699a) joined #osdev
14:42:10 --- join: hmmmmm (~sdfgsf@pool-72-79-161-139.sctnpa.east.verizon.net) joined #osdev
14:42:22 <doug16k> PXE EFI boot working!
14:42:48 <clever> nice
14:42:56 <clever> i couldnt get that working with my machines
14:43:15 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
14:43:23 <clever> if option arch = 00:07 or option arch = 00:09 {
14:43:25 <clever> filename = "x86_64-ipxe.efi";
14:43:43 <clever> i was using this in dhcpd, cant remember what broke
14:43:48 <clever> option arch code 93 = unsigned integer 16;
14:44:02 <doug16k> hopefully somewhere you set the tftp root directory path
14:44:35 <clever> next-server 192.168.3.1;
14:44:55 <clever> non-efi pxe works with filename = "undionly.kpxe"; in an else statemement
14:45:06 <clever> https://github.com/cleverca22/nixos-configs/blob/master/netboot_server.nix#L80-L98 is the full dhcpd config
14:45:08 <bslsk05> github.com: nixos-configs/netboot_server.nix at master · cleverca22/nixos-configs · GitHub
14:45:10 --- quit: hmmmm (Ping timeout: 260 seconds)
14:49:35 --- quit: Shamar (Quit: Lost terminal)
14:52:09 <doug16k> clever, where did you get 7 or 9? shouldn't that be 6 or 9? -> https://tools.ietf.org/html/rfc4578
14:52:12 <bslsk05> tools.ietf.org: RFC 4578 - Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)
14:52:35 --- quit: immibis (Ping timeout: 265 seconds)
14:52:54 <doug16k> or did you actually intend it to be bytecode or native amd64?
14:52:54 --- quit: bemeurer (Ping timeout: 264 seconds)
14:53:08 <clever> doug16k: probably just a typo
14:53:29 <clever> but that just means it wont support 32bit, or it will try to run the efi binary as bytecode... :S
14:53:50 <doug16k> if you don't have bootia32.efi then just 9, you don't have a bytecode efi app right?
14:54:19 <clever> yeah, i'll drop the or entirely
14:55:21 --- join: bemeurer (~bemeurer@199.83.221.197) joined #osdev
14:55:32 <doug16k> the firmware will probably bail out at the slightest sign of trouble, you probably have to have the config perfect or it's totally dead :)
14:58:24 <doug16k> I'm amazed that llvm doesn't have EFI bytecode target yet. that target would be the most trivial backend ever, compared to the insane complexity of a real cpu
14:58:58 <clever> i probably cant test this fix for a while though
15:02:41 <doug16k> I wrote a pxe proxy dhcp+tftp server you could try (when you get around to it) -> https://github.com/doug65536/pxedhcp
15:02:42 <bslsk05> doug65536/pxedhcp - PXE DHCP responder with built-in TFTP server (3 forks/3 watchers)
15:02:53 --- quit: dennis95 (Quit: Leaving)
15:03:00 <doug16k> you just run it with --dir /some/path --bootfile whatever
15:03:46 --- join: AndrewBC_ (~AndrewBC@ip70-187-57-150.pn.at.cox.net) joined #osdev
15:03:47 <doug16k> when I can't get dhcp daemons configured I try that and boom, works instantly :)
15:04:06 --- quit: volat__ (Quit: Page closed)
15:04:52 <doug16k> if that works then you can be sure it's all a problem with your dhcp config
15:05:02 <clever> doug16k: i have full control over my dhcp server
15:05:14 <clever> but the chunk of code above isnt compatible with my LAN, so id have to adapt it a bit
15:05:16 <doug16k> so do I. doesn't magically make me configure it right
15:05:35 <doug16k> I hate configuring dhcp daemons. never works
15:07:06 --- quit: AndrewBC (Ping timeout: 244 seconds)
15:07:25 <doug16k> it's like balancing a stack of ten pencils end to end with the sharp end of the bottom pencil down. slightest issue, dead as a doornail
15:09:21 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
15:09:25 <doug16k> because I don't have enough experience with configuring them or I'm doing it wrong? absolutely
15:10:12 <clever> my OS has full rollback support, so i can undo any change to the system
15:11:28 --- quit: bemeurer (Remote host closed the connection)
15:11:52 <_mjg_> you mean the fs state?
15:11:55 --- join: bemeurer (~bemeurer@199.83.221.197) joined #osdev
15:11:59 <_mjg_> do you have a cow fs?
15:11:59 --- quit: spare (Quit: leaving)
15:12:12 --- quit: trout (Ping timeout: 240 seconds)
15:13:54 <clever> _mjg_: thats not required for the os to do rollbacks
15:14:06 --- join: sortie (~sortie@static-5-186-55-44.ip.fibianet.dk) joined #osdev
15:14:11 <clever> _mjg_: nixos.org
15:14:31 <clever> _mjg_: all files in the OS are stored at /nix/store/<hash>-name, and the hash is a hash over the directions on how the file was built
15:14:39 --- join: macdonag2 (~macdonag2@cpc110673-lewi19-2-0-cust478.2-4.cable.virginm.net) joined #osdev
15:14:45 <clever> and everything forms a tree, starting from a /run/current-system symlink
15:14:48 --- quit: kimundi (Ping timeout: 240 seconds)
15:15:09 <clever> so new and old versions, are just different starting points for the tree, and changing the symlink changes all config files
15:15:42 <_mjg_> hence why i asked
15:15:58 <_mjg_> so you are not really doing rollbacks
15:16:15 <clever> i also use ZFS on most of my installs, but the router doesnt have zfs
15:16:27 <_mjg_> oh, it's a linux variant
15:16:34 <_mjg_> meh
15:17:52 --- quit: AndrewBC_ (Ping timeout: 268 seconds)
15:25:32 --- join: kimundi (~Kimundi@i577A9D6E.versanet.de) joined #osdev
15:28:08 --- join: vdamewood (~vdamewood@unaffiliated/vdamewood) joined #osdev
15:31:10 --- quit: sortie (Quit: Leaving)
15:31:43 --- quit: banisterfiend (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:35:37 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
15:36:53 <MrOnlineCoder> were/are there anyone who connected and chatted to this irc channel in their own OS?
15:37:10 <klys> sortie has done this
15:37:26 <klys> he just left
15:37:47 <MrOnlineCoder> he has built his own irc client or rebuilt an exisiting one on his os?
15:37:59 --- join: banisterfiend (~banister@ruby/staff/banisterfiend) joined #osdev
15:38:12 <klys> I think he built his own.
15:39:03 --- quit: Tazmain (Quit: Leaving)
15:39:39 --- quit: jmpf (Quit: leaving)
15:40:13 --- join: Matviy (8241fe11@gateway/web/freenode/ip.130.65.254.17) joined #osdev
15:41:03 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
15:41:23 <Matviy> Hi! I'm reading a book on the linux kernel, specifically about TLB flushing. And i found the following sentence:
15:41:29 <Matviy> "However, there is no need to invalidate a TLB entry that refers to a User Mode linear address, because no ker- nel thread accesses the User Mode address space."
15:41:59 <Matviy> AFAIK the kernel code (or modules) can and do access user space to read/write data
15:43:35 --- join: sympt (~sympt@209.58.135.72) joined #osdev
15:44:23 --- quit: variable (Ping timeout: 276 seconds)
15:46:26 --- quit: vdamewood (Ping timeout: 240 seconds)
15:47:43 --- quit: vmlinuz (Quit: Leaving)
15:49:38 --- quit: Asu (Quit: Konversation terminated!)
15:50:45 --- quit: Matviy (Ping timeout: 252 seconds)
15:51:01 <doug16k> Matviy, you only need to invalidate user space TLB entries when you reduce the permission on a user page or make it not-present at all. kernel threads do that? when?
15:51:19 --- quit: macdonag2 (Quit: macdonag2)
15:51:45 <doug16k> the sentence probably goes a bit too far implying that they never would do that, but typically, they wouldn't
15:55:07 <doug16k> the sentence may be completely true when understood in context. what is the surrounding text talking about?
16:02:08 <chao-tic> Not an expert, but as far as I know, the kernel typically calls access_process_vm()/get_user_pages() to "pin" the user mode pages to the kernel address space, before accessing the user process' memory
16:03:33 <chao-tic> Especially for kernel threads that have no associated "current" user task
16:04:39 --- quit: isaacwoods (Quit: isaacwoods)
16:04:53 --- quit: antkit (Quit: Connection closed for inactivity)
16:05:51 --- quit: Sanctified (Remote host closed the connection)
16:07:10 <chao-tic> s/ that/, they
16:09:21 <chao-tic> So there's no need to invalidate TLB entries in that case
16:12:42 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
16:15:42 --- quit: trout (Ping timeout: 240 seconds)
16:19:05 --- quit: MrOnlineCoder (Read error: Connection reset by peer)
16:29:57 --- join: nur (~hussein@175.141.139.56) joined #osdev
16:39:59 --- join: promach_ (~promach@bb219-74-174-136.singnet.com.sg) joined #osdev
16:40:26 --- quit: xenos1984 (Quit: Leaving.)
16:42:15 --- quit: freakazoid0223 (Remote host closed the connection)
16:43:14 --- join: freakazoid0223 (~mattc@pool-108-52-244-197.phlapa.fios.verizon.net) joined #osdev
16:43:50 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
16:47:26 --- quit: variable (Ping timeout: 276 seconds)
16:58:26 --- quit: bemeurer (Quit: WeeChat 2.1)
17:00:01 <klange> Now that I've finished with my distraction projects of building EFI loaders...
17:01:19 <doug16k> I finished the last thing today too. now I support EFI and BIOS on HD, CD, or PXE
17:03:28 --- join: ALowther_ (~Alowther_@107.144.136.35) joined #osdev
17:04:23 <klys> well today I compiled small-c for cp/m with itself and verified identical results.
17:04:36 <klys> http://show.ing.me/paste/smallc.patch
17:04:36 <doug16k> I want to start looking at implementing virtio-gpu. it looks awesome
17:04:49 --- quit: banisterfiend (Quit: Textual IRC Client: www.textualapp.com)
17:05:21 <rain1> klys: that sounds interesting but I don't fully understand
17:05:41 <rain1> small-c is C compiler in C? and CP/M is that old UNIX right?
17:05:55 <doug16k> klys, how small is small? how many KB of memory would you need?
17:06:36 <doug16k> rain1, commodore 128 can run CP/M
17:07:31 <rain1> ooh
17:07:48 <klange> CP/M isn't a Unix. It's very similar to DOS, in so far as DOS was a clone of CP/M.
17:08:15 <klys> rain1, the main archive is at http://www.cpm.z80.de/small_c/smallc86.zip
17:10:18 <klys> and I was using this ccpm/86: http://www.hampa.ch/pub/pce/pce-0.2.2-xt-ccpm86-3.1.zip - with this diskdef for apt-get install cpmtools: https://textuploader.com/dzf1w
17:10:20 <bslsk05> textuploader.com: 'diskdef pce-pimg' | TextUploader.com
17:10:26 <clever> http://spritesmods.com/?art=avrcpm
17:10:26 <bslsk05> spritesmods.com: Sprites mods - CP/M on an AVR - Intro
17:10:50 <clever> this crazy guy made a z80 emulator on an AVR, and then ported CP/M to it
17:10:56 <clever> and ultimately, got it to run zork
17:11:55 <klys> one unsavory thing about this C compiler is that it doesn't support nested #includes.
17:11:56 --- quit: nwm (Ping timeout: 240 seconds)
17:12:16 <doug16k> wow
17:13:23 <klange> Is it even technically a C compiler if it can't nest #includes?
17:13:46 <klange> That means it compiles something very close to but not quite C. ;)
17:14:05 <klys> strategy is usually to put your defines and globals at the top of main.c and include all your routines files from there.
17:14:13 --- join: nwm (~nwm@d162-156-46-158.bchsia.telus.net) joined #osdev
17:14:40 <doug16k> 56KB memory required. nice
17:14:43 <klys> well it has comments suggesting it was written towards 1980.
17:14:48 <clever> klange: i have had the "pleasure" of using a palmos "c" compiler, that didnt even support #include
17:15:05 <clever> klange: it ran directly on palm, and keys like { and [ where nested 3 levels deep in a menu
17:15:32 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
17:15:44 <clever> i had to type every single function declaration and struct by hand
17:16:00 <clever> obviously, i made a typo somewhere, and it just segfaulted the entire device, due to the lack of an MMU
17:16:58 <rain1> klys mind if i share this patch and info about smallc with #bootstrappable
17:17:25 <klange> what is the subject matter of #bootstrappable?
17:17:25 <klys> rain1, it's all pd stuff afaik
17:17:49 <rain1> we're trying to build a toolchain that goes from a hex assembler up to gcc
17:18:44 <clever> rain1: i had seen a blog post explaining how to go that entire process, starting from a hex editor that was written purely with opcodes that you can type in a standard text editor
17:18:50 <clever> rain1: but sadly, the blog has since vanished off the face of the internet
17:18:58 <rain1> I think I saw that blog maybe!
17:19:02 --- quit: trout (Ping timeout: 265 seconds)
17:19:15 <clever> https://www.reddit.com/r/lowlevel/comments/3vs1oz/bootstrapping_a_simple_compiler_from_nothing/ is where i had first seen it
17:19:16 <bslsk05> www.reddit.com: Bootstrapping a simple compiler from nothing : lowlevel
17:19:24 <rain1> oh maybe not, it wasn't done with printable ones. that's a cool twist
17:20:24 <clever> https://web.archive.org/web/20170318033104/http://www.rano.org/bcompiler.html
17:20:29 <clever> rain1: oh nice, its on the archive!
17:21:08 <klange> "rather than start with the raw hardware" aw, but that's where the fun is
17:21:17 --- join: ybyourmom (~ybintell@vampire.ertos.nicta.com.au) joined #osdev
17:21:31 <clever> yeah, it assumes you have a working linux kernel, and can run ELF binaries
17:22:30 <clever> rain1: i may be mis-remembering it slightly, he appears to start with the need for a program that can turn hex into binary
17:23:32 <rain1> https://bootstrapping.miraheze.org/wiki/Main_Page i made a wiki for info about these kinds of projects
17:23:33 <bslsk05> bootstrapping.miraheze.org: bootstrapping
17:23:42 --- quit: islandsparky (Ping timeout: 252 seconds)
17:24:09 <rain1> https://github.com/ras52/bootstrap is similar to bcompiler, pretty interesting read with a few sucessions of B and C like programming languages
17:24:10 <bslsk05> ras52/bootstrap - Richard's compiler bootstrap experiment (0 forks/2 watchers)
17:24:24 --- quit: sh3iny (Ping timeout: 250 seconds)
17:25:34 <klys> rain1, are you writing a book?
17:25:36 --- join: plonk (~plonk@rosa.physik-pool.tu-berlin.de) joined #osdev
17:25:50 <rain1> im not writing abook
17:26:33 --- join: sh3iny (~mike@gateway/tor-sasl/sh3iny) joined #osdev
17:27:20 --- quit: chao-tic (Ping timeout: 260 seconds)
17:28:56 --- quit: kimundi (Ping timeout: 240 seconds)
17:29:53 <klys> rain1, what language do wikis use?
17:31:10 <rain1> I think it's called wikimark
17:31:42 <klys> wikimark isn't perl, python, php, lua, ruby, rust, etc.?
17:31:52 <klange> What wiki?
17:31:55 <rain1> oh did you mean the app, it's PHP
17:32:00 <klange> mediawiki is php
17:32:08 <klys> o ok
17:32:12 <klys> :(
17:40:40 --- quit: ALowther_ (Remote host closed the connection)
17:41:00 --- join: ALowther_ (~Alowther_@107.144.136.35) joined #osdev
17:43:44 --- quit: ALowther_ (Client Quit)
17:47:10 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
17:51:08 --- quit: variable (Ping timeout: 276 seconds)
17:53:29 --- join: AIOP (ad102383@gateway/web/freenode/ip.173.16.35.131) joined #osdev
17:53:48 <AIOP> Does the operating system itself handle .bss zeroing?
17:54:19 <AIOP> It would load the exe by collecting a chunk of .bss and zeroing it, then cloning the .data into memory too
17:54:50 <clever> AIOP: one way i would implement it, is within the static ELF loader or dynamic linker loader, to mmap() /dev/zero in copy-on-write mode
17:54:50 <AIOP> Meaning there isn't a hardware level operating that controls this...
17:55:19 <AIOP> Well I am a sadistic person who is creating their own 'elf' file format
17:55:32 <clever> so when you read it, you just get a shared page of zeros, and if you try to write to it, the pagefault causes the kernel to copy the entire page to an unused one
17:55:57 <AIOP> Ooh I like that idea
17:56:24 <AIOP> Unfortunately my target device probably maps its 32mb of memory by default lol
17:56:25 <chrisf> clever, just making an anonymous mapping ought to be good enough even without explicitly mapping zeros -- kernel needs to zero the fresh pages for you anyway to avoid leakage across processes
17:56:30 <clever> thats standard copy-on-write stuff, which linux fork() uses to entirely get rid of the original need for vfork()
17:56:36 <Mutabah> AIOP: The executable loader is responsible for following zeroing the .bss section
17:56:51 <clever> chrisf: wasnt sure about the defaults, and a lazy dev may omit that when making their own OS
17:57:15 <Mutabah> AIOP: With ELF, it does this because the .bss section is in the uninitialised part of a writable segment
17:57:18 <chrisf> if they hand out pages full of other people's random data they're a lunatic
17:57:38 <Mutabah> (in ELF, the loadable "segments" can have a file size smaller than the memory size, the difference is filled with zeroes)
17:58:45 <AIOP> Mutabah: but what if I like having 200megs of unitialized data sitting in the executable
17:58:52 <AIOP> (0's)
18:00:06 <Mutabah> In the image? that's your choice (bit of a waste though)
18:00:13 <AIOP> yeah lol
18:01:52 <AIOP> clever: I assume these symbols point to memory address 0 or a $zero register?
18:01:59 <AIOP> FFS how did I get a fly in my house
18:02:31 <doug16k> AIOP, he flew
18:03:06 <AIOP> doug16k: he better keep on flying bc the last one that flew in got sprayed with water and threw away to die in a closed heated trash container
18:03:30 <AIOP> I.E. black trash bin in sunlight
18:08:54 <AIOP> Okay so my mips processor throws illegal on a load word/save word operations... So I guess I could use that after some testing. But I guess that is for later, as I am creating a general binary for a developed single-process operating system which allows access to program counter and I prefer the bss to be 0'd manually until I get it working
18:09:08 <AIOP> The 32mb is already fully mapped
18:10:31 --- quit: NightBlade (Ping timeout: 244 seconds)
18:10:44 <clever> AIOP: oh yeah, when i was working with avr-libc, i poked around in its _start code, and it just calls bzero() on the .bss range at bootup
18:11:01 <clever> if your doing a kernel-less thing, you will need to zero .bss yourself
18:11:19 <clever> kernels may need to do that as well, since there is no inteligent loader before it
18:13:37 <AIOP> It has a kernel, yes
18:13:52 <AIOP> Its actually going to be run on a PSP and also an emulator
18:14:03 <AIOP> But I get full kernel access
18:16:30 <AIOP> Ok github pisses me off. I told you to align my text into 4 space tabs not 8.
18:19:20 <AIOP> https://gist.github.com/tilkinsc/18536449ad3d8661884bb76d0281978a
18:19:22 <bslsk05> gist.github.com: Basic Mips Instructions Enumerated · GitHub
18:20:11 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
18:21:48 --- quit: tacco| ()
18:22:07 --- quit: graphene (Remote host closed the connection)
18:22:50 --- quit: trout (Ping timeout: 265 seconds)
18:23:40 --- join: graphene (~graphene@46.101.134.251) joined #osdev
18:29:32 --- join: NightBlade (~user@ip-173-247-149-50.user.start.ca) joined #osdev
18:34:41 --- join: pie__ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
18:35:11 --- quit: promach_ (Quit: WeeChat 2.1)
18:37:44 --- join: sympt_ (~sympt@209.58.137.94) joined #osdev
18:38:30 --- quit: pie_ (Ping timeout: 260 seconds)
18:39:48 --- quit: sympt (Ping timeout: 240 seconds)
18:46:16 --- join: nicht (~nicht@177.205.17.2.dynamic.adsl.gvt.net.br) joined #osdev
18:46:16 --- quit: nicht (Max SendQ exceeded)
18:48:14 --- quit: JusticeEX (Ping timeout: 244 seconds)
18:48:39 --- quit: light2yellow (Quit: light2yellow)
18:51:25 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
18:52:43 --- quit: ^Inuyasha^ (Ping timeout: 256 seconds)
18:54:42 --- quit: variable (Ping timeout: 240 seconds)
18:55:28 <klange> Should probably get a nice mode setting menu in the EFI loader, but for now you can pick 1025x768, 1920x1080, biggest, or "prompt at each"...
18:56:18 <klange> virtualbox happily gave me a 3840x2160 - wonder if it did that because I have a display with that resolution on this host...
18:57:17 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
18:57:56 <CrystalMath> what does the NW bit in CR0 do?
18:58:06 <CrystalMath> wikipedia says it disables write-through caching
18:58:10 <CrystalMath> but that makes little sense
18:58:22 <CrystalMath> wouldn't it make more sense if there was a bit to disable write-back caching?
18:58:32 <doug16k> CrystalMath, CD and NW are complicated. see the intel manual
18:58:52 <doug16k> why would you ever want to disable caching? want to kill performance deliberately?
18:59:39 <CrystalMath> just trying to think of a better name for the (1 << 29) constant :P
18:59:59 --- quit: MarcinWieczorek (Quit: WeeChat 2.1)
19:00:00 <CrystalMath> i'm wrapping up CPU stuff to make the rest of my system a bit more generic
19:00:04 <doug16k> it's insane to set them to anything other than CD=0 NW=0
19:00:06 <klange> qemu/ovmf gave me a 2560x1600... interesting
19:00:07 <Mutabah> doug16k: Avoid meltdown :)
19:00:31 <CrystalMath> Mutabah: there might be an MSR to specifically disable speculative execution
19:00:37 <klange> (I think 2560 or something around there may actually be the largest format supported by QEMU's internal framebuffer driver, based on my own modesetting experiments with it)
19:01:16 --- join: ^Inuyasha^ (~quassel@vmi86808.contabo.host) joined #osdev
19:02:43 <klys> klange, does the entire framebuffer get mapped into address space?
19:04:15 <klange> Yes, that's generally how a linear framebuffer works - each pixel is directly addressable.
19:04:35 <klys> so, 32-bit code does it too?
19:05:07 <klange> Yes. But even a huge 3840x2160 framebuffer is only around 32 MB.
19:05:13 <klange> So I wouldn't worry much about it.
19:06:09 <klange> It's not a matter of code doing it, it's how the hardware works.
19:06:18 <klys> which register tells it where to map?
19:06:36 <klange> Something specific to the device.
19:07:10 <klys> and your device is an intel integrated gpu?
19:07:13 <klange> ?
19:07:15 <klange> This is EFI modesetting, so I have *no idea* what interface it could be using behind the scenes. Could be calling a man in South Dakota and asking him, for all I know.
19:07:22 --- join: pie___ (~pie_@unaffiliated/pie-/x-0787662) joined #osdev
19:07:39 <klange> Where did you get intel out of this conversation? I said qemu and virtualbox.
19:07:57 <CrystalMath> klys: it's device-specific, yes
19:07:59 <klange> Both of those implement a magical bochs-derived virtual graphics card.
19:08:09 <klys> well when you said ovmf I thought passthrough
19:08:13 <CrystalMath> klys: for example, the Cirrus CL-GD5434 has extended sequencer registers
19:08:29 <klange> Passthrough of what? OVMF is a qemu-specific EFI implementation.
19:08:31 --- quit: CheckDavid (Quit: Connection closed for inactivity)
19:08:47 <klange> fuck the cirrus, tho
19:08:55 <CrystalMath> i should totally write a driver for the cirrus Alpine chipset
19:08:57 --- join: adam4813 (uid52180@gateway/web/irccloud.com/x-rnnweafuctzyvcdx) joined #osdev
19:09:01 <CrystalMath> it's my favorite graphics card design
19:09:03 <klys> ovmf works to passthrough my GTX 960, for example.
19:09:08 <CrystalMath> mostly because it kept ALL the legacy VGA stuff
19:09:12 <CrystalMath> and i love legacy stuff :)
19:09:50 <CrystalMath> when i read the ATI Rage specification... i felt rage
19:10:14 <CrystalMath> none of the VGA registers work once the card switches to VESA mode :(
19:10:17 <klys> ati is now amd, right?
19:10:19 --- quit: pie__ (Ping timeout: 264 seconds)
19:10:32 <CrystalMath> klys: yes but the ATI Rage is very old
19:10:41 <klys> yes.
19:10:41 <CrystalMath> still, i don't like the direction they went in
19:10:54 <CrystalMath> and they only went further down that road
19:11:07 <CrystalMath> "let's just delete the past"
19:11:14 <chrisf> eh, the vga register interface can go jump in the lake
19:11:44 * CrystalMath hugs a 486 computer
19:11:57 <CrystalMath> 486 PC i mean
19:12:35 <CrystalMath> i'm probably the only one who still cares about legacy computers :(
19:12:55 <geist> oh dont get us started
19:13:20 <klys> it feels that way sometimes, no? check out my links though, http://show.ing.me/
19:13:24 <bslsk05> show.ing.me: show.ing.me: now seeing...
19:14:04 <chrisf> "kindof gets the job done with very little hardware" and "sensible" are different things
19:17:20 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
19:17:23 <klys> crystalmath, bucking video standards has been going on ever since agp was a thing, so yeah, ati was probably the demise of vesa/vbe.
19:18:33 <CrystalMath> klys: well it's just that from the very start ATI thought "VGA sucks, let's avoid implementing it as much as possible"
19:18:47 <CrystalMath> so standard VGA apps don't work correctly
19:21:10 --- quit: gattuso (Ping timeout: 256 seconds)
19:22:50 <CrystalMath> they didn't continue where VGA left off, they just threw it away and started from scratch
19:22:50 <klys> the thing back then that became the next wave of standardization was opengl, and that's just an api
19:22:50 <CrystalMath> while Cirrus continued from where VGA left off
19:22:52 --- join: gattuso- (~gattuso@pompel.me) joined #osdev
19:22:52 --- join: JusticeEX (~justiceex@pool-98-113-143-43.nycmny.fios.verizon.net) joined #osdev
19:22:53 --- quit: lkurusa_ (Ping timeout: 268 seconds)
19:22:59 --- join: lkurusa_ (~pi@BC06AE14.catv.pool.telekom.hu) joined #osdev
19:23:00 <geist> i have an old 386 with a Tseng Labs 4000 in it
19:23:07 <geist> got the docs for it, pretty neat to see the low level details
19:23:29 <klys> are the docs for et3000 still online?
19:23:42 <geist> dunno, but i think the et4000 was pretty close
19:24:39 <klys> well I have a couple of 8-bit vga cards, one's a cirrus and the other zymos
19:25:22 <klys> they'll probably work in mode 0x12 though 0x13 doesn't seem too likely.
19:25:54 <geist> sadly despite me upgrading the et4000 to 1MB, it can't seem to reliably do any mode > 640x480
19:25:59 <klange> Such an amazing discussion coming from me calling QueryMode in an EFI application.
19:26:05 <geist> may be a combination of my LCD not syncing up or it not having a DAC fast enough
19:26:15 --- join: Goplat (~Goplat@reactos/developer/Goplat) joined #osdev
19:26:16 <geist> it'll however do 640x480x256 color
19:28:20 <klys> geist, did you get the bit earlier about small-c?
19:28:51 <geist> negative
19:29:11 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
19:29:33 <klys> I have a patch against small-c that makes it compile duplicates via ccpm/86 v3
19:29:49 <geist> cool
19:30:58 <klys> it was 2:30 ago
19:31:38 <jjuran> CrystalMath: I love legacy computers. It's why I still develop for 68K. :-)
19:32:26 --- quit: trout (Ping timeout: 265 seconds)
19:32:36 <klys> jjuran ye ought to talk with elz on #freedos about his amiga
19:33:37 <jjuran> klys: I never got into Amiga, but I have a lot of Mac nostalgia
19:33:50 <AIOP> oh by the way, I was able to load and boot my grub multiboot 1 x86 os on a walmart fat12 1.5mbit flash drive
19:34:33 <jjuran> The "68080" project is really cool, though
19:36:50 <AIOP> I am assuing everyone here has at least 1 raspberry pi?
19:37:30 <jjuran> I have two, though my next SBC might be a different brand
19:37:35 <klys> I know a few folks with those, not myself, aiop.
19:37:46 <klange> I have an old one somewhere.
19:37:52 <klange> I think it's probably on a shelf in my apartment.
19:37:58 <doug16k> AIOP, I have one
19:38:26 <AIOP> So I got a rbpi3b+ and I was like oh it didn't come with a sd card
19:38:46 <klange> current state of my efi loader https://i.imgur.com/yctPnwQ.png
19:38:50 <AIOP> So I was able to configure ssh onto it by loading a file into root named ssh and setting an option in the config to enable boot from flash drive
19:38:58 <AIOP> Headless ftw
19:39:58 <AIOP> Then I was trying to configure grub on it like an idio
19:40:54 <klys> aiop, reasonably sure you have to use u-boot on arm boxen
19:40:55 <AIOP> The problem with that is lack of grub boot menu
19:41:21 <AIOP> I also tried WOL wake on lan
19:41:26 <AIOP> that isnt supported
19:41:52 <AIOP> https://gist.github.com/tilkinsc/4f7db84d96ec50cf3ff80ae991bfe5d5
19:41:54 <bslsk05> gist.github.com: A simple WINDOWS ONLY example using winsock to wake on lan WOL in C · GitHub
19:41:55 <AIOP> cuz you know fuck that
19:41:58 <geist> yah the rpis are uboot based
19:44:43 <AIOP> My RPI is like my access point to my PC at home
19:44:51 <AIOP> I also compiled gcc 8.3.0 on it lol
19:45:02 <AIOP> took like 8+ hours
19:45:09 <AIOP> sat at 83-85c
19:45:23 <geist> rpi1s are not very fast at all
19:45:30 <geist> rpi3s are a bit quickier since they have more mhz and 4 cores
19:45:44 <AIOP> This was on rpi3
19:45:46 <AIOP> b+
19:45:59 <AIOP> And
19:45:59 <AIOP> and
19:46:03 <AIOP> I forgot to ,lto
19:46:12 <AIOP> So fml
19:46:27 --- quit: JusticeEX (Ping timeout: 265 seconds)
19:47:14 <AIOP> `Configured with: ./../../src/gcc-8.1.0/configure -v --enable-languages=c,c++ --prefix=/usr/local/gcc-8.1.0 `
19:51:18 <AIOP> Hmm should gcc 8.3.0 be rebuilt with gcc 8.3.0
19:54:30 <klys> if you got plendy of time on your hands and are not too busy configuring linux
19:55:32 <AIOP> Well I port forwarded its port so I have login access to it at work lol
19:56:57 <AIOP> Would my os build faster if I -j8 instead of -j4 on a 4 core pc because 4 more jobs would keep jobs in queue rather than pushing to queue each time
19:57:23 <klys> nice it too
19:58:20 <klange> real 0m4.817s, user 0m21.440s - dem some good build times
20:01:02 --- quit: freakazoid0223 (Remote host closed the connection)
20:01:06 <AIOP> Do OSes dynamically switch what cores execute what threads, because say your 4th thread is bolstered with work and all the threads worked on 1-3 thereof and all activity stopped on the 4th thread
20:01:47 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
20:02:19 <klange> Threads are often tossed around between different cores with various policies and configurable options for how that is done.
20:02:47 <AIOP> Ive never actually worked with threads outside java lol
20:04:01 <AIOP> Okay so apple juice and vodka and back to programming
20:04:05 <AIOP> Thanks for the chat guys
20:05:02 --- quit: variable (Ping timeout: 276 seconds)
20:05:42 --- quit: nj0rd (Ping timeout: 240 seconds)
20:08:00 <doug16k> AIOP, assuming you don't have HT, 4 or possibly 5 is probably optimal. 8 will just thrash your cache
20:10:59 <doug16k> you can measure, just do this: make clean; time make -j4 vs mak clean; time make -j8
20:11:22 <doug16k> compare the times, and try 5 if 8 is worse than 4
20:14:58 --- quit: chao-tic (Ping timeout: 265 seconds)
20:15:35 <AIOP> not familiar with cache thrashing casues
20:17:00 --- join: spare (~user@unaffiliated/spareproject) joined #osdev
20:19:44 --- join: nj0rd (~nj0rd@200116b84557eb0021ef282d6a526f6d.dip.versatel-1u1.de) joined #osdev
20:20:38 --- join: chao-tic (~chao@203.97.21.86) joined #osdev
20:21:43 --- quit: pie___ (Ping timeout: 264 seconds)
20:31:58 <doug16k> AIOP, just reduces performance
20:41:29 <klange> An interesting trend I've found in modern hardware is that PS/2 keyboards are often emulated from USB devices but not mice. Makes sense.
20:41:43 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
20:42:16 <klange> Also fuck me my framebuffer blitting is slow, I should look at what cache setup I'm using... https://i.imgur.com/hJkM1yO.jpg
20:43:17 <klange> also extra lol I may have neglected to cap the usable memory count to 4GB...
20:44:27 --- quit: trout (Ping timeout: 265 seconds)
20:46:42 --- join: GRD (~GRD@125.162.153.41) joined #osdev
21:10:23 --- join: xenos1984 (~xenos1984@22-164-191-90.dyn.estpak.ee) joined #osdev
21:10:32 --- quit: GRD (Quit: Leaving)
21:14:29 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
21:16:42 --- quit: variable (Ping timeout: 240 seconds)
21:19:03 <bluezinc> klange: holy crap, that looks really good!
21:28:46 --- join: zeus1 (~zeus@154.227.4.140) joined #osdev
21:29:27 --- join: islandsparky (1816e74b@gateway/web/freenode/ip.24.22.231.75) joined #osdev
21:34:40 --- join: sympt (~sympt@209.58.135.106) joined #osdev
21:34:42 --- quit: zeus1 (Ping timeout: 240 seconds)
21:37:11 --- quit: sympt_ (Ping timeout: 244 seconds)
21:46:01 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
21:49:41 --- quit: trout (Ping timeout: 276 seconds)
21:50:20 <klange> Well my EFI loader works on at least one example of real hardware, so I think it's Done™ for now.
21:50:29 <klange> On to better things... like this text layout engine...
21:54:21 --- join: zeus1 (~zeus@160.242.133.23) joined #osdev
21:54:26 --- quit: chao-tic (Quit: WeeChat 1.0.1)
21:55:12 --- quit: Nach0z (Ping timeout: 240 seconds)
21:59:19 --- quit: zeus1 (Ping timeout: 268 seconds)
22:00:10 --- join: zeus1 (~zeus@160.242.135.64) joined #osdev
22:02:32 --- join: Nach0z (~nach0z@c-98-192-72-54.hsd1.ga.comcast.net) joined #osdev
22:02:32 --- quit: Nach0z (Changing host)
22:02:33 --- join: Nach0z (~nach0z@unaffiliated/nach0z) joined #osdev
22:05:00 --- quit: zeus1 (Ping timeout: 260 seconds)
22:05:42 --- join: zeus1 (~zeus@154.227.4.140) joined #osdev
22:16:12 --- join: antkit (uid256318@gateway/web/irccloud.com/x-dgzkltqrbrbdurpj) joined #osdev
22:18:37 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
22:22:05 --- quit: variable (Ping timeout: 265 seconds)
22:23:34 <Amaan> klange: Nice, did you use gnu-efi or edk2 (or something else)?
22:26:20 <klange> gnu-efi, but fwiw that's 99% headers 1% crt0
22:26:44 <klange> Considering writing the headers from the EFI specs myself and stripping out the middleman.
22:26:54 --- quit: bauen1 (Remote host closed the connection)
22:27:46 <Amaan> klange: Yeah, I've seen iPXE do something like that
22:27:48 <Amaan> https://blog.whatthedude.com/post/uefi-app-options/#options
22:27:48 <bslsk05> blog.whatthedude.com: Options for creating a UEFI application image - What The Blog?
22:28:00 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
22:28:18 --- quit: spare (Quit: leaving)
22:28:21 <Amaan> Sort of how wimboot or Linux's EFISTUB work, yeah?
22:30:58 <Amaan> klange: The method I've been using is just using FreeBSD's UEFI loader - replace their ELF kernel with your own, and voila, you get your UEFI bootloader for free
22:32:10 --- quit: tadni (Client Quit)
22:40:45 <klange> Amaan: I previously used Git, which was happily capable of loading my OS just fine; this EFI loader is part of a project to more completely do everything from scratch; it's the first pass at an EFI loader, so I used gnu-efi to have a known-good base.
22:41:36 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
22:42:07 --- quit: NightBlade (Ping timeout: 264 seconds)
22:42:32 <klange> ...
22:42:35 <klange> I previously used Grub*
22:42:42 <klange> fucking hell I am losing my mind
22:42:54 <klange> maybe osdev really does drive people insane
22:43:02 --- quit: bm371613 (Quit: Konversation terminated!)
22:43:28 <klange> Amaan: I used GRUB's mkrescue to build CDs for years - both EFI and BIOS CDs worked, though I don't recall ever being able to build hybrid CDs with their tooling.
22:44:12 <klange> My CDs have both a rudimentary BIOS bootloader that only works in specific environments (eg. ATAPI CD), as well as a 32-bit and 64-bit EFI loader.
22:44:37 <klange> I'm not sure I have anywhere to test the 32-bit EFI loader in the wild, but the 64-bit one seems to be working, even with its shoddy jump back to protected mode to actually run the OS.
22:45:52 --- join: AverageJ0e (~joe@ip72-222-140-99.ph.ph.cox.net) joined #osdev
22:47:44 <Amaan> klange: Nice, that's quite cool! I'll have to look into how mkrescue does it. Did you do the 32-bit and 64-bit (U)EFI loaders using grub-mkrescue?
22:49:01 <Amaan> How are you doing graphics for your OS, btw? I don't quite understand anything beyond the basic VGA at b8000, but I think EFI has a framebuffer you can use even after ExitBootServices?
22:49:04 <klange> No, they are my own loaders :) https://i.imgur.com/yctPnwQ.png
22:49:28 <klange> I install them into a FAT image which gets set up as the EFI partition with xorriso.
22:49:43 <Mutabah> Amaan: Generally you get the firmware to set a framebuffer mode and tell you the location/format of that framebuffer
22:49:53 <klange> I also do some magic so that the BIOS bootloader sees files on the CD directly as part of the ISO filesystem, that was a not-super-useful-but-still-fun hack.
22:50:00 --- quit: tadni (Remote host closed the connection)
22:50:11 <klange> My EFI loaders support the EFI framebuffer mode setting interface.
22:50:16 <Amaan> Holy. Shit. This is quite cool! zv
22:50:18 <Amaan> https://github.com/klange/toaru-nih
22:50:19 <bslsk05> klange/toaru-nih - A completely-from-scratch hobby operating system: bootloader, kernel, drivers, C library, and userspace including a composited graphical UI, dynamic linker, network stack, etc. (3 forks/33 watchers)
22:50:20 <Mutabah> Amaan: Then you just write image data to that location, and the card renders from it
22:50:43 <klange> The BIOS loader doesn't do any mode setting, but it's mostly for VMs like QEMU and Bochs, so I'm not going to bother pursuing that anymore.
22:51:25 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
22:51:30 <klange> I should bump that version number to 2.0 with all this EFI work...
22:52:51 --- quit: graphene (Remote host closed the connection)
22:52:59 <Amaan> That makes sense. I wonder if the simplest method for me will continue to be using FreeBSD's bootloader (they do even write the framebuffer's location to the EFI console, which is very nice during development)
22:54:02 <Amaan> Oh, well - graphics are low on my priority list for now anyway. I need interrupts and hardware clock drivers sooner
22:54:12 --- quit: trout (Ping timeout: 240 seconds)
22:54:23 --- join: graphene (~graphene@46.101.134.251) joined #osdev
22:57:13 <Amaan> klange: Btw, about 32-bit EFI firmware in the wild - IIRC pre-2008 Macs have i386-efi firmware
22:57:35 <Amaan> https://help.ubuntu.com/community/UEFIBooting#Setting_up_GRUB2_.28U.29EFI
22:57:37 <bslsk05> help.ubuntu.com: UEFIBooting - Community Help Wiki
22:58:50 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
22:59:12 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
22:59:19 --- quit: tadni_ (Remote host closed the connection)
22:59:22 <Amaan> klange: Sorry to bother you, but how does grub-mkrescue's bootloader work? At what point does it hand off control to your OS (and is your OS just an ELF
22:59:30 <Amaan> ?)
22:59:33 <klange> It's just GRUB.
22:59:45 <klange> My OS implements multiboot, always has.
23:00:11 <klange> My own bootloader also uses multiboot, so in theory you could adapt it to work with other multiboot kernels (and I've experimentally used it to load my future kernel project)
23:00:31 <Amaan> Right, so multiboot puts you in protected mode. For x64 systems, do you have code to raise to long-mode too?
23:01:16 --- join: myvar (~myvar@105.186.208.217) joined #osdev
23:01:23 --- quit: drakonis (Remote host closed the connection)
23:01:34 <klange> I don't have a 64-bit kernel, so my 64-bit EFI loader actually does the opposite.
23:02:14 <klange> (Okay I do have a 64-bit kernel in an experimental state, and it does the jump to long mode - adjustments will be needed to get it working with my 64-bit EFI loader - but it could jump between the two just fine... just a silly thing to do)
23:02:20 <Amaan> Hahaha, okay, that's kind of funny :D
23:05:05 --- quit: zeus1 (Ping timeout: 260 seconds)
23:10:25 --- quit: CrystalMath (Quit: Support Free Software - https://www.fsf.org/)
23:11:49 --- join: SopaXorzTaker (~SopaXorzT@unaffiliated/sopaxorztaker) joined #osdev
23:17:52 --- quit: tadni (Remote host closed the connection)
23:19:31 --- join: drakonis (~drakonis@unaffiliated/drakonis) joined #osdev
23:20:06 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:20:11 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:23:50 --- join: trout (~variable@freebsd/developer/variable) joined #osdev
23:24:09 --- join: manzerbredes (~loic@myriads-lg.irisa.fr) joined #osdev
23:25:42 --- join: S_Gautam (uid286066@gateway/web/irccloud.com/x-qgfmhmzwvvgcvhgs) joined #osdev
23:26:51 --- quit: variable (Ping timeout: 265 seconds)
23:26:52 --- quit: tadni_ (Remote host closed the connection)
23:26:52 --- quit: tadni (Remote host closed the connection)
23:27:30 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:27:51 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:27:51 --- quit: tadni_ (Read error: Connection reset by peer)
23:27:51 --- quit: tadni (Remote host closed the connection)
23:30:26 --- join: tadni (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:30:51 --- join: tadni_ (~tadni@24-182-175-184.dhcp.stls.mo.charter.com) joined #osdev
23:31:29 --- quit: tadni_ (Remote host closed the connection)
23:32:22 --- join: immibis (~chatzilla@222-155-163-212-fibre.sparkbb.co.nz) joined #osdev
23:42:40 --- part: Guest16831 left #osdev
23:42:51 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
23:43:26 --- quit: apetresc (Ping timeout: 240 seconds)
23:45:38 --- join: apetresc_ (~apetresc@CPEbc4dfb720b93-CMbc4dfb720b90.cpe.net.cable.rogers.com) joined #osdev
23:46:22 --- quit: bemeurer (Client Quit)
23:46:44 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
23:46:44 --- join: zeus1 (~zeus@62.56.248.65) joined #osdev
23:48:31 --- quit: bemeurer (Client Quit)
23:48:51 --- join: bemeurer (~bemeurer@c-24-6-228-111.hsd1.ca.comcast.net) joined #osdev
23:52:34 --- join: grouse (~grouse@83-233-9-2.cust.bredband2.com) joined #osdev
23:54:27 --- join: variable (~variable@freebsd/developer/variable) joined #osdev
23:57:44 --- quit: trout (Ping timeout: 276 seconds)
23:59:20 --- join: nortega (~nortega@gateway/tor-sasl/deathsbreed) joined #osdev
23:59:59 --- log: ended osdev/18.07.11