coding » embarcado

avoid kernel messages at boottime

Tiago Maluta — Wed, 13 Apr 2011 03:17:49 +0000

Linux embedded normally don’t behave as the same in desktop system, maybe instead login at your device you need only run a specific application – for example – by just modifying an start script. Although easily… one requisite that I faced these days was avoid boot messages from kernel, accomplished by changing kernel parameters:

setenv bootargs ‘console=none root=/dev/mmcblk0pX rootwait init=/sbin/init’

But this parameter broke the output of my start code (a shell script) located on /etc/rc.d/…

Checking for solutions I go back to getty and added two parameters “-l” and “-n” to specify your program (or script) and prompt for nologin.

$ cat /etc/inittab

::sysinit:/etc/rc.d/rcS
::respawn:/sbin/getty -L ttymxc0 115200 vt100 -l /path/to/your/program -n
::ctrlaltdel:/sbin/reboot
::shutdown:/etc/rc.d/rcS stop
::restart:/sbin/init

Now I can see the serial output without kernel boot messages.

re-generating ubi

Tiago Maluta — Tue, 11 Jan 2011 18:33:07 +0000

If you need re-generate an UBIFS and don’t know the right parameters you can inspect dmesg output to filter UBI parameters.

If you need know the steps to creante an UBI/UBIFS check the official documentation or my ubifs tag on del.icio.us.

using ubi on u-boot: compiling issues

Tiago Maluta — Fri, 19 Nov 2010 18:24:18 +0000

if you are adding support to ubifs on u-boot, you must add some include/configs/.h

#define CONFIG_CMD_UBI
#define CONFIG_CMD_UBIFS
#define CONFIG_RBTREE
#define CONFIG_LZO

to avoid errors like:

/uboot-imx/fs/ubifs/tnc.c:105: undefined reference to `rb_insert_color’
fs/ubifs/libubifs.a(orphan.o): In function `insert_dead_orphan’:
/uboot-imx/fs/ubifs/orphan.c:129: undefined reference to `rb_insert_color’
fs/ubifs/libubifs.a(recovery.o): In function `add_ino’:
/uboot-imx/fs/ubifs/recovery.c:1050: undefined reference to `rb_insert_color’
fs/ubifs/libubifs.a(recovery.o): In function `remove_ino’:
/uboot-imx/fs/ubifs/recovery.c:1088: undefined reference to `rb_erase’
fs/ubifs/libubifs.a(recovery.o): In function `ubifs_recover_size’:
/uboot-imx/fs/ubifs/recovery.c:1171: undefined reference to `rb_first’
/uboot-imx/fs/ubifs/recovery.c:1214: undefined reference to `rb_next’
/uboot-imx/fs/ubifs/recovery.c:1220: undefined reference to `rb_next’
/uboot-imx/fs/ubifs/recovery.c:1221: undefined reference to `rb_erase’
fs/ubifs/libubifs.a(replay.o): In function `insert_node’:
/uboot-imx/fs/ubifs/replay.c:373: undefined reference to `rb_insert_color’
fs/ubifs/libubifs.a(replay.o): In function `insert_dent’:
/uboot-imx/fs/ubifs/replay.c:448: undefined reference to `rb_insert_color’
fs/ubifs/libubifs.a(replay.o): In function `insert_ref_node’:
/uboot-imx/fs/ubifs/replay.c:689: undefined reference to `rb_insert_color’
fs/ubifs/libubifs.a(replay.o): In function `apply_replay_tree’:
/uboot-imx/fs/ubifs/replay.c:306: undefined reference to `rb_next’
/uboot-imx/fs/ubifs/replay.c:294: undefined reference to `rb_first’

obs.: probably you will need add MTD part support too

linux booting on ubifs partitions

Tiago Maluta — Mon, 08 Nov 2010 17:01:31 +0000

UBIFS is relatively new on embedded systems but my guess is that they’ll become the standard on embedded market. To start, the first step is enable UBIFS support in kernel. I exaggerated on some debug options, fell free to avoid:

CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_RESERVE=1
CONFIG_MTD_UBI_DEBUG=y
CONFIG_MTD_UBI_DEBUG_MSG=y
CONFIG_UBIFS_FS=y
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y

Next I used a simple rootfs – basically busybox + mtd-utils – to create/format the partitions, suppose that you kernel divided the memory in the following parts:

# cat /proc/mtd
mtd0: 00300000 00020000 “bootloader” *
mtd1: 00500000 00020000 “nand.kernel” **
mtd2: 00100000 00020000 “nand.ramdisk”
mtd3: 06400000 00020000 “nand.system”

*,** The bootloader and nand.kernel I flashed via u-boot.

1. The first time

This is only needed when you create the partition for the first time. Steps are erasing the flash, detaching the UBI [if it was previously attached], format on UBI model, attach again, creating the volume (specifying a name) and finally mounting.

flash_eraseall /dev/mtd3

ubidetach /dev/ubi_ctrl -m 3
ubiformat /dev/mtd3 -y
ubiattach /dev/ubi_ctrl -m 3
ubimkvol /dev/ubi0 -N system -m
mount -t ubifs ubi0:system /mnt/ubi

[ copy your rootfs ]

umount /mnt/ubi

system is the name that I choose for partition, could be any.

2. Editing

Suppose that you need edit some files on your UBIFS , then you only need:

ubiattach /dev/ubi_ctrl -m 3
mount -t ubifs ubi0:system /mnt/ubi

3. Boot

In order to boot, you need add some parameters to u-boot.

setenv bootargs 'console=ttymxc0,115200 rootfstype=ubifs ubi.mtd=3 root=ubi0:system init=...'

mtd partitions: tips

Tiago Maluta — Wed, 03 Nov 2010 12:15:29 +0000

there are two tips when initializing MTD partition struct:

use MTDPART_OFS_APPEND to define .offset
1024 multiple to .size (4MB = 4194304 bytes or 4 * 1024 * 1024)

static struct mtd_partition nand_flash_partitions[] = {
{
.name = “bootloader”,
.offset = 0,
.size = 3 * 1024 * 1024},
{
.name = “nand.kernel”,
.offset = MTDPART_OFS_APPEND,
.size = 5 * 1024 * 1024},
{
.name = “nand.rootfs”,
.offset = MTDPART_OFS_APPEND,
.size = 256 * 1024 * 1024},
{
.name = “nand.userfs1″,
.offset = MTDPART_OFS_APPEND,
.size = 256 * 1024 * 1024},
{
.name = “nand.userfs2″,
.offset = MTDPART_OFS_APPEND,
.size = MTDPART_SIZ_FULL},
};

static struct mtd_partition nand_flash_partitions[] = {
{
    .&nbname = ”bootloader”,
    .offset = 0,
    .size = 3 * 1024 * 1024},
{
    .name = ”nand.kernel”,
    .offset = MTDPART_OFS_APPEND,
    .size = 5 * 1024 * 1024},
{
    .name = ”nand.rootfs”,
    .offset = MTDPART_OFS_APPEND,
    .size = 256 * 1024 * 1024},
{
    .name = ”nand.userfs1″,
    .offset = MTDPART_OFS_APPEND,
    .size = 256 * 1024 * 1024},
{
    .name = ”nand.userfs2″,
    .offset = MTDPART_OFS_APPEND,
    .size = MTDPART_SIZ_FULL},
};

using ubi on u-boot: part one

Tiago Maluta — Tue, 26 Oct 2010 13:42:45 +0000

UBI stands for Unsorted Block Images. The shortest description for UBI is “LVM for NAND flash memory devices” and if you don’t know yet how it’s works I recommend check this presentation. I intend here describe my use with u-boot, starting with the steps to flash an kernel image. First of all, if you not defined MTDPARTS_DEFAULT on you u-boot config file, you must define (or redefine) on u-boot terminal.

> setenv mtdparts mtdparts=nand0:0x80000@0x0(uboot),0x400000@0x80000(kernel),-@0x480000(root)

If you type mtd you I’ll see:

device nand0 , # parts = 3
 #: name        size        offset        mask_flags
 0: uboot     0x00080000    0x00000000    0
 1: kernel    0x00400000    0x00080000    0
 2: root      0x1fb80000    0x00480000    0

UBI deal with volume and not partitions. Let’s create one.

> ubi part kernel

If you got some -22 error, like:

UBI error: ubi_read_volume_table: the layout volume was not found
UBI error: ubi_init: cannot attach mtd1
UBI error: ubi_init: UBI error: cannot initialize UBI, error -22
UBI init error -22

you need erase the NAND region [ nand erase 0x00080000 0x400000 ] and ubi part command again.

Next step is create the volume:

> ubi create kernel_vol
Creating dynamic volume kernel_vol of size 3354624

The value in bold is the max size of that volume in bytes (~3MB). Note that is less than the 4MB (0×400000) defined in mtdparts. This happens because UBI works with logical blocks instead (LEB) of physical ones (PEB).

In order to write the kernel you need transfer the image to u-boot. Since Ethernet isn’t working in my board I choose between serial or mmc. As serial is too slow to large files I opted to write the image on FAT partition on SD card and load through:

> mmcinfo
> fatload mmc 0 ${loadaddr} uImage

The output will be something like

reading uImage
2845120 bytes read

Finally write it:

> ubi write ${loadaddr} kernel_vol 0x2b69c0

You can check if everything went fine comparing

> ubi read 0x90AC0000 kernel_vol
> cmp.b ${loadaddr} 0x90ac0000  0x2b69c0
Total of 2845120 bytes were the same

0×90AC0000 is some place on RAM different from ${loadaddr} (check using echo ${loadaddr}).

accessing u-boot with picocom to transfer files via serial interface

Tiago Maluta — Sat, 09 Oct 2010 00:52:00 +0000

There is a how-to with minicom too, this is using picocom to transfer files via serial interface (ymodem). First start with some parameters, in this case I’m using ttyUSB0.

$ picocom --baud 115200 --send-cmd="sb -vv" --receive-cmd="rb -vvv" /dev/ttyUSB0

Then:

U-Boot > loady
## Ready for binary (ymodem) download to 0x90800000 at 115200 bps...

Type C-a C-s and choose the file.

*** file: /tftpboot/uImage
sb -vv /tftpboot/uImage
Sending: uImage
Ymodem sectors/kbytes sent:   0/ 0kRetry 0: NAK on sector
Retry 0: NAK on sector
Bytes Sent:2203904   BPS:7800
Sending:Transfer complete*** exit status: 0
0(STX)/0(CAN) packets, 6 retries
## Total Size      = 0x0021a0e4 = 2203876 Bytes
U-Boot >

* The sb and rb utility are on lrzsz package [ $sudo apt-get install lrzsz ]

** Other reference

Installing Buildroot toolchain for Nuttx

Tiago Maluta — Wed, 08 Sep 2010 06:44:42 +0000

On my previous post I discussed some stats using Buildroot toolchain to build Nuttx. Today I’ll add the necessary steps to build on Ubuntu. Ubuntu is de-facto GNU/Linux distribution (although I’m Gentoo user) and many users, from different areas, uses it [they are not necessary command line experts] so I decided to publish my raw tutorial. If you are familiarized installing files from source-code you probably won’t need this…

1. Dependencies

$ sudo apt-get install libncurses5-dev
$ sudo apt-get install bison
$ sudo apt-get install flex
$ sudo apg-get install libgmp3-dev
$ sudo apg-get install libmpc-dev
$ sudo apg-get install libmpfr-dev
$ sudo apg-get install binutils-dev

2. Download

$ mkdir Nuttx
$ cd Nuttx

$ wget http://sourceforge.net/projects/nuttx/files/nuttx/nuttx-5.10/nuttx-5.10.tar.gz/download
$ wget http://sourceforge.net/projects/nuttx/files/buildroot/buildroot-1.8/buildroot-1.8.tar.gz/download

$ ls
buildroot-1.8.tar.gz nuttx-5.10.tar.gz

3. Install

$ tar zxf buildroot-1.8.tar.gz
$ tar zxf nuttx-5.10.tar.gz

$ cd misc/
$ ln -s ../nuttx-5.10 nuttx

You need define some Nuttx files before:

$ cd nuttx/
$ cd tools/
$ ./configure.sh nucleus2g/nsh # or ./configure
$ cd -

$ cd ../misc

I’m building a toolchain for arm cortex-m3 but check configs/ to other configuration files.

$ cd buildroot-1.8/
$ cp configs/cortexm3-defconfig-4.3.3 .
$ mv cortexm3-defconfig-4.3.3 .config

$ make menuconfig
[If you don't have any changes, just click on 'exit' and save the configuration]

$ make
[will download and build all necessary files]

$ cd build_arm_nofpu/staging_dir/bin
$ export PATH=`pwd`:$PATH
$ cd -

$ cd ../nuttx
[use normally]

I usually create an script to (re)define the $PATH for necessary building tools, something like:

$ echo “export PATH=\”"$PATH”\”" > compiler.sh

Compiler for Nuttx

Tiago Maluta — Mon, 06 Sep 2010 21:09:41 +0000

I was following this thread on Nuttx maillist on recommended compiler to build Nuttx RTOS. As a matter of practicality I guess that many users use CodeSourcery arm-none-linux-gnueabi but today I decided test the code generated for Cortex-M3 (LPC1768) using the toolchain from Buildroot. As Greg Nutt said (text adapted):

They were configured using OABI [old arm ABI], but I prefer them because (1) they are not EABI and reliably link code with -O3 or -Os, making it up to half the size, and (2) include nuttx “built in” — they really should be called arm-nuttx-gcc tools.

Here my stats (defconfig):

$ arm-none-eabi-size nutt
text data bss dec hex filename
71000 324 2248 73572 11f64 nuttx

$ arm-elf-size nuttx
text data bss dec hex filename
56172 330 2248 58750 e57e nuttx

The final .bin has an delta of 16K. As I’m using one parallel JTAG (flash rates @ 0.2 KiB/S) this means almost 1 minute reduction in each flash write_image. If you check Make.defs note that MAXOPTIMIZATION for CodeSourcery isn’t using optimize for size option (-Os). As explained on config//README.txt it doesn’t work with this kind of optimization level [tested with 2009q1].

Opcode stats

Tiago Maluta — Fri, 25 Jun 2010 00:09:50 +0000

I was trying some GCC options and decided see how they affect assembly code generated. I’ve created a simple Python script that parses .s output and put in a human readable way. Suppose the classical Hello World program. The output will be something like:

$ python stats_opcodes.py file

For Cortex-m3 (check previous post):

At my laptop (x86):

Download the script here.