Ok, I made those changes to openbios, here is the output.
> On May 8, 2018, at 6:50 AM, Joe van Tunen <joevt(a)shaw.ca> wrote:
>
> : (debug-feval) ( fcode# -- fcode# )
> \ Address
> fcode-stream 1 - . here u. ." : "
>
> \ Indicate if word is compiled
> state @ 0<> if
> ." (compile) "
> then
> dup fcode>xt cell - lfa2name type
> dup ." [ 0x" . ." ]" cr
> ;
The current PReP firmware provided with OpenBIOS is OpenHackWare which provides
a basic set of OpenFirmware interfaces but does this without providing any kind
of Forth implementation which limits its usefulness and compatibility.
Whilst the project has allowed QEMU PReP development to continue to date, it is
sadly now abandonware with no patches for over 4 years, and with no-one willing
to take on maintenance it is now time for a different approach.
This patchset adds PReP support for the QEMU 40p machine allowing it to start
booting NetBSD and the sandalfoot Linux zImage. The main features required for
this are support for the LSI SCSI controller, resdidual data and PReP boot
partitions.
In order to test these patches you'll need a recent QEMU with the following
patches applied:
https://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05480.htmlhttps://lists.gnu.org/archive/html/qemu-devel/2018-05/msg05964.html
Next you'll need an updated openbios-ppc binary, and for those without access to
a cross-compiler setup I've uploaded the resulting binary to
https://www.ilande.co.uk/tmp/qemu/openbios-ppc.prep.
To boot the sandalfoot zImage from http://www.juneau-lug.org/zImage.initrd.sandalfoot
you can do:
qemu-system-ppc -M 40p -bios openbios-ppc.prep -cdrom zImage.initrd.sandalfoot
-boot d
Note that it seems to get stuck trying to initialise the LSI SCSI controller,
presumably due to a bug in the existing QEMU emulation.
NetBSD works much better and in fact boots all the way to userspace:
qemu-system-pcc -M 40p -bios openbios-ppc.prep -cdrom NetBSD-7.1.2-prep.iso
-boot d -nographic
In terms of functionality I think this patchset is just about there: there are a
few questions around device names but hopefully someone with real PReP experience
can point me in the right direction.
Finally I've added various people on CC who have expressed interest in PReP and/or
OpenHackWare in the past: if this is no longer of any interest to you, do let me
know and I'll drop your email address from future versions.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (11):
pc_kbd: ensure that we properly reset the 8042 controller and keyboard
device
pci: rename i82378 keyboard device from 8042 to keyboard
pci: add AMD PCNET information to PCI database
bootcode_load: ensure LOADER_NOT_SUPPORT is returned if no bootcode is
present
ppc: add PReP support to dma-map-in
pci: add driver for LSI 53C810 SCSI controller
ppc: add PReP residual data block
ppc: use proper context when pre-loading kernels
pc-parts: allow successful detection of PReP boot partitions
libopenbios: add PReP boot partition loader for PPC
prep: disable VBE extensions when executing client program
arch/ppc/qemu/context.c | 129 ++++++-
arch/ppc/qemu/context.h | 1 +
arch/ppc/qemu/init.c | 34 ++
arch/ppc/qemu/kernel.h | 1 -
arch/ppc/qemu/main.c | 11 +-
arch/ppc/qemu/switch.S | 43 ---
arch/ppc/qemu/tree.fs | 5 -
config/examples/ppc_config.xml | 2 +
drivers/build.xml | 1 +
drivers/lsi.c | 770 ++++++++++++++++++++++++++++++++++++++++
drivers/pc_kbd.c | 22 +-
drivers/pci.c | 21 +-
drivers/pci_database.c | 14 +
drivers/pci_database.h | 1 +
drivers/vga.fs | 11 +
forth/debugging/client.fs | 1 +
include/arch/ppc/residual.h | 116 ++++++
include/drivers/drivers.h | 4 +
include/drivers/pci.h | 6 +
include/libopenbios/prep_load.h | 24 ++
libopenbios/bootcode_load.c | 2 +
libopenbios/build.xml | 1 +
libopenbios/initprogram.c | 8 +
libopenbios/load.c | 11 +
libopenbios/prep_load.c | 106 ++++++
packages/pc-parts.c | 10 +
26 files changed, 1300 insertions(+), 55 deletions(-)
create mode 100644 drivers/lsi.c
create mode 100644 include/arch/ppc/residual.h
create mode 100644 include/libopenbios/prep_load.h
create mode 100644 libopenbios/prep_load.c
--
2.11.0
This patchset is something I've been working on for a while and started
off with the aim of getting rid of the "dma-alloc" console warnings
whilst booting *BSD images on PPC, but ended up as a full implementation
for SPARC32/SPARC64 and PPC.
The patchset is fairly straightfoward: the first few patches rework the
SPARC32 DVMA functions to make them usable from Forth, whilst patch 8
adds a missing D-cache flush for PPC which could certainly do with another
set of eyes.
The remainder of the patches add PPC and SPARC64 support before adding
in the complete "dma-*" $call-parent chains to enable devices to call
the DMA functions as indicated in the IEEE-1275 specification and
various FCode examples found around the net.
Finally the last 2 patches switch the esp SCSI driver over to use the
IEEE-1275 Forth words instead of calling the low-level C functions
directly.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (15):
dma: add defers for the dma-* words
SPARC32: rename dvma_alloc()'s ba variable to iova
SPARC32: allocate contiguous physical memory for DVMA
SPARC32: implement dvma_map_in() for DMA IOVA to phys translation
SPARC32: move pgtsrmmu.h from arch/sparc32 to include/arch/sparc32
SPARC32: implement dvma_sync() function for synchronising DMA memory
SPARC32: implement dma-* words
PPC: add flush_dcache_range() to start.S
PPC: implement dma-* words
SPARC64: implement dma-* words
macio: add missing REGISTER_NODE for New World macio devices
pci: add dma-* call-parent chain to all PCI devices and bridges
sbus: add dma-* call-parent chain to all PCI devices and bridges
esp: switch creation of esp device over to use new-device
esp: switch over to using dma-alloc/dma-map-in
arch/ppc/qemu/init.c | 35 +++++++
arch/ppc/qemu/kernel.h | 1 +
arch/ppc/qemu/start.S | 21 ++++
arch/ppc/qemu/tree.fs | 40 ++++++++
arch/sparc32/lib.c | 2 +-
arch/sparc32/ofmem_sparc32.c | 2 +-
arch/sparc32/openbios.c | 47 ++++++++-
arch/sparc32/tree.fs | 56 +++++++++++
arch/sparc64/openbios.c | 40 ++++++++
arch/sparc64/tree.fs | 47 +++++++++
drivers/esp.c | 159 ++++++++++++++++++++----------
drivers/ide.c | 40 ++++++++
drivers/iommu.c | 95 +++++++++++++++---
drivers/macio.c | 36 +++++++
drivers/pci.c | 40 ++++++++
forth/device/other.fs | 8 +-
forth/device/table.fs | 2 +-
forth/util/util.fs | 9 ++
{arch => include/arch}/sparc32/pgtsrmmu.h | 0
include/drivers/drivers.h | 4 +-
packages/disk-label.fs | 39 ++++++++
21 files changed, 646 insertions(+), 77 deletions(-)
rename {arch => include/arch}/sparc32/pgtsrmmu.h (100%)
--
2.11.0
Here are a couple of minor fixups which have been kicking around my
OpenBIOS git repository for a little while.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
ppc: don't hardcode the system bus frequency
macio: set correct UniNorth device revision
arch/ppc/qemu/init.c | 4 ++--
drivers/macio.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--
2.11.0
If you’ll note, the one thing that jumps out at me, in the 6602.txt( openbios ), abort is called 50 times, yet it doesn’t appear at all in the 6600.txt( SLOF ).
This may have something to do with the fact that SLOF reaches the end of the Fcode without error.
> On May 8, 2018, at 3:41 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote:
>
> Not sure if this is what you’re asking for, but the verbose output of both Openbios and SLOF executing the option rom.
>
> <6600.txt>
> <6602.txt>
>
>
>> On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt(a)shaw.ca <mailto:joevt@shaw.ca>> wrote:
>>
>> Can you send the full output directly to me or post a link?
>>
>
>
>
>> Can you check the value of "here" before byte-load and after the exception to see how much dictionary space was used?
>
> Not sure how to check the value of here?
Ok,I got a little excited, [ddf] vs [dff].
Sometimes I’m easily confused.
> On May 7, 2018, at 10:54 AM, Joe van Tunen <joevt(a)shaw.ca> wrote:
>
>
>
> On 5/7/18, 4:56 AM, "Segher Boessenkool" <segher(a)kernel.crashing.org> wrote:
>
> On Mon, May 07, 2018 at 07:33:04AM -0400, Jd Lyons wrote:
>> Ok, I think the reason for the exception with [dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works on Apple’s implementation of OF, but Openbios and SLOF deal with things a little different.
>>
>> s” /pci/@x” select-dev
>>
>> That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is no active device tree node.
>
> You should use begin-package and new-device or the like. See the Open
> Firmware specification glossary entries for those words and byte-load .
>
>> Doesn’t anyone know how I can view the active device tree node?
>
> my-self ihandle>phandle ( -- phandle) and do some stuff with that,
> or just use pwd .
>
>
> Segher
>
>
>
> Is there a reason this thread isn't going to the openbios mailing list?
>
> Do you mean [dff] or [ddf]? Wasn't the evidence pointing to [ddf]?
>
> [ddf] calls the parent's map-in function a few times. The "PCI Bus Binding to Open Firmware" document mentions a bug with map-in which existed in Apple's original Open Firmware implementation. Do QEMU and the Quicksilver G4 both have a correctly implemented map-in function?
>
> What is the maximum dictionary space allowed by QEMU's OpenBIOS? If the maximum is reached, does it grow or does an exception occur? It's probably not likely that the nvidia fcode is exceeding this limit, but it would be good to have a method to confirm this.
>
>
>
Sorry, that wan me forgeting to include the list.
> On May 7, 2018, at 10:54 AM, Joe van Tunen <joevt(a)shaw.ca> wrote:
>
>
>
> On 5/7/18, 4:56 AM, "Segher Boessenkool" <segher(a)kernel.crashing.org> wrote:
>
> On Mon, May 07, 2018 at 07:33:04AM -0400, Jd Lyons wrote:
>> Ok, I think the reason for the exception with [dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works on Apple’s implementation of OF, but Openbios and SLOF deal with things a little different.
>>
>> s” /pci/@x” select-dev
>>
>> That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is no active device tree node.
>
> You should use begin-package and new-device or the like. See the Open
> Firmware specification glossary entries for those words and byte-load .
>
>> Doesn’t anyone know how I can view the active device tree node?
>
> my-self ihandle>phandle ( -- phandle) and do some stuff with that,
> or just use pwd .
>
>
> Segher
>
>
>
> Is there a reason this thread isn't going to the openbios mailing list?
>
> Do you mean [dff] or [ddf]? Wasn't the evidence pointing to [ddf]?
>
> [ddf] calls the parent's map-in function a few times. The "PCI Bus Binding to Open Firmware" document mentions a bug with map-in which existed in Apple's original Open Firmware implementation. Do QEMU and the Quicksilver G4 both have a correctly implemented map-in function?
>
> What is the maximum dictionary space allowed by QEMU's OpenBIOS? If the maximum is reached, does it grow or does an exception occur? It's probably not likely that the nvidia fcode is exceeding this limit, but it would be good to have a method to confirm this.
>
>
>
> On May 7, 2018, at 7:33 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote:
>
>
>
>> On May 6, 2018, at 8:12 PM, Joe van Tunen <joevt(a)shaw.ca> wrote:
>>
>> It is unclear to me if the exception is caused by compiling the fcode or interpreting (executing) it. Your verbose output (which I'm unfamiliar with) shows only "(compile)". Without trying it myself or looking at Apple's byte-load code, I'm guessing that's some kind of context, and perhaps there's an interpret (execute) context? Can you send the full output directly to me or post a link?
>>
>> Can you check the value of "here" before byte-load and after the exception to see how much dictionary space was used? I wonder if an exception would cause a rewind of some kind, or just leave everything as is.
>>
>> The fcode in question is at the top level and looks like this:
>>
>>
>> new-token 0xe38
>> b(:)
>> ...
>> b(;)
>> b(') (unnamed-fcode) [0xc84]
>> b(to) (unnamed-fcode) [0x9a9]
>> (unnamed-fcode) [0xe34]
>> (unnamed-fcode) [0xdff]
>> (unnamed-fcode) [0x93d]
>> b(lit) 0xf
>> <>
>> b?branch 0x0026 ( =dec 38)
>> (unnamed-fcode) [0x9bd]
>> b(lit) 0xff
>> and
>> my-space
>> +
>> (unnamed-fcode) [0xa08]
>> b(lit) 0x6
>> and
>> b(lit) 0x4
>> =
>> b?branch 0x0009 ()
>> b(') (unnamed-fcode) [0x9c1]
>> b(to) (unnamed-fcode) [0x9c0]
>> b(>resolve)
>> b(>resolve)
>> (unnamed-fcode) [0xddf]
>> ...
>>
>>
>> Since it's at the top level, it probably must be getting executed. The problem might be in executing 0xddf (defined earlier in the fcode).
>>
>> Once I get my fcode token to forth converter updated (so it can be used with Unix/macOS instead of MPW) then you can make your own nvidia open firmware driver with added debugging code.
>>
>> You should look at the 1275.pdf document "IEEE Standard for Boot (Initialization Configuration) Firmware: Core Requirements and Practices" to get a description of the tokens. "b?branch ... b(>resolve)" are the tokens for the forth "if ... then" statements (when the b?branch fcode offset is positive). The document also describes how a token behaves while the fcode evaluator is in interpretation state and compilation state.
>>
>>
>> On 5/6/18, 8:11 AM, "Jd Lyons" <lyons_dj(a)yahoo.com> wrote:
>>
>> Ok, now that I know we can load a Fcode Rom for an nVidia card in Apple’s Open Firmware implementation, I figured I try this again.
>>
>> I have to catch up a little one what we did before, so I maybe tripping over something I got passed before.
>>
>>> true to ?fcode-verbose
>>> “ /pci/@10” open-dev to my-self
>>> load hd:,\ppc\6600.rom
>>> 4000040 1 byte-load
>>
>> …….
>>
>>
>> (offset) 26
>> 400fff9 : (compile) [ 0x9bd ]
>> 400fffa : (compile) b(lit) [ 0x10 ]
>> 400ffff : (compile) and [ 0x23 ]
>> 4010001 : (compile) my-space [ 0x103 ]
>> 4010002 : (compile) + [ 0x1e ]
>> 4010004 : (compile) [ 0xa08 ]
>> 4010005 : (compile) b(lit) [ 0x10 ]
>> 401000a : (compile) and [ 0x23 ]
>> 401000b : (compile) b(lit) [ 0x10 ]
>> 4010010 : (compile) = [ 0x3c ]
>> 4010011 : (compile) b?branch [ 0x14 ]
>> (offset) 9
>> 4010014 : (compile) b(') [ 0x11 ]
>> 4010017 : (compile) b(to) [ 0xc3 ]
>> 401001a : (compile) b(>resolve) [ 0xb2 ]
>> 401001b : (compile) b(>resolve) [ 0xb2 ]
>>
>> byte-load: exception caught!
>> ok
>> 0 > 4010014 200 dump
>> 4010014 11 09 c1 c3 09 c0 b2 b2 0d df 0e 04 0e 38 0e 06 ..��.���.�...8..
>> 4010024 0c e5 0d b0 0e 07 0e 1a 0c 5b 0e 28 0e 20 0d fa .�.�.....[.(. .�
>> 4010034 0e 37 0e 2c 0e 2d 12 0b 4e 56 44 41 2c 50 61 72 .7.,.-..NVDA,Par
>> 4010044 65 6e 74 02 01 a6 01 11 12 0e 23 61 64 64 72 65 ent..�....#addre
>> 4010054 73 73 2d 63 65 6c 6c 73 01 10 a5 01 11 12 0b 23 ss-cells..�....#
>> 4010064 73 69 7a 65 2d 63 65 6c 6c 73 01 10 09 c7 09 3d size-cells...�.=
>> 4010074 10 00 00 00 35 42 14 00 0d a6 09 33 27 09 35 24 ....5B...�.3'.5$
>> 4010084 c3 09 35 b2 09 41 10 00 00 00 10 27 09 35 24 01 �.5�.A.....'.5$.
>> 4010094 11 12 0d 4e 56 44 41 2c 46 65 61 74 75 72 65 73 ...NVDA,Features
>> 40100a4 01 10 a6 01 11 12 0a 4e 56 44 41 2c 4c 65 76 65 ..�....NVDA,Leve
>> 40100b4 6c 01 10 a5 a5 0e 2e 09 bc 09 c3 0e 2e 01 12 09 l..��...�.�.....
>> 40100c4 c0 09 c6 0e 2e 01 12 09 be 09 c4 0e 2e 01 12 09 �.�.....�.�.....
>> 40100d4 bf 09 c5 0e 2e 01 12 12 03 72 65 67 01 10 a6 01 �.�......reg..�.
>> 40100e4 11 12 0e 23 61 64 64 72 65 73 73 2d 63 65 6c 6c ...#address-cell
>> 40100f4 73 01 10 a5 01 11 12 0b 23 73 69 7a 65 2d 63 65 s..�....#size-ce
>> 4010104 6c 6c 73 01 10 12 1a 3a 20 64 65 63 6f 64 65 2d lls....: decode-
>> 4010114 75 6e 69 74 20 70 61 72 73 65 2d 31 68 65 78 20 unit parse-1hex
>> 4010124 3b cd 0c 7c 47 01 11 4a 01 11 01 12 12 0c 56 52 ;�.|G..J......VR
>> 4010134 41 4d 2c 6d 65 6d 73 69 7a 65 01 10 a5 c3 09 52 AM,memsize..��.R
>> 4010144 09 51 a5 18 00 16 19 0a 41 0a 4a 08 ea 3d 14 00 .Q�.....A.J.�=..
>> 4010154 08 19 c3 09 52 1b b2 15 ff ee 09 46 38 14 01 b0 ..�.R.�.��.F8..�
>> 4010164 09 52 0a 41 01 1f 0e 32 b5 0e 39 b7 09 52 0a 41 .R.A...2�.9�.R.A
>> 4010174 0d f1 c3 01 62 c2 b5 0e 3a b7 09 52 0a 41 0d f2 .��.bµ.:�.R.A.�
>> 4010184 c2 b6 08 67 65 74 2d 6d 6f 64 65 0e 3b b7 0d cb ¶.get-mode.;�.�
>> 4010194 c2 b6 0a 73 68 6f 77 2d 6d 6f 64 65 73 0e 3c b7 ¶.show-modes.<�
>> 40101a4 0d cc c2 ca 08 73 65 74 2d 6d 6f 64 65 0e 3d b7 .���.set-mode.=�
>> 40101b4 09 52 0a 41 0d ca c2 ca 0e 64 72 61 77 2d 72 65 .R.A.���.draw-re
>> 40101c4 63 74 61 6e 67 6c 65 0e 3e b7 09 52 0a 41 0d d5 ctangle.>�.R.A.�
>> 40101d4 c2 ca 0e 66 69 6c 6c 2d 72 65 63 74 61 6e 67 6c ��.fill-rectangl
>> 40101e4 65 0e 3f b7 09 52 0a 41 0d d7 c2 ca 0e 72 65 61 e.?�.R.A.���.rea
>> 40101f4 64 2d 72 65 63 74 61 6e 67 6c 65 0e 40 b7 09 52 d-rectangle.@�.R
>> 4010204 0a 41 0d d6 c2 ca 06 63 6f 6c 6f 72 21 0e 41 b7 .A.���.color!.A�
>> ok
>> 0 > my-self . fc5ac34 ok
>>
>> I think this is the point I got to before. I’m not real sure what is going wrong here?
>>
>> Seems to be tripping over the second b(>resolve), tho I’m not sure what this fcode is trying to do?
>>
>> Joe, see if you can have a look at it, when you have time, and see if you have any ideas what is causing the exception.
>>
>> b?branch 0x0009 ()
>> b(') (unnamed-fcode) [0x9c1]
>> b(to) (unnamed-fcode) [0x9c0]
>> b(>resolve)
>> b(>resolve) <—Here?
>> (unnamed-fcode) [0xddf]
>> (unnamed-fcode) [0xe04]
>> (unnamed-fcode) [0xe38]
>> (unnamed-fcode) [0xe06]
>> (unnamed-fcode) [0xce5]
>> (unnamed-fcode) [0xdb0]
>> (unnamed-fcode) [0xe07]
>> (unnamed-fcode) [0xe1a]
>> (unnamed-fcode) [0xc5b]
>> (unnamed-fcode) [0xe28]
>> (unnamed-fcode) [0xe20]
>> (unnamed-fcode) [0xdfa]
>> (unnamed-fcode) [0xe37]
>> (unnamed-fcode) [0xe2c]
>> (unnamed-fcode) [0xe2d]
>> b(") ( len=0xb [11 bytes] )
>> " NVDA,Parent"
>> device-name
>> 1
>> encode-int
>> b(") ( len=0xe [14 bytes] )
>> " #address-cells"
>> property
>> 0
>>
>>
>
> Ok, I think the reason for the exception with [dff] is I don’t have an active device tree node. So, “ /pci/@x” open-dev to my-self works on Apple’s implementation of OF, but Openbios and SLOF deal with things a little different.
>
> s” /pci/@x” select-dev
>
> That works in SLOF, otherwise SLOF throws an exception with [dff] and tells us there is no active device tree node.
>
> Using that code in Openbios still raises the same exception at 401005b, but I really think it’s the next thing [dff], it can’t resolve the device?
>
> Doesn’t anyone know how I can view the active device tree node?
>
>
>
>
>>
>>
>>
>>
>> --
>> OpenBIOS http://openbios.org/
>> Mailinglist: http://lists.openbios.org/mailman/listinfo
>> Free your System - May the Forth be with you
>
