#glasgowinterfaceexplorer — Public Fediverse posts

i just merged the PR with revD support for #GlasgowInterfaceExplorer! https://github.com/GlasgowEmbedded/glasgow/pull/1181

this has all the basic functionality covered, but doesn't yet add support for NAFE or a DRAM controller

also, it upgrades revC devices to have programmable current limiting :)

i just merged the PR with revD support for #GlasgowInterfaceExplorer! https://github.com/GlasgowEmbedded/glasgow/pull/1181

this has all the basic functionality covered, but doesn't yet add support for NAFE or a DRAM controller

also, it upgrades revC devices to have programmable current limiting :)

Glasgow Interface Explorer in action. Dumped OEM firmware from a unmanaged router and replaced it custom "managed" firmware from https://github.com/logicog/RTLPlayground

#embedded #homelab #GlasgowInterfaceExplorer

Glasgow Interface Explorer in action. Dumped OEM firmware from a unmanaged router and replaced it custom "managed" firmware from https://github.com/logicog/RTLPlayground

#embedded #homelab #GlasgowInterfaceExplorer

The thing I'm excited the most about the new #GlasgowInterfaceExplorer is the way it allows you to travel while occasionally tinkering with random hardware you find along the way. It's like a box of tools you can manage with a Python script (or just shell commands for simple tasks) that you can put in your pocket.

#GlasgowInterfaceExplorer revD assembly density (finger for scale)

#GlasgowInterfaceExplorer revD assembly density (finger for scale)

the #GlasgowInterfaceExplorer revD project is up on CrowdSupply! subscribe to get updates and show your interest in the project, we're very excited to bring it to life :D

https://www.crowdsupply.com/fully-automated/glasgow-interface-explorer-revd

FAQ:

• timeline to shipping devices is "several months", unless something terrible happens in the meantime, which it really could
• yes, there will be a milled aluminium case, also designed by @timonsku

the #GlasgowInterfaceExplorer revD project is up on CrowdSupply! subscribe to get updates and show your interest in the project, we're very excited to bring it to life :D

https://www.crowdsupply.com/fully-automated/glasgow-interface-explorer-revd

FAQ:

• timeline to shipping devices is "several months", unless something terrible happens in the meantime, which it really could
• yes, there will be a milled aluminium case, also designed by @timonsku

check out this new primitive I'm working on for #GlasgowInterfaceExplorer! see alt text for an explanation

i'm calling it "HyperFIFO"; it has the same interface as a normal synchronous FIFO, but if you exceed the small amount of buffer space within (generally under 1 KB), the contents spill into external DRAM, where up to 64 MB of spikes (about 2 seconds of USB 2.0 bandwidth) can be buffered

this enables logic analyzer type applications on revC and revD

check out this new primitive I'm working on for #GlasgowInterfaceExplorer! see alt text for an explanation

i'm calling it "HyperFIFO"; it has the same interface as a normal synchronous FIFO, but if you exceed the small amount of buffer space within (generally under 1 KB), the contents spill into external DRAM, where up to 64 MB of spikes (about 2 seconds of USB 2.0 bandwidth) can be buffered

this enables logic analyzer type applications on revC and revD

once the changes land, #GlasgowInterfaceExplorer USB performance on Windows will be virtually identical to performance on Linux!

once the changes land, #GlasgowInterfaceExplorer USB performance on Windows will be virtually identical to performance on Linux!

once the changes land, #GlasgowInterfaceExplorer will have real-time IO port fault notifications! (on revC3 as well)

once the changes land, #GlasgowInterfaceExplorer will have real-time IO port fault notifications! (on revC3 as well)

adding new features to #GlasgowInterfaceExplorer (including revC units), such as current measurement limiting

edit: current measurement was added by the contributor i-infra a few weeks earlier, current limiting was added by me just now

$ glasgow voltage 
Port    Vsupply Vlimit  Isupply Ialert  Vsense  Vsense(alert)
A       3.322   4.913   (SHORT) 0.000   0.000   0.000-0.000
B       0.000   3.264   0.000   0.000   0.000   0.000-0.000

adding new features to #GlasgowInterfaceExplorer (including revC units), such as current measurement limiting

edit: current measurement was added by the contributor i-infra a few weeks earlier, current limiting was added by me just now

$ glasgow voltage 
Port    Vsupply Vlimit  Isupply Ialert  Vsense  Vsense(alert)
A       3.322   4.913   (SHORT) 0.000   0.000   0.000-0.000
B       0.000   3.264   0.000   0.000   0.000   0.000-0.000

people keep asking me when #GlasgowInterfaceExplorer is going to use USB3, and that's a fair question, but:

you get 40 whole megabytes per second with USB2. can you even write an application that can process that much data in realtime?

(yes, I know many of you can, I can too, even in Python for some workloads. but the point is that you need to really know what you're doing, even in a compiled language)

people keep asking me when #GlasgowInterfaceExplorer is going to use USB3, and that's a fair question, but:

you get 40 whole megabytes per second with USB2. can you even write an application that can process that much data in realtime?

(yes, I know many of you can, I can too, even in Python for some workloads. but the point is that you need to really know what you're doing, even in a compiled language)

#GlasgowInterfaceExplorer revD0 can now run the benchmark!

this is a big milestone; it tests (new, GPIF-based) bitstream loading as well as FPGA FIFO configuration

as a bonus, revC devices on Windows get about a 1.5-2x performance boost once the new firmware is merged!

#GlasgowInterfaceExplorer revD0 can now run the benchmark!

this is a big milestone; it tests (new, GPIF-based) bitstream loading as well as FPGA FIFO configuration

as a bonus, revC devices on Windows get about a 1.5-2x performance boost once the new firmware is merged!

just managed to get UART loopback to work on the #GlasgowInterfaceExplorer revD0 prototype!

just managed to get UART loopback to work on the #GlasgowInterfaceExplorer revD0 prototype!

you know the nintendo exi bus? used in gamecube and wii?

today i learned that stock #GlasgowInterfaceExplorer makes a pretty good sniffer for it

e.g. you can grab exi_decode_uart.py from here...

import sys
import struct

while item := sys.stdin.readline():
    req, rsp = map(bytes.fromhex, item.split(","))
    header, = struct.unpack(">L", req[:4])
    addr = (header & 0x7fffffff) >> 6
    if header & 0x80000000: # write
        data = req[4:]
        if addr == 0xc0_0004:
            for byte in data[0::4]:
                print(chr(byte), end="")
                if byte == 0xd:
                    print()

and then run glasgow run spi-analyzer -V 3.3 | python exi_decode_uart.py and it prints boot logs if you tap into the exi bus on which the weird macronix rtc asic is

you know the nintendo exi bus? used in gamecube and wii?

today i learned that stock #GlasgowInterfaceExplorer makes a pretty good sniffer for it

e.g. you can grab exi_decode_uart.py from here...

import sys
import struct

while item := sys.stdin.readline():
    req, rsp = map(bytes.fromhex, item.split(","))
    header, = struct.unpack(">L", req[:4])
    addr = (header & 0x7fffffff) >> 6
    if header & 0x80000000: # write
        data = req[4:]
        if addr == 0xc0_0004:
            for byte in data[0::4]:
                print(chr(byte), end="")
                if byte == 0xd:
                    print()

and then run glasgow run spi-analyzer -V 3.3 | python exi_decode_uart.py and it prints boot logs if you tap into the exi bus on which the weird macronix rtc asic is

#GlasgowInterfaceExplorer revD0 prototypes are being assembled by JLC!

#GlasgowInterfaceExplorer revD0 prototypes are being assembled by JLC!

#GlasgowInterfaceExplorer revD0 order going to the fab today!

#GlasgowInterfaceExplorer revD0 order going to the fab today!

I'm just doing simple serial protocol stuff now, but I think that for more complex exploration, AI could write custom applets for the #glasgowinterfaceexplorer (which I am not capable of) — that could be a *really* powerful tool.

I'm just doing simple serial protocol stuff now, but I think that for more complex exploration, AI could write custom applets for the #glasgowinterfaceexplorer (which I am not capable of) — that could be a *really* powerful tool.

As it turns out, AI can use the #glasgowinterfaceexplorer and Saleae Logic very well, too. This *really* cuts down on development and debugging time. Especially useful for reverse-engineering Chinese modules with shoddy or non-existent documentation.

As it turns out, AI can use the #glasgowinterfaceexplorer and Saleae Logic very well, too. This *really* cuts down on development and debugging time. Especially useful for reverse-engineering Chinese modules with shoddy or non-existent documentation.

Does someone in my bubble want to sell me their #glasgowInterfaceExplorer so I don't need to wait more than a year for one to be produced :(? (rev C preferably, shipping to Germany or at #gpn24, #40c3 etc.)
The more I'm looking into coreboot, the more I'm tapping into buses where my logic analyzer hits its limits (and also, playing with FPGAs!!1)

boost welcome

also because this wire harness is a lot shorter, i can use quad mode and read it at 4 MB/s with the #GlasgowInterfaceExplorer memory-25q applet

also because this wire harness is a lot shorter, i can use quad mode and read it at 4 MB/s with the #GlasgowInterfaceExplorer memory-25q applet

i'm working on a SPI NAND Flash applet for #GlasgowInterfaceExplorer. i would like to add the ability to read (and write) data dumps... however, unlike with SPI NOR flashes where the data is located in an flat address space, SPI NAND devices are structured as pages (each consisting of data + spare + ECC)

how should i format these dumps? is there a standard format? is "use msgpack with a simple custom schema" good enough, considering msgspec promises fast (de)serialization for Python and other languages?

i'm working on a SPI NAND Flash applet for #GlasgowInterfaceExplorer. i would like to add the ability to read (and write) data dumps... however, unlike with SPI NOR flashes where the data is located in an flat address space, SPI NAND devices are structured as pages (each consisting of data + spare + ECC)

how should i format these dumps? is there a standard format? is "use msgpack with a simple custom schema" good enough, considering msgspec promises fast (de)serialization for Python and other languages?

if you have a #GlasgowInterfaceExplorer, please try out the new memory-25q applet and let me know if it works for you!

https://glasgow-embedded.org/latest/applets/memory/25q.html

if you have a #GlasgowInterfaceExplorer, please try out the new memory-25q applet and let me know if it works for you!

https://glasgow-embedded.org/latest/applets/memory/25q.html

so!! i am excited!!! to have finally finished the complete reimplementation of the #GlasgowInterfaceExplorer memory-25x applet for managing SPI NOR flashes. it is called memory-25q and it took an enormous amount of effort, because i have decided to Build It Properly

want to jump to the docs (there are a lot of docs, including on the fundamentals of (Q)SPI flashes) or read the code? here we go:

• pull request introducing memory-25q
• quad SPI controller API
• framework for managing QSPI-style memories
• the CLI of the new memory-25q applet
• and, finally, the API of the new memory-25q applet

now, why did i do that? two reasons. memory-25x is one of the first applets i made, ~7 years ago, and i had no idea what kind of UI i should be building (yet). to make it worse, i thought that SPI NOR flashes were "easy", you could "just send a few bytes and that's basically it".

nothing could be further from truth. first off, SPI NOR flashes don't really exist—there is no spec, no standard organization that can say "no, your thing is not compliant", no order to any of this. every vendor does whatever they want, and then every other year JEDEC writes down all of the unhinged shit they did. here is the list of six incompatible methods to turn a single bit on or off, as a warmup

second, SPI flashes have an absolutely absurd diversity of framings. you cannot even express it without building a meta-framework for abstracting over all the ways people have come up to squeeze 8 bits into 2 or 4 wires. then on top of it you have to manage a bunch of global state that affects framing in subtle or sometimes really fundamental ways, without having any way to find out that you've made an error besides "you compare the actual data with the expected data (or its checksum) and it is not equal"

anyway, the new applet should be excellent at any daily task and at least okay at >90% of the exotic ones. also it's easily generalized for the (completely incompatible on the wire) QSPI NAND 25N series, octal or DTR variants, etc

so!! i am excited!!! to have finally finished the complete reimplementation of the #GlasgowInterfaceExplorer memory-25x applet for managing SPI NOR flashes. it is called memory-25q and it took an enormous amount of effort, because i have decided to Build It Properly

want to jump to the docs (there are a lot of docs, including on the fundamentals of (Q)SPI flashes) or read the code? here we go:

• pull request introducing memory-25q
• quad SPI controller API
• framework for managing QSPI-style memories
• the CLI of the new memory-25q applet
• and, finally, the API of the new memory-25q applet

now, why did i do that? two reasons. memory-25x is one of the first applets i made, ~7 years ago, and i had no idea what kind of UI i should be building (yet). to make it worse, i thought that SPI NOR flashes were "easy", you could "just send a few bytes and that's basically it".

nothing could be further from truth. first off, SPI NOR flashes don't really exist—there is no spec, no standard organization that can say "no, your thing is not compliant", no order to any of this. every vendor does whatever they want, and then every other year JEDEC writes down all of the unhinged shit they did. here is the list of six incompatible methods to turn a single bit on or off, as a warmup

second, SPI flashes have an absolutely absurd diversity of framings. you cannot even express it without building a meta-framework for abstracting over all the ways people have come up to squeeze 8 bits into 2 or 4 wires. then on top of it you have to manage a bunch of global state that affects framing in subtle or sometimes really fundamental ways, without having any way to find out that you've made an error besides "you compare the actual data with the expected data (or its checksum) and it is not equal"

anyway, the new applet should be excellent at any daily task and at least okay at >90% of the exotic ones. also it's easily generalized for the (completely incompatible on the wire) QSPI NAND 25N series, octal or DTR variants, etc

@tim @elly this is viable, you could do it on a #GlasgowInterfaceExplorer most likely; main concern is that PSRAM doesn't have all the commands that QSPI hosts may expect. eSPI solves this entirely by letting the device inject wait states, IIRC

@tim @elly this is viable, you could do it on a #GlasgowInterfaceExplorer most likely; main concern is that PSRAM doesn't have all the commands that QSPI hosts may expect. eSPI solves this entirely by letting the device inject wait states, IIRC

I would like to formally announce that the #GlasgowInterfaceExplorer revD development (the next iteration: with the same FPGA but 32 digital I/Os and 8 single-ended analog channels that can be configured as 4 differential ones) is well underway with a CrowdSupply campaign planned later this year; stay tuned!

I would like to formally announce that the #GlasgowInterfaceExplorer revD development (the next iteration: with the same FPGA but 32 digital I/Os and 8 single-ended analog channels that can be configured as 4 differential ones) is well underway with a CrowdSupply campaign planned later this year; stay tuned!

@joshua do you have a BSDL? if yes and you can access JTAG, I have a #GlasgowInterfaceExplorer applet for you that will tell you this in a single touch of a probe

@joshua do you have a BSDL? if yes and you can access JTAG, I have a #GlasgowInterfaceExplorer applet for you that will tell you this in a single touch of a probe

#GlasgowInterfaceExplorer now has (or about to have) a first-class progress bar implementation with a nice API that takes into account terminal writes elsewhere in the Python application as well as nested or concurrent progress trackers resulting from applet composition!

#GlasgowInterfaceExplorer now has (or about to have) a first-class progress bar implementation with a nice API that takes into account terminal writes elsewhere in the Python application as well as nested or concurrent progress trackers resulting from applet composition!

today's project for #GlasgowInterfaceExplorer: reworking the memory-25x applet

this is a very old applet, one of the first introduced. it works mostly fine, but it was designed and implemented before I really knew how to make good applet UIs, and long before I added QSPI support, so it's not using all of the available bandwidth & it requires specifying a bunch of geometry parameters by hand even when it is trivially extracted from the flash itself

I am planning to redesign the Flash command engine to support not just 1-1-1 (normal SPI) commands, but every mode including 1-1-2 and 1-1-4 (dual/quad data) and 1-2-2 and 1-4-4 (dual/quad address and data). to do this I will implement an abstraction for a (Q)SPI command set, which can then be extended and specialized by an individual flash

this will also handle devices like Winbond's and Micron's QSPI NAND devices (W25N series and MT29F series, respectively).

This thing is an "ETEKCITY Voltson Smart Wi-Fi Outlet" model ESW01-USA, and it's supported by Tasmota. You _can_ actually disassemble it without breaking it, but it takes some persistence. Inside is a daughterboard with a bog standard ESP8266 12-E compatible module. Which thankfully has all the UART pins on the side I can access.

This is another success story for the #GlasgowInterfaceExplorer, which not only can do the ESP8266's weird 74880 baud rate, but it can also pretend to be a serial port over pty so you can use regular old esptool with it.