> -----Original Message-----
> From: Allen Briggs [mailto:briggs@netbsd.org] 
> Sent: Thursday, July 13, 2006 9:57 AM
> To: Matt Sealey
> Cc: 'Raquel Velasco and Bill Buck'; 'DataZap'; 'Tim 
> Rightnour'; port-powerpc@NetBSD.org; netbsd-ports@NetBSD.org; 
> port-ofppc@NetBSD.org
> Subject: Re: Pegasos port status
> 
> On Thu, Jul 13, 2006 at 09:46:07AM -0500, Matt Sealey wrote:
> > Why do you need the MPP assignments?
> 
> I can't speak for Matt T, but can quote what he said yesterday:
> 
> "My questions where mostly on how the Pegasos boards used the 
> MPP pins  on the Discovery/DiscoveryII system controller and 
> what was attached to  each device bus and where.  There are 
> 32 MPP pins used for inputs,  outputs, interrupts, NMI, 
> watchdog, timers, and other assorted purposes.
>  Knowing how these pins are used is critical in writing the 
> board dependent  support."

The official response is: you don't need to know :)

The pins that are used are configured in a hardware-dependant way,
and this is done by the Genesi HAL. The interrupt controller used
is in the southbridge, you needn't touch the one in the Marvell
chip. It forwards southbridge interrupts and handles internal
chip devices, and this is all handled "transparently".

If you change the settings, things will stop working.

If you want to clone (and re-set) the settings, you are getting
no benefit at all, and if we change the hardware and you are
setting these things, things will stop working.

The Pegasos is not a specialised peice of embedded hardware, it
has a comprehensive firmware, generic design based on PC
components (VT8231 etc.) and this is what you need to support
to get the board up and running. In theory, you should be taking
the ofppc port as a basis (since this runs) and then adding the
specific hardware support from the i386 tree (ethernet, firewire,
ide and so on) which is already supported.

As an example there, the ofppc port already runs, and would always
have run without knowledge of the MPP configuration or any internal
northbridge chipset knowledge. Linux is the same way, all the
info you will ever need is in the Open Firmware device tree or
provided via RTAS callbacks.

-- 
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations