<GitHub171>
[scripts] xiangfu pushed 1 new commit to master: http://git.io/-YzlmA
<GitHub171>
[scripts/master] reflash_m1.sh update the --data parameter when use --qi - Xiangfu Liu
Martoni has joined #milkymist
<cladamw>
wolfspraul, i'll wait maybe 2 ~ 3 days for list reviews, meanwhile to prepare layout notes.
<wolfspraul>
yes, good
sh4rm4 has joined #milkymist
<Fallenou>
cladamw: got your plastic feet for the M1 :) thx !
<cladamw>
Fallenou, hi great ! :-)
rejon has joined #milkymist
wolfspraul has joined #milkymist
cladamwa has joined #milkymist
elldekaa has joined #milkymist
cladamw has joined #milkymist
sh4rm4 has joined #milkymist
elldekaa has joined #milkymist
elldekaa has joined #milkymist
cladamw has joined #milkymist
<wolfspraul>
for the ADV7181C and D sourcing query, I just looked up the suitable p/n for the D, and I think it's ADV7181DBCPZ
<wolfspraul>
so the planned one is ADV7181CBSTZ, and if we go to D, it would probably be ADV7181DBCPZ
<wpwrak>
any word from AD ?
<wolfspraul>
not much variety there, the only other version is a 'W' one for automotive
<wolfspraul>
in the que
<wolfspraul>
queue
<cladamw>
yup, should be BCPZ
<cladamw>
no else p/n choice we could pick.
<cladamw>
i've no news on D version now.
<wolfspraul>
forget D, we focus on C
<wolfspraul>
should have info from shanghai soon
<wpwrak>
ah, one bit of information for the layout house: they can move around LEDs in the matrix as they wish.
<wolfspraul>
who wants a 12 USD analog video decoder :-)
<wolfspraul>
we have to hurry up and improve m1...
<wpwrak>
(12 USD video decoder) ? is the D priced differently from the C ?
<wolfspraul>
all roughly the same
<wolfspraul>
at a time when whole routers or wifi phones cost less than 20 USD after assembly, such chips look like an anacronism to me anyway
<wpwrak>
ah ;-)
<wolfspraul>
but we need the C now, and then move forward. and we'll find it.
<cladamw>
wpwrak, what did you mean about "one bit of ...." ? you meant those reserved leds ?
<wpwrak>
cladamw: no, all of them. if the layout people find the arrangement inconvenient, they can put the LEDs at different places in the matrix.
<wolfspraul>
wpwrak: lekernel where do you prefer the m1 kicad schematics to live - github or qi-hardware ?
<lekernel>
github
<wolfspraul>
I'm fine with that, though I will continue to maintain a meaningful set of services for people to collaborate on hardware at qi-hw, of course
<wolfspraul>
it's just starting actually :-)
<wolfspraul>
but for the schematics histories, we can point to kicad easily
<lekernel>
they have a much nicer interface, and let's happily leave the sysadmin and web development work to other people (who are also better at this...)
<wolfspraul>
sorry I mean point to github
<wolfspraul>
I will maintain the qi servers, but of course github is another scale etc.
<wolfspraul>
in the long run they will end like sourceforge :-0
<lekernel>
what do you mean?
<cladamw>
wpwrak, your meaning is that we don't need to follow 'text' liked I marked 'MIDI RX' or 'RF' to under related connector, but relies on house's convenience and later we make each led's reference. did i realize correctly ?
<wolfspraul>
but in the short run we should use whatever accelerates us now, and makes people happy
<wolfspraul>
so I am totally fine with that
<wpwrak>
cladamw: yup
<wolfspraul>
lekernel: don't know, I think the most important for such sites is to not be too fragmented
<lekernel>
I have nothing against SF, except their interface is lousy and the approval process tedious
<wolfspraul>
and I don't know how github can manage this, but it's their problem now mine
<cladamw>
wpwrak, okay
<lekernel>
github is much better on both: good and fast interface, no approva
<lekernel>
l
<wolfspraul>
gee 'not mine'
<wolfspraul>
:-)
<wolfspraul>
I am ok with github, as I said
<wolfspraul>
even the histories can point there
<wolfspraul>
yes github has been doing outstanding work
<wpwrak>
(SF) "download" links you can't wget ? i lack the words to adequately express my sentiments about that
<lekernel>
wolfspraul: what do you mean, "fragmented"?
<wpwrak>
(github) i guess as long as we use if just as repository, there's little risk. i like all the "value added" things better under our direct control
<wolfspraul>
lekernel: over time github will have to manage a database they understand less and less
<wolfspraul>
that lack of understanding is difficult to deal with, imho
<wolfspraul>
but I really don't care, as i said I think github is doing a great job
<wolfspraul>
I was just asking where we should put those files
<lekernel>
database? it's just a collection of repositories
<lekernel>
there isn't much to understand
<wolfspraul>
ok :-)
<lekernel>
unless I missed something...
<wolfspraul>
no it's good, seems wpwrak agrees as well so that's settled
elldekaa has joined #milkymist
<lekernel>
if we switch to kicad, let's add a second video input and a series-7 FPGA
<lekernel>
and ddr2 or ddr3
<wolfspraul>
he
<wolfspraul>
totally with you
<wolfspraul>
the second video input is done how?
<lekernel>
another adv7181 or similar circuit
<wolfspraul>
how about digital video-in ?
<lekernel>
hmm... why not
<lekernel>
if we get the ddr3 to work correctly, we should have a lot of bandwidth
<wolfspraul>
yes, if the 2nd one would be digital-in that would be perfect as it provides a smooth transition from something that works (adv7181) to something that first needs to be developed and optimized
<wolfspraul>
I haven't read enough about hdmi, displayport, sdi or whatever to know what makes sense though digitally
<lekernel>
what about 1x adv7181 + 2x digital ?
<wolfspraul>
lekernel: did you see the question yesterday - how do you feel about removing the din-midi connectors and including a usb-midi cable instead? (not now, but assuming usb-midi works flawlessly one day)
<lekernel>
the digital ones are cheap as long as we have the memory bandwidth
<lekernel>
it's just a connector
<wolfspraul>
yes
<lekernel>
and some routes
<wolfspraul>
what are the differences between the standards - what exist even? hdmi/dp/sdi?
<lekernel>
btw - can HDMI ports be used both ways?
<lekernel>
input vs. output switchable by software?
<lekernel>
that would be awesome
<wolfspraul>
don't know
<lekernel>
SDI is very specialized
<wolfspraul>
7-series and ddr3 I agree, we should go there asap (after all the things in motion now have settled and we are still alive, of course)
<lekernel>
it's for very expensive equipment on big stages
<lekernel>
we can have it, of course
<wolfspraul>
I know too little about it, need to see whether that's a sales opportunity or not
<lekernel>
but it'd be a different product, on which HDMI makes no sense
<wolfspraul>
[sdi]
<lekernel>
we'd put the board in a rack and sell it for 10000€
<wolfspraul>
I also think we should switch to spi flash instead of nor, finally the various nor problems grow on me
<wpwrak>
(kicad) step 1: make an exact replica of the existing M1r4. step 2: clean up :) step 3: do new fancy things.
<wolfspraul>
how about displayport for video-in ?
<wpwrak>
(kicad) step 1 is important to get people aboard. it's much easier to copy from an existing design than to do something new
<wolfspraul>
so let's first investigate hdmi and dp, I guess (for digital video-in)
<wolfspraul>
wpwrak: no worries
<wolfspraul>
:-)
<lekernel>
displayport looks USB-style messy (just had a quick look at it) and not very common
<lekernel>
hdmi is the most straightforward - even simpler than DVI because it doesn't have the analog pins
<wolfspraul>
one question is also what allows us to create the highest performance
<wolfspraul>
that is something I can judge very badly, but you can
<wolfspraul>
'us' means with our design, fpga, milkymist soc, etc.
<wolfspraul>
makes no sense that we run after some buzzwords only to then deliver mediocre performance
<lekernel>
if we have a DVI input, we might have problems with analog devices (not pun intended)
<wolfspraul>
don't understand
<lekernel>
DVI can work both with analog signals (= VGA) or digital signals (= HDMI)
<wpwrak>
(nor) /me does a happy little dance :)
<Thihi>
DVI-I has both, there is of course DVI-D which only has the digital.
<Thihi>
DisplayPort is not common yet, but it is steadily gaining momentum.
<lekernel>
...and when you have a DVI input, you should be prepared to accept both digital and analog signals
<lekernel>
painful
<wolfspraul>
wpwrak: [nor] the 'grows on me' is mainly how uncommon nor is for that task, and that I don't really buy the 'boots faster' argument
<wolfspraul>
plus it's expensive, plus lots of varieties / sourcing issues
<wolfspraul>
lekernel: how strongly do you feel in favor of the nor flash over a spi flash?
<lekernel>
slide "DisplayPort uses a layered protocol for Isochronous AV Stream Transport" makes me wish for the death of DP already
<lekernel>
sounds like there are revolving doors between the USB and VESA design committees
<lekernel>
ah, also there are electrical level problems too: see the "link training" slide
<lekernel>
I'm not even sure the FPGA IOBs will support it => need for additional transceiver chip etc.
<lekernel>
wolfspraul: (nor/spi) NOR was supposedly less design effort (though with the "corruption" series of bugs this idea has pretty much been proven false)
<wolfspraul>
oh I'm sure the spi switch will be painful as well, but as I keep thinking about these things over time I start to feel when we make a big change like -7 series and ddr3, that one may just go in as well
<wolfspraul>
at least that's the right opportunity without disrupting the milkymist continuity unnecessarily, imho
<wolfspraul>
either then or never :-)
<lekernel>
its main advantage remains that it's easy to do execute-in-place
<lekernel>
which is used to boot the system when the SDRAM is not working yet
<lekernel>
we have the CPU executing code directly from the NOR
<lekernel>
and no SDRAM (which that code is bringing up)
<wolfspraul>
good point, wasn't really on my mind
<wolfspraul>
thanks!
<lekernel>
it can be done with SPI flash too, but we need to implement and debug full gateware-based SPI access
<lekernel>
it'll be slower than NOR, but we don't really need speed for booting, and the CPU cache should keep it quite fast anyway
<lekernel>
another good side of SPI is it frees many FPGA I/Os
<lekernel>
so... well, I guess we should give it a try
<wolfspraul>
how much slower do you think it might be?
<wolfspraul>
the 'fast' was always a nor argument as well, but I never remember any specific number
<wolfspraul>
my feeling is we are talking about a difference of less than 500ms or so
VJTachyon has joined #milkymist
<wolfspraul>
in other words - other factors of a real product boot procedure are far more significant anyway
<wolfspraul>
which of the -7 series fpga and ddr3 chips would you like to start with?
<wolfspraul>
or do you think make the most sense to start with?
<lekernel>
let's say any ddr3-1600 chip from micron
<lekernel>
maybe two of them, for more bandwidth
<lekernel>
and a FPGA slightly larger than what we have now - maybe from the mid-range ones (kintex), if they're not too expensive
xiangfu has joined #milkymist
<lekernel>
btw, if we let the user input a HDCP master key themselves, does the product still violate DMCA? :-)
<wolfspraul>
don't even start with that
<wolfspraul>
I think if we do anything hdmi, we should not mention 'hdmi' *anywhere*
<wolfspraul>
we need to use a new term that just describes the electrical/protocol/video parameters
<Hodapp>
lekernel: by telling me that the HDCP master key can violate the DMCA, you are violating the DMCA.
<Hodapp>
lekernel: fucker, why do you hate capitalism?
<wolfspraul>
I think kintex chips may well cost hundreds of usd
<wolfspraul>
but we need to see
<lekernel>
wolfspraul: I don't know, usually they had the virtex series for that
<lekernel>
it was spartan/virtex
<wolfspraul>
maybe they are thousands now :-)
<lekernel>
now it's artix/kintex/virtex
<wolfspraul>
yes
<larsc>
lekernel: it does not (violate the DMCA). I think
<Hodapp>
larsc: I wouldn't worry so much about actual DMCA violation; I'd worry about anyone with enough lawyers thinking they could make a case that it does.
<wpwrak>
lekernel: this reads a file describing the location of data sheets, then downloads them. after that, they're available locally, under the name(s) we assign. e.g., we could use "dsv adc" instead of "dsv adv7181c". or even things like "dsv q1"
<wpwrak>
some may still consider it illegal, but it's at least a lot less blatant