05:24 <lanrat[m]> I'm just not getting around to using my glasgow for the first time, and followed these instructions: https://glasgow-embedded.org/latest/install.html#... (full message at <https://catircservices.org/_irc/v1/media/download/ATUM8SBKgF_jlYA414f3okUBvszBXRXoNkD6aNjCdFk59C6Wo8wAg8fgfg5ip_ItHqAAmDCgpXRljeqNuGstrPW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9vWkZWSFNuaGJ1R2dTQ1FWQVJMVXd0Um8>)

10:25 <Attie[m]> it should handle loading firmware for you automatically (and should come with firmware loaded too)

10:29 <Attie[m]> If that -4 is errno, then it's EINTR, which is odd... can you try a different USB port, possibly direct / with no hub?

11:50 <_whitenotifier-4> [glasgow] xeniter opened pull request #739: change libfx2 submodule to latest version - https://github.com/GlasgowEmbedded/glasgow/pull/739

11:52 <_whitenotifier-4> [glasgow] xeniter commented on issue #726: Building firmware fails - https://github.com/GlasgowEmbedded/glasgow/issues/726#issuecomment-2646194976

18:45 <_whitenotifier-4> [glasgow] whitequark synchronize pull request #739: change libfx2 submodule to latest version - https://github.com/GlasgowEmbedded/glasgow/pull/739

18:47 <_whitenotifier-4> [glasgow] github-merge-queue[bot] created branch gh-readonly-queue/main/pr-739-2a67f79d6025a06e98277956cbb036c4237960f1 - https://github.com/GlasgowEmbedded/glasgow

18:48 <_whitenotifier-4> [GlasgowEmbedded/glasgow] github-merge-queue[bot] pushed 1 commit to main [+0/-0/±1] https://github.com/GlasgowEmbedded/glasgow/compare/2a67f79d6025...560d8dcbfb15

18:48 <_whitenotifier-4> [GlasgowEmbedded/glasgow] xeniter 560d8dc - vendor: update libfx2.

18:48 <_whitenotifier-4> [glasgow] github-merge-queue[bot] deleted branch gh-readonly-queue/main/pr-739-2a67f79d6025a06e98277956cbb036c4237960f1 - https://github.com/GlasgowEmbedded/glasgow

18:48 <_whitenotifier-4> [glasgow] whitequark closed pull request #739: change libfx2 submodule to latest version - https://github.com/GlasgowEmbedded/glasgow/pull/739

18:50 <_whitenotifier-4> [glasgow] whitequark closed issue #726: Building firmware fails - https://github.com/GlasgowEmbedded/glasgow/issues/726

18:50 <_whitenotifier-4> [glasgow] whitequark commented on issue #726: Building firmware fails - https://github.com/GlasgowEmbedded/glasgow/issues/726#issuecomment-2646478077

18:51 <whitequark[cis]> oh, i think there might be an issue with the workflow we're using for checking firmware build reproducibility

18:52 <whitequark[cis]> actually nevermind

19:36 <lanrat[m]> * I'm just now getting around to using my glasgow for the first time, and followed these instructions: https://glasgow-embedded.org/latest/install.html#... (full message at <https://catircservices.org/_irc/v1/media/download/AZgVreGCi1YSZNuBvckpZcG9GqpIaVP94sXQdve9rLM6mLaez9andD1xQIq6RiRbwApfRVBiqiu1mYfgowJh3Q2_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9ic2x6Zmx6SmtDdFRxcVRZTVJRS1NqTGc>)

19:37 <lanrat[m]> I tested multiple ports on my system, all without a hub, and all give the same error.

19:39 <whitequark[cis]> what does running glasgow -vvv devices say?

19:39 <whitequark[cis]> s//`/, s/devices/list`/

20:15 <lanrat[m]> I get the same error, but I think I may have found the problem. I run each development program on my system in a different mount namespace (to prevent dependencency conflicts) and It looks like I had a permissions problem when mounting /dev/ I change the permissions and now it works.

20:15 <lanrat[m]> * I get the same error, but I it looks like I found the problem. I run each development program on my system in a different mount namespace (to prevent dependencency conflicts) and It looks like I had a permissions problem when mounting /dev/ I change the permissions and now it works.

20:16 <whitequark[cis]> fwiw, if you use glasgow with pipx or pdm then everything it needs, including the FPGA toolchain but excluding Python, are installed locally to the tool

20:17 <lanrat[m]> I'm now observing something else. I'm running a test of the UART autobaud detection. It seems to detect the first baudrate, but if the baudrate ever changes, the new one won't be detected unless the glassgow command is restarted.

20:18 <lanrat[m]> s/first/initial/

20:18 <whitequark[cis]> have you read the description of the applet?

20:20 <lanrat[m]> Do you mean `glasgow run uart --help`? I've read that.

20:20 <whitequark[cis]> yeah

20:20 <whitequark[cis]> does it report frame/parity errors?

20:21 <lanrat[m]> not as often as I would expect.

20:21 <lanrat[m]> And sometimes when it does, it "detects" a baud rate of 0.

20:22 <whitequark[cis]> baud rate of 0 is definitely a bug albeit not one i've seen before

20:22 <whitequark[cis]> the rest is, i think, probably down to autobaud being inherently unreliable

20:23 <lanrat[m]> I have the glasgow connected to FTDI serual chip in another terminal where I'm typing manually to test it out.

20:23 <lanrat[m]> s/serual/serial/

20:24 <whitequark[cis]> interesting. the usual use case for autobaud is "booting a kernel where u-boot, dmesg, and userspace all use different baud rates"

20:24 <whitequark[cis]> it performs very well on that workload but isn't tested much otherwise

20:25 <lanrat[m]> that's the exact use-case I have in mind. But I wanted to make sure I understood how it works before I use it for that.

20:26 <lanrat[m]> I also setup a teensy MCU printing some text every second alternating between 3 baudrates, and it does not seem to be detected.

20:26 <whitequark[cis]> how much text?

20:27 <lanrat[m]> only a single line

20:27 <lanrat[m]> Is more needed?

20:27 <whitequark[cis]> try 38400 and 57600

20:45 <lanrat[m]> hmm, I think there is a bug in my teensy code.

21:31 <lanrat[m]> yep, my code was the issue, works great now

21:33 <whitequark[cis]> happy to hear that it works