00:44 TimurTabi_: Is there something weird about reading VBIOS? I'm trying to port some code from Nvidia's driver to Nouveau, and I'm getting weird results when reading some data at what's supposed to be the same address. It's only for some addresses though.
00:45 TimurTabi_: RM reads directly from vmem, but only in 32-bit aligned reads.
00:45 TimurTabi_: Nouveau seems to pre-read the whole VBIOS into some buffer, so I think it's handling misaligned reads differently
00:48 imirkin: unaligned reads are handled via various helpers
00:48 imirkin: some architectures don't handle unaligned reads on RAM well either
00:49 imirkin: there are a lot of differnet sources for the VBIOS, so nouveau just normalizes it all
00:49 karolherbst: also this partitioned VBIOS thing
00:49 imirkin: sometimes it's in ACPI. sometimes it's in a special "PROM" area. sometimes elsewhere.
00:49 imirkin: yeah, i wasn't going to get into that :)
00:49 karolherbst: :)
00:50 imirkin: TimurTabi_: what are you trying to do?
00:50 karolherbst: but yeah.. we can't just do unaligned reads in the kernel, at least not directly
00:50 imirkin: no, we can. but then we get warnings about it.
00:50 imirkin: i think TimurTabi_'s point was that it reads 32-bit chunks of e.g. PROM directly
00:51 karolherbst: well.. there was also this "feature" that nvidias driver reads a faked vbios from vram :)
00:52 karolherbst: maybe rm does read it into vram
00:52 imirkin: not really a "feature"
00:52 TimurTabi_: I'm trying to port some code that traverses the VBIOS tables and extracts info. I'm using the proper accessors, but some reads return a different value that what RM reads
00:52 imirkin: it's a legit spot for the vbios
00:52 TimurTabi_: And so my ported code goes haywire.
00:52 imirkin: nouveau supports it too
00:52 karolherbst: TimurTabi_: right... but are you using nouveaus nvbios helpers to read that?
00:52 TimurTabi_: Yes
00:52 karolherbst: mhhh
00:52 karolherbst: odd
00:52 imirkin: TimurTabi_: perhaps share the code and see if we can notice anything obviously wrong you're doing
00:53 TimurTabi_: The RM code does some math to ensure that it only does an aligned 32-bit read
00:53 karolherbst: ahh
00:53 karolherbst: yeah although that shouldn't matter in nouveau
00:53 imirkin: TimurTabi_: we do that with the unaligned_* accessors i think
00:53 TimurTabi_: And I'm wondering if RM and Nouveau treat a misaligned read differently.
00:53 imirkin: which are hidden behind other things
00:54 imirkin: i can't speak to modern RM, but definitely for "legacy" boards, we match what the RM did
00:54 TimurTabi_: Yeah, not any more
00:54 karolherbst: imirkin: we don't have those for the vbios though, do we?
00:54 TimurTabi_: RM does a hard I/O read every time you want to access any data in VBIOS.
00:54 imirkin: TimurTabi_: that can't be right
00:54 imirkin: e.g. what if VBIOS is in ACPI?
00:54 TimurTabi_: Nouveau preloads the whole bios into a buffer and just does an array read
00:55 TimurTabi_: Hmmm
00:55 karolherbst: ohh wait
00:55 karolherbst: nvbios_ indeed checks alignment
00:55 karolherbst: nvm then
00:55 imirkin: we use unaligned_* helpers to ensure that we can read an unaligned 32- or 16-bit value on e.g. alpha/sparc
00:55 TimurTabi_: All I can say is that on tu10x, vbios is not in ACPI
00:55 karolherbst: yeah
00:56 karolherbst: that's normally laptop stuff
00:56 TimurTabi_: BTW, when I say "unaligned", I don't mean really unaligned. I mean like a 16-bit read at address 10.
00:56 karolherbst: they think it's better to place it inside ACPI, so...
00:56 imirkin: TimurTabi_: that's not _that_ unaligned
00:56 TimurTabi_: it's aligned to 16 bits, but not aligned to 32 bits
00:56 imirkin: old vbios's have 16-bit reads at address 11 :)
00:56 karolherbst: that's fine
00:56 imirkin: nouveau handles it all
00:56 karolherbst: you can just ignore alignment exist
00:56 karolherbst: as long as you use nvbios_rd that is
00:57 TimurTabi_: Well, I was debugging it when I just got tired and went home. I'll keep trying again tomorrow.
00:57 imirkin: TimurTabi_: so ... the vbios stuff lends itself to fairly easy debugging
00:57 imirkin: dump the vbios
00:57 karolherbst: TimurTabi_: I hope you don't do this address adjustment
00:57 karolherbst: because we hide all this annoying thing away
00:57 imirkin: and then see where the values RM is seeing show up
00:57 imirkin: could be something incredibly dumb
00:57 imirkin: or could be something totally confusing
00:58 imirkin: note that there can also be multiple vbios sections
00:58 karolherbst: so in nouveau: you read the offset from the vbios, you use that as is and get the correct thing
00:58 imirkin: "images" as nouveau calls them iirc
00:58 TimurTabi_: I'm porting code that scans the images for a match.
00:58 TimurTabi_: I didn't see any code in Nouveau that does that already.
00:58 karolherbst: what do you mean by scanning images for a match?
00:59 TimurTabi_: Well, I don't have the code handy in front of me now,
00:59 TimurTabi_: but the code is looking for something.
00:59 karolherbst: mhh
01:00 karolherbst: well normally you start parsing stuff and gets offset, at least that's how I remember things
01:00 TimurTabi_: Yeah, sometimes I get the wrong offset
01:00 imirkin: TimurTabi_: you mean lik the NPDE match thing?
01:00 TimurTabi_: like Nouveau will read 103 where RM read 120
01:01 imirkin: TimurTabi_: dump the whole vbios and see what's up
01:01 TimurTabi_: That's what I was doing when my brain shut down.
01:01 karolherbst: right.. we provide the vbios.rom file inside debugfs
01:01 TimurTabi_: you do?
01:01 karolherbst: yeah
01:01 imirkin: /sys/kernel/debug/dri/0/vbios.rom
01:01 TimurTabi_: ah
01:01 TimurTabi_: that will help
01:01 imirkin: it's nouveau's ideal of what the vbios is
01:01 karolherbst: also the strap_peek alongside
01:01 imirkin: i.e. the image that you're talking about
01:01 karolherbst: ye
01:01 karolherbst: s
01:01 imirkin: it's the super-raw vbios
01:01 karolherbst: it's all postprocessed and everything
01:02 imirkin: it's not necessarily the whole PROM region
01:02 imirkin: (i'm blanking on some of the dteails about PCIR headers and whatnot
01:02 karolherbst: that's all handled already
01:02 imirkin: (wow, i've forgotten those details. go me! finally...)
01:02 karolherbst: you get the plain buffer without any funny business
01:02 karolherbst: well "plain"
01:03 imirkin: (maybe i can reuse those brain cells for something useful)
01:03 karolherbst: just the vbios from start to end
01:03 karolherbst: imirkin: you say that now
01:03 TimurTabi_: what kind of post-processing is done?
01:03 karolherbst: TimurTabi_: like if the vbios is made of multiple parts
01:03 imirkin: karolherbst: i do. of course i still remember that i used to know that ... once i forget even that, i will have achieved the dream
01:03 karolherbst: that PCIR stuff
01:03 TimurTabi_: ok, I'm not familiar with PCIR but I'll keep an eye out for that tomorrow.
01:03 karolherbst: so the vbios.rom file provided through sysfs doesn't have that anymore
01:03 imirkin: TimurTabi_: it's a string in the vbios
01:04 imirkin: that we search for
01:04 imirkin: there's PCIR and NPDE iirc
01:04 imirkin: and maybe some others
01:04 imirkin: (wtf is NPDE? not-partial-derivative-equation? who knows)
01:04 imirkin: at least with PCIR it's probably PCI Resource
01:05 karolherbst: it could be that newer gpus have more parts
01:05 karolherbst: that would be annoying
01:05 karolherbst: not sure if we handle that correctly
01:06 imirkin: TimurTabi_: you probably saw the nvbios code has the concept of an "image" and there can be multiple ones
01:06 imirkin: TimurTabi_: there's also, rather annoyingly, multiple copies of the vbios code
01:06 imirkin: i'm referring to the one in subdev/bios
01:06 imirkin: rather than the one in nouveau_vbios
01:06 imirkin: (or maybe nouveau_bios, i forget)
01:07 airlied: I know on some laptops from other vendors the sbios can also patch the vbios during boot
01:09 karolherbst: airlied: sounds cursed
01:09 imirkin: sbios = system bios?
01:09 karolherbst: but probably helpful if you can flip between discrete and hybrid mode
01:09 imirkin: it used to be that "PRAMIN" was a valid spot for vbios's
01:09 imirkin: this is why faking the vbios for blob was easy
01:10 imirkin: we'd just convince it to read from PRAMIN and woohoo
01:10 imirkin: (which was not a difficult feat)
01:10 imirkin: this is the "nvafakebios" utility
01:12 airlied: karolherbst: yes for that sort of thing
01:16 Lambert|2: Hey, guys. I noticed a weird issue. When boot to windows and then reboot into linux, the GPU fan is spinning very slowly and doesn't increase its rpm. I think it's because in windows it's spinning at reasonable 800-900 rpm, and the gpu is fairly cool, like 40 degrees celsius. Then I boot into linux and it's not spinning, so the GPU heats up to about 45-48C, THEN if I reboot again, the fan goes to
01:16 Lambert|2: to 800rpm
01:17 Lambert|2: I suspect it depends on how hot the GPU is on boot
01:17 karolherbst: Lambert|2: probably you got a new GPU where nvidia prevents us from changing fan speeds :)
01:18 Lambert|2: Luckily, the temps are far from critical, so it won't bake my gpu, but it is disconcerting
01:18 imirkin: which gpu?
01:18 Lambert|2: karolherbst: it's a Pascal. 1060
01:18 karolherbst: Lambert|2: figures
01:18 imirkin: nvidia has helpfully made it impossible for nouveau to control fan speeds
01:19 karolherbst: imagine a world where we would finally be able to
01:19 imirkin: thank you for choosing nvidia. we appreciate that you have a choice of gpu vendors, and you have apparently made the wrong one.
01:19 TimurTabi_: lol
01:19 Lambert|2: imirkin: yeah, I've heard on some cards it goes full blast all the time. But never heard of the fan not spinning.
01:20 imirkin: [that's adapted from a south park, btw, where they're flying City Airlines, but the pilot pronounce the "C" like a "Sh"]
01:21 Lambert|2: karolherbst: But here's the thing. Nouveau is evidently changing the fan speeds. It just only cares to do so on boot.
01:22 karolherbst: Lambert|2: well, the firmware POSTs the card
01:22 karolherbst: and that ends up running some script on the GPU which inits state
01:22 karolherbst: it's all very complicated
01:22 Lambert|2: karolherbst: Okay, so the firmware sets 0 rpm? I find that hard to believe.
01:22 imirkin: Lambert|2: nouveau is most definitely not changing fan speeds
01:23 imirkin: Lambert|2: we upload some blob firmware, and it does whatever it wants
01:23 karolherbst: Lambert|2: well.. we can't change the fan speed
01:23 imirkin: the firmware is signed, so we can't change it
01:23 karolherbst: we might report 0 though
01:23 Lambert|2: Heard about that too.
01:24 karolherbst: Lambert|2: did you actually checked it's 0 or did you trust the kernel to report sane values?
01:24 Lambert|2: But then again, there's no PMU firmware for this card, is there?
01:25 karolherbst: correct, at least not in a way we could 1. distribute it and 2. load and do sane things with it
01:25 Lambert|2: karolherbst: I physically looked at it, and it's not 0, but it's damn near 0. It's barely rotating.
01:25 karolherbst: well
01:25 karolherbst: normally nvidia relies on their driver getting loaded, so the firmware might just set it to something ridiculous low if the temperature is quite low
01:25 karolherbst: what does it matter if a second later your driver gets loaded
01:26 Lambert|2: That's... dangerous.
01:26 karolherbst: not really
01:26 karolherbst: the GPU has enough protection against that
01:26 karolherbst: the GPU can reach 115º with nothing happening
01:26 karolherbst: although at some point it's configured to shut down
01:26 karolherbst: (and do other things to prevent it from overheating by reducing power consumption in multiple ways)
01:27 Lambert|2: Yes, really, the fans are defaulting to full blast, not to 0. The CPU fan goes to 100% till the driver takes over.
01:27 karolherbst: the "soft" limit after it starts doing something is usually around 103º or so
01:28 karolherbst: I find computers which think it's a good idea to boot with a full blast quite annoying tbh, because it's just a pointless thing to do
01:28 Lambert|2: it is annoying, thankfully it's very quick
01:28 karolherbst: yeah .. anyway.. nothing we can do about it
01:28 Lambert|2: but I get why they do it
01:29 karolherbst: unless nvidia is so nice and helps out with that 🙃
01:29 Lambert|2: karolherbst: they released something a few weeks ago, didn't they?
01:29 karolherbst: they might have, but not for desktop GPUs
01:30 karolherbst: and a lot of stuff seemed to be missing
01:30 Lambert|2: it might've been for tegra (?)
01:30 karolherbst: so not sure if that would even be helpful
01:30 karolherbst: but it might be
01:30 karolherbst: dunno
01:30 karolherbst: Lambert|2: yeah
01:30 karolherbst: but the firmware we got for tegra ones is also different from the desktop ones
01:30 karolherbst: so...
01:30 Lambert|2: https://www.phoronix.com/scan.php?page=news_item&px=NVIDIA-Kernel-Driver-Source
01:30 Lambert|2: ^ that stuff
01:31 karolherbst: yeah...
01:31 karolherbst: reverse engineering any kind of firmware blob will be hell though
01:31 karolherbst: I know I looked a bit into it, but didn't find it very usefull overall
01:32 Lambert|2: karolherbst: you know what I'm tempted to do? Rip the fan off of the fan connector on the GPU card and connect it to the SYS_FAN connector on the motherboard. :-D
01:32 karolherbst: Lambert|2: yeah.. well.. I wouldn't 🙃
01:32 Lambert|2: then I'll have full control over it
01:33 Lambert|2: with fancontrol or something
01:33 karolherbst: sure, but does it solve a problem?
01:33 Lambert|2: sort of...
01:33 Lambert|2: it's a bit barbaric, sure...
01:34 karolherbst: yeah soo the GPU might get a little cooler :P
01:34 karolherbst: big deal
01:34 Lambert|2: karolherbst: the fan curves will be saner
01:34 karolherbst: doesn't really matter
01:34 karolherbst: as long as the GPU doens't reach like 90º I wouldn't even care
01:35 Lambert|2: considering that nouveau can't reclock it, the GPU doesn't get hot, that's true
01:35 karolherbst: we have laptops running their CPUs at 100º and that seems to work. all those CPUs/GPUs are quite robust these days
01:37 karolherbst: I just hope Nvidia sees reason at some point in the future and helps us out with this kind of stuff 🙃
01:37 Lambert|2: it's not strictly a problem, but it bugs me. I don't know if the reported temp is correct, or the card has a hotspot that is considerably hotter
01:37 karolherbst: Lambert|2: the reported temp is correct
01:37 karolherbst: well.. you can always check
01:37 karolherbst: but the GPU is protected
01:37 Lambert|2: karolherbst: how? :-)
01:38 karolherbst: well.. you can touch the gpu
01:38 karolherbst: after a while the entire cooling block gets hot
01:38 Lambert|2: How do I check if the VRM mosfets are at 120C?
01:38 karolherbst: well if the GPU is indeed hot
01:38 karolherbst: Lambert|2: you'd burn your fingers on the cooler
01:38 karolherbst: believe me, hot GPUs are hot
01:38 karolherbst: you'll notice
01:38 Lambert|2: yeah, well... not necessarily
01:39 Lambert|2: the VRM has a separate radiator on the mosfets, that is not connected to the rest of the cooling system
01:39 Lambert|2: and this card has nothing at all on the memory chips
01:40 karolherbst: well those usually also don't get very hot
01:40 Lambert|2: yeah, but normally the fans are blowing on them
01:40 Lambert|2: at 700-800rpms
01:41 karolherbst: well... at least nobody complained about broken GPUs before
01:41 karolherbst: I mean, you can wire up the fan to your system if you want to, I just don't think it's really needed
01:42 Lambert|2: https://www.purepc.pl/files/Image/artykul_zdjecia/2016/palit_gtx_1060_3gb/palit_geforce_gtx_1060_3gb_dual_fan_test_review_5m.jpg this is what it looks like
01:43 karolherbst: yeah well...
01:43 karolherbst: there are passively cooled GPUs and they are fine as well
01:43 karolherbst: I really wouldn't worry
01:43 Lambert|2: karolherbst: Well, when people complain about baked GPUs, it'll be loud. :-D Provided they make the connection between the breakage and the fan speeds. :-)
01:45 Lambert|2: okay, I guess point taken
01:48 Lambert|2: it is bloody annoying, though. I think something at boot sets the fan speed, but then nouveau sort of takes over, but it doesn't, so you're stuck with whatever is set on boot.
01:48 Lambert|2: Unless you load a real driver. :-)
01:48 karolherbst: sure
01:48 karolherbst: that'll fix things
01:48 Lambert|2: and break some others
01:50 karolherbst: ahh finally found the tegra stuff again
01:50 karolherbst: yeah.. doesn't seem to have any pmu stuff
01:51 Lambert|2: remember that 'anonymous' group that recently claimed to hack nvidia, steal all their stuff, and demand they opensource the drivers or they will just upload all of it?
01:51 Lambert|2: that was funny
01:51 karolherbst: except it wasn't
01:51 karolherbst: doesn't help us at all
01:51 karolherbst: to the contrary, it hurts us
01:52 Lambert|2: It doesn't help, but it makes me giggle
01:52 karolherbst: anybody looking at it would be tainted and couldn't _ever_ contribute upstream
01:52 karolherbst: Lambert|2: nope, there is nothing to laugh at, as it is harmful and makes our life harder
01:52 Lambert|2: it wasn't even true
01:52 Lambert|2: probably
01:53 Lambert|2: I think it was a bluff
01:53 karolherbst: well, they wanted to be the heros
01:53 Lambert|2: and not a good one
01:53 karolherbst: yeah, bunch of idiots
01:54 karolherbst: they claimed it would help with open sourcing, but you can only use it illegally if you scam people through cryptocoins anyway, so those people obviously don't care if they do illegal things
01:54 karolherbst: but literally everybody else does care
01:54 karolherbst: so if they weren't lying and make it open source, they have all the benefits and everybody suffers
01:54 karolherbst: *else
01:55 Lambert|2: I presonally don't care much if my drivers are 'legal'
01:55 karolherbst: just look at how the wine project deals with tainted developers
01:55 karolherbst: we would have to do something similiar
01:55 karolherbst: Lambert|2: sure.. users can download whatever, but it's a legal risk for anybody hosting that source code
01:55 Lambert|2: that's what thepiratebay.org is for
01:55 karolherbst: we would have to ask every contributor if they looked at it to get legal assurance
01:56 karolherbst: Lambert|2: well.. kernel.org can't really move there, can it?
01:56 Lambert|2: karolherbst: No, but nouveau can
01:56 karolherbst: well.. then we would have to remove nouveau from the kernel
01:57 karolherbst: and nothing could ship it by default
01:57 karolherbst: or would
01:57 karolherbst: as you see.. it only causes harms no matter how you look at it
01:57 karolherbst: nobody asked us if that would be a smart move, so...
01:58 Lambert|2: karolherbst: No, you would have to remove nouveau from kernel, if nvidia goes for it, then it'd have to be moved to piratebay and maintained out-of-tree, and that would indeed complicate things, but imagine the backlash!
01:59 Lambert|2: team green would get a lot of bad PR
01:59 karolherbst: well or we don't accept contributions from tainted devs
01:59 karolherbst: Lambert|2: why would they?
01:59 karolherbst: that's normal IP law
01:59 karolherbst: wine is in this boat already
02:00 karolherbst: they have to ignore leaked MS code so hard, it's not funny
02:00 karolherbst: accepting code from new people is always a legal risk for them
02:00 Lambert|2: karolherbst: But how do you even know? Let's say I want to contribute to nouveau, and you ask me if I looked at the leaked nvidia stuffs. And I say "no, ofc not, bro".
02:00 Lambert|2: Now what?
02:01 karolherbst: well, you lied and we acted in good faith
02:01 karolherbst: your problem
02:01 karolherbst: as long as we have a paper trail on that, we are good
02:01 karolherbst: you pay for the damage
02:01 airlied: it's generally easy to spot patches that are obviously from non-RE'd sources
02:01 Lambert|2: karolherbst: Good. Let's nvidia go after me, if they can find me.
02:01 Lambert|2: *let
02:01 Lambert|2: and IP laws are a joke to me
02:01 airlied: they rarely contain enough hex numbers, or use names you can't find in public literature
02:02 karolherbst: yeah and that
02:03 karolherbst: normally what people do is, that tainted devs write documentation, and others write the code
02:03 Lambert|2: > you pay for the damage < I pay nothing, because there's no IP laws in my country and it's behind the iron curtain anyway.
02:03 karolherbst: that's gray area enough that it is somewhat possible to do
02:03 karolherbst: Lambert|2: tough
02:03 karolherbst: guess you have other issues to deal with then
02:04 Lambert|2: That is true. But those issues have nothing to do with american legal system
02:05 karolherbst: yeah...
02:05 Lambert|2: the system that has its own issues I could go on about for hours
02:06 karolherbst: I honestly don't know how wine can enfore those things, but I doubt it's anything more than just you ticking a box saying "everything is fine"
02:07 Lambert|2: Eh... Is it just me, or would it be much easier for everyone if they simply maintained their own bloody driver? In kernel.
02:07 karolherbst: "they" being nvidia?
02:07 Lambert|2: It's be easier for them too
02:07 Lambert|2: yes
02:07 karolherbst: sure
02:07 karolherbst: it would
02:07 karolherbst: but...
02:07 karolherbst: you know, it's nvidia :P
02:08 karolherbst: well having it in the tree comes with annoying consequences
02:08 Lambert|2: It'd be easier for them too, because kernel has certain symbols that can only be used by GPL modules.
02:08 karolherbst: like if you have an UAPI you also need open source userspace
02:08 karolherbst: and there is no way nvidia ever open sources cuda
02:08 karolherbst: at least I don't see a way they ever doing that
02:09 Lambert|2: Fine. Forget cuda. Fix the fan.
02:09 karolherbst: a driver is pointless if it can't have UAPI
02:09 Lambert|2: geezless
02:09 karolherbst: but yeah.. that will be all very very interesting
02:10 karolherbst: I hope nvidia has a change of heart, but we can only hope
02:11 Lambert|2: yeah, well, to quote the Borg Queen, it's your deeply flawed inability to not hope in the face of hopelessness.
02:12 karolherbst: only time will tell
02:13 Lambert|2: very human
02:14 karolherbst: I should go to bed :D
02:14 karolherbst: it's getting late
02:14 Lambert|2: By the way. Why can you not have a GPLed kernel driver, but have a userspace blob for CUDA?
02:15 Lambert|2: that'd be fine
02:15 Lambert|2: nothing wrong with that
02:15 karolherbst: Lambert|2: special rules the drm subsystem has
02:15 karolherbst: need open source userpsace, otherwise the driver will be rejected
02:15 karolherbst: and that includes an open source compiler
02:16 karolherbst: I am sure airlied can explain in deep lengths on why that's a good idea :P
02:16 Lambert|2: yeah, that's all fine, but cuda is not drm, it's for computing
02:16 karolherbst: spoiler alert: vendors can't be trusted to come up with good UAPIs
02:16 karolherbst: Lambert|2: so?
02:16 karolherbst: the driver would be under drm
02:17 karolherbst: it would make use of kms and all the fun stuff
02:17 karolherbst: so it has to show an open source userspace for all UAPIs
02:17 Lambert|2: so you can opensource most of the driver, everything that deals with the actual graphics, but keep cuda
02:17 airlied: compute is just graphics with all the good stuff shaved off
02:17 karolherbst: Lambert|2: and can't use cuda
02:18 karolherbst: because it can't use the GPL driver :)
02:18 karolherbst: (and we would reject such a scheme anyway)
02:18 Lambert|2: cuda can do whatever it wants in userspace
02:18 karolherbst: well it can't
02:18 karolherbst: it needs UAPIs
02:18 karolherbst: need to talk to the driver in special ways for ... whatever reasons
02:19 karolherbst: cuda is huge
02:19 Lambert|2: anyone really needs it on linux?
02:19 karolherbst: yeah
02:19 karolherbst: the entire serious compute business is linux
02:20 Lambert|2: those people can use the blob, no sympathy :-D
02:20 Lambert|2: too much money
02:23 karolherbst: at which point nvidia could just help out with nouveau :p
02:24 Lambert|2: by releasing firmwares?
02:24 karolherbst: for instance
02:24 karolherbst: well.. they actually released some firmware for us, so we can use OpenGL and stuff
02:25 karolherbst: but not the PMU stuff yet
02:25 Lambert|2: karolherbst: there might be some internal issues with that idea. Remember how Intel outsourced PowerVR and how that went?
02:26 Lambert|2: Alan Cox had to re-do everything on his own :-D
02:26 karolherbst: oh no
02:27 Lambert|2: Intel got scammed, is my take on it. Imagination gave them the chip, but kept the IP for the driver.
02:27 Lambert|2: which is why intel could never really use that chip
02:27 imirkin: IMG got their come-uppance eventually
02:28 Lambert|2: yeah!
02:28 Lambert|2: Not a second too soon
02:31 Lambert|2: I actually have a device with atom and powervr. But it needs a new eMMC chip
02:31 Lambert|2: and it need android
02:31 Lambert|2: which is a whole separate can of worms
02:32 Lambert|2: and it's an x86 tablet, go figure
02:32 karolherbst: oh no
02:32 Lambert|2: Not a bad one, other than the GPU
02:33 Lambert|2: the rest of the hardware is decent
02:34 Lambert|2: Nice screen, hdmi output, 3G...
02:34 Lambert|2: I was thinking of making a car computer or a TV box out of it.
02:35 Lambert|2: But ultimately decided I don't want to even look at that GPU
02:35 Lambert|2: and to replace the dead eMMC, you kinda have to look near it
20:15 TimurTabi: Ok, I made some progress with my vbios parsing issue, but I'm not sure what's going on. I'm getting tripped up by nvbios_addr()
20:15 TimurTabi: The offset I'm looking for is >= bios->image0_size, so it does some math on it and returns a result I'm not expecting.
20:16 TimurTabi: I guess this is different than how RM does things. RM seems it as one giant blob.
20:16 TimurTabi: if (*addr > bios->image0_size && bios->imaged_addr) {
20:16 TimurTabi: *addr -= bios->image0_size;
20:16 TimurTabi: *addr += bios->imaged_addr;
20:16 TimurTabi: }
20:17 TimurTabi: What is imaged_addr supposed to be?
20:19 karolherbst: TimurTabi: the vbios might contain of multiple parts
20:19 karolherbst: but the offsets within the vbios assume it's all one linear buffer
20:19 TimurTabi: [ 330.379443] s_locateExpansionRoms::305 bios->image0_size=0xf000
20:19 TimurTabi: [ 330.385471] s_locateExpansionRoms::306 bios->imaged_addr=0x20000
20:19 TimurTabi: I don't think 0x20000 is correct
20:20 karolherbst: TimurTabi: in the raw vbios, there is "garbage" between 0xf000 and 0x20000, correct?
20:20 TimurTabi: I don't think so
20:20 karolherbst: well I think there is
20:20 TimurTabi: RM is reading it
20:20 TimurTabi: let me double check that
20:21 TimurTabi: [ 17.806178] NVRM s_locateExpansionRoms: ::317 currBlock=0xf000
20:21 TimurTabi: [ 17.806179] NVRM s_romImgReadGeneric: ::132 offset=0x30f018
20:21 TimurTabi: [ 17.806182] NVRM s_locateExpansionRoms: ::320 pciBlck=0x1c
20:21 karolherbst: I think that garbage is some signed/encrypted shadow of the buffer after it, but we never gave it much thought on what it really is.
20:21 TimurTabi: Here is RM reading at 0xf018 and getting valid data.
20:21 karolherbst: right
20:22 karolherbst: ahh
20:22 karolherbst: 0x30f018
20:22 karolherbst: so it's 0x30000 not 0x20000
20:22 karolherbst: TimurTabi: does forcing imaged_addr to 0x30000 "fixes" it?
20:22 TimurTabi: Let me see
20:23 karolherbst: all of that is a bit magic to me, but I do know we have to offset the addr after 0xf000
20:25 karolherbst: we parse that stuff inside nvbios_image and I wouldn't be surprised if that code is wrong
20:25 TimurTabi: No, it didn't fix it
20:26 TimurTabi: The problem is that there is valid data at 0xf000, and it's that data I want to access.
20:27 TimurTabi: bios->imaged_addr = bios->image0_size;
20:27 TimurTabi: I'll try that
20:28 karolherbst: I think skeggsb_ probably knows more about the details here, I just know there is some weird stuff going on we have to deal with :)
20:30 TimurTabi: Yeah, that fixed it.
20:31 karolherbst: okay
20:31 TimurTabi: So I'm going to leave that hack in there, and I'll let Ben tell me what I'm doing wrong that I need it.
20:31 karolherbst: so I guess our vbios parsing code is wrong :)
20:31 karolherbst: yep, sounds like a plan
20:31 TimurTabi: Well, more likely the code that I'm porting is not really compatible with the way nvbios_rdxx works.
20:32 karolherbst: or that
20:32 karolherbst: but I kind of doubt that
20:32 karolherbst: if you read beyond image0 you need that offset applied. but you could have a special vbios where we don't need to do that stuff
20:32 karolherbst: or something else
20:32 karolherbst: who knows
20:32 karolherbst: the vbios image got weird since pascal or something
20:34 TimurTabi: What's odd is that all my code is only intended to calculate these values:
20:34 TimurTabi: // FIXME: for some reason, we need to do this.
20:34 TimurTabi: bios->imaged_addr = bios->image0_size;
20:34 TimurTabi: Oops, not that one
20:34 TimurTabi: [ 163.238122] s_locateExpansionRoms::400 pBiosSize=331264
20:34 TimurTabi: [ 163.243379] s_locateExpansionRoms::401 extRomOffset=131072
20:34 TimurTabi: [ 163.248925] s_locateExpansionRoms::402 baseRomSize=61440
20:35 TimurTabi: These three values.
20:35 TimurTabi: I suspect there's probably a way to get these values more easily with the current Nouveau code.
20:35 karolherbst: probably
20:35 TimurTabi: Where is Ben anyway?
20:36 karolherbst: baseRomSize is 0xf000.. okay
20:36 karolherbst: that's part 0
20:36 karolherbst: pBiosSize = 0x50e00 that's the full vbios
20:36 karolherbst: extRomoffset = 0x20000
20:36 karolherbst: yeah so that's your bios->imaged_addr
20:37 karolherbst: as you see, nvbios_image already calculates that
20:38 TimurTabi: interesting
20:39 karolherbst: I guess you tried to mirror that code to nouveau, so yeah.. you would have to do whatever nvbios_image is doing, so I think you can just skip that
20:39 karolherbst: all of that code is required to use actual values from the vbios tables
20:39 karolherbst: so if you have a pointer of 0x14000 in one vbios table somewhere
20:40 karolherbst: you can't read at 0x14000, but have to read at 0x33000
20:40 karolherbst: 0x14000 + 0x20000 - 0xf000
20:41 karolherbst: and that adjustment is done inside nvbios_addr
20:41 karolherbst: but if you want to write code which calculates those offsets you obviously have to do that before we do any of that
20:43 TimurTabi: I'll just use the built-in values
20:56 TimurTabi: LOL, I just replaced the whole function I was writing with these two lines:
20:56 TimurTabi: biosSizeFromRom = bios->size;
20:56 TimurTabi: expansionRomOffset = bios->imaged_addr - bios->image0_size;
21:03 karolherbst: :)
21:03 karolherbst: TimurTabi: my assumption is, you can just ignore any of that and don't bother use those values
21:03 karolherbst: I suspect they are used to offset addresses from the vbios, no?
21:03 TimurTabi: Apparently I need to copy some data from GPU memory
21:04 TimurTabi: biosSizeAligned = biosSize & (~0x3);
21:04 TimurTabi: for (i = 0; i < biosSizeAligned; i += 4)
21:04 TimurTabi: {
21:04 TimurTabi: pImageDwords[i >> 2] = GPU_REG_RD32(pGpu, pciOffset + NV_PROM_DATA(i));
21:04 TimurTabi: }
21:04 karolherbst: just use nvbiod_rd* directly, it should just work
21:04 karolherbst: TimurTabi: there is a nvbios_memcmp btw
21:04 karolherbst: which also handles that offset business
21:05 TimurTabi: excellent, thanks.
22:21 TimurTabi_: Well, I just realized that all that code I was porting was for one thing: copying VBIOS into local memory.
22:25 karolherbst: oh no :(
22:26 TimurTabi_: At least I understand VBIOS better