Now that I have access to the
serial console on Samsung e60 reader let s build a new linux kernel for it.
The e60 reader has an ARM processor, to compile the kernel we need a cross compilation toolchain.
The first option is to use the one Samsung released with the other sources. It must work, however I don t really like the idea to run binaries from unknown sources.
The second option is to build our own toolchain, we often have to do that for systems that requires patches on the compiler.
Here, Samsung s binutils look like they were taken between 2.17 and 2.18 release (they are named 2.17.50 but are still slightly different from this snapshot) but they don t seam to embed homemade patches. As for ggc I didn t take time to check.
I choose to use the
emdebian cross-development toolchain lenny version. (As the article in the french
open silicium magazine #1 about FriendlyARM proposes to do).
Installing the cross-development toolchain on debian
First the archive keys:
sudo apt-get install emdebian-archive-keyring
Then we add a
/etc/apt/sources.list.d/emdebian.list file with the following content:
deb http://ftp.uk.debian.org/emdebian/toolchains lenny main
deb-src http://ftp.uk.debian.org/emdebian/toolchains lenny main
The we update the package list to install the needed packages:
sudo apt-get update
sudo apt-get install libc6-armel-cross libc6-dev-armel-cross libstdc++6-armel-cross binutils-arm-linux-gnueabi gcc-4.3-arm-linux-gnueabi g++-4.3-arm-linux-gnueabi
That s it ! We have now our cross-compilation toolchain installed from packages, so easy to update or remove.
The kernel sources
Samsung released it s modified 2.6.29.4 version. By cloning
the kernel 2.6.29.y git branch, I could quickly see that their changes applied well to the 2.6.29.6 version (the last in the branch).
In order to better sort the changes michel.s had splat them into several patches
(
patchs on e60-open project). After a few trials I build a
series file allowing to apply those patches with
quilt or better to import them to a git branch with
git quiltimport. The order I choose allows to drop easily some patches (the last ones).
One particular point on those patches is that some include binary files:
fs/rfs/*.o a proprietary journaling layer over FAT. If you want my point ov vue, we don t need that. After all we have free journaling file systems available and linux is able to mount something else than FAT over USB drivers/usb/gadget/file_storage.o also the corresponding .c file was removed, the BSD/GPL license from the original code allows a binary distribution (however I didn t check if Alan Stern s name appears in the doc) but I d have liked that Samsung give that source code.
U-Boot
Before compiling the kernel, we need the
mkimage utility from U-Boot. Here, Let s build the U-Boot released by Samsung, and let s just copy the
tools/mkimage to a location in our PATH (that s the only install method I could find).
make smdkc100_config
make CROSS_COMPILE=arm-linux-gnueabi-
cp tools/mkimage ~/bin/
Building linux
For the config, one of the patches includes a
.config. That file is a copy of
config_rfs so even without the previous patch, we can get Samsung s config.
Finally we can compile!
make CROSS_COMPILE=arm-linux-gnueabi- CFLAGS="-march=armv4t -mtune=cortex-a8" CXXFLAGS="-march=armv4t -mtune=cortex-a8" ARCH=arm uImage
We can then load our kernel by following
The kernel testing howto from e60-open project. To load the kernel we will need the following command:
sudo dnw arch/arm/boot/uImage
That it, and it works ! Well almost, the kernel cannot find his modules. This will not be a big deal for the ones included in the sources (but the subject of a next post) but the
/lib/modules/max14540.ko and
lib/modules/dhd.ko modules are not included in the sources while reporting a GPL license to the kernel.
Missing source code
The
Samsung Open Source Release Center website has a contact form, but it does not seam to work (I even booted my netbook on windows to try with IE8 without success). After browsing the
french e60 forum I found their email address and mailed them, no answer so far (not even automatic). Let s wait
Conclusion
We can compile a kernel for the e60 reader without using the cross tools from Samsung.
There still some work to load modules as the one on the reader are copiled for 2.6.29.4 and our kernel does not want to load them. (I ve already done a few tests but that will be a next posts topic.)
But without the missing sources it will be hard for us to best use our e60 reader.
Update: I got an answer from Samsung, they updated the released archive. I still have to look at it.
This went out to d-d-a a couple of days ago already but I figured that
this might be of interest here too:
The fourth Debian Groupware Meeting was held in the LinuxHotel,
Essen, Germany. This is a short summary of what happened during the
weekend:
With all the buzz around GNOME 3, I really wanted to try it out for real on my main laptop. It usually runs Debian Unstable but that s not enough in this case, GNOME 3 is not fully packaged yet and it s only in experimental for now.
I asked 
First steps as a GNOME packager
This is pretty common in free software and for once I followed the advice, I spent most of sunday helping out with GNOME 3 packaging. I have no prior experience with GNOME packaging but I m fairly proficient in Debian packaging in general so when I showed up on #debian-gnome (irc.debian.org) on sunday morning, Josselin quickly added me to the team on alioth.debian.org.
Still being a pkg-gnome rookie, I started by reading the documentation on 
This is the tenth Debian XSF News issue. It is basically meant to be
a follow-up to 
I've got a Debian GNU/Linux lenny installation (2.6.26-2-vserver-amd64 kernel) running on a Dell Poweredge 2950 with BIOS 2.0.1 (2007-10-27). It has two Intel(R) Xeon(R) CPU 5160 @ 3.00GHz processors (according to /proc/cpuinfo, 8 1GiB 667MHz DDR2 ECC modules (part number HYMP512F72CP8N3-Y5), according to dmidecode, and an Intel Corporation 5000X Chipset Memory Controller Hub (rev 12) according to lspci. The machine has been running stably for many months. On the morning of March 31st, i started getting the following messages from the kernel, on the order of one pair of lines every 3 seconds: ![[Individual interrupts - by month]](http://dkg.fifthhorseman.net/blog/i5000_edac/irqstats-month.png)
![[CPU Usage - by month]](http://dkg.fifthhorseman.net/blog/i5000_edac/cpu-month.png)
I also note that more rescheduling interrupts started happening, and fewer megasas interrupts at about the same time. I'm not sure what this means. A review of other logs and graphs on the system turns up no other evidence of interaction that might cause this kind of elevated activity. One thought was that the elevated activity was just due to writing out a bunch more logs. So i tried removing the i5000_edac module just to keep dmesg and /var/log/kern.log cleaner. Leaving that turned off doesn't lower the CPU utilization or change the interrupts, though. Any suggestions on what might be going on, or further diagnostics i should run? The machine is in production, and I'd really rather not take down the machine for an extended period of time to do a lengthy memory test. But i also don't want to see this kind of extra CPU usage (more than double the machine's baseline).Tags: 
Well, I still don t feel ready enough to go back to (real) work. So, once more, I had to get my fingers on something to hack and I picked the 
At least, it was very easy to fix.
Yesterday one of my free software halves was very, very
happy, because after a lot of work,
I've been following GNOME 3.0's development since Debian got the first
GNOME Shell snapshots uploaded to experimental. While my first experience,
on an old, 2 or 3 generations behind Athlon 800MHz with 512MB of RAM was
horrid due to the lack of features (it wasn't even an alpha!) and the
incredible slowness due to the crappy Radeon 9200, I've seen it evolve to
the gem that was released yesterday.
I haven't been so excited about GNOME since GTK+ and GNOME 2.0 were
released after their eternal development cycle, and was happy to see how
positive the atmosphere in 
Adam D. Barratt is a Debian developer since 2008, in just a few years he got heavily involved to the point of being now Release manager , a high responsibility role within the community. He worked hard with the other members of the release team to make Squeeze happen.
You could expect the release managers to have some rest after a big release, but it s not really the case. With the long freeze, loads of transitions have accumulated and they are now busy to get all those updated packages in the new testing (wheezy). Despite this Adam took some time to answer my questions.
He shares with us his impression on the Squeeze release, his opinion on time-based freezes (regular/predictable freeze) and much more. Read on. My questions are in bold, the rest is by Adam.
Who are you?
I m a 31 year old software developer and part-time sysadmin for a software and IT services company based in the south of England. I have no children, no pets and a long-suffering partner who puts up with me spending far too much time tinkering with things and people making fun of her Macbook during Debconf.
As well as being on the release team, I m a member of the maintainer teams for devscripts and lintian.
Can you describe your journey in Debian and in the release team?
I was introduced to Debian as part of an infrastructure upgrade at work, moving from a set of Red Hat and Solaris-based systems. As part of that, we submitted some bugs for issues we found during the upgrade and for small patches we included in some software to add extra functionality we wanted. From that starting point I became more interested in Debian in general and began following some of the mailing lists and IRC channels.
When Julian Gilbey asked for help with the maintenance of devscripts, I submitted some patches for some of the outstanding bug reports and was invited to join the team which was being created to handle maintenance for the package. One of the then Release Managers was also on the team and asked if I d be interested in working on a couple of updates they wanted to the scripts which generate the proposed-updates overview pages. I added the new functionality which was merged in to the live scripts and a little while later I was invited to join the team, shortly before Debconf 9.
As most readers will be aware, we unfortunately reached a point during last year where we didn t have anyone filling the Release Manager role. During that period, I became more active in handling transitions and requests for updates to stable and as time went on more people started to suggest that I should put myself forward for the position, or refer to me as already being RM. I procrastinated over the decision for some time but after discussions during Debconf 10 I came round to the idea that we should have the RM role filled again and agreed to take it on, together with Neil. The rest, as they say
How much time do you usually spend working for the release team ?
I ve been trying to work out how to usefully answer this question. My initial answer was approximately two hours each day , but the longer I thought about it the more I started debating exactly what I should include under the umbrella of release work; after some to-and-fro I ve decided to stick with my initial answer.
During periods when Debian is frozen and particularly in the lead up to the release that time commitment increases significantly, particularly over weekends. I m reliably informed that at that point the correct answer to the question is too much time . 
I just received a strange call. Basically, someone phoned me up and tried to convince me to change my computer s settings. They called my direct line (not the co-op switchboard), so I think they might be calling other numbers in the Weston-super-Mare area. Watch out for this attack.
I d heard about these calls from 
Looking at current state of some 
Today was the 30th annual
Today I made a couple of small tweaks to my systems. First of all I updated my