<rjeffries>
wpwrak thanks to your mail server my various email updates on PCF getting a quoye process all bounced
<rjeffries>
the PCB fab place will panelize using gerber we supply
<rjeffries>
I hear someone snoring, somewhat annoying ;)
<wpwrak>
i don't think i lost any mails :) the bounces you're getting are from things i've read. just the copies of them bounce.
<wpwrak>
(panelize) excellent !
<wpwrak>
so you have a quote now ?
<wolfspraul>
wpwrak: we found the root cause of the broken jtag-serial high-speed mode, and it could have been cought earlier if someone would have looked at KiCad's DRC report, which clearly stated 2 unconnected pads :-)
<wolfspraul>
good reminder to strengthen and tighten our process...
<wpwrak>
eeeeeh !!
<wolfspraul>
this type of discovery only motivates me, no problem :-)
<wolfspraul>
we found the bug, we will rework (fix) all boards that Adam still has, and we will offer free fixing for people who want it or have a problem with their current boards.
<wpwrak>
some ERC/DRC filter may be useful. e.g., i have lots of ERC errors in my designs because of pins that nominally connect to something that could be a problem (but isn't), and anything with an antenna gets DRC errors, because the antenna shorts its input to ground.
<wolfspraul>
(of course we already know that the unfixed boards work as well, so maybe we can fix or exchange old boards at convenient opportunities like congresses/get-togethers, rather than sending a 20 USD board around the world several times. We see. We will do good on this.)
<wpwrak>
does it actually matter in real life ?
<wolfspraul>
wpwrak: and those things cannot be expressed in KiCad?
<wolfspraul>
I don't think it matters much. maybe in high-speed the reflashing could be a little faster still, but even in full-speed we can get 1 MiB / sec over the board. The USB speed may not even be the real bottleneck, I don't know.
<wpwrak>
you can turn off combinations in ERC. but then, you may suppress too much. i have an old patch that adds some specific suppression, but that one doesn't seem to work anymore
<wolfspraul>
the point is that we overlooked an obvious bug, and we produced 100 boards with the bug.
<wolfspraul>
that will get fixed
<wpwrak>
with DRC, no, pcbnew doesn't understand PCB-level passive components ;-)
<wpwrak>
the problem with those false positives is that they could mask real problems. e.g., i don't run ERC anymore, because i'll just get a lot of meaningless complains. (also, the boards are tested, so i already know i didn't miss anything ;-)
<wolfspraul>
yeah that's bad. that sounds like improvements are needed in KiCad.
<wpwrak>
i do run DRC, because i could miss things there. but then i have to scroll past the 3 or 4 error i get for the antenna. would be easy to overlook a new "real" error, if it also had "ANT" somewhere in it
<wolfspraul>
0 warnings in C, 0 in ERC/DRC
<wolfspraul>
same thing
<wpwrak>
yup
<wpwrak>
without -w ;)
<wolfspraul>
I'm happy the bug is foudn now, and we can fix boards, and do good on customer support.
<wolfspraul>
next - rc2 bootup bug :-)
<wpwrak>
what's the theory for that one ?
<wolfspraul>
I could only relay completely inaccurate information, so let's wait until Adam comes out with his full report.
<wolfspraul>
If I understand things correctly, the problem is already understood, and a fix is being tested or already verified. All of this needs to be double-checked properly, documented, etc.
<wpwrak>
sounds good then
<wolfspraul>
Adam is very positive the problem can be caught at its real root, maybe with another full week of work or so.
<wolfspraul>
then there are also the 2 boards I broke due to excessive power-on/off cycle testing.
<wolfspraul>
Adam wants to dig a bit deeper on those 2 boards rather than just writing them off.
<wolfspraul>
maybe we find even more fundamental ways to make the boards more robust.
<wpwrak>
heh :) yes, would be good to find out what causes this
<wolfspraul>
as you know sometimes bugs come in layers :-)
<wolfspraul>
yes and no. the testing was very excessive.
<wolfspraul>
we need to keep everything economical too.
<wolfspraul>
keep in mind that of the 20+ people that already have m1 now, nobody complained even once about this rare boot-up bug we are fixing now.
<wolfspraul>
let alone are they doing excessive cycle testig.
<wpwrak>
the problem with such things is that their frequency can change rapidly
<wolfspraul>
but if it makes Adam feel better and we are digging in this area anyway right now, let's spend the time that is needed to get it right.
<wolfspraul>
so I'd say another 1-2 weeks and we have a full report
<wpwrak>
e.g., if someone posts some reset procedure that involves brief cycling, a lot of people may suddenly start doing this
<wolfspraul>
not sure. I tested with a lab power supply, and I think the way we were cycling there is just not going to happen in real life.
<wolfspraul>
but anyway
<wolfspraul>
I have no answer now, just "making good progress" and "full report in 1-2 weeks"
<wolfspraul>
today the news is that the jtag-serial high-speed bug was found and a rework is happening
<wpwrak>
that's a good result. a beer for you and adam ;-)
<roh>
hey guys
<roh>
just came back from playing catch with a segfault in nautilus
<roh>
open a folder -> boom
<roh>
bottomline... its a svg in there.. which looks perfectly valid. and comes from inkscape. render fine in inkscape.. but segfaults in some strcmp
<roh>
annoyed me so much that i tried hunting it down... trhough librsvg.. glib2... ended up in some sse3? optimized strcmp which made no sense at all.
<wolfspraul>
roh: good to see you! :-) do you feel better? how about the DHL idea?
<wolfspraul>
I'm getting anxious to get those cases to Adam so we can speed up the whole m1 endeavor...
<roh>
then i accidentally pressed save in inkscape again and it went away. fsck. and i havent got a backup of the 'evil' file
<roh>
wolfspraul: do i need special dhl packages for that?
<roh>
eh boxes
<wolfspraul>
no I don't think so.
<wolfspraul>
I think you just go to the postoffice and ship it as a normal DHL package to Taiwan. 40 EUR, done.
<roh>
one box? or 2
<wolfspraul>
it should satisfy all our requirement - proof of export, tracability, reasonable price, speed, even implied insurance I think (won't get lost anyway)
<wolfspraul>
one
<wolfspraul>
let's not do the airmail letter thing, I'm not sure you get enough proof of export, and it's not tracable or insured either
<wolfspraul>
just put in a small package, go to the post office, and ship with dhl
<wolfspraul>
according to dhl.de should be 40 EUR up to 5 kg
<roh>
ok. can you send me a mail with the 'invoice header'? of use the same as for shipping?
<roh>
s/of/or
<roh>
does sharism have a postal address?
<wolfspraul>
invoice to put into the package?
<wolfspraul>
you can just write one invoice, and put it into the package if you like (not sure that's even needed, but it may not hurt).
<wolfspraul>
I email you the sharism address, it's in Hong Kong
<wolfspraul>
roh: let me ask Adam whether he rather has an invoice in the package or not (depends on Taiwanese customs preferences)
<roh>
ah. also a good idea
<roh>
(printed, added to package)
<roh>
havent thought about that yet...
<wolfspraul>
ok I find out whether Adam wants to have an invoice in the package or not.
<wolfspraul>
I email you the invoice address.
<wolfspraul>
our goal is to send the cases out monday/tuesday with dhl?
<wolfspraul>
I want to speed up a little, need to move towards the next bigger order already, but I first want to settle this one.
<roh>
wolfspraul: i should be able to do that (monday/tuesday)
<roh>
sure
<wolfspraul>
just emailed the address to you (only for invoice, don't ship the package to Hong Kong)
<roh>
got it.
<roh>
fsck. just sent my last money to the finanzamt. and it wasnt even on time. lets hope for the best
<roh>
n8
<xiangfu>
the build is complete , the .ubi file is 500M. we need remove some packages from config.full_system
<xiangfu>
nanonote-example-files not included
<kyak>
xiangfu: cool. What are the failing packages?
<kyak>
is it the release image?
<xiangfu>
no not release image, for now , climm, and plplot-* not compile.
<xiangfu>
dvdk: ben nanonote have 2GB nand. 512M for rootfs. 1.5 for data partition.
<dvdk>
why not change it to: 1M for rootfs/1M for data partition?
<xiangfu>
larger partition increase the boot time.
<dvdk>
well.
<xiangfu>
512M for rootfs  1.5G for data partition
<dvdk>
starting to selectively exclude software seems like a bad idea to me.
<dvdk>
also, if there's not much space on rootfs, people won't be easily able to insatll more software to it?
<dvdk>
another problem: some packages need to update/add data to rootfs when started (for 1st time)
<xiangfu>
dvdk: agree with '... install more software'
<dvdk>
like fbterm (defoma?), or gforth (generating gforth.fi).
<dvdk>
are we sure that such packages still have enough space to run?
<dvdk>
then maybe openwrt has support to install sw to another partition than the rootfs?
<dvdk>
(maybe should preconfigure opkg to just do that?)
<kyak>
actually, opkg is capable of installing the software in another root.. i use it like this to install packages to sd card on my router
<xiangfu>
dvdk: don't know that. need search openwrt website.
<kyak>
so people should be able to isntall packages manually to datafs
<dvdk>
then providing a default-enabled .ipk package repository would be sufficient
<dvdk>
not even manually, if repository is specificd in opkg.conf, they just have to type sth like 'opkg install emacs'
<dvdk>
how many packages might break when installing to another directory?  shared library search paths etc.?
<kyak>
right...
<kyak>
i guess the best choise would be to isntall really commonly used packages, and to make sure only 256M of rootfs is occupied. Then people have choice to install packages they need by simple opkg install ..
<dvdk>
i'd prefer to install everything available, make the rootfs larger if necessary.
<kyak>
at some point, even 2G won't be enough
<kyak>
and it will be slow as hell
<kyak>
and even no place for personal files
<wpwrak>
dvdk: that only works as long as you don't have a lot of packages. imagine a "ubunto with everything". you'd drown in things
<dvdk>
no, i think size will converge to the size of all linux sw available, then growth will slow down enormousuly
<kyak>
good point wpwrak, install all packages in ubuntu and it will eat 20Gb
<kyak>
or more, woh knows
<dvdk>
xiangfu: build still failing for me at freetype
<wpwrak>
dvdk: yes, there is definitely an upper bound *somewhere* ;-)
<dvdk>
also contains the .config i used.  this is config.minimal with gmenu2x and very few other packages added.
<dvdk>
trying another make clean
<dvdk>
and going to have breakfast in the meantime
<wpwrak>
i haven't used openwrt with packages yet (i'm now mainly on jlime). do they work well ? e.g., opkg fast, up to date repository, etc. ?
<kyak>
dvdk: do you use feeds.conf pinned to a special revision?
<dvdk>
using feeds.conf from repo.
<dvdk>
wait uploading it
<kyak>
hm, why don't use use the "latest"?
<dvdk>
uploaded
<kyak>
without @'s
<dvdk>
since that almost always breaks :)
<kyak>
nope!
<dvdk>
need to use last known good
<kyak>
anyway, 25428 was good :)
<dvdk>
also no much use having control over openwrt-xburst.git, if upstream can still break build for *everyone*
<kyak>
at least i didn't have problems with freetype
<dvdk>
mind to try my .config?
<kyak>
sure
<kyak>
meanwhile, you could try building from scratch
<dvdk>
doing just that
<dvdk>
make clean is taking for years
<kyak>
make clean still leaves crap behind
<dvdk>
then.. distclean?  takes hours
<kyak>
hm.. your PC seems out of date :)
<dvdk>
upgraded especially for the nanonote openwrt stuff :)
<kyak>
i usually do make clean, then rm -rf build_dir staging_dir
<dvdk>
amd quad, *underclocked* to not burn a hole into the mini-itx casing
<dvdk>
trying that
<kyak>
if i want to _really_ build from scratch, i do make clean, then rm -rf build_dir staging_dir dl feeds tmp
<dvdk>
still waiting for make clean
<kyak>
after that, i do make package/symlinks to recreate feeds and tmp
<kyak>
ok, making with your config now
<dvdk>
use 'script' to record?
<kyak>
wpwrak: opkg is pretty fast in openwrt, i can't complain..
<kyak>
dvdk: no, without 'script'.. should i?
<dvdk>
else we can't compare what's different?
<dvdk>
... in case it passes
<kyak>
hey, it failed on make[3] -C package/base-files compile :)
<dvdk>
is still waiting for make clean to finish :/
<kyak>
wow...
<dvdk>
is that good or bad?
<kyak>
what's your PC?
<dvdk>
kyak?
<dvdk>
uname -a
<dvdk>
Linux snail 2.6.35-25-generic #44-Ubuntu SMP Fri Jan 21 17:40:44 UTC 2011 x86_64 GNU/Linux
<kyak>
cp: cannot stat `/home/bas/build/openwrt-xburst/staging_dir/toolchain-mipsel_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/lib/libgfortran.so.*': No such file or directory
<dvdk>
no no no no no no
<kyak>
i don't have gfortran enabled
<dvdk>
yeah, need a toolchain rebuild make toolchain/clean
<dvdk>
to pick up changes in my .config
<kyak>
yup
<dvdk>
make clean finished
<dvdk>
btw running on a dmcrypt
<kyak>
dvdk: ok, doing it now.. might take some time
<dvdk>
is running rm -rf build_dir staging_dir dl feeds tmp
<kyak>
wpwrak: i think this is the target of xiangfu.. he's trying to build it all and make the release image (with all updates packages)
<dvdk>
running make package/symlinks
<dvdk>
runs 'make -j5 V=99' and is going to have breakfast now
<wpwrak>
kyak: ah, so it's in transition. good. maybe that's also the reason why dvdk likes a "fat" rootfs - packages not quite ready yet
<kyak>
wpwrak: those that are in image, are obviously ready :)
<kyak>
they can be made as "packages", too
<kyak>
have to go now, see you later!
<wpwrak>
kyak: yeah. anyway, i agree that a thin rootfs is a better start. may not be the most convenient solution for distribution development, but for users, it allows a much more efficient usage of space. it's always easier to add things you know you need than to find out what the ones you don't need are and to remove them. particularly if some are just obscure :)
<wolfspraul>
tuxbrain: we found a bug in the jtag-serial board (it was known before). it's not serious at all, the board works totally fine with the bug as well.
<wolfspraul>
those things can happen - I cannot delay shipping boards until they are perfect, otherwise we would wait forever. when is perfect anyway?
<wolfspraul>
people can either fix it themselves, or I offer to fix for people. actually if you still have all 3 boards, we can just ship you 3 fixed jtag-serial, and you return the three old ones at a convenient opportunity.
<wolfspraul>
in the meantime, that should not stop you at all from using or selling the boards you have, like I said wasting precious time waiting for 'perfect' hardware, while totally usable hardware is at hand sounds like the wrong priorities to me.
<wolfspraul>
about oshw - I personally don't care about many open hardware licenses and schemes floating around. I am pretty sure our stuff satisfies the requirements of all of them.
<wpwrak>
wolfspraul: could tuxbrain fix them himself ?
<wolfspraul>
I would not recommend that, Adam will post instructions of course.
<wolfspraul>
it's not worth the trouble actually.
<wpwrak>
even easier ;-)
<wolfspraul>
this is just a minor improvement, tuxbrain - keep in mind that the jtag-serial boards you have are performing their function just fine :-)
<wolfspraul>
they operate in full-speed instead of high-speed
<wolfspraul>
even in full-speed they are many times faster than the 150 USD xilinx cable
<wolfspraul>
meanwhile of course we are striving for perfection, and this is clearly a bug on our end (two pads are not grounded)
<wolfspraul>
so it will be fixed
<wolfspraul>
but people who have boards don't need to disrupt their work, or have their boards fixed for the heck of it, unless that makes them feel better of course.
<wolfspraul>
I will fix and replace the non-high-speed capable boards at any time, also in the future. so we can also look for convenient opportunities for this, like a congress or conference/get-together. rather than sending those tiny boards around the world now.
<wolfspraul>
anyway, I do what the paying customers want me to do. I have an improvement for them, which is good news...
<wpwrak>
wolfspraul: doesn't sound like the sort of thing you should lose any sleep over :)
<wolfspraul>
I'm not, just need to comunicate it right.
<wpwrak>
wolfspraul: well within the range of pain any early adopter ought to be willing to accept
<wolfspraul>
it was a bug/mistake on our side though, should have been caught in DRC
<wolfspraul>
oh sure, totally
<wpwrak>
yeah, communicate it right. that's good.
<wolfspraul>
and again - the early boards work just fine
<wolfspraul>
you can still reflash at 1 MiB / sec, and it's unclear whether high-speed capable boards would actually be any faster - the bottleneck can be somewhere else
<wolfspraul>
nobody even cared to compare until now, that shows you how little people seem to think that this bug is even worth looking at
<wolfspraul>
(the ones that have the full-speed only boards)
<wpwrak>
and how often do you reflash via jtag in the first place ? :)
<wolfspraul>
you can use it for development
<wolfspraul>
so you just load the fpga via jtag, never go through flash
<wolfspraul>
speed is good, so we will straighten this out
<wolfspraul>
it's a bug, it will be fixed
<wpwrak>
(load via jtag) ah, okay
<wolfspraul>
even though I am not sure with high-speed it would actually be faster, but nonetheless - it's a plain and clear bug, so it has to be fixed.
<wolfspraul>
I just want to avoid to courier boards around the world for 100 USD where the board itself costs 20 usd. that's stupid, considering the circumstances.
<wolfspraul>
so maybe we can replace them at convenient opportunities
<wolfspraul>
like I said - tuxbrain if you still have all 3 boards, I will just send 3 new ones to you, and you return the 3 old ones to me at some later time - just store now.
<wolfspraul>
one reason we liked the ft2232hq is that it can do such a high speed :-)
<wpwrak>
wolfspraul: (replace them at convenient opportunities) most likely, nobody will ask for that. by the time people would have such an opportunity, they already made their peace with the issue in one way or another
<wolfspraul>
sure we can replace them now as well. whatever people like. I just explain the bug first.
<wolfspraul>
I just hope that people don't want it fixed simply because 'a bug' was found.
<wolfspraul>
because there are many other bugs and if someone just wants to have a perfect board in front of him, maybe an open hardware project is not the best idea :-)
<wolfspraul>
then we can also wait a year and then fix all bugs that were found until then...
<wolfspraul>
maybe someone can do a speed comparison, lekernel actually has both variants he could tell us whether the high-speed capable one actually is or feels any faster
<wpwrak>
wolfspraul: (just because a bug was found) remember the various disasters at openmoko ? there were also great fears of mass returns and what not. almost nothing happened. and these were serious things. so, don't worry ;-)
<wolfspraul>
I am not worried about returns. I love to fix and improve the stuff I sold.
<wolfspraul>
if someone wants this fixed, we will fix it.
<wolfspraul>
the 'right to have this fixed' will remain with the product for the lifetime of the product. that easy.
<wpwrak>
wolfspraul: sure. but it's nicer if you don't have to :)
<wolfspraul>
I like to do service. again, if someone feels better having this fixed, I will gladly make him feel better. it's an easy way to do so :-)
<tuxbrain>
(fixing bugs) mmm or another another buzz/fix party alike :)
<wolfspraul>
this bug is far less serious
<wolfspraul>
tuxbrain: have you used the jtag-serial for reflashing already?
<wolfspraul>
do you still have all 3 boards?
<tuxbrain>
nop
<tuxbrain>
I use the tftp aproach to flash
<wpwrak>
sure. but if you have to replace those boards now, that's another 1-2 days earlier sharism's wealth runs out. so, it's good that people most likely won't care anyway.
<tuxbrain>
yes I still have all tree
<wpwrak>
tuxbrain: btw, how's the making of UBB going ? did you hear from your pcb fab yet ?
<wolfspraul>
no way, nothing runs out. very few boards are in the wild, I could run after all those people individually. it just makes no sense to take something away from someone who is perfectly happy with it.
<wolfspraul>
tuxbrain: ok. when adam has the whole thing settled, and all boards in Taipei reworked, I will ship 3 high-speed capable ones to you. you keep the other 3 until returning later.
<tuxbrain>
the last input was... we can't open that tar.gz thing, so I have to repacked to zip and resend, :/ I hope next week we can know something
<wpwrak>
tuxbrain: ;-)))
<tuxbrain>
recieved wolfspraul
<tuxbrain>
I think next time I will visit them personaly and we will save some time.
<tuxbrain_away>
see ya guys later
<wpwrak>
now .. where was i ... approximate a FET probe with whatever i have at home ...
<wolfspraul>
wpwrak: you will see me kick into really high gear, and be really happy, about two things: fixing bugs, and customer service
<wolfspraul>
yes there is always a litle "oh shit" moment attached to that, but once you overcome that and just go out and do it, it's great
<wolfspraul>
and that is not just a personal quirk, but every truly great business I've seen is doing that too
<wpwrak>
wolfspraul: (service) yeah, i've seen you hunt down a customer in the most remote corner of the world ;-)
<wolfspraul>
the buzz fix parties at OM were a really excellent idea. turn lemons into lemonade.
<wolfspraul>
and it was almost ironic. the hardest bug was the famous #1024
<wolfspraul>
and Dieter was hacking away at it in his Bavarian seclusion
<wolfspraul>
meanwhile I was under fire to produce results... and what happens
<wolfspraul>
do you know this story?
<wpwrak>
wolfspraul: (oh shit) yeah, better get it over with than to have that sword suspended over your head, growing day by day
<wolfspraul>
in the chaos of the very last day, Monday, when everybody was let go in typical Om fashion, I received an email from Dieter that he had fixed the bug
<wolfspraul>
I couldn't believe it
<wpwrak>
wolfspraul: (under fire story) no
<wpwrak>
aah, the timing. yeah :)
<wolfspraul>
my Inbox was full of all these dramas, and then there was Dieter's mail - AT THE SAME TIME! after like a full year of bug hunting.
<wolfspraul>
I still delivered the news to our big master, he he.
<wpwrak>
i guess he just shrugged :)
<wolfspraul>
I felt good leaving that day. if you can fix the toughest bugs, you are doing good.
<wpwrak>
heh :)
<wolfspraul>
everybody can 'design' stuff. many people run away cleaning up the mess they created.
<wpwrak>
dieter indeed worked magic. i think you've given up on this for good at least three times.
<wpwrak>
(run away) yeah. quick, let's make a new product :)
<wolfspraul>
yeah, it was frustrating. but dieter didn't give up and delivered.
<wpwrak>
little sean's source disappearing trick was also something quite impressive. i didn't see that coming. but even that brilliant act of sabotage couldn't stop dieter :)
<kristianpaul>
serial-jtag board bug <- _good_ you found it !, well i dont care now, even if i reflash the board 2-5 times per week as soon my Makefiles take care of all i dont mind about time
<kristianpaul>
morning btw
<wolfspraul>
kristianpaul: how many seconds/minutes do you need for a reflash?
<wolfspraul>
don't worry we'll get you a high-speed one for sure, but if it's ok with you we wait until there's a hitchhiking opportunity...
<kristianpaul>
wolfspraul: in the worst escenario up to 1 min or so, rtems binaries are small, i think lua was the bigger so far
<kristianpaul>
no problem on my side
<wolfspraul>
with the xilinx cable it's like 15 minutes :-)
<wolfspraul>
who knows why
<wolfspraul>
maybe they have much bigger problems than we have...
<kristianpaul>
Well, i must said i never measured about writing the *whole* flash, or at least the required part to make boad work
<kristianpaul>
I just flash some areas from time to time.
<kristianpaul>
You can do some fast estimatives from that if you want use the jta-serial board in laters runs for flashing
<wolfspraul>
the thing is there may be many bottlenecks, not sure full-speed/high-speed is even in the way
<wolfspraul>
but whatever it is, the ft2232hq supports high-speed and that's one reason why we chose it. a stupid bug slipped in reducing this fast chip to full-speed. that is being fixed now.
<wolfspraul>
interestingly, if our kicad process would have been better/stronger, this bug would have been found earlier for sure. that's a good sign we are on the right path.
<wolfspraul>
I mean KiCad just says it right there in the DRC report, if anybody would have looked :-)
<wpwrak>
funny that nobody did
<wolfspraul>
bad process
<wolfspraul>
there were 4 parties involved - Yanjun Luo, me, Adam, pcb/smt maker
<wolfspraul>
and between all of us, we overlooked it
<wpwrak>
were the changes that broke it made by yanjun or later in the pipeline ?
<kristianpaul>
ah kicad pointed it . damn
<wolfspraul>
it was already in the last set of files yanjun committed, I believe
<kristianpaul>
hmm hard to fix by hand..
<kristianpaul>
well, may be not just little wire around the board ;)
<wolfspraul>
yes don't do it. you risk damaging your board, for very negligible benefits.
<wolfspraul>
we will rework the ones we have in batch, then replace for anybody who wants that, and others later.
<kristianpaul>
he i will not, but i could, just done care now
<kristianpaul>
s/done/dont
<wpwrak>
wolfspraul: then we can be sure everything he does from now on will have the most pedantic DRC checking you could imagine ;-)
<kristianpaul>
DRC chaking by command line is posible right now?
<kristianpaul>
I confess i'm lasy clkining in all those buttons in kicad ide..
<wpwrak>
nowadays it actually is. haven't tried that yet, though
<wpwrak>
wolfspraul: ah, and if you're feeling bored, that --exclude-pcb-edges option would be really handy :) once this is done, we should be able to generate the complete "production" file set from a makefile. so things like me forgetting a drill file couldn't happen.
<rjeffries>
wpwrak no I do not have quote, over this weekend 12-14 Feb an engineer is reviewing the package you put together
<rjeffries>
wpwrak I expect to get his feedback and advice early next week
<rjeffries>
wpwrak a different guy who works at a place that does board design and then acts as interface to pcb fab houses in US and China
<rjeffries>
wpwrak has told be he accepts gerbers, the pcb fab will panelize, says we need to decide on space betwwn pcbs
<rjeffries>
wpwrak I have told him width dimension is critical will need to be laser cut or milled
<rjeffries>
New topic: how actively is KiCad beubg developed?
<wpwrak>
rjeffries: (space between pcbs) that should be the fab's choice. the less, the more boards you can cram on a pcb, which may bring down the unit price a little. the lower limit is defined by their machinery.
<wpwrak>
rjeffries: (kicad) activity varies a bit, but in general, people are doing stuff.
<wpwrak>
rjeffries: do it's not a madhouse like the linux kernel, but you see a commit every once in a while.
<rjeffries>
wpwrak ok. this UBB is so tiny... new thought" I wonder if any device other than Ben may (for hacker) be able yp use UBB?
<rjeffries>
wpwrak is KiCad the leading PCB layout tool for the open community? just curious is all
<wpwrak>
maybe, if it has an 8:10-card-compatible slot, there is enough clearance for the part of the board that extends beyond the device (and the cable), and you can control the SD pins as GPIOs
<rjeffries>
tuxbrain: what progress do you have in getting UBB fabbed in Europe>
<wpwrak>
rjeffries: (kicad) there is also gEDA. gEDA is older and - was at least when i looked at it the last time - vastly inferior
<wpwrak>
rjeffries: certain free-as-in-free-beer-but-not-free-as-in-freedom EDA tools are also popular for "open" designs. in particular Eagle
<rjeffries>
wpwrak I recently purchased a Zoom H1 digital recorder. CLEVER device. it uses microSD. it simply caused some neuronal activity and I wodred what if
<rjeffries>
wpwrak I understand Eagle (for example) is failry popular, how well does KiCad compare on features
<wpwrak>
rjeffries: keep on thinking. UBB lets you do pretty much anything you can dream up :-)
<rjeffries>
the microphone digital recorder si so awesome you can not imagine it
<wpwrak>
rjeffries: (ubb) e.g., you could even construct a device that acts like a memory card but isn't. or emulate some sdio peripherals, etc. that's serious engineering, and probably a CPLD, though.
<rjeffries>
unrelated to UBB, the Zoom H1 records in .wav or MP3 (am I allowed to even SAY "MP3" here? LOL)
<wpwrak>
rjeffries: i never used eagle. if eagle has a decent autorouter or even push-router, then it would have an edge over kicad there. kicad has an external free-as-in-free-beer web-based push router, though
<rjeffries>
I was thinking that Ben might be a pretty cool portable digital audio post processing gadget for Zoom H1
<wpwrak>
rjeffries: kicad also has quite good positioning aids. so in many difficult cases, you'll find that traces just snap exactly to the place where you want them. this means that you depend less on the grid.
<rjeffries>
what is qua;ity of routing the web based Kicad tool performs? really ugly, or ok
<wpwrak>
rjeffries: e.g., if you look at the latest atben, most of the traces curving around the crystal are off-grid
<rjeffries>
back to my new Zoom toy (I bought to help with interviews for a book I am writing)
<wpwrak>
rjeffries: the web-based one is semi-automatic. so you control the quality. i only tried it briefly (i don't like its non-free nature and i like anything web-based even less), but it seemed quite decent.
<rjeffries>
on Ben is there a tool that converts .wav to ... OGG for example?
<wpwrak>
rjeffries: autorouters are generally useless. oh, kicad has one, but it's even more useless than autorouters usually are. it also has - completely useless - autoplacement.
<rjeffries>
wpwrak and for thse not very complex PCBs routing by hand is doable correct?
<wpwrak>
rjeffries: in real life, you want to know where your components go. and you probably have a few ideas about the traces as well
<wpwrak>
rjeffries: people have done multilayer boards manually. also something like the ben should be entirely feasible.
<wpwrak>
rjeffries: (wav -> ogg) sox perhaps ?
<rjeffries>
wpwrak pls don't get upset that I have not YET had time to start learning KiCad. I plan to, in due time. This is one of many balls I juggle right now
<wpwrak>
rjeffries: every great deed starts with a small first step. so now is the time for you to install it :)
<rjeffries>
Zoom H1 has a miniUSB port, but (sigh) Ben has no USB host. that would have been sweet. so...
<rjeffries>
to transfer digital audio files form Zoom H1 to Ben will require
<wpwrak>
complain to the Zoom H1 makers that you need them to provide a USB host port ;-)
<rjeffries>
moving microSD back and forth. those little cards seem fragile to me
<wpwrak>
better, organize an angry flash mobs in front of their headquarters. make friends with the military. stage a coup :-)
<rjeffries>
wpwrak you should become a full time commedian
<wpwrak>
i thought that was what i am ? (-:C
<rjeffries>
don't tempt me. but MY flash mob will be in front wolfspraul offices (a secret location) and we will burn sharism in efigy. //big smile//
<rjeffries>
anyway, on a semi-serious note, I may have stumbled across a real world use case for Ben
<rjeffries>
as a portable digital audio review (listen to the files) and possible digital audio editor
<lekernel>
rjeffries: what is your precise opinion about the Ben btw?
<rjeffries>
lekernal Good Morning Sir? ow are you today? I am fine. ;)
<rjeffries>
my opinions about everything are far form precise. I specialize in fuzzy logic.
<lekernel>
oh, and what is your fuzzy opinion then?
<rjeffries>
may I answer in a non-direct way lekernal?
<rjeffries>
you have not advised me of my rights against self incrimination, or that I have the right to have a lawyer present.
<lekernel>
well, direct answers usually result in less time wasted and I prefer them. but if all I can get is a non-direct one...
<rjeffries>
no foreplay with you I see.
<rjeffries>
ok, her is data
<lekernel>
with tech, no
<rjeffries>
I have invested time and social capitta; to explore what is needed to MAYBE manufacture say qty 1,000 of wpwrak UBB
<rjeffries>
s/her/here funny typo
<rjeffries>
lekernel however to be frank, I hope tuxbrain gets the UBB manufactured so I can buy from him
<rjeffries>
but I am learning what is involved. I know the right people, and they have given some advice
<wpwrak>
rjeffries: (flash mob in front of wolfgang's office) hmm, i wonder what the chinese government has to say about flash mobs in general ;-)
<rjeffries>
wpwrak I must censor myself. I have not visited China and would love to. I do not wish their secret police to have me on a Dangerous Persons list. I am already on lekernel s list and that is enough //grim//
<wpwrak>
(and the probe actually works ;-) now, unearthing my usb protocol analyzer ...)
<wpwrak>
kristianpaul: btw, how did the analysis if your gps bits go ?
<kristianpaul>
wpwrak: no reply yet, actually i'll send other sample in 16 bits signed format
<kristianpaul>
i think he have problems with 2 bits. well he said he also could process it..
<kristianpaul>
but 16Bit is easier for him i think
<wpwrak>
kristianpaul: seems that he's busy ...
<kristianpaul>
wpwrak: yes, phd student..
<kristianpaul>
I'm working in a bloating tool to make it easy for him, is simple, i think i'll finish it tomorrow
<wpwrak>
kristianpaul: too much partying/conferences (the former is when you come to work with a hangover, the latter is when you come from work with a hangover) then, perhaps
<kyak>
wpwrak: but there is that "click" sound and feeling when i insert it
<kyak>
like it is lockes mechnically
<kyak>
*locked
<wpwrak>
kyak: that's just the ejection mechanism. i don't think it adds significantly to the force needed to pull the card out. the main resistance is probably the friction of the contacts.
<kyak>
ok... that's a pity
<kyak>
wpwrak: speaking about other hardware issues, i have soem dust under the LCD glass
<wpwrak>
kyak: note that digi-key have mis-categorized it. it's not push/pull but has a lid.
<kyak>
wpwrak: ah, it's not for me anyway :) i don't have soldering skillls
<kyak>
(if you mean to use this holder instead of default one from Ben)
<wpwrak>
kyak: no, you couldn't use this one inside the ben, because the lid opens in the Z direction. but it could be something to consider for future devices.
<rjeffries>
good afternoon form sunny California, USA
<kristianpaul>
good evening here
<kristianpaul>
brb
<kristianpaul>
finally got how easy is to copy from one gnu screen to other
<rjeffries>
hpwdy people
<rjeffries>
s/hpwgy/Howdy!
<wolfspraul>
wpwrak: you hit a very good point about the testing. the price could come down by 30% or more if he leaves out that 'electric testing'.
<wolfspraul>
but there is a catch... and it depends on the production process and how that factory handles such small orders internally.
<wolfspraul>
if david wants to do this, 100% he has to visit the factory first and talk to them about it and what the 'testing' exactly means, and what he has to expect if he cuts it.
<wolfspraul>
Howard from funcube dongle is sharing his production experience in very nice ways, it's aggregated in the qi planet
<wpwrak>
wolfspraul: yeah. in the case of ubb, it seems difficult to imagine a common failure more that would really matter, though. e.g., if the via makes no contact, the board works anyway. if broken traces are a common enough occurrence for generate a significant failure rate in this board, then they'd be out of business already ;)
<wolfspraul>
"I found an exceptional number of PCB faults too on these latest boards which is very disappointing. About half a dozen breaks in tracks that must have been caused by faulty photographics when looked at under the microcscope. Unless youve seen them before, debugging these is a very lengthy process often with numerous blind alleys."
<wpwrak>
s/more/mode/
<wolfspraul>
wpwrak: yes, fine. but - visit the factory to double check what exactly the 'testing' is here, and what to expect if one cuts it, IS A MUST.
<wolfspraul>
otherwise David may experience a very hard landing on his first flight :-)
<wolfspraul>
I'm just saying...
<wolfspraul>
in many cases what you pay for is actually the testing effort. the raw materials just cost pennies.
<wolfspraul>
so going into that is the right way definitely, but to avoid infinite pain it needs to be done in a controlled way.
<wpwrak>
yeah, testing tends to be pricy. at 4pcb, in the order of 20-30%, as you said
<wolfspraul>
that's because your yield will go up
<wolfspraul>
a lot!
<wolfspraul>
(or go down, never understood the grammar of 'yield')
<wolfspraul>
everybody is open about it, this is not about ripping off people
<wpwrak>
theirs goes down ;-)
<wolfspraul>
you just need to realize it takes a lot of fine-tuning to move the testing to the 'perfect' spot, for every application
<wolfspraul>
that's the downside of standardized components and processes
<wolfspraul>
for those small runs and small boards, sometimes the pcb manufacturer will make twice as many as ordered, then throw away heavily and aggressively
<wolfspraul>
because that's the most economical way to achieve results for such small runs on their end
<wpwrak>
but yes, you're making a good point. it's just in the case of this blood-simple board that i don't see much of a risk. i mean, if there are obvious flaws, it should be possible to return a charge also without testing. and it's hard to introduce non-obvious flaws in this board :)
<wolfspraul>
if you want to cut out testing, they can dump that whole pile of 'boards' to you :-)
<wolfspraul>
ok, my advice is recorded
<wolfspraul>
david can try :-)
<wolfspraul>
for sure the price will go down without testing, he he
<wolfspraul>
later you will know why it went down...
<wpwrak>
;-)
<roh>
hm. i though the ubb is just 'a strip of pcb with some traces
<roh>
not much there to test
<wpwrak>
the small copper-to-edge distance could cause problems. but you'd be able to see them. the only non-visible problem could be hairline cracks in the traces.
<wpwrak>
(well, there's the potential of the via not connecting. but the via is a luxury item anyway. i included it mainly because i can't imagine you'd find a pcb fab that would give you a discount for a via-less board. well, unless they're really a garage shop. but then, they'd fail miserably with the mechanical tolerance.
<wolfspraul>
roh: ok let's just think this way. pcb manufacturing is a cut-throat low margin business.
<wolfspraul>
just look at how we are comparing a vs b
<wolfspraul>
we think of it like a totally exchangable job
<wolfspraul>
but if the industry is like that - why is there a 30% component in the price that is 'not doing much'?
<wpwrak>
wolfspraul: apart from the testing, what's your opinion on bundling/kit size ?
<wolfspraul>
maybe you should open a pcb manufacturing shop and just always leave it out? you could attract lots of orders probably?
<wolfspraul>
wpwrak: haven't thought about the rest yet. just the 'leave out testing' jumped into my eye and I knew he could indeed save a lot with that, but it's also very dangerous.
<wpwrak>
wolfspraul: (30%) well, it's 30% for something like UBB but also 30% for something like a GTA02. there's a bit of a difference between the two in terms of potential failures - and magnitude of consequences :)
<roh>
wolfspraul: sure. but if i can get stuff for seemingly 1E-1.20E a piece at a 100 pcs order in europe.. cant be that bad if one doesnt use the cheapest suppier
<roh>
+l
<wolfspraul>
wpwrak: yes and no. remember you are talking to an existing pcb manufacturer. do you really think they can afford to leave a big fat but unnecessary testing margin in there?
<wolfspraul>
I'm all for removing it, I'm just saying "go to the factory first and find out what it really is"
<wpwrak>
wolfspraul: it's not unnecessary. what i'm saying is that UBB is just extremely low-risk.
<wolfspraul>
and if that's not worth it for you (because of your time investment), then leave testing in
<wpwrak>
wolfspraul: a) no inner layers. b) no vias that matter. c) very small number of traces.
<wolfspraul>
roh: 30% in that industry is huge. they have thought about how to reduce the testing effort many times longer than us here.
<wpwrak>
wolfspraul: if each trace has a probablility of 0.1% of failing, you'd have >99% yield with UBB while, say, a GTA02 would be close to 0%. that's where the difference is.
<roh>
wolfspraul: i am fully with you on something with vias or chips.
<wpwrak>
wolfspraul: also, if you build a GTA02, you'd find out after SMT. so you don't only use the PCB, but also all the components and the SMT process cost. totally different cost structure.
<roh>
this is a adapter.. i think visual inspection should be fine.
<wolfspraul>
did you read what I just pasted about funcube?
<wolfspraul>
"I found an exceptional number of PCB faults too on these latest boards which is very disappointing. About half a dozen breaks in tracks that must have been caused by faulty photographics when looked at under the microcscope. Unless youve seen them before, debugging these is a very lengthy process often with numerous blind alleys."
<wpwrak>
wolfspraul: (funcube) half a dozen cracks in 120 boards ? that's 5%. how many traces per board ?
<wolfspraul>
did he leave out electric testing? not sure why he is complaining.
<wolfspraul>
the way I approach these things is that I sit down with the other side and ask what the testing actually is.
<roh>
the failrate he has is quite extreme for my taste
<wolfspraul>
and so far, every time, after this kind of conversation my reaction was "please for the love of god, continue to do this testing for me" :-)
<wolfspraul>
I think he's a quality guy and really cares about what he manufactures.
<wolfspraul>
david should not cut it blindly, he should first visit, then decide whether to cut.
<wolfspraul>
that's my only point.
<roh>
sure. for serious amounts.
<wpwrak>
actually, even with 5% failure rate (which i'd consider poor, too), you could just add one extra board to each pack of ten and still end up saving :)
<roh>
for 'ordering 100pcs' its really just 'upload to pcbpool, pay, wait 8 days'
<wolfspraul>
wpwrak: yes, then you move the testing effort to the next customer.
<wpwrak>
wolfspraul: the joy of kits ;-)
<roh>
worst case you invested 130E for something which is faulty... in the funcube case its clearly a manufacturing defect of the pcb
<wolfspraul>
so it depends on how that person views the value of his time.
<wolfspraul>
no no no. the funcube guy is just testing well.
<wolfspraul>
the more you test, the more you find.
<wpwrak>
wolfspraul: they'll have ~10-20% of failure on first try due to badly soldered cables anyway, best case
<wolfspraul>
you need to know the application to focus the testing resources in the right spots, where it matters to the end user.
<wolfspraul>
that's why sometimes it makes sense to move testing around.
<wolfspraul>
have you guys ever thought about how hard it is to test an fpga? :-)
<wolfspraul>
(unrelated to pcb...)
<wolfspraul>
I really like the funcube blog and how he reports his manufacturing experience.
<wolfspraul>
that totally vibes with my own experience, only that I don't find the time to write it up so nicely, illustrate, etc.
<wpwrak>
wolfspraul: i agree with you on the importance of testing in general. i would consider it insane to skip testing on anything major. but UBB ? you test the first ten or so yourself to see if the pcb maker has screwed up somehow, but that's about it.
<wolfspraul>
we cannot argue practical experience. David has to execute then he will have his own practical experience.
<wolfspraul>
mine is clear in this case "only cut electrical testing after visiting the pcb maker"
<wpwrak>
sure. if he opts for peace of mind, he'll keep the testing. it's like water insurance in la silla ;-)
<wpwrak>
(water damage)
<wolfspraul>
wpwrak: if he orders 100, they will make 150 or 200.
<wolfspraul>
at least
<wolfspraul>
we should not make assumptions about their production process, it will backfire. trust me.
<wolfspraul>
first ask them!
<wolfspraul>
I don't know whether this is water damage insurance in the desert, or in venice.
<wolfspraul>
I don't think the pcb makers will rip him off or see him as easy prey because he's there for the first time.
<wolfspraul>
they can sell him the product with or without 'electric testing'. to them it's a very different process, that's for sure.
<wpwrak>
wolfspraul: (la silla) it's in the atacama desert (chile). the most arid place on earth
<wolfspraul>
I figured.
<wpwrak>
was kinda obvious, eh ? ;-)
<wolfspraul>
we've exchanged our arguments, David has to pick...
<wolfspraul>
he is the risk taker anyway, we are just talking :-)
<wolfspraul>
which risk is worth taking...
<wolfspraul>
did you guys see how the MPEG LA is beating the drums to find people to create a VP8/WebM patent pool?
<wolfspraul>
I think slowly the real patent business model emerges.
<wolfspraul>
it's like a Web 3.0 service. first you open a webpage, call people to contribute patents to a pool.
<wolfspraul>
then you are building a pool, to create a license and bring 'safety' to that technology.
<wolfspraul>
the entire process and model is 100% removed from any innovation, research, development, marketing - anything actually.
<wolfspraul>
it's a purely parasitical model.
<roh>
ack.
<roh>
i my eyes its a sign we are on the right way.
<wolfspraul>
it's also impossible to stop it, at the most you can create another patent pool to tax the technology a second time.
<roh>
and somehow they got google pissed enough to be on out side for once
<wolfspraul>
they will first go after the 'big' technology where hopes are to extract more money faster.
<wolfspraul>
nah, the only way out is the 20-year protection, imho
<wolfspraul>
I checked for Ogg Theora, it appeared in 2001/2002.
<wolfspraul>
so if it can be under the radar for another 9 years it should be safe :-)
<wpwrak>
wolfspraul: in a way, if you had to find examples for "crimes against humanity", patents would fit that quite well. i mean, what's the first thing humans do in their life, besides making noise ? right, receive, process, and reuse information.
<wolfspraul>
dirac only appeared in 2008/2009, so that will take until 2028 for it to be removed as a potential target for patent parasites.
<wolfspraul>
I think this will continue, I totally cannot see enough momentum to egyptize the patent system.
<wpwrak>
(ogg) patents basically mean that innovation "bubbles" can only happen every ~20 years
<wolfspraul>
even if roh throws all the shoes he has at it :-0
<roh>
wolfspraul: i think the only thing we can do is do innovate and use, and publicly document -> publish what we do.
<wolfspraul>
definitely. i agree.
<wolfspraul>
then the clock is ticking for the parasites.
<roh>
in the best case in conjunction with out lawyers which make sure we have proof WE innovated. not somebody else.
<wolfspraul>
and they will go after the rich guys first, so I don't care.
<roh>
i dont tend for becoming rich.
<wolfspraul>
protection comes from the fact that there is not much to collect, and from the 20-year safety line.
<roh>
money is a problem if you have none.. and it is one if you have too much...
<wolfspraul>
at that level you are taxed in many ways anyway, it's just another tax.
<wolfspraul>
google shouldn't (and will not) be worried.
<wolfspraul>
a good counter strategy is also to delay legal processes as much as possible, which I believe is already happening.
<wolfspraul>
slow down means the total throughput to the parasites goes down
<roh>
classic capitalism is built on unresticted growth. earth has limited ressources and i like most people around me and dont want to fight for their ressources. thus i need to be humble at some point and stop at 'enough'.
<roh>
usually that keeps one out of line of sight with crazy ones snipering for the 'want to be greats' who stick out
<wolfspraul>
I was just laughing at the MPEG LA language.
<wolfspraul>
they really try to put a positive spin on it :-)
<wolfspraul>
wpwrak: I am thinking more about the jlime/openwrt dual booting, and partition sizes.
<wolfspraul>
is it possible to have just one 2gb partition and a folder structure like /openwrt /jlime /home
<wolfspraul>
and then chroot or something like that depending on whether openwrt or jlime are booting?
<wolfspraul>
I guess it would also imply that there is only one Linux kernel (outside of the partition), which maybe good or bad overall, not sure
<wolfspraul>
or the Linux kernel moves into the ubifs partition, I don't know whether u-boot supports ubifs
<wpwrak>
(u-boot) don't know either
<wpwrak>
(shared rootfs) i like this idea. with pivot_root, it should be relatively easy to implement such a scheme
<wpwrak>
(shared rootfs) is may also be possible to save some space by hardlinking identical files.
<rjeffries>
wpwrak: did Tuxbrain get a quote for UBB pcbs, it sounds like?
<rjeffries>
reading above it would seem so.
<rjeffries>
wolfspraul is qi-hardware list very quiet recently? I seldom get emails.
<rjeffries>
sourceforge seems to be unreacable for me right now
<wolfspraul>
wpwrak: pivot_root - how does it work?
<wolfspraul>
can you give me a few more clues? if u-boot supported ubifs, do you think we should move the Linux kernel into the rootfs?
<rjeffries>
I have read everthing I guess. nothing majorly interesting hap[edn on the list anyway, with exception of the wonderful "Letters from an engineer in Argintina.
<zrafa>
wpwrak: wolfspraul: for all the different jlime versions we use qi linux kernel, so if some shared rootfs is possible then we would use the same kernel I guess. Of course, qi-openwrt version should start to test some newer kernel, no idea why it still uses 2.6.32. Jlime has been using 2.6.34 without problems for all the beta version, and we are using 2.6.36 qi kernel with lars support to Blizzard jlime dev
<rjeffries>
is this part used on Milylist or Nanonote? LM4550B
<rjeffries>
AC ’97 Rev 2.1 Multi-Channel Audio Codec w
<wolfspraul>
zrafa: the other way round. I am not aware of any problem with the 2.6.32 based kernel currently in the openwrt images. we are trying to track upstream backfire as closely as possible, and backfire will probably stay on 2.6.32 for good.
<wolfspraul>
I remember I brought up the 'why is the Linux kernel not in the rootfs' a while ago, and some people liked it outside. forgot the reasons.
<wolfspraul>
if u-boot supports ubifs, I think it should be moved into the ubifs. maybe we can leave the separate 'flat' partition in front for people who like to switch to that scheme maybe for kernel development/debugging/testing.
<larsc>
it's simpler and faster
<wolfspraul>
I would think only marginally so because u-boot will most likely only focus on getting the Linux binary assembled and into memory, and will not deal with extensive caching, remapping/wear-leveling, etc.
<larsc>
mounting the filesystem is the biggest bottleneck right now during boot. so you don't want to do it twice
<wolfspraul>
we can leave the separate flat partition in between u-boot and the ubifs partition
<wolfspraul>
yes, but do we know how u-boot does it - or how slow it is?
<wolfspraul>
normally the codepath in something like u-boot is very different from the fs implementation in something like Linux. I would expect u-boot to implement a read-only "let's just get the few pages assembled together" type of codepath. traversing the tree, reading pages. that's all.
<larsc>
afaik you have to scan the nand to mount the ubifs, because else you won't know where to look for the data
<larsc>
the openinkpot firmware has the kernel image inside a ubifs
<wolfspraul>
maybe we do this - first we experiment how fast/slow u-boot can read and execute the Linux kernel outside of ubifs vs. inside ubifs
<wpwrak>
wolfspraul: (kernel in filesystem) not sure how ubifs does it, but jffs2 basically scans the entire nand for valid blocks. that's why mounting takes so long. the reason is that any block in nand can go bad, so you never know what you may find ...
<wolfspraul>
even if we decide to move the Linux kernel inside ubifs, we should leave a separate partition between u-boot and ubifs for people who prefer or need a flat Linux kernel
<wolfspraul>
ok but both of you are arguing that it will be slow, which we can just measure :-)
<wpwrak>
rjeffries: about 1 EUR per UBB, MOQ 500.
<wolfspraul>
I would think/hope that the way u-boot extracts kernel images out of filesystems is implemented entirely differently from a permanently running read/write filesystem in the Linux kernel.
<wolfspraul>
the 2 ways to implement/codepaths have pretty much nothing to do with each other (I hope)
<wpwrak>
wolfspraul: it all depends on how soon it finds the kernel :)
<wolfspraul>
I am sure one can write a read-only fat32 'filesystem support' in less than 500 lines of code
<larsc>
its not about the implementation its about ubis design
<wolfspraul>
wpwrak: well there are filesystem structures for that.
<wpwrak>
wolfspraul: FAT is not a NAND file system :)
<larsc>
read the link i just posted
<wolfspraul>
sure, I understand. [ubifs design]
<wolfspraul>
but all of this just tells me - I want to compare the 2 speeds
<wolfspraul>
larsc: how fast/slow is it for the openinkpot guys?
<wolfspraul>
(reading reading...)
<larsc>
5 seconds or something and their nand is smaller
<wpwrak>
wolfspraul: file systems designed for NAND live with the expectation that lots of blocks can go bad, including "super blocks" and such
<wpwrak>
wolfspraul: blow the "privileged" blocks of FAT32, and it will simply not work. different worlds.
<wolfspraul>
5 seconds for u-boot to read the Linux kernel?
<wpwrak>
wolfspraul: (fat support in 500 lines) in fact, 512 bytes ;-)
<larsc>
wolfspraul: iirc
<larsc>
ubifs is build ontop of ubi
<larsc>
and ubi uses logical eraseblocks
<wolfspraul>
that link doesn't talk about how much you can cut down/optimize the pure reading of a kernel from outside a ubifs
<larsc>
each phisycal eraseblock contains the vid header which contains the virtual eraseblock id
<wolfspraul>
I am comparing with how it is now.
<wolfspraul>
I would think that u-boot just reads, doesn't add to counters/wear-leveling, will do nothing to relocate/move a block with ecc errors, etc.
<larsc>
and since ubi only sees the virtual earseblocks you have to have the mapping between physical and virtual eraseblock before you can use ubifs
<larsc>
and thus you have to scan the whole nand
<wpwrak>
wolfspraul: the #1 optimization would be to make the nand partition with the kernel/initramfs as small as possible
<wolfspraul>
even if it would be like that, it would not be worse than the 'flat' partition we have now, which has none of these things either.
<wpwrak>
wolfspraul: the problem is that, if you need to load 2 MB from a 2 GB ubifs partition, that's about 1000 times as much work as loading 2 MB from a 2 MB partition
<wpwrak>
wolfspraul: with "normal" (non-NAND) file systems, this is not the case
<wpwrak>
you don't need to read all the data of the entire partition (only a few bytes per block), but if it's large enough, you still spend a significant amount of time
<wpwrak>
(i wonder how logfs handles this. it's supposed to do better. not sure if it's still alive, though)
<wolfspraul>
this begs for empirical verification (1000 times more work). I'll get the data...
<larsc>
well you can store the interal state on-disk so you don't have to rescan the nand during mounting
<roh>
wolfspraul: just because am sitting infront your cases... did you find out if i should add a printed invoice in the shipment?
<larsc>
thats what for example yaffs2 does
<wolfspraul>
Adam wants to call DHL. if you have no answer by the time you are ready to ship it, ship without invoice.
<roh>
ok
<wolfspraul>
just get that stuff on the way, invoice to me (email), I pay, etc.
<roh>
i'll add a 'lieferschein' then
<larsc>
but you have to assume that the nand does not go bad between shutdown and boot
<wpwrak>
larsc: yeah. tricky :)
<wolfspraul>
do we not assume this in the current flat partition?