+1 Hardware revision stored in EEPROM

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

+1 Hardware revision stored in EEPROM

Ron K. Jeffries
Rask Ingemann Lambertsen <[hidden email]>
wrote:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Or we could have a serial/I2C EEPROM. It would allow much
  more fine grained board revision information, and as hardware
  fixes are applied (orhardware bugs are discovered...)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
yes, yes and YES! from a former life, having field
traceability of exact hardware revision is vital.


---
Ron K. Jeffries
http://identi.ca/ronkjeffries
(I'm also on Twitter, but prefer Geeky, FOSSy character of identi.ca)

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: +1 Hardware revision stored in EEPROM

AlvieBoy
Ron K. Jeffries wrote:

> Rask Ingemann Lambertsen <[hidden email]>
> wrote:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   Or we could have a serial/I2C EEPROM. It would allow much
>   more fine grained board revision information, and as hardware
>   fixes are applied (orhardware bugs are discovered...)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> yes, yes and YES! from a former life, having field
> traceability of exact hardware revision is vital.
>

I must confess I agree in priciple.... but this presents some other problems - it has to be programmed either before or after assembly.

And we do not use most of CPU pins, so we can use them just for now. Those do not require programming.

Unless we can find other good reason to put a SPI flash in there.

Álvaro

>
> ---
> Ron K. Jeffries
> http://identi.ca/ronkjeffries
> (I'm also on Twitter, but prefer Geeky, FOSSy character of identi.ca)
>
> _______________________________________________
> gta02-core mailing list
> [hidden email]
> https://lists.openmoko.org/mailman/listinfo/gta02-core

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: +1 Hardware revision stored in EEPROM

Werner Almesberger
?lvaro Lopes wrote:
> I must confess I agree in priciple.... but this presents some other
> problems - it has to be programmed either before or after assembly.

In the future, when we hopefully add an MPU, that won't be a separate
issue - the MPU needs to be pre-programmed anyway, which can happen
in-circuit, before SMT, or even at the MPU-maker's factory.

Also, if we take the IDBG design, then updates can be made afterwards
anytime over USB (with DFU). Board revision data could be separated
from MPU firmware by using a different "DFU partition", similar to
how things are done with DFU and u-boot on the Neo.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

Dave Ball
In reply to this post by AlvieBoy
Álvaro Lopes wrote:
> I must confess I agree in priciple.... but this presents some other problems - it has to be programmed either before or after assembly.
>
> And we do not use most of CPU pins, so we can use them just for now.

I agree.  I personally like having real HW revision detection so it's
easy to change the board revision if/when mods are made to each of the
prototypes with solder blobs, and visually confirm the revision.

Maybe we should move it to GPA17/18 to avoid the EINTs, but we only
really gain if we end up using those EINTs for something else...

Freeing up the camera port for IO might be nice, but I think I'd rather
leave those lines as they are in gta02.  Less mistakes for us to make!

I've not dug into the datasheet, but would doing something with gpa0-8
be less risky?


Dave

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

Werner Almesberger
Dave Ball wrote:
> I've not dug into the datasheet, but would doing something with gpa0-8
> be less risky?

GPAx don't have an internal pull-down, so you need to have a pair
of external resistors, one for "0" and one for "1". With the other
GPIOs, you only need one (small) external resistor.

I think the revision logic we used at Openmoko is a bit inefficient,
with a pair of resistors for each GPIO. If there's only a single
small resistor, then the logic could work as follows:

        gpio_direction_input(xxx);
        s3c2410_gpio_pullup(xxx, 1);
        udelay(10);
        if (gpio_get_value(xxx)) {
                s3c2410_gpio_pullup(xxx, 0);
                return 1;
        } else {
                return 0;
        }

Of course, if we want to go to a more flexible solution in the future
anyway, then there isn't so much use in designing sophisticated board
variant selection for gta02-core. In fact, the 3 bits for the variant
code, would almost be a serial number ;-)

(I'm actually not quite sure why we have that two resistor setup in
GTA02. Might be that this was first planned for GPA and then moved to
other GPIOs. In any case, even GTA02v0 already had them on GPGx.)

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

Werner Almesberger
I wrote:
> I think the revision logic we used at Openmoko is a bit inefficient,

Argh. Please ignore all the nonsense I wrote. I confused the NAND
configuration block (GPG13-15, NCON) with the revision logic.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

Rask Ingemann Lambertsen-2
In reply to this post by Dave Ball
On Wed, Aug 26, 2009 at 09:19:31PM +0100, Dave Ball wrote:
> Álvaro Lopes wrote:
> > I must confess I agree in priciple.... but this presents some other problems - it has to be programmed either before or after assembly.
> >
> > And we do not use most of CPU pins, so we can use them just for now.
>
> I agree.  I personally like having real HW revision detection so it's
> easy to change the board revision if/when mods are made to each of the
> prototypes with solder blobs, and visually confirm the revision.

   How about using the analog inputs ANx instead? We can encode several bits
per pin that way. Some of the SMD packages are large enough that resistor
values are printed on them.

> Maybe we should move it to GPA17/18 to avoid the EINTs, but we only
> really gain if we end up using those EINTs for something else...
[...]
> I've not dug into the datasheet, but would doing something with gpa0-8
> be less risky?

   From the datasheet: "Port A(GPA): 25-output port".

> Freeing up the camera port for IO might be nice, but I think I'd rather
> leave those lines as they are in gta02.  Less mistakes for us to make!

   Then the gta02-core will be completely uninteresting for hardware
hackers. Notice how few DIY hardware projects have been made for the GTA01
(after two years) or the GTA02 (after one year) - really just Werner's IDBG.
That's simply because they offer so little in the way of interfacing
hardware addons. This is a mistake I would like gta02-core to avoid.

   Also, if we don't have anywhere to connect hardware addons, we also miss
one means of prototyping the next round of hardware developments. You can
use WLAN over SPI in gta02-core as an example. Using a GTA02 to prototype
WLAN over SPI came to the rescue when Werner couldn't get the prototype
board to work[1]. The spare SPI on the debug connector came in handy.[2]

[1] https://lists.openmoko.org/pipermail/openmoko-kernel/2008-August/004626.html
[2] https://lists.openmoko.org/pipermail/openmoko-kernel/2008-September/004922.html

   For an example of the problems DIYers are facing with the GTA02, at least
two people have looked into adding a camera to a GTA02[3] and half a year
later they haven't succeeded. That's disappointing considering that a 1.3
Mpix camera module costs less than $10 [4] and has a relatively simple I2C +
8-bit parallel interface.

[3] https://lists.openmoko.org/pipermail/hardware/2009-January/000942.html
[4] https://www.sparkfun.com/commerce/categories.php?c=102
--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

AlvieBoy
Rask Ingemann Lambertsen wrote:

> On Wed, Aug 26, 2009 at 09:19:31PM +0100, Dave Ball wrote:
>> Álvaro Lopes wrote:
>>> I must confess I agree in priciple.... but this presents some other problems - it has to be programmed either before or after assembly.
>>>
>>> And we do not use most of CPU pins, so we can use them just for now.
>> I agree.  I personally like having real HW revision detection so it's
>> easy to change the board revision if/when mods are made to each of the
>> prototypes with solder blobs, and visually confirm the revision.
>
>    How about using the analog inputs ANx instead? We can encode several bits
> per pin that way. Some of the SMD packages are large enough that resistor
> values are printed on them.

If we discard the lower (error-prone) bits I think we can do it that way, yes...

>> Maybe we should move it to GPA17/18 to avoid the EINTs, but we only
>> really gain if we end up using those EINTs for something else...
> [...]
>> I've not dug into the datasheet, but would doing something with gpa0-8
>> be less risky?
>
>    From the datasheet: "Port A(GPA): 25-output port".
>
>> Freeing up the camera port for IO might be nice, but I think I'd rather
>> leave those lines as they are in gta02.  Less mistakes for us to make!
>
>    Then the gta02-core will be completely uninteresting for hardware
> hackers. Notice how few DIY hardware projects have been made for the GTA01
> (after two years) or the GTA02 (after one year) - really just Werner's IDBG.
> That's simply because they offer so little in the way of interfacing
> hardware addons. This is a mistake I would like gta02-core to avoid.

Understood, and agreed.

>    For an example of the problems DIYers are facing with the GTA02, at least
> two people have looked into adding a camera to a GTA02[3] and half a year
> later they haven't succeeded. That's disappointing considering that a 1.3
> Mpix camera module costs less than $10 [4] and has a relatively simple I2C +
> 8-bit parallel interface.

I wonder if we should get all unused pins in some FPC connector.... cost would not be so high, would it ?

Álvaro


_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

Werner Almesberger
In reply to this post by Rask Ingemann Lambertsen-2
Rask Ingemann Lambertsen wrote:
>    Then the gta02-core will be completely uninteresting for hardware
> hackers.

Naw, gta02-core is all about hardware hacking, just at a different
level ;-)

But please bear in mind that the number of gta02-core devices we'll
ever make will be tiny. Sean promised 20 parts kits and SMT yield
will be low. Even if everything else perfect, there are always a few
boards that end up completely broken because of some subtle setup
problems. So perhaps we'll have as few as 10 working boards in the
end, even assuming that the design is flawless.

But gta02-core isn't supposed to be the end but a beginning. The
sooner we get this done, the sooner we can look for ways to make the
device we crave, and in serious numbers.

Also, I think the debug interface is beyond simple corrections. If I
wanted to add DIY peripherals, the first thing I'd expect is a
connector I can actually connect to, without having to make my own
FPC and/or interfacing to an ultra-fine-pitch socket. (Even
finding an FPC that makes a straight 1:1 connection seems to be
difficult. 39 conductors and 0.3 mm pitch aren't very common.)

By the way, there seems to be something strange with the path your
mails take. Very often, they arrive with a data that's many hours is
not days before the time they arrive. If one orders mails by date,
that makes it very easy to miss them, because there can be dozens of
already read mails that have arrived after your brand-new mail.

I put an example below. (That one lagged just a few hours, but that
already put it some 30 mails behind "current".)

- Werner

---------------------------------- cut here -----------------------------------

Return-Path: <[hidden email]>
Received: from mail.openmoko.org ([unix socket])
        by mail.openmoko.org (Cyrus v2.1.18-IPv6-Debian-2.1.18-5.1) with LMTP;
        Thu, 27 Aug 2009 21:00:10 +0200
X-Sieve: CMU Sieve 2.2
Return-path: <[hidden email]>
Received: from sita.openmoko.org ([88.198.124.203])
        by mail.openmoko.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
        (Exim 4.63)
        (envelope-from <[hidden email]>)
        id 1MgkCf-000492-SL; Thu, 27 Aug 2009 21:00:09 +0200
Received: from localhost ([127.0.0.1] helo=sita.openmoko.org)
        by sita.openmoko.org with esmtp (Exim 4.63)
        (envelope-from <[hidden email]>)
        id 1MgkC6-00040P-Hu; Thu, 27 Aug 2009 20:59:34 +0200
Received: from [62.199.123.6] (helo=debian-gta02)
        by sita.openmoko.org with esmtp (Exim 4.63)
        (envelope-from <[hidden email]>) id 1MgkBu-0003iv-UQ
        for [hidden email]; Thu, 27 Aug 2009 20:59:32
        +0200
Received: from x1-6-00-0f-9f-c6-3e-90.localdomain (fedora-pc [192.168.0.200])
        by debian-gta02 (Postfix) with ESMTPS id 536EB3F682
        for <[hidden email]>;
        Thu, 27 Aug 2009 00:40:45 +0200 (CEST)
Received: by x1-6-00-0f-9f-c6-3e-90.localdomain (Postfix, from userid 500)
        id 99499133B; Thu, 27 Aug 2009 00:40:41 +0200 (CEST)
Date: Thu, 27 Aug 2009 00:40:41 +0200
From: Rask Ingemann Lambertsen <[hidden email]>
Cc: [hidden email]
Message-ID: <[hidden email]>
References: <[hidden email]>
        <[hidden email]>
        <[hidden email]>
        <[hidden email]>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[hidden email]>
User-Agent: Mutt/1.5.19 (2009-01-05)
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sita.openmoko.org
X-Spam-Level:
X-Spam-Status: No, score=-0.8 required=5.0 tests=AWL, BAYES_00,
        MISSING_HEADERS,
        RCVD_IN_PBL,RDNS_NONE autolearn=no version=3.2.3
Subject: Re: [PATCH] U-Boot GTA02: Always enable charger on startup

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

Werner Almesberger
In reply to this post by AlvieBoy
?lvaro Lopes wrote:
> I wonder if we should get all unused pins in some FPC connector....
> cost would not be so high, would it ?

I would go for one or more relatively small FPC connectors for which
cables are readily available. Also, it may be sufficient to just
provide the footprint, without placing the component. That way,
special-case signals could also be placed under, say, the LCM.

Also, let's not forget that this is an open design now. If it
doesn't do what _you_ want, you can change it. You'd still have to
make the PCB and go through SMT, but if this is a derivate of a
model produced in larger quantities, there may very well the
possibility of finding a place that is able to make such a variant
at a relatively small cost. This place could be a factory that
makes the "mainstream" model, or it could even be smaller shops that
specialize in just making such variants.

No need for the tail to wag the dog. Tails can now stand up for
themselves :-)

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

AlvieBoy
In reply to this post by Werner Almesberger
Werner Almesberger wrote:

> Rask Ingemann Lambertsen wrote:
>>    Then the gta02-core will be completely uninteresting for hardware
>> hackers.
>
> Naw, gta02-core is all about hardware hacking, just at a different
> level ;-)
>
> But please bear in mind that the number of gta02-core devices we'll
> ever make will be tiny. Sean promised 20 parts kits and SMT yield
> will be low. Even if everything else perfect, there are always a few
> boards that end up completely broken because of some subtle setup
> problems. So perhaps we'll have as few as 10 working boards in the
> end, even assuming that the design is flawless.

Which, of course. is not. Our confidence level is high, but the probability we missed something is quite high too.

So, expect them to not work at all. What can we do to overcome that ? Maybe allow for better refurbishing, maybe split layout in a way  you can "replace" parts
of PCB with an external design. Maybe others, if you have ideas please share.

I think we at least should try to get enough boards for those that actively contributed to its design - We cannot debug boards unless we actually have some :)
For this to happen, we need money - either our own or get some investors / supporters / sponsors so they can help us at least making and assembling the first
prototypes. I am not sure what you agreed with Sean. I also expect first board PCB/Assembly to have a very high cost (soldermasks are also expensive).

> But gta02-core isn't supposed to be the end but a beginning. The
> sooner we get this done, the sooner we can look for ways to make the
> device we crave, and in serious numbers.

This is true.

> Also, I think the debug interface is beyond simple corrections. If I
> wanted to add DIY peripherals, the first thing I'd expect is a
> connector I can actually connect to, without having to make my own
> FPC and/or interfacing to an ultra-fine-pitch socket. (Even
> finding an FPC that makes a straight 1:1 connection seems to be
> difficult. 39 conductors and 0.3 mm pitch aren't very common.)

I had some ideas a few days ago, but they are not mature yet.



_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: -1 Hardware revision stored in EEPROM

Werner Almesberger
?lvaro Lopes wrote:
> So, expect them to not work at all. What can we do to overcome that ?
> Maybe allow for better refurbishing, maybe split layout in a way  you
> can "replace" parts of PCB with an external design.

I think we have that already to a large extent: power to many subsystems
passes through 0R resistors and can thus be cut. Also many other signals
have at least one component attached that can be used to inject power or
even to cut the signal.

That's by the way a reason to go easy on "redundant" NCs and 0Rs: we may
still need them.

> For this to happen, we need money - either our own or get some investors
> / supporters / sponsors so they can help us at least making and
> assembling the first prototypes. I am not sure what you agreed with Sean.

Sean promised to give gta02-core the GTA02 component kits, but making
use of them is our own problem. I estimate the final cost per board to
be around EUR 500-1000, including all the manufacturing steps and new
components, but without shipping.

Since we don't have a sponsor, that money would have to come out of our
own pockets. Let me write about the procedure I have in mind in a
separate posting.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Debug connector FPC (Was: Hardware revision stored in EEPROM)

Rask Ingemann Lambertsen-2
In reply to this post by Werner Almesberger
On Thu, Aug 27, 2009 at 05:40:49PM -0300, Werner Almesberger wrote:

> Also, I think the debug interface is beyond simple corrections. If I
> wanted to add DIY peripherals, the first thing I'd expect is a
> connector I can actually connect to, without having to make my own
> FPC and/or interfacing to an ultra-fine-pitch socket. (Even
> finding an FPC that makes a straight 1:1 connection seems to be
> difficult. 39 conductors and 0.3 mm pitch aren't very common.)

   Actually, what exactly does the debug connector accept? Do I simply feed
it a "raw" flat cable or do I need to attach a plug to the cable?  Single
sided or double sided?  I haven't seen a debug board yet, so I'm completely
in the dark here.

--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: Debug connector FPC (Was: Hardware revision stored in EEPROM)

Werner Almesberger
Rask Ingemann Lambertsen wrote:
>    Actually, what exactly does the debug connector accept?

Here it is in all its beauty:
http://wiki.openmoko.org/wiki/Connecting_Neo1973_with_Debug_Board_v2

The FPC is single-sided, 0.3 mm pitch on the Neo side, 39 traces.
Note the lovely Y shape on the way to the debug board.

Mechanical tolerances of this critter are very tight and you get
all sorts of odd problems if it isn't perfectly right, including
intermittent failures.

Once, Openmoko had to change the source for these FPCs. It took
us two or three tries before we got acceptable cables. Some were
a tiny fraction of a millimeter too narrow on the debug board
side. Much fun was had before we figured out that one.

It's also quite common that the Neo side of the cable isn't right,
although this surprisingly rarely causes problems.

I tried for more than a year to kill this spawn of hell at
Openmoko, in the end even "underground". Alas, GTA03 died a few
days too early for the conspiracy to sneak IDBG into the design to
bear fruits.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: Debug connector FPC

Rask Ingemann Lambertsen-2
On Mon, Aug 31, 2009 at 11:59:53PM -0300, Werner Almesberger wrote:
> Rask Ingemann Lambertsen wrote:
> >    Actually, what exactly does the debug connector accept?
>
> Here it is in all its beauty:
> http://wiki.openmoko.org/wiki/Connecting_Neo1973_with_Debug_Board_v2
>
> The FPC is single-sided, 0.3 mm pitch on the Neo side, 39 traces.
> Note the lovely Y shape on the way to the debug board.

   I would merely use it to save on the soldering on the Neo. I'd solder
onto the "debug board" end of the cable, so I'd not need the Y shape.
Without the Y shape, it looks like a standard etch+slit or slit+etch job on
plastic foil with copper on one side.

--
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core
Reply | Threaded
Open this post in threaded view
|

Re: Debug connector FPC

Werner Almesberger
Rask Ingemann Lambertsen wrote:
>    I would merely use it to save on the soldering on the Neo. I'd solder
> onto the "debug board" end of the cable, so I'd not need the Y shape.
> Without the Y shape, it looks like a standard etch+slit or slit+etch job on
> plastic foil with copper on one side.

The pattern at the end is a little complex:
http://people.openmoko.org/werner/fpc-gta.jpg

I think the main difficulty would be the fine structures and getting
something rigid enough that you can properly insert it.

- Werner

_______________________________________________
gta02-core mailing list
[hidden email]
https://lists.openmoko.org/mailman/listinfo/gta02-core