ask for help

ask for help

[Wang Yong]

hi, 
        would you pls. do me a favor. i want to mount a smallest minix
on my ibm evaluation board(ppc401d2). it's big-endian, but i don't have 
a big-endian desktop such as PMAC or SPARC to make the minix fs image.
so, would you please make a fs image of minix(big-endian) with command
"dd" and mail it to me. i want only the file system itself, no files
contained in it.  if you have PMAC or any other big-endian desktop,
please.
        thank you in advance.

regards,
Wang


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

Re: ask for help

[Magnus Damm]

I don't know about minix, but I've made a ramdisk
with ext2 support on my x86 server and used it on a 8xx.

I've never experienced any endian problems with that.

That was a while ago though... Maybe things have changed..

Cheers /

magnus

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

Re: ask for help

[Magnus Damm]

 > 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

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/

Re: ask for help

[Wang Yong]

>    You read it out to register r3.
> 
>    r3 = 0xefbeadde - not the same 32bit value as on the x86!

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/

Re: ask for help

[Magnus Damm]

> 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.

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/