[PATCH 0/2] gcc 9 build fixes
by Mark Cave-Ayland
During the past couple of weeks I've updated my build chain to use gcc 9.1
which generates some additional warnings that cause the build to fail
when building with -Werror.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
Mark Cave-Ayland (2):
all: gcc 9 build fixes
ppc: reduce size of Forth dictionary to 384K
arch/ppc/qemu/kernel.c | 4 ++--
arch/sparc32/context.c | 2 +-
drivers/cuda.c | 4 ++--
drivers/ide.c | 2 +-
drivers/pmu.c | 4 ++--
fs/hfs/hfs_fs.c | 2 +-
packages/nvram.c | 2 +-
7 files changed, 10 insertions(+), 10 deletions(-)
--
2.20.1
12 hours, 13 minutes
- 4
- 8
Muti CPU Support
by Jd Lyons
I’ve been working a little to see if I can get multi-threaded TGC to work for the Mac OS/X in qemu, but Openbios doesn’t seem to support more than one CPU and doesn’t build any device for a second CPU.
I’ve looked at the openbios/arch/ppc/qemu/init.c, and that seems to be the place to apply a patch for multi cpu support, but I don’t really seem any graceful way of doing it.
Can anyone offer any help?
TGC-Work/bin/qemu-system-ppc -M mac99,via=pmu -serial stdio -smp 2,cores=2,threads=1 -accel tcg,thread=multi -cpu g4 -boot c -prom-env auto-boot?=true -prom-env boot-args=-v -hda /Users/jam/os9.2.1.img -m 256 -bios /Users/jam/aty7/openbios/obj-ppc/openbios-qemu.elf
heathrow_class_init: init 2
core99_machine_class_init: init 2
qemu-system-ppc: warning: Guest not yet converted to MTTCG - you may get unexpected results
s>> et_property: NULL phandle
>> =============================================================
>> OpenBIOS 1.1 [Aug 6 2019 02:05]
>> Configuration device id QEMU version 1 machine id 1
>> CPUs: 2
>> Memory: 256M
>> UUID: 00000000-0000-0000-0000-000000000000
>> CPU type PowerPC,G4
milliseconds isn't unique.
>> switching to new context:
>> call-method slw_update_keymap failed with error ffffffdf
>> call-method slw_update_keymap failed with error ffffffdf
13 hours, 34 minutes
- 3
- 7
[PATCH v3 00/30] pci: build device tree from root
by Mark Cave-Ayland
This patchset started off with the aim of building the PCI-based machine
device trees downwards from the root node to avoid switching either the active
package and/or current instance at various points during the tree construction.
The basis for this was to try and remove all named nodes (those which are
placed at a given path) and instead build the hierarchy in order by using
new-device and finish-device as per the IEEE-1275 specification. This was
realised by creating a new BIND_NODE_METHODS() macro which is similar to
REGISTER_NAMED_NODE() except that it doesn't alter either the active package
or the current instance, and then working through the device tree from the
root converting all the devices for the PCI-based machines to use it.
Once this conversion has been completed for all devices beneath the PCI node,
it becomes possible to remove both the REGISTER_NAMED_NODE() and
REGISTER_NAMED_NODE_PHANDLE() macros to prevent future patches from accidentally
changing the tree construction order.
Next the x86, PPC and SPARC64 device tree roots were altered to set the active
package and current instance, allowing the remaining places where the PCI code
alters either of them to be removed.
At this point instance variables were working correctly, and I noticed that
there were several PCI devices which made use of C initialisation functions and/or
properties for initial configuration. These can now be replaced with instance
variables to keep everything simple and consistent.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayland(a)ilande.co.uk>
v3:
- Rebase onto master
- Fix up USB debug string for keyboard reported by Zoltan
- Fix for creating devices that don't have an entry in the PCI database
- Fix for MacOS 9 not initialising network reported by Howard
v2:
- Fix up NVRAM initialisation so that -prom-env 'vga-ndrv?=false' works again
Mark Cave-Ayland (30):
libopenbios: introduce BIND_NODE_METHODS() macro
pc_kbd: convert to use BIND_NODE_METHODS() macro
pc_serial: convert to use BIND_NODE_METHODS() macro
floppy: convert to use BIND_NODE_METHODS() macro
ide: convert to use BIND_NODE_METHODS() macro
adb: convert to use BIND_NODE_METHODS() macro
escc: convert to use BIND_NODE_METHODS() macro
cuda: convert to use BIND_NODE_METHODS() macro
macio: convert to use BIND_NODE_METHODS() macro
pmu: convert to use BIND_NODE_METHODS() macro
usbhid: convert to use BIND_NODE_METHODS() macro
nvram: convert to use BIND_NODE_METHODS() macro
lsi: don't change active package when setting device alias
lsi: convert to use BIND_NODE_METHODS() macro
virtio: convert to use BIND_NODE_METHODS() macro
pci: convert to use BIND_NODE_METHODS() macro
pci: remove ob_pci_initialize() and ob_pci_empty_node
libopenbios: remove REGISTER_NAMED_NODE and
REGISTER_NAMED_NODE_PHANDLE macros
nvram: ensure that NVRAM configuration is separate from NVRAM node
creation
ppc: move New World uninorth and nvram device node creation to the
root device
ppc: set active package and current instance to root device node
before probe
SPARC64: set active package and current instance to root device node
before probe
x86: set active package and current instance to root device node
before probe
pci: remove explicit find-device from PCI devices
pci: remove explicit setting of my-self from PCI devices
pci: call set-args before configuring PCI device nodes
pc_serial: remove separate init word
pc_kbd: use instance value to initialise C instance parameter
lsi: use instance value to hold sd_private_t pointer
virtio: use instance value to initialise C instance parameter
arch/ppc/qemu/init.c | 18 +++-
arch/sparc64/openbios.c | 6 ++
arch/x86/openbios.c | 9 +-
drivers/adb_bus.c | 57 +++++++-----
drivers/adb_kbd.c | 25 ++++--
drivers/adb_mouse.c | 31 ++++---
drivers/cuda.c | 158 ++++++++++++++++++++-------------
drivers/escc.c | 113 ++++++++++++++---------
drivers/floppy.c | 68 +++++++-------
drivers/ide.c | 123 +++++++++++++++----------
drivers/lsi.c | 65 +++++++-------
drivers/macio.c | 118 ++++++++++++------------
drivers/macio.h | 1 -
drivers/pc_kbd.c | 48 +++++-----
drivers/pc_serial.c | 32 +++----
drivers/pci.c | 132 +++++++++++++--------------
drivers/pmu.c | 152 +++++++++++++++++++++----------
drivers/usbhid.c | 17 ++--
drivers/virtio.c | 56 +++---------
include/drivers/drivers.h | 2 +
include/libopenbios/bindings.h | 19 ++--
include/packages/nvram.h | 4 +-
libopenbios/bindings.c | 10 +++
packages/nvram.c | 35 ++++++--
24 files changed, 755 insertions(+), 544 deletions(-)
--
2.20.1
1 day, 3 hours
- 1
- 30
Re: R128 interrupts
by Jd Lyons
I’m 99% sure this is the trouble, I don’’t really understand IRQ’s and interrupts, there is some info in the Rage_128_register_referance_guide.
I tested my theory via OS X 10.4.11and it mapped the VRAM rather than giving me the ATY:Not Usable, it also changed the screen resolution twice, once to 640x480 then to 1280x960.
dev /pci/@f
“ /pci/@f” select-dev
“ ATY,Rage128Pd” encode-string “ name” property
1 encode-int “ interrupts” property
boot
OS X would not be able to change the screen resolution if the ‘NDRV’ didn’t load!!!
So I’m 99% sure this is the trouble and we need to figure out how to create a mapped interrupt for the card, rather than this dummy
Interrupt I create because I’m a dummy;-)
> On Aug 8, 2019, at 12:41 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote:
>
>
> Could be the Rage128 ‘NDRV’ is aborting do to the lack of an interrupt……….
1 week, 4 days
- 3
- 4
Experiments with OpenFirmware
by BALATON Zoltan
Hello,
On Tue, 30 Jul 2019, BALATON Zoltan wrote:
> 3. Try to get some other OF implementation working like OpenFirmware. Based
> on previous work by Atar for the 40p this is possible although to do it
> cleanly may be more work and hindered by the need to do it in Forth
> completely. But Forth is needed to hack on OpenBIOS as well so once someone
> gets over that hurdle it does not matter. I've started looking at this
> posibility to find out how much work would this be that's why I was asking
> the question. I've compiled Atar's work which is now upstram in Mitch
> Bradley's tree and it worked well with 40p and even started with pegasos2 but
> of course it did not init the hardware correctly expecting to run on 40p
> (haven't tried with mac99 but I expect the same result). So OpenFirmware
> already works on PPC and has some QEMU specific drivers what we may need is
> porting drivers for mac specific and pegasos2 devices from OpenBIOS from C to
> Forth (or get equivalents from somewhere else) and think about how to pass
> the initial device tree similar to SLOF to avoid having to implement each
> board in OpenFirmware separately (although doing hardcoded board
> implementation like Atar's 40p might be a quick and dirty way to get it
> working with much less work).
I gave it a try playing with it for a few hours (without really knowing
what am I doing) just to get to know it better and see what's needed. So I
started by stripping down Atar's QEMU PReP port removing PReP specific
parts and just leaving a bare minimum to work on PowerPC and I actually
managed to build a ROM image that works with my pegasos2 emulation and
gets me an OF environment over diag serial port now:
$ qemu-system-ppc -M pegasos2 -bios ofw.rom -serial stdio
setup_mem_windows: Should enable region 14
Mapping pci1-io-win 0x0+0x2000000 @ 0xfe000000
setup_mem_windows: Should enable region 20
Type 'i' to interrupt stand-init sequence
First stand-init:
Calibrate
CIF buffers
DHCP init
memory node
Instruction cache on
Decrementer
Enable machine check exceptions
Set Memory Map
MMU
Root node
Data cache on
Fast CPU mode
PCI host bridge
CPU nodes
Keyboard overrides
Memory node
not found.
not found.
/pci/isa/serial@i2f8 not found.
/pci/isa/serial@i2f8 not found.
not found.
not found.
, Serial #0, 128 MiB memory installed
Open Firmware
Copyright (c) 1995-2000, FirmWorks.
Copyright (c) 2014,2017,2019 Artyom Tarasenko.
Type any key to interrupt automatic startup
6 5 4 3 2 1
Boot device: net Arguments:
Can't open boot device
ok show-devs
/dropin-fs
/null-nvram
/cpus
/<Unnamed>
/mmu
/memory@0
/aliases
/options
/openprom
/chosen
/packages
/cpus/PowerPC,603evARTHUR@0
/packages/ext2-file-system
/packages/disk-label
/packages/iso9660-file-system
/packages/fat-file-system
/packages/obp-tftp
/packages/deblocker
/packages/stringio
/packages/terminal-emulator
/packages/client-services
ok printenv
Variable Name Value Default Value
hrp-memmap? false false
virt-size 0x0 0xffffffff
virt-base 0x0 0xffffffff
real-size 0x0 0xffffffff
real-base 0x0 0xffffffff
real-mode? false false
diag-switch? false false
fcode-debug? false false
ip-address 255.255.255.255 255.255.255.255
ip-router
ip-domain
ip-netmask 255.255.255.0 255.255.255.0
ip-dns-server
local-mac-address? false false
oem-logo
oem-logo? false false
oem-banner
oem-banner? false false
output-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8
input-device /pci/isa/serial@i2f8 /pci/isa/serial@i2f8
load-base 4194304 4194304
boot-command boot boot
auto-boot? true true
watchdog-reboot? false false
diag-file
diag-device net net
boot-file
boot-device disk net disk net
ansi-terminal? true true
screen-#columns 80 80
screen-#rows 34 34
silent-mode? false false
use-nvramrc? false false
nvramrc
security-password
security-#badlogins 0
security-mode none
diag-switch? false false
ok dev /
ok .properties
#address-cells 00000001
ok dev openprom
ok .properties
model FirmWorks,3.0
aligned-allocator
relative-addressing
name openprom
ok dev /cpus/PowerPC,603evARTHUR
ok .properties
clock-frequency 05f5e100
reg 00000000
timebase-frequency 007de290
tlb-sets 00000080
tlb-size 00000100
d-cache-sets 00000080
d-cache-block-size 00000020
d-cache-size 00008000
i-cache-sets 00000080
i-cache-block-size 00000020
i-cache-size 00008000
device_type cpu
name PowerPC,603evARTHUR
ok
Of course it's only the start and has a lot of missing parts yet: does not
detect PCI bus and devices (I need to write a driver for the PCI host
similar to what Atar did for 40p), it misdetects the CPU (or it may be
hard coded somewhere), does not detect memory size (this is mentioned on
Atar's blog) and may have other defficiencies. But for a start it works
quite well and it was surprisingly easy to get it up thanks to previous
work. Given that the Pegasos2 is quite close to PReP and PC hardware most
of the drivers for PC like hardware are already there in OF, so maybe if I
can make a working driver for the system controller chip the rest would
just work or should be relatively easy to fix. So for the pegasos2 this
seems to be a viable alternative that may not be too hard to get working
if I limit the scope to just the pegasos2.
For Mac machines more drivers would need to be written as these are not
included in the open source OF version that was released for OLPC so only
those drivers are included which were needed for that. Therefore it would
be more work to write those missing drivers. We have USB driver (I've once
tried porting that to OpenBIOS[1]) so keyboard and mouse might work where
we have USB but we would still need drivers for uninorth and mac-io at
least to get something working but maybe others as well, I'm not sure.
For Sparc machines even CPU support is missing so it may be more difficult
to get that working. Or maybe not as this could be added based on some
other similar architecture: arm, mips and ppc are already there but these
do have a lot of Forth files so it may take a while to understand those. I
don't know Sparc hardware to tell what drivers may be needed.
But from Atar's blog on getting OF working for QEMU PReP/40p I got the
impression that Mitch Bradley (inventor of OpenFirmware and founder of
FirmWorks) did help him by releasing some additional drivers or sources
that he needed so maybe asking politely would not hurt and it may get
easier, unless there are legal hurdles in releasing additional sources.
Otherwise those need to be recreated but that may still be doable if
someone does not mind learning enough Forth to do it.
I'm not sure which is more work, getting OpenBIOS to the same level or
writing drivers for OpenFirmware but maybe for PPC machines it's not much
harder to rewrite the missing drivers. For Sparc I'm not sure, PPC support
was already there so I don't know what it takes to add a new cpu support.
Regards,
BALATON Zoltan
[1] One can follow the thread starting here:
https://mail.coreboot.org/pipermail/openbios/2014-May/008244.html
but basically the attempt to port OF driver to OpenBIOS ended with:
https://mail.coreboot.org/pipermail/openbios/2014-May/008281.html
some of those words are already there now but some are still missing.
I've ended up finishing the C driver which was finally added, even though
I only wanted to try qemu-system-ppc64 originally and did not plan to port
a USB driver. That's what I meant saying I end up having to do fixes
whenever I try something in OpenBIOS: like trying an FCode ROM the last
time. At least OpenFirmware implements the standard already perfectly so
we would only need to care about getting it to work with the machine and
not if it has everythung that might be needed by stuff using it (or at
least much less so than starting from scratch).
1 week, 5 days
- 2
- 4
[PATCH] Implement missing words for the ATI FCode ROM to test ati-vga emulation
by BALATON Zoltan
Signed-off-by: BALATON Zoltan <balaton(a)eik.bme.hu>
---
drivers/pci.c | 51 +++++++++++++++++++++++++++++++++++++--------------
drivers/pci.fs | 41 +++++++++++++++++++++++++++++++++++++++++
drivers/vga.fs | 4 ++--
forth/device/other.fs | 6 ++++++
4 files changed, 86 insertions(+), 16 deletions(-)
This is on top of Mark's previous patches from the openbios mailing
list applied to openbios master:
9a32ed9 Implement missing words for the ATI FCode ROM to test ati-vga emulation
b90ac41 virtio: use instance value to initialise C instance parameter
ac467a3 lsi: use instance value to hold sd_private_t pointer
177684a pc_kbd: use instance value to initialise C instance parameter
d5fdb98 pc_serial: remove separate init word
7c20840 pci: call set-args before configuring PCI device nodes
f37460e pci: remove explicit setting of my-self from PCI devices
b548924 pci: remove explicit find-device from PCI devices
b1ca78f x86: set active package and current instance to root device node before probe
6222a47 SPARC64: set active package and current instance to root device node before probe
5cd41e5 ppc: set active package and current instance to root device node before probe
e68504f ppc: move New World uninorth and nvram device node creation to the root device
86aa740 nvram: ensure that NVRAM configuration is separate from NVRAM node creation
e959bfd libopenbios: remove REGISTER_NAMED_NODE and REGISTER_NAMED_NODE_PHANDLE macros
abc4553 pci: remove ob_pci_initialize() and ob_pci_empty_node
0a63c74 pci: convert to use BIND_NODE_METHODS() macro
57ff6ea virtio: convert to use BIND_NODE_METHODS() macro
ea3a8eb lsi: convert to use BIND_NODE_METHODS() macro
32ff529 lsi: don't change active package when setting device alias
f63f5ee nvram: convert to use BIND_NODE_METHODS() macro
03c53be usbhid: convert to use BIND_NODE_METHODS() macro
365b2c1 pmu: convert to use BIND_NODE_METHODS() macro
60125f5 macio: convert to use BIND_NODE_METHODS() macro
7d23b31 cuda: convert to use BIND_NODE_METHODS() macro
305d629 escc: convert to use BIND_NODE_METHODS() macro
4a0aea1 adb: convert to use BIND_NODE_METHODS() macro
0081f71 ide: convert to use BIND_NODE_METHODS() macro
79a241c floppy: convert to use BIND_NODE_METHODS() macro
01ea2e4 pc_serial: convert to use BIND_NODE_METHODS() macro
9eb09a9 pc_kbd: convert to use BIND_NODE_METHODS() macro
8945ab4 libopenbios: introduce BIND_NODE_METHODS() macro
e9491ea admin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses propertyadmin/devices.fs: Format assigned-addresses property
c79e0ec (origin/master, origin/HEAD) SPARC64: use serial console when QEMU is launched with -vga none
admin/devices.fs: Format assigned-addresses property is
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/WH...
and additionally to the above I also have another patch from Mark that
I can't find now in the list archives even though I remember I've replyed
to it and had a discussion about having 3 or 2 cases if-else statement.
diff --git a/drivers/pci.c b/drivers/pci.c
index 4bc02c9..eb5f7d3 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -408,20 +408,32 @@ static void ob_pci_unmap(ucell virt, ucell size) {
static void
ob_pci_bus_map_in(int *idx)
{
- uint32_t ba;
- ucell size;
- ucell virt;
-
- PCI_DPRINTF("ob_pci_bar_map_in idx=%p\n", idx);
+ fword("pci-map-in");
+}
- size = POP();
- POP();
- POP();
- ba = POP();
+static void
+ob_pci_bus_map_out(int *idx)
+{
+ /* Should call pci-map-out but nothing to do in it yet */
+ fword("2drop");
+}
- virt = ob_pci_map(ba, size);
+static void
+ob_pci_config_read8(int *idx)
+{
+ cell hi = POP();
+ pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
+ uint8_t val = pci_config_read8(addr, hi & 0xff);
+ PUSH(val);
+}
- PUSH(virt);
+static void
+ob_pci_config_write8(int *idx)
+{
+ cell hi = POP();
+ pci_addr addr = PCI_ADDR(PCI_BUS(hi), PCI_DEV(hi), PCI_FN(hi));
+ cell val = POP();
+ pci_config_write8(addr, hi & 0xff, val & 0xff);
}
static void
@@ -459,7 +471,10 @@ NODE_METHODS(ob_pci_bus_node) = {
{ "close", ob_pci_close },
{ "decode-unit", ob_pci_decode_unit },
{ "encode-unit", ob_pci_encode_unit },
- { "pci-map-in", ob_pci_bus_map_in },
+ { "map-in", ob_pci_bus_map_in },
+ { "map-out", ob_pci_bus_map_out },
+ { "config-b@", ob_pci_config_read8 },
+ { "config-b!", ob_pci_config_write8 },
{ "dma-alloc", ob_pci_dma_alloc },
{ "dma-free", ob_pci_dma_free },
{ "dma-map-in", ob_pci_dma_map_in },
@@ -473,7 +488,14 @@ static void
ob_pci_bridge_map_in(int *idx)
{
/* As per the IEEE-1275 PCI specification, chain up to the parent */
- call_parent_method("pci-map-in");
+ call_parent_method("map-in");
+}
+
+static void
+ob_pci_bridge_map_out(int *idx)
+{
+ /* As per the IEEE-1275 PCI specification, chain up to the parent */
+ call_parent_method("map-out");
}
NODE_METHODS(ob_pci_bridge_node) = {
@@ -481,7 +503,8 @@ NODE_METHODS(ob_pci_bridge_node) = {
{ "close", ob_pci_close },
{ "decode-unit", ob_pci_decode_unit },
{ "encode-unit", ob_pci_encode_unit },
- { "pci-map-in", ob_pci_bridge_map_in },
+ { "map-in", ob_pci_bridge_map_in },
+ { "map-out", ob_pci_bridge_map_out },
{ "dma-alloc", ob_pci_dma_alloc },
{ "dma-free", ob_pci_dma_free },
{ "dma-map-in", ob_pci_dma_map_in },
diff --git a/drivers/pci.fs b/drivers/pci.fs
index a7b56e1..327c9c9 100644
--- a/drivers/pci.fs
+++ b/drivers/pci.fs
@@ -37,4 +37,45 @@
then
;
+: pci-map-in ( addr.lo addr.mid addr.hi size -- virt )
+ \ Ignore everything but addr.hi and find assigned addr for BAR
+ drop nip nip
+ \ Save my-self and set it to same as active package because otherwise
+ \ decode-phys below seems to be confused. Maybe this should not be needed
+ my-self swap active-package ihandle>phandle to my-self
+ " assigned-addresses" active-package get-package-property 0= if
+ begin
+ decode-phys ( bar prop prop-len phys.lo phys.mid phys.hi )
+ dup 0fffffff and 6 pick 0fffffff and = if
+ 2drop -rot
+ decode-int drop decode-int drop 2drop
+ ( bar addr.lo )
+ \ Now translate addr.lo, This may be wrong
+ \ maybe we should look at parent's ranges instead?
+ over 18 rshift 3 and 1 = if
+ " reg" active-package parent get-package-property 0= if
+ ( bar addr.lo prop prop-len reg.addr reg.size )
+ decode-int -rot decode-int 3drop
+ +
+ then
+ then
+ nip swap to my-self
+ exit
+ else
+ 3drop \ no match, try next
+ then
+ \ Drop the size as we don't need it
+ decode-int drop decode-int drop
+ dup 0=
+ until
+ 3drop
+ to my-self
+ -1 \ not found
+ else
+ drop
+ to my-self
+ -1 \ could not find assigned-addresses
+ then
+ ;
+
[THEN]
diff --git a/drivers/vga.fs b/drivers/vga.fs
index 53dcff0..f3ffda7 100644
--- a/drivers/vga.fs
+++ b/drivers/vga.fs
@@ -146,14 +146,14 @@ defer vbe-iow!
: map-fb ( -- )
cfg-bar0 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
- " pci-map-in" $call-parent
+ " map-in" $call-parent
to fb-addr
then
;
: map-mmio ( -- )
cfg-bar2 pci-bar>pci-addr if \ ( pci-addr.lo pci-addr.mid pci-addr.hi size )
- " pci-map-in" $call-parent
+ " map-in" $call-parent
to mmio-addr
then
;
diff --git a/forth/device/other.fs b/forth/device/other.fs
index 1bed9b8..0ff34b6 100644
--- a/forth/device/other.fs
+++ b/forth/device/other.fs
@@ -58,21 +58,27 @@ defer (poke)
\ 5.3.7.2 Device-register access
: rb@ ( addr -- byte )
+ ioc@
;
: rw@ ( waddr -- w )
+ iow@
;
: rl@ ( qaddr -- quad )
+ iol@
;
: rb! ( byte addr -- )
+ ioc!
;
: rw! ( w waddr -- )
+ iow!
;
: rl! ( quad qaddr -- )
+ iol!
;
: rx@ ( oaddr - o )
--
2.13.7
2 weeks
- 1
- 0
Debugging FCode ROM
by BALATON Zoltan
Hello,
I'm trying to find out what's missing to use an FCode ROM for the ati-vga
device to see how it would set up the card for MacOS. This has been done
before for other FCode ROMs e.g. here:
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/E7...
I can get some print out of compiling and defining new words by setting
fcode-debug? and ?fcode-verbose to true as above but this only gives me
what I can also get from detok but does not tell me where exactly it fails
during executing these words afterwards. What I get is that after a lot of
(compile), new-token and fcode# lines that define a lot of words it just
ends in one of these (the second?) when executed:
400514a : [ 0x8bc ]
400514c : [ 0x926 ]
byte-load: exception caught!
But how can I see what's inside this word that caused the exception?
There's the forth debugger I think to see or step through execution of
words but how can I add an undefined/unnamed word to the debug before the
the FCode runs?
Looking at the definition of this word in the detok output does not get me
further as it just calls more of these words defined in the FCode:
8512: b(:)
8513: (unnamed-fcode) [0x86a]
8515: (unnamed-fcode) [0x864]
8517: b(") ( len=7 )
" map-out"
8526: (unnamed-fcode) [0x91f]
8528: (unnamed-fcode) [0x86c]
8530: (unnamed-fcode) [0x866]
8532: b(") ( len=7 )
" map-out"
8541: (unnamed-fcode) [0x91f]
8543: 0
8544: b(to) (unnamed-fcode) [0x86c]
8547: 0
8548: b(to) (unnamed-fcode) [0x86a]
8551: b(;)
8552: new-token 0x926
so where can I get more details on execution of these words and the more
precise location of the exception?
Regards,
BALATON Zoltan
2 weeks, 2 days
- 5
- 71
- ← Newer
- 1
- Older →