Hi everyone,
This patch implements the missing push-package/pop-package words which seem to be included in various Fcode bootloaders (even though they are not part of the official spec). With this patch applied, I now get the following on my Solaris image/Qemu boot:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 24 2009 10:08 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 5936 bytes entry point is 0x4000 Evaluating FCode... Loading package 1.4 04 Aug 1995 13:02:54. open isn't unique. FCode UFS Reader 1.12 00/07/17 15:48:16. Loading: /platform//ufsboot claim virt = 1 size = 200 align = 0 Loading: /platform/sun4u/ufsboot Boot load failed. ok 0 >
So it looks as if we're now at the point where we need to start implementing the client interface claim/release functions.
ATB,
Mark.
On Sun, May 24, 2009 at 2:13 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Hi everyone,
This patch implements the missing push-package/pop-package words which seem to be included in various Fcode bootloaders (even though they are not part of the official spec). With this patch applied, I now get the following on my Solaris image/Qemu boot:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 24 2009 10:08 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 5936 bytes entry point is 0x4000 Evaluating FCode... Loading package 1.4 04 Aug 1995 13:02:54. open isn't unique. FCode UFS Reader 1.12 00/07/17 15:48:16. Loading: /platform//ufsboot claim virt = 1 size = 200 align = 0 Loading: /platform/sun4u/ufsboot Boot load failed. ok 0 >
So it looks as if we're now at the point where we need to start implementing the client interface claim/release functions.
Another point for implementing claim/release is the need to correctly work with PCI VGA frame buffer.
This shows up when I try to execute linux kernel in sparc64-softmmu. After kernel starts mapping pages using tlb the early low memory mappings set up by openbios code are started to go out from tlb entries. In short time after several lines are printed using prom console the openbios console driver fails because frame buffer pointer is not mapped anymore.
PPC arch seems to have it implemented using claim and map which use memory management in ofmem.c (at least two versions are there). Should the memory management (ofmem.c) be shared by all arches?
Igor Kovalenko wrote:
Another point for implementing claim/release is the need to correctly work with PCI VGA frame buffer.
This shows up when I try to execute linux kernel in sparc64-softmmu. After kernel starts mapping pages using tlb the early low memory mappings set up by openbios code are started to go out from tlb entries. In short time after several lines are printed using prom console the openbios console driver fails because frame buffer pointer is not mapped anymore.
PPC arch seems to have it implemented using claim and map which use memory management in ofmem.c (at least two versions are there). Should the memory management (ofmem.c) be shared by all arches?
I'd imagine that perhaps the claim/release functions could be shared, whereas the map/unmap functions would naturally have to be specific to each architecture. My C is reasonably good, although I don't know too much about SPARC64 (yet!) nor the C side of OpenBIOS. If yourself/Blue Swirl could come up with some code as a starting point, that would be really great :)
ATB,
Mark.
On 5/24/09, Igor Kovalenko igor.v.kovalenko@gmail.com wrote:
On Sun, May 24, 2009 at 2:13 PM, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Hi everyone,
This patch implements the missing push-package/pop-package words which seem to be included in various Fcode bootloaders (even though they are not part of the official spec). With this patch applied, I now get the following on my Solaris image/Qemu boot:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 24 2009 10:08 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 5936 bytes entry point is 0x4000 Evaluating FCode... Loading package 1.4 04 Aug 1995 13:02:54. open isn't unique. FCode UFS Reader 1.12 00/07/17 15:48:16. Loading: /platform//ufsboot claim virt = 1 size = 200 align = 0 Loading: /platform/sun4u/ufsboot Boot load failed. ok 0 >
So it looks as if we're now at the point where we need to start implementing the client interface claim/release functions.
Another point for implementing claim/release is the need to correctly work with PCI VGA frame buffer.
This shows up when I try to execute linux kernel in sparc64-softmmu. After kernel starts mapping pages using tlb the early low memory mappings set up by openbios code are started to go out from tlb entries. In short time after several lines are printed using prom console the openbios console driver fails because frame buffer pointer is not mapped anymore.
PPC arch seems to have it implemented using claim and map which use memory management in ofmem.c (at least two versions are there). Should the memory management (ofmem.c) be shared by all arches?
Yes, there is unfortunately a lot of duplicated code. For Sparc32 the romvec interface needs some consideration, but otherwise the best one should be used for all arches.
On 5/24/09, Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk wrote:
Hi everyone,
This patch implements the missing push-package/pop-package words which seem to be included in various Fcode bootloaders (even though they are not part of the official spec). With this patch applied, I now get the following on my Solaris image/Qemu boot:
OpenBIOS for Sparc64 Configuration device id QEMU version 1 machine id 0 CPUs: 1 x SUNW,UltraSPARC-II UUID: 00000000-0000-0000-0000-000000000000 Welcome to OpenBIOS v1.0 built on May 24 2009 10:08 Type 'help' for detailed information
[sparc64] Booting file 'disk' with parameters '' Not a bootable ELF image Not a Linux kernel image Not a bootable a.out image Loading FCode image... Loaded 5936 bytes entry point is 0x4000 Evaluating FCode... Loading package 1.4 04 Aug 1995 13:02:54. open isn't unique. FCode UFS Reader 1.12 00/07/17 15:48:16. Loading: /platform//ufsboot claim virt = 1 size = 200 align = 0 Loading: /platform/sun4u/ufsboot Boot load failed. ok 0 >
Thanks, applied.
So it looks as if we're now at the point where we need to start implementing the client interface claim/release functions.
It looks like arguments in the debug output are in wrong order.
Blue Swirl wrote:
So it looks as if we're now at the point where we need to start implementing the client interface claim/release functions.
It looks like arguments in the debug output are in wrong order.
I think this is okay. The bug AFAICT is that according the OF spec, if align == 0 then the virtaddr is not present and so the call should only pop 2 parameters from the stack rather than 3.
ATB,
Mark.
-
Blue Swirl -
Igor Kovalenko -
Mark Cave-Ayland