OKI 675001 Module FAQ

Two EB675001DIP modules top view
  1. What is the default serial settings used by the bootloader on this board?
  2. The network does not work what can be done to correct this?
  3. ABLE fails to obtain an automatic network configuration with bootp, how is this fixed?
  4. Why does the SSP serial port not accept baud rate settings below 9600?
  5. Why does the SSP serial port drop charcters at higher baud rates?
  6. How are the example uCLinux images from the resources page started?
  7. What is the user CPLD?
  8. What tools are available to create user CPLD code?
  9. How is the user CPLD programmed?
  10. Can the user CPLD be programmed directly?
  11. The user CPLD has been programed and now the module does not boot.
  12. How is the user CPLD accessed form the processor?
  13. Why does the Ethernet interface stop working when code is uploaded to the user CPLD?
  14. Why does the Ethernet interface stop working in uCLinux when the IRQ0 line is used?
  15. Does the uCLinux need a toolchain to build?
  16. What peripheral support is provided in uCLinux?
  17. Are there any examples of using the EB675001DIP?
  18. What pins do I need on the CPLD for a bus interface
  19. Why are there xa0_i and xa_i signals in the example project
  20. What is the naming scheme used for the bus interface in the sample VHDL projects
  21. There are no IRQ pins in the example project
  22. Why do the pinouts in the pinlist document and userguide seem to be incorrect?
  23. What is the default IO bank configuration
  24. How are the external chip-selected areas accessed
  25. What assembly instructions can be used to access external IO areas
  26. How are the externa IO areas accessed by C code

  1. What is the default serial settings used by the bootloader on this board?

    The default serial speed for this board is 115,200 baud eight data bits, no parity and one stop bit. Hardware flow control should be disabled.

  2. The network does not work what can be done to correct this?

    Check the cable is connected properly and that the link light on the RJ45 Ethernet connector lights properly.

    During the ABLE boot the following would indicate a disconnected or bad cable

    ABLE 2.09 (C) 2001-2005 Simtec Electronics
    DM9000: dm0: r1, 00:11:ac:00:06:00 int phy, link down
    

    Whereas a report such as the following is obtained when a cable is present

    ABLE 2.09 (C) 2001-2005 Simtec Electronics
    DM9000: dm0: r1, 00:11:ac:00:06:00 int phy, link ok, 100Mbit full duplex
    
  3. ABLE fails to obtain an automatic network configuration with bootp, how is this fixed?

    This is typically exhibited when the user tries to boot an image for the first time for example:

    ABLE 2.09 (C) 2001-2005 Simtec Electronics
    DM9000: dm0: r1, 00:11:ac:00:06:00 int phy, link ok, 100Mbit full duplex
    >(tftpboot)batty
    tftp: attempting bootp
    bootp: sending request
    bootp: readudp returned -2
    bootp: readudp returned -2
    bootp: readudp returned -2
    sendrecv: timeout
    bootp: no reply
    tftp: bootp failed to get IP address
    sh: (tftpboot)billy.img: error: unknown error code (-2)
    >
    

    Firstly ensure that the network is properly connected (see Q2). The bootp server should be checked to ensure it is configured to serve bootp/dhcp service to the EB675001DIP. The MAC address is clearly shown during ABLE boot and will be prefixed with 00:11:ac

    If the BOOTP server logs do not yield a solution the BOOTP session may be dumped using a tool such as tcpdump:

    tcpdump -n -v -i eth2 udp port 67 and port 68 and ether host 00:11:ac:00:06:00

    where the MAC address of the module and the ethernet interface to use is substituted.

    A successful session would look something like

    21:28:19.000508 IP (tos 0x0, ttl   4, id 0, offset 0, flags [none], length: 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:ac:00:06:00, length: 548, flags: [none]
              Client Ethernet Address: 00:11:ac:00:06:00 [|bootp]
    21:28:20.257392 IP (tos 0x0, ttl   4, id 0, offset 0, flags [none], length: 576) 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:11:ac:00:06:00, length: 548, secs:2, flags: [none]
              Client Ethernet Address: 00:11:ac:00:06:00 [|bootp]
    21:28:20.449652 IP (tos 0x10, ttl  64, id 0, offset 0, flags [none], length: 375) 192.168.7.1.67 > 192.168.7.238.68: BOOTP/DHCP, Reply, length: 347, flags: [none]
              Your IP: 192.168.7.238
              Server IP: 192.168.7.1
    

    This shows a BOOTP server (address 192.168.7.1) responding to the module with an address of 192.168.7.238

    If this still does not assist in finding the problem please contact Simtec support.

  4. Why does the SSP serial port not accept baud rate settings below 9600?

    The SSP serial port is much less flexible than the primary 16550 type serial port. One of its limitations is on the range of baud rate divisors available which ordinarily limits this port to settings of 9600baud or later.

    A configuration option exists in 2.4.29-eb675001dip-4 and later kernels to allow for lower baud rates on this serial port by altering the master peripheral clock. This will have the effect of reducing the maximum PWM speeds and may slightly impact the performance of all peripherals. Because of this the setting is not on by default.

  5. Why does the SSP serial port drop charcters at higher baud rates?

    The SSP serial port does not have any FIFO which means that an interrupt must be serviced for each character in a short time or an overrun will occur and loose characters. This is not usually an issue unless high baud rates or a very high IRQ load is experienced.

    There is no workaround for this issue but most modern serial protocols e.g. PPP have CRC and error detection which may reduce the impact of the issue.

  6. How are the example uCLinux images from the resources page started?

    The example images provided on the EB675001DIP page (such as eb675001dip-2.4.31-uclinux.bin.Z may be started from the ABLE prompt useing the following method

    >(tftpboot)image.bin.Z root=/dev/ram console=ttyS0,115200

    This will boot the file image.bin.Z from a tftp server. Replace the image.bin.Z filename with the one dowloaded form the resources page.

  7. What is the user CPLD?

    The user CPLD is a user programable uncommited logic device. The device is a Xilinx XC9572XL which provides 72 macrocells. The user can program this device with any logic they require which fits within the device. The EB675001DIP resources webpage has more details.

  8. What tools are available to create user CPLD code?

    Xilinx provide the webpack suite of software which can be used to create logic designs in VHDL or visual schematic layout. The EB675001DIP resources webpage has more details and links to the tools.

  9. How is the user CPLD programmed?

    The user CPLD can be easily progrmmed using the PlayXSVF program from the ABLE command prompt. No additional cabling or hardware is required for this type of operation.

    Details on how to create XSVF files and how to use the PlayXSVF program to write them to the CPLD can be found in the PlayXSVF manual and the EB675001DIP resources webpage.

  10. Can the user CPLD be programmed directly?

    The directly using a JTAG cable connected to the JTAG header pins on the module. The EB675001DIP user guide contains details on the port pinout and suitable cables.

    An external JTAG programming device (such as DTJTAGPAR) should be suitable for use with the xilinx webpack tools.

  11. The user CPLD has been programed and now the module does not boot.

    The user CPLD retains its programming across resets and power cycling, if an incorrect logic design is programmed which prevents the user getting to the ABLE command promptto re-run the PlayXSVF program the external JTAG port with a suitable programmer must be used to recover the system.

  12. How is the user CPLD accessed form the processor?

    The user CPLD has access to half of the Chip Select(CS) 0 area and all of CS2 and CS3 areas. These are acessed form the CPU as adresses 0xF0000000 to 0xF0DFFFFF for CS0 and xF8000000,0xFC000000 for CS2 and 3 respectively.

    The EB675001DIP user guide provides more details of how to adress and use the CPLD.

  13. Why does the Ethernet interface stop working when code is uploaded to the user CPLD?

    The user CPLD is coupled into the CPU IO XWAIT signal (on CPLD pin 25) which allows I/O cycles to be extended by slow peripherals. The XWAIT is only used by the CPU within the first external chip select region (CS0). The inverted I/O wait request from the Ethernet controller is also brought to the CPLD (pin 20). The designer must ensure the relevant logic is used to combine the nWAIT input and any internal I/O wait requirement to generate a correct XWAIT output.

    This is also covered in the EB675001DIP user guide and is included in all the supplied templates.

  14. Why does the Ethernet interface stop working in uCLinux when the IRQ0 line is used?

    As mentioned in the EB675001DIP user guide and the IRQ0 signal description in the pinout document IRQ0 is used for the Ethernet controller and connot be shared without additional software support.

    ABLE uses a polled mode of operation so isnt affected by this issue.

  15. Does the uCLinux need a toolchain to build?

    The uCLinux build notes contain the details on obtaining the required toolchain.

    uCLinux is open source software and Simtec have no direct control over its development, we do try to provide as much information as possible for our users on the EB675001DIP and SWUCLINUX resource webpages.

  16. What peripheral support is provided in uCLinux?

    Simtec provide direct kernel drivers for the standard serial port, SSP serial port, the Ethernet port and Memory Type Device (MTD) i.e. NOR flash.

    User added peripherals (including CPLD registers) and other SOC functionality may be easily manipulated by using memory mapped I/O

  17. Are there any examples of using the EB675001DIP?

    The application notes contain several examples of building projects with the EB675001DIP

  18. What pins do I need on the CPLD for a bus interface

    The bus interface is defined by five groups of pins as follows:

    • chipselect lines formed by nxcs_i and ncplden_i
    • read and write strobes noe_i, nxwe_i
    • byte lane selects nlbs_i (lower 8bits), nubs_i (upper 8bits)
    • data bus xd
    • address bus xa_i and xa0_i

    To decode an transaction, one of the cs lines and a read or write strobe must be active. The byte lane select signals indicate which of the data lines (xd) are being used for the transaction.

  19. Why are there xa0_i and xa_i signals in the example project

    VHDL does not allow buses with more than one range, so xa_i are the A21 to A23 range and xa0_i is available separately for use if a chip select is being used in 8bit mode.

  20. What is the naming scheme used for the bus interface in the sample VHDL projects

    All signals in the example projects are defined to the following standard. Any signals that are active low are prefixed by the letter n, so a signal such as ncs is an active low cs signal. Signals that are input only are postfixed with _i (for example, xa_i is input only). Output only signals are postfixed with _o.

  21. There are no IRQ pins in the example project

    The CPLD is only directly connected to the bus interface lines it needs to implement cpu IO accesses so that as many pins as possible are connected to the edge connector. If you need to generate an IRQ from the CPLD, feed one of the GPIO lines to the an IRQ pin via the external pin headers.

    Please note that IRQ0 is already connected to on board peripherals.

  22. Why do the pinouts in the pinlist document and userguide seem to be incorrect?

    The pinlist document and userguide had an error in the user CPLD pin names in the "pinouts by pin number" tables on rows C and D.

    The errors have been corrected and the documentation is now consistent with both the examples and the physical wiring.

  23. What is the default IO bank configuration

    All IO banks are configured for 16 bit accesses, with access times of 2 clocks for setup, 12 clocks strobe and 7 clocks for recovery.

    See chapter 11 in the Oki CPU user manual for more information on the configuration registers.

  24. How are the external chip-selected areas accessed

    These areas are memory mapped IO, and are accessed via the relevant memory region which maps to the chip select. The Oki data sheet contains the information about the address to chip select mapping, and details of the registers used to configure each chip select.

  25. What assembly instructions can be used to access external IO areas

    The following assembly fragments demonstrate how to access IO. Each fragment takes an address in r0. Fragments that write data take the data in r1, and code that reads values returns the value in r0.

    Read an 8bit value:

    read8:
          LDRB      r0, [ r0 ]
          MOV       pc, r14
    

    Read a 16bit value:

    read16:
          LDRH      r0, [ r0 ]
          MOV       pc, r14
    

    Write an 8bit value:

    write8:
          STRB      r1, [ r0 ]
          MOV       pc, r14
    

    Write an 16bit value:

    write16:
          STRH      r1, [ r0 ]
          MOV       pc, r14
    

    Note, the LDRH and STRH instructions are ARMv4 and later, so the assembler will need to be configured to allow ARMv4 instructions.

  26. How are the externa IO areas accessed by C code

    There are several methods of writing C code to access the external IO areas, which are dependant on the compiler being used.

    The first method is to write an assembly file which exports functions for the C code to call to read and write. See the above example for which instructions to use for the IO accesses

    The second method is to use the standard C pointer methods to access the relevant locations, as so:

    {
      /* access an 8bit register in CS2 */
    
      volatile unsigned char *reg = (unsigned char *)0xFC000000;
    
      printf("register value is %02x\n", *reg);
      *reg = 0x05;  /* store 5 to the register */
    }
    .

    The use of the volatile keyword when defining reg is to try and stop the compile caching the result of the read. Different compilers may need extra information to stop caching of data due to optimisation.

    The above code assumes that the compiler treats unsigned char as an 8bit type. The documentation for the compiler should indicate the correct types to use for this access width, and any compiler or linker settings to ensure this.

    To access 16bit registers can be trickier, and is also compiler dependant. Many gcc variants treat the short type as 16bit, but only if passed the right options. Most gcc variants will need -march=armv4 to configure the correct ARM architecture to generate 16 bit load and store instructions.

Other pages