In this second part of my Hawkboard tale I share my experiences installing Gentoo Linux on an SD card, how I failed with the SATA disk and how much I appreciated Texas Instruments customer support. Finally I was able to use the SATA disk by choosing the right kernel and patches.
In the world of embedded devices I have very bad experiences. Some companies create fancy web pages about their great product but don’t even publish prices. Others keep technical information and only share them under NDA. I must be honest this irritates me. I am a developer and if I invest time to develop on a hardware than the producer will benefit from that. For this reason I evaluated lots of hardware and when my time allows I publish my thoughts ( IGEP-V2 SheevaPlug SmartQ-v7 Hawkboard ).
I liked Hawkboard because of its features and its price. It was clear that I have to invest significant amount of time first to evaluate and then to use it. For this reason I was postponing this all the time. At the meantime I read articles about DSP programing and how to get started with the DaVinci platform. Finally I bumped into a TI page about the OMAP and DaVINCI Software for DUMMIES book. First I didn’t like to register and also the fact that I cannot download the book. I forgot this and few weeks later I received the paperback book in my PO box. I’m very happy with this and fell in love.
I hate marketing being the science of pushing down products through my throat. But now I see it can be different. This TI book is on my desk for a few weeks and every time I see it I remember that I like Texas Instruments and helps my choice which device to use.
Apart from my feelings for TI it had practical consequences too. I was about to evaluate a Realtek RTD1073 based device and that will wait. I only need to choose one platform and these events made me think TI is the way to go.
With this new power I bought a SATA disk (Samsung 2.5” 250GB HM251J) to play with Hawkboard. The sad thing is that it does not work. I read forum posts about this. And the suggestion was to checkout git kernel and the issue was probably fixed there. Before I did that I tried the uImage_v3 kernel from the hawktool site but this did not help either. I’m receiving these errors:
ata1: softreset failed (device not ready)
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: link is slow to respond, please be patient (ready=0)
ata1: softreset failed (device not ready)
ata1: limiting SATA link speed to 1.5 Gbps
ata1: softreset failed (device not ready)
ata1: reset failed, giving up
This error is a pretty bad news for me. I mounted NFS root to Hawkboard and its performance was about 1MB/s and looked CPU limited. My usual strategy for devices is to create their environment on an NFS share will not be optimal for this device.
To compile kernel from Git I will need couple of tools, that implies I have to decide which distribution to use. There are couple of available distros. They can be accessed from this eLinux Hawkboard page . Now I take the harder path because I don’t want those.
The Gentoo install steps largely follows the way I installed Gentoo on Igep .
I chose the stage3-armv5tel-20100220.tar.bz2 tarball. Extracted it on an SD card and mounted it. I also mounted proc and dev. Then I chrooted into that environment.
The steps needed:
For the rest of these I’ll need networking but that was already set at u-boot. One might also need to set IP address and default gateway.
I modified make.conf and replaced Os flag with O3 which will lead to significantly longer compilation time but faster program execution too.
CFLAGS="-O3 -march=armv5te -pipe "
CXXFLAGS="-O3 -march=armv5te -pipe "
CHOST="armv5tel-softfloat-linux-gnueabi"
FEATURES="buildpkg -ccache -stricter -test strict test-fail-continue assume-digests collision-protect cvs \
digest distlocks fixpackages multilib-strict news parallel-fetch protect-owned sandbox sfperms sign \
splitdebug unmerge-logs unmerge-orphans userfetch userpriv usersandbox"
ACCEPT_KEYWORDS="~arm"
USE="nls -X -kde -gtk -gnome -fortran -mysql -bluetooth -flac -test -apache2 \
-kerberos -smartcard linguas_en linguas_en_US linguas_hu"
I also set ~arm keyword. buildpkg is set to keep compiled packages. For the initial setup I disabled common use flags that I don’t want for a basic system.
Selected a developer profile. My goal now is to compile a SATA enabled kernel. If this machine will ever run X I can still change the profile and the USE flags in /etc/make.conf
en_US ISO-8859-1
en_US.UTF-8 UTF-8
hu_HU ISO-8859-2
hu_HU.UTF-8 UTF-8
I enabled Hungarian and English locales. Now generate them and also set the timezone:
Now I can install useful packages. I usually start with eix which is very helpful addition to portage.
This in turn installs:
The compilation failed because I forgot to set the time. I set the date and also install ntpdate so I can more easily set it.
This in turn installs:
I am not patient enough. Change strategy. I move what I have compiled to an NFS share and ask my IGEP-V2 and SheevaPlug devices to help compiling. This way I can also make a few things parallel.
The state of Hawkboard ready kernel is confusing at best. I found this page that lists a few changes for Hawkboard support but neither the TI DaVinci git repo nor the mainline stable kernel has integrated it.
I found these kernel trees to be considered as a base to be patched:
And these patches:
The first four patches are older and a quick look into the codes tells me that the board I have is patched with them. Because I know the SATA support is broken with these I give a try to the last one. I compared the kernels and the most work on da850/DaVinci went into arago/linux-omapl1 tree, so I will patch this one. The patched kernel source is available here.
Some other files like the factory kernel config and the above mentioned files made available here.
I forked the hawkboard repository on gitorious and applied the patch I used. My git repo can be accessed here.
igep src # eix u-boot
[I] dev-embedded/u-boot-tools
Available versions: 2009.03 (~)2009.06 (~)2009.08 (~)2009.11.1{tbz2}
Installed versions: 2009.11.1{tbz2}(18:39:06 07/03/10)
Homepage: http://www.denx.de/wiki/U-Boot/WebHome
Description: utilities for working with Das U-Boot
make ARCH=arm CROSS_COMPILE=armv5tel-softfloat-linux-gnueabi- distclean
make ARCH=arm CROSS_COMPILE=armv5tel-softfloat-linux-gnueabi- da850_omapl138_defconfig
make ARCH=arm CROSS_COMPILE=armv5tel-softfloat-linux-gnueabi- menuconfig
make ARCH=arm CROSS_COMPILE=armv5tel-softfloat-linux-gnueabi- uImage modules modules_install
I modified the factory config to include a few things like LVM. It can be found here.
The compiled uImage can be found here, and the modules here.
The usual disclaimer applies: no warranty, use at your own risk and every file here stay under their original license.
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1.00: ATA-8: SAMSUNG HM251JI, 2SS00_01, max UDMA/133
ata1.00: 488397168 sectors, multi 0: LBA48 NCQ (depth 31/32), AA
eth0: attached PHY driver [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=1:07, id=7c0f1)
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA SAMSUNG HM251JI 2SS0 PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 488397168 512-byte logical blocks: (250 GB/232 GiB)
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: unknown partition table
sd 0:0:0:0: [sda] Attached SCSI disk
I’m impressed. The new kernel boots fine and it sees my disk.
My next task is to setup a proper gentoo system on my HDD. I will keep you posted. I share some quick performance numbers I see on the disk:
# dd if=/dev/zero of=/dev/sda bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 39.3837 s, 26.6 MB/s
# dd if=/dev/sda of=/dev/null bs=1024k count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 33.4694 s, 31.3 MB/s
The numbers are pretty neat for a small device like this.
My task here was to collect the information that was already available. If I used what was already available in the OpenEmbedded project this could work out of the box. I still not plan to use that, but I do respect the work they have put inside. I’m not very surprised to see a few Texas Instruments emails of the contributors. The people I see worked on this, most probably not complete:
If I omitted anyone please tell me: dbeck-at-beckground-hu. Anyway, thank you guys!