[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[openrisc] Re: binutils, gcc and Linux on the OpenRISC [repost]
On Tue, Mar 26, 2002 at 10:25:45PM +0100, Damjan Lampret wrote:
> Andreas,
>
> the idea with the ROM sounds cool. Now if I understand you correctly, the device table in ROM could be used for two things:
> 1) to tell the software where to find specific devices (UART, VGA, audio etc)
> 2) optionally, to tell the software where to put the devices (optionally I say because in some systems devices would be pre-wired to specific addresses to reduce silicon area and increase performance)
>
> Is number 2 correct?
The device table would only have to have entries for the hardwired
(Wishbone) devices and their physical addresses. I don't think it would
make sense to have those addresses be configurable since Wishbone is not
an extension bus so everything can be layed out at system creation time.
The OS can still use the MMU to map the hardware wherever it's
convenient.
For those extension buses like PCI there would be a controller at a
fixed address which can be queried and the devices behind it configured
by software. The table only has to contain what can't be found out by
asking hardware.
Okay, let's have an example:
We build a system compromising of the CPU, a program ROM, a SDRAM
controller, an UART, PS/2 interface and a PCI controller all on
Wishbone. Connected to the PCI bus there are Ethernet, IDE and VGA
controllers and three PCI slots. We want to run Linux on it.
The Wishbone devices were put on specific addresses by the Wishbone SoC
Builder (if there were one), which creates an address decoder for the
CPU and the device table. Apart from the devices the table also
contains the address and size of the RAM window (which isn't necessarily
fully used, but the window size limits the max. possible memory).
The position of the ROM can be chosen freely within the limits of the
CPU reset address (if it's zero, it has to be zero, if it's configurable
like with NIOS, it could be anywhere). The device table starts with an
instruction loading the PC into r1 and then branching over the table to
the real startup code.
That (position independent) startup code then uses the table pointer in
r1 to do what preliminary setup is necessary to start Linux (like
initializing SDRAM and unpacking kernel from ROM or downloading it) then
passes control and table pointer to Linux' startup code.
Linux parses the table to initialize a bus structure. Later drivers
registering themselves for certain devices will have their
initialization function called (so we get the UART and PS/2 set up that
way). Upon stumbling across the PCI controller in the table the PCI
initialization is done by Linux (discovering devices and assigning
interrupts and free physical address ranges) by talking to the
controller. The Ethernet, IDE, VGA and cards in the PCI slots are then
available to PCI drivers.
Building the ROM is quite easy that way since it just consists of
concatenating the custom device table and the generic startup code (and
the kernel, if it's in the ROM). The startup/kernel doesn't have to
resort to probing to find devices like on ISA and the hardware address
layout can be chosen the way it fits best. This also means that the
kernel has an easier job being general purpose, e.g. you could offer the
same kernel to a lots of possibly differently configured, network
booting machines.
Still this implies that a device database has to be set up to globally
define the values to be found in the table. Every interface needs its
own ID unless different revisions of an interface can be identified by
reading a register in the common denominator interface without side
effects.
--
Andreas Bombe <bombe@informatik.tu-muenchen.de> DSA key 0x04880A44
--
To unsubscribe from openrisc mailing list please visit http://www.opencores.org/mailinglists.shtml