[PATCH] Compilation PowerPC64

[PATCH] Compilation PowerPC64

[Manoel]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

This patch corrects compilation in PowerPC64 due to some recent changes.
-- 
Best Regards,

Manoel Abranches <mrabran@linux.vnet.ibm.com>
IBM Linux Technology Center Brazil

[-- Attachment #2: compilation_powerpc64.patch --]
[-- Type: text/x-patch, Size: 1866 bytes --]

Index: conf/powerpc-ieee1275.rmk
===================================================================
--- conf/powerpc-ieee1275.rmk	(revision 1928)
+++ conf/powerpc-ieee1275.rmk	(working copy)
@@ -79,7 +79,7 @@
 	kern/ieee1275/init.c term/ieee1275/ofconsole.c 		\
 	kern/ieee1275/openfw.c disk/ieee1275/ofdisk.c 		\
 	kern/parser.c kern/partition.c kern/env.c kern/powerpc/dl.c 	\
-	kern/generic/millisleep.c kern/time.c                            \
+	kern/generic/millisleep.c kern/time.c   kern/ieee1275/mmap.c     \
 	symlist.c kern/powerpc/cache.S
 kernel_elf_HEADERS = grub/powerpc/ieee1275/ieee1275.h
 kernel_elf_CFLAGS = $(COMMON_CFLAGS)
Index: include/grub/powerpc/ieee1275/memory.h
===================================================================
--- include/grub/powerpc/ieee1275/memory.h	(revision 0)
+++ include/grub/powerpc/ieee1275/memory.h	(revision 0)
@@ -0,0 +1,25 @@
+/* memory.h - describe the memory map */
+/*
+ *  GRUB  --  GRand Unified Bootloader
+ *  Copyright (C) 2002,2007  Free Software Foundation, Inc.
+ *
+ *  GRUB is free software: you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, either version 3 of the License, or
+ *  (at your option) any later version.
+ *
+ *  GRUB is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with GRUB.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef _GRUB_MEMORY_MACHINE_LB_HEADER
+#define _GRUB_MEMORY_MACHINE_LB_HEADER      1
+
+#define GRUB_MACHINE_MEMORY_AVAILABLE		1
+
+#endif /* ! _GRUB_MEMORY_MACHINE_HEADER */

Re: [PATCH] Compilation PowerPC64

[Pavel Roskin]

On Mon, 2008-11-24 at 17:58 -0200, Manoel wrote:
> This patch corrects compilation in PowerPC64 due to some recent changes.

The compilation problems exist even when compiling for 32-bit PowerPC.
However, I'm getting errors in qemu with your patch:


stack: 5bfff80 malloc_base: 0 0x05800000 0x06000000
ERROR: OF_property_copy cannot get property 'CodeGen-copyright' for
openprom
ERROR: OF_property_copy cannot get property 'architecture' for
device-tree
Warning: attempt to claim over our own code!
Welcome to GRUB!

out of memory
Aborted. Press any key to exit


It used to work without "out of memory" before.  I think the breakage is
bigger than just in compilation.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Compilation PowerPC64

[peter cros]

 Also here on powerpc64 G5, after the recent change from
grub_available_iterate() to grub_machine_mmap_iterate().
...
kernel_elf-kern_ieee1275_init.o: In function `grub_claim_heap':
/home/pxw/src/grub2/build/../kern/ieee1275/init.c:182: undefined
reference to `grub_machine_mmap_iterate'
kernel_elf-symlist.o:(.data+0x38c): undefined reference to
`grub_machine_mmap_iterate'
collect2: ld returned 1 exit status
make: *** [kernel.elf] Error 1

There is a separate startup memory bug for G5 powerpc64 with
grub_available_iterate()/grub_machine_mmap_iterate() '#address-cells'
incorrect interpretation for Apple G5, causing grub_claim_heap to fail
and the [Welcome to Grub! out of memory], I want to recheck this and
explain if still present.

Peter Cros.

Re: [PATCH] Compilation PowerPC64

[Manoel Rebelo Abranches]

My patch only corrects the compilation error introduced by revision
1924. I have tested it in both P5 and P6 machines and all worked right.

On Mon, 2008-11-24 at 16:30 -0500, Pavel Roskin wrote:
> On Mon, 2008-11-24 at 17:58 -0200, Manoel wrote:
> > This patch corrects compilation in PowerPC64 due to some recent changes.
> 
> The compilation problems exist even when compiling for 32-bit PowerPC.
> However, I'm getting errors in qemu with your patch:
> 
> 
> stack: 5bfff80 malloc_base: 0 0x05800000 0x06000000
> ERROR: OF_property_copy cannot get property 'CodeGen-copyright' for
> openprom
> ERROR: OF_property_copy cannot get property 'architecture' for
> device-tree
> Warning: attempt to claim over our own code!
> Welcome to GRUB!
> 
> out of memory
> Aborted. Press any key to exit
> 
> 
> It used to work without "out of memory" before.  I think the breakage is
> bigger than just in compilation.
> 
-- 
Best Regards,

Manoel Abranches <mrabran@linux.vnet.ibm.com>
IBM Linux Technology Center Brazil

Re: [PATCH] Compilation PowerPC64

[Robert Millan]

On Mon, Nov 24, 2008 at 04:30:45PM -0500, Pavel Roskin wrote:
> On Mon, 2008-11-24 at 17:58 -0200, Manoel wrote:
> > This patch corrects compilation in PowerPC64 due to some recent changes.
> 
> The compilation problems exist even when compiling for 32-bit PowerPC.
> However, I'm getting errors in qemu with your patch:
> 
> 
> stack: 5bfff80 malloc_base: 0 0x05800000 0x06000000
> ERROR: OF_property_copy cannot get property 'CodeGen-copyright' for
> openprom
> ERROR: OF_property_copy cannot get property 'architecture' for
> device-tree
> Warning: attempt to claim over our own code!
> Welcome to GRUB!
> 
> out of memory
> Aborted. Press any key to exit

Not sure if that's related, but I suggest you try a pre-r1924 snapshot and
see if that works.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] Compilation PowerPC64

[Robert Millan]

On Mon, Nov 24, 2008 at 05:58:23PM -0200, Manoel wrote:
> This patch corrects compilation in PowerPC64 due to some recent changes.

Thanks.  Committed with some adjustments.

Btw, please include a ChangeLog entry next time!

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [PATCH] Compilation PowerPC64

[Pavel Roskin]

On Fri, 2008-11-28 at 20:40 +0100, Robert Millan wrote:
> On Mon, Nov 24, 2008 at 04:30:45PM -0500, Pavel Roskin wrote:
> > On Mon, 2008-11-24 at 17:58 -0200, Manoel wrote:
> > > This patch corrects compilation in PowerPC64 due to some recent changes.
> > 
> > The compilation problems exist even when compiling for 32-bit PowerPC.
> > However, I'm getting errors in qemu with your patch:
> > 
> > 
> > stack: 5bfff80 malloc_base: 0 0x05800000 0x06000000
> > ERROR: OF_property_copy cannot get property 'CodeGen-copyright' for
> > openprom
> > ERROR: OF_property_copy cannot get property 'architecture' for
> > device-tree
> > Warning: attempt to claim over our own code!
> > Welcome to GRUB!
> > 
> > out of memory
> > Aborted. Press any key to exit
> 
> Not sure if that's related, but I suggest you try a pre-r1924 snapshot and
> see if that works.

r1923 has no "out of memory" problem.  r1924 doesn't compile.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Compilation PowerPC64

[Pavel Roskin]

On Wed, 2008-12-03 at 11:20 -0500, Pavel Roskin wrote:

> r1923 has no "out of memory" problem.  r1924 doesn't compile.

I think I understand something now.  "out of memory" is caused by
heap_init() inside grub_claim_heap() failing due to memory overlap (by
the way, I hate functions inside functions).

In r1923:

_start=0x10000
_end=0x23640
addr=0x200000
(addr + len)=0x3fffff

In r1933:

_start=0x200000
_end=0x213658
addr=0x200000
(addr + len)=0x3fffff

Thus, we have an overlap.  This is caused by r1928.  Changing the link
address in conf/powerpc-ieee1275.rmk from 0x200000 to 0x100000 makes
_start equal 0x100000 and resolves the "out of memory" problem.

The "addr" variable comes from HEAP_MIN_SIZE, and it's also 0x200000.

I'm testing PowerPC code in qemu, which doesn't provide the memory
information, so the problem may not exist on real machines.

If linking at 0x200000 is important, we could allocate heap after _end.

-- 
Regards,
Pavel Roskin

Re: [PATCH] Compilation PowerPC64

[Manoel Rebelo Abranches]

Hi Pavel. The patch which changes the link address from 0x10000 to
0x200000 was sent by me.
there was a overlapping of the load-base used in CHRP/PAPR machines
0x4000 and the link address of the ELF segments. The address used is the
same that Yaboot uses but theoretically any address that don't causes
overlap should work (provide that it also doesn't overlap real-base and
that there is space to load the kernel).

On Wed, 2008-12-03 at 12:29 -0500, Pavel Roskin wrote:
> On Wed, 2008-12-03 at 11:20 -0500, Pavel Roskin wrote:
> 
> > r1923 has no "out of memory" problem.  r1924 doesn't compile.
> 
> I think I understand something now.  "out of memory" is caused by
> heap_init() inside grub_claim_heap() failing due to memory overlap (by
> the way, I hate functions inside functions).
> 
> In r1923:
> 
> _start=0x10000
> _end=0x23640
> addr=0x200000
> (addr + len)=0x3fffff
> 
> In r1933:
> 
> _start=0x200000
> _end=0x213658
> addr=0x200000
> (addr + len)=0x3fffff
> 
> Thus, we have an overlap.  This is caused by r1928.  Changing the link
> address in conf/powerpc-ieee1275.rmk from 0x200000 to 0x100000 makes
> _start equal 0x100000 and resolves the "out of memory" problem.
> 
> The "addr" variable comes from HEAP_MIN_SIZE, and it's also 0x200000.
> 
> I'm testing PowerPC code in qemu, which doesn't provide the memory
> information, so the problem may not exist on real machines.
> 
> If linking at 0x200000 is important, we could allocate heap after _end.
> 
-- 
Best Regards,

Manoel Abranches <mrabran@linux.vnet.ibm.com>
IBM Linux Technology Center Brazil

Re: [PATCH] Compilation PowerPC64

[Pavel Roskin]

Quoting Manoel Rebelo Abranches <mrabran@linux.vnet.ibm.com>:

> Hi Pavel. The patch which changes the link address from 0x10000 to
> 0x200000 was sent by me.
> there was a overlapping of the load-base used in CHRP/PAPR machines
> 0x4000 and the link address of the ELF segments. The address used is the
> same that Yaboot uses but theoretically any address that don't causes
> overlap should work (provide that it also doesn't overlap real-base and
> that there is space to load the kernel).

I don't have any strong preference, but I think it would be better to  
fix the workaround for dumb firmware rather than tweak the link  
address once again.

-- 
Regards,
Pavel Roskin