* [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
@ 2015-03-18 14:11 GP Orcullo
2015-03-18 14:21 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-18 14:11 UTC (permalink / raw)
To: xenomai@xenomai.org
Hi,
I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
3.10.33 non-mainlined kernel.
The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
Once CONFIG_XENOMAI is set, the boot fails.
Attached are the .config and the bootlog files. Turning
CONFIG_SMP_ON_UP off gives a different result.
Any pointers on where to start looking?
Thanks
GP Orcullo
-------------- next part --------------
Booting Linux on physical CPU 0x200
Initializing cgroup subsys cpu
Linux version 3.10.33-mmc+ (gemi@mba) (gcc version 4.7.2 (Debian 4.7.2-5) ) #70 SMP PREEMPT Wed Mar 18 19:16:02 SGT 2015
CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ODROIDC, model: AMLOGIC
physical memory start address is 0x200000
reserved_end is d9fffff
Total memory is 1022 MiB
Reserved low memory from 0x06000000 to 0x0d9fffff, size: 122 MiB
mesonfb0(low) : 0x06100000 - 0x07900000 ( 24 MiB)
mesonfb1(low) : 0x07900000 - 0x07a00000 ( 1 MiB)
mesonstream0(low) : 0x07a00000 - 0x09a00000 ( 32 MiB)
vdec0(low) : 0x09a00000 - 0x0da00000 ( 64 MiB)
[ 0.000000@0] Booting Linux on physical CPU 0x200
[ 0.000000@0] Initializing cgroup subsys cpu
[ 0.000000@0] Linux version 3.10.33-mmc+ (gemi@mba) (gcc version 4.7.2 (Debian 4.7.2-5) ) #70 SMP PREEMPT Wed Mar 18 19:16:02 SGT 2015
[ 0.000000@0] Machine: ODROIDC, model: AMLOGIC
[ 0.000000@0] reserved_end is d9fffff
[ 0.000000@0]
[ 0.000000@0] Total memory is 1022 MiB
[ 0.000000@0] Reserved low memory from 0x06000000 to 0x0d9fffff, size: 122 MiB
[ 0.000000@0] mesonfb0(low) : 0x06100000 - 0x07900000 ( 24 MiB)
[ 0.000000@0] mesonfb1(low) : 0x07900000 - 0x07a00000 ( 1 MiB)
[ 0.000000@0] mesonstream0(low) : 0x07a00000 - 0x09a00000 ( 32 MiB)
[ 0.000000@0] vdec0(low) : 0x09a00000 - 0x0da00000 ( 64 MiB)
bootconsole [earlycon0] enabled
[ 0.000000@0] bootconsole [earlycon0] enabled
cma: CMA: reserved 8 MiB at 2f000000
[ 0.000000@0] cma: CMA: reserved 8 MiB at 2f000000
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 226816
free_area_init_node: node 0, pgdat c0583280, node_mem_map c06e9000
Normal zone: 1520 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 159744 pages, LIFO batch:31
HighMem zone: 524 pages used for memmap
HighMem zone: 67072 pages, LIFO batch:15
Meson chip version = RevA (1B:A - 0:B72)
[ 0.000000@0] Meson chip version = RevA (1B:A - 0:B72)
PERCPU: Embedded 10 pages/cpu @c0ef2000 s18688 r8192 d14080 u40960
[ 0.000000@0] PERCPU: Embedded 10 pages/cpu @c0ef2000 s18688 r8192 d14080 u40960
pcpu-alloc: s18688 r8192 d14080 u40960 alloc=10*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 225296
Kernel command line: earlyprintk dwc_otg.speed=1 console=tty0 root=/dev/mmcblk0p1 rootwait rw no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=1024x768p60hz m_bpp=16 vout=hdmi disableuhs disablehpd=true
[ 0.000000@0] Kernel command line: earlyprintk dwc_otg.speed=1 console=tty0 root=/dev/mmcblk0p1 rootwait rw no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=1024x768p60hz m_bpp=16 vout=hdmi disableuhs disablehpd=true
PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000@0] PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000@0] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000@0] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory:[ 0.000000@0] Memory: 64MB 64MB 16MB 16MB 806MB 806MB = 886MB total
= 886MB total
Memory: 882744k/882744k available, 24520k reserved, 268288K highmem
[ 0.000000@0] Memory: 882744k/882744k available, 24520k reserved, 268288K highmem
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
.text : 0xc0008000 - 0xc052503c (5237 kB)
.init : 0xc0526000 - 0xc054d900 ( 159 kB)
.data : 0xc054e000 - 0xc05841a0 ( 217 kB)
.bss : 0xc05841a0 - 0xc06e4e68 (1412 kB)
[ 0.000000@0] Virtual kernel memory layout:
[ 0.000000@0] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000@0] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000@0] vmalloc : 0xf0000000 - 0xff000000 ( 240 MB)
[ 0.000000@0] lowmem : 0xc0000000 - 0xef800000 ( 760 MB)
[ 0.000000@0] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
[ 0.000000@0] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
[ 0.000000@0] .text : 0xc0008000 - 0xc052503c (5237 kB)
[ 0.000000@0] .init : 0xc0526000 - 0xc054d900 ( 159 kB)
[ 0.000000@0] .data : 0xc054e000 - 0xc05841a0 ( 217 kB)
[ 0.000000@0] .bss : 0xc05841a0 - 0xc06e4e68 (1412 kB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000@0] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
Preemptible hierarchical RCU implementation.
[ 0.000000@0] Preemptible hierarchical RCU implementation.
NR_IRQS:256
[ 0.000000@0] NR_IRQS:256
sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms
[ 0.000000@0] sched_clock: 32 bits at 1000kHz, resolution 1000ns, wraps every 4294967ms
I-pipe, 1.000 MHz clocksource
[ 0.000000@0] I-pipe, 1.000 MHz clocksource
Switching to timer-based delay loop
[ 0.000000@0] Switching to timer-based delay loop
Interrupt pipeline (release #7)
[ 0.000000@0] Interrupt pipeline (release #7)
Console: colour dummy device 80x30
[ 0.000000@0] Console: colour dummy device 80x30
console [tty0] enabled, bootconsole disabled
[ 0.000000@0] console [tty0] enabled, bootconsole disabled
Calibrating delay loop (skipped), value calculated using timer frequency.. 2.00 BogoMIPS (lpj=10000)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
Initializing cgroup subsys devices
CPU: Testing write buffer coherency: ok
CPU0: thread -1, cpu 0, socket 2, mpidr 80000200
Setting up static identity map for 0xc03e7d00 - 0xc03e7d58
L310 cache controller enabled
l2x0: 8 ways, CACHE_ID 0x4100a0c9, AUX_CTRL 0x7ec60001, Cache size: 524288 B
CPU1: Booted secondary processor
CPU1: thread -1, cpu 1, socket 2, mpidr 80000201
CPU2: Booted secondary processor
CPU2: thread -1, cpu 2, socket 2, mpidr 80000202
CPU3: Booted secondary processor
CPU3: thread -1, cpu 3, socket 2, mpidr 80000203
Brought up 4 CPUs
SMP: Total of 4 processors activated (8.00 BogoMIPS).
CPU: All CPU(s) started in SVC mode.
devtmpfs: initialized
clkrate [ xtal ] : 24000000
clkrate [ pll_sys ] : 1200000000
clkrate [ pll_fixed ] : 2550000000
clkrate [ pll_vid ] : 732000000
clkrate [ pll_ddr ] : 0
clkrate [ a9_clk ] : 1200000000
clkrate [ clk81 ] : 159375000
pinctrl core: initialized pinctrl subsystem
regulator-dummy: no parameters
NET: Registered protocol family 16
DMA: preallocated 4096 KiB pool for atomic coherent allocations
VPU driver version: v02
load vpu_clk in dts: 182150000Hz(3)
vpu_probe OK
amlogic_gpio gpio: Probed amlogic GPIO driver
register lm device lm-root
register lm device lm1
register lm device lm0
Init pinux probe!
pinmux-m8b pinmux: Probed amlogic pinctrl driver
bio: create slab <bio-0> at 0
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource ipipe_tsc
NET: Registered protocol family 2
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP: reno registered
UDP hash table entries: 512 (order: 2, 16384 bytes)
UDP-Lite hash table entries: 512 (order: 2, 16384 bytes)
NET: Registered protocol family 1
audit: initializing netlink socket (disabled)
type=2000 audit(0.270:1): initialized
Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 0
CPU: 3 PID: 0 Comm: swapper/3 Not tainted 3.10.33-mmc+ #70
[<c0015208>] (unwind_backtrace+0x0/0xf8) from [<c00123b8>] (show_stack+0x10/0x14)
[<c00123b8>] (show_stack+0x10/0x14) from [<c03e02b0>] (panic+0x8c/0x1e4)
[<c03e02b0>] (panic+0x8c/0x1e4) from [<c007c4a4>] (watchdog_timer_fn+0xe4/0x278)
[<c007c4a4>] (watchdog_timer_fn+0xe4/0x278) from [<c0045fc4>] (__run_hrtimer.isra.17+0x50/0xc8)
[<c0045fc4>] (__run_hrtimer.isra.17+0x50/0xc8) from [<c0046714>] (hrtimer_interrupt+0x140/0x298)
[<c0046714>] (hrtimer_interrupt+0x140/0x298) from [<c001ddf0>] (meson_timer_interrupt+0x74/0xa4)
[<c001ddf0>] (meson_timer_interrupt+0x74/0xa4) from [<c007cfa0>] (handle_irq_event_percpu+0x34/0x178)
[<c007cfa0>] (handle_irq_event_percpu+0x34/0x178) from [<c007d120>] (handle_irq_event+0x3c/0x5c)
[<c007d120>] (handle_irq_event+0x3c/0x5c) from [<c007fbc0>] (handle_fasteoi_irq+0xc0/0x100)
[<c007fbc0>] (handle_fasteoi_irq+0xc0/0x100) from [<c007c8d0>] (generic_handle_irq+0x1c/0x30)
[<c007c8d0>] (generic_handle_irq+0x1c/0x30) from [<c000f894>] (handle_IRQ+0x68/0x90)
[<c000f894>] (handle_IRQ+0x68/0x90) from [<c0087b04>] (__ipipe_do_sync_stage+0x244/0x2ec)
[<c0087b04>] (__ipipe_do_sync_stage+0x244/0x2ec) from [<c00084c8>] (__ipipe_grab_irq+0xac/0xc8)
[<c00084c8>] (__ipipe_grab_irq+0xac/0xc8) from [<c0008780>] (gic_handle_irq+0x3c/0x5c)
Exception stack(0xeea9ff78 to 0xeea9ffc0)
ff60: c0087ea4 c0087ef8
ff80: 60000153 ffffffff eea9ffc4 c000e480 00000000 00000000 c0f10a2c 00000000
ffa0: c0549a2c eea9e000 c0562568 c03eb0ac c0584030 00000001 c0584030 eea9e000
[<c0008780>] (gic_handle_irq+0x3c/0x5c) from [<c000e480>] (__irq_svc+0x40/0x6c)
Exception stack(0xeea9ff90 to 0xeea9ffd8)
ff80: 00000000 00000000 c0f10a2c 00000000
ffa0: c0549a2c eea9e000 c0562568 c03eb0ac c0584030 00000001 c0584030 eea9e000
ffc0: 00000000 eea9ffd8 c0087ea4 c0087ef8 60000153 ffffffff
[<c000e480>] (__irq_svc+0x40/0x6c) from [<c0087ef8>] (ipipe_unstall_root+0x68/0x78)
[<c0087ef8>] (ipipe_unstall_root+0x68/0x78) from [<c005caf8>] (cpu_startup_entry+0xcc/0x128)
[<c005caf8>] (cpu_startup_entry+0xcc/0x128) from [<005dd6c4>] (0x5dd6c4)
CPU1: stopping
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.10.33-mmc+ #70
[<c0015208>] (unwind_backtrace+0x0/0xf8) from [<c00123b8>] (show_stack+0x10/0x14)
[<c00123b8>] (show_stack+0x10/0x14) from [<c0013c10>] (handle_IPI+0xbc/0x174)
[<c0013c10>] (handle_IPI+0xbc/0x174) from [<c0087aa4>] (__ipipe_do_sync_stage+0x1e4/0x2ec)
[<c0087aa4>] (__ipipe_do_sync_stage+0x1e4/0x2ec) from [<c00083f8>] (__ipipe_grab_ipi+0x90/0xb0)
[<c00083f8>] (__ipipe_grab_ipi+0x90/0xb0) from [<c0008798>] (gic_handle_irq+0x54/0x5c)
Exception stack(0xeea9bf78 to 0xeea9bfc0)
bf60: c0087ea4 c0087ef8
bf80: 60000153 ffffffff eea9bfc4 c000e480 00000000 00000000 c0efca2c 00000000
bfa0: c0549a2c eea9a000 c0562568 c03eb0ac c0584030 00000001 c0584030 eea9a000
[<c0008798>] (gic_handle_irq+0x54/0x5c) from [<c000e480>] (__irq_svc+0x40/0x6c)
Exception stack(0xeea9bf90 to 0xeea9bfd8)
bf80: 00000000 00000000 c0efca2c 00000000
bfa0: c0549a2c eea9a000 c0562568 c03eb0ac c0584030 00000001 c0584030 eea9a000
bfc0: 00000000 eea9bfd8 c0087ea4 c0087ef8 60000153 ffffffff
[<c000e480>] (__irq_svc+0x40/0x6c) from [<c0087ef8>] (ipipe_unstall_root+0x68/0x78)
[<c0087ef8>] (ipipe_unstall_root+0x68/0x78) from [<c005caf8>] (cpu_startup_entry+0xcc/0x128)
[<c005caf8>] (cpu_startup_entry+0xcc/0x128) from [<005dd6c4>] (0x5dd6c4)
CPU2: stopping
CPU: 2 PID: 0 Comm: swapper/2 Not tainted 3.10.33-mmc+ #70
[<c0015208>] (unwind_backtrace+0x0/0xf8) from [<c00123b8>] (show_stack+0x10/0x14)
[<c00123b8>] (show_stack+0x10/0x14) from [<c0013c10>] (handle_IPI+0xbc/0x174)
[<c0013c10>] (handle_IPI+0xbc/0x174) from [<c0087aa4>] (__ipipe_do_sync_stage+0x1e4/0x2ec)
[<c0087aa4>] (__ipipe_do_sync_stage+0x1e4/0x2ec) from [<c00083f8>] (__ipipe_grab_ipi+0x90/0xb0)
[<c00083f8>] (__ipipe_grab_ipi+0x90/0xb0) from [<c0008798>] (gic_handle_irq+0x54/0x5c)
Exception stack(0xeea9df78 to 0xeea9dfc0)
df60: c0087ea4 c0087ef8
df80: 60000153 ffffffff eea9dfc4 c000e480 00000000 00000000 c0f06a2c 00000000
dfa0: c0549a2c eea9c000 c0562568 c03eb0ac c0584030 00000001 c0584030 eea9c000
[<c0008798>] (gic_handle_irq+0x54/0x5c) from [<c000e480>] (__irq_svc+0x40/0x6c)
Exception stack(0xeea9df90 to 0xeea9dfd8)
df80: 00000000 00000000 c0f06a2c 00000000
dfa0: c0549a2c eea9c000 c0562568 c03eb0ac c0584030 00000001 c0584030 eea9c000
dfc0: 00000000 eea9dfd8 c0087ea4 c0087ef8 60000153 ffffffff
[<c000e480>] (__irq_svc+0x40/0x6c) from [<c0087ef8>] (ipipe_unstall_root+0x68/0x78)
[<c0087ef8>] (ipipe_unstall_root+0x68/0x78) from [<c005caf8>] (cpu_startup_entry+0xcc/0x128)
[<c005caf8>] (cpu_startup_entry+0xcc/0x128) from [<005dd6c4>] (0x5dd6c4)
SMP: failed to stop secondary CPUs
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.10.33 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_IPIPE_WANT_ACTIVE_MM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_FIQ=y
CONFIG_VECTORS_BASE=0xffff0000
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION="-mmc"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_FHANDLE=y
CONFIG_AUDIT=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=19
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_CONVERTED=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_HOTPLUG=y
CONFIG_PANIC_TIMEOUT=0
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not set
# CONFIG_MAC_PARTITION is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not set
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
#
# Real-time sub-system
#
#
# WARNING! You enabled APM, CPU Frequency scaling, ACPI 'processor'
#
#
# or Intel cpuidle option. These options are known to cause troubles
#
#
# with Xenomai, disable them.
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_PRIOCPL is not set
CONFIG_XENO_OPT_PIPELINE_HEAD=y
# CONFIG_XENO_OPT_SCHED_CLASSES is not set
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_VFILE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
# CONFIG_XENO_OPT_DEBUG_NUCLEUS is not set
CONFIG_XENO_OPT_DEBUG_XNLOCK=y
# CONFIG_XENO_OPT_DEBUG_QUEUES is not set
# CONFIG_XENO_OPT_DEBUG_REGISTRY is not set
# CONFIG_XENO_OPT_DEBUG_TIMERS is not set
CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX=y
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
# CONFIG_XENO_OPT_SHIRQ is not set
CONFIG_XENO_OPT_SELECT=y
CONFIG_XENO_OPT_HOSTRT=y
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Machine
#
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
CONFIG_XENO_HW_FPU=y
CONFIG_XENO_HW_UNLOCKED_SWITCH=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
CONFIG_XENO_OPT_POSIX_REGISTRY_NRSLOTS=64
CONFIG_XENO_OPT_POSIX_REGISTRY_NRDESCS=128
CONFIG_XENO_OPT_POSIX_NRTIMERS=128
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_POSIX_SELECT=y
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_OPT_RTDM_SELECT=y
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
#
# Drivers
#
#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=y
# CONFIG_XENO_DRIVERS_KLATENCY is not set
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
CONFIG_XENO_DRIVERS_SWITCHTEST=y
# CONFIG_XENO_DRIVERS_RTDMTEST is not set
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set
#
# Real-time IPC drivers
#
CONFIG_XENO_DRIVERS_RTIPC=y
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
CONFIG_FREEZER=y
#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_MULTIPLATFORM is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
CONFIG_PLAT_MESON=y
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set
#
# Amlogic Meson platform
#
# CONFIG_ARCH_MESON6 is not set
# CONFIG_ARCH_MESON6TV is not set
# CONFIG_ARCH_MESON6TVD is not set
# CONFIG_ARCH_MESON8 is not set
CONFIG_ARCH_MESON8B=y
# CONFIG_ARCH_MESON8M2 is not set
# CONFIG_ARCH_MESONG9TV is not set
#
# Meson development boards
#
# CONFIG_MACH_MESON8B_COMMON_BOARD is not set
CONFIG_MACH_MESON8B_ODROIDC=y
# CONFIG_MESON_IRQ is not set
CONFIG_MESON_ARM_GIC=y
CONFIG_MESON_CLOCK_TICK_RATE=24000000
# CONFIG_MESON_ARM_GIC_FIQ is not set
# CONFIG_MESON_SUSPEND is not set
# CONFIG_CLK81_DFS is not set
CONFIG_MESON_LEGACY_REGISTER_API=y
# CONFIG_MESON_CPU_EMULATOR is not set
CONFIG_CLKTREE_DEBUG=y
# CONFIG_MESON_CPU_TEMP_SENSOR is not set
# CONFIG_MESON_TRUSTZONE is not set
# CONFIG_MESON_CUSTOM_BOARD_SUPPORT is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_PLAT_SPEAR is not set
CONFIG_IPIPE_ARM_KUSER_TSC=y
#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
CONFIG_SWP_EMULATE=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_NEED_KUSER_HELPERS=y
CONFIG_KUSER_HELPERS=y
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_458693 is not set
# CONFIG_ARM_ERRATA_460075 is not set
# CONFIG_ARM_ERRATA_742230 is not set
# CONFIG_ARM_ERRATA_742231 is not set
# CONFIG_PL310_ERRATA_588369 is not set
# CONFIG_ARM_ERRATA_643719 is not set
# CONFIG_ARM_ERRATA_720789 is not set
# CONFIG_PL310_ERRATA_727915 is not set
# CONFIG_ARM_ERRATA_743622 is not set
# CONFIG_ARM_ERRATA_751472 is not set
# CONFIG_PL310_ERRATA_753970 is not set
CONFIG_ARM_ERRATA_754322=y
# CONFIG_ARM_ERRATA_754327 is not set
CONFIG_ARM_ERRATA_764369=y
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
# CONFIG_ARM_ERRATA_798181 is not set
# CONFIG_FIQ_DEBUGGER is not set
#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
# CONFIG_HAVE_ARM_ARCH_TIMER is not set
# CONFIG_MCPM is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=4
CONFIG_HOTPLUG_CPU=y
# CONFIG_ARM_PSCI is not set
CONFIG_LOCAL_TIMERS=y
CONFIG_ARCH_NR_GPIO=0
CONFIG_IPIPE=y
CONFIG_IPIPE_LEGACY=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_WANT_APIREV_2=y
CONFIG_IPIPE_TARGET_APIREV=2
CONFIG_IPIPE_HAVE_HOSTRT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_BOUNCE=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_XEN is not set
# CONFIG_ARM_FLUSH_CONSOLE_ON_RESTART is not set
#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
# CONFIG_BUILD_ARM_APPENDED_DTB_IMAGE is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set
#
# CPU Power Management
#
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_HOTPLUG is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_INTERACTIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
CONFIG_CPU_FREQ_GOV_HOTPLUG=y
# CONFIG_CPU_FREQ_GOV_INTERACTIVE is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
#
# ARM CPU frequency scaling drivers
#
# CONFIG_ARM_EXYNOS4210_CPUFREQ is not set
# CONFIG_ARM_EXYNOS4X12_CPUFREQ is not set
# CONFIG_ARM_EXYNOS5250_CPUFREQ is not set
# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set
CONFIG_AMLOGIC_MESON_CPUFREQ=y
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y
#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HAS_WAKELOCK=y
CONFIG_HAS_EARLYSUSPEND=y
CONFIG_WAKELOCK=y
CONFIG_WAKELOCK_STAT=y
CONFIG_USER_WAKELOCK=y
CONFIG_EARLYSUSPEND=y
# CONFIG_NO_USER_SPACE_SCREEN_ACCESS_CONTROL is not set
# CONFIG_CONSOLE_EARLYSUSPEND is not set
CONFIG_FB_EARLYSUSPEND=y
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
# CONFIG_SUSPEND_TIME is not set
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=y
CONFIG_PACKET_DIAG=y
CONFIG_UNIX=y
CONFIG_UNIX_DIAG=y
# CONFIG_XFRM_USER is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
# CONFIG_NET_IP_TUNNEL is not set
# CONFIG_ARPD is not set
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_ANDROID_PARANOID_NETWORK is not set
# CONFIG_NET_ACTIVITY_STATS is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=m
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_RPS is not set
CONFIG_XPS=y
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_WIRELESS is not set
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y
#
# Device Drivers
#
#
# Amlogic Device Drivers
#
#
# Char devices
#
# CONFIG_EARLY_INIT is not set
#
# Register Debug Support
#
# CONFIG_AML_REG_DEBUG is not set
CONFIG_AM_UART=y
CONFIG_AM_UART_CONSOLE=y
CONFIG_OF_LM=y
CONFIG_AML_RTC=y
#
# I2C Hardware Bus support
#
# CONFIG_I2C_AML is not set
# CONFIG_I2C_SW_AML is not set
CONFIG_AM_INPUT=y
CONFIG_SARADC_AM=y
# CONFIG_MESON_INPUT_REMOTE is not set
# CONFIG_MESON_NEW_INPUT_REMOTE is not set
# CONFIG_MESON_INPUT_KEYBOARD is not set
# CONFIG_MESON_INPUT_TOUCHSCREEN is not set
# CONFIG_SIMCARD_DETECT_AM is not set
# CONFIG_AML_HOLD_KEY is not set
# CONFIG_AML_CALL_KEY is not set
# CONFIG_SENSOR_DEVICES is not set
# CONFIG_AML_GPIO_KEY is not set
CONFIG_GPIO_AMLOGIC=y
CONFIG_PINCTRL_AMLOGIC=y
#
# Power Management Support
#
# CONFIG_AMLOGIC_BOARD_HAS_PMU is not set
# CONFIG_AML_PMU_ALGORITHM_SUPPORT is not set
# CONFIG_AML_DVFS is not set
# CONFIG_MESON_CS_DCDC_REGULATOR is not set
#
# Security key Support
#
# CONFIG_SECURITYKEY is not set
#
# key management Support
#
# CONFIG_UNIFY_KEY_MANAGE is not set
#
# EFUSE Support
#
CONFIG_EFUSE=y
# CONFIG_EFUSE_WRITE_VERSION_PERMIT is not set
CONFIG_EFUSE_LAYOUT_VERSION=3
#
# Smartcard support
#
# CONFIG_AM_SMARTCARD is not set
CONFIG_AML_VIRTUAL_THERMAL=y
CONFIG_AMLOGIC_THERMAL=y
CONFIG_AML_WDT=y
#
# AMLOGIC SPI Hardware bus support
#
# CONFIG_AMLOGIC_SPICC_MASTER is not set
#
# USB Support
#
CONFIG_AMLOGIC_USB=y
CONFIG_USB_DWC_OTG_HCD=y
CONFIG_USB_HOST_ELECT_TEST=y
#
# MMC/SD/SDIO Host Controller Drivers
#
#
# Multimedia Card support
#
CONFIG_MMC_AML=y
# CONFIG_MMC_AML_DEBUG is not set
# CONFIG_AML_MMC_DEBUG_FORCE_SINGLE_BLOCK_RW is not set
#
# SPI NOR Flash support
#
# CONFIG_AMLOGIC_SPI_NOR is not set
#
# Network devices
#
#
# Ethernet Support
#
CONFIG_AM_ETHERNET=y
CONFIG_PHYLIB=y
#
# MII PHY device drivers
#
CONFIG_AML_PHY=y
# CONFIG_AML_LAN8720 is not set
# CONFIG_AML_IP101_PHY is not set
# CONFIG_AML_KSZ8091 is not set
CONFIG_AML_RTL8211F=y
CONFIG_AM_ETHERNET_DEBUG_LEVEL=1
# CONFIG_AM_WIFI is not set
#
# Bluetooth Device Support
#
# CONFIG_BT_WAKE_CTRL is not set
# CONFIG_BT_RTKBTUSB is not set
# CONFIG_MESON_NFC is not set
#
# Audio devices
#
#
# Audio Interface
#
# CONFIG_AMAUDIO is not set
#
# Amlogic Audio Interface V2
#
# CONFIG_AMAUDIO2 is not set
#
# Audio dsp process
#
# CONFIG_AML_AUDIO_DSP is not set
#
# Video devices
#
# CONFIG_AML_VFM is not set
# CONFIG_AM_PTSSERVER is not set
# CONFIG_H264_4K2K_SINGLE_CORE is not set
# CONFIG_VSYNC_RDMA is not set
# CONFIG_AM_VIDEO is not set
# CONFIG_AM_VIDEO2 is not set
# CONFIG_SUPPORT_VIDEO_ON_VPP2 is not set
#
# Canvas management driver
#
CONFIG_AM_CANVAS=y
# CONFIG_AM_DISPLAY_MODULE is not set
#
# HDMI TX Support
#
# CONFIG_AML_HDMI_TX is not set
# CONFIG_AML_EXT_HDMIIN is not set
# CONFIG_DEBUG_DRIVER is not set
#
# Post Process Manager driver
#
# CONFIG_POST_PROCESS_MANAGER is not set
#
# Amlogic Camera Support
#
# CONFIG_VIDEO_AMLOGIC_CAPTURE is not set
#
# V4L2 Video Support
#
# CONFIG_V4L_AMLOGIC_VIDEO is not set
# CONFIG_V4L_AMLOGIC_VIDEO2 is not set
#
# Amlogic ion video support
#
# CONFIG_VIDEOBUF2_ION is not set
# CONFIG_AMLOGIC_IONVIDEO is not set
#
# Deinterlace driver
#
# CONFIG_DEINTERLACE is not set
#
# MIPI Support
#
# CONFIG_AMLOGIC_MIPI is not set
# CONFIG_D2D3_PROCESS is not set
#
# Amlogic VE & CM
#
# CONFIG_AM_VECM is not set
#
# Amlogic DVB driver
#
# CONFIG_AM_DVB is not set
#
# AMLOGIC CI Driver
#
# CONFIG_AM_PCMCIA is not set
# CONFIG_AM_IOBUS is not set
#
# GPU (ARM Mali)
#
#
# ION support
#
# CONFIG_AMLOGIC_ION is not set
#
# Amlogic Crypto Support
#
# CONFIG_CRYPTO_AML_HW_CRYPRO is not set
# CONFIG_CRYPTO_DEVICE_DRIVER is not set
#
# MHL Support
#
# CONFIG_PANEL_IT6681 is not set
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
# CONFIG_DMA_SHARED_BUFFER is not set
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=8
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
CONFIG_CMA_AREAS=7
#
# Bus devices
#
# CONFIG_CONNECTOR is not set
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set
#
# RAM/ROM/Flash chip drivers
#
# CONFIG_MTD_CFI is not set
# CONFIG_MTD_JEDECPROBE is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set
#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_DATAFLASH is not set
# CONFIG_MTD_M25P80 is not set
# CONFIG_MTD_SST25L is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_NAND_IDS=y
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
# CONFIG_MTD_NAND_PLATFORM is not set
# CONFIG_MTD_ALAUDA is not set
# CONFIG_MTD_ONENAND is not set
#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
# CONFIG_MTD_UBI is not set
CONFIG_DTC=y
CONFIG_OF=y
#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
CONFIG_OF_SELFTEST=y
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
CONFIG_OF_I2C=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set
#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_UID_STAT is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set
#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set
#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
#
# SCSI device support
#
CONFIG_SCSI_MOD=m
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=m
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=m
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_MULTI_LUN=y
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_LIBFC is not set
# CONFIG_LIBFCOE is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
# CONFIG_ATA is not set
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_MII=y
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
CONFIG_TUN=y
# CONFIG_VETH is not set
#
# CAIF transport drivers
#
#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
# CONFIG_NET_CADENCE is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
# CONFIG_NET_VENDOR_CIRRUS is not set
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_NET_VENDOR_SEEQ is not set
# CONFIG_NET_VENDOR_SMSC is not set
# CONFIG_NET_VENDOR_STMICRO is not set
# CONFIG_NET_VENDOR_WIZNET is not set
#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_AMLOGIC_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_AX88179_178A=m
# CONFIG_USB_NET_CDCETHER is not set
# CONFIG_USB_NET_CDC_EEM is not set
# CONFIG_USB_NET_CDC_NCM is not set
# CONFIG_USB_NET_CDC_MBIM is not set
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_SMSC75XX is not set
# CONFIG_USB_NET_SMSC95XX is not set
# CONFIG_USB_NET_GL620A is not set
# CONFIG_USB_NET_NET1080 is not set
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_CDC_SUBSET is not set
# CONFIG_USB_NET_ZAURUS is not set
# CONFIG_USB_NET_CX82310_ETH is not set
# CONFIG_USB_NET_KALMIA is not set
# CONFIG_USB_NET_QMI_WWAN is not set
# CONFIG_USB_NET_INT51X1 is not set
# CONFIG_USB_IPHETH is not set
# CONFIG_USB_SIERRA_NET is not set
# CONFIG_WLAN is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
# CONFIG_INPUT_KEYRESET is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYCHORD is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_GPIO is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_PWM_BEEPER is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
CONFIG_DEVPTS_MULTIPLE_INSTANCES=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
CONFIG_DEVKMEM=y
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_DCC_TTY is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
#
# I2C Hardware Bus support
#
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set
#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_PINCTRL=y
#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
# CONFIG_PINCTRL_SINGLE is not set
# CONFIG_PINCTRL_EXYNOS is not set
# CONFIG_PINCTRL_EXYNOS5440 is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set
#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set
#
# PCI GPIO expanders:
#
#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set
#
# AC97 GPIO expanders:
#
#
# MODULbus GPIO expanders:
#
#
# USB GPIO expanders:
#
CONFIG_W1=m
#
# 1-wire Bus Masters
#
# CONFIG_W1_MASTER_DS2490 is not set
# CONFIG_W1_MASTER_DS2482 is not set
# CONFIG_W1_MASTER_DS1WM is not set
CONFIG_W1_MASTER_GPIO=m
#
# 1-wire Slaves
#
# CONFIG_W1_SLAVE_THERM is not set
# CONFIG_W1_SLAVE_SMEM is not set
# CONFIG_W1_SLAVE_DS2408 is not set
# CONFIG_W1_SLAVE_DS2413 is not set
# CONFIG_W1_SLAVE_DS2423 is not set
# CONFIG_W1_SLAVE_DS2431 is not set
# CONFIG_W1_SLAVE_DS2433 is not set
# CONFIG_W1_SLAVE_DS2760 is not set
# CONFIG_W1_SLAVE_DS2780 is not set
# CONFIG_W1_SLAVE_DS2781 is not set
# CONFIG_W1_SLAVE_DS28E04 is not set
# CONFIG_W1_SLAVE_BQ27000 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_BATTERY_ANDROID is not set
# CONFIG_CHARGER_ISP1704 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_RESET_RESTART is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Native drivers
#
# CONFIG_SENSORS_AD7314 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7310 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_GPIO_FAN is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95234 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_ADS7871 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA209 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
# CONFIG_THERMAL_GOV_USER_SPACE is not set
CONFIG_CPU_THERMAL=y
CONFIG_CPUCORE_THERMAL=y
CONFIG_GPU_THERMAL=y
CONFIG_GPUCORE_THERMAL=y
# CONFIG_THERMAL_EMULATION is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
# CONFIG_REGULATOR_FIXED_VOLTAGE is not set
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS6524X is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_ION is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
CONFIG_HIDRAW=y
CONFIG_UHID=y
CONFIG_HID_GENERIC=y
#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTRIG is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_PS3REMOTE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set
#
# USB HID support
#
CONFIG_USB_HID=y
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set
#
# I2C HID support
#
# CONFIG_I2C_HID is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
# CONFIG_USB_ANNOUNCE_NEW_DEVICES is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_OTG_BLACKLIST_HUB is not set
# CONFIG_USB_MON is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_MUSB_HDRC is not set
# CONFIG_USB_RENESAS_USBHS is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set
#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
CONFIG_USB_PHY=y
# CONFIG_USB_OTG_WAKELOCK is not set
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_OMAP_CONTROL_USB is not set
# CONFIG_OMAP_USB3 is not set
# CONFIG_SAMSUNG_USBPHY is not set
# CONFIG_SAMSUNG_USB2PHY is not set
# CONFIG_SAMSUNG_USB3PHY is not set
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_RCAR_PHY is not set
# CONFIG_USB_ULPI is not set
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=2
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
#
# USB Peripheral Controller
#
# CONFIG_USB_FUSB300 is not set
# CONFIG_USB_R8A66597 is not set
# CONFIG_USB_PXA27X is not set
# CONFIG_USB_MV_UDC is not set
# CONFIG_USB_MV_U3D is not set
CONFIG_USB_GADGET_DWC_OTG=y
CONFIG_USB_DWC_OTG=y
# CONFIG_USB_M66592 is not set
# CONFIG_USB_NET2272 is not set
# CONFIG_USB_DUMMY_HCD is not set
# CONFIG_USB_ZERO is not set
# CONFIG_USB_ETH is not set
# CONFIG_USB_G_NCM is not set
# CONFIG_USB_GADGETFS is not set
# CONFIG_USB_FUNCTIONFS is not set
# CONFIG_USB_MASS_STORAGE is not set
# CONFIG_USB_G_SERIAL is not set
# CONFIG_USB_G_PRINTER is not set
# CONFIG_USB_CDC_COMPOSITE is not set
# CONFIG_USB_G_ACM_MS is not set
# CONFIG_USB_G_MULTI is not set
# CONFIG_USB_G_HID is not set
# CONFIG_USB_G_DBGP is not set
CONFIG_MMC=y
CONFIG_MMC_DEBUG=y
CONFIG_MMC_UNSAFE_RESUME=y
# CONFIG_MMC_CLKGATE is not set
# CONFIG_MMC_EMBEDDED_SDIO is not set
# CONFIG_MMC_PARANOID_SD_INIT is not set
#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=16
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_EMMC_SECURE_STORAGE is not set
# CONFIG_MMC_BLOCK_DEFERRED_RESUME is not set
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
#
# MMC/SD/SDIO Host Controller Drivers
#
# CONFIG_MMC_SDHCI is not set
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
# CONFIG_MMC_DW is not set
# CONFIG_MMC_VUB300 is not set
# CONFIG_MMC_USHC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
CONFIG_LEDS_GPIO=y
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_RENESAS_TPU is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_ONESHOT is not set
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_CPU is not set
# CONFIG_LEDS_TRIGGER_GPIO is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set
#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
# CONFIG_LEDS_TRIGGER_CAMERA is not set
CONFIG_SWITCH=y
# CONFIG_SWITCH_GPIO is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set
#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set
#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set
#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_SNVS is not set
#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
CONFIG_UIO=y
CONFIG_UIO_PDRV=y
CONFIG_UIO_PDRV_GENIRQ=y
# CONFIG_UIO_DMEM_GENIRQ is not set
# CONFIG_VIRT_DRIVERS is not set
#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
#
# Hardware Spinlock drivers
#
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_SUPPORT=y
CONFIG_OF_IOMMU=y
#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set
#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
CONFIG_PWM=y
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_DEBUG=y
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
# CONFIG_NFS_V2 is not set
CONFIG_NFS_V3=m
# CONFIG_NFS_V3_ACL is not set
CONFIG_NFS_V4=m
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set
#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_READABLE_ASM=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
CONFIG_IPIPE_DEBUG=y
CONFIG_IPIPE_DEBUG_CONTEXT=y
CONFIG_IPIPE_DEBUG_INTERNAL=y
# CONFIG_IPIPE_TRACE is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_HARDLOCKUP_DETECTOR_OTHER_CPU=y
CONFIG_HARDLOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC=y
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=1
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_STACKTRACE is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU_DELAY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_VERBOSE=y
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_LKDTM is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
# CONFIG_DEBUG_RODATA is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_NONE=y
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
CONFIG_EARLY_PRINTK=y
# CONFIG_PID_IN_CONTEXTIDR is not set
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set
#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set
#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set
#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
# CONFIG_BINARY_PRINTF is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_AUDIT_GENERIC=y
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
# CONFIG_XZ_DEC_X86 is not set
# CONFIG_XZ_DEC_POWERPC is not set
# CONFIG_XZ_DEC_IA64 is not set
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
# CONFIG_XZ_DEC_BCJ is not set
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_OID_REGISTRY=m
# CONFIG_VIRTUALIZATION is not set
-------------- next part --------------
Booting Linux on physical CPU 0x200
Initializing cgroup subsys cpu
Linux version 3.10.33-mmc+ (gemi@mba) (gcc version 4.7.2 (Debian 4.7.2-5) ) #71 SMP PREEMPT Wed Mar 18 19:29:24 SGT 2015
CPU: ARMv7 Processor [410fc051] revision 1 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine: ODROIDC, model: AMLOGIC
physical memory start address is 0x200000
reserved_end is d9fffff
Total memory is 1022 MiB
Reserved low memory from 0x06000000 to 0x0d9fffff, size: 122 MiB
mesonfb0(low) : 0x06100000 - 0x07900000 ( 24 MiB)
mesonfb1(low) : 0x07900000 - 0x07a00000 ( 1 MiB)
mesonstream0(low) : 0x07a00000 - 0x09a00000 ( 32 MiB)
vdec0(low) : 0x09a00000 - 0x0da00000 ( 64 MiB)
[ 0.000000@0] Booting Linux on physical CPU 0x200
[ 0.000000@0] Initializing cgroup subsys cpu
[ 0.000000@0] Linux version 3.10.33-mmc+ (gemi@mba) (gcc version 4.7.2 (Debian 4.7.2-5) ) #71 SMP PREEMPT Wed Mar 18 19:29:24 SGT 2015
[ 0.000000@0] Machine: ODROIDC, model: AMLOGIC
[ 0.000000@0] reserved_end is d9fffff
[ 0.000000@0]
[ 0.000000@0] Total memory is 1022 MiB
[ 0.000000@0] Reserved low memory from 0x06000000 to 0x0d9fffff, size: 122 MiB
[ 0.000000@0] mesonfb0(low) : 0x06100000 - 0x07900000 ( 24 MiB)
[ 0.000000@0] mesonfb1(low) : 0x07900000 - 0x07a00000 ( 1 MiB)
[ 0.000000@0] mesonstream0(low) : 0x07a00000 - 0x09a00000 ( 32 MiB)
[ 0.000000@0] vdec0(low) : 0x09a00000 - 0x0da00000 ( 64 MiB)
bootconsole [earlycon0] enabled
[ 0.000000@0] bootconsole [earlycon0] enabled
cma: CMA: reserved 8 MiB at 2f000000
[ 0.000000@0] cma: CMA: reserved 8 MiB at 2f000000
Memory policy: ECC disabled, Data cache writealloc
On node 0 totalpages: 226816
free_area_init_node: node 0, pgdat c05a3280, node_mem_map c0709000
Normal zone: 1520 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 159744 pages, LIFO batch:31
HighMem zone: 524 pages used for memmap
HighMem zone: 67072 pages, LIFO batch:15
Meson chip version = RevA (1B:A - 0:B72)
[ 0.000000@0] Meson chip version = RevA (1B:A - 0:B72)
PERCPU: Embedded 10 pages/cpu @c0f12000 s18688 r8192 d14080 u40960
[ 0.000000@0] PERCPU: Embedded 10 pages/cpu @c0f12000 s18688 r8192 d14080 u40960
pcpu-alloc: s18688 r8192 d14080 u40960 alloc=10*4096
pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 225296
Kernel command line: earlyprintk dwc_otg.speed=1 console=tty0 root=/dev/mmcblk0p1 rootwait rw no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=1024x768p60hz m_bpp=16 vout=hdmi disableuhs disablehpd=true
[ 0.000000@0] Kernel command line: earlyprintk dwc_otg.speed=1 console=tty0 root=/dev/mmcblk0p1 rootwait rw no_console_suspend vdaccfg=0xa000 logo=osd1,loaded,0x7900000,720p,full dmfc=3 cvbsmode=576cvbs hdmimode=1024x768p60hz m_bpp=16 vout=hdmi disableuhs disablehpd=true
PID hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000@0] PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 0.000000@0] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000@0] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 0.000000@0] Unable to handle kernel NULL pointer dereference at virtual address 00000004
pgd = c0004000
[ 0.000000@0] pgd = c0004000
[00000004] *pgd=00000000[ 0.000000@0] [00000004] *pgd=00000000
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[ 0.000000@0] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Modules linked in:[ 0.000000@0] Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.33-mmc+ #71
[ 0.000000@0] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.33-mmc+ #71
task: c05845f8 ti: c056e000 task.ti: c056e000
[ 0.000000@0] task: c05845f8 ti: c056e000 task.ti: c056e000
PC is at free_hot_cold_page+0x104/0x16c
[ 0.000000@0] PC is at free_hot_cold_page+0x104/0x16c
LR is at ipipe_test_and_stall_root+0x14/0x88
[ 0.000000@0] LR is at ipipe_test_and_stall_root+0x14/0x88
pc : [<c0131ab4>] lr : [<c0016550>] psr: 600001d3
sp : c056fec8 ip : 00000001 fp : c06f3d80
[ 0.000000@0] pc : [<c0131ab4>] lr : [<c0016550>] psr: 600001d3
[ 0.000000@0] sp : c056fec8 ip : 00000001 fp : c06f3d80
r10: 00000080 r9 : c05a3280 r8 : c056ae00
[ 0.000000@0] r10: 00000080 r9 : c05a3280 r8 : c056ae00
r7 : 00000000 r6 : c056ae18 r5 : c056ae00 r4 : c0728fe0
[ 0.000000@0] r7 : 00000000 r6 : c056ae18 r5 : c056ae00 r4 : c0728fe0
r3 : c0728ff4 r2 : 00000000 r1 : c056ae1c r0 : 00000000
[ 0.000000@0] r3 : c0728ff4 r2 : 00000000 r1 : c056ae1c r0 : 00000000
Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
[ 0.000000@0] Flags: nZCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel
Control: 10c5387d Table: 0020404a DAC: 00000015
[ 0.000000@0] Control: 10c5387d Table: 0020404a DAC: 00000015
PC: 0xc0131a34:
[ 0.000000@0]
[ 0.000000@0] PC: 0xc0131a34:
1a34 [ 0.000000@0] 1a34 0a000002 0a000002 e3560004 e3560004 13a06002 13a06002 1a000005 1a000005 e1a00009 e1a00009 e1a01004 e1a01004 e3a02000 e3a02000 e1a03006 e1a03006
1a54 [ 0.000000@0] 1a54 ebfffee2 ebfffee2 ea000027 ea000027 e5995020 e5995020 ee103fb0 ee103fb0 e6ef3073 e6ef3073 e3570000 e3570000 e7913103 e7913103 e7927103 e7927103
1a74 [ 0.000000@0] 1a74 e0858007 e0858007 0a000008 0a000008 e0886186 e0886186 e2842014 e2842014 e5963010 e5963010 e5862010 e5862010 e286600c e286600c e5846014 e5846014
1a94 [ 0.000000@0] 1a94 e5843018 e5843018 e5832000 e5832000 ea000008 ea000008 e2866001 e2866001 e2843014 e2843014 e0886186 e0886186 e2861004 e2861004 e5962004 e5962004
1ab4 [ 0.000000@0] 1ab4 e5823004 e5823004 e5842014 e5842014 e5841018 e5841018 e5863004 e5863004 e7953007 e7953007 e2833001 e2833001 e7853007 e7853007 e5982004 e5982004
1ad4 [ 0.000000@0] 1ad4 e1530002 e1530002 ba000007 ba000007 e1a02008 e1a02008 e1a00009 e1a00009 e5981008 e5981008 ebfffae5 ebfffae5 e7952007 e7952007 e5983008 e5983008
1af4 [ 0.000000@0] 1af4 e0633002 e0633002 e7853007 e7853007 e31a0080 e31a0080 18bd87f0 18bd87f0 e8bd47f0 e8bd47f0 eafd5f36 eafd5f36 c05a3280 c05a3280 c056b09c c056b09c
1b14 [ 0.000000@0] 1b14 c05855a0 c05855a0 c05827e0 c05827e0 e92d0030 e92d0030 e2802010 e2802010 e1a04001 e1a04001 f57ff05f f57ff05f e192cf9f e192cf9f e24cc001 e24cc001
LR: 0xc00164d0:
[ 0.000000@0]
[ 0.000000@0] LR: 0xc00164d0:
64d0 [ 0.000000@0] 64d0 e1952f9f e1952f9f e3320000 e3320000 1320f002 1320f002 01852f93 01852f93 e3320000 e3320000 1afffff9 1afffff9 f57ff05f f57ff05f e59f2040 e59f2040
64f0 [ 0.000000@0] 64f0 e3a03000 e3a03000 e5823004 e5823004 f57ff05f f57ff05f e5853000 e5853000 f57ff04f f57ff04f e320f004 e320f004 e1a00002 e1a00002 e59d1000 e59d1000
6510 [ 0.000000@0] 6510 eb01c45e eb01c45e ea000003 ea000003 e59d300c e59d300c e313000f e313000f 1afffffc 1afffffc eaffffe8 eaffffe8 e28dd014 e28dd014 e8bd8030 e8bd8030
6530 [ 0.000000@0] 6530 c05a4518 c05a4518 c0570000 c0570000 c05855a0 c05855a0 e92d4070 e92d4070 eb01c545 eb01c545 e10f5000 e10f5000 f10c0080 f10c0080 eb01c32b eb01c32b
6550 [ 0.000000@0] 6550 e59f4058 e59f4058 e3500000 e3500000 0a000008 0a000008 e59f6050 e59f6050 e5d63000 e5d63000 e3530000 e3530000 1a000004 1a000004 e59f0044 e59f0044
6570 [ 0.000000@0] 6570 e3a010a7 e3a010a7 eb003d9d eb003d9d e3a03001 e3a03001 e5c63000 e5c63000 ee102fb0 ee102fb0 e59f3030 e59f3030 e6ef2072 e6ef2072 e7932102 e7932102
6590 [ 0.000000@0] 6590 e59f3028 e59f3028 e7933102 e7933102 e7940003 e7940003 e3802001 e3802001 e7842003 e7842003 e121f005 e121f005 e2000001 e2000001 e8bd8070 e8bd8070
65b0 [ 0.000000@0] 65b0 c0568a2c c0568a2c c05a3fd7 c05a3fd7 c04a3690 c04a3690 c05855a0 c05855a0 c05827e0 c05827e0 e92d4070 e92d4070 eb01c523 eb01c523 e10f5000 e10f5000
SP: 0xc056fe48:
[ 0.000000@0]
[ 0.000000@0] SP: 0xc056fe48:
fe48 [ 0.000000@0] fe48 c05855a0 c05855a0 c06aad00 c06aad00 c06aad00 c06aad00 c0087ad0 c0087ad0 c056ad6c c056ad6c c05827e0 c05827e0 c0131ab4 c0131ab4 600001d3 600001d3
fe68 [ 0.000000@0] fe68 ffffffff ffffffff c056feb4 c056feb4 c056ae00 c056ae00 c05a3280 c05a3280 00000080 00000080 c000e518 c000e518 00000000 00000000 c056ae1c c056ae1c
fe88 [ 0.000000@0] fe88 00000000 00000000 c0728ff4 c0728ff4 c0728fe0 c0728fe0 c056ae00 c056ae00 c056ae18 c056ae18 00000000 00000000 c056ae00 c056ae00 c05a3280 c05a3280
fea8 [ 0.000000@0] fea8 00000080 00000080 c06f3d80 c06f3d80 00000001 00000001 c056fec8 c056fec8 c0016550 c0016550 c0131ab4 c0131ab4 600001d3 600001d3 ffffffff ffffffff
fec8 [ 0.000000@0] fec8 c0565d38 c0565d38 00000001 00000001 00000000 00000000 00001200 00001200 0001ffe0 0001ffe0 0002fa00 0002fa00 00001200 00001200 c0540a1c c0540a1c
fee8 [ 0.000000@0] fee8 c056ad6c c056ad6c c05827e0 c05827e0 00000000 00000000 c0565d54 c0565d54 00000000 00000000 c0565d38 c0565d38 c058e1b0 c058e1b0 0020406a 0020406a
ff08 [ 0.000000@0] ff08 410fc051 410fc051 00000000 00000000 00000000 00000000 c0540c30 c0540c30 c056e000 c056e000 c0562cd4 c0562cd4 c06f3d80 c06f3d80 c05368fc c05368fc
ff28 [ 0.000000@0] ff28 c04b0f7c c04b0f7c c056ff5c c056ff5c 00040000 00040000 c03ec344 c03ec344 00000040 00000040 c056ff5c c056ff5c 00000000 00000000 00000001 00000001
FP: 0xc06f3d00:
[ 0.000000@0]
[ 0.000000@0] FP: 0xc06f3d00:
3d00 [ 0.000000@0] 3d00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d20 [ 0.000000@0] 3d20 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d40 [ 0.000000@0] 3d40 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d60 [ 0.000000@0] 3d60 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3d80 [ 0.000000@0] 3d80 c0709000 c0709000 00000000 00000000 00000000 00000000 00000000 00000000 ef800000 ef800000 00000000 00000000 0003fe00 0003fe00 00000000 00000000
3da0 [ 0.000000@0] 3da0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3dc0 [ 0.000000@0] 3dc0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3de0 [ 0.000000@0] 3de0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
R1: 0xc056ad9c:
[ 0.000000@0]
[ 0.000000@0] R1: 0xc056ad9c:
ad9c [ 0.000000@0] ad9c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff ffffffff
adbc [ 0.000000@0] adbc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
addc [ 0.000000@0] addc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
adfc [ 0.000000@0] adfc 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae1c [ 0.000000@0] ae1c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae3c [ 0.000000@0] ae3c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae5c [ 0.000000@0] ae5c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae7c [ 0.000000@0] ae7c 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
R3: 0xc0728f74:
[ 0.000000@0]
[ 0.000000@0] R3: 0xc0728f74:
8f74 [ 0.000000@0] 8f74 c0728f74 c0728f74 c0728f74 c0728f74 00000000 00000000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001
8f94 [ 0.000000@0] 8f94 c0728f94 c0728f94 c0728f94 c0728f94 00000000 00000000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001
8fb4 [ 0.000000@0] 8fb4 c0728fb4 c0728fb4 c0728fb4 c0728fb4 00000000 00000000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001
8fd4 [ 0.000000@0] 8fd4 c0728fd4 c0728fd4 c0728fd4 c0728fd4 00000000 00000000 00000000 00000000 00000000 00000000 00000002 00000002 ffffffff ffffffff 00000000 00000000
8ff4 [ 0.000000@0] 8ff4 c0728ff4 c0728ff4 c0728ff4 c0728ff4 00000000 00000000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001
9014 [ 0.000000@0] 9014 c0729014 c0729014 c0729014 c0729014 00000000 00000000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001
9034 [ 0.000000@0] 9034 c0729034 c0729034 c0729034 c0729034 00000000 00000000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001
9054 [ 0.000000@0] 9054 c0729054 c0729054 c0729054 c0729054 00000000 00000000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001
R4: 0xc0728f60:
[ 0.000000@0]
[ 0.000000@0] R4: 0xc0728f60:
8f60 [ 0.000000@0] 8f60 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001 c0728f74 c0728f74 c0728f74 c0728f74 00000000 00000000
8f80 [ 0.000000@0] 8f80 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001 c0728f94 c0728f94 c0728f94 c0728f94 00000000 00000000
8fa0 [ 0.000000@0] 8fa0 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001 c0728fb4 c0728fb4 c0728fb4 c0728fb4 00000000 00000000
8fc0 [ 0.000000@0] 8fc0 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001 c0728fd4 c0728fd4 c0728fd4 c0728fd4 00000000 00000000
8fe0 [ 0.000000@0] 8fe0 00000000 00000000 00000000 00000000 00000002 00000002 ffffffff ffffffff 00000000 00000000 c0728ff4 c0728ff4 c0728ff4 c0728ff4 00000000 00000000
9000 [ 0.000000@0] 9000 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001 c0729014 c0729014 c0729014 c0729014 00000000 00000000
9020 [ 0.000000@0] 9020 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001 c0729034 c0729034 c0729034 c0729034 00000000 00000000
9040 [ 0.000000@0] 9040 00000400 00000400 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000001 00000001 c0729054 c0729054 c0729054 c0729054 00000000 00000000
R5: 0xc056ad80:
[ 0.000000@0]
[ 0.000000@0] R5: 0xc056ad80:
ad80 [ 0.000000@0] ad80 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ada0 [ 0.000000@0] ada0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000000 00000000
adc0 [ 0.000000@0] adc0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ade0 [ 0.000000@0] ade0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae00 [ 0.000000@0] ae00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae20 [ 0.000000@0] ae20 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae40 [ 0.000000@0] ae40 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae60 [ 0.000000@0] ae60 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
R6: 0xc056ad98:
[ 0.000000@0]
[ 0.000000@0] R6: 0xc056ad98:
ad98 [ 0.000000@0] ad98 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
adb8 [ 0.000000@0] adb8 ffffffff ffffffff 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
add8 [ 0.000000@0] add8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
adf8 [ 0.000000@0] adf8 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae18 [ 0.000000@0] ae18 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae38 [ 0.000000@0] ae38 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae58 [ 0.000000@0] ae58 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae78 [ 0.000000@0] ae78 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
R8: 0xc056ad80:
[ 0.000000@0]
[ 0.000000@0] R8: 0xc056ad80:
ad80 [ 0.000000@0] ad80 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ada0 [ 0.000000@0] ada0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000000 00000000
adc0 [ 0.000000@0] adc0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ade0 [ 0.000000@0] ade0 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae00 [ 0.000000@0] ae00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae20 [ 0.000000@0] ae20 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae40 [ 0.000000@0] ae40 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
ae60 [ 0.000000@0] ae60 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
R9: 0xc05a3200:
[ 0.000000@0]
[ 0.000000@0] R9: 0xc05a3200:
3200 [ 0.000000@0] 3200 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c03e6000 c03e6000
3220 [ 0.000000@0] 3220 c03e6044 c03e6044 00000000 00000000 00000000 00000000 c03e60e0 c03e60e0 c03e60d8 c03e60d8 00000000 00000000 00000000 00000000 00000000 00000000
3240 [ 0.000000@0] 3240 c05a3240 c05a3240 c05a3240 c05a3240 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3260 [ 0.000000@0] 3260 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
3280 [ 0.000000@0] 3280 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
32a0 [ 0.000000@0] 32a0 c056ae00 c056ae00 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 c05a32b8 c05a32b8 c05a32b8 c05a32b8
32c0 [ 0.000000@0] 32c0 c05a32c0 c05a32c0 c05a32c0 c05a32c0 c05a32c8 c05a32c8 c05a32c8 c05a32c8 c05a32d0 c05a32d0 c05a32d0 c05a32d0 c05a32d8 c05a32d8 c05a32d8 c05a32d8
32e0 [ 0.000000@0] 32e0 c05a32e0 c05a32e0 c05a32e0 c05a32e0 00000000 00000000 00000000 00000000 c05a32f0 c05a32f0 c05a32f0 c05a32f0 c05a32f8 c05a32f8 c05a32f8 c05a32f8
Process swapper (pid: 0, stack limit = 0xc056e238)
[ 0.000000@0] Process swapper (pid: 0, stack limit = 0xc056e238)
Stack: (0xc056fec8 to 0xc0570000)
[ 0.000000@0] Stack: (0xc056fec8 to 0xc0570000)
fec0: c0565d38 00000001 00000000 00001200 0001ffe0 0002fa00
[ 0.000000@0] fec0: c0565d38 00000001 00000000 00001200 0001ffe0 0002fa00
fee0: 00001200 c0540a1c c056ad6c c05827e0 00000000 c0565d54 00000000 c0565d38
[ 0.000000@0] fee0: 00001200 c0540a1c c056ad6c c05827e0 00000000 c0565d54 00000000 c0565d38
ff00: c058e1b0 0020406a 410fc051 00000000 00000000 c0540c30 c056e000 c0562cd4
[ 0.000000@0] ff00: c058e1b0 0020406a 410fc051 00000000 00000000 c0540c30 c056e000 c0562cd4
ff20: c06f3d80 c05368fc c04b0f7c c056ff5c 00040000 c03ec344 00000040 c056ff5c
[ 0.000000@0] ff20: c06f3d80 c05368fc c04b0f7c c056ff5c 00040000 c03ec344 00000040 c056ff5c
ff40: 00000000 00000001 c06bacc0 600001d3 00000408 0000040b c05a44e0 c00874f8
[ 0.000000@0] ff40: 00000000 00000001 c06bacc0 600001d3 00000408 0000040b c05a44e0 c00874f8
ff60: 0000040b 600001d3 00000408 c0088170 c06bacc0 000001d3 c0568a28 c06aad00
[ 0.000000@0] ff60: 0000040b 600001d3 00000408 c0088170 c06bacc0 000001d3 c0568a28 c06aad00
ff80: c06bacc0 c00874f8 0000040d 000001d3 c0568a28 c0088170 c06bb040 c0582534
[ 0.000000@0] ff80: c06bacc0 c00874f8 0000040d 000001d3 c0568a28 c0088170 c06bb040 c0582534
ffa0: c056c080 c056e000 c0562cd4 c05a41c0 c0f0fb80 0020406a 410fc051 00000000
[ 0.000000@0] ffa0: c056c080 c056e000 c0562cd4 c05a41c0 c0f0fb80 0020406a 410fc051 00000000
ffc0: 00000000 c05328d0 ffffffff ffffffff c0532494 00000000 00000000 c0562cd4
[ 0.000000@0] ffc0: 00000000 c05328d0 ffffffff ffffffff c0532494 00000000 00000000 c0562cd4
ffe0: 00000000 10c5387d c05824f4 c0562cd0 c0585484 00208070 00000000 00000000
[ 0.000000@0] ffe0: 00000000 10c5387d c05824f4 c0562cd0 c0585484 00208070 00000000 00000000
[<c0131ab4>] (free_hot_cold_page+0x104/0x16c) from [<c0540a1c>] (free_all_bootmem_core+0x108/0x1e0)
[ 0.000000@0] [<c0131ab4>] (free_hot_cold_page+0x104/0x16c) from [<c0540a1c>] (free_all_bootmem_core+0x108/0x1e0)
[<c0540a1c>] (free_all_bootmem_core+0x108/0x1e0) from [<c0540c30>] (free_all_bootmem+0x60/0x84)
[ 0.000000@0] [<c0540a1c>] (free_all_bootmem_core+0x108/0x1e0) from [<c0540c30>] (free_all_bootmem+0x60/0x84)
[<c0540c30>] (free_all_bootmem+0x60/0x84) from [<c05368fc>] (mem_init+0x28/0x4c4)
[ 0.000000@0] [<c0540c30>] (free_all_bootmem+0x60/0x84) from [<c05368fc>] (mem_init+0x28/0x4c4)
[<c05368fc>] (mem_init+0x28/0x4c4) from [<c05328d0>] (start_kernel+0x158/0x324)
[ 0.000000@0] [<c05368fc>] (mem_init+0x28/0x4c4) from [<c05328d0>] (start_kernel+0x158/0x324)
[<c05328d0>] (start_kernel+0x158/0x324) from [<00208070>] (0x208070)
[ 0.000000@0] [<c05328d0>] (start_kernel+0x158/0x324) from [<00208070>] (0x208070)
Code: e2843014 e0886186 e2861004 e5962004 (e5823004)
[ 0.000000@0] Code: e2843014 e0886186 e2861004 e5962004 (e5823004)
---[ end trace 1b75b31a2719ed1c ]---
[ 0.000000@0] ---[ end trace 1b75b31a2719ed1c ]---
Kernel panic - not syncing: Attempted to kill the idle task!
[ 0.000000@0] Kernel panic - not syncing: Attempted to kill the idle task!
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-18 14:11 [Xenomai] Boot failure when CONFIG_XENOMAI is enabled GP Orcullo
@ 2015-03-18 14:21 ` Gilles Chanteperdrix
2015-03-18 14:48 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-18 14:21 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
> Hi,
>
> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
> 3.10.33 non-mainlined kernel.
>
> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
> Once CONFIG_XENOMAI is set, the boot fails.
>
> Attached are the .config and the bootlog files. Turning
> CONFIG_SMP_ON_UP off gives a different result.
>
> Any pointers on where to start looking?
here:
https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
Your diagnostic is not consistent with the kernel messages: the only
difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
xenomai starts, however your kernel crashes before xenomai starts.
Your problem is probably, as usual, in the timer handling code, or
tsc emulation.
Other than that, I would disable the usually not recommended kernel
options.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-18 14:21 ` Gilles Chanteperdrix
@ 2015-03-18 14:48 ` GP Orcullo
2015-03-18 14:56 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-18 14:48 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Wed, Mar 18, 2015 at 10:21 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
>> Hi,
>>
>> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
>> 3.10.33 non-mainlined kernel.
>>
>> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
>> Once CONFIG_XENOMAI is set, the boot fails.
>>
>> Attached are the .config and the bootlog files. Turning
>> CONFIG_SMP_ON_UP off gives a different result.
>>
>> Any pointers on where to start looking?
>
> here:
> https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
>
> Your diagnostic is not consistent with the kernel messages: the only
> difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
> xenomai starts, however your kernel crashes before xenomai starts.
>
> Your problem is probably, as usual, in the timer handling code, or
> tsc emulation.
>
> Other than that, I would disable the usually not recommended kernel
> options.
>
> --
> Gilles.
I think there's a problem with the vendor supplied kernel source.
On the xenomai patched kernel, disabling CONFIG_IPIPE and enabling
CONFIG_SMP_ON_UP gives the following error during compilation:
In file included from arch/arm/include/generated/asm/irq_regs.h:1:0,
from include/linux/irq.h:26,
from include/linux/ipipe.h:28,
from include/linux/sched.h:25,
from arch/arm/kernel/asm-offsets.c:13:
include/asm-generic/irq_regs.h: In function ‘get_irq_regs’:
include/asm-generic/irq_regs.h:25:2: error: implicit declaration of
function ‘ipipe_processor_id’ [-Werror=implicit-function-declaration]
I traced the error to this file:
http://git.xenomai.org/ipipe-gch.git/tree/arch/arm/include/asm/percpu.h?h=for-ipipe-3.10
Porting the changes from for-ipipe-3.14 allowed the compilation to
proceed - but the resulting kernel is still broken.
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-18 14:48 ` GP Orcullo
@ 2015-03-18 14:56 ` Gilles Chanteperdrix
2015-03-25 14:48 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-18 14:56 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Wed, Mar 18, 2015 at 10:48:10PM +0800, GP Orcullo wrote:
> On Wed, Mar 18, 2015 at 10:21 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
> >> Hi,
> >>
> >> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
> >> 3.10.33 non-mainlined kernel.
> >>
> >> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
> >> Once CONFIG_XENOMAI is set, the boot fails.
> >>
> >> Attached are the .config and the bootlog files. Turning
> >> CONFIG_SMP_ON_UP off gives a different result.
> >>
> >> Any pointers on where to start looking?
> >
> > here:
> > https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
> >
> > Your diagnostic is not consistent with the kernel messages: the only
> > difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
> > xenomai starts, however your kernel crashes before xenomai starts.
> >
> > Your problem is probably, as usual, in the timer handling code, or
> > tsc emulation.
> >
> > Other than that, I would disable the usually not recommended kernel
> > options.
> >
> > --
> > Gilles.
>
> I think there's a problem with the vendor supplied kernel source.
>
> On the xenomai patched kernel, disabling CONFIG_IPIPE and enabling
> CONFIG_SMP_ON_UP gives the following error during compilation:
>
> In file included from arch/arm/include/generated/asm/irq_regs.h:1:0,
> from include/linux/irq.h:26,
> from include/linux/ipipe.h:28,
> from include/linux/sched.h:25,
> from arch/arm/kernel/asm-offsets.c:13:
> include/asm-generic/irq_regs.h: In function ‘get_irq_regs’:
> include/asm-generic/irq_regs.h:25:2: error: implicit declaration of
> function ‘ipipe_processor_id’ [-Werror=implicit-function-declaration]
>
> I traced the error to this file:
> http://git.xenomai.org/ipipe-gch.git/tree/arch/arm/include/asm/percpu.h?h=for-ipipe-3.10
That is very much likely a bug in the I-pipe patch itself, a case we
did not handle (CONFIG_SMP_ON_UP and !CONFIG_IPIPE), nothing very
serious, and probably unrelated to the issues you have.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-18 14:56 ` Gilles Chanteperdrix
@ 2015-03-25 14:48 ` GP Orcullo
2015-03-25 14:57 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-25 14:48 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Wed, Mar 18, 2015 at 10:56 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Wed, Mar 18, 2015 at 10:48:10PM +0800, GP Orcullo wrote:
>> On Wed, Mar 18, 2015 at 10:21 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>> > On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
>> >> Hi,
>> >>
>> >> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
>> >> 3.10.33 non-mainlined kernel.
>> >>
>> >> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
>> >> Once CONFIG_XENOMAI is set, the boot fails.
>> >>
>> >> Attached are the .config and the bootlog files. Turning
>> >> CONFIG_SMP_ON_UP off gives a different result.
>> >>
>> >> Any pointers on where to start looking?
>> >
>> > here:
>> > https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
>> >
>> > Your diagnostic is not consistent with the kernel messages: the only
>> > difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
>> > xenomai starts, however your kernel crashes before xenomai starts.
>> >
>> > Your problem is probably, as usual, in the timer handling code, or
>> > tsc emulation.
>> >
>> > Other than that, I would disable the usually not recommended kernel
>> > options.
>> >
>> > --
>> > Gilles.
>>
>> I think there's a problem with the vendor supplied kernel source.
>>
>> On the xenomai patched kernel, disabling CONFIG_IPIPE and enabling
>> CONFIG_SMP_ON_UP gives the following error during compilation:
>>
>> In file included from arch/arm/include/generated/asm/irq_regs.h:1:0,
>> from include/linux/irq.h:26,
>> from include/linux/ipipe.h:28,
>> from include/linux/sched.h:25,
>> from arch/arm/kernel/asm-offsets.c:13:
>> include/asm-generic/irq_regs.h: In function ‘get_irq_regs’:
>> include/asm-generic/irq_regs.h:25:2: error: implicit declaration of
>> function ‘ipipe_processor_id’ [-Werror=implicit-function-declaration]
>>
>> I traced the error to this file:
>> http://git.xenomai.org/ipipe-gch.git/tree/arch/arm/include/asm/percpu.h?h=for-ipipe-3.10
>
> That is very much likely a bug in the I-pipe patch itself, a case we
> did not handle (CONFIG_SMP_ON_UP and !CONFIG_IPIPE), nothing very
> serious, and probably unrelated to the issues you have.
>
> --
> Gilles.
I've stripped the kernel to its bare minimum and I was able to boot
xenomai on a single cpu and pass the xeno-regression-test with no
problems.
Once CONFIG_SMP is enabled, the boot is stuck at "Switching to
clocksource ipipe_tsc". There are no additional messages after that.
This processor has no per-cpu local timers; it has eight timers total
and I've allocated four timers for ipipe use. Sharing timers with
Linux gives the same results.
Any hints?
--
GP Orcullo
-------------- next part --------------
#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.10.33 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_IPIPE_WANT_ACTIVE_MM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_FIQ=y
CONFIG_VECTORS_BASE=0xffff0000
# CONFIG_ARM_PATCH_PHYS_VIRT is not set
CONFIG_NEED_MACH_MEMORY_H=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
CONFIG_LOCALVERSION="-mmc"
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_FHANDLE=y
CONFIG_HAVE_GENERIC_HARDIRQS=y
#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_HZ_PERIODIC=y
# CONFIG_NO_HZ_IDLE is not set
# CONFIG_NO_HZ is not set
CONFIG_HIGH_RES_TIMERS=y
#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=19
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
CONFIG_CGROUP_DEVICE=y
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_UIDGID_CONVERTED=y
CONFIG_UIDGID_STRICT_TYPE_CHECKS=y
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="rootfs.cpio"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_INITRAMFS_COMPRESSION_NONE=y
# CONFIG_INITRAMFS_COMPRESSION_GZIP is not set
# CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set
# CONFIG_INITRAMFS_COMPRESSION_LZMA is not set
# CONFIG_INITRAMFS_COMPRESSION_XZ is not set
# CONFIG_INITRAMFS_COMPRESSION_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_HOTPLUG=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_EMBEDDED=y
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y
#
# Kernel Performance Events And Counters
#
# CONFIG_PERF_EVENTS is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
CONFIG_COMPAT_BRK=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y
#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
# CONFIG_MODULES is not set
CONFIG_STOP_MACHINE=y
# CONFIG_BLOCK is not set
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
#
# Real-time sub-system
#
CONFIG_XENOMAI=y
CONFIG_XENO_GENERIC_STACKPOOL=y
CONFIG_XENO_FASTSYNCH_DEP=y
CONFIG_XENO_FASTSYNCH=y
CONFIG_XENO_OPT_NUCLEUS=y
CONFIG_XENO_OPT_PERVASIVE=y
# CONFIG_XENO_OPT_PRIOCPL is not set
CONFIG_XENO_OPT_PIPELINE_HEAD=y
# CONFIG_XENO_OPT_SCHED_CLASSES is not set
CONFIG_XENO_OPT_PIPE=y
CONFIG_XENO_OPT_MAP=y
CONFIG_XENO_OPT_VFILE=y
CONFIG_XENO_OPT_PIPE_NRDEV=32
CONFIG_XENO_OPT_REGISTRY_NRSLOTS=512
CONFIG_XENO_OPT_SYS_HEAPSZ=256
CONFIG_XENO_OPT_SYS_STACKPOOLSZ=128
CONFIG_XENO_OPT_SEM_HEAPSZ=12
CONFIG_XENO_OPT_GLOBAL_SEM_HEAPSZ=12
CONFIG_XENO_OPT_STATS=y
CONFIG_XENO_OPT_DEBUG=y
CONFIG_XENO_OPT_DEBUG_NUCLEUS=y
CONFIG_XENO_OPT_DEBUG_XNLOCK=y
CONFIG_XENO_OPT_DEBUG_QUEUES=y
CONFIG_XENO_OPT_DEBUG_REGISTRY=y
CONFIG_XENO_OPT_DEBUG_TIMERS=y
CONFIG_XENO_OPT_DEBUG_SYNCH_RELAX=y
CONFIG_XENO_OPT_WATCHDOG=y
CONFIG_XENO_OPT_WATCHDOG_TIMEOUT=4
# CONFIG_XENO_OPT_SHIRQ is not set
CONFIG_XENO_OPT_SELECT=y
CONFIG_XENO_OPT_HOSTRT=y
#
# Timing
#
# CONFIG_XENO_OPT_TIMING_PERIODIC is not set
CONFIG_XENO_OPT_TIMING_VIRTICK=1000
CONFIG_XENO_OPT_TIMING_SCHEDLAT=0
#
# Scalability
#
# CONFIG_XENO_OPT_SCALABLE_SCHED is not set
CONFIG_XENO_OPT_TIMER_LIST=y
# CONFIG_XENO_OPT_TIMER_HEAP is not set
# CONFIG_XENO_OPT_TIMER_WHEEL is not set
#
# Machine
#
CONFIG_IPIPE_WANT_PREEMPTIBLE_SWITCH=y
CONFIG_XENO_HW_FPU=y
CONFIG_XENO_HW_UNLOCKED_SWITCH=y
#
# Interfaces
#
CONFIG_XENO_SKIN_NATIVE=y
CONFIG_XENO_OPT_NATIVE_PERIOD=0
CONFIG_XENO_OPT_NATIVE_PIPE=y
CONFIG_XENO_OPT_NATIVE_PIPE_BUFSZ=1024
CONFIG_XENO_OPT_NATIVE_SEM=y
CONFIG_XENO_OPT_NATIVE_EVENT=y
CONFIG_XENO_OPT_NATIVE_MUTEX=y
CONFIG_XENO_OPT_NATIVE_COND=y
CONFIG_XENO_OPT_NATIVE_QUEUE=y
CONFIG_XENO_OPT_NATIVE_BUFFER=y
CONFIG_XENO_OPT_NATIVE_HEAP=y
CONFIG_XENO_OPT_NATIVE_ALARM=y
CONFIG_XENO_OPT_NATIVE_MPS=y
# CONFIG_XENO_OPT_NATIVE_INTR is not set
CONFIG_XENO_OPT_DEBUG_NATIVE=y
CONFIG_XENO_SKIN_POSIX=y
CONFIG_XENO_OPT_POSIX_PERIOD=0
CONFIG_XENO_OPT_POSIX_REGISTRY_NRSLOTS=64
CONFIG_XENO_OPT_POSIX_REGISTRY_NRDESCS=128
CONFIG_XENO_OPT_POSIX_NRTIMERS=128
# CONFIG_XENO_OPT_POSIX_SHM is not set
# CONFIG_XENO_OPT_POSIX_INTR is not set
CONFIG_XENO_OPT_POSIX_SELECT=y
CONFIG_XENO_OPT_DEBUG_POSIX=y
# CONFIG_XENO_SKIN_PSOS is not set
# CONFIG_XENO_SKIN_UITRON is not set
# CONFIG_XENO_SKIN_VRTX is not set
# CONFIG_XENO_SKIN_VXWORKS is not set
# CONFIG_XENO_OPT_NOWARN_DEPRECATED is not set
CONFIG_XENO_SKIN_RTDM=y
CONFIG_XENO_OPT_RTDM_PERIOD=0
CONFIG_XENO_OPT_RTDM_FILDES=128
CONFIG_XENO_OPT_RTDM_SELECT=y
# CONFIG_XENO_OPT_DEBUG_RTDM is not set
CONFIG_XENO_OPT_DEBUG_RTDM_APPL=y
#
# Drivers
#
#
# Serial drivers
#
# CONFIG_XENO_DRIVERS_16550A is not set
#
# Testing drivers
#
CONFIG_XENO_DRIVERS_TIMERBENCH=y
# CONFIG_XENO_DRIVERS_IRQBENCH is not set
CONFIG_XENO_DRIVERS_SWITCHTEST=y
#
# CAN drivers
#
# CONFIG_XENO_DRIVERS_CAN is not set
#
# ANALOGY drivers
#
# CONFIG_XENO_DRIVERS_ANALOGY is not set
#
# Real-time IPC drivers
#
CONFIG_XENO_DRIVERS_RTIPC=y
CONFIG_XENO_DRIVERS_RTIPC_XDDP=y
CONFIG_XENO_DRIVERS_RTIPC_IDDP=y
CONFIG_XENO_OPT_IDDP_NRPORT=32
CONFIG_XENO_DRIVERS_RTIPC_BUFP=y
CONFIG_XENO_OPT_BUFP_NRPORT=32
CONFIG_FREEZER=y
#
# System Type
#
CONFIG_MMU=y
# CONFIG_ARCH_MULTIPLATFORM is not set
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
CONFIG_PLAT_MESON=y
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_U300 is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set
#
# Amlogic Meson platform
#
CONFIG_ARCH_MESON8B=y
#
# Meson development boards
#
# CONFIG_MACH_MESON8B_COMMON_BOARD is not set
CONFIG_MACH_MESON8B_ODROIDC=y
# CONFIG_MESON_IRQ is not set
CONFIG_MESON_ARM_GIC=y
CONFIG_MESON_CLOCK_TICK_RATE=24000000
# CONFIG_MESON_ARM_GIC_FIQ is not set
# CONFIG_MESON_SUSPEND is not set
# CONFIG_CLK81_DFS is not set
CONFIG_MESON_LEGACY_REGISTER_API=y
# CONFIG_MESON_CPU_EMULATOR is not set
CONFIG_CLKTREE_DEBUG=y
# CONFIG_MESON_CPU_TEMP_SENSOR is not set
# CONFIG_MESON_TRUSTZONE is not set
# CONFIG_PLAT_SPEAR is not set
CONFIG_IPIPE_ARM_KUSER_TSC=y
#
# Processor Type
#
CONFIG_CPU_V7=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
#
# Processor Features
#
# CONFIG_ARM_LPAE is not set
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
CONFIG_SWP_EMULATE=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_NEED_KUSER_HELPERS=y
CONFIG_KUSER_HELPERS=y
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_CACHE_PL310=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_ARM_ERRATA_458693 is not set
# CONFIG_ARM_ERRATA_460075 is not set
# CONFIG_ARM_ERRATA_742230 is not set
# CONFIG_ARM_ERRATA_742231 is not set
# CONFIG_PL310_ERRATA_588369 is not set
# CONFIG_ARM_ERRATA_643719 is not set
# CONFIG_ARM_ERRATA_720789 is not set
# CONFIG_PL310_ERRATA_727915 is not set
# CONFIG_ARM_ERRATA_743622 is not set
# CONFIG_ARM_ERRATA_751472 is not set
# CONFIG_PL310_ERRATA_753970 is not set
CONFIG_ARM_ERRATA_754322=y
# CONFIG_ARM_ERRATA_754327 is not set
CONFIG_ARM_ERRATA_764369=y
# CONFIG_PL310_ERRATA_769419 is not set
# CONFIG_ARM_ERRATA_775420 is not set
# CONFIG_ARM_ERRATA_798181 is not set
#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set
#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
# CONFIG_SMP_ON_UP is not set
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
# CONFIG_HAVE_ARM_ARCH_TIMER is not set
# CONFIG_MCPM is not set
CONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_NR_CPUS=4
CONFIG_HOTPLUG_CPU=y
# CONFIG_ARM_PSCI is not set
CONFIG_LOCAL_TIMERS=y
CONFIG_ARCH_NR_GPIO=0
CONFIG_IPIPE=y
CONFIG_IPIPE_LEGACY=y
CONFIG_IPIPE_CORE=y
CONFIG_IPIPE_CORE_APIREV=2
CONFIG_IPIPE_WANT_APIREV_2=y
CONFIG_IPIPE_TARGET_APIREV=2
CONFIG_IPIPE_HAVE_HOSTRT=y
CONFIG_IPIPE_DELAYED_ATOMICSW=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
# CONFIG_THUMB2_KERNEL is not set
CONFIG_AEABI=y
CONFIG_OABI_COMPAT=y
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
CONFIG_HIGHMEM=y
# CONFIG_HIGHPTE is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_CLEANCACHE is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_XEN is not set
#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE=""
# CONFIG_XIP_KERNEL is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
# CONFIG_AUTO_ZRELADDR is not set
#
# CPU Power Management
#
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not set
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
#
# Floating point emulation
#
#
# At least one emulation must be selected
#
# CONFIG_FPE_NWFPE is not set
# CONFIG_FPE_FASTFPE is not set
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y
#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y
#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_APM_EMULATION is not set
CONFIG_PM_CLK=y
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
# CONFIG_NET is not set
CONFIG_HAVE_BPF_JIT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
# CONFIG_DMA_SHARED_BUFFER is not set
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
#
# Default contiguous memory area size:
#
CONFIG_CMA_SIZE_MBYTES=8
CONFIG_CMA_SIZE_SEL_MBYTES=y
# CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
# CONFIG_CMA_SIZE_SEL_MIN is not set
# CONFIG_CMA_SIZE_SEL_MAX is not set
CONFIG_CMA_ALIGNMENT=8
CONFIG_CMA_AREAS=7
#
# Bus devices
#
# CONFIG_MTD is not set
CONFIG_DTC=y
CONFIG_OF=y
#
# Device Tree and Open Firmware support
#
CONFIG_PROC_DEVICETREE=y
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_DEVICE=y
# CONFIG_PARPORT is not set
#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_93CX6 is not set
#
# Texas Instruments shared transport line discipline
#
#
# Altera FPGA firmware download module
#
#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_SCSI_DMA is not set
# CONFIG_SCSI_NETLINK is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set
#
# Userland interfaces
#
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
# CONFIG_SERIO is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set
#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
CONFIG_AM_UART=y
CONFIG_AM_UART_CONSOLE=y
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
# CONFIG_HW_RANDOM is not set
# CONFIG_R3964 is not set
# CONFIG_TCG_TPM is not set
# CONFIG_I2C is not set
# CONFIG_SPI is not set
#
# Qualcomm MSM SSBI bus support
#
# CONFIG_SSBI is not set
# CONFIG_HSI is not set
#
# PPS support
#
# CONFIG_PPS is not set
#
# PPS generators support
#
#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_GPIO_DEVRES=y
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set
#
# Graphics support
#
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not set
# CONFIG_EXYNOS_VIDEO is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
#
# HID support
#
# CONFIG_HID is not set
# CONFIG_USB_ARCH_HAS_OHCI is not set
# CONFIG_USB_ARCH_HAS_EHCI is not set
# CONFIG_USB_ARCH_HAS_XHCI is not set
# CONFIG_USB_SUPPORT is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set
#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set
#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_CLKDEV_LOOKUP=y
#
# Hardware Spinlock drivers
#
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set
#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set
#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_PWM is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
CONFIG_PRINT_QUOTA_WARNING=y
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
# CONFIG_AUTOFS4_FS is not set
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
# CONFIG_MISC_FILESYSTEMS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set
#
# Kernel hacking
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_STRIP_ASM_SYMS is not set
CONFIG_READABLE_ASM=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_SECTION_MISMATCH=y
# CONFIG_IPIPE_DEBUG is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_LOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
#
# RCU Debugging
#
# CONFIG_PROVE_RCU_DELAY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_VERBOSE=y
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACING_SUPPORT=y
# CONFIG_FTRACE is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_ARM_UNWIND=y
# CONFIG_DEBUG_USER is not set
CONFIG_DEBUG_LL=y
CONFIG_DEBUG_LL_UART_NONE=y
# CONFIG_DEBUG_ICEDCC is not set
# CONFIG_DEBUG_SEMIHOSTING is not set
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
CONFIG_UNCOMPRESS_INCLUDE="mach/uncompress.h"
CONFIG_EARLY_PRINTK=y
# CONFIG_PID_IN_CONTEXTIDR is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
# CONFIG_CRYPTO is not set
# CONFIG_BINARY_PRINTF is not set
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
# CONFIG_CRC_CCITT is not set
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_XZ_DEC=y
# CONFIG_XZ_DEC_X86 is not set
# CONFIG_XZ_DEC_POWERPC is not set
# CONFIG_XZ_DEC_IA64 is not set
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
# CONFIG_XZ_DEC_BCJ is not set
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
# CONFIG_AVERAGE is not set
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
# CONFIG_VIRTUALIZATION is not set
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.bad
Type: application/octet-stream
Size: 3708 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150325/a14c4b91/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dmesg.good
Type: application/octet-stream
Size: 4632 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150325/a14c4b91/attachment-0001.obj>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-25 14:48 ` GP Orcullo
@ 2015-03-25 14:57 ` Gilles Chanteperdrix
2015-03-25 15:25 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-25 14:57 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Wed, Mar 25, 2015 at 10:48:45PM +0800, GP Orcullo wrote:
> On Wed, Mar 18, 2015 at 10:56 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Wed, Mar 18, 2015 at 10:48:10PM +0800, GP Orcullo wrote:
> >> On Wed, Mar 18, 2015 at 10:21 PM, Gilles Chanteperdrix
> >> <gilles.chanteperdrix@xenomai.org> wrote:
> >> > On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
> >> >> Hi,
> >> >>
> >> >> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
> >> >> 3.10.33 non-mainlined kernel.
> >> >>
> >> >> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
> >> >> Once CONFIG_XENOMAI is set, the boot fails.
> >> >>
> >> >> Attached are the .config and the bootlog files. Turning
> >> >> CONFIG_SMP_ON_UP off gives a different result.
> >> >>
> >> >> Any pointers on where to start looking?
> >> >
> >> > here:
> >> > https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
> >> >
> >> > Your diagnostic is not consistent with the kernel messages: the only
> >> > difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
> >> > xenomai starts, however your kernel crashes before xenomai starts.
> >> >
> >> > Your problem is probably, as usual, in the timer handling code, or
> >> > tsc emulation.
> >> >
> >> > Other than that, I would disable the usually not recommended kernel
> >> > options.
> >> >
> >> > --
> >> > Gilles.
> >>
> >> I think there's a problem with the vendor supplied kernel source.
> >>
> >> On the xenomai patched kernel, disabling CONFIG_IPIPE and enabling
> >> CONFIG_SMP_ON_UP gives the following error during compilation:
> >>
> >> In file included from arch/arm/include/generated/asm/irq_regs.h:1:0,
> >> from include/linux/irq.h:26,
> >> from include/linux/ipipe.h:28,
> >> from include/linux/sched.h:25,
> >> from arch/arm/kernel/asm-offsets.c:13:
> >> include/asm-generic/irq_regs.h: In function ‘get_irq_regs’:
> >> include/asm-generic/irq_regs.h:25:2: error: implicit declaration of
> >> function ‘ipipe_processor_id’ [-Werror=implicit-function-declaration]
> >>
> >> I traced the error to this file:
> >> http://git.xenomai.org/ipipe-gch.git/tree/arch/arm/include/asm/percpu.h?h=for-ipipe-3.10
> >
> > That is very much likely a bug in the I-pipe patch itself, a case we
> > did not handle (CONFIG_SMP_ON_UP and !CONFIG_IPIPE), nothing very
> > serious, and probably unrelated to the issues you have.
> >
> > --
> > Gilles.
>
> I've stripped the kernel to its bare minimum and I was able to boot
> xenomai on a single cpu and pass the xeno-regression-test with no
> problems.
>
> Once CONFIG_SMP is enabled, the boot is stuck at "Switching to
> clocksource ipipe_tsc". There are no additional messages after that.
>
> This processor has no per-cpu local timers; it has eight timers total
> and I've allocated four timers for ipipe use. Sharing timers with
> Linux gives the same results.
Check that the tsc is working by calling ipipe_tsc_get() and
printing the result in a loop right after tsc registration. If this
freezes, the address you passed when registering the tsc is invalid.
If it always print the same value, you are using a timer that is
not started.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-25 14:57 ` Gilles Chanteperdrix
@ 2015-03-25 15:25 ` GP Orcullo
2015-03-25 16:08 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-25 15:25 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Wed, Mar 25, 2015 at 10:57 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Wed, Mar 25, 2015 at 10:48:45PM +0800, GP Orcullo wrote:
>> On Wed, Mar 18, 2015 at 10:56 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>> > On Wed, Mar 18, 2015 at 10:48:10PM +0800, GP Orcullo wrote:
>> >> On Wed, Mar 18, 2015 at 10:21 PM, Gilles Chanteperdrix
>> >> <gilles.chanteperdrix@xenomai.org> wrote:
>> >> > On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
>> >> >> Hi,
>> >> >>
>> >> >> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
>> >> >> 3.10.33 non-mainlined kernel.
>> >> >>
>> >> >> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
>> >> >> Once CONFIG_XENOMAI is set, the boot fails.
>> >> >>
>> >> >> Attached are the .config and the bootlog files. Turning
>> >> >> CONFIG_SMP_ON_UP off gives a different result.
>> >> >>
>> >> >> Any pointers on where to start looking?
>> >> >
>> >> > here:
>> >> > https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
>> >> >
>> >> > Your diagnostic is not consistent with the kernel messages: the only
>> >> > difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
>> >> > xenomai starts, however your kernel crashes before xenomai starts.
>> >> >
>> >> > Your problem is probably, as usual, in the timer handling code, or
>> >> > tsc emulation.
>> >> >
>> >> > Other than that, I would disable the usually not recommended kernel
>> >> > options.
>> >> >
>> >> > --
>> >> > Gilles.
>> >>
>> >> I think there's a problem with the vendor supplied kernel source.
>> >>
>> >> On the xenomai patched kernel, disabling CONFIG_IPIPE and enabling
>> >> CONFIG_SMP_ON_UP gives the following error during compilation:
>> >>
>> >> In file included from arch/arm/include/generated/asm/irq_regs.h:1:0,
>> >> from include/linux/irq.h:26,
>> >> from include/linux/ipipe.h:28,
>> >> from include/linux/sched.h:25,
>> >> from arch/arm/kernel/asm-offsets.c:13:
>> >> include/asm-generic/irq_regs.h: In function ‘get_irq_regs’:
>> >> include/asm-generic/irq_regs.h:25:2: error: implicit declaration of
>> >> function ‘ipipe_processor_id’ [-Werror=implicit-function-declaration]
>> >>
>> >> I traced the error to this file:
>> >> http://git.xenomai.org/ipipe-gch.git/tree/arch/arm/include/asm/percpu.h?h=for-ipipe-3.10
>> >
>> > That is very much likely a bug in the I-pipe patch itself, a case we
>> > did not handle (CONFIG_SMP_ON_UP and !CONFIG_IPIPE), nothing very
>> > serious, and probably unrelated to the issues you have.
>> >
>> > --
>> > Gilles.
>>
>> I've stripped the kernel to its bare minimum and I was able to boot
>> xenomai on a single cpu and pass the xeno-regression-test with no
>> problems.
>>
>> Once CONFIG_SMP is enabled, the boot is stuck at "Switching to
>> clocksource ipipe_tsc". There are no additional messages after that.
>>
>> This processor has no per-cpu local timers; it has eight timers total
>> and I've allocated four timers for ipipe use. Sharing timers with
>> Linux gives the same results.
>
> Check that the tsc is working by calling ipipe_tsc_get() and
> printing the result in a loop right after tsc registration. If this
> freezes, the address you passed when registering the tsc is invalid.
> If it always print the same value, you are using a timer that is
> not started.
>
> --
> Gilles.
The tsc timer is working:
[ 0.192740] Brought up 4 CPUs
[ 0.206979] SMP: Total of 4 processors activated (8.00 BogoMIPS).
[ 0.213032] CPU: All CPU(s) started in SVC mode.
[ 0.218205] devtmpfs: initialized
[ 0.229562] DMA: preallocated 4096 KiB pool for atomic coherent allocations
[ 0.235390] Switching to clocksource ipipe_tsc
[ 1.845448] ipipe_tsc_get = 7361092
[ 3.515445] ipipe_tsc_get = 9031092
[ 5.185445] ipipe_tsc_get = 10701092
[ 6.855445] ipipe_tsc_get = 12371092
[ 8.525445] ipipe_tsc_get = 14041092
I've added the code in the clockevent timer interrupt handler, right
after __ipipe_tsc_update().
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-25 15:25 ` GP Orcullo
@ 2015-03-25 16:08 ` Gilles Chanteperdrix
2015-03-25 23:44 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-25 16:08 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Wed, Mar 25, 2015 at 11:25:02PM +0800, GP Orcullo wrote:
> On Wed, Mar 25, 2015 at 10:57 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Wed, Mar 25, 2015 at 10:48:45PM +0800, GP Orcullo wrote:
> >> On Wed, Mar 18, 2015 at 10:56 PM, Gilles Chanteperdrix
> >> <gilles.chanteperdrix@xenomai.org> wrote:
> >> > On Wed, Mar 18, 2015 at 10:48:10PM +0800, GP Orcullo wrote:
> >> >> On Wed, Mar 18, 2015 at 10:21 PM, Gilles Chanteperdrix
> >> >> <gilles.chanteperdrix@xenomai.org> wrote:
> >> >> > On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
> >> >> >> Hi,
> >> >> >>
> >> >> >> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
> >> >> >> 3.10.33 non-mainlined kernel.
> >> >> >>
> >> >> >> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
> >> >> >> Once CONFIG_XENOMAI is set, the boot fails.
> >> >> >>
> >> >> >> Attached are the .config and the bootlog files. Turning
> >> >> >> CONFIG_SMP_ON_UP off gives a different result.
> >> >> >>
> >> >> >> Any pointers on where to start looking?
> >> >> >
> >> >> > here:
> >> >> > https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
> >> >> >
> >> >> > Your diagnostic is not consistent with the kernel messages: the only
> >> >> > difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
> >> >> > xenomai starts, however your kernel crashes before xenomai starts.
> >> >> >
> >> >> > Your problem is probably, as usual, in the timer handling code, or
> >> >> > tsc emulation.
> >> >> >
> >> >> > Other than that, I would disable the usually not recommended kernel
> >> >> > options.
> >> >> >
> >> >> > --
> >> >> > Gilles.
> >> >>
> >> >> I think there's a problem with the vendor supplied kernel source.
> >> >>
> >> >> On the xenomai patched kernel, disabling CONFIG_IPIPE and enabling
> >> >> CONFIG_SMP_ON_UP gives the following error during compilation:
> >> >>
> >> >> In file included from arch/arm/include/generated/asm/irq_regs.h:1:0,
> >> >> from include/linux/irq.h:26,
> >> >> from include/linux/ipipe.h:28,
> >> >> from include/linux/sched.h:25,
> >> >> from arch/arm/kernel/asm-offsets.c:13:
> >> >> include/asm-generic/irq_regs.h: In function ‘get_irq_regs’:
> >> >> include/asm-generic/irq_regs.h:25:2: error: implicit declaration of
> >> >> function ‘ipipe_processor_id’ [-Werror=implicit-function-declaration]
> >> >>
> >> >> I traced the error to this file:
> >> >> http://git.xenomai.org/ipipe-gch.git/tree/arch/arm/include/asm/percpu.h?h=for-ipipe-3.10
> >> >
> >> > That is very much likely a bug in the I-pipe patch itself, a case we
> >> > did not handle (CONFIG_SMP_ON_UP and !CONFIG_IPIPE), nothing very
> >> > serious, and probably unrelated to the issues you have.
> >> >
> >> > --
> >> > Gilles.
> >>
> >> I've stripped the kernel to its bare minimum and I was able to boot
> >> xenomai on a single cpu and pass the xeno-regression-test with no
> >> problems.
> >>
> >> Once CONFIG_SMP is enabled, the boot is stuck at "Switching to
> >> clocksource ipipe_tsc". There are no additional messages after that.
> >>
> >> This processor has no per-cpu local timers; it has eight timers total
> >> and I've allocated four timers for ipipe use. Sharing timers with
> >> Linux gives the same results.
> >
> > Check that the tsc is working by calling ipipe_tsc_get() and
> > printing the result in a loop right after tsc registration. If this
> > freezes, the address you passed when registering the tsc is invalid.
> > If it always print the same value, you are using a timer that is
> > not started.
> >
> > --
> > Gilles.
>
> The tsc timer is working:
>
> [ 0.192740] Brought up 4 CPUs
> [ 0.206979] SMP: Total of 4 processors activated (8.00 BogoMIPS).
> [ 0.213032] CPU: All CPU(s) started in SVC mode.
> [ 0.218205] devtmpfs: initialized
> [ 0.229562] DMA: preallocated 4096 KiB pool for atomic coherent allocations
> [ 0.235390] Switching to clocksource ipipe_tsc
> [ 1.845448] ipipe_tsc_get = 7361092
> [ 3.515445] ipipe_tsc_get = 9031092
> [ 5.185445] ipipe_tsc_get = 10701092
> [ 6.855445] ipipe_tsc_get = 12371092
> [ 8.525445] ipipe_tsc_get = 14041092
>
> I've added the code in the clockevent timer interrupt handler, right
> after __ipipe_tsc_update().
Seems to be incrementing real fast. To be sure it is working, please
do the test as I suggested.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-25 16:08 ` Gilles Chanteperdrix
@ 2015-03-25 23:44 ` GP Orcullo
2015-03-27 10:19 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-25 23:44 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Thu, Mar 26, 2015 at 12:08 AM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Wed, Mar 25, 2015 at 11:25:02PM +0800, GP Orcullo wrote:
>> On Wed, Mar 25, 2015 at 10:57 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>> > On Wed, Mar 25, 2015 at 10:48:45PM +0800, GP Orcullo wrote:
>> >> On Wed, Mar 18, 2015 at 10:56 PM, Gilles Chanteperdrix
>> >> <gilles.chanteperdrix@xenomai.org> wrote:
>> >> > On Wed, Mar 18, 2015 at 10:48:10PM +0800, GP Orcullo wrote:
>> >> >> On Wed, Mar 18, 2015 at 10:21 PM, Gilles Chanteperdrix
>> >> >> <gilles.chanteperdrix@xenomai.org> wrote:
>> >> >> > On Wed, Mar 18, 2015 at 10:11:06PM +0800, GP Orcullo wrote:
>> >> >> >> Hi,
>> >> >> >>
>> >> >> >> I'm trying to port xenomai 2.6.4 on an Amlogic S805 board running a
>> >> >> >> 3.10.33 non-mainlined kernel.
>> >> >> >>
>> >> >> >> The kernel boots with CONFIG_IPIPE enabled but without CONFIG_XENOMAI.
>> >> >> >> Once CONFIG_XENOMAI is set, the boot fails.
>> >> >> >>
>> >> >> >> Attached are the .config and the bootlog files. Turning
>> >> >> >> CONFIG_SMP_ON_UP off gives a different result.
>> >> >> >>
>> >> >> >> Any pointers on where to start looking?
>> >> >> >
>> >> >> > here:
>> >> >> > https://xenomai.org/2014/09/porting-xenomai-dual-kernel-to-a-new-arm-soc/
>> >> >> >
>> >> >> > Your diagnostic is not consistent with the kernel messages: the only
>> >> >> > difference between CONFIG_XENOMAI and !CONFIG_XENOMAI is when
>> >> >> > xenomai starts, however your kernel crashes before xenomai starts.
>> >> >> >
>> >> >> > Your problem is probably, as usual, in the timer handling code, or
>> >> >> > tsc emulation.
>> >> >> >
>> >> >> > Other than that, I would disable the usually not recommended kernel
>> >> >> > options.
>> >> >> >
>> >> >> > --
>> >> >> > Gilles.
>> >> >>
>> >> >> I think there's a problem with the vendor supplied kernel source.
>> >> >>
>> >> >> On the xenomai patched kernel, disabling CONFIG_IPIPE and enabling
>> >> >> CONFIG_SMP_ON_UP gives the following error during compilation:
>> >> >>
>> >> >> In file included from arch/arm/include/generated/asm/irq_regs.h:1:0,
>> >> >> from include/linux/irq.h:26,
>> >> >> from include/linux/ipipe.h:28,
>> >> >> from include/linux/sched.h:25,
>> >> >> from arch/arm/kernel/asm-offsets.c:13:
>> >> >> include/asm-generic/irq_regs.h: In function ‘get_irq_regs’:
>> >> >> include/asm-generic/irq_regs.h:25:2: error: implicit declaration of
>> >> >> function ‘ipipe_processor_id’ [-Werror=implicit-function-declaration]
>> >> >>
>> >> >> I traced the error to this file:
>> >> >> http://git.xenomai.org/ipipe-gch.git/tree/arch/arm/include/asm/percpu.h?h=for-ipipe-3.10
>> >> >
>> >> > That is very much likely a bug in the I-pipe patch itself, a case we
>> >> > did not handle (CONFIG_SMP_ON_UP and !CONFIG_IPIPE), nothing very
>> >> > serious, and probably unrelated to the issues you have.
>> >> >
>> >> > --
>> >> > Gilles.
>> >>
>> >> I've stripped the kernel to its bare minimum and I was able to boot
>> >> xenomai on a single cpu and pass the xeno-regression-test with no
>> >> problems.
>> >>
>> >> Once CONFIG_SMP is enabled, the boot is stuck at "Switching to
>> >> clocksource ipipe_tsc". There are no additional messages after that.
>> >>
>> >> This processor has no per-cpu local timers; it has eight timers total
>> >> and I've allocated four timers for ipipe use. Sharing timers with
>> >> Linux gives the same results.
>> >
>> > Check that the tsc is working by calling ipipe_tsc_get() and
>> > printing the result in a loop right after tsc registration. If this
>> > freezes, the address you passed when registering the tsc is invalid.
>> > If it always print the same value, you are using a timer that is
>> > not started.
>> >
>> > --
>> > Gilles.
>>
>> The tsc timer is working:
>>
>> [ 0.192740] Brought up 4 CPUs
>> [ 0.206979] SMP: Total of 4 processors activated (8.00 BogoMIPS).
>> [ 0.213032] CPU: All CPU(s) started in SVC mode.
>> [ 0.218205] devtmpfs: initialized
>> [ 0.229562] DMA: preallocated 4096 KiB pool for atomic coherent allocations
>> [ 0.235390] Switching to clocksource ipipe_tsc
>> [ 1.845448] ipipe_tsc_get = 7361092
>> [ 3.515445] ipipe_tsc_get = 9031092
>> [ 5.185445] ipipe_tsc_get = 10701092
>> [ 6.855445] ipipe_tsc_get = 12371092
>> [ 8.525445] ipipe_tsc_get = 14041092
>>
>> I've added the code in the clockevent timer interrupt handler, right
>> after __ipipe_tsc_update().
>
> Seems to be incrementing real fast. To be sure it is working, please
> do the test as I suggested.
>
> --
> Gilles.
The increment is consistent with a 1 MHz clock rate.
Here's the result right after __ipipe_tsc_register(&tsc_info):
[ 0.000000] sched_clock: 32 bits at 1000kHz, resolution 1000ns,
wraps every 4294967ms
[ 0.000000] I-pipe, 1.000 MHz clocksource
[ 0.000000] ipipe_tsc_get = 5303847
[ 0.000000] ipipe_tsc_get = 5307392
[ 0.000000] ipipe_tsc_get = 5310942
[ 0.000000] ipipe_tsc_get = 5314492
[ 0.000000] ipipe_tsc_get = 5318042
[ 0.000000] ipipe_tsc_get = 5321592
[ 0.000000] ipipe_tsc_get = 5325142
[ 0.000000] ipipe_tsc_get = 5328692
[ 0.000000] ipipe_tsc_get = 5332242
[ 0.000000] ipipe_tsc_get = 5335792
[ 0.000000] Switching to timer-based delay loop
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-25 23:44 ` GP Orcullo
@ 2015-03-27 10:19 ` GP Orcullo
2015-03-27 12:12 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-27 10:19 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
What happens in between the clocksource switch and head domain registration?
[ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
allocations
[ 0.095333] Switching to clocksource ipipe_tsc
[ 0.122397] I-pipe: head domain Xenomai registered.
[ 0.124618] Xenomai: hal/arm started.
I'm trying to trace the code to find out where it stops. I tried
adding printk to to the set and request functions and the code never
runs when CONFIG_SMP is enabled.
Thanks,
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-27 10:19 ` GP Orcullo
@ 2015-03-27 12:12 ` GP Orcullo
2015-03-28 9:05 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-27 12:12 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> What happens in between the clocksource switch and head domain registration?
>
> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> allocations
> [ 0.095333] Switching to clocksource ipipe_tsc
> [ 0.122397] I-pipe: head domain Xenomai registered.
> [ 0.124618] Xenomai: hal/arm started.
>
> I'm trying to trace the code to find out where it stops. I tried
> adding printk to to the set and request functions and the code never
> runs when CONFIG_SMP is enabled.
>
> Thanks,
>
> GP Orcullo
It gets stuck on the call to ipipe_critical_enter:
http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
Which then gets stuck on ipipe_send_ipi:
http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-27 12:12 ` GP Orcullo
@ 2015-03-28 9:05 ` GP Orcullo
2015-03-28 9:51 ` Philippe Gerum
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-28 9:05 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> What happens in between the clocksource switch and head domain registration?
>>
>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>> allocations
>> [ 0.095333] Switching to clocksource ipipe_tsc
>> [ 0.122397] I-pipe: head domain Xenomai registered.
>> [ 0.124618] Xenomai: hal/arm started.
>>
>> I'm trying to trace the code to find out where it stops. I tried
>> adding printk to to the set and request functions and the code never
>> runs when CONFIG_SMP is enabled.
>>
>> Thanks,
>>
>> GP Orcullo
>
> It gets stuck on the call to ipipe_critical_enter:
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>
> Which then gets stuck on ipipe_send_ipi:
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>
I've traced the issue to the ipipe_processor_id() function. It returns
the value 512 for processor 0. This value comes from cpu node property
of the DT file.
Changing ipipe_processor_id() to return 0 instead of 512 allows the
kernel to boot but it fails the switchtest regression test.
Changing the cpu0 reg value on the DT file allows the kernel to boot
and pass all the xenomai regression tests but it generates the
following warning at boot:
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] WARNING: at arch/arm/kernel/devtree.c:149
arm_dt_init_cpu_maps+0x124/0x1e0()
[ 0.000000] DT /cpu 5 nodes greater than max cores 4, capping them
[ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.33-mmc+ #349
[ 0.000000] [<c0013f3c>] (unwind_backtrace+0x0/0xf8) from
[<c00118f4>] (show_stack+0x10/0x14)
[ 0.000000] [<c00118f4>] (show_stack+0x10/0x14) from [<c0022110>]
(warn_slowpath_common+0x48/0x68)
[ 0.000000] [<c0022110>] (warn_slowpath_common+0x48/0x68) from
[<c0022178>] (warn_slowpath_fmt+0x30/0x40)
[ 0.000000] [<c0022178>] (warn_slowpath_fmt+0x30/0x40) from
[<c02578bc>] (arm_dt_init_cpu_maps+0x124/0x1e0)
[ 0.000000] [<c02578bc>] (arm_dt_init_cpu_maps+0x124/0x1e0) from
[<c0256ff4>] (setup_arch+0x5a0/0x68c)
[ 0.000000] [<c0256ff4>] (setup_arch+0x5a0/0x68c) from [<c0254798>]
(start_kernel+0x7c/0x310)
[ 0.000000] [<c0254798>] (start_kernel+0x7c/0x310) from
[<0020806c>] (0x20806c)
[ 0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[ 0.000000] DT missing boot CPU MPIDR[23:0], fall back to default
cpu_logical_map
What's the proper way of fixing this?
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 9:05 ` GP Orcullo
@ 2015-03-28 9:51 ` Philippe Gerum
2015-03-28 11:36 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: Philippe Gerum @ 2015-03-28 9:51 UTC (permalink / raw)
To: GP Orcullo, Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On 03/28/2015 10:05 AM, GP Orcullo wrote:
> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>> What happens in between the clocksource switch and head domain registration?
>>>
>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>>> allocations
>>> [ 0.095333] Switching to clocksource ipipe_tsc
>>> [ 0.122397] I-pipe: head domain Xenomai registered.
>>> [ 0.124618] Xenomai: hal/arm started.
>>>
>>> I'm trying to trace the code to find out where it stops. I tried
>>> adding printk to to the set and request functions and the code never
>>> runs when CONFIG_SMP is enabled.
>>>
>>> Thanks,
>>>
>>> GP Orcullo
>>
>> It gets stuck on the call to ipipe_critical_enter:
>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>>
>> Which then gets stuck on ipipe_send_ipi:
>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>>
>
> I've traced the issue to the ipipe_processor_id() function. It returns
> the value 512 for processor 0. This value comes from cpu node property
> of the DT file.
>
> Changing ipipe_processor_id() to return 0 instead of 512 allows the
> kernel to boot but it fails the switchtest regression test.
>
> Changing the cpu0 reg value on the DT file allows the kernel to boot
> and pass all the xenomai regression tests but it generates the
> following warning at boot:
No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
of the core.
> What's the proper way of fixing this?
>
By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
the opposite.
We may have been lucky until now because the physical mapping seems to
have always matched the logical order on the SMP SoCs people used with
Xenomai so far, it looks like your A5 core does not follow this order.
--
Philippe.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 9:51 ` Philippe Gerum
@ 2015-03-28 11:36 ` Gilles Chanteperdrix
2015-03-28 12:27 ` GP Orcullo
2015-03-28 12:31 ` Philippe Gerum
0 siblings, 2 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 11:36 UTC (permalink / raw)
To: Philippe Gerum; +Cc: GP Orcullo, xenomai@xenomai.org
On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >>> What happens in between the clocksource switch and head domain registration?
> >>>
> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >>> allocations
> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >>> [ 0.124618] Xenomai: hal/arm started.
> >>>
> >>> I'm trying to trace the code to find out where it stops. I tried
> >>> adding printk to to the set and request functions and the code never
> >>> runs when CONFIG_SMP is enabled.
> >>>
> >>> Thanks,
> >>>
> >>> GP Orcullo
> >>
> >> It gets stuck on the call to ipipe_critical_enter:
> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >>
> >> Which then gets stuck on ipipe_send_ipi:
> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >>
> >
> > I've traced the issue to the ipipe_processor_id() function. It returns
> > the value 512 for processor 0. This value comes from cpu node property
> > of the DT file.
> >
> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > kernel to boot but it fails the switchtest regression test.
> >
> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > and pass all the xenomai regression tests but it generates the
> > following warning at boot:
>
> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> of the core.
>
> > What's the proper way of fixing this?
> >
>
> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> the opposite.
>
> We may have been lucky until now because the physical mapping seems to
> have always matched the logical order on the SMP SoCs people used with
> Xenomai so far, it looks like your A5 core does not follow this order.
No, cpu_logical_map works both ways, it simply exchanges 0 with
whatever number the boot cpu has
so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
it should work both ways.
At least, that was true before DT. Now, I find 512 a bit high, are
you sure cpu_logical_map[] is large enough ? Or is it even
initialized with DT ?
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 11:36 ` Gilles Chanteperdrix
@ 2015-03-28 12:27 ` GP Orcullo
2015-03-28 13:06 ` Gilles Chanteperdrix
` (2 more replies)
2015-03-28 12:31 ` Philippe Gerum
1 sibling, 3 replies; 51+ messages in thread
From: GP Orcullo @ 2015-03-28 12:27 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> >>> What happens in between the clocksource switch and head domain registration?
>> >>>
>> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>> >>> allocations
>> >>> [ 0.095333] Switching to clocksource ipipe_tsc
>> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
>> >>> [ 0.124618] Xenomai: hal/arm started.
>> >>>
>> >>> I'm trying to trace the code to find out where it stops. I tried
>> >>> adding printk to to the set and request functions and the code never
>> >>> runs when CONFIG_SMP is enabled.
>> >>>
>> >>> Thanks,
>> >>>
>> >>> GP Orcullo
>> >>
>> >> It gets stuck on the call to ipipe_critical_enter:
>> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>> >>
>> >> Which then gets stuck on ipipe_send_ipi:
>> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>> >>
>> >
>> > I've traced the issue to the ipipe_processor_id() function. It returns
>> > the value 512 for processor 0. This value comes from cpu node property
>> > of the DT file.
>> >
>> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
>> > kernel to boot but it fails the switchtest regression test.
>> >
>> > Changing the cpu0 reg value on the DT file allows the kernel to boot
>> > and pass all the xenomai regression tests but it generates the
>> > following warning at boot:
>>
>> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
>> of the core.
>>
>> > What's the proper way of fixing this?
>> >
>>
>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
>> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
>> the opposite.
>>
>> We may have been lucky until now because the physical mapping seems to
>> have always matched the logical order on the SMP SoCs people used with
>> Xenomai so far, it looks like your A5 core does not follow this order.
>
> No, cpu_logical_map works both ways, it simply exchanges 0 with
> whatever number the boot cpu has
> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> it should work both ways.
> At least, that was true before DT. Now, I find 512 a bit high, are
> you sure cpu_logical_map[] is large enough ? Or is it even
> initialized with DT ?
>
> --
> Gilles.
cpu_logical_map[] contains these values: {512,1,2,3}
This is the cpu entry:
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
Changing the reg values alters the contents of cpu_logical_map[].
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 12:27 ` GP Orcullo
@ 2015-03-28 13:06 ` Gilles Chanteperdrix
2015-03-28 13:12 ` Gilles Chanteperdrix
2015-03-28 13:53 ` Gilles Chanteperdrix
2015-03-28 18:59 ` Gilles Chanteperdrix
2 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 13:06 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> >>> What happens in between the clocksource switch and head domain registration?
> >> >>>
> >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >> >>> allocations
> >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >> >>> [ 0.124618] Xenomai: hal/arm started.
> >> >>>
> >> >>> I'm trying to trace the code to find out where it stops. I tried
> >> >>> adding printk to to the set and request functions and the code never
> >> >>> runs when CONFIG_SMP is enabled.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> GP Orcullo
> >> >>
> >> >> It gets stuck on the call to ipipe_critical_enter:
> >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >> >>
> >> >> Which then gets stuck on ipipe_send_ipi:
> >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >> >>
> >> >
> >> > I've traced the issue to the ipipe_processor_id() function. It returns
> >> > the value 512 for processor 0. This value comes from cpu node property
> >> > of the DT file.
> >> >
> >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >> > kernel to boot but it fails the switchtest regression test.
> >> >
> >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> >> > and pass all the xenomai regression tests but it generates the
> >> > following warning at boot:
> >>
> >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >> of the core.
> >>
> >> > What's the proper way of fixing this?
> >> >
> >>
> >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >> the opposite.
> >>
> >> We may have been lucky until now because the physical mapping seems to
> >> have always matched the logical order on the SMP SoCs people used with
> >> Xenomai so far, it looks like your A5 core does not follow this order.
> >
> > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > whatever number the boot cpu has
> > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > it should work both ways.
> > At least, that was true before DT. Now, I find 512 a bit high, are
> > you sure cpu_logical_map[] is large enough ? Or is it even
> > initialized with DT ?
> >
> > --
> > Gilles.
>
> cpu_logical_map[] contains these values: {512,1,2,3}
>
> This is the cpu entry:
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
>
> Changing the reg values alters the contents of cpu_logical_map[].
Ok, in that case, to make it work, cpu_logical_map would need to
have 513 entries to be able to have cpu_logical_map[512] == 0.
Or replace cpu_logical_map with a reverse map which is a copy of
cpu_logical_map plus the additional entry to make it work.
If you are using an older version of the code, there may be a
reference to __cpu_logical_map from the VFP code which you need to
replace with __cpu_reverse_map.
Please try the following untested patch:
diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
index 72ad7a4..651b7d8 100644
--- a/arch/arm/include/asm/ipipe_base.h
+++ b/arch/arm/include/asm/ipipe_base.h
@@ -55,8 +55,8 @@ extern unsigned __ipipe_first_ipi;
: "=r" (cpunum)); \
cpunum &= 0xFF; \
})
-extern u32 __cpu_logical_map[];
-#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
+extern u32 *__cpu_reverse_map[];
+#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
#else /* !legacy */
#define hard_smp_processor_id() raw_smp_processor_id()
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b10f40f..82f2811 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -469,29 +469,30 @@ void notrace cpu_init(void)
#endif
}
-#if NR_CPUS > 16
u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
-#else
-u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
-#endif
+
+u32 *__cpu_reverse_map;
+EXPORT_SYMBOL(__cpu_reverse_map);
void __init smp_setup_processor_id(void)
{
int i;
u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
- u32 max = cpu + 1 > nr_cpu_ids ? cpu + 1 : nr_cpu_ids;
+ u32 max = nr_cpu_ids > mpidr ? nr_cpu_ids : mpidr;
#ifdef CONFIG_IPIPE
/* printk on I-pipe needs per cpu data */
set_my_cpu_offset(per_cpu_offset(0));
#endif
- BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
cpu_logical_map(0) = cpu;
- for (i = 1; i < max; ++i)
+ for (i = 1; i < nr_cpu_ids; ++i)
cpu_logical_map(i) = i == cpu ? 0 : i;
+ for (i = 0; i < max; i++)
+ __cpu_reverse_map[i] = get_logical_index(i);
+
/*
* clear __my_cpu_offset on boot CPU to avoid hang caused by
* using percpu variable early, for example, lockdep will
--
Gilles.
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 13:06 ` Gilles Chanteperdrix
@ 2015-03-28 13:12 ` Gilles Chanteperdrix
2015-03-28 13:22 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 13:12 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 02:06:20PM +0100, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > <gilles.chanteperdrix@xenomai.org> wrote:
> > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > >> >>> What happens in between the clocksource switch and head domain registration?
> > >> >>>
> > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > >> >>> allocations
> > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > >> >>>
> > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > >> >>> adding printk to to the set and request functions and the code never
> > >> >>> runs when CONFIG_SMP is enabled.
> > >> >>>
> > >> >>> Thanks,
> > >> >>>
> > >> >>> GP Orcullo
> > >> >>
> > >> >> It gets stuck on the call to ipipe_critical_enter:
> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > >> >>
> > >> >> Which then gets stuck on ipipe_send_ipi:
> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > >> >>
> > >> >
> > >> > I've traced the issue to the ipipe_processor_id() function. It returns
> > >> > the value 512 for processor 0. This value comes from cpu node property
> > >> > of the DT file.
> > >> >
> > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > >> > kernel to boot but it fails the switchtest regression test.
> > >> >
> > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > >> > and pass all the xenomai regression tests but it generates the
> > >> > following warning at boot:
> > >>
> > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> > >> of the core.
> > >>
> > >> > What's the proper way of fixing this?
> > >> >
> > >>
> > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> > >> the opposite.
> > >>
> > >> We may have been lucky until now because the physical mapping seems to
> > >> have always matched the logical order on the SMP SoCs people used with
> > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > >
> > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > whatever number the boot cpu has
> > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > it should work both ways.
> > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > initialized with DT ?
> > >
> > > --
> > > Gilles.
> >
> > cpu_logical_map[] contains these values: {512,1,2,3}
> >
> > This is the cpu entry:
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> >
> > Changing the reg values alters the contents of cpu_logical_map[].
>
> Ok, in that case, to make it work, cpu_logical_map would need to
> have 513 entries to be able to have cpu_logical_map[512] == 0.
> Or replace cpu_logical_map with a reverse map which is a copy of
> cpu_logical_map plus the additional entry to make it work.
>
> If you are using an older version of the code, there may be a
> reference to __cpu_logical_map from the VFP code which you need to
> replace with __cpu_reverse_map.
>
> Please try the following untested patch:
Scrap that. Missing kmalloc, off-by-one error. I am sorry, but I
will not be able to work on that. Do you get the idea, are you able
to fix it on your own ?
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 13:12 ` Gilles Chanteperdrix
@ 2015-03-28 13:22 ` Gilles Chanteperdrix
2015-03-28 13:37 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 13:22 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 02:12:14PM +0100, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 02:06:20PM +0100, Gilles Chanteperdrix wrote:
> > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > > >> >>> What happens in between the clocksource switch and head domain registration?
> > > >> >>>
> > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > > >> >>> allocations
> > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > >> >>>
> > > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > > >> >>> adding printk to to the set and request functions and the code never
> > > >> >>> runs when CONFIG_SMP is enabled.
> > > >> >>>
> > > >> >>> Thanks,
> > > >> >>>
> > > >> >>> GP Orcullo
> > > >> >>
> > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > >> >>
> > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > >> >>
> > > >> >
> > > >> > I've traced the issue to the ipipe_processor_id() function. It returns
> > > >> > the value 512 for processor 0. This value comes from cpu node property
> > > >> > of the DT file.
> > > >> >
> > > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > > >> > kernel to boot but it fails the switchtest regression test.
> > > >> >
> > > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > > >> > and pass all the xenomai regression tests but it generates the
> > > >> > following warning at boot:
> > > >>
> > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> > > >> of the core.
> > > >>
> > > >> > What's the proper way of fixing this?
> > > >> >
> > > >>
> > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> > > >> the opposite.
> > > >>
> > > >> We may have been lucky until now because the physical mapping seems to
> > > >> have always matched the logical order on the SMP SoCs people used with
> > > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > > >
> > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > whatever number the boot cpu has
> > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > > it should work both ways.
> > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > initialized with DT ?
> > > >
> > > > --
> > > > Gilles.
> > >
> > > cpu_logical_map[] contains these values: {512,1,2,3}
> > >
> > > This is the cpu entry:
> > > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> > >
> > > Changing the reg values alters the contents of cpu_logical_map[].
> >
> > Ok, in that case, to make it work, cpu_logical_map would need to
> > have 513 entries to be able to have cpu_logical_map[512] == 0.
> > Or replace cpu_logical_map with a reverse map which is a copy of
> > cpu_logical_map plus the additional entry to make it work.
> >
> > If you are using an older version of the code, there may be a
> > reference to __cpu_logical_map from the VFP code which you need to
> > replace with __cpu_reverse_map.
> >
> > Please try the following untested patch:
>
> Scrap that. Missing kmalloc, off-by-one error. I am sorry, but I
> will not be able to work on that. Do you get the idea, are you able
> to fix it on your own ?
Last attempt:
diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
index 72ad7a4..651b7d8 100644
--- a/arch/arm/include/asm/ipipe_base.h
+++ b/arch/arm/include/asm/ipipe_base.h
@@ -55,8 +55,8 @@ extern unsigned __ipipe_first_ipi;
: "=r" (cpunum)); \
cpunum &= 0xFF; \
})
-extern u32 __cpu_logical_map[];
-#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
+extern u32 *__cpu_reverse_map[];
+#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
#else /* !legacy */
#define hard_smp_processor_id() raw_smp_processor_id()
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b10f40f..20b8854 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -469,29 +469,32 @@ void notrace cpu_init(void)
#endif
}
-#if NR_CPUS > 16
u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
-#else
-u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
-#endif
+
+u32 *__cpu_reverse_map;
+EXPORT_SYMBOL(__cpu_reverse_map);
void __init smp_setup_processor_id(void)
{
int i;
u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
- u32 max = cpu + 1 > nr_cpu_ids ? cpu + 1 : nr_cpu_ids;
+ u32 max = nr_cpu_ids > mpidr + 1 ? nr_cpu_ids : mpidr + 1;
#ifdef CONFIG_IPIPE
/* printk on I-pipe needs per cpu data */
set_my_cpu_offset(per_cpu_offset(0));
#endif
- BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
cpu_logical_map(0) = cpu;
- for (i = 1; i < max; ++i)
+ for (i = 1; i < nr_cpu_ids; ++i)
cpu_logical_map(i) = i == cpu ? 0 : i;
+ __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
+
+ for (i = 0; i < nr_cpu_ids; i++)
+ __cpu_reverse_map[cpu_logical_map(i)] = i;
+
/*
* clear __my_cpu_offset on boot CPU to avoid hang caused by
* using percpu variable early, for example, lockdep will
--
Gilles.
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 13:22 ` Gilles Chanteperdrix
@ 2015-03-28 13:37 ` Gilles Chanteperdrix
2015-03-28 15:20 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 13:37 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 02:22:52PM +0100, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 02:12:14PM +0100, Gilles Chanteperdrix wrote:
> > On Sat, Mar 28, 2015 at 02:06:20PM +0100, Gilles Chanteperdrix wrote:
> > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > > > >> >>> What happens in between the clocksource switch and head domain registration?
> > > > >> >>>
> > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > > > >> >>> allocations
> > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > >> >>>
> > > > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > > > >> >>> adding printk to to the set and request functions and the code never
> > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > >> >>>
> > > > >> >>> Thanks,
> > > > >> >>>
> > > > >> >>> GP Orcullo
> > > > >> >>
> > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > >> >>
> > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > >> >>
> > > > >> >
> > > > >> > I've traced the issue to the ipipe_processor_id() function. It returns
> > > > >> > the value 512 for processor 0. This value comes from cpu node property
> > > > >> > of the DT file.
> > > > >> >
> > > > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > >> >
> > > > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > > > >> > and pass all the xenomai regression tests but it generates the
> > > > >> > following warning at boot:
> > > > >>
> > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> > > > >> of the core.
> > > > >>
> > > > >> > What's the proper way of fixing this?
> > > > >> >
> > > > >>
> > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> > > > >> the opposite.
> > > > >>
> > > > >> We may have been lucky until now because the physical mapping seems to
> > > > >> have always matched the logical order on the SMP SoCs people used with
> > > > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > > > >
> > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > whatever number the boot cpu has
> > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > > > it should work both ways.
> > > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > initialized with DT ?
> > > > >
> > > > > --
> > > > > Gilles.
> > > >
> > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > > >
> > > > This is the cpu entry:
> > > > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> > > >
> > > > Changing the reg values alters the contents of cpu_logical_map[].
> > >
> > > Ok, in that case, to make it work, cpu_logical_map would need to
> > > have 513 entries to be able to have cpu_logical_map[512] == 0.
> > > Or replace cpu_logical_map with a reverse map which is a copy of
> > > cpu_logical_map plus the additional entry to make it work.
> > >
> > > If you are using an older version of the code, there may be a
> > > reference to __cpu_logical_map from the VFP code which you need to
> > > replace with __cpu_reverse_map.
> > >
> > > Please try the following untested patch:
> >
> > Scrap that. Missing kmalloc, off-by-one error. I am sorry, but I
> > will not be able to work on that. Do you get the idea, are you able
> > to fix it on your own ?
>
> Last attempt:
We also need to fix hard_smp_processor_id for cpus larger than 255
(also the VFP code in old patches).
So, the final patch is:
diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
index 72ad7a4..e920175 100644
--- a/arch/arm/include/asm/ipipe_base.h
+++ b/arch/arm/include/asm/ipipe_base.h
@@ -53,10 +53,10 @@ extern unsigned __ipipe_first_ipi;
" mov %0, #0\n" \
" .popsection" \
: "=r" (cpunum)); \
- cpunum &= 0xFF; \
+ cpunum &= 0xFFFFFF; \
})
-extern u32 __cpu_logical_map[];
-#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
+extern u32 *__cpu_reverse_map[];
+#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
#else /* !legacy */
#define hard_smp_processor_id() raw_smp_processor_id()
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b10f40f..df02a76 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -469,29 +469,33 @@ void notrace cpu_init(void)
#endif
}
-#if NR_CPUS > 16
u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
-#else
-u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
-#endif
+
+u32 *__cpu_reverse_map;
+EXPORT_SYMBOL(__cpu_reverse_map);
void __init smp_setup_processor_id(void)
{
int i;
u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
- u32 max = cpu + 1 > nr_cpu_ids ? cpu + 1 : nr_cpu_ids;
+ u32 max = nr_cpu_ids > mpidr + 1 ? nr_cpu_ids : mpidr + 1;
#ifdef CONFIG_IPIPE
/* printk on I-pipe needs per cpu data */
set_my_cpu_offset(per_cpu_offset(0));
#endif
- BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
cpu_logical_map(0) = cpu;
- for (i = 1; i < max; ++i)
+ for (i = 1; i < nr_cpu_ids; ++i)
cpu_logical_map(i) = i == cpu ? 0 : i;
+ __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
+ BUG_ON(!__cpu_reverse_map);
+
+ for (i = 0; i < nr_cpu_ids; i++)
+ __cpu_reverse_map[cpu_logical_map(i)] = i;
+
/*
* clear __my_cpu_offset on boot CPU to avoid hang caused by
* using percpu variable early, for example, lockdep will
--
Gilles.
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 13:37 ` Gilles Chanteperdrix
@ 2015-03-28 15:20 ` GP Orcullo
2015-03-28 17:23 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-28 15:20 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 9:37 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Sat, Mar 28, 2015 at 02:22:52PM +0100, Gilles Chanteperdrix wrote:
>> On Sat, Mar 28, 2015 at 02:12:14PM +0100, Gilles Chanteperdrix wrote:
>> > On Sat, Mar 28, 2015 at 02:06:20PM +0100, Gilles Chanteperdrix wrote:
>> > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
>> > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
>> > > > <gilles.chanteperdrix@xenomai.org> wrote:
>> > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>> > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>> > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> > > > >> >>> What happens in between the clocksource switch and head domain registration?
>> > > > >> >>>
>> > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>> > > > >> >>> allocations
>> > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
>> > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
>> > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
>> > > > >> >>>
>> > > > >> >>> I'm trying to trace the code to find out where it stops. I tried
>> > > > >> >>> adding printk to to the set and request functions and the code never
>> > > > >> >>> runs when CONFIG_SMP is enabled.
>> > > > >> >>>
>> > > > >> >>> Thanks,
>> > > > >> >>>
>> > > > >> >>> GP Orcullo
>> > > > >> >>
>> > > > >> >> It gets stuck on the call to ipipe_critical_enter:
>> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>> > > > >> >>
>> > > > >> >> Which then gets stuck on ipipe_send_ipi:
>> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>> > > > >> >>
>> > > > >> >
>> > > > >> > I've traced the issue to the ipipe_processor_id() function. It returns
>> > > > >> > the value 512 for processor 0. This value comes from cpu node property
>> > > > >> > of the DT file.
>> > > > >> >
>> > > > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
>> > > > >> > kernel to boot but it fails the switchtest regression test.
>> > > > >> >
>> > > > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
>> > > > >> > and pass all the xenomai regression tests but it generates the
>> > > > >> > following warning at boot:
>> > > > >>
>> > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
>> > > > >> of the core.
>> > > > >>
>> > > > >> > What's the proper way of fixing this?
>> > > > >> >
>> > > > >>
>> > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
>> > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
>> > > > >> the opposite.
>> > > > >>
>> > > > >> We may have been lucky until now because the physical mapping seems to
>> > > > >> have always matched the logical order on the SMP SoCs people used with
>> > > > >> Xenomai so far, it looks like your A5 core does not follow this order.
>> > > > >
>> > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
>> > > > > whatever number the boot cpu has
>> > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
>> > > > > it should work both ways.
>> > > > > At least, that was true before DT. Now, I find 512 a bit high, are
>> > > > > you sure cpu_logical_map[] is large enough ? Or is it even
>> > > > > initialized with DT ?
>> > > > >
>> > > > > --
>> > > > > Gilles.
>> > > >
>> > > > cpu_logical_map[] contains these values: {512,1,2,3}
>> > > >
>> > > > This is the cpu entry:
>> > > > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
>> > > >
>> > > > Changing the reg values alters the contents of cpu_logical_map[].
>> > >
>> > > Ok, in that case, to make it work, cpu_logical_map would need to
>> > > have 513 entries to be able to have cpu_logical_map[512] == 0.
>> > > Or replace cpu_logical_map with a reverse map which is a copy of
>> > > cpu_logical_map plus the additional entry to make it work.
>> > >
>> > > If you are using an older version of the code, there may be a
>> > > reference to __cpu_logical_map from the VFP code which you need to
>> > > replace with __cpu_reverse_map.
>> > >
>> > > Please try the following untested patch:
>> >
>> > Scrap that. Missing kmalloc, off-by-one error. I am sorry, but I
>> > will not be able to work on that. Do you get the idea, are you able
>> > to fix it on your own ?
>>
>> Last attempt:
>
> We also need to fix hard_smp_processor_id for cpus larger than 255
> (also the VFP code in old patches).
> So, the final patch is:
>
> diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
> index 72ad7a4..e920175 100644
> --- a/arch/arm/include/asm/ipipe_base.h
> +++ b/arch/arm/include/asm/ipipe_base.h
> @@ -53,10 +53,10 @@ extern unsigned __ipipe_first_ipi;
> " mov %0, #0\n" \
> " .popsection" \
> : "=r" (cpunum)); \
> - cpunum &= 0xFF; \
> + cpunum &= 0xFFFFFF; \
> })
> -extern u32 __cpu_logical_map[];
> -#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
> +extern u32 *__cpu_reverse_map[];
> +#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
>
> #else /* !legacy */
> #define hard_smp_processor_id() raw_smp_processor_id()
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index b10f40f..df02a76 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -469,29 +469,33 @@ void notrace cpu_init(void)
> #endif
> }
>
> -#if NR_CPUS > 16
> u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
> -#else
> -u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
> -#endif
> +
> +u32 *__cpu_reverse_map;
> +EXPORT_SYMBOL(__cpu_reverse_map);
>
> void __init smp_setup_processor_id(void)
> {
> int i;
> u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
> u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> - u32 max = cpu + 1 > nr_cpu_ids ? cpu + 1 : nr_cpu_ids;
> + u32 max = nr_cpu_ids > mpidr + 1 ? nr_cpu_ids : mpidr + 1;
>
> #ifdef CONFIG_IPIPE
> /* printk on I-pipe needs per cpu data */
> set_my_cpu_offset(per_cpu_offset(0));
> #endif
> - BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
>
> cpu_logical_map(0) = cpu;
> - for (i = 1; i < max; ++i)
> + for (i = 1; i < nr_cpu_ids; ++i)
> cpu_logical_map(i) = i == cpu ? 0 : i;
>
> + __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
> + BUG_ON(!__cpu_reverse_map);
> +
> + for (i = 0; i < nr_cpu_ids; i++)
> + __cpu_reverse_map[cpu_logical_map(i)] = i;
> +
> /*
> * clear __my_cpu_offset on boot CPU to avoid hang caused by
> * using percpu variable early, for example, lockdep will
>
> --
> Gilles.
The kernel doesn't boot on this one.
I'll debug it later.
Thanks!
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 15:20 ` GP Orcullo
@ 2015-03-28 17:23 ` Gilles Chanteperdrix
2015-03-28 19:14 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 17:23 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 11:20:05PM +0800, GP Orcullo wrote:
> On Sat, Mar 28, 2015 at 9:37 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Sat, Mar 28, 2015 at 02:22:52PM +0100, Gilles Chanteperdrix wrote:
> >> On Sat, Mar 28, 2015 at 02:12:14PM +0100, Gilles Chanteperdrix wrote:
> >> > On Sat, Mar 28, 2015 at 02:06:20PM +0100, Gilles Chanteperdrix wrote:
> >> > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> >> > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> >> > > > <gilles.chanteperdrix@xenomai.org> wrote:
> >> > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >> > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >> > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> > > > >> >>> What happens in between the clocksource switch and head domain registration?
> >> > > > >> >>>
> >> > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >> > > > >> >>> allocations
> >> > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> >> > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >> > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> >> > > > >> >>>
> >> > > > >> >>> I'm trying to trace the code to find out where it stops. I tried
> >> > > > >> >>> adding printk to to the set and request functions and the code never
> >> > > > >> >>> runs when CONFIG_SMP is enabled.
> >> > > > >> >>>
> >> > > > >> >>> Thanks,
> >> > > > >> >>>
> >> > > > >> >>> GP Orcullo
> >> > > > >> >>
> >> > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> >> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >> > > > >> >>
> >> > > > >> >> Which then gets stuck on ipipe_send_ipi:
> >> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >> > > > >> >>
> >> > > > >> >
> >> > > > >> > I've traced the issue to the ipipe_processor_id() function. It returns
> >> > > > >> > the value 512 for processor 0. This value comes from cpu node property
> >> > > > >> > of the DT file.
> >> > > > >> >
> >> > > > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >> > > > >> > kernel to boot but it fails the switchtest regression test.
> >> > > > >> >
> >> > > > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> >> > > > >> > and pass all the xenomai regression tests but it generates the
> >> > > > >> > following warning at boot:
> >> > > > >>
> >> > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >> > > > >> of the core.
> >> > > > >>
> >> > > > >> > What's the proper way of fixing this?
> >> > > > >> >
> >> > > > >>
> >> > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >> > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >> > > > >> the opposite.
> >> > > > >>
> >> > > > >> We may have been lucky until now because the physical mapping seems to
> >> > > > >> have always matched the logical order on the SMP SoCs people used with
> >> > > > >> Xenomai so far, it looks like your A5 core does not follow this order.
> >> > > > >
> >> > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> >> > > > > whatever number the boot cpu has
> >> > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> >> > > > > it should work both ways.
> >> > > > > At least, that was true before DT. Now, I find 512 a bit high, are
> >> > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> >> > > > > initialized with DT ?
> >> > > > >
> >> > > > > --
> >> > > > > Gilles.
> >> > > >
> >> > > > cpu_logical_map[] contains these values: {512,1,2,3}
> >> > > >
> >> > > > This is the cpu entry:
> >> > > > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> >> > > >
> >> > > > Changing the reg values alters the contents of cpu_logical_map[].
> >> > >
> >> > > Ok, in that case, to make it work, cpu_logical_map would need to
> >> > > have 513 entries to be able to have cpu_logical_map[512] == 0.
> >> > > Or replace cpu_logical_map with a reverse map which is a copy of
> >> > > cpu_logical_map plus the additional entry to make it work.
> >> > >
> >> > > If you are using an older version of the code, there may be a
> >> > > reference to __cpu_logical_map from the VFP code which you need to
> >> > > replace with __cpu_reverse_map.
> >> > >
> >> > > Please try the following untested patch:
> >> >
> >> > Scrap that. Missing kmalloc, off-by-one error. I am sorry, but I
> >> > will not be able to work on that. Do you get the idea, are you able
> >> > to fix it on your own ?
> >>
> >> Last attempt:
> >
> > We also need to fix hard_smp_processor_id for cpus larger than 255
> > (also the VFP code in old patches).
> > So, the final patch is:
> >
> > diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
> > index 72ad7a4..e920175 100644
> > --- a/arch/arm/include/asm/ipipe_base.h
> > +++ b/arch/arm/include/asm/ipipe_base.h
> > @@ -53,10 +53,10 @@ extern unsigned __ipipe_first_ipi;
> > " mov %0, #0\n" \
> > " .popsection" \
> > : "=r" (cpunum)); \
> > - cpunum &= 0xFF; \
> > + cpunum &= 0xFFFFFF; \
> > })
> > -extern u32 __cpu_logical_map[];
> > -#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
> > +extern u32 *__cpu_reverse_map[];
> > +#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
> >
> > #else /* !legacy */
> > #define hard_smp_processor_id() raw_smp_processor_id()
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index b10f40f..df02a76 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -469,29 +469,33 @@ void notrace cpu_init(void)
> > #endif
> > }
> >
> > -#if NR_CPUS > 16
> > u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
> > -#else
> > -u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
> > -#endif
> > +
> > +u32 *__cpu_reverse_map;
> > +EXPORT_SYMBOL(__cpu_reverse_map);
> >
> > void __init smp_setup_processor_id(void)
> > {
> > int i;
> > u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
> > u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > - u32 max = cpu + 1 > nr_cpu_ids ? cpu + 1 : nr_cpu_ids;
> > + u32 max = nr_cpu_ids > mpidr + 1 ? nr_cpu_ids : mpidr + 1;
> >
> > #ifdef CONFIG_IPIPE
> > /* printk on I-pipe needs per cpu data */
> > set_my_cpu_offset(per_cpu_offset(0));
> > #endif
> > - BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
> >
> > cpu_logical_map(0) = cpu;
> > - for (i = 1; i < max; ++i)
> > + for (i = 1; i < nr_cpu_ids; ++i)
> > cpu_logical_map(i) = i == cpu ? 0 : i;
> >
> > + __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
> > + BUG_ON(!__cpu_reverse_map);
> > +
> > + for (i = 0; i < nr_cpu_ids; i++)
> > + __cpu_reverse_map[cpu_logical_map(i)] = i;
> > +
> > /*
> > * clear __my_cpu_offset on boot CPU to avoid hang caused by
> > * using percpu variable early, for example, lockdep will
> >
> > --
> > Gilles.
>
> The kernel doesn't boot on this one.
Ok, the 512 may not be the real register value, but introduced by
the MPIDR_AFFINITY_LEVEL macro. Could you try the following patch ?
diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
index 72ad7a4..e920175 100644
--- a/arch/arm/include/asm/ipipe_base.h
+++ b/arch/arm/include/asm/ipipe_base.h
@@ -53,10 +53,10 @@ extern unsigned __ipipe_first_ipi;
" mov %0, #0\n" \
" .popsection" \
: "=r" (cpunum)); \
- cpunum &= 0xFF; \
+ cpunum &= 0xFFFFFF; \
})
-extern u32 __cpu_logical_map[];
-#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
+extern u32 *__cpu_reverse_map[];
+#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
#else /* !legacy */
#define hard_smp_processor_id() raw_smp_processor_id()
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b10f40f..3c77609 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -469,29 +469,34 @@ void notrace cpu_init(void)
#endif
}
-#if NR_CPUS > 16
u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
-#else
-u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
-#endif
+
+u32 *__cpu_reverse_map;
+EXPORT_SYMBOL(__cpu_reverse_map);
void __init smp_setup_processor_id(void)
{
int i;
u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
- u32 max = cpu + 1 > nr_cpu_ids ? cpu + 1 : nr_cpu_ids;
+ u32 max = nr_cpu_ids > mpidr + 1 ? nr_cpu_ids : mpidr + 1;
#ifdef CONFIG_IPIPE
/* printk on I-pipe needs per cpu data */
set_my_cpu_offset(per_cpu_offset(0));
#endif
- BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
cpu_logical_map(0) = cpu;
- for (i = 1; i < max; ++i)
+ for (i = 1; i < nr_cpu_ids; ++i)
cpu_logical_map(i) = i == cpu ? 0 : i;
+ __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
+ BUG_ON(!__cpu_reverse_map);
+
+ __cpu_reverse_map[0] = mpidr;
+ for (i = 1; i < max; i++)
+ __cpu_reverse_map[i] = i == mpidr ? 0 : i;
+
/*
* clear __my_cpu_offset on boot CPU to avoid hang caused by
* using percpu variable early, for example, lockdep will
--
Gilles.
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 17:23 ` Gilles Chanteperdrix
@ 2015-03-28 19:14 ` Gilles Chanteperdrix
0 siblings, 0 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 19:14 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 06:23:30PM +0100, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 11:20:05PM +0800, GP Orcullo wrote:
> > On Sat, Mar 28, 2015 at 9:37 PM, Gilles Chanteperdrix
> > <gilles.chanteperdrix@xenomai.org> wrote:
> > > On Sat, Mar 28, 2015 at 02:22:52PM +0100, Gilles Chanteperdrix wrote:
> > >> On Sat, Mar 28, 2015 at 02:12:14PM +0100, Gilles Chanteperdrix wrote:
> > >> > On Sat, Mar 28, 2015 at 02:06:20PM +0100, Gilles Chanteperdrix wrote:
> > >> > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > >> > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > >> > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > >> > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > >> > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > >> > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > >> > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > >> > > > >> >>> What happens in between the clocksource switch and head domain registration?
> > >> > > > >> >>>
> > >> > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > >> > > > >> >>> allocations
> > >> > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > >> > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > >> > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > >> > > > >> >>>
> > >> > > > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > >> > > > >> >>> adding printk to to the set and request functions and the code never
> > >> > > > >> >>> runs when CONFIG_SMP is enabled.
> > >> > > > >> >>>
> > >> > > > >> >>> Thanks,
> > >> > > > >> >>>
> > >> > > > >> >>> GP Orcullo
> > >> > > > >> >>
> > >> > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > >> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > >> > > > >> >>
> > >> > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > >> > > > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > >> > > > >> >>
> > >> > > > >> >
> > >> > > > >> > I've traced the issue to the ipipe_processor_id() function. It returns
> > >> > > > >> > the value 512 for processor 0. This value comes from cpu node property
> > >> > > > >> > of the DT file.
> > >> > > > >> >
> > >> > > > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > >> > > > >> > kernel to boot but it fails the switchtest regression test.
> > >> > > > >> >
> > >> > > > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > >> > > > >> > and pass all the xenomai regression tests but it generates the
> > >> > > > >> > following warning at boot:
> > >> > > > >>
> > >> > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> > >> > > > >> of the core.
> > >> > > > >>
> > >> > > > >> > What's the proper way of fixing this?
> > >> > > > >> >
> > >> > > > >>
> > >> > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > >> > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> > >> > > > >> the opposite.
> > >> > > > >>
> > >> > > > >> We may have been lucky until now because the physical mapping seems to
> > >> > > > >> have always matched the logical order on the SMP SoCs people used with
> > >> > > > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > >> > > > >
> > >> > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > >> > > > > whatever number the boot cpu has
> > >> > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > >> > > > > it should work both ways.
> > >> > > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > >> > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > >> > > > > initialized with DT ?
> > >> > > > >
> > >> > > > > --
> > >> > > > > Gilles.
> > >> > > >
> > >> > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > >> > > >
> > >> > > > This is the cpu entry:
> > >> > > > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> > >> > > >
> > >> > > > Changing the reg values alters the contents of cpu_logical_map[].
> > >> > >
> > >> > > Ok, in that case, to make it work, cpu_logical_map would need to
> > >> > > have 513 entries to be able to have cpu_logical_map[512] == 0.
> > >> > > Or replace cpu_logical_map with a reverse map which is a copy of
> > >> > > cpu_logical_map plus the additional entry to make it work.
> > >> > >
> > >> > > If you are using an older version of the code, there may be a
> > >> > > reference to __cpu_logical_map from the VFP code which you need to
> > >> > > replace with __cpu_reverse_map.
> > >> > >
> > >> > > Please try the following untested patch:
> > >> >
> > >> > Scrap that. Missing kmalloc, off-by-one error. I am sorry, but I
> > >> > will not be able to work on that. Do you get the idea, are you able
> > >> > to fix it on your own ?
> > >>
> > >> Last attempt:
> > >
> > > We also need to fix hard_smp_processor_id for cpus larger than 255
> > > (also the VFP code in old patches).
> > > So, the final patch is:
> > >
> > > diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
> > > index 72ad7a4..e920175 100644
> > > --- a/arch/arm/include/asm/ipipe_base.h
> > > +++ b/arch/arm/include/asm/ipipe_base.h
> > > @@ -53,10 +53,10 @@ extern unsigned __ipipe_first_ipi;
> > > " mov %0, #0\n" \
> > > " .popsection" \
> > > : "=r" (cpunum)); \
> > > - cpunum &= 0xFF; \
> > > + cpunum &= 0xFFFFFF; \
> > > })
> > > -extern u32 __cpu_logical_map[];
> > > -#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
> > > +extern u32 *__cpu_reverse_map[];
> > > +#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
> > >
> > > #else /* !legacy */
> > > #define hard_smp_processor_id() raw_smp_processor_id()
> > > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > > index b10f40f..df02a76 100644
> > > --- a/arch/arm/kernel/setup.c
> > > +++ b/arch/arm/kernel/setup.c
> > > @@ -469,29 +469,33 @@ void notrace cpu_init(void)
> > > #endif
> > > }
> > >
> > > -#if NR_CPUS > 16
> > > u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
> > > -#else
> > > -u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
> > > -#endif
> > > +
> > > +u32 *__cpu_reverse_map;
> > > +EXPORT_SYMBOL(__cpu_reverse_map);
> > >
> > > void __init smp_setup_processor_id(void)
> > > {
> > > int i;
> > > u32 mpidr = is_smp() ? read_cpuid_mpidr() & MPIDR_HWID_BITMASK : 0;
> > > u32 cpu = MPIDR_AFFINITY_LEVEL(mpidr, 0);
> > > - u32 max = cpu + 1 > nr_cpu_ids ? cpu + 1 : nr_cpu_ids;
> > > + u32 max = nr_cpu_ids > mpidr + 1 ? nr_cpu_ids : mpidr + 1;
> > >
> > > #ifdef CONFIG_IPIPE
> > > /* printk on I-pipe needs per cpu data */
> > > set_my_cpu_offset(per_cpu_offset(0));
> > > #endif
> > > - BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
> > >
> > > cpu_logical_map(0) = cpu;
> > > - for (i = 1; i < max; ++i)
> > > + for (i = 1; i < nr_cpu_ids; ++i)
> > > cpu_logical_map(i) = i == cpu ? 0 : i;
> > >
> > > + __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
> > > + BUG_ON(!__cpu_reverse_map);
> > > +
> > > + for (i = 0; i < nr_cpu_ids; i++)
> > > + __cpu_reverse_map[cpu_logical_map(i)] = i;
> > > +
> > > /*
> > > * clear __my_cpu_offset on boot CPU to avoid hang caused by
> > > * using percpu variable early, for example, lockdep will
> > >
> > > --
> > > Gilles.
> >
> > The kernel doesn't boot on this one.
>
> Ok, the 512 may not be the real register value, but introduced by
> the MPIDR_AFFINITY_LEVEL macro. Could you try the following patch ?
Scrap that patch. There is something wrong in your kernel tree:
the mpidr of the boot processor may be 512, but it should not be a
problem, because it is masked with 0xff. So in fact 512 becomes 0,
and the cpu_logical_map is not the problem. Since all the I-pipe
code also masks the mpidr with 0xff, neither the vfp code, nor the
percpu code should have any issue.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 12:27 ` GP Orcullo
2015-03-28 13:06 ` Gilles Chanteperdrix
@ 2015-03-28 13:53 ` Gilles Chanteperdrix
2015-03-28 14:56 ` Gilles Chanteperdrix
2015-03-28 18:59 ` Gilles Chanteperdrix
2 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 13:53 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> >>> What happens in between the clocksource switch and head domain registration?
> >> >>>
> >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >> >>> allocations
> >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >> >>> [ 0.124618] Xenomai: hal/arm started.
> >> >>>
> >> >>> I'm trying to trace the code to find out where it stops. I tried
> >> >>> adding printk to to the set and request functions and the code never
> >> >>> runs when CONFIG_SMP is enabled.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> GP Orcullo
> >> >>
> >> >> It gets stuck on the call to ipipe_critical_enter:
> >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >> >>
> >> >> Which then gets stuck on ipipe_send_ipi:
> >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >> >>
> >> >
> >> > I've traced the issue to the ipipe_processor_id() function. It returns
> >> > the value 512 for processor 0. This value comes from cpu node property
> >> > of the DT file.
> >> >
> >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >> > kernel to boot but it fails the switchtest regression test.
> >> >
> >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> >> > and pass all the xenomai regression tests but it generates the
> >> > following warning at boot:
> >>
> >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >> of the core.
> >>
> >> > What's the proper way of fixing this?
> >> >
> >>
> >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >> the opposite.
> >>
> >> We may have been lucky until now because the physical mapping seems to
> >> have always matched the logical order on the SMP SoCs people used with
> >> Xenomai so far, it looks like your A5 core does not follow this order.
> >
> > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > whatever number the boot cpu has
> > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > it should work both ways.
> > At least, that was true before DT. Now, I find 512 a bit high, are
> > you sure cpu_logical_map[] is large enough ? Or is it even
> > initialized with DT ?
> >
> > --
> > Gilles.
>
> cpu_logical_map[] contains these values: {512,1,2,3}
>
> This is the cpu entry:
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
>
> Changing the reg values alters the contents of cpu_logical_map[].
Actually, the code as it existed should either have worked, or bug
because 512 is larger than __cpu_logical_map size (the largest of 16
and NR_CPUS).
I think the only problem with the current code is the mask with 0xFF
in hard_smp_processor_id(), which forbids ids above 255.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 13:53 ` Gilles Chanteperdrix
@ 2015-03-28 14:56 ` Gilles Chanteperdrix
2015-03-28 15:17 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 14:56 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 02:53:03PM +0100, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > <gilles.chanteperdrix@xenomai.org> wrote:
> > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> > >> >>> What happens in between the clocksource switch and head domain registration?
> > >> >>>
> > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > >> >>> allocations
> > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > >> >>>
> > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > >> >>> adding printk to to the set and request functions and the code never
> > >> >>> runs when CONFIG_SMP is enabled.
> > >> >>>
> > >> >>> Thanks,
> > >> >>>
> > >> >>> GP Orcullo
> > >> >>
> > >> >> It gets stuck on the call to ipipe_critical_enter:
> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > >> >>
> > >> >> Which then gets stuck on ipipe_send_ipi:
> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > >> >>
> > >> >
> > >> > I've traced the issue to the ipipe_processor_id() function. It returns
> > >> > the value 512 for processor 0. This value comes from cpu node property
> > >> > of the DT file.
> > >> >
> > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > >> > kernel to boot but it fails the switchtest regression test.
> > >> >
> > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > >> > and pass all the xenomai regression tests but it generates the
> > >> > following warning at boot:
> > >>
> > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> > >> of the core.
> > >>
> > >> > What's the proper way of fixing this?
> > >> >
> > >>
> > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> > >> the opposite.
> > >>
> > >> We may have been lucky until now because the physical mapping seems to
> > >> have always matched the logical order on the SMP SoCs people used with
> > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > >
> > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > whatever number the boot cpu has
> > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > it should work both ways.
> > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > initialized with DT ?
> > >
> > > --
> > > Gilles.
> >
> > cpu_logical_map[] contains these values: {512,1,2,3}
> >
> > This is the cpu entry:
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> >
> > Changing the reg values alters the contents of cpu_logical_map[].
>
> Actually, the code as it existed should either have worked, or bug
> because 512 is larger than __cpu_logical_map size (the largest of 16
> and NR_CPUS).
This is bugging me, if the kernel does not print a bug in
smp_setup_processor_id, it means that NR_CPUS is sufficiently large,
so larger than 512. How much is the compilation constant
CONFIG_NR_CPUS in your kernel configuration ?
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 14:56 ` Gilles Chanteperdrix
@ 2015-03-28 15:17 ` GP Orcullo
2015-03-28 15:19 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-28 15:17 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 10:56 PM, Gilles Chanteperdrix
<gilles.chanteperdrix@xenomai.org> wrote:
> On Sat, Mar 28, 2015 at 02:53:03PM +0100, Gilles Chanteperdrix wrote:
>> On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
>> > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
>> > <gilles.chanteperdrix@xenomai.org> wrote:
>> > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>> > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>> > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>> > >> >>> What happens in between the clocksource switch and head domain registration?
>> > >> >>>
>> > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>> > >> >>> allocations
>> > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
>> > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
>> > >> >>> [ 0.124618] Xenomai: hal/arm started.
>> > >> >>>
>> > >> >>> I'm trying to trace the code to find out where it stops. I tried
>> > >> >>> adding printk to to the set and request functions and the code never
>> > >> >>> runs when CONFIG_SMP is enabled.
>> > >> >>>
>> > >> >>> Thanks,
>> > >> >>>
>> > >> >>> GP Orcullo
>> > >> >>
>> > >> >> It gets stuck on the call to ipipe_critical_enter:
>> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>> > >> >>
>> > >> >> Which then gets stuck on ipipe_send_ipi:
>> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>> > >> >>
>> > >> >
>> > >> > I've traced the issue to the ipipe_processor_id() function. It returns
>> > >> > the value 512 for processor 0. This value comes from cpu node property
>> > >> > of the DT file.
>> > >> >
>> > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
>> > >> > kernel to boot but it fails the switchtest regression test.
>> > >> >
>> > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
>> > >> > and pass all the xenomai regression tests but it generates the
>> > >> > following warning at boot:
>> > >>
>> > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
>> > >> of the core.
>> > >>
>> > >> > What's the proper way of fixing this?
>> > >> >
>> > >>
>> > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
>> > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
>> > >> the opposite.
>> > >>
>> > >> We may have been lucky until now because the physical mapping seems to
>> > >> have always matched the logical order on the SMP SoCs people used with
>> > >> Xenomai so far, it looks like your A5 core does not follow this order.
>> > >
>> > > No, cpu_logical_map works both ways, it simply exchanges 0 with
>> > > whatever number the boot cpu has
>> > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
>> > > it should work both ways.
>> > > At least, that was true before DT. Now, I find 512 a bit high, are
>> > > you sure cpu_logical_map[] is large enough ? Or is it even
>> > > initialized with DT ?
>> > >
>> > > --
>> > > Gilles.
>> >
>> > cpu_logical_map[] contains these values: {512,1,2,3}
>> >
>> > This is the cpu entry:
>> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
>> >
>> > Changing the reg values alters the contents of cpu_logical_map[].
>>
>> Actually, the code as it existed should either have worked, or bug
>> because 512 is larger than __cpu_logical_map size (the largest of 16
>> and NR_CPUS).
>
> This is bugging me, if the kernel does not print a bug in
> smp_setup_processor_id, it means that NR_CPUS is sufficiently large,
> so larger than 512. How much is the compilation constant
> CONFIG_NR_CPUS in your kernel configuration ?
>
> --
> Gilles.
CONFIG_NR_CPUS is still 4.
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 15:17 ` GP Orcullo
@ 2015-03-28 15:19 ` Gilles Chanteperdrix
2015-03-28 15:56 ` GP Orcullo
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 15:19 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 11:17:24PM +0800, GP Orcullo wrote:
> On Sat, Mar 28, 2015 at 10:56 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Sat, Mar 28, 2015 at 02:53:03PM +0100, Gilles Chanteperdrix wrote:
> >> On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> >> > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> >> > <gilles.chanteperdrix@xenomai.org> wrote:
> >> > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >> > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >> > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> > >> >>> What happens in between the clocksource switch and head domain registration?
> >> > >> >>>
> >> > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >> > >> >>> allocations
> >> > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> >> > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >> > >> >>> [ 0.124618] Xenomai: hal/arm started.
> >> > >> >>>
> >> > >> >>> I'm trying to trace the code to find out where it stops. I tried
> >> > >> >>> adding printk to to the set and request functions and the code never
> >> > >> >>> runs when CONFIG_SMP is enabled.
> >> > >> >>>
> >> > >> >>> Thanks,
> >> > >> >>>
> >> > >> >>> GP Orcullo
> >> > >> >>
> >> > >> >> It gets stuck on the call to ipipe_critical_enter:
> >> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >> > >> >>
> >> > >> >> Which then gets stuck on ipipe_send_ipi:
> >> > >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >> > >> >>
> >> > >> >
> >> > >> > I've traced the issue to the ipipe_processor_id() function. It returns
> >> > >> > the value 512 for processor 0. This value comes from cpu node property
> >> > >> > of the DT file.
> >> > >> >
> >> > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >> > >> > kernel to boot but it fails the switchtest regression test.
> >> > >> >
> >> > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> >> > >> > and pass all the xenomai regression tests but it generates the
> >> > >> > following warning at boot:
> >> > >>
> >> > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >> > >> of the core.
> >> > >>
> >> > >> > What's the proper way of fixing this?
> >> > >> >
> >> > >>
> >> > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >> > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >> > >> the opposite.
> >> > >>
> >> > >> We may have been lucky until now because the physical mapping seems to
> >> > >> have always matched the logical order on the SMP SoCs people used with
> >> > >> Xenomai so far, it looks like your A5 core does not follow this order.
> >> > >
> >> > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> >> > > whatever number the boot cpu has
> >> > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> >> > > it should work both ways.
> >> > > At least, that was true before DT. Now, I find 512 a bit high, are
> >> > > you sure cpu_logical_map[] is large enough ? Or is it even
> >> > > initialized with DT ?
> >> > >
> >> > > --
> >> > > Gilles.
> >> >
> >> > cpu_logical_map[] contains these values: {512,1,2,3}
> >> >
> >> > This is the cpu entry:
> >> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> >> >
> >> > Changing the reg values alters the contents of cpu_logical_map[].
> >>
> >> Actually, the code as it existed should either have worked, or bug
> >> because 512 is larger than __cpu_logical_map size (the largest of 16
> >> and NR_CPUS).
> >
> > This is bugging me, if the kernel does not print a bug in
> > smp_setup_processor_id, it means that NR_CPUS is sufficiently large,
> > so larger than 512. How much is the compilation constant
> > CONFIG_NR_CPUS in your kernel configuration ?
> >
> > --
> > Gilles.
>
> CONFIG_NR_CPUS is still 4.
Could you show us the code of the smp_setup_processor_id function in
the source tree of the kernel you compile ? It can be found in
arch/arm/kernel/secup.c
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 15:19 ` Gilles Chanteperdrix
@ 2015-03-28 15:56 ` GP Orcullo
2015-03-28 16:02 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-28 15:56 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 11:19 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:
> On Sat, Mar 28, 2015 at 11:17:24PM +0800, GP Orcullo wrote:
>> On Sat, Mar 28, 2015 at 10:56 PM, Gilles Chanteperdrix
>> <gilles.chanteperdrix@xenomai.org> wrote:
>> > On Sat, Mar 28, 2015 at 02:53:03PM +0100, Gilles Chanteperdrix wrote:
>> >> On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
>> >> > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
>> >> > <gilles.chanteperdrix@xenomai.org> wrote:
>> >> > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>> >> > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>> >> > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
kinsamanka@gmail.com> wrote:
>> >> > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
kinsamanka@gmail.com> wrote:
>> >> > >> >>> What happens in between the clocksource switch and head
domain registration?
>> >> > >> >>>
>> >> > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
coherent
>> >> > >> >>> allocations
>> >> > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
>> >> > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
>> >> > >> >>> [ 0.124618] Xenomai: hal/arm started.
>> >> > >> >>>
>> >> > >> >>> I'm trying to trace the code to find out where it stops. I
tried
>> >> > >> >>> adding printk to to the set and request functions and the
code never
>> >> > >> >>> runs when CONFIG_SMP is enabled.
>> >> > >> >>>
>> >> > >> >>> Thanks,
>> >> > >> >>>
>> >> > >> >>> GP Orcullo
>> >> > >> >>
>> >> > >> >> It gets stuck on the call to ipipe_critical_enter:
>> >> > >> >>
http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>> >> > >> >>
>> >> > >> >> Which then gets stuck on ipipe_send_ipi:
>> >> > >> >>
http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>> >> > >> >>
>> >> > >> >
>> >> > >> > I've traced the issue to the ipipe_processor_id() function. It
returns
>> >> > >> > the value 512 for processor 0. This value comes from cpu node
property
>> >> > >> > of the DT file.
>> >> > >> >
>> >> > >> > Changing ipipe_processor_id() to return 0 instead of 512
allows the
>> >> > >> > kernel to boot but it fails the switchtest regression test.
>> >> > >> >
>> >> > >> > Changing the cpu0 reg value on the DT file allows the kernel
to boot
>> >> > >> > and pass all the xenomai regression tests but it generates the
>> >> > >> > following warning at boot:
>> >> > >>
>> >> > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
physical id
>> >> > >> of the core.
>> >> > >>
>> >> > >> > What's the proper way of fixing this?
>> >> > >> >
>> >> > >>
>> >> > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
broken.
>> >> > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
actually
>> >> > >> the opposite.
>> >> > >>
>> >> > >> We may have been lucky until now because the physical mapping
seems to
>> >> > >> have always matched the logical order on the SMP SoCs people
used with
>> >> > >> Xenomai so far, it looks like your A5 core does not follow this
order.
>> >> > >
>> >> > > No, cpu_logical_map works both ways, it simply exchanges 0 with
>> >> > > whatever number the boot cpu has
>> >> > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
>> >> > > it should work both ways.
>> >> > > At least, that was true before DT. Now, I find 512 a bit high, are
>> >> > > you sure cpu_logical_map[] is large enough ? Or is it even
>> >> > > initialized with DT ?
>> >> > >
>> >> > > --
>> >> > > Gilles.
>> >> >
>> >> > cpu_logical_map[] contains these values: {512,1,2,3}
>> >> >
>> >> > This is the cpu entry:
>> >> >
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
>> >> >
>> >> > Changing the reg values alters the contents of cpu_logical_map[].
>> >>
>> >> Actually, the code as it existed should either have worked, or bug
>> >> because 512 is larger than __cpu_logical_map size (the largest of 16
>> >> and NR_CPUS).
>> >
>> > This is bugging me, if the kernel does not print a bug in
>> > smp_setup_processor_id, it means that NR_CPUS is sufficiently large,
>> > so larger than 512. How much is the compilation constant
>> > CONFIG_NR_CPUS in your kernel configuration ?
>> >
>> > --
>> > Gilles.
>>
>> CONFIG_NR_CPUS is still 4.
>
> Could you show us the code of the smp_setup_processor_id function in
> the source tree of the kernel you compile ? It can be found in
> arch/arm/kernel/secup.c
>
>
> --
> Gilles.
The orignal code is standard, no changes on that function:
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/setup.c#L449
Bit [11:8] of the MPIDR is actually the cluster ID; the maximum cpus is
still 4 for Cortex-A5.
I'm not sure if this is relevant here:
http://www.spinics.net/lists/arm-kernel/msg221730.html
> With commit a0ae0240 (ARM: kernel: add device tree init map function),
> the cpu id value may include the cluster id and is no longer 0-3, so we
> need to mask it in scu_power_mode to get the local cpu number. Since we
> are only dealing with the cpu we are running on, the cluster id should
> not ever be needed.
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 15:56 ` GP Orcullo
@ 2015-03-28 16:02 ` Gilles Chanteperdrix
0 siblings, 0 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 16:02 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 11:56:33PM +0800, GP Orcullo wrote:
> On Sat, Mar 28, 2015 at 11:19 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
> > On Sat, Mar 28, 2015 at 11:17:24PM +0800, GP Orcullo wrote:
> >> On Sat, Mar 28, 2015 at 10:56 PM, Gilles Chanteperdrix
> >> <gilles.chanteperdrix@xenomai.org> wrote:
> >> > On Sat, Mar 28, 2015 at 02:53:03PM +0100, Gilles Chanteperdrix wrote:
> >> >> On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> >> >> > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> >> >> > <gilles.chanteperdrix@xenomai.org> wrote:
> >> >> > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >> >> > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >> >> > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
> kinsamanka@gmail.com> wrote:
> >> >> > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
> kinsamanka@gmail.com> wrote:
> >> >> > >> >>> What happens in between the clocksource switch and head
> domain registration?
> >> >> > >> >>>
> >> >> > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
> coherent
> >> >> > >> >>> allocations
> >> >> > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> >> >> > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >> >> > >> >>> [ 0.124618] Xenomai: hal/arm started.
> >> >> > >> >>>
> >> >> > >> >>> I'm trying to trace the code to find out where it stops. I
> tried
> >> >> > >> >>> adding printk to to the set and request functions and the
> code never
> >> >> > >> >>> runs when CONFIG_SMP is enabled.
> >> >> > >> >>>
> >> >> > >> >>> Thanks,
> >> >> > >> >>>
> >> >> > >> >>> GP Orcullo
> >> >> > >> >>
> >> >> > >> >> It gets stuck on the call to ipipe_critical_enter:
> >> >> > >> >>
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >> >> > >> >>
> >> >> > >> >> Which then gets stuck on ipipe_send_ipi:
> >> >> > >> >>
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >> >> > >> >>
> >> >> > >> >
> >> >> > >> > I've traced the issue to the ipipe_processor_id() function. It
> returns
> >> >> > >> > the value 512 for processor 0. This value comes from cpu node
> property
> >> >> > >> > of the DT file.
> >> >> > >> >
> >> >> > >> > Changing ipipe_processor_id() to return 0 instead of 512
> allows the
> >> >> > >> > kernel to boot but it fails the switchtest regression test.
> >> >> > >> >
> >> >> > >> > Changing the cpu0 reg value on the DT file allows the kernel
> to boot
> >> >> > >> > and pass all the xenomai regression tests but it generates the
> >> >> > >> > following warning at boot:
> >> >> > >>
> >> >> > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
> physical id
> >> >> > >> of the core.
> >> >> > >>
> >> >> > >> > What's the proper way of fixing this?
> >> >> > >> >
> >> >> > >>
> >> >> > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
> broken.
> >> >> > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> actually
> >> >> > >> the opposite.
> >> >> > >>
> >> >> > >> We may have been lucky until now because the physical mapping
> seems to
> >> >> > >> have always matched the logical order on the SMP SoCs people
> used with
> >> >> > >> Xenomai so far, it looks like your A5 core does not follow this
> order.
> >> >> > >
> >> >> > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> >> >> > > whatever number the boot cpu has
> >> >> > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> >> >> > > it should work both ways.
> >> >> > > At least, that was true before DT. Now, I find 512 a bit high, are
> >> >> > > you sure cpu_logical_map[] is large enough ? Or is it even
> >> >> > > initialized with DT ?
> >> >> > >
> >> >> > > --
> >> >> > > Gilles.
> >> >> >
> >> >> > cpu_logical_map[] contains these values: {512,1,2,3}
> >> >> >
> >> >> > This is the cpu entry:
> >> >> >
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/boot/dts/meson8b_odroidc.dts#L9-L32
> >> >> >
> >> >> > Changing the reg values alters the contents of cpu_logical_map[].
> >> >>
> >> >> Actually, the code as it existed should either have worked, or bug
> >> >> because 512 is larger than __cpu_logical_map size (the largest of 16
> >> >> and NR_CPUS).
> >> >
> >> > This is bugging me, if the kernel does not print a bug in
> >> > smp_setup_processor_id, it means that NR_CPUS is sufficiently large,
> >> > so larger than 512. How much is the compilation constant
> >> > CONFIG_NR_CPUS in your kernel configuration ?
> >> >
> >> > --
> >> > Gilles.
> >>
> >> CONFIG_NR_CPUS is still 4.
> >
> > Could you show us the code of the smp_setup_processor_id function in
> > the source tree of the kernel you compile ? It can be found in
> > arch/arm/kernel/secup.c
> >
> >
> > --
> > Gilles.
>
> The orignal code is standard, no changes on that function:
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/setup.c#L449
Then that is the problem, because it should have been patched by the
I-pipe patch. Or maybe you mean before applying the I-pipe patch ?
What I am interested in is the code you are actually compiling, so,
after applying the I-pipe patch.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 12:27 ` GP Orcullo
2015-03-28 13:06 ` Gilles Chanteperdrix
2015-03-28 13:53 ` Gilles Chanteperdrix
@ 2015-03-28 18:59 ` Gilles Chanteperdrix
2015-03-28 22:38 ` GP Orcullo
2 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 18:59 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> <gilles.chanteperdrix@xenomai.org> wrote:
> > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >> >>> What happens in between the clocksource switch and head domain registration?
> >> >>>
> >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >> >>> allocations
> >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >> >>> [ 0.124618] Xenomai: hal/arm started.
> >> >>>
> >> >>> I'm trying to trace the code to find out where it stops. I tried
> >> >>> adding printk to to the set and request functions and the code never
> >> >>> runs when CONFIG_SMP is enabled.
> >> >>>
> >> >>> Thanks,
> >> >>>
> >> >>> GP Orcullo
> >> >>
> >> >> It gets stuck on the call to ipipe_critical_enter:
> >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >> >>
> >> >> Which then gets stuck on ipipe_send_ipi:
> >> >> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >> >>
> >> >
> >> > I've traced the issue to the ipipe_processor_id() function. It returns
> >> > the value 512 for processor 0. This value comes from cpu node property
> >> > of the DT file.
> >> >
> >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >> > kernel to boot but it fails the switchtest regression test.
> >> >
> >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> >> > and pass all the xenomai regression tests but it generates the
> >> > following warning at boot:
> >>
> >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >> of the core.
> >>
> >> > What's the proper way of fixing this?
> >> >
> >>
> >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >> the opposite.
> >>
> >> We may have been lucky until now because the physical mapping seems to
> >> have always matched the logical order on the SMP SoCs people used with
> >> Xenomai so far, it looks like your A5 core does not follow this order.
> >
> > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > whatever number the boot cpu has
> > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > it should work both ways.
> > At least, that was true before DT. Now, I find 512 a bit high, are
> > you sure cpu_logical_map[] is large enough ? Or is it even
> > initialized with DT ?
> >
> > --
> > Gilles.
>
> cpu_logical_map[] contains these values: {512,1,2,3}
Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes the
cluster ID in fact. So, I do not see how you can get 512 here.
Please show us the smp_setup_processor_id function you compile. Or
maybe the __cpu_logical_map array is not initialized by this
function in your case?
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 18:59 ` Gilles Chanteperdrix
@ 2015-03-28 22:38 ` GP Orcullo
2015-03-29 11:06 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-28 22:38 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:
> On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > <gilles.chanteperdrix@xenomai.org> wrote:
> > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com>
> wrote:
> > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com>
> wrote:
> > >> >>> What happens in between the clocksource switch and head domain
> registration?
> > >> >>>
> > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > >> >>> allocations
> > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > >> >>>
> > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > >> >>> adding printk to to the set and request functions and the code
> never
> > >> >>> runs when CONFIG_SMP is enabled.
> > >> >>>
> > >> >>> Thanks,
> > >> >>>
> > >> >>> GP Orcullo
> > >> >>
> > >> >> It gets stuck on the call to ipipe_critical_enter:
> > >> >>
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > >> >>
> > >> >> Which then gets stuck on ipipe_send_ipi:
> > >> >>
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > >> >>
> > >> >
> > >> > I've traced the issue to the ipipe_processor_id() function. It
> returns
> > >> > the value 512 for processor 0. This value comes from cpu node
> property
> > >> > of the DT file.
> > >> >
> > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > >> > kernel to boot but it fails the switchtest regression test.
> > >> >
> > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > >> > and pass all the xenomai regression tests but it generates the
> > >> > following warning at boot:
> > >>
> > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical
> id
> > >> of the core.
> > >>
> > >> > What's the proper way of fixing this?
> > >> >
> > >>
> > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> actually
> > >> the opposite.
> > >>
> > >> We may have been lucky until now because the physical mapping seems to
> > >> have always matched the logical order on the SMP SoCs people used with
> > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > >
> > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > whatever number the boot cpu has
> > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > it should work both ways.
> > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > initialized with DT ?
> > >
> > > --
> > > Gilles.
> >
> > cpu_logical_map[] contains these values: {512,1,2,3}
>
> Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes the
> cluster ID in fact. So, I do not see how you can get 512 here.
>
> Please show us the smp_setup_processor_id function you compile. Or
> maybe the __cpu_logical_map array is not initialized by this
> function in your case?
>
> --
> Gilles.
>
The array is filled up with entries from the DT, it is done here:
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
Changing the DT entry for CPU0 allowed the kernel to boot but it fails the
test here:
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 22:38 ` GP Orcullo
@ 2015-03-29 11:06 ` Gilles Chanteperdrix
2015-03-29 11:59 ` GP Orcullo
2015-03-29 12:18 ` Gilles Chanteperdrix
0 siblings, 2 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-29 11:06 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
> > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com>
> > wrote:
> > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com>
> > wrote:
> > > >> >>> What happens in between the clocksource switch and head domain
> > registration?
> > > >> >>>
> > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > > >> >>> allocations
> > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > >> >>>
> > > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > > >> >>> adding printk to to the set and request functions and the code
> > never
> > > >> >>> runs when CONFIG_SMP is enabled.
> > > >> >>>
> > > >> >>> Thanks,
> > > >> >>>
> > > >> >>> GP Orcullo
> > > >> >>
> > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > >> >>
> > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > >> >>
> > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > >> >>
> > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > >> >>
> > > >> >
> > > >> > I've traced the issue to the ipipe_processor_id() function. It
> > returns
> > > >> > the value 512 for processor 0. This value comes from cpu node
> > property
> > > >> > of the DT file.
> > > >> >
> > > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > > >> > kernel to boot but it fails the switchtest regression test.
> > > >> >
> > > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > > >> > and pass all the xenomai regression tests but it generates the
> > > >> > following warning at boot:
> > > >>
> > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical
> > id
> > > >> of the core.
> > > >>
> > > >> > What's the proper way of fixing this?
> > > >> >
> > > >>
> > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > actually
> > > >> the opposite.
> > > >>
> > > >> We may have been lucky until now because the physical mapping seems to
> > > >> have always matched the logical order on the SMP SoCs people used with
> > > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > > >
> > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > whatever number the boot cpu has
> > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > > it should work both ways.
> > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > initialized with DT ?
> > > >
> > > > --
> > > > Gilles.
> > >
> > > cpu_logical_map[] contains these values: {512,1,2,3}
> >
> > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes the
> > cluster ID in fact. So, I do not see how you can get 512 here.
> >
> > Please show us the smp_setup_processor_id function you compile. Or
> > maybe the __cpu_logical_map array is not initialized by this
> > function in your case?
> >
> > --
> > Gilles.
> >
> The array is filled up with entries from the DT, it is done here:
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
>
> Changing the DT entry for CPU0 allowed the kernel to boot but it fails the
> test here:
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
Yes, obviously, since the MPIDR of your boot cpu is 512. This should
get xenomai working however, since then the logical map is not
overridden and works as patched by the I-pipe code.
Could you get the MPIDR of the other cores ? I suspect they are 513,
514, 515, and not 1 2 3.
We have two choices:
1- admit that with Xenomai 2.6, we will only support one cluster ID,
and only replace the logical map with a reverse map for your case,
continuing masking with 0xff in I-pipe code;
2- build a complete reverse map, probably using two maps, a cluster
map which gives a pointer to a per-cpu reverse map, the reverse map
being implemented for each cluster, and mask with 0xffffff in
I-pipe code.
I can try and send a new patch for choice 1.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 11:06 ` Gilles Chanteperdrix
@ 2015-03-29 11:59 ` GP Orcullo
2015-03-29 12:02 ` Gilles Chanteperdrix
2015-03-29 12:18 ` Gilles Chanteperdrix
1 sibling, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-29 11:59 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai
On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
gilles.chanteperdrix@xenomai.org> wrote:
>
> On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
kinsamanka@gmail.com>
> > > wrote:
> > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
kinsamanka@gmail.com>
> > > wrote:
> > > > >> >>> What happens in between the clocksource switch and head
domain
> > > registration?
> > > > >> >>>
> > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
coherent
> > > > >> >>> allocations
> > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > >> >>>
> > > > >> >>> I'm trying to trace the code to find out where it stops. I
tried
> > > > >> >>> adding printk to to the set and request functions and the
code
> > > never
> > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > >> >>>
> > > > >> >>> Thanks,
> > > > >> >>>
> > > > >> >>> GP Orcullo
> > > > >> >>
> > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > >> >>
> > >
http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > >> >>
> > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > >> >>
> > >
http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > >> >>
> > > > >> >
> > > > >> > I've traced the issue to the ipipe_processor_id() function. It
> > > returns
> > > > >> > the value 512 for processor 0. This value comes from cpu node
> > > property
> > > > >> > of the DT file.
> > > > >> >
> > > > >> > Changing ipipe_processor_id() to return 0 instead of 512
allows the
> > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > >> >
> > > > >> > Changing the cpu0 reg value on the DT file allows the kernel
to boot
> > > > >> > and pass all the xenomai regression tests but it generates the
> > > > >> > following warning at boot:
> > > > >>
> > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
physical
> > > id
> > > > >> of the core.
> > > > >>
> > > > >> > What's the proper way of fixing this?
> > > > >> >
> > > > >>
> > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
broken.
> > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > > actually
> > > > >> the opposite.
> > > > >>
> > > > >> We may have been lucky until now because the physical mapping
seems to
> > > > >> have always matched the logical order on the SMP SoCs people
used with
> > > > >> Xenomai so far, it looks like your A5 core does not follow this
order.
> > > > >
> > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > whatever number the boot cpu has
> > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > > > it should work both ways.
> > > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > initialized with DT ?
> > > > >
> > > > > --
> > > > > Gilles.
> > > >
> > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > >
> > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes the
> > > cluster ID in fact. So, I do not see how you can get 512 here.
> > >
> > > Please show us the smp_setup_processor_id function you compile. Or
> > > maybe the __cpu_logical_map array is not initialized by this
> > > function in your case?
> > >
> > > --
> > > Gilles.
> > >
> > The array is filled up with entries from the DT, it is done here:
> >
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> >
> > Changing the DT entry for CPU0 allowed the kernel to boot but it fails
the
> > test here:
> >
https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
>
> Yes, obviously, since the MPIDR of your boot cpu is 512. This should
> get xenomai working however, since then the logical map is not
> overridden and works as patched by the I-pipe code.
>
> Could you get the MPIDR of the other cores ? I suspect they are 513,
> 514, 515, and not 1 2 3.
Tried this and the 3 cpus won't boot.
>
> We have two choices:
> 1- admit that with Xenomai 2.6, we will only support one cluster ID,
> and only replace the logical map with a reverse map for your case,
> continuing masking with 0xff in I-pipe code;
> 2- build a complete reverse map, probably using two maps, a cluster
> map which gives a pointer to a per-cpu reverse map, the reverse map
> being implemented for each cluster, and mask with 0xffffff in
> I-pipe code.
>
> I can try and send a new patch for choice 1.
>
> --
> Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 11:59 ` GP Orcullo
@ 2015-03-29 12:02 ` Gilles Chanteperdrix
2015-03-29 12:09 ` Gilles Chanteperdrix
2015-03-29 12:38 ` GP Orcullo
0 siblings, 2 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-29 12:02 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai
On Sun, Mar 29, 2015 at 07:59:13PM +0800, GP Orcullo wrote:
> On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
> gilles.chanteperdrix@xenomai.org> wrote:
> >
> > On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > > gilles.chanteperdrix@xenomai.org> wrote:
> > >
> > > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
> kinsamanka@gmail.com>
> > > > wrote:
> > > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
> kinsamanka@gmail.com>
> > > > wrote:
> > > > > >> >>> What happens in between the clocksource switch and head
> domain
> > > > registration?
> > > > > >> >>>
> > > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
> coherent
> > > > > >> >>> allocations
> > > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > > >> >>>
> > > > > >> >>> I'm trying to trace the code to find out where it stops. I
> tried
> > > > > >> >>> adding printk to to the set and request functions and the
> code
> > > > never
> > > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > > >> >>>
> > > > > >> >>> Thanks,
> > > > > >> >>>
> > > > > >> >>> GP Orcullo
> > > > > >> >>
> > > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > > >> >>
> > > >
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > > >> >>
> > > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > > >> >>
> > > >
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > > >> >>
> > > > > >> >
> > > > > >> > I've traced the issue to the ipipe_processor_id() function. It
> > > > returns
> > > > > >> > the value 512 for processor 0. This value comes from cpu node
> > > > property
> > > > > >> > of the DT file.
> > > > > >> >
> > > > > >> > Changing ipipe_processor_id() to return 0 instead of 512
> allows the
> > > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > > >> >
> > > > > >> > Changing the cpu0 reg value on the DT file allows the kernel
> to boot
> > > > > >> > and pass all the xenomai regression tests but it generates the
> > > > > >> > following warning at boot:
> > > > > >>
> > > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
> physical
> > > > id
> > > > > >> of the core.
> > > > > >>
> > > > > >> > What's the proper way of fixing this?
> > > > > >> >
> > > > > >>
> > > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
> broken.
> > > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > > > actually
> > > > > >> the opposite.
> > > > > >>
> > > > > >> We may have been lucky until now because the physical mapping
> seems to
> > > > > >> have always matched the logical order on the SMP SoCs people
> used with
> > > > > >> Xenomai so far, it looks like your A5 core does not follow this
> order.
> > > > > >
> > > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > > whatever number the boot cpu has
> > > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > > > > it should work both ways.
> > > > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > > initialized with DT ?
> > > > > >
> > > > > > --
> > > > > > Gilles.
> > > > >
> > > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > > >
> > > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes the
> > > > cluster ID in fact. So, I do not see how you can get 512 here.
> > > >
> > > > Please show us the smp_setup_processor_id function you compile. Or
> > > > maybe the __cpu_logical_map array is not initialized by this
> > > > function in your case?
> > > >
> > > > --
> > > > Gilles.
> > > >
> > > The array is filled up with entries from the DT, it is done here:
> > >
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> > >
> > > Changing the DT entry for CPU0 allowed the kernel to boot but it fails
> the
> > > test here:
> > >
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
> >
> > Yes, obviously, since the MPIDR of your boot cpu is 512. This should
> > get xenomai working however, since then the logical map is not
> > overridden and works as patched by the I-pipe code.
> >
> > Could you get the MPIDR of the other cores ? I suspect they are 513,
> > 514, 515, and not 1 2 3.
>
> Tried this and the 3 cpus won't boot.
You mean adding a printk in secondary_start_kernel to print the
mpidr fails ? Sounds strange.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 12:02 ` Gilles Chanteperdrix
@ 2015-03-29 12:09 ` Gilles Chanteperdrix
2015-03-29 12:38 ` GP Orcullo
1 sibling, 0 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-29 12:09 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai
On Sun, Mar 29, 2015 at 02:02:18PM +0200, Gilles Chanteperdrix wrote:
> On Sun, Mar 29, 2015 at 07:59:13PM +0800, GP Orcullo wrote:
> > On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
> > gilles.chanteperdrix@xenomai.org> wrote:
> > >
> > > On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > > > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > > > gilles.chanteperdrix@xenomai.org> wrote:
> > > >
> > > > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
> > kinsamanka@gmail.com>
> > > > > wrote:
> > > > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
> > kinsamanka@gmail.com>
> > > > > wrote:
> > > > > > >> >>> What happens in between the clocksource switch and head
> > domain
> > > > > registration?
> > > > > > >> >>>
> > > > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
> > coherent
> > > > > > >> >>> allocations
> > > > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > > > >> >>>
> > > > > > >> >>> I'm trying to trace the code to find out where it stops. I
> > tried
> > > > > > >> >>> adding printk to to the set and request functions and the
> > code
> > > > > never
> > > > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > > > >> >>>
> > > > > > >> >>> Thanks,
> > > > > > >> >>>
> > > > > > >> >>> GP Orcullo
> > > > > > >> >>
> > > > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > > > >> >>
> > > > >
> > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > > > >> >>
> > > > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > > > >> >>
> > > > >
> > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > > > >> >>
> > > > > > >> >
> > > > > > >> > I've traced the issue to the ipipe_processor_id() function. It
> > > > > returns
> > > > > > >> > the value 512 for processor 0. This value comes from cpu node
> > > > > property
> > > > > > >> > of the DT file.
> > > > > > >> >
> > > > > > >> > Changing ipipe_processor_id() to return 0 instead of 512
> > allows the
> > > > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > > > >> >
> > > > > > >> > Changing the cpu0 reg value on the DT file allows the kernel
> > to boot
> > > > > > >> > and pass all the xenomai regression tests but it generates the
> > > > > > >> > following warning at boot:
> > > > > > >>
> > > > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
> > physical
> > > > > id
> > > > > > >> of the core.
> > > > > > >>
> > > > > > >> > What's the proper way of fixing this?
> > > > > > >> >
> > > > > > >>
> > > > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
> > broken.
> > > > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > > > > actually
> > > > > > >> the opposite.
> > > > > > >>
> > > > > > >> We may have been lucky until now because the physical mapping
> > seems to
> > > > > > >> have always matched the logical order on the SMP SoCs people
> > used with
> > > > > > >> Xenomai so far, it looks like your A5 core does not follow this
> > order.
> > > > > > >
> > > > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > > > whatever number the boot cpu has
> > > > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > > > > > it should work both ways.
> > > > > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > > > initialized with DT ?
> > > > > > >
> > > > > > > --
> > > > > > > Gilles.
> > > > > >
> > > > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > > > >
> > > > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes the
> > > > > cluster ID in fact. So, I do not see how you can get 512 here.
> > > > >
> > > > > Please show us the smp_setup_processor_id function you compile. Or
> > > > > maybe the __cpu_logical_map array is not initialized by this
> > > > > function in your case?
> > > > >
> > > > > --
> > > > > Gilles.
> > > > >
> > > > The array is filled up with entries from the DT, it is done here:
> > > >
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> > > >
> > > > Changing the DT entry for CPU0 allowed the kernel to boot but it fails
> > the
> > > > test here:
> > > >
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
> > >
> > > Yes, obviously, since the MPIDR of your boot cpu is 512. This should
> > > get xenomai working however, since then the logical map is not
> > > overridden and works as patched by the I-pipe code.
> > >
> > > Could you get the MPIDR of the other cores ? I suspect they are 513,
> > > 514, 515, and not 1 2 3.
> >
> > Tried this and the 3 cpus won't boot.
>
> You mean adding a printk in secondary_start_kernel to print the
> mpidr fails ? Sounds strange.
If you mean that you tried to change DT to have the real hardware
registers values and it fails, I believe you should look at all the
code using cpu_logical_map(), some of this code, somewhere, is
probably expecting to only get the lower 8 bits as it was the case
before DT, and fails when getting a higher value. In other words:
int cpu = MPIDR_AFFINITY_LEVEL(cpu_logical_map(smp_processor_id()), 0);
is fine, whereas:
cpu = cpu_logical_map(cpu)
is probably not.
I see a lot of this in the platform specific _boot_secondary functions.
The whole point of the code you pointed me to in devtree.c is to get
cpu_logical_map to return an mpidr comprising a cluster id. So, a
logical map with 512, 1, 2, 3 is probably not what was intended.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 12:02 ` Gilles Chanteperdrix
2015-03-29 12:09 ` Gilles Chanteperdrix
@ 2015-03-29 12:38 ` GP Orcullo
2015-03-29 12:44 ` Gilles Chanteperdrix
1 sibling, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-29 12:38 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 8:02 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:
> On Sun, Mar 29, 2015 at 07:59:13PM +0800, GP Orcullo wrote:
> > On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
> > gilles.chanteperdrix@xenomai.org> wrote:
> > >
> > > On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > > > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > > > gilles.chanteperdrix@xenomai.org> wrote:
> > > >
> > > > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
> > kinsamanka@gmail.com>
> > > > > wrote:
> > > > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
> > kinsamanka@gmail.com>
> > > > > wrote:
> > > > > > >> >>> What happens in between the clocksource switch and head
> > domain
> > > > > registration?
> > > > > > >> >>>
> > > > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
> > coherent
> > > > > > >> >>> allocations
> > > > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > > > >> >>>
> > > > > > >> >>> I'm trying to trace the code to find out where it stops. I
> > tried
> > > > > > >> >>> adding printk to to the set and request functions and the
> > code
> > > > > never
> > > > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > > > >> >>>
> > > > > > >> >>> Thanks,
> > > > > > >> >>>
> > > > > > >> >>> GP Orcullo
> > > > > > >> >>
> > > > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > > > >> >>
> > > > >
> >
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > > > >> >>
> > > > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > > > >> >>
> > > > >
> >
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > > > >> >>
> > > > > > >> >
> > > > > > >> > I've traced the issue to the ipipe_processor_id() function.
> It
> > > > > returns
> > > > > > >> > the value 512 for processor 0. This value comes from cpu
> node
> > > > > property
> > > > > > >> > of the DT file.
> > > > > > >> >
> > > > > > >> > Changing ipipe_processor_id() to return 0 instead of 512
> > allows the
> > > > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > > > >> >
> > > > > > >> > Changing the cpu0 reg value on the DT file allows the kernel
> > to boot
> > > > > > >> > and pass all the xenomai regression tests but it generates
> the
> > > > > > >> > following warning at boot:
> > > > > > >>
> > > > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
> > physical
> > > > > id
> > > > > > >> of the core.
> > > > > > >>
> > > > > > >> > What's the proper way of fixing this?
> > > > > > >> >
> > > > > > >>
> > > > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
> > broken.
> > > > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > > > > actually
> > > > > > >> the opposite.
> > > > > > >>
> > > > > > >> We may have been lucky until now because the physical mapping
> > seems to
> > > > > > >> have always matched the logical order on the SMP SoCs people
> > used with
> > > > > > >> Xenomai so far, it looks like your A5 core does not follow
> this
> > order.
> > > > > > >
> > > > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > > > whatever number the boot cpu has
> > > > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512]
> == 0
> > > > > > > it should work both ways.
> > > > > > > At least, that was true before DT. Now, I find 512 a bit high,
> are
> > > > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > > > initialized with DT ?
> > > > > > >
> > > > > > > --
> > > > > > > Gilles.
> > > > > >
> > > > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > > > >
> > > > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes
> the
> > > > > cluster ID in fact. So, I do not see how you can get 512 here.
> > > > >
> > > > > Please show us the smp_setup_processor_id function you compile. Or
> > > > > maybe the __cpu_logical_map array is not initialized by this
> > > > > function in your case?
> > > > >
> > > > > --
> > > > > Gilles.
> > > > >
> > > > The array is filled up with entries from the DT, it is done here:
> > > >
> >
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> > > >
> > > > Changing the DT entry for CPU0 allowed the kernel to boot but it
> fails
> > the
> > > > test here:
> > > >
> >
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
> > >
> > > Yes, obviously, since the MPIDR of your boot cpu is 512. This should
> > > get xenomai working however, since then the logical map is not
> > > overridden and works as patched by the I-pipe code.
> > >
> > > Could you get the MPIDR of the other cores ? I suspect they are 513,
> > > 514, 515, and not 1 2 3.
> >
> > Tried this and the 3 cpus won't boot.
>
> You mean adding a printk in secondary_start_kernel to print the
> mpidr fails ? Sounds strange.
>
> --
> Gilles.
>
Sorry, what I meant was changing the reg entries of the 3 cpus on the DT
file to 513 - 515 didn't work (the 3 cpus didn't boot).
I think masking the result of ipipe_processor_id() with 0xff is enough.
Regarding the switchtest failing with the test I previously did when I
masked ipipe_processor_id() with 0xff, I'm getting the same result on
xenomai 3.x. So I think this switchtest failure is a separate issue.
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 12:38 ` GP Orcullo
@ 2015-03-29 12:44 ` Gilles Chanteperdrix
2015-03-29 12:56 ` GP Orcullo
2015-04-10 20:08 ` Henry Bausley
0 siblings, 2 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-29 12:44 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 08:38:18PM +0800, GP Orcullo wrote:
> On Sun, Mar 29, 2015 at 8:02 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
> > On Sun, Mar 29, 2015 at 07:59:13PM +0800, GP Orcullo wrote:
> > > On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
> > > gilles.chanteperdrix@xenomai.org> wrote:
> > > >
> > > > On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > > > > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > > > > gilles.chanteperdrix@xenomai.org> wrote:
> > > > >
> > > > > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
> > > kinsamanka@gmail.com>
> > > > > > wrote:
> > > > > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
> > > kinsamanka@gmail.com>
> > > > > > wrote:
> > > > > > > >> >>> What happens in between the clocksource switch and head
> > > domain
> > > > > > registration?
> > > > > > > >> >>>
> > > > > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
> > > coherent
> > > > > > > >> >>> allocations
> > > > > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > > > > >> >>>
> > > > > > > >> >>> I'm trying to trace the code to find out where it stops. I
> > > tried
> > > > > > > >> >>> adding printk to to the set and request functions and the
> > > code
> > > > > > never
> > > > > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > > > > >> >>>
> > > > > > > >> >>> Thanks,
> > > > > > > >> >>>
> > > > > > > >> >>> GP Orcullo
> > > > > > > >> >>
> > > > > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > > > > >> >>
> > > > > >
> > >
> > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > > > > >> >>
> > > > > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > > > > >> >>
> > > > > >
> > >
> > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > > > > >> >>
> > > > > > > >> >
> > > > > > > >> > I've traced the issue to the ipipe_processor_id() function.
> > It
> > > > > > returns
> > > > > > > >> > the value 512 for processor 0. This value comes from cpu
> > node
> > > > > > property
> > > > > > > >> > of the DT file.
> > > > > > > >> >
> > > > > > > >> > Changing ipipe_processor_id() to return 0 instead of 512
> > > allows the
> > > > > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > > > > >> >
> > > > > > > >> > Changing the cpu0 reg value on the DT file allows the kernel
> > > to boot
> > > > > > > >> > and pass all the xenomai regression tests but it generates
> > the
> > > > > > > >> > following warning at boot:
> > > > > > > >>
> > > > > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
> > > physical
> > > > > > id
> > > > > > > >> of the core.
> > > > > > > >>
> > > > > > > >> > What's the proper way of fixing this?
> > > > > > > >> >
> > > > > > > >>
> > > > > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
> > > broken.
> > > > > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > > > > > actually
> > > > > > > >> the opposite.
> > > > > > > >>
> > > > > > > >> We may have been lucky until now because the physical mapping
> > > seems to
> > > > > > > >> have always matched the logical order on the SMP SoCs people
> > > used with
> > > > > > > >> Xenomai so far, it looks like your A5 core does not follow
> > this
> > > order.
> > > > > > > >
> > > > > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > > > > whatever number the boot cpu has
> > > > > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512]
> > == 0
> > > > > > > > it should work both ways.
> > > > > > > > At least, that was true before DT. Now, I find 512 a bit high,
> > are
> > > > > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > > > > initialized with DT ?
> > > > > > > >
> > > > > > > > --
> > > > > > > > Gilles.
> > > > > > >
> > > > > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > > > > >
> > > > > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes
> > the
> > > > > > cluster ID in fact. So, I do not see how you can get 512 here.
> > > > > >
> > > > > > Please show us the smp_setup_processor_id function you compile. Or
> > > > > > maybe the __cpu_logical_map array is not initialized by this
> > > > > > function in your case?
> > > > > >
> > > > > > --
> > > > > > Gilles.
> > > > > >
> > > > > The array is filled up with entries from the DT, it is done here:
> > > > >
> > >
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> > > > >
> > > > > Changing the DT entry for CPU0 allowed the kernel to boot but it
> > fails
> > > the
> > > > > test here:
> > > > >
> > >
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
> > > >
> > > > Yes, obviously, since the MPIDR of your boot cpu is 512. This should
> > > > get xenomai working however, since then the logical map is not
> > > > overridden and works as patched by the I-pipe code.
> > > >
> > > > Could you get the MPIDR of the other cores ? I suspect they are 513,
> > > > 514, 515, and not 1 2 3.
> > >
> > > Tried this and the 3 cpus won't boot.
> >
> > You mean adding a printk in secondary_start_kernel to print the
> > mpidr fails ? Sounds strange.
> >
> > --
> > Gilles.
> >
>
> Sorry, what I meant was changing the reg entries of the 3 cpus on the DT
> file to 513 - 515 didn't work (the 3 cpus didn't boot).
>
> I think masking the result of ipipe_processor_id() with 0xff is enough.
Not a really good idat, it is better to implement a reverse map
distinct from the logical map, so that when the DT code overwrites
the logical map, it does not break the I-pipe. The following
untested patch should do this. Note that in the case of the old
kernel you are using, you also have to modify vfphw.S to use
__cpu_reverse_map instead of __cpu_logical_map.
diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
index 72ad7a4..651b7d8 100644
--- a/arch/arm/include/asm/ipipe_base.h
+++ b/arch/arm/include/asm/ipipe_base.h
@@ -55,8 +55,8 @@ extern unsigned __ipipe_first_ipi;
: "=r" (cpunum)); \
cpunum &= 0xFF; \
})
-extern u32 __cpu_logical_map[];
-#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
+extern u32 *__cpu_reverse_map[];
+#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
#else /* !legacy */
#define hard_smp_processor_id() raw_smp_processor_id()
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index b10f40f..e4b7d1d 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -469,11 +469,10 @@ void notrace cpu_init(void)
#endif
}
-#if NR_CPUS > 16
u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
-#else
-u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
-#endif
+
+u32 *__cpu_reverse_map;
+EXPORT_SYMBOL(__cpu_reverse_map);
void __init smp_setup_processor_id(void)
{
@@ -486,12 +485,17 @@ void __init smp_setup_processor_id(void)
/* printk on I-pipe needs per cpu data */
set_my_cpu_offset(per_cpu_offset(0));
#endif
- BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
cpu_logical_map(0) = cpu;
- for (i = 1; i < max; ++i)
+ for (i = 1; i < nr_cpu_ids; ++i)
cpu_logical_map(i) = i == cpu ? 0 : i;
+ __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
+ BUG_ON(!__cpu_reverse_map);
+
+ for (i = 1; i < nr_cpu_ids; i++)
+ __cpu_reverse_map[cpu_logical_map(i)] = i;
+
/*
* clear __my_cpu_offset on boot CPU to avoid hang caused by
* using percpu variable early, for example, lockdep will
>
> Regarding the switchtest failing with the test I previously did when I
> masked ipipe_processor_id() with 0xff, I'm getting the same result on
> xenomai 3.x. So I think this switchtest failure is a separate issue.
How does it fail? What message does it print?
--
Gilles.
^ permalink raw reply related [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 12:44 ` Gilles Chanteperdrix
@ 2015-03-29 12:56 ` GP Orcullo
2015-03-30 15:21 ` GP Orcullo
2015-04-10 20:08 ` Henry Bausley
1 sibling, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-29 12:56 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 8:44 PM, Gilles Chanteperdrix <
gilles.chanteperdrix@xenomai.org> wrote:
> On Sun, Mar 29, 2015 at 08:38:18PM +0800, GP Orcullo wrote:
> > On Sun, Mar 29, 2015 at 8:02 PM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> > > On Sun, Mar 29, 2015 at 07:59:13PM +0800, GP Orcullo wrote:
> > > > On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
> > > > gilles.chanteperdrix@xenomai.org> wrote:
> > > > >
> > > > > On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > > > > > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > > > > > gilles.chanteperdrix@xenomai.org> wrote:
> > > > > >
> > > > > > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > > > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > > > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum
> wrote:
> > > > > > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > > > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
> > > > kinsamanka@gmail.com>
> > > > > > > wrote:
> > > > > > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
> > > > kinsamanka@gmail.com>
> > > > > > > wrote:
> > > > > > > > >> >>> What happens in between the clocksource switch and
> head
> > > > domain
> > > > > > > registration?
> > > > > > > > >> >>>
> > > > > > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for
> atomic
> > > > coherent
> > > > > > > > >> >>> allocations
> > > > > > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > > > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > > > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > > > > > >> >>>
> > > > > > > > >> >>> I'm trying to trace the code to find out where it
> stops. I
> > > > tried
> > > > > > > > >> >>> adding printk to to the set and request functions and
> the
> > > > code
> > > > > > > never
> > > > > > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > > > > > >> >>>
> > > > > > > > >> >>> Thanks,
> > > > > > > > >> >>>
> > > > > > > > >> >>> GP Orcullo
> > > > > > > > >> >>
> > > > > > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > > > > > >> >>
> > > > > > >
> > > >
> > >
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > > > > > >> >>
> > > > > > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > > > > > >> >>
> > > > > > >
> > > >
> > >
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > > > > > >> >>
> > > > > > > > >> >
> > > > > > > > >> > I've traced the issue to the ipipe_processor_id()
> function.
> > > It
> > > > > > > returns
> > > > > > > > >> > the value 512 for processor 0. This value comes from cpu
> > > node
> > > > > > > property
> > > > > > > > >> > of the DT file.
> > > > > > > > >> >
> > > > > > > > >> > Changing ipipe_processor_id() to return 0 instead of 512
> > > > allows the
> > > > > > > > >> > kernel to boot but it fails the switchtest regression
> test.
> > > > > > > > >> >
> > > > > > > > >> > Changing the cpu0 reg value on the DT file allows the
> kernel
> > > > to boot
> > > > > > > > >> > and pass all the xenomai regression tests but it
> generates
> > > the
> > > > > > > > >> > following warning at boot:
> > > > > > > > >>
> > > > > > > > >> No, this property for armv7 must match MPIDR[23:0], i.e.
> the
> > > > physical
> > > > > > > id
> > > > > > > > >> of the core.
> > > > > > > > >>
> > > > > > > > >> > What's the proper way of fixing this?
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case,
> it's
> > > > broken.
> > > > > > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but
> it is
> > > > > > > actually
> > > > > > > > >> the opposite.
> > > > > > > > >>
> > > > > > > > >> We may have been lucky until now because the physical
> mapping
> > > > seems to
> > > > > > > > >> have always matched the logical order on the SMP SoCs
> people
> > > > used with
> > > > > > > > >> Xenomai so far, it looks like your A5 core does not follow
> > > this
> > > > order.
> > > > > > > > >
> > > > > > > > > No, cpu_logical_map works both ways, it simply exchanges 0
> with
> > > > > > > > > whatever number the boot cpu has
> > > > > > > > > so, since cpu_logical_map[0] == 512 and
> cpu_logical_map[512]
> > > == 0
> > > > > > > > > it should work both ways.
> > > > > > > > > At least, that was true before DT. Now, I find 512 a bit
> high,
> > > are
> > > > > > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > > > > > initialized with DT ?
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Gilles.
> > > > > > > >
> > > > > > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > > > > > >
> > > > > > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It
> removes
> > > the
> > > > > > > cluster ID in fact. So, I do not see how you can get 512 here.
> > > > > > >
> > > > > > > Please show us the smp_setup_processor_id function you
> compile. Or
> > > > > > > maybe the __cpu_logical_map array is not initialized by this
> > > > > > > function in your case?
> > > > > > >
> > > > > > > --
> > > > > > > Gilles.
> > > > > > >
> > > > > > The array is filled up with entries from the DT, it is done here:
> > > > > >
> > > >
> > >
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> > > > > >
> > > > > > Changing the DT entry for CPU0 allowed the kernel to boot but it
> > > fails
> > > > the
> > > > > > test here:
> > > > > >
> > > >
> > >
> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
> > > > >
> > > > > Yes, obviously, since the MPIDR of your boot cpu is 512. This
> should
> > > > > get xenomai working however, since then the logical map is not
> > > > > overridden and works as patched by the I-pipe code.
> > > > >
> > > > > Could you get the MPIDR of the other cores ? I suspect they are
> 513,
> > > > > 514, 515, and not 1 2 3.
> > > >
> > > > Tried this and the 3 cpus won't boot.
> > >
> > > You mean adding a printk in secondary_start_kernel to print the
> > > mpidr fails ? Sounds strange.
> > >
> > > --
> > > Gilles.
> > >
> >
> > Sorry, what I meant was changing the reg entries of the 3 cpus on the DT
> > file to 513 - 515 didn't work (the 3 cpus didn't boot).
> >
> > I think masking the result of ipipe_processor_id() with 0xff is enough.
>
> Not a really good idat, it is better to implement a reverse map
> distinct from the logical map, so that when the DT code overwrites
> the logical map, it does not break the I-pipe. The following
> untested patch should do this. Note that in the case of the old
> kernel you are using, you also have to modify vfphw.S to use
> __cpu_reverse_map instead of __cpu_logical_map.
>
> diff --git a/arch/arm/include/asm/ipipe_base.h
> b/arch/arm/include/asm/ipipe_base.h
> index 72ad7a4..651b7d8 100644
> --- a/arch/arm/include/asm/ipipe_base.h
> +++ b/arch/arm/include/asm/ipipe_base.h
> @@ -55,8 +55,8 @@ extern unsigned __ipipe_first_ipi;
> : "=r" (cpunum)); \
> cpunum &= 0xFF; \
> })
> -extern u32 __cpu_logical_map[];
> -#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
> +extern u32 *__cpu_reverse_map[];
> +#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
>
> #else /* !legacy */
> #define hard_smp_processor_id() raw_smp_processor_id()
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index b10f40f..e4b7d1d 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -469,11 +469,10 @@ void notrace cpu_init(void)
> #endif
> }
>
> -#if NR_CPUS > 16
> u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
> -#else
> -u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
> -#endif
> +
> +u32 *__cpu_reverse_map;
> +EXPORT_SYMBOL(__cpu_reverse_map);
>
> void __init smp_setup_processor_id(void)
> {
> @@ -486,12 +485,17 @@ void __init smp_setup_processor_id(void)
> /* printk on I-pipe needs per cpu data */
> set_my_cpu_offset(per_cpu_offset(0));
> #endif
> - BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
>
> cpu_logical_map(0) = cpu;
> - for (i = 1; i < max; ++i)
> + for (i = 1; i < nr_cpu_ids; ++i)
> cpu_logical_map(i) = i == cpu ? 0 : i;
>
> + __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
> + BUG_ON(!__cpu_reverse_map);
> +
> + for (i = 1; i < nr_cpu_ids; i++)
> + __cpu_reverse_map[cpu_logical_map(i)] = i;
> +
> /*
> * clear __my_cpu_offset on boot CPU to avoid hang caused by
> * using percpu variable early, for example, lockdep will
>
>
>
> >
> > Regarding the switchtest failing with the test I previously did when I
> > masked ipipe_processor_id() with 0xff, I'm getting the same result on
> > xenomai 3.x. So I think this switchtest failure is a separate issue.
>
> How does it fail? What message does it print?
>
> --
> Gilles.
>
On xenomai 3.x, the test just hangs after printing the Threads list, then
an "Alarm clock" message appears and the test is aborted. I haven't
investigated it yet.
--
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 12:56 ` GP Orcullo
@ 2015-03-30 15:21 ` GP Orcullo
2015-03-30 15:28 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: GP Orcullo @ 2015-03-30 15:21 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 8:56 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>
>
> On Sun, Mar 29, 2015 at 8:44 PM, Gilles Chanteperdrix <
> gilles.chanteperdrix@xenomai.org> wrote:
>
>> On Sun, Mar 29, 2015 at 08:38:18PM +0800, GP Orcullo wrote:
>> > On Sun, Mar 29, 2015 at 8:02 PM, Gilles Chanteperdrix <
>> > gilles.chanteperdrix@xenomai.org> wrote:
>> >
>> > > On Sun, Mar 29, 2015 at 07:59:13PM +0800, GP Orcullo wrote:
>> > > > On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
>> > > > gilles.chanteperdrix@xenomai.org> wrote:
>> > > > >
>> > > > > On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
>> > > > > > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
>> > > > > > gilles.chanteperdrix@xenomai.org> wrote:
>> > > > > >
>> > > > > > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
>> > > > > > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
>> > > > > > > > <gilles.chanteperdrix@xenomai.org> wrote:
>> > > > > > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum
>> wrote:
>> > > > > > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>> > > > > > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
>> > > > kinsamanka@gmail.com>
>> > > > > > > wrote:
>> > > > > > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
>> > > > kinsamanka@gmail.com>
>> > > > > > > wrote:
>> > > > > > > > >> >>> What happens in between the clocksource switch and
>> head
>> > > > domain
>> > > > > > > registration?
>> > > > > > > > >> >>>
>> > > > > > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for
>> atomic
>> > > > coherent
>> > > > > > > > >> >>> allocations
>> > > > > > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
>> > > > > > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai
>> registered.
>> > > > > > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
>> > > > > > > > >> >>>
>> > > > > > > > >> >>> I'm trying to trace the code to find out where it
>> stops. I
>> > > > tried
>> > > > > > > > >> >>> adding printk to to the set and request functions
>> and the
>> > > > code
>> > > > > > > never
>> > > > > > > > >> >>> runs when CONFIG_SMP is enabled.
>> > > > > > > > >> >>>
>> > > > > > > > >> >>> Thanks,
>> > > > > > > > >> >>>
>> > > > > > > > >> >>> GP Orcullo
>> > > > > > > > >> >>
>> > > > > > > > >> >> It gets stuck on the call to ipipe_critical_enter:
>> > > > > > > > >> >>
>> > > > > > >
>> > > >
>> > >
>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>> > > > > > > > >> >>
>> > > > > > > > >> >> Which then gets stuck on ipipe_send_ipi:
>> > > > > > > > >> >>
>> > > > > > >
>> > > >
>> > >
>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>> > > > > > > > >> >>
>> > > > > > > > >> >
>> > > > > > > > >> > I've traced the issue to the ipipe_processor_id()
>> function.
>> > > It
>> > > > > > > returns
>> > > > > > > > >> > the value 512 for processor 0. This value comes from
>> cpu
>> > > node
>> > > > > > > property
>> > > > > > > > >> > of the DT file.
>> > > > > > > > >> >
>> > > > > > > > >> > Changing ipipe_processor_id() to return 0 instead of
>> 512
>> > > > allows the
>> > > > > > > > >> > kernel to boot but it fails the switchtest regression
>> test.
>> > > > > > > > >> >
>> > > > > > > > >> > Changing the cpu0 reg value on the DT file allows the
>> kernel
>> > > > to boot
>> > > > > > > > >> > and pass all the xenomai regression tests but it
>> generates
>> > > the
>> > > > > > > > >> > following warning at boot:
>> > > > > > > > >>
>> > > > > > > > >> No, this property for armv7 must match MPIDR[23:0], i.e.
>> the
>> > > > physical
>> > > > > > > id
>> > > > > > > > >> of the core.
>> > > > > > > > >>
>> > > > > > > > >> > What's the proper way of fixing this?
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY
>> case, it's
>> > > > broken.
>> > > > > > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but
>> it is
>> > > > > > > actually
>> > > > > > > > >> the opposite.
>> > > > > > > > >>
>> > > > > > > > >> We may have been lucky until now because the physical
>> mapping
>> > > > seems to
>> > > > > > > > >> have always matched the logical order on the SMP SoCs
>> people
>> > > > used with
>> > > > > > > > >> Xenomai so far, it looks like your A5 core does not
>> follow
>> > > this
>> > > > order.
>> > > > > > > > >
>> > > > > > > > > No, cpu_logical_map works both ways, it simply exchanges
>> 0 with
>> > > > > > > > > whatever number the boot cpu has
>> > > > > > > > > so, since cpu_logical_map[0] == 512 and
>> cpu_logical_map[512]
>> > > == 0
>> > > > > > > > > it should work both ways.
>> > > > > > > > > At least, that was true before DT. Now, I find 512 a bit
>> high,
>> > > are
>> > > > > > > > > you sure cpu_logical_map[] is large enough ? Or is it even
>> > > > > > > > > initialized with DT ?
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > Gilles.
>> > > > > > > >
>> > > > > > > > cpu_logical_map[] contains these values: {512,1,2,3}
>> > > > > > >
>> > > > > > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It
>> removes
>> > > the
>> > > > > > > cluster ID in fact. So, I do not see how you can get 512 here.
>> > > > > > >
>> > > > > > > Please show us the smp_setup_processor_id function you
>> compile. Or
>> > > > > > > maybe the __cpu_logical_map array is not initialized by this
>> > > > > > > function in your case?
>> > > > > > >
>> > > > > > > --
>> > > > > > > Gilles.
>> > > > > > >
>> > > > > > The array is filled up with entries from the DT, it is done
>> here:
>> > > > > >
>> > > >
>> > >
>> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
>> > > > > >
>> > > > > > Changing the DT entry for CPU0 allowed the kernel to boot but it
>> > > fails
>> > > > the
>> > > > > > test here:
>> > > > > >
>> > > >
>> > >
>> https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
>> > > > >
>> > > > > Yes, obviously, since the MPIDR of your boot cpu is 512. This
>> should
>> > > > > get xenomai working however, since then the logical map is not
>> > > > > overridden and works as patched by the I-pipe code.
>> > > > >
>> > > > > Could you get the MPIDR of the other cores ? I suspect they are
>> 513,
>> > > > > 514, 515, and not 1 2 3.
>> > > >
>> > > > Tried this and the 3 cpus won't boot.
>> > >
>> > > You mean adding a printk in secondary_start_kernel to print the
>> > > mpidr fails ? Sounds strange.
>> > >
>> > > --
>> > > Gilles.
>> > >
>> >
>> > Sorry, what I meant was changing the reg entries of the 3 cpus on the DT
>> > file to 513 - 515 didn't work (the 3 cpus didn't boot).
>> >
>> > I think masking the result of ipipe_processor_id() with 0xff is enough.
>>
>> Not a really good idat, it is better to implement a reverse map
>> distinct from the logical map, so that when the DT code overwrites
>> the logical map, it does not break the I-pipe. The following
>> untested patch should do this. Note that in the case of the old
>> kernel you are using, you also have to modify vfphw.S to use
>> __cpu_reverse_map instead of __cpu_logical_map.
>>
>> diff --git a/arch/arm/include/asm/ipipe_base.h
>> b/arch/arm/include/asm/ipipe_base.h
>> index 72ad7a4..651b7d8 100644
>> --- a/arch/arm/include/asm/ipipe_base.h
>> +++ b/arch/arm/include/asm/ipipe_base.h
>> @@ -55,8 +55,8 @@ extern unsigned __ipipe_first_ipi;
>> : "=r" (cpunum)); \
>> cpunum &= 0xFF; \
>> })
>> -extern u32 __cpu_logical_map[];
>> -#define ipipe_processor_id()
>> (__cpu_logical_map[hard_smp_processor_id()])
>> +extern u32 *__cpu_reverse_map[];
>> +#define ipipe_processor_id()
>> (__cpu_reverse_map[hard_smp_processor_id()])
>>
>> #else /* !legacy */
>> #define hard_smp_processor_id() raw_smp_processor_id()
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index b10f40f..e4b7d1d 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -469,11 +469,10 @@ void notrace cpu_init(void)
>> #endif
>> }
>>
>> -#if NR_CPUS > 16
>> u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
>> -#else
>> -u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
>> -#endif
>> +
>> +u32 *__cpu_reverse_map;
>> +EXPORT_SYMBOL(__cpu_reverse_map);
>>
>> void __init smp_setup_processor_id(void)
>> {
>> @@ -486,12 +485,17 @@ void __init smp_setup_processor_id(void)
>> /* printk on I-pipe needs per cpu data */
>> set_my_cpu_offset(per_cpu_offset(0));
>> #endif
>> - BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
>>
>> cpu_logical_map(0) = cpu;
>> - for (i = 1; i < max; ++i)
>> + for (i = 1; i < nr_cpu_ids; ++i)
>> cpu_logical_map(i) = i == cpu ? 0 : i;
>>
>> + __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
>> + BUG_ON(!__cpu_reverse_map);
>> +
>> + for (i = 1; i < nr_cpu_ids; i++)
>> + __cpu_reverse_map[cpu_logical_map(i)] = i;
>> +
>> /*
>> * clear __my_cpu_offset on boot CPU to avoid hang caused by
>> * using percpu variable early, for example, lockdep will
>>
>>
>>
>> >
>> > Regarding the switchtest failing with the test I previously did when I
>> > masked ipipe_processor_id() with 0xff, I'm getting the same result on
>> > xenomai 3.x. So I think this switchtest failure is a separate issue.
>>
>> How does it fail? What message does it print?
>>
>> --
>> Gilles.
>>
>
> On xenomai 3.x, the test just hangs after printing the Threads list, then
> an "Alarm clock" message appears and the test is aborted. I haven't
> investigated it yet.
>
>
> --
> GP Orcullo
>
I tried the patch and the kernel hangs after "I-pipe: head domain Xenomai
registered.". It is stuck on the call to __ipipe_set_current_domain(ipd)
from the function ipipe_register_domain(). There's no error messages.
Attached is the patch I've used
--
GP Orcullo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.patch
Type: text/x-patch
Size: 2119 bytes
Desc: not available
URL: <http://www.xenomai.org/pipermail/xenomai/attachments/20150330/6526fa59/attachment.bin>
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 12:44 ` Gilles Chanteperdrix
2015-03-29 12:56 ` GP Orcullo
@ 2015-04-10 20:08 ` Henry Bausley
2015-04-10 21:33 ` Gilles Chanteperdrix
1 sibling, 1 reply; 51+ messages in thread
From: Henry Bausley @ 2015-04-10 20:08 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: GP Orcullo, xenomai@xenomai.org
FYI,
Using your patches also allowed the LS1021A Arm to boot with Xenomai
in SMP mode.
On Sun, 2015-03-29 at 14:44 +0200, Gilles Chanteperdrix wrote:
> On Sun, Mar 29, 2015 at 08:38:18PM +0800, GP Orcullo wrote:
> > On Sun, Mar 29, 2015 at 8:02 PM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> > > On Sun, Mar 29, 2015 at 07:59:13PM +0800, GP Orcullo wrote:
> > > > On Mar 29, 2015 7:07 PM, "Gilles Chanteperdrix" <
> > > > gilles.chanteperdrix@xenomai.org> wrote:
> > > > >
> > > > > On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > > > > > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > > > > > gilles.chanteperdrix@xenomai.org> wrote:
> > > > > >
> > > > > > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > > > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > > > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > > > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > > > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <
> > > > kinsamanka@gmail.com>
> > > > > > > wrote:
> > > > > > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <
> > > > kinsamanka@gmail.com>
> > > > > > > wrote:
> > > > > > > > >> >>> What happens in between the clocksource switch and head
> > > > domain
> > > > > > > registration?
> > > > > > > > >> >>>
> > > > > > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic
> > > > coherent
> > > > > > > > >> >>> allocations
> > > > > > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > > > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > > > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > > > > > >> >>>
> > > > > > > > >> >>> I'm trying to trace the code to find out where it stops. I
> > > > tried
> > > > > > > > >> >>> adding printk to to the set and request functions and the
> > > > code
> > > > > > > never
> > > > > > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > > > > > >> >>>
> > > > > > > > >> >>> Thanks,
> > > > > > > > >> >>>
> > > > > > > > >> >>> GP Orcullo
> > > > > > > > >> >>
> > > > > > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > > > > > >> >>
> > > > > > >
> > > >
> > > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > > > > > >> >>
> > > > > > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > > > > > >> >>
> > > > > > >
> > > >
> > > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > > > > > >> >>
> > > > > > > > >> >
> > > > > > > > >> > I've traced the issue to the ipipe_processor_id() function.
> > > It
> > > > > > > returns
> > > > > > > > >> > the value 512 for processor 0. This value comes from cpu
> > > node
> > > > > > > property
> > > > > > > > >> > of the DT file.
> > > > > > > > >> >
> > > > > > > > >> > Changing ipipe_processor_id() to return 0 instead of 512
> > > > allows the
> > > > > > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > > > > > >> >
> > > > > > > > >> > Changing the cpu0 reg value on the DT file allows the kernel
> > > > to boot
> > > > > > > > >> > and pass all the xenomai regression tests but it generates
> > > the
> > > > > > > > >> > following warning at boot:
> > > > > > > > >>
> > > > > > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the
> > > > physical
> > > > > > > id
> > > > > > > > >> of the core.
> > > > > > > > >>
> > > > > > > > >> > What's the proper way of fixing this?
> > > > > > > > >> >
> > > > > > > > >>
> > > > > > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
> > > > broken.
> > > > > > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > > > > > > actually
> > > > > > > > >> the opposite.
> > > > > > > > >>
> > > > > > > > >> We may have been lucky until now because the physical mapping
> > > > seems to
> > > > > > > > >> have always matched the logical order on the SMP SoCs people
> > > > used with
> > > > > > > > >> Xenomai so far, it looks like your A5 core does not follow
> > > this
> > > > order.
> > > > > > > > >
> > > > > > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > > > > > whatever number the boot cpu has
> > > > > > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512]
> > > == 0
> > > > > > > > > it should work both ways.
> > > > > > > > > At least, that was true before DT. Now, I find 512 a bit high,
> > > are
> > > > > > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > > > > > initialized with DT ?
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Gilles.
> > > > > > > >
> > > > > > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > > > > > >
> > > > > > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes
> > > the
> > > > > > > cluster ID in fact. So, I do not see how you can get 512 here.
> > > > > > >
> > > > > > > Please show us the smp_setup_processor_id function you compile. Or
> > > > > > > maybe the __cpu_logical_map array is not initialized by this
> > > > > > > function in your case?
> > > > > > >
> > > > > > > --
> > > > > > > Gilles.
> > > > > > >
> > > > > > The array is filled up with entries from the DT, it is done here:
> > > > > >
> > > >
> > > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> > > > > >
> > > > > > Changing the DT entry for CPU0 allowed the kernel to boot but it
> > > fails
> > > > the
> > > > > > test here:
> > > > > >
> > > >
> > > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
> > > > >
> > > > > Yes, obviously, since the MPIDR of your boot cpu is 512. This should
> > > > > get xenomai working however, since then the logical map is not
> > > > > overridden and works as patched by the I-pipe code.
> > > > >
> > > > > Could you get the MPIDR of the other cores ? I suspect they are 513,
> > > > > 514, 515, and not 1 2 3.
> > > >
> > > > Tried this and the 3 cpus won't boot.
> > >
> > > You mean adding a printk in secondary_start_kernel to print the
> > > mpidr fails ? Sounds strange.
> > >
> > > --
> > > Gilles.
> > >
> >
> > Sorry, what I meant was changing the reg entries of the 3 cpus on the DT
> > file to 513 - 515 didn't work (the 3 cpus didn't boot).
> >
> > I think masking the result of ipipe_processor_id() with 0xff is enough.
>
> Not a really good idat, it is better to implement a reverse map
> distinct from the logical map, so that when the DT code overwrites
> the logical map, it does not break the I-pipe. The following
> untested patch should do this. Note that in the case of the old
> kernel you are using, you also have to modify vfphw.S to use
> __cpu_reverse_map instead of __cpu_logical_map.
>
> diff --git a/arch/arm/include/asm/ipipe_base.h b/arch/arm/include/asm/ipipe_base.h
> index 72ad7a4..651b7d8 100644
> --- a/arch/arm/include/asm/ipipe_base.h
> +++ b/arch/arm/include/asm/ipipe_base.h
> @@ -55,8 +55,8 @@ extern unsigned __ipipe_first_ipi;
> : "=r" (cpunum)); \
> cpunum &= 0xFF; \
> })
> -extern u32 __cpu_logical_map[];
> -#define ipipe_processor_id() (__cpu_logical_map[hard_smp_processor_id()])
> +extern u32 *__cpu_reverse_map[];
> +#define ipipe_processor_id() (__cpu_reverse_map[hard_smp_processor_id()])
>
> #else /* !legacy */
> #define hard_smp_processor_id() raw_smp_processor_id()
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index b10f40f..e4b7d1d 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -469,11 +469,10 @@ void notrace cpu_init(void)
> #endif
> }
>
> -#if NR_CPUS > 16
> u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
> -#else
> -u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
> -#endif
> +
> +u32 *__cpu_reverse_map;
> +EXPORT_SYMBOL(__cpu_reverse_map);
>
> void __init smp_setup_processor_id(void)
> {
> @@ -486,12 +485,17 @@ void __init smp_setup_processor_id(void)
> /* printk on I-pipe needs per cpu data */
> set_my_cpu_offset(per_cpu_offset(0));
> #endif
> - BUG_ON(max > ARRAY_SIZE(__cpu_logical_map));
>
> cpu_logical_map(0) = cpu;
> - for (i = 1; i < max; ++i)
> + for (i = 1; i < nr_cpu_ids; ++i)
> cpu_logical_map(i) = i == cpu ? 0 : i;
>
> + __cpu_reverse_map = kmalloc(max * sizeof(*__cpu_reverse_map));
> + BUG_ON(!__cpu_reverse_map);
> +
> + for (i = 1; i < nr_cpu_ids; i++)
> + __cpu_reverse_map[cpu_logical_map(i)] = i;
> +
> /*
> * clear __my_cpu_offset on boot CPU to avoid hang caused by
> * using percpu variable early, for example, lockdep will
>
>
>
> >
> > Regarding the switchtest failing with the test I previously did when I
> > masked ipipe_processor_id() with 0xff, I'm getting the same result on
> > xenomai 3.x. So I think this switchtest failure is a separate issue.
>
> How does it fail? What message does it print?
>
Outbound scan for Spam or Virus by Barracuda at Delta Tau
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-04-10 20:08 ` Henry Bausley
@ 2015-04-10 21:33 ` Gilles Chanteperdrix
2015-04-10 21:39 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-04-10 21:33 UTC (permalink / raw)
To: Henry Bausley; +Cc: GP Orcullo, xenomai@xenomai.org
On Fri, Apr 10, 2015 at 01:08:50PM -0700, Henry Bausley wrote:
> FYI,
>
> Using your patches also allowed the LS1021A Arm to boot with Xenomai
> in SMP mode.
You mean the latest version I sent today ?
https://git.xenomai.org/ipipe-gch.git/commit/?h=for-ipipe-3.18&id=d1414de8ada86282fe77f8ff17283f1dc9d50141
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-04-10 21:33 ` Gilles Chanteperdrix
@ 2015-04-10 21:39 ` Gilles Chanteperdrix
0 siblings, 0 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-04-10 21:39 UTC (permalink / raw)
To: Henry Bausley; +Cc: GP Orcullo, xenomai@xenomai.org
On Fri, Apr 10, 2015 at 11:33:06PM +0200, Gilles Chanteperdrix wrote:
> On Fri, Apr 10, 2015 at 01:08:50PM -0700, Henry Bausley wrote:
> > FYI,
> >
> > Using your patches also allowed the LS1021A Arm to boot with Xenomai
> > in SMP mode.
>
> You mean the latest version I sent today ?
> https://git.xenomai.org/ipipe-gch.git/commit/?h=for-ipipe-3.18&id=d1414de8ada86282fe77f8ff17283f1dc9d50141
Ok, found the typo which is probably the cause of the issues.
Please try that one instead:
https://git.xenomai.org/ipipe-gch.git/commit/?h=for-ipipe-3.18&id=92b112d3c6f9f7b9a287fb6569c5e92a731e8cab
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-29 11:06 ` Gilles Chanteperdrix
2015-03-29 11:59 ` GP Orcullo
@ 2015-03-29 12:18 ` Gilles Chanteperdrix
1 sibling, 0 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-29 12:18 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 01:06:23PM +0200, Gilles Chanteperdrix wrote:
> On Sun, Mar 29, 2015 at 06:38:45AM +0800, GP Orcullo wrote:
> > On Sun, Mar 29, 2015 at 2:59 AM, Gilles Chanteperdrix <
> > gilles.chanteperdrix@xenomai.org> wrote:
> >
> > > On Sat, Mar 28, 2015 at 08:27:33PM +0800, GP Orcullo wrote:
> > > > On Sat, Mar 28, 2015 at 7:36 PM, Gilles Chanteperdrix
> > > > <gilles.chanteperdrix@xenomai.org> wrote:
> > > > > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> > > > >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> > > > >> > On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com>
> > > wrote:
> > > > >> >> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com>
> > > wrote:
> > > > >> >>> What happens in between the clocksource switch and head domain
> > > registration?
> > > > >> >>>
> > > > >> >>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> > > > >> >>> allocations
> > > > >> >>> [ 0.095333] Switching to clocksource ipipe_tsc
> > > > >> >>> [ 0.122397] I-pipe: head domain Xenomai registered.
> > > > >> >>> [ 0.124618] Xenomai: hal/arm started.
> > > > >> >>>
> > > > >> >>> I'm trying to trace the code to find out where it stops. I tried
> > > > >> >>> adding printk to to the set and request functions and the code
> > > never
> > > > >> >>> runs when CONFIG_SMP is enabled.
> > > > >> >>>
> > > > >> >>> Thanks,
> > > > >> >>>
> > > > >> >>> GP Orcullo
> > > > >> >>
> > > > >> >> It gets stuck on the call to ipipe_critical_enter:
> > > > >> >>
> > > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> > > > >> >>
> > > > >> >> Which then gets stuck on ipipe_send_ipi:
> > > > >> >>
> > > http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> > > > >> >>
> > > > >> >
> > > > >> > I've traced the issue to the ipipe_processor_id() function. It
> > > returns
> > > > >> > the value 512 for processor 0. This value comes from cpu node
> > > property
> > > > >> > of the DT file.
> > > > >> >
> > > > >> > Changing ipipe_processor_id() to return 0 instead of 512 allows the
> > > > >> > kernel to boot but it fails the switchtest regression test.
> > > > >> >
> > > > >> > Changing the cpu0 reg value on the DT file allows the kernel to boot
> > > > >> > and pass all the xenomai regression tests but it generates the
> > > > >> > following warning at boot:
> > > > >>
> > > > >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical
> > > id
> > > > >> of the core.
> > > > >>
> > > > >> > What's the proper way of fixing this?
> > > > >> >
> > > > >>
> > > > >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> > > > >> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> > > actually
> > > > >> the opposite.
> > > > >>
> > > > >> We may have been lucky until now because the physical mapping seems to
> > > > >> have always matched the logical order on the SMP SoCs people used with
> > > > >> Xenomai so far, it looks like your A5 core does not follow this order.
> > > > >
> > > > > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > > > > whatever number the boot cpu has
> > > > > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > > > > it should work both ways.
> > > > > At least, that was true before DT. Now, I find 512 a bit high, are
> > > > > you sure cpu_logical_map[] is large enough ? Or is it even
> > > > > initialized with DT ?
> > > > >
> > > > > --
> > > > > Gilles.
> > > >
> > > > cpu_logical_map[] contains these values: {512,1,2,3}
> > >
> > > Ok, the MPIDR_AFFINITY_LEVEL macro simply masks 0xff. It removes the
> > > cluster ID in fact. So, I do not see how you can get 512 here.
> > >
> > > Please show us the smp_setup_processor_id function you compile. Or
> > > maybe the __cpu_logical_map array is not initialized by this
> > > function in your case?
> > >
> > > --
> > > Gilles.
> > >
> > The array is filled up with entries from the DT, it is done here:
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L73
> >
> > Changing the DT entry for CPU0 allowed the kernel to boot but it fails the
> > test here:
> > https://github.com/hardkernel/linux/blob/odroidc-3.10.y/arch/arm/kernel/devtree.c#L138-L140
>
> Yes, obviously, since the MPIDR of your boot cpu is 512. This should
> get xenomai working however, since then the logical map is not
> overridden and works as patched by the I-pipe code.
>
> Could you get the MPIDR of the other cores ? I suspect they are 513,
> 514, 515, and not 1 2 3.
Ok, looking at the logs you posted, the mpidr are printed, and they
are indeed 0x200, 0x201, 0x202, 0x203
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 11:36 ` Gilles Chanteperdrix
2015-03-28 12:27 ` GP Orcullo
@ 2015-03-28 12:31 ` Philippe Gerum
2015-03-28 15:05 ` Gilles Chanteperdrix
1 sibling, 1 reply; 51+ messages in thread
From: Philippe Gerum @ 2015-03-28 12:31 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: GP Orcullo, xenomai@xenomai.org
On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>>> What happens in between the clocksource switch and head domain registration?
>>>>>
>>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>>>>> allocations
>>>>> [ 0.095333] Switching to clocksource ipipe_tsc
>>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
>>>>> [ 0.124618] Xenomai: hal/arm started.
>>>>>
>>>>> I'm trying to trace the code to find out where it stops. I tried
>>>>> adding printk to to the set and request functions and the code never
>>>>> runs when CONFIG_SMP is enabled.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> GP Orcullo
>>>>
>>>> It gets stuck on the call to ipipe_critical_enter:
>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>>>>
>>>> Which then gets stuck on ipipe_send_ipi:
>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>>>>
>>>
>>> I've traced the issue to the ipipe_processor_id() function. It returns
>>> the value 512 for processor 0. This value comes from cpu node property
>>> of the DT file.
>>>
>>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
>>> kernel to boot but it fails the switchtest regression test.
>>>
>>> Changing the cpu0 reg value on the DT file allows the kernel to boot
>>> and pass all the xenomai regression tests but it generates the
>>> following warning at boot:
>>
>> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
>> of the core.
>>
>>> What's the proper way of fixing this?
>>>
>>
>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
>> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
>> the opposite.
>>
>> We may have been lucky until now because the physical mapping seems to
>> have always matched the logical order on the SMP SoCs people used with
>> Xenomai so far, it looks like your A5 core does not follow this order.
>
> No, cpu_logical_map works both ways, it simply exchanges 0 with
> whatever number the boot cpu has
> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> it should work both ways.
It does not make sense. We just cannot do this with DT.
> At least, that was true before DT.
That is the issue with this code.
--
Philippe.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 12:31 ` Philippe Gerum
@ 2015-03-28 15:05 ` Gilles Chanteperdrix
2015-03-28 17:58 ` Philippe Gerum
0 siblings, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 15:05 UTC (permalink / raw)
To: Philippe Gerum; +Cc: GP Orcullo, xenomai@xenomai.org
On Sat, Mar 28, 2015 at 01:31:49PM +0100, Philippe Gerum wrote:
> On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
> > On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >>>>> What happens in between the clocksource switch and head domain registration?
> >>>>>
> >>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >>>>> allocations
> >>>>> [ 0.095333] Switching to clocksource ipipe_tsc
> >>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >>>>> [ 0.124618] Xenomai: hal/arm started.
> >>>>>
> >>>>> I'm trying to trace the code to find out where it stops. I tried
> >>>>> adding printk to to the set and request functions and the code never
> >>>>> runs when CONFIG_SMP is enabled.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> GP Orcullo
> >>>>
> >>>> It gets stuck on the call to ipipe_critical_enter:
> >>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >>>>
> >>>> Which then gets stuck on ipipe_send_ipi:
> >>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >>>>
> >>>
> >>> I've traced the issue to the ipipe_processor_id() function. It returns
> >>> the value 512 for processor 0. This value comes from cpu node property
> >>> of the DT file.
> >>>
> >>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >>> kernel to boot but it fails the switchtest regression test.
> >>>
> >>> Changing the cpu0 reg value on the DT file allows the kernel to boot
> >>> and pass all the xenomai regression tests but it generates the
> >>> following warning at boot:
> >>
> >> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >> of the core.
> >>
> >>> What's the proper way of fixing this?
> >>>
> >>
> >> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >> the opposite.
> >>
> >> We may have been lucky until now because the physical mapping seems to
> >> have always matched the logical order on the SMP SoCs people used with
> >> Xenomai so far, it looks like your A5 core does not follow this order.
> >
> > No, cpu_logical_map works both ways, it simply exchanges 0 with
> > whatever number the boot cpu has
> > so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> > it should work both ways.
>
> It does not make sense. We just cannot do this with DT.
In fact we can. The "only" downside is that we have to have
cpu_logical_map big enough to allow setting cpu_logical_map[512] to
0, so to have NR_CPUS at least 513. Setting up a separate
reverse map avoids this issue of course, so I will merge that patch
when it has been tested.
>
> > At least, that was true before DT.
>
> That is the issue with this code.
No the issue is that 512 is larger than 255 and given the way we
mask in hard_smp_processor_id(), this causes hard_smp_processor_id()
to return 0 instead of 512 for the boot cpu. The size of the MPIDR
mask has varied over time, and hard_smp_processor_id() was not
updated to reflect that change.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 15:05 ` Gilles Chanteperdrix
@ 2015-03-28 17:58 ` Philippe Gerum
2015-03-28 18:08 ` Philippe Gerum
2015-03-28 18:10 ` Gilles Chanteperdrix
0 siblings, 2 replies; 51+ messages in thread
From: Philippe Gerum @ 2015-03-28 17:58 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: GP Orcullo, xenomai@xenomai.org
On 03/28/2015 04:05 PM, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 01:31:49PM +0100, Philippe Gerum wrote:
>> On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
>>> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>>>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>>>>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>>>>> What happens in between the clocksource switch and head domain registration?
>>>>>>>
>>>>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>>>>>>> allocations
>>>>>>> [ 0.095333] Switching to clocksource ipipe_tsc
>>>>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
>>>>>>> [ 0.124618] Xenomai: hal/arm started.
>>>>>>>
>>>>>>> I'm trying to trace the code to find out where it stops. I tried
>>>>>>> adding printk to to the set and request functions and the code never
>>>>>>> runs when CONFIG_SMP is enabled.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> GP Orcullo
>>>>>>
>>>>>> It gets stuck on the call to ipipe_critical_enter:
>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>>>>>>
>>>>>> Which then gets stuck on ipipe_send_ipi:
>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>>>>>>
>>>>>
>>>>> I've traced the issue to the ipipe_processor_id() function. It returns
>>>>> the value 512 for processor 0. This value comes from cpu node property
>>>>> of the DT file.
>>>>>
>>>>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
>>>>> kernel to boot but it fails the switchtest regression test.
>>>>>
>>>>> Changing the cpu0 reg value on the DT file allows the kernel to boot
>>>>> and pass all the xenomai regression tests but it generates the
>>>>> following warning at boot:
>>>>
>>>> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
>>>> of the core.
>>>>
>>>>> What's the proper way of fixing this?
>>>>>
>>>>
>>>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
>>>> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
>>>> the opposite.
>>>>
>>>> We may have been lucky until now because the physical mapping seems to
>>>> have always matched the logical order on the SMP SoCs people used with
>>>> Xenomai so far, it looks like your A5 core does not follow this order.
>>>
>>> No, cpu_logical_map works both ways, it simply exchanges 0 with
>>> whatever number the boot cpu has
>>> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
>>> it should work both ways.
>>
>> It does not make sense. We just cannot do this with DT.
>
> In fact we can. The "only" downside is that we have to have
> cpu_logical_map big enough to allow setting cpu_logical_map[512] to
> 0, so to have NR_CPUS at least 513. Setting up a separate
> reverse map avoids this issue of course, so I will merge that patch
> when it has been tested.
>
>>
>>> At least, that was true before DT.
>>
>> That is the issue with this code.
>
> No the issue is that 512 is larger than 255 and given the way we
> mask in hard_smp_processor_id(), this causes hard_smp_processor_id()
> to return 0 instead of 512 for the boot cpu. The size of the MPIDR
> mask has varied over time, and hard_smp_processor_id() was not
> updated to reflect that change.
>
The fact that we might change the semantics of __cpu_logical_map[] to
make it a double-entry map does not make it a proper solution. The
regular kernel defines it as a logical->hardware identity mapping array,
I'd rather prefer your latest change which introduces a reverse map instead.
The calculations and masks used to extract the MPIDR fields have
obviously never changed over time, since this reflects hardware properties.
What has changed over time is the size of the logical map. The fact that
it could be capped to small values of NR_CPUS - which is a logical count
of CPUs by definition - is a strong hint that we cannot use hw ids as
indexes into this map.
Therefore, the introduction you have just made of the reverse map is a
not only a good idea, but is actually required.
-int __cpu_logical_map[NR_CPUS];
+#if NR_CPUS > 16
+u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
+#else
+u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
+#endif
commit dca463daa0151c5bbbd8ec8fd42882a3966d3c44
Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Date: Thu Nov 15 17:30:32 2012 +0000
ARM: kernel: enhance MPIDR macro definitions
Kernel subsystems other than the topology layer need the MPIDR
mask definitions to access the MPIDR without relying on hardcoded
masks. This patch moves the MPIDR register masks definition to
a header file and defines a macro to simplify access to MPIDR bit fields
representing affinity levels.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
--
Philippe.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 17:58 ` Philippe Gerum
@ 2015-03-28 18:08 ` Philippe Gerum
2015-03-28 22:29 ` GP Orcullo
2015-03-28 18:10 ` Gilles Chanteperdrix
1 sibling, 1 reply; 51+ messages in thread
From: Philippe Gerum @ 2015-03-28 18:08 UTC (permalink / raw)
To: GP Orcullo; +Cc: xenomai@xenomai.org
On 03/28/2015 06:58 PM, Philippe Gerum wrote:
> On 03/28/2015 04:05 PM, Gilles Chanteperdrix wrote:
>> On Sat, Mar 28, 2015 at 01:31:49PM +0100, Philippe Gerum wrote:
>>> On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
>>>> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>>>>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>>>>>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>>>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>>>>>> What happens in between the clocksource switch and head domain registration?
>>>>>>>>
>>>>>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>>>>>>>> allocations
>>>>>>>> [ 0.095333] Switching to clocksource ipipe_tsc
>>>>>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
>>>>>>>> [ 0.124618] Xenomai: hal/arm started.
>>>>>>>>
>>>>>>>> I'm trying to trace the code to find out where it stops. I tried
>>>>>>>> adding printk to to the set and request functions and the code never
>>>>>>>> runs when CONFIG_SMP is enabled.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> GP Orcullo
>>>>>>>
>>>>>>> It gets stuck on the call to ipipe_critical_enter:
>>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>>>>>>>
>>>>>>> Which then gets stuck on ipipe_send_ipi:
>>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>>>>>>>
>>>>>>
>>>>>> I've traced the issue to the ipipe_processor_id() function. It returns
>>>>>> the value 512 for processor 0. This value comes from cpu node property
>>>>>> of the DT file.
>>>>>>
>>>>>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
>>>>>> kernel to boot but it fails the switchtest regression test.
>>>>>>
>>>>>> Changing the cpu0 reg value on the DT file allows the kernel to boot
>>>>>> and pass all the xenomai regression tests but it generates the
>>>>>> following warning at boot:
>>>>>
>>>>> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
>>>>> of the core.
>>>>>
>>>>>> What's the proper way of fixing this?
>>>>>>
>>>>>
>>>>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
>>>>> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
>>>>> the opposite.
>>>>>
>>>>> We may have been lucky until now because the physical mapping seems to
>>>>> have always matched the logical order on the SMP SoCs people used with
>>>>> Xenomai so far, it looks like your A5 core does not follow this order.
>>>>
>>>> No, cpu_logical_map works both ways, it simply exchanges 0 with
>>>> whatever number the boot cpu has
>>>> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
>>>> it should work both ways.
>>>
>>> It does not make sense. We just cannot do this with DT.
>>
>> In fact we can. The "only" downside is that we have to have
>> cpu_logical_map big enough to allow setting cpu_logical_map[512] to
>> 0, so to have NR_CPUS at least 513. Setting up a separate
>> reverse map avoids this issue of course, so I will merge that patch
>> when it has been tested.
>>
>>>
>>>> At least, that was true before DT.
>>>
>>> That is the issue with this code.
>>
>> No the issue is that 512 is larger than 255 and given the way we
>> mask in hard_smp_processor_id(), this causes hard_smp_processor_id()
>> to return 0 instead of 512 for the boot cpu. The size of the MPIDR
>> mask has varied over time, and hard_smp_processor_id() was not
>> updated to reflect that change.
>>
>
> The fact that we might change the semantics of __cpu_logical_map[] to
> make it a double-entry map does not make it a proper solution. The
> regular kernel defines it as a logical->hardware identity mapping array,
> I'd rather prefer your latest change which introduces a reverse map instead.
>
> The calculations and masks used to extract the MPIDR fields have
> obviously never changed over time, since this reflects hardware properties.
>
> What has changed over time is the size of the logical map. The fact that
> it could be capped to small values of NR_CPUS - which is a logical count
> of CPUs by definition - is a strong hint that we cannot use hw ids as
> indexes into this map.
>
> Therefore, the introduction you have just made of the reverse map is a
> not only a good idea, but is actually required.
>
> -int __cpu_logical_map[NR_CPUS];
> +#if NR_CPUS > 16
> +u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
> +#else
> +u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
> +#endif
>
> commit dca463daa0151c5bbbd8ec8fd42882a3966d3c44
> Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Date: Thu Nov 15 17:30:32 2012 +0000
>
> ARM: kernel: enhance MPIDR macro definitions
>
> Kernel subsystems other than the topology layer need the MPIDR
> mask definitions to access the MPIDR without relying on hardcoded
> masks. This patch moves the MPIDR register masks definition to
> a header file and defines a macro to simplify access to MPIDR bit fields
> representing affinity levels.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Acked-by: Will Deacon <will.deacon@arm.com>
> Acked-by: Nicolas Pitre <nico@linaro.org>
>
Btw, this issue with the pipeline only exists because the legacy mode
has to be enabled with Xenomai 2.x (CONFIG_IPIPE_LEGACY). Xenomai 3.x
does not have this requirement for an intermediate hardware->logical
mapping in order to implement ipipe_processor_id(), and will happily
work with the regular current_thread_info()->cpu value.
--
Philippe.
^ permalink raw reply [flat|nested] 51+ messages in thread* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 18:08 ` Philippe Gerum
@ 2015-03-28 22:29 ` GP Orcullo
0 siblings, 0 replies; 51+ messages in thread
From: GP Orcullo @ 2015-03-28 22:29 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai@xenomai.org
On Sun, Mar 29, 2015 at 2:08 AM, Philippe Gerum <rpm@xenomai.org> wrote:
> On 03/28/2015 06:58 PM, Philippe Gerum wrote:
> > On 03/28/2015 04:05 PM, Gilles Chanteperdrix wrote:
> >> On Sat, Mar 28, 2015 at 01:31:49PM +0100, Philippe Gerum wrote:
> >>> On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
> >>>> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >>>>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >>>>>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com>
> wrote:
> >>>>>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com>
> wrote:
> >>>>>>>> What happens in between the clocksource switch and head domain
> registration?
> >>>>>>>>
> >>>>>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >>>>>>>> allocations
> >>>>>>>> [ 0.095333] Switching to clocksource ipipe_tsc
> >>>>>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >>>>>>>> [ 0.124618] Xenomai: hal/arm started.
> >>>>>>>>
> >>>>>>>> I'm trying to trace the code to find out where it stops. I tried
> >>>>>>>> adding printk to to the set and request functions and the code
> never
> >>>>>>>> runs when CONFIG_SMP is enabled.
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> GP Orcullo
> >>>>>>>
> >>>>>>> It gets stuck on the call to ipipe_critical_enter:
> >>>>>>>
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >>>>>>>
> >>>>>>> Which then gets stuck on ipipe_send_ipi:
> >>>>>>>
> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >>>>>>>
> >>>>>>
> >>>>>> I've traced the issue to the ipipe_processor_id() function. It
> returns
> >>>>>> the value 512 for processor 0. This value comes from cpu node
> property
> >>>>>> of the DT file.
> >>>>>>
> >>>>>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >>>>>> kernel to boot but it fails the switchtest regression test.
> >>>>>>
> >>>>>> Changing the cpu0 reg value on the DT file allows the kernel to boot
> >>>>>> and pass all the xenomai regression tests but it generates the
> >>>>>> following warning at boot:
> >>>>>
> >>>>> No, this property for armv7 must match MPIDR[23:0], i.e. the
> physical id
> >>>>> of the core.
> >>>>>
> >>>>>> What's the proper way of fixing this?
> >>>>>>
> >>>>>
> >>>>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's
> broken.
> >>>>> It assumes __cpu_logical_map[] is a hw->logical map, but it is
> actually
> >>>>> the opposite.
> >>>>>
> >>>>> We may have been lucky until now because the physical mapping seems
> to
> >>>>> have always matched the logical order on the SMP SoCs people used
> with
> >>>>> Xenomai so far, it looks like your A5 core does not follow this
> order.
> >>>>
> >>>> No, cpu_logical_map works both ways, it simply exchanges 0 with
> >>>> whatever number the boot cpu has
> >>>> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> >>>> it should work both ways.
> >>>
> >>> It does not make sense. We just cannot do this with DT.
> >>
> >> In fact we can. The "only" downside is that we have to have
> >> cpu_logical_map big enough to allow setting cpu_logical_map[512] to
> >> 0, so to have NR_CPUS at least 513. Setting up a separate
> >> reverse map avoids this issue of course, so I will merge that patch
> >> when it has been tested.
> >>
> >>>
> >>>> At least, that was true before DT.
> >>>
> >>> That is the issue with this code.
> >>
> >> No the issue is that 512 is larger than 255 and given the way we
> >> mask in hard_smp_processor_id(), this causes hard_smp_processor_id()
> >> to return 0 instead of 512 for the boot cpu. The size of the MPIDR
> >> mask has varied over time, and hard_smp_processor_id() was not
> >> updated to reflect that change.
> >>
> >
> > The fact that we might change the semantics of __cpu_logical_map[] to
> > make it a double-entry map does not make it a proper solution. The
> > regular kernel defines it as a logical->hardware identity mapping array,
> > I'd rather prefer your latest change which introduces a reverse map
> instead.
> >
> > The calculations and masks used to extract the MPIDR fields have
> > obviously never changed over time, since this reflects hardware
> properties.
> >
> > What has changed over time is the size of the logical map. The fact that
> > it could be capped to small values of NR_CPUS - which is a logical count
> > of CPUs by definition - is a strong hint that we cannot use hw ids as
> > indexes into this map.
> >
> > Therefore, the introduction you have just made of the reverse map is a
> > not only a good idea, but is actually required.
> >
> > -int __cpu_logical_map[NR_CPUS];
> > +#if NR_CPUS > 16
> > +u32 __cpu_logical_map[NR_CPUS] = { [0 ... NR_CPUS-1] = MPIDR_INVALID };
> > +#else
> > +u32 __cpu_logical_map[16] = { [0 ... 15] = MPIDR_INVALID };
> > +#endif
> >
> > commit dca463daa0151c5bbbd8ec8fd42882a3966d3c44
> > Author: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Date: Thu Nov 15 17:30:32 2012 +0000
> >
> > ARM: kernel: enhance MPIDR macro definitions
> >
> > Kernel subsystems other than the topology layer need the MPIDR
> > mask definitions to access the MPIDR without relying on hardcoded
> > masks. This patch moves the MPIDR register masks definition to
> > a header file and defines a macro to simplify access to MPIDR bit
> fields
> > representing affinity levels.
> >
> > Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> > Acked-by: Will Deacon <will.deacon@arm.com>
> > Acked-by: Nicolas Pitre <nico@linaro.org>
> >
>
> Btw, this issue with the pipeline only exists because the legacy mode
> has to be enabled with Xenomai 2.x (CONFIG_IPIPE_LEGACY). Xenomai 3.x
> does not have this requirement for an intermediate hardware->logical
> mapping in order to implement ipipe_processor_id(), and will happily
> work with the regular current_thread_info()->cpu value.
>
> --
> Philippe.
>
Thanks, I will try Xenomai 3.x
GP Orcullo
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 17:58 ` Philippe Gerum
2015-03-28 18:08 ` Philippe Gerum
@ 2015-03-28 18:10 ` Gilles Chanteperdrix
2015-03-28 18:18 ` Philippe Gerum
1 sibling, 1 reply; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 18:10 UTC (permalink / raw)
To: Philippe Gerum; +Cc: GP Orcullo, xenomai@xenomai.org
On Sat, Mar 28, 2015 at 06:58:14PM +0100, Philippe Gerum wrote:
> On 03/28/2015 04:05 PM, Gilles Chanteperdrix wrote:
> > On Sat, Mar 28, 2015 at 01:31:49PM +0100, Philippe Gerum wrote:
> >> On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
> >>> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >>>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >>>>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >>>>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >>>>>>> What happens in between the clocksource switch and head domain registration?
> >>>>>>>
> >>>>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >>>>>>> allocations
> >>>>>>> [ 0.095333] Switching to clocksource ipipe_tsc
> >>>>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >>>>>>> [ 0.124618] Xenomai: hal/arm started.
> >>>>>>>
> >>>>>>> I'm trying to trace the code to find out where it stops. I tried
> >>>>>>> adding printk to to the set and request functions and the code never
> >>>>>>> runs when CONFIG_SMP is enabled.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>>
> >>>>>>> GP Orcullo
> >>>>>>
> >>>>>> It gets stuck on the call to ipipe_critical_enter:
> >>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >>>>>>
> >>>>>> Which then gets stuck on ipipe_send_ipi:
> >>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >>>>>>
> >>>>>
> >>>>> I've traced the issue to the ipipe_processor_id() function. It returns
> >>>>> the value 512 for processor 0. This value comes from cpu node property
> >>>>> of the DT file.
> >>>>>
> >>>>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >>>>> kernel to boot but it fails the switchtest regression test.
> >>>>>
> >>>>> Changing the cpu0 reg value on the DT file allows the kernel to boot
> >>>>> and pass all the xenomai regression tests but it generates the
> >>>>> following warning at boot:
> >>>>
> >>>> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >>>> of the core.
> >>>>
> >>>>> What's the proper way of fixing this?
> >>>>>
> >>>>
> >>>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >>>> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >>>> the opposite.
> >>>>
> >>>> We may have been lucky until now because the physical mapping seems to
> >>>> have always matched the logical order on the SMP SoCs people used with
> >>>> Xenomai so far, it looks like your A5 core does not follow this order.
> >>>
> >>> No, cpu_logical_map works both ways, it simply exchanges 0 with
> >>> whatever number the boot cpu has
> >>> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> >>> it should work both ways.
> >>
> >> It does not make sense. We just cannot do this with DT.
> >
> > In fact we can. The "only" downside is that we have to have
> > cpu_logical_map big enough to allow setting cpu_logical_map[512] to
> > 0, so to have NR_CPUS at least 513. Setting up a separate
> > reverse map avoids this issue of course, so I will merge that patch
> > when it has been tested.
> >
> >>
> >>> At least, that was true before DT.
> >>
> >> That is the issue with this code.
> >
> > No the issue is that 512 is larger than 255 and given the way we
> > mask in hard_smp_processor_id(), this causes hard_smp_processor_id()
> > to return 0 instead of 512 for the boot cpu. The size of the MPIDR
> > mask has varied over time, and hard_smp_processor_id() was not
> > updated to reflect that change.
> >
>
> The fact that we might change the semantics of __cpu_logical_map[] to
> make it a double-entry map does not make it a proper solution. The
> regular kernel defines it as a logical->hardware identity mapping array,
> I'd rather prefer your latest change which introduces a reverse map instead.
>
> The calculations and masks used to extract the MPIDR fields have
> obviously never changed over time, since this reflects hardware properties.
See commit cb8cf4f821044f140ea5b9c8d4f816f0c05fab44
As the OP explained, it is to take the "cluster ID" into account.
Maybe if we look at the ARM11 MPCORE specification, it had no such
notion of cluster ID. So, yes, hardware registers do evolve over
time. And the code to parse them evolves too.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 18:10 ` Gilles Chanteperdrix
@ 2015-03-28 18:18 ` Philippe Gerum
2015-03-28 18:28 ` Gilles Chanteperdrix
0 siblings, 1 reply; 51+ messages in thread
From: Philippe Gerum @ 2015-03-28 18:18 UTC (permalink / raw)
To: Gilles Chanteperdrix; +Cc: GP Orcullo, xenomai@xenomai.org
On 03/28/2015 07:10 PM, Gilles Chanteperdrix wrote:
> On Sat, Mar 28, 2015 at 06:58:14PM +0100, Philippe Gerum wrote:
>> On 03/28/2015 04:05 PM, Gilles Chanteperdrix wrote:
>>> On Sat, Mar 28, 2015 at 01:31:49PM +0100, Philippe Gerum wrote:
>>>> On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
>>>>> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
>>>>>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
>>>>>>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>>>>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
>>>>>>>>> What happens in between the clocksource switch and head domain registration?
>>>>>>>>>
>>>>>>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
>>>>>>>>> allocations
>>>>>>>>> [ 0.095333] Switching to clocksource ipipe_tsc
>>>>>>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
>>>>>>>>> [ 0.124618] Xenomai: hal/arm started.
>>>>>>>>>
>>>>>>>>> I'm trying to trace the code to find out where it stops. I tried
>>>>>>>>> adding printk to to the set and request functions and the code never
>>>>>>>>> runs when CONFIG_SMP is enabled.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> GP Orcullo
>>>>>>>>
>>>>>>>> It gets stuck on the call to ipipe_critical_enter:
>>>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
>>>>>>>>
>>>>>>>> Which then gets stuck on ipipe_send_ipi:
>>>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
>>>>>>>>
>>>>>>>
>>>>>>> I've traced the issue to the ipipe_processor_id() function. It returns
>>>>>>> the value 512 for processor 0. This value comes from cpu node property
>>>>>>> of the DT file.
>>>>>>>
>>>>>>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
>>>>>>> kernel to boot but it fails the switchtest regression test.
>>>>>>>
>>>>>>> Changing the cpu0 reg value on the DT file allows the kernel to boot
>>>>>>> and pass all the xenomai regression tests but it generates the
>>>>>>> following warning at boot:
>>>>>>
>>>>>> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
>>>>>> of the core.
>>>>>>
>>>>>>> What's the proper way of fixing this?
>>>>>>>
>>>>>>
>>>>>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
>>>>>> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
>>>>>> the opposite.
>>>>>>
>>>>>> We may have been lucky until now because the physical mapping seems to
>>>>>> have always matched the logical order on the SMP SoCs people used with
>>>>>> Xenomai so far, it looks like your A5 core does not follow this order.
>>>>>
>>>>> No, cpu_logical_map works both ways, it simply exchanges 0 with
>>>>> whatever number the boot cpu has
>>>>> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
>>>>> it should work both ways.
>>>>
>>>> It does not make sense. We just cannot do this with DT.
>>>
>>> In fact we can. The "only" downside is that we have to have
>>> cpu_logical_map big enough to allow setting cpu_logical_map[512] to
>>> 0, so to have NR_CPUS at least 513. Setting up a separate
>>> reverse map avoids this issue of course, so I will merge that patch
>>> when it has been tested.
>>>
>>>>
>>>>> At least, that was true before DT.
>>>>
>>>> That is the issue with this code.
>>>
>>> No the issue is that 512 is larger than 255 and given the way we
>>> mask in hard_smp_processor_id(), this causes hard_smp_processor_id()
>>> to return 0 instead of 512 for the boot cpu. The size of the MPIDR
>>> mask has varied over time, and hard_smp_processor_id() was not
>>> updated to reflect that change.
>>>
>>
>> The fact that we might change the semantics of __cpu_logical_map[] to
>> make it a double-entry map does not make it a proper solution. The
>> regular kernel defines it as a logical->hardware identity mapping array,
>> I'd rather prefer your latest change which introduces a reverse map instead.
>>
>> The calculations and masks used to extract the MPIDR fields have
>> obviously never changed over time, since this reflects hardware properties.
>
> See commit cb8cf4f821044f140ea5b9c8d4f816f0c05fab44
>
> As the OP explained, it is to take the "cluster ID" into account.
> Maybe if we look at the ARM11 MPCORE specification, it had no such
> notion of cluster ID. So, yes, hardware registers do evolve over
> time. And the code to parse them evolves too.
>
This commit does not change the way the MPIDR is split in fields, which
is my point. Said differently, MPIDR_AFFINITY_LEVEL did not change since
it was introduced:
git diff dca463d..HEAD arch/arm/include/asm/cputype.h
--
Philippe.
^ permalink raw reply [flat|nested] 51+ messages in thread
* Re: [Xenomai] Boot failure when CONFIG_XENOMAI is enabled
2015-03-28 18:18 ` Philippe Gerum
@ 2015-03-28 18:28 ` Gilles Chanteperdrix
0 siblings, 0 replies; 51+ messages in thread
From: Gilles Chanteperdrix @ 2015-03-28 18:28 UTC (permalink / raw)
To: Philippe Gerum; +Cc: GP Orcullo, xenomai@xenomai.org
On Sat, Mar 28, 2015 at 07:18:27PM +0100, Philippe Gerum wrote:
> On 03/28/2015 07:10 PM, Gilles Chanteperdrix wrote:
> > On Sat, Mar 28, 2015 at 06:58:14PM +0100, Philippe Gerum wrote:
> >> On 03/28/2015 04:05 PM, Gilles Chanteperdrix wrote:
> >>> On Sat, Mar 28, 2015 at 01:31:49PM +0100, Philippe Gerum wrote:
> >>>> On 03/28/2015 12:36 PM, Gilles Chanteperdrix wrote:
> >>>>> On Sat, Mar 28, 2015 at 10:51:30AM +0100, Philippe Gerum wrote:
> >>>>>> On 03/28/2015 10:05 AM, GP Orcullo wrote:
> >>>>>>> On Fri, Mar 27, 2015 at 8:12 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >>>>>>>> On Fri, Mar 27, 2015 at 6:19 PM, GP Orcullo <kinsamanka@gmail.com> wrote:
> >>>>>>>>> What happens in between the clocksource switch and head domain registration?
> >>>>>>>>>
> >>>>>>>>> [ 0.090129] DMA: preallocated 4096 KiB pool for atomic coherent
> >>>>>>>>> allocations
> >>>>>>>>> [ 0.095333] Switching to clocksource ipipe_tsc
> >>>>>>>>> [ 0.122397] I-pipe: head domain Xenomai registered.
> >>>>>>>>> [ 0.124618] Xenomai: hal/arm started.
> >>>>>>>>>
> >>>>>>>>> I'm trying to trace the code to find out where it stops. I tried
> >>>>>>>>> adding printk to to the set and request functions and the code never
> >>>>>>>>> runs when CONFIG_SMP is enabled.
> >>>>>>>>>
> >>>>>>>>> Thanks,
> >>>>>>>>>
> >>>>>>>>> GP Orcullo
> >>>>>>>>
> >>>>>>>> It gets stuck on the call to ipipe_critical_enter:
> >>>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/timer.c?id=ipipe-core-3.10.32-arm-7#n279
> >>>>>>>>
> >>>>>>>> Which then gets stuck on ipipe_send_ipi:
> >>>>>>>> http://git.xenomai.org/ipipe-gch.git/tree/kernel/ipipe/core.c?id=ipipe-core-3.10.32-arm-7#n1533
> >>>>>>>>
> >>>>>>>
> >>>>>>> I've traced the issue to the ipipe_processor_id() function. It returns
> >>>>>>> the value 512 for processor 0. This value comes from cpu node property
> >>>>>>> of the DT file.
> >>>>>>>
> >>>>>>> Changing ipipe_processor_id() to return 0 instead of 512 allows the
> >>>>>>> kernel to boot but it fails the switchtest regression test.
> >>>>>>>
> >>>>>>> Changing the cpu0 reg value on the DT file allows the kernel to boot
> >>>>>>> and pass all the xenomai regression tests but it generates the
> >>>>>>> following warning at boot:
> >>>>>>
> >>>>>> No, this property for armv7 must match MPIDR[23:0], i.e. the physical id
> >>>>>> of the core.
> >>>>>>
> >>>>>>> What's the proper way of fixing this?
> >>>>>>>
> >>>>>>
> >>>>>> By fixing ipipe_processor_id() in the CONFIG_LEGACY case, it's broken.
> >>>>>> It assumes __cpu_logical_map[] is a hw->logical map, but it is actually
> >>>>>> the opposite.
> >>>>>>
> >>>>>> We may have been lucky until now because the physical mapping seems to
> >>>>>> have always matched the logical order on the SMP SoCs people used with
> >>>>>> Xenomai so far, it looks like your A5 core does not follow this order.
> >>>>>
> >>>>> No, cpu_logical_map works both ways, it simply exchanges 0 with
> >>>>> whatever number the boot cpu has
> >>>>> so, since cpu_logical_map[0] == 512 and cpu_logical_map[512] == 0
> >>>>> it should work both ways.
> >>>>
> >>>> It does not make sense. We just cannot do this with DT.
> >>>
> >>> In fact we can. The "only" downside is that we have to have
> >>> cpu_logical_map big enough to allow setting cpu_logical_map[512] to
> >>> 0, so to have NR_CPUS at least 513. Setting up a separate
> >>> reverse map avoids this issue of course, so I will merge that patch
> >>> when it has been tested.
> >>>
> >>>>
> >>>>> At least, that was true before DT.
> >>>>
> >>>> That is the issue with this code.
> >>>
> >>> No the issue is that 512 is larger than 255 and given the way we
> >>> mask in hard_smp_processor_id(), this causes hard_smp_processor_id()
> >>> to return 0 instead of 512 for the boot cpu. The size of the MPIDR
> >>> mask has varied over time, and hard_smp_processor_id() was not
> >>> updated to reflect that change.
> >>>
> >>
> >> The fact that we might change the semantics of __cpu_logical_map[] to
> >> make it a double-entry map does not make it a proper solution. The
> >> regular kernel defines it as a logical->hardware identity mapping array,
> >> I'd rather prefer your latest change which introduces a reverse map instead.
> >>
> >> The calculations and masks used to extract the MPIDR fields have
> >> obviously never changed over time, since this reflects hardware properties.
> >
> > See commit cb8cf4f821044f140ea5b9c8d4f816f0c05fab44
> >
> > As the OP explained, it is to take the "cluster ID" into account.
> > Maybe if we look at the ARM11 MPCORE specification, it had no such
> > notion of cluster ID. So, yes, hardware registers do evolve over
> > time. And the code to parse them evolves too.
> >
>
> This commit does not change the way the MPIDR is split in fields, which
> is my point. Said differently, MPIDR_AFFINITY_LEVEL did not change since
> it was introduced:
>
> git diff dca463d..HEAD arch/arm/include/asm/cputype.h
The linux kernel code before that commit did not take into account
the fact that there could be several "clusters", it simply masked
the mpidr register with 0xff and this is what we based the I-pipe
code on. Implementing a reverse map is more complicated than what I
did, if we want to allow that cluster ID to have a different value.
We probably have to add the call to the MPIDR_AFFINITY_LEVEL to the
ipipe_processor_id definition, I have to look more carefully at how
all this works.
--
Gilles.
^ permalink raw reply [flat|nested] 51+ messages in thread
end of thread, other threads:[~2015-04-10 21:39 UTC | newest]
Thread overview: 51+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-18 14:11 [Xenomai] Boot failure when CONFIG_XENOMAI is enabled GP Orcullo
2015-03-18 14:21 ` Gilles Chanteperdrix
2015-03-18 14:48 ` GP Orcullo
2015-03-18 14:56 ` Gilles Chanteperdrix
2015-03-25 14:48 ` GP Orcullo
2015-03-25 14:57 ` Gilles Chanteperdrix
2015-03-25 15:25 ` GP Orcullo
2015-03-25 16:08 ` Gilles Chanteperdrix
2015-03-25 23:44 ` GP Orcullo
2015-03-27 10:19 ` GP Orcullo
2015-03-27 12:12 ` GP Orcullo
2015-03-28 9:05 ` GP Orcullo
2015-03-28 9:51 ` Philippe Gerum
2015-03-28 11:36 ` Gilles Chanteperdrix
2015-03-28 12:27 ` GP Orcullo
2015-03-28 13:06 ` Gilles Chanteperdrix
2015-03-28 13:12 ` Gilles Chanteperdrix
2015-03-28 13:22 ` Gilles Chanteperdrix
2015-03-28 13:37 ` Gilles Chanteperdrix
2015-03-28 15:20 ` GP Orcullo
2015-03-28 17:23 ` Gilles Chanteperdrix
2015-03-28 19:14 ` Gilles Chanteperdrix
2015-03-28 13:53 ` Gilles Chanteperdrix
2015-03-28 14:56 ` Gilles Chanteperdrix
2015-03-28 15:17 ` GP Orcullo
2015-03-28 15:19 ` Gilles Chanteperdrix
2015-03-28 15:56 ` GP Orcullo
2015-03-28 16:02 ` Gilles Chanteperdrix
2015-03-28 18:59 ` Gilles Chanteperdrix
2015-03-28 22:38 ` GP Orcullo
2015-03-29 11:06 ` Gilles Chanteperdrix
2015-03-29 11:59 ` GP Orcullo
2015-03-29 12:02 ` Gilles Chanteperdrix
2015-03-29 12:09 ` Gilles Chanteperdrix
2015-03-29 12:38 ` GP Orcullo
2015-03-29 12:44 ` Gilles Chanteperdrix
2015-03-29 12:56 ` GP Orcullo
2015-03-30 15:21 ` GP Orcullo
2015-03-30 15:28 ` Gilles Chanteperdrix
2015-04-10 20:08 ` Henry Bausley
2015-04-10 21:33 ` Gilles Chanteperdrix
2015-04-10 21:39 ` Gilles Chanteperdrix
2015-03-29 12:18 ` Gilles Chanteperdrix
2015-03-28 12:31 ` Philippe Gerum
2015-03-28 15:05 ` Gilles Chanteperdrix
2015-03-28 17:58 ` Philippe Gerum
2015-03-28 18:08 ` Philippe Gerum
2015-03-28 22:29 ` GP Orcullo
2015-03-28 18:10 ` Gilles Chanteperdrix
2015-03-28 18:18 ` Philippe Gerum
2015-03-28 18:28 ` Gilles Chanteperdrix
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.