Subject: Re: port-evbmips/31992: alchemy ICU is too Au1000 specific
To: Garrett D'Amore <email@example.com>
From: Simon Burge <firstname.lastname@example.org>
Date: 11/10/2005 15:34:39
"Garrett D'Amore" wrote:
> I've taken GNATs off the CC list, since this discussion doesn't need to
> be in the bug, I think. More below...
There's still a few gnats-style addresses above - maybe move this all to
> Simon Burge wrote:
> >>>>The interrupt strings for the au_icu.c (and some of the identifiers,
> >>>>etc.) are really indicative of the specific Au1000 port, and do not
> >>>>reflect the general Alchemy family.
> >>>>This can actually lead to confusing output, e.g. from vmstat -e,
> >>>>because the interrupts are not wired the same on all parts.
> >>>>A better solution, IMO, is to generalize the strings to "irq XX".
> >>>>This provides less information than the current port does, but at
> >>>>least the information is not incorrect! (And someone familiar with a
> >>>>given board can easily lookup up the IRQ mappings if needed. And the
> >>>>actual drivers print out the IRQ they are on at attach time, so it
> >>>>should all be good. :-)
> >>>The way I'd previously worked around this was to have a table per
> >>>supported CPU type, similar to the way that aubus.c does things. While
> >>>you can refer back to dmesg for interrupt number assignments, I think
> >>>I prefer to see the irq names in vmstat -e/-i without having to do the
> >>>cross-referencing elsewhere.
> >>I've not looked at this too closely, but can any of the interrupt lines
> >>other than those associated with specific busses (PCI, PCMCIA) be pulled
> >>off the processor? (In other words, is this mapping specific to a
> >>board, or to a processor? If it is processor specific, then this is
> >>good enough, but if it can vary from board to board, then I'd prefer to
> >>just leave it general.)
> >The interrupt definitions there are CPU specific, not board specific.
> >For example, all the "gpio" interrupts are specific to hard-wired GPIO
> >pins, but what those pins are connected to on a specific board can vary.
> Okay, and I see now that there are PSC mappings, etc. which can go to
> different kinds of parts (PCMCIA, different memorys, I2C, AC'97, etc.)
> So I'd request that the strings in this file only reflect the details of
> the processor -- i.e. report an interrupt as being for "psc3" rather
> than "AC97", because the mapping of AC97 to psc3 is a board specific detail.
Yah, that's it exactly.
> >>My assumption as far as vmstat -e related stuff was that (for this port
> >>at least) most embedded developers will more or less "know" the
> >>interrupt routing for their board, and frankly might not be too bothered
> >>by having to go back and forth. (Granted, for someone like you with a
> >>lot of different ports that you maintain, this isn't such a big deal.)
> >>My other consideration is that with more and more parts coming out, it
> >>becomes somewhat onerous to write up a new table for each new part, and
> >>that folks will be tempted not to make it correct. The current evidence
> >>with the table being horribly wrong sort of serves as evidence of this.
> >We already need a table for the devices on the bus. This is what I
> >meant but putting all processor-specific information in a single file,
> >then it's easy to update all info for a new processor.
> Hmm.. there are a couple of ways to do this:
> 1) detection at run time (what is currently done)
> 2) selection at compile time with separate files
> 3) selection at compile time via config option and #ifdef's in a single file
> 4) allow support for either #1 or #3 based on a config directive
> I personally like option #4, which gives the best of all worlds, I
> think. Is there some reason, other than the size of the kernel, to
> separate out the processor support for different alchemy parts? I can't
> think of any. So option number 4 lets you still build a generic kernel,
> but it also lets you build a leaner proc-specific config.
One reason is size - you probably don't want info about Au1000 devices
in your product if it's only using a Au1550. Also, there's the
maintainability side. Right now, you need to change a few files to add
support for a new CPU. I'd like to centralise this. Also, lots of
#ifdef's start to get ugly. So I'm proposing:
5) allow support for either #1 or #2 based on a config directive
> >>I also don't have details on IRQ mappings for each of the
> >>boards/processors. (Granted, I could probably go search the CD-ROM I
> >>got for specs for the other parts...)
> >See above - we don't need to know board details at this level.
> This is good news. See my comments above about making sure that we only
> report mappings that are known for the processor, and don't have some
> board-specific mapping.
> >>>I've also been thinking of stripping out tables for each CPU in to their
> >>>own files, and having a way of just configuring support for a single CPU
> >>>type, instead of always being able to support CPUs (and devices) for all
> >>>Alchemy CPU types that exist. While it's sometimes convenient (eg, I
> >>>don't have to use a different kernel when I turn a different board on
> >>>here and boot with tftp kernel), I think it makes more sense from an
> >>>embededed POV to just support the CPU and features you need.
> >>Yes, I am strongly in favor of this, and actually *need* it not just
> >>per-processor but per *board*. This is because there are some details,
> >>like PCI interrupt routing, that are *board* specific and cannot be
> >>determined programmatically.
> >As long as you can identify which board you are running on at run-time,
> >you can do this. Unfortunately Alchemy didn't have a board-id FPGA
> >register on the PB1000, but only boards after that. For PCI, all
> >Alchemy eval boards have the ability to identify themselves. As I
> >mention further down, you'll probably have your own kernel config
> Hmmm... I've not groked around for the board-id FPGA. This could be
> very useful. I'd be willing to use this to build a "generic" kernel for
> the alchemy boards. Do you have any more info about this FPGA, or
> should I go RTFM?
Look on one of the CDs - for the DBAu1500 for example look for
DbAu1500/Docs/Zinfandel_Registers.pdf and look at the WHO_AM_I register.
> >>I already have some of this separated out in my Au1550 workspace, and
> >>I'll be sending you diffs.
> >>Therefore, when the PCI diffs come to you, they will include different
> >>kernel configs (and board-specific .c files) for each of the supported
> >>platforms (which as of right now are DbAu1500 and DbAu1550, because
> >>that's all I have to test with.)
> >Certainly the PB1000 kernel config just supported the PB1500 and
> >DBAu1500 without any problems, although of course there's no PCI support
> >for the latter two. However, for a simple "boots to multiuser with
> >ethernet and serial support", a single kernel config file is handy.
> Yes, and indeed I've been using that with changes even on the Au1550.
> And if I can glean the board ids, then I can even keep this around while
> continuing to support PCI and other board-specific features (granted at
> the cost of additional kernel bloat.)
> >For PCI support, etc, we can still do some run-time detection, but
> >having separate kernel config files per board for space reasons also
> >makes sense.
> I like having both options.
> >Also, my original plan was to have PB1000 (which probably should be
> >renamed to something more generic) only support the Alchemy eval boards.
> >A full port to your board if it were contributed back to NetBSD would
> >almost certainly have a separate kernel config file to the Alchemy eval
> >boards (unless it was very close to one or more of these boards in
> Yes, the PB1000 config should be renamed to something like ALCHEMY or
> DB1XXX or somesuch.
I was thinking something like ALCHEMY myself. Not DB1XXX since the
kernel also works on the PB1xxx boards too.
> And my port will have a separate config file (and probably *not* be
> contributed back to NetBSD, though the kernel bits of source code apart
> from some low level hacks to the boot rom support will probably be
> contributed back). But right now I'm working with DBAu1500 and DBAu1550
> boards until I get our own hardware. (So I'm working on improving
> support for those boards.)
Cool that you're working on it! I know of another NetBSD developer who
was planning on a port to a small Au1500 box (meshcube?), and they'll be
able to leverage off this too.
Simon Burge <email@example.com>
NetBSD Support and Service: http://www.wasabisystems.com/