From: amit.virdi@st.com (Amit Virdi)
To: linux-arm-kernel@lists.infradead.org
Subject: Need advice: unable to mount filesystem
Date: Fri, 15 Feb 2013 17:25:26 +0530 [thread overview]
Message-ID: <511E222E.7050002@st.com> (raw)
In-Reply-To: <CACRpkdaNL=y7Stgd2d=FLY9Zf4iSHjT8GMK+Ch8noe=De3cWfQ@mail.gmail.com>
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-02-15 11:55 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 [this message]
2013-10-16 5:25 ` Amit Virdi
[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=511E222E.7050002@st.com \
--to=amit.virdi@st.com \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).