Openmoko strives for openness

Ortwin Regel ortwin at gmail.com
Thu Mar 20 00:08:05 CET 2008


What would be interesting to know: What is the next thing Openmoko
wants to do? A GTA03  Neo device with some changes in functionality
but keeping the general design? An entirely new device with possibly
other/revolutionary design goals? Multiple devices at the same time?

How about a TI OMAP3 as SoC? They seem to somewhat support open source
& Linux though I'm not sure to what extent and if they can be pushed
further in the right direction.
http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?templateId=6123&contentId=4752
http://focus.ti.com/general/docs/gencontent.tsp?contentId=36915
http://focus.ti.com/docs/prod/folders/print/omap3530.html
Pandora ( http://www.openpandora.org/ ) uses the OMAP 3530. I'd like
to see a similarly powerful, similar form factor Openmoko device.
Maybe a cooperation with the Pandora guys would be possible, adding
Bluetooth and phone functionality to it?

Putting the rootfs on an internal microSD card sounds like it would
make sense. I'd like to have a second SD slot though, that is easier
to access. Full SD would be nice for that but microSD probably more
practical in a phone.

I don't have much of a clue about these things but here is what the
boot mechanism should make possible:
The first part starting the system has to be permanent and only
flashable with some effort (debug board). It should never need a
reflash. This part has to check if the user wants to start up normally
(power button) or wants to reflash the internal memory (power + aux).
The internal memory would contain everything that can change, such as
the boot loader and the OS. Flashing needs to be possible over USB. So
what needs to change is that flashing the internal memory isn't a
function of the bootloader, which sits in internal memory, but rather
something put into a part that boots up first and can't be changed
without the debug board and thus not destroyed by a virus or software
failures. The need of a debug board for repairing messed up software
would vanish.

Ortwin


On 3/19/08, Michael Shiloh <michael at openmoko.org> wrote:
> Hi everyone,
>
> I wanted to point out to you something that has been happening quietly
> for awhile now.
>
> Often discussions start on Openmoko internal mailing lists. Suddenly we
> realize the discussion is important and that there is no reason for it
> to remain internal.
>
> There is a constant trend of moving these discussions from internal
> lists to public lists. Many Openmoko employees do this, but I'd
> particularly like to publicly thank Wolfgang Spraul for championing this
> and for setting up a culture that encourages everyone to think in these
> terms.
>
> I realize that often you, the world outside, see these discussions
> appear on the external lists and perhaps don't realize that this is a
> deliberate action on our part to hold as much discussion as possible in
> public rather than private forums.
>
> Regards,
> Michael
>
> -------- Original Message --------
> Subject: Post- GTA02
> Date: Wed, 19 Mar 2008 10:27:47 +0000
> From: Andy Green <andy at openmoko.com>
> To: openmoko-kernel at lists.openmoko.org <openmoko-kernel at lists.openmoko.org>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi folks -
>
> We had some internal talk about how to go post GTA02 and Wolfgang wants
> us to make it external.
>
> We have a choice about basing on S3C2443 or S3C6400. A lot of the info
> is confidential but not these high level things which are public domain
> on Samsung's site.
>
> S3C2443 is an 130nm incremental improvement over the 2442 in GTA02 with
> 480Mbps USB Device (not OTG) and better clock scaling. It can accept
> x16 DDR memory.
>
> S3C6400 is 90nm and has 480Mbps USB2 OTG, 667MHz max clock, some 2D
> acceleration and can accept x32 DDR memory.
>
> http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=229&partnum=S3C6400
> http://www.samsung.com/global/system/business/semiconductor/product/2007/8/21/661267ptb_s3c6400_rev15.pdf
>
> I like the 6400 better but information is a bit scarce right now and it
> can go either way.
>
> Some other concepts kicked around:
>
> - Merge the debug board function on to the phone, perhaps with internal
> micro USB used for debricking and hacking. No write-once memory.
>
> - Discard U-Boot, minimal bootloader direct to kernel
>
> - Focus on SD Card rootfs rather than internal memory
>
> - Add a small lowpower MPU like TI MPS430 to manage everything
> seamlessly when main CPU is down. Stuff like motion sensors, wake
> sources, battery management, maybe touchscreen, leds so there is an
> always-on "guiding hand" in the phone that is consistent and reliable
>
> To be clear though -- GTA02 is soon going to actually exist, and this is
> just future talk right now. But because of that, if you have any ideas
> about future arch, now is the time to throw them in and they will at
> least get the time of day.
>
> - -Andy
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
> iD8DBQFH4OqjOjLpvpq7dMoRAldNAJ4kDtEv4ktKAVdw9UlW1G9+fEUMvgCfdH1e
> s67SFaeGcz6TgckzPo1Q20g=
> =/oXX
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> OpenMoko community mailing list
> community at lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>




More information about the community mailing list