<whitequark[m]>
happy to hear any feedback, including on the implementation: what was clear, what was unapproachable, etc
redstarcomrade has quit [Read error: Connection reset by peer]
smeding has quit [Quit: Lost terminal]
smeding has joined #glasgow
tec has quit [Quit: bye!]
tec has joined #glasgow
jstein has joined #glasgow
redstarcomrade has joined #glasgow
redstarcomrade has quit [Read error: Connection reset by peer]
meklort_ has joined #glasgow
meklort has quit [Ping timeout: 252 seconds]
meklort_ is now known as meklort
skipwich has quit [Ping timeout: 252 seconds]
skipwich has joined #glasgow
eigenform[m] has joined #glasgow
<eigenform[m]>
might be able to test this sometime this weekend, i tried out 25x earlier this week : o
tec8 has joined #glasgow
nafod5 has joined #glasgow
trh has quit [Ping timeout: 252 seconds]
leper- has joined #glasgow
trh has joined #glasgow
edf0 has quit [Ping timeout: 252 seconds]
skipwich_ has joined #glasgow
rcombs has quit [Ping timeout: 248 seconds]
Lord_Nightmare2 has joined #glasgow
tec has quit [Ping timeout: 252 seconds]
fibmod has quit [Ping timeout: 252 seconds]
tec8 is now known as tec
feuerrot has quit [Ping timeout: 272 seconds]
Lord_Nightmare has quit [Ping timeout: 248 seconds]
tpw_rules has quit [Ping timeout: 248 seconds]
leper has quit [Ping timeout: 248 seconds]
dx has quit [Ping timeout: 248 seconds]
vup has quit [Ping timeout: 248 seconds]
leper- is now known as leper
rcombs has joined #glasgow
skipwich has quit [Ping timeout: 252 seconds]
Xesxen has quit [Ping timeout: 252 seconds]
helle has quit [Ping timeout: 252 seconds]
vup has joined #glasgow
nafod has quit [Ping timeout: 272 seconds]
nafod5 is now known as nafod
Xesxen has joined #glasgow
edf0 has joined #glasgow
feuerrot has joined #glasgow
Lord_Nightmare2 is now known as Lord_Nightmare
fibmod has joined #glasgow
helle has joined #glasgow
dx has joined #glasgow
helle has quit [Changing host]
helle has joined #glasgow
js[m] has joined #glasgow
<js[m]>
Hi! I have a board that has a pin header for a SPI flash, but I have no idea what the pinout or voltage is. Is it possible to use `glasgow run analyzer` to figure this out>
<js[m]>
s/>/?/
<js[m]>
If I just try to run glasgow run analyzer -M vcd I get E: g.cli: I/O port A voltage (0.0 V) too low
<js[m]>
obviously, I've not connected VCC to anything since I don't know where VCC is, but ground was easy to find, obviously.
<js[m]>
so ground is connected. I would expect Glasgow to check if there's some voltage between ground and any of the connected pins?
<js[m]>
if I set the voltage to 3.3V (which I expect this to be googling data sheets for the flash on the board), I get a vcd file that looks basically empty. Is it not possible to use Glasgow for this? The documentation for the analyzer module seems to be ... nonexistent.
tpw_rules has joined #glasgow
Eli2 has joined #glasgow
Eli2_ has quit [Ping timeout: 264 seconds]
whitequark[cis] has joined #glasgow
<whitequark[cis]>
@js I would recommend a multimeter, honestly
<js[m]>
an XC-LS3A6M, which is a Chinese board with a LoongArch CPU and has as much documentation available as you'd expect 😕
<whitequark[cis]>
how does the header look like at least?
<whitequark[cis]>
the reason I ask is because in circuit programming of SPI flash is fraught
<whitequark[cis]>
people think they will do it and usually they just suffer unless the makers of the board know exactly what they're doing. which the designers of your board may have! but we can't count on it
<js[m]>
Trying to dumb both flashs on the (the Macronix and the Winbond), but for now I'm trying the Winbond on the bottom
<whitequark[cis]>
HOLD and WP need pullups at least, those are usually on the board though
<whitequark[cis]>
did you use a multimeter to find out which flash pin corresponds to which header pin?
<js[m]>
yep
<js[m]>
it seems the bottom 7 pins in the picture are all connected to the SPI
<js[m]>
no idea what the upper 6 are
<whitequark[cis]>
are they on the same bus or something? or just to one flash?
<whitequark[cis]>
btw, the flash might be 1V8 too
<whitequark[cis]>
check the suffix of the chip, or check the voltage on VCC when the board is on
<js[m]>
whitequark[cis]: Not even the two VCCs of the two are connected, weirdly. At least according to my multimeter
<js[m]>
whitequark[cis]: Data sheet says 3.3V. It's 25X40CLNIG.
<whitequark[cis]>
js[m]: that is actually good
<js[m]>
Measuring while the machine is on I also got 3.3V on the Winbond
<whitequark[cis]>
it means they probably designed it correctly
<whitequark[cis]>
there is likely a diode near each VCC
<whitequark[cis]>
or something like that
<js[m]>
that would make sense, so the VCC I apply to talk to the flash doesn't just disappear into the board
<whitequark[cis]>
correct! which is one big cause of failures
<js[m]>
So, given I multimetered everything that is connected, connected it twice just to make sure I didn't make any mistake and anything - what else could I try?
<js[m]>
I'm not even sure my Glasgow works correctly because it's also the first time I'm using it 🙂
<whitequark[cis]>
you are powering the flash via glasgow, right?
<js[m]>
whitequark[cis]: I was thinking maybe they put it on the board design so they can use another one where it is /HOLD
<js[m]>
Is there anything else I could try?
<whitequark[cis]>
oh wow that macronix device is ancient
<whitequark[cis]>
yeah that one should 100% work
<whitequark[cis]>
can you use something like the UART applet in loopback mode to verify that the pin numbering on the glasgow/harness works the way you think it does?
<js[m]>
that's a good idea
<whitequark[cis]>
from my own experience using the applet, this has a really high chance of still being an electrical issue, especially with the second flash
<whitequark[cis]>
if you run analyzer and boot the board it'll spit out a VCD file which will likely be truncated early, can you also post that? this can help me see if you've connected things right
<js[m]>
I tried analyzer and it basically had no output
<js[m]>
that was before I multimetered everything, so I just connected all the pins
<js[m]>
that was with all the pins connected and powering the machine on
<js[m]>
(except VCC, that I didn't connect)
<whitequark[cis]>
hm
<whitequark[cis]>
by default it only samples pin 0
<whitequark[cis]>
so you have to say --pins-i 0:7 or something like that
<whitequark[cis]>
(the analyzer applet is incredibly incomplete, we've not had resources to improve it for quite a while, sorry about that)
cr1901 has quit [Read error: Connection reset by peer]
<js[m]>
ah, ok
<js[m]>
anyway, let me read up the doc on the uart module and try echoing
<js[m]>
I guess the idea was to jumper TX and RX and see it echoes back, right?
<whitequark[cis]>
yes
<whitequark[cis]>
are you on linux?
<js[m]>
yeah
<whitequark[cis]>
that's fine then (windows doesn't have pty mode)
<whitequark[cis]>
* that's fine then (windows doesn't have pty mode and tty mode is limited)
<js[m]>
oh btw, I ported glasgow to pkgsrc, so it can now be installed via pkgrc on NetBSD/Linux/macOS/whatever
<whitequark[cis]>
nice
<whitequark[cis]>
does that use yowasp or native yosys?
<js[m]>
`cd devel/glasgow && make install clean-depends clean`
<js[m]>
native yosys
<js[m]>
feel free to add that to the homepage 🙂
<js[m]>
js[m]: feel free to add that to the homepage 🙂
<whitequark[cis]>
the one downside of using native yosys is that amaranth tends to be aggressive about bumping yosys versions when we find miscompilations
<whitequark[cis]>
so sometimes you might have to upgrade yosys as well. though we always support at least the latest release
<js[m]>
yeah in that case I'll just bump glasgow/amaranth/yosys at the same time 🙂
<js[m]>
So the cable ends fit well. But the connector is very lose.
<whitequark[cis]>
by cable end do you mean individual wires?
<js[m]>
so what's plugged into B in the picture is ok, what's in A comes off all the time
<whitequark[cis]>
oh! just press harder on the connector.
<js[m]>
OHHH
<js[m]>
you need to press REAL hard
<whitequark[cis]>
it requires quite a bit of force to mate properly. don't worry about breaking it if you're doing it vertically. it could take maybe half a kg of force
<js[m]>
yeah, I thought it doesn't go further in!
<whitequark[cis]>
the top of the connector key should be flush with the blue shroud
<whitequark[cis]>
the SPI stuff should probably work now too, it's extremely unlikely it would without a properly seated connector
<js[m]>
ok, now that we probably have a better connection, let me try the Macronix flash again, as that one should work 🙂
<whitequark[cis]>
same for the analyzer
<js[m]>
SUCCESS! 🙂
<js[m]>
and I just realized I can connect both flashs at the same time 😄
<whitequark[cis]>
no yeah you're right, it's rounded down
<whitequark[cis]>
a patch to protocol.sfdp to handle this particular case would be very welcome
<whitequark[cis]>
you basically can't find flashes <1Mbit any more, they're just not cost effective to make
<whitequark[cis]>
but this one is I guess somehow one of those
<whitequark[cis]>
anyway, it looks like that flash works just fine
<whitequark[cis]>
for the other one, 7 pins are connected, right? does that include WP/HOLD? try connecting them too
<whitequark[cis]>
depending on where the pullup on WP/HOLD goes (before/after the diode) maybe you need another one on the glasgow
<js[m]>
no WP/HOLD, as I couldn't find a pin that is connected to them with the multimeter
<js[m]>
whitequark[cis]: How do I dump it though when I don't know the size?
<whitequark[cis]>
the datasheet tells you the size
<whitequark[cis]>
it's 512 Kbit
<whitequark[cis]>
you need to input it in decimal or hex
<whitequark[cis]>
* or hex, and in bytes, which is a little awkward
<whitequark[cis]>
>>> hex(512*1024//8)
<whitequark[cis]>
'0x10000'
<whitequark[cis]>
Python to the rescue
<js[m]>
Found Unknown flash chip "SFDP-capable chip" (64 kB, SPI) on serprog
<js[m]>
using flashrom 🙂
<whitequark[cis]>
yeah imo just use read -f dump.bin 0 0x10000
<whitequark[cis]>
that should do the trick
<js[m]>
just did flashrom -r
<js[m]>
let me try with memory-25x as well and compare 😉
<whitequark[cis]>
64 kB seems right
<js[m]>
oh great, got two different dumps 😕
<js[m]>
hm, flashrom was significantly faster and has a lot of bytes where memory-25x just got 0xFF
<whitequark[cis]>
that's odd
<whitequark[cis]>
try fast-read maybe?
<js[m]>
well I did -f 4000 for spi-flashrom, maybe that was too much
<whitequark[cis]>
and for memory-25x?
<js[m]>
default
<whitequark[cis]>
try the same frequency for both
<js[m]>
yeah doing that right now 🙂
<js[m]>
takes a bit
<js[m]>
oh great now I have 3 different dumps
<whitequark[cis]>
apt install vbindiff can be helpful
<js[m]>
yeah that's what I'm using
<whitequark[cis]>
or pkgsrc in your case I guess
<whitequark[cis]>
how do they differ? does the dump just cut off after some point?
<whitequark[cis]>
like, cut into ffs
<js[m]>
ok I get something different on every read
<js[m]>
two reads with flashrom -> different
<js[m]>
two reads with memory-25x -> different
<whitequark[cis]>
fascinating
<whitequark[cis]>
can you show some screencaps of vbindiff?
<js[m]>
it's always different after 0x100
<js[m]>
it seems in one case everything after 0x100 is 0xFF
<js[m]>
in the other there's some randomness for a few bytes after 0x100
<js[m]>
ah ok now I got difference between 0xB0 and 0x100 as well
<js[m]>
yeah ok now I also managed to get one where the entire file is 0xFF 🙂
<whitequark[cis]>
hm
<whitequark[cis]>
this might be an EMI issue
<whitequark[cis]>
but "randomness" sounds very odd
<js[m]>
I guess the randomness is the actual data, but after some point it cuts off and is just 0xFF
<js[m]>
it seems the file is always 0xFF after some amount of bytes
<js[m]>
but after how many bytes it cuts off seems to be random
<whitequark[cis]>
that sounds like an EMI issue
<whitequark[cis]>
in this case, the victim signal is CS# and the aggressor signals are everything else
<whitequark[cis]>
if you're using e.g. pins 0, 1, 2 for SCK, COPI, CIPO, try using pin 7 for CS#, and twist the wire of the cable with the CS# wire
<whitequark[cis]>
* twist the ground wire of
<whitequark[cis]>
* if you're using e.g. pins 0, 1, 2 for SCK, COPI, CIPO, try using pin 7 for CS#, and twist a ground wire of the cable with the CS# wire
<js[m]>
one sec, I'll try something else first: Completely unplugging the PSU and removing the battery
<whitequark[cis]>
ideally connect more than one ground wire to anything available on board
<whitequark[cis]>
oh.
<whitequark[cis]>
oh you had it plugged in
<js[m]>
yeah, plugged in but PSU had the switch at the back turned off
<js[m]>
good news! I have to identical dumps! bad news: They're both just 0xFF, the entire file
<js[m]>
s/to/two/
<whitequark[cis]>
oh, no, that should've been fine
<whitequark[cis]>
battery prooobably won't affect it either unless the board is super weird
<js[m]>
<whitequark[cis]> "if you're using e.g. pins 0, 1,..." <- did that, did two reads, first truncated after 0x59 bytes, second truncated after 0 bytes
<whitequark[cis]>
then it's probably not EMI but is something else
<js[m]>
interesting, I increased the frequency and got more bytes
<whitequark[cis]>
do you have an oscilloscope?
<js[m]>
maybe something shuts off after some time?
<whitequark[cis]>
exactly
<js[m]>
whitequark[cis]: unfortuinat
<js[m]>
> <@whitequark:matrix.org> do you have an oscilloscope?
<js[m]>
* unfortunately not ☹️
<js[m]>
hm now I'm reliably getting files of only 0xFF
<js[m]>
(10000 as frequency. Got one dump almost complete, after that only 0xFF)
<js[m]>
ok this is interesting. It seems if I change the frequency, I get something, if I then run it again, only 0xFF. Does it have something to do with uploading the bitstream which resets something?
<whitequark[cis]>
10000 is not supposed to work
<whitequark[cis]>
with memory-25x at least
<whitequark[cis]>
right now the fastest you can dump SPI at is 6000, which is in the process of being fixed but not quite there yet
<whitequark[cis]>
(there is a branch which should work up to 48000)
<js[m]>
> glasgow run memory-25x: error: argument --pins-io: applet 'memory-25x': set 1,3 includes 2 pins, but 4 pins are required
<whitequark[cis]>
and then after that some two non-connected pins
<js[m]>
oh also funny. I disconnected the cable and now I just got a file full of zeros. I would have expected it to complain instead 😉
<js[m]>
<whitequark[cis]> "if everything works again after,..." <- yep, works again after voltage 0
<js[m]>
Catherine: with -f 48000, I got 3 identical dumps now (with voltage 0 in between)
<js[m]>
they all have no blocks of 0xFF until the end (blocks of 0x00, but I expect that to be what's in the flash)
<whitequark[cis]>
ok, it's a DUT issue where the Glasgow cannot power up the board and is probably trying to power it up somehow
<whitequark[cis]>
so it's probably not designed well
<whitequark[cis]>
s/well/right for this kind of dumping/
<js[m]>
DUT?
<whitequark[cis]>
device under test
<whitequark[cis]>
whatever you're attaching glasgow to
<js[m]>
ah
<whitequark[cis]>
<js[m]> "oh also funny. I disconnected..." <- there is no way for the applet to find out the flash is not there
<js[m]>
oh, you mean like, the glasgow is sending power and powering up something else that has some init time, and after that screws things up?
<whitequark[cis]>
well
<whitequark[cis]>
sorry, let me rephrase
<whitequark[cis]>
in most cases, the RES command or the SFDP read command will let you find out there's no flash
<whitequark[cis]>
but since there is no actual unified command set, the applet just blasts "give me these bytes" if you ask it to read
<whitequark[cis]>
because you may be working with something that doesn't have RES or SFDP or anything else, which happens more commonly than you'd think
<whitequark[cis]>
e.g. some FPGAs and MCUs pretend to be SPI flashes
<whitequark[cis]>
well. Winbond flashes say NEXCOM for whatever reason
<js[m]>
ah, ok
<whitequark[cis]>
the JEDEC manufacturer ID is completely fucked for weird legacy reasons
<js[m]>
ok lol, I tried powering the machine after glasgow safe but still being connected to the glasgow - it would no longer turn on
<js[m]>
shouldn't glasgow safe be the same as disconnecting the cable? after disconnecting the cable it would power on again
<whitequark[cis]>
it's not possible to make it completely the same as disconnecting the cable
<whitequark[cis]>
(not in the device size/complexity/price point we were trying to hit)
<whitequark[cis]>
glasgow safe removes all applied voltage and tristates the I/O pins, but what's probably happening there is that you're back-powering the Glasgow V output from the board
<whitequark[cis]>
if I recall, if you do that with no loaded bitstream, all I/O pins drive high strongly, and if the bitstream is loaded, it does whatever the bitstream does. in this particular case, I'm unsure
<whitequark[cis]>
back-powering the V output is an unsupported condition. it doesn't hurt the Glasgow but it might cause issues with the DUT
<whitequark[cis]>
glasgow safe means "as safe as the device can be", not "literally the same as unplugging the cable", which would require, i think, eight relays
<whitequark[cis]>
s//`/, s//`/, s/eight/ten/
<js[m]>
I see, good to know
<js[m]>
anyway, now I can no longer get the chip detected at all sigh
<whitequark[cis]>
it seems like this board isn't designed for flashing it in this way
<whitequark[cis]>
there is probably a reset pin somewhere on the flashing header
<js[m]>
which is weird, because why else would they put a pin header next to the flash?
<whitequark[cis]>
if you assert this reset pin, and power on the board, it would do nothing, and not touch the flash
<whitequark[cis]>
in this case you might be able to use the flash with a header
<whitequark[cis]>
I have mentioned it at the very beginning that in-circuit programming of SPI flashes is very fraught and it is completely normal, expected even, to get a frustrating result like yours
<whitequark[cis]>
I've tried doing it dozens of times on many boards and almost all of them behave weirdly like this, pin header or not
<js[m]>
hm, my experience with laptops has been pretty good
<whitequark[cis]>
I've not actually tried it on many laptops but I recall the few times I did it wasn't very good either
<whitequark[cis]>
I just desolder the flash
<whitequark[cis]>
it's a giant pain to do if you need to do it repeatedly but for a one time dump it's fine
<js[m]>
it worked for me on many Lenovo laptops and on an ASUS laptop
<js[m]>
in the case of Lenovo, even writing (Coreboot)
<whitequark[cis]>
in general, it is not the right expectation to have that in-circuit SPI flash programming works
<whitequark[cis]>
on like any arbitrary board
<whitequark[cis]>
it requires it to be designed in a particular way and a lot of designers just don't
<js[m]>
I really wonder what's the point of the pin headers for both flashes 😕
<whitequark[cis]>
it seems like Lenovo does do it that way
<whitequark[cis]>
there is likely a reset pin somewhere on them which makes it work
<whitequark[cis]>
it's likely not intended to be user-serviceable
<whitequark[cis]>
and the manufacturer knows exactly what to assert to program it
<whitequark[cis]>
in other words, the header isn't there for you
<js[m]>
hm, this thing has a debug port
<js[m]>
unfortunately, I cannot find out what it does
<js[m]>
maybe that is exactly what you'd use before dumping
<js[m]>
or writing
<js[m]>
the weird thing is that they even advertise the debug port
<whitequark[cis]>
who knows! it could be literally anything
<js[m]>
whitequark[cis]: Nope, completely new ISA, I'd say closer to RISC-V than to MIPS even
<whitequark[cis]>
hm
<whitequark[cis]>
I see
<whitequark[cis]>
try finding a JTAG interface there anyways
<whitequark[cis]>
actually, let me say something different
<js[m]>
js[m]: On the picture you can see they even list the debug port
<whitequark[cis]>
it's on aliexpress? I assumed at first you got it second hand
<whitequark[cis]>
just ask the seller how to dump the flash
<js[m]>
I doubt he'd know 😕
<whitequark[cis]>
they might tell you to go away, or they might give you all the details
<whitequark[cis]>
you should try that, they know quite often
<js[m]>
maybe he'd know if I spoke Chinese
<whitequark[cis]>
it's not like western customer support which tells you to go fuck yourself unless you have a $500k purchase order first
<js[m]>
I asked him on another board that was sold in various variants and one was suspiciously cheap, so I asked what it is, and the response was "it is how to run it" 😕
<js[m]>
but I'll trytt
<js[m]>
* but I'll try
<whitequark[cis]>
I see
<js[m]>
how do I even contact the seller on AliExpress?
<js[m]>
also, I asked Loongson for the official firmware, which they do release for a different board, but only got crickets
<js[m]>
I wonder if they all go silent because technically, this stuff is export banned
<js[m]>
as in, I probably should not have been able to get it
<whitequark[cis]>
then I don't think US sanctions affect you
<js[m]>
nono, China banned export 😉
<whitequark[cis]>
unless there was another sanctions package against Loongson... oh
<whitequark[cis]>
I had no idea
<js[m]>
as in, for me it's definitely not a problem, but it might be for them, so they might not respond in English because nobody outside of China should have gotten it
<js[m]>
OK, I asked the seller for the pinout for the pin header next to the SPI flash. Maybe that revels what reset pin is needed. I also asked for how to dump/flash firmware, where to get official firmware and if there are schematics available. Let's see 🙂