How to Build and Load Tizen on Odroid U3

From Tizen Wiki
Jump to: navigation, search

Contents

About the Odroid

Odroid U3 is a development board introduced by the Hardkernel.

It is based on the Samsung Exynos4412 SoC (ARM) and it can act as a standalone Linux Computer.

It is compatible with Odroid U2 and Odroid X2 with some Hardware board design differences.


Key features

  • SoC: Samsung Exynos4412@1.7GHz (Cortex A9 Quad)
  • Ram: 2GB LPDDR2(PoP)
  • Video: Mali-400 Quad Core 440MHz and micro HDMI connector
  • Audio: MAX98090 with the analog out on a 3.5mm Jack or digital by HDMI connector
  • LAN: LAN9730HSIC, 10/100Mbps Ethernet with RJ-45 Jack
  • USB: 3xHost, 1xDevice
  • I/O: GPIO, UART, I2C, SPI
  • Storage: micro-SD and eMMC slots
  • Power: 5V / 2A by 2.5mm Jack [1]

Currenty there are two board revisions: 0.2 and 0.5.
Board schematics are available here.


Boot devices

Odroid U3 supports booting from:

  • special slot for eMMC [2]
  • standard microSD slot

How to boot using:

  • eMMC - this is the default boot device - just insert eMMC card into a dedicated slot.
  • microSD - this is an optional boot device - booting only if eMMC card slot is empty.


Info:
The boot priority is determined by the state of a SoC special pins, called OM pins and can be read from proper register.
The state of OM pins can be changed by:

  • eMMC card connection (Odroid U3 only)
    • eMMC slot is connected - eMMC boot (even if SD card is present)
    • eMMC slot is empty - SD card boot
  • the jumper JP2 (Odroid X2).

Note
You cannot write the bootloader on the SD card if you have the eMMC card connected on Odroid U3, however you can do that on the Odroid X2.


Boot sequence

The boot sequence is common for the Samsung Exynos SoC based devices.

The sequence is:

  1. iROM - initializes a basic functionality like a clock, stack, load the BL1
  2. BL1 - initializes DRAM controller, check BL2 integrity and load the BL2 to DRAM
  3. BL2 - initializes board specific peripherals and load the operating system

Note
The iROM bootloader reads the OM pin state to choose the boot device, other bootloaders also can do this.


Bootloader

The U-Boot bootloader for Odroid is provided by the Hardkernel. If your board was delivered with SD/eMMC card, then it probably contains the bootloader and the Linux system. If not, then you can find the Hardkernel's U-Boot binaries here.

The Hardkernel's U-Boot works well, but it is based on the old U-Boot release: v2010.12

For Tizen purposes it is recommended to use U-Boot Tizen - it is based on the latest mainline U-Boot release and therefore is stable.


Tizen requirements

To prepare and download Tizen to the device, some tools are required. For access to the tizen open source code it is recommended to register here.


Hardware

  • PC with Linux Operating System
  • One of the Odroid development boards: U3 or X2
  • MMC card: SD card or eMMC module with preferred size of at least 8GB
  • SD card reader or eMMC module micro SD adapter
  • Odroid USB-UART Module like this
  • 2x Cable: USB type A <=> USB type micro


Software

Depending on what you want to do, you will need some software tools.

  • If you prefer to use precompiled binaries then you can skip this point
  • If you would like to build the source you will need most of the listed software


Git

To download the code of any Tizen.org repository git is required. Instalation manual can be found here.


GBS - Git Build System

This is a Tizen development tool. It can be used e.g. for the automatic build using the Tizen.org source code and the user account.
The build environment is based on the ARM architecture thanks to the qemu package, so you don't need any cross compiler.
The main advantages:

  • the U-Boot binary can be build with a one command
  • the platform binary preparation is done automatically (platform signature, appending the dtbs)

GBS installation, configuration and usage is a topic for the another wiki, so please follow the instructions on this site.


ARM Cross Compiler Toolchain

The target board architecture is ARM. To compile bootloader, system and maybe some more you will need the cross compiler.
One released by Linaro can be found here.


Fastboot Downloader

This application is one of the Android's SDK tool which is used for upgrade the binaries on Hardkernels U-Boot.
More informations can be found here.


Lthor Downloader

This software tool is required for any upgrade using the Tizen bootloader (bootloader, system, user data). You can download it from download.tizen.org. Choose your system version and find the lthor package. Example package for Ubuntu 14.04 64-bit can be found here.
Lthor package is precompiled as a 32-bit binary and it also needs some 32-bit system libraries:

  • ia32-libs-multiarch
  • libarchive12:i386

How to install it on Ubuntu:

sudo apt-get install ia32-libs-multiarch
sudo apt-get install libarchive12:i386
sudo dpkg -i lthor_1.4_amd64.deb

lthor supports only compressed images: .tar or .tar.gz.
Usage: Usage:
On the target side:

Exynos4412 # thor 0 mmc 0

Or in the latest U-Boot Tizen:

Exynos4412 # thor
lthor bootloader.tar system.tar etc...


DFU Firmware Upgrade

This is an optional software tool for advanced users for bootloader and system upgrade. Application site: dfu-util. On the host site you can use the dfu-util application. It is available as a Ubuntu package. So you can install it by:

sudo apt-get install dfu-util

To get the latest available version or compile it for other Linux distribution you can get the source by git:

git clone git://gitorious.org/dfu-util/dfu-util.git

Build configuration requires a package:

  • autoconf
  • libusb-1.0-0-dev

Build steps:

$ ./autogen.sh
$ ./configure 
$ sudo make install

Usage:
On the target side:

Exynos4412 # dfu 0 mmc 0

Or in the latest U-Boot Tizen:

Exynos4412 # dfu

On the host side:
First list the available firmware upgrade options to get the 'alt' number for each:

$ dfu-util -l
Found DFU: [04e8:6601] ver=9999, devnum=60, cfg=1, intf=0, alt=3, name="tzsw", serial="UNKNOWN"
Found DFU: [04e8:6601] ver=9999, devnum=60, cfg=1, intf=0, alt=2, name="bl2", serial="UNKNOWN"
Found DFU: [04e8:6601] ver=9999, devnum=60, cfg=1, intf=0, alt=1, name="bl1", serial="UNKNOWN"
Found DFU: [04e8:6601] ver=9999, devnum=60, cfg=1, intf=0, alt=0, name="u-boot", serial="UNKNOWN"

Chose one upgrade option, eg.'u-boot', alt=0, and download the binary to the target:

$ cd u-boot-tizen
$ dfu-util -a 0 -D u-boot-mmc.bin

Note
This software doesn't check the destination firmware name so it is easy to make a mistake. The preferred way to upgrade the system is the Lthor Downloader.


Prepare a bootable card

According to the boot sequence, the boot image requires the following files from Hardkernels github:

  • bl1.HardKernel
  • bl2.HardKernel
  • tzsw.HardKernel
  • u-boot.bin (will be changed later with the new one)

And the scripts useful for flashing using SD Card Reader:

  • sd_fusing.sh
  • emmc_fastboot_fusing.sh


Boot images layout

Binary name SD (blk) eMMC boot* (blk)
bl1 1 0
bl2 31 30
u-boot-mmc.bin 63 62
tzsw 2111 2110

*Note
The eMMC boot means that all those listed binnaries should be written into special eMMC boot partition which is normally hidden.
Read about eMMC partitions access in the Kernel documentation.


U-Boot Tizen

There are two possibilities to get the u-boot binary: build your own or download a precompiled one.


Build image from the source code

To get the latest U-Boot features before the release you can download the source code and compile it on your own.


Get the latest source

Using your tizen.org account get the latest U-Boot code:

$ git clone ssh://your_id@review.tizen.org:29418/platform/kernel/u-boot.git u-boot-tizen
$ cd u-boot-tizen
$ git checkout -b tizen origin/tizen


Build using the GBS

If you have a preconfigured GBS tool with .gbs.conf file in your home directory - then U-Boot will be build using the special project configuration file:

u-boot-tizen/packaging/u-boot.spec

To build the binary, in the u-boot-tizen directory, type:

$ gbs build --arch=armv7l

If you made some changes in the code, then use proper build option:

$ gbs build --arch=armv7l --include-all

If the first time build fails with some unknown errors, then try the same build command again.
The output of the build can be found in the directory listed at the end of the build log.


Build the Device Tree Compiler

First you need to build the Device Tree Compiler included in U-Boot Tizen tree. But this requires the following packages:

  • flex
  • bison

Quick installation for Ubuntu:

$ sudo apt-get install flex
$ sudo apt-get install bison

DTC build from u-boot-tizen directory:

$ cd ./tools/dtc
$ make install
$ dtc -v  #Check DTC version
Version: DTC 1.4.0-dirty


Build the U-Boot Tizen

Now you can build the U-Boot image using the following commands:

$ CROSS_COMPILE="cross compiler path" make tizen_config
$ CROSS_COMPILE="cross compiler path" make -j 8

The output binary is: u-boot.bin. But it requires some additional work.
First, a multiple dtbs should be appended to it (this is the one of differences with mainline U-Boot):

$ ./tools/mkimage_multidtb.sh u-boot.bin

The script output is: u-boot-multi.bin
And then make a compatible platform signature:

$ ./tools/mkimage_signed.sh u-boot-multi.bin tizen_config

The script output is: u-boot-mmc.bin


Using a precompiled image

The latest U-Boot is not yet released, but you can get the fresh rpm package with it.


Get U-Boot from RPM package

The precompiled image can be found in the build rpm directory . The package name contains build date, eg.: u-boot-2014.07-9.1.armv7l.rpm
The U-Boot of this package should be extracted from rpm:

$ rpm2cpio u-boot-2014.07-9.1.armv7l.rpm | cpio -idmv
./var/tmp/u-boot
./var/tmp/u-boot/params.bin
./var/tmp/u-boot/u-boot-mmc.bin
./var/tmp/u-boot/u-boot.bin
3292 blocks

Note
For the backward compatibility please use the u-boot-mmc.bin file, which has a special platform compatible signature.


How to flash U-Boot

Choose a suitable flash method and then read the first start info. The following upgrade methods on working U-Boot:

  • by Fastboot
  • by Lthor
  • by DFU

requires only the U-Boot binary - u-boot-mmc.bin. The other boot binaries are required only if release needs this or in case of fusing a clean SD/eMMC cards.


by Fastboot

If the U-Boot on your board supports the fastboot protocol, then you can easily upgrade the bootloader.
Get the cable: microUSB <-> USB A and connect the microUSB connector to the target and the second one to your PC.
On the Target U-Boot console:

Exynos4412 # fastboot

On the Host console:

$ cd u-boot-tizen
$ sudo fastboot flash bootloader u-boot-mmc.bin

Then using Ctrl+C on the Target you will go back to the console and then type: "reset".
The U-Boot Tizen will start after the board reset.


by Lthor

If the U-Boot on your board supports the Lthor protocol, eg. current U-Boot Tizen or any private version - then you have an easy way to upgrade it.
Get the cable: microUSB <-> USB A and connect the microUSB connector to the target and the second one to your PC.
On the Target of Tizen old U-Boot console:

Exynos4412 # thor 0 mmc 0

Or if you have the latest U-Boot, then:

Exynos4412 # thor

On the Host console: The Tizen downloader tool requires a compressed images, so you need to use tar:

$ cd u-boot-tizen
$ tar -cf u-boot.tar u-boot-mmc.bin
$ lthor u-boot.tar

After the flash finished board will automatically reset.


by DFU

If the U-Boot on your board supports the DFU protocol, eg. current U-Boot Tizen or any private version - then you have the second easy way to upgrade it.
Get the cable: microUSB <-> USB A and connect the microUSB connector to the target and the second one to your PC.
On the target's console with the old U-Boot:

Exynos4412 # dfu 0 mmc 0

Or if you have the latest U-Boot:

Exynos4412 # dfu

On the Host console: This tool requires a raw binary images, so don't use any compression:

$ cd u-boot-tizen
$ dfu-util -l # To list available upgrade options
Found DFU: [04e8:6601] ver=9999, devnum=63, cfg=1, intf=0, alt=0, name="u-boot", serial="UNKNOWN"
$ dfu-util -R -a 0 -D u-boot-mmc.bin

After the firmware upgrade, the board will automatically reset.


by SD Card Reader

To make a bootable card you will need to get the files listed before.
Please follow this steps:

$ cd u-boot-tizen
$ mv u-boot-mmc.bin u-boot.bin  #The script sd_fusing.sh uses u-boot.bin 
$ mkdir fuse
$ cd fuse
$ wget -q https://github.com/hardkernel/U-Boot/raw/odroid-v2010.12/sd_fuse/bl1.HardKernel
$ wget -q https://github.com/hardkernel/U-Boot/raw/odroid-v2010.12/sd_fuse/bl2.HardKernel
$ wget -q https://github.com/hardkernel/U-Boot/raw/odroid-v2010.12/sd_fuse/tzsw.HardKernel
$ wget -q https://github.com/hardkernel/U-Boot/raw/odroid-v2010.12/sd_fuse/sd_fusing.sh
$ chmod u+x sd_fusing.sh

Please choose the steps suitable for your case (SD or eMMC):


SD Card
  1. Connect the SD Card Reader and insert your card.
  2. Check the mass storage device (/dev/sd*) using 'dmesg | tail' commands.
  3. go into u-boot-tizen/fuse directory
  4. run:
$ sudo ./sd_fusing.sh /dev/sd*

This can take a few minutes so wait for the script to finish. Now you can insert your card into Odroid and turn on the power.
On the console you will see U-Boot prompt with the compilation date in the head.


eMMC Card (microSD adapter)

This case is more complicated since usually most USB SD Card Readers represents the SD Card as a mass storage device.
This is not a problem for SD Card, but can be for an eMMC usage with the special boot partitions described here.

So first insert your eMMC with the microSD adapter and check if your reader supports the eMMC partitions:

$ ls -1 /dev/mmcblk*
/dev/mmcblk0
/dev/mmcblk0boot0
/dev/mmcblk0boot1
/dev/mmcblk0p1
/dev/mmcblk0p2
/dev/mmcblk0p3
/dev/mmcblk0p4
/dev/mmcblk0rpmb
$

And if you see the *boot* in mmc devices it means that your reader supports eMMC partitions.
In the other case you will not see any mmcblkX and you should check your mass storage device (/dev/sd*) using 'dmesg | tail' commands.

  • If you have an mmcblkX in /dev/ directory than:
$ sudo ./sd_fusing.sh /dev/mmcblk0  # Check your mmc dev number

This will take a while. The script will write boot images to eMMC boot partitions.

  • If you have a new sdX in /dev/ directory than it needs some extra work:

First you need a modified 'sd_fusing.sh' script, so do the copy:

cp sd_fusing.sh ums_emmc_fusing.sh

And remove some lines of 'ums_emmc_fusing.sh', so the following lines:

if [ -n "$emmc" ]; then
    signed_bl1_position=0
    bl2_position=30
    uboot_position=62
    tzsw_position=2110
    device=$1boot0
else
    signed_bl1_position=1
    bl2_position=31
    uboot_position=63
    tzsw_position=2111
    device=$1
fi

Should looks like this:

signed_bl1_position=0
bl2_position=30
uboot_position=62
tzsw_position=2110
device=$1

Therefore the script will not check the device type and the positions are valid for the emmc only.

Note
The following method uses Odroid's SD card slot for the first boot and then the U-Boot upgrade is done on an eMMC boot partition using U-Boot features. The destination is to boot U-Boot from eMMC boot partition using eMMC dedicated slot to improve systm performance.


Now carefully follow the steps:

  1. First use this steps for upgrade eMMC as a standard SD Card using the microSD card adapter.
  2. Insert eMMC card with microSD adapter into Odroid SD Card slot.
  3. Power on the board and wait for U-Boot prompt.
  4. Do the first start steps.
  5. Get the cable: microUSB <-> USB A and connect: target(microUSB) <-> PC
  6. Do the fuse using 'ums_emmc_fusing.sh':

On the U-Boot prompt:

Exynos4412 # ums 0 mmc 0.1
UMS: disk start sector: 0x0, count: 0x2000                                      
USB PHY0 Enable

Note
The UMS command exports a media device as a mass storage to your host PC. In this case: the boot partiion number 1 on a mmc number 0. The size is 0x2000 * 512B -> 4MB.


Check the mass storage device (/dev/sd*) using 'dmesg | tail' commands. Example: /dev/sde

On the Host console:

# ./ums_emmc_fusing.sh /dev/sde

Note
This can take few minutes and the target console may look dead - but the write operation is going on.


You can see the following information, on the target console: 'sdhci_send_command: MMC: 0 busy timeout increasing to: 200 ms'. This is not an error and the write operation is going on.

After the script finishes, type the Ctrl+C on the Target console and do the power off:

\  # The UMS prompt
CTRL+C - Operation aborted
Exynos4412 # power off

Now insert the eMMC card into the Odroid eMMC slot. Turn on the board and will see the U-Boot prompt.



U-Boot Tizen - first start

After the first startup, U-Boot environment is usually not set properly.
To fix this, run:

Exynos4412 # env default -a
## Resetting to default environment 
Exynos4412 # saveenv
Writing to MMC(0)... done
Exynos4412 # reset
resetting ... 

Now the U-Boot has a proper setup.


U-Boot Tizen - environment

To boot the kernel, U-Boot should provide a required devices configuration and also the environment setup.
For the latest U-Boot, the default environment can be found in:

u-boot-tizen/configs/tizen.h
u-boot-tizen/configs/tizen-environment.h

The kernel boot operation is done by some U-Boot environment scripts:

  • autoboot - check the board name and available kernel Image type - then choose the boot option:
    • boot_fit - boot a special multi image (can combine multiple: kernels, dtbs, ramdisks, etc. in one binary)
    • boot_zimg - boot a compressed zImage from a proper partition
    • boot_uimg - boot a compressed uImage from a proper partition

Each environment script or variable can be printed by:

Exynos4412 # print $env_name
or
Exynos4412 # print $script_name

To successfully boot with the FIT image or z/uImage without the FDT, the kernel requires the $bootargs to be defined.
You can check the $bootargs setup in one of the environment macros:

Exynos4412 # print $kernel_args
"setenv bootargs root=/dev/mmcblk${mmcrootdev}p${mmcrootpart} rootwait ${console} ${opts}"

As you can see in the above listing - this macro needs additional environment variables:

  • $mmcrootdev - the number of mmc device with the root filesystem
  • $mmcrootpart - the number of $mmcrootdev partition with the root filesystem
  • $console - which defines the stdout for the kernel: e.g. console=ttySAC1,115200n8
  • $opts - optional setup for the system - default is unset


U-Boot Tizen - troubleshoting

Supported devices

The latest U-Boot Tizen binary supports the following boards:

  • Trats2
  • Odroid U3
  • Odroid X2

That means that the one binary can be upgraded onto those devices. The board type is recognized by U-Boot and the environment setup is done on each boot.
Note
If you want to use the one binary for a multiple devices, then make sure that the binary supports this feature. This was introduced with the 'tizen_config'.


Reset the U-Boot environment

To reset U-Boot environment:

Exynos4412 # env default -a
Exynos4412 # saveenv
Exynos4412 # reset

Each time you do the environment reset and save - you should also reset the board.
This is because some environment variables are set automatically on boot.


Platform setup feature

Latest U-Boot introduces new platform setup feature, which supports number of N environment platform setups for each platform (currently Trats/Odroid).
Each setup provides environment variables:

  • ${platname}_setup_N_name
  • ${platname}_setup_N_partitions - undefined if MBR
  • ${platname}_setup_N_alt_system
  • ${platname}_setup_N_bootpart
  • ${platname}_setup_N_rootpart


Available platform setups

You can list available setup names by:

Exynos4412 # print ${platname}_setup_1_name
odroid_setup_1_name=Tizen v2.x
Exynos4412 # print ${platname}_setup_2_name
odroid_setup_2_name=Tizen v3.0
Exynos4412 # print ${platname}_setup_N_name
[...]


Add custom platform setup

You can add your custom platform setup by define above environment variables and after update those:
Platform setup info:

  • ${platname}_setup_cnt - the number of configs for board
  • ${platname}_setup_chosen - the number of chosen board config
  • ${platname}_setup_active - the number of active board config (autoset)

It is good to add this by upgrade params.bin file - will prevent by losing your settings after env reset.


Switch platform setup

Active platform setup depends on two variables

  • ${platname}_setup_chosen - chosen board config, e.g. by setenv [..]
  • ${platname}_setup_active - active board config - is set automatically, please don't modify it manually.

On every boot:

  • ${platname} is set for your board, e.g. trats or odroid
  • a condition is checked: ${platname}_setup_active == ${platname}_setup_chosen ??
    • if true, then nothing is to do
    • if false, then dfu settings and partition layout will be updated to chosen setup

To activate any setup you need to set ${platname}_setup_chosen environment variable with few steps:

  • check platform name
Exynos4412 # print platname
platname=odroid
Exynos4412 #
  • check required setup number for your platform, e.g. 1 and make it as chosen
Exynos4412 # print ${platname}_setup_1_name
odroid_setup_1_name=Tizen v2.x
Exynos4412 # setenv ${platname}_setup_chosen 1
Exynos4412 # saveenv; reset

After rebooot you will see an info about activated platform setup.

[...]
Board PMIC init
MMC:   SAMSUNG SDHCI: 0, EXYNOS DWMMC: 1
Setup:[1] Tizen v2.x for odroid (active)
DFU alt info setting: done
[...]

It means, that basic environment:

  • ${partitions}
  • ${dfu_alt_info}
  • ${mmcbootpart}
  • ${mmcrootpart}

are equal to active setup data. Latest U-Boot supports Tizen 2.2.1 and Tizen 3.0 setups, and you can switch between them before system upgrade. Default is Tizen 3.0 setup.

Note
If you change the chosen setup, then U-Boot will try to update the partiion table - if ${partitions} defined.
Do it carefully, because you can lost your data if the new partition table is different.


Lthor and DFU target setup

Those upgrade tools require one U-Boot environment variable:

  • $dfu_alt_info - this includes the device firmware on flash placement description

In the latest U-Boot version it is set automatically on boot.


Upgrade by thor fails

Then go to the U-Boot prompt to check the environment:

Exynos4412 # print dfu_alt_info
dfu_alt_info=Please reset the board.

If you see the above information - then reset the board and after the boot, check this setup.


Using the UMS

The UMS feature should be used by advanced users. Any operations on the MMC device using the ums can overwrite the bootloader or system data and make the board unbootable. Make sure that you know what are you using this for.

USB Mass Storage a useful feature. By this feature, user can export a storage device (eMMC, SD) as a mass storage using the USB device port (microUSB on the Odroid). It can be used for:

  • upgrade
  • device backup image
  • file operations on the device partitions (read/write)

UMS usage:
First, get the cable: microUSB <-> USB A and connect the microUSB connector to the target and the second one to your PC.
Then, check the available mmc devices on the target:

Exynos4412 # mmc list
EXYNOS DWMMC: 0		# Device MMC 0 uses DWMMC driver
 SAMSUNG SDHCI: 1	# Device MMC 1 uses SDHCI driver

The MMC registered as a 'mmc 0' is always the booting device.
Next, choose one of the mmc devices and run the ums:

Exynos4412 # ums 0 mmc 0
UMS: disk start sector: 0x0, count: 0x1d5a000                                    
USB PHY0 Enable

And on the target console you will see an info about the start sector and the sector count. This mode can be finished by the Ctrl+C keys.
Before you finish this mode be sure that data is physically written after the data transfer.
To flush the host filesystem buffers, run:

$ sync

If you have the eMMC card, you can also export the eMMC boot partitions:

Exynos4412 # ums 0 mmc 0.1
UMS: disk start sector: 0x0, count: 0x2000                                    
USB PHY0 Enable

So as you can see, the block count of the eMMC boot partition is 0x2000 blks - 4MB. This is the bootloader images physical partition.

On your host PC:
After starting the ums command you can find the UMS device using 'dmesg | tail' commands combination. Example:

$ dmesg | tail
[185542.963690] usb-storage 2-1.5.1:1.0: USB Mass Storage device detected
[185542.963824] scsi35 : usb-storage 2-1.5.1:1.0
[185543.963665] scsi 35:0:0:0: Direct-Access     Linux    UMS disk         ffff PQ: 0 ANSI: 2
[185543.964503] sd 35:0:0:0: [sde] 8192 512-byte logical blocks: (4.19 MB/4.00 MiB)
[185543.964658] sd 35:0:0:0: Attached scsi generic sg5 type 0
[185543.964856] sd 35:0:0:0: [sde] Write Protect is off
[185543.964859] sd 35:0:0:0: [sde] Mode Sense: 0f 00 00 00
[185543.965238] sd 35:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[185543.970788]  sde: unknown partition table
[185543.972513] sd 35:0:0:0: [sde] Attached SCSI disk
$

So in this example: '/dev/sde' is the UMS device. Now you can upgrade the bootloader, but remember about the eMMC binary block offsets.
If you export the SD card or eMMC user partition (ums 0 mmc 0), then the card's partitions can be mounted (automatically in the Ubuntu).

Error Report
Undefined platname
Get device error
Version and Part are mismatch
  • For Tizen 3.x

1. If you see the following error messages:

ERROR: Couldn't find part #4 on mmc device #0

Change your ${odroid_setup_chosen} u-boot environment.

- U-Boot prompt

Exynos4412 # setenv odroid_setup_chosen 2
Exynos4412 # saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
Exynos4412 # reset
resetting ...

Retry thor download

Exynos4412 # thor


2. If you see the following error messages:

ERROR: Couldn't find part #5 on mmc device #0

You must setup a proper partiion table for Tizen 3.0

- U-Boot prompt

Exynos4412 # ums 0 mmc 0

- Your PC console

$ sudo ./mkpart.sh /dev/sdX	#X is your device number

Retry thor download

Exynos4412 # thor


  • For Tizen 2.x

1. If you see the following error messages:

ERROR: Couldn't find part #5 on mmc device #0

Change your ${odroid_setup_chosen} u-boot environment.

- U-Boot prompt

Exynos4412 # setenv odroid_setup_chosen 1
Exynos4412 # saveenv
Saving Environment to MMC...
Writing to MMC(0)... done
Exynos4412 # reset
resetting ...

Retry thor download

Exynos4412 # thor


2. If you see the following error messages:

ERROR: Couldn't find part #4 on mmc device #0

You must setup a proper partiion table for Tizen 2.x

- U-Boot prompt

Exynos4412 # ums 0 mmc 0

- Your PC console

$ sudo ./mkpart.sh /dev/sdX	#X is your device number

Retry thor download

Exynos4412 # thor
Unknown Version

Prepare the system

To get a working system you need to make a few steps:

  • check chosen platform setup(info)
  • device partitioning
  • get or compile the kernel
  • get or compile the system

Tizen Partitions layout

Before the device partitioning you must setup a proper partiion table on it.
Partition tables used in Tizen releases:

  • GPT - Trats2
  • MBR MSDOS - Odroid

Note
Odroid uses a different partition table, because it supports the SD Card boot. SD Card specification doesn't provide the special hidden boot partitions, and the bootloader for Odroid is stored on its second physical block. This doesn't allow use of GPT since it uses first two physical blocks: 0 and 1. The MBR uses only first block.

Tizen Partitions Layout for tizen 3.0
Partition Name Offset (MB) Size (MB) Thor image name DFU image name
1 boot 4 64 boot.tar boot.img
2 rootfs - 3072 tizen-common-{flavour}.tar.gz rootfs.img
3 system-data - 512 tizen-common-{flavour}.tar.gz system-data.img
4 user - - tizen-common-{flavour}.tar.gz user.img
5 module - 20 boot.tar modules.img


Tizen Partitions Layout for tizen 2.2.1
Partition Name Offset (MB) Size (MB) Thor image name DFU image name
1 boot 2 128 boot.tar boot.img
2 platform - 2048 platform.tar platform.img
3 data - 3072 data.tar data.img
4 ums - - ums.tar ums.img

Tizen device partitioning

If you have a problem with the device partitioning, then follow this guide.
You can put the card into the reader or you can use the U-Boot UMS feature to export the mmc card space:

  1. Go to U-Boot prompt
  2. Run USB Mass Storage by:
Exynos4412 # ums 0 mmc 0	#Export the device mmc 0

And next on your PC console. Save this listing into file 'mkpart.sh':

For Tizen 3.0
#!/bin/bash

DISK=$1
SIZE=`sfdisk -s $DISK`
SIZE_MB=$((SIZE >> 10))

BOOT_SZ=64
ROOTFS_SZ=3072
DATA_SZ=512
MODULE_SZ=22

let "USER_SZ = $SIZE_MB - $BOOT_SZ - $ROOTFS_SZ - $DATA_SZ - $MODULE_SZ - 4"

BOOT=boot
ROOTFS=rootfs
SYSTEMDATA=system-data
USER=user
MODULE=module

if [[ $USER_SZ -le 100 ]]
then
	echo "We recommend to use more than 4GB disk"
	exit 0
fi

echo "========================================"
echo "Label          dev           size"
echo "========================================"
echo $BOOT"		" $DISK"1  	" $BOOT_SZ "MB"
echo $ROOTFS"		" $DISK"2  	" $ROOTFS_SZ "MB"
echo $SYSTEMDATA"	" $DISK"3  	" $DATA_SZ "MB"
echo "[Extend]""	" $DISK"4"
echo " "$USER"		" $DISK"5  	" $USER_SZ "MB"
echo " "$MODULE"		" $DISK"6  	" $MODULE_SZ "MB"


MOUNT_LIST=`mount | grep $DISK | awk '{print $1}'`
for mnt in $MOUNT_LIST
do
	umount $mnt
done

echo "Remove partition table..."                                                
dd if=/dev/zero of=$DISK bs=512 count=1 conv=notrunc

sfdisk --unit M $DISK <<-__EOF__
4,$BOOT_SZ,0xE,*
,$ROOTFS_SZ,,-
,$DATA_SZ,,-
,,E,-
,$USER_SZ,,-
,$MODULE_SZ,,-
__EOF__

mkfs.vfat -F 16 ${DISK}1 -n $BOOT
mkfs.ext4 -q ${DISK}2 -L $ROOTFS -F
mkfs.ext4 -q ${DISK}3 -L $SYSTEMDATA -F
mkfs.ext4 -q ${DISK}5 -L $USER -F
mkfs.ext4 -q ${DISK}6 -L $MODULE -F
For Tizen 2.x
#!/bin/bash

DISK=$1
SIZE=`sfdisk -s $DISK`
SIZE_MB=$((SIZE >> 10))

BOOT_SZ=128
PLATFORM_SZ=2048
DATA_SZ=3072
let "UMS_SZ = $SIZE_MB - $BOOT_SZ - $PLATFORM_SZ - $DATA_SZ - 4"

BOOT=boot
PLATFORM=platform
DATA=data
UMS=ums

if [[ $UMS_SZ -le 100 ]]
then
	echo "We recommend to use more than 4GB disk"
	exit 0
fi

echo "Label        dev           size"
echo $BOOT"      " $DISK"1  	" $BOOT_SZ "MB"
echo $PLATFORM"  " $DISK"2  	" $PLATFORM_SZ "MB"
echo $DATA"      " $DISK"3  	" $DATA_SZ "MB"
echo $UMS"       " $DISK"4  	" $UMS_SZ "MB"

MOUNT_LIST=`mount | grep $DISK | awk '{print $1}'`
for mnt in $MOUNT_LIST
do
	umount $mnt
done

echo "Remove partition table..."                                                
dd if=/dev/zero of=$DISK bs=512 count=1 conv=notrunc 

sfdisk --in-order --Linux --unit M $DISK <<-__EOF__
4,$BOOT_SZ,0xE,*
,$PLATFORM_SZ,,-
,$DATA_SZ,,-
,,,-
__EOF__

mkfs.vfat -F 16 ${DISK}1 -n $BOOT
mkfs.ext4 -q ${DISK}2 -L $PLATFORM -F
mkfs.ext4 -q ${DISK}3 -L $DATA -F
mkfs.ext4 -q ${DISK}4 -L $UMS -F


$ Make the file executable:

$ chmod u+x mkpart.sh

Find the UMS device using 'dmesg | tail' commands combination. Then run the script for the UMS exported device:

$ sudo ./mkpart.sh /dev/sdX	#X is your device number

The script list the partitions but for sure you can check them by:

$ sudo fdisk -l /dev/sdX	# X is your device number

Next on the target console make a combination of 'Ctrl+C' keys and the device is now ready for system upgrade.

Getting the kernel

There are two possibilities to get the kernel binary: build your own or download the precompiled one.

Build image from the source code

To get the latest kernel features before the release you can download the source code and compile it on your own.

Get the latest source

Using your tizen.org account get the latest kernel code:

$ git clone ssh://your_id@review.tizen.org:29418/platform/kernel/linux-3.10.git kernel-tizen
$ cd kernel-tizen
$ git checkout -b tizen origin/tizen
Build the Kernel Tizen

Now you can build the kernel image using the following commands:

$ cd kernel-tizen
$ export CROSS_COMPILE="cross compiler path" ARCH="arm"
$ make tizen_odroid_defconfig
$ make -j 8 zImage
$ make exynos4412-odroidu3.dtb
$ tar cfv kernel.tar -C arch/arm/boot zImage
$ tar rfv kernel.tar -C arch/arm/boot/dts exynos4412-odroidu3.dtb
Using a precompiled image

The latest kernel is not yet released. After the release, this section will be updated.

How to flash the kernel

The preferred way to upgrade the kernel is Lthor downloader. So please follow the steps: Get the cable: microUSB <-> USB A and connect the microUSB connector to the target and the second one to your PC.
On the target side:

Exynos4412 # thor 0 mmc 0

Or in the latest U-Boot Tizen:

Exynos4412 # thor

On the host side:

lthor kernel.tar

After the upgrade finishes, the board reset will occure.

Getting the system

Caution: This guide is not official. We'll notice a official image guide how to make the image based on Tizen:Common profile soon.
Various system releases can depend on more then one system image. Sometimes you need first download some old full release and then do the upgrade with the new one - which is not a full system image.

To get some more info about the Tizen System Common profile please continue with this wiki.

Changing the mount options (For Tizen 2.x)

If you use a precompiled platform image for other devices, you should modify the mount and SDB options.

First, mount 'platform.img' to any directory of your host computer.
Then, move to the mounted directory.

Change the mount option

1. Remove the unnessary mount service from the systemd services

  • Path : MOUNT_DIRECTORY/usr/lib/systemd/system/local-fs.target.wants
  • Delete the "csa.mount" file


2. Change the mount device node name in the systemd services

Example : boot.mount service

# Automatically generated by mount-generator.pl

[Unit]
# FIXME: Is this required?
#SourcePath=/home/abuild/rpmbuild/BUILD/system-plugin-slp-0.0.1/etc/fstab
DefaultDependencies=no
Before=local-fs.target
Requires=fsck@dev-mmcblk0p2.service
After=local-fs-pre.target fsck@dev-mmcblk0p2.service resize2fs@dev-mmcblk0p2.service
Wants=resize2fs@dev-mmcblk0p2.service

[Mount]
What=/dev/mmcblk0p2
Where=/boot
Type=ext4
Options=defaults
  • Path : MOUNT_DIRECTORY/usr/lib/systemd/system/local-fs.target.wants
  • Change boot partition
    • in "boot.mount" : /dev/mmcblk0p2 -> /dev/mmcblk0p1
  • Change root partition
    • in "-.mount" : /dev/mmcblk0p5 -> /dev/mmcblk0p2
  • Change data partition
    • in "opt.mount" : /dev/mmcblk0p6 -> /dev/mmcblk0p3
  • Change ums partition
    • in "opt-usr.mount" : /dev/mmcblk0p7 -> /dev/mmcblk0p4


3. Edit fstab
Remove all the options in fstab

  • Path : MOUNT_DIRECTORY/etc/fstab
  • comment out all options in fstab
Enable SDB(Samsung Debug Bridge)

Need to change the settings for the USB host device of SDB due to the difference in the USB host of Odroid U3

1. Create a script to change usb hose device

  • Path : /bin/pre-sdbd.sh
#!/bin/bash
echo sdb > /sys/class/usb_mode/usb0/funcs_fconf
echo 1 > /sys/class/usb_mode/usb0/enable
sdbd

Add the execution permission

chmod +x pre-sdbd.sh

2. Modify SDBD service in systemd

  • Path : /usr/lib/systemd/system/sdbd.service
[Unit]
Description=sdbd
After=default.target
[Service]
Type=forking
Environment=DISPLAY=:0
PIDFile=/tmp/.sdbd.pid
RemainAfterExit=yes
ExecStartPre=/bin/bash /bin/pre-sdbd.sh   <- Add this line
ExecStart=/usr/sbin/sdbd
[Install]
WantedBy=multi-user.target

3. Activate SDBD Service

  • Path : /usr/lib/system/systemd/system/sdbd.service
  • Make symbolic link of sdbd.service on "/usr/lib/system/systemd/system/multi-user.target.wants/sdbd.service"

Upgrade the system

The system upgrade is easy. Make sure that all partition images are compressed with tar, so in your images directory you should have:

  • boot.tar or boot.tar.gz
  • platform.tar or platform.tar.gz
  • data.tar or data.tar.gz
  • ums.tar or ums.tar.gz

And next, get the cable: microUSB <-> USB A and connect the microUSB connector to the target and the second one to your PC.
On the target console run:

Exynos4412 # thor 0 mmc 0

or for the latest U-Boot Tizen:

Exynos4412 # thor

Next on your host PC, in the compressed images directory, run:

$ lthor boot.tar platform.tar data.tar ums.tar

After the finish board will automatically reboot and the system should boot.

Run the system

Connection with Odroid-U3

You can use UART or SDB for connecting with Tizen-ported Odroid-U3


UART Connection

  • Login ID  : Tizen
************************************************************
*                      TIZEN PLATFORM                      *
************************************************************

localhost login: root
-sh-4.1#

SDB Connection

~$ sdb shell
sh-4.1$ 

Problems

Some system configurations should be changed according to Odroid-U3 hardware platform.
In the current situation, the following problems will arise.

  • Entering the sleep state
  • No display output
  • Touch input coordinate error (When Odroid VU is used)
  • No hardware key (home/back)
  • WiFi not working
  • Bluetooth WiFi not working
  • Low battery error
  • No sound output
  • 3D acceleration
  • Notification bar rotation problem


Platform troubleshooting

You can refer this page(Embedded Software Lab of SKKU) to get additional information or files related to porting.

Entering the sleep state

If there is no input for a certain period of time, the device enters the sleep state

PM: Syncing filesystems ... done.
Freezing user space processes ... (elspsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
  • Cannot use sdb, UART in the sleep state


Modify the power manager service
We can modify the power manager service to prevent entering the sleep state

1. Download the power manager service from tizen git

git clone https://review.tizen.org/gerrit/platform/core/system/power-manager

2. Edit the power state table in pm_core.c

static int trans_table[S_END][EVENT_END] = {
	/* Timeout , Input */
	{S_START, S_START},	/* S_START */
	{S_LCDDIM, S_NORMAL},	/* S_NORMAL */
	{S_LCDOFF, S_NORMAL},	/* S_LCDDIM */
#ifdef TIZEN_EMUL
	{S_LCDOFF, S_NORMAL},	/* S_LCDOFF */
#else
	{S_LCDOFF, S_NORMAL},	/* S_LCDOFF */
	//Original code : //{S_SLEEP, S_NORMAL},	/* S_SLEEP */
#endif
	{S_LCDOFF, S_NORMAL},	/* S_SLEEP, When wake up by devices, go lcd_off state  */
};

3. Build with GBS

4. Install rpm package

  • Package path : /home/USER_NAME/GBS-ROOT/local/repos/tizen2.2/arm7l/RPMS
  • Package name : power-manager-VERSION.armv7l.rpm

Package copy

sdb root on
sdb push ./power-manager-VERSION.armv7l.rpm /home

Package install

sdb shell
rpm -Uvh --force --nodeps /home/power-manager-VERSION.armv7l.rpm

Package check

sdb shell
rpm -qa | grep "power-manager"

No display output

Device Dependent X (DDX) problem

  • The default DDX connection in Tizen is LCD(LVDS)
  • No LCD(LVDS connection) in Odroid-U3, Use HDMI output device

Modify DDX

1. Download exynos ddx (exynos_drv.so)

git clone git://git.tizen.org/platform/adaptation/samsung_exynos/xf86-video-exynos

2. Modify init code

Modify the code to set the HDMI device as main output device

  • Code : sec_display.c
  • Function : static int _secSetMainMode (ScrnInfoPtr pScrn, SECModePtr pSecMode)

Original Code

 for (i = 0; i < pXf86CrtcConfig->num_output; i++)
    {
        xf86OutputPtr pOutput = pXf86CrtcConfig->output[i];
        SECOutputPrivPtr pOutputPriv = pOutput->driver_private;
        if (!pOutputPriv)
            continue;
	
        if (pOutputPriv->mode_output->connector_type == DRM_MODE_CONNECTOR_LVDS ||
            pOutputPriv->mode_output->connector_type == DRM_MODE_CONNECTOR_Unknown)
        {
            memcpy (&pSecMode->main_lcd_mode, pOutputPriv->mode_output->modes, sizeof(drmModeModeInfo));
            return 1;
        }
    }

Modified code

 for (i = 0; i < pXf86CrtcConfig->num_output; i++)
    {
        xf86OutputPtr pOutput = pXf86CrtcConfig->output[i];
        SECOutputPrivPtr pOutputPriv = pOutput->driver_private;
        if (!pOutputPriv)
            continue;
	
        if (pOutputPriv->mode_output->connector_type == DRM_MODE_CONNECTOR_LVDS ||
            pOutputPriv->mode_output->connector_type == DRM_MODE_CONNECTOR_Unknown)
        {
            memcpy (&pSecMode->main_lcd_mode, pOutputPriv->mode_output->modes, sizeof(drmModeModeInfo));
            return 1;
        }
	else  if (pOutputPriv->mode_output->connector_type == DRM_MODE_CONNECTOR_HDMIA)
	{
            memcpy (&pSecMode->main_lcd_mode, pOutputPriv->mode_output->modes, sizeof(drmModeModeInfo));
            return 1;
        }

    }

3. Build & Install

Copy "exynos_drv.so" to Odroid

sdb root on
sdb push ./exynos_drv.so /usr/lib/xorg/modules/drivers/

4. Reboot system



Also you can download the file from here

Touch input coordinate error (When Odroid VU is used)

When Odroid Vu is used, there is a touch coordinate error

Can use the touch calibration function of Xorg

  • Path : /etc/X11/xorg.conf.d/input.conf
  • Add calibaration option to InputClass
Section "InputClass"
	Identifier "evdev touchscreen catchall"
	MatchIsTouchScreen "on"
	MatchDevicePath "/dev/input/event*"
	Driver "evdevmultitouch“
	Option "MultiTouch"     "10"
	Option "Calibration" 	"-1 1282 -4 888” 
EndSection


If the touch calibration does not work well, use xinput_calibrator to calculate calibartion values

No hardware key (home/back)

Tizen mobile needs hardware keys such as home/back buttons.
Odroid-U3 has no hardware key. Can’t go home screen, can’t back to the previous screen.
Use USB-connected Keyboard. Keyboard key mappings are required.

Modify Xmodmap file

  • Path : /etc/X11/Xmodmap
keycode 67 = XF86AudioRaiseVolume
keycode 68 = XF86AudioLowerVolume
keycode 69 = Cancel
keycode 70 = XF86Send
keycode 71 = XF86Phone
keycode 72 = XF86Stop
keycode 155 = XF86Send
keycode 156 = XF86Phone
keycode 157 = XF86Stop
keycode 73 = XF86Search
keycode 124 = XF86PowerOff
keycode 179 = XF86WebCam
keycode 220 = XF86Pictures
keycode 208 = XF86AudioPlay
keycode 209 = XF86AudioPause
keycode 174 = XF86AudioStop
keycode 171 = XF86AudioNext
keycode 173 = XF86AudioPrev
keycode 176 = XF86AudioRewind
keycode 216 = XF86AudioForward
keycode 234 = XF86AudioMedia
keycode 153 =
keycode 239 =
keycode 136 =
keycode 140 =
keycode 182 =
keycode 172 =
keycode 215 =

As a result, F1 ~ F5 keys are mapped to the following functions.

Keycode 67 = F1 key = Volume Up
Keycode 68 = F2 key = Volume Down
Keycode 69 = F3 key = Cancel
Keycode 70 = F4 key = Menu
Keycode 71 = F5 key = Home key

WiFi not working

To enable USB WiFi module, add the WiFi firmware and modify the WiFi shell script.

1. Firmware

Download and copy the WiFi firmware for your WiFi USB dongle (e.g., rtl8192)

  • Path : /lib/modules/firmware/YOUR_WIFI_FIRMWARE

Download : | RTL8192 Firmware

2. Script Create the shell script for WiFi on/off

  • Path : /usr/bin/wlan.sh
#!/bin/sh
IFACE_NAME=wlan0
start()
{
	/sbin/ifconfig ${IFACE_NAME} up
}

stop()
{
	/sbin/ifconfig ${IFACE_NAME} down
}

case $1 in
"start")
start
;;
"stop")
stop
;;
*)
/bin/echo wlan.sh [start] [stop]
exit 1
;;
esac

If you want to use hotspot and WiDi functions additionally, you should modify the script.

Bluetooth not working

Four scripts are required to use the Bluetooth

  • Path : /usr/etc/bluetooth/

* bt-stack-up.sh

#!/bin/sh

#
# Script for executing Bluetooth stack
#

# Register BT Device

# Set BT address: This will internally check for the file presence
/usr/bin/setbd

# Activate BT Device
rfkill unblock bluetooth
/usr/sbin/hciconfig hci0 up

# dbus path setting
export DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/app/dbus/user_bus_socket

# Execute BlueZ BT stack
/usr/sbin/bluetoothd -d
/usr/bin/bluetooth-share &

exit 0


* bt-stack-down.sh

#!/bin/sh

#
# Script for stopping Bluetooth stack
#

# Remove BT device
/usr/sbin/hciconfig hci0 down
rfkill block bluetooth

# Kill BlueZ bluetooth stack
killall obexd obex-client
killall bt-syspopup
killall bluetooth-share
killall bluetooth-pb-agent
killall bluetooth-map-agent
killall bluetooth-hfp-agent
killall bluetoothd

# result
exit 0


* bt-reset-env.sh

#!/bin/sh

# BT Stack and device stop
/usr/sbin/hciconfig hci0 down
rfkill block bluetooth


# Remove BT files and setting
rm -rf /opt/data/bluetooth/.bt_paired
rm -rf /var/lib/bluetooth/*

# Initialize BT vconf values
vconftool set -tf int db/bluetooth/status "0" -g 6520
vconftool set -tf int file/private/bt-service/flight_mode_deactivated "0" -g 6520 -i
vconftool set -tf string memory/bluetooth/sco_headset_name "" -g 6520 -i
vconftool set -tf int memory/bluetooth/device "0" -g 6520 -i
vconftool set -tf int memory/bluetooth/btsco "0" -g 6520 -i
vconftool set -tf int file/private/libug-setting-bluetooth-efl/visibility_time "0" -g 6520
vconftool set -tf bool memory/private/bluetooth-share/quickpanel_clear_btn_status FALSE -g 6520 -i
vconftool set -tf bool memory/private/bluetooth-share/opp_server_init FALSE -g 6520 -i

# Remove BT shared memory
list=`ipcs -m | awk '$1==0x0001000 {print $2}'`
for i in $list
do
	ipcrm -m $i
done
ipcs -m | grep "0x00001000" | awk '{ print $2 }'


* bt-set-addr.sh

#!/bin/sh

#
# Script for setting Bluetooth Address
#

#if [ -e /csa/bluetooth/.bd_addr ]
#then
#       echo "Already .bd_addr exists"
#       exit 0
#fi

/usr/bin/setbd

echo "Set BT address successes"

Low battery error

Some apps cannot be launched under low battery.
Since there is no battery in Odroid-U3, the system cannot get the battery info, and the current battery capacity will be "-1".

Modify OAL(OEM Adaptation Layer)
There are several functions related to the battery capacity.

int	(*OEM_sys_get_battery_capacity) (int *value);
int	(*OEM_sys_get_battery_capacity_raw) (int *value);
int	(*OEM_sys_get_battery_charge_full) (int *value);
int	(*OEM_sys_get_battery_charge_now) (int *value);
int	(*OEM_sys_get_battery_present) (int *value);
int	(*OEM_sys_get_battery_health) (int *value);
int	(*OEM_sys_get_battery_polling_required) (int *value);

1. Download "device-manager-plugin-exynos"

git clone https://review.tizen.org/gerrit/adaptation/ap_samsung/device-manager-plugin-exynos

2. Modify the code Code : device_manager_plugin_exynos.c

Add the below functions

int OEM_sys_get_battery_capacity(int *value){
	*value = 100;
	return 0;
}
int OEM_sys_get_battery_capacity_raw(int *value)
{
	int ret;

	*value = 10000;
	return 0;
}

3. Build & Install

No sound output

Need to change the output device of pulse audio

1. Check sound device

aplay -l

**** List of PLAYBACK Hardware Devices ****
card 0: OdroidU3 [Odroid-U3], device 0: MAX98090 PCM HiFi-0 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0
card 0: OdroidU3 [Odroid-U3], device 1: MAX98090 PCM SEC HiFi-1 []
  Subdevices: 1/1
  Subdevice #0: subdevice #0


2. Change the output device

  • Path : /etc/pulse/system.pa

Default configuration : output device = hw:0, 2

load-module module-alsa-sink sink_name=alsa_output.0.analog-stereo device=hw:0,2

Modify the configuration : output device = hw:0, 1

load-module module-alsa-sink sink_name=alsa_output.0.analog-stereo device=hw:0,1

3D acceleration

After Tizen booting, we will see the following warning message about OpenGL support.

"Your screen does not support OpenGL. Failing back to software engine."

To enable 3D hardware acceleration and OpenGL on Tizen 2.x, install the MALI DDK package.

The existing MALI DDK is r3p0 (Tizen Kernel 3.0) version.

You need the Mali DDK r3p2 driver for Tizen Linux kernel 3.10.

  • libump-mali-400.rpm (Unified Memory Provider Library)
  • libtbm-exynos4412.rpm (Tizen Buffer Manager Library)
  • gpu-ddk-mali-400.rpm (X11 Driver Development Kit)
  1. Download MALI Tizen DDK r3p2 archive from this site.
  2. Extract the archive.
  3. Go to the folder containing DDK files, experiment/odroid-u3+linux3.10+tizen2.2.1.
  4. Enter below commands.
[in host ubuntu PC] 
$ sdb -d push libtbm-*.rpm /home/
$ sdb -d push opengl-es-*.rpm /home/
$ sdb root on
$ sdb -d shell

[in odroid-u3 target]
# cd /home/
# rpm -e --nodeps opengl-es-virtual-drv
# rpm -Uvh --nodeps --force *.rpm
# sync
# reboot

For more details, refer to Enable 3D Acceleration on Tizen.

Notification Bar Problem

In the quick panel operation, there is a rotation problem.
Need to modify the quickpanel application.

1. download the code

git clone https://review.tizen.org/gerrit/apps/home/quickpanel

2. Modify the code

  • Code : ./quickpanel/daemon/quickpanel-ui.c
  • Function : static int _quickpanel_ui_create_win(void *data)
initial_angle = _quickpanel_ui_rotation_get_angle(ad);
_quickpanel_ui_rotation(ad, initial_angle);

Remove the initialization codes that are hardcoded for the Rotation angle

3. Build & Install