<sb0>
rjo, it met timing (and also does on my machine)
fengling has quit [Ping timeout: 256 seconds]
<sb0>
rjo, the order of module.__dict__.items() is undefined. so there's no concept of a "first" experiment in a module after the python interpreter has loaded it.
tommylommykins has quit [Remote host closed the connection]
FabM has quit [Remote host closed the connection]
bhamilton has joined #m-labs
<larsc>
Is this just me or does Vivado seem to not place registers connected to a IO port into the IOB?
<sb0>
rjo, can you copy cordic to pdq2 (take the latest version from migen as I've made some minor changes) so I can remove it from migen?
<sb0>
we can also create another repository "migen-extras" or similar, but it complicates dependencies
fengling has joined #m-labs
bhamilton has quit [Remote host closed the connection]
bhamilton has joined #m-labs
<ysionneau>
rjo: the ISE minimal tarball I built, based on yours with k7 support added using your stracing script, does not seem to accept to target xc7k325t-ffg900-2 device
<ysionneau>
my guess is that there are some missing files that make xst/other cmd line tools think it's "webpack" and not "system" edition and thus restricted
<sb0>
does the initial ise work on your machine? and the tarball?
fengling has quit [Ping timeout: 245 seconds]
<ysionneau>
yes, my installation does work (I removed entirely webpack and installed the system one)
<ysionneau>
but the tarball I uploaded on sionneau.net does not work
<ysionneau>
either on travis-ci or even on my own machine
<ysionneau>
what I can see in strace logs is that Xst does openat("/opt/Xilinx/14.7/ISE_DS/ISE") , then 2 getdents() then close() and ends up doing write("ERROR:Xst:1817 - Invalid target ")
<ysionneau>
maybe it's just a missing directory
<sb0>
ok, well this has taken a lot of time already and full travis/conda integration isn't a very important feature imo
FabM has joined #m-labs
<ysionneau>
alright I can suspend this task
<sb0>
how are the other ones coming along? any code ready for merging?
<sb0>
by the way we are going to need a simple in-flash filesystem to store the IP address, the default experiment ELF etc.
<sb0>
something like the u-boot variables (I guess)
<ysionneau>
do you want something like a tree hierarchy of variables? or simple list of var=value ?
<sb0>
but it only supports storing ints
<sb0>
simple list var=value
<ysionneau>
ok, could add some type+length metadata before the value
<sb0>
minimizing the number of erases
<sb0>
we can probably assume the list fits in a single sector
<sb0>
the type metadata is not necessary, we know the type from the variable name
<ysionneau>
ok
<ysionneau>
when some value gets changed, we could add the same var=value at the end of the list, which overrides the previous value, then no need to erase for a value chance for instance
<sb0>
yes
<ysionneau>
I don't know if that's the kind of stuff you had in mind
<sb0>
exactly
<sb0>
the end of list can be detected if the "name" field is all 0xff's
<ysionneau>
yep
<sb0>
and it should erase the sector and rewrite all the current values at the beginning, if a write attempt would overflow the sector
<ysionneau>
yes
<ysionneau>
and we don't handle the case where even with no duplicates it's larger than 1 sector?
<sb0>
maybe there is existing code you can recyle, I believe this is a common problem with all those apple-store-of-things-themed embedded gadgets these days
<ysionneau>
we take for granted it won't happen?
<ysionneau>
hehe
<sb0>
how large are the flash sectors on the kc705?
<ysionneau>
lemme have a look
<sb0>
I think we don't have to store more than 8 kilobytes of data altogether
<ysionneau>
1 sector is 64 kB
<sb0>
bytes?
<sb0>
should be plenty.
<ccube>
can I use liteusb/ft2232h classes to create a ft2232h compatible controller on a FPGA? Or what are they for?
<sb0>
when we start having more, we should probably use yaffs anyway
<ysionneau>
yes bytes
<sb0>
yaffs is very easy to use, including on bare metal
<sb0>
actually I wonder if we should just start using it right away, since its only inconvenience would be to bloat the executable by some dozen kilobytes or so, and we have hundreds of megabytes available
<ysionneau>
hummm do you see already future needs that would use a file system features ?
<sb0>
no, but it avoids reinventing another potentially buggy flash config management system
<ysionneau>
I agree about not reinventing the wheel, but here the wheel seems pretty straight forward
<sb0>
and the yaffs code is nice (unlike e.g. u-boot)
<ysionneau>
we are talking about using the SPI flash, right?
<sb0>
yes
<ysionneau>
that's nor flash, yes?
<sb0>
internally? I think so
<sb0>
well if you think that it's easy, go ahead
<ysionneau>
by reading a bit on yaffs on wikipedia it seems it is designed for NAND flash
<ysionneau>
but I don't know the details of yaffs actually
<sb0>
yeah because of that OOB thing
<ysionneau>
yup
<sb0>
but with a bit of adaptation it works fine on NOR
<sb0>
that's what the M1 used
<ysionneau>
yes I remember
bhamilton has quit [Ping timeout: 250 seconds]
<sb0>
ysionneau, ok so are you going to implement a simple key=value store? no FS?
<ysionneau>
I think for a start it's faster, less overhead
<sb0>
with two API functions
<sb0>
read(char *key, void *buffer, int buflen)
<sb0>
returns the actual length
<sb0>
write(char *key, void *buffer, int length)
<ysionneau>
ok se here I don't even bother about types of data, I just treat buffer as a bunch of bytes
<ysionneau>
-se+so
<sb0>
the overhead that matters here is the source code overhead :) importing YAFFS into the ARTIQ repository will add a lot of code, or add a dependency
<sb0>
also, it's GPL
<ysionneau>
+ if it's intended for usage for nand, it has a lot of mechanism we won't use, like wear leveling
<sb0>
yes, buffer is a generic binary
<ysionneau>
ok
<sb0>
yes, but the result of those features is essentially a bloat of the executable
<sb0>
that's all
<ysionneau>
and maybe some slowdown if the code path are actually used
<sb0>
speed is not relevant, in most cases it's just read once at boot and it won't take more than a split second (as the m1 has shown), even with the useless features
<ysionneau>
ok
aeris_ has quit [Ping timeout: 248 seconds]
fengling has joined #m-labs
aeris_ has joined #m-labs
<ysionneau>
ok let's do this then!
<sb0>
which one?
<ysionneau>
the API you proposed
<sb0>
ok
<ysionneau>
where should this code be placed? in artiq/soc/runtime?
<ysionneau>
or in misoc/software/libbase ?
<sb0>
yes, and I think it should fit in a single C file
<ysionneau>
agreed
fengling has quit [Ping timeout: 252 seconds]
jaeckel has quit [Ping timeout: 265 seconds]
jaeckel has joined #m-labs
Gurty has quit [Excess Flood]
Gurty has joined #m-labs
_florent_ has joined #m-labs
kyak has quit [Ping timeout: 265 seconds]
<_florent_>
hi
<_florent_>
ccbube: liteusb with ft2232h phy can be used to interface your SoC with a ft2232h device in slave fifo mode. It provides DMA and UART.
<whitequark>
oh nice
<whitequark>
ft2232h looks very sweet
<whitequark>
can it just expose the descriptors you throw at it, too?
<whitequark>
re flash: why would you want yaffs on NOR? isn't NOR supposed to directly replace parallel memory?
<whitequark>
YAFFS and UBIFS and such would only be useful on raw NAND...
<ysionneau>
NOR flash is slow, and small, but there is no bad block issue (afaik)
<ysionneau>
14:38 < whitequark> YAFFS and UBIFS and such would only be useful on raw NAND... < +1
<whitequark>
slow to write, not to read, but yeah
<whitequark>
and since it has no bad blocks it has no need for a flash translation layer
<ysionneau>
there is JFFS(2?) also which does exist
<ysionneau>
and could be more appropriate on NOR
<whitequark>
(well, it does have bad blocks, just not in any of the first 10000 or so cycles, which is guaranteed unlike NAND)
<ysionneau>
yep, NAND is a nightmare which needs tons of smart software tricks
<whitequark>
on NOR you could use anything, even ext2
<whitequark>
it's just a block device
<whitequark>
afaik JFFS is also a NAND filesystem
<ysionneau>
well, you have the issue of writing by pages and erasing by sectors
<ysionneau>
whitequark: originally it's a NOR filesystem and they added NAND support (but they had a lot of work doing so)
<whitequark>
ah gotch
<whitequark>
*gotcha
<ysionneau>
JJFS2 introduced the nand support
<ysionneau>
JFFS2*
<whitequark>
reading about it--seems original JFFS could indeed be useful on NOR
<ysionneau>
it's used by ecos, uboot
<ysionneau>
and used a lot on small openWRT devices with nor flash
<ysionneau>
(modem/routers)
<whitequark>
*nod*
<ysionneau>
we used that in my previous company, jffs2+squashfs in unionfs
<ysionneau>
but it was on Linux, not baremetal
<whitequark>
right that sounds similar to what my router uses
kyak has joined #m-labs
kyak has joined #m-labs
<ysionneau>
the questions I have about JFFS2 is how far can it be configured to drop the nand features and use it for NOR only
<whitequark>
could you just use JFFS (original)?
<ysionneau>
maybe, I don't know if it's supposed to be using the whole device or if it can just use one sector for instance
<ysionneau>
and in the disadvantages of the "circular log buffer" it seems it wears the device a lot with lofs of erase/writes
<whitequark>
wait if you just need one sector, why bother with a filesystem?
<whitequark>
treat it as a 512-byte (or whatever its size) buffer, use two functions to access?
<ysionneau>
dunno, maybe if we chose to use a file system we could use more than one sector indeed
<whitequark>
reading the log--you just need a key-value store?
<whitequark>
really, get rid of the FS, just treat it as a raw sector, especially on a NOR flash
<ysionneau>
for now yes I think a file system is over engineering for just a key-value store
<ysionneau>
that's why for now I will just use a custom key-value storage
<whitequark>
store it in XML :D
<ysionneau>
right =)
<ysionneau>
or plain text json :p
_florent_ has quit [Quit: Leaving]
<whitequark>
BSON actually would not be a bad idea
<whitequark>
the spec is one page and you don't reinvent the wheel
<ysionneau>
well, why not, but I think here we need something even simpler than what json allows you to do
<ysionneau>
no tree stuff
<whitequark>
just a sequence of length-value pairs then
<whitequark>
can't get simpler
<ysionneau>
sure
* whitequark
is looking at jffs2 in Das U_Boot
<whitequark>
49 /* Ok, so anyone who knows the jffs2 code will probably want to get a papar
<whitequark>
50 * bag to throw up into before reading this code. I looked through the jffs2
<ysionneau>
terminated by the all one 0xffffffff so that the terminaison does not involve burning bits from 1 to 0
<ysionneau>
oh
<whitequark>
I think NOR is 0 by default?
<ysionneau>
FF
<whitequark>
oh, indeed
<whitequark>
yeah. that has an advantage that a new flash is semantically empty
<ysionneau>
and that you can write data on what was previously the "END" marker, without erasing
<whitequark>
yeah, nice too
<ysionneau>
AHAH
<ysionneau>
yes this video is awesome
<whitequark>
you could even override earlier keys by writing later ones with the same name
<whitequark>
and only erase when you're out of space
<ysionneau>
:)
<ysionneau>
look at what we said earlier
<ysionneau>
that's the idea yes
<whitequark>
a log-structured flat key-value filesystem
<whitequark>
MS-DOS 1 for NOR flash
<ysionneau>
it's also a bit of the idea of jffs1 I think (but not sure)
<ysionneau>
ahah
<whitequark>
only needs 2-second resolution timestamps
<whitequark>
re ft2232h: it seems they only support a limited set of modes
<whitequark>
so it's not a "true" phy
mumptai_ has quit [Read error: Connection reset by peer]
imrehg has joined #m-labs
mumptai has joined #m-labs
antgreen has quit [Ping timeout: 264 seconds]
<ysionneau>
sb0: about the read() return value, would you rather want it to be the size which has been copied to buffer (therefore max is buflen in any case) or would it be the real size of the flash stored data? (which can be > buflen and can be a good indicator for the caller that data in buffer is only partial and it needs to call read() again ??
<ysionneau>
I would think 2nd solution is better since it gives you the information that more data is out there
imrehg has quit [Quit: Leaving]
<whitequark>
normally the read() call returns how much data was read
<whitequark>
I think it would be bad to deviate from this very common API call
<whitequark>
you could easily add stat() or maybe just another parameter like read(..., size_t *remain)
<ysionneau>
hum hum
<whitequark>
(the latter looks nicer to me)
sh[4]rm4 has joined #m-labs
sh4rm4 has quit [Ping timeout: 265 seconds]
<rjo>
sb0: #98 did not meet timing. afaict the gateware was the same.
<rjo>
sb0: re artiq_run. i was convinced there was a sorted() in there before. will fix.
<rjo>
you guys seem to systematically suspect conspiracy in quantum mechanics experiment.
<rjo>
sb0: yes. you can delete cordic from migen. but then lets please move the stuff that is deleted from migen to misoc. there are already many things in there that can be used outside a soc.
<rjo>
ysionneau, sb0: if you are starting with flash for the default experiment, keep in mind that there might be other "files" like these in the future: big ro static data and other building block experiments that we do not want to transfer each time. But I think that these might happily live in SDRAM and be uploaded on every boot. But anyways. there will be a need for persistent named data between experiments.
<rjo>
sb0: i you made it an error. that's fine.
<rjo>
s/i you/i see you/
antgreen has joined #m-labs
antgreen has quit [Remote host closed the connection]