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:

quoted

On Thu, Jan 31, 2013 at 09:20:24AM +0000, Russell King - ARM Linux wrote:

quoted

On Wed, Jan 30, 2013 at 11:19:40PM -0500, Nicolas Pitre wrote:

quoted

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.