<TD-Linux>
mwk, tbh I was under the impression that most modern VGA cards used SMM interrupts to do the emulation
<mwk>
nope
<mwk>
first, it's not possible for a *card* to do SMM interrupt
<mwk>
it might be possible for an integrated GPU, though I don't think it's likely
<whitequark>
i think an iGPU can just pull SMI#
<whitequark>
well
<mwk>
perhaps
<mwk>
but doing the interrupt is the easy part
<whitequark>
i mean, a card in cahoots with PCH could do it as well
<mwk>
getting it handled is a different thing
<whitequark>
but i don't think this collaboration actually happens
<mwk>
since you would need code in the system BIOS to know how to driver your GPU's display circuitry
<mwk>
and there's no interface a card can use to expose that
<mwk>
for an iGPU it would indeed be doable, or even for a discrete GPU that just happens to be soldered to the motherboard
<mwk>
but nvidia has to do cards, so they do it in hardware
<mwk>
intel... idk, could do it in
<mwk>
ME for all I know
<TD-Linux>
I looked all over coreboot and couldn't find any evidence of it
<ktemkin>
I mean, other than the idea of it running up in SMM, the idea of a card exposing code to tell your BIOS how to interface with its hardware isn't really *that* far from how things work
<ktemkin>
delicious, delicious option roms
* whitequark
screams internally
<ktemkin>
as of about ~5 years ago; I don't recall intel's integrated graphics doing anything all -that- odd for its legacy 'video bios' / VBE stuff
<mwk>
it doesn't "tell" the bios anything though, it just... takes over parts of it?
<ktemkin>
well, define "tell"
<mwk>
hm or I suppose it does
<mwk>
bios kind of does use int 0x10 calls to draw stuff on screen
<ktemkin>
a tad reductively, it exposes code that's mapped into the BIOS' memory space and then either hooks the interrupt handler or registers handlers for a bunch of driver functions
<sorear>
I want to believe option roms have documented calling conventions and pre/postconditions
<ktemkin>
it's... er, more documented in UEFI than it was prior to that?
<ktemkin>
anyway, re: intel graphics doing Terrible Things: when I worked on virtualization some years back, the team I worked with was tasked with creating a driver that let you pass through the intel integrated graphics to a VM using VMX, EPT, and the VT-d IOMMU
<ktemkin>
this was a monstrosity that never should have existed
<ktemkin>
but it worked, after a lot of horrible hacks; which it totally wouldn't have if the intel integrated GPU was doing *too* much behind-the-scenes breaking of the bus model
<ktemkin>
(it totally did have some fun circumventions to aide in memory 'stealing' that'd let you use a live chunk of foreign memory as a texture or scanout buffer; which the relevant Citrix folks immediately abused to do zero-copy rendering of LFBs residing in guest VMs)
<mwk>
sorear: yes, option roms do have a calling convention
<mwk>
the convention is that you use far call/return
<mwk>
any other questions?
<kc8apf>
And you work around quirks such as the option ROM address decoder on a certain PCIe switch screwing up an address bit so some pages are aliased
HexGlaze_ has left #glasgow ["Leaving"]
<marcan>
< mwk> the NV1 had VGA registers, sure, but all they did was keep the last value that was written to them <- this is what the WiiU does in Wii mode, with the legacy display interface
<marcan>
they have some microcontroller in the ATI (which I think was already there on ATI cards before?), the DMCU, converting all that stuff to the usual Radeon display hardware registers
<marcan>
including scaling and HDMI and all that
<marcan>
heck drivers/gpu/drm/amd/display/dc/dce/dce_dmcu.c is a thing these days
<marcan>
so I guess they use it for something else on PC?
<marcan>
though maybe it was introduced for wiiu and then kept for PC because they found it useful, lol
<TD-Linux>
interesting. I've never looked at wiiu homebrew
<TD-Linux>
did they include a full copy of the gc graphics?
<whitequark>
ok well it's ... not just a yosys bug. it seems to be some other bug too
gregdavill has quit [Ping timeout: 265 seconds]
nomad1 has quit [Remote host closed the connection]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier>
[Glasgow] whitequark commented on issue #161: selftest loopback fails with USB EP8IN timeout - https://git.io/JenxT
<_whitenotifier>
[Glasgow] whitequark commented on issue #161: selftest loopback fails with USB EP8IN timeout - https://git.io/Jenxh
<_whitenotifier>
[Glasgow] whitequark closed issue #161: selftest loopback fails with USB EP8IN timeout - https://git.io/JeZob
ExeciN has joined #glasgow
<tnt>
whitequark: btw, just noticed, but the 1 Mbit EEPROM is a tad too small for a HX8k bitstream isn't it ?
<whitequark>
tnt: shit
<whitequark>
you're right of course... it was sized for up5k
<whitequark>
what's the size for hx8k?
<tnt>
5376 bytes too large.
<tnt>
136448 bytes total.
<tnt>
(this is from TN1248, I haven't actually checked files generated from icepack)
<daveshah>
Fine if you don't need initialised BRAM...
<whitequark>
unfortunately nmigen initializes all BRAM it uses
<whitequark>
just checked. hx8k bitstream overflows that flash by 0xfbb bytes.
<tnt>
24M02 I guess then
<whitequark>
myeah
<_whitenotifier>
[Glasgow] whitequark opened issue #164: FX2_MEM is too small, needs to use 24M02 instead of 24M01 - https://git.io/Jenho
<whitequark>
tnt: thanks. that would have been a very annoying issue to solve post production
<daveshah>
The loading is from the fx2? I wonder if you have enough code space for icecompr
<whitequark>
i don't think it's worth the added complexity
<whitequark>
i also bet iceuncompr is going to be hideously slow on the 8051
<whitequark>
it already takes something like 4 seconds to load the bitstream, i'm not going to take a hit that makes it 30 seconds instead
<marcan>
whitequark: whoops, yeah
<marcan>
that's a software-visible change, so revC2
<marcan>
however all revC1 units are upgradable with a part swap
<whitequark>
electronic_eel: btw, you are in fact relying on bitarray's conceptually broken endianness model
<marcan>
well, good excuse to make the various fixes that are remaining at the same time
<whitequark>
yeah
<marcan>
gotta document this stuff on the ECNs page
<marcan>
(there is no reason to buy a revC2 if you have a revC1, just swap the flash)
<marcan>
do we have a command that can upgrade revisions? just re-factory with the same serial?
<marcan>
incidentally, we've still done nothing with the ATECC
<marcan>
I really should give a shot at implementing all that
<marcan>
I'll put all this in the queue for after moving
<sorear>
today's free terrible idea: implement RLE decompression on the fx2 so that most bitstreams will fit
<marcan>
(the movers should be here any minute)
<marcan>
sorear: I mean, sure, but there are not enough C1s in the field and most people don't need that feature anyway
<whitequark>
marcan: yeah, re-factory
<whitequark>
sorear: 09:44 < whitequark> i don't think it's worth the added complexity
<marcan>
might as well just bump the flash
<whitequark>
it's clearly possible. i am also clearly uninterested in supporting it
<sorear>
ah, missed that
* tnt
already added 24M02 in my next mouser basket :)
<whitequark>
marcan: good news: the nmigen migration proceeds fairly smoothly
<whitequark>
i *think* i ironed out all relevant bugs
<whitequark>
in fact, one thing it enabled is bitstream caching!
<whitequark>
nmigen-constructed zip archives include sufficient environment info that i'm comfortable using them + yosys/nextpnr versions as cache key
<marcan>
ok, movers are here, I'm afk
gregdavill has joined #glasgow
<gregdavill>
I'm planning on ordering a few more Glasgow PCBs soon. Should I hold off until some designs are spun for revC2? or will it just be a component substitution?
<ZirconiumX>
<marcan> (there is no reason to buy a revC2 if you have a revC1, just swap the flash)
<ZirconiumX>
Based on this I'd say you can substitute the flashes, gregdavill, but WQ mentioned issues with ESD diodes
<tnt>
The ESD diode stuff is just DFM.
<tnt>
Basically remove some of the un-used pads footprints because they tend to short ...
<gregdavill>
Ahh okay, Gottcha. I think I'm on the same page now. :)
fridtjof[m] has quit [Read error: Connection reset by peer]
disasm[m] has quit [Read error: Connection reset by peer]
nrossi has quit [Read error: Connection reset by peer]
JJJollyjim has quit [Read error: Connection reset by peer]
cyrillu[m] has quit [Remote host closed the connection]
chocol4te has quit [Read error: Connection reset by peer]
jschievink has quit [Write error: Broken pipe]
chocol4te has joined #glasgow
cyrillu[m] has joined #glasgow
JJJollyjim has joined #glasgow
disasm[m] has joined #glasgow
fridtjof[m] has joined #glasgow
nrossi has joined #glasgow
jschievink has joined #glasgow
ExeciN has quit [Ping timeout: 240 seconds]
carl0s has joined #glasgow
ExeciN has joined #glasgow
gregdavill has quit [Remote host closed the connection]
gregdavill has joined #glasgow
uberushaximus has quit [Remote host closed the connection]
Exec1N has joined #glasgow
nicexe has joined #glasgow
ExeciN has quit [Ping timeout: 245 seconds]
nicexe is now known as ExeciN
<electronic_eel>
will just changing to 24M02 be enough? To me it looks like we'll then get an address clash with the fx2 mem
<electronic_eel>
the 24m02 needs one more bit for the memory addressing, so we can't use it to differentiate the address from the one of the fx2 mem anymore
<electronic_eel>
current address FX2_MEM: 1010001
<electronic_eel>
current address ICE_MEM: 101001X (with X being unavailable due to memory addressing)
<electronic_eel>
address ICE_MEM with 24M02: 10100XX
<electronic_eel>
so we also need to change the A2 address pin of the 24M02 to get 10101XX
<electronic_eel>
luckily the pad is left floating, so you just need to set a solder bridge when retrofitting. But a revC2 will need the pad be set to 3V3
<electronic_eel>
oh no, 10101XX conflicts with the ADCs
pg12_ has quit [Ping timeout: 276 seconds]
pg12_ has joined #glasgow
pg12_ has quit [Ping timeout: 245 seconds]
pg12_ has joined #glasgow
<electronic_eel>
ok, we can change the address of the ADC to 1011000 (port A), 1011001 (port B)
<electronic_eel>
this means changing ADR1 (pin 6) from gnd to 3v3 - you need to cut and rewire two traces when retrofitting
<electronic_eel>
then the 24M02 can use 10101XX
<electronic_eel>
but not all models of 24M02 are compatible, there seems to be a M24M02-DR from ST which uses the 4th bit for a special id page
<tnt>
electronic_eel: oh, nice catch :/
<electronic_eel>
yeah, seems like revC2 will not just be a part swap :(
<tnt>
The FX2 MEM is read at boot by the fx2 right ? That's why it needs to be a separate memory ?
<tnt>
But a single 24M02 and a tiny bit of adress shuffling to use 00, 10 and 11 for the bitstream data and '01' for the FX2 stuff would work right ? With a single combined eeprom.
<electronic_eel>
yes, it gets its config like usb ids and stuff from it
<electronic_eel>
I don't know the internals of the fx2
<tnt>
As far as the FX2 bootrom is concerned, it would simply access a I2C eeprim at 1010001 and not be aware that it's actually a zone inside a large 2 Mbits eeprom.
<electronic_eel>
yeah, I understood your idea. but don't know if will work that way
<tnt>
Then for every access for the ice_mem you just need to xor 0x20000 with the address you try to access.
<electronic_eel>
just scrolling through the datasheet to get an idea how it works
<tnt>
Looking at the random read command of a 24c256 or 24M02, they seem identical, just 2 address bits "hidden" in the device address.
<electronic_eel>
ok, the fx2 doesn't use a hardcoded i2c address to load the data from, it looks for a magic sequence at the start of the memory
<electronic_eel>
so I guess it tries different addresses that would match for eeproms and looks at the data it can read from them
<electronic_eel>
then we could indeed pull this off and embed the data/program for the fx2 in one eeprom
<electronic_eel>
do you know how the hard reset procedure works? you short a0 and a1 of the fx2 mem to get it
<electronic_eel>
trigger it I mean
<electronic_eel>
but why does this make the fx2 eeprom invisible on the bus?
<electronic_eel>
I fear I'm still missing some important bit here
<electronic_eel>
ah, you pull A1 of the fx2 eeprom up and this creates a address clash with the ice eeprom
<electronic_eel>
to emulate that we could probably create the address clash with the adc with a similar resistor pad, just for A2
<electronic_eel>
I need to leave now, let's see what whitequark says when she is back
<_whitenotifier>
[Glasgow] electroniceel commented on issue #164: ICE_MEM is too small, needs to use 24M02 instead of 24M01 - https://git.io/Jectx
uovo is now known as egg|egg
<whitequark>
electronic_eel: no, fx2 does in fact look for two hardcoded i2c addresses
<whitequark>
but i think putting fx2 data/program in one flash is perfectly viable
<whitequark>
i'm going to order a 24M02 and test
Exec1N has quit [Ping timeout: 245 seconds]
Exec1N has joined #glasgow
mwk has quit [Remote host closed the connection]
Exec1N has quit [Ping timeout: 240 seconds]
<_whitenotifier>
[Glasgow] whitequark commented on issue #164: ICE_MEM is too small, needs to use 24M02 instead of 24M01 - https://git.io/JecOG
karlyeurl has quit [Ping timeout: 265 seconds]
carl0s has quit [Remote host closed the connection]
<_whitenotifier>
[GlasgowEmbedded/Glasgow] whitequark pushed 2 commits to master [+0/-0/±2] https://git.io/Jec3T