Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66
Successful boards:
apc vt8500_v6_v7_defconfig : passed 1:15.73 arndale exynos_defconfig : passed 1:11.62 bbb omap2plus_defconfig : passed 1:37.09 beaver tegra_defconfig : passed 0:59.84 beaver multi_v7_defconfig : passed 0:50.22 capri bcm_defconfig : passed 0:46.40 capri multi_v7_defconfig : passed 0:44.20 cubie sunxi_defconfig : passed 0:54.52 dalmore tegra_defconfig : passed 1:19.45 dalmore multi_v7_defconfig : passed 1:22.50 dalmore multi_lpae_defconfig : passed 1:15.72 hummingboard imx_v6_v7_defconfig : passed 1:24.29 omap5uevm omap2plus_defconfig : warnings 1:08.06 omap5uevm multi_v7_defconfig : warnings 1:47.30 omap5uevm multi_lpae_defconfig : warnings 1:40.38 panda omap2plus_defconfig : warnings 1:13.92 sama5 sama5_defconfig : passed 1:50.89 seaboard tegra_defconfig : passed 1:05.31 seaboard multi_v7_defconfig : passed 1:05.55 snowball u8500_defconfig : passed 2:08.75 trimslice tegra_defconfig : passed 1:00.71 trimslice multi_v7_defconfig : passed 1:01.60 wandboard imx_v6_v7_defconfig : passed 0:57.05
Offline boards:
bbb multi_v7_defconfig : OFFLINE 0:50.74
Board legend is available at http://arm-soc.lixom.net/boards.html
Last entries of failed logs below:
========================================================================
Board cubie-multi_v7_defconfig failure log: -------------------------------------------------
tftp 0x40008000 next/next-20140407/multi_v7_defconfig/zImagenode: cubie status: on
Using emac device TFTP from server 172.16.1.3; our IP address is 172.16.1.165 Filename 'next/next-20140407/multi_v7_defconfig/zImage'. Load address: 0x40008000 Loading: *################################################################# ################################################################# ################################################################# ################################################################# ######################################################## 2.8 MiB/s done Bytes transferred = 4632184 (46ae78 hex) sun4i#setenv serverip 172.16.1.3 setenv serverip 172.16.1.3 sun4i#tftp 0x42000000 next/next-20140407/multi_v7_defconfig/dtbs/sun4i-a10-cubieboard.dtb tftp 0x42000000 next/next-20140407/multi_v7_defconfig/dtbs/sun4i-a10-cubieboard.dtb Using emac device TFTP from server 172.16.1.3; our IP address is 172.16.1.165 Filename 'next/next-20140407/multi_v7_defconfig/dtbs/sun4i-a10-cubieboard.dtb'. Load address: 0x42000000 Loading: *## 2.4 MiB/s done Bytes transferred = 15184 (3b50 hex) sun4i#printenv bootargs printenv bootargs bootargs=console=ttyS0,115200n8 root=/dev/nfs rootwait rw nfsroot=172.16.1.7:/work/nfsroot/cubie ip=dhcp sun4i#bootz 0x40008000 - 0x42000000 bootz 0x40008000 - 0x42000000 Kernel image @ 0x40008000 [ 0x000000 - 0x46ae78 ] ## Flattened Device Tree blob at 42000000 Booting using the fdt blob at 0x42000000 Loading Device Tree to 40ff9000, end 40fffb4f ... OK
Starting kernel ...
~$off # PYBOOT: Exception: timeout
========================================================================
Board cubie2-multi_lpae_defconfig failure log: -------------------------------------------------
sun7i# tftp 0x40008000 next/next-20140407/multi_lpae_defconfig/zImage tftp 0x40008000 next/next-20140407/multi_lpae_defconfig/zImage Using emac device TFTP from server 172.16.1.3; our IP address is 172.16.1.101 Filename 'next/next-20140407/multi_lpae_defconfig/zImage'. Load address: 0x40008000 Loading: *################################################################# ################################################################# ################################################################# ################################################################# ######################################################### 3.9 MiB/s done Bytes transferred = 4651920 (46fb90 hex) sun7i# setenv serverip 172.16.1.3 setenv serverip 172.16.1.3 sun7i# tftp 0x42000000 next/next-20140407/multi_lpae_defconfig/dtbs/sun7i-a20-cubieboard2.dtb tftp 0x42000000 next/next-20140407/multi_lpae_defconfig/dtbs/sun7i-a20-cubieboard2.dtb Using emac device TFTP from server 172.16.1.3; our IP address is 172.16.1.101 Filename 'next/next-20140407/multi_lpae_defconfig/dtbs/sun7i-a20-cubieboard2.dtb'. Load address: 0x42000000 Loading: *## 747.1 KiB/s done Bytes transferred = 18361 (47b9 hex) sun7i# printenv bootargs printenv bootargs bootargs=console=ttyS0,115200n8 root=/dev/nfs rootwait rw nfsroot=172.16.1.7:/work/nfsroot/cubie2 ip=dhcp sun7i# bootz 0x40008000 - 0x42000000 bootz 0x40008000 - 0x42000000 Kernel image @ 0x40008000 [ 0x000000 - 0x46fb90 ] ## Flattened Device Tree blob at 42000000 Booting using the fdt blob at 0x42000000 Loading Device Tree to 40ff8000, end 40fff7b8 ... OK
Starting kernel ...
~$off # PYBOOT: Exception: timeout
========================================================================
Board cubie2-multi_v7_defconfig failure log: -------------------------------------------------
tftp 0x40008000 next/nexnode: cubie2 status: on t-20140407/multi_v7_defconfig/zImage Using emac device TFTP from server 172.16.1.3; our IP address is 172.16.1.101 Filename 'next/next-20140407/multi_v7_defconfig/zImage'. Load address: 0x40008000 Loading: *################################################################# ################################################################# ################################################################# ################################################################# ######################################################## 4 MiB/s done Bytes transferred = 4632184 (46ae78 hex) sun7i# setenv serverip 172.16.1.3 setenv serverip 172.16.1.3 sun7i# tftp 0x42000000 next/next-20140407/multi_v7_defconfig/dtbs/sun7i-a20-cubieboard2.dtb tftp 0x42000000 next/next-20140407/multi_v7_defconfig/dtbs/sun7i-a20-cubieboard2.dtb Using emac device TFTP from server 172.16.1.3; our IP address is 172.16.1.101 Filename 'next/next-20140407/multi_v7_defconfig/dtbs/sun7i-a20-cubieboard2.dtb'. Load address: 0x42000000 Loading: *## 853.5 KiB/s done Bytes transferred = 18361 (47b9 hex) sun7i# printenv bootargs printenv bootargs bootargs=console=ttyS0,115200n8 root=/dev/nfs rootwait rw nfsroot=172.16.1.7:/work/nfsroot/cubie2 ip=dhcp sun7i#bootz 0x40008000 - 0x42000000 bootz 0x40008000 - 0x42000000 Kernel image @ 0x40008000 [ 0x000000 - 0x46ae78 ] ## Flattened Device Tree blob at 42000000 Booting using the fdt blob at 0x42000000 Loading Device Tree to 40ff8000, end 40fff7b8 ... OK
Starting kernel ...
~$off # PYBOOT: Exception: timeout
========================================================================
Board cubie2-sunxi_defconfig failure log: -------------------------------------------------
[ 0.017893] platform ahci-5v.2: Driver reg-fixed-voltage requests probe deferral [ 0.017916] reg-fixed-voltage usb1-vbus.3: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb1_vbus_pin@0, deferring probe [ 0.017930] platform usb1-vbus.3: Driver reg-fixed-voltage requests probe deferral [ 0.017951] reg-fixed-voltage usb2-vbus.4: could not find pctldev for node /soc@01c00000/pinctrl@01c20800/usb2_vbus_pin@0, deferring probe [ 0.017964] platform usb2-vbus.4: Driver reg-fixed-voltage requests probe deferral [ 0.018911] Switched to clocksource arch_sys_counter [ 0.026039] NET: Registered protocol family 2 [ 0.026508] TCP established hash table entries: 8192 (order: 3, 32768 bytes) [ 0.026595] TCP bind hash table entries: 8192 (order: 4, 65536 bytes) [ 0.026719] TCP: Hash tables configured (established 8192 bind 8192) [ 0.026803] TCP: reno registered [ 0.026820] UDP hash table entries: 512 (order: 2, 16384 bytes) [ 0.026874] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes) [ 0.027072] NET: Registered protocol family 1 [ 0.027464] RPC: Registered named UNIX socket transport module. [ 0.027477] RPC: Registered udp transport module. [ 0.027483] RPC: Registered tcp transport module. [ 0.027489] RPC: Registered tcp NFSv4.1 backchannel transport module. [ 0.028449] futex hash table entries: 512 (order: 3, 32768 bytes) [ 0.028990] bounce pool size: 64 pages [ 0.036844] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 0.036865] io scheduler noop registered [ 0.036872] io scheduler deadline registered [ 0.037053] io scheduler cfq registered (default) [ 0.038699] sunxi-pinctrl 1c20800.pinctrl: initialized sunXi PIO driver [ 0.080575] Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled [ 0.083014] console [ttyS0] disabled [ 0.103213] 1c28000.serial: ttyS0 at MMIO 0x1c28000 (irq = 33, base_baud = 1500000) is a U6_16550A [ 0.618202] console [ttyS0] enabled [ 0.622912] mousedev: PS/2 mouse device common for all mice [ 0.628735] i2c /dev entries driver [ 0.633604] sunxi-wdt 1c20c90.watchdog: Watchdog enabled (timeout=16 sec, nowayout=0) [ 0.642594] TCP: cubic registered [ 0.645914] NET: Registered protocol family 17 [ 0.650474] Registering SWP/SWPB emulation handler [ 0.656183] ahci-5v: 5000 mV [ 0.659484] usb1-vbus: 5000 mV [ 0.662840] usb2-vbus: 5000 mV ~$off # PYBOOT: Exception: timeout
========================================================================
Board hummingboard-multi_v7_defconfig failure log: -------------------------------------------------
C1 U-Boot > tftp 0x10800000 next/next-20140407/multi_v7_defconfig/zImage tftp 0x10800000 next/next-20140407/multi_v7_defconfig/zImage Using FEC device TFTP from server 172.16.1.3; our IP address is 172.16.1.103 Filename 'next/next-20140407/multi_v7_defconfig/zImage'. Load address: 0x10800000 Loading: *################################################################# ################################################################# ################################################################# ################################################################# ######################################################## 2 MiB/s done Bytes transferred = 4632184 (46ae78 hex) C1 U-Boot > setenv serverip 172.16.1.3 setenv serverip 172.16.1.3 C1 U-Boot >tftp 0x11000000 next/next-20140407/multi_v7_defconfig/dtbs/imx6dl-hummingboard.dtb tftp 0x11000000 next/next-20140407/multi_v7_defconfig/dtbs/imx6dl-hummingboard.dtb Using FEC device TFTP from server 172.16.1.3; our IP address is 172.16.1.103 Filename 'next/next-20140407/multi_v7_defconfig/dtbs/imx6dl-hummingboard.dtb'. Load address: 0x11000000 Loading: *## 618.2 KiB/s done Bytes transferred = 25956 (6564 hex) C1 U-Boot > printenv bootargs printenv bootargs bootargs=console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait debug earlyprintk C1 U-Boot > bootz 0x10800000 - 0x11000000 bootz 0x10800000 - 0x11000000 Kernel image @ 0x10800000 [ 0x000000 - 0x46ae78 ] ## Flattened Device Tree blob at 11000000 Booting using the fdt blob at 0x11000000 Using Device Tree in place at 11000000, end 11009563
Starting kernel ...
~$off # PYBOOT: Exception: timeout
========================================================================
Board panda-multi_v7_defconfig failure log: -------------------------------------------------
[ 1.617431] omap_hsmmc 4809c000.mmc: unable to get vmmc regulator -517 [ 1.624328] platform 4809c000.mmc: Driver omap_hsmmc requests probe deferral [ 1.632019] omap_hsmmc 480d5000.mmc: unable to get vmmc regulator -517 [ 1.638916] platform 480d5000.mmc: Driver omap_hsmmc requests probe deferral [ 1.646820] sdhci-pltfm: SDHCI platform and OF driver helper [ 1.653686] usbcore: registered new interface driver usbhid [ 1.659576] usbhid: USB HID core driver [ 1.667510] TCP: cubic registered [ 1.671020] NET: Registered protocol family 17 [ 1.675872] Key type dns_resolver registered [ 1.680816] Power Management for TI OMAP4+ devices. [ 1.685974] Power Management for TI OMAP4. [ 1.690277] OMAP4 PM: u-boot >= v2012.07 is required for full PM support [ 1.697387] Registering SWP/SWPB emulation handler [ 1.703704] vwl1271: 1800 mV [ 1.707977] Skipping twl internal clock init and using bootloader value (unknown osc rate) [ 1.717712] twl 0-0048: PIH (irq 39) nested IRQs [ 1.723388] twl_rtc rtc.15: Power up reset detected. [ 1.729309] twl_rtc rtc.15: Enabling TWL-RTC [ 1.736236] twl_rtc rtc.15: rtc core: registered rtc.15 as rtc0 [ 1.743164] VAUX1_6030: 1000 <--> 3000 mV at 2800 mV [ 1.749267] VAUX2_6030: 1200 <--> 2800 mV at 1800 mV [ 1.755371] VAUX3_6030: 1000 <--> 3000 mV at 1200 mV [ 1.761444] VMMC: 1200 <--> 3000 mV at 3000 mV [ 1.766998] VPP: 1800 <--> 2500 mV at 1900 mV [ 1.772430] VUSIM: 1200 <--> 2900 mV at 1800 mV [ 1.777435] VDAC: 1800 mV [ 1.781188] VANA: 2100 mV [ 1.784729] VCXIO: 1800 mV [ 1.784729] VUSB: 3300 mV [ 1.791656] V1V8: 1800 mV [ 1.795196] V2V1: 2100 mV [ 1.899322] usb 1-1: new high-speed USB device number 2 using ehci-omap [ 2.069824] hub 1-1:1.0: USB hub found [ 2.074096] hub 1-1:1.0: 5 ports detected [ 2.643463] usb 1-1.1: new high-speed USB device number 3 using ehci-omap [ 2.870208] smsc95xx v1.0.4 [ 8.171295] smsc95xx 1-1.1:1.0 eth0: register 'smsc95xx' at usb-4a064c00.ehci-1.1, smsc95xx USB 2.0 Ethernet, 4e:7b:f8:42:6d:fe ~$off # PYBOOT: Exception: timeout
========================================================================
Board snow-exynos_defconfig failure log: -------------------------------------------------
OK Loading Device Tree to 5fff0000, end 5ffffa3a ... OK
Starting kernel ...
Timer summary in microseconds: Mark Elapsed Stage 0 0 reset 100,000 100,000 spl_start 1,694,366 1,594,366 board_init_f 1,744,328 49,962 board_init_r 1,746,536 2,208 board_init 1,877,151 130,615 board_init_done 1,959,472 82,321 id=64 1,964,904 5,432 main_loop 3,911,695 1,946,791 usb_start 8,675,493 4,763,798 tftp_start 8,675,510 17 id=80 8,675,512 2 eth_start 41,141,099 32,465,587 id=81 41,141,101 2 tftp_done 87,676,555 46,535,454 id=82 87,676,560 5 id=84 95,693,292 8,016,732 bootm_start 95,693,300 8 id=1 95,773,295 79,995 id=2 95,773,314 19 id=3 96,557,757 784,443 id=4 96,557,758 1 id=5 96,557,770 12 id=6 97,284,651 726,881 id=7 97,284,655 4 id=8 97,284,668 13 id=15 97,855,250 570,582 start_kernel
Accumulated time: 153,793 lcd Stashed 27 records ~$off # PYBOOT: Exception: timeout
========================================================================
Board snowball-multi_v7_defconfig failure log: -------------------------------------------------
BOOTP broadcast 1 *** Unhandled DHCP Option in OFFER/ACK: 28 *** Unhandled DHCP Option in OFFER/ACK: 28 DHCP client bound to address 172.16.1.149 U8500 $ setenv serverip 172.16.1.3 setenv serverip 172.16.1.3 U8500 $ tftp 0x00100000 tmp/snowball-aR90Io/tmpwzE9_W-uImage tftp 0x00100000 tmp/snowball-aR90Io/tmpwzE9_W-uImage smc911x: detected LAN9221 controller smc911x: phy initialized smc911x: MAC 08:00:08:1e:0f:44 Using smc911x-0 device TFTP from server 172.16.1.3; our IP address is 172.16.1.149 Filename 'tmp/snowball-aR90Io/tmpwzE9_W-uImage'. Load address: 0x100000 Loading: *################################################################# ################################################################# ################################################################# ################################################################# ########################################################### done Bytes transferred = 4673497 (474fd9 hex) U8500 $ printenv bootargs printenv bootargs bootargs=console=ttyAMA2,115200 root=/dev/mmcblk0p4 rootwait rw debug earlyprintk U8500 $ bootm 0x00100000 bootm 0x00100000 ## Booting kernel from Legacy Image at 00100000 ... Image Name: Linux Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 4673433 Bytes = 4.5 MB Load Address: 00008000 Entry Point: 00008000 Loading Kernel Image ... OK OK
Starting kernel ...
~$off # PYBOOT: Exception: timeout
========================================================================
Board wandboard-multi_v7_defconfig failure log: -------------------------------------------------
=> tftp 0x10800000 next/next-20140407/multi_v7_defconfig/zImage tftp 0x10800000 next/next-20140407/multi_v7_defconfig/zImage Using FEC device TFTP from server 172.16.1.3; our IP address is 172.16.1.102 Filename 'next/next-20140407/multi_v7_defconfig/zImage'. Load address: 0x10800000 Loading: *################################################################# ################################################################# ################################################################# ################################################################# ######################################################## 6.1 MiB/s done Bytes transferred = 4632184 (46ae78 hex) => setenv serverip 172.16.1.3 setenv serverip 172.16.1.3 => tftp 0x11000000 next/next-20140407/multi_v7_defconfig/dtbs/imx6q-wandboard.dtb tftp 0x11000000 next/next-20140407/multi_v7_defconfig/dtbs/imx6q-wandboard.dtb Using FEC device TFTP from server 172.16.1.3; our IP address is 172.16.1.102 Filename 'next/next-20140407/multi_v7_defconfig/dtbs/imx6q-wandboard.dtb'. Load address: 0x11000000 Loading: *### 3.5 MiB/s done Bytes transferred = 29394 (72d2 hex) => printenv bootargs printenv bootargs bootargs=console=ttymxc0,115200 root=/dev/mmcblk0p2 rootwait debug => bootz 0x10800000 - 0x11000000 bootz 0x10800000 - 0x11000000 Kernel image @ 0x10800000 [ 0x000000 - 0x46ae78 ] ## Flattened Device Tree blob at 11000000 Booting using the fdt blob at 0x11000000 Using Device Tree in place at 11000000, end 1100a2d1
Starting kernel ...
~$off # PYBOOT: Exception: timeout
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66
So do we have any clues what's causing these to fail?
On Mon, Apr 7, 2014 at 6:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
For the mx6 boards the boot failure only happens with multi_v7_defconfig, not with imx_v6_v7_defconfig.
I tried to boot multi_v7_defconfig with earlyprintk support and I noticed that it forces the user to enter the physical and virtual addresses for the UART port (The default is incorrect for i.mx):
[*] Kernel low-level debugging functions (read help!) Kernel low-level debugging port (i.MX6Q/DL Debug UART) (1) i.MX Debug UART Port Selection (NEW) (0xe0000000) Physical base address of debug UART (0xfd000000) Virtual base address of debug UART
Then I unselected all other platforms, keeping only i.mx, then the physical/virtual adresses selection menu disappeared and the kernel booted fine.
Other experiment I tried was to boot multi_v7_defconfig with the following change:
--- arch/arm/Kconfig.debug | 118 ------------------------------------------------- 1 file changed, 118 deletions(-)
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 7289853..021fbc8 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -1009,124 +1009,6 @@ config DEBUG_UART_8250 ARCH_IOP33X || ARCH_IXP4XX || ARCH_KIRKWOOD || \ ARCH_LPC32XX || ARCH_MV78XX0 || ARCH_ORION5X || ARCH_RPC
-config DEBUG_UART_PHYS - hex "Physical base address of debug UART" - default 0x01c20000 if DEBUG_DAVINCI_DMx_UART0 - default 0x01c28000 if DEBUG_SUNXI_UART0 - default 0x01c28400 if DEBUG_SUNXI_UART1 - default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1 - default 0x01d0d000 if DEBUG_DAVINCI_DA8XX_UART2 - default 0x02530c00 if DEBUG_KEYSTONE_UART0 - default 0x02531000 if DEBUG_KEYSTONE_UART1 - default 0x03010fe0 if ARCH_RPC - default 0x10009000 if DEBUG_REALVIEW_STD_PORT || DEBUG_CNS3XXX || \ - DEBUG_VEXPRESS_UART0_CA9 - default 0x1010c000 if DEBUG_REALVIEW_PB1176_PORT - default 0x10124000 if DEBUG_RK3X_UART0 - default 0x10126000 if DEBUG_RK3X_UART1 - default 0x101f1000 if ARCH_VERSATILE - default 0x101fb000 if DEBUG_NOMADIK_UART - default 0x16000000 if ARCH_INTEGRATOR - default 0x18000300 if DEBUG_BCM_5301X - default 0x1c090000 if DEBUG_VEXPRESS_UART0_RS1 - default 0x20060000 if DEBUG_RK29_UART0 - default 0x20064000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2 - default 0x20068000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3 - default 0x20201000 if DEBUG_BCM2835 - default 0x3e000000 if DEBUG_BCM_KONA_UART - default 0x4000e400 if DEBUG_LL_UART_EFM32 - default 0x40090000 if ARCH_LPC32XX - default 0x40100000 if DEBUG_PXA_UART1 - default 0x42000000 if ARCH_GEMINI - default 0x7c0003f8 if FOOTBRIDGE - default 0x80230000 if DEBUG_PICOXCELL_UART - default 0x80070000 if DEBUG_IMX23_UART - default 0x80074000 if DEBUG_IMX28_UART - default 0x808c0000 if ARCH_EP93XX - default 0x90020000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART - default 0xb0090000 if DEBUG_VEXPRESS_UART0_CRX - default 0xc0013000 if DEBUG_U300_UART - default 0xc8000000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN - default 0xc8000003 if ARCH_IXP4XX && CPU_BIG_ENDIAN - default 0xd0000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX - default 0xd0012000 if DEBUG_MVEBU_UART - default 0xd4017000 if DEBUG_MMP_UART2 - default 0xd4018000 if DEBUG_MMP_UART3 - default 0xe0000000 if ARCH_SPEAR13XX - default 0xf0000be0 if ARCH_EBSA110 - default 0xf1012000 if DEBUG_MVEBU_UART_ALTERNATE - default 0xf1012000 if ARCH_DOVE || ARCH_KIRKWOOD || ARCH_MV78XX0 || \ - ARCH_ORION5X - default 0xf7fc9000 if DEBUG_BERLIN_UART - default 0xf8b00000 if DEBUG_HI3716_UART - default 0xfcb00000 if DEBUG_HI3620_UART - default 0xfe800000 if ARCH_IOP32X - default 0xffc02000 if DEBUG_SOCFPGA_UART - default 0xffd82340 if ARCH_IOP13XX - default 0xfff36000 if DEBUG_HIGHBANK_UART - default 0xfffff700 if ARCH_IOP33X - depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ - DEBUG_LL_UART_EFM32 || \ - DEBUG_UART_8250 || DEBUG_UART_PL01X - -config DEBUG_UART_VIRT - hex "Virtual base address of debug UART" - default 0xe0010fe0 if ARCH_RPC - default 0xf0000be0 if ARCH_EBSA110 - default 0xf0009000 if DEBUG_CNS3XXX - default 0xf01fb000 if DEBUG_NOMADIK_UART - default 0xf0201000 if DEBUG_BCM2835 - default 0xf1000300 if DEBUG_BCM_5301X - default 0xf11f1000 if ARCH_VERSATILE - default 0xf1600000 if ARCH_INTEGRATOR - default 0xf1c28000 if DEBUG_SUNXI_UART0 - default 0xf1c28400 if DEBUG_SUNXI_UART1 - default 0xf2100000 if DEBUG_PXA_UART1 - default 0xf4090000 if ARCH_LPC32XX - default 0xf4200000 if ARCH_GEMINI - default 0xf7fc9000 if DEBUG_BERLIN_UART - default 0xf8009000 if DEBUG_VEXPRESS_UART0_CA9 - default 0xf8090000 if DEBUG_VEXPRESS_UART0_RS1 - default 0xfb009000 if DEBUG_REALVIEW_STD_PORT - default 0xfb10c000 if DEBUG_REALVIEW_PB1176_PORT - default 0xfd000000 if ARCH_SPEAR3XX || ARCH_SPEAR6XX - default 0xfd000000 if ARCH_SPEAR13XX - default 0xfd012000 if ARCH_MV78XX0 - default 0xfde12000 if ARCH_DOVE - default 0xfe012000 if ARCH_ORION5X - default 0xfe017000 if DEBUG_MMP_UART2 - default 0xfe018000 if DEBUG_MMP_UART3 - default 0xfe100000 if DEBUG_IMX23_UART || DEBUG_IMX28_UART - default 0xfe230000 if DEBUG_PICOXCELL_UART - default 0xfe300000 if DEBUG_BCM_KONA_UART - default 0xfe800000 if ARCH_IOP32X - default 0xfeb00000 if DEBUG_HI3620_UART || DEBUG_HI3716_UART - default 0xfeb24000 if DEBUG_RK3X_UART0 - default 0xfeb26000 if DEBUG_RK3X_UART1 - default 0xfeb30c00 if DEBUG_KEYSTONE_UART0 - default 0xfeb31000 if DEBUG_KEYSTONE_UART1 - default 0xfec12000 if DEBUG_MVEBU_UART || DEBUG_MVEBU_UART_ALTERNATE - default 0xfed60000 if DEBUG_RK29_UART0 - default 0xfed64000 if DEBUG_RK29_UART1 || DEBUG_RK3X_UART2 - default 0xfed68000 if DEBUG_RK29_UART2 || DEBUG_RK3X_UART3 - default 0xfec02000 if DEBUG_SOCFPGA_UART - default 0xfec20000 if DEBUG_DAVINCI_DMx_UART0 - default 0xfed0c000 if DEBUG_DAVINCI_DA8XX_UART1 - default 0xfed0d000 if DEBUG_DAVINCI_DA8XX_UART2 - default 0xfed12000 if ARCH_KIRKWOOD - default 0xfedc0000 if ARCH_EP93XX - default 0xfee003f8 if FOOTBRIDGE - default 0xfee20000 if DEBUG_NSPIRE_CLASSIC_UART || DEBUG_NSPIRE_CX_UART - default 0xfef36000 if DEBUG_HIGHBANK_UART - default 0xfee82340 if ARCH_IOP13XX - default 0xfef00000 if ARCH_IXP4XX && !CPU_BIG_ENDIAN - default 0xfef00003 if ARCH_IXP4XX && CPU_BIG_ENDIAN - default 0xfefff700 if ARCH_IOP33X - default 0xff003000 if DEBUG_U300_UART - default DEBUG_UART_PHYS if !MMU - depends on DEBUG_LL_UART_8250 || DEBUG_LL_UART_PL01X || \ - DEBUG_UART_8250 || DEBUG_UART_PL01X - config DEBUG_UART_8250_SHIFT int "Register offset shift for the 8250 debug UART" depends on DEBUG_LL_UART_8250 || DEBUG_UART_8250
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
I haven't paid close attention to my board status in the last couple of weeks. I hope to clear up any remaining failures this week, so we can get them sorted before -rc1.
-Olof
On Mon, Apr 07, 2014 at 07:15:34AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
A good question at this point is what change introduced this regression, and why did that change go through a different tree to that which is being asked to carry the fixes?
On April 7, 2014 7:25:20 AM PDT, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:15:34AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED1:05.77
cubie2 sunxi_defconfig : FAILED1:21.41
cubie2 multi_v7_defconfig : FAILED1:09.94
cubie2 multi_lpae_defconfig : FAILED0:59.68
hummingboard multi_v7_defconfig : FAILED1:04.69
panda multi_v7_defconfig : FAILED1:36.35
snow exynos_defconfig : FAILED2:24.53
snowball multi_v7_defconfig : FAILED1:07.90
wandboard multi_v7_defconfig : FAILED1:05.66
So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since
we've
already requested the patch to be sent to the patch tracker...
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
A good question at this point is what change introduced this regression, and why did that change go through a different tree to that which is being asked to carry the fixes?
Good point. I'll apply the fix to arm-soc this morning.
-Olof
On Mon, Apr 07, 2014 at 07:30:50AM -0700, Olof Johansson wrote:
On April 7, 2014 7:25:20 AM PDT, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
A good question at this point is what change introduced this regression, and why did that change go through a different tree to that which is being asked to carry the fixes?
Good point. I'll apply the fix to arm-soc this morning.
Not quite - the two changes "Add cpu_is_pj4 to distinguish PJ4 because it has some differences with V7" and "Check cpu id in pj4_cp0_init." are both clearly core code changes, so should be applied via my tree.
Hence my question about what introduced this regression.
You know... Arnd moaned at me over the weekend having changes to arch/arm/boot/dts in my tree, saying that they should go via arm-soc, but it seems that it's perfectly fine for arm-soc to take core ARM code changes on a whim.
I don't care which stops: either arm-soc stops taking changes which should come via my tree, or arm-soc maintainers accept that from time to time I will be carrying changes to arch/arm/boot/dts which may conflict with changes in arm-soc.
What is unacceptable is both complaining and also take core ARM changes.
On Mon, Apr 7, 2014 at 7:40 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:30:50AM -0700, Olof Johansson wrote:
On April 7, 2014 7:25:20 AM PDT, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
A good question at this point is what change introduced this regression, and why did that change go through a different tree to that which is being asked to carry the fixes?
Good point. I'll apply the fix to arm-soc this morning.
Not quite - the two changes "Add cpu_is_pj4 to distinguish PJ4 because it has some differences with V7" and "Check cpu id in pj4_cp0_init." are both clearly core code changes, so should be applied via my tree.
Hence my question about what introduced this regression.
You know... Arnd moaned at me over the weekend having changes to arch/arm/boot/dts in my tree, saying that they should go via arm-soc, but it seems that it's perfectly fine for arm-soc to take core ARM code changes on a whim.
I don't care which stops: either arm-soc stops taking changes which should come via my tree, or arm-soc maintainers accept that from time to time I will be carrying changes to arch/arm/boot/dts which may conflict with changes in arm-soc.
What is unacceptable is both complaining and also take core ARM changes.
Awesome!
I'm strongly in favor of code going in through the appropriate tree since it makes life easier for maintainers, and I am looking forward to you starting sending non-core patches over to us.
I didn't know we had a resolution to that problem, and I'm glad to see that we do. This made my morning!
Thanks,
-Olof
On Mon, Apr 07, 2014 at 09:31:39AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 7:40 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:30:50AM -0700, Olof Johansson wrote:
On April 7, 2014 7:25:20 AM PDT, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
A good question at this point is what change introduced this regression, and why did that change go through a different tree to that which is being asked to carry the fixes?
Good point. I'll apply the fix to arm-soc this morning.
Not quite - the two changes "Add cpu_is_pj4 to distinguish PJ4 because it has some differences with V7" and "Check cpu id in pj4_cp0_init." are both clearly core code changes, so should be applied via my tree.
Hence my question about what introduced this regression.
You know... Arnd moaned at me over the weekend having changes to arch/arm/boot/dts in my tree, saying that they should go via arm-soc, but it seems that it's perfectly fine for arm-soc to take core ARM code changes on a whim.
I don't care which stops: either arm-soc stops taking changes which should come via my tree, or arm-soc maintainers accept that from time to time I will be carrying changes to arch/arm/boot/dts which may conflict with changes in arm-soc.
What is unacceptable is both complaining and also take core ARM changes.
Awesome!
I'm strongly in favor of code going in through the appropriate tree since it makes life easier for maintainers, and I am looking forward to you starting sending non-core patches over to us.
I didn't know we had a resolution to that problem, and I'm glad to see that we do. This made my morning!
That's not what I said. We have a *big* problem in that many of our patches affect each other's trees, that's because we work in the same area.
We both have to accept that we're going to keep conflicting - there are always going to be core ARM changes which affect SoC specifics, and there's always going to be SoC specific stuff which affects core ARM stuff. There's no getting away from that.
That's why I believe it's totally wrong that arm-soc has sole ownership of anything under arch/arm. That just doesn't work.
Plus, let's not forget that I'm the primary maintainer for a bunch of ARM platforms (though you wouldn't ever know it given how arm-soc behaves...) and that's been *really* pissing me off over the last few months...
Hi Russell,
On Mon, Apr 7, 2014 at 7:25 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:15:34AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
The multi_v7_defconfig change that triggers the PJ4 enable (and thus some boot failures[1]) is now in mainline. The fixes for this are in the patch tracker as 8015/1 and 8016/1.
A good question at this point is what change introduced this regression,
What introduced this regression was enabling MACH_DOVE in multi_v7_defconfig (commit 5c436fbef207e11aeae54ea6c8dfd4c65b2aaac2) since that selects the PJ4 options.
We've had this reverted in arm-soc/for-next while waiting for the patches to make it through your patch tracker, but the pull request with that change has gone out, and now it's in mainline, so we have boot failures in mainline[1]
and why did that change go through a different tree to that which is being asked to carry the fixes?
The original change was a multi_v7_defconfig change which we've been handling through arm-soc. The fix is a core CPU identification change that typically goes through you.
Since we now have mainline breakage, we'd be glad to take the fix if you're too busy, but ideally the fix would go through your patch tracker into your tree.
Thanks,
Kevin
[1] http://lists.linaro.org/pipermail/kernel-build-reports/2014-April/003158.htm...
On Tue, Apr 08, 2014 at 09:12:44AM -0700, Kevin Hilman wrote:
Hi Russell,
On Mon, Apr 7, 2014 at 7:25 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:15:34AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
The multi_v7_defconfig change that triggers the PJ4 enable (and thus some boot failures[1]) is now in mainline. The fixes for this are in the patch tracker as 8015/1 and 8016/1.
Right, eventually submitted four days *after* the merge window had opened.
A good question at this point is what change introduced this regression,
What introduced this regression was enabling MACH_DOVE in multi_v7_defconfig (commit 5c436fbef207e11aeae54ea6c8dfd4c65b2aaac2) since that selects the PJ4 options.
We've had this reverted in arm-soc/for-next while waiting for the patches to make it through your patch tracker, but the pull request with that change has gone out, and now it's in mainline, so we have boot failures in mainline[1]
Right, so rather than checking with me about those *late* submitted patches, arm-soc people decided to go off and do their own thing.
and why did that change go through a different tree to that which is being asked to carry the fixes?
The original change was a multi_v7_defconfig change which we've been handling through arm-soc. The fix is a core CPU identification change that typically goes through you.
Right. If we're doing the strict file ownership thing, then this is what _should_ have happened, because there's a strict dependency between these two changes:
- the fixes for the PJ4B needed to be merged into a branch in my tree - _then_ that branch cross-merged into arm-soc - _then_ the offending arm-soc change should have been committed on top of that.
That means whoever merges first, the outcome is the same, and avoids any kind of build breakage.
If that didn't happen (it didn't) then with strict file ownership, arm-soc can't take the offending change. arm-soc shouldn't just stuff it into the mainline kernel anyway.
I will merge these two patches today. However, I'm *not* changing my plans as for pull requests to Linus for.
We _could_ of course all calm down, and realise that there will always be cases where patches for "files under our control" to go through different trees from time to time, and just deal with it as we have done in the past - but the message I'm getting is that arm-soc want to own all the SoC stuff exclusively, _and_ they want to take core ARM patches too. As I've already said, that's not on.
On Tue, Apr 8, 2014 at 9:53 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Tue, Apr 08, 2014 at 09:12:44AM -0700, Kevin Hilman wrote:
Hi Russell,
On Mon, Apr 7, 2014 at 7:25 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Mon, Apr 07, 2014 at 07:15:34AM -0700, Olof Johansson wrote:
On Mon, Apr 7, 2014 at 2:10 AM, Russell King - ARM Linux linux@arm.linux.org.uk wrote:
On Sun, Apr 06, 2014 at 11:12:51PM -0700, Olof's autobooter wrote:
Failed boards:
cubie multi_v7_defconfig : FAILED 1:05.77 cubie2 sunxi_defconfig : FAILED 1:21.41 cubie2 multi_v7_defconfig : FAILED 1:09.94 cubie2 multi_lpae_defconfig : FAILED 0:59.68 hummingboard multi_v7_defconfig : FAILED 1:04.69 panda multi_v7_defconfig : FAILED 1:36.35 snow exynos_defconfig : FAILED 2:24.53 snowball multi_v7_defconfig : FAILED 1:07.90 wandboard multi_v7_defconfig : FAILED 1:05.66So do we have any clues what's causing these to fail?
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
I haven't applied anything from the patch system for the last month or more as I've been soo bogged down with the l2c and fec changes.
The multi_v7_defconfig change that triggers the PJ4 enable (and thus some boot failures[1]) is now in mainline. The fixes for this are in the patch tracker as 8015/1 and 8016/1.
Right, eventually submitted four days *after* the merge window had opened.
Yes, that was very unfortunate. I had asked him several times to get those patches submitted to your patch tracker, but he took a long time.
A good question at this point is what change introduced this regression,
What introduced this regression was enabling MACH_DOVE in multi_v7_defconfig (commit 5c436fbef207e11aeae54ea6c8dfd4c65b2aaac2) since that selects the PJ4 options.
We've had this reverted in arm-soc/for-next while waiting for the patches to make it through your patch tracker, but the pull request with that change has gone out, and now it's in mainline, so we have boot failures in mainline[1]
Right, so rather than checking with me about those *late* submitted patches, arm-soc people decided to go off and do their own thing.
You're right, I should've checked with you on these. You were Cc'd on the PJ4 patches (and even had some comments on them), and since I was requesting Chao to submit them to your patch tracker on the same thread, I assumed you would see them and know they were needed as fixes. I know you're busy, so I should have pinged you on those fixes.
and why did that change go through a different tree to that which is being asked to carry the fixes?
The original change was a multi_v7_defconfig change which we've been handling through arm-soc. The fix is a core CPU identification change that typically goes through you.
Right. If we're doing the strict file ownership thing, then this is what _should_ have happened, because there's a strict dependency between these two changes:
- the fixes for the PJ4B needed to be merged into a branch in my tree
- _then_ that branch cross-merged into arm-soc
- _then_ the offending arm-soc change should have been committed on top of that.
That means whoever merges first, the outcome is the same, and avoids any kind of build breakage.
Agreed, That makes sense for build breakage.
The problem here though is actually boot breakage. We could do the same thing, but for boot breakage, it's just fine (IMO) that patches take separate paths, as long as they arrive around the same time.
If that didn't happen (it didn't) then with strict file ownership, arm-soc can't take the offending change. arm-soc shouldn't just stuff it into the mainline kernel anyway.
I think our (mistaken) assumption was that since the patches landed in your tracker, they would be applied soon since I assumed you were aware of the need for them. Our pull request wen out 3 days after the patches landed in your tracker, but I should've pinged you to confirm when they would be applied/submitted.
I will merge these two patches today. However, I'm *not* changing my plans as for pull requests to Linus for.
Thanks, I don't expect you to change your pull request plans.
We _could_ of course all calm down, and realise that there will always be cases where patches for "files under our control" to go through different trees from time to time, and just deal with it as we have done in the past
That is what I'm trying to do now.
I acknowledge it would've worked better if I had been checking with you on those patches before we sent our pull request. Sorry about that.
Kevin
On Mon, Apr 7, 2014 at 11:15 AM, Olof Johansson olof@lixom.net wrote:
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
You are right, Olof. With Chao's patch applied I was able to boot a mx6q with multi_v7_defconfig.
Thanks,
Fabio Estevam
On Mon, Apr 7, 2014 at 7:28 AM, Fabio Estevam festevam@gmail.com wrote:
On Mon, Apr 7, 2014 at 11:15 AM, Olof Johansson olof@lixom.net wrote:
I'm pretty sure these will be fixed by:
"arm: pj4: check cpu id for pj4 cp0 access"
That I don't see in -next yet. Adding Chao on this thread, since we've already requested the patch to be sent to the patch tracker...
You are right, Olof. With Chao's patch applied I was able to boot a mx6q with multi_v7_defconfig.
The PJ4 fix should not affect next-20140407.
What introduced this regression was enabling MACH_DOVE in multi_v7_defconfig (commit 5c436fbef207e11aeae54ea6c8dfd4c65b2aaac2) since that selects the PJ4 options.
However, we've had that commit reverted in arm-soc/for-next while waiting for the fix(es) to make it through Russell's patch tracker, so MACH_DOVE (and thus the PJ4 options) are *not* selected by default in the multi_v7_defconfig, so the boot failures here (on -next) are very unlikely to be fixed by the PJ4 fix.
For my booter, I had some imx failures also that were fixed by giving the kernel more room to uncompress since it was overwriting the DTB. Seems are multi_v7 kernels are growing, so are getting big enough to cause problems with the default load addresses we're using.
Olof, FWIW, here's what I'm using for wandboards:
loadaddr: 0x11000000 dtb_addr: 0x12000000 initrd_addr: 0x13000000
Kevin
Hi Kevin,
On Mon, Apr 7, 2014 at 12:24 PM, Kevin Hilman khilman@linaro.org wrote:
The PJ4 fix should not affect next-20140407.
It fixes the boot for me on mx6qsabresd.
Regards,
Fabio Estevam
On Mon, Apr 7, 2014 at 8:26 AM, Fabio Estevam festevam@gmail.com wrote:
Hi Kevin,
On Mon, Apr 7, 2014 at 12:24 PM, Kevin Hilman khilman@linaro.org wrote:
The PJ4 fix should not affect next-20140407.
It fixes the boot for me on mx6qsabresd.
Are you building next-20140407? Using multi_v7_defconfig?
Without the fix, when you build multi_v7_defconfig, do you see MACH_DOVE or the PJ4 options enabled in the resulting ~/.config?
Kevin
On Mon, Apr 7, 2014 at 12:29 PM, Kevin Hilman khilman@linaro.org wrote:
On Mon, Apr 7, 2014 at 8:26 AM, Fabio Estevam festevam@gmail.com wrote:
Hi Kevin,
On Mon, Apr 7, 2014 at 12:24 PM, Kevin Hilman khilman@linaro.org wrote:
The PJ4 fix should not affect next-20140407.
It fixes the boot for me on mx6qsabresd.
Are you building next-20140407? Using multi_v7_defconfig?
Yes, correct.
Without the fix, when you build multi_v7_defconfig, do you see MACH_DOVE or the PJ4 options enabled in the resulting ~/.config?
Without the fix:
CONFIG_CPU_PJ4B=y # CONFIG_MACH_DOVE is not set
(BTW: after applying Chao's patch these two options remain the same).
On Mon, Apr 7, 2014 at 8:35 AM, Fabio Estevam festevam@gmail.com wrote:
On Mon, Apr 7, 2014 at 12:29 PM, Kevin Hilman khilman@linaro.org wrote:
On Mon, Apr 7, 2014 at 8:26 AM, Fabio Estevam festevam@gmail.com wrote:
Hi Kevin,
On Mon, Apr 7, 2014 at 12:24 PM, Kevin Hilman khilman@linaro.org wrote:
The PJ4 fix should not affect next-20140407.
It fixes the boot for me on mx6qsabresd.
Are you building next-20140407? Using multi_v7_defconfig?
Yes, correct.
Without the fix, when you build multi_v7_defconfig, do you see MACH_DOVE or the PJ4 options enabled in the resulting ~/.config?
Without the fix:
CONFIG_CPU_PJ4B=y # CONFIG_MACH_DOVE is not set
(BTW: after applying Chao's patch these two options remain the same).
Chao's patch[1] has no effect unless CONFIG_CPU_PJ4=y, which is not set in your config because MACH_DOVE is not selected. (NOTE: this is different from PJ4B, which is set in your config), so I'm having a hard time understanding how his patch is fixing your boot.
Kevin
[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=8015/1
On Mon, Apr 7, 2014 at 12:40 PM, Kevin Hilman khilman@linaro.org wrote:
Chao's patch[1] has no effect unless CONFIG_CPU_PJ4=y, which is not set in your config because MACH_DOVE is not selected. (NOTE: this is different from PJ4B, which is set in your config), so I'm having a hard time understanding how his patch is fixing your boot.
Ok, just re-started the test with 3.14.0-next-20140407 built from multi_v7_defconfig and it is booting fine now.
Sorry for the noise.
kernel-build-reports@lists.linaro.org
-
Fabio Estevam -
Kevin Hilman -
Olof Johansson -
Olof's autobooter -
Russell King - ARM Linux