I've taken GNATs off the CC list, since this discussion doesn't need to 
be in the bug, I think.  More below...

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.

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

>  
>
>>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?

>  
>
>>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
>implementation).
>  
>
Yes, the PB1000 config should be renamed to something like ALCHEMY or 
DB1XXX or somesuch.

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

    -- Garrett

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