"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
port-mips?

> 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
> >anyways.
>
> 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.

Yes.

> >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
> >implementation).
> >  
> >
> 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.

Cheers,
Simon.
--
Simon Burge                            <simonb@wasabisystems.com>
NetBSD Support and Service:         http://www.wasabisystems.com/