Getting Started STi5528 and STm8000 Dual Boot support

With the term "Dual Boot" we mean the support provided by ST Linux to launch dedicate applications on slave co-processors which equip the multicore ST SOCs. Among multicore SOCs we can mention the STi5528 (ST40 plus a ST20) and the STm8000 (ST40 plus 3 ST220).

The ST40 it's always considered the master CPU, and it runs Linux.
Generally all the CPUs share all the RAM and ROM (FLASH) resources. Other HW resources such as devices may or may not be accessed by all cores, this depend on the architecture.
So far the dual boot is based on a static memory partitioned model, while the ST Remote Procedure Call constitute the infrastructure used by applications, running on different cores to cooperate.
Examples below do not use the RPC mechanism.

The Dual Boot is based on few assumptions:

• assumptions:
  • the ST40 acts as a master and boots first: this implies that it is in charge of performing the basic hardware initialization (setup clocks, LMI, EMI, etc...)
  • the master CPU runs Linux. It must be told to leave some amount of RAM for slave applications.
  • other CPUs (ST20, ST220) act as slave CPUs. Constraints exists concerning how the slave applications have to be built (see below).
  • Linux space is always located at the bottom of memory (lowest addresses) while additional slaves use the RAM regions at the top (highest addresses)
  • the solution is based on a static partitioning of the memory between ST40 and slave CPUs. Depending on which platform we are dealing with and to make more clear some statements we will refer dedicate examples of memory layout.


• limits:
  • Regardless the platform we are working with, a selective reset and reload of a single slave CPU is not permitted. Although foreseen by the SW support, it is not allowed by the hardware. Hence a re-start of a slave application cannot be done without resetting all the SOC and re-loading also the Linux kernel.
    Not observing this rule may lead to unpredictable behaviours.


• the support, general schema:
  1. if you are using the STm8000 SOC (ST220 Eval board or the STm8000 Demo) you must build and load in FLASH the relevant IPL program. This is required regardless if the Linux kernel will be launched from DCU or FLASH. This step is easy, if you are not familiar with the IPL program a ST_README file will give you all the information you need.
     Using the STi5528 (Espresso and Evaluation board) this step is not required, unless you like to boot also the ST20 application from FLASH.
  2. when configuring and building the Linux kernel include the ST coprocessor support (in the page of Platforms type and features make active ST-coprocessor interface)
  3. when booting the kernel, tune the two command line arguments below, to inform Linux about the memory layout:
  • reduce the amount of Linux RAM via:

    "... mem=XXXm ..."

  • inform the kernel about the slaves RAM space via:

    "... coprocessor_mem=[offset]:size0[,size1[,...]] ..."

    where:
    offset defines where the co-processors region starts. (it's an offset from ST40 RAM start. pay attention not to overlap the Linux memory). size{n} defines the region size for the n.th slave core.
  4. build and link consistently the application for the target coprocessor. How to achieve this depend on the target coprocessor (and toolchain) and it's better to refer to the examples below.
     Depending on the target coprocessor this step may require the use of the stimage filter to create the final executable image file.
  5. Copy the executables on the Linux File System and boot them using the stslave utility. Obviously this step isn't required if you are booting the ST20 side of a STi5528 from FLASH.

STi5528: booting the ST20

On the STi5528 platforms, it is recommended to work with two ST MicroConnects plugged (to ST40-HUDI debug and ST20-DCU interface ports) and configured. Although, this is required only if the scenario 1 is chosen, it is useful in all cases to help with debugging.
The ST20 toolchain should be installed as well on the linux host, the Rel. 1.9.6 patch 7 is recommended.

Launching a ST20 application, together with Linux, can be done in three different ways. Before entering into details let we assume to have 128Mb of RAM partitioned like in the following' example: Fig.1

1) Booting ST40 and ST20 via Micro Connect

This method is the simplest, doesn't require most of the actions previously described in the support paragraph, minimizes the impacts on the development stage and it allows to use the st20run and the ST20 debugger to download and debug the ST20 application without any known restriction.

The Linux Kernel has to be booted first on the ST40, and must be informed to leave enough RAM space for the slave CPU. Assuming the memory layout in Fig.1 the Linux kernel command line will include:

"... mem=64m ..."

In this case Linux is not aware of the existence of the RAM space beyond the mem=... boundary, hence it will never access it nor it will allow any standard command to do this.

The ST20 application must be built as a LKU format. Addresses within the ST20 region have to be used to define the EXTERNAL RAM layout when linking the ST20 application (see the sti5528.cfg file provided with the hello example. Note also the poke statements and their comments below the linking directives).
Download the example ST20 hello and prove the dual boot via DCUs to acquire familiarity with the ST20 configuration files (xxx.cfg).

2) Boot the ST20 CPU from Linux

This method is recommended when the SW development has achieved a reasonable maturity level.

Linux kernel must be configured with the co-processor as described in the support paragraph. Assuming the memory layout example of Fig.1, when launched the following arguments have to be specified in command line:

"... mem=64m coprocessor_mem=64m:64m ..."

Once the Linux boot is complete, check if the following special character device exists, otherwise create it as follows:

$ mknod /dev/st20 c 63 0

Consistently with the memory layout, the ST20 application must be built as a romimage format, this instruct the ST20 toolchain to produce a .hex executable file. Move it on the target Linux File System, and launch it using the stslave tool.
This stage can be made automatic by customizing the Linux initialization stage (init task).
Note:using Linux Rel.1.0-pl1 utilities, the ST20 .hex file must be converted into a binary image (.img file), using the hex2img cross filter, before launching it with the stslave tool.

Once the FLASH and RAM layout has been defined (let we refer to the memory layout in Fig.1), perform the following steps:

1. link the ST20 application accordingly to the layout. Force the ST20 toolchain to build it as a romimage format, convert it into a pure binary image before loading it in FLASH. To do this:
   • link the ST20 application at:

     EXTERNAL memory at 0xC4000000 size (64 * M)
     ROM at 0x40400000 size (...)

   • convert the output .hex file into a binary image:

     $ hex2raw -v st20appl.hex

   will create the file st20appl.raw


2. customize the STi5528 IPL program by modifying the config.h file. Make it aware of the existence of the ST20 application and define the command line it will pass to the kernel. The two following definitions exists for this purpose:

   #define CONFIG_ST20_BOOT_OFFSET boot_addr

   #define CONFIG_CMD_LINE ".... mem=64m coprocessor_mem=64m:64m ...

   Assuming the layout in Fig.1, boot_addr will be 0x80140000 (the offset of /dev/mtd1 FLASH device, where the ST20 application is loaded).
   This will cause IPL to start the ST20 before continuing with the Linux kernel initialization.
   The ST_README file in the IPL source tree and comments in the config.h file should help to do this step.


3. build the final Linux kernel, zImage format, you desire to be executed from FLASH. It doesn't require to be configured with the st-coprocessor support, however it is suggested to include it (it requires a very limited amount of space)


4. The last step concerns to program the FLASH, Linux itself can be used for this purpose. Boot, from DCU, a Linux kernel having the knowledge of the defined FLASH layout. Assuming the Fig.1 example this is achieved booting the kernel with the following command line:

   "... mem=64m coprocessor_mem=64m:64m mtdparts=Onboard_Flash:256k@0k,1024k@256k,2816k@1280k,-..."

   Copy all the executable images (IPL: sh-stub.bin, kernel zImage, and the ST20 application: st20appl.raw) on the target Linux File system, and then use the standard dd and eraseall utilities to copy the images in FLASH:

   $ eraseall /dev/mtd0
   $ eraseall /dev/mtd1
   $ eraseall /dev/mtd2
   $ dd if=sh-stub.bin of=/dev/mtd0 bs=128k
   $ dd if=zImage of=/dev/mtd1 bs=128k
   $ dd if=st20appl.raw of=/dev/mtd3 bs=128k
   

   See the Getting Started chapters Boot from ROM and Flash Partitioning for further details.
   

STm8000: booting the ST220 cpus

On these platforms only the boot from Linux model is allowed. The ST220 applications are executables ELF files stored on the target Linux File System.

So far ST40 Linux doesn't support debugging of applications running on slave CPUs, hence this way of executing ST220 applications is recommended for stable code, as a final development stage.

Before going forward a short background may be worth. All the ST220 devices are under the global system reset control (also controlled by ST40). By HW design all the ST220 cores, exit reset at the same time as the rest of the system, and if their input DEBUG_ENABLE is not asserted (prerequisite #4) they jump to execute their bootcode at ROM (FLASH) addresses:

ST40 -> 0x00000000 (when booting from FLASH)
Video encoder (ST220 0) -> 0x00000040
Audio encoder (ST220 1) -> 0x00000080
Audio decoder (ST220 2) -> 0x000000C0

Prerequisite for doing this are:

1. the ST200 toolchain Rel. 3.2 or 4.0 installed
2. Linux kernel configured with the ST coprocessor support
3. the stslave utility installed
4. do not plug any ST MicroConnect into the ST220 debug ports, this disable the ST220 booting via its JTAG port, and enable them to boot from ROM
5. on the ST220 Eval board, checks the 4 switches in SW1 be in OFF position
6. ST40 can boot from ROM or DCU (ST40 MicroConnect can be plugged)
7. the Linux IPL program for ST220 Eval or STm8000 Demo must be built and stored in FLASH
8. note: the ST220 application, regardless is bare or OS21 based needs to be linked using a simplified version of the bootStub.S code (form ST200 toolchain runtime support). The standard code provided by the toolchain, generates some extra ELF sections which are not compatible with a Linux based environment.

To run the LED flashing examples, on a ST220 Evaluation board, do the following:

1. be sure the ST200 toolchain (rel. 4.0 is recommended) be properly installed and their tools accessible via environment PATH variable (this make things easier).


2. download the LED test, move under the test directory and build them:

   $ make CPU=0
   $ make CPU=1
   $ make CPU=2
   

   Copy the executable ELF files on the target File System mounted by Linux
   Note: their linking directives are consistent with the memory layout of Fig.2


3. build the FLASH IPL program. In the IPL source tree do:

   $ ln -s config/config.h-st220eval config.h
   $ ln -s config/config.mk-st220eval config.mk
   $ make clean
   $ make TYPE=FAST sh-stub.bin
   

   boot code for the ST220 is automatically included. Store it in FLASH


4. build the Linux kernel making sure that the ST coprocessor support has been enabled.
   Note: providing the MDT device has been enabled, this kernel can be used also to copy the IPL program in FLASH. (see the Getting Started chapters Boot from ROM and Flash Partitioning for further details).


5. boot the Linux kernel (from MicroConnect or from FLASH), make sure the the command line defines the correct RAM layout. Like the example of Fig.2 it will be:

   "... mem=32m coprocessor_mem=40m:8m,8m,8m ..."

   when the boot is complete and the shell prompt appear, checks for the following devices creates the following devices (on latests Linux releases they should already exist):

   $ mknod /dev/st220 c 63 0
   $ mknod /dev/st220-0 c 63 0
   $ mknod /dev/st220-1 c 63 1
   $ mknod /dev/st220-2 c 63 2
   

   
   finally launch the ST220 applications typing:

   $ stslave -t st220eval.0 -R led0.elf
   $ stslave -t st220eval.1 -R led1.elf
   $ stslave -t st220eval.2 -R led2.elf
   

   as a result, all the green LEDs on the boards should flash at a different rate.