Hi everyone,
I've been spending some time over the past few weeks trying to get a
Sparc64/Solaris disk image to boot under qemu, and as far as I can tell,
the first reason that the code terminates incorrectly is because
b?branch doesn't work.
This can be demonstrated fairly easily using the following couple of
Fcode programs. Note that while I'm working on Sparc64, I see the same
issue on x86 OpenBIOS too.
Example 1: b?branch with -1 on stack: ignore branch & abort
CC \ offset16
10 \ b(lit)
FF FF FF FF \ (-1)
14 00 04 \ b?branch
02 16 \ if false, abort
9D \ if true, display stack
00 \ end
0 > true to ?fcode-verbose ok
0 > here CC10FFFFFFFF1400 /n allot over ! ok
1 > here 0402169D00000000 /n allot over ! drop ok
1 > 1 byte-load
byte-load: evaluating fcode at 0xffd9d128
fcode-table at 0xffdb7f90
offset16 [ 0xcc ]
b(lit) [ 0x10 ]
b?branch [ 0x14 ]
abort [ 0x216 ]
byte-load: exception caught!
ok
Example 2: b?branch with 0 on stack: skip abort, display stack
CC \ offset16
10 \ b(lit)
00 00 00 00 \ (0)
14 00 04 \ b?branch
02 16 \ if false, abort
9D \ if true, display stack
00 \ end
0 > true to ?fcode-verbose ok
0 > here CC10000000001400 /n allot over ! ok
1 > here 0402169D00000000 /n allot over ! drop ok
1 > 1 byte-load
byte-load: evaluating fcode at 0xffd9d128
fcode-table at 0xffdb7f90
offset16 [ 0xcc ]
b(lit) [ 0x10 ]
b?branch [ 0x14 ]
abort [ 0x216 ]
byte-load: exception caught!
ok
Okay, so did anyone notice the difference?! This led me to look into the
definition of b?branch in forth/device/fcode.fs:
\ b?branch ( continue? -- )
\ Conditional branch FCode. Followed by FCode-offset.
: b?branch
['] do?branch ,
fcode-offset 0< if \ if we jump backwards, we can forsee where it goes
resolve-dest
else
here
0 ,
then
; immediate
By adding some extra debugging into b?branch, I can see that for the
above Fcode, do?branch is *never* called, although it correct takes the
"else" branch listed above.
I'm still reasonably new to Forth, but AIUI, all the code above does is
allocate one cell to store the xt of do?branch, and in the case of a
forward branch, push the here location onto the stack and then store 0
into another allocated cell. This agrees with my investigation that
shows that do?branch is never actually called.
Given that this code is also missing a section that will read and
discard Fcode-offset-2 bytes for a forward branch, I'm inclined to think
that this code is just wrong. Can anyone else with any experience with
this code comment upon this?
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
While booting a 64bit kernel, there is a small timeframe where OF and
the kernel communicate with each other. Within that timeframe, DSI/ISI
interrupts may occur, because some memory is not mapped yet.
Right now in case that happens, we jump into the DSI/ISI interrupt
handler which clobbers the high 32 bits of the kernel's registers. In
order to circumvent that, let's save/restore all 64 bits of all kernel
registers when we get a DSI/ISI interrupt.
This patch enables a PPC64 Linux kernel to boot up to the point where
it tries to set up the SLB entries (slbmte), which is not yet
implemented in qemu.
v2 implements handling for the HIOR register, bringing interrupt
handlers to RAM.
Signed-off-by: Alexander Graf <alex(a)csgraf.de>
While booting a 64bit kernel, there is a small timeframe where OF and
the kernel communicate with each other. Within that timeframe, DSI/ISI
interrupts may occur, because some memory is not mapped yet.
Right now in case that happens, we jump into the DSI/ISI interrupt
handler which clobbers the high 32 bits of the kernel's registers. In
order to circumvent that, let's save/restore all 64 bits of all kernel
registers when we get a DSI/ISI interrupt.
In order to make use of this patch in qemu, a separate patch is
required that makes qemu not run the interrupt handlers from ROM, but
from RAM. It will follow on the qemu list shortly.
This patch enables a PPC64 Linux kernel to boot up to the point where
it tries to set up the SLB entries (slbmte), which is not yet
implemented in qemu.
Signed-off-by: Alexander Graf <alex(a)csgraf.de>
This patch enables OpenBIOS to initialize on PPC64, enabling support
for -cpu 970fx.
It gets up to the boot prompt and works rather good so far, though I
haven't been able to run a kernel yet.
For more recent PowerPC CPUs the PTE layout has changed, so we need to
take that into account and create PTEs according to the new layout and
at the new physical positions.
v2 takes Laurent's comments into account
Signed-off-by: Alexander Graf <alex(a)csgraf.de>
On 2/27/09, Anthony Liguori <anthony(a)codemonkey.ws> wrote:
> Hi,
>
> I wanted to see how we look from a release perspective. For x86, I think
> things are looking pretty good. There are a couple outstanding patches that
> need more review (like the CVE fix) but I think we'll be ready in a few
> days.
>
> How are the other architectures looking? Are there any major bug fixes
> people are working on? PPC is now fully converted to OpenBIOS, right?
Yes, except for PREP.
There are recent patches to make PPC64 work that should be committed
in the coming days. That would be a nice addition but not critical.
We have also discussed about making also an OpenBIOS (1.0) release,
the previous release candidate (1.0RC1) is more than year old. It
would be great to release Qemu with 1.0 OpenBIOS.
Overall, there should be an update of the OpenBIOS images, otherwise
Sparc32 and I think PPC32 are ready. Sparc64 will not be without major
miracles in any case. PPC64 case may be interesting.
This patch enables OpenBIOS to initialize on PPC64, enabling support
for -cpu 970fx.
It gets up to the boot prompt and works rather good so far, though I
haven't been able to run a kernel yet.
For more recent PowerPC CPUs the PTE layout has changed, so we need to
take that into account and create PTEs according to the new layout and
at the new physical positions.
Signed-off-by: Alexander Graf <alex(a)csgraf.de>
On Tue, 2009-02-24 at 22:27 +0200, Blue Swirl wrote:
>
> Would this patch fix the problem?
Doesn't look like it. After patching and make clean, I see the same
warning from strip, and basically the same output:
# tail obj-ppc/build.log
[...]
powerpc-440-linux-gnu-ld --warn-common -N -T ../arch/ppc/qemu/ldscript target/arch/ppc/qemu/start.o target/arch/ppc/timebase.o libqemu.a libbootstrap.a libdrivers.a libmodules.a liblibc.a libfs.a libgcc.a -o openbios-qemu.elf
powerpc-440-linux-gnu-nm openbios-qemu.elf | sort > ./openbios-qemu.syms
cp openbios-qemu.elf openbios-qemu.elf.nostrip
powerpc-440-linux-gnu-strip openbios-qemu.elf
BFD: stzD2J6q: warning: allocated section `.bss' not in segment
BFD: stzD2J6q: warning: allocated section `.sbss' not in segment
# readelf -l obj-ppc/openbios-qemu.elf*
File: obj-ppc/openbios-qemu.elf
Elf file type is EXEC (Executable file)
Entry point 0xfff08000
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000094 0xfff00000 0xfff00000 0x100000 0x100000 RWE 0x4
LOAD 0x100094 0xfffffffc 0xfffffffc 0x00004 0x00004 R E 0x1
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping:
Segment Sections...
00 .text.vectors .text .rodata .data .bss .sbss
01 .romentry
02
File: obj-ppc/openbios-qemu.elf.nostrip
Elf file type is EXEC (Executable file)
Entry point 0xfff08000
There are 3 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x000094 0xfff00000 0xfff00000 0x42044 0x4bcb4 RWE 0x4
LOAD 0x0420d8 0xfffffffc 0xfffffffc 0x00004 0x00004 R E 0x1
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping:
Segment Sections...
00 .text.vectors .text .rodata .data
01 .romentry
02
--
Hollis Blanchard
IBM Linux Technology Center