PATCH: Implement push-package/pop-package

[Mark Cave-Ayland]

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.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

[Igor Kovalenko]

On Sun, May 24, 2009 at 2:13 PM, Mark Cave-Ayland
<mark.cave-ayland(a)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?

-- 
Kind regards,
Igor V. Kovalenko

[Mark Cave-Ayland]

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.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]

[Blue Swirl]

On 5/24/09, Igor Kovalenko <igor.v.kovalenko(a)gmail.com> wrote:
  On Sun, May 24, 2009 at 2:13 PM, Mark Cave-Ayland
  <mark.cave-ayland(a)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.

[Blue Swirl]

On 5/24/09, Mark Cave-Ayland <mark.cave-ayland(a)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.

[Mark Cave-Ayland]

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.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: [phone]