Patchwork mach-virt RAM start address

login
register
mail settings
Submitter Giridhar Maruthy
Date Oct. 5, 2013, 4:41 a.m.
Message ID <CAHuqX+H1ELmquVL5uKhFdQr3gveYvNJPmVUrgWMzzSbnXt6N1Q@mail.gmail.com>
Download mbox | patch
Permalink /patch/280756/
State New
Headers show

Comments

Giridhar Maruthy - Oct. 5, 2013, 4:41 a.m.
Hi,

I am using mach-virt in qemu which boots correctly when RAM start
address is 0x8000000. But if I change the address to anything like
0x9000000, the mach-virt machine just hangs, not even an error
message.

Do we have to mention the RAM start address anywhere else?

Thanks,
Giridhar
Peter Maydell - Oct. 5, 2013, 4:49 a.m.
On 5 October 2013 13:41, Giridhar Maruthy <giridhar.maruthy@linaro.org> wrote:
> I am using mach-virt in qemu which boots correctly when RAM start
> address is 0x8000000. But if I change the address to anything like
> 0x9000000, the mach-virt machine just hangs, not even an error
> message.

The kernel automatically figures out where in physical memory it should
decompress itself to (CONFIG_AUTO_ZRELADDR), but the mechanism
it uses to do this assumes that RAM starts at a 128MB boundary.
So we must keep the board's RAM start address at a 128MB boundary.
Why did you want to move VIRT_MEM up? There's plenty of space
below it still, I would have thought.

-- PMM
Giridhar Maruthy - Oct. 5, 2013, 5:20 a.m.
On 5 October 2013 10:19, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 5 October 2013 13:41, Giridhar Maruthy <giridhar.maruthy@linaro.org> wrote:
>> I am using mach-virt in qemu which boots correctly when RAM start
>> address is 0x8000000. But if I change the address to anything like
>> 0x9000000, the mach-virt machine just hangs, not even an error
>> message.
>
> The kernel automatically figures out where in physical memory it should
> decompress itself to (CONFIG_AUTO_ZRELADDR), but the mechanism
> it uses to do this assumes that RAM starts at a 128MB boundary.

ok. But changing the RAM start to 0x20000000 (2 followed by seven
zeros) still does not work even though is at 128MB boundary.

> So we must keep the board's RAM start address at a 128MB boundary.
> Why did you want to move VIRT_MEM up? There's plenty of space
> below it still, I would have thought.
The purpose is that I wanted to use mach-virt as a base to test other
machines' properties like different RAM base and size, peripherals at
different locations, etc.

Thanks,
Giridhar
Peter Maydell - Oct. 5, 2013, 5:22 a.m.
On 5 October 2013 14:20, Giridhar Maruthy <giridhar.maruthy@linaro.org> wrote:
> On 5 October 2013 10:19, Peter Maydell <peter.maydell@linaro.org> wrote:
>> On 5 October 2013 13:41, Giridhar Maruthy <giridhar.maruthy@linaro.org> wrote:
>>> I am using mach-virt in qemu which boots correctly when RAM start
>>> address is 0x8000000. But if I change the address to anything like
>>> 0x9000000, the mach-virt machine just hangs, not even an error
>>> message.
>>
>> The kernel automatically figures out where in physical memory it should
>> decompress itself to (CONFIG_AUTO_ZRELADDR), but the mechanism
>> it uses to do this assumes that RAM starts at a 128MB boundary.
>
> ok. But changing the RAM start to 0x20000000 (2 followed by seven
> zeros) still does not work even though is at 128MB boundary.

Well, in theory that should work. You'll need to debug why the kernel
isn't booting, then (try using a gdb connected to qemu's gdb stub);
I'm afraid that's a pretty painful process.

-- PMM

Patch

diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 448a0e5..d3797c8 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -101,7 +101,7 @@  static const MemMapEntry a15memmap[] = {
     [VIRT_UART] = { 0x1008000, 0x1000 },
     [VIRT_MMIO] = { 0x2000000, 0x200 },
     /* ...repeating for a total of NUM_VIRTIO_TRANSPORTS, each of that size */
-    [VIRT_MEM] = { 0x8000000, 30ULL * 1024 * 1024 * 1024 },
+    [VIRT_MEM] = { 0x9000000, 30ULL * 1024 * 1024 * 1024 },
 };