For about six months I’ve been using a Raspberry Pi 3 as my desktop computer at home.
The overall experience is fine, but I had to do a few adjustments.
First was to use KeePass, the second to compile gcc for cross-compilation (ie use buildroot).
Continue reading
The French version was originally written for linuxembedded.fr : Crée un CD d’installation d’une debian spécialisée.
The goal is to build a debian install CD suitable for the distribution of a complete system including the operating system and applications.
Debian already has a tool for that purpose: simple-cdd. Simple-cdd is a set of scripts wrapping debian-cd which is the tool used to build official CDs.
In our case, we will include some “non-free” packages (firmwares for instance) and application specific packages in the system.
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).
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.
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.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/
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.
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 …
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.
Better later than never, I restarted to triage last week, here is the report for it.
In the mean time, Cyril has been triaging a lot of bugs see Debian XSF News #7.
But there are still 533 bugs to triage.
Mike Hommey recently wrote about graphs for the Debian Bug Tracking System. In particular there is now a per maintainer graph, so here it the X Strike Force bug graph ! (Note: the graph does not filter out some bugs as we do on UDD.
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
This report is 2 week late… It was delayed by an important event, not the release of squeeze, but the birth of my first child: Célestine is born Monday the 31th of January.
My wife and Célestine are both fine now but the firsts days were not that easy. I’m starting to recover from the lack of sleep, but I’m still very late on my debian tasks 😉 So I guess I just drop Triaging for week 13, 14 and maybe 15…
Now the bugs I triaged just before :
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
I’ve been lasy about the reporting lately, so this is a 3 weeks update at once !
The bug count according to udd is down to 818. I guess this is due to Kibi‘s triaging on input related bugs, but I helped to close a few one too !
I kept my week numbering as before, so now I know the first bugs I pinged are more that 11 weeks old. I guess if some submitter did not answer in that delay, they will probably never do it. I think the bug count will go down again ! 😉
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
There is a big thread on -devel that started about Forwarding bugs upstream, the idea is that it should be the maintainer’s job. While it’s true in general, some understaffed teams are so flooded by bugs that they just can’t do it.
I’ve seen more than once the X Strike Force asking a user to report upstream (pointing to the relevant BTS) and come back with the tracking URL to be attached to the bug. This was mostly for driver issue if I remember well.
And most users did it, so thanks!
Then the thread evolved in lots of directions, I’m not following all of it, but there was the question of the bug triaging and as I’m doing it for the X packages, I want to share about my experience here.
The debian wiki already have a general Bug Triage page.
The thread pointed to the KDE Bug triaging page.
The X Strike Force has some pages, one on the wiki and a new one more specific to bug triaging on the alioth project’s doc.
And when it comes to closing bugs with version information, there is a good read on the wiki: Bugs Version Tracking.
Finally don’t hesitate to reopen the BTS documentation whenever you need to write to control@b.d.o !
Now if all those docs don’t help you, then try to improve the docs as a first step ! 😉
Well I did met Julien Cristau and Cyril Brulebois in person during mini-DebConf Paris/2010 that certainly helped. But we exchanged several mails, or met on IRC channel #debian-x.
But the triaging rules of the X Strike Force (linked above) were pretty clear anyway.
This process has evolved over time with the response of several contributors either to help or to fix to my mistakes, thanks!
bts command as a way to open the bug mbox in mutt, that makes it really easy to answer the bug.bts -m show $n where $n is the bug number, and I can then answer the bug from mutt.Note: Sometime I don’t send the bug to -quiet so that other debian-x subscriber can have a look at the bug. They then can give me advices, or close the bug directly with a stronger reason than any I could have found. 😉
To submitters, please keep the bug CCed when you answer, thanks.
Yes as a newbie I did some mistakes, but I was always corrected in a nice way, with explanations. Also I try to have a conservative approach, I don’t close bugs if I’m not sure, I ask if I can close them, so it might take longer, but in the end the effect is the same for the bug, but not the same to the submitter ! 😉
Also this work might look boring, but it’s actually rewarding, most of the answers I received included a cheerful message thanking me for following up on the bug. Not to mention all I’ve learned on Xorg.
As long as I have time for it, I’ll continue to triage bugs and I’d love to see others coming to help me on X or probably better go and help some other teams that also need help, and flood the planet with bug triaging reports ! 😉
Get involved !
Happy new year !
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
For some reason1 bug #607242 did not make it to the debian-x@d.o mailing list, I got aware of it only by the message shirish sent to my blog.
If he didn’t write to me, this bug will have waited for what… about 3 years until I got all the 800+ bugs triaged ? So please you can help triaging X bugs, first subscribe to the debian-x mailing list so you can get the feeling of what to respond to some bugs, and join the TXBW effort 😉
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.
Note 1: The Xorg.0.log file was so huge that the mailing list did not accept the mail.
An other week, a few more bugs looked, unfortunately in the mean time the number of bug grew to 875…
The X Strike Force (still) needs you !
You can have a look at the X Strike Force Bug Closing Procedure and check XSF unstable bugs sorted by date.