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