1. Unpacked Progear

    After 691 days of not using Progear I unpacked it and got it running again. Why “691 days”? It was written by fsck during booting.

    Progear support in OpenEmbedded is a bit updated now. New kernel (2.6.27) gives VESA frame buffer which finally utilize XGA resolution (in 2.6.19-rc5 it was VGA centered on screen). It still lack good AC/Battery support anyway. External modules which were used (progear-ac, progear-battery) do not build with current kernels (not strange as they were hacked ACPI modules) so I tried to write driver to get at least AC status. It works more or less.

    I currently do not have any plans for this machine. Will use it to learn how to write ugly kernel drivers which probably no one will use (how many Progear users plays with current kernels?) and sooner or later it will go back to basement as other toys will need space on desk.

    Written by Marcin Juszkiewicz on
  2. Bug Labs and their BUG device

    Month ago I ended work for OpenedHand. Some people asked me what I am doing now, who is my client etc. Now I can write a bit about it.

    I am working as contractor with Bug Labs Inc. to help them with their development of BUG Linux (which is based on OpenedHand’s Poky). Target device is BUG device which consists of BUGbase and BUGmodules (more on their website). Hardware is quite interesting (information copied from website):

    • ARM1136JF-S-based microprocessor
    • 1 USB 2.0 HS host interface/4 hub port connections
    • 1 USB OTG HS interface
    • 4 UART serial links
    • 4 channel SPI interface
    • I2C (400 kbits) interface/4 channels
    • I2S interface/2 channels
    • Smart LCD interface
    • Camera sensor interface
    • Micro memory card interface
    • MPEG4 hardware encoding/decoding
    • Hardware graphic acceleration
    • 10/100 Ethernet MAC
    • Base unit LCD module interface
    • Base unit 128MB on-board memory (FLASH/DDR SDRAM)
    • JTAG/ICE support
    • Serial debug port
    • Power system
    • AC operation
    • Battery operation/up to 4 external batteries
    • Fast battery charging/simultaneous of internal and external batteries
    • Smart power management support
    • Battery-backed real-time clock
    • Audio out via on-board piezo speaker

    And BUGbase has 4 slots for additional BUGmodules which can be hotplugged during use. Currently there are screen (with touchscreen), GPS, accelerometer + motion detector and 2Mpix camera modules. As i.mx31 cpu, which they use, supports two framebuffers two screens can be used at same time — I hope that will have occasion to play wit such setup ;D

    Software side is other thing as it is Java based. Under it is normal GNU/Linux system (Poky based) but access to hardware is now based on Java components. Does it works with normal languages? No idea yet — will check when will get hardware to play with.

    Generally it is interesting project and I hope that it will get more popularity as most of informations is open so (in theory) anyone can make own BUGmodule.

    Written by Marcin Juszkiewicz on
  3. Next events

    Some people asked me which events I plan to attend in next months. Currently there are two of them: OEDEM and FOSDEM.

    OEDEM is not yet decided when and where it will be. There was suggestion from OpenBossa conference organizers to make it there but it would costs us too much (travels, hotels). We are considering Berlin (as all previous meetings were there) but we lack place for it. And I suggested Szczecin, Poland. But where and when? Not decided yet.

    FOSDEM will be in Brussels, Belgium like it was always. Probably it will be 21-22 February 2009 and I hope that it will get confirmed soon so I will be able to buy cheap plane tickets for BerlinBrussels flights (today it would be EasyJet with 52EUR for total cost). OE developers not decided yet which hotel will get our blessing so I did not yet checked this.

    Will I attempt other events? It depends on when and where they will be as this generate costs which I have to care about.

    Written by Marcin Juszkiewicz on
  4. Merging stuff from Poky into OpenEmbedded

    Recently I started merging interesting stuff from OpenedHand’s Poky into OpenEmbedded. Now, with OE using GIT as storage for metadata it is much, much easier then it was in Monotone times.

    I have over 3 thousands of revisions exported (using git format-patch) from Poky and I am reviewing them and adapt to add into OE. Useful ones are changed by simple shell script which adapts paths, change authors informations (I use Poky via git-svn so no real names/emails) and adds “(from Poky)” message to end of patch description. Then just git am and patch lands in OpenEmbedded.

    For now I added newer APT and DPKG package tools, newer QEMU (not the latest but working with ARMv6/v7 instructions), U-Boot mkimage tool which does not use lot of Openmoko patches (just one is needed), Shared MIME Info which does not need any processing on target device and some tweaks here or there.

    Next in queue are Maemo4 cleaned recipes (Diablo ones), binary locales for Angstrom powered ARMv6/7 based machines and miscellaneous tweaks or updates.

    Written by Marcin Juszkiewicz on
  5. My private buildbot

    One of great things which OpenedHand use to get Poky into working state is buildbot. But it is available only over VPN so recently I started my own buildbot for my projects.

    Currently there are few build configurations enabled:

    • Poky build from scratch — qemuarm, c7x0, om-gta01, qemux86 images
    • Poky incremental (same targets as above)
    • Ångström incremental with same machines and base, console and x11 images

    Soon more configurations will get added, some will change (probably will drop Poky ones). I am also wondering about providing public access to waterfall display but without rights to stop/start builders.

    I hope that this will allow to catch some bad commits.

    Written by Marcin Juszkiewicz on
  6. Updates

    Long time no post — I wonder does someone wondered what happened :)

    Job situation change

    15th October was my last day of work for OpenedHand (which was acquired by Intel two months earlier). Since then I am free to work for anyone and I have few offers of cooperation in discussion. I will still have my own company (HaeRWu) but probably will change name of it as this is very hard to pronounce for English speakers.

    I have to admit that I will miss atmosphere of OpenedHand. That company had great people with many ideas, there was lot of interesting projects (sane and insane ones), interesting hardware which no one had idea of existence etc. I hope that our future roads will cross one day and we will meet on some conferences or in some projects.

    OpenEmbedded switched to GIT from Monotone

    After long time of git trail we finally switched to GIT. I hope that Monotone guys will not be sad (we were one of biggest projects according to their wiki) but this system was too slow to handle our metadata.

    I was using GIT during my work with Poky (by git-svn). It really change a way how does people work. Ok, Monotone also has local branches support but it is too slow compared to git.

    During near time I plan to merge some interesting stuff from Poky to OpenEmbedded — for example updates to Maemo libraries and applications.

    Other websites

    My profile on LinkedIn is updated. Got connected to companies which I was working with during my OpenedHand times, got some recommendations etc. BTW - I am in “Szczecin Area, Poland” not “Lublin Area, Poland” (as listed in LI profile) but due to the bug in the system I can not fix it ;(

    After long time Ohloh service managed to handle aliases in OpenEmbedded project so I can claim all my commits in OE repository as mine. The result can be seen in my profile there.

    Written by Marcin Juszkiewicz on
  7. How much RAM/HDD is enough?

    During recent discussions we got into common developer problem — there is no such thing as enough disk space… Later it also expanded to RAM size.

    My current desktop machine has 4GiB of memory and two hard disks with 820GB (763GiB real) of total capacity. And I have only 90GiB of free space on them. So what took most of space? Usual suspects: Poky and OpenEmbedded builds (du -hs took one hour with “160GiB used” result).

    Which get us back to the subject — how much disk space is enough today for development? It depends on area — some people will be fine with less then 100GB, some not. Laptop which I will soon send back to Intel has only 80GB hdd and this is really not enough for me for Poky development (if it has to be the only machine). I know that few persons started to look for 320GB (or larger) disks for their laptops ;D

    OK, with “rm_work” class I was able to do Poky builds with few gigabytes of free space. But small hard drive forced me to forget about using VirtualBox for testing in other distributions then Debian ‘sid’ (which I use on all machines). Currently ~/.Virtualbox on my desktop uses about 70GiB as I have there Fedora 8, Fedora 9, Ubuntu 8.04 and few other distributions which I use for testing does Poky works under them.

    Other thing is doing strange builds… In past I did lot of them — record one took 270GiB of space (and two weeks of building). And I do not like to be space limited when doing them (“rm_work” is not always good way). I still plan to make such big ones from time to time as they allow to check does everything works (and also show new bugs to fix).

    But how much RAM is enough? My previous desktop had 2.1GiB RAM, laptop which I use for x86 builds has only 1GiB. Current desktop has 4GiB of DDR2 (low price made it affordable) and for OpenEmbedded or Poky builds it is more then enough (as no one use BitBake from times when 512MiB ram was not enough to just parse metadata). My machine usually maxx at 2.5-3GiB of used memory during heavy builds. When it will be not enough… I still have 2 slots for RAM free :)

    How it is for other people?

    Written by Marcin Juszkiewicz on
Page 62 / 105