[b7a6d23a] | 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. |
---|