Subject: Re: port-evbmips/31992: alchemy ICU is too Au1000 specific
To: None <,,>
From: Simon Burge <>
List: netbsd-bugs
Date: 11/10/2005 03:39:02
The following reply was made to PR port-evbmips/31992; it has been noted by GNATS.

From: Simon Burge <>
To: "Garrett D'Amore" <>
Subject: Re: port-evbmips/31992: alchemy ICU is too Au1000 specific 
Date: Thu, 10 Nov 2005 14:37:58 +1100

 "Garrett D'Amore" wrote:
 > Simon Burge wrote:
 > > wrote:
 > >
 > >>>Number:         31992
 > >>>Category:       port-evbmips
 > >>>Synopsis:       alchemy ICU is too Au1000 specific
 > >>>      
 > >>>
 > >>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.
 > 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.
 > 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.
 > >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
 > 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.
 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.
 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
 Simon Burge                            <>
 NetBSD Support and Service: