<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>
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.
<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>
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 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.
<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
<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