*.o.cmd files that were created by the patch, which could ossibly confuse
Kbuild with intermediate module sources.
This patch is intended to replace the one you have in the Google Code
by Florian Fainelli
Email : florian@openwrt.orghttp://openwrt.org
The fdisk and mkfs was factored out into a shell function
so that it is easier to create dirfferent partition layouts.
The default case was left the same as the original script
The partitions can be specified as percentages of the
available space (after Qi reserved space has been taken out)
by providing a comma separated list of values:
e.g. 25,0,50
Which would create partitions 1 and 3 with 25% and 50%
of the usable capacity. Partitions 2 and 4 would not be
assigned.
Signed-off-by: Christopher Hall <hsw@openmoko.com>
s3c6410 defaults to all clocks up, this leads to 120mA idle current at 5V.
Gating all the unused clocks off gets us down to 76mA idle current at 533Mhz
CPU clock down to 133MHz only helps by a further ~1.5mA.
During these tests camera unit was active with no camera attached, no EDGE.
Signed-off-by: Andy Green <andy@openmoko.com>
Hello Andy,
I am in the process of making a modified 6410-partition.sh
and I wonder if there is a mistake in the VFAT partition size:
Shouldn't the "+ $REARSECTORS" in the FATSECTORS calculation
be a subtraction, otherwise the backupfs will overlap the
space reserved for Qi at the end of the SD Card.
Please look at this dif to see what I mean:
Hi Andy,
Sorry, previous patch to enable reset function of LCM is not working
stably somehow. :(
Since it's pin configuration is input. Attached patch is to set LCM
reset pin as output.
Cheers,
Matt
We can get rid of quite a few backslashes since in modern C,
consecutive strings are concatenated at compile time.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
Received: from mail.openmoko.org ([unix socket])
by mail.openmoko.org (Cyrus v2.1.18-IPv6-Debian-2.1.18-5.1) with LMTP; Sat, 07 Mar 2009 06:46:20 +0000
X-Sieve: CMU Sieve 2.2
Return-path: <openmoko-kernel-bounces@lists.openmoko.org>
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 <openmoko-kernel-bounces@lists.openmoko.org>)
id 1LfqIe-000690-LR
for andy@imap.openmoko.org; Sat, 07 Mar 2009 06:46:20 +0000
Received: from localhost ([127.0.0.1] helo=sita.openmoko.org)
by sita.openmoko.org with esmtp (Exim 4.63)
(envelope-from <openmoko-kernel-bounces@lists.openmoko.org>)
id 1LfqIA-0005iO-2x; Sat, 07 Mar 2009 07:45:50 +0100
Received: from imap.tw.openmoko.org ([59.124.115.149] helo=aakash.openmoko.org)
by sita.openmoko.org with esmtp (Exim 4.63)
(envelope-from <matt_hsu@openmoko.org>) id 1LfqI0-0005cg-Rz
for openmoko-kernel@lists.openmoko.org; Sat, 07 Mar 2009 07:45:44 +0100
Received: from [172.16.22.173] (helo=abacus-om.tw.openmoko.com
ident=Debian-exim)
by aakash.openmoko.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.63) (envelope-from <matt_hsu@openmoko.org>)
id 1LfqHA-0007Xa-Eu
for openmoko-kernel@lists.openmoko.org; Sat, 07 Mar 2009 14:45:09 +0800
Received: from matt by abacus-om.tw.openmoko.com with local (Exim 4.69)
(envelope-from <matt_hsu@openmoko.org>) id 1Lfqto-0006XS-9X
for openmoko-kernel@lists.openmoko.org; Sat, 07 Mar 2009 15:24:44 +0800
From: Matt Hsu <matt_hsu@openmoko.org>
To: openmoko-kernel@lists.openmoko.org
Date: Sat, 7 Mar 2009 15:24:42 +0800
Message-Id: <1236410684-20364-2-git-send-email-matt_hsu@openmoko.org>
X-Mailer: git-send-email 1.5.6.5
In-Reply-To: <1236410684-20364-1-git-send-email-matt_hsu@openmoko.org>
References: <1236410684-20364-1-git-send-email-matt_hsu@openmoko.org>
X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on sita.openmoko.org
X-Spam-Level:
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham
version=3.2.3
Subject: [PATCH 1/3] qi/om_3d7k: deassert LCM_RESET pin before getting kernel.
X-BeenThere: openmoko-kernel@lists.openmoko.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion regarding the OpenMoko Linux Kernel and boot loader
<openmoko-kernel.lists.openmoko.org>
List-Unsubscribe: <http://lists.openmoko.org/mailman/listinfo/openmoko-kernel>,
<mailto:openmoko-kernel-request@lists.openmoko.org?subject=unsubscribe>
List-Archive: <http://lists.openmoko.org/pipermail/openmoko-kernel>
List-Post: <mailto:openmoko-kernel@lists.openmoko.org>
List-Help: <mailto:openmoko-kernel-request@lists.openmoko.org?subject=help>
List-Subscribe: <http://lists.openmoko.org/mailman/listinfo/openmoko-kernel>,
<mailto:openmoko-kernel-request@lists.openmoko.org?subject=subscribe>
Sender: openmoko-kernel-bounces@lists.openmoko.org
Errors-To: openmoko-kernel-bounces@lists.openmoko.org
Since the reset callback function of probing jbt6k74 is
eliminated for some reasons in kernel. In order to support
both of LCM driver device, l1k002 and jbt6k74, just issue this reset in qi stage.
Signed-off-by: Matt Hsu <matt_hsu@openmoko.org>
This patch uses fdisk instead of dmesg to determine the size of
the uSD card. This should be less fragile and is much simpler
than the previous solution.
Signed-off-by: Werner Almesberger <werner@openmoko.org>
6410-partition-sd.sh didn't handle Debian, which is just like Ubuntu 7.
(Tested on "lenny". YMMV.)
Signed-off-by: Werner Almesberger <werner@openmoko.org>
There's no trailing space after the last mac address addition, it
was broken before the recent patch adding the second mac address.
Also, we don't need to add the first space by hand if it's unconditionally
added in the string afterwards.
Reported-by: Werner Almesberger <werner@openmoko.org>
Signed-off-by: Andy Green <andy@openmoko.com>
Andy,
On Tuesday 03 February 2009 18:12:50 Andy Green wrote:
> Now everything else is in place, we are able to mount
> the GTA02 "identity" partition and extract the USB Ethernet
> MAC Address from it, and add it to the kernel commandline.
>
> This causes the Ethernet gadget to use the same MAC address
> each boot, simplifying DHCP server situation. The MAC
> address in the identity partition is globally unique from
> the factory.
Because of this patch I can no longer load g_ether module with host_addr= and
dev_addr= parameters.
The module is always loaded using factory mac for HOST and random mac for DEV.
That messes up my setup a bit, as I use NetworkManager 0.7 on FreeRunner
itself (and it expects DEV mac to be the same each time).
Would it be a problem to also include g_ether.dev_addr?
Attached patch solves my problem.
Rob
