On Jan 9, 2007, at 11:24 AM, Hollis Blanchard wrote:

On Mon, 2007-01-08 at 18:38 -0500, Jimi Xenidis wrote:
Removing our custom allocator is important to simplify the upcoming
  multiboot2 conversion.


We have currently have three page allocators. The first is PPC- specific,
and it includes the Xen image, RTAS, and our copy of the Open Firmware
device tree.

More precisely, it is OF-specific and exists because we cannot trust the "claim" OF-method, so really it is more of a workaround. This is analogous to the custom allocator in prom.c in Linux. The ultimate use of boot_of.c is to get the minimum information necessary need from OF, put everything in a canonical form and then go to common code. So if we are ever booted without OF, we would run some other boot_XXX.c and then go to common code.

It's also limited to 32 MB, and that makes some of the code
rather hackful (particularly boot_of_alloc_init() and

Not hacky at all it is a practical limit for OF that we empirically know is sufficient.

Then we need to populate the common boot allocator. Right now this is
being done with ad-hoc communication between boot_of.c and memory.c via
a variety of global variables. We make lots of assumptions about the
location of those reserved areas. Since those areas can be placed
arbitrarily (like by a multiboot loader, for example), those assumptions
need to go. So instead we should use the PPC allocator bitmap to
populate the common allocator bitmap, and avoid all these globals.

I agree, but formalizing the canonical form and having minimal "translators" to get us to that point is the correct way to go. I believe that right now we are using multiboot2 as our canonical form.
Once that is designed we can happily leave the globals behind.

Except we can't just copy it, because the second bitmap itself is not
present in the first bitmap. We also need to invent an interface to
access the early bitmap, or make it global, and don't you think we
already have too many globals in this area?


So now the copy needs to
look something like this:

        i = 0;
        while (1) {
                // here's the accessor we've invented:
                i = boot_of_get_next_available(i, &base, &len);
                if (i == -1)
                if (base, len) overlaps with (bitmap_addr, bitmap_len)
                        mangle (base, len) somehow
                init_boot_pages(base, len);

If you take a step back, you might ask yourself why we have a bitmap
that's just being copied into another bitmap, when we could have used
the second bitmap all along? So that's what this patch does. In fact,
despite being more flexible than the current code (e.g. it does not
require the init_boot_allocator() to be below _start), this patch
removes more code than it adds.

the bitmap need not exist beyond boot_of.c but we do need an ordered way to describe memory that is occupied once OF is terminated and we enter common code.

I am beginning to think that multiboot2 is insufficient and is simply yet another temporary boot-time form that should not be accessed from common boot code and whose information could be expressed in a flatened-devtree or the current OFD that is used by common code beyond setup.c.

- This will also be needed to support non-Open Firmware systems
(though the
  firmware-specific interface was not the focus of this patch).

But what is there is designed with non-OF in mind.
IMHO this is a step backwards.

"rtas_base" has no place in a firmware-agnostic memory.c,
I would argue that neither does bultiboot2.

so I think
you'd agree there are at least some rough edges remaining?

Oh I do indeed! :) Just looking for improvement rather then another shuffle which we all seem to do quite a bit.

I'll think about how to adapt this code to take into account firmware
that passes a flattened tree. In this patch, most of the new code would need to be duplicated to call "ofd_" routines instead of "of_" routines
(a very poorly-named distinction IMHO).

I know your sentiments well. "of_" prefixes for OpenFirmware calls and "ofd_" OpenFirmwareDevtree calls. AFAICT it is a definate improvement over the prefixes in Linux.


Xen-ppc-devel mailing list

Reply via email to