From patchwork Thu Jan 31 03:02:03 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Olof Johansson X-Patchwork-Id: 2070611 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 05B963FD56 for ; Thu, 31 Jan 2013 03:02:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753485Ab3AaDCI (ORCPT ); Wed, 30 Jan 2013 22:02:08 -0500 Received: from mail-da0-f44.google.com ([209.85.210.44]:53016 "EHLO mail-da0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753300Ab3AaDCG (ORCPT ); Wed, 30 Jan 2013 22:02:06 -0500 Received: by mail-da0-f44.google.com with SMTP id z20so1069666dae.31 for ; Wed, 30 Jan 2013 19:02:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-gm-message-state; bh=U7mZTrMXsr9XaeljDmMBI7c2C8zvGJXRrXXPDTCLOo0=; b=dgm3XnIVVjIF+zB0HMwRixH2U03kyVvGM9sBa0aQV6Dh8iEoGIMB1UZMf74C63pJGa BEfuiJ4SFnRyYA9s8TLZTqoBbE9SQefn08maHyYm8TOxu0qBQUPzsT0OzP6P9Wub1Ipp ElcWAUe4u7wzCZKrR68R9VZMR3EK95CAXuHAYEFqOSl06Bw7fjD8t9kpH4ICR6b/tF7G 1XYTLmJgxXk8qP9zmZLkOxCxRo2h60iBXabGNALWPItjq5DjikjmdPg3hpqa40dRmEkN TV6sFmAVvYJ+e2rphe/AYM7s9T+w9xmWJQuHmIRznrOVSv4G2Q3vo2FCQcqYq5soGVcv C/HA== X-Received: by 10.68.236.97 with SMTP id ut1mr17817725pbc.164.1359601325538; Wed, 30 Jan 2013 19:02:05 -0800 (PST) Received: from localhost (173-13-129-225-sfba.hfc.comcastbusiness.net. [173.13.129.225]) by mx.google.com with ESMTPS id ou8sm3435470pbb.39.2013.01.30.19.02.03 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 30 Jan 2013 19:02:04 -0800 (PST) Date: Wed, 30 Jan 2013 19:02:03 -0800 From: Olof Johansson To: Russell King - ARM Linux Cc: linux-arm-kernel@lists.infradead.org, linux-omap@vger.kernel.org, Tony Lindgren , Nicolas Pitre , arm@kernel.org Subject: Re: Failure to boot... Message-ID: <20130131030203.GA8374@quad.lixom.net> References: <20130131014912.GM2637@n2100.arm.linux.org.uk> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20130131014912.GM2637@n2100.arm.linux.org.uk> User-Agent: Mutt/1.5.21 (2010-09-15) X-Gm-Message-State: ALoCoQmVql5pVEhN96+O/Zw1a1WurQxzspbE7VIHRb/RWYUVcTE5Sr7ThSk7EeWZ3EP0nAo6bmOE Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Thu, Jan 31, 2013 at 01:49:12AM +0000, Russell King - ARM Linux wrote: > Having spent today sorting out the Realview EB boot, the last thing > I expected to find was that both my OMAP platforms are unbootable > to the point that absolutely nothing happens after the boot loader > transfers control. > > I've not been running the boots for about a month, so I'm not sure > when this breakage crept in. > > You can see the results in the boot logs on the website. Please > investigate. And I'll try without arm-soc tomorrow. > > Very disappointed that the ARM kernel seems to be rather screwed at > the moment across multiple sub-arches. 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. 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? -Olof Acked-by: Nicolas Pitre --- 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; \