source: rtems/c/src/lib/libbsp/powerpc/beatnik/README @ b7a6d23a

Last change on this file since b7a6d23a was b7a6d23a, checked in by Till Straumann <strauman@…>, on Dec 3, 2009 at 4:56:50 PM
  • importing 'beatnik' BSP from SLAC repository.
  • Property mode set to 100644
File size: 7.8 KB
1Some information about this BSP
7 Valuable information was obtained from the following drivers
8   netbsd: Allegro Networks Inc; Wasabi Systems Inc.
9    linux: MontaVista, Software, Inc; Chris Zankel, Mark A. Greer.
10               Matthew Dharm, rabeeh, Manish Lachwani, Ralf Baechle. 
11    rtems: Brookhaven National Laboratory; Shuchen Kate Feng
12 This BSP also builds on top of the work of others who have contributed
13 to similar RTEMS (powerpc) BSPs, most notably Eric Valette, Eric Norum
14 and others.
16 In particular, the Author wishes to thank Shuchen Kate Feng (BNL) for many
17 inspiring discussions and Dayle Kotturi (SLAC) for her contributions, support
18 and extensive testing.
22See ./LICENSE file.
24Note that not all files that are part of this BSP were written by
25me (most notably, the ethernet drivers if_gfe [netbsd port] and
26if_em [freebsd port]). Consult individual file headers for copyright
27and authorship information.
31(relevant only if you received this BSP unbundled from the RTEMS distribution)
33  prepare:
34  - get up-to date RTEMS release
35  - untar beatnik.tgz into c/src/lib/libbsp/powerpc
36  - copy beatnik.cfg into make/custom
37  - patch c/src/lib/libsp/powerpc/
38  - run 'bootstrap' from top directory; make sure RTEMS
39    autoXXX are found first in your PATH
40  configure:
41  - configure with your favorite options. BSP name is 'beatnik'
42    I recommend passing RTEMS_CFLAGS=-g to 'configure'
46Even though this BSP is binary compatible with the MVME5500 it's primary
47target was and is the MVME6100 board which in some respects is quite different.
48In particular, the discovery chip and the VME bridge exhibit significant
50I am sometimes asked why this BSP provides yet another port of the gfe
51and em BSD drivers (which had previously been ported for the mvme5500
52BSP by Shuchen Kate Feng [BNL]). The answer is simply a matter of time:
53Once support for the 6100 board was completed I found it easier to use
54the set of 'quick-and-dirty' wrappers (found in network/porting) that I had
55developed for other projects and to do a new port from scratch using that
56framework rather than modifying the mvme5500 BSP's drivers. mvme5500 support was
57added to this BSP because we own a few of those boards we occasionally
58play with but we don't want to build and support an additional BSP for them.
59An important detail -- hardware cache snooping -- was borrowed from
60Shuchen Kate Feng's gfe driver port, though.
64(some of the headers mentioned below contain more
65detailed information)
67NOTE:  The BSP supports both, the mvme6100 and the mvme5500 boards.
68       It detects relevant hardware at run-time.
70CONSOLE: 2 serial devices, UART driver from 'shared' - no surprises
71       ("/dev/ttyS0", [="/dev/console"], "/dev/ttyS1"). (Only
72       /dev/ttyS0 is accessible from the front panel.)
74CLOCK: Decrementer, same as other PPC BSPs. (FIXME: a discovery timer
75       could be used.)
77PIC (interrupt controller) (bsp/irq.h): Marvell hostbridge
78       does not implement interrupt priorities. The driver supports
79       priorities in software (masking lower priority lines during
80       execution of higher priority ISR). I believe the design of the
81       IRQ subsystem is as efficient as possible with focus on low
82       latencies.
83       In addition to the rtems IRQ API, calls are available to
84       change IRQ priority and to enable/disable interrupts at the PIC.
86EXCEPTIONS: (bspException.h) Routines to install a user callback
87       for (PPC) exception handling.
89PCI (bsp/pci.h): The BSP hides the fact that there are effectively
90       two 'root' busses (AKA 'hoses') behind the discovery bridge.
91           Devices are addressed by bus/slot/function-triples and the PCI
92           subsystem transparently figures out what hose to use.
93       In addition to rtems' PCI API, a call is available to scan
94       all devices executing a user callback on each device.
95       BSP_pciConfigDump() is a convenience wrapper dumping essential
96       information (IDs, BAs, IRQ pin/line) to the console or a file.
98MEMORY MAP: CHRP; all addresses (MEM + I/O) read from PCI config. space
99       are CPU addresses. For sake of portability, drivers should still
100       use the _IO_BASE, PCI_MEM_BASE, PCI_DRAM_OFFSET constants.
102NVRAM: Address constants are defined in bsp.h
104FLASH (bsp/flashPgm.h): Routines to write flash. Highest level
105      wrapper writes a file to flash.
106          NOTE: Writing to flash is disabled by default;
107                call BSP_flashWriteEnable().
109I2C (bsp.h, rtems/libi2c.h, libchip/i2c-xxx.h):  temp. sensor and eeprom
110      are available as device files (bsp.h); lower-level interface is
111      provided by libi2c.h.
112          NOTE: The I2C devices are not registered and the driver is not
113                initialized by default. Call BSP_i2c_initialize() to do that;
114                        this will create
115                                /dev/i2c0.vpd-eeprom
116                                /dev/i2c0.usr-eeprom
117                                /dev/i2c0.ds1621
118                You can then read the board temperature:
119                            fd = open("/dev/i2c0.ds1621",O_RDONLY)
120                                read(fd,&temp,1)
121                                close(fd);
122                                printf("Board Temp. is %idegC\n",(int)temp);
124VME: (bsp/VME.h, bsp/vme_am_defs.h, bsp/VMEDMA.h).
125      *always* use VME.h API, if possible; do *not* use chip drivers
126          (vmeUniverse.h, vmeTsi148.h) directly unless you know what you are
127          doing (i.e., if you need specific features provided by the particular
128          chip; currently, both of the mentioned chip drivers expose entry points
129          that are designed to be compatible).
131      VMEConfig.h should not be used by applications as it makes them
132      dependent on BSP internals. VMEConfig.h is intended to be used
133          by BSP designers only.
135      VME interrupt priorities: the VME bridge(s) do not implement
136      priorities in hardware.
137      However, on the 5500/6100 multiple physical interrupt
138      lines/wires connect the VME bridge to the PIC. Hence, it is possible
139      to assign the different wires different priorities at the PIC
140      (see above) and to route VME interrupts to different wires according
141      to their priority. You need to call driver specific routines
142      for this (vmeXXXIntRoute()), however (for driver-specific API
143          consult bsp/vmeUniverse.h, bsp/vmeTsi148.h).
145          For VME DMA *always* use the bsp/VMEDMA.h API. DO NOT use
146          chip-specific features. Applications written using the bsp/VMEDMA.h
147          API are portable between the UniverseII and the Tsi148.
149HARDWARE TIMERS: (bsp/gt_timer.h). Programmable general-purpose (GPT) and
150      watchdog timers. Routines are provided to setup, start and stop
151          GPTs. The setup routine allows for specifying single-shot or periodic
152          mode and dispatches a user ISR when the GPT expires.
154          The watchdog timer - when started - issues a hard-reset of the
155          board if not 'petted' within a configurable timeout period.
157NETWORK: (bsp/bsp_bsdnet_attach.h). The BSP offers a call to list
158      all available interfaces (name, description, 'attach'-method)
159      for the application to make a selection.
160      Alternatively, there are BSP_auto_network_driver_name and
161      BSP_auto_enet_attach(), the latter with the capability to configure
162      the first NIC with a 'live' link status.
163      All drivers (rewritten 'mve' for the mv64360 NIC (6100) and BSD ports
164      'gfe'/'em' (5500)) support the SIOCSIFMEDIA/SIOCGIFMEDIA ioctls
165      (rtems/rtems_mii_ioctl.h provides helpers to convert strings from/to
166      control words).
168VPD: (bsp/vpd.h). The board's VPD (vital-product-data such as S/N,
169      MAC addresses and so forth) can be retrieved.
171BOOTING: BSP has a relocator-header. Clear MSR and jump to the first
172      instruction in the binary. R3 and R4, if non-null, point to the
173      start/end of an optional command line string that is copied into
174      BSP_commandline_string. The BSP is compatible with 'netboot'.
176Have fun.
178-- Till Straumann <>, 2005-2007.
Note: See TracBrowser for help on using the repository browser.