Hi,

I have an sbus-based coprocessor board (see
http://www.classiccmp.org/transputer/bbks4.htm) that used to work fine
under Solaris 2.6, but it no longer works correctly under Solaris 10.0.
I suspect this is due to the 32-bit vs 64-bit kernel issue. However,
the way that boards are setup is the following:

Create two symlinks in /dev:
sbus1 -> /devices/iommu@0,10000000/sbus@0,10001000/sbusmem@1,0:slot1
sbus2 -> /devices/iommu@0,10000000/sbus@0,10001000/sbusmem@2,0:slot2

These two links are then opened in the application to communicate back
and forth with the SBUS card. I do have the source code to the actual
application. Eventhough, it is doing raw reads/writes to the SBUS
card, do I need to compile the application in 64-bit or 32-bit? Since
it really doesnt have a device driver and uses the raw drivers, how
does it work??

Thanks,

Ram

PS: The machine if anyone is interested is an Ultra-2 Enterprise with
Dual 400Mhz processors and 2GB of memory running Solaris 10 in 64-bit
mode

In comp.unix.solaris rmeenaks@olf.com wrote:
> I have an sbus-based coprocessor board (see
> http://www.classiccmp.org/transputer/bbks4.htm) that used to work fine
> under Solaris 2.6, but it no longer works correctly under Solaris 10.0.
> I suspect this is due to the 32-bit vs 64-bit kernel issue.

Right. You'll have to have 64-bit drivers.

> Create two symlinks in /dev:
> sbus1 -> /devices/iommu@0,10000000/sbus@0,10001000/sbusmem@1,0:slot1
> sbus2 -> /devices/iommu@0,10000000/sbus@0,10001000/sbusmem@2,0:slot2

So the targets there are the device files which are handled by the
driver (which you probably don't have).

> These two links are then opened in the application to communicate back
> and forth with the SBUS card. I do have the source code to the actual
> application.

Do you have source to the driver?

> Eventhough, it is doing raw reads/writes to the SBUS
> card, do I need to compile the application in 64-bit or 32-bit?

Either is fine. Unless it's doing something esoteric, leaving the
application 32-bit shouldn't be an issue.

> Since
> it really doesnt have a device driver and uses the raw drivers, how
> does it work??

Huh? I don't follow that sentence.

Almost certainly your system needs a driver for the SBUS hardware.
Without it, those device files aren't going to work.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

Hi Darren,

Thanks for the response. The two device files /dev/sbus0 and
/dev/sbus1 are Solaris-supplied devices and are supposed to be the raw
sbus cards that are present in the machine. The so-called application
(which is really an a bunch of functions to use the card) is just
opening, reading, writing, and closing the /dev/sbus0. So, it is doing
raw access to the sbus card. Hence, there really isnt any device
driver in Solaris terms.

Since it is doing such raw access, does it need to be 32-bit or 64-bit
if I recompile it under Solaris 10. Would it work? I might run into
similar issues with another device (a SCSI device) that probably does
the same thing. However, I dont have the source for the SCSI device
unfortunately...

Any help is much appreciated,

Ram

In article <1128373832.416676.181240@g14g2000cwa.googlegroups .com>,
rmeenaks@olf.com wrote:

> Hi Darren,
>
> Thanks for the response. The two device files /dev/sbus0 and
> /dev/sbus1 are Solaris-supplied devices and are supposed to be the raw
> sbus cards that are present in the machine. The so-called application
> (which is really an a bunch of functions to use the card) is just
> opening, reading, writing, and closing the /dev/sbus0. So, it is doing
> raw access to the sbus card. Hence, there really isnt any device
> driver in Solaris terms.
>
> Since it is doing such raw access, does it need to be 32-bit or 64-bit
> if I recompile it under Solaris 10. Would it work? I might run into
> similar issues with another device (a SCSI device) that probably does
> the same thing. However, I dont have the source for the SCSI device
> unfortunately...
>
> Any help is much appreciated,
>
> Ram

Excuse me, but I think I misunderstand this. Unless there's a driver
that attaches to the card, there won't be a /dev/sbus0 device? Yes?
So, you _are_ using a driver to access the card. It's my understanding
that's how UNIX works. The question is, what driver? And is there a
64-bit version on Solaris 10?

--
DeeDee, don't press that button! DeeDee! NO! Dee...

In comp.unix.solaris rmeenaks@olf.com wrote:
> Hi Darren,

> Thanks for the response. The two device files /dev/sbus0 and
> /dev/sbus1 are Solaris-supplied devices and are supposed to be the raw
> sbus cards that are present in the machine.

I don't think so.

Do you still have these devices (on a pre-10 machine)?

Please do the following on it..

#1 ls -lL /dev/sbus0

You'll get a major and minor number separated by a comma like this: (my
example is on a different file) (That's a lower-case L, not a 1).

$ ls -lL /dev/rmt/0cbn
crw-rw-rw- 1 root sys 33,2783 Oct 3 03:38 /dev/rmt/0cbn

#2 grep for the major number (the first one) in /etc/name_to_major

$ grep 33 /etc/name_to_major
st 33
cvcredir 133
wrsm 233

Thanks.

> The so-called application
> (which is really an a bunch of functions to use the card) is just
> opening, reading, writing, and closing the /dev/sbus0. So, it is doing
> raw access to the sbus card. Hence, there really isnt any device
> driver in Solaris terms.

That's like saying an an application that just opens,reads, etc. from
/dev/rmt/0cbn isn't using a driver. Yes it is. The operating system
knows the file is special and passes the requests on to the driver. The
app itself doesn't know about the driver, but the OS does.

> Since it is doing such raw access, does it need to be 32-bit or 64-bit
> if I recompile it under Solaris 10.

The driver (which isn't part of the application) must be the same as the
running kernel (64-bit on SPARC Solaris 10)

The application can do everything you've said so far as a 32-bit app, no
problem.

> Would it work?

Only if the driver is there.

> I might run into
> similar issues with another device (a SCSI device) that probably does
> the same thing. However, I dont have the source for the SCSI device
> unfortunately...

Also, it's more likely that Solaris 10 comes with a SCSI driver
already. I doubt that there's one for your SBUS device in the base OS.

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

rmeenaks@olf.com writes:
>Thanks for the response. The two device files /dev/sbus0 and
>/dev/sbus1 are Solaris-supplied devices and are supposed to be the raw
>sbus cards that are present in the machine. The so-called application
>(which is really an a bunch of functions to use the card) is just
>opening, reading, writing, and closing the /dev/sbus0. So, it is doing
>raw access to the sbus card. Hence, there really isnt any device
>driver in Solaris terms.

/dev/sbus0 and /dev/sbus1 don't exist normally. Your device driver
must map in under these names. If there were system supplied drivers
that had these names, they should show up in section 7d of the man
pages, but nothing there... My Ultra SBUS systems don't have these
devices even though they have SBUS cards installed.

Solaris systems typically don't have generic device drivers for raw
accessing. *All* devices typically require device drivers written, even
if its just some raw access to some registers on the card.

So, if you don't have a working 64-bit driver for these cards, you are
fighting an uphill battle, and you'll either have to revert to an OS
level that supports the drivers you have, pester the maker to build
drivers to match your desired OS, or reverse engineer your old driver,
write a new one, and hope the Ultra 2 support still exists later on
for the many man-month effort you exerted.


>Since it is doing such raw access, does it need to be 32-bit or 64-bit
>if I recompile it under Solaris 10. Would it work? I might run into
>similar issues with another device (a SCSI device) that probably does
>the same thing. However, I dont have the source for the SCSI device
>unfortunately...

No such thing as raw access in Solaris.

Doug McIntyre <merlyn@geeks.org> wrote:

> rmeenaks@olf.com writes:
> >Thanks for the response. The two device files /dev/sbus0 and
> >/dev/sbus1 are Solaris-supplied devices and are supposed to be the
> >raw sbus cards that are present in the machine. The so-called
> >application(which is really an a bunch of functions to use the card)
> >is just opening, reading, writing, and closing the /dev/sbus0. So,
> >it is doing raw access to the sbus card. Hence, there really isnt
> >any device driver in Solaris terms.
>
> /dev/sbus0 and /dev/sbus1 don't exist normally. Your device driver
> must map in under these names. If there were system supplied drivers
> that had these names, they should show up in section 7d of the man
> pages, but nothing there... My Ultra SBUS systems don't have these
> devices even though they have SBUS cards installed.

Hmm, I have the same card in use (under Solaris 2.5.1) and without
being a specialist on these terms: there isn't a driver...

Just put in the card, create the links and the applications will
use them. Really.

Could it have something to do with the proms on the card?

Orgel

--
I have seen things you lusers would not believe. I've seen Sun
monitors on fire off the side of the multimedia lab. I've seen
NTU lights glitter in the dark near the Mail Gate. All these
things will be lost in time, like the root partition last week.

In article <20051004064546.3aee4676.legro70@netscape.net>,
Thomas Orgelmacher <legro70@netscape.net> wrote:

> Doug McIntyre <merlyn@geeks.org> wrote:
>
> > rmeenaks@olf.com writes:
> > >Thanks for the response. The two device files /dev/sbus0 and
> > >/dev/sbus1 are Solaris-supplied devices and are supposed to be the
> > >raw sbus cards that are present in the machine. The so-called
> > >application(which is really an a bunch of functions to use the card)
> > >is just opening, reading, writing, and closing the /dev/sbus0. So,
> > >it is doing raw access to the sbus card. Hence, there really isnt
> > >any device driver in Solaris terms.
> >
> > /dev/sbus0 and /dev/sbus1 don't exist normally. Your device driver
> > must map in under these names. If there were system supplied drivers
> > that had these names, they should show up in section 7d of the man
> > pages, but nothing there... My Ultra SBUS systems don't have these
> > devices even though they have SBUS cards installed.
>
> Hmm, I have the same card in use (under Solaris 2.5.1) and without
> being a specialist on these terms: there isn't a driver...
>
> Just put in the card, create the links and the applications will
> use them. Really.
>
> Could it have something to do with the proms on the card?
>
> Orgel

Nope. When you "create the links", the OS is recognizing the device and
assigning a driver to that device. If you look at the device files with
ls -l, the major and minor numbers will be displayed. You can look
those up as has been previously described.

So, a driver is _really_ being used to access this device. Truly.
Otherwise, there would be no device file created. This is how the I/O
system works on UNIX even if you don't realize it.

--
DeeDee, don't press that button! DeeDee! NO! Dee...

Darren Dunham <ddunham@redwood.taos.com> writes:

>Almost certainly your system needs a driver for the SBUS hardware.
>Without it, those device files aren't going to work.

Well, with VME and Sbus there are some default memory mappings which
do not require an actual device driver... You can just map the device
using generic devices.

Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

In comp.unix.solaris Thomas Orgelmacher <legro70@netscape.net> wrote:
> Hmm, I have the same card in use (under Solaris 2.5.1) and without
> being a specialist on these terms: there isn't a driver...

Can you run those two commands on your 2.5.1 machine I had in the other
post?

ls -lL /dev/sbus0

Then take the number before the comma and do...

grep <number> /etc/name_to_major

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >