[OpenBIOS] PATCH: Implement push-package/pop-package

[Blue Swirl]

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