Running kexec on mx6

Running kexec on mx6

[Fabio Estevam]

Hi,

I am trying to load a kernel and dtb via kexec on a mx6solo wandboard
board running 4.1-rc7:

root at wandboard-solo:~# kexec -d -l /mnt/zImage --dtb /mnt/imx6dl-wandboard.dtb -
-command-line="console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw"
my_load:667: do
kernel: 0x75da4008 kernel_size: 0x5be000
kexec_load: entry = 0x10008000 flags = 0x280000
nr_segments = 2
segment[0].buf   = 0x75da4008
segment[0].bufsz = 0x5be000
segment[0].mem   = 0x10008000
segment[0].memsz = 0x5be000
segment[1].buf   = 0x1ce9008
segment[1].bufsz = 0x6c87
segment[1].mem   = 0x116f9000
segment[1].memsz = 0x7000
root at wandboard-solo:~# kexec -e
[   62.581795] kexec: Starting new kernel
[   62.585570] Disabling non-boot CPUs ...
[   62.589485] Bye!

And then nothing comes out.

Does anyone have any suggestions on how I can debug this?

Thanks,

Fabio Estevam

Running kexec on mx6

[Fabio Estevam]

On Thu, Jun 11, 2015 at 9:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi,
>
> I am trying to load a kernel and dtb via kexec on a mx6solo wandboard
> board running 4.1-rc7:
>
> root at wandboard-solo:~# kexec -d -l /mnt/zImage --dtb /mnt/imx6dl-wandboard.dtb -
> -command-line="console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw"
> my_load:667: do
> kernel: 0x75da4008 kernel_size: 0x5be000
> kexec_load: entry = 0x10008000 flags = 0x280000
> nr_segments = 2
> segment[0].buf   = 0x75da4008
> segment[0].bufsz = 0x5be000
> segment[0].mem   = 0x10008000
> segment[0].memsz = 0x5be000
> segment[1].buf   = 0x1ce9008
> segment[1].bufsz = 0x6c87
> segment[1].mem   = 0x116f9000
> segment[1].memsz = 0x7000
> root at wandboard-solo:~# kexec -e
> [   62.581795] kexec: Starting new kernel
> [   62.585570] Disabling non-boot CPUs ...
> [   62.589485] Bye!
>
> And then nothing comes out.

If I use a 4.1-rc7 to be loaded via kexec then I get the
"Uncompressing Linux... done, booting the kernel" message.

Initially I was loading a 3.10 kernel from a running 4.1-rc7.

Now I see:

root at wandboard-solo:~# kexec -d -l /tmp/zImage --dtb /tmp/imx6dl-wandboard.dtb -
-command-line="console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait rw"
my_load:667: do
kernel: 0x75d95008 kernel_size: 0x5c99d8
kexec_load: entry = 0x10008000 flags = 0x280000
nr_segments = 2
segment[0].buf   = 0x75d95008
segment[0].bufsz = 0x5c99d8
segment[0].mem   = 0x10008000
segment[0].memsz = 0x5ca000
segment[1].buf   = 0x1f4008
segment[1].bufsz = 0x6d63
segment[1].mem   = 0x11728000
segment[1].memsz = 0x7000
root at wandboard-solo:~# kexec -e
[   27.591555] kexec: Starting new kernel
[   27.595331] Disabling non-boot CPUs ...
[   27.599250] Bye!
Uncompressing Linux... done, booting the kernel.

Running kexec on mx6

[Russell King - ARM Linux]

On Fri, Jun 12, 2015 at 10:53:13AM -0300, Fabio Estevam wrote:
> On Thu, Jun 11, 2015 at 9:08 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > Hi,
> >
> > I am trying to load a kernel and dtb via kexec on a mx6solo wandboard
> > board running 4.1-rc7:
> >
> > root at wandboard-solo:~# kexec -d -l /mnt/zImage --dtb /mnt/imx6dl-wandboard.dtb -
> > -command-line="console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw"
> > my_load:667: do
> > kernel: 0x75da4008 kernel_size: 0x5be000
> > kexec_load: entry = 0x10008000 flags = 0x280000
> > nr_segments = 2
> > segment[0].buf   = 0x75da4008
> > segment[0].bufsz = 0x5be000
> > segment[0].mem   = 0x10008000
> > segment[0].memsz = 0x5be000
> > segment[1].buf   = 0x1ce9008
> > segment[1].bufsz = 0x6c87
> > segment[1].mem   = 0x116f9000
> > segment[1].memsz = 0x7000
> > root at wandboard-solo:~# kexec -e
> > [   62.581795] kexec: Starting new kernel
> > [   62.585570] Disabling non-boot CPUs ...
> > [   62.589485] Bye!
> >
> > And then nothing comes out.
> 
> If I use a 4.1-rc7 to be loaded via kexec then I get the
> "Uncompressing Linux... done, booting the kernel" message.
> 
> Initially I was loading a 3.10 kernel from a running 4.1-rc7.
> 
> Now I see:
> 
> root at wandboard-solo:~# kexec -d -l /tmp/zImage --dtb /tmp/imx6dl-wandboard.dtb -
> -command-line="console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait rw"
> my_load:667: do
> kernel: 0x75d95008 kernel_size: 0x5c99d8
> kexec_load: entry = 0x10008000 flags = 0x280000
> nr_segments = 2
> segment[0].buf   = 0x75d95008
> segment[0].bufsz = 0x5c99d8
> segment[0].mem   = 0x10008000
> segment[0].memsz = 0x5ca000
> segment[1].buf   = 0x1f4008
> segment[1].bufsz = 0x6d63
> segment[1].mem   = 0x11728000
> segment[1].memsz = 0x7000
> root at wandboard-solo:~# kexec -e
> [   27.591555] kexec: Starting new kernel
> [   27.595331] Disabling non-boot CPUs ...
> [   27.599250] Bye!
> Uncompressing Linux... done, booting the kernel.

Has it ever worked, or is this a regression?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Running kexec on mx6

[Fabio Estevam]

On Fri, Jun 12, 2015 at 10:53 AM, Fabio Estevam <festevam@gmail.com> wrote:

> root at wandboard-solo:~# kexec -d -l /tmp/zImage --dtb /tmp/imx6dl-wandboard.dtb -
> -command-line="console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait rw"
> my_load:667: do
> kernel: 0x75d95008 kernel_size: 0x5c99d8
> kexec_load: entry = 0x10008000 flags = 0x280000
> nr_segments = 2
> segment[0].buf   = 0x75d95008
> segment[0].bufsz = 0x5c99d8
> segment[0].mem   = 0x10008000
> segment[0].memsz = 0x5ca000
> segment[1].buf   = 0x1f4008
> segment[1].bufsz = 0x6d63
> segment[1].mem   = 0x11728000
> segment[1].memsz = 0x7000
> root at wandboard-solo:~# kexec -e
> [   27.591555] kexec: Starting new kernel
> [   27.595331] Disabling non-boot CPUs ...
> [   27.599250] Bye!
> Uncompressing Linux... done, booting the kernel.

Ok, so here is the "kexec -e" output with earlyprintk enabled:

root at wandboard-solo:~# kexec -e
[   33.853279] kexec: Starting new kernel
[   33.857076] Disabling non-boot CPUs ...
[   33.861107] Bye!
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.1.0-rc7-00063-gcff100f (fabio at fabio-Latitude-E645
[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructie
[    0.000000] Machine model: Wandboard i.MX6 Dual Lite Board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: Reserved 16 MiB at 0x4f000000
[    0.000000] Memory policy: Data cache writeback

And then it hangs here.

Running kexec on mx6

[Fabio Estevam]

Hi Russell,

On Fri, Jun 12, 2015 at 11:01 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> Has it ever worked, or is this a regression?

It is my first time using kexec. Also tested running a 3.10 kernel and
it also failed, so I think kexec has never worked on mx6.

Thanks

Running kexec on mx6

[Robert Schwebel]

On Fri, Jun 12, 2015 at 11:06:39AM -0300, Fabio Estevam wrote:
> On Fri, Jun 12, 2015 at 11:01 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > Has it ever worked, or is this a regression?
> 
> It is my first time using kexec. Also tested running a 3.10 kernel and
> it also failed, so I think kexec has never worked on mx6.

We have used kexec on MX6 before. Adding Philipp to Cc:.

rsc
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

Running kexec on mx6

[Fabio Estevam]

Hi Philipp,

On Fri, Jun 12, 2015 at 2:54 PM, Robert Schwebel
<r.schwebel@pengutronix.de> wrote:
> On Fri, Jun 12, 2015 at 11:06:39AM -0300, Fabio Estevam wrote:
>> On Fri, Jun 12, 2015 at 11:01 AM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>
>> > Has it ever worked, or is this a regression?
>>
>> It is my first time using kexec. Also tested running a 3.10 kernel and
>> it also failed, so I think kexec has never worked on mx6.
>
> We have used kexec on MX6 before. Adding Philipp to Cc:.

Do you recall which kernel version you used to get kexec working on mx6?

Any extra patches needed?

Thanks

Running kexec on mx6

[Fabio Estevam]

On Fri, Jun 12, 2015 at 11:02 AM, Fabio Estevam <festevam@gmail.com> wrote:

> root at wandboard-solo:~# kexec -e
> [   33.853279] kexec: Starting new kernel
> [   33.857076] Disabling non-boot CPUs ...
> [   33.861107] Bye!
> Uncompressing Linux... done, booting the kernel.
> [    0.000000] Booting Linux on physical CPU 0x0
> [    0.000000] Linux version 4.1.0-rc7-00063-gcff100f (fabio at fabio-Latitude-E645
> [    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
> [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructie
> [    0.000000] Machine model: Wandboard i.MX6 Dual Lite Board
> [    0.000000] bootconsole [earlycon0] enabled
> [    0.000000] cma: Reserved 16 MiB at 0x4f000000
> [    0.000000] Memory policy: Data cache writeback
>
> And then it hangs here.

I am using a mx6qsabresd now and running linux-next. In this case I am
able to proceed with the boot further:

root at wandboard-solo:~# kexec -d -l /tmp/zImage --dtb /tmp/imx6q-sabresd.dtb --co
mmand-line="console=ttymxc0,115200 earlyprintk root=/dev/mmcblk0p2 rootwait rw"
my_load:667: do
kernel: 0x75dd3008 kernel_size: 0x5dfc18
kexec_load: entry = 0x10008000 flags = 0x280000
nr_segments = 2
segment[0].buf   = 0x75dd3008
segment[0].bufsz = 0x5dfc18
segment[0].mem   = 0x10008000
segment[0].memsz = 0x5e0000
segment[1].buf   = 0x3f0008
segment[1].bufsz = 0x8970
segment[1].mem   = 0x11781000
segment[1].memsz = 0x9000
root at wandboard-solo:~# kexec -e
[   70.267087] kexec: Starting new kernel
[   70.270941] Disabling non-boot CPUs ...
[   70.317951] CPU1: shutdown
[   70.447787] CPU2: shutdown
[   70.517750] CPU3: shutdown
[   70.551034] Bye!
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.1.0-rc7-next-20150615-dirty
(fabio at fabio-Latitude-E6410) (gcc version 4.7.3 (Ubuntu/Linaro
4.7.3-12ubu5
[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] Machine model: Freescale i.MX6 Quad SABRE Smart Device Board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: Reserved 16 MiB at 0x4f000000
[    0.000000] Memory policy: Data cache writealloc
[    0.000000] PERCPU: Embedded 12 pages/cpu @be795000 s16960 r8192
d24000 u49152
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.
Total pages: 260096
[    0.000000] Kernel command line: console=ttymxc0,115200 earlyprintk
root=/dev/mmcblk0p2 rootwait rw
[    0.000000] PID hash table entries: 4096 (order: 2, 16384 bytes)
[    0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[    0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[    0.000000] Memory: 1003112K/1048576K available (7767K kernel code,
408K rwdata, 2648K rodata, 420K init, 8371K bss, 29080K reserv)
[    0.000000] Virtual kernel memory layout:
[    0.000000]     vector  : 0xffff0000 - 0xffff1000   (   4 kB)
[    0.000000]     fixmap  : 0xffc00000 - 0xfff00000   (3072 kB)
[    0.000000]     vmalloc : 0xc0800000 - 0xff000000   (1000 MB)
[    0.000000]     lowmem  : 0x80000000 - 0xc0000000   (1024 MB)
[    0.000000]     pkmap   : 0x7fe00000 - 0x80000000   (   2 MB)
[    0.000000]     modules : 0x7f000000 - 0x7fe00000   (  14 MB)
[    0.000000]       .text : 0x80008000 - 0x80a3408c   (10417 kB)
[    0.000000]       .init : 0x80a35000 - 0x80a9e000   ( 420 kB)
[    0.000000]       .data : 0x80a9e000 - 0x80b04040   ( 409 kB)
[    0.000000]        .bss : 0x80b07000 - 0x81333dc4   (8372 kB)
[    0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[    0.000000] Running RCU self tests
[    0.000000] Hierarchical RCU implementation.
[    0.000000]  RCU lockdep checking is enabled.
[    0.000000]  Additional per-CPU info printed with stalls.
[    0.000000]  Build-time adjustment of leaf fanout to 32.
[    0.000000] NR_IRQS:16 nr_irqs:16 16
[    0.000000] L2C-310 erratum 769419 enabled
[    0.000000] L2C-310 enabling early BRESP for Cortex-A9
[    0.000000] L2C-310: enabling full line of zeros but not enabled in Cortex-A9
[    0.000000] L2C-310 ID prefetch enabled, offset 1 lines
[    0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[    0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[    0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[    0.000000] Switching to timer-based delay loop, resolution 333ns
[    0.000006] sched_clock: 32 bits at 3000kHz, resolution 333ns,
wraps every 715827882841ns
[    0.008281] clocksource: mxc_timer1: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 637086815595 ns
[    0.019091] Console: colour dummy device 80x30
[    0.023649] Lock dependency validator: Copyright (c) 2006 Red Hat,
Inc., Ingo Molnar
[    0.031478] ... MAX_LOCKDEP_SUBCLASSES:  8
[    0.035671] ... MAX_LOCK_DEPTH:          48
[    0.039939] ... MAX_LOCKDEP_KEYS:        8191
[    0.044391] ... CLASSHASH_SIZE:          4096
[    0.048833] ... MAX_LOCKDEP_ENTRIES:     32768
[    0.053361] ... MAX_LOCKDEP_CHAINS:      65536
[    0.057898] ... CHAINHASH_SIZE:          32768
[    0.062427]  memory used by lock dependency info: 5167 kB
[    0.067919]  per task-struct memory footprint: 1152 bytes
[    0.073418] Calibrating delay loop (skipped), value calculated
using timer frequency.. 6.00 BogoMIPS (lpj=30000)
[    0.083713] pid_max: default: 32768 minimum: 301
[    0.088621] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.095341] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes)
[    0.103834] CPU: Testing write buffer coherency: ok
[    0.109472] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[    0.115292] Setting up static identity map for 0x100082c0 - 0x10008330
[    0.125591] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[    0.126896] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[    0.127894] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[    0.128054] Brought up 4 CPUs
[    0.148367] SMP: Total of 4 processors activated (24.00 BogoMIPS).
[    0.154644] CPU: All CPU(s) started in SVC mode.
[    0.160883] devtmpfs: initialized
[    0.186252] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
[    0.194779] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[    0.206101] pinctrl core: initialized pinctrl subsystem
[    0.214024] NET: Registered protocol family 16
[    0.221896] DMA: preallocated 256 KiB pool for atomic coherent allocations
[    0.230531] CPU identified as i.MX6Q, silicon rev 1.2
[    0.271546] No ATAGs?
[    0.273715] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[    0.282076] hw-breakpoint: maximum watchpoint size is 4 bytes.
[    0.290359] imx6q-pinctrl 20e0000.iomuxc: initialized IMX pinctrl driver
[    0.349288] mxs-dma 110000.dma-apbh: initialized
[    0.358562] vgaarb: loaded
[    0.362081] SCSI subsystem initialized
[    0.366785] usbcore: registered new interface driver usbfs
[    0.372468] usbcore: registered new interface driver hub
[    0.378053] usbcore: registered new device driver usb
[    0.385024] i2c i2c-0: IMX I2C adapter registered
[    0.389830] i2c i2c-0: can't use DMA
[    0.394338] i2c i2c-1: IMX I2C adapter registered
[    0.399141] i2c i2c-1: can't use DMA
[    0.403649] i2c i2c-2: IMX I2C adapter registered
[    0.408452] i2c i2c-2: can't use DMA
[    0.412235] Linux video capture interface: v2.00
[    0.417154] pps_core: LinuxPPS API ver. 1 registered
[    0.422207] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[    0.431480] PTP clock support registered
[    0.436119] Advanced Linux Sound Architecture Driver Initialized.
[    0.444783] Bluetooth: Core ver 2.20
[    0.448510] NET: Registered protocol family 31
[    0.453041] Bluetooth: HCI device and connection manager initialized
[    0.459546] Bluetooth: HCI socket layer initialized
[    0.464540] Bluetooth: L2CAP socket layer initialized
[    0.469779] Bluetooth: SCO socket layer initialized
[    0.475927] cfg80211: Calling CRDA to update world regulatory domain
[    0.483790] clocksource: Switched to clocksource mxc_timer1
[    0.512511] NET: Registered protocol family 2
[    0.518616] TCP established hash table entries: 8192 (order: 3, 32768 bytes)
[    0.525903] TCP bind hash table entries: 8192 (order: 6, 294912 bytes)
[    0.534677] TCP: Hash tables configured (established 8192 bind 8192)
[    0.541326] UDP hash table entries: 512 (order: 3, 40960 bytes)
[    0.547649] UDP-Lite hash table entries: 512 (order: 3, 40960 bytes)
[    0.554974] NET: Registered protocol family 1
[    0.560325] RPC: Registered named UNIX socket transport module.
[    0.566360] RPC: Registered udp transport module.
[    0.571153] RPC: Registered tcp transport module.
[    0.575962] RPC: Registered tcp NFSv4.1 backchannel transport module.
[    0.583897] hw perfevents: Failed to parse /soc/pmu/interrupt-affinity[0]
[    0.590839] hw perfevents: enabled with armv7_cortex_a9 PMU driver,
7 counters available
[    0.601578] futex hash table entries: 1024 (order: 4, 65536 bytes)
[    0.621860] VFS: Disk quotas dquot_6.6.0
[    0.626237] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[    0.638944] NFS: Registering the id_resolver key type
[    0.644296] Key type id_resolver registered
[    0.648571] Key type id_legacy registered
[    0.652804] jffs2: version 2.2. (NAND) ?? 2001-2006 Red Hat, Inc.
[    0.660409] fuse init (API version 7.23)
[    0.671351] io scheduler noop registered
[    0.675400] io scheduler deadline registered
[    0.679822] io scheduler cfq registered (default)
[    0.685176] imx-weim 21b8000.weim: Driver registered.
[    0.807637] imx6q-pcie 1ffc000.pcie: PCI host bridge to bus 0000:00
[    0.814026] pci_bus 0000:00: root bus resource [io  0x1000-0xffff]
[    0.820299] pci_bus 0000:00: root bus resource [mem 0x01000000-0x01efffff]
[    0.827283] pci_bus 0000:00: root bus resource [bus 00-ff]
[    0.833904] PCI: bus0: Fast back to back transfers disabled
[    0.853714] PCI: bus1: Fast back to back transfers disabled
[    0.859552] pci 0000:00:00.0: BAR 0: assigned [mem 0x01000000-0x010fffff]
[    0.866463] pci 0000:00:00.0: BAR 8: assigned [mem 0x01100000-0x011fffff]
[    0.873346] pci 0000:00:00.0: BAR 6: assigned [mem
0x01200000-0x0120ffff pref]
[    0.880685] pci 0000:01:00.0: BAR 0: assigned [mem
0x01100000-0x01101fff 64bit]
[    0.888158] pci 0000:00:00.0: PCI bridge to [bus 01]
[    0.893217] pci 0000:00:00.0:   bridge window [mem 0x01100000-0x011fffff]
[    0.900681] pcieport 0000:00:00.0: Signaling PME through PCIe PME interrupt
[    0.907760] pci 0000:01:00.0: Signaling PME through PCIe PME interrupt
[    0.916043] backlight supply power not found, using dummy regulator
[    0.925893] imx-sdma 20ec000.sdma: Direct firmware load for
imx/sdma/sdma-imx6q.bin failed with error -2
[    0.935510] imx-sdma 20ec000.sdma: external firmware not found,
using ROM firmware
[    0.941269] imx-sdma 20ec000.sdma: initialized
[    0.943507] pfuze100-regulator 1-0008: Full layer: 1, Metal layer: 1
[    0.944228] pfuze100-regulator 1-0008: FAB: 0, FIN: 0
[    0.944236] pfuze100-regulator 1-0008: pfuze100 found.

[Hangs here]

Running kexec on mx6

[Fabio Estevam]

On Mon, Jun 15, 2015 at 6:40 PM, Fabio Estevam <festevam@gmail.com> wrote:

> [    0.925893] imx-sdma 20ec000.sdma: Direct firmware load for
> imx/sdma/sdma-imx6q.bin failed with error -2
> [    0.935510] imx-sdma 20ec000.sdma: external firmware not found,
> using ROM firmware
> [    0.941269] imx-sdma 20ec000.sdma: initialized
> [    0.943507] pfuze100-regulator 1-0008: Full layer: 1, Metal layer: 1
> [    0.944228] pfuze100-regulator 1-0008: FAB: 0, FIN: 0
> [    0.944236] pfuze100-regulator 1-0008: pfuze100 found.
>
> [Hangs here]

Restarted from a clean build of imx_v6_v7_defconfig and now it can
kexec a linux-next kernel just fine on a mx6qsabresd:
http://pastebin.com/458TY8Z3

However, kexec still hangs the same way on mx6solo:
[  216.673307] kexec: Starting new kernel
[  216.677079] Disabling non-boot CPUs ...
[  216.681002] Bye!
[  216.682852] ********** flushing and disabling L2 cache
Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 4.1.0-rc7-next-20150615-dirty
(fabio at fabio-Latitude-E6410) (gcc version 4.7.3 (Ubuntu/Linaro
4.7.3-12ubu5
[    0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[    0.000000] Machine model: Wandboard i.MX6 Dual Lite Board
[    0.000000] bootconsole [earlycon0] enabled
[    0.000000] cma: Reserved 16 MiB at 0x4f000000
[    0.000000] Memory policy: Data cache writeback

So kexec is working fine on mx6quad, but not on mx6solo.

Running kexec on mx6

[Fabio Estevam]

On Mon, Jun 15, 2015 at 7:43 PM, Fabio Estevam <festevam@gmail.com> wrote:

> So kexec is working fine on mx6quad, but not on mx6solo.

Also tried on mx6dl and kexec works well.

On mx6solo I can only get kexec to work if I rebuild the kernel
without SMP support (CONFIG_SMP=n):
http://pastebin.com/nRVe3NZM

Does anyone have any ideas?

Thanks

Running kexec on mx6

[Russell King - ARM Linux]

On Tue, Jun 16, 2015 at 01:18:34AM -0300, Fabio Estevam wrote:
> On Mon, Jun 15, 2015 at 7:43 PM, Fabio Estevam <festevam@gmail.com> wrote:
> 
> > So kexec is working fine on mx6quad, but not on mx6solo.
> 
> Also tried on mx6dl and kexec works well.
> 
> On mx6solo I can only get kexec to work if I rebuild the kernel
> without SMP support (CONFIG_SMP=n):
> http://pastebin.com/nRVe3NZM

Which kernel - the one which is doing the kexec, or the one being kexec'd
into?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Running kexec on mx6

[Fabio Estevam]

Hi Russell,

On Tue, Jun 16, 2015 at 6:42 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jun 16, 2015 at 01:18:34AM -0300, Fabio Estevam wrote:
>> On Mon, Jun 15, 2015 at 7:43 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>
>> > So kexec is working fine on mx6quad, but not on mx6solo.
>>
>> Also tried on mx6dl and kexec works well.
>>
>> On mx6solo I can only get kexec to work if I rebuild the kernel
>> without SMP support (CONFIG_SMP=n):
>> http://pastebin.com/nRVe3NZM
>
> Which kernel - the one which is doing the kexec, or the one being kexec'd
> into?

In my tests the kernel which is doing the kexec needs to have
CONFIG_SMP=n, so that kexec works on mx6solo.

Thanks

Running kexec on mx6

[Fabio Estevam]

On Tue, Jun 16, 2015 at 8:15 AM, Fabio Estevam <festevam@gmail.com> wrote:

>> Which kernel - the one which is doing the kexec, or the one being kexec'd
>> into?
>
> In my tests the kernel which is doing the kexec needs to have
> CONFIG_SMP=n, so that kexec works on mx6solo.

Other combination that works is to have CONFIG_SMP=y and then pass
'nosmp' in the kernel command line, or also by removing cpu1 from the
imx6dl.dtsi.

Running kexec on mx6

[Russell King - ARM Linux]

On Tue, Jun 16, 2015 at 09:46:46AM -0300, Fabio Estevam wrote:
> On Tue, Jun 16, 2015 at 8:15 AM, Fabio Estevam <festevam@gmail.com> wrote:
> 
> >> Which kernel - the one which is doing the kexec, or the one being kexec'd
> >> into?
> >
> > In my tests the kernel which is doing the kexec needs to have
> > CONFIG_SMP=n, so that kexec works on mx6solo.
> 
> Other combination that works is to have CONFIG_SMP=y and then pass
> 'nosmp' in the kernel command line, or also by removing cpu1 from the
> imx6dl.dtsi.

Well, the good news is I can reproduce it here... the bad news is that
my attempt to debug it so far is causing extra problems - because the
imx6 uart is having its clocks disabled, which kind'a makes it hard to
get debug out... that's wasted half an hour working that out, and
further debug is now going to have to wait until later this evening
or tomorrow.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Running kexec on mx6

[Fabio Estevam]

On Tue, Jun 16, 2015 at 1:13 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> Well, the good news is I can reproduce it here... the bad news is that
> my attempt to debug it so far is causing extra problems - because the
> imx6 uart is having its clocks disabled, which kind'a makes it hard to
> get debug out... that's wasted half an hour working that out, and
> further debug is now going to have to wait until later this evening
> or tomorrow.

Thanks, Russell.

I am having different results from the initial post now.

I noticed that 4.1-rc works fine, but 4.0 does not.

If I apply commit fee3fd4fd2ad136b ("ARM: 8338/1: kexec: Relax SMP
validation to improve DT compatibility") against 4.0 then kexec works
fine here.

Running kexec on mx6

[Russell King - ARM Linux]

On Tue, Jun 16, 2015 at 03:01:49PM -0300, Fabio Estevam wrote:
> On Tue, Jun 16, 2015 at 1:13 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > Well, the good news is I can reproduce it here... the bad news is that
> > my attempt to debug it so far is causing extra problems - because the
> > imx6 uart is having its clocks disabled, which kind'a makes it hard to
> > get debug out... that's wasted half an hour working that out, and
> > further debug is now going to have to wait until later this evening
> > or tomorrow.
> 
> Thanks, Russell.
> 
> I am having different results from the initial post now.
> 
> I noticed that 4.1-rc works fine, but 4.0 does not.
> 
> If I apply commit fee3fd4fd2ad136b ("ARM: 8338/1: kexec: Relax SMP
> validation to improve DT compatibility") against 4.0 then kexec works
> fine here.

If you don't have that commit, kexec should fail gracefully if it thinks
it can't cope with the existing system config - it shouldn't get to the
point where it takes the existing kernel down.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

Running kexec on mx6

[Fabio Estevam]

On Tue, Jun 16, 2015 at 4:58 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:

> If you don't have that commit, kexec should fail gracefully if it thinks
> it can't cope with the existing system config - it shouldn't get to the
> point where it takes the existing kernel down.

That's correct. On 4.0.5:

root at wandboard-solo:~# kexec -d -l /tmp/zImage --dtb
/tmp/imx6dl-wandboard.dtb --command-line="console=ttymxc0,115200
earlyprintk root=/dev/mmcblk0p2 rootwait rw"
my_load:667: do
kernel: 0x75dd1008 kernel_size: 0x5664c8
kexec_load: entry = 0x10008000 flags = 0x280000
nr_segments = 2
segment[0].buf   = 0x75dd1008
segment[0].bufsz = 0x5664c8
segment[0].mem   = 0x10008000
segment[0].memsz = 0x567000
segment[1].buf   = 0x10ab008
segment[1].bufsz = 0x6ba7
segment[1].mem   = 0x1159b000
segment[1].memsz = 0x7000
kexec_load failed: Invalid argument
entry       = 0x10008000 flags = 0x280000
nr_segments = 2
segment[0].buf   = 0x75dd1008
segment[0].bufsz = 0x5664c8
segment[0].mem   = 0x10008000
segment[0].memsz = 0x567000
segment[1].buf   = 0x10ab008
segment[1].bufsz = 0x6ba7
segment[1].mem   = 0x1159b000
segment[1].memsz = 0x7000

Applying fee3fd4fd2ad136b into 4.0.5 then kexec works fine.

Should we send fee3fd4fd2ad136b to stable?

Thanks

Running kexec on mx6

[Russell King - ARM Linux]

On Tue, Jun 16, 2015 at 05:13:37PM -0300, Fabio Estevam wrote:
> On Tue, Jun 16, 2015 at 4:58 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> 
> > If you don't have that commit, kexec should fail gracefully if it thinks
> > it can't cope with the existing system config - it shouldn't get to the
> > point where it takes the existing kernel down.
> 
> That's correct. On 4.0.5:
> 
> root at wandboard-solo:~# kexec -d -l /tmp/zImage --dtb
> /tmp/imx6dl-wandboard.dtb --command-line="console=ttymxc0,115200
> earlyprintk root=/dev/mmcblk0p2 rootwait rw"
> my_load:667: do
> kernel: 0x75dd1008 kernel_size: 0x5664c8
> kexec_load: entry = 0x10008000 flags = 0x280000
> nr_segments = 2
> segment[0].buf   = 0x75dd1008
> segment[0].bufsz = 0x5664c8
> segment[0].mem   = 0x10008000
> segment[0].memsz = 0x567000
> segment[1].buf   = 0x10ab008
> segment[1].bufsz = 0x6ba7
> segment[1].mem   = 0x1159b000
> segment[1].memsz = 0x7000
> kexec_load failed: Invalid argument
> entry       = 0x10008000 flags = 0x280000
> nr_segments = 2
> segment[0].buf   = 0x75dd1008
> segment[0].bufsz = 0x5664c8
> segment[0].mem   = 0x10008000
> segment[0].memsz = 0x567000
> segment[1].buf   = 0x10ab008
> segment[1].bufsz = 0x6ba7
> segment[1].mem   = 0x1159b000
> segment[1].memsz = 0x7000
> 
> Applying fee3fd4fd2ad136b into 4.0.5 then kexec works fine.
> 
> Should we send fee3fd4fd2ad136b to stable?

Do we have "real" users affected by this?  It seems there's more issues
that need resolving for it to work on iMX6, and so I don't think this
is a regression.

1) If you build just for imx6, then you get the decompressor talking to
   the serial port, which has been left disabled by the previous kernel
   (when userspace closes, it disables the TXEN bit in UCR2 and UARTEN
   in UCR1.)  This causes an imprecise abort to be raised in the
   decompressor when it tries to talk to the console.

   Changing the 

2) The IPU probe code is _definitely_ buggy - it claims its interrupt
   before it's finished setting stuff up, resulting in a nice oops.
   That's because we receive an interrupt immediately when:

        irq_set_chained_handler(ipu->irq_sync, ipu_irq_handler);

   has been called, and it tries to grab the pointer to the IPU, but
   it hasn't been set yet...

        irq_set_handler_data(ipu->irq_sync, ipu);

   I've had a quick discussion with tglx this evening about it, and
   we think it'd make sense to have a combo function -

	irq_set_chained_handler_and_data(ipu->irq_sync, ipu_irq_handler, ipu);

   which sets stuff up without this possibly being out of order.  With
   that resolved...

3) Something else causes boot to fail at:

621f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 294, base_baud = 5000000) is a IMX
[drm] Initialized drm 1.1.0 20060810
imx-drm display-subsystem: parent device of /soc/aips-bus at 02000000/ldb at 020e0008/lvds-channel at 1 is not available
imx-drm display-subsystem: parent device of /soc/aips-bus at 02000000/ldb at 020e0008/lvds-channel at 1 is not available

   It would have given the next kernel message as:

[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
imx-drm display-subsystem: bound imx-ipuv3-crtc.0 (ops ipu_crtc_ops)
...

Not sure what's going on there yet...

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.