#milkymist IRC log for Sunday, 2012-05-27

wolfspraulbut those are hacking projects for me and someone else (if anyone) needs to get behind them if they believe this could be a product00:00
wolfspraulI don't :-)00:00
wolfspraulso the best we can do to protect our users is to first finish the r400:00
wolfspraulif I can afford it, I will upgrade all units in stock00:00
wolfspraulthat gives us some rc3 devel boards to play with00:00
wpwraki wouldn't give up on m1 so quickly. i think it still has a lot of untapped potential.00:00
wolfsprauland we have a solid product ready to ship at any time00:00
wolfspraulthat's what I mean00:00
wolfspraulwe need those 10+ units in stock, because we have to believe that out of this base one day something with real demand will emerge00:01
wolfspraulkeep in mind that I only think about the sales potential00:01
wolfspraulnot some tech features00:01
wolfspraulwill ddr3 sell more m1?00:01
wolfspraulnever heard of that00:01
wolfspraulwill "the reactable of video" sell more m1?00:01
wpwrakfor the units in stock, a gateware upgrade that improves the pixel depth and brings the new memory controller would mean a significant improvement00:02
wolfspraulno way, never heard of that, it seems like just some random new attempt at making something cool, without having been asked for00:02
wpwrakwe're also not at the limits of vga. so we don't need dvi for resolution or such. dunno if it would be possible to add dvi though an expansion board00:02
wolfspraulmaybe we can extract it out of migen or migen/-ng generated sources and packport00:02
wolfspraulI'm taking the gloves off for backporting and improving m1, if we cannot 100% follow migen right now then so be it. the only thing that matters to m1 and its users is what actually works today, without regressions.00:03
wolfspraulall agree00:03
wolfspraulthe reason we need to go digital video is mostly because the analog video chips cost a lot of money00:04
wolfsprauland analog video is disappearing fast00:04
wpwrak(ract as amplifier) yes, that's also my feeling. that's why i'd also unbundle it. maybe the ract itself would be so cool that it takes off on its own. but mixing it with m1 seems dangerous because it wuold only be a nice product for those who like ract && m1. all others would hate to have to pay for the part they're not interested in.00:04
wolfsprauland, as in so many things m1, there are PLENTY of features missing even in the analog-in and analog-out side00:04
wolfsprauland nobody will work on those features00:04
wolfspraulract = zero demand00:04
wolfspraulI wait until there is demand00:04
wolfsprauldemonstrable demand00:04
wolfspraulbottom line: my focus is and remains m1, until I can come up with an idea for a 3rd product00:05
wolfspraul3rd as in Ben NanoNote -> Milkymist One -> ?00:05
wolfspraulthat 3rd one better have more demand (sales) than #1 and #200:05
wolfspraulthat's my problem00:05
wolfspraulI think it will use parts or all of the milkymist soc, in whatever variety (-ng/migen/old/mangled together/whatever)00:06
wolfspraulI think it will include some rf, I am still very positive on kristianpaul's work00:06
wolfspraulit must be cheap, super simple mechanical00:06
wpwrakract would basically a low-cost competitor for reactable. its success would hinge to a large extent on the quality of the market research reactable have done. if successful, it would kill them. of course, that's just nature taking its course.00:07
wolfspraulnew sales channel, new logistics00:07
wolfspraulyou don't kill anyone by saying it's a "video reactable"00:07
wolfspraulplus - kill what?00:07
wolfspraulyou think making those 20 10,000 EUR tables is a business?00:07
wpwrakno clue ;-)00:07
wolfspraulkristianpaul mentioned some 9 USD app - there could be some money there00:07
wolfspraulnah, this is in no way at all thouht through economically, but that's ok00:08
wolfspraulI'm not going to stop interesting projects00:08
wolfspraulmy 3rd product I think will also have dramatically less software00:08
wolfspraulwhat I learnt in both the ben and m1 is that we have overwhelmed ourselves in delivering really high quality to users00:09
wolfspraulwe don't have a test plan for either ben or m1, which is a joke00:09
wolfspraulit shows how we function :-)00:09
wolfspraulso we see, I don't know now and it won't get better with chatting, it will emerge from the work on m1 (and ben)00:09
wpwrakwe compensate with superior design that's immune to failure ;-))00:10
wolfsprauland the things that are lurking in the background, such as atrf, gps, ledtoy, etc.00:10
wolfspraulbut for sure I don't repeat a mistake that was learned in rounds 1 and 2 :-)00:10
wolfspraulI was very happy about the huge success of the pebble watch, for a number of reasons00:11
wolfspraulthey are not open hw00:11
wolfspraulthey are just a bluetooth extension of an iphone/android phone00:11
wpwrakyeah, the pebble is cool00:11
wolfspraulbut they did a lot of things right that I learned in the last years in hardware00:11
wolfspraulso we see00:11
wolfspraulm1 is cool, and I will continue00:11
wolfspraulI will increase the price, which should matter much in terms of lowering sales, but it will allow us to have the product for someone who really sees its value00:12
wolfspraulplus we can discount, finally :-)00:12
wolfspraul3rd product, it will come out of the ashes of the burnt #1 and #200:12
wolfspraulkristianpaul - please keep hacking :-)00:12
wolfsprauland werner too, and many others. and sebastien of course as well - the more works on m1 the better for me...00:13
wpwrakincreasing the price of m1rc3 units seems a bit odd, though.  but well, maybe it has some unexpected way of working ;-)00:13
wolfsprauland if some great new -7/ddr3/spi design comes out, neat. maybe something can be made out of that.00:13
wolfspraulkeep in mind that sales are 000:13
wolfspraulwe have to increase the price00:13
wolfspraulthe price was too aggressive as well00:13
wolfspraulbut m1 was wrong on a number of angles00:13
wolfspraulwhich was good to learn00:14
wpwrakthat's also in part because we more or less stopped any efforts of making it look attractive, and focused on m1r4 work in the last months00:14
wolfspraulI will never again sell a product that doesn't have a test plan with 100% coverage which I can walk throuhg myself first.00:14
wolfsprauljust to pick one thing00:14
wolfspraulI don't think so, why?00:14
wolfspraulwe try to make it attractive00:14
wolfspraulyou mean usb-midi controllers?00:14
wolfspraulopenclipart integration?00:14
wolfspraulthose things we try to work on, but you know we are just a few guys00:14
wpwrakwe didn't anything that would make it look interesting to prospective buyers. no new features. no new demos. hardly any new use cases.00:15
wpwrakand then you get the osborne effect with m1r4 :)00:15
wolfspraulI think xiangfu will soon finish the workaround of using a 703n dongle/router to provide wifi00:15
wpwrakso i'm not surprised m1rc3 doesn't sell at the moment00:15
wolfspraulyou can setup essid and password on the m1, it goes to the dongle over json, done00:16
wolfspraulthat adds wifi, a much asked-for feature00:16
wolfspraulafter that, usb-midi and openclipart00:16
wolfspraulosborne effect?00:16
wolfspraulha ha00:16
wolfspraulno, this needs a new name00:16
wolfspraulmost of the people who bought m1 are in one of the following states, or mix:00:17
wolfspraul1) why the hell did I let these guys talk me into this?00:17
wolfspraul2) milky what?00:17
wpwrak(just a few guys) sure. and all the output of us few guys went into m1r4 (or migen) so nothing moved on the m1rc3 side. and we already know that m1rc3 doesn't have enough momentum to keep on selling by inertia alone00:17
wolfspraul3) when my happiness and optimism gets too strong, and I cannot sit still anymore, I go back to my m1 for a little balance00:18
wolfspraulwhat else?00:18
wolfspraulthere is on 'osborne' effect00:18
wolfspraul*nobody*, but really nobody, is waiting for the next great milkymist product00:18
wolfspraulthey are all happy they survived the first one, mentally :-)00:18
wpwrakthere may be people out there who are considering to buy an m1 but wouldn't get an m1rc3 if the m1r4 is somehow around the corner00:18
wolfspraul no no00:19
wolfspraulthere are not00:19
wolfspraulI work in sales actually00:19
wpwrakand we've been giving the impression that m1r4 is coming. so ...00:19
wolfspraulthe only way to sell an m1 is to talk a friend into it long enough that his peace is worth more than 500 USD to him/her00:19
wolfspraulnobody is following, nobody is waiting00:19
wpwrakhehe ;-)00:19
wpwraki don't know. they can just lurk.00:19
wolfspraulsure not00:20
wpwrakwe can't know :)00:20
wolfspraulbut the reaction is correct, it matches with what I learnt about the product00:20
wolfspraulwhich is that pretty much nothing anyone imagines/expects works00:20
wolfspraulany remaining interest must come out of very zen-like needs, rare00:20
wolfspraulso anyway00:21
wolfspraulthe best idea I have is - finish r400:21
wolfspraulr4 has a number of hugely important things, including kicad & boom00:21
wolfspraulthat will be completely outside of sebastiens' view anyway, he won't care I think00:21
wpwrakwell, i don't see it with quite that much pessimism. most of the problems seem to have a solution. but there's a lack of focus on solving them.00:21
wolfspraulso there is no overlap with future milky development effortrs on his side00:21
wolfspraulhopefully it can combine later00:21
wolfspraulI am focused00:22
wolfsprauljust slow00:22
wolfspraulas I said I will continue with m1 as a product00:22
wolfspraulI do believe in it00:22
wolfspraulr4 now first, including kicad & boom00:22
wolfspraulI actually want to move the layout into kicad as well, we see. we already work on the footprints.00:22
wpwrakyou're contradicting yourself :)00:22
wolfspraulno, maybe not clear enough, sorry00:22
wolfspraulwhere is the contradiction?00:22
wpwrakif you already exclude making m1r4, then the product is pretty much finished00:22
wolfspraulthere is no demand00:23
wolfspraulwith 0 demand, you only need to make 0 units00:23
wolfspraulbut then you still 'made' enough00:23
wpwrakyou can sell these remaining units but then it'll be only a support cost item without any possible revenue00:23
wolfspraulsell to whom?00:23
wolfspraulI think we can upgrade the in-stock rc3 to rc400:23
wolfspraulthen we have our best possible product in stock00:23
wolfsprauland can polish the experience00:23
wolfspraulmake it 'more attractive' as you say00:24
wolfsprauland hopefully find a real uptick/demand somewhere!00:24
wolfspraulof course. that's why I need it in stock and working.00:24
wpwrakwell, what i would do is make a small number of m1r4 (for "internal" use), make sure they actually work, including dvi, and be prepared to manufacture a larger number00:24
wolfspraulthat's what we do00:24
wolfsprauland we can do more00:24
wpwrakthen focus on marketing and finding financing00:24
wolfspraulwe can upgrade our inventory00:24
wpwrakwhat would "upgrading' mean ?00:25
wolfspraulmake not 8 r4 boards, but maybe 2500:25
wolfspraulmake new side panels for the sides that changed00:25
wolfspraulupgrade the rc3 boards in all units in stock to rc400:25
wpwrakyou mean unsolder all the chips, put them on the new pcb, add the new items, ... ?00:26
wolfsprauljust an idea now, let's first verify r4 itself. but it's the best idea I can come up with since I do believe in the potential of the m1 product.00:27
wolfspraulgod no00:27
wolfsprauljust the whole pcba00:27
wpwrakyou can't upgrade rc3 to r400:27
wolfspraulwhy not00:27
wpwrakmaybe you could make an rc3+. but it would be quite different from the r400:27
wpwrakhow do you add dvi ?00:28
wpwrakall the new usb ports ?00:28
wolfspraulI don't get it00:28
wpwrakthe second extension header ?00:28
wpwrakthe leds ?00:28
wolfspraulI have 15 or so rc3 units in stock00:28
wolfspraulno no00:28
wolfspraul'upgrade' looking at the full box!00:28
wolfspraulI open the box00:28
wolfspraulopen the case00:28
wpwrakr4 hw has a larger feature set than rc3 hardware00:28
wolfspraultake the old board out00:28
wpwrakaaah !00:28
wolfspraulput the new board in00:28
wolfspraulswap the side panels00:28
wpwrakokay :)00:28
wolfspraulwait, breakfast. bbiab.00:29
wpwraki thought you mean to rework the rc3 to make them more r4-like :)00:29
wpwrakbut there is very little extra value if you already remove the pcba, half the case, the keyboard, etc.00:30
wpwrakabout the only things you'd keep would be the camera and some cables00:30
wpwrakso unless you have other plans for the m1rc3 boards or don't want to sell m1rc3 in order to avoid competing with m1r4, the "upgrade" wouldn't make much sense00:32
wolfspraulgrabbed it here00:34
wolfspraulno 'competing'00:34
wolfspraulbecause no sales00:34
wolfspraulof course the upgrade is a purely 'hope for the future' thing00:34
wolfsprauljust spend another few thousand usd without any demand00:34
wpwrakno sunday family breakfast :)00:34
wolfspraulbut that is no difference to tens of thousands already spent, and spending00:35
wolfspraulbut we have to believe in our own stuff first00:35
wpwrakwell, you could sell m1rc3 bare boards at a discount. maybe that'll get a few hackers aboard.00:35
wolfspraulif we fiddle around with r4, but keep selling rc3 (rather not selling, but 'offering'), then that shows m1 is really at a dead end00:35
wolfspraulcannot sell I think00:35
wpwrakwhy ?00:35
wolfspraulbut sure we have them and will carefully use for the core team :-)00:36
wolfspraulactually I think the small milkymist team is quite a good start00:36
wolfspraulbecause no demand00:36
wolfspraulthe way to sell an m1 is to talk someone into it00:36
wolfspraulthat's how 90% got sold00:36
wolfspraulof course - *nobody* then went on to recommend to a friend00:37
wolfspraulother than a story like "listen to what crazy stuff I just did"00:37
wolfspraulbut that is all fine, I just think positive and how we move forward 1) m1 product 2) future product00:37
wolfspraulI also agree with you now that we should tackle the problem of fpga pin reconfiguration00:38
wolfspraulthat's kinda like sand in the engine for any future thing we plan to do00:38
wpwrakwell, as i said, i think m1 has untapped potential. i think it can fascinate people. but there are a number of showstoppers we need to get out of the way first. since the video output is one of the key features, i'm very concerned about quality there. hence my insistence on the pixel depth. and my disappointment with what has happened there.00:39
wolfspraulwe need to understand the effort/breakage of having different pin configs on different boards, and maybe some simple but effective software tools to keep them under one umbrella still00:39
wolfspraulyes, I 100% agree00:40
wolfspraulwerner, unless I specifically say so, I always agree with you :-)00:40
wolfspraulwe need higher memory bandwidth00:40
wpwrakthen, writing patches may be too hard or simply unattractive for the average user. but we can make fairly generic patches. e.g., you can have hours of fun experimenting with the rain dance and all its controls.00:40
wolfspraulthe video specs are a total joke00:40
wolfspraullike a computer from a museum, maybe a museum sale?00:40
wolfspraulour problem is as we know that the goal of making a totally independent platform is also totally crazy and totally difficult00:41
wpwrakthe video specs are a problem, yes. i think, with improved memory bandwidth (pixel depth, perhaps a bit more resolution), and dvi, we'd at least be at a point where we can overlap with what people expect00:41
wolfspraulso it's not anyones fault actually, other than for thinking this might work :-)00:41
wolfspraulso maybe we can backport something sebastien has been hacking on?00:42
wolfsprauldon't know00:42
wolfspraulwpwrak: did you read what I said about changing fpga pins? I am with you on that one too now :-)00:43
wolfspraulthought about it for a while00:43
wpwrakas i understand it, the improved memory controller depends on migen. so one option would be to backport the memory controller into verilog. or go forward and make migen support the "legacy" hardware, and move the whole m1rc3/m1r4 to migen.00:43
wolfspraulwe don't need to break those assignments on purpose, but next time an opportunity comes up we make the jump and go from 1 pin config to 200:43
wolfspraulthe first step is the hardest00:43
wpwraki knew you'd eventually come around ;-)00:43
wolfspraulgoing from 2 to 3 and 4 etc. will be easier then00:43
wolfspraulI don't see anyone who would start working on either taking the verilog out and over into m1, or fully supporting m1 in migen00:44
wolfsprauland i hope that the few active hdl hackers there are right now continue and finish the stuff they are on, like mmu and gps. because they are hugely valuable in and of themselves.00:45
wpwrakthis is something sebastien should do. there's little point for someone else to spend months duplicating all the learning he has done when working on that.00:45
wpwrakwe can focus on other things. like linux and usb.00:45
wolfspraulif he gets to it, nice. but I think what he wrote a few hours ago was pretty clear.00:45
wolfspraulok, I think my plans, as of my current best thinking, are clear now :-)00:46
wolfspraulI keep learning as I go, and I think the direction is great, but that's my current brain dump00:46
wolfspraulfirst kicad and boom now00:46
wolfsprauland footprints, and maybe layout00:46
wolfspraulthen make those boards00:47
wpwraki consider what he wrote a proposal. now we're discussing it :)00:47
wolfspraulupgrade rc3 units in stock00:47
wolfspraulif I can afford that, it would be great. I think I can if we hurry up a bit.00:47
wolfspraulthat would give me an excellent base to keep looking for users and potential business partners (read: sales channels)00:47
wolfspraulor as werner would say 'investors' (but I still prefer 'sales partners' :-))00:47
wpwraki would disentangle people who give the project money from people who have sales channels. divide and conquer applies here, too ;-)00:48
wolfspraulI think we work on exactly the right thing00:50
wolfspraulso that should make the thing more attractive00:51
wolfspraulall fine00:51
wolfspraulthe more sebastien can contribute the better, of course I hope he delivers many great things for m100:51
wolfspraulbut it sounds like he will deliver nothing much for m1 anymore, it's just a devel board for now until he gets the kintex-7 devel board00:51
wpwraki think what's important regarding m1 strategy is to agree on the roadmap. so far, the plan was to deal with all the unsolved issues in m1r4. now, m1r4 may not happen as a product. so the new plan would be to seek a point where m1rc3 can enter stasis in a honorable way.00:52
wolfspraulat least on the core levels of faster memory, higher bpp, higher resolution, etc.00:52
wolfspraulm1r4 happens as a product!00:52
wpwrakif that statis should happen to be suitable for creating interest in m1r4, we'd be in a good position to make it happen quickly. if not, then so be it.00:52
wolfspraulit's great that we have rc3 units in stock we can upgrade00:53
wolfspraulbut of course I will not make another batch of 100 r4 or so, why?00:53
wolfspraulfor whom?00:53
wolfspraulno demand00:53
wpwrakokay. well, we probably shouldn't call this "upgrade". it's like getting a new pc but keeping the old mouse ;-)00:54
wolfspraulI look at it from the box00:54
wolfspraulthere is tremendous effort in the accessories, case, box, etc.00:54
wolfspraulwhoever wants to make another product in the future will find out too :-)00:54
wolfspraulor just don't do it, and go for an iPad app00:54
wolfsprauldo we have a plan?00:55
wolfspraulI do :-)00:55
wolfspraulI hope I don't demotivate anyone here00:55
wolfspraulit should be quite the contrary00:55
wpwrak"upgrade" sound too much like a modification of the m1rc3 device to me. i understand now that you mean "upgrade the product". but the use of "upgrade" seems misleading.00:56
wolfspraulI cannot wait to have the MMU for example, and maybe through some magic we can get a Linux kernel dev to restart that effort. don't know.00:56
wolfspraul'upgrade' is just for our internal communication00:56
wolfspraulit's the best and only way I can think of using (and demanding use) from r4 right now00:56
wolfsprauleven that will waste me thousands of usd00:56
wolfspraulbut I think we should do it as a vote of confidence in the future of m1 and future milkymist-based products00:57
wpwraki know you approach to dealing with disappointment. you reach a point where you assert that it's hopeless, that it'll never work, and that this was clear from the beginning. fortunately, this doesn't stop you from supporting efforts to prove you wrong. remember #1024 ? ;)00:57
wolfspraulha, sure00:57
wolfspraulI am speaking my mind, and also work through and grow on these efforts00:57
wolfspraulevery disappointment is the source of energy to make things better00:58
wolfspraulin that sense m1 gave me energy for the next 10 years00:58
wpwrak(linux) yeah, if all else fails, i may have to do it myself :)00:58
wolfspraul'clear from the beginning' is a little unfair to all of us, I think00:58
wolfspraulfor myself I can just say - I learnt like crazy through this, and would know no other way to learn those things00:58
wolfspraulalso I do think milkymist has a future, and I want to keep the tech together00:59
wolfspraulthat's my worry a little about what is 'legacy' or 'backported'00:59
wolfspraula franker term might be just to call it a fork00:59
wolfspraulthen everyone knows what it is :-)00:59
wolfspraulbut that would not be good00:59
wolfspraulso let's see01:00
wpwraki suspect that switch to extreme pessimism once you've crossed that point may be an attempt to shame those engineers to finally get their act together and solve the damn problem :)01:00
wolfspraulI rather thing how I can get myself into a position where I can help myself01:00
wolfspraulthat bridges the waiting time constructively :-)01:01
wpwrakhmm, if you're looking for things to do ... :)01:01
wolfspraulI have the m1 schematics here and keep reading them, nice...01:01
wolfsprauljust so I get a better feeling of how things are wired up01:02
wpwrakyeah, i like them. adam did very good work there.01:02
wolfspraulwpwrak: what do you have in mind?01:05
wpwrakwrite patches. patches that use midi. make demo videos.01:06
wpwrakit's a lot of work, also finding the right music and such. that's why i do so little in that direction at the moment. i still plan to make a "control freak" video with the rain dance patch that shows off the 30 or so controls it has acquired by now. but that'll be several days of work.01:07
wpwrakand of course, it would be so much nicer if things didn't just all fade to green ;-)01:08
wpwrakyou have an lv3, right ?01:08
wpwrakthen you could try https://github.com/milkymist/flickernoise/blob/master/patches/demo/raindance/raindance.fnp01:14
wpwrakto get an idea of just how many controls one can cram into a patch :)01:14
wpwrakthis does the stuff you've already seen. plus it allows fine adjustments of rotation, static angle, has some crossfade effects, and you can use the joysticks to add some distortions.01:15
wpwrakmy plan for a video is to mount the thing on a chair, then place the camera such that it looks over my shoulder (well, a bit from the side), at lv3 and tv screen, and then i could do a little starship enterprise lookalike :)01:17
wpwrak(at least as far as the command chair is concerned)01:17
lekernelwpwrak: the new memory controller works _today_ on the M109:41
lekernelbetter go the other way and port the other cores into milkymist-ng for M109:42
lekernelwolfspraul: I don't think the M1 features are all about overpromising. first we did test every single of them at the hardware (pcb) level - that's what the m1testing program (remember it...?) that I wrote is for...09:47
lekernelso it's perfectly sound as a development/experimental hardware platform. then there are gateware/software bugs.09:48
lekernelthe problem here is simply that there are not enough people to fix them. but just have a look at opengraphics, opencores, etc. ...09:50
lekernelyou could say it was totally expected, even :)09:50
lekernelalso, the mirteo isn't just a random cool-looking device. it actually addresses the common M1 problems - though you could say that's still random :)10:02
lekernelpoor video quality => ddr3 + 32bpp + multiple HD ports10:02
lekernelcode is scary => effect is defined using the reactable-style interface10:03
lekerneltoo many time-wasting features like USB => strip it down to the bare minimum so it does one thing well10:04
lekernelswitching between performance and render mode is lousy (confusing + non-instantaneous feedback) => also solved by the new if10:04
lekernelm1 is difficult to explain => "look, I put this object here and it does that"10:06
lekernelof course that doesn't mean it will be successful10:07
lekernelbut I think it has much more of a chance than the M110:07
lekerneland anyway it would be more interesting to watch this one fail than continue with the stream of recurring M1 problems...10:08
wpwrak(memory controller) which subsystems are using it so far ? cpu, video out (refresh), what else ? pfpu, video in, ... ?11:44
wpwrak(mirteo) besides all the technical issues, there's the question whether this device would actually fit the vj's needs. e.g., all those little critters you're supposed to put on that table can also be lost. so this would make the device risk to use for live performances. you wouldn't want to have to search the floor of the DJ cabin in the middle of a performance because some knob fell off the table.11:48
wpwrak(code is scary) we can already do a lot of things with midi. have you run into situations where you actually exceeded the number of controls lv3 gives you ? highly configurable patches are a different paradigm than writing one patch per effect. but you'd need to write them for the mirteo as much as you need to write them for m1.11:50
lekernelwpwrak: direct DMA to DRAM (= cores harder to move to/from -ng) is for framebuffer, video-in and TMU11:56
lekernelpfpu uses wishbone (you don't need that much bandwidth for vertices...)11:57
lekernel(code) you would not write a patch anymore. the position and other parameters of the objects will fully determine the current video effect, just like they determine the sound on the reactable11:58
lekernelthen there can be "ghost" modes, where the object is no longer there but still acts. allows saving/restoring patches, and reducing the number of objects when there are some you know you don't want to play with anymore.11:59
wolfspraulall the great things I learnt with Milkymist came from putting it in front of people and listening to their feedback12:00
wolfsprauland even though I realized that >95% of the promise of m1 (or what people thought of it) were disappointed, the remaining 5% still prove valuable12:00
wolfspraulthere's no way I will walk away from what is most valuable, the user feedback we got on m112:01
wolfspraulaka 'bugs'12:01
lekernelwolfspraul: the new interface would also have the advantage of making it much clearer what the device does and does not12:03
wpwraklekernel: (memory) so which memory bus users do work now ? not fb -> video, not video-on, not tmu ? so it's only the cpu ?12:03
wolfspraulfinish the mmu, switch from rtems to linux without regressions, if migen is not as easy to introduce to m1 (without regressions) than thought then no need to use it, just keep using plain Verilog, on the 'interesting new things' side get back to the abandoned (?) llhdl12:03
wolfspraulthat's just my thinking, but please everybody do as they like12:03
wolfspraulwe are a free wheeling group :-)12:03
wolfspraulI love to continue on m1 and will do so12:03
lekernelwpwrak: right now yes, but i'll probably have the framebuffer shortly12:04
lekernelwolfspraul: and what do mmu and linux bring, feature-wise?12:04
lekernelthe m1 will still be an obscure box with a slow CPU12:05
wolfspraulthey are also risky but may make the platform more attractive and more maintainable, and bring new people in12:05
wolfsprauldefinitely better than fixing rtems bugs, or nuttx porting now12:05
wolfspraulbut we can try it all, and see what works12:05
wolfspraulbut that's a realization that only came from putting it in front of users and not running away :-)12:06
wolfspraulI need more of that, not less12:06
wolfsprauland eventually a really good product idea will emerge12:06
lekernelI think the mirteo is a pretty good idea.12:06
wpwraklekernel: (code) so there will be no user-visible code at all ? everything done by adjusting parameters and connecting blocks ? have you tried that interface yet, to see if it is actually flexible enough without producing a maze of items on the table ?12:06
wolfspraulhopefully others agree (if you care)12:06
wolfspraulI stay on m1, 100%12:07
wolfspraulthe best things in m1, and thus milkymist, are yet to come12:07
lekernelwpwrak: yes / not totally yet, but that's down the road12:07
wpwrakmmu + linux = drivers and freedom from rtems breakage :)12:07
wolfspraulis llhdl abandoned?12:07
wolfspraulthe mmu/linux move is also risky12:07
wolfspraulbut there are risks everywhere12:08
lekernelthe mirteo won't need drivers or rtems, so I'm already ahead there12:08
wpwraklife is risky :)12:08
wolfsprauland for sure it broadens the appeal of the platform12:08
wpwrakgetting down from those trees was damn risky :)12:08
wpwraklet alone leaving the safety of the water ;-)12:08
wolfspraulmmu/linux are not 'guaranteed to suceed' moves in the context of milkymist12:08
lekernelwolfspraul: (llhdl) commented on that last week or so. executive summary: yes.12:08
wolfspraulah ok12:08
wolfspraulthen someone could continue12:09
wolfspraullemme read the backlog, sorry I didn't search first...12:09
wolfspraulso we have 3 people that are more interested in llhdl than migen12:10
wolfspraulpeople who are continuously involved with m1 - werner, kpaul, me12:11
wolfspraulinteresting :-)12:11
wolfspraulI don't believe llhdl will bring immediate benefits to the m1 user, it's a little like the mmu/linux idea12:11
wolfspraulbut for example I personally don't believe migen will ever bring any benefit to the m1 user either, because it's too much work to rewrite all of the m1 cores via migen12:12
wpwrakllhdl would be more something that brings humanity forward. like having an open source unix kernel.12:12
wpwrakfor m1, it should be irrelevant12:12
lekernelit's not, you can instantiate the verilog cores from migen12:12
wolfspraulI think if someone would solidly hack away on it, it can't be such an impossible task12:12
wolfspraulall a matter of focus12:12
wolfspraulsure, we can try that - for example take the mem cntrl from there and backport to m1?12:13
lekernelby the way, your estimate of interested people is wrong - there are the rhinoplatform.org people (and some more) who are using migen12:13
wolfspraulmight be ugly though :-)12:13
lekernelso, 5th time or so12:13
wolfspraulnew url - great12:13
wolfspraulare they m1 users?12:13
lekernelthe migen/-ng memory controller works on the M1 today12:13
wolfspraulunusable for m1 users12:13
wolfspraulbecause it would break 80% of the few things that do work with the other parts of their machine12:13
lekerneland for the other cores, just instantiate the legacy verilog from migen if you want an easy way12:14
lekernelonly two are troublesome: video-in and TMU12:14
wolfspraul9 months ago rhino was 'ready to manufacture'12:15
wolfspraulis the project active?12:15
lekernelyes, website isn't updated12:15
wpwraklekernel: i don't think we know whether it really works. after all, you've only tested it with a single user so far, haven't you ? so test coverage is rather incomplete. what we should have at the moment is that you still feel confident that the memory controller will be able to handle this, too. this is good, but doesn't replace a real life test.12:15
wolfspraulnice I never heard about it before - thanks a lot for the link!12:15
lekernelwpwrak: nevertheless I'm prototyping it on the M1 and will fix the bugs12:16
wpwraklekernel: sure. just trying to clarify the finer points of "it works" :-)12:17
lekernelI'm also planning to support the DVI output in -ng12:22
lekernelon m1r412:22
wpwrakvery good. to fill the gaps in m1 to an extent where they aren't quite so painful anymore, we have to be efficient. that means, if we're resource-constrained, to do the things that are easy for us. and of course, each of us has their own strengths.12:26
lekernelhe, that's what I've been saying all along12:27
Fallenoufyi, I am still commited to keep working on the mmu, it's making small progresses every week, I am planning on testing if the exception handling is reliable. I just have very little time, but I have not stopped at all :)12:29
wolfspraulFallenou: oh my god please continue12:29
wolfspraulwe need to invest in the right things, and the mmu is definitely one of them12:30
FallenouI would like to see a Linux-with-mmu booting on my M1, but I don't know if that would boost up sales and the project ^^12:30
wolfsprauldoesn't matter, don't worry12:30
Fallenoubut I'm doing it anyway, just for the sake of learning :)12:30
wpwraki mean on the path towards making m1 a more credible device :) all the mirteo and new milkymist with new fpga, ddr3 and what not looks more like a way to increase the workload to me.12:30
lekernelprobably not, but it has nerd-fu12:30
wolfspraulan mmu which can be easily enabled or not would add great value to the platform12:30
wolfspraulno way12:30
wolfspraulmigen is nerd-fu12:30
wolfspraulbig time12:30
wolfspraulmmu is an important feature in a larger machine12:31
wolfspraulwhere milkymist in the future is hopefully used in very integrated/small machines, and also larger machines running the full blown mmu/linux12:31
FallenouI'm a bit concerned by the "abandon" of M1, I think like wpwrak that there is still room for improvement (in usb and FN for instance, and DVI maybe)12:32
wolfspraulwon't be abandoned12:32
wolfspraulall the valuable things we learned was trying to make a product ouf of it and trying to put it in front of regular people12:32
FallenouI know, I've read the backlog, but focusing on a new product is a way of abandoning the old one :)12:32
wolfspraulonly to get their big stares back :-)12:32
wolfspraulWHAT IS THAT?12:32
wolfspraulare you crazy?12:32
wolfspraulwhy does A B C D E F G and so on not work?12:32
wolfspraulis this from a museum?12:32
wolfsprauland so on12:32
Fallenousince resources are very limited12:32
wolfspraulthat was the great part12:32
wpwraklet alone the overall development cost. wolfgang has already said he couldn't shoulder that. and if m1 is in a semi-abandoned state when you go to look for other sources of financing, that may raise some red flags in those people. investors familiar with this sort of projects should have a keen sense for this sort of signs of trouble. they may understand nothing about the technology, but there are development patterns that can tell a lo12:33
wpwrakt, too.12:33
wolfspraulshoulder what?12:33
wolfspraulI hope we focus on m112:33
wolfspraulI am12:33
wolfspraulthe only thing that makes me kick is user feedback12:33
wolfsprauland that was fantastic the last 2 years12:34
wolfsprauleven though it was mostly a huge list of things that don't work :-)12:34
Fallenouit's understandable, limited resources, so the developments is "slow" (even if I find it really fast regarding to the very few people contributing)12:34
wolfspraulI think milkymist, and m1, are the most advanced free and new computing architecture in the world12:34
wolfspraulat least I am searching for better ones but cannot find12:35
wolfspraulslow doesn't matter if we do the right things12:35
Fallenouso slow developments means bugs not yet fixed, and features "not yet implemented completely"12:35
wolfspraulwhich I believe includes kicad, boom12:35
wolfspraulmmu, linux12:35
wpwrakwolfspraul: shoulder the development of a future device that combines reactable with milkymist12:35
wolfsprauloh, I am totally not interested first of all12:35
lekernelI will.12:35
wolfspraulgreat, and maybe some breadcrumbs fall off for old and rusty m1 :-)12:36
wolfspraul-7 series, ddr3 and spi definitely would be interesting things for m112:36
lekernelsure (to both)12:37
Action: Fallenou must says he is excited about "m2" featuring milkymist-ng+new fpga+ddr3+digital video12:37
wolfspraulFallenou: please continue and finish the mmu, I totally trust your "slow and steady" development model. it's unstoppable :-) we will build the most awesome machine out of this stuff later, guaranteed12:37
FallenouWill do !12:37
wolfspraulmaybe the paris subway can slow down a little12:37
wolfspraulit will speed up mmu development12:38
wolfspraulwe should make a few calls in the right places!12:38
wpwrakFallenou: the mmu is very important. an mmu means that you can have a proper linux on it, without all the weaknesses of an mmu-less system12:38
wolfsprauland it needs to be easily enabled and disabled12:38
Fallenousure, but we will need someone motivated in fixing theobroma linux bugs (if I understand correctly)12:38
wolfspraulbecause I agree with sebastien that very interesting machines in the future may need to be built without all the legacy of linux, usb, and similar overloaded standards12:39
Fallenouanyway, first things first12:39
wolfspraulbut we need both, and we need them to compete12:39
wolfspraulthe full-blown linux system on one hand, expensive and slow as it may be, but with some advantages12:39
Fallenou14:44 < wolfspraul> maybe the paris subway can slow down a little < hehe, paris subway is definitely slowing down mmu progress :p12:39
wpwrakFallenou: so while it's not a requirement for having linux on the m1 in the strict sense, it's something that gives the assurance that a port won't have to stop with a crippled feature set, because that key piece is missing.12:39
wolfsprauland the super-integrated high-performance bare-bones system on the other hand12:39
wolfspraulmay the two compete happily ever after :-)12:39
wpwrakFallenou: besides, planning to have no mmu would also affect some design choices when making the basic system12:40
Fallenouwolfspraul: OK I see (full blown linux / super integrated)12:40
wolfspraulback when the linux port on m1 was still active, over time I got the definitive impression that everybody said "in the end linux without mmu is worthless"12:40
wolfspraulFallenou: yes, we need both, and we need them to compete12:41
wolfspraulbecause with all chatting here, we cannot find out and predict which one will work better in which use case and marketing case12:41
Fallenouwell yes, memory protection for user space is really a needed feature for a stable system12:41
wolfspraulso if sebastien is storming ahead on some fancy new features, so be it12:41
wolfspraulit's good12:41
wolfspraulsomething will come out of it12:41
wolfspraulI am sure that chips will become tremendously more powerful still the next 10 years, let's say12:42
wolfspraulthat leans towards the value of a large system like Linux12:42
wolfspraulon the other hand there is nothing better than cutting out all the old crap with one big swing of the sword12:42
FallenouI've never seen any sebastien's development that have been proved worthless :) it always ends up with a powerful nerdy technology :)12:42
Fallenoulet's everybody work on what he thinks is necessary/cool/important, we'll see what comes out of all this :)12:43
wolfspraulllhdl is unfortunately abandoned right now, but that begs to be adopted somewhere12:43
FallenouI've got to run to get something to eat (almost 3 pm here) in order not to starve12:44
Fallenousee you !12:44
wpwrakgood hunting ! :)12:44
Fallenou=) thanks12:44
wpwraklekernel: a lower-risk approach to a new interface would be as follows: 1a) find a device that can do video out and has a touch screen, acting like a mouse or such. not sure if there are nicely priced critters of that kind. 1b) if they're too expensive or otherwise troublesome, use a tablet instead.12:47
wpwrak2) write code to show controls (and any other command functions you may want to be able to access in performance mode), like that software-only reactable. the controls act as inputs to the core software running on m1.12:49
wpwrak3) make these things act like midi inputs to patches. that way, we can easily upgrade existing patches.12:49
wpwrak4) design your visual "patch-less" system and try it with that hardware. once you're happy with it, move on to12:50
wpwrak5) build your own hardware.12:50
wpwraksuch an incremental plan allows you to do things in manageable steps. you get feedback along the way (so you can detect mistakes early and resolve them at little stress and cost) and you have little successes on a regular basis.12:52
wpwrakeven better, if you change your mind at some point in time, you hit a problem that takes a lot of time to solve, you'll have created things that are useful already. so you don't have to wait until the last piece is in place, in maybe two years or so, to see any return.12:54
wpwrakalso, it would allow you to reuse the existing m1 for a long time as a basis. the features you don't like won't get in the way, and they can evolve in parallel and at their own pace.13:09
wpwrak(1a) hmm, seems that cintiq and sentip are the only choices at the moment. both pricy. so plan 1b. actually, you could probably do decent enough video over wlan or even usb with 1 bpp and a bit of compression, doing the refresh on the tablet.13:30
wolfspraulvideo over rf is great13:30
wolfspraulI like it :-)13:30
wolfspraulanything rf makes me happy right now13:30
wpwrakwlan is rapidly becoming the next usb, in terms of "market admission requirement". if it hasn't already done so.13:32
wolfspraulthe llhdl backlogs tell me that llhdl will happen when milkymist beats the raspberry pi in google trends13:32
wolfsprauloh my :-)13:32
wolfspraulbut ok, it's a clear thing at least13:32
wolfspraulis milkymist even measurable?13:32
wolfspraulno "not enough search volume for ranking"13:33
wolfspraulwill check again in a year or so :-)13:33
wpwrak"not for the unwashed masses" :)13:34
wpwrakif popularity was the goal, then we should all happily dance around facebook and post pictures of cats playing with poodles13:35
wolfspraulwhich other free and new computing architecture similar to milkymist is more popular?13:36
wolfspraulor what is milkymist, in fact?13:36
wolfspraulwhat do we measure popularity against?13:36
wolfspraulif I find a better free platform, I switch :-)13:36
wolfsprauluntil then, I think milkymist is actually the best one (of that kind), and also most popular13:36
wpwrakhmm. http://www.googlefight.com/index.php?lang=en_GB&word1=milkymist&word2=openrisc13:37
wpwraknow the most reliable test, though: http://www.googlefight.com/index.php?lang=en_GB&word1=milkymist&word2=flickernoise13:37
wpwraka part is bigger than the whole13:38
wolfspraulwell, exactly!13:38
wolfspraulmilkymist is over 50% of openrisc already!13:38
wolfspraulthat's unbelievable13:38
wolfspraulopenrisc is far older, but I don't know where it comes out in one package as strong as we have on m1 - urls welcome13:38
wolfspraulit typically appears under the hood in all sorts of partially-open/partially-closed environments13:39
wpwrakfor comparing cores, this would be fairer: http://www.googlefight.com/index.php?lang=en_GB&word1=lm32&word2=openrisc13:39
wpwraknow, which is the flagship project of openrisc ?13:39
wolfspraulI can easily recommend m1 to anyone wanting to go below kernel, into digital design, computing architecture, etc.13:40
wolfspraulsimply because I don't know a better starting point. if I find one, I will reconsider.13:40
wolfspraulof course13:40
wolfspraulif it's free, we would all benefit from mixing and matching13:40
wolfspraulso I am constantly on the lookout13:40
wolfspraulbut for the time being I think we can consider milkymist very popular for what it tries to do and what it's uniqueness is13:41
wpwrakyeah. m1 is a complete system that's fully free (except for the toolchain). that's pretty unique.13:41
wolfsprauland relatively well supported entry points, everywhere13:41
wolfsprauland those entry points are improving13:41
wolfspraulthat's why I think llhdl would be great, for example. another entry point.13:41
wolfspraulI do not think a large part of the world is waiting for a 'free soc' though13:42
wolfspraulso the 'popularity' if such an endeavor will always be a tiny fraction of even rusty Paris Hilton introducing yet another fragrance13:42
wolfspraulso what13:42
wolfspraulbut if we can make a kickass product out of it one day, then we know the investment was worth it13:43
wpwraksometimes, people don't realize what they want until it's being shown to them13:43
wolfspraulnot that even then many people will care what's inside - almost nobody will13:43
lekernellet's have Paris Hilton introduce our products then ;)13:43
wpwrakor put a poo-dle on it, and write "paris hilton would take him". let the readers figure out why they think that may not make it the best choice for everyone else ;-)13:44
GitHub76[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/BMWFDQ13:47
GitHub76[milkymist-ng/master] software/libbase: fix memcpy handling of buffers with differing alignments - Sebastien Bourdeauducq13:47
GitHub191[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/fe4299b8a58fb4a3598bccd09dcf9515db80f0e213:48
GitHub191[milkymist/master] software/libbase: fix memcpy handling of buffers with differing alignments - Sebastien Bourdeauducq13:48
GitHub90[milkymist-ng] sbourdeauducq pushed 2 new commits to master: http://git.io/HJdICg14:07
GitHub90[milkymist-ng/master] software/libbase: __floatunsisf/__floatunsidf - Sebastien Bourdeauducq14:07
GitHub90[milkymist-ng/master] software/libbase: memcpy: same with 2 alignment - Sebastien Bourdeauducq14:07
GitHub118[milkymist] sbourdeauducq pushed 1 new commit to master: https://github.com/milkymist/milkymist/commit/c7ace9a77918de8974d87ef3ea42e84d205b530914:07
GitHub118[milkymist/master] software/libbase: memcpy: same with 2 alignment - Sebastien Bourdeauducq14:07
stekernwpwrak: the flagship project for openrisc is... openrisc ;)14:16
stekernmilkymist SoC is a far more defined SoC than any of the reference SoC projects, orpsoc and minsoc14:18
stekernthey are more thought of as "easy" startup-points for people that wants to try out openrisc14:20
FallenouDoes it annoy someone if I add a github hook to get "commit push" messages for Milkymist MMU related repository here on IRC? like GitHub90/11815:14
FallenouI am activating it, don't hesitate to tell me if it's pissing you off15:32
wpwrak(1a) this one looks pretty nice: http://www.iiyama.com/gl_en/products/prolite-t2234mc-1/15:35
wpwrakbigger than the wacom / hanvon devices, wider viewing angle, rugged, and in the same price range15:36
wpwrakand they even provide linux code ;)15:37
wpwrakstekern: (flagship) ah, so wikipedia is right on this :) and yes, compared to the others, the milkymist soc is a rather nicely rounded package already15:39
wpwrak(1a) make a nice wooden frame, place the monitor and the m1 inside, with clean internal cable routing, and you have a good package at virtually zero extra hardware r&d cost15:42
wpwrakthis one is even a bit cheaper (19"): http://www.iiyama.com/gl_en/products/prolite-t1731sr-1/15:47
wpwrakerr, i mean 17"15:47
stekernwpwrak: to be fair, the wikipedia says "OpenRISC is the original flagship project of he OpenCores community", nowdays it's scope is beyond opencores though15:57
Fallenou6 min 50 seconds to generate a minimalist Milkymist SoC bitstream in a Debian virtual machine on a Macbook pro16:13
Fallenouwith all optional cores disabled16:13
Fallenouand a nice priority of -19 for the make process16:14
Fallenoupretty fast :)16:14
kristianpaulsurvived the first one, mentally  ;-)17:29
wpwrakFallenou: btw, is the mmu currently for the verilog-based system, the migen-based one, or both ?17:50
FallenouI am simulating the MMU project using a migen generated SoC, and using ISim for the simulation17:54
Fallenoubut when I test on real hardware I am using the "normal" SoC (non migen based)17:54
wpwrakbecause the latter still lacks features ?17:54
FallenouI have not tried booting milkymist-ng yet :)17:55
FallenouI guess it could be a good test to try milkymist-ng+mmu on the M117:55
FallenouI think it's pretty recent that milkymist-ng boots on the M117:56
wpwrakah, i see17:56
Fallenouanyway the MMU is hidden deep inside lm32_dcache.v (for now only DTLB is implemented) and a little bit in lm32_cpu.v17:56
Fallenouall of this is independant of using migen or not17:57
wpwraklekernel: besides the missing features, does the migen-based gateware look different to code running on the M1 (application, operating system, etc.) than the verilog-based one ?17:57
Fallenoumigen "just" generates the interconnect arbiter and the SoC cores, but it generates nothing inside lm32 cpu17:57
Fallenoummu is only inside lm32 cpu17:57
wpwrakFallenou: interconnect arbiter = the interface between cpu core and the memory bus ?17:58
Fallenouwishbone arbiter, interface between cores17:59
wpwrakisn't the memory bus in parallel to wishbone ?17:59
FallenouAFAIK on milkymist-ng, FML has been replaced by ASMI18:02
Fallenouso yes there is some kind of a "memory bus" called ASMI18:02
Fallenouconnected to wishbone bus18:02
Fallenouusing the wishbone2asmi core18:03
Fallenou(the gateway between the 2 buses)18:03
Fallenouand the memory controller is on the ASMI bus18:04
wpwrakah, i see. i thought it was completely parallel18:04
Fallenoubut to have a simplified idea in mind, you can just think of the soc as just one wishbone bus with all the cores connected to it18:05
Fallenouand all the wishbone mess of wires and arbiter is generated dynamically by migen18:05
Fallenoutaking care of addresses, number of slaves, number of masters and so on18:05
Fallenouall the real topology can be read there https://github.com/milkymist/milkymist-ng/blob/master/top.py18:06
Fallenou20:10 < wpwrak> ah, i see. i thought it was completely parallel < the two buses are indeed "parallel", but they are connected18:07
Fallenouby a "gateway" core18:08
Fallenouhttp://upload.wikimedia.org/wikipedia/commons/8/84/Milkymist_architecture.svg < the "gateway" on regular non-migen-based Milkymist was Slave 4 "FML bridge"18:08
FallenouI hope I didn't unnecessaryly made your representation of the SoC less clear than it was before :p18:09
kristianpaulstill room for improvement, yes like wpwrak'w work around improveing patching language18:09
kristianpaulalso if the fpga is not fully used, why not add second cpu? well too fancy perhaps18:10
wpwrakFallenou: no, that helps a lot for arranging the pieces in my head :) thanks !18:10
kristianpauleven tought hardware is no full feature in specs, try avoid the same software missing features and bug fixes history wont happen again18:11
kristianpaulwpwrak: VERY good idea, use a cheap tablet first :-)18:11
kristianpaulor two chep tablets, that will be fun18:11
kristianpaulstekern: when getting to folks light that milkymist based soc? :-)18:13
kristianpaulperhaps other path forth a linux friendly system.. or a lm32 openrisc combo in same soc18:13
kristianpaulwpwrak: i feel you donk like too much the use of the 703n + m1 combo, but thats a cheap out of the box system at least with one usb host port that can serve to provide wifi (that seems almost ready?) and propably usb support for memory stick18:17
kristianpaulcounting for that in same package thats one less problem to solve for now18:17
wpwrak(tablet) a monitor with touch surface should be pretty ideal. a bit more expensive than a low-end tablet, but you can a) get them at more interesting sizes, and b) you avoid having to develop code for android as well18:17
kristianpaullekernel: I see you coming work around a the xilinx-7 family and ddd3 and interesting effor to have a *dedicaded* box for generating HD-like huh blabla quality imagery18:18
wpwrakand m1r4 hw will already be dual video out capable. bandwidth shouldn't be a problem: for a proof of concept, even 1 bpp should do nicely18:18
kristianpaulsomething will not look like m1 gets abandong but a coming nice box that upgrades video out18:18
kristianpaulwpwrak: i will buy a tablet when they be at least 16", that will be awesome to try touch based kbd on it18:19
wpwrak(703n) what does it look like ? some diy hack with a little box somehow bolted/glued to the big box ? or does it look "smooth" ?18:20
kristianpauli may look like as we want it to :),d you have a 703n btw18:20
wpwraki don't have one18:20
kristianpaulboard is really small, i just imagine hacking or sending to produce a second box for  mine and add a usb port some how to make it extend and fix in same box18:21
kristianpaulwpwrak: dont know, ask xiangu i guess18:21
kristianpauli dont know if its work include making fit in same box.. dont know but even no18:22
kristianpaulalready ahving that usb host port, why not use it18:22
kristianpaulanother round to try rtems nfs support too ;-)18:22
wpwraki don't trust approaches where you need to do a lot of engineering just to integrate an end-user product over which you have little control18:22
kristianpaulme either18:22
kristianpaulbut and off the shell product that add some value? but problem solving to our current neeeds is not that bad worth too look at18:23
wpwrake.g., what if they decide to make the next version 5 mm shorter ? then any adapters you cook up will have to be redone18:23
stekernkristianpaul: as soon as Julius Baxter get green lights from his company to release the cpu source18:23
FallenouI think having Linux running correctly (with shared objects, mmu and so on) could attrack geeks :)18:23
kristianpaulindeed Fallenou18:23
Fallenoufor now, without Linux, I don't know who it can attrat18:23
kristianpaulattrack more software people wanted to hack in higer layers too :)18:24
Fallenoueven geeks can be disgust because it does not run their favourit OS18:24
wpwraki'd much rather try my luck with a usb dongle. there are a few to choose from. according to wolfgang, they're not great. which would coincide with my impressions when wrestling with wlan a few years ago. but perhaps they're good enough.18:24
kristianpauland re-use all that software already works on  other lowend devices (for instance jlime project as reference)18:24
Fallenousure, having linux means the basic geek can hack his way almost easily18:25
Fallenouhe can try to just cross compile his software18:25
Fallenoufix a few porting bugs and voila18:25
kristianpaulyah !18:25
wpwrakFallenou: yes, rtems is a big barrier for hackers18:25
Fallenouinstead of porting from scratch to RTEMS18:25
Fallenouindeed RTEMS is open source and free18:25
Fallenoubut it can be a lot of work to port something on it :/18:25
Fallenouat least, more work than porting to Linux-lm3218:26
Fallenou(IF it is working correctly.)18:26
kristianpaulwpwrak: i know mmu less is weak, but for example you could rely on a scripting languge like why not lua, to write "safe" software inside it18:26
Fallenoubut I guess it has been said tons of times here :)18:26
kristianpaulas it includes its own memory allocation ANSI code18:26
kristianpaulFallenou: ;)18:27
kristianpaulFallenou: i also was thinking the alredy in upstream openrisc18:27
wpwrakkristianpaul: why not have a ROM BASIC like in "home" computers in the 1980es ? that was pretty safe ;-)18:27
kristianpaulmy palm and jornada have a rom :-)18:27
kristianpaulwpwrak: i just want to support the mmu-less idea :)18:28
wpwrakFallenou: it's not only the amount of work. other factors are that you may need to maintain a linux and an rtems branch of your code if you want it to run on both at the same time.18:28
Fallenouyes :/18:29
kristianpaulperhaps i'm still too lazy to learn linux internal so i need elaborate more excuses for not use mmu18:29
Action: kristianpaul like flat memory space, flat internet, flat...18:29
wpwrakFallenou: furthermore, when people ask whether it runs linux, what they really mean is "is it powerful enough ?". so a "no" means that they'll see it more in the arduino class18:29
kristianpaulwpwrak: and getting back to 703 (hope not OT here sorry lekernel :), just imagine this things are getting smaller and smaller18:30
wpwrakkristianpaul: fragmentation, bugs in application X crashing application Y, ... oh the joy :)18:30
kristianpaulso you'll end outsourcing some nasty? and no worth effort to free yet? wlan with in those devices that at least run owrt fine18:31
kristianpaulwpwrak: i even mentioned X, that is too  much a feature it self18:31
kristianpaulalso is hard to said what is an aplication running inside a lua intepreter but... i got your point for sure18:32
Fallenouwpwrak: oh indeed, but usually I think we say "yes it used to run Linux, during development, but then we ported RTEMS and we are now using it instead of Linux and Linux is no longer supported"18:32
Fallenouso they kind of know it is "powerful enough to run linux"18:32
wpwrakkristianpaul: (703n) it's not the size i'm worried about. it's the integration. if you went to your car dealer and they tried to sell you a car that has no rear seats but a little rickshaw attached (with wire) to the rear bumper. would you think that's a credible product ?18:33
Fallenoubut they may be disappointed by the fact that it is no longer supportee18:33
kristianpaulwpwrak: integration or comsmetic look?18:33
kristianpaulbecause i think you worry more for the last18:33
wpwrakFallenou: is it's powerful enough, why on earth aren't you running it then ? that's a very suspicious statement :)18:34
wpwrakkristianpaul: well, both18:34
Fallenouwpwrak: usually I say "lm32 Linux port is just totally crappy and buggy and we don't have the bandwidth to fix it"18:34
FallenouI reject the fault on theobroma18:34
wpwrakkristianpaul: people going rotfl after the first glance may not be the uplifting experience we aim for :)18:34
FallenouAdding the fact that RTEMS has less memory and cpu footprint18:35
Fallenouand it's realtime etc etc etc18:35
Fallenouyou can easily justify the use of RTEMS I think :)18:35
wpwrak(RT) yawn ;-) is if linux wasn't18:35
Fallenousure :p18:35
FallenouI am reading a nice book about linux real time18:35
Fallenouvery interesting18:36
Fallenou(in French :x)18:36
kristianpaul(RT) why bother when we can run RT stack on softcores as right now the usb one?18:36
FallenouChristophe Blaess writes nice books about Linux and embedded stuff18:36
kristianpauland implement a MMIO API or such to talk to this devices18:36
Fallenouthis is his new book (released 2 weeks ago)18:37
Fallenoubut too bad it's only in French18:37
wpwrakkristianpaul: it's usually easier if you can have everything in the same part of the system18:37
kristianpaulyou mean for RT or 703n?18:37
wpwrakkristianpaul: and "RT" can mean a lot of things. you don't always need extremely quick responses.18:38
kristianpaulah ya18:38
wpwrakhah, actually applies to both ;-)18:38
kristianpaulindeed ;)18:38
Fallenouthe big thing for RT is not to be quick18:38
Fallenouit's to be deterministic :p18:38
kristianpauland not get hang :)18:39
Fallenoubut indeed, if it's deterministicly slow, it's bad18:39
Fallenoubut at least when it's deterministic, you can what it can do, and what it cannot do18:40
Fallenou-you can+you know18:40
wpwrakif your timing requirements aren't too tight, you can accomplish quite a lot simply by giving the bit that's in a hurry real-time scheduling priority and be done with it. example: http://abiss.sourceforge.net/doc/abiss-ols2005.ps18:48
wpwrak(measurements on page 12)18:49
Fallenouwow, will read later18:49
Fallenouseems like a complex paper to read :)18:49
wpwrakjust look at the numbers :) that's disk i/o. still jitter in the range of only 5 ms.18:50
kristianpauland i just enable/patch this abiss and thats it ? !18:51
wpwrakyou have to tell the system how you expect it to perform, to adjust the buffering and such18:52
wpwrakalso, we didn't finish that project. interest went elsewhere, so eventually it just fell asleep18:52
Fallenouoh, your name is on the first page :)18:53
Fallenousurrounded by philips folks18:53
wpwraksee page 5 for the buffering18:53
Fallenouwhat I've read so far about RT was not talking about I/O18:53
wpwrakyeah, the was the project i was working on before openmoko18:54
Fallenouonly scheduling, timers, irq18:54
wpwrakdisk i/o is something rt folks don't like. because it's way too complex to specify exactly18:54
wpwraki guess that would make a nice assignment for an RT course at a university: "give the exact timing characterization of the disk in your pc"18:57
wpwrakof course, the correct answer would be: "bugger off !" ;-)18:57
Fallenoudoes it mean something like "fuck off" ?18:58
Fallenouit seems to :p18:58
wpwrakyes. it's about as vulgar, too. there are just less people who recognize it as vulgar ;)18:59
Fallenouhehe ok :p18:59
Fallenoudiner, bbl19:05
Action: Fallenou just unplugged from it's socket : an Intel 486 DX2, an Intel Celeron and an Intel Pentium III21:31
Fallenousouvenir :'21:31
--- Mon May 28 201200:00

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