Message-ID: <0cd7f288-ba43-7764-01a7-2e1e5c7a1640@linux-m68k.org>
Date:   Sat, 25 Mar 2023 10:35:52 +1100 (AEDT)
From:   Finn Thain <fthain@...ux-m68k.org>
To:     Brad Boyer <flar@...andria.com>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] nubus: Don't list card resources by default

Hi Brad,

On Fri, 24 Mar 2023, Brad Boyer wrote:

> On Fri, Mar 24, 2023 at 10:13:51AM +1100, Finn Thain wrote:
> > On Thu, 23 Mar 2023, Geert Uytterhoeven wrote:
> > > On Thu, Mar 23, 2023 at 7:02???AM Finn Thain <fthain@...ux-m68k.org> wrote:
> > > > --- a/drivers/nubus/nubus.c
> > > > +++ b/drivers/nubus/nubus.c
> > > > @@ -34,6 +34,9 @@
> > > >
> > > >  LIST_HEAD(nubus_func_rsrcs);
> > > >
> > > > +bool procfs_rsrcs;
> > > > +module_param(procfs_rsrcs, bool, 0444);
> > > 
> > > With the expanded functionality, is "rsrcs" still a good name?
> > > Perhaps this should be an integer, so you can define different
> > > levels? E.g.
> > >   - 0 = just devices
> > >   - 1 = above + boards + public resources
> > >   - 2 = above + private resources
> > 
> > That really depends on how the proc entries get used. I think it's 
> > probably going to be developers who would use them so I consider all 
> > of this to be outside of the UAPI and subject to change. But it would 
> > be nice to hear from other developers on that point.
> 
> I don't know of anything that currently uses them, but there's a number 
> of potential uses depending on how far we want to take things. A real 
> video driver for X.org for some of the more advanced cards could take 
> advantage of some of the secondary information made available. I've got 
> a number of NuBus video cards with some acceleration capabilities that 
> were pretty advanced for the time.

Good point. I had not considered Xorg drivers. But I'm not sure why 
userspace drivers would access /proc when they already need /dev/mem or 
some more modern graphics API to be implemented by an in-kernel driver.

> There's even a driver in the ROM on video cards that could be used, but 
> that also requires more emulation of the MacOS environment. KVM could 
> potentially need more information if we got it running on m68k, although 
> I doubt any real Mac has enough RAM to make that useful.

You only need a few MB to run MacOS (or an early Linux distro). So I 
rather think that KVM could be workable with 64 or 128 MB of RAM.

The /proc/bus/nubus/boards file is not affected by this patch, so userland 
tools could still identify the available boards if need be.

> I haven't looked at a Radius Rocket (a Mac on a card) to see if it has 
> anything useful in these, but I wouldn't be surprised if there are 
> useful things there. I've never tried to boot Linux on a system with one 
> installed or booting Linux on the card itself. I have booted a second 
> instance of the MacOS on one, and I seem to recall it shows up as a 
> Q900. I have a couple x86 system cards that were intended to run DOS as 
> well. There was an Apple II card for the LC slot, but I don't own one. 
> LC slot cards show up in software as NuBus, as I recall.
> 

I think those cards are in the same category as video cards in the sense 
that userspace drivers would need /dev/mem.

> It wouldn't be in userspace, but we could end up needing to pull 
> firmware out of them for a number of different cards. I've got a couple 
> SCSI cards that would need to have firmware loaded at runtime, and the 
> ROM would have the default version even if we also allow a firmware file 
> to override that. Based on the existing qlogicpti.c code, the ISP 1000 
> chip (found on ATTO SiliconExpress IV cards) needs firmware. The older 
> SiliconExpress cards all appear to use various ESP chips, so they likely 
> don't need anything special. I suspect the various MCP based cards have 
> useful things on the ROM for a driver to use. They each have a 68000 
> chip on them running A/ROSE, which is presumably loaded from firmware as 
> well. I have both ethernet and serial cards based on this platform. It 
> appears that a driver for the specific card has to be loaded into A/ROSE 
> on the card after it boots.
> 

I had not considered that /proc could be used that way. Unfortunately, the 
length of procfs entries is limited to PAGESIZE. Larger entries are listed 
but have length 0. So I think this isn't going to fly.

Probably /dev/mem or a MacOS utility, or a ROM dump created by a MacOS 
utility, would be needed to extract firmware from the MacOS ROM, such as 
the firmware used by the IOP co-processors (which are standard equipment 
on some models). The same solutions (though not ideal) could also work for 
slot resources.

> I've got a bunch of cards that I've never even looked at the resources 
> built into the ROM chips, so I'm guessing on what might or might not be 
> useful. At one point I was buying every card I could find that looked 
> interesting, and many of them I've never tested. I have crates full of 
> stuff, plus a bunch stacked up that came in original boxes.
> 
> Checking them is disabled now, but some Macs have fake NuBus resources 
> for some of the onboard devices that show up as if they were in a 
> virtual NuBus slot 0. Scanning that apparently caused problems on some 
> models (presumably a bus error, since it would be accessing invalid 
> addresses). Really old kernels had code to scan that protected by a 
> compile time option.
> 

I can't figure out why procfs access to the slot resources from pseudo 
slot 0 would be desirable (?)

Powered by blists - more mailing lists