using a jffs2 rootfs in NAND

[Bloggins]

I have a mini2440 256M version of the board. I have u-boot in the NAND
flash and I can currently boot the board using nfs to get the rootfs.
I would prefer to be booting completely from NAND. The nfs method is
very handy for development but eventually I need to be able to write
the rootfs to the board's NAND.

I have setup the environment "bootargs" variable with the following
string:

bootargs=console=ttySAC0,115200 noinitrd init=/linuxrc mini2440=1tb
rootfs=/dev/mtdblock3

I have compiled the kernel to support jffs2 fileystems.

I have used the following u-boot commands to copy over the jffs2 image
and write it to the NAND flash:

MINI2440 # tftpboot 0x10000 root_qtopia-jffs2.img
< shows the download, a lot of # marks, no crc errors >

MINI2440 # mtdparts
device nand0 <mini2440-nand>, # parts = 4
#: name size offset
mask_flags
0: u-boot 0x00040000 0x00000000 0
1: u-boot_env 0x00020000 0x00040000 0
2: kernel 0x00500000 0x00060000 0
3: rootfs 0x0faa0000 0x00560000 0

active partition: nand0,0 - (u-boot) 0x00040000 @ 0x00000000

defaults:
mtdids : nand0=mini2440-nand
mtdparts: <NULL>

MINI2440 # nand erase rootfs
MINI2440 # nand write.e 0x10000 rootfs < size of the rootfs download >

I then call the "boot" command. The kernel loads as per usual but it
gacks when it tries to load the rootfs file system. Here's the output
from when it "gacks":

ib80211: common routines for IEEE802.11 drivers
s3c2410-rtc s3c2410-rtc: setting system clock to 2010-05-15 18:01:57
UTC (1273946517)
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "<NULL>" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available
partitions:
1f00 256 mtdblock0 (driver?)
1f01 128 mtdblock1 (driver?)
1f02 5120 mtdblock2 (driver?)
1f03 256640 mtdblock3 (driver?)
1f04 262144 mtdblock4 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-
block(2,0)
Backtrace:
[<c0035270>] (dump_backtrace+0x0/0x10c) from [<c03ad290>] (dump_stack
+0x18/0x1c)
r7:c39330d7 r6:c0521fb0 r5:c3933000 r4:c3823f40
[<c03ad278>] (dump_stack+0x0/0x1c) from [<c03ad2e0>] (panic+0x4c/
0x134)
[<c03ad294>] (panic+0x0/0x134) from [<c0008e9c>] (mount_block_root
+0x178/0x234)
r3:00000000 r2:c38619ec r1:c3823f40 r0:c046d5d0
[<c0008d24>] (mount_block_root+0x0/0x234) from [<c0009008>] (mount_root
+0xb0/0xf4)
[<c0008f58>] (mount_root+0x0/0xf4) from [<c0009144>] (prepare_namespace
+0xf8/0x190)
r7:c0521980 r6:c0021808 r5:c0021808 r4:c00208d8
[<c000904c>] (prepare_namespace+0x0/0x190) from [<c00084c0>]
(kernel_init+0xf0/0x124)
r7:00000000 r6:c00203dc r5:c00208d8 r4:c00208d8
[<c00083d0>] (kernel_init+0x0/0x124) from [<c004d1a4>] (do_exit
+0x0/0x62c)
r7:00000000 r6:00000000 r5:00000000 r4:00000000

Have I forgotten anything in setting this board up for jffs2? Are
there specific switches I need to be using to build the jffs2 image
when using the mkfs.jjfs2 tool?

[M P]

There is a write.jffs command, or equivalent (look at the help) --
jffs uses the OOB data to store metadata about the filessytem, so it
needs a special write command.

Michael

[rayholland]

Hi,

first: < size of the rootfs download > is not exactly correct. you
have to pad it to the the page size.
for example: your page size is 2k and your rootfs size is 65582 then
65582/2048=32.0224609375
=> we pad 32.0224609375 to 33
=> 33 * 2048 = 67584 (we padded the rootfs size to 2k)
=> 67584 = 10800 (hex)
=> nand write 0x32000000 rootfs 10800

second: you forget to set rootfstype=jffs2 in your bootargs.

good luck!
-- raymond

[Paul Jones]

> -----Original Message-----
> From: mini...@googlegroups.com [mailto:mini...@googlegroups.com]
> On Behalf Of Bloggins
> Sent: Sunday, 16 May 2010 8:30 AM
> To: mini2440
> Cc: oly...@gmail.com
> Subject: using a jffs2 rootfs in NAND
>
> I have a mini2440 256M version of the board. I have u-boot in the NAND
> flash and I can currently boot the board using nfs to get the rootfs.
> I would prefer to be booting completely from NAND. The nfs method is
> very handy for development but eventually I need to be able to write
> the rootfs to the board's NAND.

Can I ask how you managed to get u-boot working with a 256M board? I can get
it to run from RAM and it appears to flash correctly, but on reboot it just
locks up. My 128M board works fine.



Thanks,
Paul.

[rayholland]

hi,

i dont have the 256M, but the 128M mini2440.
but you can try to flash uboot using supervivi option 'v' (upload
supervivi bootloader).
but instead of selecting a supervivi image, select your uboot.bin)

--raymond

>  winmail.dat
> 3KViewDownload

[Bloggins]

I adjusted the bootargs, as it happens, the way I have the mkfs.jffs2
command working, it gives me an image that is exactly a multiple of
the 2048 block size.

Either way, I still have the same problem. I get the same error
reported from the kernel when it starts to look for a rootfs.

Cheers!!

[Bloggins]

I've been pursuing a possible problem with the git repository for u-
boot. My contention is that if you got the image out before a certain
date you would have got the u-boot code that works, after that time,
it does not work. They did some changes to use a common flash.c file I
believe. I have the older source and it compiles and works fine, if I
get a new copy from the git, it will not work.

Check the friendlyArm forum under "Linux" for my thread on the
subject.

Cheers!!

>  winmail.dat
> 3KViewDownload

[rayholland]

i have looked at your previous posts again and i think i now the
problem:

you set:
rootfs=/dev/mtdblock3

this is a typo it should be:

root=/dev/mtdblock3

so the whole bootargs should be:
setenv bootargs console=ttySAC0,115200 noinitrd init=/sbin/init
mini2440=1tb root=/dev/mtdblock3 rootfstype=jffs2

let me know if this solves your problem.
-- raymond

> > 3KViewDownload- Hide quoted text -
>
> - Show quoted text -

[Bloggins]

We are definitely closer. It would appear that the jffs2 image is
invalid. Here's the output from the kernel as it tries to mount the
jffs2 image:

s3c2410-rtc s3c2410-rtc: setting system clock to 2010-05-16 12:55:12
UTC (1274014512)
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0000:
0x0844 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0004:
0xaaa5 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0008:
0x081d instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff000c:
0x117a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0010:
0x81c0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0018:
0x60b4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff001c:
0x62d4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0020:
0x62d4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0024:
0x62d4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x00ff0028:
0x9000 instead
Further such events for this erase block will not be printed
Empty flash at 0x00ff0218 ends at 0x00ff021c
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0000:
0x0844 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0004:
0xaaa5 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0008:
0x081d instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff000c:
0x117a instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0010:
0x81c0 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0018:
0x60b4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff001c:
0x62d4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0020:
0x62d4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0024:
0x62d4 instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x01ff0028:
0x9000 instead
Further such events for this erase block will not be printed
Empty flash at 0x01ff0218 ends at 0x01ff021c
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0fa600b0:
0x3fff instead
Empty flash at 0x0fa600b4 ends at 0x0fa60130
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0fa60130:
0xff3f instead
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0fa800b0:
0x3fff instead
Empty flash at 0x0fa800b4 ends at 0x0fa80130
jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x0fa80130:
0xff3f instead
Cowardly refusing to erase blocks on filesystem with no valid JFFS2
nodes
empty_blocks 1723, bad_blocks 2, c->nr_blocks 2005
VFS: Cannot open root device "mtdblock3" or unknown-block(31,3)

Please append a correct "root=" boot option; here are the available
partitions:
1f00 256 mtdblock0 (driver?)
1f01 128 mtdblock1 (driver?)
1f02 5120 mtdblock2 (driver?)
1f03 256640 mtdblock3 (driver?)
1f04 262144 mtdblock4 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-

block(31,3)

Backtrace:
[<c0035270>] (dump_backtrace+0x0/0x10c) from [<c03ad290>] (dump_stack
+0x18/0x1c)

r7:c04e4440 r6:c0521fb0 r5:c3933000 r4:c3823f40

[<c03ad278>] (dump_stack+0x0/0x1c) from [<c03ad2e0>] (panic+0x4c/
0x134)
[<c03ad294>] (panic+0x0/0x134) from [<c0008e9c>] (mount_block_root
+0x178/0x234)

r3:00000000 r2:c38520ec r1:c3823f40 r0:c046d5d0

[<c0008d24>] (mount_block_root+0x0/0x234) from [<c0009008>] (mount_root
+0xb0/0xf4)
[<c0008f58>] (mount_root+0x0/0xf4) from [<c0009144>] (prepare_namespace
+0xf8/0x190)

r7:c0521980 r6:c0021808 r5:c0021808 r4:c0021818

[<c000904c>] (prepare_namespace+0x0/0x190) from [<c00084c0>]
(kernel_init+0xf0/0x124)
r7:00000000 r6:c00203dc r5:c00208d8 r4:c00208d8
[<c00083d0>] (kernel_init+0x0/0x124) from [<c004d1a4>] (do_exit
+0x0/0x62c)
r7:00000000 r6:00000000 r5:00000000 r4:00000000

From above in the kernel boot code the driver reports the following:

S3C24XX NAND Driver, (c) 2004 Simtec Electronics
s3c24xx-nand s3c2440-nand: Tacls=3, 29ns Twrph0=7 69ns, Twrph1=3 29ns
s3c24xx-nand s3c2440-nand: NAND soft ECC
NAND device: Manufacturer ID: 0xec, Chip ID: 0xda (Samsung NAND 256MiB
3,3V 8-bit)
Scanning device for bad blocks
Bad eraseblock 711 at 0x0000058e0000
Bad eraseblock 1219 at 0x000009860000
Creating 5 MTD partitions on "NAND 256MiB 3,3V 8-bit":
0x000000000000-0x000000040000 : "supervivi"
0x000000040000-0x000000060000 : "param"
0x000000060000-0x000000560000 : "Kernel"
0x000000560000-0x000040560000 : "root"
mtd: partition "root" extends beyond the end of device "NAND 256MiB
3,3V 8-bit" -- size truncated to 0xfaa0000
0x000000000000-0x000040000000 : "nand"
mtd: partition "nand" extends beyond the end of device "NAND 256MiB
3,3V 8-bit" -- size truncated to 0x10000000

Any ideas? I'm going to root around in the mtd driver code to see if
can find any clues.

Cheers!!

[Gabriel Zabusek]

Hi,

how did you upload the image to the nand via uboot? can you send the
exact command?


Thanks,
Gabriel Zabusek

--
..............................................................................................................................................

"...the finding of new proofs for known truths is often at least as
important as the discovery itself..."

[Bloggins]

tftp 0x10000 root_qtopia-jffs2.img

Cheers!!

[M P]

And how did you write it to nand ?

[Gabriel Zabusek]

Hi,

a meant how you loaded it from ram to nand. I had very similar issue
but with yaffs2 filesystem.


Gabriel Zabusek

[Bloggins]

Oops, sorry!! I just re-read your post Gabriel and realized that
wasn't the correct question I answered...

I did the following...

After I uploaded the image to RAM, I then erased the partition:

MINI2440 # nand erase rootfs

then I used the following to write the image to nand:
MINI2440 # nand write.jffs2 0x10000 rootfs 0x22c0000

The jffs2 image is exactly a multiple of the block size in bytes.

Cheers!!

[Bloggins]

And here is the command that I used to create the jffs2 image:

mkfs.jffs2 --pad --little-endian --squash -s 0x800 -n -e 128KiB -d
root_qtopia -o root_qtopia-jffs2.img

[Gabriel Zabusek]

Hi,

ok, was the very first thing you did before you started uploading the fs:

dynenv set 40000

? Also, i am not certain if it could have effected it but i would
choose a higher address, for instance 0x31000000

if i remember correctly the cause of my problem was either the dynenv
set command or that i was using command:

nand write.yaffs2 0x31000000 root ${filesize}

instead of this one - which works

nand write.yaffs 0x31000000 root ${filesize}

notice that i am using write.yaffs for yaffs2 filesystem - also notice
the ${filesize} command, there is no nead to type it manually.

for the mkfs.jffs2 command you sent i would have to check the man -
you use quite a lot of params :) (for yaffs2 i use almost none, no
padding / aligning etc needed...)

however, i believe the problem is definitely not your kernel (as you
can see from the output the driver works correctly)! its either the
image or the way it was uploaded by uboot.

Reymond: I dont use qtopia, I use my custom fs (yaffs2) + a bit hacked
git kernel + very simple 'gui'

Hope this helps,
Gabriel Zabusek

[rayholland]

i used:

for 2048 bytes page size - 128kb erase block
mkfs.jffs2 -e 0x20000 -l -s 0x800 -n -d ./target -o /tftpboot/
rootfs.arm.jffs2

but i have used fakeroot to pretend all target binaries are owned by
root

here is the part from buildroot i have used to make the rootfs image:

rm -f /home/raymond/embedded/mini2440/buildroot/output/build/
_fakeroot.rootfs.arm.jffs2
touch /home/raymond/embedded/mini2440/buildroot/output/build/.fakeroot.
00000
cat /home/raymond/embedded/mini2440/buildroot/output/build/.fakeroot*
> /home/raymond/embedded/mini2440/buildroot/output/build/
_fakeroot.rootfs.arm.jffs2
echo "chown -R 0:0 /home/raymond/embedded/mini2440/buildroot/output/
target" >> /home/raymond/embedded/mini2440/buildroot/output/build/
_fakeroot.rootfs.arm.jffs2
# Use fakeroot to pretend to create all needed device nodes
echo "/home/raymond/embedded/mini2440/buildroot/output/host/usr/bin/
makedevs -d target/generic/mini_device_table.txt /home/raymond/
embedded/mini2440/buildroot/output/target" \
>> /home/raymond/embedded/mini2440/buildroot/output/build/
_fakeroot.rootfs.arm.jffs2
# Use fakeroot so mkfs.jffs2 believes the previous fakery


echo "/home/raymond/embedded/mini2440/buildroot/output/toolchain/
mtd_orig/mkfs.jffs2 -e 0x20000 -l -s 0x800 -n -D target/generic/
mini_device_table.txt -d /home/raymond/embedded/mini2440/buildroot/
output/target -o /tftpboot/rootfs.arm.jffs2" \
>> /home/raymond/embedded/mini2440/buildroot/output/build/
_fakeroot.rootfs.arm.jffs2
chmod a+x /home/raymond/embedded/mini2440/buildroot/output/build/
_fakeroot.rootfs.arm.jffs2
/home/raymond/embedded/mini2440/buildroot/output/host/usr/bin/fakeroot
-- /home/raymond/embedded/mini2440/buildroot/output/build/
_fakeroot.rootfs.arm.jffs2

worked for me, but i dont know if you are using buildroot. if not you
can alter the script for your needs.

> > > > ...........................................................................­...................................................................

>
> > > > "...the finding of new proofs for known truths is often at least as

> > > > important as the discovery itself..."- Hide quoted text -

[Gabriel Zabusek]

Actually I just realized i might be wrong about the ${filesize}
argument in the email below - i upload the filesystem from a sd card
instead of network, so it could be different in your case.

Sorry about this.
Gabriel Zabusek

[Bloggins]

Rayholland,
I've never used "fakeroot" or "buildroot" before but from what I can
see, it's mostly for working on the hosting side so that you can
create a root filesystem without being root. Handy, and I will be
setting it up.

However, the real issue is the creation of the actual jffs2 image and
from your listing, I can see that you are using the exact same
settings that I use. Other than actually configuring the kernel to
recognize the jffs2 file system type, are there other switches that
need to be turned on in the kernel?

here is my setup:

<*> Journalling Flash File System v2 (JFFS2) support
(0) JFFS2 debugging verbosity (0 = quiet, 2 = noisy)
[*] JFFS2 write-buffering support

That's all I have on with regards to the jffs2 support. I'm using the
2.6.32.2 kernel that came with the board.

Cheers!!

> ...
>
> read more »

[rayholland]

your switches are correct.
i think you can better start from scratch.
here is my 'HOWTO' to get your mini2440 running.
like we say in holland: there are many roads to rome. but following
these steps i got my mini2440 up and running (later switched to
yaffs2, but thats an other story ;-))

---------------------------------------------------------------------------------
FLASHING UBOOT


connect usb kabel and rs232 cable

minicom

turn on mini2440 (nor)

supervivi

q

load ram 0x31000000 242332 u
249856

go 0x31000000


nand bad
nand scrub
nand createbbt (please wait, takes a while)
dynpart
dynenv set u-boot_env
saveenv

nand write 0x31000000 u-boot

turn on nand / reboot
You are now in UBOOT (MINI2440 prompt)


setenv ipaddr 192.168.1.25
setenv serverip 192.168.1.201
setenv tfpserver 192.168.1.201
setenv gatewayip 192.168.1.201

setenv bootargs console=ttySAC0,115200 noinitrd init=/sbin/init
mini2440=1tb root=/dev/mtdblock3 rootfstype=jffs2

setenv bootcmd 'nboot.e kernel ; bootm'
setenv bootargs_init init=/sbin/init

saveenv

--------------------------------

MAKING JFFS2 rootfs

2048 bytes pagsuze - 128kb erase block

mkfs.jffs2 -e 0x20000 -l -s 0x800 -n -d ./target -o /tftpboot/

rootfs.jffs2
copy /tftpboot/rootfs.jffs2 file to sd-card (fat32)


---------------------------------

FLASHING KERNEL FROM SD-CARD

nand erase 0x060000 500000

mmcinit
fatload mmc 0:1 0X32000000 /uImage
nand write 0x32000000 kernel

----------------------------------

FLASHING ROOTFS FROM SD-CARD

nand erase rootfs

mmcinit
fatload mmc 0:1 0x32000000 /rootfs.jffs2
nand write.jffs2 0x32000000 rootfs <rootfs file size>

----------------------------------

REBOOT AND WE ARE DONE

---------------------------------------------------------------------------------

> ...
>
> read more »- Hide quoted text -

[rayholland]

to make the story complete:
add extra header to kernel image for uboot (convert zImage to uImage)

mkimage -A arm -O linux -T kernel -C none -a 0x30008000 -e 0x30008000 -
d zImage uImage

--raymond

On May 16, 9:24 pm, rayholland <raymond.schee...@valid.nl> wrote:
> your switches are correct.
> i think you can better start from scratch.
> here is my 'HOWTO' to get your mini2440 running.
> like we say in holland: there are many roads to rome. but following
> these steps i got my mini2440 up and running (later switched to
> yaffs2, but thats an other story ;-))
>

> ---------------------------------------------------------------------------­------

> ---------------------------------------------------------------------------­------