#milkymist IRC log for Friday, 2012-03-09

wolfspraulI ran into this standard that allows to send video and audio over low pin-count interfaces, called MHL02:31
wolfspraulfor example USB02:31
wolfspraulwhich makes me wonder whether the m1, theoretically, could support this 'MHL signalling'?02:32
wolfspraulno idea :-) (and the standard doc costs 100 USD...)02:32
wolfsprauljust 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 possible02:33
whitequarkwolfspraul: I guess it has HDCP02:39
whitequarkwell, it certainly does02:39
whitequarkwon't that make it "not open" ?02:39
whitequarkwait, Samsung Galaxy S 2 has it02:39
whitequarkI know it02:39
whitequarkit's not a new interface whatsoever02:40
whitequarkjust a connector which has both USB and HDMI and is compatible with micro-USB02:40
whitequarknothing more02:40
wolfspraula number of phones support MHL, from Samsung, LG, HTC02:42
whitequarknow that I read further into it, looks like it is02:42
wolfspraulhave you read the wikipedia article about it? I think that's a starting point02:42
whitequarkbut I don't quite get how they squeezed USB, HDMI and some other interface into such a tiny connector02:42
wolfspraulI'm just saying I wonder whether m1 can theoretically output that 'MHL signalling'02:42
wolfspraulwhich probably depends on performance, usb tranceiver, client/host issues, details in the standard, etc.02:43
wolfspraulwhat is the lowest resolution supported, and so on02:43
whitequarkah ok02:43
wolfspraulthe standard is connector-agnostic, it's just a standard/protocol to send video + audio over 'low pin count' interfaces02:44
wolfspraulso for example it can use a micro-usb connector, but when activated there will be no usb protocol over those wires, but MHL instead02:44
whitequarkhm, interesting02:45
wolfspraulyou 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 HDMI02:45
whitequarkoh, really? I bought it, but it hasn't arrived yet02:45
wolfspraulwell that is my assumption that that's what's going on02:46
whitequarkwell ok, I'll disassemble it then02:46
wolfspraulwhat blocks m1 from supporting mhl? probably a number of things02:46
whitequarkalso I have schematics for SGS202:46
whitequarkif you want to look at it02:46
wolfspraulaccess to the standard, implementation in the soc, memory bandwidth, usb client/host or transceiver issues02:46
wolfsprauland probably more :-)02:46
wolfspraulbut there is a standard, that's all I wanted to say, and it seems to be picking up some speed02:47
wolfspraulI don't even know how open this standard is (mhl). the doc is 100 USD? ...02:48
wolfspraulit's so low that it becomes a nuisance to even talk about it, but hey it's not 0 still. argh. anyway.02:48
wolfspraulwhitequark: SGS2? that's some phone? no sorry, not interested but thanks for offering.02:49
whitequarkyeah, Galaxy S 2 with that interface02:49
cladamw(J24 internal usb header) wpwrak according to Figure 3 and Table 7 of page http://www.formfactors.org/developer%5Cspecs%5Cfpio_design_guideline.pdf  we should let pin 9 as key surely but also pin 10 for NC since we don't have overcurrent signal for pin 10, also i checked Figure 10 in page 15 of http://www.usb.org/developers/whitepapers/power_delivery_motherboards.pdf both pdf files are good to know. ;-)03:20
cladamwwpwrak, J24 5*2 pins header is for usb E/F ports. ;-)03:21
cladamwFigure 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 ?03:24
hypermodernGreetings 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?04:01
wolfspraulhypermodern: can you search for milkymist on youtube?04:31
wolfsprauldon't have my vpn running at the moment :-)04:31
wolfspraultry this http://www.youtube.com/watch?v=ZcO3qslAmTo04:33
wolfspraulmilkymist @8static in philadelphia last november04:33
hypermodernThank you wolfspraul04:38
hypermodernI was hoping for something with image control that wasn't the demo video04:38
hypermodernThis seems like it's just a patch right?04:39
hypermodernThe band is fun  :-) thank you.04:40
hypermodernbonewolf, is this M1 http://youtu.be/6DcY83OP6h0?04:41
hypermodernWolfspraul, is this M1 http://youtu.be/6DcY83OP6h004:41
wolfspraulcan't access, wait I check a little later04:42
hypermodernThank you04:42
wpwrakwolfspraul: we have the expansion header. don't underestimate its power ;-)04:45
wolfspraulis that regarding MHL?04:45
wpwrakwe can always make little boards that interface from whatever to something that works great with M104:46
wolfspraulmaybe it's even possible over the existing usb connectors?04:46
wolfspraulbut probably not because ours are host - not sure04:46
wpwrakand the USD 100 standard may have additional royalties if you dare to implement it04:46
wpwraki doubt MHL would be happy with just full-speed D+/D-04:47
wolfspraulsure not04:47
wpwraki'd consider the USD 100 price tag fair warning that there will be more toll booths along the way :)04:47
wolfspraulthe SD spec costs 1000 USD04:48
wolfspraulshould we rip out the sd card?04:48
wolfspraul8:10 card :-)04:48
wolfspraulanyway I found it and I thought it may be interesting one day - MHL04:48
wpwrak(D+/D-) so our problem would be less the host (although it may be too) bit more the link speed04:48
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 :)04:50
wpwrakhmm, does adam read the backlog ? fire and forget gets a tad inconvenient ...04:52
wpwrakhah ! here he is :)05:29
wpwrakcladamw: the intel document is a great find !05:30
cladamwso did you agree on pin9 & pin10 ?05:31
wpwrakand yes, i agree with everything it says :) my suggestions for the header so far have been mere guesswork05:31
cladamwokay, 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-110H05:33
cladamwfor J24 5*2 headers with p/n: 69192-110HLF, just for temporarily candidate but not final. ;-)05:34
wolfspraulroh: the other day we talked about video cables with builtin dacs/adcs, I just ran into this one http://detail.tmall.com/item.htm?id=1285142739705:37
wpwrakyou can perhaps even find one that's pre-keyed05:37
wolfspraulthey are easily available in all sorts of conversion types, and I think increasingly so05:37
cladamw120 uF is recommended from usb org, but alternative like 220uF or more for two port with ESR is also okay.05:37
wolfsprauljust to follow up (you said you hadn't seen them)05:38
cladamwyup...i tried to find a pre-keyed, but not found yet, maybe my sorting skill is not right. ;-)05:38
wpwraki don't mind more :)05:38
wpwrakfinding keyed headers is a bit of a nightmare. there may be plenty of needles, but the haystack is huge ...05:39
cladamwwpwrak, 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. :)05:39
wpwrakyeah. a wire cutter goes a long way ;-)05:40
cladamw(V32, V33) to be DNP too since no LNLVLOUT out, my fault.05:43
cladamw(U8 value) from TSOP4838 to TSOP34838, also my fault. :(05:43
cladamwi updated them in latest one.05:44
wpwrak(V32, V33) ah, good catch. i wonder if we shouldn't DNO C4,5,7,8,14 too05:44
wpwrak(U8) good catch too :)05:45
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. :-)05:47
wpwrakmmh ?05:49
cladamwso if M1r4 don't have them, worse case one feed audio signal by a 1uF by themselves ?05:49
cladamwor you want directly removed them ?05:49
wpwrakoh, we could just DNP them05:49
wpwrakfreedom of choice ;-)05:49
cladamwhap..okay. let's DNP them. :-)05:49
cladamwI'll update.05:50
cladamw(C22) wpwrak DNP too ? it's for MONOOUT.05:55
cladamwokay :)05:59
wolfspraulwpwrak: I kept hearing from several sides now complaints about m1 connectors on all 4 sides06:32
wolfsprauland you mentioned it too the other day06:32
wolfspraulso what do you propose?06:32
wpwrakfor M2, change the form factor from square to rectangle. then put connectors on front and rear only. mainly rear.06:36
wpwraki would also move to panel-mounted connectors, for better mechanical stability. but that's a bit expensive06:37
wpwrakor "more expensive". hopefully not horribly so06:39
wolfspraulok let's go through. rectangle - which aspect ratio do you have in mind?06:40
wolfspraulconnectors mainly on back? why? you may as well argue for having them mainly on the front, no?06:41
wolfspraulpanel-mounted? don't know what you mean06:41
wolfspraulyou 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?06:41
wpwrakaspect 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 structure06:42
wpwrak(front) except that the vj will pump into them a lot more :)06:43
wpwrak(panel-mounted) yes. screwed to the sidewall. so when your vj bumps into the connector, the sidewall takes the hit and not the PCB06:43
wolfspraulthen you could also argue for upward-facing connectors, that's what a lot of dj stuff has06:44
wolfspraulwe have that already for dmx and video-in06:44
wpwrakyes, upward is an option. more expensive. and needs a bigger base unit06:44
wolfspraulwhy bigger base unit?06:44
wpwrakif you have a panel on top, you need some space to avoid bumping into the upward-facing connectors06:45
wpwraki think the common theme emerges ;-)06:45
wolfsprauldon't understand, sorry06:46
wolfspraulbumping into upward facing connectors?06:46
wpwrakif you don't have a panel on top, you can of course do as you please.06:46
wolfspraullet'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 into06:46
wpwrakif we add an lcd panel, you'd have your hands on the M106:46
wolfspraulof course they wouldn't want to hit the stick from the side06:46
wolfspraulbut that is a very typical setup of DJ equipment06:47
wolfspraulit's just like another knob06:47
wolfsprauleverything on the top side is naturally upward facing06:47
wpwrakyes, but they usually put the plugs where you don't hit them06:47
wolfspraulnot from what I've seen so far06:47
wpwrake.g., on the very top, with no or only auxiliary controls06:47
wolfspraulif there are other knobs, buttons, whatnot, you also cannot randomly hit them06:48
wolfsprauleither it's a button or not :-)06:48
wpwrakknobs tend to be relatively flat. if you hit them, not much happens. try that with your usb stick :)06:49
wolfspraulthey are small nowadays, smaller than a typical encoder06:49
wolfspraulI think upward facing makes the board hard to embed in an installation/object/larger something06:50
wolfspraulin general06:50
wolfspraulbecause connectors on the sides just extend the board along existing dimensions, whereas upward facing connectors open up the 3rd dimension06:50
wpwrakmay 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 :)06:51
wolfspraulor they all sit on expansion cards :-)06:51
wolfspraulall glue circuitry that goes with that connector on that card as well, the base board becomes fpga+memory only06:52
wpwraki see that you learned a lot about mechanical stacking at openmoko ;-)06:52
wolfspraulok, so we make changes in small practical steps - good06:52
wpwrakwhy simple if we can make it ruinously complex ? ;-)06:52
wolfspraulcost down, highlight milkymist and performance as much as possible06:52
wpwraksounds good :)06:53
wpwrakrear/front are relatively easy. standard components, no adapter boards, only need a few screws06:53
wpwrakthe 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.06:54
wpwrakgah, worry about06:54
xiangfuhypermodern, you created this patch?(http://www.youtube.com/watch?v=6DcY83OP6h0&feature=youtu.be) cool08:17
xiangfuhypermodern, would you mind share those patches to us? just send them to me. I will upload them to patch club. :)08:18
wolfspraulhypermodern: please email to xiangfu@sharism.cc - we need this stuff08:27
wolfspraulnow that the foundation starts to wokr better and better, we have to bring m1 to a totally different level aesthetically08:27
wolfspraullike shocking new stuff :-)08:28
wpwrakthat was done with milkymist ? doesn't look like it10:05
wpwrakothers effects do, though. e.g., this one is very typical: http://www.youtube.com/watch?v=qCqg-By3zEQ10:07
wpwrakof course, if it should turn out that there is no "typical" effect, even better ;-)10:09
wolfspraulwpwrak: 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?10:27
wolfspraulwhat would your ideal spi boot process look like?10:28
Action: lekernel is fine with pesky memory cards as long as someone else's code takes care of it10:39
wolfspraulthat is 100% fair10:41
wolfsprauldon't worry, I think we are realistic10:41
wolfspraulif we can go to migen and get faster memory, that's AWESOME! :-)10:42
wolfspraulplus I am only trying to understand and document werner's thinking, it's not that we have to make this decision anytime soon10:42
wolfspraulbut I think most spi flashs are rather small10:43
wpwrakyes, small SPI flash followed by MMC sounds good to me10:43
wolfspraulthere you go10:43
wolfspraulthanks! :-)10:43
wpwrakMMC also has more bits -> ought to be faster :)10:43
wpwrak(bits) bus width10:43
wolfspraulwe save pins from removing the nor, guess we can throw them right back into the game with a 2nd mmc? :-)10:44
wolfspraulor if that's too wasteful, then the first mmc we have now...10:44
lekernelyes, 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 cards10:44
wpwrakwe still save lots of pins even if we add five MMCs ;-))10:44
wolfspraulwe don't need to support all cards10:44
wolfspraulnot at all10:44
wolfspraulthat's a design/communication decision whether we even tell people that this chip is removable...10:45
wpwraklekernel: it doesn't work that way. we pick the card that works and ship with that one ;-)10:45
wolfspraulwe do that in rc3 already, every rc3 has a formatted and working 2gb mmc card inside10:45
wolfspraulexcept for a few bare-board developer boards I sold to people who are supposed to fix bugs anyway :-)10:46
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)10:46
lekernelwpwrak: by the way, there are quad-bit "SPI" memory chips that are becoming quite common too10:47
lekerneland xilinx fpgas support them for configuration10:47
wpwraklekernel: oh, cool. so no worries about boot speed.10:47
wolfspraulmy question about actual expected boot speed difference was unanswered the other day10:47
wolfspraulI keep hearing "nor is faster"10:48
wolfspraul20 times10:48
wolfspraulbut not once an actual estimated number10:48
wolfspraulthat makes me suspicious :-)10:48
wolfspraulmaybe it's just a few hundred ms?10:48
lekernelwell, NOR gets the FPGA configured in < 500ms10:48
wolfspraulif m1 would boot from spi today, how much slower would the boot be?10:48
lekernelmaybe even a lot less10:48
wolfspraul(estimated, of course)10:48
wolfspraulbecause funny enough, I also ran into people that happily tell me "I boot from spi, it's faster" :-)10:49
lekernelbut of course, if SPI is 4 times slower, it won't make much difference on a ~20s boot10:49
wolfspraulto which I can only smile back "m1 boots from nor, it's faster"10:49
wolfspraulhow much?10:49
wolfspraulbtw - the boot time on recent builds is dramatically improved!10:49
lekernelif SPI is 4 times slower, well, < 1.5s then *g*10:49
wolfspraulhow do you get to that number?10:50
lekernelbut I don't know. the answer is somewhere in FPGA and flash datasheets ...10:50
wolfspraulSPI would be < 1.5s slower?10:50
wpwrakaccording to adam's graph, it currently takes ~280 ms: http://en.qi-hardware.com/wiki/File:M1rc2_powerOnOff_sequences_manuscript.jpg10:50
wolfspraulyes, it's ok10:50
wolfspraulno need to waste time over this10:50
wolfspraulI am just saying I always hear "faster"10:50
wolfspraulbut never an actual number10:50
wolfsprauland I have met people who happily say the opposite10:50
wolfsprauljust saying10:50
wolfspraulexperienced board-level designers10:51
lekernelno, I'm saying under the assumption that SPI is 4 times slower, it would increase the boot time by less than 1.5s10:51
wolfspraulbut I feel no urge to know an exact number10:51
wolfspraulmy feeling is that the difference cannot be much10:51
wpwrakif it was glacially slow, we'd see more people using NOR10:51
wpwrakand ours isn't even a particularly big FPGA10:52
wolfspraulif it's 280ms, the difference shrinks to 840ms (with the 4 times slower assumption)10:53
wpwrakmaybe we can also squeeze the bitstream a bit :)10:54
lekernelno, it'll become larger, not smaller10:54
lekernelwe'll also want a bigger FPGA10:54
wpwrakwill even a low-occupancy bitstream have to grow ? i.e., does it have to touch all the control bits ? or are there some optimizations ?10:56
lekernelbut we won't stick to low occupancy :)10:56
wpwrakwell, we'd pull in a small loader and then switch to MMC, no ?10:57
wolfspraulyes i agree we should focus on milkymist soc power and fpga power, those are dollars well spent for the manufacturer and user of the product10:57
wolfspraulin other words - larger fpga - yes, sounds right10:58
lekerneland the only possible "compression" is removing empty frames. a frame is empty only if the 16 (iirc) slices that it controls are entirely unused.10:58
wpwrakthat sounds like a useful compression to me10:58
lekernelso 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 speed10:58
lekernelah, and bootstrapping a bitstream from memory card is messy10:59
Fallenouadd an AtTiny24 ? :p10:59
wolfspraulyou mean the entire bitstream has to fit into the spi flash for sure?10:59
lekernelbecause you don't want to erase the circuit reading from that card10:59
wolfspraulFallenou: heart attack!11:00
lekernelit's possible to do, but quite difficult. not worth it imo.11:00
wolfspraul(actually I'm cool about whatever option that moves us forward :-))11:00
lekernelmuch simpler to pick a flash chip that can store the entire bitstream, and the BIOS11:01
wpwrakwe'll need some engineering challenges for the future :)11:01
wolfspraulgot it11:01
Fallenouattiny was able to load the fpga with bitstream on sdcard in 5 seconds :p a bit slow11:01
wpwrakand tricky placements constraints sound like a good exercise for llhdl :)11:01
lekernelwell let's not throw in more chips. a larger flash chip solves the problem in a very simple way.11:02
lekernelif you're looking for challenges you can have a look at dataflow optimizers in migen :-)11:02
lekernelthis stuff can build blazingly fast HW accelerators and enable great GUI/render effects11:03
wpwrakwe can test most of this with existing M1s anyway: boot MMC loader from NOR, then switch over11:03
wpwrakhehe :)11:03
lekernelnot some obscure FPGA configuration details that no one will give a crap about11:04
wpwrakllhdl should be all about fpga configuration details :)11:04
lekernelyeah well... I'll think again about llhdl when milkymist is popular enough11:05
lekernelllhdl will not get there, migen might11:05
wpwrakllhdl is the revolution :)11:06
wpwrakmigen is thriving in conformance11:06
lekernelyeah, for the 100 persons on earth who care about this stuff11:07
wpwraki think it's a bit more :)11:07
wpwrakand openness should get a lot more interested11:08
wpwraki can't help but think of the pathetic state of operating system research in the 1980es11:08
lekernelwho cares about openness. see, all the hype is about the rpi atm, which has proprietary chip + proprietary drivers even11:08
wpwrakor networking, for that matter. basically anything that touched the kernel.11:08
wpwraki'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 ? ;-)11:10
lekernelopenness is great to get cool technology done in a brilliant way11:10
lekernelbut it doesn't make a great and popular product11:10
wpwraki think fpgas are cool11:10
lekernelyes, but most people would disagree :-)11:11
wpwrakand i think it does help to make great products11:11
wpwrak(most people) see above, paris hilton's dog :)11:11
lekernelbut 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.11:13
wpwraki see the toolchain more as a proof of concept for having cracked the process, plus a basis for future development of the configuration process11:15
wpwrakten years from now, i want gcc or llvm or whatever to know there's an fpga and send code snippets to it :)11:15
wpwrak(and all that without having to do anything funny in my C code)11:16
wolfspraulwe believe in open because we think open builds the best products11:16
wolfspraulso now we have to proove this, and as I said before the proof is not so easy, especially to see today11:16
wpwrakthe fpga should be used as transparently as a barrel shifter in my cpu11:16
wolfspraulI would never expect a lot of people to care about 'open', what should that be?11:17
wolfspraulyou can only care about 'open' if you have a deep understanding first of how things get made, especially in a collaborative way11:17
wolfspraulthat alone shrinks you to 1% of the population11:17
wolfspraulbut that's no problem as long as the resulting products are great, which they will be11:18
wolfspraulI 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 hw11:18
wolfspraulbecause everybody is afraid to invest on that side too, besides Apple :-)11:18
wpwrakopen 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.11:18
wolfspraulsure, you say that as a professional, and of course I agree11:19
wolfspraulbut to reach a regular person, our product has to be great11:19
wolfspraulin terms of its look and feel, explanation, ease of use, documentation, intuitive interface, cool factor, and so on11:19
wpwrakand yes, good point about investment11:19
wolfspraullekernel: you were right about the rpi being a total broadcom joke btw11:20
wolfspraulI was never excited about the beagleboard, but when I see broadcom's stupid propaganda now I tend to defend even the beagleboard guys :-)11:21
wpwrakopenpandora next ? :)11:21
wolfspraulthis is a sad text, I only post it here in the happy milkymist forum because sebastien mentioned rpi again... http://www.linuxuser.co.uk/features/raspberry-pi-interview-eban-upton-reveals-all/11:22
wolfspraulwpwrak: nah, openpandora is run similar to us, although I think we can say with even less competence than us11:23
wolfspraulrpi is a simple broadcom marketing gimmick11:23
wolfspraulI didn't even know that on that chip, the entire ARM side is sandboxed by the closed GPU side :-)11:23
wolfspraulbut it all makes sense (to me) reading that interview, as Sebastien already said earlier11:24
wolfspraulmilkymist soc is 1000 times different and better than that11:24
wolfspraulcan't even compare11:24
wolfspraulit's just totally different11:24
wpwraki was thinking of making a matrix like this one http://kuehnast.com/s9y/uploads/langs.jpg11:25
wpwrakbut for (more or less) open hardware projects11:25
wpwrak"RPI as seen by Milkymist" would be http://en.wikipedia.org/wiki/File:Macaca_tonkeana_groupe.jpg11:25
wpwrakfor "Arduino as seen by Milkymist", i had this in mind: http://en.wikipedia.org/wiki/File:Schnuller.JPG11:26
wolfspraulwell it's ok, those are all very different projects11:27
wpwrakM1 -> M1 would be this, properly cropped: http://en.wikipedia.org/wiki/File:HAL_2001_monolith.jpg11:27
wpwrakben -> ben: http://en.wikipedia.org/wiki/File:The_giant_wenger.jpg11:28
wpwrakand so on :)11:28
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"11:30
wolfspraulcome on, he speaks for broadcom marketing11:31
wolfspraulhe is a full-time broadcom employee, interviewed at the broadcom offices, etc. etc.11:31
wolfspraulyou have to read between the lines11:31
wolfspraulthey are laughing at the freetards11:31
wpwrakit sounds as if he was in the child slave trade11:31
wpwrakor maybe specialty food marketing11:31
lekernelas everyone knows, the percentage of households with a computer has been in steady decline since the 80s11:31
wolfspraulthey 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 pressure11:31
wolfspraulit'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"11:32
wolfspraulha ha11:32
wolfspraulor "if we (pi) would make money, they (companies like broadcom) would screw us"11:32
wolfspraulthat's a classic, since it's coming straight from a full-time broadcom employee11:32
wolfspraulit's so twisted you need a higher degree in politics and marketing and corporate scheming first :-)11:33
wolfspraulrpi will go nowhere except as broadcom's puppy11:33
wolfspraulit's sad11:33
wolfspraulI 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 future11:34
wolfspraulrather than being exploited by some corporate marketing agenda11:34
wolfspraulthey can later always go to these guys to make money :-)11:34
wolfspraulto be fair to their pressure, they are fighting with TI and Qualcomm for survival11:35
wolfspraulthe last thing they care about are the sentiments of some foss guys11:36
wpwrakif 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 ...11:36
wpwrakhmm, RPI -> RPI self-image: http://www.infinitydish.com/tvblog/wp-content/uploads/2012/01/seven.jpg11:39
kristian1aullol (RPI)13:47
cladamwwpwrak, phew~ just finished all link of parts. email sent. i am very sorry about that no real file in there then. ;-)14:48
cladamwwpwrak, not sure if the ods or csv file are good to you to convert into BOOKSHELF14:50
lekernelhmm... anyone knows how to set the TOC depth with sphinx? it obstinately ignores my ".. toctree:: :maxdepth: 3" and all variations of it I tried14:52
lekernelaha http://sphinx.pocoo.org/concepts.html#id314:57
GitHub139[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/90546fd8117f3270afd2202e2662528df71c8a2b16:15
GitHub139[migen/master] doc: switch to sphinx - Sebastien Bourdeauducq16:15
GitHub47[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/59db4e9106300dde8025bc92d0dbd184fd44e49516:23
GitHub47[migen/master] doc: add logo - Sebastien Bourdeauducq16:23
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120309-1556/17:02
GitHub170[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/0165d23295896684af6f25d9dc5fb437c82d133a17:32
GitHub170[migen/master] doc: cosmetic changes (thanks rofl0r for reporting typos) - Sebastien Bourdeauducq17:32
qi-botThe firmware (using branch) build was successful, checkout the VERSIONS for detail, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120309-1802/20:22
GitHub32[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/7b1101ab993f63a500b798fcfce3a23590d8666f20:24
GitHub32[migen/master] doc: simulation - Sebastien Bourdeauducq20:24
GitHub165[migen] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/migen/commit/78c707e35410e4adfd887e34bb09352bff5abe3121:04
GitHub165[migen/master] doc: use script font - Sebastien Bourdeauducq21:04
sh4rm4lekernel, spotted another typo: the most advanced forms of procedural... that V*HDL offers21:08
sh4rm4i guess this should be "offer"21:08
sh4rm4and then ... and generatING statements21:09
lekernelI think both "offer" and "offers" are correct... V*HDL can be both singular or plural21:11
lekernelit's "generate" statement (referring to the vhdl/verilog keyword)... should be using the code font though21:12
sh4rm4same case here: ... one or several signal named bar21:17
sh4rm4i'm not sure whether it is valid to use the plural of memory to describe RAM21:24
sh4rm4(at least i haven't seen it before ;)21:25
sh4rm4"iff there is a write enable signal)21:26
lekernelhttp://en.wikipedia.org/wiki/Iff :)21:27
rohhm. xnor21:36
rohsay that and more people will understand ;)21:36
larscgiven the context a normal if is as strong as a iff anyway ;)21:53
qi-botThe firmware build was successful, see images here: http://fidelio.qi-hardware.com/~xiangfu/build-milkymist/milkymist-firmware-20120309-2132/23:50
--- Sat Mar 10 201200:00

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