Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
On Wednesday, December 05, 2012 11:36:34 PM Neil Jerram wrote: Therefore I doubt that adopting the serial state kernel fix was a good reason for removing AT_OPSYS=0,2, and I think that people who don't want AT_OPSYS=0,2 (such as me) might be better advised to keep installing restart-when-modem-stops-working.patch. It's probably better to restart QtMoko, even though that might lose some application state, than to leave the phone not working and draining lots of power. The patch is still applied when building the debian package and it looks that we cant get rid of it yet. Maybe we could rework it so that it does not touch code in serial port class, move it completely to gta04 plugin and commit it. Or we could commit - ugly as it is - in case that reworking is not possible and if it would help people building from sources. Or have I misunderstood some part of this? BTW, did we ever establish that AT_OPSYS=0,2 100% avoids reenumerations? I dont know way how to 100% avoid it. 1/ without AT_OPSYS=0,2 i could make the reenumeration happen always. 2/ with AT_OPSYS=0,2 it happened very rarely. 3/ with kernel patch + 3G enabled it happened just once in last 3 weeks or so. Btw in latest release when the reenumeration happens, it's logged to /modem_reenumerate.log Could people who use GTA04 as phone report contents of the file? This could help us better to monitor the situation. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
Radek Polak pson...@seznam.cz writes: Could people who use GTA04 as phone report contents of the file? This could help us better to monitor the situation. Here's mine: Sun Nov 18 21:18:30 GMT 2012 modem reenumerated ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
Neil Jerram n...@ossau.homelinux.net writes: Radek Polak pson...@seznam.cz writes: Could people who use GTA04 as phone report contents of the file? This could help us better to monitor the situation. Here's mine: Sun Nov 18 21:18:30 GMT 2012 modem reenumerated On reflection, though, I'm confused. What now calls fix-modem-reenumerate.sh (apart from the restart-when-modem-stops-working, if that is installed)? Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
On Thursday, December 06, 2012 08:25:36 PM Neil Jerram wrote: Neil Jerram n...@ossau.homelinux.net writes: Radek Polak pson...@seznam.cz writes: Could people who use GTA04 as phone report contents of the file? This could help us better to monitor the situation. Here's mine: Sun Nov 18 21:18:30 GMT 2012 modem reenumerated On reflection, though, I'm confused. What now calls fix-modem-reenumerate.sh (apart from the restart-when-modem-stops-working, if that is installed)? It's called only from serial port class when restart-when-modem-stops- working.patch is applied. Regards Radek ___ 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
Am 06.12.2012 um 22:19 schrieb Phil Vandry: 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 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. 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 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 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 ... 1. Get Linux 3.7 working on the GTA02 3. develop 3.7/3.8 for GTA04 how's that going to help when he's specifically asking about the GTA02? ___ 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
Am 06.12.2012 um 22:42 schrieb arne anka: 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 ... 1. Get Linux 3.7 working on the GTA02 3. develop 3.7/3.8 for GTA04 how's that going to help when he's specifically asking about the GTA02? I think he is mainly interested in the f2fs. And needs some hardware to test it. So he can upgrade the GTA02 with a GTA04 board and that saves a lot of time by not backporting to an old system. ___ 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 = {
UBIFS - Issue while running ubimkvol (ubimkvol Killed)
Hi all, We are basically trying to mount our inbuilt NAND flash device and write some files onto it using UBI/UBI-FS. After running some of the following steps successfully, the linux kernel crashed after running ‘ubimkvol’. Please help me if I am doing something wrong in any of the steps below which is causing ubimkvol to be killed. Flash Size : 800 MB Linux Kernel Version : 3.1.14 Page size : 8192 Physical Erase Block Size : 1MiB ( We are taking) These are the steps we are following: 1. Create ubifs image by using mkfs.ubifs command #mkfs.ubifs -v -r rootfs -o ubifs.img -m 8192 -e 1032192 -c 788 Description: We are taking Physical Erase Block (PEB) size as 1048576 bytes(1MiB) -e -- Erase Block Size e = (1048576 - 2 * 8192) = 1032192 bytes -c --The maximum size, in LEBs, of this file system c = 788(see the below calculation) PEB Size (SP) = 1048576 LEB Size (SL) = 1048576 - 2 * 8192 = 1032192 Total Flash Size = 800 MiB Total number of PEBs on the MTD device (P) = 800 MiB/1048576 = 800 Number of PEBs reserved for bad PEB handling(B) is 1% of P = 8 The overhead related to storing EC and VID headers in bytes i.e. O = SP - SL = 1048576 - 1032192 = 16384. UBI Overhead = (B + 4) * SP + O * (P - B - 4) = (8 + 4) * 1048576 + 16384(800 - 8 -4) = ~24 Available PEB's = 800 - 24 = 776 PEB's. Calcultion of 'c' = ((Available PEB's)*PEB)/LEB = (776 * 1048576)/ 1032192 = ~ 788 LEB's. 2. Create ubinize.cfg file and write the contents into it # vi ubinize.cfg [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=512MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize give ubinise command #ubinize -o ubi.img -m 8192 -p 1MiB ubinize.cfg -v m = 8192 page size. p = 1MiB physical erase block 3. Flash_Erase: Prepares NAND partition; MTD partition 3 needs to be erased and used for UBI file system. # flash_erase /dev/mtd3 0 0 (0 0) - indicates erases the memory from available first LEB to last LEB It displays the following message : Erasing 1024 Kibyte @ 31f0 -- 100 % complete 4. UBI Formatting :Flash the UBI file system image (ubi.img) to MTD partition 3 # ubiformat /dev/mtd3 -f ubi.img 5. Ubiattach: Attach MTD device to UBI # ubiattach /dev/mtd3 -f ubi.img 6. ubimkvol : Create an UBI volume - the created volume will be empty # ubimkvol /dev/ubi0 -N ubifs_volume -m It displays the following message : Set volume size to 813367296 Killed (log of ubimkvol is attached please find it for further reference) The kernel crashed after running this step. Thanks in advance, Charan.___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
