1:38 a.m.
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
10:46 a.m.
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
(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!
I get the same result with SLOF on qemu-system-ppc64 as per
https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html
914a: [8bc] x8bc 0 0 2 1 1e786d38
914c: [926] x926 Aborted
So maybe it's relying on some pecularity of Apple's Open Firmware
implementation? Any idea how to get more info on where it may fail?
Regards,
BALATON Zoltan
11:25 a.m.
I eventually did get the Geforce 6600 to work with SLOF in PCI Passthrough.
Sadly my PC wouldn’t POST with a Radeon 9200 PCI in a PCI-E to PCI bridge card, tho it
worked fine with a generic firewire card under both OS 9 and OS X in Qemu-system-ppc.
Balaton, are you using PCI Passthrough?
What ATI card are you using, with what FCODE Rom?
On Jul 13, 2019, at 4:46 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
(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!
I get the same result with SLOF on qemu-system-ppc64 as per
https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html
914a: [8bc] x8bc 0 0 2 1 1e786d38
914c: [926] x926 Aborted
So maybe it's relying on some pecularity of Apple's Open Firmware implementation?
Any idea how to get more info on where it may fail?
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
11:48 a.m.
With Openbios and nVidia FCode ROM’s:
OpenBios lacks some of the Config- words and maybe some others that are part of IEEE-1275.
Mark made a patch to one of the missing Config words, but others are still unimplemented,
likely you are getting abort on unimplemented words.
I don’t think ATI FCode ROM’s use anything Apple specific, other than a work a round to
the old Map-In bug present in some Apple Open Firmware implementations.
As a side note: load in Apple’s Open Firmware implementation seems to always do load and
go, nessistating striping the PCI Header( everything before the start of the FCode ) from
Fcode PCI ROM’s when loading them from a file in Apple’s Open Firmware.
On Jul 13, 2019, at 5:25 AM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org> wrote:
I eventually did get the Geforce 6600 to work with SLOF in PCI Passthrough.
Sadly my PC wouldn’t POST with a Radeon 9200 PCI in a PCI-E to PCI bridge card, tho it
worked fine with a generic firewire card under both OS 9 and OS X in Qemu-system-ppc.
Balaton, are you using PCI Passthrough?
What ATI card are you using, with what FCODE Rom?
On Jul 13, 2019, at 4:46 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org (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!
I get the same result with SLOF on qemu-system-ppc64 as per
https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html
914a: [8bc] x8bc 0 0 2 1 1e786d38
914c: [926] x926 Aborted
So maybe it's relying on some pecularity of Apple's Open Firmware implementation?
Any idea how to get more info on where it may fail?
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
12:05 p.m.
On Sat, 13 Jul 2019, Jd Lyons wrote:
OpenBios lacks some of the Config- words and maybe
some others that are
part of IEEE-1275. Mark made a patch to one of the missing Config words,
but others are still unimplemented, likely you are getting abort on
unimplemented words.
Yes but how to find which ones? The "exception caught" error is not very
informative about that.
Regards,
BALATON Zoltan
1:36 p.m.
detok the FCode rom and fallow the code from the exception, looking for words that are
unimplemented.
I can help if you outline exactly what you are doing and provide the Code rom you are
using.
On Jul 13, 2019, at 6:05 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
Yes but how to find which ones? The "exception caught" error is not very
informative about that.
12:02 p.m.
On Sat, 13 Jul 2019, Jd Lyons wrote:
I eventually did get the Geforce 6600 to work with
SLOF in PCI Passthrough.
Sadly my PC wouldn’t POST with a Radeon 9200 PCI in a PCI-E to PCI
bridge card, tho it worked fine with a generic firewire card under both
OS 9 and OS X in Qemu-system-ppc.
That's interesting. Do you have it documented somewhere how to do
pass through of cards to work on qemu-system-ppc?
Balaton, are you using PCI Passthrough?
What ATI card are you using, with what FCODE Rom?
No passthrough, I don't have a card I could try to pass through. I'm
emulating ati-vga in QEMU:
https://git.qemu.org/?p=qemu.git;a=blob;f=hw/display/ati.c;h=a747c4cc98c7...
This partially emulates the Rage 128 Pro found in PowerMac3,1 (and
eventually may grow to RV100) but it's not there yet. Currently Linux
console works in the defaulr 8 bpp and MorphOS can use some 2D
acceleration. No 3D or any advanced features of the card emulated yet.
More info on this at: https://osdn.net/projects/qmiga/wiki/SubprojectAti
This is in upstream QEMU and can be enabled with -device ati-vga but
expect it to not work most of the time so only for developers at the
moment.
I'm trying to get an FCode ROM from a real card to talk to the emulation
as a way to test what's missing or see what's needed for MacOS. Just
putting the NDRV from the ROM in the device-tree makes MacOS poke the card
but then does not work so maybe it needs something more that the FCode
does. That's why I want to try to run the FCode ROM.
Regards,
BALATON Zoltan
2:30 p.m.
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
> (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 ]
How to enable debugging of words defined by FCode such as 0x926 above?
Regards,
BALATON Zoltan
2:37 p.m.
That’s a good question, i’m not sure there is a way, I don’t think you can debug words
defined as colon definitions either.
Tho others here would know better than me, so let’s see what they have to say about it.
On Jul 17, 2019, at 8:30 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
> (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 ]
How to enable debugging of words defined by FCode such as 0x926 above?
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
5:36 p.m.
If I’m reading this right 0x926 is:
new-token 0x926
b(:)
my-address
b(lit) 0x1000014
my-space
+
(unnamed-fcode) [0x867]
b(") ( len=6 )
" map-in"
(unnamed-fcode) [0x91f]
b(to) (unnamed-fcode) [0x86c]
b(lit) 0x4
my-space
+
dup
b(") ( len=9 )
" config-b@"
(unnamed-fcode) [0x91f]
1
or
swap
b(") ( len=9 )
" config-b!"
(unnamed-fcode) [0x91f]
b(;)
On Jul 13, 2019, at 11:33 AM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org> wrote:
Likely failing config-b@ and or config-b!
On Jul 12, 2019, at 7:38 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
400514a : [ 0x8bc ]
400514c : [ 0x926 ]
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
5:42 p.m.
On Sat, 13 Jul 2019, Jd Lyons wrote:
If I’m reading this right 0x926 is:
new-token 0x926
b(:)
I was under the impression that Forth is stack based and defining new word
taked stuff from the stack so the new-token for a block might be to one
after the b(;) not the one before the b(:) but I'm not sure so this could
be as well. Anyway, seeing the execution and getting the exact place of
the exception somehow would be better than having to guess.
Regards,
BALATON Zoltan
my-address
b(lit) 0x1000014
my-space
+
(unnamed-fcode) [0x867]
b(") ( len=6 )
" map-in"
(unnamed-fcode) [0x91f]
b(to) (unnamed-fcode) [0x86c]
b(lit) 0x4
my-space
+
dup
b(") ( len=9 )
" config-b@"
(unnamed-fcode) [0x91f]
1
or
swap
b(") ( len=9 )
" config-b!"
(unnamed-fcode) [0x91f]
b(;)
On Jul 13, 2019, at 11:33 AM, Jd Lyons via
OpenBIOS <openbios(a)openbios.org> wrote:
Likely failing config-b@ and or config-b!
On Jul 12, 2019, at 7:38 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
400514a : [ 0x8bc ]
400514c : [ 0x926 ]
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
5:39 p.m.
On Sat, 13 Jul 2019, Jd Lyons via OpenBIOS wrote:
Likely failing config-b@ and or config-b!
Is that a wild guess or are you basing it on something concrete? The ROM
seems to use these words and it seems to be missing from OpenBIOS so it
might be. Any idea how to implement these?
Regards,
BALATON Zoltan
>> On Jul 12, 2019, at 7:38 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
>>
>> 400514a : [ 0x8bc ]
>> 400514c : [ 0x926 ]
> _______________________________________________
> OpenBIOS mailing list -- openbios(a)openbios.org
> To unsubscribe send an email to openbios-leave(a)openbios.org
>
>
7:44 p.m.
On Jul 13, 2019, at 11:39 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
Is that a wild guess or are you basing it on something concrete? The ROM seems to use
these words and it seems to be missing from OpenBIOS so it might be. Any idea how to
implement these?
Here is how mark implemented config-l:
diff --git a/drivers/pci.c b/drivers/pci.c
index 295be7e..1788c26 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -428,6 +428,15 @@ ob_pci_bus_map_in(int *idx)
PUSH(virt);
}
+static void
+ob_pci_config_readl(int *idx)
+{
+ ucell addr = POP();
+
+ uint32_t value = pci_config_read32(0x80000000 | (addr & 0xffffff00), addr &
0xff);
+ PUSH(value);
+}
+
NODE_METHODS(ob_pci_bus_node) = {
{ NULL, ob_pci_initialize },
{ "open", ob_pci_open },
@@ -435,6 +444,7 @@ NODE_METHODS(ob_pci_bus_node) = {
{ "decode-unit", ob_pci_decode_unit },
{ "encode-unit", ob_pci_encode_unit },
{ "pci-map-in", ob_pci_bus_map_in },
+ { "config-l@", ob_pci_config_readl },
};
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
I’m not 100% sure you are aborting due to the config words, but I’m 100% sure you will if
you get that far.
Could you give me you SLOF launch command, I’m having trouble loading the code from the
disk?
7:58 p.m.
On Sat, 13 Jul 2019, Jd Lyons wrote:
Hope he or someone else can also add config-b fetch and store (@!) words
too. Maybe I won't attempt that as I don't understand it well enough. It
also seems instead of map-in OpenBIOS has pci-map-in but I don't
understand any of that.
On Jul 13,
2019, at 11:39 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
Here is how
mark implemented config-l:
diff --git a/drivers/pci.c b/drivers/pci.c
index 295be7e..1788c26 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -428,6 +428,15 @@ ob_pci_bus_map_in(int *idx)
PUSH(virt);
}
+static void
+ob_pci_config_readl(int *idx)
+{
+ ucell addr = POP();
+
+ uint32_t value = pci_config_read32(0x80000000 | (addr & 0xffffff00), addr &
0xff);
+ PUSH(value);
+}
+
NODE_METHODS(ob_pci_bus_node) = {
{ NULL, ob_pci_initialize },
{ "open", ob_pci_open },
@@ -435,6 +444,7 @@ NODE_METHODS(ob_pci_bus_node) = {
{ "decode-unit", ob_pci_decode_unit },
{ "encode-unit", ob_pci_encode_unit },
{ "pci-map-in", ob_pci_bus_map_in },
+ { "config-l@", ob_pci_config_readl },
};
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
I’m not 100% sure you are aborting due to the config words, but I’m 100% sure you will if
you get that far. Could you give me you SLOF launch command, I’m having
trouble loading the code from the disk?
I've used the commands from the end of the message on the SLOF list I've
quoted (https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html)
and that worked. I think I've either used an image formatted ext2 with the
file or an iso created with genisoimage -R then load cdrom:,\ati.rom or
similar worked but I've lost the log since, I'll need to redo that.
Regards,
BALATON Zoltan
9:09 p.m.
Try this with SLOF:
qemu-system-ppc64 -M pseries -m 512 -device ati-vga -prom-env 'vga-ndrv?=false'
-device secondary-vga -cdrom ~/aty.iso
include evaluator.fs
dev /pci/@1
load cdrom:,\rage
“ /pci/@1” open-dev to my-self
4040 1 byte-load
Wait for it….
Works for me.
On Jul 13, 2019, at 1:58 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 13 Jul 2019, Jd Lyons wrote:
Hope he or someone else can also add config-b fetch and store (@!) words too. Maybe I
won't attempt that as I don't understand it well enough. It also seems instead of
map-in OpenBIOS has pci-map-in but I don't understand any of that.
On Jul
13, 2019, at 11:39 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
Here is how
mark implemented config-l:
diff --git a/drivers/pci.c b/drivers/pci.c
index 295be7e..1788c26 100644
--- a/drivers/pci.c
+++ b/drivers/pci.c
@@ -428,6 +428,15 @@ ob_pci_bus_map_in(int *idx)
PUSH(virt);
}
+static void
+ob_pci_config_readl(int *idx)
+{
+ ucell addr = POP();
+
+ uint32_t value = pci_config_read32(0x80000000 | (addr & 0xffffff00), addr &
0xff);
+ PUSH(value);
+}
+
NODE_METHODS(ob_pci_bus_node) = {
{ NULL, ob_pci_initialize },
{ "open", ob_pci_open },
@@ -435,6 +444,7 @@ NODE_METHODS(ob_pci_bus_node) = {
{ "decode-unit", ob_pci_decode_unit },
{ "encode-unit", ob_pci_encode_unit },
{ "pci-map-in", ob_pci_bus_map_in },
+ { "config-l@", ob_pci_config_readl },
};
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
I’m not 100% sure you are aborting due to the config words, but I’m 100% sure you will if
you get that far. Could you give me you SLOF launch command, I’m
having trouble loading the code from the disk?
I've used the commands from the end of the message on the SLOF list I've quoted
(https://lists.ozlabs.org/pipermail/slof/2018-January/002020.html) and that worked. I
think I've either used an image formatted ext2 with the file or an iso created with
genisoimage -R then load cdrom:,\ati.rom or similar worked but I've lost the log
since, I'll need to redo that.
Regards,
BALATON Zoltan_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
11:16 p.m.
On Sat, 13 Jul 2019, Jd Lyons wrote:
Try this with SLOF:
qemu-system-ppc64 -M pseries -m 512 -device ati-vga -prom-env 'vga-ndrv?=false'
-device secondary-vga -cdrom ~/aty.iso
include evaluator.fs
dev /pci/@1
load cdrom:,\rage
“ /pci/@1” open-dev to my-self
4040 1 byte-load
Wait for it….
Works for me.
Indeed with these commands it does access the card. (You don't actually
need secondary-vga, can use -serial stdio instead and I guess the
vga-ndrv?=false also only makes sense for OpenBIOS so these can be
omitted.)
With this on SLOF it does what it should I guess:
914a: [8bc] x8bc 0 0 2 1 1e786d20
914c: [926] x926
pci_cfg_read ati-vga 01:0 @0x14 -> 0x101
pci_cfg_read ati-vga 01:0 @0x4 -> 0x7
pci_cfg_write ati-vga 01:0 @0x4 <- 0x7
0 0 2 1 1e786d20
914e: [936] x936
ati_mm_write 4 0x0 MM_INDEX <- 0x50000000
ati_mm_write 4 0x4 MM_DATA <- 0x20005
ati_mm_write 4 0x50000000 unknown <- 0x20005
ati_mm_write 4 0x0 MM_INDEX <- 0x30000000
ati_mm_write 4 0x4 MM_DATA <- 0x40a3b371
ati_mm_write 4 0x30000000 unknown <- 0x40a3b371
ati_mm_write 4 0x0 MM_INDEX <- 0x34000000
ati_mm_write 4 0x4 MM_DATA <- 0x1f000000
ati_mm_write 4 0x34000000 unknown <- 0x1f000000
and so on. It uses indexed access to card registers but the values look
wrong. Maybe they are byte swapped so there's an endianness problem
somewhere? It does end eventually and adds some properties to device node.
Now the question is why values are the wrong endianness and where are they
swapped? PCI devices are little endian by default and that's what the QEMU
ati-vga emulates and other drivers normally use (even on ppc, Linux,
MorphOS can access the card). The real hardware does have some facilities
for big-endian access and an ATI ROM on PowerPC may use that but I don't
see how it would enable that. as it only writes one bit before sending
data. PCI config reg 0x14 is BAR1 where IO space is that aliases first 256
bytes of mmio regs. (The rest can be accessed via index/data.) This is
what it maps in. Then PCI config reg 4 is Command where it turns on bits
0-2 which are enabling io access, mem access and bus master. I don't see
what might enable big endian aperture. Can this be that on a Mac this is
set by OpenFirmware somehow or SLOF may have some defaults for this?
Regards,
BALATON Zoltan
7:01 p.m.
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
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
Here is the rest of it:
8555: b(:)
8556: my-address
8558: b(lit) 0x1000014
8563: my-space
8565: +
8566: (unnamed-fcode) [0x867]
8568: b(") ( len=6 )
" map-in"
8576: (unnamed-fcode) [0x91f]
8578: b(to) (unnamed-fcode) [0x86c]
8581: b(lit) 0x4
8586: my-space
8588: +
8589: dup
8590: b(") ( len=9 )
" config-b@"
8601: (unnamed-fcode) [0x91f]
8603: 1
8604: or
8605: swap
8606: b(") ( len=9 )
" config-b!"
8617: (unnamed-fcode) [0x91f]
8619: b(;)
But I'm not sure. The config- words seem to be missing from OpenBIOS but
SLOF does have these and it also fails on SLOF so maybe the exception is
earlier in map-in? The 0x867 is just some variable and the " map-out" "
map-in" is usually followed by $call-parent in other drivers I've seen in
OpenBIOS and SLOF so I guess 0x91f should be that. Here's the detok output
around there:
8033: new-token 0x91d
8036: b(:)
8037: const_0xb0
8039: (unnamed-fcode) [0x90a]
8041: b(;)
8042: 0
8043: new-token 0x91e
8046: b(value)
8047: new-token 0x91f
8050: b(:)
8051: my-self
8053: 0<>
8054: b?branch 0x000b ( =dec 11 dest = 8066 )
8057: my-self
8059: b(to) (unnamed-fcode) [0x869]
8062: bbranch 0x0009 ( dest = 8072 )
8065: b(>resolve)
8066: (unnamed-fcode) [0x869]
8068: b(to) my-self
8071: b(>resolve)
8072: $call-parent
8074: b(;)
8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes
before the : not after the ; in these listings. (But then what is 0x91e
and if it's the value 0 then what about the :; block without new-token
before that?)
So is map-in map-out expected to work in OpenBIOS or is it known to be
missing? Since these are also used by some OpenBIOS drivers and pci.c
does have some code for these maybe it could work. SLOF has these words
but some implementation just print a message and do drop2 so does not seem
to be really implemented there but maybe it works I just can't read Forth.
Maybe we have a problem with $call-parent?
Regards,
BALATON Zoltan
11:50 p.m.
On Sat, 13 Jul 2019, Jd Lyons wrote:
I could not find map-in either so I'm not sure it really works. I've
checked in OpenFirmware and found a comment explaining the bug you've
mentioned:
https://github.com/openbios/openfirmware/blob/master/dev/video/common/def...
Not sure if that's useful but just for reference. Probably we don't need
to emulate that bug. But we should have map-in map-out words. In
OpenFirmware AFAIU these are implemented on the root node:
https://github.com/openbios/openfirmware/blob/master/cpu/ppc/rootnode.fth
and everything else just $call-parent to that. It basically should call
claim to get a virtual address for the specified phys address I think.
OpenBIOS does have something similar in drivers/iommu.c but that's only
used on sparc32. Should that be generalised and also used on ppc or is
that really sparc specific?
Regards,
BALATON Zoltan
On Jul 13,
2019, at 1:01 PM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
So is map-in map-out expected to work in OpenBIOS or is it known to be missing?
Map-in works, map-out is unimplemented, last I checked. 
10:05 p.m.
On Sat, Jul 13, 2019 at 07:01:52PM +0200, BALATON Zoltan wrote:
: _926
my-address 01000014 + my-space + _867 " map-in" _91f TO _86c
4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
On Sat, 13 Jul 2019, BALATON Zoltan wrote:
>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(;)
: _...
_86a _864 " map-out" _91f
_86c _866 " map-out" _91f
0 TO _86c
0 TO _86a ;
8552:
new-token 0x926
Here is the rest of it:
8555: b(:)
8556: my-address
8558: b(lit) 0x1000014
8563: my-space
8565: +
8566: (unnamed-fcode) [0x867]
8568: b(") ( len=6 )
" map-in"
8576: (unnamed-fcode) [0x91f]
8578: b(to) (unnamed-fcode) [0x86c]
8581: b(lit) 0x4
8586: my-space
8588: +
8589: dup
8590: b(") ( len=9 )
" config-b@"
8601: (unnamed-fcode) [0x91f]
8603: 1
8604: or
8605: swap
8606: b(") ( len=9 )
" config-b!"
8617: (unnamed-fcode) [0x91f]
8619: b(;) But I'm not sure. The config- words seem to be
missing from OpenBIOS but
SLOF does have these and it also fails on SLOF so maybe the exception is
earlier in map-in?
The standard config-* words are methods of any specific PCI bus node.
SLOF also has some in the global dictionaries, as convenience.
The 0x867 is just some variable and the "
map-out" "
map-in" is usually followed by $call-parent in other drivers I've seen in
OpenBIOS and SLOF so I guess 0x91f should be that.
Yup.
Here's the detok output
around there:
8033: new-token 0x91d
8036: b(:)
8037: const_0xb0
8039: (unnamed-fcode) [0x90a]
8041: b(;)
: _91d 00b0 _090a ;
8042: 0
8043: new-token 0x91e
8046: b(value)
0 VALUE _91e
8047: new-token 0x91f
8050: b(:)
8051: my-self
8053: 0<>
8054: b?branch 0x000b ( =dec 11 dest = 8066 )
8057: my-self
8059: b(to) (unnamed-fcode) [0x869]
8062: bbranch 0x0009 ( dest = 8072 )
8065: b(>resolve)
8066: (unnamed-fcode) [0x869]
8068: b(to) my-self
8071: b(>resolve)
8072: $call-parent
8074: b(;)
: _091f
my-self 0<> IF
my-self TO _869 ELSE
_869 TO my-self THEN
$call-parent ;
I.e.: if my-self is non-zero, just call $call-parent ; and if it
is zero, set the previously used instance as current instance.
This is pretty curious.
8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes
before the : not after the ; in these listings.
Yes. new-token makes a word header without a name.
(But then what is 0x91e
and if it's the value 0 then what about the :; block without new-token
before that?)
I'm not sure which block you mean?
So is map-in map-out expected to work in OpenBIOS or
is it known to be
missing? Since these are also used by some OpenBIOS drivers and pci.c
does have some code for these maybe it could work. SLOF has these words
but some implementation just print a message and do drop2 so does not seem
to be really implemented there but maybe it works I just can't read Forth.
SLOF runs in real mode, so its memory mapping functions are trivial.
Segher
10:34 p.m.
On Sat, 13 Jul 2019, Segher Boessenkool wrote:
: _926
my-address 01000014 + my-space + _867 " map-in" _91f TO _86c
4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
Thanks for rewriting it into more idiomatic Forth but I'm afraid I can't
read that any better than the above. All I can grasp from it is that it
tries to map something (maybe card's PCI config space) somewhere and set a
bit in it or something along that line. If it worked I should have seen
access to pci config space of the card but it just failed with an
exception. According to Jd it may work with SLOF, I'll retry that later.
What's my-space? That's relevant to my other question (unrelated to this
but more interesting to me):
https://mail.coreboot.org/hyperkitty/list/openbios@openbios.org/thread/WV...
Do you have some insight on that maybe? Although I probably need some help
from someone with OpenBIOS knowledge if there are anyone here with that.
OK I don't know how Forth works internally so the debug output did not
make much sense.
I was confused by that the new-token comes usually before the defined word
but for the 0 value _91e it was between the number and b(value) so not
what I expected:
new-token 91e
0
b(value)
as with :; blocks. But the above explains which lines belong to which
new-token definition.
I think we can conclude that it gets exception because all the words it
tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it
can't really work and likely trips on map-in already.
Thank you,
BALATON Zoltan
8552: new-token 0x926
Here is the rest of it:
8555: b(:)
8556: my-address
8558: b(lit) 0x1000014
8563: my-space
8565: +
8566: (unnamed-fcode) [0x867]
8568: b(") ( len=6 )
" map-in"
8576: (unnamed-fcode) [0x91f]
8578: b(to) (unnamed-fcode) [0x86c]
8581: b(lit) 0x4
8586: my-space
8588: +
8589: dup
8590: b(") ( len=9 )
" config-b@"
8601: (unnamed-fcode) [0x91f]
8603: 1
8604: or
8605: swap
8606: b(") ( len=9 )
" config-b!"
8617: (unnamed-fcode) [0x91f]
8619: b(;) Here's the
detok output
around there:
8033: new-token 0x91d
8036: b(:)
8037: const_0xb0
8039: (unnamed-fcode) [0x90a]
8041: b(;)
: _91d 00b0 _090a ;
8042: 0
8043: new-token 0x91e
8046: b(value)
0 VALUE _91e
8047: new-token 0x91f
8050: b(:)
8051: my-self
8053: 0<>
8054: b?branch 0x000b ( =dec 11 dest = 8066 )
8057: my-self
8059: b(to) (unnamed-fcode) [0x869]
8062: bbranch 0x0009 ( dest = 8072 )
8065: b(>resolve)
8066: (unnamed-fcode) [0x869]
8068: b(to) my-self
8071: b(>resolve)
8072: $call-parent
8074: b(;)
: _091f
my-self 0<> IF
my-self TO _869 ELSE
_869 TO my-self THEN
$call-parent ;
I.e.: if my-self is non-zero, just call $call-parent ; and if it
is zero, set the previously used instance as current instance.
This is pretty curious.
8075: new-token 0x920
So if 0x91f should be the one that does $call-parent then new-token comes
before the : not after the ; in these listings.
Yes. new-token makes a word header without a name. (But then what
is 0x91e
and if it's the value 0 then what about the :; block without new-token
before that?)
I'm not sure which block you mean? So is map-in
map-out expected to work in OpenBIOS or is it known to be
missing? Since these are also used by some OpenBIOS drivers and pci.c
does have some code for these maybe it could work. SLOF has these words
but some implementation just print a message and do drop2 so does not seem
to be really implemented there but maybe it works I just can't read Forth.
SLOF runs in real mode, so its memory mapping functions are trivial.
2:16 a.m.
On Sat, Jul 13, 2019 at 10:34:45PM +0200, BALATON Zoltan wrote:
https://www.openfirmware.info/data/docs/of1275.pdf
Pay special attention to A.2, the glossary. The entry for : says,
for example:
Tokenizer equivalent: new-token|named-token|external-token b(:)
It should normally fail with an intelligible error message, not try to
jump to address zero or similar. But there can be bugs of course, and
there is not much you can do about bugs in the FCode program (the
card's ROM), etc.
Segher
On Sat, 13 Jul 2019, Segher Boessenkool wrote:
01000014 means the PCI I/O space mapped by BAR 1 (the one at config space
address 14). What *exactly* it means I cannot tell either, there is a
lot of missing context.
https://www.openfirmware.info/data/docs/bus.pci.pdf
: _926
my-address 01000014 + my-space + _867 " map-in" _91f TO _86c
4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
Thanks for rewriting it into more idiomatic Forth but I'm afraid I can't
read that any better than the above. All I can grasp from it is that it
tries to map something (maybe card's PCI config space) somewhere and set a
bit in it or something along that line. What's my-space? That's relevant to my other
question (unrelated to this
but more interesting to me):
my-space returns the high 32 bits of an address (PCI addresses are 3 such
32-bit numbers, in open firmware).
I could read that if the https was set up correctly, perhaps.
Yes. new-token
makes a word header without a name.
OK I don't know how Forth works internally so the debug output did not
make much sense. SLOF runs in
real mode, so its memory mapping functions are trivial.
I think we can conclude that it gets exception because all the words it
tries to use: map-in, config-b@, config-b! are missing in OpenBIOS so it
can't really work and likely trips on map-in already. 
11:58 a.m.
On 13/07/2019 21:34, BALATON Zoltan wrote:
I think we can conclude that it gets exception because
all the words it tries to use:
map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and
likely trips on map-in already.
Right. Certainly words like my-parent won't work in FCode for PCI devices until I
finish work getting the PCI ihandle instance chain fixed up, and as JD mentioned
before, the PCI config words aren't yet implemented but should be fairly trivial.
ATB,
Mark.
1:32 p.m.
On Sun, 14 Jul 2019, Mark Cave-Ayland wrote:
On 13/07/2019 21:34, BALATON Zoltan wrote:
Now this is a separate problem to what's discussed in previous message.
That one was about porting SLOF's fdt.fs to use in OpenBIOS, this one is
about running an ATI FCode ROM to test QEMU ati-vga emulation with MacOS.
Sorry if this was confusing, hope this is now cleared.
I might be able to try to implement config-* words based on the config-l
you've added but not sure if these should all call back to C or should we
base them on config-l or config-b or some other generic C helper in Forth?
For reading bytes one could do config-l@ then extract the needed byte
somehow (need to find the forth for that) but for storing we may be better
off with a helper otherwise we need to 'config-l@ modify-it config-l!' if
we only have config-l! or if we base it on config-b! then we need to do
multiple of these for config-l so C helpers or a generic one like
do_config_{read,write}(addr, size) might be simpler. I should check how
other open firmware implementation do this in forth (although probably I
won't understand it). Do you think it's worth trying to do in Forth or
should I try to do that in pci.c?
I don't understand map-in map-out enough to try to implement those so I'll
need some help with that. I've seen there are pci-map-in and dma-map-in
but this is plain map-in which is probably different. I think it should
make a phys addr accessible in forth by assigning a virt addr to it. It we
have virt == phys then this should be simple do nothing. If so we may try
with : map-in 2drop ; or something similar?
In the meantime we've managed to run the FCode ROM in SLOF but data sent
to the device turned out byte swapped so not sure if SLOF does something
differently or Apple's OpenFirmware.
Regards,
BALATON Zoltan
I think we can conclude that it gets exception
because all the words it tries to use:
map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and
likely trips on map-in already.
Right. Certainly words like my-parent won't work in FCode for PCI devices until I
finish work getting the PCI ihandle instance chain fixed up, and as JD mentioned
before, the PCI config words aren't yet implemented but should be fairly trivial.
2:24 p.m.
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
I might be able to try to implement config-* words
based on the config-l
you've added but not sure if these should all call back to C or should we
base them on config-l or config-b or some other generic C helper in Forth?
For reading bytes one could do config-l@ then extract the needed byte somehow
(need to find the forth for that) but for storing we may be better off with a
helper otherwise we need to 'config-l@ modify-it config-l!' if we only have
config-l! or if we base it on config-b! then we need to do multiple of these
for config-l so C helpers or a generic one like do_config_{read,write}(addr,
size) might be simpler. I should check how other open firmware implementation
do this in forth (although probably I won't understand it). Do you think it's
worth trying to do in Forth or should I try to do that in pci.c?
AFAIU looks like most implementations use a C helper for this: most of
SmartFirmware is in C, SLOF seem to call back to rtas and maybe only
OpenFirmware tries to do this in Forth:
https://github.com/openbios/openfirmware/blob/master/dev/pci/configm1.fth
but even in OF I've seen machine specific implementations that use
assembly. So probably doing it in OpenBIOS in a C helper would be
simplest or maybe could be done in Forth if the config base address is
available somewhere.
Regards,
BALATON Zoltan
7:07 p.m.
I suppose the first thing we need it the my-space patch so we can get the correct value
before map-in.
On Jul 14, 2019, at 8:24 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
I might be able to try to implement config-*
words based on the config-l you've added but not sure if these should all call back to
C or should we base them on config-l or config-b or some other generic C helper in Forth?
For reading bytes one could do config-l@ then extract the needed byte somehow (need to
find the forth for that) but for storing we may be better off with a helper otherwise we
need to 'config-l@ modify-it config-l!' if we only have config-l! or if we base it
on config-b! then we need to do multiple of these for config-l so C helpers or a generic
one like do_config_{read,write}(addr, size) might be simpler. I should check how other
open firmware implementation do this in forth (although probably I won't understand
it). Do you think it's worth trying to do in Forth or should I try to do that in
pci.c?
AFAIU looks like most implementations use a C helper for this: most of SmartFirmware is
in C, SLOF seem to call back to rtas and maybe only OpenFirmware tries to do this in
Forth:
https://github.com/openbios/openfirmware/blob/master/dev/pci/configm1.fth
but even in OF I've seen machine specific implementations that use assembly. So
probably doing it in OpenBIOS in a C helper would be simplest or maybe could be done in
Forth if the config base address is available somewhere.
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
1:51 p.m.
On 16/07/2019 13:57, BALATON Zoltan wrote:
On Sun, 14 Jul 2019, Jd Lyons wrote:
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but
really quickly there are 2 reasons: 1) it's a bit of a hack (the real solution is to
build the DT in order rather than constantly switching around active package/current
instance, otherwise your instance variables can be initialised incorrectly) and 2)
we're in QEMU freeze at the moment so I'd like to be confident that there will be
no
OpenBIOS changes required before 4.1 arrives.
As I mentioned in my previous email I am currently working on a patchset to implement
1) properly for PCI devices which I hope to post to the list soon.
ATB,
Mark.
I suppose the first thing we need it the my-space
patch so we can get the correct
value before map-in.
Attachment: openbios-pci-set-args.patch
Why is this patch not in master yet?
4:57 p.m.
On Fri, 19 Jul 2019, Mark Cave-Ayland wrote:
On 16/07/2019 13:57, BALATON Zoltan wrote:
Sure, although we only know about this side of your life here :-). I did
not mean to complain about you being late with this just asked what's the
reason this is a separate patch and not merged yet. It was forwarded to me
by Jd and I though this was done when he was trying to run the NVidia ROM
a few months ago so I thought it's an older patch that could have been
merged unless there's some problem with it that kept it out of master.
On Sun, 14 Jul 2019, Jd Lyons wrote:
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but I suppose the first thing we need it the my-space
patch so we can get the correct
value before map-in.
Attachment: openbios-pci-set-args.patch
Why is this patch not in master yet? really quickly there are 2 reasons: 1) it's a bit
of a hack (the real solution is to
build the DT in order rather than constantly switching around active package/current
instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then
unflattening it to construct the OF device-tree would help with or is it
only about the pci devices part of the tree? Still I think getting a
complete tree from QEMU and only adding some properties as SLOF does is
better then the current situation where OpenBIOS needs knowledge about
every change in QEMU so I think the way to avoid this is to do what SLOF
does. This is more work once but then helps to get rid of a lot of hacks
and make it less work later because a lot of things can be done in QEMU
alone not requiring an OpenBIOS update as well so would make OpenBIOS more
stable.
As I mentioned in my previous email I am currently
working on a patchset to implement
1) properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it
please share the info with the list at least so someone else could have a
chance to help (although I get the impression there's no one else who
cares about OpenBIOS besides you here).
Regards,
BALATON Zoltan
5:29 p.m.
On 19/07/2019 15:57, BALATON Zoltan wrote:
Sure, although we only know about this side of your life here :-). I did not mean to
complain about you being late with this just asked what's the reason this is a
separate patch and not merged yet. It was forwarded to me by Jd and I though this was
done when he was trying to run the NVidia ROM a few months ago so I thought it's an
older patch that could have been merged unless there's some problem with it that
kept
it out of master.
The patchset I've just posted is the proper fix for this - please test and let me
know how you get on.
ATB,
Mark.
Why is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but really quickly there are 2 reasons: 1) it's a
bit of a hack (the real solution is to
build the DT in order rather than constantly switching around active package/current
instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then unflattening it
to construct the OF device-tree would help with or is it only about the pci devices
part of the tree? Still I think getting a complete tree from QEMU and only adding
some properties as SLOF does is better then the current situation where OpenBIOS
needs knowledge about every change in QEMU so I think the way to avoid this is to do
what SLOF does. This is more work once but then helps to get rid of a lot of hacks
and make it less work later because a lot of things can be done in QEMU alone not
requiring an OpenBIOS update as well so would make OpenBIOS more stable.
As I mentioned in my previous email I am
currently working on a patchset to implement
1) properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it please
share the info with the list at least so someone else could have a chance to help
(although I get the impression there's no one else who cares about OpenBIOS besides
you here).
6:36 p.m.
On Sat, 20 Jul 2019, Mark Cave-Ayland wrote:
On 19/07/2019 15:57, BALATON Zoltan wrote:
Sure, although we only know about this side of your life here :-). I did not mean to
complain about you being late with this just asked what's the reason this is a
separate patch and not merged yet. It was forwarded to me by Jd and I though this was
done when he was trying to run the NVidia ROM a few months ago so I thought it's an
older patch that could have been merged unless there's some problem with it that
kept
it out of master.
The patchset I've just posted is the proper fix for this - please test and let me
know how you get on.
Great work, thanks! I've retried with this patch set instead of the
openbios-pci-set-args.patch I was using before but it does not seem to fix
that, neither the map-in problem. I've also found that these new patches
break vga-ndrv?=false:
Welcome to OpenBIOS v1.1 built on Jul 20 2019 16:18
0 > printenv
name "options"
boot-args ""
boot-device "hd:,\\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT"
use-generic? "false"
boot-script ""
boot-screen ""
vga-ndrv? "false"
[...]
0 > cd . .. .. .dev /pci@f2000000/ATY ok
0 > .properties
name "ATY"
vendor-id 1002
device-id 5046
revision-id 0
class-code 30000
min-grant 0
max-latency 0
devsel-speed 0
subsystem-vendor-id 1af4
subsystem-id 1100
cache-line-size 0
device_type "display"
model "ATY Rage128"
compatible "VGA"
assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00
00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00
00 01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00
reg 00007800 00000000 00000000 00000000 00000000
42007810 00000000 00000000 00000000 01000000
01007814 00000000 00000000 00000000 00000100
02007818 00000000 00000000 00000000 00004000
width 320
height 258
depth 20
linebytes c80
driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
I've decorated the map_in function with some more debug messages now:
0 > "/pci@f2000000/ATY" open-dev to my-self
Why is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but really quickly there are 2 reasons: 1) it's a
bit of a hack (the real solution is to
build the DT in order rather than constantly switching around active package/current
instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then unflattening it
to construct the OF device-tree would help with or is it only about the pci devices
part of the tree? Still I think getting a complete tree from QEMU and only adding
some properties as SLOF does is better then the current situation where OpenBIOS
needs knowledge about every change in QEMU so I think the way to avoid this is to do
what SLOF does. This is more work once but then helps to get rid of a lot of hacks
and make it less work later because a lot of things can be done in QEMU alone not
requiring an OpenBIOS update as well so would make OpenBIOS more stable.
As I mentioned in my previous email I am
currently working on a patchset to implement
1) properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it please
share the info with the list at least so someone else could have a chance to help
(although I get the impression there's no one else who cares about OpenBIOS besides
you here). > ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x82000000 size=16384
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x81000000 size=16777216
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000
> ob_pci_map: phys=0x81000000 size=16777216
ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok
0 > my-address h# 1000014 h# 7800 + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x00000000 size=256
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000
> ob_pci_map: phys=0x00000000 size=256
ok
So the base address already looks wrong in the first line of ob_pci_map.
Does the ob_pci_bar_map_in() function decode its parameters correctly?
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
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);
size = POP();
POP();
POP();
ba = POP();
virt = ob_pci_map(ba, size);
PUSH(virt);
}
Shouldn't this be
size = POP();
ba = POP();
POP();
POP();
above?
Regards,
BALATON Zoltan
6:43 p.m.
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
0 > "/pci@f2000000/ATY" open-dev to
my-self
Or maybe not because it looks correct for BARs as above at the top of this
message. So why does this function ignore the pci-addr.hi which is the
only non-0 in this call or should it try to map config space of the card
for ba=0?
Regards,
BALATON Zoltan
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x82000000 size=16384
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x81000000 size=16777216
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000
> ob_pci_map: phys=0x81000000 size=16777216
ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok
0 > my-address h# 1000014 h# 7800 + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x00000000 size=256
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000
> ob_pci_map: phys=0x00000000 size=256
ok
So the base address already looks wrong in the first line of ob_pci_map. Does
the ob_pci_bar_map_in() function decode its parameters correctly?
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
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);
size = POP();
POP();
POP();
ba = POP();
virt = ob_pci_map(ba, size);
PUSH(virt);
}
Shouldn't this be
size = POP();
ba = POP();
POP();
POP();
above?
7:38 p.m.
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
This pci_decode_pci_addr() function looks suspicious:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L156
it's called from ob_pci_map():
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L373
It only expects IO or MMIO space and instead of finding what space is
requested from pci-addr.hi it only looks at pci-addr.lo to decide. I think
this is probably not how this should work. OK, the comment near
ob_pci_map() says it's for mapping PCI MMIO or IO so it was probably not
meant to allow access to config space but the map-in word seems to allow
that as well. So what's the recommended way here? Which of these functions
should be changed to add support for config space or should that be
handled in ob_pci_bus_map_in already?
Regards,
BALATON Zoltan
0 > "/pci@f2000000/ATY" open-dev to
my-self
Or maybe not because it looks correct for BARs as above at the top of this
message. So why does this function ignore the pci-addr.hi which is the only
non-0 in this call or should it try to map config space of the card for ba=0? > ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x82000000 size=16384
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x81000000 size=16777216
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000
> ob_pci_map: phys=0x81000000 size=16777216
ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok
0 > my-address h# 1000014 h# 7800 + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x00000000 size=256
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000
> ob_pci_map: phys=0x00000000 size=256
ok
So the base address already looks wrong in the first line of ob_pci_map.
Does the ob_pci_bar_map_in() function decode its parameters correctly?
/* ( pci-addr.lo pci-addr.mid pci-addr.hi size -- virt ) */
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);
size = POP();
POP();
POP();
ba = POP();
virt = ob_pci_map(ba, size);
PUSH(virt);
}
Shouldn't this be
size = POP();
ba = POP();
POP();
POP();
above?
10:39 a.m.
On 20/07/2019 18:38, BALATON Zoltan wrote:
Right, moving the detection and handling of the space into map-in rather than relying
on the caller to do it seems to be the right thing here. It shouldn't take you too
long to make the relevant changes:
- Change pci_bus_addr_to_host_addr() to return arch->cfg_addr if the space code
indicates CONFIGURATION_SPACE (a switch statement is probably better here)
- Create pci_decode_phys_addr() as the opposite to pci_encode_phys_addr() that takes
an array of 3 u32s and sets flags, space_code, dev and addr
- Switch pci_decode_pci_addr() in ob_pci_map() to use your new pci_decode_phys_addr()
function
- ...at which point it probably makes sense to merge ob_pci_map() into
ob_pci_bus_map_in(). There are a couple of callers that you'll need to fix up, and
possibly vga.fs too.
That should give you a basic working PCI map-in word. Once you get the virtual
address for a PCI device configuration space you can easily test by reading a 16-bit
LE word and if all is well you'll get the PCI device id back:
0 0 1007814 100
" map-in" $call-parent \ should place virt address on stack
le-w@ \ should perform LE read from virt and return 5046
\ on the stack (the device id of your ATI card)
Once the basics work the next step is to look at moving the ob_pci_map() logic into a
call-parent chain (particularly the config, IO and MMIO base addresses) to implement
the config-* words within the PCI bus node itself.
ATB,
Mark.
Or maybe not
because it looks correct for BARs as above at the top of this message.
So why does this function ignore the pci-addr.hi which is the only non-0 in this
call or should it try to map config space of the card for ba=0?
This pci_decode_pci_addr() function looks suspicious:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L156
it's called from ob_pci_map():
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L373
It only expects IO or MMIO space and instead of finding what space is requested from
pci-addr.hi it only looks at pci-addr.lo to decide. I think this is probably not how
this should work. OK, the comment near ob_pci_map() says it's for mapping PCI MMIO
or
IO so it was probably not meant to allow access to config space but the map-in word
seems to allow that as well. So what's the recommended way here? Which of these
functions should be changed to add support for config space or should that be handled
in ob_pci_bus_map_in already?
2:02 p.m.
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
Right, moving the detection and handling of the space
into map-in rather than relying
on the caller to do it seems to be the right thing here. It shouldn't take you too
long to make the relevant changes:
- Change pci_bus_addr_to_host_addr() to return arch->cfg_addr if the space code
indicates CONFIGURATION_SPACE (a switch statement is probably better here)
- Create pci_decode_phys_addr() as the opposite to pci_encode_phys_addr() that takes
an array of 3 u32s and sets flags, space_code, dev and addr
I gave it a try and got to this point without problems.
- Switch pci_decode_pci_addr() in ob_pci_map() to use
your new pci_decode_phys_addr()
function
- ...at which point it probably makes sense to merge ob_pci_map() into
ob_pci_bus_map_in(). There are a couple of callers that you'll need to fix up, and
possibly vga.fs too.
But I got stuck here, there are too many callers and they have different
input than the proposed phys_addr[3] so this I don't see how to adjust
them. ob_pci_map currently only takes an address which callers get from
config->assigned[1] (the BAR if I got that right) but proposed new
function would take phys_addr[3] of which only the low 64 bits are in
config->assigned. Where to get the phys[0] part? Should I try to encode
that at every caller when it's not really needed? That looks inefficient
so unless it's already available somewhere we probably need to leave
ob_pci_map as it is.
Then ob_pci_bus_map_in takes forth parameters while ob_pci_map takes C
ones so merging the two means that all callers could just use the forth
map-in word as they would need to push their parameters to stach to pass
to ob_pci_bus_map_in(). Either there's a problem with this design or I
need more details on how should this work to go further.
Regards,
BALATON Zoltan
4:16 p.m.
OK I came up with the attched patch (on top of your previous series and
set-args patch) which is I think about what you've suggested. I kept
ob_pci_map for existing callers but renamed it to ob_pci_map_in to keep
symmetry between ob_pci_map and ob_pci_unmap with ob_pci_map now only
doing mapping as its name suggests (although I think this should still be
simpler) and ob_pci_bus_map_in is doing its own address decoding now. The
previous ob_pci_map (now called ob_pci_map_in which is a C helper for some
of what map-in should do) can be cleaned up as you like. Also cleaned up
some white space (tab vs. spaces) but that's excluded from this patch for
brevity.
But it does not seem to work yet:
0 > " /pci@f2000000/ATY" open-dev to my-self
> ob_pci_bar_map_in idx=1fc5ac54
> pci_bus_addr_to_host_addr space=2 ba=0x82000000
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5ac54
> pci_bus_addr_to_host_addr space=2 ba=0x81000000
> ob_pci_map: phys=0x81000000 size=16777216
ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-space ok
1 > . 7800 ok
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-address h# 1000014 my-space + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent
> ob_pci_bar_map_in idx=1fc5ac54
> pci_bus_addr_to_host_addr space=1 ba=0x0
> ob_pci_map: phys=0xf2000000 size=256
ok
1 > .s <1> -e000000
ok
1 > le-l@ ok
1 > . -1 ok
0 >
Any idea?
Regards,
BALATON Zoltan
8:10 p.m.
On 21/07/2019 15:16, BALATON Zoltan wrote:
OK I came up with the attched patch (on top of your
previous series and set-args
patch) which is I think about what you've suggested. I kept ob_pci_map for existing
callers but renamed it to ob_pci_map_in to keep symmetry between ob_pci_map and
ob_pci_unmap with ob_pci_map now only doing mapping as its name suggests (although I
think this should still be simpler) and ob_pci_bus_map_in is doing its own address
decoding now. The previous ob_pci_map (now called ob_pci_map_in which is a C helper
for some of what map-in should do) can be cleaned up as you like. Also cleaned up
some white space (tab vs. spaces) but that's excluded from this patch for brevity.
Now I'm really confused - I had a quick look at your patch and compared it with
pci_config_*() words and they show that you can't memory map PCI config space on a
Mac. So how did you get to the conclusion earlier in the thread that this was what
was required?
But it does not seem to work yet:
0 > " /pci@f2000000/ATY" open-dev to my-self
Here we see 2 MMIO BARs being mapped: one of 16K and another of 16M. And this happens
as soon as you open the device? I think you'll have to explain more about your
command line and how you are getting OpenBIOS to execute the FCode, since I can't
tell if this is OpenBIOS or the FCode.
> ob_pci_bar_map_in idx=1fc5ac54
> pci_bus_addr_to_host_addr space=2 ba=0x82000000
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5ac54
> pci_bus_addr_to_host_addr space=2 ba=0x81000000
> ob_pci_map: phys=0x81000000 size=16777216
ok 0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-space ok
1 > . 7800 ok
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-address h# 1000014 my-space + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent
This is trying to map an IO BAR with 256 bytes, but the phys address isn't going to
be correct because OpenBIOS copies arch->io_base into *io_base (and also *mem_base
for MMIO) during PCI configuration and advances that copy to hold the start of the
next free address.
At a very minimum you're going to have to teach the PCI map-in how to use these
values instead of making the assumption that the BAR has already been mapped by
ob_pci_configure_bar() and the address can be calculated by adding the BAR address to
arch->io_base or arch->mem_base according to the space type. This is how
pci_bus_addr_to_host_addr() currently works.
The other issue is that the PCI enumeration code will already have mapped the ATI
BARs once so you'll have to come up with a solution so that if you detect an FCode
ROM then the existing PCI configuration code is ignored. Otherwise you'll find that
you have mapped the 16M MMIO BAR twice which is going to take quite a bit of MMIO
memory and lead to more confusion.
Finally one other thing: I'm finding this thread really hard to follow - too much
information is spread across too many emails, and the subject line isn't really
helping me understand what topic we're following or where I can find related
information. May I suggest that it makes sense to break this down into a series of
smaller, more concise threads?
ATB,
Mark.
> ob_pci_bar_map_in idx=1fc5ac54
> pci_bus_addr_to_host_addr space=1 ba=0x0
> ob_pci_map: phys=0xf2000000 size=256
ok
8:24 p.m.
On Sun, Jul 21, 2019 at 07:10:02PM +0100, Mark Cave-Ayland wrote:
On 21/07/2019 15:16, BALATON Zoltan wrote:
Now I'm really confused - I had a quick look at your patch and compared it with
pci_config_*() words and they show that you can't memory map PCI config space on a
Mac.
That depends on the PCI host bridge. Most are direct-mapped on powermac.
A few are not.
> 0 > " /pci@f2000000/ATY" open-dev to
my-self
Like this f2000000, that is the physical address that maps directly to
PCI config space on that bus.
Segher
10:13 a.m.
On 20/07/2019 17:36, BALATON Zoltan wrote:
On Sat, 20 Jul 2019, Mark Cave-Ayland wrote:
Ah I see. This is because vga_config_cb() gets called not just for a specific
device/vendor id but for any PCI display device. It might be worth renaming it to
bochs_config_cb() and tying it down to the QEMU device/vendor id so that it doesn't
interfere with external FCode ROMs.
On 19/07/2019 15:57, BALATON Zoltan wrote:
The patchset I've just posted is the proper fix for this - please test and let me
know how you get on.
Great work, thanks! I've retried with this patch set instead of the
openbios-pci-set-args.patch I was using before but it does not seem to fix that,
neither the map-in problem. I've also found that these new patches break
vga-ndrv?=false:
Welcome to OpenBIOS v1.1 built on Jul 20 2019 16:18
0 > printenv
name "options"
boot-args ""
boot-device "hd:,\\:tbxi hd:,\ppc\bootinfo.txt hd:,%BOOT"
use-generic? "false"
boot-script ""
boot-screen ""
vga-ndrv? "false"
[...]
0 > cd . .. .. .dev /pci@f2000000/ATY ok
0 > .properties
name "ATY"
vendor-id 1002
device-id 5046
revision-id 0
class-code 30000
min-grant 0
max-latency 0
devsel-speed 0
subsystem-vendor-id 1af4
subsystem-id 1100
cache-line-size 0
device_type "display"
model "ATY Rage128"
compatible "VGA"
assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01
00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00
00 01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00
reg 00007800 00000000 00000000 00000000 00000000
42007810 00000000 00000000 00000000 01000000
01007814 00000000 00000000 00000000 00000100
02007818 00000000 00000000 00000000 00004000
width 320
height 258
depth 20
linebytes c80
driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21 70 65 66 66 70 77 70 63 00
^^^ This driver should not be here. > Why
is this patch not in master yet?
Well sometimes I have been known to have a life outside of QEMU/OpenBIOS... but
Sure, although we only know about this side of your life here :-). I did not mean to
complain about you being late with this just asked what's the reason this is a
separate patch and not merged yet. It was forwarded to me by Jd and I though this was
done when he was trying to run the NVidia ROM a few months ago so I thought it's an
older patch that could have been merged unless there's some problem with it that
kept
it out of master.
really quickly there are 2 reasons: 1) it's a
bit of a hack (the real solution is to
build the DT in order rather than constantly switching around active package/current
instance, otherwise your instance variables can be initialised incorrectly) and 2)
OK, is that something getting the device tree from QEMU as FDT then unflattening it
to construct the OF device-tree would help with or is it only about the pci devices
part of the tree? Still I think getting a complete tree from QEMU and only adding
some properties as SLOF does is better then the current situation where OpenBIOS
needs knowledge about every change in QEMU so I think the way to avoid this is to do
what SLOF does. This is more work once but then helps to get rid of a lot of hacks
and make it less work later because a lot of things can be done in QEMU alone not
requiring an OpenBIOS update as well so would make OpenBIOS more stable.
As I mentioned in my previous email I am
currently working on a patchset to
implement
1) properly for PCI devices which I hope to post to the list soon.
Is there more info available on this? If you don't have time to work on it please
share the info with the list at least so someone else could have a chance to help
(although I get the impression there's no one else who cares about OpenBIOS besides
you here). I've decorated the map_in function with some more
debug messages now:
0 > "/pci@f2000000/ATY" open-dev to my-self
I had a fresh read of the relevant parts of the IEEE-1275 specification this morning
and the fallback behaviour related to the reg property I was looking at is only
related to my-unit, i.e. after the package has been created. So yes, even with the
new code we still need an explicit set-args in there since this is the only thing
that can set the probe address which is used for my-space and my-address.
Attached is a lightly tested patch to be applied on top of the existing patchset
which uses the instance chain to encode the unit number correctly before invoking
set-args.
ATB,
Mark.
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x82000000 size=16384
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x82000000
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x81000000 size=16777216
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x81000000
> ob_pci_map: phys=0x81000000 size=16777216
ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-space . 0 ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0 ok
0 > my-address h# 1000014 h# 7800 + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent
> ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x00000000 size=256
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000
> ob_pci_map: phys=0x00000000 size=256
ok
noon
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
But I had vga-ndrv? set to false so this then should not add driver even
for QEMU VGA and it didn't add it with this serting before your patches,
only does now so there's some problem with handling that option now.
Not running vga.fs and adding driver for ATY but let an FCode ROM do it is
next step but we'll need to make FCode ROMs work for that first. (Actually
once that works I'd like to also switch QEMU VGA to use proper FCode ROM
added in QEMU then the hacks regading vga.fs and NDRV patching could be
completely cleaned up from OpenBIOS.)
Regards,
BALATON Zoltan
driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21
70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
Ah I see. This is because vga_config_cb() gets called not just for a specific
device/vendor id but for any PCI display device. It might be worth renaming it to
bochs_config_cb() and tying it down to the QEMU device/vendor id so that it doesn't
interfere with external FCode ROMs.
1:04 p.m.
On 21/07/2019 11:00, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
Hmmm okay, I thought you meant for your ATI card. I'll do a quick test in a bit and
see if I can recreate this.
On 20/07/2019 17:36, BALATON Zoltan wrote:
But I had vga-ndrv? set to false so this then should not add driver even for QEMU VGA
and it didn't add it with this serting before your patches, only does now so
there's
some problem with handling that option now. driver,AAPL,MacOS,PowerPC -- 4941 : 4a 6f 79 21
70 65 66 66 70 77 70 63 00
^^^ This driver should not be here.
Ah I see. This is because vga_config_cb() gets called not just for a specific
device/vendor id but for any PCI display device. It might be worth renaming it to
bochs_config_cb() and tying it down to the QEMU device/vendor id so that it doesn't
interfere with external FCode ROMs. Not running vga.fs and adding driver for ATY but let
an FCode ROM do it is next step
but we'll need to make FCode ROMs work for that first. (Actually once that works
I'd
like to also switch QEMU VGA to use proper FCode ROM added in QEMU then the hacks
regading vga.fs and NDRV patching could be completely cleaned up from OpenBIOS.)
I think there is something to be said for splitting out the VGA driver as already is
done for the CG3/TCX drivers, but there's not much point doing that until we're
happy
that the implementation is fairly compliant with the specification. As for the NDRV
my current preference is to keep it separate since it makes development/debugging the
driver itself considerably easier.
Then again this only affects the QEMU VGA device: if you have a real option ROM then
you should be able to pass that in as a parameter to your ATI device and everything
should "just work" once OpenBIOS has been tweaked to detect its FCode payload.
ATB,
Mark.
12:11 p.m.
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
On 20/07/2019 17:36, BALATON Zoltan wrote:
I'm not sure what fallback you mean here but referring to my previous
message regarding this:
On Fri, 19 Jul 2019, BALATON Zoltan wrote:
0 > my-unit? ok
3 > . 7800? ok
2 > . 0? ok
1 > . 0? ok
0 > my-space . 0? ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0? ok
0 > my-address h# 1000014 h# 7800 + h# 100? ok
4 > .s <4> 0 0 1007814 100
?ok
4 > " map-in" $call-parent
I had a fresh read of the relevant parts of the IEEE-1275 specification this morning
and the fallback behaviour related to the reg property I was looking at is only
related to my-unit, i.e. after the package has been created. So yes, even with the
new code we still need an explicit set-args in there since this is the only thing
that can set the probe address which is used for my-space and my-address. > ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x00000000 size=256
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000
> ob_pci_map: phys=0x00000000 size=256
?ok On Mon, 15 Jul 2019, Segher Boessenkool wrote:
Why isn't my-unit is just my-address my-space and how can these return
different values? Should these values be stored on the same place and all
of these words get it from that one place? Apparently not there are
several places these are stored and the problem is that they get out of
sync isnt'it?
Regards,
BALATON Zoltan
my-address is two zeroes for configuration space
addresses. But my-space
shouldn't be zero, it's 7800 here. my-unit should be exactly identical
to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\
\ 5.3.4.3 Get local arguments
\
: my-address ( -- phys.lo ... )
?my-self >in.device-node @
dn.probe-addr
my-#acells tuck /l* + swap
1- 0
?do
/l - dup l@ swap
loop
drop
;
: my-space ( -- phys.hi )
?my-self >in.device-node @
dn.probe-addr @
;
: my-unit ( -- phys.lo ... phys.hi )
?my-self >in.my-unit
my-#acells tuck /l* + swap 0 ?do
/l - dup l@ swap
loop
drop
;
my-unit seems to get the info from a different place (>in.my-unit vs.
> dn.probe-addr) here. Why is that?
1:08 p.m.
On 21/07/2019 11:11, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
I'm not sure what you mean about returning different values? At least with my
patchset and this morning's patch applied they both looks the same here:
0 > " /pci/usb" open-dev to my-self ok
0 > my-unit ok
3 > u. 6800 ok
2 > u. 0 ok
1 > u. 0 ok
0 > my-address ok
2 > my-space ok
3 > u. 6800 ok
2 > u. 0 ok
1 > u. 0 ok
Segher's comment about my-unit is an implementation detail rather than a definition
from the specification, so I wouldn't worry about this. Given that the above looks
correct I'd say it's time to move on to the PCI mapping as per the outline given
in
my previous email.
ATB,
Mark.
On 20/07/2019 17:36, BALATON Zoltan wrote:
I'm not sure what fallback you mean here but referring to my previous message
regarding this:
On Fri, 19 Jul 2019, BALATON Zoltan wrote:
0 > my-unit? ok
3 > . 7800? ok
2 > . 0? ok
1 > . 0? ok
0 > my-space . 0? ok
^ this is still wrong, should be 7800
0 > my-address . . 0 0? ok
0 > my-address h# 1000014 h# 7800 + h# 100? ok
4 > .s <4> 0 0 1007814 100
?ok
4 > " map-in" $call-parent
I had a fresh read of the relevant parts of the IEEE-1275 specification this morning
and the fallback behaviour related to the reg property I was looking at is only
related to my-unit, i.e. after the package has been created. So yes, even with the
new code we still need an explicit set-args in there since this is the only thing
that can set the probe address which is used for my-space and my-address. > ob_pci_bar_map_in idx=1fc5ac54
> ob_pci_map: ba=0x00000000 size=256
> ob_pci_map: after decode flags=0x0 space_code=0x2 mask=0xf
> pci_bus_addr_to_host_addr: space=0x2 ba=0x00000000
> ob_pci_map: phys=0x00000000 size=256
?ok On Mon, 15 Jul 2019, Segher Boessenkool wrote:
Why isn't my-unit is just my-address my-space and how can these return different
values? Should these values be stored on the same place and all of these words get it
from that one place? Apparently not there are several places these are stored and the
problem is that they get out of sync isnt'it? my-address is two zeroes for configuration space
addresses. But my-space
shouldn't be zero, it's 7800 here. my-unit should be exactly identical
to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\
\ 5.3.4.3 Get local arguments
\
: my-address ( -- phys.lo ... )
?my-self >in.device-node @
dn.probe-addr
my-#acells tuck /l* + swap
1- 0
?do
/l - dup l@ swap
loop
drop
;
: my-space ( -- phys.hi )
?my-self >in.device-node @
dn.probe-addr @
;
: my-unit ( -- phys.lo ... phys.hi )
?my-self >in.my-unit
my-#acells tuck /l* + swap 0 ?do
/l - dup l@ swap
loop
drop
;
my-unit seems to get the info from a different place (>in.my-unit vs. >
dn.probe-addr) here. Why is that?
1:55 p.m.
On Sun, 21 Jul 2019, Mark Cave-Ayland wrote:
I meant before the patch they could refurn different values which means
that space address (the one my-space gets it from) can become unsynced
from the unit address (the one that my-unit looks at) and this probably
should not happen so it suggests there might be a problem here which
could be prevented by ensuring space address is only stored at one place
and both my-unit and my-space get it from that same place which currently
does not seem to be the case.
Why isn't
my-unit is just my-address my-space and how can these return different
values? Should these values be stored on the same place and all of these words get it
from that one place? Apparently not there are several places these are stored and the
problem is that they get out of sync isnt'it?
I'm not sure what you mean about returning different values? At least with my
patchset and this morning's patch applied they both looks the same here: Segher's comment about my-unit is an
implementation detail rather than a definition
from the specification, so I wouldn't worry about this. Given that the above looks
I don't care much as long as it works but maybe it would help if I
understood the implementation detail why my-space and my-unit are not
equivalent in OpenBIOS (for FDT unflattening maybe I'll need to get more
understanding of this).
correct I'd say it's time to move on to the
PCI mapping as per the outline given in
my previous email.
Yes, more on that in next message.
Regards,
BALATON Zoltan
8:16 p.m.
Hi Mark,
On Sun, Jul 21, 2019 at 12:08:21PM +0100, Mark Cave-Ayland wrote:
I'm not sure what you mean about returning
different values? At least with my
patchset and this morning's patch applied they both looks the same here:
0 > " /pci/usb" open-dev to my-self ok
0 > my-unit ok
3 > u. 6800 ok
2 > u. 0 ok
1 > u. 0 ok
0 > my-address ok
2 > my-space ok
3 > u. 6800 ok
2 > u. 0 ok
1 > u. 0 ok
That looks good.
Segher's comment about my-unit is an
implementation detail rather than a definition
from the specification,
Which comment?
Segher
9:19 p.m.
On Sun, 21 Jul 2019, Segher Boessenkool wrote:
On Sun, Jul 21, 2019 at 12:08:21PM +0100, Mark
Cave-Ayland wrote:
That my-unit should be the same as my-address my-space which without
Mark's latest patch does not hold in OpenBIOS. But that patch does not
change where these values are pulled from just calls set-args which
apparently syncs the places space and address come from while my-unit gets
space from somewhere else.
Regards,
BALATON Zoltan
I'm not sure what you mean about returning
different values? At least with my
patchset and this morning's patch applied they both looks the same here:
0 > " /pci/usb" open-dev to my-self ok
0 > my-unit ok
3 > u. 6800 ok
2 > u. 0 ok
1 > u. 0 ok
0 > my-address ok
2 > my-space ok
3 > u. 6800 ok
2 > u. 0 ok
1 > u. 0 ok
That looks good.
Segher's comment about my-unit is an
implementation detail rather than a definition
from the specification,
Which comment?
10:36 p.m.
On Sun, Jul 21, 2019 at 09:19:13PM +0200, BALATON Zoltan wrote:
On Sun, 21 Jul 2019, Segher Boessenkool wrote:
set-args sets up what my-address and my-space return. This is standard.
my-space and my-address are used for determining the value in the "reg"
property. The standard says this, too, and various bindings make it
more explicit.
my-unit gets its value from the "reg" property. This is also standard.
(I'm ignoring wildcard nodes and only partially set up nodes, as usual).
Segher
On Sun, Jul 21, 2019 at 12:08:21PM +0100, Mark
Cave-Ayland wrote:
That my-unit should be the same as my-address my-space which without
Mark's latest patch does not hold in OpenBIOS. But that patch does not
change where these values are pulled from just calls set-args which
apparently syncs the places space and address come from while my-unit gets
space from somewhere else. Segher's comment about my-unit is an
implementation detail rather than a
definition
from the specification,
Which comment?
1:18 a.m.
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
On Sun, 14 Jul 2019, BALATON Zoltan wrote:
Investigating it some more I've found that in OpenBIOS we're missing the
register read/write words: r[bwl][!@] besides the pci config-[bwl][!@]
words. However we have non-standard io[cwl][!@] words instead (implemented
by the io[cwl]{fetch,store} functions in kernel/forth.c) which I think
correspond to the missing r[bwl][!@] words so these could be aliased to
those. For pci config access we also have non-standard equivalents in
https://github.com/openbios/openbios/blob/master/forth/util/pci.fs
These pci-* words are not much used so maybe we could just rename them to
config-* to match OpemFirmware?
Does anyone see a problem with that or do you think this could work?
Regards,
BALATON Zoltan
I might be able to try to implement config-*
words based on the config-l
you've added but not sure if these should all call back to C or should we
base them on config-l or config-b or some other generic C helper in Forth?
For reading bytes one could do config-l@ then extract the needed byte
somehow (need to find the forth for that) but for storing we may be better
off with a helper otherwise we need to 'config-l@ modify-it config-l!' if
we only have config-l! or if we base it on config-b! then we need to do
multiple of these for config-l so C helpers or a generic one like
do_config_{read,write}(addr, size) might be simpler. I should check how
other open firmware implementation do this in forth (although probably I
won't understand it). Do you think it's worth trying to do in Forth or
should I try to do that in pci.c?
AFAIU looks like most implementations use a C helper for this: most of
SmartFirmware is in C, SLOF seem to call back to rtas and maybe only
OpenFirmware tries to do this in Forth:
https://github.com/openbios/openfirmware/blob/master/dev/pci/configm1.fth
but even in OF I've seen machine specific implementations that use assembly.
So probably doing it in OpenBIOS in a C helper would be simplest or maybe
could be done in Forth if the config base address is available somewhere.
2:23 a.m.
On Sun, 14 Jul 2019, Mark Cave-Ayland wrote:
On 13/07/2019 21:34, BALATON Zoltan wrote:
OK so it's even worse. Not only map-in and config-b[!@] words are missing
but also the my-* words don't return what they should that's what you're
saying? Looks like that's the case. In OpenBIOS:
0 > " /pci/ATY" select-dev ok
0 > .properties
name "ATY"
vendor-id 1002
device-id 5046
revision-id 0
class-code 30000
min-grant 0
max-latency 0
devsel-speed 0
subsystem-vendor-id 1af4
subsystem-id 1100
cache-line-size 0
device_type "display"
model "ATY Rage128"
compatible "VGA"
assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00
00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00
01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00
reg 00007800 00000000 00000000 00000000 00000000
42007810 00000000 00000000 00000000 01000000
01007814 00000000 00000000 00000000 00000100
02007818 00000000 00000000 00000000 00004000
width 320
height 258
depth 20
linebytes c80
address 81000000
ok
0 > my-self . 1fc5abfc ok
0 > my-space ok
1 > . 0 ok
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 >
So then even computing the parameter to map-in is probably wrong in the
word where it gets exception:
: _926
my-address 01000014 + my-space + _867 " map-in" _91f TO _86c
4 my-space + dup " config-b@" _91f 1 or swap " config-b!" _91f ;
I think these my-* values should have some numbers instead of 0. What's
the problem here? Looks like it returns first value from reg but shouldn't
it return something from assigned-addresses instead?
Regards,
BALATON Zoltan
I think we can conclude that it gets exception
because all the words it tries to use:
map-in, config-b@, config-b! are missing in OpenBIOS so it can't really work and
likely trips on map-in already.
Right. Certainly words like my-parent won't work in FCode for PCI devices until I
finish work getting the PCI ihandle instance chain fixed up, and as JD mentioned
before, the PCI config words aren't yet implemented but should be fairly trivial.
9:20 a.m.
Hi!
On Mon, Jul 15, 2019 at 02:23:24AM +0200, BALATON Zoltan wrote:
0 > " /pci/ATY" select-dev ok
It's called open-dev since ages, fwiw.
0 > my-self . 1fc5abfc ok
0 > my-space ok
1 > . 0 ok
This one should be 7800
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
Those all look fine.
I think these my-* values should have some numbers
instead of 0. What's
the problem here? Looks like it returns first value from reg but shouldn't
it return something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But my-space
shouldn't be zero, it's 7800 here. my-unit should be exactly identical
to my-address my-space , but it isn't for you?
Segher
12:39 p.m.
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
https://github.com/openbios/openbios/blob/master/forth/admin/devices.fs#L49
\ Open selected device node and make it the current instance
\ section H.8 errata: pre OpenFirmware, but Sun OBP compatible
: select-dev ( -- )
open-dev dup 0= abort" failed opening parent."
dup to my-self
ihandle>phandle active-package!
;
(actually definition of this word seems wrong, it says ( -- ) but
really takes the same values as open-dev ( dev-str dev-len -- )? The
following just hangs:
dev /pci/ATY
select-dev
But I get same results with open-dev:
0 > " /pci/ATY" open-dev to my-self ok
0 > my-space ok
1 > . 0 ok
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 >
These words are defined here:
https://github.com/openbios/openbios/blob/master/forth/device/package.fs#...
but I don't understand how these work and why they don't return correct
values.
Regards,
BALATON Zoltan
0 > "
/pci/ATY" select-dev ok
It's called open-dev since ages, fwiw. 0 > my-self
. 1fc5abfc ok
0 > my-space ok
1 > . 0 ok
This one should be 7800
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
Those all look fine.
I think these my-* values should have some
numbers instead of 0. What's
the problem here? Looks like it returns first value from reg but shouldn't
it return something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But my-space
shouldn't be zero, it's 7800 here. my-unit should be exactly identical
to my-address my-space , but it isn't for you?
5:17 p.m.
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\
\ 5.3.4.3 Get local arguments
\
: my-address ( -- phys.lo ... )
?my-self >in.device-node @
0 > my-self
. 1fc5abfc ok
0 > my-space ok
1 > . 0 ok
This one should be 7800
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
Those all look fine.
I think these my-* values should have some
numbers instead of 0. What's
the problem here? Looks like it returns first value from reg but shouldn't
it return something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But my-space
shouldn't be zero, it's 7800 here. my-unit should be exactly identical
to my-address my-space , but it isn't for you? dn.probe-addr
my-#acells tuck /l* + swap 1- 0
?do
/l - dup l@ swap
loop
drop
;
: my-space ( -- phys.hi )
?my-self >in.device-node @
dn.probe-addr @
;
: my-unit ( -- phys.lo ... phys.hi )
?my-self >in.my-unit
my-#acells tuck /l* + swap 0 ?do
/l - dup l@ swap
loop
drop
;
my-unit seems to get the info from a different place (>in.my-unit vs.
dn.probe-addr) here. Why is that? Also this brings up
further questions:
What are in, dn, ihandle, phandle? (I can probably find what do
/l and /l*
do.)
Regards,
BALATON Zoltan
6:01 p.m.
Might this document help?
https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
On Fri, Jul 19, 2019 at 5:17 PM BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
On Mon, 15 Jul 2019, Segher Boessenkool wrote:
shouldn't
my-space
0 >
my-self . 1fc5abfc ok
0 > my-space ok
1 > . 0 ok
This one should be 7800
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
Those all look fine.
> I think these my-* values should have some numbers instead of 0. What's
> the problem here? Looks like it returns first value from reg but it return
something from assigned-addresses instead?
my-address is two zeroes for configuration space addresses. But shouldn't be zero, it's 7800 here.
my-unit should be exactly identical
to my-address my-space , but it isn't for you?
So you say it should be
: my-unit my-address my-space ;
but in OpenBIOS we have (in forth/device/package.fs):
\
\ 5.3.4.3 Get local arguments
\
: my-address ( -- phys.lo ... )
?my-self >in.device-node @
dn.probe-addr
my-#acells tuck /l* + swap
1- 0
?do
/l - dup l@ swap
loop
drop
;
: my-space ( -- phys.hi )
?my-self >in.device-node @
dn.probe-addr @
;
: my-unit ( -- phys.lo ... phys.hi )
?my-self >in.my-unit
my-#acells tuck /l* + swap 0 ?do
/l - dup l@ swap
loop
drop
;
my-unit seems to get the info from a different place (>in.my-unit vs.
dn.probe-addr) here. Why is that? Also this brings
up further questions:
What are in, dn, ihandle, phandle? (I can probably find what
do /l and /l*
do.)
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
10:36 p.m.
On Fri, 19 Jul 2019, Howard Spoelstra wrote:
Might this document help?
https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
I'm sure it would help I just rather have someone else read it and then
answer my questions because I aleady have enough to read (such as ati-vga
docs, Pegasos2 chipset docs, PPC docs) so I'd not add OpenFirmware
standards and docs to this list because I don't have time for all of
these.
Regards,
BALATON Zoltan
10:58 p.m.
On Fri, Jul 19, 2019 at 10:36:36PM +0200, BALATON Zoltan wrote:
On Fri, 19 Jul 2019, Howard Spoelstra wrote:
If you do not know open firmware basics, and you refuse to learn
them, then why (and how!) do you expect us to help you with your
misunderstandings of it?
Segher
Might this document help?
https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
I'm sure it would help I just rather have someone else read it and then
answer my questions because I aleady have enough to read (such as ati-vga
docs, Pegasos2 chipset docs, PPC docs) so I'd not add OpenFirmware
standards and docs to this list because I don't have time for all of
these.
11:10 p.m.
On Fri, 19 Jul 2019, Segher Boessenkool wrote:
On Fri, Jul 19, 2019 at 10:36:36PM +0200, BALATON
Zoltan wrote:
By explaining it and answering specific questions so I can learn the small
part I need without reading through hundreds of pages? For someone who
already read the docs or know these it's probably easy to see why I'm
wrong and correct me or point me to the pages I should read to clear my
misunderstanding while for me who knows nothing about it I don't even know
where to look for an answer. I ask questions here because I hope to get it
done quicker that way than learning everything myself to the point that I
can do it alone. I'm not refusing to learn but I don't have time to make
myself an Open Firmware expert first to be able to make some changes. I
hope those who are already experts could help me here this way. That's
what a development mailing list is for isn't it? As for why, I do this
because no one else does and I need a firmware for the machines I'm trying
to emulate in QEMU.
Regards,
BALATON Zoltan
On Fri, 19 Jul 2019, Howard Spoelstra wrote:
If you do not know open firmware basics, and you refuse to learn
them, then why (and how!) do you expect us to help you with your
misunderstandings of it? Might this document help?
https://docs.oracle.com/cd/E63648_01/pdf/806-1379.pdf
I'm sure it would help I just rather have someone else read it and then
answer my questions because I aleady have enough to read (such as ati-vga
docs, Pegasos2 chipset docs, PPC docs) so I'd not add OpenFirmware
standards and docs to this list because I don't have time for all of
these.
12:52 a.m.
Okay, let's try to start at the start then...
You need to know the #address-cells of the bus your device sits on
(its parent node), and the reg of your device.
"cells" means 32-bit integers in this context. For PCI buses, it is 3.
Addresses on a PCI bus consist of three 32-bit integers, in open firmware.
The address used to identify your device is the first address in reg .
It is the PCI configuration space address. This address has the last two
cells zero always. The first cell is busdevfn. See page 4 and 5 of
https://www.openfirmware.info/data/docs/bus.pci.pdf .
my-space give you that first cell. my-address gives you the rest, so
two zeroes here. my-unit gives you all three.
my-unit is more complicated for "wildcard nodes", but you can ignore that
stuff. And things are of course a bit different while the device tree is
being constructed.
Segher
3:44 a.m.
On Fri, 19 Jul 2019, Segher Boessenkool wrote:
The address used to identify your device is the first
address in reg .
It is the PCI configuration space address. This address has the last two
cells zero always. The first cell is busdevfn. See page 4 and 5 of
https://www.openfirmware.info/data/docs/bus.pci.pdf .
my-space give you that first cell. my-address gives you the rest, so
two zeroes here. my-unit gives you all three.
OK thanks it makes more sense now (I haven't yet checked the doc but
probably will look at it later). At least for the problem of running ATI
FCode ROM, based on the above I think the pci-map-in implemented in
OpenBIOS's pci driver approximately does what map-in we're missing should
do:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L413
I've also found before that the other missing words seem to have similar
but differently named implementations in OpenBIOS as well:
On Mon, 15 Jul 2019, BALATON Zoltan wrote:
Investigating it some more I've found that in
OpenBIOS we're missing the
register read/write words: r[bwl][!@] besides the pci config-[bwl][!@]
words. However we have non-standard io[cwl][!@] words instead
(implemented by the io[cwl]{fetch,store} functions in kernel/forth.c)
which I think correspond to the missing r[bwl][!@] words so these could
be aliased to those. For pci config access we also have non-standard
equivalents in
https://github.com/openbios/openbios/blob/master/forth/util/pci.fs
These pci-* words are not much used so maybe we could just rename them
to config-* to match OpemFirmware?
Does anyone see a problem with that or do you think this could work?
So I could try to connect the dots and make a patch to test this but is
there a way to try from OpenBIOS command line first without patching? I
can define words for r* and config-* words like:
: rb! ioc! ; : rb@ ioc@ ;
: config-b! pci-c! ; : config-b@ pci-c@ ;
and so on for w and l but how do I define map-in? This should be a method
of the parent of the device so it should be added to /pci@f2000000 somehow
where it now has pci-map-in. Is there a way to define a new method that's
alias of an existing one?
Or maybe it's easier to just rename pci-map-in in source as it only seems
to be used by the vga driver FCode part in drivers/vga.fs (where it is
used to map PCI BARs of the card, the same as the ATI ROM is trying to
do). So is there a reason this is not yet called map-in but pci-map in?
I'll try this when I'll have time but if anyone else wants to test this
and come up with a patch I won't mind. (One can tell if it works if the
ATI FCode pokes the ati-vga card regs which can be seen with -trace
enable='ati*' on QEMU command line.)
Regards,
BALATON Zoltan
5:19 p.m.
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
based on the above I think the pci-map-in implemented
in OpenBIOS's pci
driver approximately does what map-in we're missing should do:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L413
[...]
Or maybe it's easier to just rename pci-map-in in
source as it only seems to
be used by the vga driver FCode part in drivers/vga.fs (where it is used to
map PCI BARs of the card, the same as the ATI ROM is trying to do). So is
there a reason this is not yet called map-in but pci-map in?
I've tried renaming pci-map-in to map-in but it does not seem to work for
what the ATI FCode is trying to do. I've also enabled PCI debugging
options in OpenBIOS and QEMU, here are some logs I got (this is with the
pci-set-args patch we talked about earlier plus renaming pci-map-in to
map-in in drivers/pci.c):
[Cut some logs of init-ing other PCI cards, similar as below for ati-vga]
3233@1563634437.470612:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002
3233@1563634437.470616:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046
3233@1563634437.470619:pci_cfg_read ati-vga 15:0 @0xa -> 0x300
3233@1563634437.470622:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0
> 0:f.0 - 1002:5046 -
3233@1563634437.470675:pci_cfg_read ati-vga 15:0 @0xe -> 0x0
/pci@f2000000/ATY -
3233@1563634437.471882:pci_cfg_read ati-vga 15:0 @0x3d -> 0x0
3233@1563634437.471886:pci_cfg_read ati-vga 15:0 @0x10 -> 0x8
3233@1563634437.471889:pci_cfg_write ati-vga 15:0 @0x10 <- 0xffffffff
3233@1563634437.471892:pci_cfg_read ati-vga 15:0 @0x10 -> 0xff000008
changing mem_base from 0x80400000 to 0x82000000
> Configuring BARs for /pci@f2000000/ATY: reloc
0x81000000 omask 0x8
io_base 0x1000 mem_base 0x82000000 size 0x1000000
3233@1563634437.472242:pci_cfg_write ati-vga 15:0 @0x10 <- 0x81000008
3233@1563634437.472254:pci_cfg_read ati-vga 15:0 @0x14 -> 0x1
3233@1563634437.472257:pci_cfg_write ati-vga 15:0 @0x14 <- 0xffffffff
3233@1563634437.472260:pci_cfg_read ati-vga 15:0 @0x14 -> 0xffffff01
> changing io_base from 0x1000 to 0x1100
> Configuring BARs for /pci@f2000000/ATY: reloc 0x1000 omask 0x1 io_base
0x1100
mem_base 0x82000000 size 0x100
3233@1563634437.472556:pci_cfg_write ati-vga 15:0 @0x14 <- 0x1001
3233@1563634437.472566:pci_cfg_read ati-vga 15:0 @0x18 -> 0x0
3233@1563634437.472569:pci_cfg_write ati-vga 15:0 @0x18 <- 0xffffffff
3233@1563634437.472571:pci_cfg_read ati-vga 15:0 @0x18 -> 0xffffc000
> changing mem_base from 0x82000000 to 0x82010000
> Configuring BARs for /pci@f2000000/ATY: reloc 0x82000000 omask 0x0
io_base
0x1100 mem_base 0x82010000 size 0x10000
3233@1563634437.472878:pci_cfg_write ati-vga 15:0 @0x18 <- 0x82000000
3233@1563634437.472881:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0
3233@1563634437.472884:pci_cfg_write ati-vga 15:0 @0x1c <- 0xffffffff
3233@1563634437.472886:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0
3233@1563634437.472889:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0
3233@1563634437.472891:pci_cfg_write ati-vga 15:0 @0x20 <- 0xffffffff
3233@1563634437.472893:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0
3233@1563634437.472896:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0
3233@1563634437.472898:pci_cfg_write ati-vga 15:0 @0x24 <- 0xffffffff
3233@1563634437.472901:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0
3233@1563634437.472903:pci_cfg_read ati-vga 15:0 @0x30 -> 0x0
3233@1563634437.472906:pci_cfg_write ati-vga 15:0 @0x30 <- 0xffffffff
3233@1563634437.472908:pci_cfg_read ati-vga 15:0 @0x30 -> 0xffff0001
> changing mem_base from 0x82010000 to 0x82020000
> Configuring BARs for /pci@f2000000/ATY: reloc 0x82010000 omask 0x1
io_base
0x1100 mem_base 0x82020000 size 0x10000
3233@1563634437.473236:pci_cfg_write ati-vga 15:0 @0x30 <- 0x82010001
3233@1563634437.473240:pci_cfg_read ati-vga 15:0 @0x4 -> 0x0
3233@1563634437.473242:pci_cfg_write ati-vga 15:0 @0x4 <- 0x3
3233@1563634437.473244:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0
0,0x81000000+0x1000000
pci_update_mappings: adding bar 0 to unin-pci-mmio @ 0x81000000
3233@1563634437.473322:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0
1,0x1000+0x100
pci_update_mappings: adding bar 1 to unin-pci-isa-mmio @ 0x1000
3233@1563634437.473409:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0
2,0x82000000+0x4000
pci_update_mappings: adding bar 2 to unin-pci-mmio @ 0x82000000
3233@1563634437.473531:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0
6,0x82010000+0x10000
pci_update_mappings: adding bar 6 to unin-pci-mmio @ 0x82010000
3233@1563634437.473639:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002
3233@1563634437.473643:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046
3233@1563634437.473645:pci_cfg_read ati-vga 15:0 @0x8 -> 0x0
3233@1563634437.473647:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0
3233@1563634437.473649:pci_cfg_read ati-vga 15:0 @0xa -> 0x300
3233@1563634437.473914:pci_cfg_read ati-vga 15:0 @0x3e -> 0x0
3233@1563634437.474012:pci_cfg_read ati-vga 15:0 @0x3f -> 0x0
3233@1563634437.474146:pci_cfg_read ati-vga 15:0 @0x6 -> 0x0
3233@1563634437.474261:pci_cfg_read ati-vga 15:0 @0x2c -> 0x1af4
3233@1563634437.474380:pci_cfg_read ati-vga 15:0 @0x2e -> 0x1100
3233@1563634437.474515:pci_cfg_read ati-vga 15:0 @0xc -> 0x0
> ob_pci_encode_unit space=0 dev=15 fn=0 buf=f
> === CHANGED === package path old=/pci@f2000000/ATY
new=/pci@f2000000/ATY@f
> pci_set_reg reg 00007800 00000000 00000000
00000000 00000000 42007810
00000000 00000000 00000000 01000000 01007814 00000000
00000000 00000000
00000100 02007818 00000000 00000000 00000000 00004000
3233@1563634437.593836:pci_cfg_read uni-north-pci 11:0 @0x30 -> 0x0
3233@1563634437.593845:pci_cfg_write uni-north-pci 11:0 @0x0 <- 0x1
> ob_pci_decode_unit idx=1fc5a984
> ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800
> ob_pci_bar_map_in idx=1fc5a984
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5a984
> ob_pci_map: phys=0x81000000 size=16777216
> ob_pci_decode_unit idx=1fc5a984
> ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800
3233@1563634437.781563:pci_cfg_write uni-north-pci 11:0 @0x1a <- 0x0
> bridge /pci@f2000000 PCI bus primary=0 secondary=0
subordinate=0
3233@1563634437.781711:pci_cfg_write uni-north-pci 11:0 @0x22 <-
0x8200
3233@1563634437.781718:pci_cfg_write uni-north-pci 11:0 @0x32 <- 0x0
3233@1563634437.781724:pci_cfg_write uni-north-pci 11:0 @0x1d <- 0x10
3233@1563634437.781729:pci_cfg_read uni-north-pci 11:0 @0x4 -> 0x3
> setting bus range for /pci@f2000000 PCI device,
package handle fff5b0a8
bus primary=0 secondary=0 subordinate=0
> setting up interrupt map for host fff5b0a8
> set_property: NULL phandle
>
=============================================================
> OpenBIOS 1.1 [Jul 20 2019 14:01]
> Configuration device id QEMU version 1 machine id 1
> CPUs: 1
> Memory: 512M
> UUID: 00000000-0000-0000-0000-000000000000
> CPU type PowerPC,G4
milliseconds isn't unique.
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=1fc5ab54
> ob_pci_decode_unit idx=1fc5ab54 addr=00000000 00000000 00006000
> ob_pci_encode_unit space=0 dev=13 fn=0 buf=d
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=1fc5acc0
> ob_pci_decode_unit idx=1fc5acc0 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=1fc5adc8
> ob_pci_decode_unit idx=1fc5adc8 addr=00000000 00000000 00006000
Welcome to
OpenBIOS v1.1 built on Jul 20 2019 14:01
0 > dev /pci@f2000000/ATY ok
0 > .properties
name "ATY"
vendor-id 1002
device-id 5046
revision-id 0
class-code 30000
min-grant 0
max-latency 0
devsel-speed 0
subsystem-vendor-id 1af4
subsystem-id 1100
cache-line-size 0
device_type "display"
model "ATY Rage128"
compatible "VGA"
assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00
00 00 00 01 00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00
01 00 02 00 78 18 00 00 00 00 82 00 00 00 00 00 00 00 00 00 40 00
reg 00007800 00000000 00000000 00000000 00000000
42007810 00000000 00000000 00000000 01000000
01007814 00000000 00000000 00000000 00000100
02007818 00000000 00000000 00000000 00004000
width 320
height 258
depth 20
linebytes c80
address 81000000
ok
0 > " /pci@f2000000/ATY" open-dev to my-self ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-space . 7800 ok
0 > my-address h# 1000014 my-space + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent >> ob_pci_bar_map_in idx=1fc5aef4
> ob_pci_map: phys=0x00000000 size=256
ok
1 > . -1 ok
0 >
So the ob_pci_bus_map_in() in drivers/pci.c is called but it does not find
the correct phys address to map. This is done in ob_pci_map() where I've
added a debug message before of_mem_claim_phys() is called. Before that it
has these calls:
pci_decode_pci_addr(ba, &flags, &space_code, &mask);
phys = pci_bus_addr_to_host_addr(space_code,
ba & ~mask);
So one of these does not work correctly and cannot find the requested
space of the card. Maybe this only works for BARs but we need config space
here which is not yet supported? Does the above make sense to anyone or
do I have to trace it back myself?
Regards,
BALATON Zoltan
5:39 p.m.
On 20/07/2019 16:19, BALATON Zoltan wrote:
On Sat, 20 Jul 2019, BALATON Zoltan wrote:
I'm fairly sure the reason I named the function pci-map-in rather than just map-in is
because it doesn't quite follow the spec, but it's enough to allow us to map
various
devices within memory such as the in-built VGA driver in vga.fs (see there for an
example usage).
Probably the correct solution is to create a call-parent chain much like the dma-*
words which should also enable you to get rid of the hack that is
pci_bus_addr_to_host_addr(). Also looking at your Forth above where you are about to
call map-in for a PCI device the parameters look correct, so it's really the PCI
mapping function that needs to be tweaked here.
ATB,
Mark.
based on the above I think the pci-map-in
implemented in OpenBIOS's pci driver
approximately does what map-in we're missing should do:
https://github.com/openbios/openbios/blob/master/drivers/pci.c#L413
[...]
Or maybe it's easier to just rename
pci-map-in in source as it only seems to be
used by the vga driver FCode part in drivers/vga.fs (where it is used to map PCI
BARs of the card, the same as the ATI ROM is trying to do). So is there a reason
this is not yet called map-in but pci-map in?
I've tried renaming pci-map-in to map-in but it does not seem to work for what the
ATI FCode is trying to do. I've also enabled PCI debugging options in OpenBIOS and
QEMU, here are some logs I got (this is with the pci-set-args patch we talked about
earlier plus renaming pci-map-in to map-in in drivers/pci.c):
[Cut some logs of init-ing other PCI cards, similar as below for ati-vga]
3233@1563634437.470612:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002
3233@1563634437.470616:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046
3233@1563634437.470619:pci_cfg_read ati-vga 15:0 @0xa -> 0x300
3233@1563634437.470622:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0
> 0:f.0 - 1002:5046 -
3233@1563634437.470675:pci_cfg_read ati-vga 15:0 @0xe -> 0x0
/pci@f2000000/ATY -
3233@1563634437.471882:pci_cfg_read ati-vga 15:0 @0x3d -> 0x0
3233@1563634437.471886:pci_cfg_read ati-vga 15:0 @0x10 -> 0x8
3233@1563634437.471889:pci_cfg_write ati-vga 15:0 @0x10 <- 0xffffffff
3233@1563634437.471892:pci_cfg_read ati-vga 15:0 @0x10 -> 0xff000008
changing mem_base from 0x80400000 to 0x82000000
> Configuring BARs for /pci@f2000000/ATY: reloc
0x81000000 omask 0x8
io_base 0x1000 mem_base 0x82000000 size 0x1000000
3233@1563634437.472242:pci_cfg_write ati-vga 15:0 @0x10 <- 0x81000008
3233@1563634437.472254:pci_cfg_read ati-vga 15:0 @0x14 -> 0x1
3233@1563634437.472257:pci_cfg_write ati-vga 15:0 @0x14 <- 0xffffffff
3233@1563634437.472260:pci_cfg_read ati-vga 15:0 @0x14 -> 0xffffff01
> changing io_base from 0x1000 to 0x1100
> Configuring BARs for /pci@f2000000/ATY: reloc 0x1000 omask 0x1 io_base
0x1100
mem_base 0x82000000 size 0x100
3233@1563634437.472556:pci_cfg_write ati-vga 15:0 @0x14 <- 0x1001
3233@1563634437.472566:pci_cfg_read ati-vga 15:0 @0x18 -> 0x0
3233@1563634437.472569:pci_cfg_write ati-vga 15:0 @0x18 <- 0xffffffff
3233@1563634437.472571:pci_cfg_read ati-vga 15:0 @0x18 -> 0xffffc000
> changing mem_base from 0x82000000 to
0x82010000
> Configuring BARs for /pci@f2000000/ATY: reloc 0x82000000 omask 0x0
io_base
0x1100 mem_base 0x82010000 size 0x10000
3233@1563634437.472878:pci_cfg_write ati-vga 15:0 @0x18 <- 0x82000000
3233@1563634437.472881:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0
3233@1563634437.472884:pci_cfg_write ati-vga 15:0 @0x1c <- 0xffffffff
3233@1563634437.472886:pci_cfg_read ati-vga 15:0 @0x1c -> 0x0
3233@1563634437.472889:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0
3233@1563634437.472891:pci_cfg_write ati-vga 15:0 @0x20 <- 0xffffffff
3233@1563634437.472893:pci_cfg_read ati-vga 15:0 @0x20 -> 0x0
3233@1563634437.472896:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0
3233@1563634437.472898:pci_cfg_write ati-vga 15:0 @0x24 <- 0xffffffff
3233@1563634437.472901:pci_cfg_read ati-vga 15:0 @0x24 -> 0x0
3233@1563634437.472903:pci_cfg_read ati-vga 15:0 @0x30 -> 0x0
3233@1563634437.472906:pci_cfg_write ati-vga 15:0 @0x30 <- 0xffffffff
3233@1563634437.472908:pci_cfg_read ati-vga 15:0 @0x30 -> 0xffff0001
> changing mem_base from 0x82010000 to
0x82020000
> Configuring BARs for /pci@f2000000/ATY: reloc 0x82010000 omask 0x1
io_base
0x1100 mem_base 0x82020000 size 0x10000
3233@1563634437.473236:pci_cfg_write ati-vga 15:0 @0x30 <- 0x82010001
3233@1563634437.473240:pci_cfg_read ati-vga 15:0 @0x4 -> 0x0
3233@1563634437.473242:pci_cfg_write ati-vga 15:0 @0x4 <- 0x3
3233@1563634437.473244:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0
0,0x81000000+0x1000000
pci_update_mappings: adding bar 0 to unin-pci-mmio @ 0x81000000
3233@1563634437.473322:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0 1,0x1000+0x100
pci_update_mappings: adding bar 1 to unin-pci-isa-mmio @ 0x1000
3233@1563634437.473409:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0
2,0x82000000+0x4000
pci_update_mappings: adding bar 2 to unin-pci-mmio @ 0x82000000
3233@1563634437.473531:pci_update_mappings_add d=0x55ef8ac6e280 00:0f.0
6,0x82010000+0x10000
pci_update_mappings: adding bar 6 to unin-pci-mmio @ 0x82010000
3233@1563634437.473639:pci_cfg_read ati-vga 15:0 @0x0 -> 0x1002
3233@1563634437.473643:pci_cfg_read ati-vga 15:0 @0x2 -> 0x5046
3233@1563634437.473645:pci_cfg_read ati-vga 15:0 @0x8 -> 0x0
3233@1563634437.473647:pci_cfg_read ati-vga 15:0 @0x9 -> 0x0
3233@1563634437.473649:pci_cfg_read ati-vga 15:0 @0xa -> 0x300
3233@1563634437.473914:pci_cfg_read ati-vga 15:0 @0x3e -> 0x0
3233@1563634437.474012:pci_cfg_read ati-vga 15:0 @0x3f -> 0x0
3233@1563634437.474146:pci_cfg_read ati-vga 15:0 @0x6 -> 0x0
3233@1563634437.474261:pci_cfg_read ati-vga 15:0 @0x2c -> 0x1af4
3233@1563634437.474380:pci_cfg_read ati-vga 15:0 @0x2e -> 0x1100
3233@1563634437.474515:pci_cfg_read ati-vga 15:0 @0xc -> 0x0
> ob_pci_encode_unit space=0 dev=15 fn=0 buf=f
> === CHANGED === package path
old=/pci@f2000000/ATY
new=/pci@f2000000/ATY@f
> pci_set_reg reg 00007800 00000000 00000000
00000000 00000000 42007810
00000000 00000000 00000000 01000000 01007814 00000000
00000000 00000000 00000100
02007818 00000000 00000000 00000000 00004000
3233@1563634437.593836:pci_cfg_read uni-north-pci 11:0 @0x30 -> 0x0
3233@1563634437.593845:pci_cfg_write uni-north-pci 11:0 @0x0 <- 0x1
> ob_pci_decode_unit idx=1fc5a984
> ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800
> ob_pci_bar_map_in idx=1fc5a984
> ob_pci_map: phys=0x82000000 size=16384
> ob_pci_bar_map_in idx=1fc5a984
> ob_pci_map: phys=0x81000000 size=16777216
> ob_pci_decode_unit idx=1fc5a984
> ob_pci_decode_unit idx=1fc5a984 addr=00000000 00000000 00007800
3233@1563634437.781563:pci_cfg_write uni-north-pci 11:0 @0x1a <- 0x0
> bridge /pci@f2000000 PCI bus primary=0
secondary=0 subordinate=0
3233@1563634437.781711:pci_cfg_write uni-north-pci 11:0
@0x22 <- 0x8200
3233@1563634437.781718:pci_cfg_write uni-north-pci 11:0 @0x32 <- 0x0
3233@1563634437.781724:pci_cfg_write uni-north-pci 11:0 @0x1d <- 0x10
3233@1563634437.781729:pci_cfg_read uni-north-pci 11:0 @0x4 -> 0x3
> setting bus range for /pci@f2000000 PCI
device, package handle fff5b0a8
bus primary=0 secondary=0 subordinate=0
> setting up interrupt map for host fff5b0a8
> set_property: NULL phandle
>
=============================================================
> OpenBIOS 1.1 [Jul 20 2019 14:01]
> Configuration device id QEMU version 1 machine id 1
> CPUs: 1
> Memory: 512M
> UUID: 00000000-0000-0000-0000-000000000000
> CPU type PowerPC,G4
milliseconds isn't unique.
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=1fc5ab54
> ob_pci_decode_unit idx=1fc5ab54 addr=00000000 00000000 00006000
> ob_pci_encode_unit space=0 dev=13 fn=0 buf=d
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=1fc5acc0
> ob_pci_decode_unit idx=1fc5acc0 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=fff5b130
> ob_pci_decode_unit idx=fff5b130 addr=00000000 00000000 00006000
> ob_pci_decode_unit idx=1fc5adc8
> ob_pci_decode_unit idx=1fc5adc8 addr=00000000 00000000 00006000
Welcome to
OpenBIOS v1.1 built on Jul 20 2019 14:01
0 > dev /pci@f2000000/ATY ok
0 > .properties
name "ATY"
vendor-id 1002
device-id 5046
revision-id 0
class-code 30000
min-grant 0
max-latency 0
devsel-speed 0
subsystem-vendor-id 1af4
subsystem-id 1100
cache-line-size 0
device_type "display"
model "ATY Rage128"
compatible "VGA"
assigned-addresses -- 3c : 42 00 78 10 00 00 00 00 81 00 00 00 00 00 00 00 01
00 00 00 01 00 78 14 00 00 00 00 00 00 10 00 00 00 00 00 00 00 01 00 02 00 78 18 00
00 00 00 82 00 00 00 00 00 00 00 00 00 40 00
reg 00007800 00000000 00000000 00000000 00000000
42007810 00000000 00000000 00000000 01000000
01007814 00000000 00000000 00000000 00000100
02007818 00000000 00000000 00000000 00004000
width 320
height 258
depth 20
linebytes c80
address 81000000
ok
0 > " /pci@f2000000/ATY" open-dev to my-self ok
0 > my-unit ok
3 > . 7800 ok
2 > . 0 ok
1 > . 0 ok
0 > my-address ok
2 > . 0 ok
1 > . 0 ok
0 > my-space . 7800 ok
0 > my-address h# 1000014 my-space + h# 100 ok
4 > .s <4> 0 0 1007814 100
ok
4 > " map-in" $call-parent >> ob_pci_bar_map_in idx=1fc5aef4
> ob_pci_map: phys=0x00000000 size=256
ok
1 > . -1 ok
0 >
So the ob_pci_bus_map_in() in drivers/pci.c is called but it does not find the
correct phys address to map. This is done in ob_pci_map() where I've added a debug
message before of_mem_claim_phys() is called. Before that it has these calls:
pci_decode_pci_addr(ba, &flags, &space_code, &mask);
phys = pci_bus_addr_to_host_addr(space_code,
ba & ~mask);
So one of these does not work correctly and cannot find the requested space of the
card. Maybe this only works for BARs but we need config space here which is not yet
supported? Does the above make sense to anyone or do I have to trace it back myself?
6:07 p.m.
On Sat, Jul 20, 2019 at 04:39:08PM +0100, Mark Cave-Ayland wrote:
I'm fairly sure the reason I named the function
pci-map-in rather than just map-in is
because it doesn't quite follow the spec, but it's enough to allow us to map
various
devices within memory such as the in-built VGA driver in vga.fs (see there for an
example usage).
There is no standard map-in word, only map-in device methods, which can
be different for each (bus) node. It is convenient to have some global
words that work for many buses on a system, like your pci-map-in
probably is; it is also helpful to have separate names for them then,
to ease debugging.
Segher
2:18 a.m.
On Sat, 20 Jul 2019, Mark Cave-Ayland wrote:
Probably the correct solution is to create a
call-parent chain much like the dma-*
words which should also enable you to get rid of the hack that is
pci_bus_addr_to_host_addr().
Maybe we don't need a chain up to the root for this. SLOF seems to
translate adresses by looking at the parent's ranges property. See
translate-address in this file:
https://github.com/aik/SLOF/blob/master/slof/fs/translate.fs
This is used to implement map-in as well:
https://github.com/aik/SLOF/blob/master/slof/fs/pci-config-bridge.fs
Maybe we should do the same (either in Forth or in C).
Regards,
BALATON Zoltan
12:30 a.m.
Hello,
OK back to this thread now that map-in and other missing words are
implemented enough to test this (improvements to the pci-map-in patch will
be in the implementing map-in thread, this is about running the FCode
ROM now to keep it organised).
With my last pci-map-in patch on top of Mark's device tree creation and
set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct
picture yet with MacOS (and maybe the NDRV does not fully init yet).
You'll also need these two QEMU patches at the moment before they are
merged in QEMU:
http://patchwork.ozlabs.org/patch/1127919/
http://patchwork.ozlabs.org/patch/1136568/
The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110
FCode ROM), the other one tries to add registers the NDRV seems to access
but not sure if those are correct.
The FCode ROM switches mode but does that before reading EDID and with
parameters that I can't handle from the emulation so the question is why
it selects this mode and if this is correct. What mode does it set on real
hardware? Before setting the mode it tries to access another set of
registers similar to what is used to get the EDID. These are called
AMCGPIO in the doc but not explained what that is. AMC may be ATI
Multimedia Channel which is an ATI specific feature connector but I'm not
sure. Does it try to access some info over that? Does the card have
multiple connectors and it expects the primary display somewhere else than
what we emulate? The NDRV also only seems to try the AMCGPIO regs and stop
after that without trying the switch mode. Does anyone have any info on
this or knows about some source of info?
Regards,
BALATON Zoltan
6:02 p.m.
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
With my last pci-map-in patch on top of Mark's
device tree creation and
set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct
picture yet with MacOS (and maybe the NDRV does not fully init yet).
You'll also need these two QEMU patches at the moment before they are merged
in QEMU:
http://patchwork.ozlabs.org/patch/1127919/
http://patchwork.ozlabs.org/patch/1136568/
The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode
ROM), the other one tries to add registers the NDRV seems to access but not
sure if those are correct.
The FCode ROM switches mode but does that before reading EDID and with
parameters that I can't handle from the emulation so the question is why it
Here's another QEMU patch that hopefully fixes handling the offset that is
set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the
VGA driver of OpenBIOS and the FCode ROM programming the card and setting
up its own words but I'm not sure OpenBIOS uses those and maybe blindly
continues to use its own driver instead which no longer works after FCode
ROM has set up the card. Maybe the gfx card initialisation should now be
fixed in OpenBIOS to allow proper FCode ROMs to init the card and turn the
OpenBIOS vga driver into FCode as well so it works more like it should on
real hardware. This looks like a welcome clean up but I'm not volunteering
to do that because I don't know enough about how this should work just so
I'm bringing up the topic here for comments.
selects this mode and if this is correct. What mode
does it set on real
hardware? Before setting the mode it tries to access another set of registers
similar to what is used to get the EDID. These are called AMCGPIO in the doc
but not explained what that is. AMC may be ATI Multimedia Channel which is an
ATI specific feature connector but I'm not sure. Does it try to access some
info over that? Does the card have multiple connectors and it expects the
primary display somewhere else than what we emulate? The NDRV also only seems
to try the AMCGPIO regs and stop after that without trying the switch mode.
Does anyone have any info on this or knows about some source of info?
This is still the same. I wonder if MacOS uses the firmware routines to
draw before the NDRV is inited and picture is now broken because OpenBIOS
does not know about what the FCode has done and uses the wrong routines to
drive the card? Then next question is why NDRV stops but I can't answer
that because it gives no error and just stops accessing card regs after
attempting to read something (EDID?) from AMCGPIO regs and getting BAR
addresses. So someone may need to debug the NDRV to find out.
Regards,
BALATON Zoltan
1 a.m.
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
> With my last pci-map-in patch on top of Mark's device tree creation and
> set-args fixes to OpenBIOS the FCode ROM now runs but we don't get correct
> picture yet with MacOS (and maybe the NDRV does not fully init yet).
>
> You'll also need these two QEMU patches at the moment before they are
> merged in QEMU:
>
> http://patchwork.ozlabs.org/patch/1127919/
> http://patchwork.ozlabs.org/patch/1136568/
>
> The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110
> FCode ROM), the other one tries to add registers the NDRV seems to access
> but not sure if those are correct.
>
> The FCode ROM switches mode but does that before reading EDID and with
> parameters that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not
the DVI. The ROM tries to get EDID from flat panel (DVI?) first, if it
finds that it won't init the CRTC part so we get no picture. Therefore I
think this is now OK and what happens is FCode tries reading EDID from DVI
and when that fails switches to VGA port and sets default mode before
reading EDID which it then puts in the device tree. I'm not sure how it
selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully fixes
handling the offset that is
set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA
driver of OpenBIOS and the FCode ROM programming the card and setting up its
own words but I'm not sure OpenBIOS uses those and maybe blindly continues to
use its own driver instead which no longer works after FCode ROM has set up
the card. Maybe the gfx card initialisation should now be fixed in OpenBIOS
to allow proper FCode ROMs to init the card and turn the OpenBIOS vga driver
into FCode as well so it works more like it should on real hardware. This
looks like a welcome clean up but I'm not volunteering to do that because I
don't know enough about how this should work just so I'm bringing up the
topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during
booting MacOS but we could not find out yet. It also tries getting DFP
EDID but it does not matter if it finds that or not. Then queries BAR
addresses and after trying to switch to mmio it stops working. I've
compared device tree properties after FCode run to those on real hardware
and found these differences:
1. address is missing the 8000 offset that also appears in the screen
mode it switches to but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is
likely wrong not what causing the NDRV to exit.
2. reg property matches but assigned-addresses has several differences
(probably need my patch from openbios list to see it). In OpenBIOS we have
io BAR mapped but ROM BAR not mapped and the vram BAR size is 1000000
instead of 4000000 (i.e. only 4M vram is mapped instead of the full vram).
Not sure if any of these causes problem with NDRV.
OpenBIOS:
assigned-addresses 42007810 00000000 81000000 00000000 01000000
01007814 00000000 00001000 00000000 00000100
02007818 00000000 82000000 00000000 00004000
reg 00007800 00000000 00000000 00000000 00000000
02007830 00000000 00000000 00000000 00020000
42007810 00000000 00000000 00000000 04000000
02007818 00000000 00000000 00000000 00004000
real machine:
assigned-addresses c2008010 00000000 94000000 00000000 04000000
82008030 00000000 90020000 00000000 00020000
82008018 00000000 90000000 00000000 00004000
reg 00008000 00000000 00000000 00000000 00000000
02008030 00000000 00000000 00000000 00020000
42008010 00000000 00000000 00000000 04000000
02008018 00000000 00000000 00000000 00004000
3. We don't have AGP_Master and ATYN property. The AGP one is likely not
needed but not sure about what ATYN is.
> hardware? Before setting the mode it tries to
access another set of
> registers similar to what is used to get the EDID. These are called AMCGPIO
> in the doc but not explained what that is. AMC may be ATI Multimedia
> Channel which is an ATI specific feature connector but I'm not sure. Does
> it try to access some info over that? Does the card have multiple
> connectors and it expects the primary display somewhere else than what we
> emulate? The NDRV also only seems to try the AMCGPIO regs and stop after
> that without trying the switch mode. Does anyone have any info on this or
> knows about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think
it's maybe connected to DVI port or it's unused on the card and useful in
laptops. In any case we don't emulate DFP controller only CRT so this is
not needed and likely not where NDRV fails as it does run a bit further
after this.
This is still the same. I wonder if MacOS uses the
firmware routines to draw
before the NDRV is inited and picture is now broken because OpenBIOS does not
know about what the FCode has done and uses the wrong routines to drive the
card? Then next question is why NDRV stops but I can't answer that because it
gives no error and just stops accessing card regs after attempting to read
something (EDID?) from AMCGPIO regs and getting BAR addresses. So someone may
need to debug the NDRV to find out.
Still don't know what happens with NDRV, it's not the missing EDID from
AMCGPIO regs and not the wrong address property. The last thing the NDRV
appears to do is getting mmio and ROM BARs then trying to set up mmio but
after that no register writes or reads reach the card but I'm not sure
why.
I think that's enough for me of this, I'll let others who are interested
in making this work experiment with it and find out.
Regards,
BALATON Zoltan
12:08 p.m.
Executing the FCode ROM completely screws up all the address and device properties in
PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device
ID’s.
On Jul 27, 2019, at 7:00 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
> With my last pci-map-in patch on top of Mark's device tree creation and set-args
fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with
MacOS (and maybe the NDRV does not fully init yet).
> You'll also need these two QEMU patches at the moment before they are merged in
QEMU:
> http://patchwork.ozlabs.org/patch/1127919/
> http://patchwork.ozlabs.org/patch/1136568/
> The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM),
the other one tries to add registers the NDRV seems to access but not sure if those are
correct.
> The FCode ROM switches mode but does that before reading EDID and with parameters
that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not the DVI.
The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init
the CRTC part so we get no picture. Therefore I think this is now OK and what happens is
FCode tries reading EDID from DVI and when that fails switches to VGA port and sets
default mode before reading EDID which it then puts in the device tree. I'm not sure
how it selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully
fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of
OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm
not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead
which no longer works after FCode ROM has set up the card. Maybe the gfx card
initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card
and turn the OpenBIOS vga driver into FCode as well so it works more like it should on
real hardware. This looks like a welcome clean up but I'm not volunteering to do that
because I don't know enough about how this should work just so I'm bringing up the
topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS
but we could not find out yet. It also tries getting DFP EDID but it does not matter if it
finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops
working. I've compared device tree properties after FCode run to those on real
hardware and found these differences:
1. address is missing the 8000 offset that also appears in the screen mode it switches to
but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not
what causing the NDRV to exit.
2. reg property matches but assigned-addresses has several differences (probably need my
patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not
mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped
instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS:
assigned-addresses 42007810 00000000 81000000 00000000 01000000
01007814 00000000 00001000 00000000 00000100
02007818 00000000 82000000 00000000 00004000
reg 00007800 00000000 00000000 00000000 00000000
02007830 00000000 00000000 00000000 00020000
42007810 00000000 00000000 00000000 04000000
02007818 00000000 00000000 00000000 00004000
real machine:
assigned-addresses c2008010 00000000 94000000 00000000 04000000
82008030 00000000 90020000 00000000 00020000
82008018 00000000 90000000 00000000 00004000
reg 00008000 00000000 00000000 00000000 00000000
02008030 00000000 00000000 00000000 00020000
42008010 00000000 00000000 00000000 04000000
02008018 00000000 00000000 00000000 00004000
3. We don't have AGP_Master and ATYN property. The AGP one is likely not needed but
not sure about what ATYN is.
> hardware? Before setting the mode it tries to
access another set of registers similar to what is used to get the EDID. These are called
AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which
is an ATI specific feature connector but I'm not sure. Does it try to access some info
over that? Does the card have multiple connectors and it expects the primary display
somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and
stop after that without trying the switch mode. Does anyone have any info on this or knows
about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe
connected to DVI port or it's unused on the card and useful in laptops. In any case we
don't emulate DFP controller only CRT so this is not needed and likely not where NDRV
fails as it does run a bit further after this.
This is still the same. I wonder if MacOS uses
the firmware routines to draw before the NDRV is inited and picture is now broken because
OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive
the card? Then next question is why NDRV stops but I can't answer that because it
gives no error and just stops accessing card regs after attempting to read something
(EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV
to find out.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO
regs and not the wrong address property. The last thing the NDRV appears to do is getting
mmio and ROM BARs then trying to set up mmio but after that no register writes or reads
reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in
making this work experiment with it and find out.
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
12:33 p.m.
Hello,
On Fri, 2 Aug 2019, Jd Lyons wrote:
Executing the FCode ROM completely screws up all the
address and device properties in PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device
ID’s.
You should elaboreate a bit more because I'm not sure what you did. What
FCode ROM did you run with which OpenBIOS and which card and how did it
screw up device state and properties?
Regards,
BALATON Zoltan
12:54 p.m.
I think the only properties that matter are the “ name” property and the “ EDID”
property.
I think if we just inject them correctly into the device tree for the card we will have
more success……….
On Aug 2, 2019, at 6:08 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
Executing the FCode ROM completely screws up all the address and device properties in
PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device
ID’s.
On Jul 27, 2019, at 7:00 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
> With my last pci-map-in patch on top of Mark's device tree creation and set-args
fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with
MacOS (and maybe the NDRV does not fully init yet).
> You'll also need these two QEMU patches at the moment before they are merged in
QEMU:
> http://patchwork.ozlabs.org/patch/1127919/
> http://patchwork.ozlabs.org/patch/1136568/
> The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM),
the other one tries to add registers the NDRV seems to access but not sure if those are
correct.
> The FCode ROM switches mode but does that before reading EDID and with parameters
that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not the DVI.
The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init
the CRTC part so we get no picture. Therefore I think this is now OK and what happens is
FCode tries reading EDID from DVI and when that fails switches to VGA port and sets
default mode before reading EDID which it then puts in the device tree. I'm not sure
how it selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully
fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of
OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm
not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead
which no longer works after FCode ROM has set up the card. Maybe the gfx card
initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card
and turn the OpenBIOS vga driver into FCode as well so it works more like it should on
real hardware. This looks like a welcome clean up but I'm not volunteering to do that
because I don't know enough about how this should work just so I'm bringing up the
topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS
but we could not find out yet. It also tries getting DFP EDID but it does not matter if it
finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops
working. I've compared device tree properties after FCode run to those on real
hardware and found these differences:
1. address is missing the 8000 offset that also appears in the screen mode it switches to
but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not
what causing the NDRV to exit.
2. reg property matches but assigned-addresses has several differences (probably need my
patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not
mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped
instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS:
assigned-addresses 42007810 00000000 81000000 00000000 01000000
01007814 00000000 00001000 00000000 00000100
02007818 00000000 82000000 00000000 00004000
reg 00007800 00000000 00000000 00000000 00000000
02007830 00000000 00000000 00000000 00020000
42007810 00000000 00000000 00000000 04000000
02007818 00000000 00000000 00000000 00004000
real machine:
assigned-addresses c2008010 00000000 94000000 00000000 04000000
82008030 00000000 90020000 00000000 00020000
82008018 00000000 90000000 00000000 00004000
reg 00008000 00000000 00000000 00000000 00000000
02008030 00000000 00000000 00000000 00020000
42008010 00000000 00000000 00000000 04000000
02008018 00000000 00000000 00000000 00004000
3. We don't have AGP_Master and ATYN property. The AGP one is likely not needed but
not sure about what ATYN is.
> hardware? Before setting the mode it tries to
access another set of registers similar to what is used to get the EDID. These are called
AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which
is an ATI specific feature connector but I'm not sure. Does it try to access some info
over that? Does the card have multiple connectors and it expects the primary display
somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and
stop after that without trying the switch mode. Does anyone have any info on this or knows
about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe
connected to DVI port or it's unused on the card and useful in laptops. In any case we
don't emulate DFP controller only CRT so this is not needed and likely not where NDRV
fails as it does run a bit further after this.
This is still the same. I wonder if MacOS uses
the firmware routines to draw before the NDRV is inited and picture is now broken because
OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive
the card? Then next question is why NDRV stops but I can't answer that because it
gives no error and just stops accessing card regs after attempting to read something
(EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV
to find out.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO
regs and not the wrong address property. The last thing the NDRV appears to do is getting
mmio and ROM BARs then trying to set up mmio but after that no register writes or reads
reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in
making this work experiment with it and find out.
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
3:54 p.m.
On Fri, 2 Aug 2019, Jd Lyons wrote:
I think the only properties that matter are the “
name” property and the “ EDID” property.
I think if we just inject them correctly into the device tree for the card we will have
more success……….
I don't think that's enough at least it did not work the last time I've
tried but could be I made some mistake somewhere. Maybe you'd also need
"address" at least which seems to point to the frame buffer address and
not sure EDID is needed as the NDRV seems to read it itself as well but
without checking what the NDRV does this is all just guessing and we can't
be sure. Shortest way to success would be to find out what NDRV does so we
can understand why it fails and then fix that instead of trying to find
out by trial and error.
Maybe this tool could help:
https://web.archive.org/web/20110603204602/http://developer.apple.com/too...
found as reference on
https://en.wikipedia.org/wiki/Preferred_Executable_Format
Or you could also test if adding attributes is enough by either adding
these by hand from command line or loading and executing a forth script to
do it or temporarily change drivers/vga.fs which is run also for ati-vga
so you could add forth code there to add arbitrary properties for testing.
Regards,
BALATON Zoltan
3:58 p.m.
I made a custom Mac OS ROM that injects the EDID and ATY,Rage128Ps via a script, however
that didn’t solve any issues:-(
Zoltan, did you notice that the node on the PCI bus changes after execution of the FCode
ROM, it moves from /pci/@f to /pci/@0.
I think this is why PCIPeek returns garbage and maybe why our NDRV is aborting.
On Aug 2, 2019, at 6:54 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
I think the only properties that matter are the “ name” property and the “ EDID”
property.
I think if we just inject them correctly into the device tree for the card we will have
more success……….
On Aug 2, 2019, at 6:08 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
Executing the FCode ROM completely screws up all the address and device properties in
PCIPeek under OS 9.
The card is in an unusable state, it doesn’t even have unit address, vendor or device
ID’s.
On Jul 27, 2019, at 7:00 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
On Thu, 25 Jul 2019, BALATON Zoltan wrote:
> With my last pci-map-in patch on top of Mark's device tree creation and set-args
fixes to OpenBIOS the FCode ROM now runs but we don't get correct picture yet with
MacOS (and maybe the NDRV does not fully init yet).
> You'll also need these two QEMU patches at the moment before they are merged in
QEMU:
> http://patchwork.ozlabs.org/patch/1127919/
> http://patchwork.ozlabs.org/patch/1136568/
> The GPIO_MONID patch fixes EDID access (at least for the Rage128Ps-110 FCode ROM),
the other one tries to add registers the NDRV seems to access but not sure if those are
correct.
> The FCode ROM switches mode but does that before reading EDID and with parameters
that I can't handle from the emulation so the question is why it
I've found that the card has two ports but we only emulate the VGA one not the DVI.
The ROM tries to get EDID from flat panel (DVI?) first, if it finds that it won't init
the CRTC part so we get no picture. Therefore I think this is now OK and what happens is
FCode tries reading EDID from DVI and when that fails switches to VGA port and sets
default mode before reading EDID which it then puts in the device tree. I'm not sure
how it selects default mode though, probably not from EDID.
Here's another QEMU patch that hopefully
fixes handling the offset that is set by the FCode ROM:
http://patchwork.ozlabs.org/patch/1136954/
Picture is still broken but maybe now because of a mismatch between the VGA driver of
OpenBIOS and the FCode ROM programming the card and setting up its own words but I'm
not sure OpenBIOS uses those and maybe blindly continues to use its own driver instead
which no longer works after FCode ROM has set up the card. Maybe the gfx card
initialisation should now be fixed in OpenBIOS to allow proper FCode ROMs to init the card
and turn the OpenBIOS vga driver into FCode as well so it works more like it should on
real hardware. This looks like a welcome clean up but I'm not volunteering to do that
because I don't know enough about how this should work just so I'm bringing up the
topic here for comments.
We've tried to find why the NDRV that the FCode installs fails during booting MacOS
but we could not find out yet. It also tries getting DFP EDID but it does not matter if it
finds that or not. Then queries BAR addresses and after trying to switch to mmio it stops
working. I've compared device tree properties after FCode run to those on real
hardware and found these differences:
1. address is missing the 8000 offset that also appears in the screen mode it switches to
but I don't know why. Manually changing it by
81008000 encode-int " address" property
before boot does not fix display and NDRV still hangs so while this is likely wrong not
what causing the NDRV to exit.
2. reg property matches but assigned-addresses has several differences (probably need my
patch from openbios list to see it). In OpenBIOS we have io BAR mapped but ROM BAR not
mapped and the vram BAR size is 1000000 instead of 4000000 (i.e. only 4M vram is mapped
instead of the full vram). Not sure if any of these causes problem with NDRV.
OpenBIOS:
assigned-addresses 42007810 00000000 81000000 00000000 01000000
01007814 00000000 00001000 00000000 00000100
02007818 00000000 82000000 00000000 00004000
reg 00007800 00000000 00000000 00000000 00000000
02007830 00000000 00000000 00000000 00020000
42007810 00000000 00000000 00000000 04000000
02007818 00000000 00000000 00000000 00004000
real machine:
assigned-addresses c2008010 00000000 94000000 00000000 04000000
82008030 00000000 90020000 00000000 00020000
82008018 00000000 90000000 00000000 00004000
reg 00008000 00000000 00000000 00000000 00000000
02008030 00000000 00000000 00000000 00020000
42008010 00000000 00000000 00000000 04000000
02008018 00000000 00000000 00000000 00004000
3. We don't have AGP_Master and ATYN property. The AGP one is likely not needed but
not sure about what ATYN is.
> hardware? Before setting the mode it tries to
access another set of registers similar to what is used to get the EDID. These are called
AMCGPIO in the doc but not explained what that is. AMC may be ATI Multimedia Channel which
is an ATI specific feature connector but I'm not sure. Does it try to access some info
over that? Does the card have multiple connectors and it expects the primary display
somewhere else than what we emulate? The NDRV also only seems to try the AMCGPIO regs and
stop after that without trying the switch mode. Does anyone have any info on this or knows
about some source of info?
Answering myself: this is where the EDID form the DFP is read so I think it's maybe
connected to DVI port or it's unused on the card and useful in laptops. In any case we
don't emulate DFP controller only CRT so this is not needed and likely not where NDRV
fails as it does run a bit further after this.
This is still the same. I wonder if MacOS uses
the firmware routines to draw before the NDRV is inited and picture is now broken because
OpenBIOS does not know about what the FCode has done and uses the wrong routines to drive
the card? Then next question is why NDRV stops but I can't answer that because it
gives no error and just stops accessing card regs after attempting to read something
(EDID?) from AMCGPIO regs and getting BAR addresses. So someone may need to debug the NDRV
to find out.
Still don't know what happens with NDRV, it's not the missing EDID from AMCGPIO
regs and not the wrong address property. The last thing the NDRV appears to do is getting
mmio and ROM BARs then trying to set up mmio but after that no register writes or reads
reach the card but I'm not sure why.
I think that's enough for me of this, I'll let others who are interested in
making this work experiment with it and find out.
Regards,
BALATON Zoltan
_______________________________________________
OpenBIOS mailing list -- openbios(a)openbios.org
To unsubscribe send an email to openbios-leave(a)openbios.org
4:29 p.m.
On Sat, 3 Aug 2019, Jd Lyons wrote:
Zoltan, did you notice that the node on the PCI bus
changes after
execution of the FCode ROM, it moves from /pci/@f to /pci/@0.
No I haven't noticed that nor do I know what that means and if it could
cause any problems. I think the driver should look at properties and not
the node name so I don't think it matters but I don't know. I've only
noticed the wrong address, difference in assigned-addresses property and
some differences in other properties as I've listed in my original message
that you keep quoting below your reply.
I think this is why PCIPeek returns garbage and maybe
why our NDRV is aborting.
Not sure about that. It still looks like you're just blindly guessing
instead of trying to find out what the NDRV does. I've found there
supposed to be pef support in GNU binutils so I've tried compiling it with
target powerpc-darwin that adds pef format but it did not recognise the
NDRV (maybe it supports a different pef version or has some bugs or I have
too old version). So the best tool to look at the NDRV may be the one from
MPW but I don'thave experience with that, nor a machine to try it on, nor
free time to spend on that.
Regards,
BALATON Zoltan
199
days inactive
221
days old
71 comments
5 participants
participants (5)
-
BALATON Zoltan -
Howard Spoelstra -
Jd Lyons -
Mark Cave-Ayland -
Segher Boessenkool