Re: wiki.openmoko.org unreachable?

2010-10-08 Thread Timo Jyrinki
2010/10/7 Joerg Reisenweber jo...@openmoko.org:
 hetzner moved irons. fs needed fsck and other service, after 2 years 'uptime'
 Central Services (aka roh, gismo) is taking care of it.
 ETA unknown yet.

Thanks for letting us know.

-Timo

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: wiki.openmoko.org unreachable?

2010-10-08 Thread urodelo
It's up again now!
Thank you
urodelo

On Fri, 08 Oct 2010 08:50:07 +0200, Timo Jyrinki timo.jyri...@gmail.com  
wrote:

 2010/10/7 Joerg Reisenweber jo...@openmoko.org:
 hetzner moved irons. fs needed fsck and other service, after 2 years  
 'uptime'
 Central Services (aka roh, gismo) is taking care of it.
 ETA unknown yet.

 Thanks for letting us know.

 -Timo


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [ANNOUNCE] qi-bootmenu-0.2

2010-10-08 Thread Treviño
Il giorno mer, 06/10/2010 alle 21.55 +0200, Marc Andre Tanner ha
scritto:
 Hi,
 
 I finally had some time to hack on qi-bootmenu the result is
 a new 0.2 release 

Cool!
However, why not using this partition policy:
 - First partition used for both bootmenu kernel and rootfs
 - Other partitions and NAND for the other distros...




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [ANNOUNCE] qi-bootmenu-0.2

2010-10-08 Thread Marc Andre Tanner
Marco Trevisan (Treviño) schrieb:
 Il giorno mer, 06/10/2010 alle 21.55 +0200, Marc Andre Tanner ha
 scritto:
 Hi,

 I finally had some time to hack on qi-bootmenu the result is
 a new 0.2 release 
 
 Cool!
 However, why not using this partition policy:
  - First partition used for both bootmenu kernel and rootfs
  - Other partitions and NAND for the other distros...

The original idea was that it should be possible to swap the SD card
and the bootmenu should still be there and work as expected.
I therefore flash it into the NAND kernel partition. You can still
have a regular distro in the NAND rootfs partition. You just need
to place the distros kernel into the /boot folder as you would do
on a SD card.

Of course nothing prevents you from adding a bootmenu partition
to your SD card. The kernel doesn't care how it is started and
just runs its initramfs. The only 'problem' which I can think of
at the moment is, that it will present itself in the menu. So
you would have the possibility of a recursive bootmenu. This could
be taken care of by a parameter on the kernel command line which is
read by the initramfs.

Marc

-- 
  Marc Andre Tanner  http://www.brain-dump.org/  GPG key: CF7D56C0

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: [ANNOUNCE] qi-bootmenu-0.2

2010-10-08 Thread Marc Andre Tanner
Radek Polak schrieb:
 On Thursday 07 October 2010 16:25:03 Marc Andre Tanner wrote:
 
 No. It's the same as in the initial release (built sometime in February)
 I am not really up to date regarding the glamo timings, is it stable?
 What are the prefered settings? If you provide a patch I can add it.
 Or better yet someone should commit it to the openmoko git repository
 then I will pick it up 'automatically'.
 
 I am using it for 2 weeks now and it's stable. You can cherry pick commit 
 from 
 my repo:
 
 http://github.com/radekp/qi.git
 
 http://github.com/radekp/qi/commit/b214400c048857e0f2156028bcd7a16397094a7d

Thanks, I have queued it up.

Marc

-- 
  Marc Andre Tanner  http://www.brain-dump.org/  GPG key: CF7D56C0

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Reminder: Open HardSoftware Event in Munich (4th/5th December) - we still have room for more topics speakers

2010-10-08 Thread Dr. H. Nikolaus Schaller
We still need some more speakers and proposals for the German Open
HardSoftware Workshop/Event that we plan for December in Munich.

Details can be found here:

http://wiki.openmoko.org/wiki/Open_HW_SW_Event/de

Please register to the specific German language mailing list to stay
up to date and discuss the agenda.

Topics are e.g. (depends on participants who organize a session or
have something to contribute):
• Openmoko
• Nanonote
• Freerunner Navigation Board v2
• BeagleBoard
• SHR
• QtMoko
• FSO
• Arduino
• OpenPandora

Note: workshop language will be German
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


Re: New Phone Project (MiniMoko) : Which functionalities ?

2010-10-08 Thread Al Johnson
On Wednesday 06 October 2010, Thomas HOCEDEZ wrote:
 Hi,
 
 As you might have read, Always Innovating (A.I.), is opened to think
 about a collaboration between them and us (Openmoko community)  to build
 a phone based on their MiniBook.
 
 This device is a MID, without phone capabilities (except VoIP). So the
 idea is to build something together on that basis.
 I don't want AT ALL to shortcut GTA04 project, which is vital for
 everyone, so the main idea would be to improve a bit the MiniBook,
 generating a lite version of the GTA04. By lite, I suggest not to
 overload the bill  motherboard with extra features that GTA04 will bring.
 
 More, The MiniBook have to stay an A.I. product, this mean, it must be
 linkable to the others as it does today.
 
 For information, MiniBook has already impressive specs :
 
 * TI http://www.ti.com cortex-A8 with 3D and video acceleration
 * 512MB (RAM) + 256MB (NAND) Memory
 * Main storage: 8GB microSD card
 * 480x320 3.5 capacitive touchscreen
 * 30fps VGA front webcam
 * Wifi 802.11 b/g/n, Bluetooth class 2.1
 * Video output HDMI HD
 * Two high-quality stereo speakers
 * Internal microphone
 * Headphone jack
 * 3-dimensional accelerometer
 * One 1500 mAh battery
 * Bi-color silver/black case
 * 64mm x 106mm x 9.3mm
 * Secured attachment of the MID into a Touch Book Table
 
 There's nothing much to improve, nothing to remove, just adding GSM/3G
 chip. Nikolaus Schaller pointed the OPTION GTM501, which is a brilliant
 little chip ! And if we use the same one, the porting of
 distros/software will be easier from one machine to another.
 
 So, the first question is : What to add for this project being
 interresting ? Those will be minimal functions (forget Wimax, 4G,  coffe
 machines or color printer ...).

GPS - I wouldn't buy without it. It's just too useful for navigation.

3 axis magnetometer - from recent experience it is sometimes very useful to 
know which way you're facing as well as where you are. 3 axis accel, gyro and 
a pressure sensor would be nice but less important.

Daylight readable screen - again from recent experience in a sunny 
environment. A transreflective screen, or one from PixelQi, would be better as 
they would cut down on the power needed for backlighting in bright 
environments. An ambient light sensor would be good to automate the backlight 
level.

Better screen resolution - at least 640x480. It really does make the screen 
more legible, and significantly broadens the number of apps that can be used 
without gui porting.

USB host mode

Standard connectors for USB host/otg/device and charging. These could be in 
place of the mini-HDMI and coax power connectors.

Given what's on the 40 pin connector an option might be to have a dockable 
module that can go either on the end of the MiniBook or inside the SmartBook. 
That would enable everything but the screen changes without changing the 
existing MiniBook design, and seems similar to the DualScreen module in design 
philosophy.

 Second question : Debian is able to run on such a device, but does
 developpers of other distributions can tell if it would be possible to
 port their on it ?

If debian can run on it there should be no problem porting to other distros. 
Similarities to the beagleboard and n900 may mean other distros can already 
work with it.

 Third question : On the basis we have a 'paper' version of the phone, is
 there anyone able to give a hand to AI for the integration of new
 components on the board or do we let AI do the major part of the job ?
 (this way, we only would be 'consultants' for them).

That probably depends on what they decide to do. On the hardware side they 
should be more than capable of implementing anything suggested above. Pick the 
right components and support may already be present either in the mainstream 
kernel or other open drivers. See the FR Navigation Board[1] for some 
examples, and n900 sensor support in the mainstream kernel for others.

 Thanks for your interest.
 
 Thomas.

[1] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community