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
<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'?
<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
<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
<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
<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?
<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.
<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
<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
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
<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
<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]