Re: New Amiga drivers coming for Linux 4.18
Hi Adrian,
On Thu, Apr 19, 2018 at 11:26 PM, John Paul Adrian Glaubitz
wrote:
> As of today, two new m68k drivers have been merged into the staging trees
> of the Linux kernel.
Not staging, but linux-next. Staging is something different ;-)
> * zorro_esp [1]:
> * xsurf100 [2]:
I am happy to see hardware support for m68k being increased in the upstream
kernel. It seems m68k support is far from being dropped from the kernel, and
we survived many evictions of other "obsolete" architectures.
> Both drivers will be available in Linux 4.18 and I will enable those drivers
> in upcoming versions of the debian-installer and the Debian m68k installation
> images.
Live long and prosper!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: New Amiga drivers coming for Linux 4.18
Hi Finn, Am 20.04.2018 um 15:33 schrieb Finn Thain: > On Fri, 20 Apr 2018, Michael Schmitz wrote: > >> >> What's not supported right now is Oktagon SCSI - in contrast to the >> above, this card does not have a DMA engine. We have pseudo-DMA support >> in the Mac ESP driver, but the Mac uses a 1:1 mapping of physical >> addresses into kernel virtual space while the Amiga uses an offset >> mapping. The Mac PDMA code would need some modifications for this board >> (ideally, just accounting for some offset, nothing major). If someone's >> keen to give it a try and wants more details, just let me know. > > A PDMA algorithm like the one in g_NCR5380 may be more relevant here (?) Might be an alternative, yes. But can we monitor the DRQ status in the ESP interrupt or status registers? The 5380 is a dumb piece of hardware and must expose all these details, the 53C9x is a lot smarter and may not. > On Macs, the PDMA logic circuit is found in a custom Apple ASIC. This > suggests that the mac_esp PDMA algorithm may not be very portable. Much as I hate to admit that, but despite Apple's use of custom logic, the details of the PDMA algorithm may vary but the concept itself is quite portable. > Moreover, this algorithm won't work unless the logic circuits in Oktagon > cards raise the appropriate bus faults, as derived from the DMA signalling > from the ESP chip. Looking at oktakon_io.S from the 2.16 series, it's using an exception table similar to the Mac PDMA code (the main difference is that the Mac PDMA has the transfer loop unrolled). So it would appear the PDMA logic on the Oktagon board can raise a bus fault to signal transfer errors. Cheers, Michael
Re: New Amiga drivers coming for Linux 4.18
Hi Geert! On 04/20/2018 09:43 AM, Geert Uytterhoeven wrote: On Thu, Apr 19, 2018 at 11:26 PM, John Paul Adrian Glaubitz wrote: As of today, two new m68k drivers have been merged into the staging trees of the Linux kernel. Not staging, but linux-next. Staging is something different ;-) You're right. I wasn't talking about "the" staging drivers though, but just git trees that are used to stage the changes before they get into Linus' main tree. But I agree, using "staging" in this context is a bit misleading. * zorro_esp [1]: * xsurf100 [2]: I am happy to see hardware support for m68k being increased in the upstream kernel. It seems m68k support is far from being dropped from the kernel, and we survived many evictions of other "obsolete" architectures. We already have the next project to work on. I attached the USB module "RapidRoad" to the X-Surf100 networking card [1]. The board is based on the isp1763 chip for which there is a driver in the Linux kernel already. Both drivers will be available in Linux 4.18 and I will enable those drivers in upcoming versions of the debian-installer and the Debian m68k installation images. Live long and prosper! Btw, there is something to worry about regarding m68k support in gcc. The gcc folk is threatening to remove the backend if it doesn't get ported over to the new backend code base. I don't have enough knowledge about gcc yet in order to assess how difficult it would be to make that port. But I will do my best to prevent the backend from being dropped. Adrian [1] http://wiki.icomp.de/wiki/RapidRoad -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: New Amiga drivers coming for Linux 4.18
Hi, On Fri, 20 Apr 2018, Michael Schmitz wrote: > The new ESP driver supports CyberStorm I and II, Blizzard 2060 (all > recently tested by Adrian and Christian). Blizzard 1230 II and IV > (last tested by Tuomas Vainikka a few years ago on an earlier version > of this driver), and FastLane (no idea when that was last tested). > > Also not supported is Cyberstorm 060 SCSI - that one shares the same > Zorro ID as Fastlane / Blizzard 1230 II, and ZorroII boards will be > probed as a Blizzard 1230. Looking at the Zorro board data, it should > be possible to tell the boards apart - if someone has such a board and > can provide some data, I can easily add support now that the driver > has been accepted. Sorry for my ignorance, but what is a Cyberstorm 060 SCSI, if it's not the Cyberstorm I or II? Charlie
Re: New Amiga drivers coming for Linux 4.18
Charlie, Am 20.04.2018 um 22:02 schrieb Karoly Balogh (Charlie/SGR): > Hi, > > On Fri, 20 Apr 2018, Michael Schmitz wrote: > >> The new ESP driver supports CyberStorm I and II, Blizzard 2060 (all >> recently tested by Adrian and Christian). Blizzard 1230 II and IV >> (last tested by Tuomas Vainikka a few years ago on an earlier version >> of this driver), and FastLane (no idea when that was last tested). >> >> Also not supported is Cyberstorm 060 SCSI - that one shares the same >> Zorro ID as Fastlane / Blizzard 1230 II, and ZorroII boards will be >> probed as a Blizzard 1230. Looking at the Zorro board data, it should >> be possible to tell the boards apart - if someone has such a board and >> can provide some data, I can easily add support now that the driver >> has been accepted. > > Sorry for my ignorance, but what is a Cyberstorm 060 SCSI, if it's not the > Cyberstorm I or II? As far as I can see from the old driver code, it's a Cyberstorm I but the board ID is the same as is used for the Blizzard 1230 II and Fastlane boards. I called it Cyberstorm 060 because the Linux board ID macro is named ZORRO_PROD_PHASE5_BLIZZARD_1230_II_FASTLANE_Z3_CYBERSCSI_CYBERSTORM060 Happy to use the correct name for this particular board type, if someone can give a definite answer. Is this simply a Cyberstorm I with another ID, or something subtly different? Cheers, Michael > > Charlie >
Re: New Amiga drivers coming for Linux 4.18
On Fri, 20 Apr 2018, Michael Schmitz wrote: > > Looking at oktakon_io.S from the 2.16 series, it's using an exception > table similar to the Mac PDMA code (the main difference is that the Mac > PDMA has the transfer loop unrolled). Yes, it seems so. > So it would appear the PDMA logic on the Oktagon board can raise a bus > fault to signal transfer errors. > I think the comments and transfer loops in oktagon_esp.c refute this interpretation. On Macs (at least) the PDMA bus fault is not a transfer error, it is a handshaking/pacing mechanism. I think that's an important distinction (especially after having tried and failed to get bus_error030() fixed). Recall that the scsi target always controls the transfer, not the initiator. Naturally scsi targets care not at all about processor bus timing, and naturally the processor cares not at all about ESP DMA signals. Hence the need for special handshaking logic. Bus faults would appear to be inevitable and normal occurrences during transfers. (Alternatively, the PDMA logic can buffer the transfer instead, which is the approach used by 53C400 chips. In this case bus errors never arise.) --
