User talk:Hiciu

From Openmoko

Jump to: navigation, search

Maybe we should start listing people involved what they can do to help.

I can probably help with building packages, but maybe it's best to wait for the qemu image for that.

I can also help with providing PKGBUILDs for openmoko specific stuff ( fso, shr apps, zhone etc..).

I also started looking at patches etc. what we probably need (soft float etc.) and editing the PKGBUILDs for them. Is someone already doing this or is there a reason I shouldn't do it? :) I see if I can get the toolchain setup for them. --Beini 22:20, 17 March 2009 (UTC)

I agree. But first of all we should find someone who can lead this thing, someone with leadership capacity. I think I'm not good person for this :). Maybe you? Or we could take someone from Openmoko community, or find someone on Arch forums:

For now I'm missing few important packages (gcc, glibc and other "big" things). After them I will make qemu image and everything should move on. --Hiciu 17:22, 18 March 2009 (UTC)

I did make a new thread on Arch forums : --Beini 19:45, 18 March 2009 (UTC)
ok.. I've made qemu image with Arch x86, scratchbox2, crosscompiler and all other stuff needed to build packages. 992Mb, bzipped, md5: 53314cdef85b1754c7fedd5dc572b221, md5 after bzip -d: e56c1a3dc5f2ad19003f37c62a1207ad.
bzip -d ArchArmDev.img
qemu -m 512 -hda ArchArmDev.img -redir tcp:5555::22

I'm stuck on gcc-* and glibc packages...
--Hiciu 16:53, 23 March 2009 (UTC)

I thought I should give you a little status update, in case you're wondering what am I doing :). So, You were right, gcc-* glibc* etc. refuse to compile under sbox2/makepkg. But I suspect this is a problem with sbox2/cross-compiling. I have succesfully cross-compiled manually some packages which refuse to compile under sbox2 (I think it was gmp... or mpfr). I followed the PKGBUILD but with cross-compiler, and made the package with makepkg -R. This should be close to what you get with compiling in sbox2 and makepkg, I think. At least close enough for our needs because we're going recompile everything under the host/qemu.

But I have ran into an another problem, our toolchain seems to be missing some stuff to cross compile gcc-*. I think the easiest solution would be using another toolchain. But that would require recompiling everything.

I could provide the config for crosstool-ng to build the toolchain. So what's your opinion about using new toolchain and about the manually packaging some packages? --Beini 12:49, 27 March 2009 (UTC)

I think the easiest solution would be using another toolchain. But that would require recompiling everything.

I don't think so. Another (better) toolchain is good idea, but IMO it wouldn't require to recompile everything if we won't change target cpu type and other options.

So what's your opinion about using new toolchain and about the manually packaging some packages?

Ok. Please post instructions how to build it / precompiled package so I can use it too :). --Hiciu 14:29, 28 March 2009 (UTC)

I'm almost ready compiling everything from core, so there's really no need for the toolchain now. I can post the configs later if there's a need but now I'm trying to concentrate getting everything ready. I will find a way getting them all to you for recompiling when I'm ready. But have you seen this?

That would be the easiest solution for our development, right? Just install to chroot, chroot to it, build everything like in host computer.;a=blob;f=app-emulation/qemu-user/qemu-user-0.10.0-r1.ebuild;h=5828c2d6206e3507e4b567dbc4fdca0e2e390581;hb=HEAD

Ebuild and patches for it are there. Could be made quite easily into PKGBUILD, I think. If you want to make the PKGBUILD, it would be great. :) But I can make it too, after I have finished fighting with rest of these packages :P

This would be the easiest way, scratchbox (with -m emulate) works similar to this. I will prepare PKGBUILD. --Hiciu 22:36, 29 March 2009 (UTC)

I posted instructions and config for the toolchain, notice that the CHOST is different with this toolchain. --Beini 12:14, 30 March 2009 (UTC)

This works!


# $Id: PKGBUILD 32318 2009-03-30 06:42:01Z tpowa $
pkgdesc="QEMU is a generic and open source processor emulator which achieves a good emulation speed by using dynamic translation."
arch=(i686 x86_64)

  cd ${srcdir}/qemu-${pkgver}
  unset CFLAGS
  sed -i -e 's/lib64/lib/g' x86_64.ld || return 1
  export LDFLAGS=" -pthread"
  ./configure --prefix=/usr \
              --disable-bluez --disable-blobs \
              --disable-aio --disable-kvm \
              --disable-kqemu --disable-system \
              --disable-sdl --disable-darwin-user \
              --disable-curses --disable-bsd-user \
              --disable-vnc-tls --disable-gfx-check \
              --disable-vde \
              --enable-linux-user --static \
  make || return 1
  mkdir -p ${startdir}/pkg/usr/bin || return 1
  cp arm-linux-user/qemu-arm ${startdir}/pkg/usr/bin/qemu-static-arm || return 1
  chmod 755 ${startdir}/pkg/usr/bin/qemu-static-arm || return 1


pacman -U qemu-static-arm-0.10.1-1-i686.pkg.tar.gz
sudo mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
sudo bash -c 'echo ":arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-static-arm:" > /proc/sys/fs/binfmt_misc/register'

now "install" arch from packages:

mkdir ~/arch-arm-system
cd ~/arch-arm-system
for x in `ls ~/arch-arm-buildroot/pkgs/core`;
  echo $x;
  sudo tar xzf ~/arch-arm-buildroot/pkgs/core/$x;
cp /usr/bin/qemu-static-arm ~/arch-arm-system/usr/bin/

and chroot:

sudo chroot ~/arch-arm-system /usr/bin/qemu-static-arm /bin/bash

--Hiciu 18:30, 31 March 2009 (UTC)

Great! Did you try with pacman instead of tar? That way .install files would get used. The package compilation is taking longer than I expected. I'm compiling some broken packages in qemu with debian arm running and pacman installed. And it's very slow. While I'm waiting bigger packages to build, here's a quick play in gimp ;)

Hi there,

I am not quite sure if this is the right way to say hello but I haven't found any other way to reach you two yet. I am an archlinux user myself and love to get arch running on my FR. Are you still interested in this project? Is the current status being described here the most recent one and how can I help?


-- Harlekin 14:31, 14 April 2009 (UTC+1)

1) yes
2) yes
3) yes ;)
I'm still stuck trying to build glibc, gcc and other big packages with new toolchain. You could help by:

  • setting up your build environment, building missing packages (check pacman -Sg base) and posting them here:
  • AFAIR we still need leader ;)
  • someone should write PKGBUILDs for openmoko-kernel, fso-frameworkd and others
  • maybe we should make new page ( or something).. but this isn't important for now

Current status: I'm sure I can manage to boot ArchLinux on Freerunner with packages from, kernel from fso and (this one is from toolchain, it's linked to many executables). But I tested it only under qemu, not under real device.

--Hiciu 17:57, 7 April 2009 (UTC)

I have the glibc and gcc packages build. Not sure will they work. I will try to get rest of the base build ASAP and test them. I also have PKGBUILD for the kernel from the andy tracking branch. I'm not sure will the packages work with hicius packages, do you want me to dump packages you're missing to your repo? --Beini 20:13, 7 April 2009 (UTC)

yes, please do so (should I make something better / more friendly for uploading packages?) --Hiciu 21:25, 7 April 2009 (UTC)

Ok, I'll start with gcc, gcc-libs and glibc. I have some others too if you need them. But there seems to be a problem: "Warning: POST Content-Length of 24550864 bytes exceeds the limit of 8388608 bytes in Unknown on line 0" Filesize limit too small? :) But the current upload system is fine for now, Let's look into that when we have the "real" repo setup. --Beini 21:53, 7 April 2009 (UTC)

Meanwhile, grab them from here and try them out: --Beini 22:40, 7 April 2009 (UTC)

Currently I am compiling a base system in which I can compile the PKGBUILDs for ARM. I don't know if this is still necessary as you two seem to have made a great progress compiling the base packages. But I thought it couldn't hurt to try it myself. As I like to use gentoo-arm for that task I have lots of time waiting for emerge to finish compiling. I hope I can test building PKGBUILDs this evening or the next morning. (Am I introducing incompability by using gentoo (arm-softfloat-linux-gnueabi, armv5tl, posix threads)? debian-arm gave me troubles using it with qemu and I prefer gentoo over debian.)

In my waiting time I tried to create a small road map listing which packages we have to compile first in order to compile the others from base. I've noticed that we need openssl, libnl, expat. These packages aren't in the base group, but wpa_supplicant and dbus-core depend on them which are.

In case the list is of use to you: (I haven't checked if it correct in total though. Also some make dependencies aren't in it yet.)

Can I reach you guys via IRC or something?


-- Harlekin, 21:19 8 April 2009 (UTC+1)

Beini: your -moko PKGBUILDs looks great!
Harlekin: I'm available on irc (hiciu on #openmoko and #openmoko-cdevel).
Now I'm rebuilding all packages with new toolchain, so far it looks good. In meantime I will try to find (or write) something similar to AUR / some kind of better web gui for repository.
About dependencies: IMO we don't need klibc-*, grub and other x86 stuff.. do we? --Hiciu 08:53, 9 April 2009 (UTC)

If you don't want go through that trouble, i have most of the packages build with the new toolchain. about 140 packages or so. --Beini 08:52, 10 April 2009 (UTC)

It would be great if you could post them somewhere. --Hiciu 15:07, 10 April 2009 (UTC)


RootDir     = /media/disk/
DBPath      = /media/disk/var/lib/pacman/
CacheDir    = ~/pacman/pkg/
LogFile     = ~/pacman/pacman.log
HoldPkg     = pacman glibc

Server =
hiciu[13:35:20]:~|1 sudo pacman --config=pacman.arm.conf -Sy bash coreutils
:: Synchronizing package databases...
 core is up to date
resolving dependencies...
error: cannot resolve "readline>=5.2", a dependency of "bash"
error: failed to prepare transaction (could not satisfy dependencies)
:: bash: requires readline>=5.2

So far it looks good :). --Hiciu 11:48, 11 April 2009 (UTC)

Flyspray: (please register so I can give you access to setup everything)
Repo: (contact me [irc: hiciu on freenode, mail:] for ftp access)
Svn repo: (not ready yet) -> what about --Hiciu 17:25, 11 April 2009 (UTC)

Thanks for setting up the flyspray and the core repo. I'll try installing arch from there shortly. There doesn't seem to be the need for me running gentoo-arm anymore. (:

Do you have any further plans or do we have to discuss where to go from here? What should be our main communication platform? And besides that, would you mind joining #arch-arm on freenode or aren't you two in IRC that frequent that it'd be useful to have a channel?

I'd like to have a domain for that project, but if it should be depends on what we plan to do from here. Maintaining arch for the Neo/Freerunner and maintaining it as general ARM repos aren't the same things or am I mistaken? For instance I could imagine we need a very different base for the Neo as we need for a regular PC. Compile options for the packages could diverge even more, I guess.

Still we shouldn't just abandon your work to a general purpose ARM port and make it available to others. Even maintain it alongside?

-- Harlekin 12:52, 12 April 2009 (UTC+1)

Well... I just want to have Arch on my freerunner ;). I'm not interested in maintain general purpose ARM port... That doesn't mean I'm telling "no" to general ARM port, but I will focus only on freerunner.

Maybe Or something shorter? --Hiciu 17:44, 15 April 2009 (UTC)

Something shorter would be nice. for instance? I agree to your goals. I am not interested in a general ARM port as well, although I don't mind helping out there if I have the time; and I could imagine the problems one encounters are quite similar. Also you've done a great amount of work which would be of interest to anyone who wanted to maintain a general purpose ARM arch port.

-- harlekin 12:26, 16 April 2009 (UTC+1)

Personal tools