OSDev.org

I recently saved a HPPA machine from the computer graveyard, with the intention of making a port for it. (All i have is a large collection of x86s and some embedded devices, so supporting a new architecture is completely new to me) So i decided to give it a try.

However, things didnt run as smoothly as i expected: the linux ports all manage to get into a kernel panic. The 64 bit kernels wont even get to a panic...
To make things worse: a cross-compiled GAS (2.17) won't assemble the standard bootloader (called PALO), GCC doesn't compile (3.4.4, 4.1.1), and all of PALO sources contain too few comments to deduce their actual workings. And HP's docs aren't that great a source of information.

Summarized, i'm stuck without development tools and no really practical information.

Does anybody here have any experience with the HPPA architecture or any other clues as to what goes wrong?

Edit: solution details near the bottom.

I know, you hate me etc etc..

But in any sense, I would recommended checking out the NetBSD or OpenBSD HPPA ports.

They might be good code bases to borrow code from here and there...

NetBSD's port supports the hp700 series CPU.
http://www.netbsd.org/Ports/hp700/

Here is the OpenBSD related page.
http://www.openbsd.org/hppa.html

(Not sure if this is useful to you but I'll post it anyway..)
http://www.openbsd.org/hppa64.html

Be sure to look at the bottom of each of the OpenBSD pages, They provide links to various pieces of documentation that might be helpful in your porting effort

Your input is appreciated, but without a toolchain all code sources are pretty much worthless. Apart from that, my box (a D380) isn't supported.

For the information, i've tried compiling the set again under linux, resulting in the same messages. Does anybody know of needed patches or different pa-risc supporting toolchains, since writing my own assembler or having to work around bugs is the last thing i want.

Brynet-Inc wrote:I know, you hate me etc etc..

Most definately NOT - You're just a nuisance picking fights and advocating BSD a few times too often

Hmmm... I know that the the UCLA LUG managed to get Debian onto a bunch of HPPA's, and they (IIRC) said that they hadn't run into any problems. Not sure what model they were, though...

i used to have like a c340 or something. the hppa boxes had some serious chipset issues and cache issues from what I remember, and with little to no documentation

*bump*

I wanted to let you know that I managed to get a basis to solve the problem. I had to patch GCC and read through a lot of mailinglists to get the basics done.

I managed to build a working binutils (2.17) and gcc (4.2.2) with hppa-elf as the target on cygwin. Details in the wiki. Basically it involved trial-and-error composition of a new GCC target (I stole a few details from the hppa-pro target) and patching gcc-x.x.x/gcc/config.gcc.

The GCC output is however very dependent on two components: the gcc support code, and the HPPA millicode. The first is the libgcc.a which is compiled together with GCC, the millicode comprises of the common instructions that are not directly implemented in the CPU (to know, multiplication, division, modulo, and indirect calls), which does not get bundled with gcc. It neither is provided with binutils, nor (g)libc as the google searches suggest. I didn't bother asking Hewlett Packard since it required registration.

Instead, I picked it up from a linux kernel patch, and reading the sources its origin are said to come from GCC, which I just verified did not have it.
I commited the millicode sources as part of my os development tree for later. You can pick it up there or download the entire source distribution, which is probably easier than downloading the entire linux kernel and applying the patch manually.

With the millicode in place, I could compile and link some test programs as expected. It still chokes on the PALO bootloader - I'll have to check wether it is a remaining gcc thing or that it is missing the symbols for the hppa firmware...

final note: GAS does not work as stated in the manual - it will properly assemble gcc-generated output, but it does not eat the vast majority of pseudo-ops it is said to support.