From: amit.virdi@st•com (Amit Virdi)
To: linux-arm-kernel@lists•infradead.org
Subject: Need advice: unable to mount filesystem
Date: Wed, 16 Oct 2013 10:55:17 +0530 [thread overview]
Message-ID: <525E233D.9060303@st.com> (raw)
In-Reply-To: <511E222E.7050002@st.com>
Hi All,
I'm using cortex-R4 in my SoC. I figured earlier that the support for
MMU-less kernel was broken from Kernel v3.6 onwards. As a result, I was
facing problem in mounting the filesystem. Using git bisect, I figured
out that as a result of:
> ARM: 7449/1: use generic strnlen_user and strncpy_from_user functions
the file system was unable to mount on MMU-less kernel. Till date, I
have been using the following local fix [1]:
---
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 479a635..e5d549f 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -190,7 +190,7 @@ static inline void set_fs(mm_segment_t fs)
#define access_ok(type,addr,size) (__range_ok(addr,size) == 0)
#define user_addr_max() \
- (segment_eq(get_fs(), USER_DS) ? TASK_SIZE : ~0UL)
+ (segment_eq(get_fs(), KERNEL_DL) ? ~0UL : TASK_SIZE)
/*
* The "__xxx" versions of the user access functions do not verify the
---
However, I have realized that other people using MMU-less CPUs are happy
(hopefully) with the latest kernel. So, this makes me think that there's
something other than my local fix that I should be doing to get rid of
the filesystem mounting problem.
Can anyone guide me how they are able to run the kernel on MMU-less
system without facing FS mounting problem?
Regards
Amit Virdi
[1] The above fix works only till kernel v3.11-rc3
[2] The patch "ARM: move signal handlers into a vdso-like page"
introduced in v3.11-rc4 generates Prefetch abort while booting kernel in
MMU-less systems
On 2/15/2013 5:25 PM, Amit VIRDI wrote:
> Linus,
>
> I have some more findings...
>
>>> [<20185984>] (kernel_init+0x8/0xe4) from [<20008e98>]
>>> (ret_from_fork+0x14/0x3c)
>>
>> It looks like something is wrong with your initramfs. Check that
>> it is really added to the kernel image.
>>
>
> I copied a known good flat filesystem in the flash. Then I appled
> patches for my SoC code to Linux 3.3, build the kernel and executed.
> Everything went smooth and the kernel successfully mounted the filesystem.
>
> Then, I rebased on v3.4. The new kernel again successfully mounted the FS.
>
> I rebased again on v3.5, again everything went smoothly.
>
> However, when I rebased on v3.6 things started to break. The Kernel
> didn't boot at all. The processor generated Synchronous Data Abort
> exception because of alignment fault (during read operation). I debugged
> the code and noticed that start_kernel ran successfully till the end. It
> is the execution of rest_init that generated alignment fault.
>
> Same behavior was observed for v3.7.
>
> However, this problem didn't come with Kernel v3.8-rc6. So, the kernel
> execution proceeded further and all the devices were probed and their
> drivers loaded. As reported earlier, the Kernel couldn't mount the FS
> and is throwing the error:
> --
> VFS: Cannot open root device "mtdblock3" or unknown-block(31,3): error -14
> --
>
> So, as long as there's no compatibility change introduced in the newer
> Kernel, I do not suspect the filesystem as such.
>
> It seems something has been broken for MMUless processors.
>
>> I usually use:
>>
>> CONFIG_BLK_DEV_INITRD
>> CONFIG_INITRAMFS_SOURCE "your-ramdisk.cpio"
>> CONFIG_RD_GZIP
>
> I have verified these for initramfs and these are perfect.
>
>> CONFIG_INITRAMFS_COMPRESSION_GZIP
>>
>
> However, I'm not using this but this might not be necessary.
>
>> Then pass root=/dev/ram0
>>
>> But the last should not be necessary I think.
>>
>> I have a precompiled ramfs here:
>> http://www.df.lth.se/~triad/krad/ux00/rootfs-u300.cpio
>>
>> This is for ARM9 and uses ttyAMA0 as console so it
>> probably works with your system if you copy it to your
>> kernel build dir and state "rootfs-u300.cpio" as
>> initramfs source.
>>
>
> Didn't get chance to try these yet.
>
> Regards
> Amit Virdi
> .
>
next prev parent reply other threads:[~2013-10-16 5:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 12:29 Need advice: unable to mount filesystem Amit Virdi
2013-02-13 13:14 ` Linus Walleij
2013-02-14 2:57 ` Anil Kumar
2013-02-14 5:34 ` Amit Virdi
2013-02-14 5:24 ` Amit Virdi
2013-02-14 9:36 ` Linus Walleij
2013-02-15 11:55 ` Amit Virdi
2013-10-16 5:25 ` Amit Virdi [this message]
[not found] ` <20131016082019.GA10079@pengutronix.de>
2013-10-21 11:29 ` copy from user broken on no-MMU (Was: Need advice: unable to mount filesystem) Amit Virdi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525E233D.9060303@st.com \
--to=amit.virdi@st$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox