whitequark changed the topic of #glasgow to: glasgow debug tool · code https://github.com/whitequark/Glasgow · logs https://freenode.irclog.whitequark.org/glasgow · revC status: prototype acquired :D :D
puck has joined #glasgow
<puck> hmm. is the pinout for the revB connectors documented somewhere?
<whitequark> the pages are rotated but page 2 matches the A connector orientation
<whitequark> ground/power on the outside
<puck> awesome, thanks! i'll be attempting to run the NAND flash reading code on the OTP memory tomorrow. reading the datasheet it seems like everything should Just Work but i'll probably hit some fun issues either way
<puck> liking the revb so far tho
<whitequark> nice :3
<whitequark> don't forget the pullup on R/B
<puck> yeah, i saw
<whitequark> oh, i put that in the help text? cool
<puck> also as far as i can tell the matrix OTP is also not ONFI compliant, but uses the same values
<whitequark> i have literally never seen an ONFI compliant chip
<whitequark> i've bought an actual bag of USB flashes to disassemble
<whitequark> I haven't yet checked them all but I've put every single NAND flash I desoldered in the socket and none of them were ONFI complian
<puck> oh i might have to play around a bit with the address calculations
<whitequark> do you have a datasheet for the ROM?
<puck> i do!
<whitequark> gimme
<puck> it's 512 byte pages (plus 16 bytes extra)
<whitequark> wow
<whitequark> was this made for SmartMedia?
<puck> i think read1 and read2 just start at 256 bytes offset
<whitequark> I swear this was made for SmartMedia
<puck> and read3 reads only the extras
<puck> no clue
<whitequark> yes
<puck> i found one of these chips inside like a really obscure game console's cartridge
<puck> from my shitty flash memory reading attempts (using either bitbanging on a raspi or a beaglebone PRU, neither to proper success) it actually contains u-boot and linux
<whitequark> what
<whitequark> that's weird as heck
<puck> i'm really really interested in this
<puck> the three cartridges i have are: a hybrid of Winx Club (tv show) plus like. some atari classics, one cartridge that is just full of a tv show, and one that is Rayman 3
<puck> i'm going to end up making like. a full pcb to connect glasgow to a digiblast cartridge, if i don't watch out
<whitequark> ha
<whitequark> puck: yeah, you'll need to implement a different read mode
<whitequark> i'd be interested in this being upstreamed
<whitequark> because i see this in smartmedia as well
<puck> well
<puck> looking at page 14, "sequential row read operation"
<puck> that /should/ cover just sequentially reading an entire chip
<puck> but yeah, arbitrarily seeking to a specific point would require a small amount of patching, shouldn't be too hard
<puck> pretty sure i understand how the code works
<whitequark> ah, i think it's even easier
<whitequark> if you treat this device as one 512+16, then you can seek to any page with Cmd 00
<whitequark> the only thing you need to change is to make reads use Cmd 00 instead of Cmd 00 + Cmd 30
<puck> yup
<_whitenotifier-c> [whitequark/Glasgow] whitequark pushed 1 commit to master [+8/-0/±1] https://git.io/fh9TO
<_whitenotifier-c> [whitequark/Glasgow] whitequark 531eed4 - docs: explain device startup.
<_whitenotifier-c> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/488842795?utm_source=github_status&utm_medium=notification
<marcan> whitequark: you swapped ICE_MEM and FX2_MEM in the docs
<whitequark> uh
<marcan> also --remove-firmware/--no-firmware
<marcan> so the ISO serials, wouldn't it make sense to have some kind of vendor prefix?
<marcan> I mean producing more than one glasgow per second is unlikely, but colliding at some point among different people isn't *that* unlikely
<whitequark> I think a random suffix, maybe 6 digits?
<marcan> that would help
<marcan> but it would still be useful to differentiate vendors I think?
<marcan> also, currently we can't distinguish revC0/C1/etc, do we envision that to be necessary at some point? (I'm not sure)
<marcan> (at this point it doesn't seem likely, but not having space in the serial to do that could bite us in the ass maybe?)
<whitequark> hrm
<whitequark> we could add that i guess
<_whitenotifier-c> [whitequark/Glasgow] whitequark pushed 1 commit to master [+0/-0/±1] https://git.io/fh9Tc
<_whitenotifier-c> [whitequark/Glasgow] whitequark a7b44b8 - docs: fix some typos.
<sorear> pull an ARM and 0xC1
<_whitenotifier-c> [Glasgow] Success. The Travis CI build passed - https://travis-ci.org/whitequark/Glasgow/builds/488850616?utm_source=github_status&utm_medium=notification
jevinskie has joined #glasgow
<marcan> glasgow revÀ and revÁ
<sorear> ha
<whitequark> marcan: okay, i think i'm done for today, maybe
<TD-Linux> has anyone else fabbing glasgows had any difficulty with the fx2 pad?
<TD-Linux> after I finished my batch I did notice that the fx2 was a bit less reliable than the ice40 footprint
<TD-Linux> the bottom of the fx2 has a rectangular pad that doesn't quite match the footprint
<whitequark> hm
<whitequark> that's intentional
<whitequark> the cypress documents are very explicit on the dimensions of that pad
<TD-Linux> yeah looks like the cypress documents match the pad layout, but not the paste layout
<TD-Linux> in particular they put a small bit of paste over each via. the existing footprint has 4 big squares of paste
<whitequark> there was a discussion on kicad list about that
<whitequark> hrm
<whitequark> it's linked from the issue
<TD-Linux> ah ok I see. yeah OK now I agree with the kicad symbol more
<TD-Linux> paste pattern tweaks are very process dependent, so esden may also have more opinions later :)
jevinskie has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<puck> whitequark: hrmm. i think i found a weird bug in the NAND flash stuff
<puck> i added an await self.lower.flush() after the await self._wait() in _do and somehow that improved stability of the data transfer a ton
<puck> not sure tho. i feel like what's going on is that somewhere it writes, doesn't get flushed, and forever waits?
<puck> oops, turns out 2 wait states doesn't ensure a stable dump here
<puck> upped it to 8 arbitrarily to make it reliable
<whitequark> puck: you're not wrong but it's not exactly a bug
<whitequark> can you take a photo of your wiring?