[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Petter Larsen]

Hello

We have enabled JFFS2 in PPCBoot 2.0.

We can then for example use "fsload" to load a file into memory. But how
can we use this feature if we wont to boot the kernel, lying in this
filesystem, with "bootm".

We use a AMD flash device. In the kernel we have enabled the CFI in the
MTD options, and enabled JFFS2.

Best regards
Petter Larsen

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Kenneth Johansson]

On Tue, 2003-03-04 at 15:47, Petter Larsen wrote:
> Hello
> 
> We have enabled JFFS2 in PPCBoot 2.0.
> 
> We can then for example use "fsload" to load a file into memory. But how
> can we use this feature if we wont to boot the kernel, lying in this
> filesystem, with "bootm".
> 
> We use a AMD flash device. In the kernel we have enabled the CFI in the
> MTD options, and enabled JFFS2.
> 

I'm confused. you load the kernel into memory with fsload then you start
that kernel with bootm. What's the problem?

-- 
Kenneth Johansson	
Ericsson AB                       Tel: +46 8 719 70 20
Tellusborgsv?gen  90              Fax: +46 8 719 29 45
126 25 Stockholm                  ken at switchboard.ericsson.se

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <1046789264.1140.173.camel@pla> you wrote:
> 
> We can then for example use "fsload" to load a file into memory. But how
> can we use this feature if we wont to boot the kernel, lying in this
> filesystem, with "bootm".

Can you please explain the problem again? When you can  use  "fsload"
to  load  a file into memory, what prevents you from using "bootm" to
boot it, then?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
This all sounds complicated, but it mostly does excatly what you  ex-
pect. It's just difficult for us to explain what you expect...
                       - L. Wall & R. L. Schwartz, _Programming Perl_

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Robert Schwebel]

On Tue, Mar 04, 2003 at 03:47:45PM +0100, Petter Larsen wrote:
> We have enabled JFFS2 in PPCBoot 2.0.
> 
> We can then for example use "fsload" to load a file into memory. But how
> can we use this feature if we wont to boot the kernel, lying in this
> filesystem, with "bootm".
> 
> We use a AMD flash device. In the kernel we have enabled the CFI in the
> MTD options, and enabled JFFS2.

I don't understand your question; if your kernel is on a jffs2
partition it is the right way to load it with fsload! What else do you
want to do, additional to loading the kernel and booting it? 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Petter Larsen]

Hello

I got it. I was just to simple:-)
But is it possible to boot it directly from the filesystem and not load
it into memory first?



Best regards
Petter Larsen
moreCom as

On Tue, 2003-03-04 at 16:42, Kenneth Johansson wrote:
> On Tue, 2003-03-04 at 15:47, Petter Larsen wrote:
> > Hello
> > 
> > We have enabled JFFS2 in PPCBoot 2.0.
> > 
> > We can then for example use "fsload" to load a file into memory. But how
> > can we use this feature if we wont to boot the kernel, lying in this
> > filesystem, with "bootm".
> > 
> > We use a AMD flash device. In the kernel we have enabled the CFI in the
> > MTD options, and enabled JFFS2.
> > 
> 
> I'm confused. you load the kernel into memory with fsload then you start
> that kernel with bootm. What's the problem?

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Kenneth Johansson]

On Tue, 2003-03-04 at 17:50, Petter Larsen wrote:
> Hello
> 
> I got it. I was just to simple:-)
> But is it possible to boot it directly from the filesystem and not load
> it into memory first?

No the file is not a continuous block of data so it can't be done.  

-- 
Kenneth Johansson	
Ericsson AB                       Tel: +46 8 719 70 20
Tellusborgsv?gen  90              Fax: +46 8 719 29 45
126 25 Stockholm                  ken at switchboard.ericsson.se

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Robert Schwebel]

On Tue, Mar 04, 2003 at 05:50:52PM +0100, Petter Larsen wrote:
> I got it. I was just to simple:-) But is it possible to boot it
> directly from the filesystem and not load it into memory first?

What's the problem with two commands instead of one? You have to load
the kernel into memory anyway. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Braunschweiger Str. 79,  31134 Hildesheim, Germany
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <20030304170121.GL3593@pengutronix.de> you wrote:
>
> > I got it. I was just to simple:-) But is it possible to boot it
> > directly from the filesystem and not load it into memory first?
> 
> What's the problem with two commands instead of one? You have to load
> the kernel into memory anyway. 

Well, having to deal a lot with customers who want to  minimize  boot
times  I can see the argument that you have an additional memcpy here
- but then, when boot time matters, you should not use JFFS2 to store
the kernel image in the first place.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The biggest difference between time and space is that you can't reuse
time.                                                 - Merrick Furst

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> In message <20030304170121.GL3593@pengutronix.de> you wrote:
> >
> > > I got it. I was just to simple:-) But is it possible to boot it
> > > directly from the filesystem and not load it into memory first?
> > 
> > What's the problem with two commands instead of one? You have to load
> > the kernel into memory anyway. 
> 
> Well, having to deal a lot with customers who want to  minimize  boot
> times  I can see the argument that you have an additional memcpy here
> - but then, when boot time matters, you should not use JFFS2 to store
> the kernel image in the first place.

Optimizing crc32 will probably help a bit. I have pushed some optimiziations into
linux 2.5(lib/crc32.c & friends) that is much faster. I also moved these into my ppcboot, 1.05.
If someone wants, I can send my ppc/crc32.c file. It should be very easy to move these into u-boot.

  Jocke 

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Petter Larsen]

Is there a similar method if I use Compact Flash and a more generic 
filesystem like ext2, ext3 or  Reiserfs

Best regards
Petter Larsen
moreCom as

On Tue, 2003-03-04 at 17:59, Kenneth Johansson wrote:
> On Tue, 2003-03-04 at 17:50, Petter Larsen wrote:
> > Hello
> > 
> > I got it. I was just to simple:-)
> > But is it possible to boot it directly from the filesystem and not load
> > it into memory first?
> 
> No the file is not a continuous block of data so it can't be done.  

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLMEMMFKAA.joakim.tjernlund@lumentis.se> you wrote:
>
> > Well, having to deal a lot with customers who want to  minimize  boot
> > times  I can see the argument that you have an additional memcpy here
> > - but then, when boot time matters, you should not use JFFS2 to store
> > the kernel image in the first place.
> 
> Optimizing crc32 will probably help a bit. I have pushed some optimiziations into

No. We're not talking about optimizing a few percent. When  you  have
to  have  the  application  up and running within 5 or even 3 seconds
after power-on you have to pay some price. You cannot afford  to  use
compression,  and  even  a  highly optimized CRC over an uncompressed
kernel image takes nearly as long as the uncompress would.

I think you cannot beat the speed of loading an  uncompressed  kernel
image  from  flash (raw memory, no filesystem), with CRC verification
turned off. If security plays a role, you  can  (and  will  have  to)
verify the in-flash image later, when you are up and running :-) ]

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Never worry about theory as long as  the  machinery  does  what  it's
supposed to do.                                      - R. A. Heinlein

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLMEMMFKAA.joakim.tjernlund@lumentis.se> you wrote:
>
> Optimizing crc32 will probably help a bit. I have pushed some optimiziations into
> linux 2.5(lib/crc32.c & friends) that is much faster. I also moved these into my ppcboot, 1.05.
> If someone wants, I can send my ppc/crc32.c file. It should be very easy to move these into u-boot.

...ummmm - please do'nt get me wrong: of course I do  appreciate  any
optimizations  you  may  have  for  the CRC32 code. Just send a patch
against the current source.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Use the Force, Luke.

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <1046801107.1192.34.camel@pla> you wrote:
>
> Is there a similar method if I use Compact Flash and a more generic 

Yes, of course. You did read the DPLG?

It shows in detail how to use the "diskboot" command to load an image
from a partition on any IDE device  (harddisk,  CompactFlash,  memory
Stick,  ...).  You  can  then  use  "bootm"  to boot it - except that
"diskboot" knows and  pays  regard  to  the  "autostart"  environment
variable.

Please read the docs.

> filesystem like ext2, ext3 or  Reiserfs

No. Not unless you implement some filesystem code (but then please do
it as a standalone program, something like a second  stage  bootstrap
loader;  I don't like the way how the JFFS2 code is egrafted onto the
other U-Boot code - it breakds the design philosophy).


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Little known fact about Middle Earth:   The Hobbits had a very sophi-
sticated computer network!   It was a Tolkien Ring...

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> No. We're not talking about optimizing a few percent. When  you  have
> to  have  the  application  up and running within 5 or even 3 seconds
> after power-on you have to pay some price. You cannot afford  to  use
> compression,  and  even  a  highly optimized CRC over an uncompressed
> kernel image takes nearly as long as the uncompress would.
> 
> I think you cannot beat the speed of loading an  uncompressed  kernel
> image  from  flash (raw memory, no filesystem), with CRC verification
> turned off. If security plays a role, you  can  (and  will  have  to)
> verify the in-flash image later, when you are up and running :-) ]

Of course, but it's always nice to save a little time even if you can afford
a long boot time. You can probly also save some decompression time if you
choose a lower compression level(gzip -3) especially if port current zlib impl.
in linux which uses precompted lookup tables.

 > ...ummmm - please do'nt get me wrong: of course I do  appreciate  any
> optimizations  you  may  have  for  the CRC32 code. Just send a patch
> against the current source.

That was/is my plan, but since I am still in ppcboot and will be for some time I
offer to send it as is if someone is in a hurry and willing to do the integration with
u-boot. Just let me know.

      Jocke

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <003501c2e295$7f8cbed0$020120b0@jockeXP> you wrote:
>
> That was/is my plan, but since I am still in ppcboot and will be for some time I
> offer to send it as is if someone is in a hurry and willing to do the integration with
> u-boot. Just let me know.

The crc32.c in the top-of-tree version of U-Boot and that in  PPCBoot
are  identical;  I  think  the  last  change  to that file was before
PPCBoot-0.4.4 (July 2000).

A patch against any semi-recent version will do.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
When a program is being  tested,  it  is  too  late  to  make  design
changes.                  -- Geoffrey James, "The Tao of Programming"

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> >
> > That was/is my plan, but since I am still in ppcboot and will be for some time I
> > offer to send it as is if someone is in a hurry and willing to do the integration with
> > u-boot. Just let me know.
> 
> The crc32.c in the top-of-tree version of U-Boot and that in  PPCBoot
> are  identical;  I  think  the  last  change  to that file was before
> PPCBoot-0.4.4 (July 2000).
> 
> A patch against any semi-recent version will do.

I will have a look, but I can't test it in u-boot so you will have to do it, OK?

 Jocke 

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <004701c2e29a$a280b4a0$020120b0@jockeXP> you wrote:
>
> I will have a look, but I can't test it in u-boot so you will have to do it, OK?

Sure. I hope the code is not much bigger, though.  That  might  be  a
killing point.


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Everybody is talking about the  weather  but  nobody  does  anything
about it."                                               - Mark Twain

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> In message <004701c2e29a$a280b4a0$020120b0@jockeXP> you wrote:
> >
> > I will have a look, but I can't test it in u-boot so you will have to do it, OK?
> 
> Sure. I hope the code is not much bigger, though.  That  might  be  a
> killing point.

OK, here it is. It compiles, but generates alot of warnings.
I had made some clenups as well.
Don't think the size is to bad but judge for your self

 Jocke

--- lib_generic/crc32.c.old	Tue Mar  4 23:39:48 2003
+++ lib_generic/crc32.c	Wed Mar  5 00:00:14 2003
@@ -11,18 +11,14 @@
 #ifndef USE_HOSTCC	/* Shut down "ANSI does not permit..." warnings */
 #include <common.h>	/* to get command definitions like CFG_CMD_JFFS2 */
 #endif
-
-#include "zlib.h"
-
-#define local static
-#define ZEXPORT	/* empty */
-unsigned long crc32 (unsigned long, const unsigned char *, unsigned int);
+#include "asm/types.h"
+#include "asm/byteorder.h"
 
 #ifdef DYNAMIC_CRC_TABLE
 
-local int crc_table_empty = 1;
-local uLongf crc_table[256];
-local void make_crc_table OF((void));
+static int crc_table_empty = 1;
+static __u32 crc_table[256];
+static void make_crc_table (void);
 
 /*
   Generate a table for a byte-wise 32-bit CRC calculation on the polynomial:
@@ -48,13 +44,13 @@ local void make_crc_table OF((void));
   the information needed to generate CRC's on data a byte at a time for all
   combinations of CRC register values and incoming bytes.
 */
-local void make_crc_table()
+static void make_crc_table()
 {
-  uLong c;
+  __u32 c;
   int n, k;
-  uLong poly;            /* polynomial exclusive-or pattern */
+  __u32 poly;            /* polynomial exclusive-or pattern */
   /* terms of polynomial defining this crc (except x^32): */
-  static const Byte p[] = {0,1,2,4,5,7,8,10,11,12,16,22,23,26};
+  static const __u8 p[] = {0,1,2,4,5,7,8,10,11,12,16,22,23,26};
 
   /* make exclusive-or pattern from polynomial (0xedb88320L) */
   poly = 0L;
@@ -63,10 +59,10 @@ local void make_crc_table()
 
   for (n = 0; n < 256; n++)
   {
-    c = (uLong)n;
+    c = (__u32)n;
     for (k = 0; k < 8; k++)
       c = c & 1 ? poly ^ (c >> 1) : c >> 1;
-    crc_table[n] = c;
+    crc_table[n] = __cpu_to_le32(c);
   }
   crc_table_empty = 0;
 }
@@ -74,59 +70,60 @@ local void make_crc_table()
 /* ========================================================================
  * Table of CRC-32's of all single-byte values (made by make_crc_table)
  */
-local const uLongf crc_table[256] = {
-  0x00000000L, 0x77073096L, 0xee0e612cL, 0x990951baL, 0x076dc419L,
-  0x706af48fL, 0xe963a535L, 0x9e6495a3L, 0x0edb8832L, 0x79dcb8a4L,
-  0xe0d5e91eL, 0x97d2d988L, 0x09b64c2bL, 0x7eb17cbdL, 0xe7b82d07L,
-  0x90bf1d91L, 0x1db71064L, 0x6ab020f2L, 0xf3b97148L, 0x84be41deL,
-  0x1adad47dL, 0x6ddde4ebL, 0xf4d4b551L, 0x83d385c7L, 0x136c9856L,
-  0x646ba8c0L, 0xfd62f97aL, 0x8a65c9ecL, 0x14015c4fL, 0x63066cd9L,
-  0xfa0f3d63L, 0x8d080df5L, 0x3b6e20c8L, 0x4c69105eL, 0xd56041e4L,
-  0xa2677172L, 0x3c03e4d1L, 0x4b04d447L, 0xd20d85fdL, 0xa50ab56bL,
-  0x35b5a8faL, 0x42b2986cL, 0xdbbbc9d6L, 0xacbcf940L, 0x32d86ce3L,
-  0x45df5c75L, 0xdcd60dcfL, 0xabd13d59L, 0x26d930acL, 0x51de003aL,
-  0xc8d75180L, 0xbfd06116L, 0x21b4f4b5L, 0x56b3c423L, 0xcfba9599L,
-  0xb8bda50fL, 0x2802b89eL, 0x5f058808L, 0xc60cd9b2L, 0xb10be924L,
-  0x2f6f7c87L, 0x58684c11L, 0xc1611dabL, 0xb6662d3dL, 0x76dc4190L,
-  0x01db7106L, 0x98d220bcL, 0xefd5102aL, 0x71b18589L, 0x06b6b51fL,
-  0x9fbfe4a5L, 0xe8b8d433L, 0x7807c9a2L, 0x0f00f934L, 0x9609a88eL,
-  0xe10e9818L, 0x7f6a0dbbL, 0x086d3d2dL, 0x91646c97L, 0xe6635c01L,
-  0x6b6b51f4L, 0x1c6c6162L, 0x856530d8L, 0xf262004eL, 0x6c0695edL,
-  0x1b01a57bL, 0x8208f4c1L, 0xf50fc457L, 0x65b0d9c6L, 0x12b7e950L,
-  0x8bbeb8eaL, 0xfcb9887cL, 0x62dd1ddfL, 0x15da2d49L, 0x8cd37cf3L,
-  0xfbd44c65L, 0x4db26158L, 0x3ab551ceL, 0xa3bc0074L, 0xd4bb30e2L,
-  0x4adfa541L, 0x3dd895d7L, 0xa4d1c46dL, 0xd3d6f4fbL, 0x4369e96aL,
-  0x346ed9fcL, 0xad678846L, 0xda60b8d0L, 0x44042d73L, 0x33031de5L,
-  0xaa0a4c5fL, 0xdd0d7cc9L, 0x5005713cL, 0x270241aaL, 0xbe0b1010L,
-  0xc90c2086L, 0x5768b525L, 0x206f85b3L, 0xb966d409L, 0xce61e49fL,
-  0x5edef90eL, 0x29d9c998L, 0xb0d09822L, 0xc7d7a8b4L, 0x59b33d17L,
-  0x2eb40d81L, 0xb7bd5c3bL, 0xc0ba6cadL, 0xedb88320L, 0x9abfb3b6L,
-  0x03b6e20cL, 0x74b1d29aL, 0xead54739L, 0x9dd277afL, 0x04db2615L,
-  0x73dc1683L, 0xe3630b12L, 0x94643b84L, 0x0d6d6a3eL, 0x7a6a5aa8L,
-  0xe40ecf0bL, 0x9309ff9dL, 0x0a00ae27L, 0x7d079eb1L, 0xf00f9344L,
-  0x8708a3d2L, 0x1e01f268L, 0x6906c2feL, 0xf762575dL, 0x806567cbL,
-  0x196c3671L, 0x6e6b06e7L, 0xfed41b76L, 0x89d32be0L, 0x10da7a5aL,
-  0x67dd4accL, 0xf9b9df6fL, 0x8ebeeff9L, 0x17b7be43L, 0x60b08ed5L,
-  0xd6d6a3e8L, 0xa1d1937eL, 0x38d8c2c4L, 0x4fdff252L, 0xd1bb67f1L,
-  0xa6bc5767L, 0x3fb506ddL, 0x48b2364bL, 0xd80d2bdaL, 0xaf0a1b4cL,
-  0x36034af6L, 0x41047a60L, 0xdf60efc3L, 0xa867df55L, 0x316e8eefL,
-  0x4669be79L, 0xcb61b38cL, 0xbc66831aL, 0x256fd2a0L, 0x5268e236L,
-  0xcc0c7795L, 0xbb0b4703L, 0x220216b9L, 0x5505262fL, 0xc5ba3bbeL,
-  0xb2bd0b28L, 0x2bb45a92L, 0x5cb36a04L, 0xc2d7ffa7L, 0xb5d0cf31L,
-  0x2cd99e8bL, 0x5bdeae1dL, 0x9b64c2b0L, 0xec63f226L, 0x756aa39cL,
-  0x026d930aL, 0x9c0906a9L, 0xeb0e363fL, 0x72076785L, 0x05005713L,
-  0x95bf4a82L, 0xe2b87a14L, 0x7bb12baeL, 0x0cb61b38L, 0x92d28e9bL,
-  0xe5d5be0dL, 0x7cdcefb7L, 0x0bdbdf21L, 0x86d3d2d4L, 0xf1d4e242L,
-  0x68ddb3f8L, 0x1fda836eL, 0x81be16cdL, 0xf6b9265bL, 0x6fb077e1L,
-  0x18b74777L, 0x88085ae6L, 0xff0f6a70L, 0x66063bcaL, 0x11010b5cL,
-  0x8f659effL, 0xf862ae69L, 0x616bffd3L, 0x166ccf45L, 0xa00ae278L,
-  0xd70dd2eeL, 0x4e048354L, 0x3903b3c2L, 0xa7672661L, 0xd06016f7L,
-  0x4969474dL, 0x3e6e77dbL, 0xaed16a4aL, 0xd9d65adcL, 0x40df0b66L,
-  0x37d83bf0L, 0xa9bcae53L, 0xdebb9ec5L, 0x47b2cf7fL, 0x30b5ffe9L,
-  0xbdbdf21cL, 0xcabac28aL, 0x53b39330L, 0x24b4a3a6L, 0xbad03605L,
-  0xcdd70693L, 0x54de5729L, 0x23d967bfL, 0xb3667a2eL, 0xc4614ab8L,
-  0x5d681b02L, 0x2a6f2b94L, 0xb40bbe37L, 0xc30c8ea1L, 0x5a05df1bL,
-  0x2d02ef8dL
+#define tole(x) __constant_cpu_to_le32(x)
+static const __u32 crc_table[256] = {
+  tole(0x00000000L), tole(0x77073096L), tole(0xee0e612cL), tole(0x990951baL), tole(0x076dc419L),
+  tole(0x706af48fL), tole(0xe963a535L), tole(0x9e6495a3L), tole(0x0edb8832L), tole(0x79dcb8a4L),
+  tole(0xe0d5e91eL), tole(0x97d2d988L), tole(0x09b64c2bL), tole(0x7eb17cbdL), tole(0xe7b82d07L),
+  tole(0x90bf1d91L), tole(0x1db71064L), tole(0x6ab020f2L), tole(0xf3b97148L), tole(0x84be41deL),
+  tole(0x1adad47dL), tole(0x6ddde4ebL), tole(0xf4d4b551L), tole(0x83d385c7L), tole(0x136c9856L),
+  tole(0x646ba8c0L), tole(0xfd62f97aL), tole(0x8a65c9ecL), tole(0x14015c4fL), tole(0x63066cd9L),
+  tole(0xfa0f3d63L), tole(0x8d080df5L), tole(0x3b6e20c8L), tole(0x4c69105eL), tole(0xd56041e4L),
+  tole(0xa2677172L), tole(0x3c03e4d1L), tole(0x4b04d447L), tole(0xd20d85fdL), tole(0xa50ab56bL),
+  tole(0x35b5a8faL), tole(0x42b2986cL), tole(0xdbbbc9d6L), tole(0xacbcf940L), tole(0x32d86ce3L),
+  tole(0x45df5c75L), tole(0xdcd60dcfL), tole(0xabd13d59L), tole(0x26d930acL), tole(0x51de003aL),
+  tole(0xc8d75180L), tole(0xbfd06116L), tole(0x21b4f4b5L), tole(0x56b3c423L), tole(0xcfba9599L),
+  tole(0xb8bda50fL), tole(0x2802b89eL), tole(0x5f058808L), tole(0xc60cd9b2L), tole(0xb10be924L),
+  tole(0x2f6f7c87L), tole(0x58684c11L), tole(0xc1611dabL), tole(0xb6662d3dL), tole(0x76dc4190L),
+  tole(0x01db7106L), tole(0x98d220bcL), tole(0xefd5102aL), tole(0x71b18589L), tole(0x06b6b51fL),
+  tole(0x9fbfe4a5L), tole(0xe8b8d433L), tole(0x7807c9a2L), tole(0x0f00f934L), tole(0x9609a88eL),
+  tole(0xe10e9818L), tole(0x7f6a0dbbL), tole(0x086d3d2dL), tole(0x91646c97L), tole(0xe6635c01L),
+  tole(0x6b6b51f4L), tole(0x1c6c6162L), tole(0x856530d8L), tole(0xf262004eL), tole(0x6c0695edL),
+  tole(0x1b01a57bL), tole(0x8208f4c1L), tole(0xf50fc457L), tole(0x65b0d9c6L), tole(0x12b7e950L),
+  tole(0x8bbeb8eaL), tole(0xfcb9887cL), tole(0x62dd1ddfL), tole(0x15da2d49L), tole(0x8cd37cf3L),
+  tole(0xfbd44c65L), tole(0x4db26158L), tole(0x3ab551ceL), tole(0xa3bc0074L), tole(0xd4bb30e2L),
+  tole(0x4adfa541L), tole(0x3dd895d7L), tole(0xa4d1c46dL), tole(0xd3d6f4fbL), tole(0x4369e96aL),
+  tole(0x346ed9fcL), tole(0xad678846L), tole(0xda60b8d0L), tole(0x44042d73L), tole(0x33031de5L),
+  tole(0xaa0a4c5fL), tole(0xdd0d7cc9L), tole(0x5005713cL), tole(0x270241aaL), tole(0xbe0b1010L),
+  tole(0xc90c2086L), tole(0x5768b525L), tole(0x206f85b3L), tole(0xb966d409L), tole(0xce61e49fL),
+  tole(0x5edef90eL), tole(0x29d9c998L), tole(0xb0d09822L), tole(0xc7d7a8b4L), tole(0x59b33d17L),
+  tole(0x2eb40d81L), tole(0xb7bd5c3bL), tole(0xc0ba6cadL), tole(0xedb88320L), tole(0x9abfb3b6L),
+  tole(0x03b6e20cL), tole(0x74b1d29aL), tole(0xead54739L), tole(0x9dd277afL), tole(0x04db2615L),
+  tole(0x73dc1683L), tole(0xe3630b12L), tole(0x94643b84L), tole(0x0d6d6a3eL), tole(0x7a6a5aa8L),
+  tole(0xe40ecf0bL), tole(0x9309ff9dL), tole(0x0a00ae27L), tole(0x7d079eb1L), tole(0xf00f9344L),
+  tole(0x8708a3d2L), tole(0x1e01f268L), tole(0x6906c2feL), tole(0xf762575dL), tole(0x806567cbL),
+  tole(0x196c3671L), tole(0x6e6b06e7L), tole(0xfed41b76L), tole(0x89d32be0L), tole(0x10da7a5aL),
+  tole(0x67dd4accL), tole(0xf9b9df6fL), tole(0x8ebeeff9L), tole(0x17b7be43L), tole(0x60b08ed5L),
+  tole(0xd6d6a3e8L), tole(0xa1d1937eL), tole(0x38d8c2c4L), tole(0x4fdff252L), tole(0xd1bb67f1L),
+  tole(0xa6bc5767L), tole(0x3fb506ddL), tole(0x48b2364bL), tole(0xd80d2bdaL), tole(0xaf0a1b4cL),
+  tole(0x36034af6L), tole(0x41047a60L), tole(0xdf60efc3L), tole(0xa867df55L), tole(0x316e8eefL),
+  tole(0x4669be79L), tole(0xcb61b38cL), tole(0xbc66831aL), tole(0x256fd2a0L), tole(0x5268e236L),
+  tole(0xcc0c7795L), tole(0xbb0b4703L), tole(0x220216b9L), tole(0x5505262fL), tole(0xc5ba3bbeL),
+  tole(0xb2bd0b28L), tole(0x2bb45a92L), tole(0x5cb36a04L), tole(0xc2d7ffa7L), tole(0xb5d0cf31L),
+  tole(0x2cd99e8bL), tole(0x5bdeae1dL), tole(0x9b64c2b0L), tole(0xec63f226L), tole(0x756aa39cL),
+  tole(0x026d930aL), tole(0x9c0906a9L), tole(0xeb0e363fL), tole(0x72076785L), tole(0x05005713L),
+  tole(0x95bf4a82L), tole(0xe2b87a14L), tole(0x7bb12baeL), tole(0x0cb61b38L), tole(0x92d28e9bL),
+  tole(0xe5d5be0dL), tole(0x7cdcefb7L), tole(0x0bdbdf21L), tole(0x86d3d2d4L), tole(0xf1d4e242L),
+  tole(0x68ddb3f8L), tole(0x1fda836eL), tole(0x81be16cdL), tole(0xf6b9265bL), tole(0x6fb077e1L),
+  tole(0x18b74777L), tole(0x88085ae6L), tole(0xff0f6a70L), tole(0x66063bcaL), tole(0x11010b5cL),
+  tole(0x8f659effL), tole(0xf862ae69L), tole(0x616bffd3L), tole(0x166ccf45L), tole(0xa00ae278L),
+  tole(0xd70dd2eeL), tole(0x4e048354L), tole(0x3903b3c2L), tole(0xa7672661L), tole(0xd06016f7L),
+  tole(0x4969474dL), tole(0x3e6e77dbL), tole(0xaed16a4aL), tole(0xd9d65adcL), tole(0x40df0b66L),
+  tole(0x37d83bf0L), tole(0xa9bcae53L), tole(0xdebb9ec5L), tole(0x47b2cf7fL), tole(0x30b5ffe9L),
+  tole(0xbdbdf21cL), tole(0xcabac28aL), tole(0x53b39330L), tole(0x24b4a3a6L), tole(0xbad03605L),
+  tole(0xcdd70693L), tole(0x54de5729L), tole(0x23d967bfL), tole(0xb3667a2eL), tole(0xc4614ab8L),
+  tole(0x5d681b02L), tole(0x2a6f2b94L), tole(0xb40bbe37L), tole(0xc30c8ea1L), tole(0x5a05df1bL),
+  tole(0x2d02ef8dL)
 };
 #endif
 
@@ -134,42 +131,63 @@ local const uLongf crc_table[256] = {
 /* =========================================================================
  * This function can be used by asm versions of crc32()
  */
-const uLongf * ZEXPORT get_crc_table()
+const __u32 * get_crc_table()
 {
 #ifdef DYNAMIC_CRC_TABLE
   if (crc_table_empty) make_crc_table();
 #endif
-  return (const uLongf *)crc_table;
+  return (const __u32 *)crc_table;
 }
 #endif
 
-/* ========================================================================= */
-#define DO1(buf) crc = crc_table[((int)crc ^ (*buf++)) & 0xff] ^ (crc >> 8);
-#define DO2(buf)  DO1(buf); DO1(buf);
-#define DO4(buf)  DO2(buf); DO2(buf);
-#define DO8(buf)  DO4(buf); DO4(buf);
-
-/* ========================================================================= */
-uLong ZEXPORT crc32(crc, buf, len)
-    uLong crc;
-    const Bytef *buf;
-    uInt len;
+# ifdef __LITTLE_ENDIAN
+#  define DO_CRC(x) crc = tab[ (crc ^ (x)) & 255 ] ^ (crc>>8)
+# else
+#  define DO_CRC(x) crc = tab[ ((crc >> 24) ^ (x)) & 255] ^ (crc<<8)
+# endif
+
+unsigned long crc32(unsigned long crc, const unsigned char *p, unsigned int len)
 {
-    if (buf == Z_NULL) return 0L;
+	const __u32      *b =(__u32 *)p;
+	const __u32      *tab = crc_table;
+
+	if (!p) return 0L;
 #ifdef DYNAMIC_CRC_TABLE
-    if (crc_table_empty)
-      make_crc_table();
+	if (crc_table_empty)
+		make_crc_table();
 #endif
-    crc = crc ^ 0xffffffffL;
-    while (len >= 8)
-    {
-      DO8(buf);
-      len -= 8;
-    }
-    if (len) do {
-      DO1(buf);
-    } while (--len);
-    return crc ^ 0xffffffffL;
+	crc = __cpu_to_le32(crc ^ 0xffffffffL);
+	/* Align it */
+	if( ((long)b)&3 && len){
+		do {
+			DO_CRC(*((__u8 *)b)++);
+		} while ((--len) && ((long)b)&3 );
+	}
+
+	if(len >= 4){
+		/* Load data 32 bits wide, xor data 32 bits wide. */
+		__u32 save_len = len & 3;
+
+		len = len >> 2;
+		--b; /* use pre increment below(*++b) for speed */
+		do {
+			crc ^= *++b;
+			DO_CRC(0);
+			DO_CRC(0);
+			DO_CRC(0);
+			DO_CRC(0);
+		} while (--len);
+		b++; /* point to next byte(s) */
+		len = save_len;
+	}
+
+	/* And the last few bytes */
+	if(len){
+		do {
+			DO_CRC(*((__u8 *)b)++);
+		} while (--len);
+	}
+	return __le32_to_cpu(crc) ^ 0xffffffffL;
 }
 
 #if (CONFIG_COMMANDS & CFG_CMD_JFFS2)
@@ -177,23 +195,48 @@ uLong ZEXPORT crc32(crc, buf, len)
 /* No ones complement version. JFFS2 (and other things ?)
  * don't use ones compliment in their CRC calculations.
  */
-uLong ZEXPORT crc32_no_comp(uLong crc, const Bytef *buf, uInt len)
+unsigned long crc32_no_comp(unsigned long crc, const unsigned char *p, unsigned int len)
 {
-    if (buf == Z_NULL) return 0L;
+	const __u32      *b =(__u32 *)p;
+	const __u32      *tab = crc_table;
+
+	if (!p) return 0L;
 #ifdef DYNAMIC_CRC_TABLE
-    if (crc_table_empty)
-      make_crc_table();
+	if (crc_table_empty)
+		make_crc_table();
 #endif
-    while (len >= 8)
-    {
-      DO8(buf);
-      len -= 8;
-    }
-    if (len) do {
-      DO1(buf);
-    } while (--len);
-
-    return crc;
+	crc = __cpu_to_le32(crc);
+	/* Align it */
+	if( ((long)b)&3 && len){
+		do {
+			DO_CRC(*((__u8 *)b)++);
+		} while ((--len) && ((long)b)&3 );
+	}
+
+	if(len >= 4){
+		/* Load data 32 bits wide, xor data 32 bits wide. */
+		__u32 save_len = len & 3;
+
+		len = len >> 2;
+		--b; /* use pre increment below(*++b) for speed */
+		do {
+			crc ^= *++b;
+			DO_CRC(0);
+			DO_CRC(0);
+			DO_CRC(0);
+			DO_CRC(0);
+		} while (--len);
+		b++; /* point to next byte(s) */
+		len = save_len;
+	}
+
+	/* And the last few bytes */
+	if(len){
+		do {
+			DO_CRC(*((__u8 *)b)++);
+		} while (--len);
+	}
+	return __le32_to_cpu(crc);
 }
 
 #endif	/* CFG_CMD_JFFS2 */

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLOENAFKAA.joakim.tjernlund@lumentis.se> you wrote:
> > In message <004701c2e29a$a280b4a0$020120b0@jockeXP> you wrote:
> > >
> > > I will have a look, but I can't test it in u-boot so you will have to do it, OK?
> > 
> > Sure. I hope the code is not much bigger, though.  That  might  be  a
> > killing point.
> 
> OK, here it is. It compiles, but generates alot of warnings.
> I had made some clenups as well.
> Don't think the size is to bad but judge for your self

Sorry, but this does not compile at all for me; the native GCC
(when building the tools/ directory) will complain:

/tmp/ccRasvph.s: Assembler messages:
/tmp/ccRasvph.s:323: Error: no such instruction: `rlwimi %ecx,%eax,24,16,23'
/tmp/ccRasvph.s:324: Error: no such instruction: `rlwimi %ecx,%eax,8,8,15'
/tmp/ccRasvph.s:325: Error: no such instruction: `rlwimi %ecx,%eax,24,0,7'
/tmp/ccRasvph.s:429: Error: no such instruction: `rlwimi %eax,%ecx,24,16,23'
/tmp/ccRasvph.s:430: Error: no such instruction: `rlwimi %eax,%ecx,8,8,15'
/tmp/ccRasvph.s:431: Error: no such instruction: `rlwimi %eax,%ecx,24,0,7'
make[1]: *** [crc32.o] Error 1

This is with gcc version 3.2.

Were you able to compile this code?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
The one who says it cannot be done should never interrupt the one who
is doing it.

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Vladimir Gurevich]

Hi Wolfgang,

Wolfgang Denk wrote:
> Sorry, but this does not compile at all for me; the native GCC
> (when building the tools/ directory) will complain:
> 
> /tmp/ccRasvph.s: Assembler messages:
> /tmp/ccRasvph.s:323: Error: no such instruction: `rlwimi %ecx,%eax,24,16,23'
> /tmp/ccRasvph.s:324: Error: no such instruction: `rlwimi %ecx,%eax,8,8,15'
> /tmp/ccRasvph.s:325: Error: no such instruction: `rlwimi %ecx,%eax,24,0,7'
> /tmp/ccRasvph.s:429: Error: no such instruction: `rlwimi %eax,%ecx,24,16,23'
> /tmp/ccRasvph.s:430: Error: no such instruction: `rlwimi %eax,%ecx,8,8,15'
> /tmp/ccRasvph.s:431: Error: no such instruction: `rlwimi %eax,%ecx,24,0,7'
> make[1]: *** [crc32.o] Error 1

Could it be that your include/asm points to include/asm-ppc and 
thus you include wrong byteorder.h? These instructions look as 
PPC implementation of ___arch__swab32 applied to x86 code.

Regards,
Vladimir Gurevich

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

Dear Vladimir,

in message <3E667F95.5000308@paulidav.org> you wrote:
> 
> > /tmp/ccRasvph.s: Assembler messages:
> > /tmp/ccRasvph.s:323: Error: no such instruction: `rlwimi %ecx,%eax,24,16,23'
...
> Could it be that your include/asm points to include/asm-ppc and 

Of course, as I'm compiling for a PowerPC system.

> thus you include wrong byteorder.h? These instructions look as 
> PPC implementation of ___arch__swab32 applied to x86 code.

Right. And this is why I wonder how Jocke compiled this stuff at  all
in a U-Boot environment.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
"Unix is simple, but it takes a genius to understand the simplicity."
					             - Dennis Ritchie

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Vladimir Gurevich]

Dear Wolfgang,

Wolfgang Denk wrote:
> Of course, as I'm compiling for a PowerPC system.

BUT, when you compile stuff in /tools you use a native
compiler, as you mentioned in the previous email, don't you?

That points out to a small problem in U-boot (and Linux)
include directory structure. Basically, you cannot compile
source that include machine-dependent code from include/asm
using a native compiler, since asm points to the target-specific
asm directory. That means that Jocke's crc32.c file cannot be shared
between u-boot code and tools, since it contains machine-specific
code. :( Any good ideas on how to avoid that?

I guess, Jocke had his /tools compiled long time ago and only
tried PPC-specific stuff, that seems to work.

Anyway, you two can definitely resolve this.

Best regards,
Vladimir

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <3E669B87.7030302@paulidav.org> you wrote:
> 
> BUT, when you compile stuff in /tools you use a native
> compiler, as you mentioned in the previous email, don't you?

Right.

> I guess, Jocke had his /tools compiled long time ago and only
> tried PPC-specific stuff, that seems to work.

But I guess he did run a MAKEALL before submitting the patch?


> Anyway, you two can definitely resolve this.

Maybe, but I'm really short of time at the moment...


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
It would be illogical to kill without reason
	-- Spock, "Journey to Babel", stardate 3842.4

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> > I guess, Jocke had his /tools compiled long time ago and only
> > tried PPC-specific stuff, that seems to work.
> 
> But I guess he did run a MAKEALL before submitting the patch?

I tried a few boards, but not all and it compiles with a a lot of ISO bla bla warnings.
Looking at now I see that is't wrong for the tools part:

make[1]: Entering directory `/usr/local/src/u-boot/tools'
gcc -g -Wall -pedantic -I../include -I.. -DTEXT_BASE=0x40000000 -DUSE_HOSTCC -O -c crc32.c
In file included from crc32.c:14:
../include/asm/types.h:18: warning: ISO C89 does not support `long long'
../include/asm/types.h:19: warning: ISO C89 does not support `long long'
In file included from ../include/linux/byteorder/big_endian.h:11,
                 from ../include/asm/byteorder.h:82,
                 from crc32.c:15:
../include/linux/byteorder/swab.h: In function `__fswab64':
../include/linux/byteorder/swab.h:133: warning: ISO C89 forbids long long integer constants
[SNIP]
../include/linux/byteorder/swab.h: In function `__swab64p':
../include/linux/byteorder/swab.h:138: warning: ISO C89 forbids long long integer constants
[SNIP]
crc32.c: In function `crc32':
crc32.c:163: warning: ISO C forbids use of cast expressions as lvalues
crc32.c:187: warning: ISO C forbids use of cast expressions as lvalues

The ISO warning are harmless caused by the -pedatic option and I don't know how
to get rid of these without removing the option.

This part is wrong though:
In file included from ../include/linux/byteorder/big_endian.h:11,
                 from ../include/asm/byteorder.h:82,
                 from crc32.c:15:

This could be solved with some (ugly):
#ifdef __powerpc__
#include <asm-ppc/byteorder.h>
#elif ....

I still don't understand how this can compile. I use RH7.2 and gcc 2.96 RH.
My U-boot is not completly up to date(0.2.1) but I don't think that is a problem.

 Jocke 

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> This could be solved with some (ugly):
> #ifdef __powerpc__
> #include <asm-ppc/byteorder.h>
> #elif ....

Or create a asm link in tools: ln -s ../asm-$HOSTARCH asm

The mkconfig and tools/Makefile needs to be adopted for this.

 Jocke

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Wolfgang Denk]

In message <IGEFJKJNHJDCBKALBJLLMEOCFKAA.joakim.tjernlund@lumentis.se> you wrote:
> > This could be solved with some (ugly):
> > #ifdef __powerpc__
> > #include <asm-ppc/byteorder.h>
> > #elif ....
> 
> Or create a asm link in tools: ln -s ../asm-$HOSTARCH asm

You are aware that these are two _different_ solutions?

On a x86 host, the former would pull in the PPC version of
byteorder.h, while the latter would use the i386 version?

BTW: there is no tools/../asm-* ;-)

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Everyting looks interesting until you do it. Then you find it's  just
another job.                     - Terry Pratchett, _Moving Pictures_

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> In message <IGEFJKJNHJDCBKALBJLLMEOCFKAA.joakim.tjernlund@lumentis.se> you wrote:
> > > This could be solved with some (ugly):
> > > #ifdef __powerpc__
> > > #include <asm-ppc/byteorder.h>
> > > #elif ....
> > 
> > Or create a asm link in tools: ln -s ../asm-$HOSTARCH asm
> 
> You are aware that these are two _different_ solutions?

Of course I am! That's why I wrote "Or create ..."
                                    ^^
> On a x86 host, the former would pull in the PPC version of
> byteorder.h, while the latter would use the i386 version?
ehh?
Let me clarify. Either do like this:
#ifndef USE_HOSTCC
#  include <common.h>
#  include <asm/types.h>
#  include <asm/byteorder.h>
#else
#  ifdef __powerpc__
#    include <asm-ppc/types.h>
#    include <asm-ppc/byteorder.h>
#  elif __i386__
#    include <asm-i386/types.h>
#    include <asm-i386/byteorder.h>
#  elif ....
#  endif

OR use the ln -s procedure
> 
> BTW: there is no tools/../asm-* ;-)
Opps, meant ln -s ../include/asm-$HOSTARCH asm

 Jocke

[U-Boot-Users] Boot the kernel from a JFFS2 filesystem

[Joakim Tjernlund]

> Let me clarify. Either do like this:
> #ifndef USE_HOSTCC
> #  include <common.h>
> #  include <asm/types.h>
> #  include <asm/byteorder.h>
> #else
> #  ifdef __powerpc__
> #    include <asm-ppc/types.h>
> #    include <asm-ppc/byteorder.h>
> #  elif __i386__
> #    include <asm-i386/types.h>
> #    include <asm-i386/byteorder.h>
> #  elif ....
> #  endif
> 
> OR use the ln -s procedure

hmm, I wonder if the include dir search order is broken for the tools
dir. The tools dir contain host tools and these should pick up
system include files BEFORE looking in uboots include dir, otherwise
these program may pick up bogus stuff from uboot in case there is a
file there with the same name as one of the system files.

The asm/byteorder.h is a good example of that, but I think my earlier
proposed soultions to the asm/byteorder.h is too much bandaid.

I can't find a way to make gcc search the system include dirs BEFORE 
-IDIR. The best I can find is this: "-I../include -I- -I.". That
will force gcc to look in ../include only for #include "file.h" directives.

The above #ifdef mess will then become:
#ifndef USE_HOSTCC
#  include <common.h>
#  include "asm/types.h"
#  include "asm/byteorder.h"
#else
#  include <asm/types.h>
#  include <asm/byteorder.h>
#endif

Comments?