Warning, /bsps/powerpc/mvme3100/README.md is written in an unsupported language. File is not indexed.
0001 mvme3100
0002 ========
0003 Valuable information was obtained from the following drivers
0004
0005 linux: (BCM54xx) Maciej W. Rozycki, Amy Fong.
0006
0007 This BSP also builds on top of the work of others who have contributed
0008 to similar RTEMS (powerpc) BSPs, most notably Eric Valette, Eric Norum
0009 and others.
0010
0011 This BSP was produced by the Stanford Linear Accelerator Center,
0012 Stanford University under contract with the US Department of Energy.
0013
0014 LICENSE
0015 -------
0016 See ./LICENSE file.
0017
0018 Note that not all files that are part of this BSP were written by
0019 myself. Consult individual file headers for copyright
0020 and authorship information.
0021
0022
0023 HARDWARE SUPPORT
0024 ---------------
0025 (some of the headers mentioned below contain more
0026 detailed information)
0027
0028 NOTE: The BSP supports the mvme3100 board.
0029
0030 WARNING: It is extremely important that a MOTLoad "waitProbe", "netShut"
0031 sequence be executed before booting RTEMS. Otherwise, network
0032 interface interrupt handlers installed by MOTLoad may cause memory
0033 corruption
0034
0035 CONSOLE: 2 serial devices, UART driver from 'shared' - no surprises
0036 ("/dev/ttyS0", [="/dev/console"], "/dev/ttyS1"). (Only
0037 /dev/ttyS0 is accessible from the front panel.)
0038
0039 CLOCK: Decrementer, same as other PPC BSPs. (FIXME: a openpic timer
0040 could be used.) The bookE decrementer is slightly different
0041 from the classic PPC decrementer but the differences are
0042 hidden from the user.
0043
0044 PIC (interrupt controller) (bsp/irq.h): OpenPIC integrated with
0045 the MPC8540. (see also: bsp/openpic.h).
0046
0047 PCI (bsp/pci.h):
0048 In addition to rtems' PCI API, a call is available to scan
0049 all devices executing a user callback on each device.
0050 BSP_pciConfigDump() is a convenience wrapper dumping essential
0051 information (IDs, BAs, IRQ pin/line) to the console or a file.
0052
0053 MEMORY MAP: MotLoad; all addresses (MEM + I/O) read from PCI config. space
0054 are CPU addresses. For sake of portability, drivers should still
0055 use the _IO_BASE, PCI_MEM_BASE, PCI_DRAM_OFFSET constants.
0056
0057 NVRAM: No NVRAM.
0058
0059 FLASH (bsp/flashPgm.h): Routines to write flash. Highest level
0060 wrapper writes a file to flash.
0061 NOTE: Writing to flash is disabled by default;
0062 call BSP_flashWriteEnable().
0063
0064 I2C (bsp.h, rtems/libi2c.h, libchip/i2c-xxx.h): temp. sensor, eeprom
0065 and real-time clock (RTC) are available as device files (bsp.h);
0066 lower-level interface is provided by libi2c.h.
0067
0068 Available i2c devices are:
0069
0070 /dev/i2c0.vpd-eeprom
0071 /dev/i2c0.usr-eeprom
0072 /dev/i2c0.usr1-eeprom
0073 /dev/i2c0.ds1621
0074 /dev/i2c0.ds1621-raw
0075 /dev/i2c0.ds1375-raw
0076
0077 You can e.g., read the board temperature:
0078 fd = open("/dev/i2c0.ds1621",O_RDONLY)
0079 read(fd,&temp,1)
0080 close(fd);
0081 printf("Board Temp. is %idegC\n",(int)temp);
0082
0083 VME: (bsp/VME.h, bsp/vme_am_defs.h, bsp/VMEDMA.h).
0084 *always* use VME.h API, if possible; do *not* use chip driver
0085 (vmeTsi148.h) directly unless you know what you are
0086 doing (i.e., if you need specific features provided by the particular
0087 chip)
0088
0089 VMEConfig.h should not be used by applications as it makes them
0090 dependent on BSP internals. VMEConfig.h is intended to be used
0091 by BSP designers only.
0092
0093 VME interrupt priorities: the VME bridge(s) do not implement
0094 priorities in hardware.
0095 However, on the 3100 multiple physical interrupt
0096 lines/wires connect the VME bridge to the PIC. Hence, it is possible
0097 to assign the different wires different priorities at the PIC
0098 (see bsp/openpic.h) and to route VME interrupts to different
0099 wires according to their priority.
0100 You need to call driver specific routines
0101 for this (vmeXXXIntRoute()), however (for driver-specific API
0102 consult bsp/vmeTsi148.h).
0103
0104 For VME DMA *always* use the bsp/VMEDMA.h API. DO NOT use
0105 chip-specific features. Applications written using the bsp/VMEDMA.h
0106 API are portable between the UniverseII and the Tsi148.
0107
0108 HARDWARE TIMERS: (bsp/openpic.h). Programmable general-purpose
0109 timers. Routines are provided to setup, start and stop
0110 GPTs. The setup routine allows for specifying single-shot or periodic
0111 mode and dispatches a user ISR when the GPT expires.
0112
0113 NETWORK: (bsp/if_tsec_pub.h). In addition to the standard bsdnet
0114 'attach' function the driver offers a low-level API that
0115 can be used to implement alternate communication links
0116 which are totally decoupled from BSDNET.
0117
0118 Consult 'KNOWN_PROBLEMS'.
0119
0120 VPD: (bsp/vpd.h). The board's VPD (vital-product-data such as S/N,
0121 MAC addresses and so forth) can be retrieved.
0122
0123 BOOTING: BSP has a relocator-header. Clear MSR and jump to the first
0124 instruction in the binary. R3 and R4, if non-null, point to the
0125 start/end of an optional command line string that is copied into
0126 BSP_commandline_string. The BSP is compatible with 'netboot'.
0127
0128 Have fun.
0129
0130 -- Till Straumann <strauman@slac.stanford.edu>, 2007.
0131
0132
0133 Known Problems
0134 ==============
0135 I have observed what seem to be strange
0136 initialization problems with the ethernet
0137 driver:
0138
0139 I usually configure RTEMS networking by
0140 BOOTP (the problem has nothing to do with
0141 BOOTP but I just want to describe my
0142 environment). Sometimes (it can actually
0143 happen quite frequently, like 1 out of 4
0144 attempts but since yesterday when I decided
0145 to hunt this down more systematically
0146 the problem seems to have gone - typical!)
0147 networking fails to initialize properly:
0148
0149 BOOTP requests are sent (to the MAC),
0150 TX interrupts occur and the TX MIB
0151 counters increment - i.e., everything
0152 seems normal but no data can be seen on
0153 the wire. Also, even though we are on
0154 a quite busy network, the receiver
0155 doesn't see anything, i.e., 0 RX
0156 interrupts, RX MIB counters for broadcast
0157 packets remain steady at zero etc.
0158 In brief, everyting seems normal at the
0159 MAC and higher layers but no connection
0160 to the wire seems to be established.
0161
0162 Some further tests reveal (system under
0163 test is in the 'bad' state):
0164 1 communication with the BCM5461 PHY
0165 is normal. Registers can be read/written
0166 and everything seems normal. In particular,
0167 the link status is reported OK: disconnect
0168 the cable and MII - BMSR bit 1<<2 is clear,
0169 reconnect the cable and BMSR[2] is set.
0170 Restart autoneg, the link goes and comes
0171 back after a short while.
0172 2 setting the loopback bit in the TSEC's
0173 MACCFG1 register correctly feeds packets
0174 back into the RX, RX MIB counters now
0175 increment and indicate data flow.
0176 There are RX interrupts and all indicates
0177 (I haven't actually looked at RX packet
0178 data) that the RX would work normally.
0179 After switching MACCFG1[LOOP_BACK] off
0180 no RX traffic can be seen anymore.
0181 3 resetting the PHY (BMCR = 0x8000) and/or
0182 restarting autoneg (BMCR = 0x1200) seems
0183 to perform the desired action (registers
0184 take on expected values) but still no luck
0185 with communication all the way through
0186 to the wire.
0187
0188 Especially point 2 seems to indicate that
0189 the problem is likely to be between the
0190 wire and the MAC somewhere but re-setting
0191 the PHY doesn't change things. Analysis is
0192 much complicated by the fact that there
0193 is no documentation on the BCM5461 chip
0194 available.
0195
0196 Noteworthy is also that if the system
0197 initializes OK then it continues to work
0198 normally; if initialization fails then
0199 only resetting the board and restarting
0200 helps.
0201
0202 I wanted to test if it makes a difference
0203 if MotLoad used the chip prior to RTEMS
0204 being booted (in case MotLoad did some
0205 magic step during initialization) but
0206 before I could really test this the
0207 problem went away.
0208
0209 Big Mystery...
0210
0211 12/12/2007, T.S.
