#milkymist IRC log for Saturday, 2012-04-07

wolfspraulwow nice, mwalle contributed a number of usb improvements? did I understand this correctly?01:52
wolfspraulmaybe that solves some of the open usb issues wpwrak had?01:52
wolfsprauljust trying to understand the significance/use cases...01:53
wpwraknot 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.02:17
wolfspraulyeah so we can rule out the lack of crc being the culprit02:29
wolfspraulwhat problems remain on the low-end now?02:29
wpwrakwhat 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.05:13
wpwrakthe 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 CRC05:14
wolfspraulhmm, ok05:22
wolfspraulwhat about speeds?05:22
wolfsprauldo you think m1 can handle the full full-speed now, 12 mbit/sec ?05:22
wolfspraulgotta run for a meeting, bbl05:23
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...)05:24
wpwrakthe garbling only seems to happen at full speed. besides that, full-speed seems fine05:24
wolfspraulis = might be05:25
wpwrakit doesn't look like a signal integrity problem. if it was one, i would expect CRC errors to happen.05:25
wolfspraulwhat stops m1 from supporting high-speed then?05:25
wolfsprauljust trying to get overview of blockers05:26
wpwrakuuh .... high-speed ... ;-)05:26
wpwrakfirst of all, the transceiver05:26
wpwrakthen i'm not sure the FPGA can drive high-speed, at least not on arbitrary pins05:27
wpwrakthen there would probably be many other bottlenecks. don't forget that our LM32 core is extremely slow.05:29
wolfspraulsure, too early to think about maybe05:29
wolfspraulof course we want to build out more low-speed and full-speed instrumentation first...05:29
wpwrakwe would also have no way to actually debug it. we can see full-speed on a scope. high-speed would mean flying blind.05:30
wolfspraulgood to know that you think the pure speed of full-speed is not causing an issue05:30
wpwraki'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.05:31
lekernelif your interface is synchronous, you can have 1Gbps/pin, but clock recovery will be an issue for RX08:37
lekernelbut there are high speed USB PHYs, just like there are Ethernet PHYs08:37
lekernelhttp://www.smsc.com/index.php?pid=28&tid=14308:43
lekernelthen of course, to take advantage of the speed, you'll need DMA in the USB core etc.08:47
wpwrakhmm, 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 ? :)09:01
lekernelyeah, it works for DRAM, after some tweaking of clock phases and such to align the data :)09:04
wpwrakinteresting :) when we should also be able to have a faster CPU core, shouldn't we ? perhaps not LM32, though09:06
lekernelthe 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)09:07
wpwraksounds great. what's the rate we have in regular units now ?09:08
lekernel160Mbps/pin09:08
wpwraknice improvement then :)09:08
wpwrakyou've also optimized the higher layers a bit, haven't you ?09:09
lekernelalso 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 design09:10
lekernelthe CPU core is difficult. LM32 is actually pretty fast already for a softcore.09:10
wpwrak(reordering) that's what i meant. very good.09:11
wpwrakbut if we can have a path that runs at 366 Mcycles/sec, there should be a way to pipeline this better09:12
lekernelat some point we'll probably want multiple memory controllers too :)09:12
lekernelin fact, I guess the future M1s will probably use most of the I/Os for DRAM and high speed digital video *g*09:13
wpwrakwide memory buses are the trend for sure09:13
lekernelyou can have more performance if you drive the memory chips independently09:14
lekerneland you also avoid long PCB traces on address/command (which aren't shared anymore)09:14
lekernelwith the current memory architecture, there's actually an easy solution for this09:15
wpwrakhmm yes, i can imagine that we have many short bursts09:15
lekernelor well, relatively easy09:15
lekernelwe share the pool of requests with all memory controllers09:15
lekerneleach memory controller picks only requests for their chip (identified by some bits in the address)09:15
wpwrakwhy share ? the split by address is quite hard anyway09:16
wpwrakunless you invent some bus-sharing or behind-the-scenes-migration mechanism :)09:17
lekerneland 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)09:17
lekernelphew, no. the split is something like 10 lines of code with migen09:17
lekernelthe difficult part is the multiple data buses, but that's not an intractable problem either09:17
wpwrak"hard" = given, unavoidable09:17
wpwrake.g., address xxxxx00xx would always be on bus 0. so there should be little benefit for sharing requests. at least for throughput09:20
wpwrakmaybe you can save a few gates09:20
lekernelyes, sharing actually makes the design a little less complex09:20
lekernelotherwise, each device must have a slot in each memory controller09:20
lekerneland then pick the right one to issue the transaction09:20
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)09:21
wpwrakah, i see09:21
lekernelalso, from the system clock point of view, there are no bursts anymore (because of the DRAM clock multiplication)09:22
lekernelso if issue takes more than 1 cycle, it becomes the bottleneck09:23
wpwrakbursts on the device-to-memoory-controller bus ?09:23
lekernelnow, arbitrating several devices and issuing unique tags to each transaction in 1 cycle isn't easy wrt timing09:24
lekernelso it's much easier to have dedicated slots09:24
lekerneland issue can NEVER become a bottleneck, since all devices can actually push out their request all at the same time09:25
wpwrakso the slots also determine when each memory controller access the internal bus ?09:25
lekernelthe 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 clock09:26
lekernelthere 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 ratios09:27
lekernelwhat internal bus? the data transfer one?09:28
wpwrakwhat's the bus that connected devices to the memory controller ? WB ?09:29
lekernelno, custom09:29
lekernelit's actually quite simple, the MC sends the slot number one cycle before the data09:29
wpwrakdoes it have a name ?09:29
lekernelyeah, asmibus09:29
wpwrakah, the MC assigns slots. interesting09:29
wpwrakso the devices need to remember to which slot the data comes back ?09:30
wpwrak(in a read)09:30
wpwrakin a write, you wouldn't need any of this then09:30
lekernelwell, it picks slots taking into account the DRAM state and its various timing properties, proceeds with the transaction, and supplies/retrieves data09:30
lekernelso of course, it assigns the slots09:30
lekernelyou need slots for both reads and writes09:31
wpwrakslot = time slot on the real memory bus ? i.e., not just a queue position09:31
lekerneland yes, the devices need to store their slot number09:31
lekerneland match it on the data bus09:32
wpwrakbut for writes, the device doesn't need to know the slow number, does it ?09:32
lekernelslot = entry in the pool of requests09:32
lekernelwrites are reordered too09:32
lekernelwell, you could supply the data into the slot as well09:32
wpwrakso write reordering is visible on asmibus09:32
lekernelbut it actually makes things more complex09:32
wpwrakdoes sending slot assignments eat a bus cycle ? or is this parallel to data transfers ?09:33
lekernelit actually means adding a write buffer on each devices, though some may not need it09:34
lekernelno, each device has dedicated access to its slot(s)09:34
lekernelthis runs fully parallel to data transfers, and the data bus can have 100% bandwidth efficiency09:35
wpwrakhmm, i still don't get the writes09:36
lekernelactually, in asmibus the only "bus" part is for the data (which is shared anyway at the DRAM I/Os)09:36
wpwrakif 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 ?09:36
lekernelbecause then, the MC has to buffer your data09:37
wpwrakor 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 versa09:38
lekernelif that data comes from e.g. a block RAM, it doesn't need to09:38
lekernelyes, that's how it works09:38
wpwrakah, i see. so the buffering would be needed to keep the amount of work per cycle low09:39
lekernelthe first part happens on the dedicated slot access09:39
lekerneland the second on the shared data bus09:39
wpwraki think i got it :)09:39
wpwrakso the "sharing or requests" would be on asmibus. but the MCs would each have their own request tables ?09:40
wpwrakmaybe with some layering, to arbitrate asmibus09:41
lekernelno, there's one request pool, and all the MCs have access to it.10:00
lekernelthen each MC has its own data bus10:00
lekernelthere should be no arbitration on the data bus, otherwise you'll lose bandwidth since only one DRAM chip can talk at a time10:01
wpwrakbut the data but is shared, so you need to arbitrate that as well, don't you ?10:03
wpwrakor do you have buffers there ?10:03
lekerneldevices should connect all data buses and have buffers10:05
lekernelor just a mux, if they send requests one at a time10:05
lekernelbut that's for later. right now we have only one MC10:07
wpwrakyeah, with one MC, you're safe :)10:07
lekernelwpwrak: by the way, unless the German administration has set us another trap, we should have the EHSM room booked for 28-30.12 on Tuesday10:08
wpwrakah, so i'll miss half the nice mid-summer fireworks10:12
wpwrakbut it's good that you finally got there. quite a bit more of a battle than expected, i guess ?10:14
lekernelyeah, that's why it was initially planned for August. and well, technically I'm not there yet.11:06
lekernelwho knows if there is some arcane rule that says the university must be closed between xmas and new years11:07
mumptailekernel, some universities do that, including turning down the heating :-/11:14
wpwrakah, ask about the heating ;-)11:15
wpwrakand if there's none, maybe about their policy regarding indoors bonfires :)11:15
mumptaihihi11:17
mumptaiwell, what are the servers clusters for ;)11:17
wpwrakhmm, a conference in the machine room :)11:18
kristianpaulwpwrak: faster cpu you mean ie, 200Mhz? :-)12:37
kristianpaulperhaps having a separate FPGA for just lm32 and its conbus... clocked at higer sped?12:38
kristianpaulI 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 cause12:39
kristianpaulmay be lekernel now more about it12:39
wpwrakkristianpaul: 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 ?15:28
wpwrakkristianpaul: 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.15:29
wpwrakthat's what MIPS is all about ;-) you could probably reduce the number of NOPs by using conditional instructions, similar to ARM15:30
wpwrakalso, put the MMU into the pipeline, so it doesn't add overhead to the memory cycles15:30
lekernelthe memory can only run at 366MHz because I'm using the SERDES15:31
lekernelif you insert logic and routing, delays build up15:31
wpwrakso asmibus (sp?) is slower ?15:32
lekernelsystem clock is 83MHz15:32
lekernelthat's why we have clock multiplication15:32
lekerneland the multiplication only happens at the I/O15:33
wpwrakokay, but couldn't a (radically) different core have a higher system clock ?15:34
lekernelif you use things like lava, probably15:34
lekernelbut don't expect miracles either. also this way of doing things is more difficult to develop.15:35
wpwrakaren't there cheats that give you the same level of control in verilog ?15:35
wpwrakoh, sure it's difficult. when has that ever scared the entire population ? ;-)15:36
wpwrakthe harder the work, the more the glory ;-)15:36
whitequarkwpwrak: that's what MIPS was all about, and it utterly failed17:02
wpwrakhuh ?17:02
whitequarknewer MIPSes only include branch delay slots for compatibility, actually having a workaround inside to make them work17:02
wpwrakthe MIPS architecture seems to be pretty popular17:03
whitequarkreasons are different. branch delay slots aren't really that useful, depend too much on implementation details, make compilers more complex and bug-prone17:03
whitequarkwpwrak: err, I meant "utterly failed on branch delay slots"17:03
wpwrakand we don't need to worry so much about binary compatibility. if the pipeline changes, we can just recompile. different world.17:03
whitequarkyes17:03
whitequarkjust don't overestimate the value of branch delay slots17:04
whitequarkpractice has already shown that they do more harm than good17:04
whitequarkin a certain sense, branch delay slots and other features intended not to stall the pipeline were the reason MIPS is named MIPS17:05
whitequarkah, I got what you mean about "not worrying about binary compat". yes, way easier this way.17:05
wpwraki you go for heavy pipelining, avoiding them is probably very costly elsewhere17:05
wpwraks/i/if/17:05
whitequarkwell, I personally just think that pipeline might very well be stalled for the sake of compiler simplicity17:06
whitequarkAFAIK, only quite advanced compilers can make any use of it anyway17:06
whitequarkllvm does, gcc not so much17:06
whitequarkand they can be quite a source of bugs due to inobviousness17:07
wpwrakcode is cheap. fpga power isn't :)17:07
whitequarker17:07
whitequarkstalling the pipeline in this case is several logic elements17:07
whitequarkand you still have reasons you might need to stall it anyway, e.g. load cycles, so this logic would be routed along the pipeline anyway17:08
wpwraki would defer loads17:08
whitequarkon the other hand, hard-to-find bugs are not cheap17:08
whitequarkin terms of possible damage or even work needed to eliminate them17:08
whitequark(defer loads) as in "instruction reordering"?17:08
wpwrakeven any register write would be deferred. add Rout, Rina, Rinb  would fetch Rina/Rinb in cycle t and write Rout in a cycle > t17:09
wpwrakno. make instructions non-atomic17:09
whitequark(fetch/write) er, doesn't any pipeline execute it like this?17:10
wpwrakyes, but they hide it from the user17:10
whitequarkt = EX, t+1 = WB17:10
whitequarkhm.17:10
whitequarkwhat do you mean by "showing it to user"?17:10
whitequarkmake user write "add A, Rina, Rinb";"set Rout, A"17:11
whitequarkwhere "A" is immutable?17:11
whitequarkthat is, introduce explicit instructions for each pipeline stage?17:11
wpwrakno, more like the Milkymist PFPU17:12
wpwraktreat the result register as an independent channel17:12
whitequarkin other words, you want to make a 3-stage pipeline17:12
whitequarkfetch, decode, execute17:12
whitequarkand make what was a writeback stage an explicit instruction17:13
wpwrakso an instruction says basically: OP args /* to start in cycle t */ result /* of operating finishing in cycle t */17:13
wpwrakperhaps more stages. we also have the TLB17:13
whitequarksure, I just outlined a basic idea17:13
whitequarkinteresting17:13
whitequarkI think this has something in common with VLIW architectures17:14
wpwrakyou can represent the writeback as a "separate" instruction. as long as you always pair it with an instruction that starts an operation17:14
whitequarknot sure if this is a good idea or bad, through. I need to think about it17:14
whitequarkbut this indeed sounds interesting17:14
wpwrakit seems interesting enough to be worth trying ;)17:14
whitequarkexactly17:14
whitequarkhah, every day you learn something new... again, I'll think about it17:15
whitequarknow I got to go. bbl17:15
wpwrakand the PFPU works this way. you need to twist your mind around it a bit, but it's something one can handle17:15
mwallewpwrak: wolfspraul: so whats the use of hi-speed usb?17:23
wpwrakmwalle: i think wolfgang was just curious whether we could have it at all19:54
lekernelwpwrak: this way of doing things is nice for the PFPU because the basic block (unconditional instructions between jumps) is large22:23
lekernelon real software, with a jump every 5-10 instructions or so, VLIW sucks22:23
lekernelunpredictable memory latency does some damage, too22:24
wpwrakyes, you probably need to estimate the memory latency and then add buffers for reads that arrive early22:43
wpwrakor just stall whenever the data isn't ready yet. would need some kind of tagging/barriers, though.22:44
wpwrakand 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 selected22:45
wpwrakbut yes, it may be hard to generate efficient code for such a radical architecture22:47
whitequarkvliw sucks, I just said about it because of similarity23:04
whitequarkbtw, an architecture with explicit memory wait cycles? I'd say this is _too_ radical23:05
lekernelwell it depends, for the pfpu it does not (around 75% of the register file write slots are successfully filled)23:06
lekernelbut for a general purpose CPU... it always failed23:07
whitequarkyeah, I was talking about GPCPU23:08
wolfspraulmwalle: no specific use, I am very much a believer in fixing bugs one by one, and improving features incrementally23:15
wolfsprauland 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 fpga23:15
wolfspraulhaving 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.23:16
wolfspraulfor 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)23:16
wolfspraulby supporting usb webcams, we could immediately support multiple video-ins23:17
wolfspraulby supporting those usb video capture dongles, we could remove the entire video-in subsystem23:17
wolfspraulwhat else?23:17
wolfspraulusb storage (to supply pictures or videos)23:17
wolfspraulusb audio (could remove the audio subsystem)23:18
wolfspraulusb dvb-t dongles, could mix in live TV23:19
wolfspraulthe 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 :-)23:20
wolfspraulin reality xiangfu is still fixing bugs related to unsupported keyboards and mice, and that is good23:20
wolfsprauland you just provided a hardware crc check :-)23:20
wolfspraulfirst step: really support all keyboards and mice that work on a notebook23:22
wolfspraulsecond step: full support of usb-midi23:22
wolfspraulthen we see23:23
wolfspraulwhat are you thoughts on usb?23:23
mwalleyeah but that should work with full speed too, shouldnt it?23:24
mwallewolfspraul: dunno, just beginning to explore it ;)23:25
wolfsprauloh sure23:26
wolfspraulbut I *think* about everything, right?23:26
wolfsprauleven super speed :-)23:26
wolfspraulI am trying to find the best way forward for m123:26
wolfspraulso I want to look at a lot of options, lot of alternatives23:26
wolfspraulwhat attracts me to usb is some immediate use cases that people already ask for, such as usb storage23:27
wolfspraulbut they are very difficult to implement!23:27
wolfspraulso first - low speed & full speed done right23:27
wolfspraulin fact - only keyboards & usb-midi done right, that'd be wonderful23:27
wolfspraulusb seems complex too, I can understand sebastien's reservations23:28
wolfspraulwe could also outsource the usb problem to a separate chip, no? let the fpga communicate with that chip in, what? pcie? don't know23:29
wolfspraul*could*23:29
wpwrakthe 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.23:29
wolfspraulor plug the usb device into a daughter-system like a tp-link 703n router connected to the m1 via ethernet23:29
wolfspraullet the 703n be the m1's usb bridge :-) (werner will experience some of his tooth pain coming back now, I know)23:30
wpwrakhow long do you expect to be able to source the tp-link 703n unchanged ? :)23:30
wolfspraulthere will be another successor, but sure23:30
wolfsprauljust keep in mind that can work very fast, like 'today'23:30
wolfsprauljust options, options23:31
wolfspraulmwalle asked, so I explain my thinking23:31
wolfspraulalso a dedicated usb chip, it's a possibililty23:31
wpwrakif you want a quick solution, drop in an OMAP ;-)23:31
wolfsprauleven if we decide not to do one particular option, we should clearly document and articulate why23:32
wolfspraulso people can understand and hopefully agree and be excited23:32
wolfspraulrather than thinking 'these guys are stupid'23:32
wpwrakthe complexity is in the USB stack. so unless the "usb chip" is a complete system (linux or such), it doens't help much23:32
wolfspraulyeah, that's why I mention the 703n23:32
wpwrakunless, of course, you settle for things like FTDI. single-function.23:32
wolfspraulwhich has a neat usb host connector on it :-)23:32
wolfspraul16 USD for the whole thing23:33
wpwrakand you have zero control of what goes on inside23:33
wolfspraulzero control?23:33
wolfspraulyou get spoilt by milkymist soc a little :-)23:33
wolfspraulbut yes, sure23:33
wolfspraulwe are on the same page23:33
wpwrakif they change something, you won't find out until very late23:33
wolfspraulanother thing that keeps popping back up is webcams23:33
wolfspraulI can buy a nice little uvc webcam for 15 usd23:34
wolfspraulthink about that23:34
wolfspraulwe pay 12 USD for the analog video decoder alone23:34
wpwrak;-)23:34
wolfspraulplus 22 USD for the analog camera23:34
wolfspraulplus 5 usd for the power supply23:34
wolfspraulwe are really stupid, a lot of people *must* think23:34
wpwrakindeed. a usb cam would be nicer23:34
wolfsprauland then all the work with the video decoding subsystem23:35
wolfspraulnobody understands all this, they think we are crazy23:35
wpwrakof course, also more limited. but then, we don't exactly extract HDTV from that camera input ;-)23:35
Fallenouabout webcams, they usually use the UVC protocole (USB Video Class)23:35
wolfspraulyeah23:35
wolfspraulhttp://www.ideasonboard.org/uvc/23:35
Fallenouand webcam constructors very often don't implement UVC correctly23:35
wolfspraulI bought a few, will try to find out more23:35
FallenouYes I spoke a few times with the UVC guy23:35
wolfspraulwhat we have on m1 today works, that's a big value23:35
Fallenouand he told me it's a nightmare23:35
wpwraki would consider webcams a "once linux runs" issue23:35
wolfspraulyes23:36
FallenouUVC linux driver is full of "quircks"23:36
Fallenouto make all webcams work23:36
Fallenoueven those which don't follow UVC23:36
FallenouI mean don't follow it very well23:36
wolfspraulevery option will have issues23:36
wpwrak-> use linux. don't reinvent it ;-)23:36
wolfspraulbut that doesn't mean that they are all the same good, into the future23:36
wolfspraula support of webcams would remove a lot of cost from m123:36
Fallenouso re implementing support for UVC, it's a big job, and even if we do it correctly, it won't work23:36
Fallenoubecause webcams are shit23:36
Fallenouso we just need the linux driver :')23:37
wolfsprauland it would allow us at least theoretically to support multiple video-ins23:37
Fallenouwhich implements the work arounds23:37
wolfspraulagree23:37
mwallebtw i dont think nommu is a blocker for linux..23:37
mwalleesp not for the kernel23:37
wpwraki'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 ?23:37
wolfspraulthe pure cash costs of the various components in the video-in path alone are more than 2-3 cheap webcams23:38
Fallenoulow-light & good quality is hard to find, right ?23:38
wolfspraulwpwrak: we need to try23:38
Fallenouyou need a good aperture and good optic23:38
wolfspraulbut the current cam quality is also really bad, we only sample half the vertical resolution, etc.23:38
Fallenouso it won't be cheap23:38
wpwraki think webcams can be a nice complement to our current video in path23:38
wolfsprauland nobody believes that fixing that is even worth the effort23:38
wolfspraulyes, agree23:38
Fallenouanyway I don't want to discourage you, but I just wanted to say "UVC looks nice, but in reality it's just hell"23:39
wolfspraulfirst make the new thing work, then think about removing what worked before23:39
wolfspraulof course it's hell23:39
wolfspraullike any standard that became successful and was adopted by many companies over many years23:39
Fallenouthat's the opinion of Laurent Pinchart too23:39
wolfspraulbut we look at specific options for m1 now23:39
wolfsprauland I realized: webcams is something to keep an eye on23:39
wpwraki think it's worth the effort ! at least i can contribute my opinion ;-)23:39
wolfspraulnot more than that, because many blockers remain to make them work today23:40
FallenouTomorrow 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 :)23:40
wolfspraulactually I could try to plug one into a 703n and stream it over to the m1 over ethernet :-) will not tell Werner :-)23:40
FallenouI could need a hand23:40
mwallewpwrak: 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 support23:41
wolfspraulthat's why I say there is a big value in what we have and what works today23:41
wolfspraulnone of this will be touched until we have something better, in reality23:42
wpwrakmwalle: that's possible, yes. i guess we'll have to see how bad it is23:42
Fallenoumwalle: maybe with webcams which streams h264, and with a h264 decoder hardware block23:42
wpwrakmwalle: but i agree that the slow core looks like something that will bite us hard and soon23:42
wolfspraulno h264, that's a patent minefield you want to stay away from23:43
Fallenouoh yes, sure23:44
Fallenouforgot about that, sorry =)23:44
wolfspraulFallenou: if you run into a tough problem, definitely please describe23:44
wolfsprauleven writing the mail may help you, and others can try to come to rescue23:45
Fallenouyep, I just need to clear my mind up before writting the email in order to describe the problem in an intelligible way23:45
Fallenouand sometimes just writting the e-mail makes me think about the problem and solves it, and I never click on "send" button :)23:45
mwallewpwrak: yeah but for me thats ok, if i want sth fast and ready to use, i would by a raspberry pi.. ;)23:45
wolfspraulmwalle: what are your thoughts on usb?23:46
wolfspraulyou contributed some fixes and a crc check, right? why did you need this?23:46
Action: Fallenou will take advantage on the extended week-end, in France next monday is day off !23:46
wolfspraulwhat are your future plans with usb?23:46
mwalleeven 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 ;)23:48
mwallewolfspraul: 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 side23:49
mwallewolfspraul: 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 see23:54
mwalleeg a user will never use the gdbstub ;)23:54
Fallenoubut 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 ;)23:57
mwalleFallenou: yeah of course23:59
mwalletime to sleep23:59
--- Sun Apr 8 201200:00

Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!