patch for mktree.c on cross compiles

patch for mktree.c on cross compiles

[andrew may]

I am not sure how correct this is, but it does get me furthrer
along in doing a cross compile for the 405GP.

I would think everything in arch/ppc/boot/utils should be checked
for endian problems on cross compiles.

This is what is outputed on boot. I don't have a BDM yet so it
is hard to see were things really are wrong.

Sending tftp boot request ...
Transfer Complete ...
Loaded successfully ...
Entry point at 0x500000 ...
loaded at:     00500000 0050A244
relocated to:  00400000 0040A244
board data at: 00407174 004071B4
relocated to:  00200100 00200140
zimage at:     00507067 00584D05
avail ram:     00585000 02000000

Linux/PPC load: root=/dev/nfs rw ip=auto
Uncompressing Linux...done.
Now booting the kernel
----------  progress:  0x200 id mach(): done
----------  progress:  0x111 MMU:enter
----------  progress:  0x300 MMU:hw init
----------  progress:  0x301 MMU:mapin
----------  progress:  0x302 MMU:setio
----------  progress:  0x211 MMU:exit
Linux version 2.4.10-pre4 (amay@infosec-server) (gcc version 2.95.3 20010315 (release/MontaVista)) #4 Wed Sep 5 12:47:36 PDT 2001
----------  progress:  0x3eab setup_arch: enter
----------  progress:  0x3eab setup_arch: bootmem
----------  progress:  0x3eab arch: exit
On node 0 totalpages: 8192
zone(0): 8192 pages.
zone(1): 0 pages.
zone(2): 0 pages.
Kernel command line: root=/dev/nfs rw ip=auto

The patch.

--- mktree.c	Wed Sep  5 13:02:11 2001
+++ mktree.c.org	Wed Sep  5 12:43:33 2001
@@ -51,16 +51,16 @@

 	nblks = (st.st_size + IMGBLK) / IMGBLK;

-	bt.bb_magic = htonl(0x0052504F);
+	bt.bb_magic = 0x0052504F;

 	/* We know these from the linker command.
 	 * ...and then move it up into memory a little more so the
 	 * relocation can happen.
 	 */
-	bt.bb_dest = htonl(0x500000);
-        bt.bb_entry_point = htonl(0x500000);
+	bt.bb_dest = 0x500000;
+        bt.bb_entry_point = 0x500000;

-	bt.bb_num_512blocks = htonl(nblks);
+	bt.bb_num_512blocks = nblks;
 	bt.bb_debug_flag = 0;

 	bt.bb_checksum = 0;
@@ -88,17 +88,17 @@
 	/* Assume zImage is an ELF file, and skip the 64K header.
 	*/
 	if (read(in_fd, tmpbuf, IMGBLK) != IMGBLK) {
-		fprintf(stderr, "%s is too small to be an ELF image\n", argv[1]);
+		fprintf(stderr, "%s is not an ELF image\n", argv[1]);
 		exit(4);
 	}

-	if ((*(uint *)tmpbuf) != htonl(0x7f454c46) ) {
-		fprintf(stderr, "%s does not have correct ELF tag\n", argv[1]);
+	if ((*(uint *)tmpbuf) != 0x7f454c46) {
+		fprintf(stderr, "%s is not an ELF image\n", argv[1]);
 		exit(4);
 	}

 	if (lseek(in_fd, (64 * 1024), SEEK_SET) < 0) {
-		fprintf(stderr, "%s failed to seek in ELF image\n", argv[1]);
+		fprintf(stderr, "%s is not an ELF image\n", argv[1]);
 		exit(4);
 	}

@@ -127,7 +127,7 @@

 	/* rewrite the header with the computed checksum.
 	*/
-	bt.bb_checksum = htonl(cksum);
+	bt.bb_checksum = cksum;
 	if (lseek(out_fd, 0, SEEK_SET) < 0) {
 		perror("rewrite seek");
 		exit(1);

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

Re: patch for mktree.c on cross compiles

[Tom Rini]

On Wed, Sep 05, 2001 at 04:43:33PM -0400, Dan Malek wrote:
> andrew may wrote:
> > I would think everything in arch/ppc/boot/utils should be checked
> > for endian problems on cross compiles.
>
> Are the network-host macros the right things to use?  That's what
> always comes to mind for me, but I suspect there is a more standard
> set of macros from 'endian.h' or something........If it's OK with
> everyone I'll check it in, but it does look kind of weird.

Well, after some quick digging, here's what I found.  If we include
<asm/byteoder.h>, and deal with some __'s, which are exported outside
of the kernel, we can use these.  But, it's getting late and my brain
is giving up after being fried for a while today, so I could be wrong,
but I _think_ we can use asm/byteorder.h, possibly make some changes
to mkbugboot/mkprep/mktree and it'll just work (The first two only work
on big endian or x86.  Not other LE machines, I think :))

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: patch for mktree.c on cross compiles

[Tom Rini]

On Wed, Sep 05, 2001 at 10:39:03PM -0700, acmay@acmay.homeip.net wrote:
> On Wed, Sep 05, 2001 at 09:20:50PM -0700, Tom Rini wrote:
> > On Wed, Sep 05, 2001 at 04:43:33PM -0400, Dan Malek wrote:
> > > andrew may wrote:
> > > > I would think everything in arch/ppc/boot/utils should be checked
> > > > for endian problems on cross compiles.
> > >
> > > Are the network-host macros the right things to use?  That's what
> > > always comes to mind for me, but I suspect there is a more standard
> > > set of macros from 'endian.h' or something........If it's OK with
> > > everyone I'll check it in, but it does look kind of weird.
> >
> > Well, after some quick digging, here's what I found.  If we include
> > <asm/byteoder.h>, and deal with some __'s, which are exported outside
>
> One problem with trying this is that <asm/byteoder.h> will only be for
> the target, not the compiling host. I think mktree should stick with
> standard userspace include headers and stay away from kernel headers.

Er.  No, <asm/byteorder.h> _should_ be a userspace header.  At least on
Linux..  For BSD (and Linux with _USE_BSD) we can use sys/types.h and get
back a __BYTE_ORDER, I _think_...

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: patch for mktree.c on cross compiles

[andrew may]

On Thu, Sep 06, 2001 at 07:55:42AM -0700, Tom Rini wrote:
> On Wed, Sep 05, 2001 at 10:39:03PM -0700, acmay@acmay.homeip.net wrote:
> > On Wed, Sep 05, 2001 at 09:20:50PM -0700, Tom Rini wrote:
> > > On Wed, Sep 05, 2001 at 04:43:33PM -0400, Dan Malek wrote:
> > > > andrew may wrote:
> > > > > I would think everything in arch/ppc/boot/utils should be checked
> > > > > for endian problems on cross compiles.
> > > >
> > > > Are the network-host macros the right things to use?  That's what
> > > > always comes to mind for me, but I suspect there is a more standard
> > > > set of macros from 'endian.h' or something........If it's OK with
> > > > everyone I'll check it in, but it does look kind of weird.
> > >
> > > Well, after some quick digging, here's what I found.  If we include
> > > <asm/byteoder.h>, and deal with some __'s, which are exported outside
> >
> > One problem with trying this is that <asm/byteoder.h> will only be for
> > the target, not the compiling host. I think mktree should stick with
> > standard userspace include headers and stay away from kernel headers.
>
> Er.  No, <asm/byteorder.h> _should_ be a userspace header.  At least on
> Linux..  For BSD (and Linux with _USE_BSD) we can use sys/types.h and get
> back a __BYTE_ORDER, I _think_...

It seems that <asm/byteorder.h> is one of the "shared" headers between glibc
and the kernel. Hasn't Linus wanted the glibc people to do there own headers
for ages.

Either way it seems that htonl gets mapped down __cpu_to_be32() in
linux/byteorder/generic.h. So that even thought it seems strange to
use the "network" functions it does seem to be OK.

We can only hope people don't have bad /usr/include/[asm][linux] symlinks.


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

Re: patch for mktree.c on cross compiles

[Tom Rini]

On Thu, Sep 06, 2001 at 01:01:06PM -0700, andrew may wrote:
> On Thu, Sep 06, 2001 at 07:55:42AM -0700, Tom Rini wrote:
> > On Wed, Sep 05, 2001 at 10:39:03PM -0700, acmay@acmay.homeip.net wrote:
> > > On Wed, Sep 05, 2001 at 09:20:50PM -0700, Tom Rini wrote:
> > > > On Wed, Sep 05, 2001 at 04:43:33PM -0400, Dan Malek wrote:
> > > > > andrew may wrote:
> > > > > > I would think everything in arch/ppc/boot/utils should be checked
> > > > > > for endian problems on cross compiles.
> > > > >
> > > > > Are the network-host macros the right things to use?  That's what
> > > > > always comes to mind for me, but I suspect there is a more standard
> > > > > set of macros from 'endian.h' or something........If it's OK with
> > > > > everyone I'll check it in, but it does look kind of weird.
> > > >
> > > > Well, after some quick digging, here's what I found.  If we include
> > > > <asm/byteoder.h>, and deal with some __'s, which are exported outside
> > >
> > > One problem with trying this is that <asm/byteoder.h> will only be for
> > > the target, not the compiling host. I think mktree should stick with
> > > standard userspace include headers and stay away from kernel headers.
> >
> > Er.  No, <asm/byteorder.h> _should_ be a userspace header.  At least on
> > Linux..  For BSD (and Linux with _USE_BSD) we can use sys/types.h and get
> > back a __BYTE_ORDER, I _think_...
>
> It seems that <asm/byteorder.h> is one of the "shared" headers between glibc
> and the kernel. Hasn't Linus wanted the glibc people to do there own headers
> for ages.

Yes, it's an imperfect solution at best.  What would be correct is for us
to copy all of the needed magic into our own header and toss it in
arch/ppc/boot/include.  With some proper magic for the !Linux case too.

> Either way it seems that htonl gets mapped down __cpu_to_be32() in
> linux/byteorder/generic.h. So that even thought it seems strange to
> use the "network" functions it does seem to be OK.

> We can only hope people don't have bad /usr/include/[asm][linux] symlinks.

Well, if they do there's good odds of them not having gotten past 'dep'.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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

Re: patch for mktree.c on cross compiles

[Mark Hatle]

andrew may wrote:
>
> > Yes, it's an imperfect solution at best.  What would be correct is for us
> > to copy all of the needed magic into our own header and toss it in
> > arch/ppc/boot/include.  With some proper magic for the !Linux case too.
>
> I am not sure why we would need to do this. mktree.c already includes
> libc headers and the htonl defination is pulled in with them.
>
> This does increase our build requirments to have a working libc env
> on the host.
>
> To be completely correct not only will you need to have the byte order
> magic in arch/ppc/boot/include, but also all the file access magic as
> well, since mktree reads in a file, adds a header and then writes out
> another file.

I have a concern that using any glibc (specific) stuff will break cross
compiling from say a solaris system to linux.  I thing Andrew is right,
the correct solution is probably to copy the bits into the boot/include
dir.

--Mark

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

Re: patch for mktree.c on cross compiles

[Tom Rini]

On Thu, Sep 06, 2001 at 01:54:32PM -0700, andrew may wrote:
> > Yes, it's an imperfect solution at best.  What would be correct is for us
> > to copy all of the needed magic into our own header and toss it in
> > arch/ppc/boot/include.  With some proper magic for the !Linux case too.
>
> I am not sure why we would need to do this. mktree.c already includes
> libc headers and the htonl defination is pulled in with them.

htonl works, it's just non-obvious.  It should be on anything that
conforms to BSD 4.3, so it should hopefully be fine for cross-platform.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

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