GTA04 Block V4
Wolfgang Spraul
wolfgang at openmoko.com
Wed Aug 13 04:49:04 CEST 2008
Werner,
should we change your job title to 'novelist' :-)
I think many people like the idea of the second ARM core.
If you have any chips in mind, can you add them to the 'Chip Scouting'
section of MokoForesight?
http://wiki.openmoko.org/wiki/MokoForesight
Thanks,
Wolfgang
On Aug 13, 2008, at 5:03 AM, Werner Almesberger wrote:
> Andy Green wrote:
>> This was actively rejected by folks in .tw last time this was live,
>> but
>> I expect we get another chance when it comes up again.
>
> The brief history of this:
>
> - we started with the observation that we always ended up with bits
> and pieces that needed discrete logic and/or board revisions, and
> that could be solved quickly and/or more elegantly if we had a
> separate MPU that runs in parallel to the main CPU or when the main
> CPU doesn't.
>
> In particular, PMU setup and various other power management issues
> would be in this domain. We didn't have a specific "must have"
> scenario, though, only the general observation that one will
> certainly develop over time.
>
> - the search for a suitable MPU quickly centered on the TI MSP430
> family, which are very low-power 16 bit microcontrollers.
>
> - since the general idea was to have the MPU ready to take care of
> problems wherever they may pop up, a fairly large (and expensive)
> chip from that family was chosen as the candidate.
>
> It seems that we didn't communicate this concept properly, so the
> MPU was considered by many as something that would also eat lots
> of space and be really expensive in the final product.
>
> - in parallel, we also considered ways for simplifying and improving
> our "unbrickability" concept. In GTA01, the only unbrickability
> feature was the debug board. That debug board has had an enormous
> cost on terms of engineering effort and it still isn't something
> we'd consider "nice". A brief overview of the debug board story:
>
> - the debugv2 design and prototype went quite smoothly, but then
> we discovered stray EEPROM failures, which eventually (after
> weeks ? months ?) were tracked down to overly large capacitors
> causing the supply voltage to drop just at the wrong moment
> during reset.
>
> - the FPC is fragile and can break when bent
>
> - the FPC connectors (both) break easily. Furthermore, they're
> only rated for 10 insertions.
>
> - the FPC often had problems fitting into the connectors, either
> being too wide (so it wouldn't go in or only if forced) or too
> narrow (so it would go in without a fight, but you had no idea
> what kind of contacts it made).
>
> - our FPC source dried up and we had to find a new one, with a
> repeat performance (just worse) of the mechanical issues. You'd
> think an FPC maker could make a cable that fits into a standard
> connector in their sleep. Well, actually, perhaps that's what
> they tried to do ...
>
> - there are suspected signal integrity issues due to the long
> unshielded cable as well
>
> - it's a large piece of external circuitry, which can alter the
> way the phone behaves electronically, thus limiting its use
> when debugging hardware problems
>
> - we then made a debugv3 board, fixing various minor issues and
> the reset problem.
>
> - for GTA02, we investigated into replacing the FPC connector
> with something mechanically less dubious, but couldn't find any
> solution we could trust to be reliable, buildable, and that
> would fit into the existing case without causing new problems.
>
> - there is talk of trying again to find a mechanically more sound
> connector for the debug board in future devices.
>
> - the debug board is full of bare contacts, eagerly waiting for
> an opportunity to short or to pick up some surge. We considered
> making a case in the debugv3 era, but abandoned the idea.
>
> - we made another attempt to give the debug board a case earlier
> this year, and this actually went to the point of having a
> design proposal and a quote for manufacturing it, but this was
> cancelled for schedule and cost reasons.
>
> - besides all the problems with the implementation of the debug
> board, the general design is quite unsuitable for a mobile
> device. (One of the original ideas was that one could carry Neo
> and debug board around as a package. Hence the USB downstream
> ports.)
>
> So the bottom line is that we have very much a love-hate
> relationship with the debug board. It's undeniably useful, it
> fits squarely with all we believe in regarding openness, but the
> implementation is fraught with problems, and many of our attempts
> to control them were abysmal failures.
>
> To mitigate the debug board issues somewhat, we added the NOR in
> GTA02, so that one could recover from mere software problems without
> requiring a debug board. The NOR has its own set of issues, namely:
>
> - it's designed to be "write-once" (at the factory, with regular
> users not expected to change it, although they can with a debug
> board or a bit of soldering skills) and it contains a complex
> piece of software, namely u-boot.
>
> This means that there's the risk that we'll fix bugs or need new
> features (e.g., if we were to change the partitioning scheme),
> which thus cannot be deployed.
>
> This has actually happened already, but fortunately none of the
> issues encountered so far were catastrophic.
>
> - the NOR chip costs money and is hard to source
>
> - it loads the memory bus, limiting our top speed for accessing
> the RAM
>
> - perhaps worst of all, it eats PCB space
>
> For GTA03, we plan to drop the NOR and to basically use the whole
> NAND just for booting, along with a more flexible write protection
> mechanism. This will mitigate or solve all of the issues above,
> but it also means that we have a major architectural constraint
> and we still haven't solved the debug board problems when
> debugging.
>
> Since not everyone has a debug board and it's messy to attach, this
> also limits our ability to obtain detailed bug reports from users
> who wouldn't consider themselves kernel hackers.
>
> Given all the problems with the debug board, we came up with the
> idea of simply removing all the unnecessary parts and integrating
> it into the phone.
>
> This would solve almost all of the problems of the debug board and
> it would also reduce the need for having a hardware-protected
> alternate boot path for unbricking.
>
> This idea went through two iterations and in the end we had it down
> to just needing the FT2232 and a bit of glue logic. However, also
> this drew flak:
>
> - the FT2232 is fairly large, something our hardware team obviously
> strongly resents
>
> - we'd need another USB connector, which may confuse users, is
> hated by design purists, and may also violate one of the more
> obscure areas of USB OTG.
>
> - the FT2232 isn't cheap either
>
> So after some struggle, that idea was shot down as well.
>
> - during discussion about the microcontroller some discomfort was
> felt about having another CPU architecture in our system, and in
> particular one that's fairly exotic to most Linux hackers. The
> suggestion was made to just add another ARM.
>
> Now this may sound crazy, but in recent years, small ARM-based
> systems have started to enter what was previously the domain of
> small microcontroller, such as 8051, PIC, AVR, or MSP430. There
> are still clear differences, for example in power consumption, but
> they're no longer necessarily a big issue.
>
> - all that has been put aside for a while as more pressing issues in
> GTA02 and the work towards GTA03 surfaced
>
> - meanwhile, we ran into new problems (regarding PMU bringup) which
> confirmed our expectation that an MPU able to act independently
> from the CPU would be something really useful to have. So there's
> hope that we'll be able to defend the MPU better when the GTA04
> discussion is opened again.
>
> - realizing that we had two very promising enhancements that would
> also solve recurring nightmares that are as old as Openmoko itself,
> which both were shut down for cost and space reasons, the idea came
> up to actually combine the two, thus halving the perceived penalty.
>
> In addition to this, it's tempting to also try to avoid complicating
> our development environment, and make everything ARM.
>
> And this is what this ultimately is about: if we can have an MPU that
> has USB device functionality, it could act as a JTAG interface and
> serial console towards the CPU. Since we want to be able to also
> change the firmware of the MPU, it has to be unbrickable as well,
> which could be achieved by having a robust mechanism to download
> new firmware over USB.
>
> So far, we haven't found a solution that would be perfect, and there's
> still the possibility of having an MPU that only helps with low-level
> tasks, without getting involved with USB and such. But I'm hopeful
> that we'll get there, and that we can close the book on that series of
> engineering tragedies debug board and lack of MPU have already caused
> us.
>
> - Werner
>
> _______________________________________________
> hardware mailing list
> hardware at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/hardware
More information about the hardware
mailing list