Skip to content

Developerbox Getting Started

Daniel Thompson edited this page Nov 9, 2017 · 37 revisions

Developerbox (cased) Developerbox (board only)

Disclaimer

The Developerbox is not yet commercially available and users have been allocated boards for testing purposes only. Please expect limited documentation and support until further notice.

Reporting problems

This section applies only to participants in the Developerbox test programme.

Before reporting any problems with Developerbox please ensure that they have not been reported already (open issues) and that the problems described are specific to Developerbox.

Bugs can be reported at: bugs.linaro.org.

Table of contents

Platform firmware

These instructions assume you have created a working directory and stored its name in the environment variable, WORKSPACE. In addition to testing on an x86 PC, these instructions are known to work, without modification, on a Developerbox running Debian Stretch.

In addition to the "normal" build tools you will also need a few specialist tools:

sudo apt install acpica-tools device-tree-compiler uuid-dev

Cloning the sources

git clone https://git.linaro.org/uefi/arm-trusted-firmware.git -b synquacer
git clone https://github.com/ardbiesheuvel/edk2.git -b x86emu
git clone https://github.com/ardbiesheuvel/X86EmulatorPkg
git clone git://git.linaro.org/uefi/edk2-platforms.git -b developer-box
git clone git://git.linaro.org/uefi/edk2-non-osi.git -b developer-box
git clone https://github.com/openssl/openssl  -b OpenSSL_1_1_0e
(cd edk2/CryptoPkg/Library/OpensslLib/; ln -s ../../../../openssl .)
(cd edk2-platforms; ln -s ../X86EmulatorPkg .)

Build ARM Trusted Firmware

cd $WORKSPACE/arm-trusted-firmware
make -j `nproc` \
	CROSS_COMPILE=aarch64-linux-gnu- \
	PLAT=ashbrook_5 \
	BL33_BASE=0x8200000 \
	all fiptool
tools/fip_create/fip_create \
	--dump \
	--tb-fw ./build/ashbrook_5/release/bl1.bin \
	--soc-fw ./build/ashbrook_5/release/bl2.bin \
	--scp-fw ./build/ashbrook_5/release/bl31.bin \
	../edk2-non-osi/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin

Build EDK2

cd $WORKSPACE
export PACKAGES_PATH=$WORKSPACE/edk2:$WORKSPACE/edk2-platforms:$WORKSPACE/edk2-non-osi
export ACTIVE_PLATFORM="`find $WORKSPACE -name DeveloperBox.dsc`"
export GCC5_AARCH64_PREFIX=aarch64-linux-gnu-
unset ARCH

. edk2/edksetup.sh
make -C edk2/BaseTools

build -p $ACTIVE_PLATFORM -b RELEASE -a AARCH64 -t GCC5 -n `nproc` -D DO_X86EMU=TRUE

The firmware image, which comprises the option ROM, ARM trusted firmware and EDK2 itself, can be found Build/DeveloperBox/RELEASE_GCC5/FV/. Use SYNQUACERFIRMWAREUPDATECAPSULEFMPPKCS7.Cap for UEFI capsule update and SPI_NOR_IMAGE.fd for the serial flasher.

Note #1: -t GCC5 can be loosely translated as "enable link-time-optimization"; any version of gcc >= 5 will support this feature and may be used to build EDK2.

Note #2: Replace -b RELEASE with -b DEBUG to build a debug version of the firmware.

Updating the platform firmware

The platform firmware can be updated in two different ways:

  1. From within UEFI itself (a.k.a. capsule update). This is the recommended way for most users.
  2. Booting a serial flasher utility from NOR FLASH. This requires access to LS-UART0 using a suitable 1.8v TTL serial adapter. Take great care using the serial flasher;. it is capable of (unbanked) self-update and, if used incorrectly, can render the system unbootable and recoverable only by using JTAG programmer.

Capsule update via UEFI

As root:

# (temporary - you might have to update fwupaa64.efi until the latest version starts to land in install images)
apt install fwupdate
fwupdate \
        --apply {50b94ce5-8b63-4849-8af4-ea479356f0e3} \
        Build/DeveloperBox/RELEASE_GCC5/FV/SYNQUACERFIRMWAREUPDATECAPSULEFMPPKCS7.Cap
reboot

Update using serial flasher

The serial flasher can be enabled in two ways.

  1. Turn the board off, set DSW2-7 to on and turn the board on again. The flasher program will be started automatically; don't forget to turn the switch off again after flashing.
  2. Send a keypress to LS-UART0 shortly after turning on the power to the board and enter update firmware at the resulting command prompt. In some systems the timeout to enter the initial keypress is very short meaning it is best to send repeated keypresses commencing before you turn the board on (a.k.a. keyboard auto-repeat).

When the serial flasher is running correctly is will show the following boot messages:

/*------------------------------------------*/
/*  SC2A11 "SynQuacer" series Flash writer  */
/*------------------------------------------*/

Command Input >

Once the flasher tool is running we are ready flash the UEFI image:

flash rawwrite 180000 280000
# Send SPI_NOR_IMAGE.fd via XMODEM (Control-A S in minicom)

Resetting the NVRAM

Occasionally it is necessary to reset the platform's "NVRAM", a special section on the NOR flash which holds the UEFI variable store.

The simplest way to reset the NVRAM is to set DSW3-1 to on and reboot the system. Be sure to remember to set the switch back to the default (off) position, before the next reboot!

Alternatively it is possible to wipe the varstore when updating the UEFI image using the serial flasher, try (note the change if size, from 28000 to 2b0000, compared to a normal flash write operation):

flash rawwrite 180000 2b0000
# Send SPI_NOR_IMAGE.fd via XMODEM (Control-A S in minicom)

Low-level (CM3) firmware

Very occasionally it may be required to update the low-level board firmware (a.k.a. CM3 firmware).

Update using serial flasher

Be aware that THIS COMMAND HAS THE CAPABILITY TO SOFT-BRICK YOUR BOARD. In particular the implementation of the XMODEM protocol is easily confused by extra keystrokes and runs after the FLASH has been erased. For example sending Control-A Control-S rather than Control-A S from minicom risks soft-bricking the board. It is possible to recovery a soft-bricked board using a JTAG programmer (see below).

Update the low-level firmware only when strictly necessary, and it is recommended to always "practice" by updating the option ROM whether or not it requires contains any changes!

flash write s-mir-cm3
# Send new option ROM via XMODEM
# synquacer_eeprom_pcie0snoop_on_pcie1snoop_on.bin
flash write p-REMOVEmasterCAPS-cm3
# Send new CM3 firmware via XMODEM

The currently recommended firmware is: ramfw_20171102.bin (sha1sum: 6dad40f7d055346a7cd095ed432c677bf2509c8e).

Example session log

Full log of a low-level firmware upgrade is shown below. The serial flasher was entered using the keystroke method:

[SYSTEM] Entered SynQuacer Firme
[SYSTEM] chip version 2.
[SYSTEM] Firmware mode Master
[SYSTEM] Platform: Socionext ARM Server
[SYSTEM] Configuration: 5
[SYSTEM] v1.15.1
[SYSTEM] Build: 09/22/17 19:42:53
[SYSTEM] git revision f4de521
[SYSTEM] Initializing power domain 
[PowerDomain] Socionext-PPU initialize .
[PowerDomain] Socionext-PPU initialize end .
[PowerDomain] PowerDomain All-ON start.
[PowerDomain] PowerDomain All-ON finished .
[SYSTEM] Finished initializing power domain 
[SYSTEM] Initializing NIC SECURE
[SYSTEM] Finished initializing NIC SECURE
[SYSTEM] Starting irq enabele 
[SYSTEM] Finished starting irq enabele 
[SYSTEM] Initializing maintenance network 
[COMLIB] Initializing NETSEC hardware 
[COMLIB] NETSEC found. Hardware version: 00050041
[COMLIB] Finished initializing NETSEC hardware 
[COMLIB] Microcode version: 100005D5
[COMLIB] Initializing external Ethernet PHY device 
[COMLIB] Finished initializing external Ethernet PHY device 
[SYSTEM] Finished initializing maintenance network 
To enter debug mode, please press any key.

/*------------------------------------------*/
/* uart input mode (state : P_IDLE)         */
/*------------------------------------------*/

Command Input >update firmware
update firmware 

/*------------------------------------------*/                                 
/*  SC2A11 "SynQuacer" series Flash writer  */                                 
/*------------------------------------------*/                                 
                                                                               
Command Input >flash write p-master-cm3                                        
Command'flash'Start...                                                         
HsspiSoftwareReset()...RDSR=40                                                 
[INFO] ManufacturerID=C2 DeviceID=25 RDSR=00                                   
[INFO] DeviceName=MX66U1G45G (256bytes per programmable page)                  
Showing status registers. RDSR = 0x00000040, Enter 4-byte mode                 
HsspiSectorErase. Please wait...                                               
 End.SectorErase(7/7)...                                                       
Writing data at offset 0x00000000, max_size 0x00080000
Waiting to receive the data in XMODEM protocol (128bytes check-sum)...         

>>>>> Send firmware via XMODEM when non-ASCII characters appear <<<<<

[SUCCESS] 0x0001ec80 bytes written
Exit 4-byte mode
Showing status registers. RDSR = 0x00000042, Return Val = '0'
Command'flash'End...
Command Input >

JTAG recovery

The JTAG recovery process allows the serial flasher to be run from SRAM, thus allowing the NOR to be updated.

To recovery the board you will need a suitable JTAG programmer. The SC2A11 is interfaced using 1.8v TTL logic. Your programmer must support 1.8v signalling and, if the programmer supports powering the target device, this feature must be disabled before you connect the programmer to the board (many programmers provide a 3.3v power supply and applying this voltage could damage the board).

These instructions assume you have a Bus Blaster running using a KT-Link compatible buffer and with the power supply jumper removed (as discussed above). In the instructions below, replace interface/ftdi/dp_busblaster_kt-link.cfg with whatever is appropriate for your programmer.

Note: If you have purchased a Bus Blaster device to perform the recovery, it will not have been shipped with a KT-Link compatible buffer (they are usually shipped with selftest firmware). To update the buffer, try git clone https://github.com/bharrisau/busblaster followed by openocd -f board/dp_busblaster_v3.cfg -c "adapter_khz 1000; init; svf synthesis/system.svf; shutdown"

Firstly we must create a configuration file to describe the board:

cat > sc2a11.cfg <<EOF
###########################################
set _CHIPNAME sc2a11
set _TARGETNAME \$_CHIPNAME.m3
adapter_khz 1000

if { [info exists ENDIAN] } {
   set _ENDIAN \$ENDIAN
} else {
   set _ENDIAN little
}

set _M3_JTAG_TAPID 0x6ba00477

jtag newtap auto0 tap -irlen 4 -expected-id 0x6ba00477

target create \$_TARGETNAME cortex_m -endian \$_ENDIAN -chain-position auto0.tap
EOF

If your board was bricked by a failed attempt to update the CM3 firmware then the flasher tool is still present in NOR but there is no bootloader to launch it. Try:

openocd \
        -f interface/ftdi/dp_busblaster_kt-link.cfg \
        -f sc2a11.cfg \
        -c "init" \
        -c "reset halt" \
        -c "mwb 0x44100000 3" \
        -c "resume 0x8fe0050" \
        -c "exit"

Alternatively, if your NOR has been totally erased (this is unlikely, but certainly possible) then you may have to load a flasher tool into RAM:

openocd \
        -f interface/ftdi/dp_busblaster_kt-link.cfg \
        -f sc2a11.cfg \
        -c "init" \
        -c "reset halt" \
        -c "mwb 0x44100000 3" \
        -c "load_image flash-writer-maverick-evb-4bytemode.axf-cd59a5d" \
        -c "resume 0x800051" \
        -c "exit"

Whichever approach is used, at this point the SC2A11 Flash writer should be running on the CM3 console and NOR can be updated:

flash write s-mir-cm3
# Send new option ROM via XMODEM
# edk2-non-osi/Platform/Socionext/DeveloperBox/synquacer_eeprom_pcie0snoop_on_pcie1snoop_on.bin
flash write p-master-cm3
# Send new CM3 firmware via XMODEM

Hardware setup

This section is primarily of interest to developers who received a bare motherboard rather than a pre-assembled PC tower case.

Minimal build

The minimal build assumes you have a PC case; note that strictly speaking the case is optional since the reset and power buttons the case provides are replicated on the motherboard itself.

  • Install motherboard in PC case,
  • Connect USB3 front panel connector (F_USB1),
  • Connect chassis power switch, power LED and HDD LED to pin header near RTC battery (J-PWR-SW, J-PWR-LED and SATA-LED; for LEDs the -ve pin is closest to the large ATX power connector,
  • Connect power supply to 24-pin ATX connector (ATX1).
  • Install RAM. Follow DIMM slot layout guide below.

Note on pre-production boards the reset switch may cause the board to hang so connecting it is not recommended. See workaround below.

DIMM slot layout

The SynQuacer firmware will log boot information via LS-UART0 (115200 8N1, no flow control). If the DIMM slot layout is incorrect the following message will appear in the firmware log:

[SYSTEM] Starting read spd at sdram size
[SYSTEM] slot DIMM1: 4096MB UDIMM non-ECC
[SYSTEM] slot DIMM2: not detected
[SYSTEM] slot DIMM3: not detected
[SYSTEM] slot DIMM4: not detected
[ERROR] read spd at sdram non support dimm slot layout!

The following DIMM slot layouts may be used:

  • Single DIMM: DIMM2
  • Dual DIMM: DIMM2 and DIMM4
  • Quad DIMM: Use all slots

UART for main system and CM3 SCP

The main system UART (used for OS console) is available via a micro-USB connector. On pre-production boards this connector is located on the back edge next to the front panenl pin header.

The CM3 SCP UART (used for low-level firmware upgrade) is availabled on the 96Boards low-speed connector: pins 1 (GND), 5 (TX) nd 7 (RX). Unfortunately on pre-production motherboards access is difficult because the LS connector has the wrong gender. Possible workarounds include:

  1. Use a 2x22 2mm female-to-female ribbon cable as a converter. There are two caveats here: 1) for most cables the sides of the socket on the motherboard must be physically snapped off to provide clearance to attach the cable and, 2) most ribbon cable have connectors on same side of the ribbon meaning they swap odd/even rows making it unsafe to attach mezzanine boards to all 40 pins, however the 96Boards-uart mezzanine can still be used but it must be offset so that only one row of pins is connected to the ribbon cable. There are four possible ways to attach a mezzanine like this (and at least one will likely do physical damage) to review the 96Boards GPIO Pinout carefully.
  2. Use 2mm female jumper cables to bring out just the UART signals from the LS connector.
  3. De-solder the male connector and replace with male 2x20 2mm header.

Workarounds for pre-production boards

The rear USB3 sockets have D+/D- swapped preventing the sockets from working. This can be workarounded around with custom cabling (either by modding a broken out USB cable or by switching the D+/D- lines of a hub with a wired "uplink").

The reset switch (and associated pin header) is connected to an advisory reset line rather than the power-on reset, making it unreliable. The power-on reset signal is available on pin 4 of the 96Boards low-speed connector. If you have a chassis reset switch it is recommended to use jumper wires to connect the switch across pin 2 (GND) and pin 4 (PWR_BTN_N) of the LS connector.

DIP switches

As shipped the default DIP switch positions are:

  • DSW1: All off
  • DSW2: On (3, 4, 5, 6), Off (1, 2, 7, 8)
  • DSW3: All off

Hints and tips

UEFI

  • It is possible to install Debian Stretch (plus a custom kernel) directly from within the UEFI menu system:

    asciicast

  • If the UEFI menus do not show correctly on the serial port try using screen or picocom instead of minicom and ensure the terminal emulator window is at least 80x25 characters

  • The default boot timeout is quite long. It can be shortened by setting the appropriate EFI variable, just modify the fifth byte from \x05 to any hex number (in seconds):

    printf '\x07\x00\x00\x00\x05\x00' /sys/firmware/efi/efivars/Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c

Debian

  • If you have a couple of x86_64 binaries that you just cannot do without (the hikey960 recovery tools for example) then you may be able to run them using QEMU user-mode emulator. See https://wiki.debian.org/QemuUserEmulation for more details; the instructions are known to work on Developerbox, just replace armhf with x86_64.

  • Developerbox can natively run AArch32 binaries but will need a suitable C library:

    dpkg --add-architecture armhf && apt update && apt install libc6:armhf.