??? ???? ????
Login |
  • Why Register?
  • Download development tools
  • Create and track support tickets
  • Subscribe to resource updates
  • Access latest developer news
Register

USB Bootloader Description and Standards

Development Tools:

USB Bootloader Description and Standards
Version 1.0
The USB interface used to connect XS1-L devices to the XMOS
toolchain and referenced in this document is under current
development and subject to improvements and changes--the
latest version is described in the XMOS USB Device Layer
Library Guide.

Publication Date: 2010/07/22
Copyright © 2010 XMOS Ltd. All Rights Reserved.

USB Bootloader Description and Standards (1.0)
2/9
1
Introduction
This document explains how the XMOS toolchain can boot an XS1-L1 over USB. It is
used, for example, by the debugger (xgdb) to debug systems that are built out of
one or more XCores. The document explains how the bootloader works, the port
layout, the schematics, and the protocol to use the bootloader over USB.
This document does not discuss the USB Device Firmware Upgrade (DFU) protocol,
which is discussed in a separate document (USB Firmware Upgrade on XMOS avail-
able soon). Firmware upgrade enables any USB device to upgrade firmware stored
in flash memory using a standard USB-protocol. USB boot enables a specific USB
device to boot over USB without using flash.
This document specifies a set of the standards that must be followed for a design
to be compatible with the XMOS toolchain. These standards are:
USB-BOOT-1: USB enumeration The USB descriptors to use when enumerating as a
bootloader.
USB-BOOT-2: Firmware upload over USB protocol The protocol to use over the two
USB endpoints.
USB-BOOT-3: Hardware design The schematics to use when designing a system
that uses a USB bootloader.
USB-BOOT-4: USB serial number assignment The meaning of serial numbers.
USB-BOOT-5: USB Serial number storage How the serial number is stored.
The use of the XMOS USB Vendor ID (VID) and the allocated Product Identifier (PID)
are allowed provided that these standards are followed.
Figure 1 shows a block diagram of a device that supports bootloading over USB.
It comprises a USB-PHY and an XS1-L1 device that is both controlling the PHY and
being booted over the PHY.
www.xmos.com

USB Bootloader Description and Standards (1.0)
3/9
L1 USB bootloader hardware
L1
GPIO
USB
PHY
ULPI
OTP stores
bootloader
USB reset
GPIO
Power, clock
Figure 1: Block diagram of booting over USB
The bootloader works as follows:
1. The L1 boots from OTP and runs code that enumerates on the USB bus and
presents itself as a device that accepts programs to execute.
2. xgdb (or other program) scans the USB bus and tries to find devices that are
a bootloader (determined by the VID, PID and version number of the device),
and that have a serial number that indicates that the device is compatible.
For example, xgdb requires a serial number that indicates that the L1 has
hardware that is compatible with the debugger.
3. xgdb (or other program) loads the new firmware into the device. When a device
receives new firmware, bootcode copies its serial number to the 16 bytes at
address 0x1B000 to 0x1B00F prior to executing the new code.
4. On boot, the new firmware picks up the serial number to use from address
0x1B000, and then enumerates as a device with that serial number.
www.xmos.com

USB Bootloader Description and Standards (1.0)
4/9
1.1
PID and VID
USB uses a PID and VID to indicate the product and vendor. These must be identi-
cal for the bootloader and new firmware if one wants to avoid Microsoft Windows
requiring multiple driver installations. The values of PID and VID are specified in
Standard USB-BOOT-1 below.
1.2
Version numbers
The version number is used to differentiate between bootloader (major version 0)
and subsequent firmware (major version not equal to 0) if identical PID, VID and
serial numbers are used.
1.3
Serial numbers
The serial number must uniquely identify the hardware. The same serial number
must be used for both the bootloader and the new firmware (again in order to
avoid windows requiring multiple drivers). The serial number is used to decide
what capabilities this device has, and must adhere to the specification in Standard
USB-BOOT-4 below.
A serial number can be programmed in by loading the programming firmware into
the device (using the bootloader).
2
Standard USB-BOOT-1: USB Enumeration
The descriptor should contain a device class, subclass and protocol that are all equal
to 0xff, and have one configuration only. The device qualifier should indicate a max
packet size of 64 bytes.
The single interface should have two endpoints, interfaceclass, subclass and proto-
col should all be 0xff. For each endpoint the max packet size should be set to 512,
and the interval should be set to 1.
Any bootloadable USB device must enumerate using the following details:
· Use VID (Vendor ID) 0x20B1.
· Use PID (Product ID) 0xF7D1.
· Enumerate with major version number 0
www.xmos.com

USB Bootloader Description and Standards (1.0)
5/9
· Enumerate with a serial number of 16 digits where the first character indicates
the class; the serial numbers are defined in Section 5 - Standard USB-BOOT-4.
The serial number must be read out from OTP; first the word on address 2040
must be read, if it is '0' then serial number "XXXXXXXXXXXXXXXX" (16 Xs) shall
be used. If word 2040 does not equal 0, then the entire serial number should
be read out from word 2040 using differential mode. The least significant byte
of the word at address 2040 is the first byte of the serial number. The most
significant byte of the word at address 2046 is the sixteenth byte of the serial
number.
USB bootloader firmware must be programmed into either flash or OTP. The boot-
loader must relocate itself to address 0x1B000 or higher prior to execution, and
execute from that address. If stored in OTP, the bootloader must be no larger than
8160 bytes, including the relocation code and any error correcting code, leaving 32
bytes empty for the serial number.
3
Standard USB-BOOT-2: Firmware upload over USB
protocol
The bootloader must reside at at address 0x1B000 or above in memory, allowing
programs of up to 44K of memory to be loaded into the device. The protocol of
the USB bootloader requires two endpoints (in addition to endpoint 0) that are used
as described below. Communication is synchronous: for every OUT transaction on
Endpoint 0x01, the host must issue an IN transaction on Endpoint 0x82 to verify
that the operation has completed.
3.1
Out Endpoint 1 (0x01)
Commands are received on this endpoint. A command comprises at most 512 bytes,
and consists of a single word command, and up to 508 bytes of payload.
LOADER_CMD_WRITE_MEM -- 1 Carries an address (bytes 0..3), a length (bytes
4..7), and length bytes of data. The length must be a multiple of 4. After writ-
ing the data, the USB loader will send back a LOADER_CMD_WRITE_MEM_ACK,
see section 3.2. No writes should be requested to addresses 0x1B000 - 0x1FFFF
inclusive.
LOADER_CMD_JUMP -- 5 Carries an address (bytes 0..3) only; it must have a pay-
load of exactly 4 bytes. The USB loader will send back a LOADER_CMD_JUMP_ACK
(see section 3.2) and then jump to the specified address prior to shutting down
all resources.
www.xmos.com

USB Bootloader Description and Standards (1.0)
6/9
3.2
IN Endpoint 2 (0x82)
On this endpoint the firmware responds to commands. Packets are up to 12 bytes
long, where the first word contains the response; there are up to 8 bytes of payload.
The last 4 bytes of payload indicate whether another command can be issued: (0)
means that another command can be issued, (-1) indicates that no other commands
can be issued.
LOADER_CMD_WRITE_MEM_ACK -- 2 Has a payload of 4 bytes, indicating the suc-
cess state only (0).
LOADER_CMD_JUMP_ACK -- 6 Has a payload of 4 bytes containing -1 indicating
that the device will detach itself from the bus. On receiving this response, the
host should wait for at least one millisecond and then issue a USB-reset.
4
Standard USB-BOOT-3: Hardware design
4.1
Clock frequencies
The L1 must run at 400MHz derived from a 13 MHz Crystal.
4.2
Port map
The L1 must use the following portmap. All pins labeled ULPI should be connected
to the ULPI USB-PHY. Ports M and N should be declared as input ports (they must be
tristated).
Pin
Port
Signal
1b
4b
8b
XD12
P1E0
ULPI_STP
XD13
P1F0
ULPI_NXT
XD14
P4C0 P8B0
XD15
P4C1 P8B1
XD16
P4D0 P8B2
XD17
P4D1 P8B3
ULPI_DATA[0:7]
XD18
P4D2 P8B4
XD19
P4D3 P8B5
XD20
P4C2 P8B6
XD21
P4C3 P8B7
XD22
P1G0
ULPI_DIR
XD23
P1H0
ULPI_CLK
XD24
P1I0
ULPI_RST_N
XD35
P1L0
Declare as input
XD36
P1M0
Declare as input
www.xmos.com

USB Bootloader Description and Standards (1.0)
7/9
Some ports are used internally when the ULPI is in operation--see the XS1-L Hard-
ware Design Checklist
for further information.
Developers are strongly encouraged to use the design in Figure 2 verbatim.
+3V3
C25
C24
100N
100N
+5V
+1V8
+3V3
U1
USB3318
3
16
ULPI_DATA0
4VBAT
15
DATA0
ULPI_DATA1
17VDD33
14
DATA1
VDDIO
ULPI_DATA2
13
DATA2
ULPI_DATA3
1700mA
21
11
DATA3
ULPI_DATA4
MODE[1:0] = 00 ==> PLL_MULT = 30.75 ==> 13MHZ REFCLK
330R
VDD18
10
DATA4
ULPI_DATA5
J2
R4
2
9
DATA5
VBUS
ULPI_DATA6
MODE[3:2] = 11 ==> BOOT FROM SPI
8
DATA6
ULPI_DATA7
1
FB1
1K
DATA7
2
VBUS
5
20
ULPI_STP
3
DM
6DM
18
STP
ULPI_NXT
+3V3
4
DP
DP
NXT
GND
19
DIR
ULPI_DIR
U3
XS1_L1_64LQFP
5
NC
1
12
ULPI_CLK
6
S1
ID
CLKOUT
S2
NC
7CPEN
+1V0
+1V0
6VDDIO_6
X0D016
OSC_13M
23
24
VDDIO_18
18
X0D115
USB_A_PLUG
REFCLK
RBIAS
VDDIO_32
32
X0D214
PHY_RST_N
22
25
VDDIO_40
40
X0D312
RESETB
GND
X0D411
R1
VDDIO_60
60VDDIO_53
53
X0D510
8K06
X0D67
C3
4
R11
4R7
VDD_4
X0D75
R7
10K
VDD_13
13
X0D83
R10
DNP
VDD_21
21
X0D92
10N
VDD_28
28
X0D101
VDD_37
37
X0D1164
C1
VDD_43
43
X0D1263
ULPI_STP
VDD_52
52
X0D1362
ULPI_NXT
VDD_61
61
X0D1459
ULPI_DATA0
1U
X0D1558
ULPI_DATA1
X0D1657
ULPI_DATA2
PLL_AGND
19PLL_AVDD
20
X0D1756
ULPI_DATA3
X0D1855
ULPI_DATA4
X0D1954
ULPI_DATA5
MODE0
22
X0D2051
ULPI_DATA6
+3V3
+3V3
MODE1
23
X0D2150
ULPI_DATA7
NC
MODE2
24
X0D2249
ULPI_DIR
NC
MODE3
25
X0D2348
ULPI_CLK
U2
PHY_RST_N
+5V
U4
+1V8
X0D2447
NC7SZU04
NC
UART_DN
NCP699SN18
C20
DEBUG
17
X0D2546
5
TP6
RST_N
8
UART_UP
2
4
OSC_13M
9RST_N
X0D2645
1
5
CLK
X0D2744
VIN
VOUT
100N
X0D3236
3
TP1
31
X0D3335
C21
C30
TP2
30
X0D3434 DBG
TP3
27
3
4 NC
29
X0D3533
EN
NC
TP4
X0D3642
100N
2U2
TP5
26
X0D3741
2 GND
X0D3839
R2
GND_PAD
65
X0D3938
TP7
2M2
R8
10K
X1
R12
470R
+5V
U5
+3V3
NCP699SN33
1
5
+3V3
VIN
VOUT
13M
C28
ABLS2
C27
C22
C29
3
4
EN
NC
NC
33P
33P
100N
2U2
C16
C17
C13
C14
C15
2 GND
100N
100N
100N
100N
100N
+5V
U6
+1V0
NCP1521B
L1
1
5
+1V0
VIN
LX
2U2
C2
C4
C5
3
4
EN
FB
R3
6K8
4U7
330P
10U
C11
C12
C8
C19
C9
C6
2 GND
100N
100N
100N
100N
100N
100N
+3V3
R5
10K
+1V0
U7
R6
10K
NCP303LSN09
2
1
INPUT
RST_OUT
RST_N
5CD
C7
3
4
GND
NC
NC
1N
Figure 2: Reference design of an L1 for USB boot loading. [TODO: delete compo-
nents that are not USB related, ie, XLINK, UART, and JTAG]
www.xmos.com

USB Bootloader Description and Standards (1.0)
8/9
5
Standard USB-BOOT-4: USB serial number assignment
The USB serial number indicates the type of device and its capabilities. Serial num-
bers are interpreted as follows:
· Identifiers starting with 'X', 'x', 'Y', 'y', 'Z' and 'z' are reserved by XMOS and
shall not be used by any device not developed by XMOS.
· 'D' and 'd' are used to indicate that this hardware is compatible with the de-
bugger. Serial numbers of this class are defined in a companion document:
"USB debugger description and standards".
· A serial number of all 'X' is used to indicate that this device does not have
an identifier programmed. They can be programmed according to Section 6 -
Standard USB-BOOT-5.
· A serial number starting with 'R' or 'r' can be used freely.
· All other serial numbers are reserved for future device classes.
6
Standard USB-BOOT-5: USB serial number storage
The serial number is stored in differential mode in the top 32 bytes of the OTP.
Blank serial numbers appear as a sequence of 0 and -1 words; any device with a
blank serial number shall enumerate with "XXXXXXXXXXXXXXXX".
Words 2040 to 2047 of the OTP should be programmed as follows:
· Word 2040 should contain the first 4 characters of the serial number--byte 0
should be stored in the least significant byte of the word, byte 3 should be
stored in the most significant byte of the word.
· Word 2041 must be a copy of word 2040.
· Word 2042 should contain characters 4-7 of the serial number
· Word 2043 must be a copy of word 2042.
· Word 2044 should contain characters 8-11 of the serial number
· Word 2045 must be a copy of word 2044.
· Word 2046 should contain characters 12-15 of the serial number
· Word 2047 must be a copy of word 2046.
Each word is programmed twice to provide redundancy when reading out the serial
number.
www.xmos.com

USB Bootloader Description and Standards (1.0)
9/9
Document History
Date
Release
Comment
2010-07-22
1.0
First release
Disclaimer
XMOS Ltd. is the owner or licensee of this design, code, or Information (collectively, the
"Information") and is providing it to you "AS IS" with no warranty of any kind, express or
implied and shall have no liability in relation to its use. XMOS Ltd. makes no representation
that the Information, or any particular implementation thereof, is or will be free from any
claims of infringement and again, shall have no liability in relation to any such claims.
Copyright © 2010 XMOS Ltd. All Rights Reserved. XMOS and the XMOS logo are registered
trademarks of XMOS Ltd in the United Kingdom and other countries, and may not be used
without written permission. Company and product names mentioned in this document are
the trademarks or registered trademarks of their respective owners. Where those designa-
tions appear in this document, and XMOS was aware of a trademark claim, the designations
have been printed with initial capital letters or in all capitals.
www.xmos.com

Document Outline

  • Introduction
  • Standard USB-BOOT-1: USB Enumeration
  • Standard USB-BOOT-2: Firmware upload over USB protocol
  • Standard USB-BOOT-3: Hardware design
  • Standard USB-BOOT-4: USB serial number

Revision History

Revision Released Formats Supported Tools
Version: 1.0 September 15, 2010 download N/A