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

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



On 06/11/2014 05:12 PM, Jeenu Viswambharan wrote:
> On Wed, Jun 11, 2014 at 16:10:46, Ian Campbell wrote:
>> On Wed, 2014-06-11 at 16:02 +0100, Jeenu Viswambharan wrote:
>>>>> Xen is now launching DOM0. But next issue I'm now facing is that
>>>>> Linux refusing to run when loaded at 0xa0008000 - it panics and
>>>>> complains about failing to allocate memory in
>>>>> mm/memblock.c:memblock_alloc_base().  FWIW, I've built the
>>>>> kernel v3.14 with vexpress_defconfig and enabled Xen and highmem
>>>>> support.  The kernel however is happy to boot when loaded at
>>>>> 0x80008000 (without Xen). The same with Xen though, the kernel
>>>>> reports 'uncompression error'.
>>>>>
>>>>> It's little to do with Xen, but are there any other options
>>>>> required to be enabled in the DOM0 Kernel to run from
>>>>> 0xa0008000?
>>>>
>>>> Your kernel needs to be relocatable. I'm not 100% which option
>>>> that is (perhaps CONFIG_ARM_PATCH_PHYS_VIRT) but if you build a
>>>> multiplatform kernel (CONFIG_ARCH_MULTIPLATFORM) it certainly will
>>>> be.
>>>
>>> Just found out that both of the configs are enabled in my build, and
>>> I've no idea what's going on.
>>>
>>> Like I said, when loaded at 0xa0008000, the kernel didn't boot
>>> neither on bare metal nor Xen. But at 0x80008000, the kernel was
>>> happy to boot bare metal but not with Xen. Does Xen care where the
>>> kernel is, as long as the kernel is happy to execute from wherever
>>> it's loaded?
>>
>> The kernel wants to be loaded within 128M of the start of RAM. Does
>> 0xa0008000 meet that? What is loading the kernel there -- I don't
>> think Xen will (it knows about the 128MB thing). How much RAM does
>> your vexpress have? Is 0xa0008000 even in RAM on a vexpress? I thought
>> it had up to 1GB at 0x60000000-0xa0000000.
> 
> 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?

> 
>   (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.

diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
index 2dc2831..931c72a 100644
--- a/drivers/tty/hvc/hvc_xen.c
+++ b/drivers/tty/hvc/hvc_xen.c
@@ -630,7 +630,6 @@ void xen_raw_console_write(const char *str)
        ssize_t len = strlen(str);
        int rc = 0;

-       if (xen_domain()) {
                rc = dom0_write_console(0, str, len);
 #ifdef CONFIG_X86
                if (rc == -ENOSYS && xen_hvm_domain())
@@ -642,7 +641,6 @@ outb_print:
                for (i = 0; i < len; i++)
                        outb(str[i], 0xe9);
 #endif
-       }
 }

 void xen_raw_printk(const char *fmt, ...)
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index a45b509..907922b 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -45,6 +45,7 @@
 #include <linux/poll.h>
 #include <linux/irq_work.h>
 #include <linux/utsname.h>
+#include <xen/hvc-console.h>

 #include <asm/uaccess.h>

@@ -1571,6 +1572,8 @@ asmlinkage int vprintk_emit(int facility, int level,
                }
        }

+       xen_raw_console_write(text);
+
        if (level == -1)
                level = default_message_loglevel;

Regards,

-- 
Julien Grall

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

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