[uClinux-dev] romfs problem

Greg Ungerer gerg at snapgear.com
Mon Nov 26 20:02:35 EST 2001


Hi Jennifer,

Jennifer wrote:
> My CPU is Samsung s3c4510 (ARM7TDMI). My kernel is 2.0.38 and the development environment was gotten from the EB40 development CD. My start_kernel() seems fine and the blkmem_init() was called. While it read the romfs, the probelm happened. The arena[0].length will be very large because the code was compiled into the little-endian. The code in the memory are "00 02 CD 50" and after the translated to long it will become 0x50cd0200. It extend my ROM limitation. If the value is translated into 0x02cd50, it match the length of the romdisk.img.  from the "genromfs" manual page, it points that there is endian bug. Does it mean this bug? If so, does I need to modify the blkmem_init() function? If so, why my EB40 evaluation board does not have such problem? Could anyone tell me how should I handle the probelm?
> 
> The content of the romdisk.img are
> 2D 72 6F 6D 31 66 73 2D 00 02 CD 50 0A 6B 8B 52 4F 4D 20 ...
> 
> int
> blkmem_init( void )
> {
>   .....
>   for(i=0;i<arenas;i++) {
>     if (arena[i].length == -1)
>       arena[i].length = *(volatile unsigned long *)(arena[i].address + 8);

This appears to be a bug in the 2.0.x blkmem.c.

The blkmem.c in 2.4.x has:
      
 arena[i].length = ntohl(*(volatile unsigned long
*)(arena[i].address+8));

So it doesn't suffer the same problem. I would make this same
change in your blkmem.c

Regards
Greg


------------------------------------------------------------------------
Greg Ungerer  --  Chief Software Wizard        EMAIL:  gerg at snapgear.com
SnapGear                                       PHONE:    +61 7 3435 2888
825 Stanley St,                                  FAX:    +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia              WEB:   www.snapgear.com
This message resent by the uclinux-dev at uclinux.org list server http://www.uClinux.org/



More information about the uClinux-dev mailing list