Re: f2fs on GTA02
On 2012-12-11 02:19, Martin Jansa wrote: 3.2 kernel works pretty good https://github.com/shr-distribution/linux/tree/om-gta02/3.2/master there are branches also for 3.5 and GNUtoo is working on it. Oh, wow. That means that the wiki page http://wiki.openmoko.org/wiki/Kernel is way behind. Thanks for the pointer to the more recent stuff. -v ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: f2fs on GTA02
On 2012-12-11 13:40, Peter Viskup wrote: would be great to see how it performs. I would like to ask you to publish outcomes of your performance tests on the openmoko wiki [1] or here on the list. I found UBIFS an great filesystem for the OpenMoko Hi Peter, Please note that UBIFS, like jffs2, is a filesystem designed to be used with flash that you have direct access to (MTD devices). It can be used on the Freerunner's internal NAND flash. What I'm talking about here is f2fs, a filesystem designed to be used on a block device. In that sense it is like ext4 and most other well known filesystems, not like UBIFS. It can be used on the Freerunner's µSD card. I will of course report my experience with f2fs once I try it out. -v ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
f2fs on GTA02
Hello Freerunner users, I am interested in using the new f2fs filesystem created by Kim Jaegeuk at Samsung on the µSD cards of a bunch of GTA02s. Right now it's undergoing testing in linux-next and there are several fresh discussion threads about it on lkml. I intend to wait until the code has stabilized a bit before making the attempt. First, is this a good idea? Also, is anyone else interested? The problem is that the code only compiles against recent Linux kernels and the newest kernel available for GTA02 is 2.6.39. I see two options: 1. Get Linux 3.7 working on the GTA02 2. Get f2fs working on Linux 2.6.39 Both options are challenging but I have to go for #2 because I don't have the knowledge to do #1. For #1: There are quite a few differences between upstream 2.6.39 and om-gta02-2.6.39 kernels. Some of the patches I understand and could re-apply against a more recent kernel, some of them have already been integrated upstream, but others are mysterious to me and even if I could apply them I can't guess whether or not they ought to still be applied. One big issue is that the glamo driver is not present upstream (and ar6000 also?). For #2: I have already prepared a patch to backport f2fs to 2.6.34/2.6.39 but there have been quite a lot of changes in the vfs and other areas in the intervening time. The patch is 817 lines long. Most of it is straightforward, though there were one or two tricky bits. The only thing I have achieved so far is getting it to compile with no errors and no warnings. That's a start, but it's not a guarantee that the filesystem will actually work! A significant problem with #2 is maintenance and bug fixes going forward. I would have to backport all future changes to f2fs. Anyway, for the information of anyone who's interested, I plan to at least give option #2 a try and see if I might be lucky :-) -v ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: f2fs on GTA02
On 2012-12-06 16:35, Dr. H. Nikolaus Schaller wrote: 3. develop 3.7/3.8 for GTA04 - the newest complete kernel is 3.5 and someone has recently posted first success on a 3.6 kernel with device tree. Oh, very true, very true :-) But we also have a lot of GTA02 already deployed and I would quite like to have it working on those devices. -v ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: f2fs on GTA02
On 2012-12-06 16:56, NeilBrown wrote:
I plan to try it sometime in the next few week.
Cool!
No partitions means you need to have x-loader, uboot, and kernel in the
NAND. That isn't difficult but it something to be aware of.
As you say, no problem. We already have our bootloader, kernel, and
rootfs in NAND and I was already planning to not use a partition.
If you post the patch I can have a look and see if anything obvious stands
out.
Here it is. It's against 2.6.34, not 2.6.39, because that's what we
happen to be using in our GTA02s in the field, but it probably wouldn't
be much different for 2.6.39. Also, it's against the very first version
of f2fs that was posted to lkml. I'm planning to redo it to integrate
the latest version of f2fs.
Thanks for your feedback. I'll look forward to your 3.7 work for GTA04,
and for GTA02 I'll try to get my backport working.
-v
From f50b49a4c40a02882eff1455600ddda571814e56 Mon Sep 17 00:00:00 2001
From: Phil Vandry van...@tzone.org
Date: Sat, 10 Nov 2012 22:05:51 -0500
Subject: backport f2fs to kernel 2.6.34
---
fs/f2fs/acl.c | 61 --
fs/f2fs/acl.h |2 +-
fs/f2fs/data.c|4 +-
fs/f2fs/dir.c | 30 ++--
fs/f2fs/f2fs.h|5 +-
fs/f2fs/file.c| 123 +
fs/f2fs/gc.h |2 +-
fs/f2fs/inode.c |6 +--
fs/f2fs/namei.c | 14 +++---
fs/f2fs/node.c|8 ++--
fs/f2fs/segment.c | 15 --
fs/f2fs/super.c | 24 --
fs/f2fs/xattr.c |6 +-
fs/f2fs/xattr.h | 10 ++--
14 files changed, 139 insertions(+), 171 deletions(-)
diff --git a/fs/f2fs/acl.c b/fs/f2fs/acl.c
index ce661ae..bc58644 100644
--- a/fs/f2fs/acl.c
+++ b/fs/f2fs/acl.c
@@ -190,6 +190,23 @@ struct posix_acl *f2fs_get_acl(struct inode *inode, int type)
return acl;
}
+int
+f2fs_check_acl(struct inode *inode, int mask)
+{
+ struct posix_acl *acl;
+
+ acl = f2fs_get_acl(inode, ACL_TYPE_ACCESS);
+ if (IS_ERR(acl))
+ return PTR_ERR(acl);
+ if (acl) {
+ int error = posix_acl_permission(inode, acl, mask);
+ posix_acl_release(acl);
+ return error;
+ }
+
+ return -EAGAIN;
+}
+
static int f2fs_set_acl(struct inode *inode, int type, struct posix_acl *acl)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode-i_sb);
@@ -208,9 +225,11 @@ static int f2fs_set_acl(struct inode *inode, int type, struct posix_acl *acl)
case ACL_TYPE_ACCESS:
name_index = F2FS_XATTR_INDEX_POSIX_ACL_ACCESS;
if (acl) {
- error = posix_acl_equiv_mode(acl, inode-i_mode);
+ mode_t mode = inode-i_mode;
+ error = posix_acl_equiv_mode(acl, mode);
if (error 0)
return error;
+ inode-i_mode = mode;
set_acl_inode(fi, inode-i_mode);
if (error == 0)
acl = NULL;
@@ -262,17 +281,28 @@ int f2fs_init_acl(struct inode *inode, struct inode *dir)
}
if (test_opt(sbi, POSIX_ACL) acl) {
+ struct posix_acl *clone;
+ mode_t mode;
if (S_ISDIR(inode-i_mode)) {
error = f2fs_set_acl(inode, ACL_TYPE_DEFAULT, acl);
if (error)
goto cleanup;
}
- error = posix_acl_create(acl, GFP_KERNEL, inode-i_mode);
- if (error 0)
- return error;
- if (error 0)
- error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
+ clone = posix_acl_clone(acl, GFP_KERNEL);
+ error = -ENOMEM;
+ if (!clone)
+ goto cleanup;
+ mode = inode-i_mode;
+ error = posix_acl_create_masq(clone, mode);
+ if (error = 0) {
+ inode-i_mode = mode;
+ if (error 0) {
+/* This is an extended ACL */
+error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, clone);
+ }
+ }
+ posix_acl_release(clone);
}
cleanup:
posix_acl_release(acl);
@@ -282,7 +312,7 @@ cleanup:
int f2fs_acl_chmod(struct inode *inode)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode-i_sb);
- struct posix_acl *acl;
+ struct posix_acl *acl, *clone;
int error;
mode_t mode = get_inode_mode(inode);
@@ -295,11 +325,14 @@ int f2fs_acl_chmod(struct inode *inode)
if (IS_ERR(acl) || !acl)
return PTR_ERR(acl);
- error = posix_acl_chmod(acl, GFP_KERNEL, mode);
- if (error)
- return error;
- error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
+ clone = posix_acl_clone(acl, GFP_KERNEL);
posix_acl_release(acl);
+ if (!clone)
+ return -ENOMEM;
+ error = posix_acl_chmod_masq(clone, inode-i_mode);
+ if (!error)
+ error = f2fs_set_acl(inode, ACL_TYPE_ACCESS, acl);
+ posix_acl_release(clone);
return error;
}
@@ -362,7 +395,7 @@ static int f2fs_xattr_set_acl(struct dentry *dentry, const char *name,
if (strcmp(name, ) != 0)
return -EINVAL;
- if (!inode_owner_or_capable(inode))
+ if (!is_owner_or_cap(inode))
return -EPERM;
if (value) {
@@ -385,7 +418,7 @@ release_and_out:
return error;
}
-const struct xattr_handler f2fs_xattr_acl_default_handler = {
+struct xattr_handler f2fs_xattr_acl_default_handler = {
.prefix = POSIX_ACL_XATTR_DEFAULT,
.flags = ACL_TYPE_DEFAULT,
.list = f2fs_xattr_list_acl,
@@ -393,7 +426,7 @@ const struct xattr_handler f2fs_xattr_acl_default_handler
Re: GTA02 fails to charge
On 2011-09-28 05:22, Ivan Matveev wrote: On Tue, 27 Sep 2011 14:46:11 -0400 Phil Vandryvan...@tzone.org wrote: I have 2 GTA02v6 Freerunners which don't charge their batteries anymore. The symptoms on both are the same, but it started happening on both phones in different locations and times. The battery state is Charging whether the phone is plugged in to a computer or wall charger, but the battery slowly goes down instead of charging. Had a similar problem. New battery helped. In my case, the problem follows the Freerunner, not the battery. I have many spare GTA02 batteries so this is easy to test. -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA02 fails to charge
I have 2 GTA02v6 Freerunners which don't charge their batteries anymore. The symptoms on both are the same, but it started happening on both phones in different locations and times. The battery state is Charging whether the phone is plugged in to a computer or wall charger, but the battery slowly goes down instead of charging. We use the phones in airplanes, connected to 5V DC power supplies. My wild guess is that both units might have experienced a power surge or something that fried the charging circuit (RT9711BPB chip in socket U4905?). With 2 Freerunners affected and afraid it might happen a third time, I would like to know if anyone else has experienced this problem. -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
A-GPS (was Re: Freerunner as a mobile gateway - shipping container)
On 2011-05-24 08:42, Ed Kapitein wrote: You could overcome the TTFF problem by using the agps software from [1] It loads the needed data from the gps chip and uses that the next time you power on the gps unit. I usually get a fix in 2 minutes. Hi Ed, For some reason I thought the Antaris chip in the GTA02 didn't support all of the AID message types but only AID-INI (which provides a basic saved position and time but nothing else like almanac or ephemeris). I think it has something to do with the facts that (a) the chip doesn't send ACK messages in response to any AID-* messages, making it hard to know if the messages you're sending are good, and (b) I've never managed to get a Freerunner to send me a AID-DATA probe which is the message that means please send me any available aid data. Why my Freerunners never send AID-DATA whereas the code you pointed to clearly expects to receive it I have no idea. In any case, I decided to try again. This time I just send it all the AID messages at startup whether it asks for them or not. The results are good so far. If the Freerunner has network connectivity within a few minutes of startup, I subsequently get fresh AID data from the Internet and send that too. The result is that the GPS gets two copies of the AID data, one saved from the last shutdown and one fresh from the Internet. It doesn't seem to mind. Thanks for motivating me to try this A-GPS stuff again. -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner as a mobile gateway - shipping container
On Wed, May 18, 2011 at 03:19:16PM +0200, Eric Smith wrote: Main application here is in a sea shipping container. The key issues are RF communication (when in a GSM range of course) and power management due to the long haul journey including journey overland. Power supply has to be in the form of an additional battery. Technical issue is to have minimal size OS and to be low in power consumption. And robust. If you sleep and only wake up at intervals, you should anticipate some difficulty acquiring a GPS signal every time you wake up. The GPS in the Freerunner is really designed to make use of A-GPS and if you can't do it because you are at sea and far from any network signal, it can take a long time to get a position. We have sometimes seen it take over 40 minutes to get a good fix (unit mounted on an aircraft glareshield). -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QI kernel parameters
On Sun, 02 Jan 2011 21:26:08 +0100 Ed Kapitein e...@kapitein.org wrote: Anyway, i tried it, and i end up with: neo qi # make mkdir -p image ld: cannot open linker script file src/cpu//qi.lds: No such file or directory Sorry, I didn't (re-)read the instructions in the README file before sending that. make CPU=s3c2442 Did you manage to get your SD card to work? if so how? I ran a full bad blocks scan of the card on another computer and recreated the filesystem once again. It seems to work OK now though I'm still not sure if I want to put this unit back in the field... I would have done dd if=/dev/zero of=/dev/thecard to force reallocation of bad sectors like I would do on a hard drive but I was afraid that would cause every flash block to be read-modify-written multiple times. I wish we could get direct access to the flash on SD cards like we can do with the NOR/NAND flash to bypass the FTL and use a file system designed for flash. -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QI kernel parameters
On Sun, Jan 02, 2011 at 05:43:36PM +0100, Ed Kapitein wrote: I have a hard time with an SD card that will give errors whne running fsck, even right after an fresh mke2fs. I have one of those too :-( The problem follows the μSD card, not the Freerunner. Any other idea on how to supply kernel parameters while booting from NAND? I needed to change the kernel command line and I found that it was easy to do by changing Qi's source code. Qi is very small so it's not daunting to modify and compiles in to time. All you need is a working toolchain. - git clone git://git.openmoko.org/git/qi.git - find the function append_device_specific_cmdline_gta02 in src/cpu/s3c2442/gta02.c You can just add something like cmdline += strlen(strcpy(cmdline, youroption=yourvalue)); - make - Use dfu-util to flash the result onto the Freerunner. -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Freerunner's contribution to /dev/random entropy
Hello all happy holidays, With the recent thread that mentions the noisiness of the accelerometers, I was reminded that the Freerunner has lots of sensors that are capable of being good sources of entropy for Linux's random number generator, especially with the Nav board installed. The accelerometers actually already contribute entropy (the input device framework takes care of it), but the new devices on the Nav board do not. Do you think it would be a good idea to add that? I think that the BMP085 probably should not (sensor readings too predictable and hardly changing from one reading to the next) but the other two should be good candidates, especially the rate gyros. -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Measure boot time using ttyUSBx on host mach?
On Fri, Nov 26, 2010 at 08:01:39AM +0530, Ranjit Pillai wrote: Can access uboot using ttyACM* but would love to have an output like http://lists.openmoko.org/nabble.html#nabble-td4204941 with ttyUSBx on host mach using terminal program like neocon/picocom. Is it really possible to have ttyUSB enabled all the time of so how to acheive that? I do not think that you will be able to do that. By default with Qi, the Freerunner's console output appears both on the touchscreen and on the real serial port (accessible with a debug board). In order for the Freerunner's console boot-time console output to be visible through a virtual serial port on the host, you would have to use the USB Gadget serial driver (/dev/ttyGS*) as a console device on the Freerunner. I believe that this driver does not work without help from userspace. Even if you can do that, it will not work until the whole USB system on the Freerunner has been initialized so you would miss all the messages that come before that. -Phil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
