[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] ARM: Xen on Vexpress

On 06/11/2014 05:42 PM, Jeenu Viswambharan wrote:
> On Wed, Jun 11, 2014 at 17:21:22, Julien Grall wrote:
>> On 06/11/2014 05:12 PM, Jeenu Viswambharan wrote:
>>> The TC2 has 1GB RAM from 0x80000000 to 0xc0000000. The instructions
>>> on the Wiki tells u-boot to load it at 0xa0008000 and modifies the
>>> DTB accordingly.
>> The 0xa0008000 in the u-boot runes is not the address where the kernel
>> will be loaded in DOM0. You should see this address in Xen log smth
>> like "Loading zImage at...".
>> Also, why did you had to modify the DTB? Are you talking about the A7s
>> cpus?
> Oh, I meant to say the u-boot script inserts some stuff to the FDT using
> u-boot commands.
> Also, yes, I had to remove the A7 CPUs from the FDT.
>>>   (XEN) DOM0: Uncompressing Linux... done, booting the kernel.
>>> at the console. The rest is in the log buffer which I can view through
>>> the debugger. I've attached the best I could muster.
>> It's a bit hard to read. Can you apply the below patch to your Linux
>> tree? It will print everything to the Xen console log before the HVC
>> console has been initialised.
>> [...]
> Thanks. I've the logs now, but nothing different from the memory dump.
> Attached.

Just easier to read :).

> Ignoring RAM at a8000000-afffffff (!CONFIG_HIGHMEM).

I think you have to look why this error is printed. Linux is considering
the memory as high mem when the base address of the range is greater
than __pa(vmalloc_min - 1) + 1.

IIRC vmalloc_min is determined following the VMSPLIT. It seems
vexpress_defconfig is using VMSPLIT_2G, could you give a try on
VMSPLIT_3G? The latter option will set vmalloc_min higher than the first

If it works, then there is another issue in the physical offset. I
remembered, back to 3.11, Linux was unable to handle correctly pa - virt
delta positive. I hope it didn't get back.


Julien Grall

Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.