tecepe has quit [Ping timeout: 260 seconds]
tecepe has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<cyrozap> azonenberg: You may have already seen this, but just in case you haven't: https://www.qualcomm.com/news/releases/2016/10/27/qualcomm-acquire-nxp
<rqou> holy shit
<pointfree> The PSoC 5LP address range starting at 0x48000000 is used to store startup config, essentially what's in config.hex. It is not documented in the Registers TRM. It is between PANTHER_DEVICE_ID 0x4008001C (device identification, JTAG ID) and FLSHID_RSVD[0..127] 0x49000000-0x4900007F. What's special about it?
<azonenberg> cyrozap: RIP nxp datasheets
<azonenberg> you'll need an nda, volume sales agreement, and your firstborn son to even see the pinout now
<pointfree> download-them-all
<openfpga-github> [openfpga] azonenberg opened issue #53: Support for multiple dev boards in gp4prog/gpdevboard https://git.io/vXTBJ
doomlord has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 2 new commits to master: https://git.io/vXTBw
<openfpga-github> openfpga/master 38a7ae5 Andrew Zonenberg: tests: refactored for new OpenBoard() prototype. No means for actually detecting the target device yet.
<openfpga-github> openfpga/master f0d7587 Andrew Zonenberg: gpdevboard/gp4prog: Added support for multiple devices. Fixes #53.
<pointfree> ah: FLSECC_DATA_MBASE: 0x48000000, FLSECC_DATA_MSIZE, 0x00008000. I assume "FL" means "flash" but what does "SECC" mean?
<azonenberg> single error correcting code?
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 835517b to 4cabe04: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 4cabe04 Travis CI User: Update documentation
<azonenberg> So now i have two devkits plugged into my destkop
<azonenberg> desktop*
<azonenberg> one with a 46620 and one with a 46621 installed
<azonenberg> Time to see if i can tell them apart
<travis-ci> azonenberg/openfpga#158 (master - 38a7ae5 : Andrew Zonenberg): The build passed.
digshadow has joined ##openfpga
<pointfree> azonenberg: That sounds like it. They say you can store configuration and user data in ECC memory:
<pointfree> "If the option ‘Store Configuration Data in ECC Memory’ is enabled, then the device configuration data will be stored in the ECC memory to reduce main flash memory usage. Error correction may not be used when this option is enabled."
<azonenberg> lol
<azonenberg> So, you can steal the ecc metadata page for use as extra main flash
<azonenberg> at the expense of losing ecc?
<azonenberg> that makes sense
<pointfree> "Up to 32 KB additional flash for error correcting code (ECC) "
<pointfree> yes
* rqou is finally retrieving all my email from my old @yahoo.com mailbox
digshadow has quit [Client Quit]
<azonenberg> lol
<rqou> and in the meantime cleaning up anything that might be using it as a backup email
<pointfree> That's a lot of space for just an ECC I would think.
<rqou> because apparently one of the best way to get haxed nowadays is decade-old backup emails
<azonenberg> rqou: yeah i found one of my ancient mail accounts apparently got owned and started sending spam
<azonenberg> no idea how, i just shut it down
<rqou> more dangerous is people that then use it to initiate password resets on live accounts
<azonenberg> yeah well none of my live accounts had that configured on them anymore
<azonenberg> i had migrated off it ages ago
<rqou> i'm currently working on consolidating mine
<pointfree> There's got to be a better way, maybe a FEC?
<rqou> I'm also going to set the "backup for the backup" to my @berkeley.edu email in the hope that it's much harder to social engineer your way into that
<cyrozap> azonenberg: And don't forget NXP bought Freescale last year, so any Freescale docs that NXP hasn't *already* closed could go away because of this, too.
<azonenberg> Lol great
<pointfree> I don't know why they need 32KB for ECC. There's only 64KB of RAM.
<azonenberg> pointfree: this is for flash, i think
<azonenberg> how much flash is there?
<cyrozap> pointfree: The ECC is for the 256K of flash
<azonenberg> if you have per-line ECC
<azonenberg> you have say 32768 64-bit words of flash
<azonenberg> each word with an extra 8 bits of ECC metadata
<azonenberg> Which comes out to be 32KB of ECC data
<azonenberg> this is the same topology that DRAM uses, if you look at a typical ECC DIMM they'll have nine 8-bit wide chips
<azonenberg> with one for correction data
<cyrozap> pointfree: The ECC region is explained fully in the PSoC 5LP Architecture TRM, under "Nonvolatile Memory Programming"
<pointfree> I was only doing a size comparison to show how much waste there is, and thinking about whether we could use a better, more lightweight ECC getting both the flash error correction and that space back.
<azonenberg> pointfree: the thing is
<azonenberg> you need to check the ecc for every single read
<azonenberg> this means you need to have a relatively small ecc block size
<azonenberg> Which means more overhead
<azonenberg> a (64, 72) or (128, 144) code is a sane choice for something like this
<cyrozap> pointfree: That's hardware-based ECC--it can fire an interrupt if it ever detects an error (single/multi-bit), and auto-corrects correctible errors.
<cyrozap> You could roll your own, but I don't think it'd be worth it. If you really need the space, you can just disable ECC. If you really need reliable flash, you turn ECC on.
carl0s has joined ##openfpga
<pointfree> yeah, I suppose I had little need to roll my own ECC.
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<openfpga-github> [openfpga] azonenberg opened issue #54: Device gets stuck in a weird state when gp4prog is run without programming https://git.io/vXTuN
<azonenberg> whitequark: ping
doomlord has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 3 new commits to master: https://git.io/vXTzu
<openfpga-github> openfpga/master 4223d45 Andrew Zonenberg: tests: now PARing PowerRailDetector_STQFN20
<openfpga-github> openfpga/master 177a5ec Andrew Zonenberg: tests: Added PowerRailDetector_STQFN20 (not yet used for anything)
<openfpga-github> openfpga/master 15150b3 Andrew Zonenberg: gpdevboard: can now distinguish between SLG46620 and SLG46621. Fixes #49.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXTz2
<openfpga-github> openfpga/master 67ddb00 Andrew Zonenberg: gpdevboard: now printing pattern IDs as hex
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXTzw
<openfpga-github> openfpga/master 3539b11 Andrew Zonenberg: Fixed typo in last commit
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 4cabe04 to fdb2f0c: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages fdb2f0c Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#159 (master - 15150b3 : Andrew Zonenberg): The build passed.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXTzS
<openfpga-github> openfpga/master a0c7400 Andrew Zonenberg: gpdevboard: OpenDevice now logs bus/port in verbose mode
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from fdb2f0c to 5b3ad34: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 5b3ad34 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#160 (master - 67ddb00 : Andrew Zonenberg): The build passed.
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 5b3ad34 to 3bb2233: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 3bb2233 Travis CI User: Update documentation
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 3bb2233 to 34bc868: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 34bc868 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#162 (master - a0c7400 : Andrew Zonenberg): The build passed.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXTgn
<openfpga-github> openfpga/master 2d38e96 Andrew Zonenberg: gpdevboard: refactoring of DetectPart(), better printing of device IDs
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 34bc868 to ef3d675: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages ef3d675 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#163 (master - 2d38e96 : Andrew Zonenberg): The build passed.
<azonenberg> well that was a lot of spam
<azonenberg> maybe i should have pushed more of those commits in one go, lol
<azonenberg> So, as of now we can detect 46620 and 46621 and tell them apart
<azonenberg> I believe the 46621 is now fully supported (to the extent that the 46620 is, at least) although i have not tested it nearly as thoroughly
<azonenberg> On the 46140 i support the non-shared LUTs, LF oscillator, POR, bandgap, and GPIOs only
<azonenberg> aka, not much of the device
<azonenberg> but i can program it and generate valid bitstreams for the supported subset of features
<azonenberg> I have a new bug, not sure where it came from or how old it is yet
<azonenberg> tl;dr when you run gp4prog without any arguments it can put the board in a bad state where the chip returns 0xFFFFFFFF to all reads
<azonenberg> and you have to power cycle to recover
<azonenberg> Don't yet know what's going on with that yet
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
digshadow has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow2 has joined ##openfpga
digshadow has quit [Quit: Leaving.]
<rqou> so I just updated my debian and now all my fonts look funny
<rqou> don't know if I should bother bisecting the package and filing a bug or not
digshadow1 has quit [Ping timeout: 250 seconds]
amclain has quit [Quit: Leaving]
<azonenberg> Aaand can't reproduce, weird
<openfpga-github> [openfpga] azonenberg closed issue #54: Device gets stuck in a weird state when gp4prog is run without programming or emulating https://git.io/vXTuN
carl0s has quit [Quit: Leaving]
digshadow has joined ##openfpga
digshadow2 has quit [Ping timeout: 250 seconds]
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 3 new commits to master: https://git.io/vXTr2
<openfpga-github> openfpga/master c60f24b Andrew Zonenberg: gp4prog/gpdevboard: Make sure to turn off pin 14 VCCO_2 power if we're not using it
<openfpga-github> openfpga/master 9997fc0 Andrew Zonenberg: gpdevboard: Lots of work on multi-board support. Seems to have some bugs detecting 46620/46621.
<openfpga-github> openfpga/master 7c45065 Andrew Zonenberg: Fixed indentation
<azonenberg> whitequark: so it seems i have a bug doing a socket test after using a siggen on a pin
<azonenberg> in particular, i can't ever turn it off :(
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from ef3d675 to 77c3bec: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 77c3bec Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#164 (master - 9997fc0 : Andrew Zonenberg): The build passed.
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXToN
<openfpga-github> openfpga/master f070c13 Andrew Zonenberg: gpdevboard: Improved detection of SLG46621
<openfpga-github> [openfpga] azonenberg opened issue #55: Once a SLG46621 is detected, dev board can't use pin 14 for logic anymore https://git.io/vXTKJ
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 77c3bec to e29df20: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages e29df20 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#165 (master - f070c13 : Andrew Zonenberg): The build passed.
<azonenberg> huh still having issues here...
<openfpga-github> [openfpga] azonenberg commented on issue #55: Temporary workaround for initial testing: Drive pin 14 with TP_VDD rather than a siggen. Although this does not allow use of a second (lower) voltage rail it avoids screwing with the siggen config in a (currently) hard to reverse fashion. https://git.io/vXT6v
doomlord has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXT6Y
<openfpga-github> openfpga/master 3972f81 Andrew Zonenberg: gpdevboard/gp4prog: temporary workaround for siggen config issues
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from e29df20 to 036d7a1: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 036d7a1 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#166 (master - 3972f81 : Andrew Zonenberg): The build passed.
massi has joined ##openfpga
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXTid
<openfpga-github> openfpga/master 6d616fc Andrew Zonenberg: gp4prog/gpdevboard: Added ResetAllSiggens() to clear SLG46621 power since for some reason resetting just the one siggen didn't work. Fixes #55.
<openfpga-github> [openfpga] azonenberg pushed 1 new commit to master: https://git.io/vXTip
<openfpga-github> openfpga/master 145d35e Andrew Zonenberg: Removed vestigial function not used anywhere
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 036d7a1 to 5dc5237: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 5dc5237 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#167 (master - 6d616fc : Andrew Zonenberg): The build passed.
<openfpga-github> [openfpga] azonenberg force-pushed gh-pages from 5dc5237 to 1ace319: https://git.io/v6vmV
<openfpga-github> openfpga/gh-pages 1ace319 Travis CI User: Update documentation
<travis-ci> azonenberg/openfpga#168 (master - 145d35e : Andrew Zonenberg): The build passed.
Bike has quit [Quit: quat]
clifford has quit [Ping timeout: 256 seconds]
clifford has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<rqou> offtopic: GNOME is bad at programming
<rqou> I updated my debian and now the lock screen password prompt is only a quarter on the screen in the bottom right
<rqou> it's like they never even smoke tested it
<rqou> (sure, my fault for running unstable I guess)
kuldeep has quit [Ping timeout: 260 seconds]
clifford has quit [Ping timeout: 256 seconds]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
felix___ has joined ##openfpga
kuldeep has joined ##openfpga
LoveMHz_ has joined ##openfpga
clifford has joined ##openfpga
felix_ has quit [*.net *.split]
gruetzkopf has quit [*.net *.split]
LoveMHz has quit [*.net *.split]
gruetzkopf has joined ##openfpga
gruetzkopf is now known as Guest79474
Guest79474 is now known as gruetze
gruetze is now known as gruetzkop
gruetzkop is now known as gruetzko
DocScrutinizer05 has quit [Remote host closed the connection]
DocScrutinizer05 has joined ##openfpga
DocScrutinizer05 has quit [Quit: EEEEEEK]
DocScrutinizer05 has joined ##openfpga
felix___ is now known as felix_
DocScrutinizer05 has quit [Quit: EEEEEEK]
DocScrutinizer05 has joined ##openfpga
doomlord has joined ##openfpga
X-Scale has quit [Read error: Connection reset by peer]
X-Scale has joined ##openfpga
<whitequark> azonenberg: yeah, siggens have weird bugs
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
m_w has joined ##openfpga
doomlord has joined ##openfpga
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
DocScrutinizer05 has quit [Disconnected by services]
DocScrutinizer05 has joined ##openfpga
doomlord has joined ##openfpga
DocScrutinizer05 has quit [Read error: Connection reset by peer]
DocScrutinizer05 has joined ##openfpga
digshadow1 has joined ##openfpga
digshadow has quit [Ping timeout: 265 seconds]
digshadow1 has quit [Client Quit]
doomlord has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
amclain has joined ##openfpga
Bike has joined ##openfpga
mithro has quit [Ping timeout: 256 seconds]
sharebrained has quit [Ping timeout: 256 seconds]
forrestv has quit [Ping timeout: 256 seconds]
reportingsjr has quit [Ping timeout: 256 seconds]
azonenberg has quit [Ping timeout: 256 seconds]
sharebrained has joined ##openfpga
reportingsjr has joined ##openfpga
mithro has joined ##openfpga
azonenberg has joined ##openfpga
forrestv has joined ##openfpga
doomlord has joined ##openfpga
massi has quit [Remote host closed the connection]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
<azonenberg> whitequark: so, the other thing i am now pretty much 100% on
wpwrak has quit [Read error: Connection reset by peer]
<azonenberg> is that the ADC used on the greenpak devboard is referenced to 1.0V
<azonenberg> it gives readings that match the voltage i see with a DMM from 0 to 1V
<azonenberg> then saturates at 1V for anything higher
<azonenberg> for example 0.5V reads ~0.5
<azonenberg> 0.0V reads ~0
<azonenberg> 1.0V reads ~1.0
<azonenberg> 1.8V also reads ~1.0
<azonenberg> Not sure if there's a usb command to change vref to vdd or something
wpwrak has joined ##openfpga
<azonenberg> i mean it makes sense, the DACs, vrefs, etc top out at 1V
<azonenberg> But it means we have no way to distinguish 1V from 2V
<whitequark> azonenberg: hmm
<azonenberg> When you get a chance can you try and see if there is a usb command for specifying ref to 1v or vdd?
<azonenberg> Also look at DistinguishSLG4662X in gpdevboard/utils.cpp
<azonenberg> see if you have any thoughts on how i did that
<azonenberg> basically when i detect a slg4662x from the readback bitstream
<azonenberg> i load an emulation bitstream that pulls pin 20 high
<azonenberg> then set vdd to 1.8 and vdd2 to 0.5
<azonenberg> read pin 20
<azonenberg> if much below 0.5, board fault
<azonenberg> if much above 0.5, its a 46620 since the pin is on the vcore/vcco1 rail
<azonenberg> if around 0.5 it's a 46621 since the pin is on the vcco2 rail
<azonenberg> this is possibly (datasheet unclear) out of spec and i wouldn't want to rely on the INPUT behavior when vcco is that low
<azonenberg> but the output driver appears to work fine
<azonenberg> and the datasheet does say that it's safe to remove and reapply vcco2 while vcc is powered
<azonenberg> and you won't lose config etc
<azonenberg> i would LIKE to be able to use say 3.3 and 1.8 as the detect voltages
<azonenberg> But i cant do that w/o having a wider adc range
<azonenberg> Also, i dont know if i'm damaging the adc by sampling values > vref
<azonenberg> it certainly doesnt seem healthy
<azonenberg> lol
<azonenberg> So looking at the psoc datasheet
<azonenberg> its not 1v, its 1.024v
<azonenberg> so that might explain some of my readbacks being off by a few percent
tecepe has quit [Remote host closed the connection]
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
tecepe has joined ##openfpga
<gruetzko> 1.024V makes for very round mV/count
gruetzko is now known as gruetzkop
gruetzkop is now known as gruetzkopf
digshadow has joined ##openfpga
digshadow has quit [Quit: Leaving.]
digshadow has joined ##openfpga
digshadow has quit [Ping timeout: 250 seconds]
m_w has quit [Quit: leaving]
DocScrutinizer05 has quit [Quit: EEEEEEK]
DocScrutinizer05 has joined ##openfpga
digshadow has joined ##openfpga
digshadow has quit [Client Quit]
digshadow has joined ##openfpga
<azonenberg> gruetzkopf: yeah it does
<azonenberg> whitequark: anyway, it looks like we cannot do analog sampling of values >1V
<azonenberg> it would be nice to be able to read digital values too
<rqou> offtopic: GNOME, how do you even manage to make this happen? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=842423
* azonenberg doesnt click link
<azonenberg> it's gnome
<azonenberg> enough said :p
digshadow has quit [Ping timeout: 252 seconds]
<azonenberg> also wooow
<rqou> i think this bug is related to how gnome or somebody is trying to invent some new concept of "sessions" that didn't exist before
<rqou> and didn't think through all of the possible use cases people might have
<rqou> unfortunately, i have no idea how this part of the stack works
<rqou> it also doesn't seem to be really documented anywhere
<azonenberg> i just dont use gnome :p
<azonenberg> xfce ftw
<rqou> i'm not really using "gnome"
<rqou> i'm using awesome wm + xfce bits + gnome bits
<rqou> so i'm not running gnome shell
<azonenberg> oh i see
<azonenberg> i'm using primarily xfce with xfwm
<azonenberg> i use the gnome calculator and a few other things b/c i never got around to finding good replacements
<azonenberg> but probably will be purging them so i can get rid of gnome libs at some point
<gruetzkopf> i'm using mate + random pieces
<rqou> i don't really care what DE "world" programs belong to as long as they work and do what I want
<azonenberg> yeah same here
<azonenberg> it just seems wasteful to pull in half of gnome for a calculator
<azonenberg> disk space wise
<cr1901_modern> I wouldn't care in principle if you didn't have to effectively install the whole DE's dependencies just to use a single app
<rqou> but don't you know, this is the FUTURE! :P
<rqou> pretty soon you're going to have to download all of the dependencies compiled to javascript and run this in a giant 50MB web browser just to get a calculator
* cr1901_modern has wished for a gvfs alternative in the past, but can't remember why
<rqou> but don't worry, this calculator will be better because it can use The Cloud to idk covert units or something silly :P