> Date: Tue, 9 Sep 2014 09:10:08 +0100
> From: graeme.gregory@linaro.org
> To: ndhillonv2@gmail.com
> CC: linaro-uefi@lists.linaro.org
> Subject: Re: [Linaro-uefi] LEG Kernel & ACPI Tables
>
> Hi Narinder,
>
> Inside Linaro we do not have access to an ARM64 platform which has PCI
> drivers available so we have never tried.
>
> Al might have some different info from Redhats perspective.
>
> Did you solve the issue you originally had?
>
> Graeme
>
> On Mon, Sep 08, 2014 at 07:03:12PM -0700, Narinder Dhillon wrote:
> > Thanx Al.
> > On another note. Do we have support for parsing PCIe root bridges for
> > ARM64 ?
> > I am trying to add PCIe root bridge to DSDT and osl.c is calling
> > 'pci_acpi_scan_root'. I can see there is code in ia64/kernel/pci.c but
> > no corresponding file in arm64.
> > Thanx.
> >
> > On Mon, Sep 8, 2014 at 1:59 PM, Al Stone <[1]al.stone@linaro.org>
> > wrote:
> >
> > On 09/05/2014 01:19 AM, Graeme Gregory wrote:
> > > Hi Narinder,
> > >
> > > That message is normal and occurs on successful boots for FVP/Juno
> > as
> > > well.
> > >
> > > I do not know why your kernel is stopping, but I believe the next
> > step
> > > in the kernel boot process is to bring up secondary CPUs via PSCI
> > so
> > > maybe a PSCI issue on the platform?
> > >
> > > Graeme
> > I've got a patch coming to fix the message; it's occurring even if
> > there
> > is no DT whatsoever and that seems sort of silly.
> > But, Graeme is essentially correct: either secondary CPU startup is
> > happening, or something gets stuck during device probe before printk
> > can report it. At this stage, the only secondary CPU boot protocol
> > supported is via PSCI; there is a parking protocol also but that's
> > still being implemented. You could use the spin-table protocol but
> > I would not recommend it -- it *will* go away and very soon.
> >
> > > On Thu, Sep 04, 2014 at 03:44:21PM -0700, Narinder Dhillon wrote:
> > >> Hi All,
> > >> I am booting latest LEG kernel from UEFI that has ACPI tables for
> > ARMv8
> > >> core. ACPI tables are parsed but kernel stops at a certain point
> > in the
> > >> boot cycle and I am not sure where and why.
> > >> In particular, this statement seems odd because it should not be
> > >> looking for device tree at all.
> > >> No CPU information found in DT
> > >> Kernel console output pasted below. Any help would be
> > appreciated.
> > >> Thanx,
> > >> EFI stub: Booting Linux Kernel...
> > >> Initializing cgroup subsys cpu
> > >> Linux version 3.17.0-rc2+ (narinder@ndhillon-lnx) (gcc version
> > 4.7.0
> > >> (Cavium Development Version) ) #3 SMP PREEMPT Thu Sep 4 15:33:38
> > PDT
> > >> 2014
> > >> CPU: AArch64 Processor [430f0a10] revision 0
> > >> Detected VIPT I-cache on CPU0
> > >> L1_CACHE_BYTES smaller than the Cache Writeback Granule (64 <
> > 128)
> > >> Memory limited to 1024MB
> > >> Early serial console at I/O port 0x0 (options '')
> > >> bootconsole [uart0] enabled
> > >> efi: Getting EFI parameters from FDT:
> > >> EFI v2.40 by Cavium Thunder cn88xx EFI Sep 1 2014 20:10:17
> > >> efi: ACPI=0x7ab85000 ACPI 2.0=0x7ab85014
> > >> cma: Reserved 16 MiB at 78c00000
> > >> ACPI: Early table checksum verification disabled
> > >> ACPI: RSDP 0x000000007AB85014 000024 (v02 CAVIUM)
> > >> ACPI: XSDT 0x000000007AB840E8 00003C (v01 CAVIUM THUNDERX
> > 00000000
> > >> 01000013)
> > >> ACPI: FACP 0x000000007AB81000 00010C (v05 CAVIUM THUNDERX
> > 00000000 INTL
> > >> 20140828)
> > >> ACPI BIOS Warning (bug): 32/64X FACS address mismatch in FADT:
> > >> 0x7AB80000/0x0000000000000001, using 32-bit address
> > >> (20140724/tbfadt-283)
> > >> ACPI: DSDT 0x000000007AB82000 000117 (v02 CAVIUM THUNDERX
> > 00000001 INTL
> > >> 20140828)
> > >> ACPI: APIC 0x000000007AB83000 0002B4 (v04 CAVIUM THUNDERX
> > 00000001 INTL
> > >> 20140828)
> > >> ACPI: GTDT 0x000000007AB7F000 0000E0 (v02 CAVIUM THUNDERX
> > 00000001 INTL
> > >> 20140828)
> > >> On node 0 totalpages: 521216
> > >> DMA zone: 7126 pages used for memmap
> > >> DMA zone: 0 pages reserved
> > >> DMA zone: 521216 pages, LIFO batch:31
> > >> BUG: not creating id mapping for 0x00008ee000000000
> > >> psci: probing for conduit method from ACPI.
> > >> psci: Using standard PSCI v0.2 function IDs
> > >> ACPI: GICC (acpi_id[0x0000] address[0000801000000000] MPDIR[0x0]
> > >> enabled)
> > >> ACPI: GICC (acpi_id[0x0001] address[0000801000000000] MPDIR[0x1]
> > >> enabled)
> > >> ACPI: GICC (acpi_id[0x0002] address[0000801000000000] MPDIR[0x2]
> > >> enabled)
> > >> ACPI: GICC (acpi_id[0x0003] address[0000801000000000] MPDIR[0x3]
> > >> enabled)
> > >> ACPI: GICC (acpi_id[0x0004] address[0000801000000000] MPDIR[0x4]
> > >> enabled)
> > >> ACPI: GICC (acpi_id[0x0005] address[0000801000000000] MPDIR[0x5]
> > >> enabled)
> > >> ACPI: GICC (acpi_id[0x0006] address[0000801000000000] MPDIR[0x6]
> > >> enabled)
> > >> ACPI: GICC (acpi_id[0x0007] address[0000801000000000] MPDIR[0x7]
> > >> enabled)
> > >> ACPI: 8 CPUs enabled, 8 CPUs total
> > >> PERCPU: Embedded 12 pages/cpu @ffffffc07edbc000 s17472 r8192
> > d23488
> > >> u49152
> > >> pcpu-alloc: s17472 r8192 d23488 u49152 alloc=12*4096
> > >> pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3 [0] 4 [0] 5 [0] 6 [0] 7
> > >> Built 1 zonelists in Zone order, mobility grouping on. Total
> > pages:
> > >> 514090
> > >> Kernel command line: BOOT_IMAGE=/boot/Image root=/dev/sda2
> > >> console=ttyAMA0 mem=1024M earlycon=pl011,0x87e024000000 debug
> > >> maxcpus=16 rw
> > >> log_buf_len individual max cpu contribution: 4096 bytes
> > >> log_buf_len total cpu_extra contributions: 28672 bytes
> > >> log_buf_len min size: 16384 bytes
> > >> log_buf_len: 65536 bytes
> > >> early log buf free: 12956(79%)
> > >> PID hash table entries: 4096 (order: 3, 32768 bytes)
> > >> Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes)
> > >> Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes)
> > >> Memory: 1957372K/2084864K available (4948K kernel code, 446K
> > rwdata,
> > >> 1928K rodata, 305K init, 229K bss, 127492K reserved)
> > >> Virtual kernel memory layout:
> > >> vmalloc : 0xffffff8000000000 - 0xffffffbdffff0000 ( 247
> > GB)
> > >> vmemmap : 0xffffffbe00000000 - 0xffffffbfc0000000 ( 7
> > GB
> > >> maximum)
> > >> 0xffffffbe0002a000 - 0xffffffbe01c00000 ( 27
> > MB
> > >> actual)
> > >> PCI I/O : 0xffffffbffa000000 - 0xffffffbffb000000 ( 16
> > MB)
> > >> fixed : 0xffffffbffbdfe000 - 0xffffffbffbdff000 ( 4
> > KB)
> > >> modules : 0xffffffbffc000000 - 0xffffffc000000000 ( 64
> > MB)
> > >> memory : 0xffffffc000000000 - 0xffffffc07f400000 ( 2036
> > MB)
> > >> .init : 0xffffffc000739000 - 0xffffffc000785440 ( 306
> > KB)
> > >> .text : 0xffffffc000080000 - 0xffffffc0007380f4 ( 6881
> > KB)
> > >> .data : 0xffffffc000786000 - 0xffffffc0007f5b98 ( 447
> > KB)
> > >> SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=8, Nodes=1
> > >> Preemptible hierarchical RCU implementation.
> > >> NR_IRQS:64 nr_irqs:64 0
> > >> clocksource_of_init: no matching clocksources found
> > >> Architected cp15 timer(s) running at 100.00MHz (phys).
> > >> sched_clock: 56 bits at 100MHz, resolution 10ns, wraps every
> > >> 2748779069440ns
> > >> Console: colour dummy device 80x25
> > >> allocated 8388608 bytes of page_cgroup
> > >> please try 'cgroup_disable=memory' option if you don't want
> > memory
> > >> cgroups
> > >> Calibrating delay loop (skipped), value calculated using timer
> > >> frequency.. 200.00 BogoMIPS (lpj=1000000)
> > >> pid_max: default: 32768 minimum: 301
> > >> ACPI: Core revision 20140724
> > >> ACPI: All ACPI Tables successfully acquired
> > >> Security Framework initialized
> > >> Mount-cache hash table entries: 4096 (order: 3, 32768 bytes)
> > >> Mountpoint-cache hash table entries: 4096 (order: 3, 32768 bytes)
> > >> Initializing cgroup subsys memory
> > >> Initializing cgroup subsys hugetlb
> > >> No CPU information found in DT
> > >> hw perfevents: enabled with arm/armv8-pmuv3 PMU driver, 7
> > counters
> > >> available
> > >> Remapping and enabling EFI services.
> > >> Freed 0x44f8000 bytes of EFI boot services memory
> > >
> > >> _______________________________________________
> > >> Linaro-uefi mailing list
> > >> [2]Linaro-uefi@lists.linaro.org
> > >> [3]http://lists.linaro.org/mailman/listinfo/linaro-uefi
> > >
> > >
> > > _______________________________________________
> > > Linaro-uefi mailing list
> > > [4]Linaro-uefi@lists.linaro.org
> > > [5]http://lists.linaro.org/mailman/listinfo/linaro-uefi
> > >
> >
> > --
> > ciao,
> > al
> > -----------------------------------
> > Al Stone
> > Software Engineer
> > Linaro Enterprise Group
> > [6]al.stone@linaro.org
> > -----------------------------------
> >
> > References
> >
> > 1. mailto:al.stone@linaro.org
> > 2. mailto:Linaro-uefi@lists.linaro.org
> > 3. http://lists.linaro.org/mailman/listinfo/linaro-uefi
> > 4. mailto:Linaro-uefi@lists.linaro.org
> > 5. http://lists.linaro.org/mailman/listinfo/linaro-uefi
> > 6. mailto:al.stone@linaro.org
>
> _______________________________________________
> Linaro-uefi mailing list
> Linaro-uefi@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/linaro-uefi