From owner-freebsd-arm@freebsd.org Sat Jan 6 14:36:47 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24220EBC534 for ; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0AA0B71A9F for ; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 0A04AEBC531; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09663EBC530; Sat, 6 Jan 2018 14:36:47 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7B3E71A9E; Sat, 6 Jan 2018 14:36:45 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [IPv6:2003:cd:6beb:2600:a470:65d3:e324:200f] (p200300CD6BEB2600A47065D3E324200F.dip0.t-ipconnect.de [IPv6:2003:cd:6beb:2600:a470:65d3:e324:200f]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 9A05771E3F906; Sat, 6 Jan 2018 15:36:35 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: svn commit: r327563 - in head/sys: arm/allwinner arm/conf arm64/conf conf From: Michael Tuexen In-Reply-To: Date: Sat, 6 Jan 2018 15:36:25 +0100 Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org, "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <1431AAD8-E4CB-437B-83D5-7691DC3FDD51@freebsd.org> References: <201801042237.w04MbFVR015965@repo.freebsd.org> <6F912304-B760-4DA2-AB74-C2C934026FC1@freebsd.org> To: Kyle Evans X-Mailer: Apple Mail (2.3445.5.20) X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=disabled version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail-n.franken.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jan 2018 14:36:47 -0000 > On 6. Jan 2018, at 15:24, Kyle Evans wrote: >=20 > On Sat, Jan 6, 2018 at 7:23 AM, Michael Tuexen = wrote: >>> On 4. Jan 2018, at 23:37, Kyle Evans wrote: >>>=20 >>> Author: kevans >>> Date: Thu Jan 4 22:37:15 2018 >>> New Revision: 327563 >>> URL: https://svnweb.freebsd.org/changeset/base/327563 >>>=20 >>> Log: >>> if_awg: Use syscon prop if it exists >>>=20 >>> The emac bindings that are landing in Linux 4.15 specify a syscon = property >>> on the emac node that point to /soc/syscon. Use this property if = it's >>> specified, but maintain backwards compatibility with the old method. >>>=20 >>> The older method is still used for boards that we get .dtb from = u-boot, such >>> as pine64, that did not yet have stable emac bindings. >>>=20 >>> Tested on: Banana Pi-M3 (a83t) >>> Tested on: Pine64 (a64) >>> Reviewed by: manu >>> Differential Revision: https://reviews.freebsd.org/D13296 >> This breaks booting on a RPi3. Please note that it is not only = panic'ing, >> but there are multiple errors before that. >=20 > Ugh, sorry about that. No problem... >=20 >>>> FreeBSD EFI boot block >> Loader path: /boot/loader.efi >>=20 >> Initializing modules: UFS >> Probing 3 block devices.....* done >> UFS found 1 partition >> Consoles: EFI console >> Command line arguments: loader.efi >> Image base: 0x39ab8008 >> EFI version: 2.05 >> EFI Firmware: Das U-boot (rev 0.00) >>=20 >> FreeBSD/arm64 EFI loader, Revision 1.1 >> (Wed Dec 6 19:13:14 CET 2017 root@bsd18.fh-muenster.de) >> EFI boot environment >> Loading /boot/defaults/loader.conf >> /boot/kernel/kernel text=3D0x7f3b28 data=3D0xaac80+0x3a106d = syms=3D[0x8+0x10e870+0x8+0x101345] >> /boot/entropy size=3D0x1000 >> /boot/kernel/geom_label.ko text=3D0x2a80 text=3D0x2710 = data=3D0x10118+0xfeec syms=3D[0x8+0x1548+0x8+0xef2] >>=20 >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by EFI at 0x8004000. >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2018 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, = 1994 >> The Regents of the University of California. All rights = reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 12.0-CURRENT #21 r327563M: Sat Jan 6 14:16:20 CET 2018 >> = tuexen@bsd10.fh-muenster.de:/usr/home/tuexen/head/sys/arm64/compile/TCP = arm64 >> FreeBSD clang version 5.0.1 (branches/release_50 319231) (based on = LLVM 5.0.1) >> VT: init without driver. >> sysctl_warn_reuse: can't re-use a leaf (kern.features.geom_label)! >> module_register: cannot register g_label from kernel; already loaded = from geom_label.ko >> Module g_label failed to register: 17 >> Starting CPU 1 (1) >> Starting CPU 2 (2) >> Starting CPU 3 (3) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: unblocking device. >> module_register_init: MOD_LOAD (efirt, 0xffff0000000cb414, 0) error = 12 >> random: entropy device external interface >> kbd0 at kbdmux0 >> ofwbus0: >> simplebus0: on ofwbus0 >> ofw_clkbus0: on ofwbus0 >> clk_fixed0: on ofw_clkbus0 >> clk_fixed1: on ofw_clkbus0 >> regfix0: on ofwbus0 >> regfix1: on ofwbus0 >> syscon_generic0: mem 0x40000000-0x400000ff on simplebus0 >> psci0: on ofwbus0 >> local_intc0: mem 0x40000000-0x400000ff = on simplebus0 >> local_intc0: could not allocate memory resource >> device_attach: local_intc0 attach returned 6 >=20 > Apologies for the breakage; this should be alleviated by r327621. > There will still be some errors (syscon_generic cannot allocate memory > resource), but that should be completely innocent in this case and > will give me time to track down why syscon shares register space with > local intc here. I can confirm that r327621 boots again on RPi3 and the system is usable. Thanks for the quick fix/workaround. Best regards Michael