lekernel changed the topic of #milkymist to: Milkymist One, Migen, Milkymist SoC & Flickernoise :: Logs: http://en.qi-hardware.com/mmlogs :: Something to do? Port NuttX to Milkymist SoC
<wolfspraul>
but those are hacking projects for me and someone else (if anyone) needs to get behind them if they believe this could be a product
<wolfspraul>
I don't :-)
<wolfspraul>
so the best we can do to protect our users is to first finish the r4
<wolfspraul>
if I can afford it, I will upgrade all units in stock
<wolfspraul>
that gives us some rc3 devel boards to play with
<wpwrak>
i wouldn't give up on m1 so quickly. i think it still has a lot of untapped potential.
<wolfspraul>
and we have a solid product ready to ship at any time
<wolfspraul>
absolutely
<wolfspraul>
that's what I mean
<wolfspraul>
we need those 10+ units in stock, because we have to believe that out of this base one day something with real demand will emerge
<wolfspraul>
keep in mind that I only think about the sales potential
<wolfspraul>
not some tech features
<wolfspraul>
will ddr3 sell more m1?
<wolfspraul>
never heard of that
<wolfspraul>
will "the reactable of video" sell more m1?
<wpwrak>
for the units in stock, a gateware upgrade that improves the pixel depth and brings the new memory controller would mean a significant improvement
<wolfspraul>
no way, never heard of that, it seems like just some random new attempt at making something cool, without having been asked for
<wolfspraul>
agree
<wpwrak>
we'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 board
<wolfspraul>
maybe we can extract it out of migen or migen/-ng generated sources and packport
<wolfspraul>
I'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.
<wolfspraul>
all agree
<wolfspraul>
the reason we need to go digital video is mostly because the analog video chips cost a lot of money
<wolfspraul>
and analog video is disappearing fast
<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.
<wolfspraul>
and, as in so many things m1, there are PLENTY of features missing even in the analog-in and analog-out side
<wolfspraul>
and nobody will work on those features
<wolfspraul>
ract = zero demand
<wolfspraul>
I wait until there is demand
<wolfspraul>
demonstrable demand
<wolfspraul>
bottom line: my focus is and remains m1, until I can come up with an idea for a 3rd product
<wolfspraul>
3rd as in Ben NanoNote -> Milkymist One -> ?
<wolfspraul>
that 3rd one better have more demand (sales) than #1 and #2
<wolfspraul>
that's my problem
<wolfspraul>
I think it will use parts or all of the milkymist soc, in whatever variety (-ng/migen/old/mangled together/whatever)
<wolfspraul>
I think it will include some rf, I am still very positive on kristianpaul's work
<wolfspraul>
it must be cheap, super simple mechanical
<wpwrak>
ract 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.
<wolfspraul>
new sales channel, new logistics
<wolfspraul>
you don't kill anyone by saying it's a "video reactable"
<wolfspraul>
plus - kill what?
<wolfspraul>
you think making those 20 10,000 EUR tables is a business?
<wpwrak>
no clue ;-)
<wolfspraul>
kristianpaul mentioned some 9 USD app - there could be some money there
<wolfspraul>
nah, this is in no way at all thouht through economically, but that's ok
<wolfspraul>
I'm not going to stop interesting projects
<wolfspraul>
my 3rd product I think will also have dramatically less software
<wolfspraul>
what I learnt in both the ben and m1 is that we have overwhelmed ourselves in delivering really high quality to users
<wolfspraul>
we don't have a test plan for either ben or m1, which is a joke
<wolfspraul>
it shows how we function :-)
<wolfspraul>
so 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)
<wpwrak>
we compensate with superior design that's immune to failure ;-))
<wolfspraul>
and the things that are lurking in the background, such as atrf, gps, ledtoy, etc.
<wolfspraul>
but for sure I don't repeat a mistake that was learned in rounds 1 and 2 :-)
<wolfspraul>
I was very happy about the huge success of the pebble watch, for a number of reasons
<wolfspraul>
they are not open hw
<wolfspraul>
they are just a bluetooth extension of an iphone/android phone
<wpwrak>
yeah, the pebble is cool
<wolfspraul>
but they did a lot of things right that I learned in the last years in hardware
<wolfspraul>
so we see
<wolfspraul>
m1 is cool, and I will continue
<wolfspraul>
I 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 value
<wolfspraul>
plus we can discount, finally :-)
<wpwrak>
;-)
<wolfspraul>
3rd product, it will come out of the ashes of the burnt #1 and #2
<wolfspraul>
and werner too, and many others. and sebastien of course as well - the more works on m1 the better for me...
<wpwrak>
increasing the price of m1rc3 units seems a bit odd, though. but well, maybe it has some unexpected way of working ;-)
<wolfspraul>
and if some great new -7/ddr3/spi design comes out, neat. maybe something can be made out of that.
<wolfspraul>
keep in mind that sales are 0
<wolfspraul>
we have to increase the price
<wolfspraul>
the price was too aggressive as well
<wolfspraul>
but m1 was wrong on a number of angles
<wolfspraul>
which was good to learn
<wpwrak>
that'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 months
<wolfspraul>
I will never again sell a product that doesn't have a test plan with 100% coverage which I can walk throuhg myself first.
<wolfspraul>
just to pick one thing
<wolfspraul>
I don't think so, why?
<wolfspraul>
we try to make it attractive
<wolfspraul>
you mean usb-midi controllers?
<wolfspraul>
openclipart integration?
<wolfspraul>
those things we try to work on, but you know we are just a few guys
<wpwrak>
we didn't anything that would make it look interesting to prospective buyers. no new features. no new demos. hardly any new use cases.
<wpwrak>
and then you get the osborne effect with m1r4 :)
<wolfspraul>
I think xiangfu will soon finish the workaround of using a 703n dongle/router to provide wifi
<wpwrak>
so i'm not surprised m1rc3 doesn't sell at the moment
<wolfspraul>
you can setup essid and password on the m1, it goes to the dongle over json, done
<wolfspraul>
that adds wifi, a much asked-for feature
<wolfspraul>
after that, usb-midi and openclipart
<wolfspraul>
osborne effect?
<wolfspraul>
ha ha
<wolfspraul>
no, this needs a new name
<wolfspraul>
most of the people who bought m1 are in one of the following states, or mix:
<wolfspraul>
1) why the hell did I let these guys talk me into this?
<wolfspraul>
2) milky what?
<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 alone
<wolfspraul>
3) when my happiness and optimism gets too strong, and I cannot sit still anymore, I go back to my m1 for a little balance
<wpwrak>
;-))
<wolfspraul>
what else?
<wolfspraul>
there is on 'osborne' effect
<wolfspraul>
*nobody*, but really nobody, is waiting for the next great milkymist product
<wolfspraul>
they are all happy they survived the first one, mentally :-)
<wpwrak>
there 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 corner
<wolfspraul>
no no
<wolfspraul>
there are not
<wolfspraul>
I work in sales actually
<wpwrak>
and we've been giving the impression that m1r4 is coming. so ...
<wolfspraul>
the 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/her
<wolfspraul>
no
<wolfspraul>
nobody is following, nobody is waiting
<wpwrak>
hehe ;-)
<wpwrak>
i don't know. they can just lurk.
<wolfspraul>
no
<wolfspraul>
sure not
<wpwrak>
we can't know :)
<wolfspraul>
but the reaction is correct, it matches with what I learnt about the product
<wolfspraul>
which is that pretty much nothing anyone imagines/expects works
<wolfspraul>
any remaining interest must come out of very zen-like needs, rare
<wolfspraul>
so anyway
<wolfspraul>
the best idea I have is - finish r4
<wolfspraul>
r4 has a number of hugely important things, including kicad & boom
<wpwrak>
well, 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.
<wolfspraul>
that will be completely outside of sebastiens' view anyway, he won't care I think
<wolfspraul>
so there is no overlap with future milky development effortrs on his side
<wolfspraul>
hopefully it can combine later
<wolfspraul>
I am focused
<wolfspraul>
just slow
<wolfspraul>
as I said I will continue with m1 as a product
<wolfspraul>
I do believe in it
<wolfspraul>
r4 now first, including kicad & boom
<wolfspraul>
I actually want to move the layout into kicad as well, we see. we already work on the footprints.
<wpwrak>
you're contradicting yourself :)
<wolfspraul>
no, maybe not clear enough, sorry
<wolfspraul>
where is the contradiction?
<wpwrak>
if you already exclude making m1r4, then the product is pretty much finished
<wolfspraul>
there is no demand
<wolfspraul>
with 0 demand, you only need to make 0 units
<wolfspraul>
:-)
<wolfspraul>
but then you still 'made' enough
<wolfspraul>
right?
<wpwrak>
you can sell these remaining units but then it'll be only a support cost item without any possible revenue
<wolfspraul>
sell to whom?
<wolfspraul>
I think we can upgrade the in-stock rc3 to rc4
<wolfspraul>
R4
<wolfspraul>
then we have our best possible product in stock
<wolfspraul>
and can polish the experience
<wolfspraul>
make it 'more attractive' as you say
<wolfspraul>
and hopefully find a real uptick/demand somewhere!
<wolfspraul>
of course. that's why I need it in stock and working.
<wpwrak>
well, 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 number
<wolfspraul>
absolutely
<wolfspraul>
that's what we do
<wolfspraul>
and we can do more
<wpwrak>
then focus on marketing and finding financing
<wolfspraul>
we can upgrade our inventory
<wpwrak>
what would "upgrading' mean ?
<wolfspraul>
make not 8 r4 boards, but maybe 25
<wolfspraul>
make new side panels for the sides that changed
<wolfspraul>
upgrade the rc3 boards in all units in stock to rc4
<wpwrak>
you mean unsolder all the chips, put them on the new pcb, add the new items, ... ?
<wolfspraul>
just 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.
<wolfspraul>
god no
<wolfspraul>
just the whole pcba
<wpwrak>
;-))
<wpwrak>
you can't upgrade rc3 to r4
<wolfspraul>
why not
<wpwrak>
maybe you could make an rc3+. but it would be quite different from the r4
<wpwrak>
how do you add dvi ?
<wpwrak>
all the new usb ports ?
<wolfspraul>
add?
<wolfspraul>
I don't get it
<wpwrak>
the second extension header ?
<wpwrak>
the leds ?
<wolfspraul>
I have 15 or so rc3 units in stock
<wolfspraul>
no no
<wolfspraul>
'upgrade' looking at the full box!
<wolfspraul>
I open the box
<wolfspraul>
open the case
<wpwrak>
r4 hw has a larger feature set than rc3 hardware
<wolfspraul>
take the old board out
<wpwrak>
aaah !
<wolfspraul>
put the new board in
<wolfspraul>
swap the side panels
<wpwrak>
okay :)
<wolfspraul>
wait, breakfast. bbiab.
<wpwrak>
i thought you mean to rework the rc3 to make them more r4-like :)
<wpwrak>
but there is very little extra value if you already remove the pcba, half the case, the keyboard, etc.
<wpwrak>
about the only things you'd keep would be the camera and some cables
<wpwrak>
so 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 sense
<wolfspraul>
grabbed it here
<wpwrak>
;-)
<wolfspraul>
no 'competing'
<wolfspraul>
because no sales
<wolfspraul>
of course the upgrade is a purely 'hope for the future' thing
<wolfspraul>
just spend another few thousand usd without any demand
<wpwrak>
no sunday family breakfast :)
<wolfspraul>
but that is no difference to tens of thousands already spent, and spending
<wolfspraul>
but we have to believe in our own stuff first
<wpwrak>
well, you could sell m1rc3 bare boards at a discount. maybe that'll get a few hackers aboard.
<wolfspraul>
if we fiddle around with r4, but keep selling rc3 (rather not selling, but 'offering'), then that shows m1 is really at a dead end
<wpwrak>
why ?
<wolfspraul>
cannot sell I think
<wolfspraul>
but sure we have them and will carefully use for the core team :-)
<wolfspraul>
actually I think the small milkymist team is quite a good start
<wolfspraul>
because no demand
<wolfspraul>
the way to sell an m1 is to talk someone into it
<wolfspraul>
that's how 90% got sold
<wolfspraul>
of course - *nobody* then went on to recommend to a friend
<wolfspraul>
other than a story like "listen to what crazy stuff I just did"
<wolfspraul>
but that is all fine, I just think positive and how we move forward 1) m1 product 2) future product
<wolfspraul>
I also agree with you now that we should tackle the problem of fpga pin reconfiguration
<wolfspraul>
that's kinda like sand in the engine for any future thing we plan to do
<wpwrak>
well, 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.
<wolfspraul>
we 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 still
<wolfspraul>
yes, I 100% agree
<wolfspraul>
werner, unless I specifically say so, I always agree with you :-)
<wolfspraul>
we need higher memory bandwidth
<wpwrak>
then, 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.
<wolfspraul>
the video specs are a total joke
<wolfspraul>
like a computer from a museum, maybe a museum sale?
<wolfspraul>
our problem is as we know that the goal of making a totally independent platform is also totally crazy and totally difficult
<wpwrak>
the 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 expect
<wolfspraul>
so it's not anyones fault actually, other than for thinking this might work :-)
<wolfspraul>
yes
<wolfspraul>
so maybe we can backport something sebastien has been hacking on?
<wolfspraul>
don't know
<wolfspraul>
wpwrak: did you read what I said about changing fpga pins? I am with you on that one too now :-)
<wolfspraul>
thought about it for a while
<wpwrak>
as 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.
<wolfspraul>
we 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 2
<wolfspraul>
the first step is the hardest
<wpwrak>
i knew you'd eventually come around ;-)
<wolfspraul>
going from 2 to 3 and 4 etc. will be easier then
<wolfspraul>
I don't see anyone who would start working on either taking the verilog out and over into m1, or fully supporting m1 in migen
<wolfspraul>
and 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.
<wpwrak>
this 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.
<wpwrak>
we can focus on other things. like linux and usb.
<wolfspraul>
if he gets to it, nice. but I think what he wrote a few hours ago was pretty clear.
<wolfspraul>
yes
<wolfspraul>
ok, I think my plans, as of my current best thinking, are clear now :-)
<wolfspraul>
I keep learning as I go, and I think the direction is great, but that's my current brain dump
<wolfspraul>
first kicad and boom now
<wolfspraul>
and footprints, and maybe layout
<wolfspraul>
then make those boards
<wolfspraul>
test
<wpwrak>
i consider what he wrote a proposal. now we're discussing it :)
<wolfspraul>
upgrade rc3 units in stock
<wolfspraul>
if I can afford that, it would be great. I think I can if we hurry up a bit.
<wolfspraul>
that would give me an excellent base to keep looking for users and potential business partners (read: sales channels)
<wolfspraul>
or as werner would say 'investors' (but I still prefer 'sales partners' :-))
<wpwrak>
i would disentangle people who give the project money from people who have sales channels. divide and conquer applies here, too ;-)
<wolfspraul>
I think we work on exactly the right thing
<wolfspraul>
things
<wolfspraul>
so that should make the thing more attractive
<wolfspraul>
all fine
<wolfspraul>
the more sebastien can contribute the better, of course I hope he delivers many great things for m1
<wolfspraul>
but 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 board
<wpwrak>
i 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.
<wolfspraul>
at least on the core levels of faster memory, higher bpp, higher resolution, etc.
<wolfspraul>
m1r4 happens as a product!
<wpwrak>
if 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.
<wolfspraul>
it's great that we have rc3 units in stock we can upgrade
<wolfspraul>
but of course I will not make another batch of 100 r4 or so, why?
<wolfspraul>
for whom?
<wolfspraul>
no demand
<wpwrak>
okay. well, we probably shouldn't call this "upgrade". it's like getting a new pc but keeping the old mouse ;-)
<wolfspraul>
I look at it from the box
<wolfspraul>
there is tremendous effort in the accessories, case, box, etc.
<wolfspraul>
whoever wants to make another product in the future will find out too :-)
<wolfspraul>
or just don't do it, and go for an iPad app
<wolfspraul>
do we have a plan?
<wolfspraul>
I do :-)
<wolfspraul>
I hope I don't demotivate anyone here
<wolfspraul>
it should be quite the contrary
<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.
<wolfspraul>
I 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.
<wolfspraul>
'upgrade' is just for our internal communication
<wolfspraul>
it's the best and only way I can think of using (and demanding use) from r4 right now
<wolfspraul>
even that will waste me thousands of usd
<wolfspraul>
but I think we should do it as a vote of confidence in the future of m1 and future milkymist-based products
<wpwrak>
i 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 ? ;)
<wolfspraul>
ha, sure
<wolfspraul>
I am speaking my mind, and also work through and grow on these efforts
<wolfspraul>
every disappointment is the source of energy to make things better
<wolfspraul>
in that sense m1 gave me energy for the next 10 years
<wolfspraul>
:-)
<wpwrak>
(linux) yeah, if all else fails, i may have to do it myself :)
<wolfspraul>
'clear from the beginning' is a little unfair to all of us, I think
<wolfspraul>
for myself I can just say - I learnt like crazy through this, and would know no other way to learn those things
<wolfspraul>
also I do think milkymist has a future, and I want to keep the tech together
<wolfspraul>
that's my worry a little about what is 'legacy' or 'backported'
<wolfspraul>
a franker term might be just to call it a fork
<wolfspraul>
then everyone knows what it is :-)
<wolfspraul>
but that would not be good
<wolfspraul>
so let's see
<wpwrak>
i 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 :)
<wolfspraul>
I rather thing how I can get myself into a position where I can help myself
<wolfspraul>
that bridges the waiting time constructively :-)
<wpwrak>
hmm, if you're looking for things to do ... :)
<wolfspraul>
I have the m1 schematics here and keep reading them, nice...
<wolfspraul>
just so I get a better feeling of how things are wired up
<wpwrak>
yeah, i like them. adam did very good work there.
<wolfspraul>
yes
<wolfspraul>
wpwrak: what do you have in mind?
<wpwrak>
write patches. patches that use midi. make demo videos.
<wpwrak>
it'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.
<wolfspraul>
ok
<wpwrak>
and of course, it would be so much nicer if things didn't just all fade to green ;-)
<wpwrak>
to get an idea of just how many controls one can cram into a patch :)
voidcoder has quit [Read error: Connection reset by peer]
voidcoder has joined #milkymist
<wpwrak>
this 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.
<wpwrak>
my 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 :)
<wpwrak>
(at least as far as the command chair is concerned)
elldekaa has joined #milkymist
azonenberg has joined #milkymist
Jia has joined #milkymist
rejon has quit [Ping timeout: 265 seconds]
wolfspraul has quit [Read error: Connection reset by peer]
wolfspraul has joined #milkymist
jimmythehorn has quit [Ping timeout: 245 seconds]
jimmythehorn has joined #milkymist
Jia has quit [Quit: Konversation terminated!]
fpgaminer has quit [Remote host closed the connection]
fpgaminer has joined #milkymist
voidcoder has quit [Read error: Connection reset by peer]
jimmythehorn has quit [Read error: Connection reset by peer]
elldekaa has joined #milkymist
elldekaa has quit [Read error: Operation timed out]
elldekaa has joined #milkymist
<lekernel>
wpwrak: the new memory controller works _today_ on the M1
<lekernel>
better go the other way and port the other cores into milkymist-ng for M1
<lekernel>
wolfspraul: 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...
<lekernel>
so it's perfectly sound as a development/experimental hardware platform. then there are gateware/software bugs.
<lekernel>
the problem here is simply that there are not enough people to fix them. but just have a look at opengraphics, opencores, etc. ...
<lekernel>
you could say it was totally expected, even :)
elldekaa has quit [Ping timeout: 245 seconds]
<lekernel>
also, 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 :)
<lekernel>
poor video quality => ddr3 + 32bpp + multiple HD ports
<lekernel>
code is scary => effect is defined using the reactable-style interface
<lekernel>
too many time-wasting features like USB => strip it down to the bare minimum so it does one thing well
<lekernel>
switching between performance and render mode is lousy (confusing + non-instantaneous feedback) => also solved by the new if
<lekernel>
m1 is difficult to explain => "look, I put this object here and it does that"
<lekernel>
of course that doesn't mean it will be successful
<lekernel>
but I think it has much more of a chance than the M1
<lekernel>
and anyway it would be more interesting to watch this one fail than continue with the stream of recurring M1 problems...
rejon has joined #milkymist
<wpwrak>
(memory controller) which subsystems are using it so far ? cpu, video out (refresh), what else ? pfpu, video in, ... ?
<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.
<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.
wolfspraul has quit [*.net *.split]
azonenberg has quit [*.net *.split]
lekernel has quit [*.net *.split]
rejon has quit [Ping timeout: 245 seconds]
lekernel has joined #milkymist
<lekernel>
wpwrak: direct DMA to DRAM (= cores harder to move to/from -ng) is for framebuffer, video-in and TMU
<lekernel>
pfpu uses wishbone (you don't need that much bandwidth for vertices...)
<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 reactable
wolfspraul has joined #milkymist
<lekernel>
then 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.
<wolfspraul>
all the great things I learnt with Milkymist came from putting it in front of people and listening to their feedback
<wolfspraul>
and even though I realized that >95% of the promise of m1 (or what people thought of it) were disappointed, the remaining 5% still prove valuable
<wolfspraul>
there's no way I will walk away from what is most valuable, the user feedback we got on m1
<wolfspraul>
aka 'bugs'
<lekernel>
wolfspraul: the new interface would also have the advantage of making it much clearer what the device does and does not
<wpwrak>
lekernel: (memory) so which memory bus users do work now ? not fb -> video, not video-on, not tmu ? so it's only the cpu ?
<wolfspraul>
finish 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 (?) llhdl
<wolfspraul>
that's just my thinking, but please everybody do as they like
<wolfspraul>
we are a free wheeling group :-)
<wolfspraul>
I love to continue on m1 and will do so
<lekernel>
wpwrak: right now yes, but i'll probably have the framebuffer shortly
<lekernel>
wolfspraul: and what do mmu and linux bring, feature-wise?
<lekernel>
the m1 will still be an obscure box with a slow CPU
<wolfspraul>
they are also risky but may make the platform more attractive and more maintainable, and bring new people in
<wolfspraul>
definitely better than fixing rtems bugs, or nuttx porting now
<wolfspraul>
but we can try it all, and see what works
<wolfspraul>
true
<wolfspraul>
but that's a realization that only came from putting it in front of users and not running away :-)
<wolfspraul>
I need more of that, not less
<wolfspraul>
and eventually a really good product idea will emerge
rejon has joined #milkymist
<lekernel>
I think the mirteo is a pretty good idea.
<wpwrak>
lekernel: (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 ?
<wolfspraul>
hopefully others agree (if you care)
<wolfspraul>
I stay on m1, 100%
<wolfspraul>
the best things in m1, and thus milkymist, are yet to come
<lekernel>
wpwrak: yes / not totally yet, but that's down the road
<wpwrak>
mmu + linux = drivers and freedom from rtems breakage :)
<wolfspraul>
is llhdl abandoned?
<wolfspraul>
the mmu/linux move is also risky
<wolfspraul>
but there are risks everywhere
<lekernel>
the mirteo won't need drivers or rtems, so I'm already ahead there
<wpwrak>
life is risky :)
<wolfspraul>
and for sure it broadens the appeal of the platform
<wpwrak>
getting down from those trees was damn risky :)
<wpwrak>
let alone leaving the safety of the water ;-)
<wolfspraul>
mmu/linux are not 'guaranteed to suceed' moves in the context of milkymist
<lekernel>
wolfspraul: (llhdl) commented on that last week or so. executive summary: yes.
<wolfspraul>
ah ok
<wolfspraul>
then someone could continue
<wolfspraul>
lemme read the backlog, sorry I didn't search first...
<wolfspraul>
so we have 3 people that are more interested in llhdl than migen
<wolfspraul>
people who are continuously involved with m1 - werner, kpaul, me
<wolfspraul>
interesting :-)
<wolfspraul>
I don't believe llhdl will bring immediate benefits to the m1 user, it's a little like the mmu/linux idea
<lekernel>
totally
<wolfspraul>
but 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 migen
<wpwrak>
llhdl would be more something that brings humanity forward. like having an open source unix kernel.
<wpwrak>
for m1, it should be irrelevant
<lekernel>
it's not, you can instantiate the verilog cores from migen
<wolfspraul>
I think if someone would solidly hack away on it, it can't be such an impossible task
<wolfspraul>
all a matter of focus
<wolfspraul>
sure, we can try that - for example take the mem cntrl from there and backport to m1?
<lekernel>
by the way, your estimate of interested people is wrong - there are the rhinoplatform.org people (and some more) who are using migen
<wolfspraul>
might be ugly though :-)
<lekernel>
so, 5th time or so
<wolfspraul>
new url - great
<wolfspraul>
reading
<wolfspraul>
are they m1 users?
<lekernel>
the migen/-ng memory controller works on the M1 today
<wolfspraul>
unusable for m1 users
<wolfspraul>
because it would break 80% of the few things that do work with the other parts of their machine
<lekernel>
and for the other cores, just instantiate the legacy verilog from migen if you want an easy way
<lekernel>
only two are troublesome: video-in and TMU
<wolfspraul>
9 months ago rhino was 'ready to manufacture'
<wolfspraul>
is the project active?
<lekernel>
yes, website isn't updated
<wpwrak>
lekernel: 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.
<wolfspraul>
nice I never heard about it before - thanks a lot for the link!
azonenberg has joined #milkymist
<lekernel>
wpwrak: nevertheless I'm prototyping it on the M1 and will fix the bugs
<wpwrak>
lekernel: sure. just trying to clarify the finer points of "it works" :-)
xiangfu has joined #milkymist
<lekernel>
I'm also planning to support the DVI output in -ng
<lekernel>
on m1r4
<wolfspraul>
great
<wpwrak>
very 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.
<lekernel>
he, that's what I've been saying all along
<Fallenou>
fyi, 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 :)
<wolfspraul>
Fallenou: oh my god please continue
<wolfspraul>
:-)
<wolfspraul>
we need to invest in the right things, and the mmu is definitely one of them
<Fallenou>
I 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 ^^
<wolfspraul>
doesn't matter, don't worry
<Fallenou>
but I'm doing it anyway, just for the sake of learning :)
<wpwrak>
i 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.
<lekernel>
probably not, but it has nerd-fu
<wolfspraul>
an mmu which can be easily enabled or not would add great value to the platform
<wolfspraul>
no way
<wolfspraul>
migen is nerd-fu
<wolfspraul>
big time
<wolfspraul>
mmu is an important feature in a larger machine
<wolfspraul>
where milkymist in the future is hopefully used in very integrated/small machines, and also larger machines running the full blown mmu/linux
<Fallenou>
I'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)
<wolfspraul>
won't be abandoned
<wolfspraul>
all the valuable things we learned was trying to make a product ouf of it and trying to put it in front of regular people
<Fallenou>
I know, I've read the backlog, but focusing on a new product is a way of abandoning the old one :)
<wolfspraul>
only to get their big stares back :-)
<wolfspraul>
WHAT IS THAT?
<wolfspraul>
are you crazy?
<wolfspraul>
why does A B C D E F G and so on not work?
<wolfspraul>
is this from a museum?
<wolfspraul>
and so on
<Fallenou>
since resources are very limited
<wolfspraul>
that was the great part
<wpwrak>
let 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 lo
<wpwrak>
t, too.
<wolfspraul>
shoulder what?
<wolfspraul>
I hope we focus on m1
<wolfspraul>
I am
<wolfspraul>
the only thing that makes me kick is user feedback
<wolfspraul>
and that was fantastic the last 2 years
<wolfspraul>
even though it was mostly a huge list of things that don't work :-)
<Fallenou>
it's understandable, limited resources, so the developments is "slow" (even if I find it really fast regarding to the very few people contributing)
<wolfspraul>
I think milkymist, and m1, are the most advanced free and new computing architecture in the world
<wolfspraul>
at least I am searching for better ones but cannot find
<wolfspraul>
slow doesn't matter if we do the right things
<Fallenou>
so slow developments means bugs not yet fixed, and features "not yet implemented completely"
<wolfspraul>
which I believe includes kicad, boom
<wolfspraul>
mmu, linux
<wolfspraul>
llhdl
<wpwrak>
wolfspraul: shoulder the development of a future device that combines reactable with milkymist
<wolfspraul>
oh, I am totally not interested first of all
<lekernel>
I will.
<wolfspraul>
great, and maybe some breadcrumbs fall off for old and rusty m1 :-)
<wolfspraul>
-7 series, ddr3 and spi definitely would be interesting things for m1
<lekernel>
sure (to both)
* Fallenou
must says he is excited about "m2" featuring milkymist-ng+new fpga+ddr3+digital video
<wolfspraul>
Fallenou: 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, guaranteed
<Fallenou>
Will do !
<wolfspraul>
maybe the paris subway can slow down a little
<wolfspraul>
it will speed up mmu development
<wolfspraul>
we should make a few calls in the right places!
<wpwrak>
Fallenou: 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 system
<wolfspraul>
and it needs to be easily enabled and disabled
<Fallenou>
sure, but we will need someone motivated in fixing theobroma linux bugs (if I understand correctly)
<wolfspraul>
because 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 standards
<Fallenou>
anyway, first things first
<wolfspraul>
but we need both, and we need them to compete
<wolfspraul>
the full-blown linux system on one hand, expensive and slow as it may be, but with some advantages
<Fallenou>
14:44 < wolfspraul> maybe the paris subway can slow down a little < hehe, paris subway is definitely slowing down mmu progress :p
<wpwrak>
Fallenou: 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.
<wolfspraul>
and the super-integrated high-performance bare-bones system on the other hand
<wolfspraul>
may the two compete happily ever after :-)
<wpwrak>
Fallenou: besides, planning to have no mmu would also affect some design choices when making the basic system
<Fallenou>
wolfspraul: OK I see (full blown linux / super integrated)
<wolfspraul>
back 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"
<wolfspraul>
Fallenou: yes, we need both, and we need them to compete
<wolfspraul>
because with all chatting here, we cannot find out and predict which one will work better in which use case and marketing case
<Fallenou>
well yes, memory protection for user space is really a needed feature for a stable system
<wolfspraul>
so if sebastien is storming ahead on some fancy new features, so be it
<wolfspraul>
it's good
<wolfspraul>
something will come out of it
<Fallenou>
sure
<wolfspraul>
I am sure that chips will become tremendously more powerful still the next 10 years, let's say
<wolfspraul>
that leans towards the value of a large system like Linux
<wolfspraul>
on the other hand there is nothing better than cutting out all the old crap with one big swing of the sword
<Fallenou>
I've never seen any sebastien's development that have been proved worthless :) it always ends up with a powerful nerdy technology :)
<wolfspraul>
:-)
<Fallenou>
let's everybody work on what he thinks is necessary/cool/important, we'll see what comes out of all this :)
<wolfspraul>
llhdl is unfortunately abandoned right now, but that begs to be adopted somewhere
<wolfspraul>
yes!
<wolfspraul>
:-)
<Fallenou>
I've got to run to get something to eat (almost 3 pm here) in order not to starve
<Fallenou>
see you !
<wpwrak>
good hunting ! :)
<wolfspraul>
enjoy
<Fallenou>
=) thanks
elldekaa has joined #milkymist
<wpwrak>
lekernel: 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.
<wpwrak>
2) 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.
<wpwrak>
3) make these things act like midi inputs to patches. that way, we can easily upgrade existing patches.
<wpwrak>
4) design your visual "patch-less" system and try it with that hardware. once you're happy with it, move on to
<wpwrak>
5) build your own hardware.
<wpwrak>
such 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.
<wpwrak>
even 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.
<wpwrak>
also, 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.
xiangfu has quit [Remote host closed the connection]
<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.
<wolfspraul>
video over rf is great
<wolfspraul>
I like it :-)
<wolfspraul>
anything rf makes me happy right now
<wpwrak>
:)
<wpwrak>
wlan is rapidly becoming the next usb, in terms of "market admission requirement". if it hasn't already done so.
<wolfspraul>
the llhdl backlogs tell me that llhdl will happen when milkymist beats the raspberry pi in google trends
<wolfspraul>
oh my :-)
<wolfspraul>
but ok, it's a clear thing at least
<wolfspraul>
is milkymist even measurable?
<wolfspraul>
checking
<wolfspraul>
no "not enough search volume for ranking"
<wolfspraul>
will check again in a year or so :-)
<wpwrak>
"not for the unwashed masses" :)
elldekaa has quit [Read error: Connection reset by peer]
<wpwrak>
if popularity was the goal, then we should all happily dance around facebook and post pictures of cats playing with poodles
<wolfspraul>
which other free and new computing architecture similar to milkymist is more popular?
<wolfspraul>
or what is milkymist, in fact?
<wolfspraul>
what do we measure popularity against?
<wolfspraul>
if I find a better free platform, I switch :-)
<wolfspraul>
until then, I think milkymist is actually the best one (of that kind), and also most popular
<wpwrak>
now, which is the flagship project of openrisc ?
<wolfspraul>
I can easily recommend m1 to anyone wanting to go below kernel, into digital design, computing architecture, etc.
<wolfspraul>
simply because I don't know a better starting point. if I find one, I will reconsider.
<wolfspraul>
of course
<wolfspraul>
if it's free, we would all benefit from mixing and matching
<wolfspraul>
so I am constantly on the lookout
<wolfspraul>
but for the time being I think we can consider milkymist very popular for what it tries to do and what it's uniqueness is
<wpwrak>
yeah. m1 is a complete system that's fully free (except for the toolchain). that's pretty unique.
<wolfspraul>
and relatively well supported entry points, everywhere
<wolfspraul>
and those entry points are improving
<wolfspraul>
that's why I think llhdl would be great, for example. another entry point.
<wolfspraul>
I do not think a large part of the world is waiting for a 'free soc' though
<wolfspraul>
so the 'popularity' if such an endeavor will always be a tiny fraction of even rusty Paris Hilton introducing yet another fragrance
<wolfspraul>
so what
<wolfspraul>
but if we can make a kickass product out of it one day, then we know the investment was worth it
<wpwrak>
sometimes, people don't realize what they want until it's being shown to them
<wolfspraul>
not that even then many people will care what's inside - almost nobody will
<lekernel>
let's have Paris Hilton introduce our products then ;)
<wpwrak>
or 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 ;-)
<GitHub76>
[milkymist-ng] sbourdeauducq pushed 1 new commit to master: http://git.io/BMWFDQ
<GitHub76>
[milkymist-ng/master] software/libbase: fix memcpy handling of buffers with differing alignments - Sebastien Bourdeauducq
<GitHub118>
[milkymist/master] software/libbase: memcpy: same with 2 alignment - Sebastien Bourdeauducq
<stekern>
wpwrak: the flagship project for openrisc is... openrisc ;)
<stekern>
milkymist SoC is a far more defined SoC than any of the reference SoC projects, orpsoc and minsoc
<stekern>
they are more thought of as "easy" startup-points for people that wants to try out openrisc
elldekaa has joined #milkymist
rejon has joined #milkymist
kyak has quit [Read error: Operation timed out]
rejon has quit [Ping timeout: 246 seconds]
voidcoder has quit [Read error: Connection reset by peer]
kyak has joined #milkymist
voidcoder has joined #milkymist
Zorro has joined #milkymist
Zorro is now known as Guest53508
Gurty` has quit [Ping timeout: 265 seconds]
<Fallenou>
Does it annoy someone if I add a github hook to get "commit push" messages for Milkymist MMU related repository here on IRC? like GitHub90/118
<wpwrak>
bigger than the wacom / hanvon devices, wider viewing angle, rugged, and in the same price range
<wpwrak>
and they even provide linux code ;)
<wpwrak>
stekern: (flagship) ah, so wikipedia is right on this :) and yes, compared to the others, the milkymist soc is a rather nicely rounded package already
<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 cost
<stekern>
wpwrak: to be fair, the wikipedia says "OpenRISC is the original flagship project of he OpenCores community", nowdays it's scope is beyond opencores though
elldekaa has quit [Ping timeout: 260 seconds]
rejon has joined #milkymist
elldekaa has joined #milkymist
<Fallenou>
6 min 50 seconds to generate a minimalist Milkymist SoC bitstream in a Debian virtual machine on a Macbook pro
<Fallenou>
with all optional cores disabled
<Fallenou>
and a nice priority of -19 for the make process
<Fallenou>
pretty fast :)
rejon has quit [Ping timeout: 240 seconds]
<kristianpaul>
survived the first one, mentally ;-)
<wpwrak>
Fallenou: btw, is the mmu currently for the verilog-based system, the migen-based one, or both ?
<Fallenou>
both
<wpwrak>
excellent
<Fallenou>
I am simulating the MMU project using a migen generated SoC, and using ISim for the simulation
<Fallenou>
but when I test on real hardware I am using the "normal" SoC (non migen based)
<wpwrak>
because the latter still lacks features ?
<Fallenou>
I have not tried booting milkymist-ng yet :)
<Fallenou>
I guess it could be a good test to try milkymist-ng+mmu on the M1
<Fallenou>
I think it's pretty recent that milkymist-ng boots on the M1
<wpwrak>
ah, i see
<Fallenou>
anyway the MMU is hidden deep inside lm32_dcache.v (for now only DTLB is implemented) and a little bit in lm32_cpu.v
<Fallenou>
all of this is independant of using migen or not
<wpwrak>
lekernel: 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 ?
<Fallenou>
migen "just" generates the interconnect arbiter and the SoC cores, but it generates nothing inside lm32 cpu
<Fallenou>
mmu is only inside lm32 cpu
<wpwrak>
Fallenou: interconnect arbiter = the interface between cpu core and the memory bus ?
<Fallenou>
wishbone arbiter, interface between cores
<wpwrak>
isn't the memory bus in parallel to wishbone ?
<Fallenou>
AFAIK on milkymist-ng, FML has been replaced by ASMI
<Fallenou>
so yes there is some kind of a "memory bus" called ASMI
<Fallenou>
connected to wishbone bus
<Fallenou>
using the wishbone2asmi core
<Fallenou>
(the gateway between the 2 buses)
<Fallenou>
and the memory controller is on the ASMI bus
<wpwrak>
ah, i see. i thought it was completely parallel
<Fallenou>
but 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 it
<Fallenou>
and all the wishbone mess of wires and arbiter is generated dynamically by migen
<Fallenou>
taking care of addresses, number of slaves, number of masters and so on
<Fallenou>
I hope I didn't unnecessaryly made your representation of the SoC less clear than it was before :p
<kristianpaul>
still room for improvement, yes like wpwrak'w work around improveing patching language
<kristianpaul>
also if the fpga is not fully used, why not add second cpu? well too fancy perhaps
<wpwrak>
Fallenou: no, that helps a lot for arranging the pieces in my head :) thanks !
<kristianpaul>
even tought hardware is no full feature in specs, try avoid the same software missing features and bug fixes history wont happen again
<kristianpaul>
wpwrak: VERY good idea, use a cheap tablet first :-)
<kristianpaul>
or two chep tablets, that will be fun
<kristianpaul>
stekern: when getting to folks light that milkymist based soc? :-)
<kristianpaul>
perhaps other path forth a linux friendly system.. or a lm32 openrisc combo in same soc
<kristianpaul>
wpwrak: 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 stick
<kristianpaul>
counting for that in same package thats one less problem to solve for now
<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 well
<kristianpaul>
lekernel: 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 imagery
<wpwrak>
and 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 nicely
<kristianpaul>
something will not look like m1 gets abandong but a coming nice box that upgrades video out
<kristianpaul>
wpwrak: i will buy a tablet when they be at least 16", that will be awesome to try touch based kbd on it
<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" ?
<kristianpaul>
i may look like as we want it to :),d you have a 703n btw
<kristianpaul>
?
<wpwrak>
i don't have one
<kristianpaul>
board 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 box
<kristianpaul>
wpwrak: dont know, ask xiangu i guess
<kristianpaul>
i dont know if its work include making fit in same box.. dont know but even no
<kristianpaul>
already ahving that usb host port, why not use it
<kristianpaul>
another round to try rtems nfs support too ;-)
<wpwrak>
i 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 control
<kristianpaul>
me either
<kristianpaul>
but and off the shell product that add some value? but problem solving to our current neeeds is not that bad worth too look at
<wpwrak>
e.g., what if they decide to make the next version 5 mm shorter ? then any adapters you cook up will have to be redone
<stekern>
kristianpaul: as soon as Julius Baxter get green lights from his company to release the cpu source
<Fallenou>
I think having Linux running correctly (with shared objects, mmu and so on) could attrack geeks :)
<kristianpaul>
indeed Fallenou
<Fallenou>
for now, without Linux, I don't know who it can attrat
<Fallenou>
attract
<kristianpaul>
attrack more software people wanted to hack in higer layers too :)
<Fallenou>
even geeks can be disgust because it does not run their favourit OS
<wpwrak>
i'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.
<kristianpaul>
and re-use all that software already works on other lowend devices (for instance jlime project as reference)
<Fallenou>
sure, having linux means the basic geek can hack his way almost easily
<Fallenou>
he can try to just cross compile his software
<Fallenou>
fix a few porting bugs and voila
<kristianpaul>
yah !
<wpwrak>
Fallenou: yes, rtems is a big barrier for hackers
<Fallenou>
instead of porting from scratch to RTEMS
<Fallenou>
sure
<kristianpaul>
BIG
<Fallenou>
indeed RTEMS is open source and free
<Fallenou>
but it can be a lot of work to port something on it :/
<Fallenou>
at least, more work than porting to Linux-lm32
<Fallenou>
(IF it is working correctly.)
<kristianpaul>
wpwrak: 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 it
<Fallenou>
but I guess it has been said tons of times here :)
<kristianpaul>
as it includes its own memory allocation ANSI code
<kristianpaul>
Fallenou: ;)
<kristianpaul>
Fallenou: i also was thinking the alredy in upstream openrisc
<wpwrak>
kristianpaul: why not have a ROM BASIC like in "home" computers in the 1980es ? that was pretty safe ;-)
<kristianpaul>
my palm and jornada have a rom :-)
<kristianpaul>
wpwrak: i just want to support the mmu-less idea :)
<wpwrak>
Fallenou: 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.
<Fallenou>
yes :/
<kristianpaul>
perhaps i'm still too lazy to learn linux internal so i need elaborate more excuses for not use mmu
* kristianpaul
like flat memory space, flat internet, flat...
<wpwrak>
Fallenou: 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 class
<kristianpaul>
wpwrak: and getting back to 703 (hope not OT here sorry lekernel :), just imagine this things are getting smaller and smaller
<wpwrak>
kristianpaul: fragmentation, bugs in application X crashing application Y, ... oh the joy :)
<kristianpaul>
so you'll end outsourcing some nasty? and no worth effort to free yet? wlan with in those devices that at least run owrt fine
<kristianpaul>
wpwrak: i even mentioned X, that is too much a feature it self
<kristianpaul>
also is hard to said what is an aplication running inside a lua intepreter but... i got your point for sure
<Fallenou>
wpwrak: 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"
<Fallenou>
so they kind of know it is "powerful enough to run linux"
<wpwrak>
kristianpaul: (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 ?
<Fallenou>
but they may be disappointed by the fact that it is no longer supportee
<Fallenou>
supported*
<kristianpaul>
wpwrak: integration or comsmetic look?
<kristianpaul>
because i think you worry more for the last
<wpwrak>
Fallenou: is it's powerful enough, why on earth aren't you running it then ? that's a very suspicious statement :)
<wpwrak>
kristianpaul: well, both
<Fallenou>
wpwrak: usually I say "lm32 Linux port is just totally crappy and buggy and we don't have the bandwidth to fix it"
<Fallenou>
I reject the fault on theobroma
<wpwrak>
kristianpaul: people going rotfl after the first glance may not be the uplifting experience we aim for :)
<Fallenou>
Adding the fact that RTEMS has less memory and cpu footprint
<Fallenou>
and it's realtime etc etc etc
<Fallenou>
you can easily justify the use of RTEMS I think :)
<wpwrak>
(RT) yawn ;-) is if linux wasn't
<Fallenou>
sure :p
<Fallenou>
I am reading a nice book about linux real time
<kristianpaul>
(RT) why bother when we can run RT stack on softcores as right now the usb one?
<Fallenou>
Christophe Blaess writes nice books about Linux and embedded stuff
<kristianpaul>
and implement a MMIO API or such to talk to this devices
<Fallenou>
this is his new book (released 2 weeks ago)
<Fallenou>
but too bad it's only in French
<wpwrak>
kristianpaul: it's usually easier if you can have everything in the same part of the system
<kristianpaul>
you mean for RT or 703n?
<wpwrak>
kristianpaul: and "RT" can mean a lot of things. you don't always need extremely quick responses.
<kristianpaul>
ah ya
<kristianpaul>
sure
<wpwrak>
hah, actually applies to both ;-)
<kristianpaul>
indeed ;)
<Fallenou>
the big thing for RT is not to be quick
<Fallenou>
it's to be deterministic :p
<kristianpaul>
and not get hang :)
<Fallenou>
but indeed, if it's deterministicly slow, it's bad
<Fallenou>
but at least when it's deterministic, you can what it can do, and what it cannot do
<Fallenou>
-you can+you know
<wpwrak>
if 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.ps
<wpwrak>
(measurements on page 12)
<Fallenou>
wow, will read later
<Fallenou>
seems like a complex paper to read :)
<wpwrak>
just look at the numbers :) that's disk i/o. still jitter in the range of only 5 ms.
<kristianpaul>
wow
<kristianpaul>
and i just enable/patch this abiss and thats it ? !
<wpwrak>
you have to tell the system how you expect it to perform, to adjust the buffering and such
<wpwrak>
also, we didn't finish that project. interest went elsewhere, so eventually it just fell asleep
<Fallenou>
oh, your name is on the first page :)
<Fallenou>
surrounded by philips folks
<wpwrak>
see page 5 for the buffering
<Fallenou>
what I've read so far about RT was not talking about I/O
<wpwrak>
yeah, the was the project i was working on before openmoko
<Fallenou>
only scheduling, timers, irq
<wpwrak>
disk i/o is something rt folks don't like. because it's way too complex to specify exactly
<wpwrak>
i 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"
<wpwrak>
of course, the correct answer would be: "bugger off !" ;-)
<Fallenou>
does it mean something like "fuck off" ?
<Fallenou>
it seems to :p
<wpwrak>
yes. it's about as vulgar, too. there are just less people who recognize it as vulgar ;)
<Fallenou>
hehe ok :p
<Fallenou>
diner, bbl
lekernel_ has joined #milkymist
lekernel has quit [Ping timeout: 252 seconds]
lekernel_ is now known as lekernel
elldekaa_ has joined #milkymist
elldekaa has quit [Ping timeout: 252 seconds]
lekernel has quit [Ping timeout: 246 seconds]
wolfspraul has quit [Ping timeout: 246 seconds]
wolfspraul has joined #milkymist
voidcoder has joined #milkymist
km2 has quit [Ping timeout: 276 seconds]
km2 has joined #milkymist
lekernel has joined #milkymist
elldekaa_ has quit [Remote host closed the connection]
* Fallenou
just unplugged from it's socket : an Intel 486 DX2, an Intel Celeron and an Intel Pentium III
<Fallenou>
souvenir :'
lekernel has quit [Remote host closed the connection]