On Tue, Jun 14, 2016 at 2:49 AM, Alistair Francis <alistair.fran...@xilinx.com> wrote: > On Fri, Jun 10, 2016 at 10:53 AM, Alistair Francis > <alistair.fran...@xilinx.com> wrote: >> On Fri, Jun 10, 2016 at 4:02 AM, Nathan Rossi <nat...@nathanrossi.com> wrote: >>> On Wed, Jun 8, 2016 at 10:59 AM, Alistair Francis >>> <alistair.fran...@xilinx.com> wrote: >>>> Update the QEMU Cadence UART reset values to enable a direct Linux boot >>>> without u-boot. >>> >>> Hi Alistair, >>> >>> Could you expand a bit on this, I don't see any issues where direct >>> booting is broken with the cadence uart for zynq or zynqmp. I did >>> notice however that the earlycon for the cadence uart driver (in the >>> kernel) does not set txen, which is possibly the cause for the delayed >>> console output. >> >> Hey Nathan, >> >> At the moment on the Krogoth branch I don't see any console output >> when booting the ZCU102 machine if I don't have this patch.
Ah ok, i understand the issue you are referring to, this issue appears whenever the kernel panics/hangs before the serial devices are initialized fully. Since this patch is a feature, I don't see a need to apply this to the krogoth branch. But I would like to see this fixed for master if possible. However i'm not sure if applying a workaround to QEMU (I would like to avoid maintaining a non-upstream patch in meta-xilinx for it) is the best solution to resolve this. I think this might best be solved by improving the support for cadence uart earlycon in the kernel. Whilst from a QEMU use stance the earlycon driver merely needs to setup the TXEN bit, it looks as though it might be possible to solve the JTAG boot earlycon side as well by adding a clock rate param to the earlycon arg so that the driver can do a simple baud calc and setup the uart with a static clock. Have you considered? if not what is your opinion of solving the the issue this way? > > Hey Nathan, > > On Krogoth branch with this patch for the ZCU102 this is what I see: Just to note that using the linux-xlnx kernel with the "xilinx_zynqmp_defconfig" config has issues booting on QEMU which is why I asked Manju to make the use of that defconfig specific for the zcu102 only. See this post: https://lists.yoctoproject.org/pipermail/meta-xilinx/2016-May/001691.html. You are missing the rest of the log after the bootconsole is disabled (VT_CONSOLE is enabled on that kernel also, which causes it to switch to tty0). Add "keep_bootcon" or "console=ttyPS0 earlycon" to see the full log, or use QEMU monitor to dump the logbuf (http://www.wiki.xilinx.com/QEMU-Linux+Kernel+logbuf+Extraction). Regards, Nathan > > alistai@xsjalistai50:/work/alistai/poky/build (detached*)$ > ./tmp/sysroots/x86_64-linux/usr/bin/qemu-system-aarch64 -M > xlnx-ep108 -nographic -kernel > ./tmp/deploy/images/zcu102-zynqmp/Image -initrd > ./tmp/deploy/images/zcu102-zynqmp/core-image-minimal-zcu102-zynqmp.cpio > -dtb ./tmp/deploy/images/zcu102-zynqmp/Image-zynqmp-zcu102-revB.dtb > [ 0.000000] Booting Linux on physical CPU 0x0 > [ 0.000000] Linux version 4.4.0-xilinx (alistai@xsjalistai50) (gcc > version 5.3.0 (GCC) ) #1 SMP PREEMPT Mon Jun 6 18:44:26 PDT 2016 > [ 0.000000] Boot CPU: AArch64 Processor [410fd034] > [ 0.000000] bootconsole [uart0] enabled > [ 0.000000] cma: Failed to reserve 128 MiB > [ 0.000000] psci: probing for conduit method from DT. > [ 0.000000] psci: PSCIv0.2 detected in firmware. > [ 0.000000] psci: Using standard PSCI v0.2 function IDs > [ 0.000000] psci: Trusted OS migration not required > [ 0.000000] PERCPU: Embedded 16 pages/cpu @ffffffc007f92000 s24728 > r8192 d32616 u65536 > [ 0.000000] Detected VIPT I-cache on CPU0 > [ 0.000000] CPU features: enabling workaround for ARM erratum 845719 > [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. > Total pages: 32320 > [ 0.000000] Kernel command line: earlycon > [ 0.000000] PID hash table entries: 512 (order: 0, 4096 bytes) > [ 0.000000] Dentry cache hash table entries: 16384 (order: 5, 131072 bytes) > [ 0.000000] Inode-cache hash table entries: 8192 (order: 4, 65536 bytes) > [ 0.000000] Cannot allocate SWIOTLB buffer > [ 0.000000] Memory: 87152K/131072K available (7382K kernel code, > 532K rwdata, 3048K rodata, 272K init, 478K bss, 43920K reserved, 0K > cma-reserved) > [ 0.000000] Virtual kernel memory layout: > [ 0.000000] vmalloc : 0xffffff8000000000 - 0xffffffbdffff0000 > ( 247 GB) > [ 0.000000] vmemmap : 0xffffffbe00000000 - 0xffffffbfc0000000 > ( 7 GB maximum) > [ 0.000000] 0xffffffbe00000000 - 0xffffffbe001c0000 > ( 1 MB actual) > [ 0.000000] fixed : 0xffffffbffa7fd000 - 0xffffffbffac00000 > ( 4108 KB) > [ 0.000000] PCI I/O : 0xffffffbffae00000 - 0xffffffbffbe00000 > ( 16 MB) > [ 0.000000] modules : 0xffffffbffc000000 - 0xffffffc000000000 > ( 64 MB) > [ 0.000000] memory : 0xffffffc000000000 - 0xffffffc008000000 > ( 128 MB) > [ 0.000000] .init : 0xffffffc000ab1000 - 0xffffffc000af5000 > ( 272 KB) > [ 0.000000] .text : 0xffffffc000080000 - 0xffffffc000ab0374 > ( 10433 KB) > [ 0.000000] .data : 0xffffffc000b08000 - 0xffffffc000b8d080 > ( 533 KB) > [ 0.000000] Preemptible hierarchical RCU implementation. > [ 0.000000] Build-time adjustment of leaf fanout to 64. > [ 0.000000] RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4. > [ 0.000000] RCU: Adjusting geometry for rcu_fanout_leaf=64, nr_cpu_ids=4 > [ 0.000000] NR_IRQS:64 nr_irqs:64 0 > [ 0.000000] Architected cp15 timer(s) running at 62.50MHz (virt). > [ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff > max_cycles: 0x1cd42e208c, max_idle_ns: 881590405314 ns > [ 0.000126] sched_clock: 56 bits at 62MHz, resolution 16ns, wraps > every 4398046511096ns > [ 0.005764] Console: colour dummy device 80x25 > [ 0.005950] console [tty0] enabled > [ 0.006336] bootconsole [uart0] disabled > > Without this patch I never see any prints. > > Thanks, > > Alistair > >> >>> >>> Also I do see that there is a regression for xlnx-ep108 with qemu >>> 2.6.0 where bringing up the additional cpus causes a RAM/ROM exec >>> error (see below). If i remove cpu@1,2,3 from the dt it boots fine >>> (ep108 kernel dt). >> >> Strange. I'll look into it next week. >> >> Thanks, >> >> Alistair >> >>> >>> qemu: fatal: Trying to execute code outside RAM or ROM at 0xffffffc000082000 >>> >>> PC=ffffffc000082000 SP=0000000000000000 >>> X00=0000000034d5d91d X01=0000000000001122 X02=0000000000000000 >>> X03=0000000000000000 >>> X04=0000000000000000 X05=ffffffc000084000 X06=0000000034d5d91d >>> X07=0000000000000000 >>> X08=0000000000000000 X09=0000000000000000 X10=00000032b5193519 >>> X11=0000000000000000 >>> X12=0000000000000000 X13=0000000000000000 X14=0000000000000000 >>> X15=0000000000000000 >>> X16=0000000000000000 X17=0000000000000000 X18=0000000000000000 >>> X19=0000000000000000 >>> X20=0000000000000e11 X21=ffffffc000ae8688 X22=0000000000000000 >>> X23=0000000000000000 >>> X24=0000000000000000 X25=0000000000b43000 X26=0000000000b46000 >>> X27=ffffffc000082000 >>> X28=0000000000000000 X29=0000000000000000 X30=0000000000081fec >>> PSTATE=600003cd -ZC- EL3h >>> >>> --- >>> ffffffc000082000 <__secondary_switched>: >>> ffffffc000082000: f94002a0 ldr x0, [x21] >>> ffffffc000082004: 9100001f mov sp, x0 >>> ffffffc000082008: d280001d mov x29, #0x0 // #0 >>> ffffffc00008200c: 14002d0b b ffffffc00008d438 <secondary_start_kernel> >>> >>> Regards, >>> Nathan >>> >>>> >>>> Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com> >>>> --- >>>> In future versions of QEMU we can hopefully change the reset values from >>>> the command line, but at the moment this is the best we can do. >>>> >>>> .../d3d0ed0cc451232fd5037d41d8e73de469c83cf6.patch | 31 >>>> ++++++++++++++++++++++ >>>> recipes-zynqmp/qemu/qemu_2.5%.bbappend | 1 + >>>> 2 files changed, 32 insertions(+) >>>> create mode 100644 >>>> recipes-zynqmp/qemu/files/d3d0ed0cc451232fd5037d41d8e73de469c83cf6.patch >>>> >>>> diff --git >>>> a/recipes-zynqmp/qemu/files/d3d0ed0cc451232fd5037d41d8e73de469c83cf6.patch >>>> b/recipes-zynqmp/qemu/files/d3d0ed0cc451232fd5037d41d8e73de469c83cf6.patch >>>> new file mode 100644 >>>> index 0000000..930fcfc >>>> --- /dev/null >>>> +++ >>>> b/recipes-zynqmp/qemu/files/d3d0ed0cc451232fd5037d41d8e73de469c83cf6.patch >>>> @@ -0,0 +1,31 @@ >>>> +From d3d0ed0cc451232fd5037d41d8e73de469c83cf6 Mon Sep 17 00:00:00 2001 >>>> +From: Alistair Francis <alistair.fran...@xilinx.com> >>>> +Date: Tue, 7 Jun 2016 17:14:27 -0700 >>>> +Subject: [PATCH] cadence_uart: Enable transmitter by default >>>> + >>>> +On hardware Linux relies on u-boot to enable the transmitter for the >>>> +Cadence UART device. To allow direct Linux boots on QEMU change the >>>> +default reset values to enable the transmitter by default. >>>> + >>>> +Signed-off-by: Alistair Francis <alistair.fran...@xilinx.com> >>>> +Upstream-Status: Not Applicable >>>> +--- >>>> + hw/char/cadence_uart.c | 2 +- >>>> + 1 file changed, 1 insertion(+), 1 deletion(-) >>>> + >>>> +diff --git a/hw/char/cadence_uart.c b/hw/char/cadence_uart.c >>>> +index 9d379e5..c72ceb7 100644 >>>> +--- a/hw/char/cadence_uart.c >>>> ++++ b/hw/char/cadence_uart.c >>>> +@@ -440,7 +440,7 @@ static void cadence_uart_reset(DeviceState *dev) >>>> + { >>>> + CadenceUARTState *s = CADENCE_UART(dev); >>>> + >>>> +- s->r[R_CR] = 0x00000128; >>>> ++ s->r[R_CR] = 0x00000118; >>>> + s->r[R_IMR] = 0; >>>> + s->r[R_CISR] = 0; >>>> + s->r[R_RTRIG] = 0x00000020; >>>> +-- >>>> +2.7.4 >>>> + >>>> diff --git a/recipes-zynqmp/qemu/qemu_2.5%.bbappend >>>> b/recipes-zynqmp/qemu/qemu_2.5%.bbappend >>>> index 6f7cb50..73ed23d 100644 >>>> --- a/recipes-zynqmp/qemu/qemu_2.5%.bbappend >>>> +++ b/recipes-zynqmp/qemu/qemu_2.5%.bbappend >>>> @@ -5,5 +5,6 @@ SRC_URI += " \ >>>> file://4054bfa9e7986c9b7d2bf70f9e10af9647e376fc.patch \ >>>> file://8a83ffc2dafad3499b87a736b17ab1b203fdb00b.patch \ >>>> file://978364f12adebb4b8d90fdeb71242cb3c1405740.patch \ >>>> + file://d3d0ed0cc451232fd5037d41d8e73de469c83cf6.patch \ >>>> " >>>> >>>> -- >>>> 2.7.4 >>>> >>>> -- >>>> _______________________________________________ >>>> meta-xilinx mailing list >>>> meta-xilinx@yoctoproject.org >>>> https://lists.yoctoproject.org/listinfo/meta-xilinx >>> -- >>> _______________________________________________ >>> meta-xilinx mailing list >>> meta-xilinx@yoctoproject.org >>> https://lists.yoctoproject.org/listinfo/meta-xilinx -- _______________________________________________ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
