<wolfspraul>
which makes me wonder whether the m1, theoretically, could support this 'MHL signalling'?
<wolfspraul>
no idea :-) (and the standard doc costs 100 USD...)
<wolfspraul>
just thought I post it here for completeness/reference. if MHL becomes more common over the years, maybe it could be interesting to support it, if technically possible
<whitequark>
wolfspraul: I guess it has HDCP
<whitequark>
well, it certainly does
<whitequark>
won't that make it "not open" ?
<whitequark>
wait, Samsung Galaxy S 2 has it
<whitequark>
I know it
<whitequark>
it's not a new interface whatsoever
<whitequark>
just a connector which has both USB and HDMI and is compatible with micro-USB
<whitequark>
nothing more
<wolfspraul>
:-)
<wolfspraul>
relax
<wolfspraul>
a number of phones support MHL, from Samsung, LG, HTC
<whitequark>
now that I read further into it, looks like it is
<wolfspraul>
have you read the wikipedia article about it? I think that's a starting point
<whitequark>
but I don't quite get how they squeezed USB, HDMI and some other interface into such a tiny connector
<wolfspraul>
I'm just saying I wonder whether m1 can theoretically output that 'MHL signalling'
<wolfspraul>
which probably depends on performance, usb tranceiver, client/host issues, details in the standard, etc.
<wolfspraul>
what is the lowest resolution supported, and so on
<whitequark>
ah ok
<wolfspraul>
the standard is connector-agnostic, it's just a standard/protocol to send video + audio over 'low pin count' interfaces
<wolfspraul>
so for example it can use a micro-usb connector, but when activated there will be no usb protocol over those wires, but MHL instead
<whitequark>
hm, interesting
<wolfspraul>
you can buy a cable with micro-usb on one side and hdmi on the other for 5 USD, that cable includes some chip from Silicon Image to convert MHL back to proper HDMI
<whitequark>
oh, really? I bought it, but it hasn't arrived yet
<wolfspraul>
well that is my assumption that that's what's going on
<whitequark>
well ok, I'll disassemble it then
<wolfspraul>
what blocks m1 from supporting mhl? probably a number of things
<whitequark>
also I have schematics for SGS2
<whitequark>
if you want to look at it
<wolfspraul>
access to the standard, implementation in the soc, memory bandwidth, usb client/host or transceiver issues
<wolfspraul>
and probably more :-)
<wolfspraul>
but there is a standard, that's all I wanted to say, and it seems to be picking up some speed
<wolfspraul>
I don't even know how open this standard is (mhl). the doc is 100 USD? ...
<wolfspraul>
it's so low that it becomes a nuisance to even talk about it, but hey it's not 0 still. argh. anyway.
<wolfspraul>
whitequark: SGS2? that's some phone? no sorry, not interested but thanks for offering.
<cladamw>
wpwrak, J24 5*2 pins header is for usb E/F ports. ;-)
<cladamw>
Figure 12.a and 12.b shows up usb cable and/or front panel industry design for example. so if you agreed, I'll now change J24.10 pin to NC, and J24.9 pin to mark as 'KEY' but also NC in schematic. is it okay ?
<hypermodern>
Greetings friends, does anyone have some video of the milkymist one in action in a club setting or at a party where it's in the field rather than in a house/demo in a conference?
<wolfspraul>
hypermodern: can you search for milkymist on youtube?
<wolfspraul>
don't have my vpn running at the moment :-)
<wolfspraul>
can't access, wait I check a little later
<hypermodern>
Thank you
<wpwrak>
wolfspraul: we have the expansion header. don't underestimate its power ;-)
<wolfspraul>
is that regarding MHL?
<wpwrak>
yes
<wpwrak>
we can always make little boards that interface from whatever to something that works great with M1
<wolfspraul>
maybe it's even possible over the existing usb connectors?
<wolfspraul>
but probably not because ours are host - not sure
<wpwrak>
and the USD 100 standard may have additional royalties if you dare to implement it
<wolfspraul>
may
<wpwrak>
i doubt MHL would be happy with just full-speed D+/D-
<wolfspraul>
sure not
<wpwrak>
i'd consider the USD 100 price tag fair warning that there will be more toll booths along the way :)
<wolfspraul>
nah
<wolfspraul>
the SD spec costs 1000 USD
<wolfspraul>
should we rip out the sd card?
<wolfspraul>
ah
<wolfspraul>
8:10 card :-)
<wolfspraul>
anyway I found it and I thought it may be interesting one day - MHL
<wpwrak>
(D+/D-) so our problem would be less the host (although it may be too) bit more the link speed
<wolfspraul>
sure
<wpwrak>
(sd) yup. ripped out the sd card and put the 8:10 card there instead. all virtual. if you don't look very carefully, you could never tell what we did. even the text that clearly says "8:10" looks like "SD" to a lot of people. kinda like the FNORDs :)
<wpwrak>
hmm, does adam read the backlog ? fire and forget gets a tad inconvenient ...
lekernel_ has joined #milkymist
xiangfu has joined #milkymist
cladamw has joined #milkymist
<wpwrak>
hah ! here he is :)
<wpwrak>
cladamw: the intel document is a great find !
<cladamw>
so did you agree on pin9 & pin10 ?
<wpwrak>
and yes, i agree with everything it says :) my suggestions for the header so far have been mere guesswork
<cladamw>
okay, meanwhile I'll check the coupling capacitor from both intel files to know if our decision on 120uF is good or not. Also i temporarily selected http://octopart.com/partsearch#search/requestData&q=69192-110H
<cladamw>
for J24 5*2 headers with p/n: 69192-110HLF, just for temporarily candidate but not final. ;-)
<wpwrak>
you can perhaps even find one that's pre-keyed
<wolfspraul>
they are easily available in all sorts of conversion types, and I think increasingly so
<cladamw>
120 uF is recommended from usb org, but alternative like 220uF or more for two port with ESR is also okay.
<wpwrak>
kewl
<wolfspraul>
just to follow up (you said you hadn't seen them)
<cladamw>
yup...i tried to find a pre-keyed, but not found yet, maybe my sorting skill is not right. ;-)
<wpwrak>
i don't mind more :)
<wpwrak>
finding keyed headers is a bit of a nightmare. there may be plenty of needles, but the haystack is huge ...
<cladamw>
wpwrak, worse case i can just put that pin 9 out myself. but it's okay we can still have time to find out before gerber out. :)
<wpwrak>
yeah. a wire cutter goes a long way ;-)
<cladamw>
(V32, V33) to be DNP too since no LNLVLOUT out, my fault.
<cladamw>
(U8 value) from TSOP4838 to TSOP34838, also my fault. :(
<cladamw>
i updated them in latest one.
<wpwrak>
(V32, V33) ah, good catch. i wonder if we shouldn't DNO C4,5,7,8,14 too
<wpwrak>
(U8) good catch too :)
<cladamw>
(C4, 5, 7, 8, 14) i think those inputs DC block capacitors maybe just you 'werner' will try to give a hand on them. :-)
<wpwrak>
mmh ?
<cladamw>
so if M1r4 don't have them, worse case one feed audio signal by a 1uF by themselves ?
<cladamw>
or you want directly removed them ?
<wpwrak>
oh, we could just DNP them
<wpwrak>
freedom of choice ;-)
<cladamw>
hap..okay. let's DNP them. :-)
<cladamw>
I'll update.
<cladamw>
(C22) wpwrak DNP too ? it's for MONOOUT.
<wpwrak>
yeah
<cladamw>
okay :)
fpgaminer has joined #milkymist
<wolfspraul>
wpwrak: I kept hearing from several sides now complaints about m1 connectors on all 4 sides
<wolfspraul>
and you mentioned it too the other day
<wolfspraul>
so what do you propose?
<wpwrak>
for M2, change the form factor from square to rectangle. then put connectors on front and rear only. mainly rear.
<wpwrak>
i would also move to panel-mounted connectors, for better mechanical stability. but that's a bit expensive
<wpwrak>
or "more expensive". hopefully not horribly so
<wolfspraul>
ok let's go through. rectangle - which aspect ratio do you have in mind?
<wolfspraul>
connectors mainly on back? why? you may as well argue for having them mainly on the front, no?
<wolfspraul>
panel-mounted? don't know what you mean
<wolfspraul>
you mean that the connector should make a fixed connection to the side wall as well, in addition to being soldered to the PCB of course?
<wpwrak>
aspect ratio depends on many factors. maybe something around 1:2. i'd size it such that an lcd with touch panel fits. borders would depend on the mechanical structure
<wpwrak>
(front) except that the vj will pump into them a lot more :)
<wpwrak>
(panel-mounted) yes. screwed to the sidewall. so when your vj bumps into the connector, the sidewall takes the hit and not the PCB
<wpwrak>
s/pump/bump/
<wolfspraul>
then you could also argue for upward-facing connectors, that's what a lot of dj stuff has
<wolfspraul>
we have that already for dmx and video-in
<wpwrak>
yes, upward is an option. more expensive. and needs a bigger base unit
<wolfspraul>
why bigger base unit?
<wpwrak>
if you have a panel on top, you need some space to avoid bumping into the upward-facing connectors
<wpwrak>
i think the common theme emerges ;-)
<wolfspraul>
don't understand, sorry
<wolfspraul>
bumping into upward facing connectors?
<wpwrak>
if you don't have a panel on top, you can of course do as you please.
<wolfspraul>
let's assume there is a touch screen in the middle, and on the side there is an upward facing USB connector where someone may stick a usb storage into
<wpwrak>
if we add an lcd panel, you'd have your hands on the M1
<wolfspraul>
of course they wouldn't want to hit the stick from the side
<wolfspraul>
but that is a very typical setup of DJ equipment
<wolfspraul>
it's just like another knob
<wolfspraul>
everything on the top side is naturally upward facing
<wpwrak>
yes, but they usually put the plugs where you don't hit them
<wolfspraul>
nah
<wolfspraul>
not from what I've seen so far
<wpwrak>
e.g., on the very top, with no or only auxiliary controls
<wolfspraul>
if there are other knobs, buttons, whatnot, you also cannot randomly hit them
<wolfspraul>
either it's a button or not :-)
<wpwrak>
knobs tend to be relatively flat. if you hit them, not much happens. try that with your usb stick :)
<wolfspraul>
they are small nowadays, smaller than a typical encoder
<wolfspraul>
I think upward facing makes the board hard to embed in an installation/object/larger something
<wolfspraul>
in general
rhinoplatform has joined #milkymist
<wolfspraul>
because connectors on the sides just extend the board along existing dimensions, whereas upward facing connectors open up the 3rd dimension
<wpwrak>
may also be harder to get the parts to the PCB. e.g., you need to height-match them all. see the jtag experience, just MUCH worse :)
<wolfspraul>
yes
<wolfspraul>
or they all sit on expansion cards :-)
<wolfspraul>
all glue circuitry that goes with that connector on that card as well, the base board becomes fpga+memory only
<wpwrak>
i see that you learned a lot about mechanical stacking at openmoko ;-)
<wolfspraul>
ok, so we make changes in small practical steps - good
<wolfspraul>
:-)
<wpwrak>
why simple if we can make it ruinously complex ? ;-)
<wolfspraul>
cost down, highlight milkymist and performance as much as possible
<wpwrak>
sounds good :)
<wpwrak>
rear/front are relatively easy. standard components, no adapter boards, only need a few screws
<wpwrak>
the main issue is to avoid mechanical stress just from the static setup. not sure how to do this properly. maybe it's something you don't have to worry much. maybe it is.
<wpwrak>
of course, if it should turn out that there is no "typical" effect, even better ;-)
kyak has joined #milkymist
kyak has joined #milkymist
Martoni has joined #milkymist
<wolfspraul>
wpwrak: since we are tentatively planning a nor->spi switch somewhere on the horizon, I was wondering about SPI flash size. should we make it a small flash and divert to a second mmc for the bigger part?
<wolfspraul>
what would your ideal spi boot process look like?
voidcoder has joined #milkymist
* lekernel
is fine with pesky memory cards as long as someone else's code takes care of it
<wolfspraul>
that is 100% fair
<wolfspraul>
don't worry, I think we are realistic
<wolfspraul>
if we can go to migen and get faster memory, that's AWESOME! :-)
<wolfspraul>
plus I am only trying to understand and document werner's thinking, it's not that we have to make this decision anytime soon
<wolfspraul>
but I think most spi flashs are rather small
<wpwrak>
yes, small SPI flash followed by MMC sounds good to me
<wolfspraul>
there you go
<wolfspraul>
thanks! :-)
<wpwrak>
MMC also has more bits -> ought to be faster :)
<wpwrak>
(bits) bus width
<wolfspraul>
we save pins from removing the nor, guess we can throw them right back into the game with a 2nd mmc? :-)
<wolfspraul>
or if that's too wasteful, then the first mmc we have now...
<lekernel>
yes, and various operating conditions (SDR/DDR, bus voltage, clock rates, timings, ...) and commands to select them that are a charm to get to work with all cards
<wpwrak>
we still save lots of pins even if we add five MMCs ;-))
<wolfspraul>
we don't need to support all cards
<wolfspraul>
not at all
<wolfspraul>
that's a design/communication decision whether we even tell people that this chip is removable...
<wpwrak>
lekernel: it doesn't work that way. we pick the card that works and ship with that one ;-)
<wolfspraul>
yes
<wolfspraul>
we do that in rc3 already, every rc3 has a formatted and working 2gb mmc card inside
<wolfspraul>
except for a few bare-board developer boards I sold to people who are supposed to fix bugs anyway :-)
<wolfspraul>
(not that I am that cruel, but I only bought 85 or so of the 'right' cards and quickly ran out of them -> have one only for each retail box)
<lekernel>
wpwrak: by the way, there are quad-bit "SPI" memory chips that are becoming quite common too
<lekernel>
and xilinx fpgas support them for configuration
<wpwrak>
lekernel: oh, cool. so no worries about boot speed.
<wolfspraul>
my question about actual expected boot speed difference was unanswered the other day
<wolfspraul>
I keep hearing "nor is faster"
<wolfspraul>
20 times
<wolfspraul>
but not once an actual estimated number
<wolfspraul>
that makes me suspicious :-)
<wolfspraul>
maybe it's just a few hundred ms?
<lekernel>
well, NOR gets the FPGA configured in < 500ms
<wolfspraul>
if m1 would boot from spi today, how much slower would the boot be?
<lekernel>
maybe even a lot less
<wolfspraul>
(estimated, of course)
<wolfspraul>
because funny enough, I also ran into people that happily tell me "I boot from spi, it's faster" :-)
<lekernel>
but of course, if SPI is 4 times slower, it won't make much difference on a ~20s boot
<wolfspraul>
to which I can only smile back "m1 boots from nor, it's faster"
<wolfspraul>
how much?
<wolfspraul>
btw - the boot time on recent builds is dramatically improved!
<lekernel>
if SPI is 4 times slower, well, < 1.5s then *g*
<wolfspraul>
how do you get to that number?
<lekernel>
but I don't know. the answer is somewhere in FPGA and flash datasheets ...
<wolfspraul>
I am just saying I always hear "faster"
<wolfspraul>
but never an actual number
<wolfspraul>
and I have met people who happily say the opposite
<wolfspraul>
just saying
<wolfspraul>
experienced board-level designers
<lekernel>
no, I'm saying under the assumption that SPI is 4 times slower, it would increase the boot time by less than 1.5s
<wolfspraul>
but I feel no urge to know an exact number
<wolfspraul>
my feeling is that the difference cannot be much
<wolfspraul>
:-)
<wpwrak>
if it was glacially slow, we'd see more people using NOR
<wpwrak>
and ours isn't even a particularly big FPGA
<wolfspraul>
if it's 280ms, the difference shrinks to 840ms (with the 4 times slower assumption)
<wpwrak>
maybe we can also squeeze the bitstream a bit :)
<lekernel>
no, it'll become larger, not smaller
<lekernel>
we'll also want a bigger FPGA
<wpwrak>
will even a low-occupancy bitstream have to grow ? i.e., does it have to touch all the control bits ? or are there some optimizations ?
<lekernel>
but we won't stick to low occupancy :)
<wpwrak>
well, we'd pull in a small loader and then switch to MMC, no ?
<wolfspraul>
yes i agree we should focus on milkymist soc power and fpga power, those are dollars well spent for the manufacturer and user of the product
<wolfspraul>
in other words - larger fpga - yes, sounds right
<lekernel>
and the only possible "compression" is removing empty frames. a frame is empty only if the 16 (iirc) slices that it controls are entirely unused.
<wpwrak>
that sounds like a useful compression to me
<lekernel>
so even if you have only ~50% occupation, most frames will be used - unless you put a lot of constraints on the placement, which are detrimental to speed
<lekernel>
ah, and bootstrapping a bitstream from memory card is messy
<Fallenou>
add an AtTiny24 ? :p
<wolfspraul>
you mean the entire bitstream has to fit into the spi flash for sure?
<lekernel>
because you don't want to erase the circuit reading from that card
<Fallenou>
*joke*
<wolfspraul>
Fallenou: heart attack!
<lekernel>
it's possible to do, but quite difficult. not worth it imo.
<wolfspraul>
(actually I'm cool about whatever option that moves us forward :-))
<lekernel>
much simpler to pick a flash chip that can store the entire bitstream, and the BIOS
<wpwrak>
we'll need some engineering challenges for the future :)
<wolfspraul>
got it
<Fallenou>
attiny was able to load the fpga with bitstream on sdcard in 5 seconds :p a bit slow
<wpwrak>
and tricky placements constraints sound like a good exercise for llhdl :)
<lekernel>
well let's not throw in more chips. a larger flash chip solves the problem in a very simple way.
<lekernel>
if you're looking for challenges you can have a look at dataflow optimizers in migen :-)
<lekernel>
this stuff can build blazingly fast HW accelerators and enable great GUI/render effects
<wpwrak>
we can test most of this with existing M1s anyway: boot MMC loader from NOR, then switch over
<wpwrak>
hehe :)
<lekernel>
not some obscure FPGA configuration details that no one will give a crap about
<wpwrak>
llhdl should be all about fpga configuration details :)
<lekernel>
yeah well... I'll think again about llhdl when milkymist is popular enough
<lekernel>
llhdl will not get there, migen might
<wpwrak>
llhdl is the revolution :)
<wpwrak>
migen is thriving in conformance
<lekernel>
yeah, for the 100 persons on earth who care about this stuff
<wpwrak>
i think it's a bit more :)
<wpwrak>
and openness should get a lot more interested
<wpwrak>
i can't help but think of the pathetic state of operating system research in the 1980es
<lekernel>
who cares about openness. see, all the hype is about the rpi atm, which has proprietary chip + proprietary drivers even
<wpwrak>
or networking, for that matter. basically anything that touched the kernel.
<wpwrak>
i'm sure you can find even more people who can get excited about the love life of paris hilton's dog. who should that affect our objectives ? ;-)
<lekernel>
openness is great to get cool technology done in a brilliant way
<lekernel>
but it doesn't make a great and popular product
<wpwrak>
i think fpgas are cool
<lekernel>
yes, but most people would disagree :-)
<wpwrak>
and i think it does help to make great products
<wpwrak>
(most people) see above, paris hilton's dog :)
<lekernel>
sure
<lekernel>
but I think it is important anyway to build something that really works on the market. and a free FPGA toolchain, however cool it may be to us nerds, will not help much with that goal.
<wpwrak>
i see the toolchain more as a proof of concept for having cracked the process, plus a basis for future development of the configuration process
<wpwrak>
ten years from now, i want gcc or llvm or whatever to know there's an fpga and send code snippets to it :)
<wpwrak>
(and all that without having to do anything funny in my C code)
<wolfspraul>
we believe in open because we think open builds the best products
<wolfspraul>
so now we have to proove this, and as I said before the proof is not so easy, especially to see today
<wpwrak>
the fpga should be used as transparently as a barrel shifter in my cpu
<wolfspraul>
I would never expect a lot of people to care about 'open', what should that be?
<wolfspraul>
you can only care about 'open' if you have a deep understanding first of how things get made, especially in a collaborative way
<wolfspraul>
that alone shrinks you to 1% of the population
<wolfspraul>
but that's no problem as long as the resulting products are great, which they will be
<wolfspraul>
I am very happy that I don't have to invest in a proprietary development, in fact that's why you see so little exciting proprietary new hw
<wolfspraul>
because everybody is afraid to invest on that side too, besides Apple :-)
<wpwrak>
open is an enabler. e.g., see the gazillion of embedded systems running linux. of course, many of them would also be around if open source had never happened, but probably a bit less reliable, more expensive, less feature-rich, etc.
<wolfspraul>
sure, you say that as a professional, and of course I agree
<wolfspraul>
but to reach a regular person, our product has to be great
<wolfspraul>
in terms of its look and feel, explanation, ease of use, documentation, intuitive interface, cool factor, and so on
<wpwrak>
and yes, good point about investment
<wolfspraul>
lekernel: you were right about the rpi being a total broadcom joke btw
<wolfspraul>
I was never excited about the beagleboard, but when I see broadcom's stupid propaganda now I tend to defend even the beagleboard guys :-)
<lekernel>
"we think that the lack of programmable hardware for children – the sort of hardware we used to have in the 1980s – is undermining the supply of eighteen year olds who know how to program"
<lekernel>
huh?
<wolfspraul>
come on, he speaks for broadcom marketing
<wolfspraul>
he is a full-time broadcom employee, interviewed at the broadcom offices, etc. etc.
<wolfspraul>
you have to read between the lines
<wolfspraul>
they are laughing at the freetards
<wpwrak>
it sounds as if he was in the child slave trade
<wpwrak>
or maybe specialty food marketing
<lekernel>
as everyone knows, the percentage of households with a computer has been in steady decline since the 80s
<wolfspraul>
they need the idiots to help them squeeze out a little more profit from their investment, and most importantly to put their commercial partners (who they really believe in) under a bit of pressure
<wolfspraul>
it's broadcom's answer to the beagleboard, which you can see in the shameless comments about "someone in the beagleboard supply chain has to be making loads of cash"
<wolfspraul>
ha ha
<wolfspraul>
or "if we (pi) would make money, they (companies like broadcom) would screw us"
<wolfspraul>
that's a classic, since it's coming straight from a full-time broadcom employee
<wolfspraul>
it's so twisted you need a higher degree in politics and marketing and corporate scheming first :-)
<wolfspraul>
rpi will go nowhere except as broadcom's puppy
<wolfspraul>
it's sad
<wolfspraul>
I hope milkymist can become so attractive that the brightest and most talented in fact join here, which is where they can learn something truly valuable for the future
<wolfspraul>
rather than being exploited by some corporate marketing agenda
<wolfspraul>
they can later always go to these guys to make money :-)
<wolfspraul>
to be fair to their pressure, they are fighting with TI and Qualcomm for survival
<wolfspraul>
the last thing they care about are the sentiments of some foss guys
<wpwrak>
if you want sad, look no further than the daily yahoo news. so your horse died. you let it decompose. then you brought in a necromancer to raise it again. it's "lived" on as a zombie until it died again, of old age. now you want it to have kids ...
<cladamw>
wpwrak, phew~ just finished all link of parts. email sent. i am very sorry about that no real file in there then. ;-)
<cladamw>
wpwrak, not sure if the ods or csv file are good to you to convert into BOOKSHELF
<lekernel>
hmm... anyone knows how to set the TOC depth with sphinx? it obstinately ignores my ".. toctree:: :maxdepth: 3" and all variations of it I tried