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