Subject: Re: structuring interrupt machine in ppoea-renovation
To: Chris Gilbert <>
From: Toru Nishimura <>
List: port-arm
Date: 05/11/2007 10:41:05
Chris Gilbert replies;

[ ... talking about ppcoea-renovation ... ]

> On an initial look over the code, I can see some areas that have 
> improved.  Mainly around pic handling.
> ...
> Also the code looks to regularly write and set the irq masks in the 
> hardware, which is something we try to avoid on arm, as any time you 
> touch hardware is slow, especially if it's in every spl(9) routine.
> ...
> I never change the hardware mask unless it's necessary.
>  ...
> An spl change just updates a software value, if the spl drops and there 
> are ipls pending, we jump into the interrupt handling code and deal with 
> them. 

Understood.  On my ARM9 porting assignment I've realised and
learned how smart two global variables to handle "defered interrupt
delivery," and I renamed them to "_deferred" and "_toblock" to
make them highlighted for attention.

I hope you to have talk with Macheal Lorez and Tim Rightnour. Some
ppc developers are making progress to adapt their idea for various
"system controller" HW.  Their invention is so attractive to deliver
complicated interrupts in a very simple form.  The following is the case
for MPC824x which has "OpenPIC," a prioritized interrupt controller
much like ARM VIC (NetBSD does not use HW prioritized vector
scheme in favour of spl, anyway).  Here, the OpenPIC #0 interrupt
request routes classic i8259 in popular South bridge to deliver 0..15
legacy ISA (8 + 8 indeed) IRQ.  
         * Prepare EPIC and install external interrupt handler.
         *  0..15       used by South bridge i8259 PIC if exists.
         *  16..39/41   EPIC interrupts, 24 source or 26 source.
        /* set up i8259 as a cascade on EPIC irq 0 */
        isa_pic = setup_i8259();
        (void)setup_openpic(baseaddr, 0);
        intr_establish(16, IST_LEVEL, IPL_NONE, pic_handle_intr, isa_pic);

That's all needed.  Tim made MI framework to handle whole ISA stuff
(and PCI) to handle.  In essense, a very few number of files (two or three)
remain necessary to adapt the target port.

> Is tftp not enough?

A number of reasons;
- I'm sticked with classic Cyclone since I found that ABLE can not work for
  me and I switched back to Cyclone.
- NFS read can transfer twice large load (1024 than 512).
- ELF kernel on exported diskless root directory to eliminate a duplicated
  copy on /tftproot/

Toru Nishimura / ALKYL Technology