On Sep 20, 2016, at 8:41 PM, Benjamin Herrenschmidt wrote:
On Tue, 2016-09-20 at 20:35 -0400, G 3 wrote:
When I use the -prom-env option I can easily add properties to the options node. Can something like this be done with the chosen node?
We can make it so. That or we can add code to OpenBIOS to copy the list of resolutions into the device-node of the VGA device. The latter is probably the best, that way we can also have all the default ones in OpenBIOS and remove the hard coded list completely.
You really want to remove the included list of resolutions? I was thinking about adding a lot more built-in resolutions in another patch. A built-in list is very convenient.
As for the options node problem. We need a way to add resolutions from the command-line for a Mac OS X guest. Using "-prom-env" isn't an option because of some unknown bug. I suppose it is possible to fix this bug - if it is a bug. Another idea I have is to add a completely different command-line option to QEMU just for resolutions. The user could specify resolutions like this: -video- resolutions 640x480,1024x768,1280x700.... This feature could place the list of resolutions inside a property of the VGA device node. I am betting the VGA driver could access this node and parse the list of resolutions. So this: qemu -video-resolutions ---> OpenBIOS VGA device node ---> VGA driver
Would anyone have another idea they would like to share?
Perhaps include a base set of resolutions that the actual mac99 machine supported, implemented in OpenBIOS, and also adding the --video-resolutions option so the user may add custom entries that would be read by the VGA device if so desired. I believe that is the best compromise vs. having a huge list of resolutions hard coded in QEMU and presented to MacOS and OSX.
On Tue, 2016-09-20 at 22:54 -0400, G 3 wrote:
You really want to remove the included list of resolutions? I was thinking about adding a lot more built-in resolutions in another patch. A built-in list is very convenient.
I mean remove it from the driver and put it in OpenBIOS instead.
Ie. have openbios build the resolution list from the combination of what you put in the options node and its own built-in list.
As for the options node problem. We need a way to add resolutions from the command-line for a Mac OS X guest. Using "-prom-env" isn't an option because of some unknown bug.
Maybe, I can look into it later, but the above would fix it nicely.
I suppose it is possible to fix this bug - if it is a bug. Another idea I have is to add a completely different command-line option to QEMU just for resolutions. The user could specify resolutions like this: -video- resolutions 640x480,1024x768,1280x700.... This feature could place the list of resolutions inside a property of the VGA device node. I am betting the VGA driver could access this node and parse the list of resolutions. So this: qemu -video-resolutions ---> OpenBIOS VGA device node ---> VGA driver
Would anyone have another idea they would like to share?
As I said. Have OpenBIOS build the list of resolutions and put it in a property (in binary, not ASCII form so the driver doesn't have to do the mess it does now) in the DT node of the device itself.
Cheers, Ben.
On Sep 21, 2016, at 5:01 AM, Benjamin Herrenschmidt wrote:
On Tue, 2016-09-20 at 22:54 -0400, G 3 wrote:
You really want to remove the included list of resolutions? I was thinking about adding a lot more built-in resolutions in another patch. A built-in list is very convenient.
I mean remove it from the driver and put it in OpenBIOS instead.
Ie. have openbios build the resolution list from the combination of what you put in the options node and its own built-in list.
That idea is shared with others. OpenBIOS might be considered easier to alter than the VGA driver, so this might be best.
As for the options node problem. We need a way to add resolutions from the command-line for a Mac OS X guest. Using "-prom-env" isn't an option because of some unknown bug.
Maybe, I can look into it later, but the above would fix it nicely.
Nodes like chose, aliases, openprom are of class IOService. options is of class IODTNVRAM. It looks like this class has problems. I'm thinking since Alexander Graf did work in the mac_nvram.c file, he might know what is wrong. I found another way to access the options node in Mac OS X. Use this command: ioreg -c IODTNVRAM. It stops at the options node and prints this error message: "ioreg: error: can't obtain properties" in QEMU. On a real Power Mac the command prints all the properties of the options node just fine.
I suppose it is possible to fix this bug - if it is a bug. Another idea I have is to add a completely different command-line option to QEMU just for resolutions. The user could specify resolutions like this: -video- resolutions 640x480,1024x768,1280x700.... This feature could place the list of resolutions inside a property of the VGA device node. I am betting the VGA driver could access this node and parse the list of resolutions. So this: qemu -video-resolutions ---> OpenBIOS VGA device node ---> VGA driver
Would anyone have another idea they would like to share?
As I said. Have OpenBIOS build the list of resolutions and put it in a property (in binary, not ASCII form so the driver doesn't have to do the mess it does now) in the DT node of the device itself.
I don't know about using binary. The way we do it now seems just fine.
I just need to figure out how to write to the /chosen node from the QEMU command line. I found a function called OpenBIOS_set_var() in openbios_firmware_abi.h, but it would require an address to write to. So where do I find the address of the /chosen node....
On Wed, 2016-09-21 at 14:26 -0400, G 3 wrote:
Nodes like chose, aliases, openprom are of class IOService. options is of class IODTNVRAM. It looks like this class has problems. I'm thinking since Alexander Graf did work in the mac_nvram.c file, he might know what is wrong.
What is wrong is purely that MacOS X limits how you do things on that node. Have a look at the OS X kernel source :-) The implementation of the support libraries to run NDRVs is all there (module IOGraphicsFamily iirc).
I found another way to access the options node in Mac OS X. Use this command: ioreg -c IODTNVRAM. It stops at the options node and prints this error message: "ioreg: error: can't obtain properties" in QEMU. On a real Power Mac the command prints all the properties of the options node just fine.
Correct, part of the problem is that I think we don't emulate the NVRAM in a format that OS X understands, a problem for another day.
I don't know about using binary. The way we do it now seems just fine.
ASCII parsing in a driver sucks.
I just need to figure out how to write to the /chosen node from the QEMU command line. I found a function called OpenBIOS_set_var() in openbios_firmware_abi.h, but it would require an address to write to. So where do I find the address of the /chosen node....
No, you don't. Do as I said. Have OpenBIOS construct the list of resolutions and put it in the node of the device itself.
Cheers, Ben.
On Sep 21, 2016, at 5:53 PM, Benjamin Herrenschmidt wrote:
On Wed, 2016-09-21 at 14:26 -0400, G 3 wrote:
Nodes like chose, aliases, openprom are of class IOService. options is of class IODTNVRAM. It looks like this class has problems. I'm thinking since Alexander Graf did work in the mac_nvram.c file, he might know what is wrong.
What is wrong is purely that MacOS X limits how you do things on that node. Have a look at the OS X kernel source :-) The implementation of the support libraries to run NDRVs is all there (module IOGraphicsFamily iirc).
I will check the IOGraphicsFamily kernel extension source code.
I found another way to access the options node in Mac OS X. Use this command: ioreg -c IODTNVRAM. It stops at the options node and prints this error message: "ioreg: error: can't obtain properties" in QEMU. On a real Power Mac the command prints all the properties of the options node just fine.
Correct, part of the problem is that I think we don't emulate the NVRAM in a format that OS X understands, a problem for another day.
If you know any more info please share. I would like to help fix this problem.
I don't know about using binary. The way we do it now seems just fine.
ASCII parsing in a driver sucks.
All the code needed parse ASCII is already in the patch. But I will try to see things your way.
I just need to figure out how to write to the /chosen node from the QEMU command line. I found a function called OpenBIOS_set_var() in openbios_firmware_abi.h, but it would require an address to write to. So where do I find the address of the /chosen node....
No, you don't. Do as I said. Have OpenBIOS construct the list of resolutions and put it in the node of the device itself.
That can be done, but I was hoping to be able to do this via a command-line switch. That would make things so much easier on the user. Altering properties in OpenBIOS can be challenging using forth. OpenBIOS does support using startup scripts so maybe someone could make a script that adds user resolutions to the QEMU,VGA node from the options node.
I'm hoping you had a look at version three of my patch. If there are any other issues with it, I would like to know before making version 4.
On Wed, 2016-09-21 at 19:18 -0400, G 3 wrote:
That can be done, but I was hoping to be able to do this via a command-line switch.
But you still do that !
Your switch puts stuff in /options which OpenBIOS then picks up to construct the final list that it puts in the driver node.
That would make things so much easier on the user. Altering properties in OpenBIOS can be challenging using forth. OpenBIOS does support using startup scripts so maybe someone could make a script that adds user resolutions to the QEMU,VGA node from the options node.
I'm hoping you had a look at version three of my patch. If there are any other issues with it, I would like to know before making version 4.
I'm really not fan of the whole ASCII parsing business. In any case, I'm a bit too busy right now, I'll try to get back onto this next week.
On 21/09/16 22:53, Benjamin Herrenschmidt wrote:
On Wed, 2016-09-21 at 14:26 -0400, G 3 wrote:
Nodes like chose, aliases, openprom are of class IOService. options is of class IODTNVRAM. It looks like this class has problems. I'm thinking since Alexander Graf did work in the mac_nvram.c file, he might know what is wrong.
What is wrong is purely that MacOS X limits how you do things on that node. Have a look at the OS X kernel source :-) The implementation of the support libraries to run NDRVs is all there (module IOGraphicsFamily iirc).
I found another way to access the options node in Mac OS X. Use this command: ioreg -c IODTNVRAM. It stops at the options node and prints this error message: "ioreg: error: can't obtain properties" in QEMU. On a real Power Mac the command prints all the properties of the options node just fine.
Correct, part of the problem is that I think we don't emulate the NVRAM in a format that OS X understands, a problem for another day.
I don't know about using binary. The way we do it now seems just fine.
ASCII parsing in a driver sucks.
I just need to figure out how to write to the /chosen node from the QEMU command line. I found a function called OpenBIOS_set_var() in openbios_firmware_abi.h, but it would require an address to write to. So where do I find the address of the /chosen node....
No, you don't. Do as I said. Have OpenBIOS construct the list of resolutions and put it in the node of the device itself.
Yeah. My take would be to add a "modes" property to the VGA device which is a set of encode-int triplets of (width, height, depth) respectively.
Even better, does QEMU provide any preset resolutions via EDID? I'd much rather get OpenBIOS's VGA to read those and put them in the "modes" device property, including adding in any custom resolution provided on the command line via -g wxhxd.
ATB,
Mark.
-
Alfonso Gamboa -
Benjamin Herrenschmidt -
G 3 -
Mark Cave-Ayland