support for NCR voyager (3/4/5xxx series)

support for NCR voyager (3/4/5xxx series)

Post by James Bottomle » Tue, 11 Jun 2002 03:00:10



This patch adds SMP (and UP) support for voyager which is an (up to 32 way)
SMP microchannel non-PC architecture.

There's basically nothing different from the 2.5.15 one except for updates and
changes to the arch-split and a few #include file additions.

The patch is in two parts:  The i386 sub-architecture split is separated from
the addition of the voyager components

http://www.hansenpartnership.com/voyager/files/arch-split-2.5.21.diff (165k)
http://www.hansenpartnership.com/voyager/files/voyager-2.5.21.diff (148k)

(The split diff is pretty huge because it's actually moving files about).  You
must apply the split diff before applying the voyager one.

These two patches are also available as separate bitkeeper trees (the voyager
tree is a superset of the arch-split one):

http://linux-voyager.bkbits.net/voyager-2.5
http://linux-voyager.bkbits.net/arch-split-2.5

James Bottomley

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by James Bottomle » Sat, 15 Jun 2002 01:00:07



Quote:> Attached patch is needed to compile kernel with Voyager patch applied
> for the SMP PC machine.

I've applied it to my repository, thanks.  I forgot to keep track of these
issues in the voyager tree when I separated the arch-split stuff.

Quote:> [Q1] Will it be better to  create separate directory for PC
> architecture and split some PC'isms from arch/i386/generic ? Right now
> it contains acpi.c, bootflag.c and dmi_scan.c which are not generic in
> any way :)

The thinking currently is that arch/i386 is really PC plus a few exceptions
rather than a truly generic x86 plus additonal machine architectures, so it
makes sense under this view that `generic' and PC be the same thing.

Quote:> [Q2] May be directory naming like mach-visws, mach-voyager and
> possible  mach-pc will be more convinent ?

To be more consistent with the way arch/arm does it?  Certainly the renames
can be done easily enough, what does the rest of the list think?

James

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Dave Jone » Sat, 15 Jun 2002 08:30:08


 > > [Q1] Will it be better to  create separate directory for PC
 > > architecture and split some PC'isms from arch/i386/generic ? Right now
 > > it contains acpi.c, bootflag.c and dmi_scan.c which are not generic in
 > > any way :)
 > The thinking currently is that arch/i386 is really PC plus a few exceptions
 > rather than a truly generic x86 plus additonal machine architectures, so it
 > makes sense under this view that `generic' and PC be the same thing.

Would it make sense for the subarchs to use the generic code where possible,
and only reimplement it's own (for eg) apic.c as and when it actually
*needs* to be different ?

For the most part, I'd expect the existing subarchs we know about
(sgi visws, voyager, numaq), the amount of "own version" copies of
files would be quite low.

The big advantage of doing it this way, is that it reduces the overhead
of having to update every subarch when someone changes function
parameters. The downside is possibly slightly ickier Makefile's.

 > > [Q2] May be directory naming like mach-visws, mach-voyager and
 > > possible  mach-pc will be more convinent ?
 > To be more consistent with the way arch/arm does it?  Certainly the renames
 > can be done easily enough, what does the rest of the list think?

Sounds quite logical. What does the current patches you have do ?
I've not had chance to look at them yet.

        Dave

--
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by James Bottomle » Sat, 15 Jun 2002 09:20:05



Quote:> Would it make sense for the subarchs to use the generic code where
> possible, and only reimplement it's own (for eg) apic.c as and when it
> actually *needs* to be different ?

That is really the way I've implemented it.  The only PC specific file in the
generic directory is mpparse.c (since neither visws nor voyager has an MP
compliant bios).  All the shareable files are kept in `kernel' and activated
by config options.

I can certainly move mpparse.c back to kernel and add an extra (non user
visible) config option.

Quote:> Sounds quite logical. What does the current patches you have do ? I've
> not had chance to look at them yet.

It creates directories `generic' for the standard pc and `visws'.  The voyager
patch creates a `voyager' directory.  Alternatively, these could be `mach-pc',
`mach-visws' and `mach-voyager'.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Dave Jone » Sat, 15 Jun 2002 10:00:10


 > > Would it make sense for the subarchs to use the generic code where
 > > possible, and only reimplement it's own (for eg) apic.c as and when it
 > > actually *needs* to be different ?
 > That is really the way I've implemented it.

Ah, good.

 >  The only PC specific file in the
 > generic directory is mpparse.c (since neither visws nor voyager has an MP
 > compliant bios).  All the shareable files are kept in `kernel' and activated
 > by config options.

Another piece of low* fruit is probably dmi_scan.c
There are no workarounds there for either (are they even DMI compliant?)
so compiling it in doesn't make much sense.

 > I can certainly move mpparse.c back to kernel and add an extra (non user
 > visible) config option.

if neither visws or voyager need it, I'd say it doesn't belong in the
respective subarch directories period.

 > > Sounds quite logical. What does the current patches you have do ? I've
 > > not had chance to look at them yet.
 > It creates directories `generic' for the standard pc and `visws'.  The voyager
 > patch creates a `voyager' directory.  Alternatively, these could be `mach-pc',
 > `mach-visws' and `mach-voyager'.

Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
cast my vote for that one. If nothing else, it makes it obvious that
the subdir isn't important if you don't care about $subarch

        Dave.

--
| Dave Jones.        http://www.veryComputer.com/
| SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://www.veryComputer.com/
Please read the FAQ at  http://www.veryComputer.com/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Matthew D. Pitt » Sat, 15 Jun 2002 11:20:06


Quote:>  > > Sounds quite logical. What does the current patches you have do ?
I've
>  > > not had chance to look at them yet.
>  > It creates directories `generic' for the standard pc and `visws'.  The
voyager
>  > patch creates a `voyager' directory.  Alternatively, these could be
`mach-pc',
>  > `mach-visws' and `mach-voyager'.

> Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
> cast my vote for that one. If nothing else, it makes it obvious that
> the subdir isn't important if you don't care about $subarch

I think it would be a good idea as well.

Matthew

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Mark Atwoo » Sat, 15 Jun 2002 12:00:09


Is there a mapping between the Host,Channel,Id,Lun of a SCSI device as
reported in /proc/scsi/scsi, and the the /dev/sd* names and/or the
major/minor device numbers?

I've done some experamentation, and the more obvious ways of doing
the mapping dont seem to be 100%.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Douglas Gilber » Sat, 15 Jun 2002 13:30:11


Mark Atwood write:

Quote:> Is there a mapping between the Host,Channel,Id,Lun of a SCSI device as
> reported in /proc/scsi/scsi, and the the /dev/sd* names and/or the
> major/minor device numbers?

> I've done some experamentation, and the more obvious ways of doing
> the mapping dont seem to be 100%.

Mark,
There are several utilities discussed at this url:
http://www.torque.net/sg/u_index.html
including scsidev and sg_map. Devfs shows you this mapping
via its hierarchy:
$ ls -l
total 0
brw-------    1 root     root       8,   0 Dec 31  1969 disc
crw-r-----    1 root     root      21,   0 Dec 31  1969 generic
brw-------    1 root     root       8,   1 Dec 31  1969 part1
$ pwd
/dev/scsi/host1/bus0/target0/lun0/

None of these approaches is completely satisfactory. Kurt Garloff
is working on a patch that seems to address this problem quite
cleanly:

$ cat /proc/scsi/map
# C,B,T,U       Type    onl     sg_nm   sg_dev  nm      dev
0,0,00,00       05      1       sg0     c:15:00 sr0     b:0b:00
1,0,01,00       05      1       sg1     c:15:01 sr1     b:0b:01
1,0,03,00       05      1       sg3     c:15:03 sr2     b:0b:02
1,0,05,00       00      1       sg4     c:15:04 sda     b:08:00
1,0,09,00       00      1       sg5     c:15:05 sdb     b:08:10
1,0,02,00       01      1       sg2     c:15:02 osst0   c:ce:00
2,0,01,00       05      1       sg6     c:15:06 sr3     b:0b:03
2,0,02,00       01      1       sg7     c:15:07 osst1   c:ce:01
2,0,03,00       05      1       sg8     c:15:08 sr4     b:0b:04
2,0,09,00       00      1       sg10    c:15:0a sdd     b:08:30
3,0,10,00       00      1       sg11    c:15:0b sde     b:08:40
3,0,12,00       00      1       sg12    c:15:0c sdf     b:08:50

Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Andrey Pani » Sat, 15 Jun 2002 22:50:09




>  > > Would it make sense for the subarchs to use the generic code where
>  > > possible, and only reimplement it's own (for eg) apic.c as and when it
>  > > actually *needs* to be different ?
>  > That is really the way I've implemented it.

> Ah, good.

>  >  The only PC specific file in the
>  > generic directory is mpparse.c (since neither visws nor voyager has an MP
>  > compliant bios).  All the shareable files are kept in `kernel' and activated
>  > by config options.

> Another piece of low* fruit is probably dmi_scan.c
> There are no workarounds there for either (are they even DMI compliant?)
> so compiling it in doesn't make much sense.

We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.

Quote:>  > I can certainly move mpparse.c back to kernel and add an extra (non user
>  > visible) config option.

> if neither visws or voyager need it, I'd say it doesn't belong in the
> respective subarch directories period.

"Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
function MP_processor_info() from generic mpparse.c. May be it makes sence
to move to some generic file ?

Quote:>  > > Sounds quite logical. What does the current patches you have do ? I've
>  > > not had chance to look at them yet.
>  > It creates directories `generic' for the standard pc and `visws'.  The voyager
>  > patch creates a `voyager' directory.  Alternatively, these could be `mach-pc',
>  > `mach-visws' and `mach-voyager'.

> Yeah, I think mach-foo would be more aesthetically pleasing, so I'll
> cast my vote for that one. If nothing else, it makes it obvious that
> the subdir isn't important if you don't care about $subarch

>         Dave.

--
Andrey Panin            | Embedded systems software engineer

  application_pgp-signature_part
< 1K Download
 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Dave Jone » Sat, 15 Jun 2002 23:00:11


 > We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.

apm may be present on the others (need visws/voyager folks to comment on
that I guess), but bootflag and acpi I'd suspect not.

 > "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
 > function MP_processor_info() from generic mpparse.c. May be it makes sence
 > to move to some generic file ?

Is that the one from the visws sourceforge project ?

        Dave

--
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Andrey Pani » Sat, 15 Jun 2002 23:00:15




>  > We also have apm.c, bootflag.c and acpi.c which are definetely PC specific.

> apm may be present on the others (need visws/voyager folks to comment on
> that I guess), but bootflag and acpi I'd suspect not.

IMHO Voyagers are too old and big machines to get (working) APM,
and visws have no BIOS or limited BIOS emulation.

Quote:>  > "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
>  > function MP_processor_info() from generic mpparse.c. May be it makes sence
>  > to move to some generic file ?

> Is that the one from the visws sourceforge project ?

Yes it is.

--
Andrey Panin            | Embedded systems software engineer

  application_pgp-signature_part
< 1K Download
 
 
 

support for NCR voyager (3/4/5xxx series)

Post by James Bottomle » Sat, 15 Jun 2002 23:20:09



Quote:> IMHO Voyagers are too old and big machines to get (working) APM, and
> visws have no BIOS or limited BIOS emulation.

That depends what you mean by `apm'.  In kernel/apm.c, it's tied to the
existence of the APM bios and since voyagers have no bios per say (they
actually have a SUS, which is an actively running boot OS on a tiny i386
processor which can emulate a minimal PC bios when in PC mode) then you're
correct.

Running Linux on a voyager, I can power off the machine, read the internal
power source, the status of the front panel switch and even trigger a power
management shutdown after the AC power is lost for a certain length of time
(voyagers usually have internal lead acid batteries).  The way it's currently
set up, if I turn off the front panel switch, the machine will execute a clean
shutdown and power itself off when the shutdown is finished.  (this is mainly
done in the voyager_thread.c file, where it keeps a kernel daemon permanently
monitoring the machine status, if you're interested).

The above are all traditional APM functions, I just don't need apm.c to do
them.

However, apm.c is still in arch/i386/kernel, just in case, so I think
mpparse.c should join it, and we should keep all the other pieces (bootflag.c
and acpi.c) in there just in case.

James

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

support for NCR voyager (3/4/5xxx series)

Post by Dave Jone » Sat, 15 Jun 2002 23:20:10


 > >  > "Latest" (2.4.17) visws patch which i'm planning to convert for 2.5, uses
 > >  > function MP_processor_info() from generic mpparse.c. May be it makes sence
 > >  > to move to some generic file ?
 > > Is that the one from the visws sourceforge project ?
 > Yes it is.

Ah good. *cross item off TODO list*

        Dave

--
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

 
 
 

1. support for NCR voyager (3/4/5xxx series)

This patch adds SMP (and UP) support for voyager which is an (up to 32 way)
SMP microchannel non-PC architecture.

There's basically nothing different from the 2.5.15 one except for merge fixes
and changes to the tlb and process init code.

The patch is in two parts:  The i386 sub-architecture split is separated from
the addition of the voyager components

http://www.hansenpartnership.com/voyager/files/arch-split-2.5.15.diff (144k)
http://www.hansenpartnership.com/voyager/files/voyager-2.5.15.diff (148k)

(The split diff is pretty huge because it's actually moving files about).  You
must apply the split diff before applying the voyager one.

These two patches are also available as separate bitkeeper trees (the voyager
tree contains the arch-split tree):

http://linux-voyager.bkbits.net/voyager-2.5
http://linux-voyager.bkbits.net/arch-split-2.5

James Bottomley

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. Compact Flash Reader

3. can't read proc/PID/environ or other - top and vmstat freeze - soft reboot freeze

4. gtk-1.2.2 helloworld.c problem?? maybe glibc??

5. USR 14.4k fax/modem

6. support for NCR voyager

7. support for NCR voyager 343x/345x/4100/51xx architecture