<qu1j0t3> otoh pidgin's problems probably have zero to do with the version control tool :)
<pie_> :D
<pointfree> balrog: You can get the number of base addresses from the cyfitter_cfg.c file of a project: grep 'define CY_CFG_BASE_ADDR_COUNT' codegentemp/cyfitter_cfg.c
<pointfree> (I'm planning on writing some python scripts to do all this later and just use forth on the embedded side)
<rqou> so dumb question: is it now possible to program a psoc without any proprietary gui at all?
<rqou> just arm-none-eabi-gcc and a SWD dongle?
<pointfree> rqou: cyrozap did some openocd support for psoc5lp and the (attacted) kitprog so yeah.
specing has quit [Read error: Connection reset by peer]
<pointfree> rqou: ...but you need to pull in a few patches: https://github.com/azonenberg/openfpga/wiki/UDB-%26-Routing-Examples
<balrog> Fixing up dinner, will check soon
<pointfree> oh and balrog, I forgot to mention that the configdump tool does not dump the pin drive mode configuration at the end of the config.hex. I can add that feature but I didn't yet becaues pin drive modes are straightforward enough.
<balrog> pointfree: I need gforth?
<pointfree> balrog: For now yeah. It should be in distro repositories though.
<rqou> so the reconfigurable logic is just MMIO registers on the arm side?
<balrog> Yep
<balrog> And Cypress provides documentation in the form of two large volumes
<balrog> Not the clearest documentation, but better than most other vendors
<pointfree> rqou: Yes, and as a consequence we can come up with our own, superior bitstream format.
<rqou> but it still needed RE?
<balrog> There are unclear things in their docs
<pointfree> rqou: The routing fabric was undocumented.
<rqou> ah, routing fabric
<rqou> lots of sekrit sauce there
<balrog> pointfree: looking closely at that doc it seems documented in an obtuse non-obvious and probably incomplete way
pie_ has quit [Ping timeout: 255 seconds]
<pointfree> They did provide a list of registers used for routing with no description.
<balrog> Maybe they revised it?
coino has quit [Read error: Connection reset by peer]
<pointfree> balrog: They also have tools from PSoC Creator that run under wine and dump switching matrices: https://hub.darcs.net/pointfree/psoc-cli-tools/
<pointfree> Then the task was to find how the registers and bits map to the switching matrices.
<pointfree> I did that, but I want to verify all of it with scripts.
<balrog> PSoC USB is all MCU right?
<pointfree> Also, if you look at the register addresses in binary you will start to see a pattern with respect to how the bits of an address map to their function. More on that later once you get up and running.
<pointfree> balrog: The PSoC uses hard USB.
<enriq> hi
<balrog> I meant it doesn't require the PLD to set it up?
<pointfree> balrog: Correct. It does not require the UDB array.
<enriq> oh I have to logout. brb
<balrog> So one could write a program that exercised the UDB array and reports feedback over USB HID...
<pointfree> balrog: or you could just use swd + openocd. You would need to route the feedback to a pin such as the one connected to the blue led (2.1) ...or figure out the status registers which can get the signal passing through a route into software.
<rqou> btw why the sudden interest in psoc?
<pointfree> Although it would be a noble deed to write an open source usb driver for the psoc5lp.
<pointfree> rqou: I don't know but I like it :)
<pointfree> balrog: You may already be aware of it but https://github.com/kiml/PSOC_compiler is a good starting point for the arm side of the psoc with a way to include config.hex's.
<enriq> back
<enriq> just a question in case anyone knows
<enriq> FT232H and FT232R are apparently both uarts, afaik R y usb1 and H is usb2
<rqou> careful, H has MPSSE and R doesn't
<enriq> xc3sprog declares to support FT232H
<enriq> so almost certainly xc3sprog would not work with the R
<rqou> R still has bitbang
<rqou> but bitbang is awful
<rqou> MPSSE is less awful
<enriq> I don't know what you're talking about :)
<enriq> I need a dongle and the ones available are R
<enriq> for jtag to coolrunner
<rqou> ping azonenberg
<rqou> can you answer this?
<enriq> meanwhile another question
<enriq> is P == NP?
<enriq> turns out it is not :)
<rqou> yeah that's been making the rounds
<rqou> i'm not qualified to judge it though
<enriq> damm
<rqou> i'm not _that_ hardcore CS
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<balrog> pointfree: back
<lain> CS friend's response to that was "I don't understand it, but it doesn't have enough pages to be real"
<lain> :P
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
clifford has quit [Ping timeout: 246 seconds]
<balrog> lain: what, the TRMs?
<balrog> oh nvm, missed a bunch of chat
enriq has joined ##openfpga
<jn__> the P!=NP thing, i guess
<balrog> yeah I see it now
<lain> yeah
enriq has quit [Client Quit]
<balrog> let's see what people think
enriq has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<balrog> lain: the jury's still out on it apparently
<balrog> which is surprising since you'd have expected it to be refuted by now if it were obviously wrong
<rqou> hmm, maybe i'll go annoy the CS professors here and ask them about it
<rqou> i wonder if they're discussing it right at this moment? :P
<balrog> pointfree: you around?
<balrog> I'm confused on how to compile this :P
<pointfree> balrog: What are you compiling?
<balrog> forth-psoc-utils
<balrog> or do I need a confix.hex from someplace?
<balrog> or are those commands backwards
<balrog> oh wait, that's to turn a .hex into a register map?
<pointfree> balrog: You need a config.hex from a project
<balrog> ahh, I see now
<pointfree> then you convert it to a config.bin
<balrog> this is configdump after all :)
<balrog> you did want me to run some tests too
<pointfree> gforth configdump.4th config.bin <number_of_base_addresses> -e bye
<pointfree> will dump the values, registers, register names.
<balrog> yeah I see now
<balrog> I'm running ahead too quickly.
<enriq> I could use some FT232H based cable with xc3sprog or some xilinx cable clone with impact right?
<enriq> are there xilinx cable clones?
<rqou> there are parallel cable clones for sure
<rqou> idk about the usb ones
<rqou> the parallel cable sucks btw
<balrog> rqou: I recently used the early usb cable (xilinx multilinx)
<balrog> it sucks too
<balrog> but that's what I had :p
<enriq> not counting you need a 1990 pc
<lain> you can get a xilinx platform cable usb clone on ebay for a few bucks
<lain> I have one
<lain> works fine
<enriq> rather expensive
<lain> oh hey it's alice1101983, she's good
<enriq> altera clone cables are like 5
<enriq> that cable from alice is the one you have lain?
<lain> enriq: looks very similar, yeah
<pointfree> balrog: cooking dinner, almost done.
<lain> pointfree: what's for dinner?
<enriq> you use it with impact or xc3sprog
<enriq> hi pointfree
<lain> enriq: I've used it with impact, but these days I mostly use my own programmers so I haven't used it in a long while
<lain> I was using it to program an artix7, and a spartan6. worked fine in both cases
<enriq> your own programmer?
<pointfree> lain: breaded chicken with honey + potatoes, etc :)
<pointfree> o/ enriq
<lain> yeah I usually just throw a ft232h on a board, or similar. I have some code to do jtag with ftdi chips
<lain> pointfree: yum
<enriq> o/
<enriq> oh you might know then
<enriq> ft232r would do?
<balrog> lain: btw anyone have used silabs' ftdi-compatible chip lately?
<balrog> (pinout, not driver compatible)
<lain> balrog: I hadn't heard of that!
<balrog> they still seem to suck at mac driver writing
<balrog> their latest mac driver adds GPIO support and completely breaks uart
<lain> enriq: I don't know ftdi's stuff very well tbh, I seem to recall I'm doing jtag in the MPSSE mode or whatever they call it
<enriq> silabs is cp201 or something?
<balrog> enriq: yes
<balrog> cp210x
<balrog> lain: Adafruit changed to them after the whole ftdi mess
<lain> I hate ftdi, I've just been lazy about making an mcu-based jtag adapter
<enriq> I have one in the mac to connect to arduino
<balrog> FTDI sucks but makes good chips
<enriq> works decently
<balrog> as for Mac drivers... Apple rewrote the driver
<balrog> so if you're using a Mac, chances are you're using Apple's FTDI driver
<lain> cause these days it's probably cheaper to just use a random usb arm mcu, vs. a dedicated chip. which is ironic, given the difference in complexity of the silicon.
<balrog> it apparently is very difficult to write a good USB-serial driver for Mac
<lain> usb-serial in general is a nightmare
<balrog> lain: Arduino moved to using an MCU for USB-serial
<balrog> (an atmega16u2)
<lain> yeah
<enriq> I have a silabs dongle and I installed some driver
<balrog> and that supports USB CDC which doesn't even require a driver on most OSes
<enriq> but I use arduino mini pro so I need a separate usart
<balrog> pointfree: I'm still waiting for gcc-arm-none-eabi to download :/
<enriq> cannot I use my cp210x based dongle to send jtag to a coolrunner ii?
<balrog> probably not since apparently jtag uses mpsse mode?
<enriq> with xc3sprog
<enriq> this is the part of the story that I don't want to learn
<rqou> yeah, everybody's been a bit too busy to work on the "programmer" part of the system
<pointfree> but I'm here
<rqou> > soldering iron on dinner table
<rqou> (yes, i need to work on eliminating cross-contamination too)
<enriq> lol
<enriq> maybe iron has a function
<enriq> like toast chicken
<rqou> but lead has a negative function
<enriq> I haven't had enough to say
<enriq> when I studied electronics when I was a kid, and that was looong time ago, nobody cared about lead, so probably I'm already contaminated
<balrog> lead is a heavy metal that builds up
<balrog> cumulative poison
<rqou> here, let's have Mehdi Sadaghdar explain it: https://www.youtube.com/watch?v=5YBwDNfOaxU
<balrog> haha, Mehdi Sadaghdar
<balrog> saw him give a live performance/demo at Maker Faire two years ago
<rqou> there's also this one: https://www.youtube.com/watch?v=NJRDclzi5Vg
<enriq> lol
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
<pointfree> balrog: alright, I'm back.
<pointfree> So for the tests on live hardware we would need to go through the possible routes to see if any mappings are incorrect: pld config --> pld port interface / or term, macrocells --> hc --> hv --> vs / hs --> dsi vs --> dsi hv --> dsi hc --> dsiinp / dsioutt --> portpins
<pointfree> We'll likely also improve the documentation while doing this.
<pointfree> I just quickly pushed my progress on the pi-dsi mappings https://hub.darcs.net/pointfree/psoc-tabular/patch/c1f85e86eb5328c96486e7dd9213eaaf88f009dd DSIINP and DSIOUTT are there, and that's what we need to light up the led or toggle portpins.
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<balrog> pointfree: okay...
<balrog> pointfree: what are these register names in Cypress nomenclature?
<pointfree> balrog: Which ones? The routing registers have the prefixes like DSI0_ and B1_P5_ROUTE_ in the Registers TRM.
<pointfree> register names*
<balrog> pointfree: 1.3.1163?
<pointfree> balrog: PLD Input Terms?
<balrog> it's titled
<balrog> 1.3.1163 B[0..3]_P[0..7]_U[0..1]_PLD_IT[0..11] PLD_IT
<balrog> very descriptive :D
<pointfree> balrog: B[0..3] is for UDB banks 0 through 3. Only bank 0 and half of bank 1 are implemented https://cdn.rawgit.com/wiki/azonenberg/openfpga/images/udb-banks-and-routing.svg
<pointfree> P[0..7] is for the UDB pairs (only half of them are implemented in bank 1)
<pointfree> U[0..1] refer to one of the UDB's of a pair.
<pointfree> IT[0..11] refer to the 12 input terms of the UDB's PLDs.
<balrog> yeah I see this mess now...
<balrog> pointfree: also where does mergehex come from?
<balrog> ahh, I see now
<balrog> overlooked that :/
<balrog> so do you have a project for me to test?
<balrog> I can write something up myself and start poking at this but probably not today
<balrog> also lol mass storage mode doesn't want to work here
<pointfree> balrog: as in a config.hex?
<balrog> pointfree: I meant something to compile to test e.g. leds flashing
<balrog> or connection
<balrog> and mass storage mode meaning that feature of kitprog
<balrog> ah, the kitprog mass storage programmer doesn't work with the 5LP
<balrog> boo
<pointfree> I'm not sure that the kitprog mass storage feature actually works with the PSoC 5LP devkit. (although supposedly it works with the psoc 4 devkit)
<balrog> it tried but fails with bad usb descriptor
<balrog> tries*
<pointfree> openocd is probably the way to go right now.
<balrog> is patchset 3221 still required?
<balrog> it looks like it's merged
<balrog> I'll test and I'll fix the wiki if it works
<balrog> lol apple removed `telnet` in 10.13
<balrog> I mean you're not supposed to use it anymore right? :D
<rqou> unless you're abusing it as nc
<lain> <3 nc
<mtp> ncat imo
<mtp> 10.12 doesn't have rsh / rlogin
digshadow has joined ##openfpga
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
<balrog> pointfree: well kitprog reset_target doesn't work, and I don't have a wire here to pull P2.2 to 3.3V, and it's late :)
<pointfree> balrog: Try this for now: psoc5lp.cpu mwb 0x40005011 0xD 1
<balrog> LED goes blue
<pointfree> yay!
<balrog> that's PRT2_PC1...
<pointfree> so your setup works but you just need a jumper wire to test it with the logic fabric.
<balrog> yeah.
<balrog> it's too late anyway
<balrog> I'll poke more at this tomorrow
<pointfree> goodnight balrog!
<pointfree> Hmm. psoc5lp.cpu mwb 0x40005012 0x0D 1 ;# drive P2.2 high from swd ... this will be the way to test.
<balrog> yeah I figured you could do that, just too tired :p
<balrog> will try anyway
<balrog> pointfree: yeah the LED lights up
<pointfree> yay
<rqou> i think i saw an EMV "success" for the first time
<rqou> a place that _only_ takes chip cards, in the US
Lord_Nightmare has quit [Ping timeout: 246 seconds]
kristianpaul has quit [Quit: Lost terminal]
kmehall has quit [Ping timeout: 246 seconds]
kmehall has joined ##openfpga
Lord_Nightmare has joined ##openfpga
<azonenberg> rqou: :o
<azonenberg> i've seen places that can take either, but if you have a chip force use of the chip (vs the stripe)
<azonenberg> I have not seen any places that turn away stripe users
<cyrozap> balrog: The instructions on the wiki are a little old--you shouldn't be using "kitprog reset_target" since I eventually figured out how to get the normal reset commands to work with the KitProg.
<cyrozap> And yeah, 3221 is merged, so the only patches you need are to support the 5LP flash, but there's currently a few merge conflicts with that (IIRC).
<cyrozap> balrog, pointfree: I've updated the OpenOCD instructions and that patch so you can build off the master branch.
m_w has quit [Ping timeout: 255 seconds]
m_w has joined ##openfpga
specing has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
laintoo has quit [Quit: bai~]
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 255 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 245 seconds]
teepee has joined ##openfpga
clifford has joined ##openfpga
teepee has quit [Ping timeout: 240 seconds]
teepee has joined ##openfpga
teepee has quit [Ping timeout: 258 seconds]
teepee has joined ##openfpga
enriq has joined ##openfpga
specing has quit [Ping timeout: 248 seconds]
<balrog> cyrozap: what's holding the patch from getting merged to upstream?
specing has joined ##openfpga
teepee has quit [Ping timeout: 248 seconds]
teepee has joined ##openfpga
<openfpga-github> [yosys] azonenberg pushed 2 new commits to master: https://git.io/v7NZA
<openfpga-github> yosys/master 32b67f4 Andrew Zonenberg: Merge https://github.com/cliffordwolf/yosys
<openfpga-github> yosys/master 8644985 Clifford Wolf: Merge pull request #386 from azonenberg/gpak-counters...
<balrog> pointfree: I'm back around btw
<balrog> btw trying to find the PSoC 5 Registers TRM but Cypress removed it!
<balrog> (not 5LP)
<pointfree> balrog: Is this the PSoC 5 Architecture TRM? http://rtds.cse.tamu.edu/wp-content/uploads/2013/03/psoc5_architecture.pdf
<balrog> pointfree: Yep
<balrog> the Registers TRM used to be at http://www.cypress.com/?rID=37832
<balrog> there's a chinese site that seems to have a copy but requires login / dl credit
<balrog> and found it
<balrog> (sometimes Bing is useful)
<pointfree> yay
lexano has quit [Ping timeout: 260 seconds]
lexano has joined ##openfpga
flaviusb has quit [Ping timeout: 276 seconds]
flaviusb has joined ##openfpga
kristianpaul has joined ##openfpga
<zino> balrog: PDF now added to the Wayback Machine.
<balrog> zino: thanks. problem would be locating the URL though
<zino> Everyone here just reads the IRC logs. :)
<balrog> hah, true.
flaviusb has quit [Ping timeout: 246 seconds]
digshadow has quit [Ping timeout: 246 seconds]
flaviusb has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
specing has quit [Ping timeout: 255 seconds]
X-Scale has joined ##openfpga
Hootch has joined ##openfpga
specing has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Hootch has quit [Quit: Leaving]
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 240 seconds]
enriq has joined ##openfpga
<balrog> btw, why PSoC? because an MCU with not only loads of peripherals but a PLD reconfigurable in real time using registers is cool
<balrog> you can have quasi self-reconfiguring logic :P
test123456 has joined ##openfpga
<enriq> It sucks not having time for fpga hobby because of work.... *work*, what a loser I am
pie_ has joined ##openfpga
pie_ has quit [Ping timeout: 240 seconds]
pie_ has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
test123456 has quit [Quit: Leaving]
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
enriq has joined ##openfpga
<cyrozap> balrog: The PSoC 5LP doesn't actually have many hard digital peripherals--most of them are implemented in UDBs.
<balrog> has quite a few of analog ones though
<cyrozap> balrog: And I don't think there's anything in particular preventing that patch from being merged, but it only supports flashing PSoCs with ECC disabled and it doesn't support writing to the ECC flash region. See the comments on the changeset here: http://openocd.zylin.com/3432
<balrog> should it support ECC if ECC is enabled?
<balrog> though I noticed some comments about OpenOCD API issues
<rqou> "just openocd things" :P :P
<rqou> openocd always feels like it supports a bajillion things, all poorly
specing has quit [Read error: Connection reset by peer]
<cyrozap> balrog: Not sure what you mean. Basically, the flash supports two modes: One where you can only use 256k of the flash and all 32k of the ECC space is used as ECC data automatically, the other where ECC is disabled and you can use the extra 32k of space as extra raw flash space at address 0x48000000.
<cyrozap> The problem is, the ECC data space is located in the last 32 bytes of every 288-byte flash row, and occupies a completely different address space from the normal flash data.
<cyrozap> The way OpenOCD works, it can only flash one flash address space at a time. So, either you don't use the extra space, or you do a read-modify-write for every flash row if you're using the ECC space for data, meaning you end up writing to each row twice if you try to flash both flash areas at once.
<cyrozap> rqou: Feel free to rewrite OpenOCD from scratch... in a cave, with a box of scraps ;)
<rqou> nah, i just live with it being bugged
<rqou> actually, afaict all debug tools are bugged, just differently
<rqou> i've been using the black magic probe firmware and it has its own bugs
<cyrozap> I have a list of things I want to fix in OpenOCD. It's very long. The tricky part is, once you think you've figured out how vendors do things, they go and add a new transport protocol (SWD) or some weird time-sensitive debug/test mode acquisition sequence (*cough* CYPRESS *cough*) or a 64-bit mode to their chips (aarch64/armv8).
<rqou> ironically, vendor debug tools are in my experience the buggiest
<cyrozap> You end up running into the inner-platform effect (https://en.wikipedia.org/wiki/Inner-platform_effect), where you eventually write a turing-complete DSL to describe everything a vendor could possibly do with their hardware/protocols.
<cyrozap> Oh, and I forgot to mention:
<cyrozap> FREAKING MULTI-CORE CORTEX-M DEVICES
<rqou> what's wrong with them?
<rqou> i thought cortex-m is supposed to be designed so that that can work?
<rqou> e.g. ldrex/strex
<cyrozap> It's a new thing that I didn't expect to ever exist
<rqou> i thought m4+m0 combos have existed for some time now?
<rqou> except ugh wait m0 doesn't have ldrex/strex, which is fun
<cyrozap> I was thinking more Cortex-M33, etc.
<cyrozap> I'm sure someone will figure it out.
<rqou> oh i didn't even know that existed
<balrog> cyrozap: you can't preprocess the file?
<cyrozap> balrog: They're still in different address spaces, though. The first 256 bytes of a row are in the (I forget, maybe 0x20000000?) address space, and the other 32 bytes start at 0x48000000.
<balrog> but you have to write them at the same time?
<cyrozap> You have to write the entire row at once, but OpenOCD is only aware of one flash address space at a time. The API was designed for things like, if you have a NAND flash and a NOR flash both connected to a target, or an internal NOR flash and internal EEPROM that live in different areas of memory.
<rqou> doesn't nand flash have this same problem with ecc pages where several "normal" pages share an ecc page?
<cyrozap> rqou: But that's handled inside the flash driver and isn't real "data" space, so it's a non-issue in OpenOCD.
<rqou> i thought people usually stuffed FTL (flash translation layer) metadata in there too?
<cyrozap> The problem is that OpenOCD assigns a driver to each flash memory address space, and even if you use the same driver for two spaces, they don't talk to each other, so when provided with something like an ELF file, OpenOCD just flashes one space and then the other, not realizing that it could flash both spaces at once. This is a limitation of the flash driver API.
<rqou> ahh i see
<rqou> so for nand+ecc+metadata it's not actually two address spaces
enriq has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
* pointfree is reading about Majority-Inverter Graphs
<rqou> did you hit the same paper i hit?
<rqou> oh huh no it isn't