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=19&m=5&d=20
12:10:56 <doug16k> heat, ya the q thing being needed in .code64 is a bit annoying. bug
12:11:17 <doug16k> should be the other way around, need 'l' suffix to not have rex prefix
12:24:58 <doug16k> lret is retf
12:26:22 <doug16k> iirc gas would accept retf, but clang's builtin assembler insists on AT&T opcode names
12:27:08 <doug16k> lret is better in AT&T code
02:32:54 <doug16k> it's funny to read the hdparm man page. the number of occurrences of "do NOT use this option!" in there is hilarious
02:56:05 <doug16k> my favourite part is "This is because setting the value requires a pair of back-to-back drive commands, but there is no way to prevent some other command from being inserted between them by the kernel"
02:56:47 <doug16k> "... So if it fails initially, just try again"
02:57:28 <doug16k> what a hack
02:59:02 <bcos> It's worst than that - how messed up does an OS need to be before a random user/admin is more able to determine hardware parameters than the device driver?
03:00:19 <doug16k> ya
06:15:51 <mquy90> doug16k, it is run via qemu/bochs, I thought it is a disk image because I did what https://wiki.osdev.org/GRUB#HDD_Image_Instructions_for_OS_X_users said
06:30:29 <doug16k> yes but you could mean accessing it like a drive from inside an OS, from a disk controller driver, or, you could mean doing things with the disk image on your dev machine with tools
06:31:21 <doug16k> to access a hard disk image you should probably implement an AHCI driver
06:32:12 <doug16k> you could also implement an IDE driver, which would be simpler but not as useful on real hardware
06:35:40 <doug16k> ahci is fairly clearly documented. it will cause you to add things needed by many drivers, like building an API for hooking, unhooking, sharing, and handling, and ending IRQs, looking for PCI IRQ signalling methods like MSI/MSI-X, mapping MMIO ranges, getting DMA physical region descriptors, handling requests until they complete, an asynchronous completion signalling mechanism, etc
06:36:40 <doug16k> you will use the same facilities for disk controllers, usb controllers, and network interfaces
06:38:12 <doug16k> they all boil down to reading and writing pages of memory to or from some far away thing on request, they all have a concept of opening, sending, receiving, etc
07:03:51 <doug16k> this query worked in wolfram alpha: 2^63 nanoseconds after 00:00:00 UTC january 1 1970
07:03:56 <doug16k> man I love that website
07:04:52 <doug16k> changing the word "after" to "before" also works perfectly
07:07:35 <doug16k> I guess the year 2262 problem is when you are so cheap, 8 bytes is all you use to represent a date, when you should be using the new 256 bit date format that supports different solar systems
07:12:37 <doug16k> if you made a sound effect for a cpu, what would it be? I thought a chicken sound effect would be right, it's the sound of the buck converter stepping the 12V down to ~1.2V with high amperage capacity
07:13:01 <doug16k> it'd go "buck buck buck buck" wouldn't it?
07:13:42 <doug16k> 6 to 8 overlapping phases of "buck" sounds?
07:51:44 <mquy90> doug16k, I thought that ata is what I might need?
07:52:40 <mquy90> from my understand, it works like booting from our harddisk which is installed os (mbr)
08:54:20 <doug16k> ATA is the drive command set. you have to write a driver for a host controller to send ATA commands to a drive
08:54:36 <doug16k> an old simpler host controller is IDE, newer is AHCI
08:56:32 * bcos wonders if mquy90 is doing a "stage 1 loads stage 2" thing; and needs to use "int 0x13"
08:56:51 <doug16k> I asked a few times
08:57:11 <doug16k> didn't catch the answer if it went by
08:57:35 <doug16k> wants to do something to a disk image
08:58:14 <mquy90> bcos, I use grub instead of my own bootloader so I think no? because it is in pmode
08:59:09 <mquy90> do you have an example, or docs doug16k, I am a bit confused
08:59:17 <bcos> mquy90: There's mostly 2 cases - during early boot (where you have to rely on boot loader or firmware) and later on (where you start with PCI bus scan and load drivers for whatever that found)
08:59:48 <doug16k> example disk controller driver?
09:00:21 <mquy90> yup, I think I might misunderstand
09:00:33 <doug16k> https://github.com/doug65536/dgos/blob/master/kernel/device/ahci.cc
09:00:35 <mquy90> bcos, the later one
09:00:40 <doug16k> see the ahci spec pdf
09:02:56 <mquy90> currently, I am checking this source code https://github.com/szhou42/osdev/blob/master/src/kernel/drivers/ata.c#L165, maybe better to read spec
09:03:29 <zid> Bear in mind nobody says you have to do ATA over ISA ports
09:03:34 <zid> maybe your controller doesn't even support it
09:03:38 <zid> ATA is just a commandset
09:07:17 <bcos> mquy90: That code looks like it's only for "PCI IDA/ATA controller stuck in legacy mode (and not using native mode), that happens to have DMA engine"
09:09:40 <mquy90> am looking for tutorials or code samples to begin with, but it seems there aren't :(
09:10:01 <doug16k> mquy90, look for IDE, it is a more commonly used term for what you want
09:14:29 <mquy90> I cannot find it in ide, seem like https://wiki.osdev.org/Category:ATA?
09:14:45 <zid> P
09:18:43 <bcos> Hrm
09:19:23 <bcos> mquy90: Do you have code to scan PCI buses (which starts the right driver for what it finds; unlike the code you were looking at which does the opposite)?
09:20:31 <mquy90> I don't have any code related to drivers, only ports communication https://github.com/MQuy/mos/blob/master/src/kernel/cpu/hal.c#L14
09:22:16 <bcos> Then you need to forget about hard disk controllers until you've written code to scan PCI buses
09:23:28 <mquy90> I just want to support read/write sectors to implement vfs in my disk image qemu-system-i386 -s -boot a -drive format=raw,file=./mos.img
09:24:17 <mquy90> I might misunderstand
09:24:18 <bcos> "I just want to build a roof, I don't want to build the rest of the building under it. I want the roof to fall on my head so that I die. Yay"
09:25:08 <mquy90> ah, I am willing to learn, but not sure which direction 😀
09:25:50 <bcos> You need PCI bus scan next - can't write any PCI device drivers properly until you do that
09:26:05 <zid> I need to do that, I deleted my pci code and replaced it with pci-e :P
09:26:19 <zid> it works, I just need to actually enumerate devices
09:26:53 <bcos> Hrm
09:27:28 <bcos> mquy90: If you only want to work on implementing VFS (and don't really want drivers or PCI stuff yet); then you could do an "initial file system in RAM" thing
09:27:58 <zid> I was hoping to get rid of ISA entirely but I still need to tell the PIC to go away :'(
09:29:09 <mquy90> ah, I know about initrd, but I want to actually read/write in my disk image
09:33:32 <bcos> Yeah. I want to buy a Ferrari. People keep telling me I need to earn lots of $$ first, but I just ignore them.
09:34:33 <bcos> :-)
09:37:14 <mquy90> so starting with PCI bus -> hard disk controllers
09:37:44 <bcos> Yes
09:38:08 <Brnocrist> https://www.bu.edu/rhcollab/2019/04/11/a-fork-in-the-road/
09:38:14 <Brnocrist> he is back
09:39:27 <bcos> Start with (recursive) PCI bus scan; and when doing that you'll end up with some kind of "handle_PCI_function(busNumber, deviceNumber, functionNumber);" which would grab the info for the device (class code, vendor ID, device ID) and figure out if it can/can't start a driver for the device, that then starts the driver and tells the driver which resources (IO ports, memory mapped IO areas, etc) the device needs to use
09:41:35 <bcos> Brnocrist: Not sure I understand - it's a Unix clone, it's supposed to be shit, it needs "fork()" to be shit - no discussion needed.
09:42:18 <bcos> (alternative phrasing: it can't get rid of fork without breaking compatibility and failing to meet the design goals)
09:42:56 <mquy90> thanks bcos, seem like what I need right now (got confused where should I start)
09:43:30 <bcos> mquy90: Cool :-)
09:44:01 <bcos> Will also help for everything else you want in future - same PCI bus scan code can start AHCI drivers, sound card drivers, SCSI drivers, USB controller drivers, ...
09:44:35 <Brnocrist> bcos: no discussion in precence of Drepper? no way
12:10:41 <pterp> I was reading the osdev wiki articke on PCI, and this sentence is very confusing: "The BAR register is naturally aligned and as such you can only modify the bits that are set." So if a device that uses 1MB is, (hypothetically, this would never happen) mapped right at one megabyte, which is 0x100000, i could never move it higher in the address space?
12:12:56 <pterp> I get the part about keeping it aligned (the lower 5 digits must stay 0), but why couldn't you move it higher in the address space in that scenario? (or thinking about it, any scenario, you could ony move it lower)
12:16:48 <zid> Did you skip the step where you wrote 111111111111111 to it first
12:18:03 <pterp> i'm not trying to find the size. But that sentence seems to imply that no matter what, you can ony write lower values to it, which seems slightly pointless.
12:18:49 <zid> It means prior
12:18:54 <pterp> Or does the card go into a specal mode when you write all ones that turns on that restriction?
12:18:57 <zid> the step where you wrote 1 to every bit
12:19:20 <pterp> yes, what about it?
12:19:23 <zid> include a mental 'now' before the word set
12:19:36 <zid> You can only change the bits which are NOW set (after writing 0xFFFFFFFFFF to the BAR)
12:20:17 <zid> 0x10000 -> 0xFFF10000 or whatever
12:20:20 <pterp> ohhhh. tht makes a whole lot more sense.
12:21:59 <pterp> Now, question 2, When you detect a conflict between PCI dvices (or just want to remap a device), how do you find what parts of physical manory are not occupied, so you can map the device in?
12:22:11 <pterp> *physical memory
12:22:27 <zid> Know where everything else is
12:22:38 <zid> e820 + device enumeration
12:22:45 <pterp> e280?
12:23:15 <zid> http://www.uruk.org/orig-grub/mem64mb.html
12:23:33 <zid> grub can provide it to you in the multiboot struct
12:23:37 <pterp> The GRUB memory map.
12:23:48 <zid> Not grub, E820, grub just gives you it verbatim
12:24:09 <zid> note things overlapping at boot is a bios bug
12:24:16 <zid> so the e820 might be buggy anyway who knows
12:25:41 <bcos> pterp: You can't just put whatever you like in BARs - you also need to program bridges, etc so that they forward the right range to the other side of the bridge. Ends up being a "wholesale reconfigurement" of everything related to PCI
12:27:41 <pterp> From the multiboot 2 memory map doc: "and all other values currently indicated a reserved area". That doesn't necessarily meanaddress space completely unoccupied, so wer'e back at square one. Also, when i say unoccupied address space, that means not occuppied by RAM or ROM. It includes address space used by PCI devices"
12:28:55 <pterp> bcos: What parts in the PCI-to-PCI bridge header do I have to change?
12:31:31 <bcos> pterp: Mostly: memory base, memory limit, prefetchable memory base, prefetchable memory limit, IO base and IO limit; and their "upper halves"
12:31:57 <bcos> ..which is almost everything from offset 0x1C to 0x34 in the bridge's config space
12:31:58 <pterp> what does prefetchable mean?
12:32:27 <bcos> Means, CPU can prefetch it safely (because there's no side effects on reads)
12:33:20 <bcos> ..like, if a PCI device has a register and the docs say "A read from this register causes the world to explode", then that wouldn't be prefetchable
12:33:28 <pterp> what if i just move mappings around in the specified ranges? I'd expect there to be some free space.
12:34:12 <bcos> I'd expect the ranges are just large enough to cover the sum of areas each device uses; so you can't really move anything because there's no free space in the rage
12:34:14 <bcos> (range
12:34:19 <pterp> ok.
02:59:56 <Bitweasil> zid, there's no difference between a PCI and PCI-E parser.
03:00:09 <Bitweasil> Same exact software interface, though you get the memory mapped regions with PCI-E.
03:01:23 <Bitweasil> Also, I'd highly suggest not moving PCI devices around unless you know what you're doing. The BIOS/EFI almost certainly leaves them in a usable state.
03:01:25 <Bitweasil> Use them there. :)
03:03:48 <zid> Bitweasil: Incorrect, and I am not that guy
03:05:54 <Bitweasil> Ah, ok.
03:05:56 <Bitweasil> Wrong person, then.
03:06:27 <zid> https://wiki.osdev.org/PCI_Express#Changes_from_the_PCI_Configuration_Space
03:06:33 <Bitweasil> You were mentioning deleting your PCI code and starting over with PCI-E, wasn't sure what you meant by that.
03:06:47 <zid> https://wiki.osdev.org/PCI_Express#Enhanced_Configuration_Mechanism
03:07:01 <Bitweasil> Right, but that's in the memory mapped area. The legacy parsing is identical.
03:07:23 <zid> which I am not doing anymore
03:07:26 <Bitweasil> (and I hate having to parse ACPI tables)
03:07:27 <Bitweasil> Ok.
09:38:46 <mquy90> hi, according to https://wiki.osdev.org/PCI#Recursive_Scan, in checkAllBuses, if(getVendorID(0, 0, function) != 0xFFFF) break;
09:38:55 <mquy90> should it be == instead of !=