1 | Some information about this BSP |
---|
2 | ================================ |
---|
3 | |
---|
4 | ACKNOWLEDGEMENTS |
---|
5 | ---------------- |
---|
6 | Acknowledgements: |
---|
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. |
---|
15 | |
---|
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. |
---|
19 | |
---|
20 | LICENSE |
---|
21 | ------- |
---|
22 | See ./LICENSE file. |
---|
23 | |
---|
24 | Note that not all files that are part of this BSP were written by |
---|
25 | me (most notably, the ethernet drivers if_gfe [netbsd port] and |
---|
26 | if_em [freebsd port]). Consult individual file headers for copyright |
---|
27 | and authorship information. |
---|
28 | |
---|
29 | BUILD INFO |
---|
30 | ---------- |
---|
31 | (relevant only if you received this BSP unbundled from the RTEMS distribution) |
---|
32 | |
---|
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/acinclude.ac |
---|
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' |
---|
43 | |
---|
44 | TARGET |
---|
45 | ------ |
---|
46 | Even though this BSP is binary compatible with the MVME5500 it's primary |
---|
47 | target was and is the MVME6100 board which in some respects is quite different. |
---|
48 | In particular, the discovery chip and the VME bridge exhibit significant |
---|
49 | differences. |
---|
50 | I am sometimes asked why this BSP provides yet another port of the gfe |
---|
51 | and em BSD drivers (which had previously been ported for the mvme5500 |
---|
52 | BSP by Shuchen Kate Feng [BNL]). The answer is simply a matter of time: |
---|
53 | Once support for the 6100 board was completed I found it easier to use |
---|
54 | the set of 'quick-and-dirty' wrappers (found in network/porting) that I had |
---|
55 | developed for other projects and to do a new port from scratch using that |
---|
56 | framework rather than modifying the mvme5500 BSP's drivers. mvme5500 support was |
---|
57 | added to this BSP because we own a few of those boards we occasionally |
---|
58 | play with but we don't want to build and support an additional BSP for them. |
---|
59 | An important detail -- hardware cache snooping -- was borrowed from |
---|
60 | Shuchen Kate Feng's gfe driver port, though. |
---|
61 | |
---|
62 | HARDWARE SUPPORT |
---|
63 | =============== |
---|
64 | (some of the headers mentioned below contain more |
---|
65 | detailed information) |
---|
66 | |
---|
67 | NOTE: The BSP supports both, the mvme6100 and the mvme5500 boards. |
---|
68 | It detects relevant hardware at run-time. |
---|
69 | |
---|
70 | CONSOLE: 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.) |
---|
73 | |
---|
74 | CLOCK: Decrementer, same as other PPC BSPs. (FIXME: a discovery timer |
---|
75 | could be used.) |
---|
76 | |
---|
77 | PIC (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. |
---|
85 | |
---|
86 | EXCEPTIONS: (bspException.h) Routines to install a user callback |
---|
87 | for (PPC) exception handling. |
---|
88 | |
---|
89 | PCI (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. |
---|
97 | |
---|
98 | MEMORY 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. |
---|
101 | |
---|
102 | NVRAM: Address constants are defined in bsp.h |
---|
103 | |
---|
104 | FLASH (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(). |
---|
108 | |
---|
109 | I2C (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); |
---|
123 | |
---|
124 | VME: (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). |
---|
130 | |
---|
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. |
---|
134 | |
---|
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). |
---|
144 | |
---|
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. |
---|
148 | |
---|
149 | HARDWARE 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. |
---|
153 | |
---|
154 | The watchdog timer - when started - issues a hard-reset of the |
---|
155 | board if not 'petted' within a configurable timeout period. |
---|
156 | |
---|
157 | NETWORK: (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). |
---|
167 | |
---|
168 | VPD: (bsp/vpd.h). The board's VPD (vital-product-data such as S/N, |
---|
169 | MAC addresses and so forth) can be retrieved. |
---|
170 | |
---|
171 | BOOTING: 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'. |
---|
175 | |
---|
176 | Have fun. |
---|
177 | |
---|
178 | -- Till Straumann <strauman@slac.stanford.edu>, 2005-2007. |
---|