From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 90ECBC433EF for ; Sat, 9 Jul 2022 07:45:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:Message-ID: In-Reply-To:Subject:cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=8wm9GlGrA6blnE7LSWzgujeUNoJ+CtAjX495XwUI6C8=; b=u6j/UaEFjNd8N8 iLEP8WM+pM8NTMBWbQwEav+7qC+ARgq0foYDwFIzvrzVI66RVWozAkxxgN7sS1HCUzehjHGL9gGOb bHUyAJO2OHQs8PGUHuC+n/HyD61Vby7srcSnHxl6NuJ3oAW19KgLTiN09xL1WNI5fqKhO+F4KWdqv 4d48qLJjmOxuLiWamJBMvfXTMuekG+IBByjRtZumZxNQLANfVJtVmPV14ZMT4pjw16vkUOLhBYtM+ 66bWz4NFzwaXzGyoXoeiqDdA2a43H8bduF8pGl09f9dSfXVzT+2nUoZgXS4fn5up/sPxJY0+jCWD4 gUM/kGsNcOdRmZXhlvHw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oA58b-007Hm3-Vc; Sat, 09 Jul 2022 07:44:26 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oA58Y-007Hkv-1G for linux-arm-kernel@lists.infradead.org; Sat, 09 Jul 2022 07:44:23 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 607945C0159; Sat, 9 Jul 2022 03:44:21 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Sat, 09 Jul 2022 03:44:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1657352661; x=1657439061; bh=0cXoGRMGDTh1wYqM2BmQkH/KT8aE QokoLXiRn8lItgs=; b=S7NR17ZdBpIlfXyapA4hYHgPwoCwsOmCrNMaM84o9evC 6kHgCxJ5xq8qcQEhZXw1/G379ERTUDrFw1zF1aW+kb9LSAOGJUy6vjLnLn3LJGyy Mb3MA3oYyjjotCY4JY6PKWHWsG3rxVOGwX3co8bRaou6MQz+H4u03E4B7IIrqQaR xUCf64WB3xJoITmPGznvbr+V5JS+N4Mp7hV1CwjFqvcscysiw7xVUjhcACgEusMs YD2eKvt/TkE89psJEqLrOnA6MAkHYY7mszMvLKJBTQxHenRUWnOoASsUEiSPhHet 9lVuBOxTCrEq+tbVjZ5I9es4Yk+7ywv8x5L2yWLN4w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeikedguddvudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefujgfkfhggtgesthdtredttddtvdenucfhrhhomhephfhinhhn ucfvhhgrihhnuceofhhthhgrihhnsehlihhnuhigqdhmieekkhdrohhrgheqnecuggftrf grthhtvghrnhepkeelheekgeehieduudeiheehgeetffelkeekuedtkeelgfehgeeufeej teefieffnecuffhomhgrihhnpehophgvnhifrhhtrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepfhhthhgrihhnsehlihhnuhigqdhm ieekkhdrohhrgh X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 9 Jul 2022 03:44:18 -0400 (EDT) Date: Sat, 9 Jul 2022 17:44:32 +1000 (AEST) From: Finn Thain To: Geert Uytterhoeven cc: Linus Walleij , Imre Kaloz , Krzysztof Halasa , Linux ARM , Zoltan HERPAI Subject: Re: [PATCH] ARM: dts: ixp4xx: Fix up the Netgear WG302 device tree In-Reply-To: Message-ID: <7d2ec26-253e-ba2b-5b86-e4a83fc5ec2@linux-m68k.org> References: <20211228002818.302910-1-linus.walleij@linaro.org> MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220709_004422_166034_83282DF4 X-CRM114-Status: GOOD ( 18.73 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 8 Jul 2022, Geert Uytterhoeven wrote: > On Fri, Jul 8, 2022 at 3:15 PM Linus Walleij wrote: > > On Fri, Jul 8, 2022 at 5:16 AM Finn Thain wrote: > > > Does anyone still have the configs for that test? Here's what I see when I > > > build and boot ixp4xx_defconfig. > > > > > > RedBoot> load -r -b 0x01600000 zImage > > > Using default protocol (TFTP) > > > Raw file loaded 0x01600000-0x018a4087, assumed entry at 0x01600000 > > > RedBoot> exec 0x01600000 > > > Using base address 0x01600000 and length 0x002a4088 > > > > > > Error: invalid dtb and unrecognized/unsupported machine ID > > > r1=0x000000f5, r2=0x00000000 > > > Available machine support: > > > > > > ID (hex) NAME > > > ffffffff Generic DT based system > > > ffffffff IXP4xx (Device Tree) > > > > > > Please check your kernel config and/or bootloader. > > > > Usually this is because the DTB is corrupt. > > Usually because it gets overwritten due to a bad combination of load > addresses for kernel and DTB, or during copying by the boot loader. > However, this is redboot, using a single load command. > Load address seems to be okay. Changing 0x01600000 to 0x00080000 has no effect here. I suspect you're right about Redboot preventing such mistakes. > Finn: Does your zImage have an appended DTB? > No, I wasn't aware of that step. Thanks for the tip! Appending the appropriate dtb was sufficient to get the ixp4xx_defconfig build to boot. But a build using a custom .config crashed early: [ 0.000000] Booting Linux on physical CPU 0x0 [ 0.000000] Linux version 5.19.0-rc5-00105-g9f09069cde34 (fthain@nippy) (arm-unknown-linux-gnueabi-gcc (btc) 6.4.0, GNU ld (btc) 2.28) #16 Sat Jul 9 13:46:40 AEST 2022 [ 0.000000] CPU: XScale-IXP42x Family [690541f1] revision 1 (ARMv5TE), cr=000039ff [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] OF: fdt: Machine model: Netgear WG302 v1 [ 0.000000] printk: debug: ignoring loglevel setting. [ 0.000000] printk: bootconsole [earlycon0] enabled [ 0.000000] Memory policy: Data cache writeback [ 0.000000] Internal error: Oops - BUG: 0 [#1] ARM [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-rc5-00105-g9f09069cde34 #16 [ 0.000000] Hardware name: IXP4xx (Device Tree) [ 0.000000] PC is at 0x80494a74 [ 0.000000] LR is at 0x00200000 [ 0.000000] pc : [<80494a74>] lr : [<00200000>] psr: 800000d3 [ 0.000000] sp : 804b1ed4 ip : 81ffcfb0 fp : fef00000 [ 0.000000] r10: ffe00000 r9 : 001fffff r8 : 804b760c [ 0.000000] r7 : 804d6218 r6 : 804e8234 r5 : 804b75ec r4 : 81ffcf88 [ 0.000000] r3 : 81ffcfd8 r2 : fef00000 r1 : ff000000 r0 : 81ffcf88 [ 0.000000] Flags: Nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment user [ 0.000000] Control: 000039ff Table: 00004000 DAC: 00000055 [ 0.000000] Register r0 information: [ 0.000000] 8<--- cut here --- [ 0.000000] Unable to handle kernel paging request at virtual address 0003ff84 [ 0.000000] [0003ff84] *pgd=00000000 After a lot of messing around, I was finally able to fix my .config by deleting "CONFIG_DEBUG_UART_VIRT=0xfef00003". Then make was able to replace it with "CONFIG_DEBUG_UART_VIRT=0xfec00003" which resolved the crash. (ISTR the original setting came from an old ixp4xx .config from openwrt.org.) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel