ask for help

really? I made a minix fs on my linux box run on i586 and dd it to a image file. i checked this image file and found the magic number in the struct of the super block is "8F 13". because i386 is little endian, so the number is 0x138F. and then, i copied this file to the flash memory
of the eval board and ran linux. this time the magic number read by linux
is 0x8F13.

the main difference between the environments of yours and mine is that you
put image on disk while i put it on flash. something must do some transferring
work while read image from disk, maybe the disk driver. but i read the flash
by this mean:

	int a;
	a = 0xFFFD0400;
        ret =*(int*)a;

so, no transfer is done.

i don't if my words right. does anyone have some idea?

Wang

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Hm.
Nowadays I use NFS/compact flash for storage.
But before stuff like that worked I used initrd.
And I am very sure I did the initrd on my x86 server.
I copied the linux image and the initrd to flash on my 8xx board. It worked. Did not gzip it though.

And I did some code to 8xxrom that reads blocks from a romdisk.

This is how it must be:

1. The program you use to write the diskimage to flash does not convert anything. If it did it would convert your linux image too, right? And that would not work.

2. Your block device driver reads the data from the flash, right?

Lets say that the x86 computer has stored the 32bit number 0xdeadbeef in memory and written it to disk:

byte no. 00 01 02 03

content ef be ad de

You burn your file to your flash:

flash addr 00 01 02 03

content ef be ad de

You read it out to register r3.

r3 = 0xefbeadde - not the same 32bit value as on the x86!

But the contents of the memory is the same on both platforms. It is the way it is written/read that matters.
That is why it must be some standard how the fs is treated. The blockdriver should copy 512/4 bytes. No translation at all.

3. File systems are either big endian or little endian. If your platform is say big endian and the fs is little, you need to byteswap. This is usually handled by the fs with macros.

If you have a look at minix source code it looks like the code does not support endian changing. That means that you have to create the fs on the machine you intend to use it on.

Both fat and ext2 supports both endians -> no problems!

Good luck /

Magnus Damm

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

yes, that is the problem.

i do my work follow these steps:

1. make a loopback minix on i386 linux box and dd it to a image
2. burn the image to flash
3. when linux startup, uncompress the image to the buffer of a ramdisk
4. use this ramdisk as root file system and mount it as root.

when mount root, the super block should be read first. the super block in the image made in i386 looked like this:

00000400h: 02 a0 07 d0 00 01 00 01 00 19 00 00 1c 00 10 08 00000410h: 13 8f 00 01 00 00 00 00 00 00 00 00 00 00 00 00
^^^^^ the magic number of minix

the code in minix_read_super() (fs/minix/inode.c) is like below:

	struct minix_super_block *ms;
	if (!(bh = bread(dev,1,BLOCK_SIZE)))
		goto out_bad_sb;

	ms = (struct minix_super_block *) bh->b_data;
        /* 
           now ms points to the start of superblock
           that is 0x00000400+baseaddress
         */
	s->s_magic = ms->s_magic;

s->s_magic is 0x8f13 but not 0x138f due to the endian problem. so the magic number is wrong and the root fs mount fail.

if i make a minix fs image in a big endian machine, the image should be looked like this:

00000410h: 8f 13 00 01 00 00 00 00 00 00 00 00 00 00 00 00

is this correct? if yes, there is no problem any more.

Wang

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Seems correct after a quick glance.

Question 1: Why use minix?

If you really want minix I suggest you to improve the funcionality of it and add endian macros to it.

If you look at fs/fat/inode.c you see that the fat
code use macros like CF_LE_x to read variables from the structs that are mapped on the data from the disk.
So does ext2.
The CF_LE_x are translated to lexx_to_cpu in include/linux/msdos_fs.h where x is the size.

I would use ext2.

Cheers /

magnus

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/