How to dock OpenOffice Navigator and Style windows when Graphics effects are enabled in Ubuntu
Ubuntu is a great distribution, but not all is perfect (as all in the world)
Moving on the left the Navigator window, the docking grey lines are not showed anymore
When the composite manager is enabled (System -> Preferences -> Appearance -> Visual Effects set to Normal or Extra), moving the OpenOffice’s Navigator and Styles windows on the right or left do shows docking capabilities for these windows anymore.
Well there’s a simple fix about this which I’ve found here: Simple Ctrl + Double left click on the grey area of Navigator (or Styles) and the window will be anchored on the left.
Then you will be able to drag the docked component on the side you prefer.
Bye!
Alberto!
Tweet from the linux shell on Ubuntu Karmic
Twitter is something like a panel where you write all what you want in as short message style.
What makes Tweeter powerful (for me and for IT developer) is the fact that nowadays IT companies look for job candidates also in these Social Networks. This is a way to find out the best candidates for a vacancy looking for already skilled people in what the vacancy involve.
Well, I am a kernel developer, so what is better than the ability to tweet my messages from bash???
This tutorial is for whom that want to do this also after the Tweeter strength of its authentication policy (now plain authentication is forbidden) with the OAuth mechanism.
The utility that can do this is called bti version 028 and upper, made by one of the most important member of the Linux development community: Greg Kroah Hartman.
Getting the source
So move into your preferred source directory, I will call it $BUILD and clone these repositories (it is needed a working installation of git and svn ):
$ cd $BUILD $ git clone git://github.com/gregkh/bti.git $ svn co https://oauth.googlecode.com/svn/code/c/liboauth
all other packages needed can be found with apt-get (or whatever other debian package management you like).
Compiling the source
First we have to compile liboauth (it is needed a working installation of automake and autoconf):
$ cd $BUILD/liboauth $ mkdir m4 $ aclocal $ automake --add-missing $ autoreconf $ ./configure $ make $ sudo make install
The library will be installed to /usr/local/lib, if you want another destination dir, change the –prefix as you want in configure time.
Now bti:
$ cd $BUILD/bti $ ./autogen.sh $ # Because of liboauth did not wrote the package configuration info: $ ./configure LIBOAUTH_LIBS=/usr/local/lib/liboauth.a LIBOAUTH_CFLAGS="-g -O2" $ make $ sudo make install
In the configuration process you may be prompted to install other packages. You can find them with apt-get.
Make it work
Now you have the command bti available on your shell and you have to complete the OAuth authorization process to be able to post on your twitter account.
First create your configuration file as:
# comments are allowed in the bti config file # rename this to ~/.bti so that you do not need # to constantly enter your account name and/or # password on the command line every time you send # a message. account="your account" password="your password" host=twitter # Example of a custom laconica installation #host=http://army.twit.tv/api/statuses logfile=.bti.log action=update #user="your proxy user" #proxy="http://your proxy address:port" #shrink-urls=yes
and put it in ~/.bti.
Consumer key and secret
Now the “cloudy” part for me. Because consumer key and secret should be application specific as I understood so these keys should be part of the bti application (correct me otherwise).
@update from Amir: Read this post to understand why those informations are not part of the bti sources http://gluegadget.com/blog/index.php?/archives/34-Twitter,-OAuth-and-bti.html.
Anyway you can register a new application to have access at your twitter following this link: https://twitter.com/apps/new. Please give the correct info on bti website as linked from this post but choose a different application name because bti is already choosen.
The application type is client without callback, must to have write permission and do not use twitter for the authentication.
Twitter will give you the two keys you need and You will put these at the and of your .bti config file as:
consumer_key=ambarabaciccicocco consumer_secret=trecivettesulcomò
Then try your first run:
$ bti
You will be prompted to browse a specific link and past back the pin you see. Then you will be asked to add other two rows in your configuration file and when you have done it, well all the process is completed! with the command:
$ echo "tweet what you want" | bti
You will be able to tweet all you want from the shell!
Enhancement
Maybe for someone lazy it is too much complicated the form with echo.
So I suggest to add the following lines at the end of your ~/.bashrc:
# $ tweet "your message"
function tweet {
if [ ! "$*" ]; then
echo 'Nothing to tweet!'
return 1
fi
echo "$*" | bti
}
The comment on top explain how to use this function from the bash shell.
Hope you enjoyed this tutorial and please, any corrections or suggestions are welcome!
Alberto!
OpenOCD with Amontec JtagKey2 support
Recently I bought an Amontec JtagKey-2 debug probe for my embedded projects. This Jtag probe have great features over a relative little buying cost: over other low cost Jtag probes, this one supports the RTCK signal and nominal speeds are really interesting.
What this post will describe is how to setup a useful JTAG debug environment:
libftd2xx
The JtagKey2 is based on FTDI FT2232 usb interface. Drivers for this chip can be found here:
http://www.ftdichip.com/Drivers/D2XX.htm
Choose your arch (for me Linux x86_64) and download the archive in $PRJROOT/openocd.
Then:
$ cd $PRJROOT/openocd $ tar -xvf libftd2xx0.4.16_x86_64.tar.gz
OpenOCD
OpenOCD can be downloaded from its public git repository:
$ cd $PRJROOT $ git clone git://openocd.git.sourceforge.net/gitroot/openocd/openocd openocd
Then, move to the opnocd directory and configure with:
$ cd openocd $ ./bootstrap $ # If you need, choose the right prefix with --prefix=DIR $ ./configure --enable-maintainer-mode --enable-ft2232_ftd2xx \ --with-ftd2xx-linux-tardir=libftd2xx0.4.16_x86_64 $ # n: Numbers of cores in your machine $ make -j n
At this point the OpenOCD build process fire a linker error, this because libtool mess up the library order when linking main.c so, let we do the right command:
$ cd src/
$ gcc -std=gnu99 -g -O2 -I/media/dati/android/openocd/libftd2xx0.4.16_x86_64 \ -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter \ -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror \ -o openocd main.o ./.libs/libopenocd.a \ /media/dati/android/openocd/libftd2xx0.4.16_x86_64/static_lib/libftd2xx.a.0.4.16 \ -ldl -lpthread $ cd .. $ make -j 6
And at the end, install:
$ sudo make install
Using OpenOCD
OpenOCD is completely configurable: the server must be started with a number of “-f ” options that points to the necessaries configuration files.
Normally must be given two configuration files: The interface config and a board config.
So OpenOCD can be started with:
$ sudo openocd -f interface/jtagkey2.cfg -f board/your_board.cfg
We have to use sudo because of permissions needs on using an usb device, otherwise an udev rule must be set.
On Android smoothness
Currently I am working on Android optimizations for Freescale i.MX SoCs.
I am frustrate because of a lot of CPU utilization in jobs where the load should not be as heavy as it looks.. But I am working on! And solutions are coming up.
I found by chance this Freescale video, where one Freescale engineer present the opportunity to develop Android based embedded projects on an MPC8536 (Power III based SoC that works at 1.25 GHz) provided board.
He say “Optimized implementation of Android operating system” but look at time 2:18! How smooth is this Optimized implementation 🙂
Cheers,
Alberto!
FOSDEM
Too late, I know, but I’ve been there!! 🙂
It was the fist time and sure, I think it is normal, but I was too excited!! Lot of Open Source stuff: areas, projects, peoples, minds.. All was Open!! and lot of Embedded talks and stands. I was crying like a baby :’)
I had the chance to introduce me to two of mine bigger open source guru, and it was Great! they are people like me and you, with a lot of desire to do their work well!
If you are thinking on going or not the next year, CAME WITH ME!!!!!!
Alberto!
Git clone with local references
In this post I explain how to clone a remote git repository basing it on a local one.
If you work with the Linux kernel there are so many different repositories for developing, so when you are asked to base your patch series on branch x of repo y, if you follow those rules you don’t have the need to re download the n-est Linux kernel repository!
First: You must have a clean linus repository!
Saying the project root dir for developing is $PRJROOT we can setup a clean linus repo with:
$ cd $PRJROOT $ mkdir kernel-linus $ cd kernel-linus $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
Second: clone a remote repository referencing the local linus one:
The parameter –reference in the git clone command make what we need
$ cd $PRJROOT $ mkdir kernel-mfd $ cd kernel-mfd $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/sameo/mfd-2.6.git \ --reference ../kernel-linus/linux-2.6/
Pay attention that the default behaviour for git in local referencing is to setup a .git/objects/info/alternates to share the objects with the source repository, resulting in much more space occupied but deleting old objects in the new one, deletes the same in the old one that is not always a good thing.
So only go ahead in referenced local repositories 🙂
Bye!
Alberto!
NAND Flash Support
In the CPU board there is a 2 Gb NAND Flash chip organized in :
1 Device = (2K+64)Bytes x 64Pages x 2048 Blocks = 2112Mbits
This chip is connected to the i.MX31 Application Processor through the Nand Flash Controller Interface with an 8 bit data bus. The in kernel driver “drivers/mtd/nand/mxc_nand.c” can easily support it registering the nand device in the machine code with the follow platform data:
static struct mxc_nand_platform_data imx31pdk_nand_flash_pdata = {
.width = 1, /* 1 Byte data bus */
.hw_ecc = 1, /* No suppress hardware ECC */
};
The mxc_nand.c driver is enabled by default with a $ make mx3_defconfig
What can be enabled is the MTD Partitioning support with support for RedBoot partition table parsing where the Location of RedBoot partition table is the number of the Flash page where it is stored the RedBoot “FIS directory” that for me start at 0x80000, so it is the fourth page (4).
The resulting patch:
Subject: [PATCH 2/2] MXC: imx31pdk: Add support for on board NAND Flash.
Signed-off-by: Alberto Panizzo <alberto.panizzo@gmail.com>
---
arch/arm/mach-mx3/mx31pdk.c | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mx3/mx31pdk.c b/arch/arm/mach-mx3/mx31pdk.c
index 0f7a2f0..ca1fe5d 100644
--- a/arch/arm/mach-mx3/mx31pdk.c
+++ b/arch/arm/mach-mx3/mx31pdk.c
@@ -34,6 +34,7 @@
#include <mach/board-mx31pdk.h>
#include <mach/imx-uart.h>
#include <mach/iomux-mx3.h>
+#include <mach/mxc_nand.h>
#include "devices.h"
/*!
@@ -53,6 +54,14 @@ static int mx31pdk_pins[] = {
IOMUX_MODE(MX31_PIN_GPIO1_1, IOMUX_CONFIG_GPIO),
};
+/*
+ * NAND Flash
+ */
+static struct mxc_nand_platform_data imx31pdk_nand_flash_pdata = {
+ .width = 1,
+ .hw_ecc = 1,
+};
+
static struct imxuart_platform_data uart_pdata = {
.flags = IMXUART_HAVE_RTSCTS,
};
@@ -241,6 +250,7 @@ static void __init mxc_board_init(void)
"mx31pdk");
mxc_register_device(&mxc_uart_device0, &uart_pdata);
+ mxc_register_device(&mxc_nand_device, &imx31pdk_nand_flash_pdata);
if (!mx31pdk_init_expio())
platform_device_register(&smsc911x_device);
--
1.6.3.3
imx31pdk Initial Support path
On the imx31 PDK CPU board there are mainly those chips:
| Device | Description | Connected through |
Application processor: |
i.MX31 |
|
RAM Memory: |
128 MB (1 Gb) DDR |
iMX31 EMI |
NAND Flash: |
256 MB (2 Gb) |
iMX31 NFC |
Power Management and Audio IC: |
MC13783 |
iMX31 SPI2 |
USB transceiver: |
ISP 1504 |
iMX31 USB OTG |
RAM memory is native managed by the iMX31 External Memory Interface, then the first chip that can be supported is the NAND Flash. Then we must to go through the support for the Power management chip to go ahead with all other devices because MC13783 hold the entire power supply management, with its Regulator interface.
i.MX 31 PDK developing
In those days I am involved in supporting the Freescale i.MX PDK developing board in the mainline kernel.
This is not a simple job because there are (at first seeing) a lot of holes in mainline kernel.
Stay tuned for news!
Developing kernel on a Virtual Machine (the solution)
I am working now on Ubuntu Karmic Koala.
As I said in my previous post, Qemu is a complete platform emulator that can emulate the Integrator ARM machine platform (CPU and devices!).
In Karmic Koala the latests Qemu version (0.11.0) is shipped within Ubuntu repositories so with this line we can install it:
# sudo apt-get install qemu qemu-kvm qemu-kvm-extras
ARM test images
From the Qemu home page we can download a Linux 2.6 ARM example image builded by Paul Brook and extracting it in $PRJROOT/images, we can find the README file where it is written how to launch the test platform:
# cp DownloadDirectory/arm-test-0.2.tar.gz $PRJROOT/images # cd $PRJROOT/images # tar -xvf arm-test-0.2.tar.gz # cd arm-test # cat README
So, with or without the graphical interface we can test the qemu arm installation with the followings:
# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img or # qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \ -nographic -append "console=ttyAMA0"
A suitable Linux config file
Over the test purpose , executing the test image can give the kernel configuration file stored in /proc/config.gz ! so:
# qemu-system-arm -kernel zImage.integrator -initrd arm_root.img \ -nographic -append "console=ttyAMA0" Uncompressing Linux............................................... ........................... done, booting the kernel. Linux version 2.6.17-rc3 (paul@wren) (gcc version 4.1.0 (CodeSourcery ARM)) #53 Thu May 4 15:05:18 BST 2006 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) Machine: ARM-IntegratorCP Memory policy: ECC disabled, Data cache writeback CPU0: D VIVT write-through cache CPU0: I cache: 4096 bytes, associativity 4, 32 byte lines, 32 sets CPU0: D cache: 65536 bytes, associativity 4, 32 byte lines, 512 sets Built 1 zonelists Kernel command line: console=ttyAMA0 PID hash table entries: 1024 (order: 10, 4096 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 128MB = 128MB total ... Log in as root with no password. qemu login: root # cp /proc/config.gz . # tar -xvf config.gz # vi config.gz
With this file we can configure the mainline linux kernel! (copying from screen, copying within net, scrolling the options with a near mainline make menuconfig window).
ARMv5te Toolchain to build the kernel
The machine emulated by qemu-arm is based on the core ARMv5te , so I need the correct toolchain for build all the necessary code.
The Pengutronix OSELAS environment can do that in the OSELAS toolchain project. Similarly at what described in Initializing a Linux Embedded Development Host Machine moving in $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/ we can select the suitable ptxdist configs with:
# cd $PRJROOT/build-tools/OSELAS.Toolchain-1.99.3.4/ # ls ptxconfigs/ arm-1136jfs-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig arm-1136jfs-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.19_kernel-2.6.27-sanitized.ptxconfig.old arm-cortexa8-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig armeb-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig armeb-xscale-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig ... arm-v4t-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig arm-v4t-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig arm-v5te-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig arm-v5te_vfp-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig arm-xscale-linux-gnueabi_gcc-4.1.2_glibc-2.5_binutils-2.17_kernel-2.6.18.ptxconfig arm-xscale-linux-gnueabi_gcc-4.2.3_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig ... # ptxdist select ptxconfigs/\ arm-v5te-linux-gnueabi_gcc-4.3.2_glibc-2.8_binutils-2.18_kernel-2.6.27-sanitized.ptxconfig # ptxdist menuconfig
In the menuconfig, all can live as it is but in “misc->prefix for installation” we can choose $PRJROOT/tools where $PRJROOT must be manually extended. So with:
# ptxdist go
A part from minor dependencies that we can solve installing software with apt-get, the toolchain is built and the correct prefix will be:
CROSS_COMPILE_OSELAS_v5=$PRJROOT/tools/OSELAS.Toolchain-1.99.3/arm-v5te-linux-gnueabi/\ gcc-4.3.2-glibc-2.8-binutils-2.18-kernel-2.6.27-sanitized/bin/arm-v5te-linux-gnueabi-
If we assign the environmental variable CROSS_COMPILE=CROSS_COMPILE_OSELAS_v5 the kernel configured by the upper config file and compiled with this toolchain is a good kernel to execute within the qemu-system-arm emulator!
A suitable Root Filesystem
Ok we have a good kernel ad a small initrd filesystem, but we have to develop application to run in the emulated device!
We can use the OSELAS.BSP Phytec phyCORE project installed following the description in Initializing a Linux Embedded Development Host Machine.
Download the platform_config file platformconfig-qemu and the ptxconfig one ptxconfigThiny (that is the normal ptxconfig removing all graphic subsystem for a speedier compilation)
Every two configuration file must be placed in $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/configs so with:
# cd $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/ # ptxdist select configs/ptxconfigThiny # ptxdist platform configs/platformconfig-qemu # ptxdist toolchain $CROSS_COMPILE_OSELAS_v5 # ptxdist go # ptxdist images
In $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/ we will find the root.ext2 image, ready to be the SD/MMC image of the qemu device!
Running qemu
If in the $PRJROOT directory we create the images/phyCORE directory and we put all the necessary:
# cd $PRJROOT # mkdir -p images/phyCORE # cp (kernel_path)/arch/arm/boot/zImage images/phyCORE/ # cp $PRJROOT/build-BSP/OSELAS.BSP-Phytec-phyCORE-12-1/platform-phyCORE-qemu/images/root.ext2\ images/phyCORE/
then we can start qemu:
# qemu-system-arm -kernel images/phyCORE/zImage -sd images/phyCORE/root.ext2 \ -nographic -append "console=ttyAMA0 root=/dev/mmcblk0"
Results
In results we have a complete developing environment: emulator, toolchain, kernel, software ecosystem.
Kernel modification that do not deal with the hardware abstraction layer can be well developed in the emulator and tested by ad-hoc software inserted in the phyCORE-qemu distribution!
Alberto Embedded & Open experience 