00:17 <whitequark> marcan: opinion on #128?

00:17 <whitequark> well, specifically,

00:18 <whitequark> take a look at applet/uart

00:19 <whitequark> there's the target.register.add calls, these should just live inside the interface

00:19 <whitequark> ie whatever is returned by claim_interface

00:20 <whitequark> similarly you should be setting the registers via the interface returned by demultiplexer.claim_interface

00:20 <whitequark> but i don't know what to use for a register identifier

00:20 <whitequark> the options are:

00:20 <whitequark> 1) provide a string to a multiplexer, use a string when poking the demultiplexer

00:20 <whitequark> but this is a problem e.g. in case of the avr applet

00:20 <whitequark> because there's the SPI reset register and the AVR reset register

00:21 <whitequark> 2) return an opaque object and require its use afterwards

00:21 <whitequark> then you need to track it around though...

00:21 <whitequark> am i missing something that's possible?

05:36 <marcan> whitequark: should we have revC1.1 tags or something like that for documentation changes? (e.g. that fix for the ATECC partno; other things: messing with BOM keys and such)

05:36 <marcan> or revC1_p1 or some other scheme

05:37 <whitequark> marcan: i think it's fine to just use master for that

05:37 <marcan> the rule would be that these must have zero effect and result in an equivalent device specification-wise and have no software impact, and we would update the production files in-place

05:37 <marcan> well we can use master, but we might still want to tag them?

05:37 <marcan> (in fact for the production files the rule would be that only schematic, BOM, and fab layers can change)

05:37 <whitequark> if you change anything besides BOM it's revC2 imo

05:38 <whitequark> right, BOM, non-electronic parts of schematic, and fab

05:38 <marcan> yes

05:38 <whitequark> i don't see the point of tagging really, it's still revC1

05:38 <whitequark> same device for all intents and purposes

05:39 <marcan> the only problem here is if we start making other changes and then have to branch off a minor fix like that

05:39 <marcan> what's the plan for revD? I think we should have a separate kicad project for that

05:39 <marcan> revA-B-C were superseding changes, revD won't be

05:39 <whitequark> yes, you mentioned forking off kicad projects

05:40 <marcan> I think we should branch off for revD, and keep the current files (possibly renaming the directory) for future revC2... etc

05:40 <_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fjW4Z

05:40 <_whitenotifier-3> [GlasgowEmbedded/Glasgow] whitequark ddc5219 - target.hardware: add explicit clock domain names for PyPy compat.

05:40 <marcan> in that case using master for BOM changes is fine

05:40 <whitequark> i'm basically fine with it

05:41 <whitequark> how will it happen in reality

05:41 <whitequark> ?

05:41 <whitequark> i'm thinking keep the same kicad project file but fork .sch/.kicad_pcb files

05:41 <whitequark> but i'm not sure

05:42 <marcan> I think I'd rather use a different kicad project just to avoid any accidental damage, but I'm not sure either

05:42 <marcan> like git mv hardware/boards/{glasgow,glasgow-revC}

05:43 <whitequark> they'd still use the same footprint/symbol libraries

05:43 <marcan> yeah

05:43 <marcan> which makes sense

05:43 <whitequark> at which point i feel like it's pointless to have different kicad projects

05:43 <_whitenotifier-3> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/GlasgowEmbedded/Glasgow/builds/531620264?utm_source=github_status&utm_medium=notification

05:43 <whitequark> hmm wait

05:44 <whitequark> the .pro file has net classes and via diameters and such

05:44 <marcan> yeah

05:44 <marcan> it stores preferences

05:44 <marcan> that's why I'm slightly concerned

05:44 <whitequark> ok

05:44 <whitequark> i agree, let's do the git mv above

05:44 <marcan> ok

05:45 <whitequark> can you also resurrect kicad files for revA and revB then?

05:45 <whitequark> and rename glasgow/revA to something like glasgow-revA/out

05:45 <marcan> ah, you want to fork those too? I can certainly do that

05:45 <marcan> I thought we were burying them since people shouldn't really be making them

05:45 <whitequark> it seems much nicer to do so

05:45 <whitequark> well people shouldn't make revC0s either

05:45 <whitequark> but the ones that are already around should be documented

05:45 <marcan> yeah

05:46 <whitequark> i think if someone *wants* to grab design files from a random git tag they will do it

05:46 <whitequark> case in point: literally esden

05:46 <whitequark> or git commit even

05:46 <marcan> what I mean is that since our versioning scheme changed, revAB are superseded by revC, so the "trees" logically are revC/D/E and revAB are just old versions of revC

05:46 <marcan> so if someone really wants those they can dig back through history

05:46 <marcan> but they may not make sense as top level directories

05:46 <marcan> we still have the production files of course

05:47 <marcan> but being next to revC makes the fact that they're superseded evident

05:47 <whitequark> revB should've been revA1 but other than that revB and revC are fairly parallel

05:47 <whitequark> well

05:47 <marcan> I could also just resurrect only revB

05:48 <whitequark> i guess that works

05:48 <whitequark> i can write a README explaining what's up with that

05:48 <marcan> yeah, that would help

05:48 <marcan> at $work right now, but I can shuffle things around when I get home

05:49 <whitequark> ack

05:53 <marcan> I wonder if I can get git to represent that "history resurrection"

05:54 <marcan> maybe I can fork off revB with a git cp commit, then merge it back to master

05:57 <whitequark> it doesn't track that

05:57 <whitequark> oh wait

05:57 <whitequark> i see what you mean

05:57 <whitequark> yeah that would work i think

07:15 <whitequark> marcan: btw have you seen my question re registers?

08:00 <marcan> whitequark: need to look at the code to get a good idea of what's going on

08:01 <marcan> register numbering is a problem we had with OV too, you can take a look at that code if you're interested

08:05 <whitequark> well there's no persistent register numbering in glasgow

08:05 <whitequark> worse yet there are register *sizes* too

08:05 <whitequark> also i might end up adding an I2C-readable ROM of some kind

08:06 <whitequark> trading one BRAM for being able to plug&play to openocd or something is worthwhile

08:07 <marcan> why do you need a ROM?

08:10 <marcan> for OV we use the misoc CSR stuff

08:10 <marcan> e.g. https://github.com/openvizsla/ov_ftdi/blob/020367709bbbd79d19827f13794cedd55068bac9/software/fpga/ov3/ovhw/leds.py

08:10 <marcan> then that gets dumped out to a map file next to the bitstream, that the host software can use: https://github.com/openvizsla/ov_ftdi/blob/72c3600086e3dc53606d90a9d6b09c689432782d/software/fpga/ov3/build.py#L6

08:11 <whitequark> marcan: because i don't want people to have to get a file from glasgow.cli and feed it to openocd

08:11 <marcan> you mean like loading the bitstream from glasgow.cli and then running openocd standalone?

08:12 <whitequark> yes

08:13 <whitequark> it might not matter / be a good idea for openocd specifically but there are sure some applications that need it

08:13 <marcan> you'd still need a glasgow-specific backend for any apps that care about register numbers, no?

08:13 <marcan> unless you're emulating a specific USB class

08:13 <whitequark> it'd be glasgow-specific, yes

08:13 <whitequark> but it would not be tied to one specific gateware build

08:15 <marcan> I think if you're distributing gateware binaries you can use a sidecar approach like we do for OV (.fwpkg is a zip file containing gateware and map); if you're putting gateware in the flash you can add the mapfile there without consuming BRAM space and read it off directly; and if you're loading gateware live you can arrange for some software-side approach to pass the mapfile without requiring ...

08:15 <marcan> ... actually storing it on-device.

08:15 <marcan> I don't like the idea of spending a BRAM on some metadata ROM

08:15 <whitequark> i don't like the idea of having three different ways to discover gateware capabilities.

08:16 <marcan> is there enough ram on the FX2 to put the map there?

08:16 <whitequark> i *especially* don't like the idea of having different ways to discover this with and without flash

08:17 <whitequark> soooort of

08:18 <whitequark> i guess we could put it on the FX2 instead

08:19 <whitequark> maybe limit it to 1k

08:20 <thaytan> whitequark, I have a mac mini and the ability to build solvespace

08:20 <thaytan> I'm not surprised by OpenGL regressions, since it's officially deprecated

08:20 <whitequark> well i'm not about to port anything to metal

08:20 <thaytan> "just rewrite the world in our platform specific Metal API, mmkkay"

08:20 <thaytan> yeah, exactly

08:20 <whitequark> ... or vulkan for that matter

08:21 <whitequark> because it means dropping a lot of opengl devices

08:21 <thaytan> we're using MoltenVK for a project atm

08:21 <thaytan> (instead of adding a Metal specific GStreamer backend)

08:21 <thaytan> it's working out OK

08:22 <thaytan> it's a frustrating position to be in though

08:23 <whitequark> i'd use moltengl if it could be redistributed

08:23 <whitequark> we considered a potential vulkan rewrite

08:23 <whitequark> besides vulkan being a nightmare it'd mean dropping support for thinkpad x220

08:23 <whitequark> so, well, no.

08:25 <thaytan> *nod*

08:25 <thaytan> yeah, it'd mean 2 backends to maintain

08:25 <whitequark> one is bad enough already

19:17 <electronic_eel> whitequark: re registers for detecting gateware capabilities

19:17 <electronic_eel> why disconnect glasgow cli from external applications like openocd?

19:17 <electronic_eel> i suggest that the openocd (or similar) interface driver either forks the glasgow cli or uses a socket to connect to it

19:17 <electronic_eel> then they use some text protocol to agree on features for the gateware

19:18 <electronic_eel> glasgow cli builds the matching bitstream, uploads it and then uses the socket to tell openocd which usb bus id and so on it can use to directly communicate with the glasgow hw

19:19 <electronic_eel> that way the interface driver and the glasgow cli can communicate in both directions to agree on what to do

19:19 <electronic_eel> makes it more flexible re upgrading one part without affecting the other

19:20 <electronic_eel> you also don't have to care if the bitstream you uploaded is really compatible and does exactly what you want or not

19:22 <electronic_eel> ...uploaded manually i mean

19:25 <electronic_eel> it also would also allow to either specify stuff like pins, io voltages, pin-autodetection,... in the openocd board file or just have a socket name there and start the glasgow cli manually with all the wanted options.