From: Russell King - ARM Linux <linux@arm.linux.org.uk> To: Santosh Shilimkar <santosh.shilimkar@ti.com> Cc: Nicolas Pitre <nico@fluxnic.net>, Olof Johansson <olof@lixom.net>, Tony Lindgren <tony@atomide.com>, linux-omap@vger.kernel.org, arm@kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: Failure to boot... Date: Thu, 31 Jan 2013 13:04:37 +0000 [thread overview] Message-ID: <20130131130437.GP2637@n2100.arm.linux.org.uk> (raw) In-Reply-To: <510A6877.9080307@ti.com> On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>> Better yet (IMHO): just enable the zboot command in U-Boot to let you >>>> boot a zImage binary directly. >>> >>> I wish it were that easy but it isn't. I've no idea where to get a >>> version of uboot for my boards which supports that; TI have always >>> supplied updates to uboot for me, and with the current state of TI >>> being afaict in chaos. >>> >>> TI have always supplied a replacement X-Loader with each uboot update. >>> I've no idea what X-Loader is or why both get updated together, but... >>> >>> Moreover, I doubt that the 3430LDP, of which there are multiple versions, >>> will ever see a uboot update. It already suffers from a lack of correct >>> kernel support due to random wiring changes between these versions (the >>> keypad doesn't work correctly) and I've yet to indentify which version >>> it is despite downloading the circuits. So trying to locate the right >>> uboot will be impossible there. >>> >>> So, I'm _stuck_ with uImages for these platforms. >> >> Right, so I'm now passing LOADADDR= which allows this to work - and the >> latest OMAP4430SDP boot result shows almost the same sad broken story. >> > I just tried latest mainline (commit: 04c2eee5) and default config > just boots fine. Please read the notes at the bottom of the page, specifically: * Build tree is currently created on an ad-hoc basis from Linus' tip, rmk's development tip and arm-soc for-next branches. This system does *not* build and boot vanilla mainline kernels. It is (as the above says): - Linus' tip - My for-next plus a few other bits - arm-soc for-next all merged together. Here's the diffstat between my for-next and the remainder of other stuff that gets built: arch/arm/mach-realview/core.c | 212 ++++++++ arch/arm/mach-realview/core.h | 2 + arch/arm/mach-realview/include/mach/platform.h | 2 + arch/arm/mach-realview/realview_eb.c | 37 ++- arch/arm/mach-realview/realview_pb11mp.c | 33 ++- arch/arm/mach-realview/realview_pba8.c | 3 +- arch/arm/mach-realview/realview_pbx.c | 3 +- arch/arm/mach-versatile/core.c | 482 ++++++++++++++++++- arch/arm/mach-versatile/include/mach/platform.h | 6 + arch/arm/mach-versatile/versatile_pb.c | 17 +- drivers/dma/amba-pl08x.c | 26 +- drivers/tty/serial/omap-serial.c | 30 ++ drivers/tty/serial/serial_core.c | 23 +- include/linux/serial_core.h | 2 + include/sound/soc-dmaengine.h | 26 + sound/soc/Kconfig | 5 + sound/soc/Makefile | 3 + sound/soc/sa11x0/Kconfig | 14 + sound/soc/sa11x0/Makefile | 5 + sound/soc/sa11x0/sa11x0-assabet.c | 432 +++++++++++++++++ sound/soc/sa11x0/sa11x0-ssp.c | 345 +++++++++++++ sound/soc/sa11x0/sa11x0-ssp.h | 11 + sound/soc/soc-dmaengine.c | 591 +++++++++++++++++++++++ 23 files changed, 2283 insertions(+), 27 deletions(-) As far as OMAP goes, that's basically additional bits for serial DMA support that I was working on, best pieced back together before the serial driver was majorly reworked a couple of merge windows ago. These have been there for at least the last three months. The rest are for SA11x0 Assabet sound support, and DMA support on Versatile/Realview platforms. > I was looking at your build system output which shows the boot > state "OMAP4430 SDP: fail". Your config seems to be with > CONFIG_ARCH_MULTIPLATFORM=y and indeed this kernel doesn't > boot. Seems to abort very early in boot. Am looking at it. Thanks. > P.S Btw, the load address issue with multi-platform build > was highlighted on the list in past by Tony [1] > > [1] http://www.spinics.net/lists/linux-omap/msg84146.html That's no good to me if it only goes to linux-omap. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: linux@arm.linux.org.uk (Russell King - ARM Linux) To: linux-arm-kernel@lists.infradead.org Subject: Failure to boot... Date: Thu, 31 Jan 2013 13:04:37 +0000 [thread overview] Message-ID: <20130131130437.GP2637@n2100.arm.linux.org.uk> (raw) In-Reply-To: <510A6877.9080307@ti.com> On Thu, Jan 31, 2013 at 06:19:59PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 04:10 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote: >>> On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote: >>>> Better yet (IMHO): just enable the zboot command in U-Boot to let you >>>> boot a zImage binary directly. >>> >>> I wish it were that easy but it isn't. I've no idea where to get a >>> version of uboot for my boards which supports that; TI have always >>> supplied updates to uboot for me, and with the current state of TI >>> being afaict in chaos. >>> >>> TI have always supplied a replacement X-Loader with each uboot update. >>> I've no idea what X-Loader is or why both get updated together, but... >>> >>> Moreover, I doubt that the 3430LDP, of which there are multiple versions, >>> will ever see a uboot update. It already suffers from a lack of correct >>> kernel support due to random wiring changes between these versions (the >>> keypad doesn't work correctly) and I've yet to indentify which version >>> it is despite downloading the circuits. So trying to locate the right >>> uboot will be impossible there. >>> >>> So, I'm _stuck_ with uImages for these platforms. >> >> Right, so I'm now passing LOADADDR= which allows this to work - and the >> latest OMAP4430SDP boot result shows almost the same sad broken story. >> > I just tried latest mainline (commit: 04c2eee5) and default config > just boots fine. Please read the notes at the bottom of the page, specifically: *?Build tree is currently created on an ad-hoc basis from Linus' tip, rmk's development tip and arm-soc for-next branches. This system does *not* build and boot vanilla mainline kernels. It is (as the above says): - Linus' tip - My for-next plus a few other bits - arm-soc for-next all merged together. Here's the diffstat between my for-next and the remainder of other stuff that gets built: arch/arm/mach-realview/core.c | 212 ++++++++ arch/arm/mach-realview/core.h | 2 + arch/arm/mach-realview/include/mach/platform.h | 2 + arch/arm/mach-realview/realview_eb.c | 37 ++- arch/arm/mach-realview/realview_pb11mp.c | 33 ++- arch/arm/mach-realview/realview_pba8.c | 3 +- arch/arm/mach-realview/realview_pbx.c | 3 +- arch/arm/mach-versatile/core.c | 482 ++++++++++++++++++- arch/arm/mach-versatile/include/mach/platform.h | 6 + arch/arm/mach-versatile/versatile_pb.c | 17 +- drivers/dma/amba-pl08x.c | 26 +- drivers/tty/serial/omap-serial.c | 30 ++ drivers/tty/serial/serial_core.c | 23 +- include/linux/serial_core.h | 2 + include/sound/soc-dmaengine.h | 26 + sound/soc/Kconfig | 5 + sound/soc/Makefile | 3 + sound/soc/sa11x0/Kconfig | 14 + sound/soc/sa11x0/Makefile | 5 + sound/soc/sa11x0/sa11x0-assabet.c | 432 +++++++++++++++++ sound/soc/sa11x0/sa11x0-ssp.c | 345 +++++++++++++ sound/soc/sa11x0/sa11x0-ssp.h | 11 + sound/soc/soc-dmaengine.c | 591 +++++++++++++++++++++++ 23 files changed, 2283 insertions(+), 27 deletions(-) As far as OMAP goes, that's basically additional bits for serial DMA support that I was working on, best pieced back together before the serial driver was majorly reworked a couple of merge windows ago. These have been there for at least the last three months. The rest are for SA11x0 Assabet sound support, and DMA support on Versatile/Realview platforms. > I was looking at your build system output which shows the boot > state "OMAP4430 SDP: fail". Your config seems to be with > CONFIG_ARCH_MULTIPLATFORM=y and indeed this kernel doesn't > boot. Seems to abort very early in boot. Am looking at it. Thanks. > P.S Btw, the load address issue with multi-platform build > was highlighted on the list in past by Tony [1] > > [1] http://www.spinics.net/lists/linux-omap/msg84146.html That's no good to me if it only goes to linux-omap.
next prev parent reply other threads:[~2013-01-31 13:04 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-01-31 1:49 Failure to boot Russell King - ARM Linux 2013-01-31 1:49 ` Russell King - ARM Linux 2013-01-31 3:02 ` Olof Johansson 2013-01-31 3:02 ` Olof Johansson 2013-01-31 4:19 ` Nicolas Pitre 2013-01-31 4:19 ` Nicolas Pitre 2013-01-31 9:20 ` Russell King - ARM Linux 2013-01-31 9:20 ` Russell King - ARM Linux 2013-01-31 10:40 ` Russell King - ARM Linux 2013-01-31 10:40 ` Russell King - ARM Linux 2013-01-31 12:49 ` Santosh Shilimkar 2013-01-31 12:49 ` Santosh Shilimkar 2013-01-31 13:04 ` Russell King - ARM Linux [this message] 2013-01-31 13:04 ` Russell King - ARM Linux 2013-01-31 14:00 ` Santosh Shilimkar 2013-01-31 14:00 ` Santosh Shilimkar 2013-01-31 14:10 ` Santosh Shilimkar 2013-01-31 14:10 ` Santosh Shilimkar 2013-01-31 14:13 ` Russell King - ARM Linux 2013-01-31 14:13 ` Russell King - ARM Linux 2013-01-31 14:16 ` Russell King - ARM Linux 2013-01-31 14:16 ` Russell King - ARM Linux 2013-01-31 14:20 ` Santosh Shilimkar 2013-01-31 14:20 ` Santosh Shilimkar 2013-01-31 14:27 ` Russell King - ARM Linux 2013-01-31 14:27 ` Russell King - ARM Linux 2013-01-31 14:43 ` Santosh Shilimkar 2013-01-31 14:43 ` Santosh Shilimkar 2013-01-31 16:00 ` Tony Lindgren 2013-01-31 16:00 ` Tony Lindgren 2013-01-31 16:19 ` Russell King - ARM Linux 2013-01-31 16:19 ` Russell King - ARM Linux 2013-01-31 16:01 ` Fabio Estevam 2013-01-31 16:01 ` Fabio Estevam 2013-01-31 16:18 ` Russell King - ARM Linux 2013-01-31 16:18 ` Russell King - ARM Linux 2013-01-31 16:27 ` Arnd Bergmann 2013-01-31 16:27 ` Arnd Bergmann 2013-01-31 17:51 ` [PATCH, RFC] default machine descriptor for multiplatform Arnd Bergmann 2013-01-31 17:51 ` Arnd Bergmann 2013-01-31 18:52 ` Stephen Warren 2013-01-31 18:52 ` Stephen Warren 2013-01-31 20:57 ` Arnd Bergmann 2013-01-31 20:57 ` Arnd Bergmann 2013-01-31 20:34 ` Nicolas Pitre 2013-01-31 20:34 ` Nicolas Pitre 2013-02-01 11:47 ` Santosh Shilimkar 2013-02-01 11:47 ` Santosh Shilimkar 2013-02-01 12:34 ` Arnd Bergmann 2013-02-01 12:34 ` Arnd Bergmann 2013-02-05 21:37 ` Rob Herring 2013-02-05 21:37 ` Rob Herring 2013-02-05 22:23 ` Arnd Bergmann 2013-02-05 22:23 ` Arnd Bergmann 2013-02-05 21:39 ` Olof Johansson 2013-02-05 21:39 ` Olof Johansson 2013-03-03 13:27 ` Rob Herring
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20130131130437.GP2637@n2100.arm.linux.org.uk \ --to=linux@arm.linux.org.uk \ --cc=arm@kernel.org \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=nico@fluxnic.net \ --cc=olof@lixom.net \ --cc=santosh.shilimkar@ti.com \ --cc=tony@atomide.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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.