Just wanted to give you an update where I'm currently procrastinating on.
The bootloader was actually easy to do, but there is a catch. It was setting
the ELFSIZE #define to 64 bit in /usr/src/sys/arch/aim64/stand/main.c and
it from then on loads a 64 bit kernel. Only on execution it has problems.
When I let it execute it soon falls into an Illegal Instruction which is what
I'd expect coming from 32 bit mode and encountering a 64 bit instruction.
Only I'm unsure that it's entering the kernel at the right offset. In the
illegal instruction it is accompanied by a SRR0 and SRR1 display of where it
encountered this and I've written the SRR0 down (it's 2304 I assume that's
hex). I find that hard to believe that this is right. Since in the ELF I'm
using readelf to look at this and the entry point is at 0x100120...where is
my logic wrong? Here a readelf -a output of a powerpc64 kernel:
Magic: 7f 45 4c 46 02 02 01 00 00 00 00 00 00 00 00 00
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Entry point address: 0x100120
Start of program headers: 64 (bytes into file)
Start of section headers: 8449240 (bytes into file)
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 2
Size of section headers: 64 (bytes)
Number of section headers: 13
Section header string table index: 10
Anyhow, since 6.4 was released I'm going to be upgrading my vps network over
the course of next week and also I want to make the cross-compiler build
environ build on 6.4 which will require a bit more work. I want to make it
presentable so that someone can help me with this as we're at a stage where
many people can give it a shot and provide feedback, I just gotta let them and
make the building sources available.
So far I've been building the cross-compiler in a vmm dedicated for this task,
and the 6.4 vmm will be dedicated for this as well. I'm thinking of perhaps
making an entire vmm available for download, but we'll see.
One more thing I wanted to show you, I got this bit from FreeBSD and it's in
mfmsr %r20 /* get MSR */
li %r21, 1 /* load immediate 1 */
insrdi %r20, %r21, 1, 0 /* set PSL_SF */
mtmsrd %r20 /* write back to MSR */
isync /* we should be 64 bit now */
These are the very first op instructions that should set the processor in
64 bit mode. However there is a paradox that I can think of. If the processor
is in 32 bit mode, how can register %r20 be 64 bit? and I need it to be 64
bit in order to set 0x8000000000000000 which is the MSb (63rd bit). I have
also tried jumping to 0x100 to cause a cpu reset which sets this bit on 64
bit capable powerpc's. But I'm unsure of it returning in that case. I think
0x100 must first be patched and I haven't written the opcodes for that yet.
Not sure if it's needed. I hung out a bit on a FreeBSD channel where I got
some good input from someone but the systems are pretty different.
So on multiple things I'm stuck on, and hoping the community would help out
Oh ya one more thing. In order to know that I'm entering the kernel at the
right offset I'd like it to indicate on console that it's hit it right, so
I was thinking of it printing something like "!obsd!", can someone write the
32 bit asm for that, for me? I'd put it before entering the 64 bit mode on
start, so that I have a debug that this offset was really hit.
If you have a better suggestion I'm all ears. I'm not that good in asm and
if I'd be doing it it'd take a bit longer...
Almost end of week again. I'm making an amd64 vmm image available that others
can help if they want. The image contains my cross-build enviroment which I
have just upgraded to 6.4. Please see more information at
I'm stuck on a linker problem I think. Yesterday I investigated why my
entry to the powerpc64 kernel would not work right by setting a few "trap"
commands in the locore0.S asm source. I came to the conclusion that whenever
it tries to jump to a location provided by C source code it would get a 380
exception. After investigating the kernel with objdump and nm I noticed that
the C function .initppc does not have a T (for text) in an nm output. To show
you a comparison between 2 other archs there is a lot of T symbols in the
I also tried "fixing" the binutils patch I got from someone by placing this:
aimee# more elf64ppc_obsd.sh
TRAP=0x0000000000000000 # guaranteed always illegal
(that is from /usr/src/gnu/usr.bin/binutils-2.17/ld/emulparams/elf64ppc_obsd.sh)
Really I don't know what I'm doing at this point and have to count on you guys
What could cause the lack of T(ext) symbols in my kernel? I'm getting a feeling
it's the linker other than that it would be the GNU assembler that I'm using.