[patch] linux 2.4.5: Export mips_machtype

[patch] linux 2.4.5: Export mips_machtype

[Maciej W. Rozycki]

Hi,

 The following patch exports mips_machtype to modules.  Please apply.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

patch-mips-2.4.5-20010704-machtype-0
diff -up --recursive --new-file linux-mips-2.4.5-20010704.macro/arch/mips/kernel/mips_ksyms.c linux-mips-2.4.5-20010704/arch/mips/kernel/mips_ksyms.c
--- linux-mips-2.4.5-20010704.macro/arch/mips/kernel/mips_ksyms.c	Thu Jun 14 04:26:19 2001
+++ linux-mips-2.4.5-20010704/arch/mips/kernel/mips_ksyms.c	Sat Aug 11 21:02:38 2001
@@ -17,6 +17,7 @@
 #include <linux/pci.h>
 #include <linux/ide.h>
 
+#include <asm/bootinfo.h>
 #include <asm/checksum.h>
 #include <asm/dma.h>
 #include <asm/io.h>
@@ -40,6 +41,7 @@ extern long __strlen_user_asm(const char
 extern long __strnlen_user_nocheck_asm(const char *s);
 extern long __strnlen_user_asm(const char *s);
 
+EXPORT_SYMBOL(mips_machtype);
 EXPORT_SYMBOL(EISA_bus);
 
 /*

Re: [patch] linux 2.4.5: Export mips_machtype

[Ralf Baechle]

On Mon, Aug 13, 2001 at 03:26:23PM +0200, Maciej W. Rozycki wrote:

>  The following patch exports mips_machtype to modules.  Please apply.

Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5.  To
messy and requires a central authority to allocate machine types.  What
do you think?

  Ralf

Re: [patch] linux 2.4.5: Export mips_machtype

[Maciej W. Rozycki]

On Mon, 13 Aug 2001, Ralf Baechle wrote:

> >  The following patch exports mips_machtype to modules.  Please apply.
> 
> Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5.  To
> messy and requires a central authority to allocate machine types.  What
> do you think?

 No idea at the moment.  For DECs things are pretty easy.  The firmware
returns a unique system ID for each different kind of hardware.  It can be
used instead (actually mips_machtype is initialized bazed on what firmware
reports).  The ID is mostly useful for system-specific stuff, e.g. onboard
devices that cannot be identified or probed in another way.

 Note that for PCI-based systems, there is usually no problem -- PCI IDs
can be used instead in most cases.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [patch] linux 2.4.5: Export mips_machtype

[Gleb O. Raiko]

"Maciej W. Rozycki" wrote:
> 
> On Mon, 13 Aug 2001, Ralf Baechle wrote:
> 
> > >  The following patch exports mips_machtype to modules.  Please apply.
> >
> > Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5.  To
> > messy and requires a central authority to allocate machine types.  What
> > do you think?
> 
>  No idea at the moment.  For DECs things are pretty easy.  The firmware
> returns a unique system ID for each different kind of hardware.  It can be
> used instead (actually mips_machtype is initialized bazed on what firmware
> reports).  The ID is mostly useful for system-specific stuff, e.g. onboard
> devices that cannot be identified or probed in another way.
> 
>  Note that for PCI-based systems, there is usually no problem -- PCI IDs
> can be used instead in most cases.
> 

How? In fact, I've got two different boards with the same Ethernet chip.
Moreover, mach type shall be known as early as possible, early than pci
init for sure. Just imagine, I need a way to identify PCI controller by
mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I
miss something in your proposal?

BTW, in my Baget case, I just need a number for mach type. I can ask to
change my prom in worst case.

Regards,
Gleb.

Re: [patch] linux 2.4.5: Export mips_machtype

[Maciej W. Rozycki]

On Mon, 13 Aug 2001, Gleb O. Raiko wrote:

> >  Note that for PCI-based systems, there is usually no problem -- PCI IDs
> > can be used instead in most cases.
> 
> How? In fact, I've got two different boards with the same Ethernet chip.
> Moreover, mach type shall be known as early as possible, early than pci
> init for sure. Just imagine, I need a way to identify PCI controller by
> mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I
> miss something in your proposal?

 The PCI ID of a host bridge is usually sufficient to differentiate most
systems for onboard devices that are not reported on PCI.  If it is not
for your one, you just fall outside of the scope of "most cases" and you
need a different way to identify a system.  Note I do not promote
mips_machtype removal.

> BTW, in my Baget case, I just need a number for mach type. I can ask to
> change my prom in worst case.

 How do you set up mips_machtype on your system in the first place?  At
kernel_entry the code does not know what machine it's running on anyway,
so it has to set mips_machtype based on a detection algorithm. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [patch] linux 2.4.5: Export mips_machtype

[Keith M Wesolowski]

On Tue, Aug 14, 2001 at 07:43:23PM +0200, Maciej W. Rozycki wrote:

>  How do you set up mips_machtype on your system in the first place?  At
> kernel_entry the code does not know what machine it's running on anyway,
> so it has to set mips_machtype based on a detection algorithm. 

Of course.  I published a patch and some documentation a long time ago
for doing just this.  I don't think anyone ever even read any of it; I
received no comments.  In any case it's currently used in my tree for
O2 and although I know it could be better it seems to work rather
well.

-- 
Keith M Wesolowski <wesolows@foobazco.org> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
 	"There is no such song as 'Acid Acid Acid' by 'The Acid Heads'
	 but there might as well be." --jwz

Re: [patch] linux 2.4.5: Export mips_machtype

[Ilya Volynets]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 15 August 2001 10:44, Keith M Wesolowski wrote:
> On Tue, Aug 14, 2001 at 07:43:23PM +0200, Maciej W. Rozycki wrote:
> >  How do you set up mips_machtype on your system in the first place?  At
> > kernel_entry the code does not know what machine it's running on anyway,
> > so it has to set mips_machtype based on a detection algorithm.
>
> Of course.  I published a patch and some documentation a long time ago
> for doing just this.  I don't think anyone ever even read any of it; I
> received no comments.  In any case it's currently used in my tree for
> O2 and although I know it could be better it seems to work rather
> well.
Not true. I read it, and thought it's good enough to leave as is :-)
No comments seemed to be nessesary.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iEYEARECAAYFAjt6ubgACgkQtKh84cA8u2nZhgCg2eg3Z48ZjXca9x3Rctt48Jj9
oisAoKEF2LQz3tnIc+I+j6nfSnOdFKgG
=+aUM
-----END PGP SIGNATURE-----

Soft-Float emulation with gcc - pr3900

[Zoon]

Hello, 

Although this message is more about gcc, I post here,
since I got no answer from gcc mailing lists.

I use egcs-2.91.66(Algorithmics tools) configured as a
cross-compiler on a i386 host. I got the binary
version, so didn't configured it myself.

I'm working with a PR3900 type MIPS core. Those core
don't have a Floating Point Unit, nor floating point
registers.
When using -msoft-float, I am supposed to use the
libgcc soft floating point emulation. However, I
cannot prevent gcc from using fp registers.
When looking at gcc specs:

$ mips-linux-gcc -dumpspecs | grep r3900
..
%{m3900:-mips1 -mcpu=r3900 -mfp32 -mgp32}...

The option -mfp32 is defined as the default, which
means gcc assume 32 bit fp registers are available.

I am aware of two soft-float emulation libraries:
Gofast and libgcc. However I can't figure out how
emulation can be achieved if gcc keeps using fp
registers. 

I must miss something about it, could someone help me
with this matter ?

Many thanks,
Alain

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

Re: [patch] linux 2.4.5: Export mips_machtype

[Gleb O. Raiko]

"Maciej W. Rozycki" wrote:
> 
> On Mon, 13 Aug 2001, Gleb O. Raiko wrote:
> 
> > >  Note that for PCI-based systems, there is usually no problem -- PCI IDs
> > > can be used instead in most cases.
> >
> > How? In fact, I've got two different boards with the same Ethernet chip.
> > Moreover, mach type shall be known as early as possible, early than pci
> > init for sure. Just imagine, I need a way to identify PCI controller by
> > mach type, so I need to scan pci busses for specific ID. Boom. :-) Did I
> > miss something in your proposal?
> 
>  The PCI ID of a host bridge is usually sufficient to differentiate most
> systems for onboard devices that are not reported on PCI.  If it is not
> for your one, you just fall outside of the scope of "most cases" and you
> need a different way to identify a system.  Note I do not promote
> mips_machtype removal.

In order to read a PCI ID, you need to know how to do it. In pc world,
you may rely on configuation access types, at least, ports are known. On
other arches, you need to know where such "ports" are. Even if hardware
supports, say, configuration type 1 accesses, developers are free to put
port addresses anywhere.

> 
> > BTW, in my Baget case, I just need a number for mach type. I can ask to
> > change my prom in worst case.
> 
>  How do you set up mips_machtype on your system in the first place?  At
> kernel_entry the code does not know what machine it's running on anyway,
> so it has to set mips_machtype based on a detection algorithm.
> 

First, mips_machtype is accessed far later than kernel_entry is
executed. Personally, I am lucky :-), I may read firmware environment
variables.

Regards,
Gleb.

Re: [patch] linux 2.4.5: Export mips_machtype

[Maciej W. Rozycki]

On Thu, 23 Aug 2001, Gleb O. Raiko wrote:

> In order to read a PCI ID, you need to know how to do it. In pc world,
> you may rely on configuation access types, at least, ports are known. On
> other arches, you need to know where such "ports" are. Even if hardware
> supports, say, configuration type 1 accesses, developers are free to put
> port addresses anywhere.

 Yep, I see.  MIPS is quite special here, because, unlike for Alphas,
PowerPCs, SPARCs, etc. there is a couple of independend vendors making
systems, so there is no single way of obtaining a system ID.  So you need
to know how to access chipset from elsewhere.

> >  How do you set up mips_machtype on your system in the first place?  At
> > kernel_entry the code does not know what machine it's running on anyway,
> > so it has to set mips_machtype based on a detection algorithm.
> 
> First, mips_machtype is accessed far later than kernel_entry is

 That's quite obvious -- nothing can be done in Linux earlier. ;-)  But
you need to initialize mips_machtype somehow.

> executed. Personally, I am lucky :-), I may read firmware environment
> variables.

 Well, other system might as well (e.g. DECstations can), but that doesn't
solve the problem -- to access firmware variables you need to know which
kind of firmware you are on. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [patch] linux 2.4.5: Export mips_machtype

[Jun Sun]

"Maciej W. Rozycki" wrote:
> 
> On Thu, 23 Aug 2001, Gleb O. Raiko wrote:
> 
> > In order to read a PCI ID, you need to know how to do it. In pc world,
> > you may rely on configuation access types, at least, ports are known. On
> > other arches, you need to know where such "ports" are. Even if hardware
> > supports, say, configuration type 1 accesses, developers are free to put
> > port addresses anywhere.
> 
>  Yep, I see.  MIPS is quite special here, because, unlike for Alphas,
> PowerPCs, SPARCs, etc. there is a couple of independend vendors making
> systems, so there is no single way of obtaining a system ID.  So you need
> to know how to access chipset from elsewhere.
> 
> > >  How do you set up mips_machtype on your system in the first place?  At
> > > kernel_entry the code does not know what machine it's running on anyway,
> > > so it has to set mips_machtype based on a detection algorithm.
> >
> > First, mips_machtype is accessed far later than kernel_entry is
> 
>  That's quite obvious -- nothing can be done in Linux earlier. ;-)  But
> you need to initialize mips_machtype somehow.
> 
> > executed. Personally, I am lucky :-), I may read firmware environment
> > variables.
> 
>  Well, other system might as well (e.g. DECstations can), but that doesn't
> solve the problem -- to access firmware variables you need to know which
> kind of firmware you are on.
> 

I talked about machine detection a while back.  My idea is following:

0. all machines that are *configured* into the image will supply <my>_detect()
and <my>_setup() functions.

1. at MIPS start up, we loop through all <my>_detect(), which returns three
values, a) run-time detection negative, b) run-time detection positive, and c)
no run-time detection code, but I return positive because I am configured in.

2. the startup code resolves conflicts (which sometimes may panic); and decide
on one machine.

3. then the startup code calls the right <my>_setup() code which will set up
the mach_type and other stuff. 

BTW, a side benenfit of doing this is that we can remove all the machine
specific code in common files such as bootinfo.h, setup.c, etc, which are
getting harder and harder to maintain as we are adding more and more embedded
boards to the tree.  

If we push it to an extreme by using mechnism like do_initcalls(), we can
achieve zero common source file modification when adding a new a machine. 
This will greatly facilitate embedded development as it allows more parallel
development and allow people to maintain their own board code much easier
before the code is submitted to the tree.

Jun

Re: [patch] linux 2.4.5: Export mips_machtype

[Maciej W. Rozycki]

On Thu, 23 Aug 2001, Jun Sun wrote:

> I talked about machine detection a while back.  My idea is following:
> 
> 0. all machines that are *configured* into the image will supply <my>_detect()
> and <my>_setup() functions.
> 
> 1. at MIPS start up, we loop through all <my>_detect(), which returns three
> values, a) run-time detection negative, b) run-time detection positive, and c)
> no run-time detection code, but I return positive because I am configured in.
> 
> 2. the startup code resolves conflicts (which sometimes may panic); and decide
> on one machine.
> 
> 3. then the startup code calls the right <my>_setup() code which will set up
> the mach_type and other stuff. 

 It sounds reasonable.  We may also check the Alpha port for solutions --
it supports multiple dissimilar systems as well.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [patch] linux 2.4.5: Export mips_machtype

[Gleb O. Raiko]

"Maciej W. Rozycki" wrote:
>  It sounds reasonable.  We may also check the Alpha port for solutions --
> it supports multiple dissimilar systems as well.

Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at
fixed location anyway. 

In our case, almost every box has own location for kernel varying from
0x80000000 for brave people to 0x80100000 for people who doesn't care
much about 1 MB :-). (Well, I clearly understand it's firmware
requirements, not people's preferences. Almost.) Then, various binary
formats of the kernel image...

I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP
stuff.

However, I doubt whether we could support single kernel image for all
MIPS boxes. MIPS is typical embedded platform, where standards are
favourite because there are so many to choose from.

BTW, I remember, Ralf tried to implement CPU type recognition at
run-time, he dropped his efforts after he realized nobody could use this
feature because boxes are so different.

Regards,
Gleb.

Re: [patch] linux 2.4.5: Export mips_machtype

[Maciej W. Rozycki]

On Fri, 24 Aug 2001, Gleb O. Raiko wrote:

> Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at
> fixed location anyway. 

 I mean the way platform-specific backends get installed, not the way each
of the family members get detected.  The firmware is not used beyond the
initial setup stage -- hardware is addressed directly at run time.

> In our case, almost every box has own location for kernel varying from
> 0x80000000 for brave people to 0x80100000 for people who doesn't care
> much about 1 MB :-). (Well, I clearly understand it's firmware
> requirements, not people's preferences. Almost.) Then, various binary
> formats of the kernel image...

 But due to the MIPS design there MUST be RAM starting from the physical
address 0x00000000 as exception vectors are installed at virtual addresses
starting from 0x80000000.  So except for twisted systems that only map a
few kilobytes of memory at 0x00000000 (SGI systems do, I'm told) there
exists an address, say 0x80100000 as you quoted or maybe a different one
which yet needs to be determined, which would suit most if not all
platforms.

 Such a kernel would not be meant to be run as the best one.  It would be
useful for end users to bootstrap a distribution installation at least for
the workstation/server class of MIPS hardware (ditto for MIPS64), but
possibly for certain dedicated one, too.  Given a lot of kernel images
it's not always obvious to the user which one to choose -- remember mid
nineties (pre-modules) whan you had a bunch of distribution kernel images
with different SCSI controllers and possibly network interfaces (think NFS
install) on the i386?  It wasn't nice at all... 

> I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP
> stuff.

 I'm just quoting Alpha since I know it best beside i386 and MIPS.

> However, I doubt whether we could support single kernel image for all
> MIPS boxes. MIPS is typical embedded platform, where standards are
> favourite because there are so many to choose from.

 We could try our best, though. 

> BTW, I remember, Ralf tried to implement CPU type recognition at
> run-time, he dropped his efforts after he realized nobody could use this
> feature because boxes are so different.

 I think Jun's proposal is promising -- just let each vendor provide an
own function to detect own hardware.

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [patch] linux 2.4.5: Export mips_machtype

[Jun Sun]

"Gleb O. Raiko" wrote:
> 
> "Maciej W. Rozycki" wrote:
> >  It sounds reasonable.  We may also check the Alpha port for solutions --
> > it supports multiple dissimilar systems as well.
> 
> Alpha is easy and simple from my POV, it has just SRM or MILO, kernel at
> fixed location anyway.
> 
> In our case, almost every box has own location for kernel varying from
> 0x80000000 for brave people to 0x80100000 for people who doesn't care
> much about 1 MB :-). (Well, I clearly understand it's firmware
> requirements, not people's preferences. Almost.) Then, various binary
> formats of the kernel image...
> 
> I personally prefer PPC with its _machine tricks and SPARC for BTFIXUP
> stuff.
> 
> However, I doubt whether we could support single kernel image for all
> MIPS boxes. MIPS is typical embedded platform, where standards are
> favourite because there are so many to choose from.
> 

No way to support all MIPS machines with a single kernel image - you have the
difference of BE and LE at least. :-)

Seriously, I found two cases where we do like to have one image supporting
multiple boards:

1) several CPU daughter boards plugging into one base baord - in the case we
really need to configure a kernel with multipe CPUs.

2) A reference design board is modified slightly and used in other products. 
- A typicaly change might be in interrupt routing, or some base address shift,
or removing some IOs.  In this case, we just need a slightly different board
setuo() function for each board.

I don't think it is fruitful trying to go to the extreme by having a single
image serving as many boxes as possible.

> BTW, I remember, Ralf tried to implement CPU type recognition at
> run-time, he dropped his efforts after he realized nobody could use this
> feature because boxes are so different.
>

CPU code is getting more crowded and uglier these days too, because more
vendors are adding their own CPUs.  Each CPU, in most cases, has its unique
hazards, which requires a separate low-level routines.  Even with the coming
MIPS32 and MIPS64 standard, we cannot count on vendors have totally conforming
CPUs.  I think it is about time to create a CPU abstraction which allows more
individualism.
 
Jun

Re: [patch] linux 2.4.5: Export mips_machtype

[Gleb O. Raiko]

"Maciej W. Rozycki" wrote:
>  Well, other system might as well (e.g. DECstations can), but that doesn't
> solve the problem -- to access firmware variables you need to know which
> kind of firmware you are on.
> 

No way at run-time. You have to choose the box during compilation in
order to supply linker with proper load address.

Regards,
Gleb.

Re: [patch] linux 2.4.5: Export mips_machtype

[Maciej W. Rozycki]

On Fri, 24 Aug 2001, Gleb O. Raiko wrote:

> >  Well, other system might as well (e.g. DECstations can), but that doesn't
> > solve the problem -- to access firmware variables you need to know which
> > kind of firmware you are on.
> 
> No way at run-time. You have to choose the box during compilation in
> order to supply linker with proper load address.

 Does your firmware have a fixed load or entry address?  If so, it begs
for a position-independent boot loader (but not PIC in the ELF sense)  --
something like aboot for Alpha that can interpret ELF and optionally unzip
an image beforehand (aboot can't probably execute anywhere, though, as I
don't think gcc is able to emit such code).  Workstation/server class
firmware can usually deal with arbitrary load and entry addresses, but it
requires defining an interface to pass these values to the firmware and
certainly you don't have to put a kitchen sink into every piece of
firmware, especially for lightweight systems. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: [patch] linux 2.4.5: Export mips_machtype

[Harald Koerfgen]

On Monday 13 August 2001 17:53, Ralf Baechle wrote:
> On Mon, Aug 13, 2001 at 03:26:23PM +0200, Maciej W. Rozycki wrote:
> >  The following patch exports mips_machtype to modules.  Please apply.
>
> Ok - but I'd like to burry the whole mips_machtype mechanism in 2.5.  To
> messy and requires a central authority to allocate machine types.  What
> do you think?

Well, it doesn't neccessarily have to be called mips_machtype, but, yes, we 
would need something similar at least for DECstations.

	Harald