whitequark[cis] changed the topic of #glasgow to: https://glasgow-embedded.org · digital interface explorer · https://www.crowdsupply.com/1bitsquared/glasgow · code https://github.com/GlasgowEmbedded/glasgow · logs https://libera.catirclogs.org/glasgow · matrix #glasgow-interface-explorer:matrix.org · discord https://1bitsquared.com/pages/chat
meklort has quit [Ping timeout: 252 seconds]
remexre has quit [Ping timeout: 252 seconds]
remexre has joined #glasgow
vup has quit [Ping timeout: 252 seconds]
vup has joined #glasgow
meklort has joined #glasgow
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
redstarcomrade has joined #glasgow
Fridtjof has quit [Quit: ZNC - http://znc.in]
Stary has quit [Quit: ZNC - http://znc.in]
Stary has joined #glasgow
Fridtjof has joined #glasgow
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
<_whitenotifier-5> [glasgow] whitequark commented on pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866#issuecomment-2918271902
<whitequark[cis]> l0rds474n: I have confirmed the Windows issue to happen on my side too
redstarcomrade has quit [Read error: Connection reset by peer]
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
<whitequark[cis]> okay, I tracked down the cause
<WilfriedWonkaKla> that was fast...
<whitequark[cis]> fast? it took me over a hour
<whitequark[cis]> I had to get ETW for Windows and Netmon with USB parsers out
<whitequark[cis]> turns out Windows sends a Set Interface request (that crashes the device before FPGA is configured) on configuration, while Linux only does this when you claim the interface
<_whitenotifier-5> [glasgow] whitequark opened pull request #869: Fix firmware crash during enumeration on Windows - https://github.com/GlasgowEmbedded/glasgow/pull/869
<_whitenotifier-5> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-869-b044794921880866cddb290e99e99d276d4862fb - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-5> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 3 commits to main [+0/-0/±3] https://github.com/GlasgowEmbedded/glasgow/compare/b04479492188...b092d6a1057d
<_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark 436b7cb - firmware: fix altsetting management (-22 bytes XRAM).
<_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark f67e293 - firmware: fix variable names. NFC
<_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark b092d6a - firmware: don't access FPGA if it isn't ready. (-21 bytes XRAM)
<_whitenotifier-5> [glasgow] whitequark closed pull request #869: Fix firmware crash during enumeration on Windows - https://github.com/GlasgowEmbedded/glasgow/pull/869
<_whitenotifier-5> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-869-b044794921880866cddb290e99e99d276d4862fb - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-5> [glasgow] whitequark opened pull request #870: support.endpoint: treat -ECONNRESET as disconnection - https://github.com/GlasgowEmbedded/glasgow/pull/870
<_whitenotifier-5> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-870-b092d6a1057d8ba6d93e209022219eca357b20bb - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-5> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/b092d6a1057d...80fe431d3096
<_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark 80fe431 - support.endpoint: treat -ECONNRESET as disconnection.
<_whitenotifier-5> [glasgow] whitequark closed pull request #870: support.endpoint: treat -ECONNRESET as disconnection - https://github.com/GlasgowEmbedded/glasgow/pull/870
<_whitenotifier-5> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-870-b092d6a1057d8ba6d93e209022219eca357b20bb - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
<_whitenotifier-5> [glasgow] whitequark synchronize pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #glasgow
<whitequark[cis]> zyp: so... i'm thinking i should implement SWO support in Glasgow
<whitequark[cis]> it looks like there's going to be a nontrivial amount of overlap between orbtrace and glasgow
zyp[m] has joined #glasgow
<zyp[m]> sounds like it
<whitequark[cis]> if i export SWO data via a socket, orbuculum can consume it, right?
<zyp[m]> yes
<whitequark[cis]> i should do that then
<whitequark[cis]> i've never actually looked at orbuculum, it seems neat from the landing page
<whitequark[cis]> (i've also never used SWO)
<whitequark[cis]> but beyond that, i think this is a good opportunity to advance some things in Amaranth; stream-related stuff is one, but i'm also thinking about implementing a HyperRAM controller for Glasgow
<whitequark[cis]> it looks like you're using the LiteX one, so that's something you could get rid of
galibert[m] has joined #glasgow
<galibert[m]> Is there a timeline for the HyperRAM extension?
<whitequark[cis]> gateware or hardware?
<galibert[m]> hardware
<whitequark[cis]> it's not up to me
<galibert[m]> I don't have to skills to build one myself
<galibert[m]> Yeah, but you could have heard
<whitequark[cis]> i think you might be able to pay JLCPCB or something
<whitequark[cis]> lemme check
<galibert[m]> Given I have no urgency I'd rather pay 1bitsquared
<zyp[m]> whitequark[cis]: I've been meaning to switch to the luna one
<whitequark[cis]> i'd like to upstream the one i'm developing for glasgow
<zyp[m]> orbtrace is designed to make use of DDRX2 primitives to run the hyperram at 200MHz
<whitequark[cis]> oh, i see
<zyp[m]> as well as reusing the DQS primitives in the FPGA to handle the data strobe
<zyp[m]> the litex implementation doesn't make use of that, relies on phase shifted PLL outputs instead, but the luna implementation does
<whitequark[cis]> the design i'd like to build would rely on a (much improved version of) IOStreamer
<whitequark[cis]> so the controller would form x waveform samples per cycle, the device-independent part would handle backpressure and latency, and the device-dependent part would handle instantiating the buffers
<whitequark[cis]> but i don't know if this generic design is flexible enough for what you want
<_whitenotifier-5> [glasgow] whitequark commented on pull request #742: access.direct.demultiplexer: add ability for applets to override default USB transfer settings. - https://github.com/GlasgowEmbedded/glasgow/pull/742#issuecomment-2918975431
f_ is now known as f_|AWAY
f_|AWAY is now known as f_
<whitequark[cis]> zyp: you might be interested in the Tiliqua design
<whitequark[cis]> afaik it does something similar for HyperRAM, and it will probably be more modern than the LUNA one
<zyp[m]> afaik Tiliqua is also using the luna hyperram core
<whitequark[cis]> ahh I see
ari has quit [Ping timeout: 272 seconds]
<_whitenotifier-5> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-866-80fe431d3096b1516e53df14ecb8cd1d9f22303b - https://github.com/GlasgowEmbedded/glasgow
vk2seb[m] has joined #glasgow
<vk2seb[m]> Its very similar. The main changes are A) to fix some timings bugs to do with the byte select lines and B) refactor the core so that it can work with both HyperRAM and pin-compatible oSPI-RAM
<vk2seb[m]> It can run at full speed in both scenarios, so 200MHz is good but also 240MHz with timing violations (480Mbyte/sec)
<zyp[m]> which memory chips are you using that's rated for 240 MHz?
ar has joined #glasgow
<vk2seb[m]> It's not rated for that but I tested it to that speed before the memtest started failing:D
<zyp[m]> fair enough :)
<vk2seb[m]> APS256XXN. It also has a 16-bit mode for 800Mbyte/sec (which I'm not using)
<_whitenotifier-5> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-866-80fe431d3096b1516e53df14ecb8cd1d9f22303b - https://github.com/GlasgowEmbedded/glasgow
<_whitenotifier-5> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 7 commits to main [+3/-0/±17] https://github.com/GlasgowEmbedded/glasgow/compare/80fe431d3096...2cc6f500c6d1
<_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark 6c0ea8d - support.endpoint.ServerEndpoint: allow attaching to a pipe.
<_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark 9e177d8 - software: allow detaching pipes.
<_whitenotifier-5> [GlasgowEmbedded/glasgow] whitequark d07037b - hardware.assembly: allow bypassing IN/OUT FIFOs.
<_whitenotifier-5> [GlasgowEmbedded/glasgow] ... and 4 more commits.
<_whitenotifier-5> [glasgow] whitequark closed pull request #866: Add an applet for debugging via probe-rs - https://github.com/GlasgowEmbedded/glasgow/pull/866
ari has joined #glasgow
ari has quit [Ping timeout: 244 seconds]
ari has joined #glasgow
stary[m] has quit [Quit: Idle timeout reached: 172800s]
miek__[m] has quit [Quit: Idle timeout reached: 172800s]
benny2366[m] has quit [Quit: Idle timeout reached: 172800s]
fridtjof[m] has quit [Quit: Idle timeout reached: 172800s]
GNUmoon has quit [Remote host closed the connection]
GNUmoon has joined #glasgow
altracer[m] has joined #glasgow
<altracer[m]> and that ends up cheaper and easier than DDR3L-1066 bank of 16-bit DRAM which is good for 2Gbyte/s? Or there's a PHY reason?
<vk2seb[m]> For my use case I had to fit everything in 2x2cm, so 8-bit bus was necessary for routing reasons. Probably LPC-DRAM would serve similar constraints well
<vk2seb[m]> Sorry RPC not LPC, I am remembering the acronym wrong
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Changing host]
ali_as has quit [Remote host closed the connection]
ali_as has joined #glasgow