Archive for the ‘embedded system’ Category

Unboxing DragonBoard 410c and booting up on uart console

As a start a lot of details have been covered here:

and here is the setup for uart console: (A)

And yes, the UART console is done using a 1.8V FTDI adapter cable (which I used previously for Raspberry Pi):

And the S6 pins on the DragonBoard itself is 0-1-0-0. (which is after the stage where the SDcard have been flashed to the internal eMMC.

Details see the above URL link (A) (Flashing the SD Card Image to the DB410c).

And here is the bootup captured over the uart console of booting up from internal eMMC:

(which is Ubuntu 15.04 as you can see)



Minnowmax Bootup using Buildroot


First, download buildroot, and then make the buildroot image for Minnowmax:

make minnowboard_max_defconfig

After that, under buildroot’s “output” directory there is a images subdirectory. You can find bzImage and rootfs.tar there.

These are your kernel file, and rootfs tar file. Copy the kernel file, and you have to use root (“sudo”) to untar the rootfs.tar to your SDCard, so as to retain the uid/gid information as it originally it.

These instructions can be found further explained below (host machine is running Ubuntu 14.04 64-bit LTS):

Prepare the SD card for the Minnow Board MAX

+ 1. Partition the SD card with a GPT partition table+
+ sudo cgdisk /dev/mmcblk0
+ Create two partitions:
+ a) First partition of a few dozens of megabytes, which will be
+ used to store the bootloader and the kernel image. Type must
+ be EF00 (EFI partition).
+ b) Second partition of any size, which will be used to store the
+ root filesystem. Type must be 8300 (Linux filesystem)
+ 2. Prepare the boot partition
+ We will format it, mount it, copy the EFI data generated by
+ Buildroot, and the kernel image.
+ sudo mkfs.vfat -F 32 -n boot /dev/mmcblk0p1
+ sudo mount /dev/mmcblk0p1 /mnt
+ sudo cp -a output/images/efi-part/* /mnt/
+ sudo cp output/images/bzImage /mnt/
+ sudo umount /mnt
+ 3. Prepare the root partition
+ We will format it, mount it, and extract the root filesystem.
+ sudo mkfs.ext4 -L root /dev/mmcblk0p2
+ sudo mount /dev/mmcblk0p2 /mnt
+ sudo tar -C /mnt -xf output/images/rootfs.tar
+ sudo umount /mnt

Connect the serial wire as shown below:

Serial Pinout for MINNOWMAX

Full dump of booting up:


TIVA C Series TM4C1294 Connected LaunchPad Eval Kit programming via Energia



1. Host environment: Ubuntu 14.04 LTS 64-bit. Connect the debug port of Launchpad to the host machine via USB cable. Check “dmesg” and identify /dev/ttyACM0 as being automatically configured.

2. Download Energia (and untar it into a directory):

3. Go to the Energia download directory, and enter “sudo ./energia”. Then File->Example->Basic->Blink to load the Blinker source code (as the example code). Then goto “Tool->Board” to select TM4C129 as the board. And next “Tool->Serial Port” to select /dev/ttyACM0 as the port, which is discovered through “dmesg”.

4. Compile and upload the example code, which will go to the TM4C1294 board automatically.

5. Looking into the console output you can see Energia executing under the hood:

[/home/tthtlc/Downloads/energia-0101E0014/hardware/tools/lm4f/bin/arm-none-eabi-g++, -Os, -nostartfiles, -nostdlib, -Wl,–gc-sections, -T, /home/tthtlc/Downloads/energia-0101E0014/hardware/lm4f/cores/lm4f/lm4fcpp_snowflake.ld, -Wl,–entry=ResetISR, -mthumb, -mcpu=cortex-m4, -mfloat-abi=hard, -mfpu=fpv4-sp-d16, -fsingle-precision-constant, -o, /tmp/build6614371312095748777.tmp/Blink.cpp.elf, /tmp/build6614371312095748777.tmp/Blink.cpp.o, /tmp/build6614371312095748777.tmp/core.a, -L/tmp/build6614371312095748777.tmp, /home/tthtlc/Downloads/energia-0101E0014/hardware/lm4f/cores/lm4f/driverlib/libdriverlib.a, -lm, -lc, -lgcc, -L/tmp/build6614371312095748777.tmp, -lm]

[/home/tthtlc/Downloads/energia-0101E0014/hardware/tools/lm4f/bin/arm-none-eabi-objcopy, -O, binary, /tmp/build6614371312095748777.tmp/Blink.cpp.elf, /tmp/build6614371312095748777.tmp/Blink.cpp.bin]

Binary sketch size: 2,380 bytes (of a 1,048,576 byte maximum)
Found ICDI device with serial: 0F000CFF
ICDI version: 12245

6. Now disassemble the binary (based on the console output above) using the following command:

/home/tthtlc/Downloads/energia-0101E0014/hardware/tools/lm4f/bin>./arm-none-eabi-objdump -d /tmp/build6614371312095748777.tmp/Blink.cpp.elf

The output is here:

7. The disassembled codes can be read off as for example:

00000208 :
208: b508 push {r3, lr}
20a: 2101 movs r1, #1
20c: 2051 movs r0, #81 ; 0x51
20e: f000 f867 bl 2e0
212: f44f 707a mov.w r0, #1000 ; 0x3e8
216: f000 f8a9 bl 36c
21a: 2051 movs r0, #81 ; 0x51
21c: 2100 movs r1, #0
21e: f000 f85f bl 2e0
222: f44f 707a mov.w r0, #1000 ; 0x3e8
226: e8bd 4008 ldmia.w sp!, {r3, lr}
22a: f000 b89f b.w 36c

00000230 :
230: 4b26 ldr r3, [pc, #152] ; (2cc <pinMode+0x9c>)
232: 4a27 ldr r2, [pc, #156] ; (2d0 <pinMode+0xa0>)
234: b570 push {r4, r5, r6, lr}
236: 5c1d ldrb r5, [r3, r0]
238: 4b26 ldr r3, [pc, #152] ; (2d4 <pinMode+0xa4>)
23a: 5c1b ldrb r3, [r3, r0]
23c: f852 4023 ldr.w r4, [r2, r3, lsl #2]
240: 2b00 cmp r3, #0
242: d042 beq.n 2ca <pinMode+0x9a> 244: 4e24 ldr r6, [pc, #144] ; (2d8 <pinMode+0xa8>)
246: b911 cbnz r1, 24e <pinMode+0x1e> 248: 6833 ldr r3, [r6, #0]
24a: 6b9b ldr r3, [r3, #56] ; 0x38
24c: e03a b.n 2c4 <pinMode+0x94> 24e: 2902 cmp r1, #2
250: d116 bne.n 280 <pinMode+0x50> 252: 4b22 ldr r3, [pc, #136] ; (2dc <pinMode+0xac>)
254: f8c4 3520 str.w r3, [r4, #1312] ; 0x520


ARM TrustZone technology for iMX53

Genode – An Exploration of ARM TrustZone Technology

This kernel is the only code except the mode transition PIC, that runs in privileged CPU mode. It has two tasks. First it initializes the process ‘core’, enriches it with the whole identically mapped address range, joins and applies it, assigns one thread to it with a userdefined entrypoint (the core main thread) and starts this thread in userland. Afterwards it is called each time an exception occurs in userland to do a minimum of appropriate exception handling. Thus it holds a CPU context for itself as for any other thread. But due to the fact that it never relies on prior kernel runs this context only holds some constant pointers such as SP and IP. a set of codes for iMX53

This is the bare metal program running on i.MX53 QSB to test the TrustZone Secure-Normal World Transition.

If you want to use your own mkimage in your u-boot code, please change MKIMAGE in Makefile.

MMU registers:

Further XMOS exploration

Lots of examples:

XmosStartKit/StartKit-Hacking at master · r4d10n/XmosStartKit

From here:

is described in detail how the LED light is programmable to generate any desired pattern:

So as of this writing in XMOS/xTIMEcomposer/Community_13.0.1/configs.  
I see the file XS1-UnA-64-FB96.pkg.    In that file I see

        <Pin name="X0D68">
            <Port bitNum="17" core="0" name="XS1_PORT_32A" node="0" priority="0"/>
            <XLink bitNum="2" dir="in" node="0" number="1"/>
        <Pin name="X0D69">
            <Port bitNum="18" core="0" name="XS1_PORT_32A" node="0" priority="0"/>
            <XLink bitNum="3" dir="in" node="0" number="1"/>
        <Pin name="X0D70">
            <Port bitNum="19" core="0" name="XS1_PORT_32A" node="0" priority="0"/>
            <XLink bitNum="4" dir="in" node="0" number="1"/>

From the schematic, we see

are tied to the leds.  And that all seems to match, except that the
XS1-A8A-64-FB96 datasheet does not have these


The config file does though.  curious.

So the port is XS1_PORT_32A and these bits in that port are tied to leds

X0D70 is bit 0x80000
X0D69 is bit 0x40000
X0D68 is bit 0x20000
X0D63 is bit 0x01000
X0D62 is bit 0x00800
X0D61 is bit 0x00400
X0D58 is bit 0x00200
X0D57 is bit 0x00100
X0D56 is bit 0x00080

From the schematic the led is tied between 3.3v and the gpio port, so
making the pin high turns the led off (led has 3.3v on both ends, no
current) and making the pin low turns the led on (led has 3.3v on
one end and ground, 0v, on the other, current flows).

They way their code (and now mine) works all 32 bits in that port are
getting written to AFAIK, so it requires more investigation to know
what those other port pins are tied to and whether or not to run examples
that write the whole port (without doing a read-modify-write) if the
board is connected to something and not sitting there by itself.

Start with the figure8 example then ablink01 if interested.

Between the Raspberry Pi and startKIT documentation this is the pinout
for the connection

Raspberry Pi connector
pin raspi       startkit

1   GND         (nc)
3   SDA1        X0D49
5   SCL1        X0D70
7   GPIO_GCLK   X0D69
9   GND         GND
11  GPIO_GEN0   X0D61
13  GPIO_GEN2   X0D58
15  GPIO_GEN3   X0D57
17  GND         (nc)
19  SPI_MOSI    X0D0
21  SPI_MISO    X0D11
23  SPI_SCLK    X0D10
25  GND         GND

2   5.0v        (nc)
4   5.0v        (nc)
6   GND         GND
8   TXD0        X0D68
10  RXD0        X0D63
12  GPIO_GEN1   X0D62
14  GND         GND
16  GPIO_GEN4   X0D56
18  GPIO_GEN5   (nc)
20  GND         GND
22  GPIO_GEN6   (nc)
24  SPI_CE0_N   X0D51
26  SPI_CE1_N   X0D50

So the uart comes into the XMOS on X0D68 and out the XMOS on X0D63, the
Raspberry Pi spi connections are there, something to play with as well
along with some generic gpio.

Lots of hacking with XMOS:

And from below is shown how to program the XMOS STARTKIT directly, without using Eclipse tool:

…..connect two startkits together via links and boot them from SPI. The steps should be as follows:

1. Compile a two tile application with the attached .xn file. You can only use one of the ADC tiles (it isn’t possible to include both in the network since they would have the same routing ID). For example:

xcc app.xc 2_STARTKITS.xn -o app.xe

2. Next generate two flash binary images:

xflash app.xe --noinq --boot-partition-size 0x20000 -o flash_image

This will create two images (flash_image_0 and flash_image_1).

3. Finally write the flash images over jtag:

xflash --id <board_0_id> --write-all flash_image_0 --target STARTKIT
xflash --id <board_1_id> --write-all flash_image_1 --target STARTKIT

4. If you power cycle both boards at the same time they should boot into the two tile application you’ve written to the flash.

Example XN file for combined devices is shown below.

Unboxing my XMOS “StartKIT” and discovering xTIMEComposer under the hood

I got my free XMOS StartKIT courtesy of XMOS (THANK YOU!!):

Reading this:

And start discovering lots of projects available at:

First, connect the StartKIT via USB to the computer, use “lsusb” to discover the vid and pid. Update this into the /etc/udev/rules.d/80-xmos.rules:

ATTRS{idVendor}==”20b1″, ATTRS{idProduct}==”f7d3″, MODE=”0660″, GROUP=”plugdev”

And then “sudo service udev restart” to restart the udevd services.

The purpose of above procedure is so that access to the device via USB does not need to be root, but just ensure that the current user or owner is member of the “plugdev” group.

Downloaded the xTIMEComposer (13.2.1, 64-bit and my OS is Ubuntu 14.04 LTS 64-bit), and ensure that you have 64-bit Java. Unpack the tarball downloaded from, and then starting up the “xtimecomposer”.   Many snapshots of xTIMEComposer can be found on the web:

Autodetection of USB device will be done, and subsequently go through the tutorial to create your first application. Mine is “spinning app”:

Now, at this point, doing a process enumeration, we can see hat the xtimecomposer (pid=3472) has started “xgdb” process (pid=5511) to access the hardware device via USB:

tthtlc 3472 3471 1 19:38 pts/3 00:02:19 /usr/bin/java -Dcom.xmos.cdt.disableMozillaBrowserCreation=True -Dorg.eclipse.swt.browser.UseWebKitGTK=True -jar /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar -os linux -ws gtk -arch x86_64 -showsplash -launcher /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin/xtimecomposer.exe -name Xtimecomposer.exe –launcher.library /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.1.2.R36x_v20101019_1345/ -startup /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar -exitdata 20800e -vm /usr/bin/java -vmargs -Dcom.xmos.cdt.disableMozillaBrowserCreation=True -Dorg.eclipse.swt.browser.UseWebKitGTK=True -jar /home/tthtlc/Downloads/XMOS/xTIMEcomposer/Community_13.2.1/xtimecomposer_bin//plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar

tthtlc 5511 3472 0 21:28 pts/3 00:00:20 xgdb -q -nw -i mi2 –cd=/home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar –command=.gdbinit /home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar/bin/app_spinning_bar.xe

From above we learned that xTIMECOmposer create and stored its repository inside $HOME/.xmos directory (see pid=5511 above). “xc” is the extension for a C file to be compiled by “xcc”, and output file is “xe” as the extension. Using “xobjdump -d xxx.xe” we can list the assembly as below:

Loadable 1 for tile[0] (node “0”, tile 0):

Disassembly of section .text (size: 240)

0x00010000: 00 68: ldc (ru6) r0, 0x0
0x00010012: 40 6a: ldc (ru6) r9, 0x0
0x00010014: 00 f0 6c d8: ldap (lu10) r11, 0x6c <.label0>
0x00010018: fb 37: set (1r) cp, r11
0x0001001a: 00 f0 7b d8: ldap (lu10) r11, 0x7b <.label1>
0x0001001e: eb 37: set (1r) dp, r11
0x00010020: cb 6a: ldc (ru6) r11, 0xb

Detailed instruction sets described here:
And listing the xgdb’s (pid=5511) /proc/5511/fd directory:
lrwx—— 1 tthtlc tthtlc 64 Jan 29 22:31 5 -> /dev/bus/usb/001/005
The line above indicate that the /dev/bus/usb/001/005 is open for both read and write.
Next is to trigger a “Run Configuration” to run the program on the device.

From “ps -ef” output we can see it is “xrun” that get executed (pid=6438):

tthtlc    6438  3472  0 22:52 pts/3    00:00:00 xrun –adapter-id 0ecxWIbrM.3O. –io /home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar/bin/app_spinning_bar.xe

tthtlc    6443  6438  0 22:52 pts/3    00:00:00 xgdb -q –return-child-result –batch –ex set $xcore_id=0 –ex set $xcore_boot=0 -x /tmp/.xrun6438-3BP1TC2N/xeload_auto.gdb /home/tthtlc/.xmos/repos/sw_startkit_examples/app_spinning_bar/bin/app_spinning_bar.xe

Now xrun will fork a new process running xgdb (pid=6443).

So how was xgdb able to copy the program into the remote USB XMOS device from the PC host?

The details are covered in here (page 180):
How the xcc compiler, is used is explained, and “xflash” command is shown it can be used to copy the program into the flash.   After the image is flashed, and subsequently how it is booted? The page below can provde some answer:
Hardware-wise, it is possible to integrate with RaspberryPi:
At the heart is this multicore processor:
Hardware datasheet is mainly this two:
Many other examples lies at:
After downloading, take a look at the startKIT_port_mapping.h to see all the portmap for programming hardware peripherals.
Another amazing feature is the XSwitch:
Other references:

How to write a simple OS based on outputting on UART

Writing to the UART offer an opportunity to receive and transmit out of the SoC, and therefore the simplest OS should be rather easy to write, simply by receiving and transmiting at the UART interface.

Below are the many examples of simple program written for some popular SoC:

Singpolyma » Writing a Simple OS Kernel — Part 7, Serial Port Driver

And a simple example to write to UART:

A complete program running on baremetal RPI writing Hello to UART is shown below:

And just in case u have got no money to buy any SoC board:

(which have a very good explanation of generating the binaries and laying it out in memories for the hardware simulator).

%d bloggers like this: