follow-up re system software

Wolfgang Spraul wolfgang at qi-hardware.com
Fri Nov 20 06:17:49 EST 2009


Rafael,

> I'm really interested about what you said for Design Verification and
> production testing with Linux, i think is a great step in that way, as
> most of the manufacturers use propietary software to do it.

What should the value of open software during hardware development, for
design verification or production testing be?
Naturally the manufacturers develop this 'in-house' and it is the main
reason that production cannot just go from one factory to another.

At Openmoko, we had all software open. The most advanced was the
gta03-test-suite at
http://git.openmoko.org/?p=gta03-test-suite.git;a=tree

Depending on the stage of development/production, the requirements for
the testing software are very different. I am not sure a 'one-size-fits-all'
is the right approach.
During development, prototypes are often hand-wired and the HW engineer just
wants to toggle some GPIOs or run extremely simple routines. Many of these
things are just done once before moving to the next step.
Then you move to a more formal 'design verification' then later production
testing. Production testing is continuously tweaked, to optimize valuable
testing time (counted in minutes and seconds) so that it can really find
problems on the line. It's a difficult beast to open up.

Actually something like Bas' microkernel may be helpful in the early stages,
the less code you are dealing with initially the better.
Chris Hall used a lot of Forth routines for the WikiReader production testing
(up on the WikiReader source repository), but I'm not sure many people would
be motivated to first learn Forth. If you are, you may check that out as well...

Our current problems are at a higher level still, see Carlos' KiCad wishlist
yesterday. We first need to keep the tools to do the electrical design open,
before worrying about production testing.
One thing we plan to do is to publish the factory assembly and testing document
for the NanoNotes (we own the copyrights for large parts of it, and are in the
process of re-writing the rest). The document is in Chinese currently, so after
publication we need to translate it into English.
Then we have some sort of storyline to which we can tailor Linux-based production
testing software and scripts.

If you are interested, check out the gta03-test-suite, and I can try to speed up
work on our production testing document.
Wolfgang

On Fri, Nov 20, 2009 at 11:41:07AM +0100, Rafael Campos wrote:
> Wolfgang,
> 
> On Fri, Nov 20, 2009 at 11:21 AM, Wolfgang Spraul
> <wolfgang at qi-hardware.com> wrote:
> > Rafael,
> >
> >> Really good words, but as i see in the OpenMoko project, the people is
> >> happy if we found a software workaround, but it's happier if we found
> >> a hardware solution that could apply to this design ;)
> >> I hope to have both of them.
> >
> > Absolutely! We are 100% pumped to make the hiquest quality device, both in
> > hardware and software. No worries. I very much appreciate Ron's comments,
> > he always finds our weak spots and calmly reminds us to do better.
> >
> > If you ask around, everybody who knows me knows I like to get the toughest
> > news, the one with the biggest crap, out first. I get this question regularly,
> > before at Openmoko and now at Qi "Wolfgang, look this here is totally broken,
> > can we publicly say that?". And even though it's painful, for me as well,
> > my answer is always "Yes! Mail it to the list, get it out.".
> > That's the nature of an open product, and I am very happy to be part of one.
> >
> > I actually had a 3-hour meeting with our manufacturer today, and we spoke
> > about NAND and microSD testing at length.
> > They are doing all design verification and production testing with a
> > MicroC/OS-II. The NAND tests involve 2-4 days (!) of around-the-clock read
> > and write stress testing, so do the microSD tests. The advantage of working
> > with a high-volume manufacturer. All of this stuff passes.
> >
> > Now, in an ideal world we would like to use our own Linux/OpenWrt software
> > for design verification and production testing as well. We did that at
> > Openmoko, and there is still some good stuff at git.openmoko.org.
> > One day we get back there.
> > But right now we trust the manufacturer to hammer the device, and test it.
> >
> > So with the MicroC/OS-II kernel there is no problem.
> > With our current 2.6.31 Linux kernel there is (only in some specific cases
> > however, see Mirko Vogt's mail).
> > We will find out what's going on, and get it fixed. It's not a hardware bug,
> > I think (without excluding that there aren't things that could be improved on the
> > 'hardware' side as well).
> >
> > Hopes this explains a bit better what's going on...
> > Wolfgang
> >
> Than you very much for a really good explanation. I love the Openess
> of Qi-hardware :)
> 
> I'm getting back to the scene since a small break (since September),
> and i started to read e-mails.
> 
> I'm really interested about what you said for Design Verification and
> production testing with Linux, i think is a great step in that way, as
> most of the manufacturers use propietary software to do it.
> 
> > On Fri, Nov 20, 2009 at 09:17:20AM +0100, Rafael Campos wrote:
> >> Wolfgang,
> >>
> >> On Fri, Nov 20, 2009 at 2:44 AM, Wolfgang Spraul
> >> <wolfgang at qi-hardware.com> wrote:
> >> > Ron,
> >> >
> >> >> Is that issue considered a show stopper? until one understands if the
> >> >> root cause is hardware or software, one could argue it as being STOP
> >> >> SHIP severity.
> >> >
> >> > No, not a show stopper.
> >> > Almost the same hardware design as ours has shipped over 60,000 units already.
> >> > If there would be a serious microSD problem it would have been found.
> >> > What that means is that there is at least a workaround to the problem.
> >> > Also, I vaguely recall that we have not seen this issue when we started to
> >> > work with the original 2.6.24.3 kernel, but only after we cleaned up the
> >> > sources and up-leveled to 2.6.31.
> >> > All hardware ships with bugs. Many times you can even argue what is a hardware
> >> > bug and what a software bug. The lowest levels of software routinely have to
> >> > 'cover up' / 'workaround' hardware bugs, making the hardware look 'stable'
> >> > for higher levels of software.
> >> >
> >> > For this particular problem, I am confident enough that we will find a
> >> > software workaround in the end to not make it a STOP SHIP severity.
> >> > Otherwise we would never ship anything, and you would happily use lots of
> >> > other consumer electronics with bugs inside you just don't know about.
> >> >
> >> > However, I am clearly aware of this bug, and hopefully we get to the bottom
> >> > of it soon... The beauty of open - everything is known :-)
> >> > Wolfgang
> >> >
> >> > On Thu, Nov 19, 2009 at 11:30:13AM -0800, Ron K. Jeffries wrote:
> >> >> Mirko wrote:
> >> >>
> >> >> http://wiki.qi-hardware.com/wiki/Known_issues - if you don't think it's
> >> >> up-to-date feel free helping to make it up to date :)
> >> >> ~~~~~~~~~~~~~~~~~~~~~~
> >> >>
> >> >> Is that issue considered a show stopper? until one understands if the
> >> >> root cause is hardware or software, one could argue it as being STOP
> >> >> SHIP severity.
> >> >>
> >> >>
> >> >> What I was asking is where do we find a list of prioritized bugs with indication
> >> >> of which ones are being actively worked?
> >> >>
> >> >> with respect,
> >> >>
> >> >> ---
> >> >> Ron K. Jeffries
> >> >>
> >> >> _______________________________________________
> >> >> Qi Developer Mailing List
> >> >> Mail to list (members only): developer at lists.qi-hardware.com
> >> >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer
> >> >
> >> > _______________________________________________
> >> > Qi Developer Mailing List
> >> > Mail to list (members only): developer at lists.qi-hardware.com
> >> > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer
> >> >
> >>
> >> Really good words, but as i see in the OpenMoko project, the people is
> >> happy if we found a software workaround, but it's happier if we found
> >> a hardware solution that could apply to this design ;)
> >>
> >> I hope to have both of them.
> >>
> >> Regards
> >>
> >> --
> >> ___________
> >> Rafael Campos
> >> o0 Methril 0o
> >> http://openblog.methril.net/
> >>
> >> _______________________________________________
> >> Qi Developer Mailing List
> >> Mail to list (members only): developer at lists.qi-hardware.com
> >> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer
> >
> > _______________________________________________
> > Qi Developer Mailing List
> > Mail to list (members only): developer at lists.qi-hardware.com
> > Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer
> >
> 
> 
> 
> -- 
> ___________
> Rafael Campos
> o0 Methril 0o
> http://openblog.methril.net/
> 
> _______________________________________________
> Qi Developer Mailing List
> Mail to list (members only): developer at lists.qi-hardware.com
> Subscribe or Unsubscribe: http://lists.qi-hardware.com/cgi-bin/mailman/listinfo/developer




More information about the discussion mailing list


interactive