Re: Lost DOC2000 after installation of Grub

Re: Lost DOC2000 after installation of Grub

[Chris Fowler]

When I use root=(dc0,0) :

Error 23:  Erro parsing number.

But my root is not on the flash.  My root is /dev/ram7.  I have an initrd that loads data from fla1 into ram7.  Initrd temrinates then the kernel mounts /dev/ram7 as it root.

Lilo.conf:
boot=/dev/nftla
compact
#install=/boot/doc.b
map=/boot/map
disk=/dev/nftla
bios=0x80
prompt
delay = 50
timeout = 50
serial=0,9600n8

image = /boot/kernel
        label = outpost
        root = /dev/ram7
        initrd = /boot/initrd.gz
        read-only
        ramdisk=32768
        append="console=ttyS0,9600"

image = /boot/rtl8139.net
        label = net

I'm not concerned about serial console access.  How can I get the system up so I can try nftl_format?  Will I ever be able to use DFORMAT again?

Thanks,
Chris Fowler

strtok@hotmail said: > Now when it boots I get a grub propmt. I'm not sure what to do to 
> make the doc-lilo boot now. So I do not know what to type at grub
> root=(dc0,0) kernel=/boot/... 
> How do I revocer without replaceing the chip? Use nftl_format if DFORMAT won't work. 

Re: Lost DOC2000 after installation of Grub

[Ilguiz Latypov]

Chris,

It seems that you might need the /boot/grub/menu.lst file to enable 
automatic boot process.  There is GRUB documentation at

    http://www.gnu.org/manual/grub-0.90/html_mono/grub.html

According to your lilo.conf, you have the kernel and initrd.gz in the
/boot/ directory of a filesystem formatted on top of /dev/nftla.

This means you may need the menu.lst included below.  Long lines might get
wrapped by email agents.

I didn't try initrd ramdisks with GRUB myself, so that configuration is
not tested.  

Your GRUB bootloader must understand the filesystem which you installed on 
top of /dev/nftla block device layer.

It seems that no DoC drivers are strictly required when using initrd.  
The initial ramdisk gets loaded by the boot loader.  

The kernel parameter initrd is not processed by the kernel.  This
parameter is to inform bootloaders.  See kernel's

    Documentation/i386/boot.txt

The ramdisk_image and ramdisk_size parameters are to be added to the
kernel command line by the bootloader automatically.  See also

    Documentation/initrd.txt

Ilguiz

===================================================================
default=0
timeout=2
serial --speed=9600
terminal --timeout=2 serial console

title=Linux with serial console
root (dc0)
kernel /boot/kernel root=/dev/ram0 rw init=/linuxrc console=ttyS0,9600
initrd /boot/initrd.gz

title=Linux with video card and keyboard
root (dc0)
kernel /boot/kernel root=/dev/ram7 rw init=/linuxrc
initrd /boot/initrd.gz
===================================================================

On Wed, 6 Mar 2002, Chris Fowler wrote:

> When I use root=(dc0,0) :
> 
> Error 23:  Erro parsing number.

compr_zlib.c

[Joakim Tjernlund]

Hi all

I noticed that zlib.c by default adds a small header and a adler32 checksum to the compressed
data. This is not needed since JFFS2 adds it's own CRC32. There is an 'undocumented' way to 
avoid the header and adler32 checksum, specify a negative windowBits to deflateInit2()/inflateInit2().
Also it is possible to trim the memory usage by adjusting  windowBits and memLevel accordinly. I have
left these at their default values since I don't know zlib very well. Perhaps someone else can comment?

Also I wonder about STREAM_END_SPACE, which is defined to 12. Is it useful to try and compress
data as small as 13 bytes with zlib? Maybe the simpler rtime should be used for small amounts of
data?

Below is a patch against the stable 2.4 branch, which is backwards compatible.

        Jocke

PS.
     There has been a few improvements to JFFS2 that I would like to see in the stable 2.4 branch, we
     have been using these for about 2 weeks now and I think they are stable. 


Index: fs/jffs2/compr_zlib.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/compr_zlib.c,v
retrieving revision 1.8
diff -u -r1.8 compr_zlib.c
--- fs/jffs2/compr_zlib.c       2001/09/20 15:28:31     1.8
+++ fs/jffs2/compr_zlib.c       2002/03/11 08:31:35
@@ -31,7 +31,7 @@
  * provisions above, a recipient may use your version of this file
  * under either the RHEPL or the GPL.
  *
- * $Id: compr_zlib.c,v 1.8 2001/09/20 15:28:31 dwmw2 Exp $
+ * $Id: compr_zlib.c,v 1.8 2002/01/31 13:56:11 jocke Exp $
  *
  */

@@ -92,9 +92,21 @@
        strm.zalloc = (void *)0;
        strm.zfree = (void *)0;
 #endif
-
-       if (Z_OK != deflateInit(&strm, 3)) {
-               printk(KERN_WARNING "deflateInit failed\n");
+       /* The memory requirements for deflate are (in bytes):
+          1 << (windowBits+2)   +  1 << (memLevel+9)
+          that is: 128K for windowBits=15  +  128K for memLevel = 8  (default values)
+          plus a few kilobytes for small objects. For example, if you want to reduce
+          the default memory requirements from 256K to 128K, compile with
+              make CFLAGS="-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7"
+          Of course this will generally degrade compression (there's no free lunch).
+
+          The memory requirements for inflate are (in bytes) 1 << windowBits
+          that is, 32K for windowBits=15 (default value) plus a few kilobytes
+          for small objects.
+       */
+       /* -MAX_WBITS impiles -> suppress zlib header and adler32 */
+       if (Z_OK != deflateInit2(&strm, 3, Z_DEFLATED, -MAX_WBITS, 8, Z_DEFAULT_STRATEGY)) {
+               printk(KERN_WARNING "deflateInit2 failed\n");
                return -1;
        }
        strm.next_in = data_in;
@@ -142,7 +154,7 @@
                      __u32 srclen, __u32 destlen)
 {
        z_stream strm;
-       int ret;
+       int ret, wbits, i;

 #ifdef __KERNEL__
        strm.zalloc = zalloc;
@@ -151,23 +163,34 @@
        strm.zalloc = (void *)0;
        strm.zfree = (void *)0;
 #endif
-
-       if (Z_OK != inflateInit(&strm)) {
-               printk(KERN_WARNING "inflateInit failed\n");
-               return;
-       }
-       strm.next_in = data_in;
-       strm.avail_in = srclen;
-       strm.total_in = 0;
-
-       strm.next_out = cpage_out;
-       strm.avail_out = destlen;
-       strm.total_out = 0;
+       /* -MAX_WBITS impiles -> suppress zlib header and adler32.
+          try first with -MAX_WBITS, if that fails, try MAX_WBITS to be
+          backwards compatible */
+       wbits = -MAX_WBITS;
+       for(i = 0; i < 2; i++){
+               if (Z_OK != inflateInit2(&strm, wbits)) {
+                       printk(KERN_WARNING "inflateInit2 failed\n");
+                       return;
+               }
+               strm.next_in = data_in;
+               strm.avail_in = srclen;
+               strm.total_in = 0;
+
+               strm.next_out = cpage_out;
+               strm.avail_out = destlen;
+               strm.total_out = 0;
+
+               while((ret = inflate(&strm, Z_FINISH)) == Z_OK)
+                       ;
+               inflateEnd(&strm);
+               if (ret == Z_DATA_ERROR){
+                       wbits = -wbits;
+                       continue; /* try again with next wbits */
+               }

-       while((ret = inflate(&strm, Z_FINISH)) == Z_OK)
-               ;
-       if (ret != Z_STREAM_END) {
-               printk(KERN_NOTICE "inflate returned %d\n", ret);
+               if (ret != Z_STREAM_END) {
+                       printk(KERN_NOTICE "inflate returned %d, wbits: %d\n", ret, wbits);
+               }
+               break; /* all went well */
        }
-       inflateEnd(&strm);
 }

Re: compr_zlib.c

[Joakim Tjernlund]

No comments so far.
Anyone?

      Jocke

On Monday 11 March 2002 09.56, Joakim Tjernlund wrote:
> Hi all
>
> I noticed that zlib.c by default adds a small header and a adler32 checksum
> to the compressed data. This is not needed since JFFS2 adds it's own CRC32.
> There is an 'undocumented' way to avoid the header and adler32 checksum,
> specify a negative windowBits to deflateInit2()/inflateInit2(). Also it is
> possible to trim the memory usage by adjusting  windowBits and memLevel
> accordinly. I have left these at their default values since I don't know
> zlib very well. Perhaps someone else can comment?
>
> Also I wonder about STREAM_END_SPACE, which is defined to 12. Is it useful
> to try and compress data as small as 13 bytes with zlib? Maybe the simpler
> rtime should be used for small amounts of data?
>
> Below is a patch against the stable 2.4 branch, which is backwards
> compatible.
>
>         Jocke
>
> PS.
>      There has been a few improvements to JFFS2 that I would like to see in
> the stable 2.4 branch, we have been using these for about 2 weeks now and I
> think they are stable.
>
>
> Index: fs/jffs2/compr_zlib.c
> ===================================================================
> RCS file: /home/cvs/mtd/fs/jffs2/compr_zlib.c,v
> retrieving revision 1.8
> diff -u -r1.8 compr_zlib.c
> --- fs/jffs2/compr_zlib.c       2001/09/20 15:28:31     1.8
> +++ fs/jffs2/compr_zlib.c       2002/03/11 08:31:35
> @@ -31,7 +31,7 @@
>   * provisions above, a recipient may use your version of this file
>   * under either the RHEPL or the GPL.
>   *
> - * $Id: compr_zlib.c,v 1.8 2001/09/20 15:28:31 dwmw2 Exp $
> + * $Id: compr_zlib.c,v 1.8 2002/01/31 13:56:11 jocke Exp $
>   *
>   */
>
> @@ -92,9 +92,21 @@
>         strm.zalloc = (void *)0;
>         strm.zfree = (void *)0;
>  #endif
> -
> -       if (Z_OK != deflateInit(&strm, 3)) {
> -               printk(KERN_WARNING "deflateInit failed\n");
> +       /* The memory requirements for deflate are (in bytes):
> +          1 << (windowBits+2)   +  1 << (memLevel+9)
> +          that is: 128K for windowBits=15  +  128K for memLevel = 8 
> (default values) +          plus a few kilobytes for small objects. For
> example, if you want to reduce +          the default memory requirements
> from 256K to 128K, compile with +              make CFLAGS="-O
> -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7"
> +          Of course this will generally degrade compression (there's no
> free lunch). +
> +          The memory requirements for inflate are (in bytes) 1 <<
> windowBits +          that is, 32K for windowBits=15 (default value) plus a
> few kilobytes +          for small objects.
> +       */
> +       /* -MAX_WBITS impiles -> suppress zlib header and adler32 */
> +       if (Z_OK != deflateInit2(&strm, 3, Z_DEFLATED, -MAX_WBITS, 8,
> Z_DEFAULT_STRATEGY)) { +               printk(KERN_WARNING "deflateInit2
> failed\n");
>                 return -1;
>         }
>         strm.next_in = data_in;
> @@ -142,7 +154,7 @@
>                       __u32 srclen, __u32 destlen)
>  {
>         z_stream strm;
> -       int ret;
> +       int ret, wbits, i;
>
>  #ifdef __KERNEL__
>         strm.zalloc = zalloc;
> @@ -151,23 +163,34 @@
>         strm.zalloc = (void *)0;
>         strm.zfree = (void *)0;
>  #endif
> -
> -       if (Z_OK != inflateInit(&strm)) {
> -               printk(KERN_WARNING "inflateInit failed\n");
> -               return;
> -       }
> -       strm.next_in = data_in;
> -       strm.avail_in = srclen;
> -       strm.total_in = 0;
> -
> -       strm.next_out = cpage_out;
> -       strm.avail_out = destlen;
> -       strm.total_out = 0;
> +       /* -MAX_WBITS impiles -> suppress zlib header and adler32.
> +          try first with -MAX_WBITS, if that fails, try MAX_WBITS to be
> +          backwards compatible */
> +       wbits = -MAX_WBITS;
> +       for(i = 0; i < 2; i++){
> +               if (Z_OK != inflateInit2(&strm, wbits)) {
> +                       printk(KERN_WARNING "inflateInit2 failed\n");
> +                       return;
> +               }
> +               strm.next_in = data_in;
> +               strm.avail_in = srclen;
> +               strm.total_in = 0;
> +
> +               strm.next_out = cpage_out;
> +               strm.avail_out = destlen;
> +               strm.total_out = 0;
> +
> +               while((ret = inflate(&strm, Z_FINISH)) == Z_OK)
> +                       ;
> +               inflateEnd(&strm);
> +               if (ret == Z_DATA_ERROR){
> +                       wbits = -wbits;
> +                       continue; /* try again with next wbits */
> +               }
>
> -       while((ret = inflate(&strm, Z_FINISH)) == Z_OK)
> -               ;
> -       if (ret != Z_STREAM_END) {
> -               printk(KERN_NOTICE "inflate returned %d\n", ret);
> +               if (ret != Z_STREAM_END) {
> +                       printk(KERN_NOTICE "inflate returned %d, wbits:
> %d\n", ret, wbits); +               }
> +               break; /* all went well */
>         }
> -       inflateEnd(&strm);
>  }

Re: compr_zlib.c

[David Woodhouse]

On Tue, 19 Mar 2002, Joakim Tjernlund wrote:

> No comments so far.
> Anyone?

Looks good. Suspect we should make it a new compression type instead, and 
fix the mount routine to check for compression types we don't support, 
like we check for node types we don't support.

-- 
dwmw2

compr_zlib.c

[Joakim Tjernlund]

OK, a new compression type will be cleaner. What should be done with compression types 
not supported? Can't say that I understand the logic behind the unsupported nodes. 

What do you think about STREAM_END_SPACE? Should it be changed to something bigger?

What is the maximum amount of data JFFS2 will try to compress in one go? I am
thinking of adjusting  windowBits and memLevel, now they default to 128 KB each which
seems a bit too much.

Will you accept a patch against the stable branch?

Also there has been a few performance improvements lately and I would like to see them in the
stable branch as well. We are using them all and no problems so far. Any chance that will
happen?


       Jocke

On Tue, 19 Mar 2002, Joakim Tjernlund wrote:

> No comments so far.
> Anyone?

Looks good. Suspect we should make it a new compression type instead, and 
fix the mount routine to check for compression types we don't support, 
like we check for node types we don't support.

-- 
dwmw2

Re: compr_zlib.c

[David Woodhouse]

Joakim.Tjernlund@lumentis.se said:
> OK, a new compression type will be cleaner. What should be done with
> compression types  not supported? Can't say that I understand the
> logic behind the unsupported nodes. 

I think we should mount the filesystem read only. We're going to get I/O 
errors on parts of files that we can't decompress.

> What do you think about STREAM_END_SPACE? Should it be changed to
> something bigger? 

STREAM_END_SPACE is supposed to be the amount of space we need at the end 
of the output buffer to sync up and complete the output. I suspect we 
should just use a different limit for the minimum amount of data we'll 
bother to compress.

> What is the maximum amount of data JFFS2 will try to compress in one
> go? 

One page - normally 4KiB, sometimes 8KiB. I've been pondering changing that 
to get better compression but that might break compatibility so it'd have 
to be an obvious win.

> I am thinking of adjusting  windowBits and memLevel, now they
> default to 128 KB each which seems a bit too much.

Sounds reasonable. Would that mean we can also reduce the amount of memory 
preallocated for the deflate workspace, which is currently about 400KiB?

> Will you accept a patch against the stable branch?

> Also there has been a few performance improvements lately and I would
> like to see them in the stable branch as well. We are using them all
> and no problems so far. Any chance that will happen? 

I would rather not change the stable branch. That sort of defeats the 
object of having it in the first place. There are three types of changes in 
the trunk since that branch was taken:
	1. Cosmetic changes and code reshuffles for eCos portability.
	   These shouldn't affect functionality at all.
	2. NAND support, which shouldn't affect NOR flash adversely.
	3. The aforementioned performance enhancements.

If you want to use the performance enhancements, I'd rather you worked on, 
and tested, the trunk code. 

--
dwmw2

RE: compr_zlib.c

[Joakim Tjernlund]

> 
> Joakim.Tjernlund@lumentis.se said:
> > OK, a new compression type will be cleaner. What should be done with
> > compression types  not supported? Can't say that I understand the
> > logic behind the unsupported nodes. 
> 
> I think we should mount the filesystem read only. We're going to get I/O 
> errors on parts of files that we can't decompress.

Sounds resonable.
> 
> > What do you think about STREAM_END_SPACE? Should it be changed to
> > something bigger? 
> 
> STREAM_END_SPACE is supposed to be the amount of space we need at the end 
> of the output buffer to sync up and complete the output. I suspect we 
> should just use a different limit for the minimum amount of data we'll 
> bother to compress.

OK, somethink like a 100 bytes maybe.
> 
> > What is the maximum amount of data JFFS2 will try to compress in one
> > go? 
> 
> One page - normally 4KiB, sometimes 8KiB. I've been pondering changing that 
> to get better compression but that might break compatibility so it'd have 
> to be an obvious win.
> 
> > I am thinking of adjusting  windowBits and memLevel, now they
> > default to 128 KB each which seems a bit too much.
> 
> Sounds reasonable. Would that mean we can also reduce the amount of memory 
> preallocated for the deflate workspace, which is currently about 400KiB?

Yes, read the big comment(from zlib) in my patch:
 /*
  The memory requirements for deflate are (in bytes):
        1 << (windowBits+2)   +  1 << (memLevel+9)
         that is: 128K for windowBits=15  +  128K for memLevel = 8 
  (default values) plus a few kilobytes for small objects. For
   example, if you want to reduce the default memory requirements
   from 256K to 128K, compile with make CFLAGS="-O -DMAX_WBITS=14 -DMAX_MEM_LEVEL=7"

  Of course this will generally degrade compression (there's no free lunch).
  The memory requirements for inflate are (in bytes) 1 <<
  windowBits that is, 32K for windowBits=15 (default value) plus a
  few kilobytes for small objects.
  */

> 
> > Will you accept a patch against the stable branch?
> 
> > Also there has been a few performance improvements lately and I would
> > like to see them in the stable branch as well. We are using them all
> > and no problems so far. Any chance that will happen? 
> 
> I would rather not change the stable branch. That sort of defeats the 
> object of having it in the first place. There are three types of changes in 
> the trunk since that branch was taken:
> 	1. Cosmetic changes and code reshuffles for eCos portability.
> 	   These shouldn't affect functionality at all.
> 	2. NAND support, which shouldn't affect NOR flash adversely.
> 	3. The aforementioned performance enhancements.
> 
> If you want to use the performance enhancements, I'd rather you worked on, 
> and tested, the trunk code. 

I think 1 and 2 are too risky to put in a production system at the moment. Hmm, maybe its best
to leave this patch out of the stable branch anyway since it affects the on flash format.

   Jocke