[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |