1. Palm Pre and OpenEmbedded

    Nearly month ago we got information that Palm company uses OpenEmbedded to build software for their Palm Pre smartphone. Two weeks later I read on Matthew Garret blog that there is root filesystem image available on one of Palm websites.

    What is inside? Many interesting things — you can read about it on Matthew’s post so I will not repeat. If someone wants to look inside then please take a look at /usr/lib/ipkg/ directory. It contains packaging informations which shows which packages were installed, which files were used etc. It is clearly visible that they used OpenEmbedded with own overlay separated — OE was in /home/reviewdaemon/projects/nova/oe/foss and Palm overlay in oe/palm directory. The missing thing is IP address of “subversion.palm.com” server which is used to store additional sources (propertiary and free ones). What else we can find? Build information which says that rootfs was built at 2009.05.22 14:00:49. And according to audio setup files development started in September 2008 (if not earlier).

    I wonder what kind of board they used as developer kit (they also used ARM Versatile emulation in QEMU).

    UPDATE: Palm SDK uses “qemux86” device from OpenEmbedded to run WebOS.

    Written by Marcin Juszkiewicz on
  2. Sending files over Bluetooth to S60 devices

    I use Nokia E66 phone. It runs S60 3rd edition FP1 (aka Symbian 9.2). When I switched to it sending files over Bluetooth was easy: obexftp -b BD:AD:RR:EE:SS:00 -p FILE1 FILE2 and files landed as messages in phone Inbox. But for some time it is not working — all I got was “Sending FILE1…failed” like messages.

    Hopefully obexftp tool has some options available so after some tests I got it working. And result is even better as files lands in file system instead of Inbox. The trick is to give path on phone to obexftp: obexftp -b BD:AD:RR:EE:SS:00 -c E:/folder/on/card -p FILE1 FILE2 and files will land there.

    Simple, nice and the most important: working :D

    Written by Marcin Juszkiewicz on
  3. TI: please fix your USB

    I have BeagleBoard in B7 revision. So the only USB port which is available is the OTG one. I use self made host cable which connects 4 port hub (with own power supply). This gives me keyboard, mouse and Ethernet.

    Or rather should give… Current situation (2.6.29-angstrom) is that I do not have any USB devices available because kernel do not recognize them — at least not on each reboot. During last 10 reboots nothing was found…

    So Texas Instruments engineers: do something about it please about your drivers.

    And no, buying C3 revision is not an option — I will rather wait for version with non-USB Ethernet on board.

    UPDATE: if you have U-boot 2009.01 then flash 2008.xx one or 2009.06 from Ångström. This will give you back standard behaviour of MUSB: ‘throw a dice, if you will get 5 then USB will rather work’.

    Written by Marcin Juszkiewicz on
  4. EP93xx fight continued…

    During my recent OpenEmbedded related work I merged gcc patchset from Martin Guy to add support for Maverick Crunch FP unit present in Cirrus Logic EP93xx ARM cpus. This makes floating point operations faster then it was before.

    But does using it has a sense for whole system? Is it possible at all? The answers are No and Yes. I have root filesystem for EDB9301 created with Maverick optimisations but I also have plain armv4t one for same board. They both work but I do not recommend using Crunch optimized one — there are strange errors. For example “HZ=5.33381e-315” is given instead of “HZ=100” in openssl speed test (problem is somewhere in glibc).

    Let me quote Martin’s mail:

    My current recommendation is to enable crunch only in the floating point intensive libraries and applications that your application system uses, because having more than one crunch-enabled process running in the system makes the context switches slower because the kernel has to save and restore 19 64-bit registers at every context switch. It doesn’t bother doing this if only one process is using the FPU thanks to some clever Buytenhek laziness). I don’t have figures for how much of a difference this makes, but I guess one could calculate it from the context switching rate shown in the output of “vmstat 5” and the instruction times.

    I switched “ep93xx” machine in OE back to armv4t optimisations. Also I am working on adding some more EP93xx related patches from Hasjim Williams (he made first set of patches for OpenEmbedded and Martin Guy improved them and moved to newer GCC).

    One note for end of story — I am not interested in doing more ep93xx toolchain work. If your device/company need such help then contact Martin Guy for consulting offer.

    Written by Marcin Juszkiewicz on
  5. My opinion on next Nokia tablet

    There is a new set of rumours on websites about next Nokia tablet. Name it N900 (speculation name) or Rover (which is internal name) or famous N00 which probably is on prototypes (Nokia uses N00 on proto phones and tablets).

    As Jamie Bennett wrote on his blog it will be hard to sell this tablet. He compares it to netbooks but I see other device to buy instead — Touchbook which has similar internals but higher resolution (1024x600 instead of 800x480) on bigger screen (8.9” instead of 3.5”). OK, it will not have GSM like N900 but I do not care about it — my current phone is good enough.

    And then goes other problem — Maemo. I used Maemo 2005/6/7/8 on Nokia 770 and N810 and ok, it is fine and working system but… It is niche system — small amount of applications available and no other environments then Hildon one (chroot with KDE which runs in window under Hildon does not count).

    And question is how open will it be for other operating systems/distributions — I hope that Nokia will not follow 770/n8x0 way.

    Written by Marcin Juszkiewicz on
  6. Moblin 2.0 User Interface

    Yesterday Moblin team released new UI for their system. And most of “Moblin team” are my colleagues from OpenedHand times. It is nice to see what they were working on during time when we no longer worked in same team.

    I have to admit that I did not tried Moblin 2.0 beta. None of my machines use Atom cpu and I do not plan to check how it works on my desktop machine (1920x1080 is bigger then 1024x600 used by netbooks so results could be strange). I read Ars Technica review and watched introduction video on YouTube. But they show how many projects were used to produce one product. Maybe not finished yet but impressive enough to track it’s future.

    Will I use it one day? Hard to tell — it looks like lacking some components like mail or IRC client (I do not like being forced to use IM client for IRC).

    Written by Marcin Juszkiewicz on
  7. Sheevaplug arrived

    Recently I joined group of Sheevaplug owners. It is amazing how small it is…

    Simple tests shows that CPU is faster then OMAP3 used in BeagleBoard but this is not a surprise — 1200MHz compared to 600MHz makes a difference. And they are two different types of devices.

    What use I have for it? Some native builds and it will be my local TFTP/NFS server — I just have to connect 4GB pendrive to it. Ah… I also have to install Ångström on it first as using Ubuntu is not in my style. Especially not with 512MB flash used as JFFS2 partition…

    Some useful links for those who wonder how to get Sheevaplug working:

    Written by Marcin Juszkiewicz on
  8. Cursing Intel

    I am using Dell D400 laptop as my 32bit test machine and during conferences. It has Pentium-M cpu and Intel 855GM/ICH4 chipset. And this is where problem starts…

    As I like to use text console on it I wanted to get XGA (1024x768) framebuffer on it. So first try was “use intelfb”. But “video=intelfb:mode=1024x768-32@60” or “modprobe intelfb mode=1024x768-32@60” results in same message:

    [ 1760.280291] intelfb: Framebuffer driver for Intel(R) 830M/845G/852GM/855GM/865G/915G/915GM/945G/945GM/945GME/965G/965GM chipsets
    [ 1760.280368] intelfb: Version 0.9.6
    [ 1760.280471] intelfb: 00:02.0: Intel(R) 855GM, aperture size 128MB, stolen memory 892kB
    [ 1760.289927] intelfb: Non-CRT device is enabled ( LVDS port ).  Disabling mode switching.
    [ 1760.290251] intelfb: Video mode must be programmed at boot time.
    

    The solution is to give kernel “vga=792” argument but it is not possible here as kernel thinks that 800x600-8 is highest available one.

    OK, I can use X11 and terminal there — this works fine. But why kernel got so broken? Probably Intel developers do not test their changes on something older then i945 chipsets (and thats only because it is used in Atom based devices).

    Looks like I need to do “git bisect” to check when it broke and then create some hack to get proper behaviour…

    Written by Marcin Juszkiewicz on
Page 58 / 106