<kristianpaul>
but always i do make on rtems-bsp it happens
<Fallenou>
I think I solved it doing some lm32-ranlib or something
<kristianpaul>
hmm
<Fallenou>
lekernel knows about it
<Fallenou>
We should document this on the wiki :x
<Fallenou>
sorry have to go
<kristianpaul>
np
<kristianpaul>
go !
<kristianpaul>
:-)
<Fallenou>
if you did make in the bsp and then make install
<kristianpaul>
yes
<Fallenou>
you should surely make install and mv the files from zlib libpneg and stuff
<Fallenou>
libjpeg etc etc
<kristianpaul>
hmm
<Fallenou>
maybe
<Fallenou>
i don't know
<Fallenou>
try
<kristianpaul>
k
<kristianpaul>
i solved before too, but not proper way tought..
<kristianpaul>
okay i recompiled zlib and linpng problem solved..
<Fallenou>
ok
<Fallenou>
maybe we should document that
<kristianpaul>
but i do not understand why hapen this and better way to solved
<kristianpaul>
not proper way i think, rtems should have a guideline about deal with issues related to libs
<kristianpaul>
i wonder if this is the source of the problem
<kristianpaul>
"The libpng shipped with the RTEMS graphics toolkit is out of date, so we don't use it. But there is a problem with the latest vanilla libpng (1.4.4) which can't find the RTEMS zlib because all its functions are prefixed with "z_". Instead of messing with the GNU/Autohell scripts of libpng, we simply recompile zlib to do away with the prefix. We use the regular zlib. The instructions below work with zlib 1.2.5."
<kristianpaul>
anyway..
<kristianpaul>
lets try this
<Fallenou>
*away sleeping*
<kristianpaul>
lol
<kristianpaul>
No rx buffers left in the pool! We are in big troubles!
<kristianpaul>
(ran nmap)
<kristianpaul>
Fallenou: now i'm able to freeze to board and no overflow msg on screen ;-)
<kristianpaul>
okay that was ftp,. now ttcp just in case..
<kristianpaul>
ah, yes for ftp test i was sending a 11Mb file
<kristianpaul>
need a tap
<kristianpaul>
hmm or tell my swich do trafic mirror, but nah, i prefer bring the laptop ;-)
<CIA-37>
rtems-milkymist: Yann Sionneau master * rb121f8f / c/src/lib/libbsp/lm32/shared/milkymist_networking/network.c : initialize rx buffers busy flag with 0 - http://bit.ly/gGHQgl
<kristianpaul>
what was that??
<kristianpaul>
looks at Fallenou
<Fallenou>
forgot to say that by default the buffer is "not used"
<Fallenou>
it was ok with qemu though
<kristianpaul>
yeah, seeing diff tight now
<kristianpaul>
right*
<Fallenou>
I guess this fixes nothing
<Fallenou>
but better initialize the values
<Fallenou>
so you would say it's worse ?
<kristianpaul>
no
<kristianpaul>
actually i will like help, but no enought skill for give opinios on this topic
<kristianpaul>
back to CSR bus topic
<Fallenou>
ok
<Fallenou>
is it better ? no opinion ?
<kristianpaul>
jeje
<kristianpaul>
no no
<kristianpaul>
intialize is always good
<Fallenou>
I mean, is the driver working better now ?
<Fallenou>
or worse ?
<kristianpaul>
ah
<Fallenou>
or the same
<kristianpaul>
well..
<kristianpaul>
it crasehed board with a 12~ file..
<kristianpaul>
thats same as before
<Fallenou>
hum ok
<kristianpaul>
i dint tried small files
<kristianpaul>
BUT
<kristianpaul>
i dont get a feedback on screen that may be realted with the crash..
<Fallenou>
di you try ttcp ?
<Fallenou>
+d
<kristianpaul>
yes
<kristianpaul>
is running now..
<Fallenou>
oh ok
<kristianpaul>
but is on my home swich so i cant debug verywell..
<Fallenou>
in theory you wouldn't need to debug :p
<kristianpaul>
now i wonder what hapen with the other file..
<kristianpaul>
gmm
<Fallenou>
wow what a mess
<Fallenou>
the output
<kristianpaul>
NOW you SEE ;-)
<Fallenou>
yes :p
<kristianpaul>
my suffering :(
<kristianpaul>
thats from flterm btw
<Fallenou>
so if I understand all this mess
<Fallenou>
the test completed ?
<kristianpaul>
at the amazing rate of 27.19 KB/sec
<Fallenou>
it's fucking slow
<Fallenou>
even on my qemu i get better
<kristianpaul>
but safe ? ;)
<Fallenou>
i get like 1,2 MB/sec
<kristianpaul>
hmm
<Fallenou>
really strange
<Fallenou>
I thought it would be faster on the hardware than on qemmu
<kristianpaul>
not so
<Fallenou>
well the hardware bus frequency is 80 MHz
<Fallenou>
and mine is a lot faster
<kristianpaul>
i bet buses not behave same in qemu..
<Fallenou>
yes
<Fallenou>
ttcp is behaving as before ?
<Fallenou>
or is it better ?
<kristianpaul>
no crash
<Fallenou>
I mean there is no rx buffer overflow
<kristianpaul>
but damn slow..
<kristianpaul>
rx buffer overflow
<kristianpaul>
gone..
<kristianpaul>
hahaah
<kristianpaul>
bad
<kristianpaul>
512K file by ftp to ramdisk
<kristianpaul>
crashhh..
<Fallenou>
:(
<Fallenou>
wtf
<kristianpaul>
no erros
<kristianpaul>
thats bad
<Fallenou>
ethernet is driving me crazy
<Fallenou>
lekernel thinks there may be a bug in hardware too
<kristianpaul>
yes i think same
<Fallenou>
that could explain some of the bugs
<kristianpaul>
with on chip ram
<kristianpaul>
but this was working before btw..
<Fallenou>
it may be a good idea to run simulation of the minimac core
<kristianpaul>
even wit the already noticible  "rx buffer overflow"
<Fallenou>
:(
<Fallenou>
I really doesn't understand
<Fallenou>
let's see what lekernel thinks of the patch
<Fallenou>
maybe there is something terribly wrong with it
<kristianpaul>
52294 bytes sent in 2.70 secs (18.9 kB/s)
<Fallenou>
let's see if I can improve
<kristianpaul>
as i said ttcp work now, but no ftp..
<kristianpaul>
as before
<kristianpaul>
odd..
<Fallenou>
I sent the patch to the MLÂ Â , to get feed backs
<kristianpaul>
rtems yeah !
<Fallenou>
oh do to MM ML
<Fallenou>
no*
<kristianpaul>
rtems guys could help too
<kristianpaul>
also they claim the bug also
<Fallenou>
yeah but they would whine about the fact that we are not sync'ed with them
<Fallenou>
our git and their cvs
<kristianpaul>
hehe
<kristianpaul>
true
<kristianpaul>
154128 bytes sent in 4.96 secs (30.4 kB/s)
<Fallenou>
well sorry
<Fallenou>
gotta go sleeping
<kristianpaul>
no no
<Fallenou>
will try to improve
<kristianpaul>
sure !
<kristianpaul>
go sleep
<Fallenou>
:) gn8
<wolfspraul>
kristianpaul: when you guys say 'bug in hardware', you mean the Milkymist SoC, or you mean the actual physical hardware?
<kristianpaul>
yeah, system crashed with a 512K transfer..
<kristianpaul>
wolfspraul: fpga i think, internal on-chip-memory
<wolfspraul>
yes OK, but again "bug" here means something that can be improved in Verilog, or something that needs to be improved in the physical hardware?
<wolfspraul>
that distinction is quite important to me :-)
<kristianpaul>
wolfspraul: lekernel already pointed some errata, and i noticed etherner bug was also manifesting  itself by ramdon  or after loading bitstream sometimes
<kristianpaul>
wolfspraul: verilog yes
<kristianpaul>
i think
<kristianpaul>
dunno what lekernel things
<wolfspraul>
ok
<kristianpaul>
i bet is avoid some custom memory arrangements that can trigger this
<wolfspraul>
I'm preparing for the next bigger run, with capital expenditure 20,000 - 30,000 USD
<wolfspraul>
naturally I want to avoid creating a 25,000 USD broken art installation
<wolfspraul>
no gallery to sell it either
<kristianpaul>
as ethernet core have a small buffer the memory bug can manifest there i think
<wolfspraul>
the milkyman, a sculpture made out of 80 m1 rc3 boards :-)
<kristianpaul>
bbl (dinner)
<wolfspraul>
kristianpaul: yes, understood. you get my point. I am most interested where we believe the bug can be fixed, or the improvement made.
<wolfspraul>
whenever you have the feeling it reaches beyond Verilog, into physical hardware, shoot me a note right away
<wpwrak>
wolfspraul: (broken art) maybe RISD could be interested, as a backdrop for the gta03 that supposedly went there ? :)
<kristianpaul>
wpwrak: RISD?
<wpwrak>
kristianpaul: rhode island school of design
<kristianpaul>
wolfspraul: how many mm1 this run?
<kristianpaul>
for this*
<wolfspraul>
currently I am planning for 80
<wolfspraul>
ideally 75 as sellable result
<wolfspraul>
I may adjust this number upwards or downwards depending on what happens on the ground (=everywhere) :-)
<wolfspraul>
but not much, because I am already sourcing, so especially if we adjust a lot upwards, we may have to source some components a second time
<wolfspraul>
if I have 75 sellable units, I feel equipped well enough for a real launch
<wolfspraul>
that's 37,500 USD sales revenue, need to find customers for that much first - not easy
<wolfspraul>
and even if they do show up, I can react with another run
<wolfspraul>
the size is double the rc2 run, which is a good way to grow manufacturing runs
<wolfspraul>
if I get very nervous, I will reduce the size of the run, or make two partial runs
<wolfspraul>
if some large pre-order customer shows up, I can increase it too, of course
<wolfspraul>
actually it's easy - the goal is to never run out of stock
<wolfspraul>
:-)
<wolfspraul>
which is the case right now, so what limits m1 today, is that we need to find additional customers that are paying money for the units we have
<wolfspraul>
not the size of the next run
<wolfspraul>
but I have too few units in stock (and in too customer unfriendly conditions - unassembled etc) for a real launch
<kristianpaul>
aw_: /aw
<kristianpaul>
aw_: hi
<kristianpaul>
aw_: How many or  wich kindof sd-like memory do you used for mm1 testing?
<kristianpaul>
xiangfu: morning
<kristianpaul>
xiangfu: new booting bios?
<xiangfu>
kristianpaul: morning
<xiangfu>
after flash the last bios and last flickernoise.fbiz. now MM1 boot again.
<kristianpaul>
good
<xiangfu>
my build of flickernoise.fbiz is 3MB
<xiangfu>
(btw, I update the mupdf  to 0.8)
<aw_>
kristianpaul, you meant size? i used 2GBytes only.
<kristianpaul>
aw_: size and branf :-)
<kristianpaul>
brand**
<kristianpaul>
2Gb okk
<kristianpaul>
xiangfu: 3Mb inclusing mupdf ?
<aw_>
brand: Transcend
<kristianpaul>
just that?
<kristianpaul>
only*
<xiangfu>
kristianpaul: yes.
<kristianpaul>
xiangfu: oh wow
<kristianpaul>
xiangfu: what you did?
<kristianpaul>
jsut upgrade to 0.8?
<kristianpaul>
i wonder if is also lighter when using, had you tried read some pdf?
<aw_>
this doc is indeed wrote a 'fundamental' xtal, I wrote emails to vendor with how they are different and if it could have behavior with different oscillating voltage.
<aw_>
I'll let you know hopefully they reply me later. ;-)
<kristianpaul>
:-)
<roh>
:)
<kristianpaul>
aw_: tape & reel, they provide it already as a tape
<kristianpaul>
aw_: i remenber last run operator manually feed it
<kristianpaul>
Why i'm thinking before crystal doc have a lot of copy and paste ;-)
<kristianpaul>
this look better indeed
<kristianpaul>
or at least is from dec 2010
<kristianpaul>
sed -i 's/csr_a\[13\:/csr_a\[14\:/g' */rtl/*v
<kristianpaul>
(for my record :-))
<aw_>
um..hopefully they were not copy & paste style. ;-) yes, last  time we used cylinder type bulk parts
<kristianpaul>
no no,you tell me :-) i have zero experience on this..
<kristianpaul>
ok.. other 40~ minutes..
<lekernel>
wolfspraul: ethernet transfers work reliably enough in the BIOS, so the PCB is definitely OK
<wolfspraul>
ok great, thx
<lekernel>
3MB FBIZ = after LZMA compression, before compression it's probably around 8-9MB
<lekernel>
the problem is LZMA decompression is slow as hell and brings the boot time to around 45s, so it'd be good to debloat the code a bit (ideally, enough not to require LZMA anymore)
<lekernel>
if it's too difficult to debloat, leave it, it's not a central feature
<wolfspraul>
45 seconds, wow
<wolfspraul>
I thought it was 3-4 seconds so far
<wolfspraul>
we definitely should try hard to keep it in that area, every second less is great
<wolfspraul>
lekernel: let xiangfu_ know if he can help anywhere, he is looking for tasks :-)
<lekernel>
it's still a few seconds without PDF (and therefore without LZMA)
<wolfspraul>
sure, but in my mind a feature that increases boot time to 45 seconds simply doesn't exist
<lekernel>
but since PDF isn't an important feature, let's not spend too much energy on that
<wolfspraul>
so either the boot time comes down, or we cannot include the feature
<lekernel>
it can be simply disabled at compile time already
<wolfspraul>
yes I know
<wolfspraul>
xiangfu_: you there?
<xiangfu_>
yes. reading ..
<lekernel>
hi xiangfu_
<wolfspraul>
lekernel: as xiangfu_ is slowly coming up to speed on the platform, do you have any ideas of tasks for him?
<lekernel>
dark color theme for MTK?
<lekernel>
shouldn't be too hard :)
<wolfspraul>
my big ones for xiangfu_ are easy updates via the gui ("update now" button, checking for newer versions via ethernet etc)
<lekernel>
yeah, that too
<wolfspraul>
and supporting adam on testing software, i.e. adding features adam needs, documenting the build process
<wolfspraul>
fixing rtems driver bugs as reported by others (or found by himself)
<lekernel>
there's the flash subfolder FTP problem (I mailed him about that)
<xiangfu_>
lekernel: WITH_PDF. the flickernoise is 8.3M here. the boot time will increase a lot. haven't try to boot this 8.3M flickernoise.
<lekernel>
but I suspect this has to do with a bug in the implementation of the RTEMS eval_path API, which is the most retarded programming idea I've discovered in a while
<xiangfu_>
lekernel: yes. I got that email.
<lekernel>
so... good luck :(
<wolfspraul>
xiangfu_: boot time 45 seconds is unacceptable anyway. so it either must come down, or if that's too hard we remove the feature (for now) and work on something else
<wolfspraul>
if that's an important bug, why not
<wolfspraul>
bugs need to be fixed :-)
<wolfspraul>
as long as we watch priorities, I don't care how hard it is to fix a bug
<lekernel>
xiangfu_: the flash partition is 4MB only, so you need to LZMA your 8.3M image
<xiangfu_>
wolfspraul: (boot time, pdf feature) ok. I just report my side :)
<wolfspraul>
xiangfu_: ok great, sounds like you have good practical tasks already, and you and lekernel are talking. great!
<lekernel>
the scripts can do it
<lekernel>
but LZMA decompression takes forever on the board
<wolfspraul>
xiangfu_: try to pick small tasks at the beginning, that will allow you to deliver real results to others in smaller incremental steps.
<wolfspraul>
xiangfu_: so what is your #1 priority right now on m1?
<xiangfu_>
wolfspraul: for me. I put the 'pdf' to #1. because the pdf task seems the easier one.
<lekernel>
2. different keymaps (atm it only supports the German keyboard layout)
<lekernel>
3. different languages... maybe selected at compile time
<wolfspraul>
that curlybracket jpg is under a free license?
<wolfspraul>
the language should be selectable at runtime, preferable. I cannot imagine that will take up a lot of space.
<lekernel>
no, but it's a bit harder to implement
<wolfspraul>
that's what we have xiangfu_ for :-)
<wolfspraul>
xiangfu_: that's a great task too, imho
<xiangfu_>
:D
<lekernel>
wolfspraul: (jpg) no, it's cc-nc-nd, but I have the specific permission to include it on Milkymist, which is enough I think... I see it as a small extra that we distribute with the product
<wolfspraul>
lekernel: -nc - argh. has he lifted the -nc -nd restriction for Milkymist?
<wolfspraul>
if not we should not include it
<lekernel>
-nc yes, I made it clear that we intend to sell devices with this file on the flash as default wallpaper
<lekernel>
-nd didn't ask
<wolfspraul>
ok let's assume -nd is lifted as well, otherwise we remove it
<wolfspraul>
this type of jpg is hard to modify anyway, but this -nd stuff is a sad thing. real creative people will laugh at the whole concept.
<lekernel>
it's just a wallpaper ok? :)
<wolfspraul>
not ok. since the -nc -nd stuff exists we need to take it serious.
<wolfspraul>
I didn't write this crap.
<wolfspraul>
it's laughable to any real creative person
<wolfspraul>
the good thing is it's easy to remove, and since he lifted -nc let's just assume -nd is lifted as well, for now.
<lekernel>
certainly, but not everyone shares your point of view about licenses, and we have to respect those as well
<lekernel>
a nc-nd good looking wallpaper is better than nothing
<wolfspraul>
yes, but I won't include it on devices I'm selling :-)
<lekernel>
please don't do like rms bothering the BSD people with non-free software installable from the ports tree :)
<wolfspraul>
we are on the same page that -nc -nd is an annoyance. it wastes everybody's time.
<wolfspraul>
absolutely meaningless.
<Fallenou>
wolfspraul: how can you measure pre-orders ?
<wolfspraul>
lekernel: should I email him to clarify the -nd part?
<wolfspraul>
painful stuff
<wolfspraul>
Fallenou: measure? don't understand
<wolfspraul>
I don't take pre-orders. if you want to order one you pay, then I ship :-)
<wolfspraul>
lekernel: what is the other point of view about licenses you are suggesting? you are fine to include cc -nd -nd content?
<lekernel>
wolfspraul: no, I'll write her... but I don't think it'll be easy to make her totally change the license, so you can also suggest another picture :)
<wolfspraul>
I am following Wikimedia Commons guidelines, seems the easiest and best to me.
<wolfspraul>
and nobody would ever make a derivative of that jpg anyway.
<lekernel>
wolfspraul: as long as it's non-central content, I don't really care. this jpg is just a little extra that we'd distribute with the product, which isn't as free as we would like it to be, but what can we do
<wolfspraul>
he. that sounds like no policy at all :-) "non-central content, I don't really care"
<wolfspraul>
I understand your point of course.
<wolfspraul>
I hate wasting time over -nc -nd clarifications.
<Fallenou>
lekernel: is lzma a "hardware" friendly algorithm ? can a core accelerate it ?
<lekernel>
no idea... i just copy and pasted the lzma decompression code from the linux kernel, I don't even know how it works
<Fallenou>
ok
<Fallenou>
cause maybe a core could be our solution
<Fallenou>
is just saying, doesn't know the algo
<lekernel>
sounds like a lot of work for few things
<lekernel>
i'd simply leave pdf support out instead :) there are way more important things...
<Fallenou>
ok fair enough
<Fallenou>
02:23 < wolfspraul> if some large pre-order customer shows up, IÂ Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â can increase it too, of course
<Fallenou>
that's why I wonder how you can "count" pre-orders
<Fallenou>
you have a website set-up for pre-orders ?
<Fallenou>
I met the director of this website during oshug
<Fallenou>
I am seeing it again on thursday
<Fallenou>
s/it/him/
<Fallenou>
maybe it can help you figure out how much customer we have / we can have before doing the runs
<wolfspraul>
Fallenou: what exactly do you want me to do with getitmade.com ?
<wolfspraul>
no I don't have any specific website setup for preorders, and that is not necessary. when you have money, you know you can approach anybody about buying anything.
<wolfspraul>
what I will do is to contact specific people to explain Milkymist to them and see whether I can get them interested
<wolfspraul>
if one of them turns around and says "we are very interested, we want to get in big time and order 500 right away", that would be what I meant
<wolfspraul>
the terms would be roughly 50% upfront, 50% before shipment
<wolfspraul>
the normal OEM terms are 30% upfront, 70% before shipment
<wolfspraul>
since this is a very risky/innovative product, I would ask for 50/50
<wolfspraul>
but the main point is to find someone who really believes in the product and wants to jump in (i.e. take business risks)
<wolfspraul>
I definitely agree with lekernel about just leaving PDF out if it causes too many problems now.
<wolfspraul>
but of course, if more people join we can work on more things in parallel ;-)
<Fallenou>
ok I understand better now wolfspraul :) thanks
<Fallenou>
you are trying to approach big buyers, not end users
<Fallenou>
I didn't realize that
<wolfspraul>
end users can buy now
<Fallenou>
yes
<wolfspraul>
the product is in stock
<wolfspraul>
so what is the problem you are trying to solve?
<Fallenou>
none I was just trying to understand
<Fallenou>
you made it very clear now :)
<wolfspraul>
I just read about getitmade
<wolfspraul>
they make it easy to collect pre-orders
<Fallenou>
yes
<wolfspraul>
that sounds like a disaster strategy to me
<Fallenou>
oh really ?
<wolfspraul>
then I believe much more in kickstarter.com
<Fallenou>
the problem with kickstarter is that it ships only to US or something like that
<Fallenou>
you need a US credit card or something
<wolfspraul>
I have 15+ years industry experience. I have never met one person with experience who says that pre-orders work, especially not for innovative products.
<wolfspraul>
in fact. if you see someone trying to finance anything innovative with pre-orders, you know it will all blow up.
<wolfspraul>
guaranteed. 100%.
<wolfspraul>
it has been tried many times
<Fallenou>
ok I didn't know
<wolfspraul>
you can have a few large pre-order customers, that works
<Fallenou>
I have 0- experience in this domain :)
<wolfspraul>
yes OK, so I tell you mine
<wolfspraul>
(and others might disagree)
<wolfspraul>
the problem is communication
<wolfspraul>
it's easy
<wolfspraul>
innovative means something will not work as expected
<wolfspraul>
true?
<wolfspraul>
some features need to be removed
<wolfspraul>
price need to be increased
<wolfspraul>
DELAYS!
<wolfspraul>
:-)
<wolfspraul>
the more innovative thing you do, the higher the risk of all of those
<wolfspraul>
right?
<wolfspraul>
now
<Fallenou>
yes
<wolfspraul>
imagine you are sitting on the money of 1000 individual pre-orders customers
<wolfspraul>
can you imagine the complete impossibility of keeping the communication flowing with them?
<wolfspraul>
about what strange bug showed up, what realization, what the options are, why option xyz was chosen, etc.
<wolfspraul>
then some will cancel
<Fallenou>
well it needs a dedicated man which maintains wiki/twitter/ and such
<wolfspraul>
some will not agree with the judgments
<wolfspraul>
some will only understand half
<Fallenou>
like a community manager
<wolfspraul>
and so on
<Fallenou>
manage the forum
<wolfspraul>
it's impossible
<Fallenou>
But I definitely see your point
<wolfspraul>
innovative = things turn out different than originally thought
<wolfspraul>
that is inherently incompatible with a high number of individual pre-orderers
<wolfspraul>
the two are mutually exclusive
<Fallenou>
hum I guess you're right
<wolfspraul>
so if you do something low risk, ok fine, you can do it
<Fallenou>
11:47 < wolfspraul> innovative = things turn out different than  originally thought
<Fallenou>
this is totally true
<wolfspraul>
but you better be sure that nothing unexpected happens
<wolfspraul>
because you are sitting on this communication bomb
<Fallenou>
even the creator of an innovative stuff does not see the real point at the begining
<wolfspraul>
you cannot communicate effectively with those large number of pre-orderers
<wolfspraul>
if it's innovative, you can have a few large pre-orderers
<wolfspraul>
that's fine
<wolfspraul>
say at most 5-10 people
<wolfspraul>
every one less will help
<wolfspraul>
then if something unexpected happens, you can try emails, phone calls, phone conferences, etc.
<wolfspraul>
so don't know what to do with getitmade right now
<wolfspraul>
you can register m1 there, and see how many pre-orders you can collect
<wolfspraul>
true?
<Fallenou>
maybe it's good when the product is totally finished and not evoluting
<wolfspraul>
you can even take money!
<wolfspraul>
:-)
<wolfspraul>
yes of course
<wolfspraul>
but then why pre-order at all? why not just sell?
<Fallenou>
it's to have bigger runs
<wolfspraul>
I think if you register m1 there, and start taking pre-orders (money), you will immediately see the problem.
<Fallenou>
with less risks
<wolfspraul>
you will be on my neck every day about the production date
<Fallenou>
ahah ok :)
<wolfspraul>
but that's not my problem then. I say "probably May", and then in May we see where we are.
<wolfspraul>
you promised something to your pre-order customers, not me
<wolfspraul>
I know there are too many risks (unknowns) to promise a hard shipping date now.
<wolfspraul>
alright, hope this makes sense :-)
<wolfspraul>
but thanks for pointing getitmade out to me
<wolfspraul>
very appreciated
<Fallenou>
let's be clear, I didn't want to upset you :)
<wolfspraul>
not at all
<Fallenou>
ok good
<wolfspraul>
I am sharing my thinking.
<wolfspraul>
I like those sites
<Fallenou>
and thanks for your point
<wolfspraul>
I just read their faq and scratching my head :-)
<Fallenou>
I clearly understand your opinion now
<wolfspraul>
I don't want large number of pre-orders mixed with innovative products
<wolfspraul>
that will blow up
<Fallenou>
ok
<wolfspraul>
so I think kickstarter.com is better
<wolfspraul>
you throw the money over to the other side, and get no hard promises back
<wolfspraul>
more like a donation, and wish for the best
<Fallenou>
hehe
<wolfspraul>
that's much more in line with what an innovative product needs
<Fallenou>
I guess you're right
<Fallenou>
it's not for "common" end-users
<Fallenou>
it's more for "very-small" investers
<wolfspraul>
yes
<Fallenou>
who wants to give a hand to promising project they find cool
<Fallenou>
and maybe get a product in return
<wolfspraul>
they can develop a lot of power though, I do believe in that
<wolfspraul>
correct
<wolfspraul>
that's a great model imho
<wolfspraul>
and whoever gets the money should work their ass off to deliver
<Fallenou>
yes but hard to advertise in this world
<wolfspraul>
but if it's innovative, there are no guarantees
<Fallenou>
where you want something for your money
<wolfspraul>
'pre-order' is an illusion mostly
<wolfspraul>
well, if you want to be sure, then wait until the product is in front of you
<wolfspraul>
in the store. try it there, only take the unit you hand-tested yourself.
<wolfspraul>
ok no worries we don't get stuck on this :-)
<wolfspraul>
actually, can the current m1 take screenshots?
<wolfspraul>
that would be another nice feature to add, if it's not there yet, for xiangfu
<lekernel>
the m1 no, but qemu can
<wolfspraul>
cool, I'll add it to my wishlist for xiangfu
<CIA-37>
flickernoise: Sebastien Bourdeauducq master * r79f88b0 / src/Makefile : Fix link order of libs (Xiangfu) - http://bit.ly/edjEX5
<Fallenou>
lekernel: I think you should put the "FPGA proven" flag on your Navre AVR clone on opencores
<Fallenou>
I noticed the flag is not set
<lekernel>
yeah, and document it too :)
<Fallenou>
since it works on fpga, just putting the flag can advertise it better
<Fallenou>
documentation take more time to just set the flag :p
<Fallenou>
lekernel: I was asked during the talk "which device class are supported by the usb host controller" ?
<Fallenou>
I didn't know exactly
<Fallenou>
so I said for the moment it's just some devices, like keyboard and mice
<lekernel>
assuming I lost my #{|#~ opencores password, I'm not so sure about that
<Fallenou>
didn't know the exact device classes
<lekernel>
ah, found it
<Fallenou>
:
<Fallenou>
:)
<lekernel>
I guess I can advertise it as "stable" too, by opencores standards it probably deserves it
<Fallenou>
ahah
<Fallenou>
some of your cores has been "elected/selected" as OpenCoresCertified ;)
<Fallenou>
like HPDMC
<lekernel>
phew, it's also an old version in the opencores repository
<Fallenou>
dunno if it's a reward for you though :p
<Fallenou>
puts a "OpenCoresCertified" sticker on lekernel
<Fallenou>
too bad I won't be able to attend to OSHUG #9 about opencores
<Fallenou>
i could have grabbed some stickers =)
<lekernel>
I don't think opencores has stickers
<Fallenou>
oh :(
<Fallenou>
you have to send your code to their svn ? you can't just give a git url ?
<Fallenou>
that's annoying to have to maintain 2 repositories :o
<lekernel>
"opencores policies" ... :)
<Fallenou>
they should implement a sort of daemon/cron that just git clones /svn co/cvs branch
<Fallenou>
from your main project repo
<lekernel>
"the code has to be checked in, opencores is not just a repository of links"
<Fallenou>
yeah I see
<Fallenou>
they want to be like github :)
<Fallenou>
they want content
<lekernel>
"we ask people to register to download, statistics are important to build credibility"
<Fallenou>
yeah that's strange too
<Fallenou>
you have to register to access the content in read only
<lekernel>
at least github has an outstanding web design and version control system
<lekernel>
and no registration necessary :)
<Fallenou>
yep github is really cool
<Fallenou>
not opensource but cool
<Fallenou>
I wonder if gitorious is of the same quality
<lekernel>
well, everyone's got bills to pay
<lekernel>
and quite frankly I prefer Github's policy than Opencores'
<lekernel>
github makes money by selling a proprietary web service to companies
<lekernel>
and supports open source software with a free of charge and outstanding service
<lekernel>
opencores makes money by being control freaks and talking to advertisers and (probably) investors
<Fallenou>
well anyway
<Fallenou>
the service is clearly not the same quality
<lekernel>
and maybe by using opencores to heavily promote ORSoC's consulting services - though I doubt any serious ASIC company would hire them for HDL developments
<lekernel>
they seem to do a decent job with embedded software though
<Fallenou>
I really don't know what they do
<Fallenou>
am on their website
<lekernel>
oh, and Du talar och skriver Svenska och Engelska flytande :)