Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Method to list connected Glasgow boards #206

Closed
attie opened this issue Sep 23, 2020 · 5 comments
Closed

Method to list connected Glasgow boards #206

attie opened this issue Sep 23, 2020 · 5 comments
Labels
software Component: software

Comments

@attie
Copy link
Member

attie commented Sep 23, 2020

It doesn't appear that the glasgow utility has a method to list / enumerate connected Glasgow boards.

I'd like to propse a new glasgow list subcommand that will produce a list of boards connected to the system, with their revision and serial number (ready for use with --serial)... and possibly even their position in the USB tree too.

It is possible to get this information using other system utilities (examples below), but I feel we could streamline the process and present the information in a better way.

  • lsusb -d 20b7:9db1 -v | grep iSerial
  • dmesg | grep -A2 'Glasgow Debug Tool'

Is there already a method to do this with the glasgow tool (ignoring methods that employ other system utilities such as lsusb / dmesg), and/or does this sound sensible?

@attie
Copy link
Member Author

attie commented Sep 25, 2020

While flashing and testing the batch of boards I've just run, I also noticed that the Glasgow's serial isn't reported correctly until the glasgow utility has interacted with it for the first time (since power up).

This seems to be because the firmware needs to be loaded (software/glasgow/device/hardware.py:88), which is fair enough / makes sense.

While digging, I also noticed that a list of connected serials is in fact listed if A) no serial number is given, and B) there are more than 1x Glasgows attached to the system. See software/glasgow/device/hardware.py:120, for example:

venv:$ glasgow run selftest loopback
E: g.cli: found 2 devices (serial numbers C1-20200923T174926Z, C1-20200923T190627Z), but a serial number is not specified

I appreciate that this is only presented when required... but it isn't presented when an invalid serial is given (e.g: "oops - pick from this list"), and it feels like a bit of an unexpected route (i.e: "just try running something" vs "show me a list").

@whitequark whitequark added the software Component: software label Sep 29, 2020
@whitequark
Copy link
Member

Yeah, reasonable request.

This seems to be because the firmware needs to be loaded (software/glasgow/device/hardware.py:88), which is fair enough / makes sense.

You can also run glasgow flash, which will cause the firmware to be loaded on power-up. Glasgow boards that are distributed to general public actually have to be shipped in that state because otherwise you have to do an annoying little registry dance to have them recognized via WinUSB.

@attie
Copy link
Member Author

attie commented Sep 29, 2020

You can also run glasgow flash, which will cause the firmware to be loaded on power-up.

Oh, oops... I didn't run this step for the batch I've just done - I just ran glasgow factory, and then the various self test steps. Everything seems to work okay - I'll have a play and then send an email to the group so that they're aware that this might be something worth doing(!)

Glasgow boards that are distributed to general public actually have to be shipped in that state because otherwise you have to do an annoying little registry dance to have them recognized via WinUSB

Huh, interesting... For clarity, do boards need to be shipped with firmware flashed? (i.e: which state are you referring to by "in that state")

@whitequark
Copy link
Member

For clarity, do boards need to be shipped with firmware flashed (i.e: which state are you referring to by "in that state")?

Boards need to be shipped with firmware flashed so that they present the WinUSB descriptor on first plug-in. Otherwise Windows remembers the lack of the descriptor and you'll get an access violation even if you plug a flashed board in.

You can fix that by deleting a single registry key (which I think it's possible to write a .reg file for, and it's definitely possible with a short PowerShell snippet), or by using a driverless INF file (which someone will have to write, but it's straightforward).

But it's easiest to ship flashed boards, in which case no interaction is necessary. Install the Python package and off you go.

@attie
Copy link
Member Author

attie commented Sep 29, 2020

Understood - thanks for the clarification! I had expected it to be that way round, but wanted to be sure.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
software Component: software
Projects
None yet
Development

No branches or pull requests

2 participants