headers
nick thompson | 8 May 2007 22:51

Netwinder available anywhere???

Hello all,
 I have been scouring ebay, and I just haven't seen any come up. Anyway,
does anyone know where to buy one online / know of one sitting in a
closet? ;p

Nick

"All unix, all the time."

http://npt.ath.cx
Permalink | Reply | 0 comments |
headers
Chris Gilbert | 11 May 2007 01:56
Picon

Re: structuring interrupt machine in ppoea-renovation

Toru Nishimura wrote:
> Attention for cat owners,
(this is also relevant for netwinder, which has the same footbridge & 
ISA issues)

> There is much interesting activities is going in "ppoea-renovation"
> branch and your cats could be benefited by feeding the idea from
> it.
>
> The HW has slots for PCI and ISA which are to mimic standard
> PC-alike configuration with ALi1543C and 21285 footbridge.
> Constructing the whole interrupt machinery has been a hard
> practice since mixing different breed interrupt HW designs into a single
> working one would bring forehead-bang'ng-at-neary-by-wall burdens.
> To solve the issue Macheal Lorenz and Tim Rightnour made a single,
> unified and extensible construct for PPC to house multiple interrupt HW
> sources;
>
> - can cope well with interrupt source > 32.
> - can add and cascade many interrupt HW sources.
> - can do the smart things for spl(9) and softintr(9), e.g., multiple NICs
>  populated separately in PCI/ISA slots (and possiblely ones build
>  inside SoC core) can be handled in the right fashion by IPL_NET.

On an initial look over the code, I can see some areas that have 
improved.  Mainly around pic handling.  Certainly the loop in 
pic_do_pending_int does the same as the cats one, it works through irqs 
in bitwise order changing the spl to match, so if BIT 1 is IPL_NET, bit 
2 is IPL_BIO and bit 3 is IPL_NET, bit 3 risks being starved  (note that 
I'm not familiar with the powerpc code so may not be understanding it
(Continue reading)

Permalink | Reply | 6 comments |
headers
Toru Nishimura | 11 May 2007 03:41

Re: structuring interrupt machine in ppoea-renovation

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Toru Nishimura | 11 May 2007 04:33

Re: structuring interrupt machine in ppoea-renovation

Chris Giberts sez;

> I'd like to think other arm hardware can switch to it quickly, eg ep93xx 
> springs to mind as being able to switch over quickly, as it's in the 
> position of having 2 banks of 32 irqs.

The following is the code excerpt I've sent to port-power <at>  some time
ago;

> Robert Swindells  asked;
>
>> How is the new interrupt code designed to be used on systems that have
>> interrupt enables and masks split over multiple registers ?

struct ipic_ops {
        struct pic_ops pic;
        uint32_t pending_events_x;    /* 8 external source */
        uint32_t pending_events_l;    /* 32 source 0..31 */
        uint32_t pending_events_h;    /* 32 source 32..63 */
        uint32_t enable_mask_x;
        uint32_t enable_mask_l;
        uint32_t enable_mask_h;
}

The lines is for "Intergrated PIC" found in some MPC82xx/83xx PowerQUICC
product family.  The IPC brings upto 64 independent interrupt sources from
SoC buildin peripheral devices and 8 independent sources from external
device hooked with the MPC.

The central idea of Michael's achievement is to offer an encapsulation, or
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nick Hudson | 11 May 2007 17:55
Picon

cyclone vs ABLE [was Re: structuring interrupt machine in ppoea-renovation]

On Friday 11 May 2007 00:56, Chris Gilbert wrote:
> Toru Nishimura wrote:
[...]
> > I'm planning to build 2nd-stage netboot loader to make cats possible
> > to do DHCP/NFS netboot.  The goal is to provide true ELF kernel
> > loading with DDB symbol table and no size limit.

YAY!

> Is tftp not enough?  I think that ABLE ELF kernels should be able to use
> symbols from the ELF image, I've not looked closely enough to see if the
> ABLE bootloader includes or excludes the symbol table when loading the
> kernel.

ABLE is, well, not very...

Nick
Permalink | Reply | 0 comments |
headers
Doug Brewer | 18 May 2007 08:25
Picon

Re: What's difference between ARM_VECTORS_LOW and ARM_VECTORS_HIGH?

Toru Nishimura  wrote:
> Doug Brewer asks;
>
> > Would you tell me what's diffrenece between ARM_VECTORS_LOW and
> > ARM_VECTORS_HIGH?
>
> It directs ARM core to take exception vector from base address 0x0 or
> 0xFFFF'0000.  Take a glance at CP15 Register 1 'V' bit definition.

I see, thanks.

> > How do I know my machine use ARM_VECTORS_LOW or
> > ARM_VECTORS_HIGH?
>
> It looks, from the NetBSD stand point, arbitrary and insignificant to
> assign exception vector vaddr to LOW or HIGH.

I tried to change the word ARM_VECTORS_LOW  to ARM_VECTORS_HIGH in gumstix code,
it seems to not work. The code I changed is:

pmap_link_l2pt(l1pagetable, 0x00000000,
	    &kernel_pt_table[KERNEL_PT_SYS]);
--->
pmap_link_l2pt(l1pagetable, ARM_VECTORS_HIGH & ~(0x00400000 - 1),
	    &kernel_pt_table[KERNEL_PT_SYS]);

pmap_map_entry(l1pagetable, vector_page, systempage.pv_pa,
	    VM_PROT_READ|VM_PROT_WRITE, PTE_CACHE);
-->
(Continue reading)

Permalink | Reply | 1002 comments |
headers
KIYOHARA Takashi | 21 May 2007 16:55
Picon

initialization probrem for GPIO of pxa2x0

Hi! all,

Our GPIO initiation for each devices has a lot of problem.

First, PXA2{55,60,70} is different for the GPIO functions.  For instance,
AC97_SDATA_IN_1 is GPIO99 (PXA270) and GPIO32 (PXA2{55,60}).  Then,
pxa2x0_ac97.c initializes it excluding this pin. 

Next, for instance PXA2{55,60} has I2C bus controller.  However
pxa2x0_i2c.c sets function GPIO_ALT_FN_1_IN for GPIO11[78].  Moreover
PXA2{55,60} hasn't GPIO11[78].  It will go to panic() possibly.  X-<

I think we must set configure the GPIO in init_arm() and other.  And
test to GPIO configuration from DEVICE_match().  If enable a device
then to attach a device.
It just to the way of gxpcic_match.c::gxpcic_match(). 

Shall I correct them to other PXA2xx machines?
--
kiyohara
Permalink | Reply | 2 comments |

Gmane