Re: Booting directly to JFFS2 question

Re: Booting directly to JFFS2 question

[David Woodhouse]

On Thu, 2004-01-15 at 11:45 -0800, James Ewing wrote:
> After creating the partitions the system looks for the file system image by
> checking 64K boundaries of the 2nd flash partition looking for cramfs or
> squashfs magic numbers. The routine then returns a pointer to the fs system
> start byte and the init/do_mount.c code takes over.

This works by setting up the partitions dynamically according to what's
found in the image, right? 

> This pointer was to the super_block for the filesystem. Apparently jffs2
> doesn't have a super_block in the traditional sense so I am a bit stumped.

It should still be possible -- look for a JFFS2 node (0x1985 etc..)
starting at the beginning of an eraseblock. 

See struct jffs2_unknown_node in include/linux/jffs2.h

-- 
dwmw2

Re: Booting directly to JFFS2 question

[David Woodhouse]

On Thu, 2004-01-15 at 12:01 -0800, James Ewing wrote:
> Hi David,

Please don't top-post. See http://www.infradead.org/~dwmw2/email.html

> It looks like JFFS2 uses a 2 byte magic number with a varying 2 byte block
> type. My guess is that I need to look for any of the permutations and return
> a pointer if found.

The magic will be 4-byte aligned, and you can also check the CRC to
avoid false positives.

> My next question is how to add the boot/startup code to do_mounts.c.
> Currently it finds the super_block and returns it to the routines for ext2,
> cramfs, etc.
> 
> What would the return to JFFS2 look like?

I'm not sure I understand -- what does the 'return to cramfs/ext3/etc.'
look like? 

You set up the partitions appropriately, and then the normal root mount
code mounts /dev/mtdblock1 as jffs2, surely?

-- 
dwmw2

Booting directly to JFFS2 question

[James Ewing]

Can anyone describe how to boot from flash directly to jffs2?

 I am working with a Broadcom MIPS based wireless router that originally
booted to cramfs. I added the ability to boot to Phillip Lougher's squashfs
and now use this filesystem.

With the squashfs addition, I modeled the code changes after cramfs and the
modifications were trivial. I would like to add boot ability directly to
jffs2, but am stumped as to how to do this.

When the system boots it creates four MTD partitions from flash. The second
contains a compressed root image and a cramfs (now squashfs) file system
image.
After creating the partitions the system looks for the file system image by
checking 64K boundaries of the 2nd flash partition looking for cramfs or
squashfs magic numbers. The routine then returns a pointer to the fs system
start byte and the init/do_mount.c code takes over.

This pointer was to the super_block for the filesystem. Apparently jffs2
doesn't have a super_block in the traditional sense so I am a bit stumped.


James Ewing

Re: Booting directly to JFFS2 question

[James Ewing]

Hi David,

The partitions are setup dynalically, yes.

It looks like JFFS2 uses a 2 byte magic number with a varying 2 byte block
type. My guess is that I need to look for any of the permutations and return
a pointer if found.

My next question is how to add the boot/startup code to do_mounts.c.
Currently it finds the super_block and returns it to the routines for ext2,
cramfs, etc.

What would the return to JFFS2 look like?

Thanks for the help.

James


----- Original Message ----- 
From: David Woodhouse
To: James Ewing
Cc: linux-mtd@lists.infradead.org
Sent: Thursday, January 15, 2004 2:51 AM
Subject: Re: Booting directly to JFFS2 question


On Thu, 2004-01-15 at 11:45 -0800, James Ewing wrote:
> After creating the partitions the system looks for the file system image
by
> checking 64K boundaries of the 2nd flash partition looking for cramfs or
> squashfs magic numbers. The routine then returns a pointer to the fs
system
> start byte and the init/do_mount.c code takes over.

This works by setting up the partitions dynamically according to what's
found in the image, right?

> This pointer was to the super_block for the filesystem. Apparently jffs2
> doesn't have a super_block in the traditional sense so I am a bit stumped.

It should still be possible -- look for a JFFS2 node (0x1985 etc..)
starting at the beginning of an eraseblock.

See struct jffs2_unknown_node in include/linux/jffs2.h

-- 
dwmw2