03:21 <duskwuff[m]> Finally getting back to the 25x thing. whitequark (@_discord_182174208896401419:catircservices.org): I think you got the pin order backwards in commit 97f8db87; I had to explicitly pass in `--pin-cs=0 --pins-io=3,1,2,5 --pin-sck=4` to connect to a device that was working with the default mapping before the QSPI migration.

03:25 <duskwuff[m]> Or was it backwards before and this fixed it?

09:38 <whitequark[m]> that seems rather unlikely

09:38 <whitequark[m]> I think it might've been backwards before, my bad

09:58 <js[m]> I also had the impression it's backwards now

09:58 <js[m]> what should have been 1,3,6,7 for me actually needed to be 3,1,6,7

09:58 <whitequark[cis]> hm

09:59 <whitequark[m]> so the QSPI controller's pinout is COPI,CIPO,WP#,HOLD#

10:00 <whitequark[m]> this seems to me to be exactly right wrt the pinout

10:01 <urja> previous memory-25x is CS,CIPO,WP,COPI,SCK,HOLD

10:02 <whitequark[m]> the pinout *did* change wrt previous memory-25x pinout, which is a breaking change, but since the arguments changed as well I decided that that's fine (since there is no way you could e.g. destroy the flash by using an old command line)

10:03 <urja> ah yeah QSPI is D0, D1, D2, D3, essentially, while previous is going around the chip

10:03 <whitequark[m]> the old pinout was intended for easy use with the SOIC clips, but i think that never really quite worked out

10:03 <whitequark[m]> for one the SOIC clips are kind of awful to use

10:05 <urja> Oh yeah, i did personally implement the output driver enable/disable (only affects CS with glasgow, but still) for spi-flashrom, i guess i'll need to look at that again wrt the QSPI controller :P

10:06 <whitequark[cis]> urja: QSPI controller has output enable/disable for most pins

10:06 <whitequark[cis]> if you push in a Dummy cycle, it disables IO1:IO3, and if you don't have a chip selected during that cycle, it disables SCK

10:07 <urja> yeah so did the previous one - for everything except CS (which kinda makes sense for you know, a normal SPI bus, but not for doing ISP)

10:07 <whitequark[cis]> however, CS# is always enabled

10:07 <whitequark[cis]> i think the way to do this is to have an OE override somewhere in GlasgowPort

10:16 <urja> I've also been doodling a "flash addon" (DIL32 or PLCC32) in kicad (i started from the prom-addon by esden)

10:18 <urja> I feel like it'd be fun to drive FWH/LPC with glasgow (as opposed to it being a wild hack that's technically allowed by the spec for bitbanging with a microcontroller)

10:20 <urja> (the PCI-derived clock is allowed to vary between DC and 33 Mhz, but it being bitbanged at whatever the 16Mhz AVR can keep up with might not be what was intended :P)

10:21 <whitequark[cis]> there is an LPC device applet in a branch, LPC host would be pretty easy yes

10:21 <whitequark[cis]> LPC device was one of the big things that prompted the development of Amaranth, then nMigen

10:21 <whitequark[cis]> you couldn't have an async reset domain in Migen, which is nonsense

10:24 <js[m]> one nice improvement would be though to not having to specify dummy pins

10:24 <whitequark[cis]> the next step here would be to make SPI controller function like QSPI controller

10:25 <whitequark[cis]> and then the gateware could decide between the two based on the presence of the last two pins

11:14 <whitequark[m]> gsuberland (@_discord_429990674406965278:catircservices.org) poke re: the PR

14:15 <cyborg_ar> distributors love their tarballs

21:52 <_whitenotifier-3> [glasgow] gsuberland synchronize pull request #544: Hardware description documentation for Glasgow revC3 - https://github.com/GlasgowEmbedded/glasgow/pull/544

22:00 <_whitenotifier-3> [glasgow] gsuberland synchronize pull request #544: Hardware description documentation for Glasgow revC3 - https://github.com/GlasgowEmbedded/glasgow/pull/544

22:07 <_whitenotifier-3> [glasgow] gsuberland synchronize pull request #544: Hardware description documentation for Glasgow revC3 - https://github.com/GlasgowEmbedded/glasgow/pull/544

22:08 <_whitenotifier-3> [glasgow] gsuberland reviewed pull request #544 commit - https://github.com/GlasgowEmbedded/glasgow/pull/544#discussion_r1721073711

22:09 <_whitenotifier-3> [glasgow] gsuberland reviewed pull request #544 commit - https://github.com/GlasgowEmbedded/glasgow/pull/544#discussion_r1721073807

22:11 <_whitenotifier-3> [glasgow] gsuberland synchronize pull request #544: Hardware description documentation for Glasgow revC3 - https://github.com/GlasgowEmbedded/glasgow/pull/544

22:13 <_whitenotifier-3> [glasgow] gsuberland synchronize pull request #544: Hardware description documentation for Glasgow revC3 - https://github.com/GlasgowEmbedded/glasgow/pull/544

23:25 <gsuberland[m]> Done the actual documentation work. Currently fighting with git to try to squash. It's being a huge pain, creating conflicts on every single commit and making me resolve them manually.

23:27 <gsuberland[m]> Tempted to just make a separate branch and send it as a new PR since it's at least an hour less effort.

23:37 <_whitenotifier-3> [glasgow] gsuberland opened pull request #669: Finalised revC3 hardware description documentation. - https://github.com/GlasgowEmbedded/glasgow/pull/669

23:37 <_whitenotifier-3> [glasgow] gsuberland commented on pull request #544: Hardware description documentation for Glasgow revC3 - https://github.com/GlasgowEmbedded/glasgow/pull/544#issuecomment-2295435823

23:45 <gsuberland[m]> aaaaaaaaaand of course that didn't work because we also changed `conf.py` to fix the URL issue as part of the original PR

23:45 <gsuberland[m]> sorry, I'm giving up on this for now.