• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 98 subscribers
  • Views 2587 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

jffs2 rootfs in SPI flash on omap-l138

Mike Looijmans
Expert 1275 points

So far I have used squashfs as rootfs in the internal 8MB SPI flash. I want to be able to write to my rootfs, so I want to switch to jffs2 or ubifs. We'll not be using extra NAND or NOR storage, it should all go into the little SPI flash.

I store the kernel at 0x80000 and the rootfs starts at 0x2a0000. I write it into the flash using TFTP to fetch it, then use

sf probe 0 ; sf erase 0x2a0000 0x550000 ; sf write 0xc0700000 0x2a0000 0x420000

to dump the downloaded rootfs into the SPI flash (the rootfs downloaded size is 0x420000 bytes)

To create the filesystem (the same I used for squashfs, which mounts and boots fine) I invoke mkfs.jffs2 as follows:

mkfs.jffs2 -x lzo --root=${IMAGE_ROOTFS} --faketime --output=${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.jffs2 --pad --little-endian --eraseblock=0x10000

bootargs in u-boot environ:

bootargs=console=ttyS2,115200n8 mem=32M@0xc0000000 mem=64M@0xc4000000 root=/dev/mtdblock4 ip=off rootfstype=squashfs,jffs2

Partition table according to the kernel:

0x000000000000-0x000000010000 : "UBL"
0x000000010000-0x000000070000 : "U-Boot"
0x000000070000-0x000000080000 : "U-Boot-Env"
0x000000080000-0x0000002a0000 : "Kernel"
0x0000002a0000-0x0000007f0000 : "Filesystem"
0x0000007f0000-0x000000800000 : "MAC-Address"

At the end, the kernel writes a last line and stops. Nothing else output after:

omap_rtc omap_rtc: setting system clock to 2012-03-28 14:50:55 UTC (1332946255)

If I store a squashfs image at 0x2a0000, everithing's fine. It does not matter if I remove squashfs from the rootfstype in the bootargs. Also with or without rootwait does not make a difference. The kernel has jffs2 compiled-in.


What am I doing wrong?

  • 0
    Guru 26430 points

    No expert at this. Never used squashfs. From what I've read rootfstype=squashfs,jffs2 means a read-only squashfs partition with changes stored in a second jffs2 partition. The OpenWRT guys seem ti use this hybrid file system. Not clear where that second jffs partition is specified. So "rootfstype=jffs2" does not work? Worst case would be to remove squashfs support from the kernel.

  • 0 in reply to Norman Wong
    Expert 1275 points

    rootfstype=jffs2 doesn't work either. I was under the impression that this worked like /etc/filesystems, i.e. the order in which to try filesystems.

  • 0 in reply to Mike Looijmans
    Guru 26430 points

    You're right. I'll confess to never using a list of types. I have used JFFS2 on NOR flash. The NOR flash needed to formatted with "clean markers". No idea what those are. I had to program flash from Linux. Linux was booted from something other than the JFFS2 partition. In my case I used NFS.

    cd /tmp
    tftp -r rootfs.jffs2 -g SERVER
    flash_eraseall -j /dev/mtd4
    flashcp -v rootfs.jffs2 /dev/mtd4

    The "-j" option is for the "clean markers". I never did look into doing the same from U-Boot. Maybe the "sf" commands have a jffs2 option somewhere. Documentation is tough to find. The "nand" commands have a "jffs2" option.

    In your case, you probably can't program mtd4 as you booted from it.

    That's all I got. Sorry about that. Hopefully someone will post solution. I can see that it would be a useful bit of knowledge.

  • 0
    Guru 11260 points

    Hi Mike,

    From outset everything looks fine, Is the Kernel compiled with support of NAND or NOR, if yes then the partition block changes,

    bootargs: console=ttyS2,115200n8 root=/dev/mtdblock<partion_id> [ro|rw] rootfstype=jffs2 mem=100M earlyprintk

    Regards,

    --Prabhakar Lad

  • 0 in reply to Prabhakar Lad
    Expert 1275 points

    I use neither nand nor nor (I always wanted to write that). I want to mount the filesystem from SPI flash. The board we're building will not have any nand/nor flash either.

    Access to the MTD device works, the system can boot from /dev/mtdblock4 when i put a squashfs in it. The kernel is compiled with JFFS2 filesystem support.

  • 0 in reply to Norman Wong
    Expert 1275 points

    In your case, you probably can't program mtd4 as you booted from it.

    Well, it's all copied to RAM so I took my chances :)

    I added mtd-utils to the squashfs, booted from it, and then erased with the flash utils. To my surpise, it worked!

    Apparently, there's some extra step involved while erasign or copying the flash. Now what I did IS really hackish, though I could make it boot a kernel to do only this flash step... Now the question is how I can accomplish the same from within u-boot? Maybe create the jffs image and "pad" it with empty sectors to fill all of the flash partition with formatted sectors?

  • 0 in reply to Mike Looijmans
    Expert 1275 points

    It worked only once though. At the next reboot (after a few writes to the filesystem), back to square one. So I guess this isn't going to work anyway.

  • 0 in reply to Mike Looijmans
    Guru 26430 points

    Not much to add. Is the erase block size correct? The usual sector size would be 8MB / 256 sectors for 32KB or 0x8000.

    All of TI's doc assume SPI flash is used as data for ramdisk rootfs. No examples using SPI flash directly as a writeable filesystem. Google results are much the same. NAND and NOR are handled. SPI not so much.