gsoc2009

Porting Haiku to ARM architecture

Blog post by pfoetchen on Tue, 2009-04-21 23:35

Personal Profile

  • Johannes Wischert
  • Brief bio - I'm a computer science student living in Germany. I'm 25 years old now. I wrote my first program with 8 or 9 years or so and never stopped since then... After my studies I want to work somewhere in the embedded systems development but by now I enjoy my studies and take my time to finish.

Project idea information

  • Project title - Port the Haiku Kernel to ARM-Architecture
  • List of project goals -
    • generic u-boot Bootloader using the u-boot apis as far as possible to ease porting to other platforms that use u-boot
    • Kernel that runs on the arm-processor and supports all applicable features that the x86 kernel has
    • Device driver for at least the SD-card and the Serial-Port
    • Working system running on a Beagleboard or similar device
  • Project description -
    • To get the system running on an ARM-CPU we first need a working Haiku ARM toolchain to compile the code I already got the toolchain to run and produce working binaries (tested under qemu) so this part of the system already works more or less. see: http://dev.haiku-os.org/ticket/3633
    • After that done the next step is the boot loader. Since the beagleboard I want to target already has "Das U-boot" bootloader installed I decided to use it to get the kernel loaded. Using the u-boot loader has some advantages since it already provides all the important data and functions for loading the kernel like builtin serial drivers and drivers for all kind of memory to boot from (including a TFTP client) these functions are exposed by a simple platform independent API. By using this API an architecture independent kernel loader could be build, so that porting to other architectures that use u-boot would be much easier.
    • The loader would run as a standalone application on top of u-boot to use it's features and then switch to direct access to the hardware to run the kernel.
    • To allow u-boot to boot the kernel I could either include bfs in u-boot or implement the bfs in the loader programm. If the bfs code is in the loader no change to u-boot is needed so I will probably take this way since changing the u-boot always has the risk to brick a device.
    • I know that this is not everything and I will probably have to ask a lot of questions to get everything right ;)
    • I must admit that I don't know to much about the ARM internals, yet so I can't give much details about how I will port the MMU dependent stuff etc.
    • The device drivers for the serial-port and the sd-card are quite straight forward to implement, since they are interfaced directly by the processor (at least on the beagleboard) and there are a lot of existing open source drivers (of course we would have to pay close attention to the licenses etc...)
    • Since the beagleboard does not have an isa or pci bus it could use code similar to the m68k port to put the onboard devices in the pci bus. Even better would be to write a sort of bus system for the onchip devices this would also help to port to other devices that do not realy have a bus system like many other embedded devices.
    • The next steps would be to write a driver for the onchip usb-controler and a Framebuffer driver if the porting goes much faster than I think ;)
  • Why do you want to work on this project?
    • I love the whole concept of Haiku and would love to see it run on embedded hardware like all these planned linux+arm netbooks. Since ARM-CPUs are used in so many different devices and most of these devices are multimedia devices like netbooks/mediaplayers/smartphones it would make sense to port Haik as an multimedia OS to these devices.
    • I already have experience in embedded programing for example I ported an OS from the MSP430 to the SuperH Architecture for university (it was a nano kernel OS called SmartOS there is a wiki about this project but for whatever reason they have the interesting parts hidden http://www5.informatik.uni-wuerzburg.de/snow5xoops/modules/dokuwiki/doku...? ) so I know a bit about all the problems that could arise.
    • I know porting such a complex project is quite difficult but I have the time to concentrate on this project and it's not the first embedded project I work on (but probably the biggest ).
    • Other projects I worked on were a device driver for the r4ds flash card to use it under DSLinux on the Nintendo DS and some other smaller stuff like a stepper motor controler board that was controlled by an MSP430.
    • I know that this project is not really helpful to get closer to the first alpha release of haiku but I think an ARM port would be a interresting addition to the Haiku project and perhapse attract some more developpers.

Integrate WebKit in Haiku native browser, My GSoC proposal.

Blog post by maxime.simon on Tue, 2009-04-21 14:13

Personal Profile

  • Maxime Simon

  • Brief biography:

    I am currently in my third year studying Computer Science at Rennes 1 University in France.

    I have some experience with development thanks to several academic projects, chiefly written using the Java and C languages.

    Our first big project used an obscure language called "oRis", an object and agent-oriented language developed as part of the doctoral thesis of Fabrice Harrouet. The project's objective was to design a simulation of pathfinding robots, with basic behaviour and capable of cooperating to achieve goals in a virtual maze. This project enabled us to learn how to manage a project using Subversion, and how to organise its development.
    The project was managed at this page:
    http://code.google.com/p/csr/

GSoC project : Internationalization for Haiku

Blog post by PulkoMandy on Tue, 2009-04-21 08:02

Hello world !
As you know, I am one of the selected students for this year summer of code. In this post I will introduce myself and give some details about my project.

My name is Adrien Destugues, some of you may know me as PulkoMandy as i've been lurking on the irc channel and mailing lists for some time. I already applied for the Summer of Code and Haiku Code Drive last year but unfortunately I was not selected. This year it went better :)
I'm studying electronics and computer science at the ENSSAT (École Nationale Supérieure de Sciences Appliquées et de Technologie), in Lannion, France. I used to run BeOS as my main operating system for some time, but I now switched to Linux. I have a running Haiku install on my hard disk, but as my network card is not supported, I don't use it much for everyday work. I hope this will change soon.

Now, some information on my project: the idea was born because we were talking about "which os is better" on the ENSSAT mailing list, between linux, mac os X and windows (the kind of endless discussion student have all the day long ;)). I sent a link to Haiku homepage to point the fact that there was other alternatives, and someone replied "hey, it doesn't even speaks french!". This fact is quite annoying for an operating system targeted to regular users, and not powerful computer geeks. Not everyone speaks english, and this is what an user will see first when running Haiku for the first time. So I decided to improve that and get Haiku internationalized. I did some research on the web and found informations about localization under BeOS. There was a locale kit in zeta, but the Haiku team had already started another project as part of Open Tracker. It was not integrated into Haiku because of some problems, the main one being the way the Be API is used to create windows. As the translated texts have a different length than the original ones, the window may look bad with overlapping texts and other problems similar to font sensivity.
The Layout system can now solve that, so it's about time to get the Locale Kit back to work.

The locale kit must do various things. It provides a way to translate strings, of course, but also offers services for formatting date, time, numbers and currencies. Each country have different rules for that, and any program can ask the locale kit to do the formatting properly. Another service is a natural order sorter, which sort a set of strings alphabetically but with special rules for accents, diacritics, and so on. Of course, all of this has to be done at runtime. This way the language is selected and configured with a simple preflet and all opened applications are instantly translated.
Some kind of compatibility with zeta locale kit and gnu gettext would be nice, it would allow to use translations from other systems, either directly or by using a conversion tool.

The basic layout for all that is already in place in OpenTracker's Locale Kit. However, most of the code is not written, for example there is no code for date formatting, for loading Zeta's catalog files. The API is well designed, so I will keep most of it, and fill in the missing functions. The ICU library will be used as a backend for everything except the translation. It provides all the needed data for doing all the formatting work properly.

The translation can be done with string-based or key-based lookup. The Locale Kit handles a list of catalogs, some of them are specific to an application and some are system- or user-wide. Catalogs can be stored on hard disk as plain files, resources in an application executable or bfs attributes. Catalog format can be added in the form of add-ons.

List of project goals
1) Integrate OpenTracker's Locale Kit to the Haiku build system. I've already got it building as part of the 3rdparty/ folder, and got the basic tests working. However a proper integration will need to get out of 3rdparty and fully integrated to the build system.
2) Create an example localizable "Hello World" application and test it. It will allow two things: testing of the kit and showing to programmers the way to use this kit properly.
3) Integrate the ICU library to do the collation (alphabetical sorting) and date/time/number/currency formatting. Don't try to reproduce their huge work in getting a database for all the countries. Modify their code so it compile cleanly under gcc2 (if needed) and integrates cleanly in the Be API.
4) Design and create a preflet for easily changing the language while running Haiku. It will have the following features :
* edit the settings for date, numbers and currencies and save them as user defined settings,
* allow to change the default settings for a country for all these settings,
* allow the user to select his preferred languages in a sorted list.
5) Create tools for translating an application. We need to extract translatable strings from a .cpp source file, and to save a compiled catalog for use at runtime. The current tools are working only under Haiku, and we need them under linux as part of Haiku's build process. If needed, change the catalog format to make it easy to work with, or add an importer add-on to read and write text files.
6) Write an importer (catalog add-on) for Zeta's catalogs and test it with some applications providing a Zeta catalog.
7) Write an importer for GNU gettext format.
8) Modify the code of all the preflets and applications in haiku so they use the localization system (if there is some time left at the end of summer ;))

Syndicate content