jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<felix_>
azonenberg_work: using the coolrunner2 with the same bitstream, but different vccio on one bank probably works; at least the busblaster does exactly this. the io bank related bit might be the slew rate setting; at least that would sort-of correspond to the datasheet
<azonenberg_work>
for output
<azonenberg_work>
for input it probably selects different vt and maybe oxide thickness
<azonenberg_work>
i would not put 3.3 into a 1.8 input
<azonenberg_work>
otherwise its probably safe
azonenberg_work has quit [Ping timeout: 252 seconds]
<felix_>
even for the lvcmos18 io standard the datasheet says that the maximum rating for the input buffer is 3.9v
azonenberg_work has quit [Ping timeout: 240 seconds]
azonenberg_work has joined ##openfpga
<SolraBizna>
does yosys have an upper limit on the width of a reg?
azonenberg_work has quit [Ping timeout: 268 seconds]
wbraun has joined ##openfpga
<SolraBizna>
okay, it's probably bad connections
<Bob_Dole>
because you're using jumpers in the plated-through-holes instead of soldered header pins?
<SolraBizna>
basically, yeah
wpwrak has quit [Ping timeout: 245 seconds]
<SolraBizna>
four of the connections test good, two test bad, one tests ... ambiguous
<SolraBizna>
hey look, the three questionable connections were loose
<SolraBizna>
and now it works
wpwrak has joined ##openfpga
<SolraBizna>
...almost...
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 246 seconds]
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<SolraBizna>
my approach is clearly flawed, I can't get all signals to come through clear
<Bob_Dole>
if radioshack still existed, I would have a suggestion.
<Bob_Dole>
namely, the pins are an easy thing to solder. radioshack had cheap nice-enough irons and would probably have the header pins.
azonenberg_work has joined ##openfpga
azonenberg_work has quit [Ping timeout: 244 seconds]
Miyu has quit [Ping timeout: 240 seconds]
jevinskie has joined ##openfpga
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
bike has quit [Quit: Lost terminal]
_whitelogger has joined ##openfpga
<SolraBizna>
okay, now it's definitely not a bad connection, if I swap a known working port (clock) with a known not working port (strobe), it still works as well as it did before
rohitksingh has joined ##openfpga
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
jevinski_ has joined ##openfpga
azonenberg_work has joined ##openfpga
GenTooMan has quit [Quit: Leaving]
<SolraBizna>
my trivial shift register works in simulation and fails on real hardware
<SolraBizna>
it seems to latch the strobe input at CDONE and never respond to changes
<SolraBizna>
could someone with a real iCE40 UP5K try compiling my module with the proprietary tools and see if it functions?
<SolraBizna>
not sure why I specified "real" in that sentence
<SolraBizna>
With a pin of an Arduino Due, with lots of 100μs delays to make sure it's getting plenty of time to rise/fall
<whitequark>
what about debug_strobe?
<SolraBizna>
Everything works as I expect, except that whatever the value of `debug_strobe` is when CDONE rises is what it acts like it always is
<SolraBizna>
same
<whitequark>
are you toggling debug_clock and debug_strobe simultaneously?
<whitequark>
i.e. PORTA |= 0x3 or something
<SolraBizna>
I write 1 to debug_strobe, wait 100μs, write 1 to debug_clock, wait 100μs, write 0 to debug_clock, wait 100μs, and only then write 0 to debug_strobe
<whitequark>
hrm
<whitequark>
that's weird
<SolraBizna>
I tried a delay as long as 1ms with no change (I assumed that it would be pointless to try longer delays)
<whitequark>
yes
<SolraBizna>
I tried manually instantiating SB_IOs with and without various extra levels of clocking/enabling to no change, I checked and triple-checked that all of the signals are being inputted and outputted correctly (to the extent that I can without an oscilloscope)
azonenberg_work has left ##openfpga [##openfpga]
azonenberg_work has joined ##openfpga
<SolraBizna>
my three strongest hypotheses: I've done something fundamentally wrong or weird in my Verilog (p≈0.6); the UPDuino has some kind of freak electrical issue that causes this exact problem (p≈0.2); I've found some kind of really obscure bug in yosys or arachne-pnr (p≈0.2)
<whitequark>
try this
<whitequark>
add a reset to your design
<whitequark>
asynchronous
<whitequark>
(since debug_strobe is already a sync reset)
<whitequark>
whatever happens might be insightful
<whitequark>
but no, i don't see it either
<SolraBizna>
with an `always @(reset)` block?
<whitequark>
@(posedge clk or negedge reset)
<whitequark>
is the usual incantation
<whitequark>
and then if(reset)
<whitequark>
if(!reset) rather
<whitequark>
wow, i haven't written verilog for so long i forgot how pointlessly tedious most of the basic things in it are.
<SolraBizna>
I swear I tried that 30 seconds ago and yosys complained
<SolraBizna>
with an asynchronous reset, "reset, strobe, read lots of bits" gives me the asynchronous reset value, a few dozen shifted-in ones, and then out of nowhere the BEEF
<whitequark>
iiiinteresting
<whitequark>
that virtually rules out a toolchain issue
<SolraBizna>
I think I left a long strobe pulse in there somewhere
<whitequark>
i looked at the rtl yosys generated
<whitequark>
for your design without async reset
<whitequark>
it is sane
<SolraBizna>
I would have been very very surprised otherwise
<whitequark>
it seems very unlikely that pnr would fuck up in that exact way
<whitequark>
it sounds like you have a glitch on the strobe
<whitequark>
try this
<SolraBizna>
Something this basic should be sane or surely complex modules would fail and... that would be noticed
<whitequark>
synchronize the strobe to the debug clock domain
<whitequark>
two FFs, as usual
<whitequark>
it doesn't seem like there should be metastability, but hey, worth a try
<SolraBizna>
I did leave a long second strobe in there, and the BEEF is showing up at exactly the expected offset relative to that
<SolraBizna>
(It wasn't before)
<SolraBizna>
I don't completely understand your suggestion
<whitequark>
so, does it work now?
<SolraBizna>
now that there's an asynchronous reset, a long train of clocks with strobe high is having the expected effect
<whitequark>
that's interesting
<SolraBizna>
there has to be something spooky going on electrically
<SolraBizna>
it has plenty of chances... all of these pins Arduino-side are nominally analog inputs, and the quality of the connection to the UPDuino is... less than stellar
<SolraBizna>
(don't know if you saw the photo of my hideous test rig earlier)
<whitequark>
it could be, but it still seems weird to me
<whitequark>
i've had far more hideous test rigs work well
<SolraBizna>
I modified my strobefunction to have a long chain of clocks with strobe high, and now there is no BEEF
<SolraBizna>
it's gonna turn out to be something stupid like I'm never actually calling the strobe function, isn't it
<whitequark>
yes
<SolraBizna>
...I never actually called the strobe function
<whitequark>
most likely
<whitequark>
what
<whitequark>
incredible
<SolraBizna>
I have been spoiled by `-Wall -Werror`...
<SolraBizna>
I'm having to use the "batteries extremely included" Arduino IDE for the Arduino side of this, and it not only doesn't support `-Wall` but it even turns off some warnings that default on
<SolraBizna>
thanks for your help
<SolraBizna>
(that was a great way to waste a day chasing wild geese >_<)
<SolraBizna>
I'm still confused about the BEEF not showing up even when I added those extra edges...
<Bob_Dole>
thought the meme was DEADBEEF
<SolraBizna>
DEAD was the value that the asynchronous reset set it to :P
<whitequark>
lol
<travis-ci>
whitequark/Glasgow#141 (master - a08dd2b : whitequark): The build has errored.
hackkitten has quit [Read error: Connection reset by peer]
hackkitten has joined ##openfpga
wbraun_ has joined ##openfpga
eddyb has quit [Ping timeout: 252 seconds]
wbraun has quit [Ping timeout: 272 seconds]
wbraun_ is now known as wbraun
eddyb has joined ##openfpga
eddyb has quit [Changing host]
eddyb has joined ##openfpga
eddyb has joined ##openfpga
Bike has joined ##openfpga
wbraun has quit [Quit: wbraun]
jevinski_ has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<daveshah>
I've modified ecppack to generate an SVF file directly, this gets rid of the Python script to do this. Now the time from Verilog to programmed ECP5 blinky is 3.6 seconds
<daveshah>
I'm pretty happy with that result
<whitequark>
niiiice
<whitequark>
pushed?
<daveshah>
yes, to master
<sorear>
how much of that 3.6s is programming?
<daveshah>
Not much - about 0.7s or so
* sorear
notes that JTAG is just about the slowest way to get a bitstream onto an ecp5 chip
<daveshah>
hardly matters for anything non-trivial though
<daveshah>
will be well dominated by build time
<sorear>
nah that just means your build tools are too slow :P
<daveshah>
whitequark: been playing about with Yumewatari with my Jetson TX2 board (easiest way to get a PCIe port on my desk)
<daveshah>
Had to set `p_CH0_REQ_EN = "0b1",` to get it to work more reliably
<daveshah>
I think this enables Rx equalisation
<daveshah>
But now I am seeing the green TS-FOUND LED blinking!
<whitequark>
nice!
<whitequark>
wait
<whitequark>
blinking?
<daveshah>
the tegra pcie seems a bit cursed
<daveshah>
but it seems as if it keeps retrying after failing to find a device
<whitequark>
interesting, it's lit up continuously over here
<daveshah>
I think there's a signalling issue going on
<whitequark>
guess it doesn't think that transmitting IDLE in response to TS1 is valid
<whitequark>
could be
<daveshah>
it's stopped working altogether now
<whitequark>
well
<whitequark>
I need to start transmitting TS1 myself
<whitequark>
until then it's perfectly legit for the RC to refuse to enable the port
<whitequark>
I'm currently writing some tests for RX FSM and stuff
<whitequark>
will take some time...
<daveshah>
sure
s_frit has joined ##openfpga
* cr1901_modern
googles PCIe spec... well, at least it's available through a Google search nowadays
<cr1901_modern>
Pretty sure my copy is from that Bay site back in 2011 (and just sat there all that time)
<sorear>
you want "PCI Express® Base Specification Revision 3.0" and "PCI Local Bus Specification Revision 3.0" (or other versions)
<cr1901_modern>
sorear: While I'm glad another FOSS OOO impl of riscv exists, I really wish they would do it in a language I'm familiar with (Migen, Verilog). I don't have it in me mentally to fight both having to understand the nuances of OOO and Yet Another DS-HDL
<whitequark>
migen might well not be powerful enough for an ooo core
<whitequark>
verilog is definitely not
<cr1901_modern>
I've seen a MIPS OOO core in Verilog before, and looks like there's a second one.
<sorear>
verilog is good enough for ARM, just not for me
<sorear>
this is what MIT and MIT-originated orgs use for just about everything… much less popular outside
<sorear>
no free tooling
<cr1901_modern>
It probably is great for what it's designed for. I'm happy with my "subset of Verilog with most of the gotchas removed-generator" for now :P. Also, I love migen's build system.
<cr1901_modern>
or build generator*/whatever you want to call it
Miyu has joined ##openfpga
<cr1901_modern>
The hell is a gearbox?
<daveshah>
Something that transforms data width and clock rate while keeping the width-frequency product constant
<daveshah>
e.g. 4 bits 100MHz to 1 bit 400MHz
<daveshah>
it's a term that Lattice like in particular
<cr1901_modern>
Oh, so like the 4-bit LPC ISA bus running at 33.33 MHz
<cr1901_modern>
convert to 16-bits at 8.whatever MHz
<daveshah>
yeah, sounds like that sort of thing
whitequark is now known as lamp
lamp is now known as whitequark
<q3k>
gearbox is a pretty clever name once you consider the speed/torque <-> frequency/width allegory ^^
<cr1901_modern>
whitequark is now an outdated server software bundle
<whitequark>
ye
* cr1901_modern
will see himself out
<sorear>
daveshah: how about you, strong feelings on bsv
<daveshah>
never looked at it
m4ssi has joined ##openfpga
jevinskie has joined ##openfpga
<whitequark>
daveshah: :S
<whitequark>
nextpnr is not fast enough for this
<whitequark>
without a gearbox
<whitequark>
i tried and the logic it synthesizes actually fails very badly
<whitequark>
i am guessing that's the blinking you have observed, btw
<whitequark>
i made the fsm proper and now it almost always synthesizes a broken bitstream
<whitequark>
used to just glitch constantly
<gruetzkopf>
don't the serdes blocks have a 16bit half-rate mode?
<gruetzkopf>
integrated gearbox
<sorear>
yes
<sorear>
but the logic needs to work at 250MHz to support 5 GT/s operation @ 16bit
<whitequark>
gruetzkopf: also it's a pain in the ass to do 1:2 gearbox mode
<whitequark>
software wise
<whitequark>
i want to get 1:1 FSMs working first
<whitequark>
sharing logic between 1:1 and 1:2 FSMs plus word alignment is *not* trivial
<sorear>
if the FSM can't do 250mhz you may need 1:4 gearboxing
<whitequark>
it can, with diamond
<whitequark>
also i don't do Gen2
<whitequark>
i haven't even read the Gen2 spec yet
<sorear>
right, I assumed that was a future plan though
<whitequark>
i have literally never touched a serdes until before two days ago.
<whitequark>
do you expect me to plan for gen2 right now lol
<cr1901_modern>
yes :P
* whitequark
stabs cr1901_modern
* cr1901_modern
collapses in a nearby bush... don't mind me, just dying here
<qu1j0t3>
wow
<sorear>
yes, because I plan every project several years farther than necessary and I'm not the best at remembering how other people work differently
<whitequark>
i use literally adhd-driven development
<whitequark>
why do you think i moved on from floppies to pcie?
<whitequark>
shiny~
<qu1j0t3>
whitequark: I don't think you're the only one...
<gruetzkopf>
also your best plan of getting something implemented
<whitequark>
moving from floppies to pcie?
<cr1901_modern>
bahaha
<gruetzkopf>
is telling whitequark it exists and that you might do it in the far future
* cr1901_modern
is working on a "secret" project that is actually going well, and so as to not jinx this and lose interest, will not elaborate right now.
<whitequark>
gruetzkopf: lol
<whitequark>
the second part is optional, really
<sorear>
is it weird that I'm both very distractable AND spend far more time mapping out possible futures for projects than actually working on them
<gruetzkopf>
not really
<qu1j0t3>
cr1901_modern: ha! relateable
<cr1901_modern>
qu1j0t3: I'll announce it "when it's done", or alternatively "when I've made enough progress that I won't feel bad if I need to step back"
* qu1j0t3
nods
<cr1901_modern>
most certainly the latter will happen
<daveshah>
whitequark: yeah, 250MHz is ambitious at the moment
<daveshah>
with proper timing data and clifford's improved router things might get a bit better
<whitequark>
okay
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<SolraBizna>
PCIe over floppy disks when?
<gruetzkopf>
more like the other way around
<gruetzkopf>
and i'd say with glasgow-E at the latest?
<cr1901_modern>
128b130 floppy disks with multi-track drifting capable-drives. Just remove the erase heads on the sides.
lovepon has joined ##openfpga
<SolraBizna>
when I was a tiny human, I was really pissed at my father for buying System 7.5 on CD
<SolraBizna>
I had been looking forward to floppy swapping during the install process
<SolraBizna>
so, give me floppy-swapping-based peripherals or give me death!
<Bob_Dole>
SolraBizna, wasn't I talking about you doing something with floppy for your retro ARS?
<SolraBizna>
floppies are suddenly too analog for me again
<Bob_Dole>
lol
<Bob_Dole>
I wonder how much data you can fit on a VHS if you're putting data, rather than data-encoded-as-video, directly onto the tape..
<gruetzkopf>
iirc D-VHS is around 12G/tape?
<Bob_Dole>
oh, I've mostly seen things getting 1-2GB with the data recorded as basically QR-Codes in each frame, to regular vhs players
<Bob_Dole>
that's a fair bit better
<sorear>
there's a certain bandwidth in MHz
<gruetzkopf>
D-VHS stores MPEG2 video at around 15MBit/s
<gruetzkopf>
15MBit/s on a 8h tape
<gruetzkopf>
i have seen software that could write backups to D-VHS via IEEE1394
<sorear>
very high SNR analog communication is weird to me
<cr1901_modern>
I wouldn't have figured the a VHS drum head had 15 MHz b/w
<cr1901_modern>
that a* VHS drum head
<SolraBizna>
I thought it was more like 2MHz
<SolraBizna>
not enough for a full-bandwidth NTSC or PAL signal
<cr1901_modern>
4.5 MHz for NTSC
<gruetzkopf>
S-VHS and D-VHS tapes have higher bandwidts
<SolraBizna>
ah
<gruetzkopf>
if i get a DVHS recorder i'm SOO throwing AV1 into that mpeg ts
<gruetzkopf>
4k VHS
<Bob_Dole>
apparently D-VHS had a standard for up to 28.2MBit/s, looking it up,and tapes available up to 50GB
wbraun has joined ##openfpga
<SolraBizna>
route time 596.65s
<sorear>
how much is public about the "clifford's improved router"?
<daveshah>
it's not secret
<daveshah>
not that I know anything more about it
<q3k>
sorear: it's rewritten and being smoketested, iirc
<SolraBizna>
please talk me out of making a redstone driver for nextpnr
<whitequark>
pls no
<Bob_Dole>
wat
<SolraBizna>
well, that was easy
<q3k>
also i just made a more human-friendly ulx3s foss starter project, because i don't like the code out there and i'm tired of copying my own stuff around
<gruetzkopf>
hehe, i have a minecraft mod that i could revive
<gruetzkopf>
that adds multi-wire buses and stuff like MUX, LUT4, ..
<q3k>
no
<SolraBizna>
I started writing one of those
<SolraBizna>
I came to my senses before getting too far, thank goodness
<q3k>
gruetzkopf: does it replicate the iCE40 structures?
<q3k>
gruetzkopf: i would like to run my bitstreams in minecraft TYVM
<gruetzkopf>
nah this was before i learned about FOSS PLD flows
<gruetzkopf>
which is also why i never got it to a publishable state
<cr1901_modern>
r2 of the hardware world? Please, give prjtrellis more credit :)
<galv[m]>
Why is prjtrellis seemingly more popular on this channel than prjxray? Are Xilinx's FPGAs just that much more complicated than Lattice's?
<q3k>
daveshah: updated, thank you!
<q3k>
galv[m]: you mean, development wise?
<sorear>
galv[m]: because prjxray hasn't had a public update of any kind in months
<q3k>
galv[m]: 7 series are more complex and complicated, yes
<cr1901_modern>
I also find altera FPGAs (for the most part) very notably ignored not only in this room, but in FOSS FPGA work period.
<cr1901_modern>
Err Intel*
<q3k>
daveshah: are you working on ECP5 IOBUF placement?
<galv[m]>
I guess I am just surprised since prjxray is a couple of months older than prjtrellis as far as I know. By the way, the prjxray database was recently updated (two weeks ago?) with either BRAMs or DSP blocks.
<q3k>
daveshah: (as in, automatic IOBUF placement for design ports)
<sorear>
galv[m]: yeah, someone is updating the repo, but nobody is talking about it and nobody is obviously working on pnr
<sorear>
galv[m]: while there is a working pnr flow for ecp5 *today*
<Bob_Dole>
Altera FPGAs seemed like they used to be popular several years ago, with the Spartan 6s at least completely shoving all the cyclones aside, and then artix 7 stuff suddenly becoming the thing everyone was most interested in, until the ice40s got a FOSS toolchain. and now with ECP5s rapidly progressing..
jevinskie has joined ##openfpga
<Bob_Dole>
I didn't actually realize Spartan 7s were a thing, from how little people were talking about anything but Artix 7s, until kinda recently
<sorear>
spartan 7 = XP
<sorear>
s7 is more closely related to v6 than it is to s6, s6 is technologically the end of the line
<whitequark>
XP?
<sorear>
whitequark: Windows NT 5.1
<whitequark>
ah
<daveshah>
q3k: done
<daveshah>
about a week ago
<daveshah>
there's a LPF parser and IOBUF insertion now
<q3k>
daveshah: oh heh
<q3k>
daveshah: i didn't notice that. i am using the LPF parser
<azonenberg_work>
wait waht?
<azonenberg_work>
s7 is just an artix sans transceivers
<q3k>
daveshah: so I can just place LPF constraints on the port names?
<azonenberg_work>
in fact i think some of the s7s are literally s6 dies
<daveshah>
q3k: yup
<azonenberg_work>
sorry i eman
<azonenberg_work>
some of the s7s are a7 dies
<azonenberg_work>
without the gtps bonded
<whitequark>
huh
<azonenberg_work>
basically s6 LX's successor is s7
<azonenberg_work>
s6 LXT's successor is a7
<azonenberg_work>
high end v6's successor is v7
<azonenberg_work>
low end v6's successor is k7
<gruetzkopf>
so flash a a7 bitstream that uses GTP in loopback mode and it should work?
<azonenberg_work>
the one exception to this rule is that s7 was not originally planned, so some of the low pin count a7 packages dont have the gtps bonded
<azonenberg_work>
gruetzkopf: lol. if you have the right die quite possibly
<azonenberg_work>
sec, let me check notes
<azonenberg_work>
so, 7s25 is 9,934,432 config bits
<azonenberg_work>
and has idcode x37C4093
<azonenberg_work>
7a25t is 9,934,432 bits and has idcode x37C2093
<sorear>
feed in the signal via EMI or power coupling? :3
<azonenberg_work>
7a12t, already known to be a fused 25t, is 9,934,432 bits and has IDCODE x37C3093
<azonenberg_work>
Doesn't take a genius
* gruetzkopf
checks prices
<azonenberg_work>
gruetzkopf: the 7s50 looks to be a 7a50t die as well
<azonenberg_work>
the 7s75 is a fused 7s100, but not the same die as the 7a75/100
<azonenberg_work>
the 7s6 is a fused 7s16
<azonenberg_work>
But also not shared silicon with artix
<daveshah>
I am fairly sure from the pinout files Lattice provide that the ECP5s "without a SERDES" even have the SERDES bonded
<daveshah>
but I'm also pretty sure that the SERDES yields aren't great so it's almost certainly out of tolerance
<azonenberg_work>
daveshah: so its a post package change?
<azonenberg_work>
and interesting, would be fun to try one to see :p
<daveshah>
yes, I think it's just an efuse to change the IDCODE
<daveshah>
I don't have any boards with a no-serdes ecp5 but the serdes broken out atm
<azonenberg_work>
also interesting to note, the 7s6/15 die has no xadc
<whitequark>
so they specify every single serdes?
<daveshah>
they would have to
<whitequark>
that must be a real pain
<sorear>
what does "specify" mean here?
<whitequark>
qualify
<daveshah>
there's a reason they sell both 3g and 5g parts too
<whitequark>
daveshah: try newer yumewatari
<whitequark>
it crashes nextpnr btw
<whitequark>
cannot route tx_clk
<whitequark>
seems it gets confused by an unloaded clock that just loops back to serdes
<daveshah>
I think there are some issues with SERDES clock routing, I'll see if I can sort that tomorrow
<whitequark>
sweet
<daveshah>
they might fix the timing problems too
<whitequark>
oooooooh
<daveshah>
it looked like it was routing the rx refclk out of the refclk primitive into fabric and back to the serdes
<whitequark>
oh.
<daveshah>
rather than straight into the serdes via the proper dedicated path
<whitequark>
I wonder why is the RC sending PAD in place of link number
<whitequark>
in theory it shouldn't do that, but I don't feed it TS1 which is why it might do that
<whitequark>
anyway, other than the blinking, it seems good
<whitequark>
it clearly goes through the entire state machine at least sometimes
<daveshah>
when not valid, I also seem to see ts.n_fts as 0x1f
<whitequark>
that's ok
<daveshah>
I did patch the kernel to stop it just turning off
<whitequark>
when not valid, the rest of the data can be junk
<daveshah>
it is quite fussy about pcie devices
<whitequark>
i tried to optimize the FSM for speed
<whitequark>
so it doesn't care about data in fields when valid is deasserted
<whitequark>
that said, it is still validating almost everything that the spec has
<daveshah>
sound good
<whitequark>
so that sounds like SERDES routing issue indeed
<whitequark>
not so much RX FSM
<daveshah>
this is with diamond btw
<whitequark>
wait, it's still blinking with diamond?
<whitequark>
mhmmmmm
<whitequark>
ok, let me just make the TX FSM
<whitequark>
what i'm doing right now is super not compliant
<whitequark>
it's allowed to do that
<daveshah>
I'm probably not going to test anything more tonight anyway
<daveshah>
so no rush
<whitequark>
I was going to do it anyway
<daveshah>
my only experiences with the tx2 have been a) cursed b) involved a lot of hacking poor quality kernel code
<whitequark>
wonderful
<daveshah>
so I'm not worried about this failing
<whitequark>
sounds exactly like nvidia
<whitequark>
actually, i think all nvidia socs are just fucked, period
<whitequark>
their gpus at least seem to work ok
<daveshah>
is there a non-cursed way to get PCIe on your desk with AMD so no TB?
<whitequark>
um. yes.
<daveshah>
this is a desktop too
<whitequark>
intel tbt card
<whitequark>
it has a GPIO header that switches it between DP/TBT/USB mode
<whitequark>
I think you can simply jumper it
<whitequark>
then you'll need to do echo 1|sudo tee /sys/bus/pcie/rescan
<whitequark>
a lot
<whitequark>
because the thunderbolt people can't into pcie hotplug
<Bob_Dole>
what
<daveshah>
it seems this is a lot more cursed on AMD though
<whitequark>
this is incredibly cursed but if you go for that i will assist you because i've spent enough time with this piece of shit stack
<whitequark>
i'm like 80% sure it will work
<whitequark>
worst case just return the card.
<sorear>
> Transmitter sends TS1 Ordered Sets with Lane and Link numbers set to PAD on all Lanes that detected a Receiver during Detect.
<whitequark>
sorear: which section?
<sorear>
4.2.6.2.1 (in rev 3.0)
<whitequark>
I thought only downstream ports send PAD/PAD
<whitequark>
erm
<whitequark>
upstream
<whitequark>
downstream ports send link/PAD and then link/lane
<Bob_Dole>
I think TB has proprietary bits that intel won't license to AMD, but someone from Level One Tech was able to just copy over some of the UEFI blobs to and AMD system with one of the TB expansion cards meant to go on intel motherboards and got it working on a Threadripper system at least
<whitequark>
who even needs the UEFI blobs?
<whitequark>
the ACPI shit it uses is boneless
<daveshah>
I'm not keen on copying UEFI blobs on my dev workstation
<daveshah>
this is why I was hoping I could get the TX2 working, tbh
<whitequark>
you can replace the four hundred lines of ACPI shit it uses with a one line kernel module at *worst*
<daveshah>
keep things separate
<gruetzkopf>
the ACPI stuff they use should have been done with normal pcieport messages
<whitequark>
daveshah: actually!
<whitequark>
daveshah: if you give me money for the TBT3 card i will set it up for you
<whitequark>
lik
<whitequark>
i will plug it into my TBT3 external box
jevinski_ has joined ##openfpga
<whitequark>
yo dawg i heard you like thunderbolt
<emily>
whitequark: can the xps 13 do like, nvidia optimus type stuff with the external GPU but an internal display (using the intel card to present the frames etc.)
<whitequark>
emily: yes, that's how i play tf2
<whitequark>
i told optimus to not do any PM
<gruetzkopf>
that even works with my terrible adapter
<whitequark>
and the rest is basically default optimus settings
<emily>
whitequark: cool
<gruetzkopf>
and DRI_PRIME
<whitequark>
i never got PRIME to work with ATI cards
<emily>
whitequark: I wonder if that can work with KVM PCI-e passthrough stuff :D
<whitequark>
shit would just hang my kernel
<emily>
for a windows VM
<q3k>
i'm considering buying one of those expresscard/PCIe adapters
<whitequark>
yes
<q3k>
and plugging my xeon phi into my x230
<whitequark>
KVM PCIe passthrough just works usually
<whitequark>
you need some minor hacks for vga
jevinskie has quit [Ping timeout: 252 seconds]
<q3k>
because it has a less fucked up BIOS than my workstation
<whitequark>
get the blob then feed it to qemu
<whitequark>
vbios
<daveshah>
OK, seems the gigabyte card works fine on threadripper
<emily>
like, you can play games from a windows VM on the internal screen?
<daveshah>
Can't seem to assign you for some reason
<q3k>
you might need to add me as a contributor
<q3k>
anyway, i first need to yakshave
<q3k>
need to measure whether pll works -> need scope on desk -> need to clear desk -> {need to move workstation, need to move network gear -> need to run network cable to network closet, need to reassemble thinkpad}
<q3k>
so don't hold your breath :P
<daveshah>
invite sent
<q3k>
assigned myself, thanks
jevinski_ has joined ##openfpga
jevinskie has quit [Ping timeout: 252 seconds]
m4ssi has quit [Remote host closed the connection]
m4ssi has joined ##openfpga
m4ssi has quit [Remote host closed the connection]
azonenberg_work has quit [Ping timeout: 246 seconds]
<kc8apf>
Re: prjxray; those working on it tend to just submit stuff to the repo. Not a lot of discussion on here.