arm

[GSoC 2014] Haiku ARM port

Blog post by dnivra on Thu, 2014-04-24 09:29
,
Hello everyone!
Most of you know that 4 students have been chosen to work with Haiku during the Google Summer of Code(GSoC) 2014. My name is Arvind and I am one of the 4 students(yaay!). I will be improving the ARM port and hopefully make significant progress.

The ARM keeps moving...

Blog post by ithamar on Thu, 2012-11-22 20:58
, , ,

The ARM keeps moving...

For people not watching the commit list closely, I've continued to find time to work on Haiku/ARM. So far, things look promising. No new screenshots of any kind though, but more investigation work done to get an idea of what I'm getting myself into. All in all, I'm actually quite pleased...

In my local repository (of which most is actually in the Haiku repository as well, bar some really nasty hacks that not even I dare to commit publicly) I've been able to get to the point where all content for a standard Haiku image is being built (the famous haiku-image target, for the devs reading this). Ofcourse, lots of architecture specific stuff is still stubbed out, but it means that at least there are no surprises lurking to get things to compile at least...

Since I've got a little more confidence in the amount of work needed to get Haiku/ARM up and running on at least a single target, I'll be writing up a proposal for a Haiku, Inc contract. This contract would enable me to focus more on Haiku/ARM for a longer stretch, reserve time in my schedule, with as a target getting some form of basic userland running on a single Haiku/ARM target. From start of next year I should be able to dedicate more time to Haiku/ARM if the contract proposal would get accepted.

Now, I'm not certain I'll commit to any specific target. For the moment, I'm considering to stick to QEMU/Verdex as my main target, but I might switch to some real hardware if needed. Also, some kind of userland could simply be a working "bash" shell, but ofcourse my real hope is to get far enough to see app_server up and running, with Tracker/Deskbar greeting us....

Anyway, short version is that I'm hoping to get Haiku/ARM far enough to make it very easy for other people to join in and port Haiku/ARM to their favorite device, with as little work as possible. It should become as easy as adding hardware support to Haiku/x86, if all goes well.

Time to get back to that source tree.... ;)

Finally a Haiku ARM port update

Blog post by pfoetchen on Tue, 2009-08-18 13:46
, , , ,

After quite some time I finally update my blog ;). A lot has happened in the last few weeks... The Haiku loader that gets loaded by u-boot finally is able to load the kernel and start it and we even have minimal framebuffer support running.

haiku_loader

In the previous posts I said that we would use the U-Boot API to write the loader, the problem with that is, that the API is not accessible on most U-Boots so we could not use it on early boot and had to write our own functions for serial output etc. Because of that the kernel is now loaded from a ramdisk instead of directly loading it from the sd-card as planned (but that might change later...). It also has the disadvantage, that the loader code is not completely platform independent anymore so we would have to rewrite it to be used on a PPC board with U-Boot for example.

Since we still need to know where to find the ramdisk for example (unless we hardcode it..) we decided to use the U-Boot image format that allows packing the loader and the ramdisk in one image and tell the loader where everything is and what parameters to pass to the kernel etc.. For this task U-Boot has OS-specific code since there is no standardized way of doing this. Since there was no Haiku specific code we would either have to convince the U-Boot developers to add Haiku support or simply masquerade as an other operating system. We choose the second option and François Revol added support for the netbsd way of booting so that we get the position of the ramdisk and the kernel parameters and some other info that is not yet used. He also created an jamtarget to allow to build an image directly.

Haiku-ARM progress

Blog post by pfoetchen on Tue, 2009-05-19 16:18
,

I got the kernel to boot "a bit" ;) but since u-boot does not pass the kernel arguments when loading with loadelf I had to fake some kernel arguments etc..
So it's not realy a working system but serial out works ;) (input does not work yet :( ) and I can see some stuff on my screen..
The kernel runs on a emulated gumstix verdex since there is no emulator for the gumsitx overo we will use and the beagleboard emulator did not really work (no sd card support for example) 

[pfoetchen@styleoverfunction verdextest]$ qemu-system-arm -M verdex -m 512 -nographic  -pflash flash.img -sd mmc.img  -p 1234 -d in_asm
pxa2xx_clkpwr_write: CPU frequency change attempt


U-Boot 1.2.0 (May 10 2008 - 21:17:19) - PXA270@400 MHz - 1604

*** Welcome to Gumstix ***

DRAM:  256 MB
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0x90)
Flash: 32 MB
Using default environment

pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0x90)
pflash_write: Unimplemented flash cmd sequence (offset 00000000, wcycle 0x0 cmd 0x0 value 0x90)
Hit any key to stop autoboot:  0 
GUM> mmcinit
Detected: 2097152 blocks of 512 bytes (1024MB) SD card.
Vendor: Man aa OEM XY "QEMU!" Date 02/2006
Product: 3735928559
Revision: 0.1
GUM>  fatload mmc 0:1 0xa2000000 kernel_arm
reading kernel_arm

1641609 bytes read
GUM> bootelf
Loading .interp @ 0xa2500000 (9 bytes)
Loading .hash @ 0xa250000c (22512 bytes)
Loading .dynsym @ 0xa25057fc (57168 bytes)
Loading .dynstr @ 0xa251374c (116718 bytes)
Loading .rel.got @ 0xa252ff3c (152 bytes)
Loading .text @ 0xa252ffe0 (725160 bytes)
Loading .rodata @ 0xa25e1088 (162176 bytes)
Loading .data @ 0xa2608a08 (24504 bytes)
Loading _haiku_revision @ 0xa260e9c0 (4 bytes)
Loading .gcc_except_table @ 0xa260e9c4 (124 bytes)
Loading .ctors @ 0xa260ea40 (120 bytes)
Loading .dtors @ 0xa260eab8 (116 bytes)
Loading .got @ 0xa260eb2c (88 bytes)
Loading .dynamic @ 0xa260eb84 (128 bytes)
Clearing .bss @ 0xa260ec40 (47812 bytes)
## Starting application at 0xa2541d5c ...
Welcome to kernel debugger output!
Haiku revision: 0
INIT: init CPU
INIT: init interrupts
INIT: init VM
PANIC: vm_init: go buy some RAM please.
Welcome to Kernel Debugging Land...
Thread 0 "" running on CPU -0
kdebug>

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.
Syndicate content