Simon Burge wrote:

>"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?
>  
>
Done. :-)  For those of you just tuning in, look at port-evbmips/31992 
if you want the back history. :-)

>  
>
>>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.
>  
>
Sounds like we're in violent agreement. :-)  OK, I'll take a look at 
changing my patch to do this.  Probably not until tomorrow, tho'.

>  
>
>>>>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
>  
>
OK.  I'll do it this way, then.

>>>>>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.
>  
>
Thanks, this is really helpful.

>  
>
>>>>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.
>  
>
Yep.  The ALCHEMY name is probably best.  What boards do you have access 
to for testing?  I have a DBAu1500 and DBAu1550, but nothing else.

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

    -- Garrett

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