<d1b2>
<timonsku> hi! I'm currently working on the CNC milled case for Glasgow. I got my revC2 from Esden and have my protoype ready and need to test the visibility of every LED. I talked with Esden and it would be quite handy to have a sort of LED test mode for Glasgow, as it is right now it doesn't seem very trivial to just light them up for testing.
<kbeckmann>
is the memory-25x applet regarded as fully functional? i am seeing some strange behaviour with MX25U8035F but of course it can be my setup that's bad. what i see is that after i do a "erase-chip" and then do a "read" of the whole memory, i still see data that's not 0xff. 0x000-0x1ff is 0xff, 0x200-0x3ff is old data, and it keeps repeating like this.
<whitequark>
should be fully functional
<kbeckmann>
hm ok. wonder what is happening here
<kbeckmann>
i am running it at 100kHz to avoid bit errors wrt long wires
<whitequark>
bit errors wrt long writes?..
<whitequark>
oh, *wires*
<whitequark>
can you check the lock bits?
<kbeckmann>
yeah, they are 000
<kbeckmann>
0000 actually
<kbeckmann>
the identify command executes fine
<whitequark>
sfdp?
<kbeckmann>
what is that?
<whitequark>
plug&play
<whitequark>
does it say anything about SFDP descriptors
<kbeckmann>
phew this was a real rabbit hole. i am seeing some weird stuff going on when i experiment with the various erase-program parameters. i will report back when i have something noteworthy. right now it's just different kinds of "bad", seeing curious bit patterns and so on (0x43434343 with a random bit flipped sometimes etc).
<kbeckmann>
it seems the chip doesn't like longer reads than 0x200 at a time. if i lower the chunk_size to e.g. 128, i am able to read out a binary with only 0xff in it.
<whitequark>
hum
<whitequark>
read or fast read?
<kbeckmann>
i tried both and get the same result
<whitequark>
i don't like that
<whitequark>
can you do --trace and check if the vcd looks sane in pulseview?
<kbeckmann>
i can do that
<d1b2>
<Greg> Reading thorugh the datasheet it almost souds like you've entered the OTP mode of the chip.
<whitequark>
whoa, you're right, i totally missed that
<whitequark>
4096/8=0x200...
<d1b2>
<Greg> Once entered, the read/write commads target the OTP sector, address 0x000-0x1FF are user defined (i.e. 0xFF?) And 0x200-0x3FF is factory defined and not user changable.
<d1b2>
<Greg> OP code: 0xB1 enter OTP, 0xC1 exit OTP.
<kbeckmann>
huh.. interesting
<whitequark>
i don't ever send B1
<whitequark>
kbeckmann: are you sure the power in your setup is good?
<d1b2>
<Greg> Do those OP codes overlap with something else? I doubt the chip would startup in that mode.
<kbeckmann>
trying to run with --trace but it doesn't meet timing. 29.49 vs 30.00. is there a flag to run anyway?
<whitequark>
oh. wait. you have revAB?
<kbeckmann>
well.. i am powering it with 1.8v from the glasgow. B0
<kbeckmann>
thanks, that built. however i got another exception `glasgow.gateware.analyzer.TraceDecodingError: at byte offset 513: invalid byte 0x0f for state IDLE`
<kbeckmann>
maybe it hasn't been tested in a while
<whitequark>
no, that sounds like it actually doesn't pass timing
<kbeckmann>
oh ok. so close.
<whitequark>
imean it *could* be a logic bug
<whitequark>
but
<kbeckmann>
hm i keep getting 29.49 MHz every time i run, is the seed constant perhaps?
StM has quit [Quit: No Ping reply in 180 seconds.]
StM has joined #glasgow
<whitequark>
yes, you need to pass -r to disable that
<whitequark>
NMIGEN_nextpnr_opts=-3
<whitequark>
NMIGEN_nextpnr_opts=-r
<kbeckmann>
finally found a good seed, however i get the same exception
<kbeckmann>
my commandline is `NMIGEN_nextpnr_opts='--seed 8' python -m glasgow.cli run --trace program_bad memory-25x -V 1.8 --port A program -P 64 -f counter.bin 0x0`
<whitequark>
hrm
<kbeckmann>
i have made sure to pull the submodules and rebuilt the firmware as well. is it uploaded automatically or does one have to do anything particular to upload it to the fx2? i ran the factory command ages ago (serial number is generated as `B-20181110T213510Z`)
<whitequark>
run `glasgow flash` to be sure
<kbeckmann>
thanks. i tried the tracing again but it didn't help. i have to go now but thanks for all the help. i can see if i can get a trace tomorrow.
<whitequark>
i have used --trace quite a bit recently and it works fine, worked fine on my revC1 here too
<kbeckmann>
oh okay
<whitequark>
that doesn't mean it can't have bugs
<whitequark>
but something's really fishy
<kbeckmann>
sometimes it fails with the offset 513 / 0x0f / IDLE, other times with 516 / 0x00 / DONE.
<whitequark>
i don't like that :/
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
PyroPeter_ has joined #glasgow
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter_ is now known as PyroPeter
_whitelogger has joined #glasgow
<_whitenotifier-f>
[GlasgowEmbedded/glasgow] whitequark pushed 2 commits to master [+2/-1/±8] https://git.io/JkGkc
<kbeckmann>
whitequark: thanks for that fix, this solved the trace problem for me. even if I ran "flash" before, it seems like it didn't have any effect.
<kbeckmann>
wohoo! now the read command works perfectly. so it seems that i was stuck at a really old firmware version on my device, and it didn't update properly even if i tried to force it with "glasgow flash". thanks again for fixing this :)
<whitequark>
kbeckmann: wow, i have not expected that to actually do anything...
<whitequark>
so here's something fun i'm poking at right now
<whitequark>
i discovered that it is not only viable but also aaaalmost easy to do zero-copy USB transfers. yes, in Python. yes, mostly without producing other garbage, too
<kbeckmann>
that sounds very neat..
<whitequark>
basically, i realized that the stream/packet/metadata buffering scheme i painstakingly worked out for smoltcp works almost as-is for USB too
<whitequark>
i have no idea what to expect beyond making a bunch of code a lot nicer. it's definitely not "higher throughput" because it literally doesn't go any higher than this. lower latency? no idea
<_whitenotifier-f>
[libfx2] theedge456 commented on issue #5: i2c bus scan - https://git.io/JkGws
<electronic_eel>
whitequark: nice. I think this will come in handy really for revE. from my tests with the latency benchmark i got the feeling that latency is already very low most of the time, but there are some moments where latency really spikes high. i guess that is usb and the kernel. but it could also be libusb/python or them interfacing the kernel, and that is something that could be improved
<whitequark>
electronic_eel: revE would use Ethernet... so the OS is doing that for us
<whitequark>
there's a reason what i'm doing looks like it's from TCP/IP stack :)
<electronic_eel>
revE will also have usb, and unless we find some solution for 10Gbe, usb will have higher speed than ethernet
<whitequark>
the idea was to use usb for usb ethernet
<electronic_eel>
ah, ok, yeah
<whitequark>
so you get the speed, but you don't have to maintain 2 completely different interfaces
<whitequark>
i mean i'm sure usb will still manage to make that as painful as technically feasible
<whitequark>
so here's something related i wanted to discuss
<electronic_eel>
hehe, yeah, figuring out which of the bazillion kinds of ethernet-over-usb standards to use and what their quirks in the different host osses are...
<whitequark>
we have a "connection layer" that goes through the entire glasgow stack and many of its components don't really agree with each other
<whitequark>
(ethernet over usb) i've heard that cdc-ncm is finally widely supported
<jpa->
yeah, cdc-ncm should work with windows 10, linux and newest mac os x
<jpa->
rndis + cdc-ecm is pretty easy also and will expand coverage to windows 7 and older mac os x
<whitequark>
yup, that was basically the plan
<jpa->
also, because the usb bulk endpoints already guarantee integrity, one can have a device-side tcp/ip that doesn't bother with resends or anything, which simplifies buffer management
<whitequark>
well, we don't *just* have usb
<electronic_eel>
should work, yes. but there could be still problems lurking, like windows not recognizing it if it isn't at the correct control entpoint or something like that
<whitequark>
but i'll just implement tcp/ip once more
<jpa->
electronic_eel: yeah, sure, getting the descriptors right requires a lot of testing
<whitequark>
how hard can it be™
<jpa->
there is always space for one more tcp/ip implementation
<electronic_eel>
@timonsku: you are right that there should be a easy way for testing the leds. but until this is developed, you could hack something together to get it to work for now
<electronic_eel>
@timonsku: for the user leds, have a look at the selftest applet. it currently lights all user leds
<electronic_eel>
@timonsku: so just run the pins-loop test. even if it fails, the leds will be lit. you could also change that in software/glasgow/applet/internal/selftest/__init__.py
<electronic_eel>
for the status leds, you could hack some code in the firmware to enable them. just changing firmware/main.c update_leds() should do the trick
<d1b2>
<OmniTechnoMancer> jpa-: The USB bulk endpoint may already do integrity but does the network stack in the kernel guarantee no drops?
<whitequark>
yes
<whitequark>
this is actually bad if you *want* to have drops, e.g. if you stream LA data or something over UDP
<d1b2>
<OmniTechnoMancer> it doesn't guarantee them AFAIK just tries really hard not to
<d1b2>
<OmniTechnoMancer> so worst of both worlds
<whitequark>
whaaat
<whitequark>
oh, are you talking about NCM specifically?
<d1b2>
<OmniTechnoMancer> Well I mean in cases that practically never come up like you used all the memory
<d1b2>
<OmniTechnoMancer> but I am not certain either
<whitequark>
oh, but you still get -EPIPE, no?
<whitequark>
or would, if you used libusb
<d1b2>
<OmniTechnoMancer> I mean the IP stack?
<whitequark>
I guess the difference is that you don't control how the kernel would recover
<whitequark>
yeah
<d1b2>
<OmniTechnoMancer> for UDP you would likely receive no indication but that is expected, for TCP you would probably get a connection break eventually I guess?
<d1b2>
<OmniTechnoMancer> I suppose I just would not trust the kernel network stack to not have made the assumption that it is better for it to discard a packet in some situation than something else happens because the upper layer is supposed to retransmit if that happens
<whitequark>
yeah, it makes a lot of sense.
<d1b2>
<OmniTechnoMancer> Also I don't know if you want this use case but it would complicate the case where someone has the thing plugged into a different computer to where the software is interacting with it via TCP/IP
<d1b2>
<OmniTechnoMancer> since intermediate networking equipment while it also tries hard not to discard packets may still have losses
<whitequark>
oh also true
<whitequark>
yeah no, retransmits are necessary
<d1b2>
<OmniTechnoMancer> technically the network is unreliable, despite people frequently relying on it being reliable
<whitequark>
it is also very much unreliable in practice, as i've discovered working on smoltcp...
<d1b2>
<OmniTechnoMancer> indeed
<d1b2>
<Attie> +1 on both counts (yes retransmits, and don't expect a network to be reliable)
<d1b2>
<OmniTechnoMancer> electronic_eel: Is revE going to use USB3? because 1Gbe is faster than USB2 HS is it not?
<whitequark>
yes
<whitequark>
ECP5+FX3
<hl>
cursed idea: ECP5 with SATA host interface /s
<whitequark>
*sigh*
<d1b2>
<OmniTechnoMancer> Ah I see
bvernoux has joined #glasgow
<_whitenotifier-f>
[glasgow] PTS93 opened issue #235: LED testing mode - https://git.io/JkZO8
oeuf has quit [Ping timeout: 264 seconds]
egg has joined #glasgow
whitequark[m] has quit [Ping timeout: 260 seconds]
whitequark[m] has joined #glasgow
bvernoux has quit [Read error: Connection reset by peer]