klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
sprock has joined #osdev
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
FreeFull has quit []
orthoplex64 has joined #osdev
diamondbond has joined #osdev
diamondbond has quit [Read error: Connection reset by peer]
heat_ has joined #osdev
heat has quit [Read error: Connection reset by peer]
heat_ is now known as heat
srjek has joined #osdev
gog has quit []
gog has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
dutch has quit [Quit: WeeChat 3.3]
dutch has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.3]
x88x88x has joined #osdev
heat has quit [Quit: Leaving]
kingoffrance has joined #osdev
<geist> Bitweasil: also it is a bit strange that the zero register is x31, but i think they did it that way because they map the legacy r0-r14 registers in arm32 to x0-x14
<geist> and then the other modes' arm32 registers map to the higher ones when doing a full 32bit context switch in a 64bit OS
<geist> though as someone had pointed out forever ago, Alpha did the same thing. R31 register was zero, not r0, like youd expect from most other risc machines
<geist> my theory is it was because it mapped nicer to the inevitable vax emulators it was probably running at the time, so they were probably mapping r0-r15 on VAX to r0-r15 on alpha
<geist> which is actually shockingly similar to arm32->arm64 since VAX has a very similar register layout to arm32. i'm sure that's not a coincidence
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
terrorjack has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
<dh`> doesn't the PC being r15 go all the way back to the pdp11? (or was it r7 there?)
<geist> i think so, yeah
<geist> and early VAX could directly run pdp11 opcodes, so there must have been a mapping there. maybe r0-r7 -> r8-r15?
<dh`> no idea
<geist> just double checked though. pdp11 was r0-r5, r6 = stack pointer, r7 = program counter
<geist> vax was r14 = sp, r15 = pc
[itchyjunk] has joined #osdev
Oli has quit [Quit: leaving]
arandomcomrade has joined #osdev
x88x88x has quit [Ping timeout: 264 seconds]
smeso has quit [Quit: smeso]
gorgonical_ has joined #osdev
smeso has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
sdfgsdfg has joined #osdev
arandomcomrade has quit [Quit: Leaving]
nyah has quit [Ping timeout: 256 seconds]
IslandSparky has joined #osdev
ElectronApps has joined #osdev
IslandSparky has quit [Quit: Client closed]
gorgonical_ has quit [Ping timeout: 256 seconds]
<Ameisen> So... I've noted in some tests that basically none of the compilers are able to remove array accesses in trivial cases where the values of the array are known
<Ameisen> and the array itself is static and not a public symbol
<Ameisen> This breaks an assumption that I had.
<moon-child> what do you mean by 'remove array accesses'?
<bslsk05> ​godbolt.org: Compiler Explorer
<moon-child> talking about value_map10[c - 48]?
<moon-child> that seems reasonable to me. Wouldn't expect a compiler to try to convert an array into a function
<bslsk05> ​godbolt.org: Compiler Explorer
<Ameisen> simpler case
<Mutabah> what would it optimise here?
<Ameisen> well, it could literally just return index.
<Mutabah> Seems like an overly specific inference for it to make
<moon-child> I still don't understand why you would expect or want that
<Ameisen> It would depend on the situation, I suppose.
<moon-child> would you want, given int arr[] = {1, 2, 4, 8, 16}, for arr[x] to turn into 1 << x?
<Ameisen> If the array is static constexpr const, though, I more expect it to see the array as a logical device rather than an actual object.
<Ameisen> If the compiler realized that that was doable.
<moon-child> how do you think the compiler would do that?
<klange> Going to go in and redo a bunch of memory management stuff, see if I can't get CoW and mapped files working... CoW is part of the way there, just need to reference count pages so I can free them [and skip the last copy]...
<Ameisen> If it knows the possible indices, and it knows the values that are in the array, I imagine it would resolve that the same way it would optimize away a switch statement.
<moon-child> it doesn't do that for switch statements
<moon-child> well, it does for the specific case of case 0: return 0; case 1: return 1; case 2: return 2 etc., because of conditional constant propagation and block merging
<moon-child> but that doesn't generalise
<moon-child> hmm, i guess that would be value numbering, not constant propagation, actually
<bslsk05> ​godbolt.org: Compiler Explorer
<Ameisen> Actually, this is where it gets odd: https://godbolt.org/z/7PKhd7q76
<moon-child> yes, I understand. I am asking how you expect the compiler to derive more general functions such as 1 << x
<bslsk05> ​godbolt.org: Compiler Explorer
<Ameisen> Well, in general I don't (though it still often manages to do that in more rudimentary cases)
<Ameisen> in my situation, I had a large array that was being used as a lookup table. The first 10 elements or so were basically identity mapped, and smaller templates would only use a subset of it
xenos1984 has quit [Quit: Leaving.]
JerryXia1 is now known as JerryXiao
Burgundy has joined #osdev
zaquest has quit [Remote host closed the connection]
zaquest has joined #osdev
<moon-child> anyone know where I can get dp or hdmi specs? Seems you have to register an account with vesa to download the former, and I could not find the latter anywhere despite prominently marked links labeled 'spec' on an hdmi-related website
<moon-child> https://glenwing.github.io/docs/DP-1.2.pdf found this from 10 years ago
<klange> You can request an older version of the HDMI speci: https://www.hdmi.org/requestform/clickrequestasync?docId=16
<bslsk05> ​www.hdmi.org: Download HDMI HDMI Specification 1.3a
<clever> moon-child: this is the best source ive found for hdmi encoding, https://github.com/swetland/zynq-sandbox/blob/master/hdl/hdmi_core.sv
<bslsk05> ​github.com: zynq-sandbox/hdmi_core.sv at master · swetland/zynq-sandbox · GitHub
<clever> the only thing missing, is that the hdmi output, can never drive the differential pairs high, only ever low
<clever> the hdmi input, has pull-up resistors on both halves of the diff pair
<clever> and also how audio gets encoded into ch1/ch2
<moon-child> thanks!
<moon-child> (that said it looks like my idea was not so original; e.g. https://research.nccgroup.com/wp-content/uploads/2020/07/hdmi_-_hacking_displays_made_interesting.pdf)
<clever> ctrl i mean
<clever> moon-child: basically, during the active area, each channel does an 8:10 bit encoding, using some scrambling codes to get both ecc, and a very low edge count, for emi reasons
<clever> moon-child: but during the blanking area, its using a different 2:10 bit encoding, that intentionally has a high edge densisity, to allow calibrating the rx end's clock
<clever> (line 90), the hsync/vsync get encoded into that 2bit input on the blue channel, during the blanking periods
<clever> the audio gets encoded into the other 4 bits/pixel-time (line 83/75)
<clever> moon-child: also, if you want to use the hdmi connector/logo or audio on an end product, you need to pay an hdmi license see, but if you just call it DVI, its free, lol
<clever> moon-child: ive also seen a defcon talk, that the pdf you linked reminds me of
<clever> moon-child: basically, they took a thunderbolt->DP adapter, cut it open, and then glued both halves of the case+connectors around a regular thunderbolt cable
<clever> at the far end, was an external pci-e box, with a special card to attack the host via dma
<clever> along with a daisy-chained actual DP adapter, so it could still feed the projector
<moon-child> haha that's cheating
<clever> the trick, is glueing a DP adapter shell over the thunderbolt cable, to fool the victim into thinking the pci-e lanes arent used
<clever> moon-child: oh, the pdf you linked also explains edid, i need to get into that eventually
Arthuria has joined #osdev
<clever> moon-child: another fun fact, VR displays use a special EDID tag to make the window manager exclude the monitor from the desktop layout (on both windows and linux)
<clever> so the display gets its own dedicated framebuffer, that is isolated from the rest of the gui system
<moon-child> hmm, now I'm thinking about dos attack
<moon-child> pretend to be a bunch of monitors, or a really big monitor
<clever> for some drivers, a dos attack is trivial :P
<clever> if you so much as unplug an in-use monitor with the amdgpu drivers on linux, the system will crash hard
<clever> the hotplug code doesnt deal with it very well
<moon-child> yeah, lot of low-hanging fruit
<moon-child> glamor _still_ doesn't clear gpu buffers before it gives them to you
<clever> i once rebooted from windows to linux
<clever> upon logging in, i saw my bloody windows wallpaper on the linux desktop
<clever> it was corrupted and off-center, but it was still intact enough to know where that image came from
<moon-child> fun times...
<clever> i also initially had glamor version problems
<clever> at the time i switched to nixos, it was using the out-of-tree glamor
<clever> which had long been deprecated, and replaced with in-tree glamor
<clever> due to nixos not having updated, it was using an ancient and buggy glamor, that had horrible 2d accel
<clever> scrolling text in xterm took minutes, yet 3d was perfect
<clever> if you disable accel, 2d is great, and 3d doesnt exist
<moon-child> oof
<moon-child> why do they have separate 2d and 3d accel?
<clever> i think the problem is that the 2d accel code had a fatal bug, that made it way worse then no accel at all
<clever> so turning all accel off, made it faster
<moon-child> I mean, why have 2d-specific paths at all?
<clever> i didnt investigate why the 2d path was different
<clever> i just know that 3d apps (minecraft) ran fine, but 2d apps (xterm) ran horribly
* moon-child nods
<clever> 2016-10-25 08:56:36< clever> using the in-tree glamor instead of the deprecated repo fixed them
<clever> according to my irc logs, i mentioned it around 5 years ago
<clever> *digs*
<moon-child> wow, you've been around a while :)
<moon-child> my logs only go back to 2017 I think
<clever> i had some irc logs going back to 2004, but they may be lost now
<clever> found some more chatter about it in #radeon from the old freenode
<clever> 2015-09-02 09:09:46< clever> funfunctor: X is pegged at 100% cpu while xterm is redrawing
<clever> 2015-09-02 09:10:51< dungeon007> 0.6.0 glamor, remove that :)
<clever> moon-child: when the fault was originally discovered
<clever> dont see any ticket explaining how its broken though
<klange> Okay, I think I have achieved dairy production... metaphorically speaking.
Arthuria has quit [Ping timeout: 264 seconds]
<j`ey> wut
<klange> CoW
<klange> Moo.
<j`ey> moo
<j`ey> klange: CoW in what part of the system?
<klange> This should just be covering fork at the moment...
<j`ey> so page table CoW stuff'
<klange> aye
<j`ey> nice, so now you can fork faster!
<klange> something that has been dreadfully missing in ToaruOS :) next up we'll see about file mappings, see if we can't get gcc to take a bit less time to compile 'hello world'
<j`ey> not pushed to github at least yet D:
<klange> my ld.so loads everything immediately, no lazy loads, so it's gotta load in all of cc1, which I think is the main cause of slowness there
<j`ey> my cc1 is 29M, so yeah, that could help
pretty_dumm_guy has joined #osdev
<klange> 26.5 but yeah
<klange> okay so just with cow, it looks like I'm getting a slightl improvement from 0.75s to 0.71s for hello world as done by my build script
<klange> there's a couple of forks there between the shell, kuroko, gcc, cc1, ld...
GeDaMo has joined #osdev
givemeyourpies has quit [Quit: Going offline, see ya! (www.adiirc.com)]
dormito has quit [Quit: WeeChat 3.3]
<geist> noice!
PraiseIdleness has joined #osdev
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
PraiseIdleness has quit [Client Quit]
PraiseIdleness has joined #osdev
xenos1984 has joined #osdev
dennis95 has joined #osdev
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
gog has quit [Quit: byee]
PraiseIdleness has joined #osdev
sdfgsdfg has quit [Quit: ZzzZ]
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
ahalaney has joined #osdev
PraiseIdleness has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
PraiseIdleness has joined #osdev
<klange> oh gdi
<klange> the reason gcc is slow isn't because loading cc1 is slow... it's because loading cc1's exported dynamic symbol table is slow... because I was using a hash table with 10 slots.
<klange> (and it has... 22109 dynamic symbols)
<klange> bumping my hash size to a perfectly reasonable 100 makes gcc run in a much nicer 0.15s instead of 0.71s, and that's without COW forks or file mappings.
<klange> COW looks good, might merge that as-is, think I got all the reference counting taken care of... file mappings need some work
<zid> not 128? :o
<klange> alright, this all checks out on the ol' t410, let's just push it and call it a night, it's late... and I need to get litter and food for the cats from the open-'til-5am general store...
<klange> ah, it is raining... well, the cats have enough litter to last a couple days, and there's spare food...
<zid> family mart can wait, we have hash tables to adjust
<zid> think it's worth making it grow?
[itchyjunk] has joined #osdev
<klange> I don't think it's worth it. I'm not even sure having the hash table at all is necessary.
<klange> I see string lookups and I jump for a hashtable, but this could very well just keep the dynsym table around and scan it. There's even some indexing that's supposed to already be there for that? Some symbol hash section? dunno if I'm keeping those...
<klange> but this hash is terrible and ancient, one of those dumb libs I had from before the OS
<klange> Anyway, this is within a reasonable bound of the time it takes to do similar things in Linux, so I'm happy. https://klange.dev/s/Screenshot%20from%202021-11-30%2022-52-35.png
<zid> 128 is seriously a nicer size though, lets you use & instead of /
<zid> I doubt it matters though
nyah has joined #osdev
srjek has joined #osdev
gog has joined #osdev
<zid> well, washing machine is fucked
<zid> a) full of weird bits of like, nylon thread and making an awful noise
<zid> put the belt back on, drum is sorta seized. Notice it's come off the seal, remount it to the seal, first spin makes it all come apart again
<zid> ..diagnosis, a shitty plastic clip etc has broken which keeps the drum where it should be, drum has sagged down, untensioned the belt and itself from the lip
<zid> and ground against the outside of its enclosure, rubbing bits of nylon off
ElectronApps has quit [Remote host closed the connection]
getynge has joined #osdev
<getynge> Hello world! I'm looking to reverse engineer a windows driver so I can control a piece of hardware from linux and have absolutely no clue as to where or how I would start. What are even the first steps for something like this?
<getynge> This seems like an ok guide: https://posts.specterops.io/methodology-for-static-reverse-engineering-of-windows-kernel-drivers-3115b2efed83, but I don't know if I'm working with a userland driver or kernel driver (I've never even toyed with drivers before so I'm kinda going on the deep end here, but this is functionality nobody has implemented in linux so I really have no choice)
<bslsk05> ​posts.specterops.io: Methodology for Static Reverse Engineering of Windows Kernel Drivers | by Matt Hand | Posts By SpecterOps Team Members
<[itchyjunk]> How do you know someone else hasn't already reverse engineered the thing you're trying to reverse engineer? :x
getynge has left #osdev [Leaving]
getynge has joined #osdev
<getynge> [itchyjunk]: I couldn't find one online or in any of my distros repos, I'm going to keep searching but so far I got nothing.
<zid> Pirate IDA is the first step
<zid> what is it anyway
x88x88x has joined #osdev
<getynge> zid: In this case it's software that manages the relative power consumption between my CPU and GPU on my laptop (Aorus 17g-yc), they just call it "control center"
<getynge> e.g. I can say that I want my GPU to be in "high power" mode but my cpu in "lower power" mode so that the PSU inside the laptop routes extra power to the gpu and less to the cpu, I'm not sure how it does this under the hood
<zid> so presumably the driver exposes the controller via some ioctls
<zid> and the control software does all the logic
<getynge> ah okay, let me look a few things up then (I'm very new to looking into drivers as in this is literally my first attempt)
<zid> got the .sys file handy?
<getynge> I'm not even sure what that would be, I'm on the laptop now, where would I find it?
<zid> C:\windows\system32\drivers?
<getynge> got it, one sec
<zid> or just grab the package from asus's website and see if it's in the zip
<getynge> oh right
<zid> oh gigabyte?
<getynge> yeah
<zid> heh that thing doesn't evne have w7 drivers
<getynge> bah the driver is a self extracting exe, I'll grab the file from my windows partition one second
<zid> assuming you can even figure out what it's called
getynge has quit [Quit: Leaving]
<zid> AMD64 is the most polite ISA because it says "RIP" where you crashed
xenos1984 has quit [Quit: Leaving.]
getynge has joined #osdev
<getynge> yeah I couldn't find it, at least not quickly
<getynge> since it's just a self extracting binary anyway I could just run it in wine and see where it extracts to
<zid> running autoruns in windows might be the easiest
<getynge> got it, I have some things I need to do in linux rn but next time I boot into windows I'll do that
<getynge> thanks zid! I appreciate you taking the time to help
heat has joined #osdev
<Bitweasil> You might find some things to poke at in the ACPI tables too.
<Bitweasil> But that sort of thing on Linux is often really tough.
<zid> this is the.. easy part :)
<zid> Next is the 20 hours of RE
<Bitweasil> Once you find the right stuff to poke it can go faster...
<zid> If you have nice numbers to work with yea
<zid> but for "idk higher power?" it probably will need the frontend REing to figure out what it means by that
<zid> then trace it through the driver to what it means in terms of hw
<Bitweasil> REing hypervisors is nice, just find the VMREAD/VMWRITE spots and work back.
<Bitweasil> So, uh, anyone else read the Blacksmith paper on DDR4 rowhammering? :(
<getynge> Yeah that's the other thing, the UI makes it very unclear what's actually going on when I set my CPU power to "2/4 bars" and my GPU power to "2/2" bars, gotta figure that out too
gorgonical_ has joined #osdev
<getynge> whoops messed up my quotes, oh well
<Bitweasil> Does it actually matter?
<Bitweasil> I try not to run exotica for Linux hardware.
<Bitweasil> If what you're doing can be done in a VM on Windows, let Windows manage the hardware, use Linux to do work. Or just get something straightforward and supported for Linux and sell the Windows laptop.
<gorgonical_> What would be the consequences if I didn't deliver the uart IRQ? As in, the qemu pl011 serial device's IRQ47?
<zid> nobody will get an interrupt to tell them the uart needs reading?
<getynge> Bitweasil: honestly yeah I'll probably just either sell the laptop or something. And if I'm being honest the configuration I need is pretty simple: CPU at max power and gpu at min power while in linux, the opposite in windows
<gorgonical_> I am currently trying to troubleshoot why aforementioned device works for kernel output but userland does not. It's virtualized so the hypervisor controls the IRQ right now
<heat> getynge, are you sure it's not just power mode magic?
<zid> I'll give you £20 for it, sounds like it has a 3080 in it :p
<Bitweasil> ^^ If you've got the UART configured for IRQs, and the driver expects IRQs, it'll never get them so never read the UART.
<heat> i.e cpu governor on perf and gpu on power saving
<Bitweasil> YOu could still poll it.
<zid> I wonder if I could use it as an external screen, I need to replace my monitor asap
<getynge> heat: could very well be, that's part of what I wanted to find out. But given my use case it's probably better to just suffer the manual intervention until I sell the laptop
<zid> Your first mistake was buying anything that says 'gigabyte' on it imo
gorgonical_ has quit [Read error: Connection reset by peer]
gorgonical_ has joined #osdev
<gorgonical_> That was rude, airport wifi
<getynge> my second mistake was buying an intel laptop, I didn't realize how much worse intel is on laptops than amd having used both
<zid> no irq -> nobody bothers to read the uart -> nobody prints it to screen?
<zid> intel's fine
<heat> generally most "control centers" are just a bunch of horseshit
<zid> yea I spent ages looking for a keyboard I could definitely turn the lights off on without external software
<gorgonical_> Because at this point I am completely out of ideas as to why I can push content to /dev/kmsg and it works, but busybox refuses to cooperate. I've checked setserial and the only conclusion I have is that the device expects IRQs
<zid> because I am not dumb
<zid> firmware responds to right-win + F12 to enable 10 key rollover, and right-win + F11 to turn lights off
<gorgonical_> So let's hope injecting irqs for the pl011 uart resolves this and it's just that userland is smarter than me
<heat> except steelseries', I really like steelseries
<heat> (if you forget that it's NOT AVAILABLE FOR FUCKING LINUX)
<getynge> and I mean to be honest I'm just starved for good projects and thought I finally found a good one but alas it wasn't
<zid> I should figure out how I managed to break my temp sensors at some point
<zid> I don't think my cpu is really at -60C
<getynge> idk maybe you have a really good cooler
<heat> getynge: hey it's me your osdev
<zid> getynge: or really bad, cus the dies underneath are 60C, so I have a 120C delta in about 2mm
<Bitweasil> Intel is fine for Linux, just get something with Intel integrated graphics for Linux, that tends to be pretty boring and supported, with the graphical performance of a nice potato.
<Bitweasil> But for desktop stuff, it works.
<Bitweasil> Any of the GPU switching stuff is a pain at best.
<heat> Bitweasil, nvidia and amd also work fine lol
<heat> you don't need to go intel
<zid> amd drivers, hiss
<heat> except for optimus of course, optimus is sadge time
<zid> nvidia had the optimus nonsense though
<zid> snap
<zid> You owe me a new monitor
<heat> how about
<heat> no
<zid> It'll work on someone eventually.
gorgonical_ has quit [Ping timeout: 252 seconds]
kaichiuc1u has joined #osdev
woky_ has joined #osdev
kaichiuchu has quit [Ping timeout: 256 seconds]
woky has quit [Ping timeout: 256 seconds]
x88x88x has quit [Ping timeout: 256 seconds]
air has quit [Ping timeout: 256 seconds]
stux|away has quit [Ping timeout: 256 seconds]
xenos1984 has joined #osdev
srjek has quit [Ping timeout: 264 seconds]
<heat> easily the best part of github actions is not being able to test on your own machine
srjek has joined #osdev
<heat> i love waiting for toolchain builds, i really do
air has joined #osdev
dude12312414 has joined #osdev
<Bitweasil> nVidia and AMD work fine for desktop, I remain unconvinced they're worth it for laptops.
<Bitweasil> They tend to not power manage very well on laptops, in my experience, though admittedly this is fairly old.
<zid> what if I wanna play pokemon on my laptop though
<Bitweasil> If Intel graphics can't emulate a gameboy, you have other problems.
<zid> pokemon is out on switch now
<heat> tbf new iGPUs should be way more powerful than a switch
<heat> although emulation is way harder
<zid> probably, switch is just an nvidia shield
<Bitweasil> So play it on a switch?
<zid> but it's not a super low spec one though
* Bitweasil toggles the switch really really hard to play one bit music.
<zid> Bitweasil: need my post code?
<Bitweasil> Huh?
<zid> for the switch you're buying me
<heat> and the monitor
<Bitweasil> What country?
<zid> switch has its own screen
<zid> UK
<zid> incoming light switch?
<heat> the quality is worse when in portable mode
<zid> it actually helps the fps in some games
<heat> res drops a bunch
<zid> it renders at 720p instead of 1080p and you get 60fps instead of 30
<heat> in the new gta vice city remake the switch renders at like 500p and 600p lol
<heat> horrible fps as well
<zid> That disaster was so funny to watch twitter for
<zid> it's horrifically buggy
<heat> i unironically think it's not that bad from a visual POV
<heat> some areas look totally low effort but it's a neat concept
<zid> they for some reason, remade the engine in unity, badly
<heat> they should've made like a proper HD remake on it
<heat> zid, unreal engine i think
<zid> err yea one of those
<zid> and then shipped the unstripped game engine files
<zid> including radio files for songs they didn't have the licence for, and code comments inside the scripts
<heat> rockstar outsourced it to the people that ported GTA3/VC/SA to android and iOS
<heat> not surprising shit hit the fan :v
[itchyjunk] has quit [Remote host closed the connection]
<heat> although honestly, it's a good improvement from the old games (if you forget the animations of course xd)
<zid> nothing wrong with VC
<heat> then again I also like windows 11 so my splish splash my opinion is trash
<zid> what's supposed to be wrong with it
<zid> only issue the native PC port had was the helicopter controls were wrong
<heat> ugly
<heat> and probably compatibility issues with new windows versions at this point
<zid> >only issue the native PC port had was the helicopter controls were wrong
<heat> helis are horrible in all the 3D universe games and that's a fact
<GeDaMo> If I want to play Vice City, I shall play it on my PS2 :P
<zid> nope
<zid> they're absolutely lovely in specifically bf2
<heat> i mean the GTA 3D universe
<zid> They worked fine on ps2
<heat> GTA3/VC/SA and the PSP ones
<heat> specifically because the mouse is useless
<heat> so you end up controlling it with the fucking keypad
<zid> I told you, they ported the controls wrong for PC
<zid> they're analogue on ps2, not digital
<zid> You have to fucking manually PWM NUM8 on PC it's super wrong
<heat> they should've made like GTA4 but for every old game
<heat> that would've been neat
<Bitweasil> helis are just awful in raelity. :p
dennis95 has quit [Quit: Leaving]
givemeyourpies has joined #osdev
amine has quit [Quit: The Lounge - https://thelounge.chat]
amine has joined #osdev
ravan has joined #osdev
ns12 has quit [Quit: bye]
ns12 has joined #osdev
<bslsk05> ​hubris.oxide.computer: Hubris
<junon> Set theory is the most deceptively difficult thing to program for, omg. My brain is on fire right now.
<junon> I've spent two days writing a comparison function for comparing two ranges.
<junon> Just about finished but I must have rewritten the thing like 4 times
<zid> what does a range represent?
<junon> Biggest setback was not realizing that `[10,10)` is an empty set.
<zid> I thought that was every number bigger than 10
<junon> zid: a set of integers including the possibility of -/+ infinity, with non-infinity bounds supporting open/closed
<zid> sounds like a set not a range then
<junon> Nope, I'm defining a range as `[x,y] -> x <= value <= y`
<junon> it's a range.
<zid> unless you forgot like, 'contiguous'
<junon> The larger class I'm working up to is an interval (at least, that's what I'm calling it), which is more like a set.
<junon> Or more specifically, a set of ranges.
<zid> oh okay the ) bracket and ] bracket are just < vs <=
<zid> I lookied it up
<junon> Or even more specifically, a single positive range and a set of exclusion ranges
<junon> Yea
<nshp> mxshift: neat. I like how they're actually using traits for porting in there
<junon> I had it in my head that `[10,10)` was just `{10}` but it's actually empty because `10 <= x < 10` is not satisfiable if `x` is an integer.
<junon> But the comparison function has nested `switch` statements 4 levels deep
<mxshift> full transparency: I'm an oxide employee and work on Hubris
<junon> mxshift: congrats on the HN front page.
<junon> You have a beautiful website.
<mxshift> thanks!
<nshp> aha, well then, nice work
sprock has quit [Ping timeout: 264 seconds]
PraiseIdleness has quit [Quit: Textual IRC Client: www.textualapp.com]
orthoplex64 has quit [Ping timeout: 264 seconds]
orthoplex64 has joined #osdev
stux|away has joined #osdev
<bslsk05> ​github.com: kernel: Implement basic copy-on-write for fork() · klange/toaruos@18174e4 · GitHub
<j`ey> what's cr0 on x86-64?
<zid> control register 0, you're welcome
<j`ey> v helful as per usual :P
<zid> CR0 — Contains system control flags that control operating mode and states of the processor.
<zid> i.e it's a control reg
<j`ey> ok so this is setting bit 16
<zid> write protect
<j`ey> which is WP
<j`ey> "When set, the CPU can't write to read-only pages when privilege level is 0", so looks intentional for CoW
<zid> This flag facilitates implementation of the copy-on-
<zid> write method of creating a new process (forking) used by operating systems such as UNIX
<zid> Indeed it is
mahmutov has joined #osdev
srjek has quit [Ping timeout: 252 seconds]
nur has quit [Ping timeout: 252 seconds]
andydude has joined #osdev
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
tenshi has quit [Quit: WeeChat 3.3]
andydude has quit [Quit: andydude]
andydude has joined #osdev
Oli has joined #osdev
maksy_ has joined #osdev
<geist> yah i forget precisely when that flag was added, maybe 486? seems like an early fix to try to be a bit more secure
<geist> in general you pretty much should always set it on cpu startup and leave it there
<zid> seems like a nice way to catch boogs
radens has quit [Quit: Connection closed for inactivity]
<maksy_> any ideas why qemu crashes when I write to a certain index of an array declared with extern?
<zid> qemu itself? a bug
<maksy_> If I change the condition in the if clause to "i < 320 * 36" it works
<maksy_> oh sorry I mean qemu reboots the emulated machine
<zid> are you in protected mode then?
<zid> You can tell it not to reboot btw, and to print information about faults
<maksy_> yea the cpu is in protected mode
<zid> -d int -no-shutdown -no-reboot
<zid> should give you more of an idea as to what exploded
waltster has joined #osdev
waltster has quit [Client Quit]
waltster has joined #osdev
<waltster> Is this channel still active?
<zid> The other 227 of us are bots
Oli has quit [Ping timeout: 256 seconds]
sdfgsdfg has joined #osdev
waltster has quit [Remote host closed the connection]
<maksy_> doesn't say much to me
<zid> check_exception old: 0xffffffff new 0xd
<zid> 1: v=0d e=0008 i=0 cpl=0 IP=0008:00001048 pc=00001048 SP=0010:0008ffd0 env->regs[R_EAX]=00000000
Oli has joined #osdev
<zid> gpf using cs=8 at 0x1048
<zid> with regs below, so you can see what the regs had and what the faulting instruction was
<junon> walster: no, you're the only one in here
<junon> we're just part of a botnet, promise :D
<zid> he already quit
GeDaMo has quit [Remote host closed the connection]
<maksy_> something is wrong with my isr handler. When I disable interrupts it stops throwing an exception
<zid> ah so it's just that the copy is longer :)
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<zid> The second fault is the fault because it failed to deliver the GPF
<zid> the v=8 e=0 one
<zid> invalid IDT is most likely, you do have one loaded though
waltster has joined #osdev
<waltster> Ah, yes
<zid> You missed a riveting discussion about #GP
<Oli> May I ask: What does #GP stands for in this context?
<Oli> Hello, and good day!
<zid> general protection fault
<junon> I assume general protection?
<zid> #PF is page fault, etc
<waltster> Oli, a General Protection fault
<Oli> Thank you for answering my inquiry about, zid, junon, and waltster!
<junon> You're welcome
<junon> :D
<zid> ..that was odd
<waltster> I second @zid
<zid> @zid is also weird, this is not twitter
<junon> yes
<zid> Did you change anything? Did you set the PIC up?
<maksy_> do you pinpoint anything obviously wrong?
<zid> you said it was working before?
<zid> git diff?
<zid> I mean, there isn't any code here btw
<zid> I'd dump descriptor 0xD
<zid> your GDT is misaligned btw
<zid> so you probably wanna use an alignment directive where you definie it
<zid> I don't remember if it gives a shit for the GDT, I think it cares for the table
gxt has quit [Ping timeout: 276 seconds]
gxt has joined #osdev
<sortie> The osdev cult “Your GDT is misaligned”
<zid> right right
<zid> The
<zid> base address of the GDT should be aligned on an eight-byte boundary to yield the best processor performance
<zid> It's *that* line, 'for performance'
<sortie> 0x0 is the truest most aligned address where one stores the data that must be read with the very best performance
<maksy_> one more file
<maksy_> so "align 8" at the end of gdt_descriptor?
<zid> before it, but apparently it doesn't matter
<zid> didn't need to paste, a paste of your IDT would be nice
<zid> even if it's just x /128bx 0x4420 in qemu
<zid> 4220*
<maksy_> okay I'll try to extract it from qemu
<zid> x /128bx 0x4220
<zid> just type that into the monitor, screenshot it even if it's in a VM and it's awkward
<zid> to copy paste
<zid> should take about 10 seconds
<geist> aww irccloud going down for 4 h
<geist> see ya on the other side
<zid> time to buy a real irc client geist
<kazinsal> oh what? I didn't see any notices about that
<geist> just got one, some sort of popup
<kazinsal> huh
<geist> they said they're doing some maintenance
<geist2_> zid: i do have one
<zid> no need to see us on the other side then really :P
<geist2_> I just dont shell into this one much
geist2_ is now known as geist2
<zid> You're already perving on us
<geist2> mwahaha
waltster has quit [Quit: Leaving...]
<zid> oh the idtr is a weird thing isn't it
<zid> the limit is encoded in the bottom half of the address or something?
<zid> oh no it's 48 bit I am dumb and blind
<zid> so technically we want.. x /1dx 0x4222
<zid> then x /128bx that
<zid> does d not do what I think it does in qemu
<maksy_> oops I started qemu without -d int
<zid> 08 00 00 8e
<zid> somehow turning into 0x8
<klange> j`ey: I'm turning on WP so that kernel access to non-writable memory causes a fault, mostly because I'm a naughty boy without a copy_to_user
<maksy_> oh it doesn't matter whether -d int is given. The result is the same
<j`ey> klange: I was just a bit surprised to see the raw inline asm in there
<zid> yea that just turns on/off interrupt tracing
<zid> I can't figure out what's going on in your image though
<zid> printing 0x4222 as a dword gives 8, then printing it as bytes gives 08 00 00 8e?
<zid> and I assume given how you have apparently copied all your shit really low into memory, 0x8e000008 is not the right address for your IDT entries?
pg12 has quit [Ping timeout: 240 seconds]
pg12 has joined #osdev
<zid> This reads as 'limit 0x128c, base address 0x8e000008' anyway, unless I am grossy misunderstanding what qemu is trying to tell me
<geist> yah i think the reason the idtr (and gdtr, ldtr) are the 16/32 thing is they started off as 16/16 in 286 protected mode
<geist> then they extended the pointer part
<geist> i think
<geist> if it was 16/16 in 286 mode it must have been against a segment, probably ds:
<zid> I think qemu might be doing this actuall
<zid> I just dumped my own IDT from my code.. 0x8e000008
mahmutov has quit [Ping timeout: 252 seconds]
<maksy_> yea it prints 08 00 00 8e
<zid> at some point after the lidt it's.. writing over it maybe?
<maksy_> it's possible. Maybe I'll add an array declared with extern to the tutorial code I've been following and see if it behaves the same
<zid> I'd just put a jmp -2 before the lidt
<zid> and dump it there :p
<klange> Just want to say, at this level, I strongly doubt it's a bug in qemu. qemu has plenty of bugs, but they tend to be in disused device emulations, like that ps/2 buffer bug that took several years to fix and by cosmic coincidence was fixed the day I decided to sit down and write a full bug report for it
<zid> I mean, neither my nor his IDT *should* contain that address
<zid> and it gives the exact same one
<zid> unless it's just some weird cpu feature I've never heard of, that it trashes your IDT sometimes..
srjek has joined #osdev
<maksy_> so before this: __asm__ __volatile__("lidt (%0)" : : "r" (&idt_reg));
<maksy_> add this __asm__ __volatile__("jmp -2");
andydude has quit [Quit: andydude]
<zid> I'd do erm
<zid> "mov eax, %0; jmp -2; lidt (%0)"
<zid> qemu should have with the address of it in eax then
<zid> hang*
<zid> we know it's probably 0x4220 though
<zid> and your compiler probably knows too if you tell it to make a symbol map
dormito has joined #osdev
<zid> someone else test on their qemu
<zid> IDTR not being like GDT and pointing to the IVT is an option I suppose
<zid> then the 08 could just be cs=08 which we both use
heat has quit [Read error: Connection reset by peer]
heat has joined #osdev
<maksy_> I don't know how to write that in GCC inline assembly
<zid> like I did it doesn't work?
<zid> oh wait it probably doesn't like the -2 eh
<zid> the fuck is the AT&T for that I wonder
<zid> other way for AT&T tooo right, ($0), eax
<zid> beep: jmp $beep? Idk AT&T
sdfgsdfg has quit [Quit: ZzzZ]
<zid> movl maybe too, slowly remembering AT&T..
<heat> what's jmp -2 for?
ahalaney has quit [Remote host closed the connection]
<zid> infinite poop
<Bitweasil> ebfe?
<zid> \n\t.byte 0x stuff?
<Bitweasil> (no idea on the jmp -2, that should be an infinite loop?)
<maksy_> it's getting really late gotta leave this for tomorrow
<heat> there might not be an easy way to do an infinite loop without a label in GAS
<zid> that's why I suggested a label
<heat> Ahhh!
<heat> jmp .
<heat> that's it
<heat> . is the gas equivalent of $
<zid> ahh
<zid> forgot about it being, you know, an assembler
<zid> and there would be a . or $
sham1 has quit [Ping timeout: 260 seconds]
waltster has joined #osdev
<waltster> Hello all, does anyone know where to find the manual for Intel processors? I am specifically looking for the E7500
<heat> waltster, for the actual CPU it's the good old intel architecture manuals
<heat> for the chipset, well, search for it, it must be somewhere
<zid> They don't give cpu manuals, the best you can get is small releases for the generation
<waltster> heat, thank you for that. i did not know that they do not have processor-specific manuals.
<heat> don't quote me on this but I believe it's kind of incremental
<mxshift> oh, they exist. you're just not allowed to see them
<zid> The errata is the best place to look :P
<zid> for differences wrt the ISA
<heat> where they have a bunch of microarch specific data on the manual
<heat> mxshift, hm?
<zid> intel engineers
<zid> not us plebs
<mxshift> Intel has in-depth manuals for each CPU. Redacted versions are available under NDA.
<heat> how in-depth?
<mxshift> I've never had enough time with a red-cover version to find out
<heat> i honestly don't see the reason for their existance
<zid> hmm?
<waltster> i am interested in that as well but for now i am just trying to get away from using wiki articles and acquainting myself with the manuals
<heat> you've got all the information you need on each CPU in the standard manuals
<zid> The fact the store buffer is x and cache lines are y blah blah needs to be written down somewhere
<zid> no you don't heat
<zid> you get the ISA information
<zid> You get 0 information about any actual CPUs
<mxshift> heat: not when you are trying to write firmware
<heat> oh no! anyway
<heat> mxshift, but that's on the chipset docs
<mxshift> no, no it isn't
<heat> how is it not?
<waltster> i recently learned that the raspberry pi firmware was closed source and was pretty surprised. i had always considered it to be a pretty open platform
<heat> the only difference between writing kernel code and firmware code is that you need to directly interact with the chipset, and that's all documented publicly
<mxshift> there is a large number of details on how to initialize the SoC and x86 cores that are not in public docs
<heat> mxshift, you mean FSP details?
<mxshift> nope.
<zid> How to train your CPU die.
<zid> I wouldn't wanna program all the shit my bios tunes into my CPU tbh
sham1 has joined #osdev
<zid> all the power turbo tau times and crap
<mxshift> Intel has BIOS writer's guide docs that describe a whole bunch of things your firmware needs to do to get the system up and running
sprock has joined #osdev
brenden has joined #osdev
<heat> well that seems pretty counter intuitive to me
<heat> considering that it's all open source
<zid> what's all open source?
<waltster> heat, what is counter intuitive?
<heat> having closed down BWG docs when the code that does all those things is open-source
<heat> if you look at tianocore and coreboot you can probably recreate them pretty reasonably
<zid> no it isn't? That's like saying the nvidia drivers are open source because neuvou can do some things on some cards
<zid> neouvou
<Bitweasil> waltster, the Pi is a hideous mess. Careful, you'll summon him to rant...
<heat> nouveau
<Bitweasil> Initial bringup and RAM training is Intel blobs, good luck getting details on those.
<heat> zid, what you get as a BIOS is literally tianocore with stuff on top
<heat> Bitweasil: right, which I wouldn't expect to be documented in a BWG anyway
srjek|home has joined #osdev
brenden has quit [Client Quit]
srjek has quit [Ping timeout: 264 seconds]
<heat> if you know how your particular mobo/chipset works there's nothing stopping you from flashing your own fully open-source firmware (ok, maybe some security mechanisms)
<nshp> heat: a bunch of actual early bringup stuff isn't in tianocore/edk2, it's in chipset-specific packages provided to vendors
<mxshift> heat: kinda, sorta. FSP is a precompiled binary. PEI and SEC phase of UEFI are blobs.
<nshp> at least a few of them have leaked (source), but yeah, they're not supposed to be open
<heat> in fact, one of the GSoC students ported edk2 to a laptop last summer
sham1 has quit [Quit: ZNC 1.8.2 - https://znc.in]
<mxshift> I mean, i'm only sharing my experience as someone who has designed Intel and AMD based computers and written firmware for them for 15 years
<mxshift> no one who works on coreboot would tell you that its easy to replicate what AMI does or figure out what FSP does
<heat> yes and that's not the point
srjek has joined #osdev
<heat> I don't care about figuring out what the FSP does
<zid> okay? but that isn't really what was being discussed
srjek|home has quit [Ping timeout: 264 seconds]
<heat> mxshift, what part of PEI and SEC are blobs?
<mxshift> almost all of it
sham1 has joined #osdev
<Bitweasil> mxshift, 15 years doing firmware, so... now you use a Pi for internet access and hate computers too? :D
<mxshift> Bitweasil: lol. more or less
<Bitweasil> :) It's a safe bet.
<Bitweasil> But, yes, the docs for early Intel bringup are pretty much, "You put this chunk of data here and jump to it."
<Bitweasil> After measuring it and putting the hash in the TPM, ideally.
<nshp> heat: specifically, if you pull apart a UEFI image for an intel board, you'll find e.g. a `SkylakePkg` or a `HaswellPkg` which is not present in the open source edk2. That contains all sorts of hardware initialization stuff
<nshp> like for bringing up the nvidia/intel GPU switching thing, that's all tucked away in blob land
<zid> I like that VIA bios that forgot to lock the chip out of SEC mode at boot so you could run all sorts of undefined system management instructions
<heat> ok so I'm taking a look at the build config for the new platform (https://github.com/tianocore/edk2-platforms/blob/3e73df15730667c46a1e449cca872e7f8861007c/Platform/Intel/KabylakeOpenBoardPkg/AspireVn7Dash572G/build_config.cfg) and I can only see KabylakeOpenBoardBinPkg (which is just a VBT) and the FSP
<bslsk05> ​github.com: edk2-platforms/build_config.cfg at 3e73df15730667c46a1e449cca872e7f8861007c · tianocore/edk2-platforms · GitHub
<heat> also KabylakeSiliconBinPkg for microcode
<mxshift> that's more than microcode
<zid> I mean, there's also the entire damn ME
<zid> which is megabiggles
<nshp> I think system76 is still battling with figuring out how to turn off ME without breaking things
<zid> I like my ME :(
<zid> I paid for my motherboard, I want to use it
<nshp> it's nice on servers
<nshp> it's a bit strange that it's on and can't be turned off on my laptop
<zid> it still contains all the SMI/SMM code for thermal events and stuff doesn't it?
<mxshift> ME does a bunch of early system startup. I'd like to prune it of runtime services though.
hbag has quit [Quit: Ping timeout (120 seconds)]
<Bitweasil> I thought Purism figured out ME nerfing.
<Bitweasil> Remove most of the blobs, boot, then set the HAP bit.
waltster has quit [Remote host closed the connection]
<Bitweasil> ME is independent of SMM.
<nshp> system76 was able to nerf it for a while, but iirc in newer chips, nerfing it started breaking other things
<Bitweasil> SMM is an x86 mode, ME is an embedded processor.
<Bitweasil> Yeah, but Purism figured out a lot of it.
<bslsk05> ​puri.sm: Deep dive into Intel Management Engine disablement – Purism
<Bitweasil> Give or take that.
<mxshift> you can't really _disable_ ME. You can remove a bunch of functionality.
dude12312414 has joined #osdev
<Bitweasil> Not true. The HAP bit actually shuts the thing down after boot, you can't reach it on any of the interfaces.
<Bitweasil> It's still used for boot, but there's a designed process to shut it down.
<mxshift> no one has proven that it isn't doing things in that state. Just that you can't talk to it.
<Bitweasil> Ok.
<Bitweasil> Yes, it could still be doing things. But if it has no ability to talk outside the system, and you've controlled what's in it, and shut it down with the NSA-requested shutdown bit, it's *probably* lower risk than the rest of the stuff you're running.
<Bitweasil> HAP is NSA's (IMO, quite idiotic) proposal to have classified and unclass VMs running on the same physical machine, at the same time, which required an awful lot of work to eliminate the weird channels. That's what the STM (SMM Transfer Monitor) and such came out of.
<Bitweasil> (the SMM hypervisor, "Dual Monitor Mode")
* Bitweasil wanders off, later!
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]