BlizzardPPC SCSI support!
Radosław Kujawa
I am pleased to present a driver for BlizzardPPC 603e+ SCSI controller.
BPPC "+" model has 53C710 chip. This driver utilizes our MD siop backend and is mostly based on wesc.c (Warp Engine has the same chip).
Currently driver will try to attach to any BlizzardPPC - vendor 8512, product 110. Obviously, it should attach to "+" models only, but I don't have BPPC without SCSI. I see some solutions, but I don't like them:
- bang the hardware and see if this part of bus space behaves like 53C710 (seems dangerous)
- check serial number (will not work if someone messed with the card)
- we could just leave driver commented out in GENERIC
I have no idea what will happen now if there's no SCSI chip, maybe someone will check and post the results ;).
For now I tested this only on m68k. The driver does DMA transfers, so performance is fine, but this may be a problem on ppc.
amiga.files config:
# Phase5 Blizzard 603e+ SCSI
device bppcsc: scsi, asiop
attach bppcsc at zbus
file arch/amiga/dev/bppcsc.c bppcsc needs-flag
kernel config:
bppcsc0 at zbus0 # BlizzardPPC 603e+ scsi
scsibus* at bppcsc0
Frank Wille
Rados?aw Kujawa <radosla...@c0ff33.net> wrote:
> I am pleased to present a driver for BlizzardPPC 603e+ SCSI controller.
Congratulations! :)
> BPPC "+" model has 53C710 chip. This driver utilizes our MD siop backend
> and is mostly based on wesc.c (Warp Engine has the same chip).
Indeed, the source is identical, besides the initialization of dcntl and
ctest7. It could make sense to avoid duplication of code and just extend
wesc.c to support the BPPC.
> Currently driver will try to attach to any BlizzardPPC - vendor 8512,
> product 110. Obviously, it should attach to "+" models only, but I don't
> have BPPC without SCSI. I see some solutions, but I don't like them:
> - bang the hardware and see if this part of bus space behaves like 53C710
> (seems dangerous)
Yes, not so good.
> - check serial number (will not work if someone messed with the card)
Do you know the serial numbers to check for?
> - we could just leave driver commented out in GENERIC
Maybe I would check for the serial number when this is safe. Those who
really messed with the card know what they are doing and have to build
their own kernel.
> I have no idea what will happen now if there's no SCSI chip, maybe
> someone will check and post the results ;).
Test results from a second person are always welcome.
> For now I tested this only on m68k. The driver does DMA transfers, so
> performance is fine, but this may be a problem on ppc.
That's fine. So you can help debugging the DMA problems in amigappc. ;)
--
Frank Wille
--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-...@muc.de
Radosław Kujawa
On Jan 8, 2011, at 1:32 AM, Frank Wille wrote:
> On Sat, 8 Jan 2011 00:40:13 +0100
> Radoslaw Kujawa <radosla...@c0ff33.net> wrote:
>
>> I am pleased to present a driver for BlizzardPPC 603e+ SCSI controller.
> Congratulations! :)
Thanks ;).
>> BPPC "+" model has 53C710 chip. This driver utilizes our MD siop backend
>> and is mostly based on wesc.c (Warp Engine has the same chip).
>
> Indeed, the source is identical, besides the initialization of dcntl and
> ctest7. It could make sense to avoid duplication of code and just extend
> wesc.c to support the BPPC.
There are some other subtle differences (in dmaintr routine, match, attachment code), but these could be merged very easily.
I though about merging similar drivers for 53C710-based controllers into one. But I'm hesitant to touch a driver I can't test. That's why I created a new driver. Anyone on this list owns Warp Engine? A4091?
>> - check serial number (will not work if someone messed with the card)
>
> Do you know the serial numbers to check for?
Yes, only BPPC with SN Ixx-xxxx has SCSI.
>
>> - we could just leave driver commented out in GENERIC
>
> Maybe I would check for the serial number when this is safe. Those who
> really messed with the card know what they are doing and have to build
> their own kernel.
Ok, later today I'll prepare a new version which does this. Should be trivial.
--
Best regards,
Radosław Kujawa
Bernd Ernesti
>
> On Jan 8, 2011, at 1:32 AM, Frank Wille wrote:
>
> > Radoslaw Kujawa <radosla...@c0ff33.net> wrote:
> >
> >> I am pleased to present a driver for BlizzardPPC 603e+ SCSI controller.
> > Congratulations! :)
>
> >> BPPC "+" model has 53C710 chip. This driver utilizes our MD siop backend
> >> and is mostly based on wesc.c (Warp Engine has the same chip).
> >
> > Indeed, the source is identical, besides the initialization of dcntl and
> > ctest7. It could make sense to avoid duplication of code and just extend
> > wesc.c to support the BPPC.
>
>
> I though about merging similar drivers for 53C710-based controllers into one. But I'm hesitant to touch a driver I can't test. That's why I created a new driver. Anyone on this list owns Warp Engine? A4091?
I have a Warp Engine but the NetBSD installation is old.
Bernd
Alan Hourihane
> On Jan 8, 2011, at 1:32 AM, Frank Wille wrote:
>
> > Radoslaw Kujawa <radosla...@c0ff33.net> wrote:
> >
> >> I am pleased to present a driver for BlizzardPPC 603e+ SCSI controller.
> > Congratulations! :)
>
> >> BPPC "+" model has 53C710 chip. This driver utilizes our MD siop backend
> >> and is mostly based on wesc.c (Warp Engine has the same chip).
> >
> > Indeed, the source is identical, besides the initialization of dcntl and
> > ctest7. It could make sense to avoid duplication of code and just extend
> > wesc.c to support the BPPC.
>
>
> I though about merging similar drivers for 53C710-based controllers into one. But I'm hesitant to touch a driver I can't test. That's why I created a new driver. Anyone on this list owns Warp Engine? A4091?
Yes, I have both. I need to setup a new NetBSD though.
Alan.
Ignatios Souvatzis
> I though about merging similar drivers for 53C710-based controllers into one. But I'm hesitant to touch a driver I can't test. That's why I created a new driver. Anyone on this list owns Warp Engine? A4091?
but why? most of the driver *is* in two or three shared files, and having
the frontend for each card in a different file makes it possible to
remove it from configuration, should problems appear, etc., by adding
a simple "no bppcsc* at zbus0" ... to the kernel config file.
The actual code is only a couple of lines, isn't it? And what's different
is interupt setup, hardware initialization (e.g. ctest7) and having them
seperate helps with clarity and debugging.
Regards,
-is
Frank Wille
> On Sat, Jan 08, 2011 at 12:18:54PM +0100, Rados?aw Kujawa wrote:
>
>> I though about merging similar drivers for 53C710-based controllers
>> into one. But I'm hesitant to touch a driver I can't test. That's why
> I created a new driver. Anyone on this list owns Warp Engine? A4091?
>
> but why? most of the driver *is* in two or three shared files, and
> having the frontend for each card in a different file makes it possible
> to remove it from configuration, should problems appear, etc., by
> adding a simple "no bppcsc* at zbus0" ... to the kernel config file.
>
> The actual code is only a couple of lines, isn't it? And what's
> different is interupt setup, hardware initialization (e.g. ctest7) and
> having them seperate helps with clarity and debugging.
Ok, that's what we wanted to know. I was anxious to bloat the generic kernel
even more, which is always an issue on Amigas.
So the current driver only needs a check for the correct serial number, to
make sure an scsi host is present, and it can be committed just in time for
6.0. :)
Radosław Kujawa
On Jan 8, 2011, at 4:39 PM, Frank Wille wrote:
> So the current driver only needs a check for the correct serial number, to
> make sure an scsi host is present, and it can be committed just in time for
> 6.0. :)
Updated driver attached, works for me, it should work for everyone. People with a non-SCSI BPPC should test if match function fails for them.
Frank Wille
> Updated driver attached, works for me, it should work for everyone.
> People with a non-SCSI BPPC should test if match function fails for
> them.
Maybe you shouldn't call it "scsi controller"? The right term would be "host
adapter", IIRC.
And usually your own license will go on top of the original code's license,
but I'm not really sure about those things either.
Otherwise it looks ok, and I would commit it after a delay of a week or so,
to give everybody a chance to notice and to object. ;)
Frank Wille
> Also: bppcsc(4) manual page :-).
Thanks.
Although you may consider to make it more similar to the wesc, mgnsc, wesc,
zssc man pages.
Radosław Kujawa
On Jan 9, 2011, at 1:05 PM, Frank Wille wrote:
> Radoslaw Kujawa wrote:
>
>> Also: bppcsc(4) manual page :-).
>
> Thanks.
> Although you may consider to make it more similar to the wesc, mgnsc, wesc,
> zssc man pages.
I considered this, but I found "description" section of these man pages unclear. For example, existence of common machine dependent backend (siop.c) is totally omitted. Adding "diagnostics" section to bppcsc(4) would be useful, indeed.
On Jan 9, 2011, at 1:03 PM, Frank Wille wrote:
> Radoslaw Kujawa wrote:
>
>> Updated driver attached, works for me, it should work for everyone.
>> People with a non-SCSI BPPC should test if match function fails for
>> them.
>
> Maybe you shouldn't call it "scsi controller"? The right term would be "host
> adapter", IIRC.
You are right, feel free to make this change before commit - the driver is working well for me, so I don't think I'll be making any more changes to it.
> And usually your own license will go on top of the original code's license,
> but I'm not really sure about those things either.
/usr/share/misc/style is not clear about this... Licenses were also copied from wesc.c, where newer is at the bottom. Again, feel free to rearrange it before commit.
> Otherwise it looks ok, and I would commit it after a delay of a week or so,
> to give everybody a chance to notice and to object. ;)
Ok, so I'll return to hacking on wdc_fastata4k and amigappc stuff ;).