porting arcboot

porting arcboot

[Andrew Clausen]

Hi all,

I'm planning to try porting arcboot to ip27 (mips64).

I plan to do this by cross-compiling... this is actually the only
option since there's no 64 bit userland yet.

Some issues:

 * I'll be cross-compiling (using the mips64-linux-gcc & friends that
are provided on ftp.linux-mips.org), which means some makefile hacking...

 * there's no mips64-linux glibc, which means no libc headers are
available.  So I need to either cut&paste libc headers, or remove
dependencies on them.  This affects lots of code.

 * the e2fs stuff... how is this being maintained?  It uses libc
headers a bit... can I kill them?  Or will this make it hard to update
to new upstream e2fsprogs releases?

Anything else?

Cheers,
ANdrew

Re: porting arcboot

[Ralf Baechle]

On Mon, Feb 10, 2003 at 02:45:49PM +1100, Andrew Clausen wrote:

> I'm planning to try porting arcboot to ip27 (mips64).
> 
> I plan to do this by cross-compiling... this is actually the only
> option since there's no 64 bit userland yet.
> 
> Some issues:
> 
>  * I'll be cross-compiling (using the mips64-linux-gcc & friends that
> are provided on ftp.linux-mips.org), which means some makefile hacking...
> 
>  * there's no mips64-linux glibc, which means no libc headers are
> available.  So I need to either cut&paste libc headers, or remove
> dependencies on them.  This affects lots of code.
> 
>  * the e2fs stuff... how is this being maintained?  It uses libc
> headers a bit... can I kill them?  Or will this make it hard to update
> to new upstream e2fsprogs releases?
> 
> Anything else?

Arcboot is a standalone program.  As such it shouldn't use anything from
glibc or it's going to be a royal pain in the lower back extension.
Look at Milo, spit and say no.  So keeping a private copy of the necessary
headers is the only sane way to get things to work.

  Ralf

Re: porting arcboot

[Guido Guenther]

Hi,
On Mon, Feb 10, 2003 at 02:45:49PM +1100, Andrew Clausen wrote:
>  * I'll be cross-compiling (using the mips64-linux-gcc & friends that
> are provided on ftp.linux-mips.org), which means some makefile hacking...
There hopefully shouldn't be any trouble with that outside of e2fslib.

>  * the e2fs stuff... how is this being maintained?  It uses libc
> headers a bit... can I kill them?  Or will this make it hard to update
> to new upstream e2fsprogs releases?
E2fslib will move out of arcboot with the next release and arcboot will
link against the non pic version in the debian archive. I'd really like
to keep e2fslib out of arcboot (at least for the debian version which is
quiet different from the oss.sgi.com version). There should't be many
libc header dependencies left then. If there are still any I'd be happy
to kill them.

> Anything else?
Except for the above change I was working on a better command line
handling among other things which I never got around to finish. Maybe
this beats me to it.
Regards,
 -- Guido

Re: porting arcboot

[Andrew Clausen]

On Mon, Feb 10, 2003 at 11:03:19AM +0100, Guido Guenther wrote:
> E2fslib will move out of arcboot with the next release and arcboot will
> link against the non pic version in the debian archive. I'd really like
> to keep e2fslib out of arcboot (at least for the debian version which is
> quiet different from the oss.sgi.com version).

Ah, ok.  Now we're just stuck with the problem that we can't build
e2fsprogs for misp64, since we don't have the toolchain for it.

e2fsprogs looks like it resists cross-compiling also :(

So, the obstacles are:
 * e2fsprogs uses libc headers quite extensively, but there is no
glibc available for mips64 (right?).  It also seems to make quite a
few libc calls?  (How are you planning to deal with that?  Link
against it statically?  What about syscalls?)
 * e2fsprogs doesn't use autoconf/automake "properly".  It doesn't seem
to support cross-compiling.  Adding cross-compile support looks
somewhat non-trivial, since it builds it's own tools to compile itself.
(A fancy sed replacement, for some reason?)
 * there is no toolchain to build e2fsprogs on mips64 cleanly... need
to do that objcopy business.  This means hacking the build process?

> There should't be many
> libc header dependencies left then. If there are still any I'd be happy
> to kill them.

:)

Cheers,
Andrew

Re: porting arcboot

[Guido Guenther]

On Tue, Feb 11, 2003 at 09:39:55AM +1100, Andrew Clausen wrote:
>  * e2fsprogs uses libc headers quite extensively, but there is no
> glibc available for mips64 (right?).  It also seems to make quite a
> few libc calls?  (How are you planning to deal with that?  Link
> against it statically?  What about syscalls?)
e2fsprogs doesn't call glibc (in fact in can't since we don't link
arcboot against non PIC glibc). It calls arclib.
 -- Guido

Re: porting arcboot

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 1191 bytes --]

On Tue, Feb 11, 2003 at 09:39:55AM +1100, Andrew Clausen wrote:
> 
> e2fsprogs looks like it resists cross-compiling also :(
> 
> So, the obstacles are:
>  * e2fsprogs uses libc headers quite extensively, but there is no
> glibc available for mips64 (right?).  It also seems to make quite a
> few libc calls?  (How are you planning to deal with that?  Link
> against it statically?  What about syscalls?)
>  * e2fsprogs doesn't use autoconf/automake "properly".  It doesn't seem
> to support cross-compiling.  Adding cross-compile support looks
> somewhat non-trivial, since it builds it's own tools to compile itself.
> (A fancy sed replacement, for some reason?)
>  * there is no toolchain to build e2fsprogs on mips64 cleanly... need
> to do that objcopy business.  This means hacking the build process?

You dont need e2fsprogs - Just certain parts of the libe2fs which itself
just uses some very basic libc functions like malloc/free/str* which
we all have within arcboot. So you simple need to cross-compile the
libe2fs.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: porting arcboot

[Andrew Clausen]

On Tue, Feb 11, 2003 at 11:46:22PM +0100, Florian Lohoff wrote:
> You dont need e2fsprogs

Right, just they seem so coupled...

> - Just certain parts of the libe2fs which itself
> just uses some very basic libc functions like malloc/free/str* which
> we all have within arcboot.

I disagree.

libe2fs includes lots of headers:

	pureza:~/e2fsprogs-1.32/lib$ find . | grep '\.[ch]$' | xargs grep -h "#include <" | sort | uniq | wc -l
	     77

Also, running nm gives libc calls that invoke syscalls galore.
For example:

	open64, close, ioctl, opendir, fprintf, getmntent, lseek64, time

I got these names from:

	pureza:~/e2fsprogs-1.32/lib$ nm libext2fs.a | grep '^ *U' | less

Am I missing something?

>  So you simple need to cross-compile the libe2fs.

That seems *hard*.

Cheers,
Andrew

Re: porting arcboot

[Guido Guenther]

On Wed, Feb 12, 2003 at 04:03:41PM +1100, Andrew Clausen wrote:
> Also, running nm gives libc calls that invoke syscalls galore.
> For example:
> 
> 	open64, close, ioctl, opendir, fprintf, getmntent, lseek64, time
But we don't use all of e2fslib! The functions needed to get the kernel
from an e2fs only use a very small subset of these and are contained in
arclib.
 -- Guido

Re: porting arcboot

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]

On Wed, Feb 12, 2003 at 04:03:41PM +1100, Andrew Clausen wrote:
> On Tue, Feb 11, 2003 at 11:46:22PM +0100, Florian Lohoff wrote:
> > You dont need e2fsprogs
> 
> Right, just they seem so coupled...
> 
> > - Just certain parts of the libe2fs which itself
> > just uses some very basic libc functions like malloc/free/str* which
> > we all have within arcboot.
> 
> I disagree.
> 
> libe2fs includes lots of headers:
> 
> 	pureza:~/e2fsprogs-1.32/lib$ find . | grep '\.[ch]$' | xargs grep -h "#include <" | sort | uniq | wc -l
> 	     77
> 
> Also, running nm gives libc calls that invoke syscalls galore.
> For example:
> 
> 	open64, close, ioctl, opendir, fprintf, getmntent, lseek64, time
> 
> I got these names from:
> 
> 	pureza:~/e2fsprogs-1.32/lib$ nm libext2fs.a | grep '^ *U' | less
> 
> Am I missing something?

Yes - That you dont need all those objects in that archive. 

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: porting arcboot

[Andrew Clausen]

On Wed, Feb 12, 2003 at 04:26:20PM +0100, Florian Lohoff wrote:
> > Am I missing something?
> 
> Yes - That you dont need all those objects in that archive. 

But how does that help?  It's painful to merely build the set
of objects we need.  (That would involve e2fsprogs makefile hacking...
i.e. not just reusing it out-of-the-box)  But it's absolutely necessary,
because it's impossible to build all the other objects for mips64 today.

So, are you doing the Makefile hacking, or what?

Cheers,
Andrew

Re: porting arcboot

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]

On Thu, Feb 13, 2003 at 09:58:23AM +1100, Andrew Clausen wrote:
> On Wed, Feb 12, 2003 at 04:26:20PM +0100, Florian Lohoff wrote:
> > > Am I missing something?
> > 
> > Yes - That you dont need all those objects in that archive. 
> 
> But how does that help?  It's painful to merely build the set
> of objects we need.  (That would involve e2fsprogs makefile hacking...
> i.e. not just reusing it out-of-the-box)  But it's absolutely necessary,
> because it's impossible to build all the other objects for mips64 today.
> 
> So, are you doing the Makefile hacking, or what?
> 

I havent got any mips64 equipment yet and even less time. I guess until
we have a real mips64-glibc we will need to put the kernel into the
volume-header.

Flo
-- 
Florian Lohoff                  flo@rfc822.org             +49-5201-669912
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: porting arcboot

[Vivien Chappelier]

> I'm planning to try porting arcboot to ip27 (mips64).

I'm actually doing the same for ip32 (SGI O2). I've added support for
64-bit ELF while sticking to 32-bit arcboot to avoid the issues you
mention with 64-bit userland. The code is still a bit ugly and I've
hardcoded a different load address for the O2 (this should be a
'configure' option at least), but you might be interested to have a look.
The same trick used for the kernel could probably be used to relocate the
32-bit arcboot to 64-bit address space using objcopy, for the ip27 PROM
which only supports 64-bit ELF (according to Ralf).

An early patch is there:
http://www.linux-mips.org/~glaurung/arcboot-0.3.5-o2.diff

The idea is to load segments with the KSEG0 version of the physical
address, which can be done with 32-bit code (but limits kernel load
address to <512Mb). We then jump to the 64-bit entry point with a small
bit of mips4 assembly. 

Comments welcome.

Vivien.

Re: porting arcboot

[Guido Guenther]

On Mon, Feb 10, 2003 at 11:33:39AM +0100, Vivien Chappelier wrote:
> mention with 64-bit userland. The code is still a bit ugly and I've
> hardcoded a different load address for the O2 (this should be a
> 'configure' option at least), but you might be interested to have a look.
Can't we read the load address (and needed space) from the elf header
before InitMalloc? Would be much nicer and we don't need a different
loader for every subarch.
 -- Guido

Re: porting arcboot

[Guido Guenther]

On Mon, Feb 10, 2003 at 12:13:30PM +0100, Guido Guenther wrote:
> Can't we read the load address (and needed space) from the elf header
s/load address/kernel's load address/
> before InitMalloc? Would be much nicer and we don't need a different
> loader for every subarch.
In case we find a unique place for arcboot in the memory map of the
different subarches.
Regards,
 -- Guido

Re: porting arcboot

[Guido Guenther]

On Mon, Feb 10, 2003 at 12:13:30PM +0100, Guido Guenther wrote:
> Can't we read the load address (and needed space) from the elf header
s/load address/kernel's load address/
> before InitMalloc? Would be much nicer and we don't need a different
> loader for every subarch.
In case we find a unique place for arcboot in the memory map of the
different subarches.
Regards,
 -- Guido

Re: porting arcboot

[Vivien Chappelier]

---------- Forwarded message ----------
Date: Mon, 10 Feb 2003 13:49:49 +0100 (CET)
From: Vivien Chappelier <glaurung@vivienc.net1.nerim.net>
To: Guido Guenther <agx@gandalf.physik.uni-konstanz.de>
Subject: Re: porting arcboot

On Mon, 10 Feb 2003, Guido Guenther wrote:
> > Can't we read the load address (and needed space) from the elf header
> s/load address/kernel's load address/

Yes, that's what we do already. I was speaking of arcboot load address,
sorry this wasn't very clear :)

> In case we find a unique place for arcboot in the memory map of the
> different subarches.

On the O2 physical memory starts from KSEG0 (0x80000000), the kernel is
loaded there for 32-bit version or in XKPHYS (0x9800000000000000) for the
64-bit version. I don't really know where the PROM code and data is
located precisely, but loading something (arcboot or a kernel) at
0x88000000 as with ip22 is not an option; the PROM says something like
'loading there would overwrite an existing program'. Why is kernel/arcboot
loaded at 0x88000000 on ip22? Is KSEG0 an option for ip22?
BTW, what's the status of mips64/ip22? I guess the PROM doesn't support
64-bit as on the ip32, so arcboot with 64-bit support would be needed as
well, right?

Vivien.

Re: porting arcboot

[Vivien Chappelier]

> P.S.: you didn't cc: linux-mips, feel free to forward this mail there if
> appropriate

It's just I forgot the Reply-all :)
I'll look into what you mention and how to implement it tonight.

Vivien.

---------- Forwarded message ----------
Date: Mon, 10 Feb 2003 14:38:06 +0100
From: Guido Guenther <agx@gandalf.physik.uni-konstanz.de>
To: Vivien Chappelier <vivienc@nerim.net>
Subject: Re: porting arcboot

On Mon, Feb 10, 2003 at 01:49:49PM +0100, Vivien Chappelier wrote:
> Yes, that's what we do already. I was speaking of arcboot load address,
> sorry this wasn't very clear :)
That's actually not what we do, at least not consistently. We parse the
load address from the elf header but also assume a reserved space
(reserver_base/reserve_size in loader.c).

> > In case we find a unique place for arcboot in the memory map of the
> > different subarches.
> 
> On the O2 physical memory starts from KSEG0 (0x80000000), the kernel is
> loaded there for 32-bit version or in XKPHYS (0x9800000000000000) for the
> 64-bit version. I don't really know where the PROM code and data is
> located precisely, but loading something (arcboot or a kernel) at
> 0x88000000 as with ip22 is not an option; the PROM says something like
I don't have the Indy's documentation around but I think the space between
0x80000000 and 0x88000000 is reserved for EISA (which only the I2
actually has). Anyways, I'd be nice to get rid of reserve_{base,size}
first, we could then build a unique loader and maybe simply adjust the
loader's load address using objcopy upon installation in the vh, so we
get away with a single binary for 32bit.

> 'loading there would overwrite an existing program'. Why is kernel/arcboot
> loaded at 0x88000000 on ip22? Is KSEG0 an option for ip22?
> BTW, what's the status of mips64/ip22? I guess the PROM doesn't support
Don't know, wanted to look at this together with getting 2.5 a bit further but
my Indys hard disk went up in flames a week a ago (hard disks are
currently failing around me like crazy).
> 64-bit as on the ip32, so arcboot with 64-bit support would be needed as
> well, right?
Thiemo told me that his R10k I2s PROM only loads 64bit executables.
Don't know if the rest of IP22 can laod 64bit executables at all.
 - Guido

Re: porting arcboot

[Juan Quintela]

>>>>> "vivien" == Vivien Chappelier <vivienc@nerim.net> writes:

vivien> Thiemo told me that his R10k I2s PROM only loads 64bit executables.
vivien> Don't know if the rest of IP22 can laod 64bit executables at all.

I don't think so, mine (I2) only allows ECOFF, ELF is too young for it
:p

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: porting arcboot

[Christoph Hellwig]

On Mon, Feb 10, 2003 at 04:01:40PM +0100, Juan Quintela wrote:
> >>>>> "vivien" == Vivien Chappelier <vivienc@nerim.net> writes:
> 
> vivien> Thiemo told me that his R10k I2s PROM only loads 64bit executables.
> vivien> Don't know if the rest of IP22 can laod 64bit executables at all.
> 
> I don't think so, mine (I2) only allows ECOFF, ELF is too young for it
> :p

You probably don't have a R10k I2..

Re: porting arcboot

[Juan Quintela]

>>>>> "christoph" == Christoph Hellwig <hch@infradead.org> writes:

christoph> On Mon, Feb 10, 2003 at 04:01:40PM +0100, Juan Quintela wrote:
>> >>>>> "vivien" == Vivien Chappelier <vivienc@nerim.net> writes:
>> 
vivien> Thiemo told me that his R10k I2s PROM only loads 64bit executables.
vivien> Don't know if the rest of IP22 can laod 64bit executables at all.
>> 
>> I don't think so, mine (I2) only allows ECOFF, ELF is too young for it
>> :p

christoph> You probably don't have a R10k I2..

No, mine is a good old r4400SC :p

I thought that r10k I2 was IP28 not IP22, but I can be wrong as I
don't speak SGI code names natively :p

Later, Juan.

-- 
In theory, practice and theory are the same, but in practice they 
are different -- Larry McVoy

Re: porting arcboot

[Guido Guenther]

On Mon, Feb 10, 2003 at 04:14:18PM +0100, Juan Quintela wrote:
> I thought that r10k I2 was IP28 not IP22, but I can be wrong as I
> don't speak SGI code names natively :p
Yept. According to:
 http://www.urban.ne.jp/home/mint/irix/hinv.html#indigo2-r10000sc-195-max
you are right.
 -- Guido