mvniekerk wrote:
> Well, I can help you with this much - jffs2 + Android = No Go. It will
>   

Not true. Android runs perfectly on the Openmoko Freerunner using JFFS2 
for root and system. You need to qualify your statement as the only real 
partition that needs mmap is the /data partition. What I did for that is 
to split the sdcard into 2 partitions: fat for user data like music, 
videos, etc, and ext3 for the /data partition.

> run a few apps until the actual zygote stuff needs to run. mmap is the
> thing that will screw you over - you only get mmap with read only
> jffs2.
> yaffs2 + NOR = No Go. It will fall over and flop.
> UBIFS + NOR + Android = Works well actually. Got it running on our
> iMX31 board with NOR. I'll post some instructions to get UBIFS working
> if you need it. UBIFS = JFFS3. It has compression and a lot of other
> cool stuff. It also scales well.
>
> On Nov 10, 4:10 pm, Markus <[EMAIL PROTECTED]> wrote:
>   
>> Hi,
>>
>> yes, we might change to a different file system, but actually, Android
>> uses yaffs2 as main file system or at least it seems like this if you
>> hack into its configuration files. To be honest, we do not know, if
>> this problem is caused by the file system or something else as we are
>> able to do file operations in /data/app during the booting process.
>> The kernel panic occurs after Android finished the booting process. So
>> our guess is that Android starts something, that watches the file
>> system (especially /data/app) and that this service is causing our
>> problem. Unfortunately, we could not yet locate, which tool is
>> responsible... any guess, what is started in the end of the booting
>> process, that might cause our problem?
>>
>> Below, a log of the kernel panic.
>>
>> Bye
>> Markus
>>
>> busybox cp ApiDemos.apk test
>> Unable to handle kernel paging request at virtual address 00100104
>> pgd = c70a4000
>> [00100104] *pgd=870a2031, *pte=857180dd, *ppte=8571880e
>> Internal error: Oops: 81f [#1] PREEMPT
>> Modules linked in:
>> CPU: 0    Not tainted  (2.6.24-140-g68eb4b4 #77)
>> PC is at android_unlock_suspend+0x60/0x170
>> LR is at android_unlock_suspend+0x34/0x170
>> pc : [<c01ff8b4>]    lr : [<c01ff888>]    psr: 60000193
>> sp : c711bea8  ip : c039bac4  fp : c711bee4
>> r10: c711a000  r9 : 000001e0  r8 : 60000113
>> r7 : c7de20a0  r6 : c039babc  r5 : c039babc  r4 : c7de20e0
>> r3 : c7c35da8  r2 : 00100100  r1 : 00200200  r0 : c7de20e0
>> Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
>> Control: 00e5387f  Table: 870a4000  DAC: 00000015
>> Process FileObserver (pid: 1675, stack limit = 0xc711a260)
>> Stack: (0xc711bea8 to 0xc711c000)
>> bea0:                   c710401c c7cfac40 c711bed4 c711bec0 c00603cc
>> c006035c
>> bec0: c73dc3c0 00000000 c73dc3d0 c7de20a0 c73dc3c0 c711a000 c711befc
>> c711bee8
>> bee0: c00c4f90 c01ff860 c73dc3c0 46a2cba4 c711bf4c c711bf00 c00c57d0
>> c00c4f30
>> bf00: c003f92c 46a2cb84 c7cfac70 00000000 c7cfac40 c005b298 c711bf18
>> c711bf18
>> bf20: c02bfa58 c7043ea0 46a2cb84 c711bf78 00000200 c0025004 c711a000
>> 41046fc0
>> bf40: c711bf74 c711bf50 c00961a4 c00c5634 c711bf74 c711bf60 c7043ea0
>> fffffff7
>> bf60: 00000000 00000000 c711bfa4 c711bf78 c00965ec c00960fc 00000000
>> 00000000
>> bf80: 001ce0b0 00000001 00000f4c ad352cd8 001cf5b8 00000003 00000000
>> c711bfa8
>> bfa0: c0024e80 c00965b4 00000f4c ad352cd8 0000001e 46a2cb84 00000200
>> fd1fafed
>> bfc0: 00000f4c ad352cd8 001cf5b8 00000003 46a2cda0 41046fd4 41046fc0
>> 00000001
>> bfe0: ad353458 46a2cb48 ad3414c9 afe0b50c 00000010 0000001e 00ff00ff
>> 00ff00ff
>> Backtrace:
>> [<c01ff854>] (android_unlock_suspend+0x0/0x170) from [<c00c4f90>]
>> (remove_kevent+0x6c/0x94)
>> [<c00c4f24>] (remove_kevent+0x0/0x94) from [<c00c57d0>] (inotify_read
>> +0x1a8/0x1e4)
>>  r4:46a2cba4
>> [<c00c5628>] (inotify_read+0x0/0x1e4) from [<c00961a4>] (vfs_read
>> +0xb4/0x144)
>> [<c00960f0>] (vfs_read+0x0/0x144) from [<c00965ec>] (sys_read
>> +0x44/0x70)
>>  r7:00000000 r6:00000000 r5:fffffff7 r4:c7043ea0
>> [<c00965a8>] (sys_read+0x0/0x70) from [<c0024e80>] (ret_fast_syscall
>> +0x0/0x2c)
>>  r7:00000003 r6:001cf5b8 r5:ad352cd8 r4:00000f4c
>> Code: e5965000 e5812000 e5843000 e59c3000 (e5821004)
>> Kernel panic - not syncing: Fatal exception
>>
>> On 9 Nov., 10:16, mvniekerk <[EMAIL PROTECTED]> wrote:
>>
>>     
>>> Your answer lies in UBIFS. There is a port for kernel 2.6.24 up to
>>> 2.6.27. UBIFS is JFFS3 if you like - and it does support mmap. If your
>>> flash chip is of the NOR-type then YAFFS2 will not work - that is what
>>> makes UBIFS so sweet!
>>> To set up a UBI volume for UBIFS is bit of a schlep, but once done it
>>> is a cool piece of equipment.
>>>       
>>> On Nov 6, 11:39 pm, Markus <[EMAIL PROTECTED]> wrote:
>>>       
>>>> Hi,
>>>>         
>>>> it is the init process, that cannot start. The kernel is always
>>>> booting fine and only the Android init process is not able to do its
>>>> job. For yaffs2, the booting process stops like 
>>>> inhttp://groups.google.com/group/android-porting/browse_thread/thread/d...
>>>> - I'm sorry, that I can't post my own message at the moment, but I do
>>>> not have access to the hardware right now to flash everything...
>>>>         
>>>> Like in the link above, we get the same problem about the magic
>>>> number, while Android tries to load the core.jar file. After 4 tries,
>>>> Android resigns and reboots.
>>>>         
>>>> bye
>>>> Markus
>>>>         
>>>> On 6 Nov., 17:22, "Gergely Kis" <[EMAIL PROTECTED]> wrote:
>>>>         
>>>>> Hi,
>>>>>           
>>>>> Could you give more information regarding "Android was not able to
>>>>> boot onyaffs2". What were the actual error messages? Did the kernel
>>>>> hang, or the init process?
>>>>>           
>>>>> Best Regards,
>>>>> Gergely
>>>>>           
>>>>> On Thu, Nov 6, 2008 at 4:18 PM, Markus <[EMAIL PROTECTED]> wrote:
>>>>>           
>>>>>> Hi,
>>>>>>             
>>>>>> as I wrote in Android Internals, we ported Android to an i.MX31.
>>>>>> Unfortunately, we have some issues with the file system.
>>>>>> If I use NFS as file system with a modified init.rc config, everything
>>>>>> seems to work well, but this is no option for us as permanent file
>>>>>> system, so we decided to useyaffs2as file system. As this did not
>>>>>> work (Android was not able to boot), we changed to jffs2. jffs2 boots
>>>>>> fine as long as we use a read-only file system. After booting, we can
>>>>>> start many applications, but it seems that those requiring file write
>>>>>> operations fail to start, e.g. the webbrowser. If we change init.rc
>>>>>> config to give file-write permissions, Android is not able to boot
>>>>>> anymore.
>>>>>>             
>>>>>> So we have decided to use a mixture ofyaffs2and jffs2, after we saw
>>>>>> this idea at the armv4 port. The basic idea is, that all mmap
>>>>>> operations are done onyaffs2, as jffs2 does not support them. At the
>>>>>> moment, we split the file system to two parts: /data is located on our
>>>>>> yaffs2partition, everything else on our jffs2 partition. The system
>>>>>> boots fine and we can run every application. But now, it is getting
>>>>>> confusing: As soon as Android has finished booting, it is impossible
>>>>>> to write/delete files in /data/app - if we do, we get a kernel panic,
>>>>>> which reports FileObserver to fail. This does not happen, if we do
>>>>>> file accesses before Android has finished its booting process.
>>>>>>             
>>>>>> Remembering that we had some cases, in which it was necessary to start
>>>>>> the system with strace running in the background (and discarding the
>>>>>> log), I booted theyaffs2/jffs2 system with strace in the background.
>>>>>> Now, I am able to access files in /data/app, I just get "syscall:
>>>>>> unknown syscall trap 0xe1a00000" reported to my debug console. In this
>>>>>> mode, it is also possible to run applications directly from Eclipse on
>>>>>> the target device.
>>>>>>             
>>>>>> So can anybody tell me what is going wrong, if I use ayaffs2only
>>>>>> file system? And why does strace heal those problems with ayaffs2/
>>>>>> jffs2 system? It just makes the system slower...
>>>>>>             
>>>>>> bye
>>>>>> Markus
>>>>>>             
> >
>   


--~--~---------~--~----~------------~-------~--~----~
unsubscribe: [EMAIL PROTECTED]
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---

Reply via email to