16:46karolherbst: ahhh.... is nv30/nv40 really that broken? :(
17:04karolherbst: the heck..
17:04karolherbst: gnome runs, but glxgears doesn't
17:14ajax: maybe you broke GL_QUADS
17:14karolherbst: I have no idea
17:15karolherbst: the GPU throws DMA_VTX_PROTECTION errors
17:16karolherbst: okay.. so VTX is indeed vertex
17:17karolherbst: let's see if this is some weird mesa regression
17:18karolherbst: all I want is to finish fixing multithreading :(
17:23karolherbst: sometimes I think my old GPUs are falling apart as well :)
17:23karolherbst: maybe I try to rework my patches to leave nv30 alone, so I don't risk breaking it
17:49ajax: nv40 definitely had some fabrication issues
17:54mynacol: It seems karolherbst will merge the multithreading fixes right around the time I will get a new AMD graphics card 😆
17:55mynacol: But I was able to use the MR for half a year already, so it still helped me
17:58karolherbst: still need to look at the regressions, but I think I should be able to fix nv50/nvc0 without making nv30 using per context push buffers... probably better than waiting until I get the nerves to fix nv30 :D
17:59karolherbst: apparently there is a regression.. oh well
18:19johns: karolherbst, hell__: full dmesg now at https://paste.debian.net/1248068/
18:19johns: there is mention of shadowed rom there
18:20karolherbst: could you dump the rom?
18:22johns: I'm trying that now with nvbios but seem to have lost the strap_peek
18:22karolherbst: nah.. don't use the envytools thing, just cat the /rom file of the pci sysfs node
18:22karolherbst: or well...
18:22johns: that doesn't work
18:22johns: that gives me the invalid sig error
18:22karolherbst: it can't
18:22karolherbst: because cat doesn't care
18:22karolherbst: just the raw file
18:23johns: cat gives a different error but the log at that moment says invalid sig
18:23karolherbst: what log
18:23karolherbst: from nouveau
18:23johns: cat: '/sys/devices/pci0000:00/0000:00:02.0/0000:01:00.0/rom': Input/output error
18:23karolherbst: the heck...
18:24johns: [ 744.059211] pci 0000:01:00.0: Invalid PCI ROM data signature: expecting 0x52494350, got 0xe938aa55
18:24karolherbst: ahhhh..... :(
18:24karolherbst: why doesn't it just let us dump the rom
18:24hell__: is there no way to disable the thing that shadows?
18:24johns: nvagetbios gave me something, which I can try running through nvbios
18:24karolherbst: I have no idea
18:24karolherbst: johns: I am sure it's all 0 though
18:24karolherbst: or does it actually contain something?
18:24johns: it does look like junk yes, and strings shows nothing in it
18:25johns: no strings I mean
18:25karolherbst: yeah.. so nouveau tried to load via prom and it got a 0 checksum
18:26karolherbst: why is nouveau involved "[3793481.136992] nouveau 0000:01:00.0: Invalid PCI ROM header signature: expecting 0xaa55, got 0xffff"
18:26karolherbst: maybe it just says nouveau because that's the loaded driver
18:26karolherbst: let's see...
18:27karolherbst: yeah so I can read that file when the GPU is powered on
18:28johns: karolherbst: as expected nvbios says couldn't read ("BIOS size 0x100000 [orig: 0x100000], 0 valid parts:")
18:28karolherbst: huh, but your error is weird though
18:29karolherbst: because that indicates that the ROM is all trash regardless
18:29karolherbst: hell__: I guess the only way is to dump via /dev/mem ...
18:29hell__: I think the error appears as if coming from nouveau because nouveau can call the `pci_map_rom` function
18:30karolherbst: it has nothing to do with nouveau
18:30johns: karolherbst: https://paste.debian.net/1248070/ is the full output from nvbios
18:31hell__: I'm still suspecting that whatever is in the C-segment is trash
18:32karolherbst: now how to enable access to /dev/mem
18:32hell__: what do you want to access?
18:32karolherbst: the c segment
18:32hell__: probably boot with iomem=relaxed I guess?
18:32karolherbst: mhhh.. maybe?
18:32karolherbst: johns: does "dd if=/dev/mem bs=4096 skip=192 count=32 | hexdump" print anything useful?
18:33karolherbst: but yeah.. mayby iomem was the thing to flip it..
18:34hell__: with iomem=relaxed I can read the c-segment contents
18:34karolherbst: ahh okay
18:34hell__: and on my system I see the VBIOS contents fine
18:34karolherbst: okay, cool
18:34karolherbst: johns: so.. mind booting with "iomem=relaxed" and use that dd command to dump it?
18:35hell__: I suspect that the C-segment on the failing system will have crap, probably something related to native GFX init on the BMC
18:35johns: karolherbst: as booted now, that command prints stuff that is not all 0s
18:35hell__: I used: sudo dd if=/dev/mem of=cseg.rom bs=64k count=2 skip=12
18:35karolherbst: mind pushing it into a file and upload it?
18:35karolherbst: hell__: it's annoying you can't use hex numbers :D
18:35karolherbst: guess with $(( )) you could
18:36hell__: it's not too bad if you use large blocks
18:36hell__: 0xc = 12
18:36karolherbst: hence me using 4k
18:36karolherbst: oh well
18:37hell__: I just googled "0x10000 to decimal", got 65536, I knew it's 2^16 so 64 KiB, and the rest was easy
18:37karolherbst: normally I use iomem=relaxed to be able to read GPU registers while nvidia is loaded
18:37johns: karolherbst: sure, one sec. it is a 128k file that file identifies as a BIOS, I guess that's promising
18:37karolherbst: yeah well... we told dd to dump 128k of data :P
18:38johns: small victories
18:38karolherbst: still annoying we can't just use /rom
18:38hell__: it identifies itself as a BIOS because the signature is fine (0x55 0xaa at the beginning)
18:38karolherbst: yeah.. the PCIR header is not found
18:39karolherbst: or well.. it needs a sig of 0x52494350
18:39hell__: wait... I think I know what it might be
18:40hell__: so, the hardcoded coreboot settings for this board make it initialize the Aspeed BMC using "native" graphics init (coreboot initializes graphics without a VBIOS)
18:42hell__: and I'm pretty sure SeaBIOS is providing its own option ROM, SeaVGABIOS, which implements legacy VGA BIOS compatibility for coreboot-initialized GPUs
18:42karolherbst: the hell is this file...
18:42hell__:hasn't received any files
18:42johns: PMed it
18:42karolherbst: "gcc: (Debian 6.1.1-11) 6.1.1 20160802 binutils: (GNU Binutils for Debian) 2.26.1" :3
18:42karolherbst: "Start SeaVGABIOS (version %s)"
18:43karolherbst: hell__: might be you are right and this is simply the "bios" seabios provides
18:43hell__: lol, so my hunch is completely right
18:43karolherbst: "SeaBIOS VBE(C) 2011" :3
18:43hell__: yes, that's SeaBIOS' option ROM
18:44karolherbst: at least one mystery solved
18:44hell__: so now to figure out why coreboot/SeaBIOS aren't aware of the Nvidia GPU
18:44karolherbst: I am actually wondering if there is a way for us to figure out where the ROM actually lives
18:45hell__: it should be possible to map the ROM using the PCI config register
18:45hell__: but we need to find a place to map it to
18:46karolherbst: yeah.. no clue about any of those details though :P
18:46karolherbst: maybe just map it into the c space? dunno :D
18:47hell__: no, that won't work
18:47hell__: it needs to be mapped to an address range that is decoded by the PCI bridge
18:47hell__: here's my lspci -v: https://dpaste.org/m4Xva/raw
18:48hell__: so 00:01.0 is the PCI bridge for the dGPU
18:48karolherbst: I bet "00:01.0" is the bridghe
18:49hell__: if unsure, I love `lspci -nntv`: https://dpaste.org/uX6ea/raw
18:49hell__: the PCI bridge can decode I/O, memory and prefetchable memory
18:50hell__: I remember looking at your Optimus dmesg and seeing that your VBIOS was mapped into the memory range (non-prefetchable)
18:51hell__: you have: Memory behind bridge: b3000000-b40fffff [size=17M]
18:51hell__: and then: Expansion ROM at b4000000 [disabled] [size=512K]
18:52hell__: the rest of the memory range decoded by the PCI bridge goes to something else, probably a set of registers: Memory at b3000000 (32-bit, non-prefetchable) [size=16M]
18:53hell__: on my system, I have: Memory behind bridge: de000000-df0fffff [size=17M] [32-bit]
18:53hell__: and then: Memory at de000000 (32-bit, non-prefetchable) [size=16M]
18:53hell__: but Linux is using the C-segment: Expansion ROM at 000c0000 [virtual] [disabled] [size=128K]
18:56hell__: lemme try to map the thing to 0xdf000000
18:56karolherbst: I am currently wondering if there is something we could do from the nouveau side here to workaround "broken firmware"
18:57hell__: remove the need for the c-segment quirk?
18:57hell__: I'm not sure why Linux thinks the boot GPU is the Nvidia card
18:58karolherbst: because there is no primary one
18:58karolherbst: picks the first one then
18:58hell__: the Aspeed BMC should've been set up as the primary one
18:58ajax: if there's more than one card the "boot vga" is whichever device had legacy vga decode enabled when the kernel took over
18:58karolherbst: ajax: I thought we check which device the framebuffer belongs to
18:59ajax: and you do that on bios how?
18:59karolherbst: no clue :)
18:59hell__: johns: did you manage to get the coreboot log?
18:59hell__: I really want to know if coreboot/SeaBIOS detect the Nvidia card
18:59ajax: i'm not 100% sure of what i just said but it's what i remember /dev/vga_arbiter doing when we invented it
19:00johns: hell__: working on that now..
19:00karolherbst: anyway.. in nouveau we could probably just map the actual device ROM if retrieving it via the kernel API fails
19:01hell__: hmmmmm, modify the c-segment quirk so that it doesn't try to use the C-segment on Nvidia cards if the C-segment data isn't valid
19:01hell__: also, I think I managed to read the VBIOS from the PCI ROM
19:01karolherbst: I guess if it's not a valid PCIR thing you can just bail
19:02hell__: eh, no, a bunch of F's
19:03hell__: wait a sec
19:03hell__: I forgot to enable the BAR
19:05hell__: hm, it doesn't seem to like it
19:05karolherbst: at this point probably easier to let johns patch linux and try that
19:07hell__: if rebuilding/reflashing coreboot is an option, it's probably easier to configure coreboot so that it doesn't try to initialize the Aspeed BMC
19:07johns: hell__: I didn't do this coreboot flash myself; it looks like maybe it wasn't built with the cbmem buffer enabled? sudo cbmem -C gives me "no coverage found" :/
19:07hell__: johns: oh wait
19:08hell__: it's lowercase: -c
19:08johns: that's better
19:08hell__: I don't really use cbmem to get coreboot logs, I usually have serial ports or something else
19:10hell__: (you can only use cbmem if you boot to OS, and I often need to get logs out of a non-booting system, so I need something else)
19:12johns: pastebins are all rejecting the log file as spam, one sec..
19:13hell__: you can try paste.flashrom.org
19:13johns: hell__: https://bye.wjsullivan.net/nextcloud/index.php/s/4smY4TrLgCB55bT is the log
19:14hell__: that works too
19:14hell__: > PCI: 01:00.0 [10de/11b9] enabled
19:14hell__: ok, coreboot sees the Nvidia GPU
19:15hell__: > PCI: 01:00.0 resource base 0 size 80000 align 19 gran 19 limit ffffffff flags 2200 index 30
19:17hell__: so that's the resource for PCI_ROM_ADDRESS
19:21hell__: hmmmm, so coreboot seems to be using the Nvidia GPU as primary video
19:24hell__: johns: could you please provide a `lspci -v` log as root and a `lspci -nntv` log, please?
19:27johns: hell__: https://paste.debian.net/1248077/ sudo lspci -v
19:27hell__: huh, the BMC is nowhere to be found
19:27johns: and https://paste.debian.net/1248078/
19:28hell__: without the Nvidia GPU, does the onboard VGA connector output any video?
19:29johns: hell__: I believe no, but I can verify..
19:33johns: confirmed no output
19:44hell__: johns: I have no idea why SeaBIOS doesn't try to run the Nvidia option ROM...
19:44hell__: but if I recall correctly, you got video on a different Nvidia GPU
19:46johns: hell__: yes, I have another nvidia card that does work
19:46hell__: could you please get me a coreboot log with that other card?
19:53johns: okay well this is interesting :/ even the working old card did not provide video in the slot I was trying for the new card. it only works in the original slot. unfortunately, the new card does not physically fit in the original slot
19:53johns: getting log from the working boot, guess I should've still grabbed the log from the nonworking one too
19:56johns: hell__: coreboot log with working video https://bye.wjsullivan.net/nextcloud/index.php/s/tGAtG46MCyFNHq7
19:57hell__: johns: oh, the different slot probably matters
20:18karolherbst: uhm... yeah... sadly it does :O
20:18karolherbst: I have have nv30 era GPUs which only work in the non PEGP slot, because $firmware
20:18karolherbst: but could be that coreboot/seabios only function correctly if the GPU is inside the "main" port?
20:26johns: that would be a substantial bummer given the physical layout of things
20:28karolherbst: johns: the slot where the GPU doens't fit is the "upper" one? I guess the case is in the way or something then?
20:29johns: karolherbst: yeah, the case, and also some usb power pins on the mobo. I'm going to give it another go to be sure..
20:30karolherbst: hell__: I am wondering though _why_ it should matter :/
20:31karolherbst: or is BIOS weird and you have to literally use the correct slot?
20:31karolherbst: it's odd though
20:32hell__: karolherbst: it doesn't make much sense, haven't looked at the logs in detail yet
20:32hell__: the ports aren't that different, it's two different PCI bridges coming out of the same chip
20:32karolherbst: I mean.. I know I have those nv3x GPUs, which don't work on the PEGP slot..., but the uefi system also has to boot with CSM enabled
20:33johns: I don't suppose it would help the situation to boot with both cards plugged in
20:33karolherbst: never checked what's actually wrong there, but something $firmware something
20:33karolherbst: try it
20:38johns: ah sadly they won't fit together
20:42hell__: hmmmmmmmmmm, the one difference I see is that ASPM L0s is enabled for the non-working port
20:42karolherbst: yeah well...
20:43hell__: could be because of the installed GPU
20:43karolherbst: I mean ultimately the bug is, there is simply the wrong ROM at c00000
20:43hell__: idk if 8400 GS supports ASPM
20:43karolherbst: why would it even matter?
20:44hell__: I've seen ASPM issues on coreboot do all sorts of funky things
20:44karolherbst: the GPU does work alright, afaik, linux/nouveau are simply getting the wrong ROM
20:44hell__: and the thing is, on the second log SeaBIOS actually finds the VBIOS of the Nvidia card and runs it
20:44karolherbst: even if the firmware fails to init the GPU, nouveau would do that instead
20:45hell__: and SeaBIOS doesn't put SeaVGABIOS in the C-segment if it successfully initialized video running a VBIOS on a card
20:46karolherbst: okay, sure.. but is this even _valid_ from a BIOS perspective
20:46karolherbst: I mean.. putting the seavgabios there
20:47hell__: SeaVGABIOS is meant to provide legacy BIOS functionality (e.g. INT 10h) when there isn't an actual VBIOS
20:48hell__: e.g. when using an emulated video adapter in a VM, or when coreboot has initialized the GPU without using a VBIOS (it's possible on Intel iGPUs and some BMCs)
20:48karolherbst: yeah sure, but we are on bare metal and we do have a GPU
20:49hell__: well, SeaBIOS doesn't seem to think so when the GPU is on a particular PCIe slot
20:49hell__: which I agree is nuts
20:49karolherbst: seems like the "main" slot doesn't work
20:49hell__: coreboot sees the GPU
20:50johns: this is the coreboot log booting with the old card in the same slot I've been trying the new card in: https://bye.wjsullivan.net/nextcloud/index.php/s/HeMS6FPT4LSsC8J
20:51hell__: ok, ASPM is not the issue...
20:51johns: oh hold on, that's giving me video now
20:52johns: after X starts
20:52karolherbst: johns: I am sure nouveau reads the VBIOS from PROM
20:52hell__: and SeaBIOS was able to run the VBIOS
20:52karolherbst: no it wasn't
20:52hell__: > Running option rom at ce80:0003
20:52hell__: on the latest log
20:53karolherbst: you get also that stuff in the non working log
20:53karolherbst: "Running option rom at c000:0003"
20:53hell__: that's the C-segment
20:53karolherbst: ohh.. right
20:53karolherbst: it's running both actually
20:54hell__: would be interesting to see what `sudo lspci -v` looks like with the 8400 GS
20:56karolherbst: johns: mind uploading the dmesg of the old GPU?
20:57johns: hell__: that's https://paste.debian.net/1248087/
20:59karolherbst: would be interesting to see if the seavgabios is also to be found in 000c0000 here :D
21:00karolherbst: which wouldn't matter if nouveau uses PROM
21:00hell__: hmmm, I am downloading a few GTX670 VBIOSes from techpowerup
21:00hell__: and I see they start with "NVGI"
21:00karolherbst: that's nvidias wrapper
21:01karolherbst: the actual VBIOS starts some bytes later
21:01karolherbst: 0x100 or 0x200 or something
21:01hell__: yes, 0x400 in the two I've checked
21:01johns: getting the dmesg, it's flooded with DRM-master messages after boot
21:01johns: oh right because I'm probably still booting with nouveau debug on
21:02karolherbst: please leave the bios debug thing though
21:02karolherbst: I am actually curious where nouveau loads the BIOS from
21:03karolherbst: johns: a workaround which you could use would be to dump the vbios on a different machine and tell nouveau to load the vbios from storage
21:03karolherbst: which is painful if you swap cards, but...
21:04hell__: I wonder why PROM doesn't work
21:05karolherbst: because it's not there for _whatever_ reasons
21:05hell__: does PROM access work if the VBIOS hasn't run at all?
21:05karolherbst: no idea what the GPU is doing, PROM are just GPU registers containing the VBIOS
21:05karolherbst: maybe it's shared storage with the PCI ROM, maybe it's something else
21:06karolherbst: but PROM is simply MMIO
21:06karolherbst: it's on bar... 3?
21:06hell__:tries to google "nouveau" "PROM", gets dresses instead
21:07karolherbst: ahh no, it's bar0
21:07karolherbst: hell__: bar0 + 0x300000
21:08karolherbst: that's where prom is
21:08hell__: why is there some indirection to access PCI config space registers?
21:08hell__: looking at nvkm_pci_rom_shadow ---> nvkm_pci_rd32
21:09karolherbst: no clue
21:09johns: https://bye.wjsullivan.net/nextcloud/index.php/s/RWnwAPBe6X6C4CZ is the dmesg with the old card (8400 GS)
21:09karolherbst: ahh, it's actually using PRAMIN
21:10karolherbst: PRAMIN is VBIOS located in VRAM :)
21:10karolherbst: it's part of the GPU init inside the vbios
21:10karolherbst: so it copies the VBIOS into VRAM
21:11hell__: so PRAMIN only works if the VBIOS copies itself into VRAM
21:11hell__: so this means SeaBIOS actually ran the VBIOS on the 8400GS
21:11karolherbst: doesn't matter though, as PROM seems to contain the VBIOS here
21:11karolherbst: PRAMIN is utterly useless on laptops btw
21:12karolherbst: because the BIOS doesn't init the secondary GPU
21:12karolherbst: also.. after it got turned off, all VRAM content is lost regardless
21:12hell__: oh, on Optimus laptops
21:12karolherbst: but also on desktops
21:12hell__: Optimus desktops?
21:13karolherbst: only the primary GPU gets initialized
21:13karolherbst: well.. integrated GPU + discrete GPU
21:14karolherbst: I am actually wondering if seabios/coreboot have nvidia specific code and only try to read PROM or something....
21:14karolherbst: or maybe PROM needs to be enabled
21:14hell__: coreboot doesn't have Nvidia-specific code other than stuff to make hybrid graphics work, and that's mainboard-specific
21:15hell__: and SeaBIOS doesn't seem to do anything special about it either
21:17karolherbst: anyway... something is odd about the other GPU
21:19karolherbst: hell__: mind booting with nouveau.config=NvBios=PCIROM with the old GPU?
21:19karolherbst: just wondering if it works at all, but I highly doubt it
21:19hell__: I think you mean johns?
21:19karolherbst: ahh yeah...
21:19karolherbst: probably easier to check with dd
21:19hell__: that too
21:20karolherbst: _anyway_ I think seabios/coreboot is always placing seavgabios at 0xc0000
21:20hell__: yes, very likely
21:21karolherbst: the other logs have a second option rom at ce80 and I bet that's the GPU one
21:22karolherbst: johns: mind uploading whatever you get with "sudo dd if=/dev/mem of=cseg.rom bs=64k count=2 skip=12" with the old gpu?
21:23karolherbst: I am actually wondering if we have both BIOS in there
21:25hell__: not sure what ce80:0003 means, tbh
21:25johns: karolherbst: sure. getting it..
21:27johns: karolherbst: https://bye.wjsullivan.net/nextcloud/index.php/s/XLpR62wy4nMZx6d
21:28johns: it does look like both?
21:28hell__: huh, the first one is actually the Nvidia VBIOS
21:31hell__: yes, Nvidia VBIOS at 0xc0000, SeaVGABIOS at 0xce800
21:36karolherbst: so for whatever reasons it doesn't find the VBIOS for the newer GPU
21:38hell__: hmmmmm, digging into it, looks like this is a libreboot build
21:39hell__: in a nutshell, libreboot is to coreboot what linux-libre is to linux
21:39karolherbst: yeah... I am aware
21:40karolherbst: I already fear for the worst
21:40hell__: so I wouldn't be surprised if the settings they've used break option ROM loading
21:42hell__: the CPU is running without any microcode updates, even
21:42karolherbst: you know, it's secure, because you don't load random binary blobs from the internet
21:46johns: I understand the sentiment, but from what I've read / understand, libreboot loads option roms if available, or rather, doesn't stop seabios from loading them
21:47hell__: yes, SeaBIOS somehow finds the option ROM on the 8400GS card, but not on the other card
21:49hell__: johns: honestly, your best bet might be to patch out this fixup and build your own kernel: https://github.com/torvalds/linux/blob/f8c7e4ede46fe63ff10000669652648aab09d112/arch/x86/pci/fixup.c#L311
21:50hell__: if you don't want to mess with the firmware
21:50johns: reading https://libreboot.org/faq.html#external-gpus it does same some...stuff there, but it ends clearly saying that it's configured to load the gpu option rom if available
21:50johns: *say some
21:50karolherbst: again.. I am wondering if nouveau should try fetching the actual PCI BIOS...
21:51karolherbst: johns: the code detecting it could be bonkers
21:52johns: hell__: alright, I will take a look..
21:52karolherbst: let's dive into the source code..
21:52hell__: the coreboot logs say that this is a libreboot build from 2016
21:53hell__: plenty of things have happened since then
21:54karolherbst: but I guess that patch is way too new
21:55johns: well also if I had that set to 1 in my build, it wouldn't have loaded the seavgabios either?
21:55karolherbst: ahh yeah...
21:55karolherbst: clean commit removing all history
21:56karolherbst: johns: yeah... I guess so
21:56karolherbst: just taking this more as a hint that potentially libreboot _could_ mess things jup
21:57hell__: yeah, some funky stuff happened with libreboot where other people got "erased" from history and other places...
21:57hell__: ah, https://notabug.org/swiftgeek/libreboot/commit/27fce189cd1cd9cc93494a76af558dae47557d50
22:06karolherbst: I've heard
22:06karolherbst: I missed the _second_ ?!? one
22:08swiftgeek: karolherbst: as far as pointing to optionrom goes, i would appreciate option to pass it as a file / lib/firmware
22:09karolherbst: swiftgeek: not exactly sure how that works in nouveau, but there is a way already
22:10karolherbst: yeah.. it simply uses request_firmware
22:10johns: I have to put a pin in my debugging here, thanks tons karolherbst and hell__ -- I'll take a look at the kernel fix
22:11karolherbst: johns, hell__: I think I'd still be interested in figuring out where to load the option ROM from when the firmware is doing something stupid
22:11johns: yeah I'm not ready to give up on it myself yet, just have to leave my office where the machine is for the night
22:11swiftgeek: that got me > drm/nouveau/bios: allow loading alternate vbios image as firmware
22:11swiftgeek: from redhat
22:12hell__: karolherbst: if firmware is not to be relied upon, then the only way is using the PCI_ROM_ADDRESS BAR
22:15karolherbst: hell__: would have to figure out how to do that from inside linux then :D
22:17swiftgeek: i can't find it already in 4.0 xD
22:18hell__: karolherbst: figure out a way to undo/not do the shadowing done here? https://github.com/torvalds/linux/blob/f8c7e4ede46fe63ff10000669652648aab09d112/arch/x86/pci/fixup.c#L311
22:18karolherbst:is spending too much time on libreboot drama now
22:20swiftgeek: 3.6 is the last one to support vbios as file ?
22:20karolherbst: should still be there
22:23karolherbst: swiftgeek: the code is inside drivers/gpu/drm/nouveau/nvkm/subdev/bios/shadow.c
22:24karolherbst: first it checks if the value provided is one of the supported methods, then it tries to load it as firmware
22:25karolherbst: hell__: I am actually wondering if that would be that simple
22:25karolherbst: I'd prefer to not mess with that stuff and just get it mapped so I can read it out
22:26hell__: yes, although I'm not sure who disables PCI_ROM_ADDRESS, if anyone
22:26karolherbst: but I suspect the kernel is simply overwriting the actual location.. mhhh
22:27karolherbst: hell__: probably the call to pci_disable_rom inside that fixup?
22:27hell__: on my system the register was all zeroes (if it was the right register)
22:27karolherbst: ahh yeah
22:27karolherbst: pci_disable_rom messes with the PCI config
22:27hell__: it just unsets the enable bit, though
22:27karolherbst: which could be enough
22:28hell__: on my system the register was a box of donuts (0's)
22:29karolherbst: so the address is at 0x30 or 0x38
22:30karolherbst: Expansion ROM at b4000000 [disabled] [size=512K]
22:30karolherbst: 0000030 0000 b400 0060 0000
22:30karolherbst: soo.. yeah...
22:31hell__: IIRC the 0x30 or 0x38 difference is for PCI endpoints vs bridges
22:31karolherbst: anyway.. pci_disable_rom writes ~PCI_ROM_ADDRESS_ENABLE into it
22:31karolherbst: so the address is lost even
22:33swiftgeek: lol https://patchwork.kernel.org/project/dri-devel/patch/20141122193025.GA5782@kaos.lebenslange-mailadresse.de/
22:33karolherbst: I remember that random stuff
22:33karolherbst: I had this macbookpro even I think
22:34karolherbst: got it to boot into pure bios mode using intel as the main gpu
22:34karolherbst: that was _fun_
22:34karolherbst: pure efi mode I mean
22:34swiftgeek: so you resolved issue with both radeon and nouveau where i have hit the wall, much thx
22:34karolherbst: I think the issue was on BIOS you only got the discrete GPU
22:35hell__: karolherbst: rom_addr &= ~PCI_ROM_ADDRESS_ENABLE;
22:35karolherbst: and EFI wired the display to the wrong GPU by default
22:35hell__: that's just setting the enable bit to 0
22:35karolherbst: hell__: it writes to 0x30/0x38
22:35karolherbst: ohh wait..
22:35karolherbst: &=.. duh
22:35hell__: it's a read modify write
22:36karolherbst: nah, you are right
22:36karolherbst: I missed the and operator
22:37karolherbst: johns: ... mind hexdumping the /config file of the new GPU? I am only interested in the 4 bytes from 0x30 onwards
22:38karolherbst: actually.. let me check if that even works on one of my discrete gpus
22:40karolherbst: okay... "[ 3.573760] pci 0000:01:00.0: Video device with shadowed ROM at [mem 0x000c0000-0x000dffff]"
22:41karolherbst: "0000030 0000 8d00 0060 0000"
22:41karolherbst: that looks promising
22:42hell__: IIRC on my system the register was all zeroes
22:44karolherbst: it's all ffff, but maybe because it's disabled.. so let's enable it
22:46hell__: yes, FF's is what you'll get if a PCI access doesn't get decoded
22:46karolherbst: it doens't let me set bit 1...
22:47karolherbst: ehh wait
22:47karolherbst: I have to do that on 0x30...
22:47karolherbst: I tried that on 0x34 :D
22:48karolherbst: it's 0x8d000001 now.. okay
22:48karolherbst: now it's all 0... :(
22:48hell__: which system is it?
22:49karolherbst: uhm... what do you mean by "system"?
22:49hell__: which computer are you testing things on?
22:49karolherbst: some desktop
22:50karolherbst: let me see if I find a GPU without PROM
22:50karolherbst: highly doubt I have one though
22:50karolherbst: _but_ I have 30 to choose from, sooo...
22:52karolherbst: ahh that one does use PROM and not PRAMIN, fun
23:28karolherbst: heh.. this GPU only contains garbage
23:52karolherbst: hell__: so dding from the address I find there gives me only garbage :/