<wolfspraul>
wow nice, mwalle contributed a number of usb improvements? did I understand this correctly?
<wolfspraul>
maybe that solves some of the open usb issues wpwrak had?
<wolfspraul>
just trying to understand the significance/use cases...
rejon_ has joined #milkymist
<wpwrak>
not sure about the assignments. maybe they help. the rest of the changes doesn't seem to touch anything that caused trouble. of course, the CRC is very welcome. i found that i rarely/never encountered CRC16 errors, but checking for them is still good.
<wolfspraul>
yeah so we can rule out the lack of crc being the culprit
<wolfspraul>
what problems remain on the low-end now?
dvdk has joined #milkymist
rejon_ has joined #milkymist
fpgaminer has joined #milkymist
<wpwrak>
what remains is something i'd call "confused behaviour" :) all sorts of spontaneous errors that cause packets to be rejected. i haven't been able to identify a clear pattern. it seems more complex than, say, everything shifted by some number of bits.
<wpwrak>
the packets are definitely garbled, but it's not the sort of garbled that looks healthy enough to begin packet processing, only to have it later rejected with a bad CRC
<wolfspraul>
hmm, ok
<wolfspraul>
what about speeds?
<wolfspraul>
do you think m1 can handle the full full-speed now, 12 mbit/sec ?
<wolfspraul>
gotta run for a meeting, bbl
<wolfspraul>
(I understand we don't support bulk mode and probably another dozen details now, just asking whether the pure speed is causing an issue, or whether we can assume that part to be stable and without electrical or signal integrity issues...)
<wpwrak>
the garbling only seems to happen at full speed. besides that, full-speed seems fine
<wolfspraul>
is = might be
<wpwrak>
it doesn't look like a signal integrity problem. if it was one, i would expect CRC errors to happen.
<wolfspraul>
what stops m1 from supporting high-speed then?
<wolfspraul>
just trying to get overview of blockers
<wpwrak>
uuh .... high-speed ... ;-)
<wpwrak>
first of all, the transceiver
<wpwrak>
then i'm not sure the FPGA can drive high-speed, at least not on arbitrary pins
<wpwrak>
then there would probably be many other bottlenecks. don't forget that our LM32 core is extremely slow.
<wolfspraul>
sure, too early to think about maybe
<wolfspraul>
of course we want to build out more low-speed and full-speed instrumentation first...
<wpwrak>
we would also have no way to actually debug it. we can see full-speed on a scope. high-speed would mean flying blind.
<wolfspraul>
good to know that you think the pure speed of full-speed is not causing an issue
<wpwrak>
i'm not sure the FPGA can actually do full-speed. so the pure line rate may also be an issue. the highest data rate i've seen mentioned was 400 Mbaud.
mumptai has joined #milkymist
<lekernel>
if your interface is synchronous, you can have 1Gbps/pin, but clock recovery will be an issue for RX
<lekernel>
but there are high speed USB PHYs, just like there are Ethernet PHYs
<lekernel>
then of course, to take advantage of the speed, you'll need DMA in the USB core etc.
<wpwrak>
hmm, but would we be able to do anything useful with such a fast interface ? i.e., is that an engineering Gbps or only a marketing Gbps ? :)
<lekernel>
yeah, it works for DRAM, after some tweaking of clock phases and such to align the data :)
<wpwrak>
interesting :) when we should also be able to have a faster CPU core, shouldn't we ? perhaps not LM32, though
<lekernel>
the experimental soc successfully does 366Mbps/pin atm (the hard limit of the DRAM chips we have atm is 400Mbps/pin, with the 2.6V power supply)
<wpwrak>
sounds great. what's the rate we have in regular units now ?
<lekernel>
160Mbps/pin
<wpwrak>
nice improvement then :)
<wpwrak>
you've also optimized the higher layers a bit, haven't you ?
<lekernel>
also the new soc will reorder (i.e. after I have fixed all the bugs) the memory transactions, which can also bring an additonal 30-50% increase in bandwidth utilization efficiency compared to the current design
<lekernel>
the CPU core is difficult. LM32 is actually pretty fast already for a softcore.
<wpwrak>
(reordering) that's what i meant. very good.
<wpwrak>
but if we can have a path that runs at 366 Mcycles/sec, there should be a way to pipeline this better
<lekernel>
at some point we'll probably want multiple memory controllers too :)
<lekernel>
in fact, I guess the future M1s will probably use most of the I/Os for DRAM and high speed digital video *g*
<wpwrak>
wide memory buses are the trend for sure
<lekernel>
you can have more performance if you drive the memory chips independently
<lekernel>
and you also avoid long PCB traces on address/command (which aren't shared anymore)
<lekernel>
with the current memory architecture, there's actually an easy solution for this
<wpwrak>
hmm yes, i can imagine that we have many short bursts
<lekernel>
or well, relatively easy
<lekernel>
we share the pool of requests with all memory controllers
<lekernel>
each memory controller picks only requests for their chip (identified by some bits in the address)
<wpwrak>
why share ? the split by address is quite hard anyway
<wpwrak>
unless you invent some bus-sharing or behind-the-scenes-migration mechanism :)
<lekernel>
and then for the data phase, there are simply multiple data buses - and the transaction can appear on any of them (the DMA masters should be ready to provide/read data from any bus)
<lekernel>
phew, no. the split is something like 10 lines of code with migen
<lekernel>
the difficult part is the multiple data buses, but that's not an intractable problem either
<wpwrak>
"hard" = given, unavoidable
<wpwrak>
e.g., address xxxxx00xx would always be on bus 0. so there should be little benefit for sharing requests. at least for throughput
<wpwrak>
maybe you can save a few gates
<lekernel>
yes, sharing actually makes the design a little less complex
<lekernel>
otherwise, each device must have a slot in each memory controller
<lekernel>
and then pick the right one to issue the transaction
<lekernel>
(with the current arch, each device has dedicated issue slots in the MC so that they can push out requests very fast and hopefully maximize reorder opportunities)
<wpwrak>
ah, i see
<lekernel>
also, from the system clock point of view, there are no bursts anymore (because of the DRAM clock multiplication)
<lekernel>
so if issue takes more than 1 cycle, it becomes the bottleneck
<wpwrak>
bursts on the device-to-memoory-controller bus ?
rejon_ has joined #milkymist
<lekernel>
now, arbitrating several devices and issuing unique tags to each transaction in 1 cycle isn't easy wrt timing
<lekernel>
so it's much easier to have dedicated slots
<lekernel>
and issue can NEVER become a bottleneck, since all devices can actually push out their request all at the same time
<wpwrak>
so the slots also determine when each memory controller access the internal bus ?
<lekernel>
the burst length is 4 16-bit data elements sent at the DDR rate 366Mbps/s, which becomes 2 32-bit elements at the 2x multiplied DRAM clock, and finally becomes 1 64-bit element at the system clock
<lekernel>
there would be the possibility to use burst length 8 at the DRAM (and 2 at the system clock), but I don't like that because DDR2/DDR3 will need higher multiplication ratios
<lekernel>
what internal bus? the data transfer one?
<wpwrak>
what's the bus that connected devices to the memory controller ? WB ?
<lekernel>
no, custom
<lekernel>
it's actually quite simple, the MC sends the slot number one cycle before the data
<wpwrak>
does it have a name ?
<lekernel>
yeah, asmibus
<wpwrak>
ah, the MC assigns slots. interesting
<wpwrak>
so the devices need to remember to which slot the data comes back ?
<wpwrak>
(in a read)
<wpwrak>
in a write, you wouldn't need any of this then
<lekernel>
well, it picks slots taking into account the DRAM state and its various timing properties, proceeds with the transaction, and supplies/retrieves data
<lekernel>
so of course, it assigns the slots
<lekernel>
you need slots for both reads and writes
<wpwrak>
slot = time slot on the real memory bus ? i.e., not just a queue position
<lekernel>
and yes, the devices need to store their slot number
<lekernel>
and match it on the data bus
<wpwrak>
but for writes, the device doesn't need to know the slow number, does it ?
<lekernel>
slot = entry in the pool of requests
<lekernel>
writes are reordered too
<lekernel>
well, you could supply the data into the slot as well
<wpwrak>
so write reordering is visible on asmibus
<lekernel>
but it actually makes things more complex
<wpwrak>
does sending slot assignments eat a bus cycle ? or is this parallel to data transfers ?
<lekernel>
it actually means adding a write buffer on each devices, though some may not need it
<lekernel>
no, each device has dedicated access to its slot(s)
<lekernel>
this runs fully parallel to data transfers, and the data bus can have 100% bandwidth efficiency
<wpwrak>
hmm, i still don't get the writes
<lekernel>
actually, in asmibus the only "bus" part is for the data (which is shared anyway at the DRAM I/Os)
<wpwrak>
if you ask the memory controller to assign a slot for an upcoming write, why can't you just do the write and make the assignment internally ?
<lekernel>
because then, the MC has to buffer your data
<wpwrak>
or it this pipelined ? i.e., in on cycle, you do: { dev->mc rw, dev->mc addr }, { mc->dev slot }, plus { mc->dev slot, mc->dev data} or vice versa
<lekernel>
if that data comes from e.g. a block RAM, it doesn't need to
<lekernel>
yes, that's how it works
<wpwrak>
ah, i see. so the buffering would be needed to keep the amount of work per cycle low
<lekernel>
the first part happens on the dedicated slot access
<lekernel>
and the second on the shared data bus
<wpwrak>
i think i got it :)
<wpwrak>
so the "sharing or requests" would be on asmibus. but the MCs would each have their own request tables ?
<wpwrak>
maybe with some layering, to arbitrate asmibus
<lekernel>
no, there's one request pool, and all the MCs have access to it.
<lekernel>
then each MC has its own data bus
<lekernel>
there should be no arbitration on the data bus, otherwise you'll lose bandwidth since only one DRAM chip can talk at a time
<wpwrak>
but the data but is shared, so you need to arbitrate that as well, don't you ?
<wpwrak>
or do you have buffers there ?
<lekernel>
devices should connect all data buses and have buffers
<lekernel>
or just a mux, if they send requests one at a time
<lekernel>
but that's for later. right now we have only one MC
<wpwrak>
yeah, with one MC, you're safe :)
<lekernel>
wpwrak: by the way, unless the German administration has set us another trap, we should have the EHSM room booked for 28-30.12 on Tuesday
<wpwrak>
ah, so i'll miss half the nice mid-summer fireworks
<wpwrak>
but it's good that you finally got there. quite a bit more of a battle than expected, i guess ?
voidcoder has joined #milkymist
mumptai has joined #milkymist
<lekernel>
yeah, that's why it was initially planned for August. and well, technically I'm not there yet.
<lekernel>
who knows if there is some arcane rule that says the university must be closed between xmas and new years
<mumptai>
lekernel, some universities do that, including turning down the heating :-/
<wpwrak>
ah, ask about the heating ;-)
<wpwrak>
and if there's none, maybe about their policy regarding indoors bonfires :)
<mumptai>
hihi
<mumptai>
well, what are the servers clusters for ;)
<wpwrak>
hmm, a conference in the machine room :)
abushcrafterfor1 has joined #milkymist
lekernel_ has joined #milkymist
abushcrafterfor1 has joined #milkymist
<kristianpaul>
wpwrak: faster cpu you mean ie, 200Mhz? :-)
<kristianpaul>
perhaps having a separate FPGA for just lm32 and its conbus... clocked at higer sped?
<kristianpaul>
I always had wonder if we cant achieve better timing just because all the delays routing caused by the whole soc and there is no other cause
<kristianpaul>
may be lekernel now more about it
voidcoder has joined #milkymist
antgreen has joined #milkymist
antgreen has joined #milkymist
abushcrafterfor1 has quit [#milkymist]
abushcrafterfor1 has joined #milkymist
voidcoder has joined #milkymist
voidcoder has joined #milkymist
sh4rm4 has joined #milkymist
sh4rm4 has joined #milkymist
voidcoder has joined #milkymist
<wpwrak>
kristianpaul: yes, 200 MHz or more. if we can do useful and non-trivial things with memory at 366 MHz, why shouldn't the core be able to run at 366 MHz as well ?
<wpwrak>
kristianpaul: e.g., the PFPU approach looks quite attractive: separate register reads from register writes. leave it to the compiler to figure out an efficient instruction sequence.
<wpwrak>
that's what MIPS is all about ;-) you could probably reduce the number of NOPs by using conditional instructions, similar to ARM
<wpwrak>
also, put the MMU into the pipeline, so it doesn't add overhead to the memory cycles
<lekernel>
the memory can only run at 366MHz because I'm using the SERDES
<lekernel>
if you insert logic and routing, delays build up
<wpwrak>
so asmibus (sp?) is slower ?
<lekernel>
system clock is 83MHz
<lekernel>
that's why we have clock multiplication
<lekernel>
and the multiplication only happens at the I/O
<wpwrak>
okay, but couldn't a (radically) different core have a higher system clock ?
<lekernel>
if you use things like lava, probably
<lekernel>
but don't expect miracles either. also this way of doing things is more difficult to develop.
<wpwrak>
aren't there cheats that give you the same level of control in verilog ?
<wpwrak>
oh, sure it's difficult. when has that ever scared the entire population ? ;-)
<wpwrak>
the harder the work, the more the glory ;-)
kristianpaul has joined #milkymist
voidcoder has joined #milkymist
<whitequark>
wpwrak: that's what MIPS was all about, and it utterly failed
<wpwrak>
huh ?
<whitequark>
newer MIPSes only include branch delay slots for compatibility, actually having a workaround inside to make them work
<wpwrak>
the MIPS architecture seems to be pretty popular
<whitequark>
reasons are different. branch delay slots aren't really that useful, depend too much on implementation details, make compilers more complex and bug-prone
<whitequark>
wpwrak: err, I meant "utterly failed on branch delay slots"
<wpwrak>
and we don't need to worry so much about binary compatibility. if the pipeline changes, we can just recompile. different world.
<whitequark>
yes
<whitequark>
just don't overestimate the value of branch delay slots
<whitequark>
practice has already shown that they do more harm than good
<whitequark>
in a certain sense, branch delay slots and other features intended not to stall the pipeline were the reason MIPS is named MIPS
<whitequark>
ah, I got what you mean about "not worrying about binary compat". yes, way easier this way.
<wpwrak>
i you go for heavy pipelining, avoiding them is probably very costly elsewhere
<wpwrak>
s/i/if/
<whitequark>
well, I personally just think that pipeline might very well be stalled for the sake of compiler simplicity
<whitequark>
AFAIK, only quite advanced compilers can make any use of it anyway
<whitequark>
llvm does, gcc not so much
<whitequark>
and they can be quite a source of bugs due to inobviousness
<wpwrak>
code is cheap. fpga power isn't :)
<whitequark>
er
<whitequark>
stalling the pipeline in this case is several logic elements
<whitequark>
and you still have reasons you might need to stall it anyway, e.g. load cycles, so this logic would be routed along the pipeline anyway
<wpwrak>
i would defer loads
<whitequark>
on the other hand, hard-to-find bugs are not cheap
<whitequark>
in terms of possible damage or even work needed to eliminate them
<whitequark>
(defer loads) as in "instruction reordering"?
<wpwrak>
even any register write would be deferred. add Rout, Rina, Rinb would fetch Rina/Rinb in cycle t and write Rout in a cycle > t
<wpwrak>
no. make instructions non-atomic
<whitequark>
(fetch/write) er, doesn't any pipeline execute it like this?
<wpwrak>
yes, but they hide it from the user
<whitequark>
t = EX, t+1 = WB
<whitequark>
hm.
<whitequark>
what do you mean by "showing it to user"?
<whitequark>
make user write "add A, Rina, Rinb";"set Rout, A"
<whitequark>
where "A" is immutable?
<whitequark>
that is, introduce explicit instructions for each pipeline stage?
<wpwrak>
no, more like the Milkymist PFPU
<wpwrak>
treat the result register as an independent channel
<whitequark>
in other words, you want to make a 3-stage pipeline
<whitequark>
fetch, decode, execute
<whitequark>
and make what was a writeback stage an explicit instruction
<wpwrak>
so an instruction says basically: OP args /* to start in cycle t */ result /* of operating finishing in cycle t */
<wpwrak>
perhaps more stages. we also have the TLB
<whitequark>
sure, I just outlined a basic idea
<whitequark>
interesting
<whitequark>
I think this has something in common with VLIW architectures
<wpwrak>
you can represent the writeback as a "separate" instruction. as long as you always pair it with an instruction that starts an operation
<whitequark>
not sure if this is a good idea or bad, through. I need to think about it
<whitequark>
but this indeed sounds interesting
<wpwrak>
it seems interesting enough to be worth trying ;)
<whitequark>
exactly
<whitequark>
hah, every day you learn something new... again, I'll think about it
<whitequark>
now I got to go. bbl
<wpwrak>
and the PFPU works this way. you need to twist your mind around it a bit, but it's something one can handle
voidcoder has joined #milkymist
<mwalle>
wpwrak: wolfspraul: so whats the use of hi-speed usb?
Artyom has joined #milkymist
scrts has joined #milkymist
hypermodern has joined #milkymist
<wpwrak>
mwalle: i think wolfgang was just curious whether we could have it at all
dvdk has joined #milkymist
<lekernel>
wpwrak: this way of doing things is nice for the PFPU because the basic block (unconditional instructions between jumps) is large
<lekernel>
on real software, with a jump every 5-10 instructions or so, VLIW sucks
<lekernel>
unpredictable memory latency does some damage, too
voidcoder has joined #milkymist
<wpwrak>
yes, you probably need to estimate the memory latency and then add buffers for reads that arrive early
<wpwrak>
or just stall whenever the data isn't ready yet. would need some kind of tagging/barriers, though.
<wpwrak>
and to reduce the number of jumps, you could have conditional instructions, like on ARM. in a simplified variant, you would just skip the result phase if the instruction isn't selected
<wpwrak>
but yes, it may be hard to generate efficient code for such a radical architecture
Gurty` has joined #milkymist
<whitequark>
vliw sucks, I just said about it because of similarity
<whitequark>
btw, an architecture with explicit memory wait cycles? I'd say this is _too_ radical
<lekernel>
well it depends, for the pfpu it does not (around 75% of the register file write slots are successfully filled)
<lekernel>
but for a general purpose CPU... it always failed
<whitequark>
yeah, I was talking about GPCPU
<wolfspraul>
mwalle: no specific use, I am very much a believer in fixing bugs one by one, and improving features incrementally
<wolfspraul>
and I can understand Sebastien saying that in general, usb is a complex protocol that removes some of the beauty and power of working with an fpga
<wolfspraul>
having said that, there is a plethora of cheap usb devices, and I believe they will be there for years. so naturally I wonder when/whether/if this or that may one day work.
<wolfspraul>
for example usb webcams, usb video converters (there are nice little dongles you can buy for 5 USD that sample from rca analog video to usb)
<wolfspraul>
by supporting usb webcams, we could immediately support multiple video-ins
<wolfspraul>
by supporting those usb video capture dongles, we could remove the entire video-in subsystem
<wolfspraul>
what else?
<wolfspraul>
usb storage (to supply pictures or videos)
<wolfspraul>
usb audio (could remove the audio subsystem)
<wolfspraul>
usb dvb-t dongles, could mix in live TV
<wolfspraul>
the list goes on. none of this is practical anytime soon, and I don't think usb is the one and only interface, not at all. but that's the background of my question :-)
<wolfspraul>
in reality xiangfu is still fixing bugs related to unsupported keyboards and mice, and that is good
<wolfspraul>
and you just provided a hardware crc check :-)
<wolfspraul>
first step: really support all keyboards and mice that work on a notebook
<wolfspraul>
second step: full support of usb-midi
<wolfspraul>
then we see
<wolfspraul>
what are you thoughts on usb?
<mwalle>
yeah but that should work with full speed too, shouldnt it?
<mwalle>
wolfspraul: dunno, just beginning to explore it ;)
<wolfspraul>
oh sure
<wolfspraul>
but I *think* about everything, right?
<wolfspraul>
even super speed :-)
<wolfspraul>
I am trying to find the best way forward for m1
<wolfspraul>
so I want to look at a lot of options, lot of alternatives
<wolfspraul>
what attracts me to usb is some immediate use cases that people already ask for, such as usb storage
<wolfspraul>
but they are very difficult to implement!
<wolfspraul>
so first - low speed & full speed done right
<wolfspraul>
in fact - only keyboards & usb-midi done right, that'd be wonderful
<wolfspraul>
usb seems complex too, I can understand sebastien's reservations
<wolfspraul>
we could also outsource the usb problem to a separate chip, no? let the fpga communicate with that chip in, what? pcie? don't know
<wolfspraul>
*could*
<wpwrak>
the best way forward with usb would seem to be linux. issues to solve: 1) MMU. 2) turn softusb into a proper host controller. 3) sneak in some optimizations to avoid loading the slow core with too many administrative details / interrupts.
<wolfspraul>
or plug the usb device into a daughter-system like a tp-link 703n router connected to the m1 via ethernet
<wolfspraul>
let the 703n be the m1's usb bridge :-) (werner will experience some of his tooth pain coming back now, I know)
<wpwrak>
how long do you expect to be able to source the tp-link 703n unchanged ? :)
<wolfspraul>
there will be another successor, but sure
<wolfspraul>
just keep in mind that can work very fast, like 'today'
<wolfspraul>
just options, options
<wolfspraul>
mwalle asked, so I explain my thinking
<wolfspraul>
also a dedicated usb chip, it's a possibililty
<wpwrak>
if you want a quick solution, drop in an OMAP ;-)
<wolfspraul>
even if we decide not to do one particular option, we should clearly document and articulate why
<wolfspraul>
so people can understand and hopefully agree and be excited
<wolfspraul>
rather than thinking 'these guys are stupid'
<wpwrak>
the complexity is in the USB stack. so unless the "usb chip" is a complete system (linux or such), it doens't help much
<wolfspraul>
yeah, that's why I mention the 703n
<wpwrak>
unless, of course, you settle for things like FTDI. single-function.
<wolfspraul>
which has a neat usb host connector on it :-)
<wolfspraul>
16 USD for the whole thing
<wpwrak>
and you have zero control of what goes on inside
<wolfspraul>
zero control?
<wolfspraul>
you get spoilt by milkymist soc a little :-)
<wolfspraul>
but yes, sure
<wolfspraul>
we are on the same page
<wpwrak>
if they change something, you won't find out until very late
<wolfspraul>
another thing that keeps popping back up is webcams
<wolfspraul>
I can buy a nice little uvc webcam for 15 usd
<wolfspraul>
think about that
<wolfspraul>
we pay 12 USD for the analog video decoder alone
<wpwrak>
;-)
<wolfspraul>
plus 22 USD for the analog camera
<wolfspraul>
plus 5 usd for the power supply
<wolfspraul>
we are really stupid, a lot of people *must* think
<wpwrak>
indeed. a usb cam would be nicer
<wolfspraul>
and then all the work with the video decoding subsystem
<wolfspraul>
nobody understands all this, they think we are crazy
<wpwrak>
of course, also more limited. but then, we don't exactly extract HDTV from that camera input ;-)
<Fallenou>
about webcams, they usually use the UVC protocole (USB Video Class)
<Fallenou>
and webcam constructors very often don't implement UVC correctly
<wolfspraul>
I bought a few, will try to find out more
<Fallenou>
Yes I spoke a few times with the UVC guy
<wolfspraul>
what we have on m1 today works, that's a big value
<Fallenou>
and he told me it's a nightmare
<wpwrak>
i would consider webcams a "once linux runs" issue
<wolfspraul>
yes
<Fallenou>
UVC linux driver is full of "quircks"
<Fallenou>
to make all webcams work
<Fallenou>
even those which don't follow UVC
<Fallenou>
I mean don't follow it very well
<wolfspraul>
every option will have issues
<wpwrak>
-> use linux. don't reinvent it ;-)
<wolfspraul>
but that doesn't mean that they are all the same good, into the future
<wolfspraul>
a support of webcams would remove a lot of cost from m1
<Fallenou>
so re implementing support for UVC, it's a big job, and even if we do it correctly, it won't work
<Fallenou>
because webcams are shit
<Fallenou>
so we just need the linux driver :')
<wolfspraul>
and it would allow us at least theoretically to support multiple video-ins
<Fallenou>
which implements the work arounds
<wolfspraul>
agree
<mwalle>
btw i dont think nommu is a blocker for linux..
<mwalle>
esp not for the kernel
<wpwrak>
i'm not sure if webcams are really good enough, though. e.g., can you get a good camera (large zoom, good low-light performance, etc.) what speaks UVC ?
<wolfspraul>
the pure cash costs of the various components in the video-in path alone are more than 2-3 cheap webcams
<Fallenou>
low-light & good quality is hard to find, right ?
<wolfspraul>
wpwrak: we need to try
<Fallenou>
you need a good aperture and good optic
<wolfspraul>
but the current cam quality is also really bad, we only sample half the vertical resolution, etc.
<Fallenou>
so it won't be cheap
<wpwrak>
i think webcams can be a nice complement to our current video in path
<wolfspraul>
and nobody believes that fixing that is even worth the effort
<wolfspraul>
yes, agree
<Fallenou>
anyway I don't want to discourage you, but I just wanted to say "UVC looks nice, but in reality it's just hell"
<wolfspraul>
first make the new thing work, then think about removing what worked before
<wolfspraul>
of course it's hell
<wolfspraul>
like any standard that became successful and was adopted by many companies over many years
<Fallenou>
that's the opinion of Laurent Pinchart too
<wolfspraul>
but we look at specific options for m1 now
<wpwrak>
i think it's worth the effort ! at least i can contribute my opinion ;-)
<wolfspraul>
and I realized: webcams is something to keep an eye on
<wolfspraul>
not more than that, because many blockers remain to make them work today
<Fallenou>
Tomorrow I will try a few things on the mmu, but I think I am running out of ideas, so don't be surprise if I drop an e-mail on the mailing list with a status on my mmu related work, asking for advices and help :)
<wolfspraul>
actually I could try to plug one into a 703n and stream it over to the m1 over ethernet :-) will not tell Werner :-)
<Fallenou>
I could need a hand
<mwalle>
wpwrak: lets assume we have linux and a working webcam, i doubt our lm32 is fast enought to handle the video stream, even if theres some h/w support
<wolfspraul>
that's why I say there is a big value in what we have and what works today
<wolfspraul>
none of this will be touched until we have something better, in reality
<wpwrak>
mwalle: that's possible, yes. i guess we'll have to see how bad it is
<Fallenou>
mwalle: maybe with webcams which streams h264, and with a h264 decoder hardware block
<wpwrak>
mwalle: but i agree that the slow core looks like something that will bite us hard and soon
<wolfspraul>
no h264, that's a patent minefield you want to stay away from
<Fallenou>
oh yes, sure
<Fallenou>
forgot about that, sorry =)
<wolfspraul>
Fallenou: if you run into a tough problem, definitely please describe
<wolfspraul>
even writing the mail may help you, and others can try to come to rescue
<Fallenou>
yep, I just need to clear my mind up before writting the email in order to describe the problem in an intelligible way
<Fallenou>
and sometimes just writting the e-mail makes me think about the problem and solves it, and I never click on "send" button :)
<mwalle>
wpwrak: yeah but for me thats ok, if i want sth fast and ready to use, i would by a raspberry pi.. ;)
<wolfspraul>
mwalle: what are your thoughts on usb?
<wolfspraul>
you contributed some fixes and a crc check, right? why did you need this?
* Fallenou
will take advantage on the extended week-end, in France next monday is day off !
<wolfspraul>
what are your future plans with usb?
<mwalle>
even a usb 2.0 phy doesnt appeal me, lekernel did a great job with the usb phy and its very interesing to study it. if there would be a phy on board there would be just some bytes falling out of it to study ;)
<mwalle>
wolfspraul: im experiementing with device side of the usb, i just mails some minor fixes, i dont think they will have an impact on the hardware side
<mwalle>
wolfspraul: i guess my plans with the mm doesn't suite your business plan, like wpwrak usb midi support etc.. i'm more on the low level side, rather than anything a user will see
<mwalle>
eg a user will never use the gdbstub ;)
<Fallenou>
but werner lekernel or any other will be more than happy to use the gdbstub to debug their work which will be seen by end users ;)