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