| Message ID | 20130131030203.GA8374@quad.lixom.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 30 Jan 2013, Olof Johansson wrote: > My Panda ES works with omap2plus_defconfig, but I just noticed that the > in-kernel uImage target will use a bad load/entry address so loading and > booting that uImage will hang u-boot: > > Image Name: Linux-3.8.0-rc5-00389-g120d4a8 > Created: Wed Jan 30 18:30:39 2013 > Image Type: ARM Linux Kernel Image (uncompressed) > Data Size: 3843912 Bytes = 3753.82 kB = 3.67 MB > Load Address: fffffff2 > Entry Point: fffffff2 > > Looking at the latest build and boot log for SDP (oldconfig) on your build > status site verifies that you hit that case too. :( > > Wrapping by hand (which my scripts already do) produces a bootable image; just > verified both with and without device-tree on my panda. > > git bisect points at a069486162a59513053cf772515217ca61727704 (ARM: OMAP2+: > Enable ARCH_MULTIPLATFORM support) > > Hmm. This happens because nothing sources arch/arm/mach-*/Makefile.boot for > CONFIG_ARCH_MULTIPLATFORM builds, even if only a single platform is enabled, > since $MACHINE is empty. The uImage format is incompatible with multi-platform builds, period. The uImage wrapping should be done at kernel _installation_ time, not at _build_ time. That is, people shoud get into the habit of distributing a zImage binary, and the installation procedure on a particular platform should take care of running mkimage on it. Better yet (IMHO): just enable the zboot command in U-Boot to let you boot a zImage binary directly. > It seems like most of the available options to deal with this are bad. One > thing we should never do though, is to pretend to make a working uImage > when we're not. Maybe abort building just like in the case of multiple > load addresses? Absolutely. > diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile > index abfce28..71768b8 100644 > --- a/arch/arm/boot/Makefile > +++ b/arch/arm/boot/Makefile > @@ -68,8 +68,8 @@ else > endif > > check_for_multiple_loadaddr = \ > -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \ > - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \ > +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \ > + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \ > echo 'This is incompatible with uImages'; \ > echo 'Specify LOADADDR on the commandline to build an uImage'; \ > false; \ Acked-by: Nicolas Pitre <nico@linaro.org> Nicolas -- 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
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. -- 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
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. -- 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
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. 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. Regards, Santosh 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 -- 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
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
On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: > 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. > Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. The pull request from Tony [1] fixed the multi-platform boot issue for OMAP. Now trying to merge your for-next and test. Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83084.html -- 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
On Thursday 31 January 2013 07:30 PM, Santosh Shilimkar wrote: > On Thursday 31 January 2013 06:34 PM, Russell King - ARM Linux wrote: >> 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. >> > Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. > The pull request from Tony [1] fixed the multi-platform boot issue > for OMAP. > > Now trying to merge your for-next and test. > This is fine as well. I think the issue is the way uImage is created. 'make LOADADDRESS=XXXX uImage' actually doesn't work. Am using below method to create an uImage. mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n "Linux" -d zImage uImage Will you be able to try this out please ? Regards, Santosh -- 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
On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. > The pull request from Tony [1] fixed the multi-platform boot issue > for OMAP. > > Now trying to merge your for-next and test. Well, my tip (which is based on Linus' 6abb7c25) also builds and boots fine. Hang on... # CONFIG_ARCH_OMAP2PLUS is not set CONFIG_ARCH_VEXPRESS=y which of course won't boot, and this happens on both oldconfigs because of the change to multiplatform support. -- 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
On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: > > Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. > > The pull request from Tony [1] fixed the multi-platform boot issue > > for OMAP. > > > > Now trying to merge your for-next and test. > > Well, my tip (which is based on Linus' 6abb7c25) also builds and > boots fine. > > Hang on... > > # CONFIG_ARCH_OMAP2PLUS is not set > CONFIG_ARCH_VEXPRESS=y > > which of course won't boot, and this happens on both oldconfigs because > of the change to multiplatform support. And no, the instructions given last time around to add: # 13 Jan 2013: Update for OMAP moving to multiplatform CONFIG_ARCH_MULTIPLATFORM=y CONFIG_ARCH_MULTI_V7=y don't fix it either, it needs more options defined... -- 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
On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. >>> The pull request from Tony [1] fixed the multi-platform boot issue >>> for OMAP. >>> >>> Now trying to merge your for-next and test. >> >> Well, my tip (which is based on Linus' 6abb7c25) also builds and >> boots fine. >> >> Hang on... >> >> # CONFIG_ARCH_OMAP2PLUS is not set >> CONFIG_ARCH_VEXPRESS=y >> >> which of course won't boot, and this happens on both oldconfigs because >> of the change to multiplatform support. > > And no, the instructions given last time around to add: > > # 13 Jan 2013: Update for OMAP moving to multiplatform > CONFIG_ARCH_MULTIPLATFORM=y > CONFIG_ARCH_MULTI_V7=y > > don't fix it either, it needs more options defined... > Linus' tip + Tony's pull [1] request also makes things work on OMAP. Regards, Santosh [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg83084.html -- 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
On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: > On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: >> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>>> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. >>>> The pull request from Tony [1] fixed the multi-platform boot issue >>>> for OMAP. >>>> >>>> Now trying to merge your for-next and test. >>> >>> Well, my tip (which is based on Linus' 6abb7c25) also builds and >>> boots fine. >>> >>> Hang on... >>> >>> # CONFIG_ARCH_OMAP2PLUS is not set >>> CONFIG_ARCH_VEXPRESS=y >>> >>> which of course won't boot, and this happens on both oldconfigs because >>> of the change to multiplatform support. >> >> And no, the instructions given last time around to add: >> >> # 13 Jan 2013: Update for OMAP moving to multiplatform >> CONFIG_ARCH_MULTIPLATFORM=y >> CONFIG_ARCH_MULTI_V7=y >> >> don't fix it either, it needs more options defined... >> > Linus' tip + Tony's pull [1] request also makes things work > on OMAP. Thanks to all this multiplatform stuff, the autobuilder has been building nothing but Versatile Express kernels for the last 20 days. That totally explains why it won't boot. The only thing I was told is to add the above two config symbols. That is not the complete story. There's also other symbols which need adding too. It also looks like Versatile Express support _can't_ be disabled in a multiplatform kernel, which is ludicrous. And... fixing the config finally results in something that boots on the SDP4430. -- 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
On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 07:50:15PM +0530, Santosh Shilimkar wrote: >> On Thursday 31 January 2013 07:46 PM, Russell King - ARM Linux wrote: >>> On Thu, Jan 31, 2013 at 02:13:20PM +0000, Russell King - ARM Linux wrote: >>>> On Thu, Jan 31, 2013 at 07:30:01PM +0530, Santosh Shilimkar wrote: >>>>> Linus' tip(commit: 04c2eee5) + arm-soc for-next boots fine as well. >>>>> The pull request from Tony [1] fixed the multi-platform boot issue >>>>> for OMAP. >>>>> >>>>> Now trying to merge your for-next and test. >>>> >>>> Well, my tip (which is based on Linus' 6abb7c25) also builds and >>>> boots fine. >>>> >>>> Hang on... >>>> >>>> # CONFIG_ARCH_OMAP2PLUS is not set >>>> CONFIG_ARCH_VEXPRESS=y >>>> >>>> which of course won't boot, and this happens on both oldconfigs because >>>> of the change to multiplatform support. >>> >>> And no, the instructions given last time around to add: >>> >>> # 13 Jan 2013: Update for OMAP moving to multiplatform >>> CONFIG_ARCH_MULTIPLATFORM=y >>> CONFIG_ARCH_MULTI_V7=y >>> >>> don't fix it either, it needs more options defined... >>> >> Linus' tip + Tony's pull [1] request also makes things work >> on OMAP. > > Thanks to all this multiplatform stuff, the autobuilder has been building > nothing but Versatile Express kernels for the last 20 days. That totally > explains why it won't boot. > > The only thing I was told is to add the above two config symbols. That > is not the complete story. There's also other symbols which need adding > too. It also looks like Versatile Express support _can't_ be disabled in > a multiplatform kernel, which is ludicrous. > > And... fixing the config finally results in something that boots on the > SDP4430. > Great. Thanks for the confirmation. Regards, Santosh -- 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
* Santosh Shilimkar <santosh.shilimkar@ti.com> [130131 06:45]: > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > >>> > >>># 13 Jan 2013: Update for OMAP moving to multiplatform > >>>CONFIG_ARCH_MULTIPLATFORM=y > >>>CONFIG_ARCH_MULTI_V7=y > >>> > >>>don't fix it either, it needs more options defined... Just trying to figure out what was the missing entry in case others have the same problem. In addition to the ones above, I had also CONFIG_ARCH_OMAP2PLUS=y listed in my comments. Did you also need something else added manually? Regards, Tony -- 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
On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote: > too. It also looks like Versatile Express support _can't_ be disabled in > a multiplatform kernel, which is ludicrous. Should we go with this approach? https://patchwork.kernel.org/patch/1774521/ -- 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
On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > <linux@arm.linux.org.uk> wrote: > > > too. It also looks like Versatile Express support _can't_ be disabled in > > a multiplatform kernel, which is ludicrous. > > Should we go with this approach? > https://patchwork.kernel.org/patch/1774521/ We need to go with an approach which isn't going to break allnoconfig and randconfig. I've suggested that we should have a basic, minimalist platform always built in for DT supporting kernels. I've actually suggested that we should end up not having a machine_desc at all once the DT conversion is complete. Either of those solves the problem of us ending up with no platform support built with these configurations. The alternative is we end up with quite a long disgusting Kconfig option which becomes enabled when everything but Versatile Express is disabled... -- 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
On Thu, Jan 31, 2013 at 08:00:02AM -0800, Tony Lindgren wrote: > * Santosh Shilimkar <santosh.shilimkar@ti.com> [130131 06:45]: > > On Thursday 31 January 2013 07:57 PM, Russell King - ARM Linux wrote: > > >>> > > >>># 13 Jan 2013: Update for OMAP moving to multiplatform > > >>>CONFIG_ARCH_MULTIPLATFORM=y > > >>>CONFIG_ARCH_MULTI_V7=y > > >>> > > >>>don't fix it either, it needs more options defined... > > Just trying to figure out what was the missing entry in case > others have the same problem. > > In addition to the ones above, I had also CONFIG_ARCH_OMAP2PLUS=y > listed in my comments. Did you also need something else added > manually? Interesting, that's the one which got missed. The ones which did get updated on the 13th were just the noconfigs which were failing to build, and not the two oldconfigs which are the booted ones. The noconfigs already had OMAP2PLUS enabled in them which is probably how it got lost. -- 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
On Thursday 31 January 2013 16:18:23 Russell King - ARM Linux wrote: > On Thu, Jan 31, 2013 at 02:01:14PM -0200, Fabio Estevam wrote: > > On Thu, Jan 31, 2013 at 12:27 PM, Russell King - ARM Linux > > <linux@arm.linux.org.uk> wrote: > > > > > too. It also looks like Versatile Express support _can't_ be disabled in > > > a multiplatform kernel, which is ludicrous. > > > > Should we go with this approach? > > https://patchwork.kernel.org/patch/1774521/ > > We need to go with an approach which isn't going to break allnoconfig > and randconfig. > > I've suggested that we should have a basic, minimalist platform always > built in for DT supporting kernels. I've actually suggested that we > should end up not having a machine_desc at all once the DT conversion > is complete. Either of those solves the problem of us ending up with > no platform support built with these configurations. Yes, I like the idea a lot. I think we should be pretty close to being able to do that just now, with generic hooks to initialize the interrupt controller and clocksouroce drivers. > The alternative is we end up with quite a long disgusting Kconfig > option which becomes enabled when everything but Versatile Express > is disabled... Yes, I've tried that in the past, it wasn't nice. It also gets much more complex if you want to do it for all configurations instead of just those that enable ARMv7. Arnd -- 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
diff --git a/arch/arm/boot/Makefile b/arch/arm/boot/Makefile index abfce28..71768b8 100644 --- a/arch/arm/boot/Makefile +++ b/arch/arm/boot/Makefile @@ -68,8 +68,8 @@ else endif check_for_multiple_loadaddr = \ -if [ $(words $(UIMAGE_LOADADDR)) -gt 1 ]; then \ - echo 'multiple load addresses: $(UIMAGE_LOADADDR)'; \ +if [ $(words $(UIMAGE_LOADADDR)) -ne 1 ]; then \ + echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \ echo 'This is incompatible with uImages'; \ echo 'Specify LOADADDR on the commandline to build an uImage'; \ false; \