The OQO odyssey – Part 2

This article is part of the OQO odyssey series – You might want to read Part 1 first.

As the windows installation was finished, I am adding my default software set containing Firefox, Thunderbird, OpenOffice, Antivir and some Sysinternals-Tools.

But if you remember the first article about the installation, I have left 15 GB for a Linux installation on that UMPC. The gentoo LiveCD will be just fine for this job. For better readability, I recommend using the gentoo-nofb kernel. A positive side effect might be, that the unknown hardware will surely handle the common terminal.

The OQO booted up and arrived on the common bash prompt waiting for my commands. This must be my lucky day. Let’s start with some hardware inspection by looking at /proc/cpuinfo for some decent information about the brick here:

livecd ~ # cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineTMx86
cpu family      : 6
model           : 4
model name      : Transmeta(tm) Crusoe(tm) Processor TM5800
stepping        : 3
cpu MHz         : 999.211
cache size      : 512 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr cx8 sep cmov
mmx longrun lrti up
bogomips        : 2014.40

Our victim is a Crusoe CPU made by Transmeta – a CPU consisting of three-fourths Software and one-fourth of Hardware. Bummer – that’s strange. Well: The Crusoe emulates x86 architecture with a limited instruction set. For a little speed gain, the internal code morphing system works with 128 bit. But what does limited instruction set mean for us? Code alignment functions are unsupported.

As I want to run Gentoo on that UMPC, there’s no way around the GCC Documentation for determining the correct CFLAGS. Code alignment can be turned off by using -Os. So I’d suggest using the following settings:

-march=i686 -Os -mmmx -pipe -fomit-frame-pointer

Our little journey into cpu architectures might be fun, but I guess heading to the rest of the hardware might be fun too. The PCI bus offers the following devices:

livecd ~ # lspci
00:00.0 Host bridge: Transmeta Corporation LongRun
 Northbridge (rev 04)
00:00.1 RAM memory: Transmeta Corporation SDRAM controller
00:00.2 RAM memory: Transmeta Corporation BIOS scratchpad
00:00.3 RAM memory: Transmeta Corporation Unknown device 0399
00:03.0 Multimedia audio controller: ALi Corporation
 M5451 PCI AC-Link Controller Audio Device (rev 02)
00:05.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A
 IEEE-1394a-2000 Controller (PHY/Link)
00:06.0 VGA compatible controller: Silicon Motion, Inc.
 SM720 Lynx3DM (rev c1)
00:07.0 ISA bridge: ALi Corporation M1533/M1535 PCI to
 ISA Bridge [Aladdin IV/V/V+]
00:0c.0 USB Controller: NEC Corporation USB (rev 43)
00:0c.1 USB Controller: NEC Corporation USB (rev 43)
00:0c.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
00:0f.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
00:11.0 Bridge: ALi Corporation M7101 Power Management
 Controller [PMU]

As I’m clueless about if this would ever work, I start doing the partition scheme as I’m about to run out of power soon. You know, the power supply is semi-broken…

livecd ~ # fdisk -l /dev/hda
Disk /dev/hda: 30.0 GB, 30005821440 bytes
255 heads, 63 sectors/track, 3648 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1        1824    14651248+   7  HPFS/NTFS
/dev/hda2            1825        3648    14651280    5  Extended
/dev/hda5   *        1825        1831       56196   83  Linux
/dev/hda6            1832        1894      506016   82  Linux swap / Solaris
/dev/hda7            1895        2381     3911796   83  Linux
/dev/hda8            2382        3648    10177146   83  Linux

The boot partition will have 50 MB for being able to test some kernels on Ext2. 512 MB Swap and 5 GB Portage should leave enough free space for the root filesystem.

As there is still some power left I start with downloading the stage file and a manual sync of the gentoo portage. Just in time the battery is out now and I’m shutting the device down for now. See you later folks!

This entry was posted in IT Related stuff and tagged , , , , . Bookmark the permalink.

14 Responses to The OQO odyssey – Part 2

  1. JJ says:

    Hi Stargazer,
    Have a look at this:


  2. TK says:

    Does this flags “-march=i686 -Os -mmmx -pipe -fomit-frame-pointer” works (without errors on compilation – bootstrap) ?

    Will they work on Transmetya Efficeon with current gcc, because this on Safe Cflags from Gentoo Linux Wiki doesn’t work.

  3. Stargazer says:

    The OQO device was too weak to survive a complete bootstrap on device. But on a bigger CPU the whole process worked flawless.

    Regarding the Transmeta Efficion, I haven’t had a chance to test things. But in general, those flags should work. If you are in doubt, plain i686 optimization should do the trick.

  4. TK says:

    Saying “plain i686 optimization should do the trick” you mean using only “-march=i686″ flag in make.conf ?

  5. Stargazer says:

    The cflags I have used should work for your CPU too. If not, you may try to reduce the cflags. I’d say “-march=i686″ is the last try before giving up…

    What device are you trying to compile on, if I may ask?

  6. TK says:

    It’s ECS 532.

  7. Stargazer says:

    The cpu itself should be able to deal with those cflags: “-O2 -march=i686 -fomit-frame-pointer -mmmx -msse -msse2″

    keep in mind, it’s the successor of the crusoe I was using here…

  8. TK says:

    It’s ECS 532 with Transmeta Efficeon.

  9. Stargazer says:

    So it should work. But keep in mind – stage 1 and bootstraping is not (officially) supported anymore.

    As far as I remember, Perl and Libperl were missing some modules in the stage1 archive tarball. So it’s not the CPU which is causing the problems

  10. TK says:

    And which version of stage did you use: stage1 or stage3 ?

    By the way, I read on some gentoo web page that if I change flags in make.conf (after I used stage3), I have to recompile all chainloader (run bootsrap).

  11. Stargazer says:

    I usually stick to stage1 – but that’s more or less because of the strange CPUs I am having.

    Regarding CHOST changes, there is a nice document on the gentoo page. Any other flags don’t really need a recompile of the toolchain.

  12. TK says:

    Can I use “-falign-functions=0 -falign-jumps=0 -falign-loops=0″ flags for Transmeta Efficeon,maybe those flags make errors on compiling ?

  13. Stargazer says:

    You surely can test it – but I wouldn’t use too fancy flags as such flags might break things.

  14. Toei Rei says:

    Usually all those flags starting with -f like -falign are considered to be evil and break things. So best thing is – as Stargazer already said: keep the flags simple

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Notify me of followup comments via e-mail. You can also subscribe without commenting.