Physical address and size were both using two cells instead of one, and their order was wrong. This would happen to work for RAM < 4 GB, since the clear high address bits would happen to match the zero-based memory location. It would indicate a second bank of size zero though.
Switch the value order and use encode-phys in preparation for ppc64.
This tidies the output of the Haiku boot loader.
Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de --- arch/ppc/qemu/init.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index bfd147a..c5da992 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -730,15 +730,9 @@ arch_of_init( void )
/* all memory */
- PUSH(ram_size >> 32); - fword("encode-int"); - PUSH(ram_size & 0xffffffff); - fword("encode-int"); - fword("encode+"); - PUSH(0); - fword("encode-int"); - fword("encode+"); PUSH(0); + fword("encode-phys"); + PUSH(ram_size & 0xffffffff); fword("encode-int"); fword("encode+"); push_str("reg");
On 05.11.2010, at 21:46, Andreas Färber wrote:
Physical address and size were both using two cells instead of one, and their order was wrong. This would happen to work for RAM < 4 GB, since the clear high address bits would happen to match the zero-based memory location. It would indicate a second bank of size zero though.
Switch the value order and use encode-phys in preparation for ppc64.
This tidies the output of the Haiku boot loader.
Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de
arch/ppc/qemu/init.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index bfd147a..c5da992 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -730,15 +730,9 @@ arch_of_init( void )
/* all memory */
- PUSH(ram_size >> 32);
- fword("encode-int");
- PUSH(ram_size & 0xffffffff);
- fword("encode-int");
- fword("encode+");
- PUSH(0);
- fword("encode-int");
- fword("encode+"); PUSH(0);
- fword("encode-phys");
- PUSH(ram_size & 0xffffffff);
Doesn't this limit RAM to 4GB?
Alex
Am 07.11.2010 um 01:30 schrieb Alexander Graf:
On 05.11.2010, at 21:46, Andreas Färber wrote:
Physical address and size were both using two cells instead of one, and their order was wrong. This would happen to work for RAM < 4 GB, since the clear high address bits would happen to match the zero- based memory location. It would indicate a second bank of size zero though.
Switch the value order and use encode-phys in preparation for ppc64.
This tidies the output of the Haiku boot loader.
Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de
arch/ppc/qemu/init.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index bfd147a..c5da992 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -730,15 +730,9 @@ arch_of_init( void )
/* all memory */
- PUSH(ram_size >> 32);
- fword("encode-int");
- PUSH(ram_size & 0xffffffff);
- fword("encode-int");
- fword("encode+");
- PUSH(0);
- fword("encode-int");
- fword("encode+"); PUSH(0);
- fword("encode-phys");
- PUSH(ram_size & 0xffffffff);
Doesn't this limit RAM to 4GB?
It does limit location and size of RAM to 4 GB, which is correct for ppc. For ppc64 we need to bump #address-cells to 2 first, which is something I'd like to postpone until ppc64 boot gets somewhere. The current state is definitely wrong either way.
We currently don't handle RAM > 2 GB correctly anyway. It would overlap ISA, PCI, fw_cfg etc. That may need adjustments in QEMU, too, haven't checked.
Andreas
On 06.11.2010, at 21:02, Andreas Färber wrote:
Am 07.11.2010 um 01:30 schrieb Alexander Graf:
On 05.11.2010, at 21:46, Andreas Färber wrote:
Physical address and size were both using two cells instead of one, and their order was wrong. This would happen to work for RAM < 4 GB, since the clear high address bits would happen to match the zero-based memory location. It would indicate a second bank of size zero though.
Switch the value order and use encode-phys in preparation for ppc64.
This tidies the output of the Haiku boot loader.
Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de
arch/ppc/qemu/init.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index bfd147a..c5da992 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -730,15 +730,9 @@ arch_of_init( void )
/* all memory */
- PUSH(ram_size >> 32);
- fword("encode-int");
- PUSH(ram_size & 0xffffffff);
- fword("encode-int");
- fword("encode+");
- PUSH(0);
- fword("encode-int");
- fword("encode+"); PUSH(0);
- fword("encode-phys");
- PUSH(ram_size & 0xffffffff);
Doesn't this limit RAM to 4GB?
It does limit location and size of RAM to 4 GB, which is correct for ppc. For ppc64 we need to bump #address-cells to 2 first, which is something I'd like to postpone until ppc64 boot gets somewhere. The current state is definitely wrong either way.
We currently don't handle RAM > 2 GB correctly anyway. It would overlap ISA, PCI, fw_cfg etc. That may need adjustments in QEMU, too, haven't checked.
*shrug* Please put a comment there then. If things (read: Linux) still work fine for you in a VM, I have no objections to the patch :)
Alex
Am 07.11.2010 um 02:10 schrieb Alexander Graf:
On 06.11.2010, at 21:02, Andreas Färber wrote:
Am 07.11.2010 um 01:30 schrieb Alexander Graf:
On 05.11.2010, at 21:46, Andreas Färber wrote:
Physical address and size were both using two cells instead of one, and their order was wrong. This would happen to work for RAM < 4 GB, since the clear high address bits would happen to match the zero- based memory location. It would indicate a second bank of size zero though.
Switch the value order and use encode-phys in preparation for ppc64.
This tidies the output of the Haiku boot loader.
Cc: Alexander Graf agraf@suse.de Signed-off-by: Andreas Färber andreas.faerber@web.de
arch/ppc/qemu/init.c | 10 ++-------- 1 files changed, 2 insertions(+), 8 deletions(-)
diff --git a/arch/ppc/qemu/init.c b/arch/ppc/qemu/init.c index bfd147a..c5da992 100644 --- a/arch/ppc/qemu/init.c +++ b/arch/ppc/qemu/init.c @@ -730,15 +730,9 @@ arch_of_init( void )
/* all memory */
- PUSH(ram_size >> 32);
- fword("encode-int");
- PUSH(ram_size & 0xffffffff);
- fword("encode-int");
- fword("encode+");
- PUSH(0);
- fword("encode-int");
- fword("encode+"); PUSH(0);
- fword("encode-phys");
- PUSH(ram_size & 0xffffffff);
Doesn't this limit RAM to 4GB?
It does limit location and size of RAM to 4 GB, which is correct for ppc. For ppc64 we need to bump #address-cells to 2 first, which is something I'd like to postpone until ppc64 boot gets somewhere. The current state is definitely wrong either way.
We currently don't handle RAM > 2 GB correctly anyway. It would overlap ISA, PCI, fw_cfg etc. That may need adjustments in QEMU, too, haven't checked.
*shrug* Please put a comment there then. If things (read: Linux) still work fine for you in a VM, I have no objections to the patch :)
Done, thanks, applied in r947. Debian still boots.
Andreas
-
Alexander Graf -
Andreas Färber