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

Re: [Xen-devel] Question on hvc console init



On 10/29/2014 08:22 AM, Ian Campbell wrote:
> On Tue, 2014-10-28 at 17:32 +0000, Julien Grall wrote:
>> Hi Konrad,
>>
>> On 10/28/2014 04:53 PM, Konrad Rzeszutek Wilk wrote:
>>> On Tue, Oct 28, 2014 at 05:53:25PM +0200, Iurii Konovalenko wrote:
>>>> Hello, all!
>>>>
>>>> I try to bring up Xen on Renesas Lager board (r8a7790 SoC - R-Car H2).
>>>> Xen revision is 4.4.
>>>> I try to run Linux (kernel 3.14 + LTSI patches) as Dom0.
>>>> In kernel I've found strange behaviour in hvc console init function.
>>>> In file drivers/tty/hvc/hvc_xen.c in function xen_cons_init(void) sources 
>>>> are:
>>>>
>>>>     if (!xen_domain())
>>>>         return 0;
>>>>
>>>>     if (xen_initial_domain())
>>>>         ops = &dom0_hvc_ops;
>>>>     else {
>>>>
>>>> xen_domain() and xen_initial_domain() are defined to check
>>>> xen_domain_type variable. This variable is defined and initialized to
>>>> XEN_NATIVE in arch/arm/xen/enlighten.c. The real value of this
>>>> variable is set in same file function xen_guest_init(), that is
>>>> early_initcall. But eraly_initcall is called later, than
>>>> console_initcall, that's why in time of running xen_cons_init(void)
>>>> xen_domain_type is not initialized to correct value and
>>>> xen_cons_init() does not initialize console, as returns on first check
>>>> "if (!xen_domain())".
>>>> It is not critical in normal operation, because we have
>>>> device_initcall xen_hvc_init() that is called after xen_guest_init(),
>>>> it initialize hvc. But in case of kernel falls before
>>>> device_initcall's, we can't see any printouts, that could be useful.
>>>>
>>>> Could you please explain, may be using some configs or arguments in
>>>> command line for kernel, how to enable this early console?
>>>
>>>
>>> It is explained in the kernel-parameters.txt 
>>> (https://www.kernel.org/doc/Documentation/kernel-parameters.txt)
>>> :
>>>
>>> earlyprintk=        [X86,SH,BLACKFIN,ARM,M68k]
>>>                     earlyprintk=vga
>>>                     earlyprintk=efi
>>>                     earlyprintk=xen
>>> ...
>>
>> AFAIK, earlyprintk=xen has never work on ARM. This is because we don't
>> know that we running on Xen until late.
> 
> earlyprintk on arm doesn't parse it's argument at all, it is a boolean
> option which just enables printk via the hardcoded (via .config) debug
> UART. Because of that it's incompatible with multiplatform kernels as
> well.

For now the good way to debug is enabling the earlyprintk for your
platform (Xen is emulating a simple UART for the one it "steal") or
patching Linux with the patch I sent few mails earlier.

> Some platforms (e.g. arm64) have replace earlyprintk with a more
> flexible earlycon, I don't know if arm is one of those (yet?). It would
> probably be nice to integrate the xen early print stuff with earlycon at
> some point.

It seems that earlycon exists also for ARM. I will give a look next week.

Regards,

-- 
Julien Grall

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


 


Rackspace

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