From owner-freebsd-arm@freebsd.org Sun Dec 17 15:03:54 2017 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 6E070E8C0A4 for ; Sun, 17 Dec 2017 15:03:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21C6573037 for ; Sun, 17 Dec 2017 15:03:53 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1eQaTf-0001bA-Fg for freebsd-arm@freebsd.org; Sun, 17 Dec 2017 17:03:43 +0200 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: ubldr question Message-Id: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> Date: Sun, 17 Dec 2017 17:03:43 +0200 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.4.7) 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: Sun, 17 Dec 2017 15:03:54 -0000 Hi, in the past there was CONFIG.TXT and/or UENV.TXT where I could override = the default .dtb file set by uboot, but now it seems these files are either = not read, or the command has changed. So, apart from stoping the loader, and typing =E2=80=98env set fdtfile = xxx.dtb=E2=80=99 is there another way? cheers, danny From owner-freebsd-arm@freebsd.org Sun Dec 17 17:02:12 2017 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 C3FFBE8EE40 for ; Sun, 17 Dec 2017 17:02:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A857876DC2 for ; Sun, 17 Dec 2017 17:02:12 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: fc61dcd4-e34b-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id fc61dcd4-e34b-11e7-93a5-cd02e7dc7692; Sun, 17 Dec 2017 17:01:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBHH25ou003491; Sun, 17 Dec 2017 10:02:05 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513530125.95072.27.camel@freebsd.org> Subject: Re: ubldr question From: Ian Lepore To: Daniel Braniss , freebsd-arm@freebsd.org Date: Sun, 17 Dec 2017 10:02:05 -0700 In-Reply-To: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Sun, 17 Dec 2017 17:02:12 -0000 On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > Hi, > in the past there was CONFIG.TXT and/or UENV.TXT where I could > override the > default .dtb file set by uboot, but now it seems these files are > either not read, or the > command has changed. > > So, apart from stoping the loader, and typing ¡env set fdtfile > xxx.dtb¢ > is there another way? > > cheers, > danny > You should be able to "saveenv" after making your change. The uEnv.txt that used to be supported was to make it possible to programatically change the boot behavior from freebsd userland.  That feature got lost when the uboot ports were all rewritten to use a default environment (boot scripts and all) for freebsd that is basically identical to what linux uses.  It's a lot less work for the port maintainers, but we lost some functionality along the way. -- Ian From owner-freebsd-arm@freebsd.org Sun Dec 17 17:29:42 2017 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 AA907E8FA1B for ; Sun, 17 Dec 2017 17:29:42 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8D48B77717 for ; Sun, 17 Dec 2017 17:29:42 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: d6d4a100-e34f-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id d6d4a100-e34f-11e7-93a5-cd02e7dc7692; Sun, 17 Dec 2017 17:29:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBHHTenK003509; Sun, 17 Dec 2017 10:29:40 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513531780.95072.29.camel@freebsd.org> Subject: Re: ubldr vs ubldr.bin? From: Ian Lepore To: Sergey Manucharian , freebsd-arm@freebsd.org Date: Sun, 17 Dec 2017 10:29:40 -0700 In-Reply-To: <20171111015041.GC1974@dendrobates.araler.com> References: <1436978285.1334.335.camel@freebsd.org> <20171111015041.GC1974@dendrobates.araler.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Sun, 17 Dec 2017 17:29:42 -0000 On Fri, 2017-11-10 at 18:50 -0700, Sergey Manucharian wrote: > Excerpts from Ian Lepore's message from Wed 15-Jul-15 10:38: > > > > On Wed, 2015-07-15 at 15:04 +0200, Ronald Klop wrote: > > > > > > Hello, > > > > > > What is the difference between ubldr and ubldr.bin? > > > > > > [root at sheeva ~]# ls -l /boot/ubldr* > > > -r--r--r--  1 root  wheel  283086 Jul 11 00:34 /boot/ubldr > > > -r--r--r--  1 root  wheel  235212 Jul 11 00:34 /boot/ubldr.bin > > > -r-xr-xr-x  1 root  wheel  214432 Jan  8  2015 /boot/ubldr.old > > > > > > > > > Regards, > > > Ronald. > > ubldr is an elf binary that must be loaded at the address it was built > > for (the UBLDR_LOADADDR address).  ubldr.bin is a raw executable image > > (no elf headers) which is self-relocating and can be loaded at any > > address.  ubldr is launched with the bootelf command, and thus requires > > CONFIG_ELF in u-boot.  ubldr.bin is launched with "go ${loadaddr}". > > > > So all in all, ubldr.bin is the new way of things, and ubldr is still > > being built only for compatibility with people that have older u-boot > > installed.  (Right now that's pretty much everybody, because I haven't > > actually updated any of the u-boot ports yet to use ubldr.bin, because > > I've been too busy with $work.) > > > > The big thing ubldr.bin gets us is a common armv6[hf] userland that runs > > on any board.  Previously the single userland difference between various > > arm boards is that UBLDR_LOADADDR was different for each board. > > > > -- Ian > Sorry for the resurrection of this old thread. > > Why the mainstream u-boot cannot run ubldr.bin? Or am I missing > something? > > I tried with BeagleBone Black and it doesn't work, resets CPU when > trying: > > load mmc 0:1 0x82000000 ubldr.bin > go 0x82000000 > > -S > Some bug fixes from PR 224008 were applied recently (about a week ago), I wonder if they might fix the problem you're seeing? -- Ian From owner-freebsd-arm@freebsd.org Sun Dec 17 19:19:55 2017 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 870C2E9290A for ; Sun, 17 Dec 2017 19:19:55 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 40FD17ABC7; Sun, 17 Dec 2017 19:19:54 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1eQeTT-0005H8-Us; Sun, 17 Dec 2017 21:19:48 +0200 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: ubldr question Date: Sun, 17 Dec 2017 21:19:23 +0200 In-Reply-To: <1513530125.95072.27.camel@freebsd.org> Cc: freebsd-arm@freebsd.org To: Ian Lepore References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> X-Mailer: Apple Mail (2.3445.4.7) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Sun, 17 Dec 2017 19:19:55 -0000 > On 17 Dec 2017, at 19:02, Ian Lepore wrote: >=20 > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: >> Hi, >> in the past there was CONFIG.TXT and/or UENV.TXT where I could >> override the >> default .dtb file set by uboot, but now it seems these files are >> either not read, or the >> command has changed. >>=20 >> So, apart from stoping the loader, and typing =E2=80=98env set = fdtfile >> xxx.dtb=E2=80=99 >> is there another way? >>=20 >> cheers, >> danny >>=20 >=20 > You should be able to "saveenv" after making your change. >=20 > The uEnv.txt that used to be supported was to make it possible to > programatically change the boot behavior from freebsd userland. That > feature got lost when the uboot ports were all rewritten to use a > default environment (boot scripts and all) for freebsd that is > basically identical to what linux uses. It's a lot less work for the > port maintainers, but we lost some functionality along the way. >=20 > =E2=80=94 Ian thank sIan, that did it, now if uboot could figure out what SOC it booted from and = choose the appropriate dtb file would be great! cheers, danny From owner-freebsd-arm@freebsd.org Sun Dec 17 19:25:12 2017 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 C4EA2E92B58 for ; Sun, 17 Dec 2017 19:25:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 846C97AFAF for ; Sun, 17 Dec 2017 19:25:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x234.google.com with SMTP id f190so25279487ita.5 for ; Sun, 17 Dec 2017 11:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=CX0TGCrWxnhvMgrbCmqimuVrmlc4Im419od4jLuPT50=; b=k5ZRj3woY5Dpthph0AeUiisPC/U9WSUU7CW6dfzLJ/S99THI0iEsW1LlJhCOfgE0ne XecXYDyo78L/AYaOYET6e56v2bINJV7dH28t0drkURgCCDBt+Eq6a7UbkNIpAO8x3Gf5 jtarYGUkP1dRCBgK4cLKP/UtdNqf2vsNj3XfTLX3CmTJ+mCHOHBKQJREDMJL1GXcbCO5 +jm11ruOMkjpa3DDebtsm2kpdbzXiwxVo7xCbargw1oreGW4kR5Ea4E/2YYLtVph2dh+ PP4RfUOapVx6JeB9Mj19UtWYdfR1bqaKh7ePOUiigJPPF1o+o39/yL5iVXGoEjiNndSa 5F0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=CX0TGCrWxnhvMgrbCmqimuVrmlc4Im419od4jLuPT50=; b=BHn6k1LNI/7cck6YgUn/KGl7r1G4G+aI3U5gvo1l43SGASTkE+dSHxXa5uqNC2+02S sDSsyVUhayg+bypdlt2V4niLqhZgcxz9fs+odCN36DZgprKNynLtxVx/W4sLsPAzdEe+ LQSx4ve5h084gwbzZz5V9LHF3+TjZG+JDZ4qgufd8LdrWgSHYIK3fCnJmhaAiBP10r1d 5jH2AGnawfp4774DYwWegXTKNPJqV8q6yGQr8EfAhUroZwh9ChV8kYlKYCmhqDj4kIQ2 Yx7hjJYep5FTAtGwmjUo7uuZ1M5zK0w++u4fFzng7Jfv2HXe43rQRrvie/KNWIbIzvTH xLXA== X-Gm-Message-State: AKGB3mIrzBQccA7MUQ/3CU4BzgxKg83rrVcs8eSWAyqFYMgD+3Zt2q+1 rSQxH0a9Jae1PHR90gjubpGuwhDOF4/j+4Ts/+45nw== X-Google-Smtp-Source: ACJfBouiqC6SqLz2zO0MbdEKSfKlp1cAL/uHtWJNfajXGkmqiZmIDoaaa2fZGgP1hHP8T4vvItUCOk16w9zNfuUgzps= X-Received: by 10.36.131.200 with SMTP id d191mr17153964ite.97.1513538711660; Sun, 17 Dec 2017 11:25:11 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Sun, 17 Dec 2017 11:25:10 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> From: Warner Losh Date: Sun, 17 Dec 2017 12:25:10 -0700 X-Google-Sender-Auth: j9MdxQbMQ1-jT69qvWJ6ubYC6AQ Message-ID: Subject: Re: ubldr question To: Daniel Braniss Cc: Ian Lepore , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Sun, 17 Dec 2017 19:25:12 -0000 On Sun, Dec 17, 2017 at 12:19 PM, Daniel Braniss wrote: > > > > On 17 Dec 2017, at 19:02, Ian Lepore wrote: > > > > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > >> Hi, > >> in the past there was CONFIG.TXT and/or UENV.TXT where I could > >> override the > >> default .dtb file set by uboot, but now it seems these files are > >> either not read, or the > >> command has changed. > >> > >> So, apart from stoping the loader, and typing =E2=80=98env set fdtfile > >> xxx.dtb=E2=80=99 > >> is there another way? > >> > >> cheers, > >> danny > >> > > > > You should be able to "saveenv" after making your change. > > > > The uEnv.txt that used to be supported was to make it possible to > > programatically change the boot behavior from freebsd userland. That > > feature got lost when the uboot ports were all rewritten to use a > > default environment (boot scripts and all) for freebsd that is > > basically identical to what linux uses. It's a lot less work for the > > port maintainers, but we lost some functionality along the way. > > > > =E2=80=94 Ian > > thank sIan, > that did it, now if uboot could figure out what SOC it booted from and > choose the appropriate > dtb file would be great! > It's already supposed to do that since we have a different u-boot for each board (or in some cases family of boards). The SoC is insufficient to know which DTB to load (otherwise we'd just have the tables in the kernel and not bother with the added complication). Warner From owner-freebsd-arm@freebsd.org Sun Dec 17 19:34:39 2017 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 1E09CE92E06 for ; Sun, 17 Dec 2017 19:34:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 019697B2D3 for ; Sun, 17 Dec 2017 19:34:38 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 26161c75-e361-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 26161c75-e361-11e7-8486-0934409070aa; Sun, 17 Dec 2017 19:33:25 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBHJXUtr003661; Sun, 17 Dec 2017 12:33:30 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513539210.95072.31.camel@freebsd.org> Subject: Re: ubldr question From: Ian Lepore To: Daniel Braniss Cc: freebsd-arm@freebsd.org Date: Sun, 17 Dec 2017 12:33:30 -0700 In-Reply-To: References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Sun, 17 Dec 2017 19:34:39 -0000 On Sun, 2017-12-17 at 21:19 +0200, Daniel Braniss wrote: > > > > > On 17 Dec 2017, at 19:02, Ian Lepore wrote: > > > > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > > > > > Hi, > > > in the past there was CONFIG.TXT and/or UENV.TXT where I could > > > override the > > > default .dtb file set by uboot, but now it seems these files are > > > either not read, or the > > > command has changed. > > > > > > So, apart from stoping the loader, and typing ‘env set fdtfile > > > xxx.dtb’ > > > is there another way? > > > > > > cheers, > > > danny > > > > > You should be able to "saveenv" after making your change. > > > > The uEnv.txt that used to be supported was to make it possible to > > programatically change the boot behavior from freebsd > > userland.  That > > feature got lost when the uboot ports were all rewritten to use a > > default environment (boot scripts and all) for freebsd that is > > basically identical to what linux uses.  It's a lot less work for > > the > > port maintainers, but we lost some functionality along the way. > > > > — Ian > thank sIan, > that did it, now if uboot could figure out what SOC it booted from > and choose the appropriate > dtb file would be great! > > cheers, > danny > I'm not sure why it's not doing so, but you can work around it by manually doing "setenv fdt_file yourfilename.dtb" then saveenv. -- Ian From owner-freebsd-arm@freebsd.org Mon Dec 18 05:56:53 2017 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 3CE94EA235D for ; Mon, 18 Dec 2017 05:56:53 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C2F656CCEA for ; Mon, 18 Dec 2017 05:56:52 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: by mail-wm0-x22a.google.com with SMTP id n138so26866356wmg.2 for ; Sun, 17 Dec 2017 21:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=oPmc9+AItfrL8joWhfcZ8dlvP+5p3b+H5ZAYsEEApHA=; b=CCKKYSh1OH1UccAW1F2g08FDSSuRBQbIxHgyvzUbWWf4VDG+aXIs2RAsNISlFJgspq jDIZSyjuoZd4EiDs1FS6A/q+3iq7k311OaR44Ncluy4zleNJTy1d7v9inUEpwN4BTyUQ mUU8c+FhylAtBNyVwVxXx3YqPdoJWzpVPgg9imrzWIsSJSQB06V/0VPCMwgPastL/A2L w6iiuTrLr/aWgP6jlNBYHsVr+mxEd9mQSAimCJkOO9CV/X6VkduJngvE+36FJO7J0tIy 0CvH46OXu9iymPxBRRZCykNAQua+M+sx9sLIqcmy8pYIbyxlVAKtJD7/Y8JEbydo/uwX Eg9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=oPmc9+AItfrL8joWhfcZ8dlvP+5p3b+H5ZAYsEEApHA=; b=uQeNXolIaXvIp2LePH9HMXKcVeKGaFw1PWzV43P2t8WN1IxNxhYwa7DI/NLBfUxBbF BgtkeEg8w8BGFbL+7lobapO4lG9KU7DmE+yDJ2/uxFnkN6/wKdIvQR2BBLKusNOGgaBN 1FOzo2uzMzlTeasOBc9vqL8R5GLXSw6zm/pyyoD5Jm2o/c6ldXOh5O8KrLo5SKQAbAE4 DN4RWdMPWESWcWMHmVNvIN97rSvQlNYKM1KHg/MTaCiEvWV4KrcNjFLr8k0FENHTPTSp zaTNtIv4PB2+MaSS5PpsUWylv9VeD6ZkYGY2JdFU4cMsVvgny1Hq+7eo3dfYIepZ+naO XyPg== X-Gm-Message-State: AKGB3mJz5EKEIpRh9Wtk8OdDs9UKJVL3yKxmsGuZ7NoqLyIdy6KPqvks q/w1ZePrMomQ3BJFIYqtjaWmA1UNlFPfbTosXLBxuQ== X-Google-Smtp-Source: ACJfBosJ5Bs637wjBD4OsAG/RW2I2gHqg2DYosF8x69vxEIoz9N4kIbgL+KR4vmE9XIpSl2lVK0BGTh2/WWRpc+qNs4= X-Received: by 10.80.207.143 with SMTP id h15mr28056816edk.189.1513576610093; Sun, 17 Dec 2017 21:56:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.219.73 with HTTP; Sun, 17 Dec 2017 21:56:49 -0800 (PST) In-Reply-To: <20171215170619.8021fb253a15f3e54a356f9a@bidouilliste.com> References: <20171215170619.8021fb253a15f3e54a356f9a@bidouilliste.com> From: =?UTF-8?B?6Zi/6YeR?= Date: Mon, 18 Dec 2017 13:56:49 +0800 Message-ID: Subject: Re: Orange pi one plug network cable after booted , network will not active To: Emmanuel Vadot , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 05:56:53 -0000 in if_awg.c awg_reset function soft reset(EMAC_BASIC_CTL_1) will not be 0 till network cable plug . (EMAC_BASIC_CTL_1 will remain 1 till network cable plug) so this seem orange pi one hardware bug?, could I fix this from software?? (In my test, I watch relative EMAC registers,seem not different when network cable plug in or off) 2017-12-16 0:06 GMT+08:00 Emmanuel Vadot : > On Fri, 15 Dec 2017 16:41:56 +0800 > ?? wrote: > > > Dear all, > > > > I think ,this maybe is the problem of u-boot.dtb?? > > > > scenario1:plug network cable first then power on,kernel had loaded. > > network will work well. > > even if I plug off cable then plug on again .network work well too. > > > > scenario2:network cable not plug till kernel had loaded and prompt login > > message. > > > > booting message=>awg0:soft reset timed out > > > > then I plug network cable ,network will not work. > > ifconfig will not show awg0. > > /etc/netstart will show => ifconfig: interface awg0 does not exist > > > > blow is my u-boot source > > https://github.com/evadot/u-boot/tree/freebsd > > > > export CROSS_COMPILE=arm-none-eabi- > > gmake orangepi_one_defconfig > > gmake menuconfig > > vi .config > > CONFIG_API=y > > gmake > > > > how could I fixed this problem ?? > > thanks all. > > I'll look into it but note that emac (if_awg) isn't in the dts for now > and only will be when we pull the Liunx 4.15 dts (early january). > > -- > Emmanuel Vadot > From owner-freebsd-arm@freebsd.org Mon Dec 18 07:40:29 2017 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 6BAEFEA4479 for ; Mon, 18 Dec 2017 07:40:29 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 027176F618 for ; Mon, 18 Dec 2017 07:40:28 +0000 (UTC) (envelope-from unto.foru13@gmail.com) Received: by mail-wm0-x22d.google.com with SMTP id b199so27392056wme.1 for ; Sun, 17 Dec 2017 23:40:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Lh0CJ3FE4QDC+01HYFyIkZhlEtWXmbKOWPVf4zFFuYI=; b=YqqMa10SBdHJcTayYbaU7j8xzfv/iEhyniV+Vyyrti+hkiJ0+y+OU3TAG4xMKuREUg PpdmvRu6ojurghXh2QJxehuS1tTZ6G9iaHcsEahc9TuJv41ho7o/R7q8npNaGiKF90aj wcVCehNwjLF87GMVTjiC7CdD1uicM9DsOrMryvriPigfqYw5g537vVts/lw9wuTJjI2S SXpW9J4758F5dudrZ63L1+yMe8O5pb/7OFZKqgIGtbYXXpqUCbX6e3V+aVjNaAj+EtNa kTddyhY92poqcl4igfBbpn0THh3kMCI+2MRjADkx1/EpN5+4nV1FrInbiWACeYTBVvWd oPeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=Lh0CJ3FE4QDC+01HYFyIkZhlEtWXmbKOWPVf4zFFuYI=; b=rfURBXwO9/4v3ERP9eduXYWH2iU9EZ+VPganJOevZ9mCpr6Ttjf9kroKXFF8TwZvy+ 2sddBz4eBgtRZsteHtQFQL+QY0tIR+4elthvg5qpo0XUFiFkO5kwXcWFpEmVC7sguCW9 L1TfpanWcaMqPNPUaGb0ma/7aNH+ARXltMHZNlOc3Q3rQQ2QDAEufYI6Srofp5xIWL0t UmJawg+qgnBHv6q6gNRCJvKbJcioE+V/bQuef1w7Osln9jIJEiQ3h5VSbQ5r0YlacQwE +PgkeudQY54v34DhBbwD2QdZYC/GZzJZkiif/DxSHiMKpxTPOFWR9R36q4kO0aUJp7iL ymcw== X-Gm-Message-State: AKGB3mKuOntpfLdKKs7sr+sJ988uHf7NdsALGBp2TqmsisMx+YTpryt1 vw7xi4epFYH8k7WmH25IlrwMAIodt6ER6OKpH8EHVg== X-Google-Smtp-Source: ACJfBos25hIz5flOlIbV5NDho0CoPDCeNgg5tFyMPqUnAfBVLIzbnrTh2dOLhZMgZ/znHhuOooDPKO9lJHVZ4msmuRo= X-Received: by 10.80.140.237 with SMTP id r42mr27932300edr.299.1513582826873; Sun, 17 Dec 2017 23:40:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.219.73 with HTTP; Sun, 17 Dec 2017 23:40:26 -0800 (PST) In-Reply-To: References: <20171215170619.8021fb253a15f3e54a356f9a@bidouilliste.com> From: =?UTF-8?B?6Zi/6YeR?= Date: Mon, 18 Dec 2017 15:40:26 +0800 Message-ID: Subject: Re: Orange pi one plug network cable after booted , network will not active To: Emmanuel Vadot , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 07:40:29 -0000 In /head/sys/arm/allwinner/if_awg.c awg_reset function I comment this line,then when I power on board ,kernel loaded . after that, I plug network cable ,this time I can ping network normally. /* Soft reset all registers and logic */ // WR4(sc, EMAC_BASIC_CTL_1, BASIC_CTL_SOFT_RST); 2017-12-18 13:56 GMT+08:00 =E9=98=BF=E9=87=91 : > > in if_awg.c awg_reset function > soft reset(EMAC_BASIC_CTL_1) will not be 0 till network cable plug . > (EMAC_BASIC_CTL_1 will remain 1 till network cable plug) > > so this seem orange pi one hardware bug?, > could I fix this from software?? > (In my test, I watch relative EMAC registers,seem not different when > network cable plug in or off) > > > > 2017-12-16 0:06 GMT+08:00 Emmanuel Vadot : > >> On Fri, 15 Dec 2017 16:41:56 +0800 >> ?? wrote: >> >> > Dear all, >> > >> > I think ,this maybe is the problem of u-boot.dtb?? >> > >> > scenario1:plug network cable first then power on,kernel had loaded. >> > network will work well. >> > even if I plug off cable then plug on again .network work well too. >> > >> > scenario2:network cable not plug till kernel had loaded and prompt >> login >> > message. >> > >> > booting message=3D>awg0:soft reset timed out >> > >> > then I plug network cable ,network will not work. >> > ifconfig will not show awg0. >> > /etc/netstart will show =3D> ifconfig: interface awg0 does not exist >> > >> > blow is my u-boot source >> > https://github.com/evadot/u-boot/tree/freebsd >> > >> > export CROSS_COMPILE=3Darm-none-eabi- >> > gmake orangepi_one_defconfig >> > gmake menuconfig >> > vi .config >> > CONFIG_API=3Dy >> > gmake >> > >> > how could I fixed this problem ?? >> > thanks all. >> >> I'll look into it but note that emac (if_awg) isn't in the dts for now >> and only will be when we pull the Liunx 4.15 dts (early january). >> >> -- >> Emmanuel Vadot >> > > From owner-freebsd-arm@freebsd.org Mon Dec 18 09:48:38 2017 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 C51AAE82154 for ; Mon, 18 Dec 2017 09:48:38 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ED37372D64; Mon, 18 Dec 2017 09:48:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id adfd434d; Mon, 18 Dec 2017 10:48:28 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=IQ8YCjbawVK8FHyyvq3y6Yz3OhQ=; b=a0CgGRkxM22UNOzZGO/oep0YqIqn pAaW14937JAvzb2+Gn3lRb2nDy/5bJ1ykqDFyDy7X/qYQN8m8qY3BywlSPP/0c08 qOsvDc/uvINTI4DALK+6sBxySqYMfrYj/Vj8/Gef7pWljTCMlw5AnzsOKzNElOP9 EIPrzRocEwpM0ZQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=RQxdDS8zyOCu28uSoimNWPt1/8j1tmf5uOMAzg9stGqR8y9zA4miK8Jt WaJ2LVGXenx7/+C5MIGYaE0ChAHvif5MijLvRIVEvqmNbloAsASDZV91PVYqQTj6 p+B2ocEyNCPwxS5ZD8eVpEMMcRPChjgewkWLbHaoa8g2xOyfXNg= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 1ab6802f TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 18 Dec 2017 10:48:24 +0100 (CET) Date: Mon, 18 Dec 2017 10:48:24 +0100 From: Emmanuel Vadot To: Ian Lepore Cc: Daniel Braniss , freebsd-arm@freebsd.org Subject: Re: ubldr question Message-Id: <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> In-Reply-To: <1513530125.95072.27.camel@freebsd.org> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 18 Dec 2017 09:48:38 -0000 On Sun, 17 Dec 2017 10:02:05 -0700 Ian Lepore wrote: > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > Hi, > > in the past there was CONFIG.TXT and/or UENV.TXT where I could > > override the > > default .dtb file set by uboot, but now it seems these files are > > either not read, or the > > command has changed. > >=20 > > So, apart from stoping the loader, and typing ?env set fdtfile > > xxx.dtb? > > is there another way? > >=20 > > cheers, > > danny > >=20 >=20 > You should be able to "saveenv" after making your change. >=20 > The uEnv.txt that used to be supported was to make it possible to > programatically change the boot behavior from freebsd userland. =A0That > feature got lost when the uboot ports were all rewritten to use a > default environment (boot scripts and all) for freebsd that is > basically identical to what linux uses. =A0It's a lot less work for the > port maintainers, but we lost some functionality along the way. >=20 > -- Ian We currently use the default for the boards for the env, the default value for most of the board is to put the env in the mmc (in the space reserved for u-boot) and not in the fat. There is some discussion to move the env in the fat by default for allwinner boards as u-boot is getting too big now. One of the reason I didn't put back ENV_IS_IN_FAT is that our u-boot port is currently lacking of a proper way to customize the defconfigs (I'm currently working on this part) and I don't want to have too many patches (one for each board/soc). As of functionality, I'm not sure we lost something, one can still create a u-boot script (u-boot.scr) and do everything he needs for a custom boot. (Also setenv/saveenv works as Ian said). --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Dec 18 15:38:12 2017 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 8ADF4E94307 for ; Mon, 18 Dec 2017 15:38:12 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6E3517FF93 for ; Mon, 18 Dec 2017 15:38:12 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6fbac198-e409-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 6fbac198-e409-11e7-8486-0934409070aa; Mon, 18 Dec 2017 15:38:04 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBIFc9l4001296; Mon, 18 Dec 2017 08:38:09 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513611489.95072.45.camel@freebsd.org> Subject: Re: ubldr question From: Ian Lepore To: Emmanuel Vadot Cc: Daniel Braniss , freebsd-arm@freebsd.org Date: Mon, 18 Dec 2017 08:38:09 -0700 In-Reply-To: <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Mon, 18 Dec 2017 15:38:12 -0000 On Mon, 2017-12-18 at 10:48 +0100, Emmanuel Vadot wrote: > On Sun, 17 Dec 2017 10:02:05 -0700 > Ian Lepore wrote: > > > > > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > > > > > Hi, > > > in the past there was CONFIG.TXT and/or UENV.TXT where I could > > > override the > > > default .dtb file set by uboot, but now it seems these files are > > > either not read, or the > > > command has changed. > > > > > > So, apart from stoping the loader, and typing ?env set fdtfile > > > xxx.dtb? > > > is there another way? > > > > > > cheers, > > > danny > > > > > You should be able to "saveenv" after making your change. > > > > The uEnv.txt that used to be supported was to make it possible to > > programatically change the boot behavior from freebsd userland.  That > > feature got lost when the uboot ports were all rewritten to use a > > default environment (boot scripts and all) for freebsd that is > > basically identical to what linux uses.  It's a lot less work for the > > port maintainers, but we lost some functionality along the way. > > > > -- Ian >  We currently use the default for the boards for the env, the default > value for most of the board is to put the env in the mmc (in the space > reserved for u-boot) and not in the fat. There is some discussion to > move the env in the fat by default for allwinner boards as u-boot is > getting too big now. >  One of the reason I didn't put back ENV_IS_IN_FAT is that our u-boot > port is currently lacking of a proper way to customize the defconfigs > (I'm currently working on this part) and I don't want to have too many > patches (one for each board/soc). >  As of functionality, I'm not sure we lost something, one can still > create a u-boot script (u-boot.scr) and do everything he needs for a > custom boot. (Also setenv/saveenv works as Ian said). > The uEnv.txt file never had anything to do with ENV_IS_IN_FAT or anything else related uboot's builtin features for saving/loading the environment.  It was something we added as part of freebsd boot support, to provide a way for userland software to control the boot process without knowing anything about how uboot stores its env (which can be completely inaccessible to running freebsd apps in some cases). It was there specifically to support pingpong update schemes where updates are applied to an inactive slice/partition/device, then some persistant data is written that switches which slice/part/dev is used for the next boot.  On some systems, especially if loader(8) is in use, that can be controlled through the MBR or GPT.  On other systems, those things may not be an option, and uEnv.txt was the always-available mechanism. So yeah, we definitely lost something.  It wasn't well-documented, and from the lack of complaints up until now, I guess it wasn't something that was widely used.  But it's just one of several important (IMO) features of the old uboot ports that we lost.  The other major loss was some standard env script vars that made it easy for a user to hook into the boot process and customize it using just a 'setenv' command.  "Write your own boot.scr" is nowhere near an adequate replacement for the lost functionality of being able to set a variable or two in plain text. -- Ian From owner-freebsd-arm@freebsd.org Mon Dec 18 16:25:11 2017 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 DF3CAE97FF0 for ; Mon, 18 Dec 2017 16:25:11 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id B769A2474 for ; Mon, 18 Dec 2017 16:25:11 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id AA9CC2734B for ; Mon, 18 Dec 2017 11:24:35 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id C216113E9BA for ; Mon, 18 Dec 2017 10:24:33 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: RPI2 boot failure with recent changes to u-boot Message-ID: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> Date: Mon, 18 Dec 2017 10:24:33 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms050104090800010703030603" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 16:25:12 -0000 This is a cryptographically signed message in MIME format. --------------ms050104090800010703030603 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I recently upgraded my "u-boot" package for RPI2 to the current version (and grabbed the "rpi-firmware" package it said it needed) and now I have no-start on the RPI2.... U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) DRAM:=C2=A0 948 MiB RPI 2 Model B (0xa21041) MMC:=C2=A0=C2=A0 sdhci@7e300000: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In:=C2=A0=C2=A0=C2=A0 serial Out:=C2=A0=C2=A0 vidconsole Err:=C2=A0=C2=A0 vidconsole Net:=C2=A0=C2=A0 No ethernet found. starting USB... USB0:=C2=A0=C2=A0 Core Release: 2.80a scanning bus 0 for devices... 3 USB Device(s) found =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scanning usb for storage devices... = 0 Storage Device(s) found Hit any key to stop autoboot:=C2=A0 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 227704 bytes read in 34 ms (6.4 MiB/s) ## Starting application at 0x01000000 ... And that be all I get. This is what I have in board/RaspberryPi2/setup.sh related to that (which I had to change since the firmware files have been split between the two packages) raspberry_pi_populate_boot_partition ( ) { =C2=A0=C2=A0=C2=A0 # Copy RaspberryPi 2 boot files to FAT partition =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/LICENCE.broadcom . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/bootcode.bin . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/config.txt . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup.dat . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup_cd.dat . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup_x.dat . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start.elf . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start_cd.elf . =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start_x.elf . =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/u-boot.bin . =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/fixup_db.dat . =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/start_db.elf . =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/README . =C2=A0=C2=A0=C2=A0 # RPi firmware loads and modify the DTB before pass it= to kernel. =C2=A0=C2=A0=C2=A0 freebsd_install_fdt rpi2.dts rpi2.dtb =C2=A0=C2=A0=C2=A0 # Install ubldr to FAT partition =C2=A0=C2=A0=C2=A0 freebsd_ubldr_copy_ubldr . } Any ideas on tracking this down? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms050104090800010703030603 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjE4MTYyNDMz WjBPBgkqhkiG9w0BCQQxQgRAFb0Wk6824ytf1j9dFrK0XBn5HAoE5GjqbakgD0CwmGFJ5Fwc iyoiztAhmsTU5hcGOp4j5pHH3Cud/dEoZ1APOjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBvkg/RlHabTPxT48wGsG6J62ipT56NXYSiRlmFdC161LkmV6ONO6mp+IdF4R7NK5d+ ZRAO/pl6oA7ZoHBFJr39jHDbf7YZiRbQe+/LVenCFvaSxlj50UGKkuuF3eIeWj3EuH6SNJR+ LSdziYc0hyPtME/2sVh40jXUjR8q2kIluVAAfCTYo+2n+XhFTPQfYEX73e1qK2WGiVVSKZFi GdsB3l0mIEi207C4xAYjxkIrigehqkVQ+E8Y/+rwwHoH7TqPy6iIv8W4QEq6AJG0ItoHs6lA EAxoXlPq7cW6R5u6SrBlB3O30mP1xQrWj5Z0uzezyeNTUKvnFiybZ7k6E0pzFSY27mH7RmUa 30v0hYFrMs9HxqPPaWKE67wDsevgZ1B9pWdK2JysJpyHK/5CkRmbn2Sx3humMcq/4M+xnUlc LjLC0rpgAMfkgAxr/NDSgTuTgOb3i1arQtXj5r3GhRgrQtxKZ95+C+NmLvPhXNFwrRDaIST7 smwngxvnWRZcQqiWyCET83b2E3eycY1gMpYBjT+e0LmhFjxb6Xae2LXHPc5Nd9XzFo92SpV5 6bnQqPuSpWkJMKbGb2L6ipav9UdlDIrv9AAxzGyIzWifkDmampeEfyeaNCTHDZ4G4BmgvQhZ 7SSIChxVZXPgxZ5qBsGdEvLg5yfkqNB7mq+Y36WcCQAAAAAAAA== --------------ms050104090800010703030603-- From owner-freebsd-arm@freebsd.org Mon Dec 18 16:33:04 2017 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 62360E98B1E for ; Mon, 18 Dec 2017 16:33:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 000552BA2 for ; Mon, 18 Dec 2017 16:33:03 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f2b28da0-e410-11e7-8dac-d32f5c2d02ef X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id f2b28da0-e410-11e7-8dac-d32f5c2d02ef; Mon, 18 Dec 2017 16:31:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBIGVn35001379; Mon, 18 Dec 2017 09:31:49 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513614709.95072.48.camel@freebsd.org> Subject: Re: RPI2 boot failure with recent changes to u-boot From: Ian Lepore To: Karl Denninger , "freebsd-arm@freebsd.org" Date: Mon, 18 Dec 2017 09:31:49 -0700 In-Reply-To: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Mon, 18 Dec 2017 16:33:04 -0000 On Mon, 2017-12-18 at 10:24 -0600, Karl Denninger wrote: > I recently upgraded my "u-boot" package for RPI2 to the current > version > (and grabbed the "rpi-firmware" package it said it needed) and now I > have no-start on the RPI2.... > > U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) > > DRAM:  948 MiB > RPI 2 Model B (0xa21041) > MMC:   sdhci@7e300000: 0 > reading uboot.env > > ** Unable to read "uboot.env" from mmc0:1 ** > Using default environment > > In:    serial > Out:   vidconsole > Err:   vidconsole > Net:   No ethernet found. > starting USB... > USB0:   Core Release: 2.80a > scanning bus 0 for devices... 3 USB Device(s) found >        scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot:  0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 227704 bytes read in 34 ms (6.4 MiB/s) > ## Starting application at 0x01000000 ... > > And that be all I get. > > This is what I have in board/RaspberryPi2/setup.sh related to that > (which I had to change since the firmware files have been split > between > the two packages) > > raspberry_pi_populate_boot_partition ( ) { >     # Copy RaspberryPi 2 boot files to FAT partition >     cp ${FIRMWARE_PATH}/LICENCE.broadcom . >     cp ${FIRMWARE_PATH}/bootcode.bin . >     cp ${FIRMWARE_PATH}/config.txt . >     cp ${FIRMWARE_PATH}/fixup.dat . >     cp ${FIRMWARE_PATH}/fixup_cd.dat . >     cp ${FIRMWARE_PATH}/fixup_x.dat . >     cp ${FIRMWARE_PATH}/start.elf . >     cp ${FIRMWARE_PATH}/start_cd.elf . >     cp ${FIRMWARE_PATH}/start_x.elf . >     cp ${UBOOT_PATH}/u-boot.bin . >     cp ${UBOOT_PATH}/fixup_db.dat . >     cp ${UBOOT_PATH}/start_db.elf . >     cp ${UBOOT_PATH}/README . > >     # RPi firmware loads and modify the DTB before pass it to kernel. >     freebsd_install_fdt rpi2.dts rpi2.dtb > >     # Install ubldr to FAT partition >     freebsd_ubldr_copy_ubldr . > } > > Any ideas on tracking this down? > How recent is your ubldr.bin?  About a week ago in r326752 I committed the patches from PR 224008, which affects the startup code for ubldr.bin, so it could possibly be a fix for the problem you're seeing. (I don't have an rpi2 to test so I can't say for sure.) -- Ian From owner-freebsd-arm@freebsd.org Mon Dec 18 16:34:13 2017 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 2317EE98CB2 for ; Mon, 18 Dec 2017 16:34:13 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pl0-x22e.google.com (mail-pl0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E384E2D59; Mon, 18 Dec 2017 16:34:12 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pl0-x22e.google.com with SMTP id i6so5124597plt.13; Mon, 18 Dec 2017 08:34:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=QaJL49Gcod7Fy3DayJkFCqaCsPROVJqbURFTTlvC7f8=; b=hQT0lgXCVKxMPLSY+/ErmxOhwTtAa+2dDhNiNCRszYPImQSkKPWcJO2Y56kkhdgQRl BB2jCEsPI3NwPKQJGCSxkfvCzfmW57Ko8+zPbQhtUej7xd7Jwcdk2sVTaE1eOAtKYMaS rCAIOtmozBaPKVXIR2E4Hrlk8awrjxB7PEfBJSUau92AYoDUakByLj1NN5XCP/Lev3CB o+2qmOgJZcnyzpGOa+BHyr9/opVD23CghtxztBAN+AmdEbN7QFQVrBQ6fDCOLbDUtma9 GChwoHd5+Sh35f6UmGarOSs3SQvJs+Wu5slrj5zZtpJ3gHzcCmv4NbHhM6nNBmgU/2WO CbVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=QaJL49Gcod7Fy3DayJkFCqaCsPROVJqbURFTTlvC7f8=; b=t04+s4LUKcfMysabj7uU1uV4PHV13F6cxmK1xrVmE3n/vKz2PKzSLsfAb0+l9g1EJV nW5vjVHa4Yds7pZSaQb7c3My1zUmBG9pDkN+WyTc/B/h0QYMHIx6d6SeSMWZhS4C6urp wdIWeA2ZfKSGQku54ACYYIcl3SjZwQg2/inex+BBDgR9rMnlWHqYgvhB0fEEGYuaa18u q3lhHCUyQG/GHwKXn/vSL4NoR3DUAGrOeaSloTzSzvqwImFSHNRCAJi0pw4GZQa4Yh/w iTbp2LUSGBiiqqCveNcQohdk/NioYTj5olKTA/K12UnOTjKs/bEbMshLr3G0dafpCiq+ OyPA== X-Gm-Message-State: AKGB3mKu7nj/KqW2lojPOXOTVkNse5UMd2J+6breTY6AhlNCOGokABp+ PwQ0ABtyhHcmDXSZi9C2/WVqTe1f X-Google-Smtp-Source: ACJfBotI9neb3d/lHQ2LuzZg9oOULRCFp3hHfKX9xMdljXXbk536o55fcCBf4OBLp1fl/wP86oLpuQ== X-Received: by 10.84.197.3 with SMTP id m3mr297698pld.264.1513614852270; Mon, 18 Dec 2017 08:34:12 -0800 (PST) Received: from [127.0.0.1] ([184.151.231.133]) by smtp.gmail.com with ESMTPSA id p19sm29512133pfj.140.2017.12.18.08.34.09 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 18 Dec 2017 08:34:10 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.3.2163) Message-ID: <20171218163409.6914130.29031.36691@gmail.com> Date: Mon, 18 Dec 2017 08:34:09 -0800 Subject: Re: ubldr question From: Russell Haley In-Reply-To: <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> To: Emmanuel Vadot , Ian Lepore Cc: freebsd-arm@freebsd.org 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: Mon, 18 Dec 2017 16:34:13 -0000 Sorry for the top post. So it's just a matter of updating the define/variable noted below=E2=80=8E = to restore that functionality on previously supported platforms? Russ Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Virgin=C2=A0Mobile=C2=A0network. =C2=A0 Original Message =C2=A0 From: Emmanuel Vadot Sent: Monday, December 18, 2017 1:48 AM To: Ian Lepore Cc: freebsd-arm@freebsd.org Subject: Re: ubldr question On Sun, 17 Dec 2017 10:02:05 -0700 Ian Lepore wrote: > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > Hi, > > in the past there was CONFIG.TXT and/or UENV.TXT where I could > > override the > > default .dtb file set by uboot, but now it seems these files are > > either not read, or the > > command has changed. > >=20 > > So, apart from stoping the loader, and typing ?env set fdtfile > > xxx.dtb? > > is there another way? > >=20 > > cheers, > > danny > >=20 >=20 > You should be able to "saveenv" after making your change. >=20 > The uEnv.txt that used to be supported was to make it possible to > programatically change the boot behavior from freebsd userland. =C2=A0That > feature got lost when the uboot ports were all rewritten to use a > default environment (boot scripts and all) for freebsd that is > basically identical to what linux uses. =C2=A0It's a lot less work for the > port maintainers, but we lost some functionality along the way. >=20 > -- Ian We currently use the default for the boards for the env, the default value for most of the board is to put the env in the mmc (in the space reserved for u-boot) and not in the fat. There is some discussion to move the env in the fat by default for allwinner boards as u-boot is getting too big now. One of the reason I didn't put back ENV_IS_IN_FAT is that our u-boot port is currently lacking of a proper way to customize the defconfigs (I'm currently working on this part) and I don't want to have too many patches (one for each board/soc). As of functionality, I'm not sure we lost something, one can still create a u-boot script (u-boot.scr) and do everything he needs for a custom boot. (Also setenv/saveenv works as Ian said). --=20 Emmanuel Vadot _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Dec 18 16:41:21 2017 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 12F67E99594 for ; Mon, 18 Dec 2017 16:41:21 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EA46235B2 for ; Mon, 18 Dec 2017 16:41:20 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 3ee3b3c1-e412-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 3ee3b3c1-e412-11e7-93a5-cd02e7dc7692; Mon, 18 Dec 2017 16:41:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBIGfHEo001418; Mon, 18 Dec 2017 09:41:17 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513615277.95072.50.camel@freebsd.org> Subject: Re: ubldr question From: Ian Lepore To: Russell Haley , Emmanuel Vadot Cc: freebsd-arm@freebsd.org Date: Mon, 18 Dec 2017 09:41:17 -0700 In-Reply-To: <20171218163409.6914130.29031.36691@gmail.com> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> <20171218163409.6914130.29031.36691@gmail.com> Content-Type: text/plain; charset="euc-jp" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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: Mon, 18 Dec 2017 16:41:21 -0000 On Mon, 2017-12-18 at 08:34 -0800, Russell Haley wrote: > Sorry for the top post. > > So it's just a matter of updating the define/variable noted below to > restore that functionality on previously supported platforms? > > Russ > Yes, just do: setenv fdtfile yourfilename.dtb saveenv -- Ian > SentfrommyBlackBerry10smartphoneontheVirginMobilenetwork. > Original Message > From: Emmanuel Vadot > Sent: Monday, December 18, 2017 1:48 AM > To: Ian Lepore > Cc: freebsd-arm@freebsd.org > Subject: Re: ubldr question > > On Sun, 17 Dec 2017 10:02:05 -0700 > Ian Lepore wrote: > > > > > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > > > > > Hi, > > > in the past there was CONFIG.TXT and/or UENV.TXT where I could > > > override the > > > default .dtb file set by uboot, but now it seems these files are > > > either not read, or the > > > command has changed. > > > > > > So, apart from stoping the loader, and typing ?env set fdtfile > > > xxx.dtb? > > > is there another way? > > > > > > cheers, > > > danny > > > > > You should be able to "saveenv" after making your change. > > > > The uEnv.txt that used to be supported was to make it possible to > > programatically change the boot behavior from freebsd userland. > > That > > feature got lost when the uboot ports were all rewritten to use a > > default environment (boot scripts and all) for freebsd that is > > basically identical to what linux uses. It's a lot less work for > > the > > port maintainers, but we lost some functionality along the way. > > > > -- Ian > We currently use the default for the boards for the env, the default > value for most of the board is to put the env in the mmc (in the > space > reserved for u-boot) and not in the fat. There is some discussion to > move the env in the fat by default for allwinner boards as u-boot is > getting too big now. > One of the reason I didn't put back ENV_IS_IN_FAT is that our u-boot > port is currently lacking of a proper way to customize the defconfigs > (I'm currently working on this part) and I don't want to have too > many > patches (one for each board/soc). > As of functionality, I'm not sure we lost something, one can still > create a u-boot script (u-boot.scr) and do everything he needs for a > custom boot. (Also setenv/saveenv works as Ian said). > From owner-freebsd-arm@freebsd.org Mon Dec 18 16:49:27 2017 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 18328E9A1EF for ; Mon, 18 Dec 2017 16:49:27 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5923C3E4E; Mon, 18 Dec 2017 16:49:25 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 670948e9; Mon, 18 Dec 2017 17:49:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=0v88XkanwUgLBod68oMy9BvhtoA=; b=q9Ja2qu1duEuKT57mpvsWp8sOTQa jbeTwWW07cOqIQVP+B6pRUWatD6efezromOK83ECKV9ghxsnZP84te57EDiqV1xm zGcVrkRudUNxsAFhoqvN6sS3Z7nq/cyQCBaoo3UYHG9t2MZjn5gCB2FtxrBAXogx lJwVgw7KpkYDQf8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=mDMK88SUXOHGob1IhSZcdEQEYICZdfKCnhMjV1zlklqMW6okdpw+uNpW xkvEkVPZ4f3mLpkbEEjC6xlDv/tmGIwPS20FQKnEtWctRy2vPibpO73uUtigAexr zvRf3hwxW0/VkX0ApGhvbzYsyq4S8NWoOL777RU/u7xmGvZmf8M= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 97f32969 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 18 Dec 2017 17:49:23 +0100 (CET) Date: Mon, 18 Dec 2017 17:49:18 +0100 From: Emmanuel Vadot To: Ian Lepore Cc: Daniel Braniss , freebsd-arm@freebsd.org Subject: Re: ubldr question Message-Id: <20171218174918.c6aa89984174ce41d500b5b7@bidouilliste.com> In-Reply-To: <1513611489.95072.45.camel@freebsd.org> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> <1513611489.95072.45.camel@freebsd.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 18 Dec 2017 16:49:27 -0000 On Mon, 18 Dec 2017 08:38:09 -0700 Ian Lepore wrote: > On Mon, 2017-12-18 at 10:48 +0100, Emmanuel Vadot wrote: > > On Sun, 17 Dec 2017 10:02:05 -0700 > > Ian Lepore wrote: > >=20 > > >=20 > > > On Sun, 2017-12-17 at 17:03 +0200, Daniel Braniss wrote: > > > >=20 > > > > Hi, > > > > in the past there was CONFIG.TXT and/or UENV.TXT where I could > > > > override the > > > > default .dtb file set by uboot, but now it seems these files are > > > > either not read, or the > > > > command has changed. > > > >=20 > > > > So, apart from stoping the loader, and typing ?env set fdtfile > > > > xxx.dtb? > > > > is there another way? > > > >=20 > > > > cheers, > > > > danny > > > >=20 > > > You should be able to "saveenv" after making your change. > > >=20 > > > The uEnv.txt that used to be supported was to make it possible to > > > programatically change the boot behavior from freebsd userland. =A0Th= at > > > feature got lost when the uboot ports were all rewritten to use a > > > default environment (boot scripts and all) for freebsd that is > > > basically identical to what linux uses. =A0It's a lot less work for t= he > > > port maintainers, but we lost some functionality along the way. > > >=20 > > > -- Ian > > =A0We currently use the default for the boards for the env, the default > > value for most of the board is to put the env in the mmc (in the space > > reserved for u-boot) and not in the fat. There is some discussion to > > move the env in the fat by default for allwinner boards as u-boot is > > getting too big now. > > =A0One of the reason I didn't put back ENV_IS_IN_FAT is that our u-boot > > port is currently lacking of a proper way to customize the defconfigs > > (I'm currently working on this part) and I don't want to have too many > > patches (one for each board/soc). > > =A0As of functionality, I'm not sure we lost something, one can still > > create a u-boot script (u-boot.scr) and do everything he needs for a > > custom boot. (Also setenv/saveenv works as Ian said). > >=20 >=20 > The uEnv.txt file never had anything to do with=A0ENV_IS_IN_FAT or > anything else related uboot's builtin features for saving/loading the > environment. =A0It was something we added as part of freebsd boot > support, to provide a way for userland software to control the boot > process without knowing anything about how uboot stores its env (which > can be completely inaccessible to running freebsd apps in some cases). Yes sorry, I always (don't know why, maybe the name ...) mix up thoses two. > It was there specifically to support pingpong update schemes where > updates are applied to an inactive slice/partition/device, then some > persistant data is written that switches which slice/part/dev is used > for the next boot. =A0On some systems, especially if loader(8) is in use, > that can be controlled through the MBR or GPT. =A0On other systems, those > things may not be an option, and uEnv.txt was the always-available > mechanism. >=20 > So yeah, we definitely lost something. =A0It wasn't well-documented, and > from the lack of complaints up until now, I guess it wasn't something > that was widely used. =A0But it's just one of several important (IMO) > features of the old uboot ports that we lost. =A0The other major loss was > some standard env script vars that made it easy for a user to hook into > the boot process and customize it using just a 'setenv' command. > =A0"Write your own boot.scr" is nowhere near an adequate replacement for > the lost functionality of being able to set a variable or two in plain > text. >=20 > -- Ian I agree that we lost something then, I'll see what I can do. As you said it was done for pingpong support, which release image do not provide, I try to provide something that work for 99% of the users (which either download a snapshot/release or build their own with crochet or similar tool. I expect users that want something better/different as what we provide in the image to be able to come up with a solution that fix their needs. As a general rule for u-boot : we have almost catched upstream and all the modification should go there (but we can cherry-pick commits for our ports). Also I'm currently looking at what to do for loading ubldr.bin, the u-boot guys told me to use scripts (u-boot.scr) but they will be deprecated in the near future and u-boot will only use EFI or syslinux.conf, I'll start a thread soon on uboot@freebsd with my finding and the pro/con of using each solution. Cheers, --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Dec 18 16:51:29 2017 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 7B43FE9A587 for ; Mon, 18 Dec 2017 16:51:29 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C53E73FD3; Mon, 18 Dec 2017 16:51:28 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id b1fa8b34; Mon, 18 Dec 2017 17:51:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=ZZym/OAjl4cPxN4y9Q5T2TvzntA=; b=ZEFs2WxQK1cB2ZpTOt50OutRTIVJ BxYCuq1jLfZ2J4x589s86v3i1gxpogwbgTNs8aRALwkHlvMSZMFmExwjtjF4wMw0 MyCJpYDxk5lc7w/BhvSV8+nq3SbckSMk/WxVqp2j4h17je8U49QTu1kbrpJ9cvW3 VpyhkuwevkZb87w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=kmt4mjqKpUpL8wMBFdAcyxfYPWQqlWbXFuu3Jp/AsMs1bJevd+CkbzhV sAfP9eJXAwXhChhwhKQdsHwavZocIaysa+A3ywu9aD5BFLtmPA2TCr4x2ptCExfC jn6ni91K5gnq2nfor3siwAz/h1bjyjzCWixSpkFGcaEYNzqKtgc= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8954183b TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 18 Dec 2017 17:51:26 +0100 (CET) Date: Mon, 18 Dec 2017 17:51:26 +0100 From: Emmanuel Vadot To: Russell Haley Cc: freebsd-arm@freebsd.org, Ian Lepore Subject: Re: ubldr question Message-Id: <20171218175126.328b883b0d010ba83ae7032e@bidouilliste.com> In-Reply-To: <1513615277.95072.50.camel@freebsd.org> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> <20171218163409.6914130.29031.36691@gmail.com> <1513615277.95072.50.camel@freebsd.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Mon, 18 Dec 2017 16:51:29 -0000 On Mon, 18 Dec 2017 09:41:17 -0700 Ian Lepore wrote: > On Mon, 2017-12-18 at 08:34 -0800, Russell Haley wrote: > > Sorry for the top post. > > > > So it's just a matter of updating the define/variable noted below to > > restore that functionality on previously supported platforms? > > > > Russ > > > > Yes, just do: > > setenv fdtfile yourfilename.dtb > saveenv > > -- Ian I'm curious for what board you need this ? Do you have some custom dtb and don't want to load the default one ? The only port that I know which aren't setting fdtfile is for the pandaboard, it's the same in u-boot mainline I need to see why it isn't set and if it's intentional or not (pandaboard is more or less dead). -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Dec 18 17:11:06 2017 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 48849E9C1AC for ; Mon, 18 Dec 2017 17:11:06 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02B82643ED; Mon, 18 Dec 2017 17:11:05 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bk.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1eQywG-000Ld8-PH; Mon, 18 Dec 2017 19:10:52 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: ubldr question From: Daniel Braniss In-Reply-To: <20171218175126.328b883b0d010ba83ae7032e@bidouilliste.com> Date: Mon, 18 Dec 2017 19:10:52 +0200 Cc: Russell Haley , freebsd-arm@freebsd.org, Ian Lepore Content-Transfer-Encoding: quoted-printable Message-Id: <29119CFF-D3C9-451C-9DEE-55320B88DC8E@cs.huji.ac.il> References: <0844C635-7FA6-4684-92F5-4C1AAC8EFB95@cs.huji.ac.il> <1513530125.95072.27.camel@freebsd.org> <20171218104824.a4e656687a9121aa256b094c@bidouilliste.com> <20171218163409.6914130.29031.36691@gmail.com> <1513615277.95072.50.camel@freebsd.org> <20171218175126.328b883b0d010ba83ae7032e@bidouilliste.com> To: Emmanuel Vadot X-Mailer: Apple Mail (2.3445.4.7) 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: Mon, 18 Dec 2017 17:11:06 -0000 > On 18 Dec 2017, at 18:51, Emmanuel Vadot = wrote: >=20 > On Mon, 18 Dec 2017 09:41:17 -0700 > Ian Lepore wrote: >=20 >> On Mon, 2017-12-18 at 08:34 -0800, Russell Haley wrote: >>> Sorry for the top post. >>>=20 >>> So it's just a matter of updating the define/variable noted below to >>> restore that functionality on previously supported platforms? >>>=20 >>> Russ >>>=20 >>=20 >> Yes, just do: >>=20 >> setenv fdtfile yourfilename.dtb >> saveenv >>=20 >> -- Ian >=20 > I'm curious for what board you need this ? Do you have some custom dtb > and don't want to load the default one ? allwinners, zero, one, pc and neopi-nano. and so far i have enabled uart1, so yes, you can say it=E2=80=99s a = custom dtb. next, I want to mark some gpios that I use too. I like to keep the origin just in case I screw up, all this is while developing, it=E2=80=99s a PITA every time I boot one of them,=20 and since the awg is not working, I have to write to the sd card on another host. I tried saveenv before but didn=E2=80=99t see any new file, so i guessed = - wrongly- that nothing was happening. having some file has the nice property that ed then reboot, instead of hitting enter at the right time :-) > The only port that I know which aren't setting fdtfile is for the > pandaboard, it's the same in u-boot mainline I need to see why it = isn't > set and if it's intentional or not (pandaboard is more or less dead). >=20 > --=20 > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Dec 18 17:25:06 2017 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 5C2E6E9D744 for ; Mon, 18 Dec 2017 17:25:06 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 4A8CE659A4 for ; Mon, 18 Dec 2017 17:25:03 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id A5A2127335 for ; Mon, 18 Dec 2017 12:25:03 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id D3E1013F2B7 for ; Mon, 18 Dec 2017 11:25:01 -0600 (CST) Subject: Re: RPI2 boot failure with recent changes to u-boot To: "freebsd-arm@freebsd.org" References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> <1513614709.95072.48.camel@freebsd.org> From: Karl Denninger Message-ID: <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> Date: Mon, 18 Dec 2017 11:25:01 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1513614709.95072.48.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms070709050903080402090304" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 17:25:06 -0000 This is a cryptographically signed message in MIME format. --------------ms070709050903080402090304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/18/2017 10:31, Ian Lepore wrote: > On Mon, 2017-12-18 at 10:24 -0600, Karl Denninger wrote: >> I recently upgraded my "u-boot" package for RPI2 to the current >> version >> (and grabbed the "rpi-firmware" package it said it needed) and now I >> have no-start on the RPI2.... >> >> U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) >> >> DRAM:=C2=A0 948 MiB >> RPI 2 Model B (0xa21041) >> MMC:=C2=A0=C2=A0 sdhci@7e300000: 0 >> reading uboot.env >> >> ** Unable to read "uboot.env" from mmc0:1 ** >> Using default environment >> >> In:=C2=A0=C2=A0=C2=A0 serial >> Out:=C2=A0=C2=A0 vidconsole >> Err:=C2=A0=C2=A0 vidconsole >> Net:=C2=A0=C2=A0 No ethernet found. >> starting USB... >> USB0:=C2=A0=C2=A0 Core Release: 2.80a >> scanning bus 0 for devices... 3 USB Device(s) found >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scanning usb for storage devices.= =2E. 0 Storage Device(s) found >> Hit any key to stop autoboot:=C2=A0 0 >> switch to partitions #0, OK >> mmc0 is current device >> Scanning mmc 0:1... >> Found FreeBSD U-Boot Loader (bin) >> reading ubldr.bin >> 227704 bytes read in 34 ms (6.4 MiB/s) >> ## Starting application at 0x01000000 ... >> >> And that be all I get. >> >> This is what I have in board/RaspberryPi2/setup.sh related to that >> (which I had to change since the firmware files have been split >> between >> the two packages) >> >> raspberry_pi_populate_boot_partition ( ) { >> =C2=A0=C2=A0=C2=A0 # Copy RaspberryPi 2 boot files to FAT partition >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/LICENCE.broadcom . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/bootcode.bin . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/config.txt . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup.dat . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup_cd.dat . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup_x.dat . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start.elf . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start_cd.elf . >> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start_x.elf . >> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/u-boot.bin . >> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/fixup_db.dat . >> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/start_db.elf . >> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/README . >> >> =C2=A0=C2=A0=C2=A0 # RPi firmware loads and modify the DTB before pass= it to kernel. >> =C2=A0=C2=A0=C2=A0 freebsd_install_fdt rpi2.dts rpi2.dtb >> >> =C2=A0=C2=A0=C2=A0 # Install ubldr to FAT partition >> =C2=A0=C2=A0=C2=A0 freebsd_ubldr_copy_ubldr . >> } >> >> Any ideas on tracking this down? >> > How recent is your ubldr.bin? =C2=A0About a week ago in r326752 I commi= tted > the patches from PR 224008, which affects the startup code for > ubldr.bin, so it could possibly be a fix for the problem you're seeing.= > > (I don't have an rpi2 to test so I can't say for sure.) > > -- Ian I updated the 11.x source tree I use to build this and now I get further..... U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) DRAM:=C2=A0 948 MiB RPI 2 Model B (0xa21041) MMC:=C2=A0=C2=A0 sdhci@7e300000: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In:=C2=A0=C2=A0=C2=A0 serial Out:=C2=A0=C2=A0 vidconsole Err:=C2=A0=C2=A0 vidconsole Net:=C2=A0=C2=A0 No ethernet found. starting USB... USB0:=C2=A0=C2=A0 Core Release: 2.80a scanning bus 0 for devices... 3 USB Device(s) found =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scanning usb for storage devices... = 0 Storage Device(s) found Hit any key to stop autoboot:=C2=A0 0 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found FreeBSD U-Boot Loader (bin) reading ubldr.bin 235040 bytes read in 33 ms (6.8 MiB/s) ## Starting application at 0x01000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0x3af5d988 FreeBSD/armv6 U-Boot loader, Revision 1.2 (Mon Dec 18 11:14:37 CST 2017 freebsd@NewFS.denninger.net) DRAM: 948MB Number of U-Boot devices: 1 U-Boot env: loaderdev not set, will probe all devices. Found U-Boot device: disk =C2=A0 Probing all disk devices... =C2=A0 Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: /boot/kernel/kernel text=3D0x617118 data=3D0x54300+0x17fbc0 syms=3D[0x4+0x67d30+0x4+0x9480c] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! Type '?' for a list of commands, 'help' for more detailed help. loader> Am=C2=A0 I missing a line in config.txt that needs to be there or did something else odd happen that the dtb is missing? --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070709050903080402090304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjE4MTcyNTAx WjBPBgkqhkiG9w0BCQQxQgRAAFPLl3t2iS/PIYxM53w0blnoyyk+8K36mylVdoWTu6QaWh8g im8aMkIyNwUh/TPn2UrGJmpZeEgNcuF3jdr1hTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgAo/jPWf1HRMFV/68kc8XlmADfVFRg5lfwW32RYAHXJ7rQIgiIMMvousaMr05FOjE/e e+kgKtzeaAYXc3Kz1WHVLAhA5PlveKKckL8ynsOFhuIWad2tmIY8RYtq4V9NcrLPsi/8NoVI ecI+7fjnkuzoimmT0T+K8gqCTA1GwNYgf++quF3NlOGFN8CG2I1B4lcfvs491reW6Lt0Zx5n IpIT3SWgcZ7IkSrUXeiu9YmShzDBUBgDdJzrNbxBIgkb2HdA6GbGMIReQCGx6BxHQ6Lr9nj4 VIzJ3AzJlqRdDkLF4lUmCgak1rx9blZMiruHSsgk8m2UTWsXT5JBRpmywC1bDJ9lg3/rpL8u 5ofP2jFSsl6rh6rz3pTiaacevSl1w0t/XrFsQcHdFCsYsMs4EO3VmPbR0AKQ1LKqYPsQE7xx MnOspSl+jy4dBcVAp9Kndg/1taE6EPxx1LTpmceEkkLQ29rWPAcNixPlcczPrZUVRdKWbcNz Z0eH5UknYuqPZcSDfh8BmMm3xdnJ+XD4UZU6VzDmALSf9hwQypRAnXZSKws6NWO+kw4MxyCG 54L0ia85qVaMl6CyXYyMJF5ZJhzUZygNBj6FSMWRPajiHtvqAw78GcfkMgs71b1hIDEN+R1K sRSbbbVPPrKMxgpmWDRmxeqQmwYVpFzQu9DquoR2mQAAAAAAAA== --------------ms070709050903080402090304-- From owner-freebsd-arm@freebsd.org Mon Dec 18 17:35:57 2017 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 70013E9E519 for ; Mon, 18 Dec 2017 17:35:57 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0F5476624D for ; Mon, 18 Dec 2017 17:35:56 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: e3f66a11-e419-11e7-8dac-d32f5c2d02ef X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id e3f66a11-e419-11e7-8dac-d32f5c2d02ef; Mon, 18 Dec 2017 17:35:52 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBIHZmG5001591; Mon, 18 Dec 2017 10:35:48 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513618548.95072.62.camel@freebsd.org> Subject: Re: RPI2 boot failure with recent changes to u-boot From: Ian Lepore To: Karl Denninger , "freebsd-arm@freebsd.org" Date: Mon, 18 Dec 2017 10:35:48 -0700 In-Reply-To: <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> <1513614709.95072.48.camel@freebsd.org> <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Mon, 18 Dec 2017 17:35:57 -0000 On Mon, 2017-12-18 at 11:25 -0600, Karl Denninger wrote: > On 12/18/2017 10:31, Ian Lepore wrote: > > > > On Mon, 2017-12-18 at 10:24 -0600, Karl Denninger wrote: > > > > > > I recently upgraded my "u-boot" package for RPI2 to the current > > > version > > > (and grabbed the "rpi-firmware" package it said it needed) and > > > now I > > > have no-start on the RPI2.... > > > > > > U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) > > > > > > DRAM:  948 MiB > > > RPI 2 Model B (0xa21041) > > > MMC:   sdhci@7e300000: 0 > > > reading uboot.env > > > > > > ** Unable to read "uboot.env" from mmc0:1 ** > > > Using default environment > > > > > > In:    serial > > > Out:   vidconsole > > > Err:   vidconsole > > > Net:   No ethernet found. > > > starting USB... > > > USB0:   Core Release: 2.80a > > > scanning bus 0 for devices... 3 USB Device(s) found > > >        scanning usb for storage devices... 0 Storage Device(s) > > > found > > > Hit any key to stop autoboot:  0 > > > switch to partitions #0, OK > > > mmc0 is current device > > > Scanning mmc 0:1... > > > Found FreeBSD U-Boot Loader (bin) > > > reading ubldr.bin > > > 227704 bytes read in 34 ms (6.4 MiB/s) > > > ## Starting application at 0x01000000 ... > > > > > > And that be all I get. > > > > > > This is what I have in board/RaspberryPi2/setup.sh related to > > > that > > > (which I had to change since the firmware files have been split > > > between > > > the two packages) > > > > > > raspberry_pi_populate_boot_partition ( ) { > > >     # Copy RaspberryPi 2 boot files to FAT partition > > >     cp ${FIRMWARE_PATH}/LICENCE.broadcom . > > >     cp ${FIRMWARE_PATH}/bootcode.bin . > > >     cp ${FIRMWARE_PATH}/config.txt . > > >     cp ${FIRMWARE_PATH}/fixup.dat . > > >     cp ${FIRMWARE_PATH}/fixup_cd.dat . > > >     cp ${FIRMWARE_PATH}/fixup_x.dat . > > >     cp ${FIRMWARE_PATH}/start.elf . > > >     cp ${FIRMWARE_PATH}/start_cd.elf . > > >     cp ${FIRMWARE_PATH}/start_x.elf . > > >     cp ${UBOOT_PATH}/u-boot.bin . > > >     cp ${UBOOT_PATH}/fixup_db.dat . > > >     cp ${UBOOT_PATH}/start_db.elf . > > >     cp ${UBOOT_PATH}/README . > > > > > >     # RPi firmware loads and modify the DTB before pass it to > > > kernel. > > >     freebsd_install_fdt rpi2.dts rpi2.dtb > > > > > >     # Install ubldr to FAT partition > > >     freebsd_ubldr_copy_ubldr . > > > } > > > > > > Any ideas on tracking this down? > > > > > How recent is your ubldr.bin?  About a week ago in r326752 I > > committed > > the patches from PR 224008, which affects the startup code for > > ubldr.bin, so it could possibly be a fix for the problem you're > > seeing. > > > > (I don't have an rpi2 to test so I can't say for sure.) > > > > -- Ian > I updated the 11.x source tree I use to build this and now I get > further..... > > U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) > > DRAM:  948 MiB > RPI 2 Model B (0xa21041) > MMC:   sdhci@7e300000: 0 > reading uboot.env > > ** Unable to read "uboot.env" from mmc0:1 ** > Using default environment > > In:    serial > Out:   vidconsole > Err:   vidconsole > Net:   No ethernet found. > starting USB... > USB0:   Core Release: 2.80a > scanning bus 0 for devices... 3 USB Device(s) found >        scanning usb for storage devices... 0 Storage Device(s) found > Hit any key to stop autoboot:  0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 235040 bytes read in 33 ms (6.8 MiB/s) > ## Starting application at 0x01000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x3af5d988 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (Mon Dec 18 11:14:37 CST 2017 freebsd@NewFS.denninger.net) > > DRAM: 948MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk >   Probing all disk devices... >   Checking unit=0 slice= partition=... good. > Booting from disk0s2a: > /boot/kernel/kernel text=0x617118 data=0x54300+0x17fbc0 > syms=[0x4+0x67d30+0x4+0x9480c] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > No valid device tree blob found! > > Type '?' for a list of commands, 'help' for more detailed help. > loader> > > > Am  I missing a line in config.txt that needs to be there or did > something else odd happen that the dtb is missing? > On my rpi-b, the dtb file is set in config.txt, which looks like this for booting on 12-current: root@rpi:~ # cat /mnt/config.txt  gpu_mem=32 device_tree=bcm2835-rpi-b-rev2.dtb device_tree_address=0x100 disable_commandline_tags=1 kernel=u-boot.img I think 11-stable still uses the old freebsd-specifc rpi2.dtb, maybe the firmware update changed your config.txt to use the new name? -- Ian From owner-freebsd-arm@freebsd.org Mon Dec 18 17:52:43 2017 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 1B669E9F86E for ; Mon, 18 Dec 2017 17:52:43 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id E4E7B66EF9 for ; Mon, 18 Dec 2017 17:52:42 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 6DBB227335 for ; Mon, 18 Dec 2017 12:52:13 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 7B83D14A58B for ; Mon, 18 Dec 2017 11:52:11 -0600 (CST) Subject: Re: RPI2 boot failure with recent changes to u-boot To: freebsd-arm@freebsd.org References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> <1513614709.95072.48.camel@freebsd.org> <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> From: Karl Denninger Message-ID: <4a2c96e1-b1bd-376f-34f5-e1f0163be2ba@denninger.net> Date: Mon, 18 Dec 2017 11:52:10 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080201070105080801050006" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 17:52:43 -0000 This is a cryptographically signed message in MIME format. --------------ms080201070105080801050006 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/18/2017 11:25, Karl Denninger wrote: > On 12/18/2017 10:31, Ian Lepore wrote: >> On Mon, 2017-12-18 at 10:24 -0600, Karl Denninger wrote: >>> I recently upgraded my "u-boot" package for RPI2 to the current >>> version >>> (and grabbed the "rpi-firmware" package it said it needed) and now I >>> have no-start on the RPI2.... >>> >>> U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) >>> >>> DRAM:=C2=A0 948 MiB >>> RPI 2 Model B (0xa21041) >>> MMC:=C2=A0=C2=A0 sdhci@7e300000: 0 >>> reading uboot.env >>> >>> ** Unable to read "uboot.env" from mmc0:1 ** >>> Using default environment >>> >>> In:=C2=A0=C2=A0=C2=A0 serial >>> Out:=C2=A0=C2=A0 vidconsole >>> Err:=C2=A0=C2=A0 vidconsole >>> Net:=C2=A0=C2=A0 No ethernet found. >>> starting USB... >>> USB0:=C2=A0=C2=A0 Core Release: 2.80a >>> scanning bus 0 for devices... 3 USB Device(s) found >>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scanning usb for storage devices= =2E.. 0 Storage Device(s) found >>> Hit any key to stop autoboot:=C2=A0 0 >>> switch to partitions #0, OK >>> mmc0 is current device >>> Scanning mmc 0:1... >>> Found FreeBSD U-Boot Loader (bin) >>> reading ubldr.bin >>> 227704 bytes read in 34 ms (6.4 MiB/s) >>> ## Starting application at 0x01000000 ... >>> >>> And that be all I get. >>> >>> This is what I have in board/RaspberryPi2/setup.sh related to that >>> (which I had to change since the firmware files have been split >>> between >>> the two packages) >>> >>> raspberry_pi_populate_boot_partition ( ) { >>> =C2=A0=C2=A0=C2=A0 # Copy RaspberryPi 2 boot files to FAT partition >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/LICENCE.broadcom . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/bootcode.bin . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/config.txt . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup.dat . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup_cd.dat . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/fixup_x.dat . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start.elf . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start_cd.elf . >>> =C2=A0=C2=A0=C2=A0 cp ${FIRMWARE_PATH}/start_x.elf . >>> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/u-boot.bin . >>> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/fixup_db.dat . >>> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/start_db.elf . >>> =C2=A0=C2=A0=C2=A0 cp ${UBOOT_PATH}/README . >>> >>> =C2=A0=C2=A0=C2=A0 # RPi firmware loads and modify the DTB before pas= s it to kernel. >>> =C2=A0=C2=A0=C2=A0 freebsd_install_fdt rpi2.dts rpi2.dtb >>> >>> =C2=A0=C2=A0=C2=A0 # Install ubldr to FAT partition >>> =C2=A0=C2=A0=C2=A0 freebsd_ubldr_copy_ubldr . >>> } >>> >>> Any ideas on tracking this down? >>> >> How recent is your ubldr.bin? =C2=A0About a week ago in r326752 I comm= itted >> the patches from PR 224008, which affects the startup code for >> ubldr.bin, so it could possibly be a fix for the problem you're seeing= =2E >> >> (I don't have an rpi2 to test so I can't say for sure.) >> >> -- Ian > I updated the 11.x source tree I use to build this and now I get > further..... > > U-Boot 2017.09 (Dec 12 2017 - 18:48:47 +0000) > > DRAM:=C2=A0 948 MiB > RPI 2 Model B (0xa21041) > MMC:=C2=A0=C2=A0 sdhci@7e300000: 0 > reading uboot.env > > ** Unable to read "uboot.env" from mmc0:1 ** > Using default environment > > In:=C2=A0=C2=A0=C2=A0 serial > Out:=C2=A0=C2=A0 vidconsole > Err:=C2=A0=C2=A0 vidconsole > Net:=C2=A0=C2=A0 No ethernet found. > starting USB... > USB0:=C2=A0=C2=A0 Core Release: 2.80a > scanning bus 0 for devices... 3 USB Device(s) found > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scanning usb for storage devices..= =2E 0 Storage Device(s) found > Hit any key to stop autoboot:=C2=A0 0 > switch to partitions #0, OK > mmc0 is current device > Scanning mmc 0:1... > Found FreeBSD U-Boot Loader (bin) > reading ubldr.bin > 235040 bytes read in 33 ms (6.8 MiB/s) > ## Starting application at 0x01000000 ... > Consoles: U-Boot console > Compatible U-Boot API signature found @0x3af5d988 > > FreeBSD/armv6 U-Boot loader, Revision 1.2 > (Mon Dec 18 11:14:37 CST 2017 freebsd@NewFS.denninger.net) > > DRAM: 948MB > Number of U-Boot devices: 1 > U-Boot env: loaderdev not set, will probe all devices. > Found U-Boot device: disk > =C2=A0 Probing all disk devices... > =C2=A0 Checking unit=3D0 slice=3D partition=3D... good. > Booting from disk0s2a: > /boot/kernel/kernel text=3D0x617118 data=3D0x54300+0x17fbc0 > syms=3D[0x4+0x67d30+0x4+0x9480c] > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > No valid device tree blob found! > > Type '?' for a list of commands, 'help' for more detailed help. > loader> > > > Am=C2=A0 I missing a line in config.txt that needs to be there or did > something else odd happen that the dtb is missing? > Back and forth with Ian a bit, added the dtb file declaration to config.txt in the dos partition (and it's load address) and now the kernel comes up but the disk device is missing, and thus the mount fails..... Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x1200180... Kernel args: (null) Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Regents of the University = of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.1-STABLE #0 r326933M: Mon Dec 18 11:14:31 CST 2017 =C2=A0=C2=A0=C2=A0 freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm.armv6/pics/CrossBu= ild/src/sys/RPI2 arm FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) VT: init without driver. CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: =C2=A0 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, =C2=A0 PXN, LPAE, Coherent Walk Optional instructions: =C2=A0 SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 Cache level 1: =C2=A032KB/64B 4-way data cache WB Read-Alloc Write-Alloc =C2=A032KB/32B 2-way instruction cache Read-Alloc Cache level 2: =C2=A0512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory=C2=A0 =3D 994045952 (947 MB) avail memory =3D 961916928 (917 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: entropy device external interface kbd0 at kbdmux0 ofwbus0: simplebus0: mem 0x3f000000-0x3fffffff on ofwbus0 local_intc0: mem 0x40000000-0x400000ff on simplebus0 intc0: mem 0xb200-0xb3ff irq 4 on simplebu= s0 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 bcmwd0: mem 0x10001c-0x100027 on simplebus0 gpio0: mem 0x200000-0x2000af irq 5,6,7,8 on simplebus0 gpio0: read-only pins: 46,48-53. gpio0: reserved pins: 48-53. gpiobus0: on gpio0 gpioc0: on gpio0 iichb0: mem 0x205000-0x20501f irq 9 on simplebus0 iichb1: mem 0x804000-0x80401f irq 10 on simplebus0 spi0: mem 0x204000-0x20401f irq 11 on simplebus0 spibus0: on spi0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff irq 12,13,14,15,16,17,18,19,20,21,22,23,24 on simplebus0 mbox0: mem 0xb880-0xb8bf irq 25 on simplebus0= sdhci_bcm0: mem 0x300000-0x3000ff irq 26 on simplebus0 uart0: mem 0x201000-0x201fff irq 27 on simplebus= 0 uart0: console (115200,n,8,1) vchiq0: mem 0xb800-0xb84f irq 28 on simplebus0 vchiq: local ver 8 (min 3), remote ver 8. pcm0: on vchiq0 bcm283x_dwcotg0: mem 0x980000-0x99ffff irq 29 on simplebus0 usbus0 on bcm283x_dwcotg0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 fb0: on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver "fb". fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 gpioled0: on ofwbus0 cryptosoft0: Timecounters tick every 1.000 msec iicbus0: on iichb0 iic0: on iicbus0 iicbus1: on iichb1 iic1: on iicbus1 usbus0: 480Mbps High Speed USB v2.0 bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF ugen0.1: at usbus0 uhub0: on usbus0 Release APs Trying to mount root from ufs:/dev/mmcsd0s2a [ro]... Root mount waiting for: usbus0 uhub0: 1 port with 1 removable, self powered Root mount waiting for: usbus0 ugen0.2: at usbus0 uhub1 on uhub0 uhub1: on usbus0 uhub1: MTT enabled uhub1: 5 ports with 4 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0 on uhub1 smsc0: on usbus0 mountroot: waiting for device /dev/mmcsd0s2a... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0:=C2=A0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:be:e6:f8 Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Trying to mount root from ufs:mmcsd0s2 []... mountroot: waiting for device mmcsd0s2... Mounting from ufs:mmcsd0s2 failed with error 19. Loader variables: =C2=A0 vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a =C2=A0 vfs.root.mountfrom.options=3Dro Manual root filesystem specification: =C2=A0 : [options] =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Mount using filesystem =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 and with the specified (optional) option l= ist. =C2=A0=C2=A0=C2=A0 eg. ufs:/dev/da0s1a =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 zfs:tank =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cd9660:/dev/cd0 ro =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (which is equivale= nt to: mount -t cd9660 -o ro /dev/cd0 /) =C2=A0 ?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 List valid disk boot devices =C2=A0 .=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 Yield 1 second (for background tasks) =C2=A0 =C2=A0=C2=A0=C2=A0 Abort manual input mountroot> ? List of GEOM managed disk devices: mountroot> --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080201070105080801050006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjE4MTc1MjEw WjBPBgkqhkiG9w0BCQQxQgRAlzWyn45JEKw+L3+Da8sv7Om8+CW2nhxIJBzqwsUPl3ChUG5S QJNVJ8WcJ1r5HrrsFevC4X7U6aa+Y4j6ppg47jBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBT4qju2BWhEPfVYck3lRahgZOeqKGf0uFAhtfSv/JNqFXhnnPTA8NugIayPwRXNaLI 56Eit+XainFBQskAPuKxSZ7SZUPuVcFHMtDp/ysgV5za55D+nn48rLz/jAP7/gVNyKI60eJ9 QBpjjx9XsJHXjCBNOHmlByrgwNodrebEUhpouaXPjRc0ptg/cDsbqa0znfqp/XxzzVIML0FO IGxrz9SDcNTU8HedwZqAe+HvTiilMSJLRB8FCgHAuwBWscytAIAckG/iCCe9izVcPrCHhU6C gEWWb7v/hpRNge+VFX3Jk+dA8QAnmDEYkWQ3pp9uqcHf6RT8yI+koo+05R0QFb+PKO48cL0H HJMYlctFmVeOXgQZPHmuB4VwAEhRuDrd7Xu9VHoa1d3uNjTS77dbAZfdk0q2UlV7JAi52ZQR Ec80Anb5+8PGLWTnI3Rd7qpccRwuQJqy9bv1Yc9g1+EtV39d8g75skxmhoGIWlX+W0lcTK/v gFe45N9YH7CvXmiRxXaTLVLKfZ4CCd2WTj93OWDfhUYqy3ZXG1hjZFubONoHvednkoAvHtxa KN5xwg1XPfVK9MiCwaNGXQVtElBdoTvo9ueu5VUDwLdcMiK5zkrgz2u6/WcQVpNjl21GYScH F9Ak/5D4J2J0iRseLvbVKx1mewkklbSOlme0SxyNKgAAAAAAAA== --------------ms080201070105080801050006-- From owner-freebsd-arm@freebsd.org Mon Dec 18 18:02:18 2017 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 61BDEEA050E for ; Mon, 18 Dec 2017 18:02:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 44B4C67940 for ; Mon, 18 Dec 2017 18:02:17 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 90a30d4c-e41d-11e7-8486-0934409070aa X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 90a30d4c-e41d-11e7-8486-0934409070aa; Mon, 18 Dec 2017 18:02:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBII2FFv001684; Mon, 18 Dec 2017 11:02:15 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513620135.95072.70.camel@freebsd.org> Subject: Re: RPI2 boot failure with recent changes to u-boot From: Ian Lepore To: Karl Denninger , freebsd-arm@freebsd.org Date: Mon, 18 Dec 2017 11:02:15 -0700 In-Reply-To: <4a2c96e1-b1bd-376f-34f5-e1f0163be2ba@denninger.net> References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> <1513614709.95072.48.camel@freebsd.org> <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> <4a2c96e1-b1bd-376f-34f5-e1f0163be2ba@denninger.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Mon, 18 Dec 2017 18:02:18 -0000 On Mon, 2017-12-18 at 11:52 -0600, Karl Denninger wrote: > On 12/18/2017 11:25, Karl Denninger wrote: > > > > On 12/18/2017 10:31, Ian Lepore wrote: > > > > > > On Mon, 2017-12-18 at 10:24 -0600, Karl Denninger wrote: > > > > > > > > [...] > > > Back and forth with Ian a bit, added the dtb file declaration to > config.txt in the dos partition (and it's load address) and now the > kernel comes up but the disk device is missing, and thus the mount > fails..... > > Hit [Enter] to boot immediately, or any other key for command prompt. > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x100. > Kernel entry at 0x1200180... > Kernel args: (null) > Copyright (c) 1992-2017 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 11.1-STABLE #0 r326933M: Mon Dec 18 11:14:31 CST 2017 >     > freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm.armv6/pics/CrossBuild/src/sys/RPI2 > arm > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on > LLVM 5.0.0svn) > VT: init without driver. > CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > CPU Features: >   Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, >   PXN, LPAE, Coherent Walk > Optional instructions: >   SDIV/UDIV, UMULL, SMULL, SIMD(ext) > LoUU:2 LoC:3 LoUIS:2 > Cache level 1: >  32KB/64B 4-way data cache WB Read-Alloc Write-Alloc >  32KB/32B 2-way instruction cache Read-Alloc > Cache level 2: >  512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > real memory  = 994045952 (947 MB) > avail memory = 961916928 (917 MB) > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > random: entropy device external interface > kbd0 at kbdmux0 > ofwbus0: > simplebus0: mem 0x3f000000-0x3fffffff > on ofwbus0 > local_intc0: mem 0x40000000-0x400000ff on > simplebus0 > intc0: mem 0xb200-0xb3ff irq 4 on simplebus0 > generic_timer0: irq 0,1,2,3 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 > bcmwd0: mem 0x10001c-0x100027 on simplebus0 > gpio0: mem 0x200000-0x2000af irq 5,6,7,8 > on simplebus0 > gpio0: read-only pins: 46,48-53. > gpio0: reserved pins: 48-53. > gpiobus0: on gpio0 > gpioc0: on gpio0 > iichb0: mem 0x205000-0x20501f irq 9 on > simplebus0 > iichb1: mem 0x804000-0x80401f irq 10 on > simplebus0 > spi0: mem 0x204000-0x20401f irq 11 on > simplebus0 > spibus0: on spi0 > bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff > irq 12,13,14,15,16,17,18,19,20,21,22,23,24 on simplebus0 > mbox0: mem 0xb880-0xb8bf irq 25 on simplebus0 > sdhci_bcm0: mem 0x300000-0x3000ff irq > 26 on simplebus0 Right here is where it turns strange, because the next line after sdhci_bcm0: should be this one: mmc0: on sdhci_bcm0 The only thing I can think of that would cause it to be missing is if "device mmc" is missing from the kernel config.  It's also available as a module, so you could try interrupting ubldr to get the prompt and do "load mmc". If that's not the problem, maybe the output from "boot -v" will have more clues. -- Ian > uart0: mem 0x201000-0x201fff irq 27 on simplebus0 > uart0: console (115200,n,8,1) > vchiq0: mem 0xb800-0xb84f irq 28 on simplebus0 > vchiq: local ver 8 (min 3), remote ver 8. > pcm0: on vchiq0 > bcm283x_dwcotg0: mem > 0x980000-0x99ffff irq 29 on simplebus0 > usbus0 on bcm283x_dwcotg0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > bcm2835_cpufreq0: on cpu0 > cpu1: on cpulist0 > cpu2: on cpulist0 > cpu3: on cpulist0 > fb0: on ofwbus0 > fbd0 on fb0 > VT: initialize with new VT driver "fb". > fb0: 656x416(656x416@0,0) 24bpp > fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 > gpioled0: on ofwbus0 > cryptosoft0: > Timecounters tick every 1.000 msec > iicbus0: on iichb0 > iic0: on iicbus0 > iicbus1: on iichb1 > iic1: on iicbus1 > usbus0: 480Mbps High Speed USB v2.0 > bcm2835_cpufreq0: ARM 600MHz, Core 250MHz, SDRAM 400MHz, Turbo OFF > ugen0.1: at usbus0 > uhub0: on usbus0 > Release APs > Trying to mount root from ufs:/dev/mmcsd0s2a [ro]... > Root mount waiting for: usbus0 > uhub0: 1 port with 1 removable, self powered > Root mount waiting for: usbus0 > ugen0.2: at usbus0 > uhub1 on uhub0 > uhub1: > on usbus0 > uhub1: MTT enabled > uhub1: 5 ports with 4 removable, self powered > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0 on uhub1 > smsc0: on usbus0 > mountroot: waiting for device /dev/mmcsd0s2a... > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > ue0: on smsc0 > ue0: Ethernet address: b8:27:eb:be:e6:f8 > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > Trying to mount root from ufs:mmcsd0s2 []... > mountroot: waiting for device mmcsd0s2... > Mounting from ufs:mmcsd0s2 failed with error 19. > > Loader variables: >   vfs.root.mountfrom=ufs:/dev/mmcsd0s2a >   vfs.root.mountfrom.options=ro > > Manual root filesystem specification: >   : [options] >       Mount using filesystem >       and with the specified (optional) option list. > >     eg. ufs:/dev/da0s1a >         zfs:tank >         cd9660:/dev/cd0 ro >           (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) > >   ?               List valid disk boot devices >   .               Yield 1 second (for background tasks) >       Abort manual input > > mountroot> ? > > List of GEOM managed disk devices: > > > mountroot> > > From owner-freebsd-arm@freebsd.org Mon Dec 18 18:10:09 2017 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 CC54FEA0CC4 for ; Mon, 18 Dec 2017 18:10:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 9D58367C3B for ; Mon, 18 Dec 2017 18:10:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id C936127517 for ; Mon, 18 Dec 2017 13:10:09 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 03B6614A61E for ; Mon, 18 Dec 2017 12:10:07 -0600 (CST) Subject: Re: RPI2 boot failure with recent changes to u-boot To: freebsd-arm@freebsd.org References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> <1513614709.95072.48.camel@freebsd.org> <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> <4a2c96e1-b1bd-376f-34f5-e1f0163be2ba@denninger.net> <1513620135.95072.70.camel@freebsd.org> From: Karl Denninger Message-ID: Date: Mon, 18 Dec 2017 12:10:07 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1513620135.95072.70.camel@freebsd.org> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms010805000807090003000304" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 18:10:09 -0000 This is a cryptographically signed message in MIME format. --------------ms010805000807090003000304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/18/2017 12:02, Ian Lepore wrote: > On Mon, 2017-12-18 at 11:52 -0600, Karl Denninger wrote: >> On 12/18/2017 11:25, Karl Denninger wrote: >>> On 12/18/2017 10:31, Ian Lepore wrote: >>>> On Mon, 2017-12-18 at 10:24 -0600, Karl Denninger wrote: >>>>> [...] >> Back and forth with Ian a bit, added the dtb file declaration to >> config.txt in the dos partition (and it's load address) and now the >> kernel comes up but the disk device is missing, and thus the mount >> fails..... >> >> Hit [Enter] to boot immediately, or any other key for command prompt. >> Booting [/boot/kernel/kernel]... >> Using DTB provided by U-Boot at address 0x100. >> Kernel entry at 0x1200180... >> Kernel args: (null) >> Copyright (c) 1992-2017 The FreeBSD Project. >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 >> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Regents of the Universi= ty of California. All rights reserved. >> FreeBSD is a registered trademark of The FreeBSD Foundation. >> FreeBSD 11.1-STABLE #0 r326933M: Mon Dec 18 11:14:31 CST 2017 >> =C2=A0=C2=A0=C2=A0 >> freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm.armv6/pics/Cros= sBuild/src/sys/RPI2 >> arm >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on >> LLVM 5.0.0svn) >> VT: init without driver. >> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) >> CPU Features: >> =C2=A0 Multiprocessing, Thumb2, Security, Virtualization, Generic Time= r, VMSAv7, >> =C2=A0 PXN, LPAE, Coherent Walk >> Optional instructions: >> =C2=A0 SDIV/UDIV, UMULL, SMULL, SIMD(ext) >> LoUU:2 LoC:3 LoUIS:2 >> Cache level 1: >> =C2=A032KB/64B 4-way data cache WB Read-Alloc Write-Alloc >> =C2=A032KB/32B 2-way instruction cache Read-Alloc >> Cache level 2: >> =C2=A0512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc >> real memory=C2=A0 =3D 994045952 (947 MB) >> avail memory =3D 961916928 (917 MB) >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >> random: entropy device external interface >> kbd0 at kbdmux0 >> ofwbus0:=20 >> simplebus0: mem 0x3f000000-0x3fffffff >> on ofwbus0 >> local_intc0: mem 0x40000000-0x400000ff on >> simplebus0 >> intc0: mem 0xb200-0xb3ff irq 4 on simplebus0 >> generic_timer0: irq 0,1,2,3 on ofwbus0 >> Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 100= 0 >> Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000= >> bcmwd0: mem 0x10001c-0x100027 on simplebus0 >> gpio0: mem 0x200000-0x2000af irq 5,6,7,8 >> on simplebus0 >> gpio0: read-only pins: 46,48-53. >> gpio0: reserved pins: 48-53. >> gpiobus0: on gpio0 >> gpioc0: on gpio0 >> iichb0: mem 0x205000-0x20501f irq 9 on >> simplebus0 >> iichb1: mem 0x804000-0x80401f irq 10 on >> simplebus0 >> spi0: mem 0x204000-0x20401f irq 11 on >> simplebus0 >> spibus0: on spi0 >> bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff >> irq 12,13,14,15,16,17,18,19,20,21,22,23,24 on simplebus0 >> mbox0: mem 0xb880-0xb8bf irq 25 on simplebus0 >> sdhci_bcm0: mem 0x300000-0x3000ff irq >> 26 on simplebus0 > Right here is where it turns strange, because the next line after > sdhci_bcm0: should be this one: > > mmc0: on sdhci_bcm0 > > The only thing I can think of that would cause it to be missing is if > "device mmc" is missing from the kernel config. =C2=A0It's also availab= le as > a module, so you could try interrupting ubldr to get the prompt and do > "load mmc". > > If that's not the problem, maybe the output from "boot -v" will have > more clues. > > -- Ian load mmc from the loader> prompt does nothing. "boot -v" returns: loader> boot -v Booting... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x1200180... Kernel args: -v Copyright (c) 1992-2017 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The Regents of the University = of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.1-STABLE #0 r326933M: Mon Dec 18 11:14:31 CST 2017 =C2=A0=C2=A0=C2=A0 freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm.armv6/pics/CrossBu= ild/src/sys/RPI2 arm FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) VT: init without driver. Preloaded elf kernel "/boot/kernel/kernel" at 0xc09ee000. CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: =C2=A0 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, =C2=A0 PXN, LPAE, Coherent Walk Optional instructions: =C2=A0 SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 Cache level 1: =C2=A032KB/64B 4-way data cache WB Read-Alloc Write-Alloc =C2=A032KB/32B 2-way instruction cache Read-Alloc Cache level 2: =C2=A0512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory=C2=A0 =3D 994045952 (947 MB) avail memory =3D 961916928 (917 MB) Physical memory chunk(s): =C2=A0 0x00001000 - 0x3b3fffff,=C2=A0=C2=A0 947 MB ( 242687 pages) Excluded memory regions: =C2=A0 0x01200000 - 0x01b53fff,=C2=A0=C2=A0=C2=A0=C2=A0 9 MB (=C2=A0=C2=A0= 2388 pages) NoAlloc =C2=A0 0x3b400000 - 0x3fffffff,=C2=A0=C2=A0=C2=A0 76 MB (=C2=A0 19456 pag= es) NoAlloc NoDump Static device mappings: =C2=A0 0x3f000000 - 0x3fffffff mapped at VA 0xfef00000 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs ULE: setup cpu 0 ULE: setup cpu 1 ULE: setup cpu 2 ULE: setup cpu 3 random: entropy device external interface snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [= 1024] feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 crypto: null: openfirm: kbd0 at kbdmux0 mem: nfslock: pseudo-device random: harvesting attach, 8 bytes (4 bits) from nexus0 ofwbus0: simplebus0: mem 0x3f000000-0x3fffffff on ofwbus0 simplebus0: Malformed reg property on random: harvesting attach, 8 bytes (4 bits) from simplebus0 random: harvesting attach, 8 bytes (4 bits) from ofwbus0 local_intc0: mem 0x40000000-0x400000ff on simplebus0 random: harvesting attach, 8 bytes (4 bits) from local_intc0 intc0: mem 0xb200-0xb3ff irq 4 on simplebu= s0 random: harvesting attach, 8 bytes (4 bits) from intc0 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 random: harvesting attach, 8 bytes (4 bits) from generic_timer0 bcmwd0: mem 0x10001c-0x100027 on simplebus0 random: harvesting attach, 8 bytes (4 bits) from bcmwd0 gpio0: mem 0x200000-0x2000af irq 5,6,7,8 on simplebus0 gpio0: read-only pins: 46,48-53. gpio0: reserved pins: 48-53. gpiobus0: on gpio0 random: harvesting attach, 8 bytes (4 bits) from gpiobus0 gpioc0: on gpio0 random: harvesting attach, 8 bytes (4 bits) from gpioc0 random: harvesting attach, 8 bytes (4 bits) from gpio0 iichb0: mem 0x205000-0x20501f irq 9 on simplebus0 random: harvesting attach, 8 bytes (4 bits) from iichb0 iichb1: mem 0x804000-0x80401f irq 10 on simplebus0 random: harvesting attach, 8 bytes (4 bits) from iichb1 spi0: mem 0x204000-0x20401f irq 11 on simplebus0 spibus0: on spi0 random: harvesting attach, 8 bytes (4 bits) from spibus0 random: harvesting attach, 8 bytes (4 bits) from spi0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff irq 12,13,14,15,16,17,18,19,20,21,22,23,24 on simplebus0 random: harvesting attach, 8 bytes (4 bits) from bcm_dma0 mbox0: mem 0xb880-0xb8bf irq 25 on simplebus0= random: harvesting attach, 8 bytes (4 bits) from mbox0 sdhci_bcm0: mem 0x300000-0x3000ff irq 26 on simplebus0 sdhci_bcm0: SDHCI frequency: 250MHz sdhci_bcm0-slot0: 250MHz HS 4bits VDD: 3.3V VCCQ: 3.3V DRV: B PIO removab= le sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version:=C2=A0 0x00009902 sdhci_bcm0-slot0: Blk size: 0x00007200 | Blk cnt:=C2=A0 0x00000000 sdhci_bcm0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 sdhci_bcm0-slot0: Present:=C2=A0 0x01ff0000 | Host ctl: 0x00000002 sdhci_bcm0-slot0: Power:=C2=A0=C2=A0=C2=A0 0x0000000f | Blk gap:=C2=A0 0x= 00000000 sdhci_bcm0-slot0: Wake-up:=C2=A0 0x00000000 | Clock:=C2=A0=C2=A0=C2=A0 0x= 00000307 sdhci_bcm0-slot0: Timeout:=C2=A0 0x0000000e | Int stat: 0x00000000 sdhci_bcm0-slot0: Int enab: 0x027f003b | Sig enab: 0x00000000 sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 sdhci_bcm0-slot0: Caps:=C2=A0=C2=A0=C2=A0=C2=A0 0x00000000 | Caps2:=C2=A0= =C2=A0=C2=A0 0x00000000 sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D random: harvesting attach, 8 bytes (4 bits) from sdhci_bcm0 uart0: mem 0x201000-0x201fff irq 27 on simplebus= 0 uart0: console (115200,n,8,1) uart0: fast interrupt uart0: PPS capture mode: DCDinvalid random: harvesting attach, 8 bytes (4 bits) from uart0 vchiq0: mem 0xb800-0xb84f irq 28 on simplebus0 vchiq: local ver 8 (min 3), remote ver 8. pcm0: on vchiq0 random: harvesting attach, 8 bytes (4 bits) from pcm0 random: harvesting attach, 8 bytes (4 bits) from vchiq0 bcm283x_dwcotg0: mem 0x980000-0x99ffff irq 29 on simplebus0 usbus0 on bcm283x_dwcotg0 bcm283x_dwcotg0: usbpf: Attached random: harvesting attach, 8 bytes (4 bits) from usbus0 random: harvesting attach, 8 bytes (4 bits) from bcm283x_dwcotg0 cpulist0: on ofwbus0 cpu0: on cpulist0 bcm2835_cpufreq0: on cpu0 random: harvesting attach, 8 bytes (4 bits) from cpufreq0 random: harvesting attach, 8 bytes (4 bits) from bcm2835_cpufreq0 random: harvesting attach, 8 bytes (4 bits) from cpu0 cpu1: on cpulist0 random: harvesting attach, 8 bytes (4 bits) from cpu1 cpu2: on cpulist0 random: harvesting attach, 8 bytes (4 bits) from cpu2 cpu3: on cpulist0 random: harvesting attach, 8 bytes (4 bits) from cpu3 random: harvesting attach, 8 bytes (4 bits) from cpulist0 fb0: on ofwbus0 fbd0 on fb0 VT: initialize with new VT driver "fb". random: harvesting attach, 8 bytes (4 bits) from fbd0 fb0: 656x416(656x416@0,0) 24bpp fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 random: harvesting attach, 8 bytes (4 bits) from fb0 ofwbus0: compat rpi,rpi-ft5406 (no driver attached) gpioled0: on ofwbus0 random: harvesting attach, 8 bytes (4 bits) from gpioled0 ofwbus0: compat broadcom,bcm2835-power-mgr (no driver attache= d) ofwbus0: compat simple_bus (no driver attached) cryptosoft0: crypto: assign cryptosoft0 driver id 0, flags 100663296 crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 Tdwuhub0: 1 port with 1 removable, self poweredcbcm28rrt, H , random: harvesting attach, 8 bytes (4 bits) from uhub0 ugen0.2: at usbus0 uhub1 on uhub0 uhub1: on usbus0 uhub1: MTT enabled Root mount waiting for: usbus0 uhub1: 5 ports with 4 removable, self powered random: harvesting attach, 8 bytes (4 bits) from uhub1 Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0 on uhub1 smsc0: on usbus0 random: harvesting attach, 8 bytes (4 bits) from smsc0 mountroot: waiting for device /dev/mmcsd0s2a... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 ukphy0: OUI 0x00800f, model 0x000c, rev. 3 ukphy0:=C2=A0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto random: harvesting attach, 8 bytes (4 bits) from ukphy0 random: harvesting attach, 8 bytes (4 bits) from miibus0 ue0: on smsc0 ue0: bpf attached ue0: Ethernet address: b8:27:eb:be:e6:f8 Mounting from ufs:/dev/mmcsd0s2a failed with error 19. Trying to mount root from ufs:mmcsd0s2 []... mountroot: waiting for device mmcsd0s2... Mounting from ufs:mmcsd0s2 failed with error 19. Loader variables: =C2=A0 vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a =C2=A0 vfs.root.mountfrom.options=3Dro The device is just.... gone. The rpi2.dts file was updated when I updated the source (if that's involved here), so that should be current.... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms010805000807090003000304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjE4MTgxMDA3 WjBPBgkqhkiG9w0BCQQxQgRAL5TmJcUSSTFoSvEc6Il6JJVk73771CjuU0oSiSn7vb8BPHCs MMEuCpgYEKauD9h8FsnMRbFI4w9g0bQ26ZqfKDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCDeguhXl4HmtT5u5KNq4SL8QSobA4Q+j8uOpf2TkmPvNg/3519T//I8pEeKb6WBL5k lpBrInSYBFpvQ0KOyAZkXliAlXjP6Z0wwFytbQnVMJwf/o+IuuYTE7/Djq+GN2tiM5jHl/Ky VtnLuRydlufQoTFMGK2UpRZ66xwPr2clZbJTxtvZB+GM7Np5eDFrE1h1NJdB5chz9+uFoEDm NrBNKDUvdQM76iYdAVHc5i5hbuPts9N2Nd+ohD72tCQbtvhhLXeJRiS+rejTj6PoW2EFcDHB T/C4pza+p9LbGJbnwQxoYK/pnJhjf0P5mt7Gxli9ZZ/MSBkvYufUPdVTIuDyQoZ8WNv/7WPs A/JXq18mb7pwQEdhQrQuk/O+PomIXmGMFHGrQEn/DS0WQSPl5R1/NL5LzOluldQwfgs8iV1T 79f8KAOQ32zdxEKimQL+3yOyN4Jbgam6AacCjezDHftYO8t9f9qV7BkrtkngBH4chL6ubZJ+ E8kOLLQ12Cg+cBR62WuP+Xf4VPGDilwm74gz7lzmNvrGPFUc9/+W8geOxUSSEMLqL0dj/6qO i76vckCeCIOmLcFDLsMLHhpajsjNEHWfr7Z4sspGxJZAIeklnBlObB6QzfIR7qzMqcV3iTw+ 31gHEcDFZ0zgYbnne6sKMQMhg4t+RxB+5al4i6G5VwAAAAAAAA== --------------ms010805000807090003000304-- From owner-freebsd-arm@freebsd.org Mon Dec 18 19:31:55 2017 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 F3768E809C7 for ; Mon, 18 Dec 2017 19:31:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ADEF56B51B for ; Mon, 18 Dec 2017 19:31:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBIJVlPQ008514 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Dec 2017 11:31:48 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBIJVlde008513; Mon, 18 Dec 2017 11:31:47 -0800 (PST) (envelope-from fbsd) Date: Mon, 18 Dec 2017 11:31:47 -0800 From: bob prohaska To: Mika??l Urankar Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: firefox-esr on armv6/7 Message-ID: <20171218193147.GA8436@www.zefox.net> References: <20171211001731.GA43056@www.zefox.net> <20171211152414.GA45253@www.zefox.net> <20171213202758.GA62406@www.zefox.net> <20171213203346.GA62447@www.zefox.net> <20171213215449.GB62406@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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: Mon, 18 Dec 2017 19:31:56 -0000 Hi Mikael, To my bafflement, trying firefox again today was successful. I didn't make any changes (that I know of) so it's unclear what happened. The only explicit change was to try firefox more than once. There was a power outage the morning of the 16th which forced a restart of my DSL modem, perhaps there was some obscure issue unique to firefox that the power cycling resolved. In any case, firefox-esr seems to be usable on RPI2. The biggest oddity observed is that after exiting firefox, it seems to remain active in a top window well after the window disappears. By my account your patches are a success. Thanks for all your help, bob prohaska On Mon, Dec 18, 2017 at 08:03:58PM +0100, Mika??l Urankar wrote: > 2017-12-18 13:23 GMT+01:00 Mika??l Urankar : > > > 2017-12-13 22:54 GMT+01:00 bob prohaska : > > > >> On Wed, Dec 13, 2017 at 10:28:26PM +0100, Mika??l Urankar wrote: > >> > > >> > > >> > Can you give me the whole message, > >> > >> Yes, here's a verbatim copy/paste. > > > > > > The warnings are harmless, it works on my rpi, I will send you my package > > this evening for testing. > > http://mikael.urankar.free.fr/FreeBSD/arm/firefox-esr_armv7.png > > > > > Here is my pkg: > http://mikael.urankar.free.fr/FreeBSD/arm/firefox-esr-52.5.1,1.txz From owner-freebsd-arm@freebsd.org Mon Dec 18 20:21:21 2017 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 60D4DE844EF for ; Mon, 18 Dec 2017 20:21:21 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C8DEB6E114 for ; Mon, 18 Dec 2017 20:21:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 78a864b5; Mon, 18 Dec 2017 21:21:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=HW6C8mI86HCLzMdwOId8CSeBjOw=; b=W4po38Eaq8By8TSYPuUmJLpIlsK+ IvlmNfzVxDQNitWMHABpL3p4IzWyhWfK+h1oz5rgyqfOOqgLQZHGCBXa0yB41mcl /qrFvUYoCtvbs1s8WW7Qz5UmMIkoFOWs6F1XaX2XhETyie+LY/RVh2l/QxoNUE7T eXsj3imU20O+TQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=UKNyFTi4SHYfUIX/q4r+W1tL6uWsOpurbyTFw1vHVx5BlEfcGnUYo+9D og5G6wD6Hb4SLn2ch8tVTriirjC4Pgt8ILXw3bPclYEJ3FG2p11hy4AlU0lcL4pD kZy4l+Q3ekBQuQKEnmEw4hxBIrgAO9sPPoipI6W6CWM2tTFwBm4= Received: from arcadia.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 53f15658 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 18 Dec 2017 21:21:17 +0100 (CET) Date: Mon, 18 Dec 2017 21:21:15 +0100 From: Emmanuel Vadot To: Karl Denninger Cc: freebsd-arm@freebsd.org Subject: Re: RPI2 boot failure with recent changes to u-boot Message-Id: <20171218212115.318d72a4b237907ddcb42229@bidouilliste.com> In-Reply-To: References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> <1513614709.95072.48.camel@freebsd.org> <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> <4a2c96e1-b1bd-376f-34f5-e1f0163be2ba@denninger.net> <1513620135.95072.70.camel@freebsd.org> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Mon, 18 Dec 2017 20:21:21 -0000 On Mon, 18 Dec 2017 12:10:07 -0600 Karl Denninger wrote: >=20 >=20 > On 12/18/2017 12:02, Ian Lepore wrote: > > On Mon, 2017-12-18 at 11:52 -0600, Karl Denninger wrote: > >> On 12/18/2017 11:25, Karl Denninger wrote: > >>> On 12/18/2017 10:31, Ian Lepore wrote: > >>>> On Mon, 2017-12-18 at 10:24 -0600, Karl Denninger wrote: > >>>>> [...] > >> Back and forth with Ian a bit, added the dtb file declaration to > >> config.txt in the dos partition (and it's load address) and now the > >> kernel comes up but the disk device is missing, and thus the mount > >> fails..... > >> > >> Hit [Enter] to boot immediately, or any other key for command prompt. > >> Booting [/boot/kernel/kernel]... > >> Using DTB provided by U-Boot at address 0x100. > >> Kernel entry at 0x1200180... > >> Kernel args: (null) > >> Copyright (c) 1992-2017 The FreeBSD Project. > >> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 19= 94 > >> =A0=A0=A0=A0=A0=A0=A0 The Regents of the University of California. All= rights reserved. > >> FreeBSD is a registered trademark of The FreeBSD Foundation. > >> FreeBSD 11.1-STABLE #0 r326933M: Mon Dec 18 11:14:31 CST 2017 > >> =A0=A0=A0 > >> freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm.armv6/pics/Cros= sBuild/src/sys/RPI2 > >> arm > >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on > >> LLVM 5.0.0svn) > >> VT: init without driver. > >> CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > >> CPU Features: > >> =A0 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, = VMSAv7, > >> =A0 PXN, LPAE, Coherent Walk > >> Optional instructions: > >> =A0 SDIV/UDIV, UMULL, SMULL, SIMD(ext) > >> LoUU:2 LoC:3 LoUIS:2 > >> Cache level 1: > >> =A032KB/64B 4-way data cache WB Read-Alloc Write-Alloc > >> =A032KB/32B 2-way instruction cache Read-Alloc > >> Cache level 2: > >> =A0512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > >> real memory=A0 =3D 994045952 (947 MB) > >> avail memory =3D 961916928 (917 MB) > >> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > >> random: entropy device external interface > >> kbd0 at kbdmux0 > >> ofwbus0:=20 > >> simplebus0: mem 0x3f000000-0x3fffffff > >> on ofwbus0 > >> local_intc0: mem 0x40000000-0x400000ff on > >> simplebus0 > >> intc0: mem 0xb200-0xb3ff irq 4 on simplebus0 > >> generic_timer0: irq 0,1,2,3 on ofwbus0 > >> Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 > >> Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 > >> bcmwd0: mem 0x10001c-0x100027 on simplebus0 > >> gpio0: mem 0x200000-0x2000af irq 5,6,7,8 > >> on simplebus0 > >> gpio0: read-only pins: 46,48-53. > >> gpio0: reserved pins: 48-53. > >> gpiobus0: on gpio0 > >> gpioc0: on gpio0 > >> iichb0: mem 0x205000-0x20501f irq 9 on > >> simplebus0 > >> iichb1: mem 0x804000-0x80401f irq 10 on > >> simplebus0 > >> spi0: mem 0x204000-0x20401f irq 11 on > >> simplebus0 > >> spibus0: on spi0 > >> bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff > >> irq 12,13,14,15,16,17,18,19,20,21,22,23,24 on simplebus0 > >> mbox0: mem 0xb880-0xb8bf irq 25 on simplebus0 > >> sdhci_bcm0: mem 0x300000-0x3000ff irq > >> 26 on simplebus0 > > Right here is where it turns strange, because the next line after > > sdhci_bcm0: should be this one: > > > > mmc0: on sdhci_bcm0 > > > > The only thing I can think of that would cause it to be missing is if > > "device mmc" is missing from the kernel config. =A0It's also available = as > > a module, so you could try interrupting ubldr to get the prompt and do > > "load mmc". > > > > If that's not the problem, maybe the output from "boot -v" will have > > more clues. > > > > -- Ian >=20 > load mmc from the loader> prompt does nothing. >=20 > "boot -v" returns: >=20 > loader> boot -v > Booting... > Using DTB provided by U-Boot at address 0x100. > Kernel entry at 0x1200180... > Kernel args: -v > Copyright (c) 1992-2017 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > =A0=A0=A0=A0=A0=A0=A0 The Regents of the University of California. All ri= ghts reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 11.1-STABLE #0 r326933M: Mon Dec 18 11:14:31 CST 2017 > =A0=A0=A0 > freebsd@NewFS.denninger.net:/pics/Crochet-work/obj/arm.armv6/pics/CrossBu= ild/src/sys/RPI2 > arm > FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on > LLVM 5.0.0svn) > VT: init without driver. > Preloaded elf kernel "/boot/kernel/kernel" at 0xc09ee000. > CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) > CPU Features: > =A0 Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMS= Av7, > =A0 PXN, LPAE, Coherent Walk > Optional instructions: > =A0 SDIV/UDIV, UMULL, SMULL, SIMD(ext) > LoUU:2 LoC:3 LoUIS:2 > Cache level 1: > =A032KB/64B 4-way data cache WB Read-Alloc Write-Alloc > =A032KB/32B 2-way instruction cache Read-Alloc > Cache level 2: > =A0512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc > real memory=A0 =3D 994045952 (947 MB) > avail memory =3D 961916928 (917 MB) > Physical memory chunk(s): > =A0 0x00001000 - 0x3b3fffff,=A0=A0 947 MB ( 242687 pages) > Excluded memory regions: > =A0 0x01200000 - 0x01b53fff,=A0=A0=A0=A0 9 MB (=A0=A0 2388 pages) NoAlloc > =A0 0x3b400000 - 0x3fffffff,=A0=A0=A0 76 MB (=A0 19456 pages) NoAlloc NoD= ump > Static device mappings: > =A0 0x3f000000 - 0x3fffffff mapped at VA 0xfef00000 > FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs > ULE: setup cpu 0 > ULE: setup cpu 1 > ULE: setup cpu 2 > ULE: setup cpu 3 > random: entropy device external interface > snd_unit_init() u=3D0x00ff8000 [512] d=3D0x00007c00 [32] c=3D0x000003ff [= 1024] > feeder_register: snd_unit=3D-1 snd_maxautovchans=3D16 latency=3D5 > feeder_rate_min=3D1 feeder_rate_max=3D2016000 feeder_rate_round=3D25 > crypto: > null: > openfirm: > kbd0 at kbdmux0 > mem: > nfslock: pseudo-device > random: harvesting attach, 8 bytes (4 bits) from nexus0 > ofwbus0: > simplebus0: mem 0x3f000000-0x3fffffff > on ofwbus0 > simplebus0: Malformed reg property on > random: harvesting attach, 8 bytes (4 bits) from simplebus0 > random: harvesting attach, 8 bytes (4 bits) from ofwbus0 > local_intc0: mem 0x40000000-0x400000ff on > simplebus0 > random: harvesting attach, 8 bytes (4 bits) from local_intc0 > intc0: mem 0xb200-0xb3ff irq 4 on simplebu= s0 > random: harvesting attach, 8 bytes (4 bits) from intc0 > generic_timer0: irq 0,1,2,3 on ofwbus0 > Timecounter "ARM MPCore Timecounter" frequency 19200000 Hz quality 1000 > Event timer "ARM MPCore Eventtimer" frequency 19200000 Hz quality 1000 > random: harvesting attach, 8 bytes (4 bits) from generic_timer0 > bcmwd0: mem 0x10001c-0x100027 on simplebus0 > random: harvesting attach, 8 bytes (4 bits) from bcmwd0 > gpio0: mem 0x200000-0x2000af irq 5,6,7,8 > on simplebus0 > gpio0: read-only pins: 46,48-53. > gpio0: reserved pins: 48-53. > gpiobus0: on gpio0 > random: harvesting attach, 8 bytes (4 bits) from gpiobus0 > gpioc0: on gpio0 > random: harvesting attach, 8 bytes (4 bits) from gpioc0 > random: harvesting attach, 8 bytes (4 bits) from gpio0 > iichb0: mem 0x205000-0x20501f irq 9 on > simplebus0 > random: harvesting attach, 8 bytes (4 bits) from iichb0 > iichb1: mem 0x804000-0x80401f irq 10 on > simplebus0 > random: harvesting attach, 8 bytes (4 bits) from iichb1 > spi0: mem 0x204000-0x20401f irq 11 on > simplebus0 > spibus0: on spi0 > random: harvesting attach, 8 bytes (4 bits) from spibus0 > random: harvesting attach, 8 bytes (4 bits) from spi0 > bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff > irq 12,13,14,15,16,17,18,19,20,21,22,23,24 on simplebus0 > random: harvesting attach, 8 bytes (4 bits) from bcm_dma0 > mbox0: mem 0xb880-0xb8bf irq 25 on simplebus0 > random: harvesting attach, 8 bytes (4 bits) from mbox0 > sdhci_bcm0: mem 0x300000-0x3000ff irq > 26 on simplebus0 > sdhci_bcm0: SDHCI frequency: 250MHz > sdhci_bcm0-slot0: 250MHz HS 4bits VDD: 3.3V VCCQ: 3.3V DRV: B PIO removab= le > sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D REGISTER DUM= P =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > sdhci_bcm0-slot0: Sys addr: 0x00000000 | Version:=A0 0x00009902 > sdhci_bcm0-slot0: Blk size: 0x00007200 | Blk cnt:=A0 0x00000000 > sdhci_bcm0-slot0: Argument: 0x00000000 | Trn mode: 0x00000000 > sdhci_bcm0-slot0: Present:=A0 0x01ff0000 | Host ctl: 0x00000002 > sdhci_bcm0-slot0: Power:=A0=A0=A0 0x0000000f | Blk gap:=A0 0x00000000 > sdhci_bcm0-slot0: Wake-up:=A0 0x00000000 | Clock:=A0=A0=A0 0x00000307 > sdhci_bcm0-slot0: Timeout:=A0 0x0000000e | Int stat: 0x00000000 > sdhci_bcm0-slot0: Int enab: 0x027f003b | Sig enab: 0x00000000 > sdhci_bcm0-slot0: AC12 err: 0x00000000 | Host ctl2:0x00000000 > sdhci_bcm0-slot0: Caps:=A0=A0=A0=A0 0x00000000 | Caps2:=A0=A0=A0 0x000000= 00 > sdhci_bcm0-slot0: Max curr: 0x00000001 | ADMA err: 0x00000000 > sdhci_bcm0-slot0: ADMA addr:0x00000000 | Slot int: 0x00000000 > sdhci_bcm0-slot0: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > random: harvesting attach, 8 bytes (4 bits) from sdhci_bcm0 > uart0: mem 0x201000-0x201fff irq 27 on simplebus0 > uart0: console (115200,n,8,1) > uart0: fast interrupt > uart0: PPS capture mode: DCDinvalid > random: harvesting attach, 8 bytes (4 bits) from uart0 > vchiq0: mem 0xb800-0xb84f irq 28 on simplebus0 > vchiq: local ver 8 (min 3), remote ver 8. > pcm0: on vchiq0 > random: harvesting attach, 8 bytes (4 bits) from pcm0 > random: harvesting attach, 8 bytes (4 bits) from vchiq0 > bcm283x_dwcotg0: mem > 0x980000-0x99ffff irq 29 on simplebus0 > usbus0 on bcm283x_dwcotg0 > bcm283x_dwcotg0: usbpf: Attached > random: harvesting attach, 8 bytes (4 bits) from usbus0 > random: harvesting attach, 8 bytes (4 bits) from bcm283x_dwcotg0 > cpulist0: on ofwbus0 > cpu0: on cpulist0 > bcm2835_cpufreq0: on cpu0 > random: harvesting attach, 8 bytes (4 bits) from cpufreq0 > random: harvesting attach, 8 bytes (4 bits) from bcm2835_cpufreq0 > random: harvesting attach, 8 bytes (4 bits) from cpu0 > cpu1: on cpulist0 > random: harvesting attach, 8 bytes (4 bits) from cpu1 > cpu2: on cpulist0 > random: harvesting attach, 8 bytes (4 bits) from cpu2 > cpu3: on cpulist0 > random: harvesting attach, 8 bytes (4 bits) from cpu3 > random: harvesting attach, 8 bytes (4 bits) from cpulist0 > fb0: on ofwbus0 > fbd0 on fb0 > VT: initialize with new VT driver "fb". > random: harvesting attach, 8 bytes (4 bits) from fbd0 > fb0: 656x416(656x416@0,0) 24bpp > fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 > random: harvesting attach, 8 bytes (4 bits) from fb0 > ofwbus0: compat rpi,rpi-ft5406 (no driver attached) > gpioled0: on ofwbus0 > random: harvesting attach, 8 bytes (4 bits) from gpioled0 > ofwbus0: compat broadcom,bcm2835-power-mgr (no driver attache= d) > ofwbus0: compat simple_bus (no driver attached) > cryptosoft0: > crypto: assign cryptosoft0 driver id 0, flags 100663296 > crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 > crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 > Tdwuhub0: 1 port with 1 removable, self poweredcbcm28rrt, H , > random: harvesting attach, 8 bytes (4 bits) from uhub0 > ugen0.2: at usbus0 > uhub1 on uhub0 > uhub1: > on usbus0 > uhub1: MTT enabled > Root mount waiting for: usbus0 > uhub1: 5 ports with 4 removable, self powered > random: harvesting attach, 8 bytes (4 bits) from uhub1 > Root mount waiting for: usbus0 > ugen0.3: at usbus0 > smsc0 on uhub1 > smsc0: on usbus0 > random: harvesting attach, 8 bytes (4 bits) from smsc0 > mountroot: waiting for device /dev/mmcsd0s2a... > smsc0: chip 0xec00, rev. 0002 > miibus0: on smsc0 > ukphy0: PHY 1 on miibus0 > ukphy0: OUI 0x00800f, model 0x000c, rev. 3 > ukphy0:=A0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > random: harvesting attach, 8 bytes (4 bits) from ukphy0 > random: harvesting attach, 8 bytes (4 bits) from miibus0 > ue0: on smsc0 > ue0: bpf attached > ue0: Ethernet address: b8:27:eb:be:e6:f8 > Mounting from ufs:/dev/mmcsd0s2a failed with error 19. > Trying to mount root from ufs:mmcsd0s2 []... > mountroot: waiting for device mmcsd0s2... > Mounting from ufs:mmcsd0s2 failed with error 19. >=20 > Loader variables: > =A0 vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a > =A0 vfs.root.mountfrom.options=3Dro >=20 > The device is just.... gone. >=20 > The rpi2.dts file was updated when I updated the source (if that's > involved here), so that should be current.... >=20 > --=20 > Karl Denninger > karl@denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ Hello, I've just fixed the issues in r326951. Sorry for the breakage. Now the only problem is that the growfs bug was mfc'ed and I don't want to mfc my workaround, as Ian said when I commited it it was wrong doing so. I'll see what I can find. Cheers, --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Dec 18 21:20:34 2017 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 388E6E88C84 for ; Mon, 18 Dec 2017 21:20:34 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0E7AD70696 for ; Mon, 18 Dec 2017 21:20:33 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 5864B27335 for ; Mon, 18 Dec 2017 16:20:01 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 482AC108D78 for ; Mon, 18 Dec 2017 15:19:59 -0600 (CST) Subject: Re: RPI2 boot failure with recent changes to u-boot References: <20ad35ef-2166-c429-fad6-21fedef1ff0e@denninger.net> <1513614709.95072.48.camel@freebsd.org> <401bad68-a6f4-ff9f-49e5-431c9441dde7@denninger.net> <4a2c96e1-b1bd-376f-34f5-e1f0163be2ba@denninger.net> <1513620135.95072.70.camel@freebsd.org> <20171218212115.318d72a4b237907ddcb42229@bidouilliste.com> To: freebsd-arm@freebsd.org From: Karl Denninger Message-ID: <88c7c959-8a46-a0f9-2d6f-ac8f76e0c4d6@denninger.net> Date: Mon, 18 Dec 2017 15:19:59 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171218212115.318d72a4b237907ddcb42229@bidouilliste.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020902090602030008060200" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 21:20:34 -0000 This is a cryptographically signed message in MIME format. --------------ms020902090602030008060200 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 12/18/2017 14:21, Emmanuel Vadot wrote: > On Mon, 18 Dec 2017 12:10:07 -0600 > Karl Denninger wrote: > >> ...... >> random: harvesting attach, 8 bytes (4 bits) from sdhci_bcm0 >> uart0: mem 0x201000-0x201fff irq 27 on simple= bus0 >> uart0: console (115200,n,8,1) >> uart0: fast interrupt >> uart0: PPS capture mode: DCDinvalid >> random: harvesting attach, 8 bytes (4 bits) from uart0 >> vchiq0: mem 0xb800-0xb84f irq 28 on simplebus0 >> vchiq: local ver 8 (min 3), remote ver 8. >> pcm0: on vchiq0 >> random: harvesting attach, 8 bytes (4 bits) from pcm0 >> random: harvesting attach, 8 bytes (4 bits) from vchiq0 >> bcm283x_dwcotg0: mem= >> 0x980000-0x99ffff irq 29 on simplebus0 >> usbus0 on bcm283x_dwcotg0 >> bcm283x_dwcotg0: usbpf: Attached >> random: harvesting attach, 8 bytes (4 bits) from usbus0 >> random: harvesting attach, 8 bytes (4 bits) from bcm283x_dwcotg0 >> cpulist0: on ofwbus0 >> cpu0: on cpulist0 >> bcm2835_cpufreq0: on cpu0 >> random: harvesting attach, 8 bytes (4 bits) from cpufreq0 >> random: harvesting attach, 8 bytes (4 bits) from bcm2835_cpufreq0 >> random: harvesting attach, 8 bytes (4 bits) from cpu0 >> cpu1: on cpulist0 >> random: harvesting attach, 8 bytes (4 bits) from cpu1 >> cpu2: on cpulist0 >> random: harvesting attach, 8 bytes (4 bits) from cpu2 >> cpu3: on cpulist0 >> random: harvesting attach, 8 bytes (4 bits) from cpu3 >> random: harvesting attach, 8 bytes (4 bits) from cpulist0 >> fb0: on ofwbus0 >> fbd0 on fb0 >> VT: initialize with new VT driver "fb". >> random: harvesting attach, 8 bytes (4 bits) from fbd0 >> fb0: 656x416(656x416@0,0) 24bpp >> fb0: fbswap: 1, pitch 1968, base 0x3eb33000, screen_size 818688 >> random: harvesting attach, 8 bytes (4 bits) from fb0 >> ofwbus0: compat rpi,rpi-ft5406 (no driver attached) >> gpioled0: on ofwbus0 >> random: harvesting attach, 8 bytes (4 bits) from gpioled0 >> ofwbus0: compat broadcom,bcm2835-power-mgr (no driver atta= ched) >> ofwbus0: compat simple_bus (no driver attached) >> cryptosoft0: >> crypto: assign cryptosoft0 driver id 0, flags 100663296 >> crypto: cryptosoft0 registers alg 1 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 2 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 3 flags 0 maxoplen 0 >> crypto: cryptosoft0 registers alg 4 flags 0 maxoplen 0 >> Tdwuhub0: 1 port with 1 removable, self poweredcbcm28rrt, H , >> random: harvesting attach, 8 bytes (4 bits) from uhub0 >> ugen0.2: at usbus0 >> uhub1 on uhub0 >> uhub1: >> on usbus0 >> uhub1: MTT enabled >> Root mount waiting for: usbus0 >> uhub1: 5 ports with 4 removable, self powered >> random: harvesting attach, 8 bytes (4 bits) from uhub1 >> Root mount waiting for: usbus0 >> ugen0.3: at usbus0 >> smsc0 on uhub1 >> smsc0: on usbus0= >> random: harvesting attach, 8 bytes (4 bits) from smsc0 >> mountroot: waiting for device /dev/mmcsd0s2a... >> smsc0: chip 0xec00, rev. 0002 >> miibus0: on smsc0 >> ukphy0: PHY 1 on miibus0 >> ukphy0: OUI 0x00800f, model 0x000c, rev. 3 >> ukphy0:=C2=A0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, au= to >> random: harvesting attach, 8 bytes (4 bits) from ukphy0 >> random: harvesting attach, 8 bytes (4 bits) from miibus0 >> ue0: on smsc0 >> ue0: bpf attached >> ue0: Ethernet address: b8:27:eb:be:e6:f8 >> Mounting from ufs:/dev/mmcsd0s2a failed with error 19. >> Trying to mount root from ufs:mmcsd0s2 []... >> mountroot: waiting for device mmcsd0s2... >> Mounting from ufs:mmcsd0s2 failed with error 19. >> >> Loader variables: >> =C2=A0 vfs.root.mountfrom=3Dufs:/dev/mmcsd0s2a >> =C2=A0 vfs.root.mountfrom.options=3Dro >> >> The device is just.... gone. >> >> The rpi2.dts file was updated when I updated the source (if that's >> involved here), so that should be current.... >> >> --=20 >> Karl Denninger >> karl@denninger.net >> /The Market Ticker/ >> /[S/MIME encrypted email preferred]/ > Hello, > > I've just fixed the issues in r326951. > Sorry for the breakage. > > Now the only problem is that the growfs bug was mfc'ed and I don't > want to mfc my workaround, as Ian said when I commited it it was wrong > doing so. > I'll see what I can find. > > Cheers, The boot problem is fixed by r326951; it can find the sd card now. Onward.... --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020902090602030008060200 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjE4MjExOTU5 WjBPBgkqhkiG9w0BCQQxQgRAGG/6Eo2zgstJlg5Fi64hV846eV/leqeug4NRMyDukQdM4l0v Owo1Gsjq0v14nefoshplrGqLOBQxkebjIDVCijBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCM1uvrmx6sRSWjwTVmwb8y8b/+BO8vtAPkOidv3tfK0Xun2XXQYIJBaBgujsSOkReu zKunva0mYpXfcnIeU1q4/gNcKjk767u6Nfk/R4BJVyJd9FRo6GOjYXFvwuliW5EHk4nJmhqj GnsPgxgOGuigTnF6exbXbKUJopRLB7Lb14xkBKMbRkrLW76FfufOLpHx35TTNAfy9weyO0Ww P/DguIcX9SyCIn1xUQdSAXQ0H6Z6+bTerD1l0Awglf21UMKzFu1xzOO9jxY4RXqAUKALdFJw PLhkS1JD2E43ZNMZap0VunDoVj5vY2BN+llueKBzvZuwDXH6exwLmoaE6eR0aakr+TS31yKK MUornYTgnNcRQWSEVIHrBw/MhjGe1Q+fGrusbx1Xa3WL1DpfuC2Lys02bAWFnBG8GhzGwEHT qscJkEsyelypzFEi2M/ROBNc4mj2vE1UDKLmieDSjpSw0QNB2q0Q6fAnVQCnh36s4T9wWZwe ISEZg527z9OQ0t1Dafxmb1uJNoHzxwT5pDXTnejt8vQYAXjDPyG/GCYHPIZgyouaTd0XM1jF E/9k0Ot5N7l8IwTsdZpjypU943gGEq9Jw+J1STBGCu9KgDWEIT8SSP8rYg3mY2JP/KlZnQ3d FpleUi3fgSxnFVz+kvYEl9/uwUvtmVXcbRuf3qlt2AAAAAAAAA== --------------ms020902090602030008060200-- From owner-freebsd-arm@freebsd.org Mon Dec 18 21:59:29 2017 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 BD3A4E8BE57 for ; Mon, 18 Dec 2017 21:59:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8149A72AAB for ; Mon, 18 Dec 2017 21:59:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id f190so446452ita.5 for ; Mon, 18 Dec 2017 13:59:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MIjVdfIL9HqOx00WxMjuZR2gnhbj2mYV9Ywi/qeN2G8=; b=Efd2kqC7VTiSfrDU8wPfRzjzJ33Px7GUafSpQ3d2pnveIjdSjN19Th0B2z1Gp1BWZg uDJOZ8illAClrri7nkgHj/1Jhl6eG47AAs6r5PPLmV5JaUrRuVoCgNZmF13+U/8MCUtb 2q50LhnLgCZSuyIXsUzLA4tYoPvSxVE1JqW5J8qvBtD0RdUu2CjLOo5QCbdGbC+AaI8r G+TORAspLdmS/bpz/P36HsGy2UmeWtaJAcX4+erfhup2Cs29Qhy6D8FmChHvSFCIY1PQ L5LmD5+T0c8190but9AmwIqPPph3GJSS1OO0LzdckBUr7QjO6SE/o+GgbAv9FuuU53Og lhhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=MIjVdfIL9HqOx00WxMjuZR2gnhbj2mYV9Ywi/qeN2G8=; b=NbzdwPEG48BR2VfnQoA0VQwkUbiFP900luiUZ/f6aNKi6/L8+6G/9yJOqhrFY1MPJ2 KHWzJbt0AMLjQ8JG1JZOtU7D1xCB4b8Meapk6/+R2KhfrRQ/HPlVCEWGKS+IwgvprMEC S1GUw1qlCHIGWAFkiFBBbFp/IPcx3ZpJC3gMlw1kFYBT+6JY8U3dEXDTueRJQCFOhn/Q uqpaYVmAA3hdGXWobadmcpTXMEu3kCmVBCsXrsGsTvf1VQ9+nWsPq4L1pyy0GcE1DIgn 5+/g3Bva/skJKvwYT62LtZyI1FUkyAFKsQyHrCbYwaNXsrppy2CE5X6G2n1ScXxswup/ o1UQ== X-Gm-Message-State: AKGB3mKrGlu28mCVp1gKZYAVrZuLEC80igB8lxNQcnFVtYEhPMXh1W5L T9apg8U0d2QrOswN6MMGXOPUrRyoHtiDIlH7IqFXrvOX X-Google-Smtp-Source: ACJfBotrTW2xDId4L14L2pD531KnJshF9dzxXSpuy4qoMZ9bfJXTwLfEz0IhCC2dx1syWc1TSlPE2MixIQWdNZ+AkPs= X-Received: by 10.36.133.135 with SMTP id r129mr753019itd.69.1513634368665; Mon, 18 Dec 2017 13:59:28 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Mon, 18 Dec 2017 13:59:27 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171216153225.GA74471@regency.nsu.ru> References: <20171216153225.GA74471@regency.nsu.ru> From: Warner Losh Date: Mon, 18 Dec 2017 14:59:27 -0700 X-Google-Sender-Auth: PG1Ui347fpK3WOGpBziLcon8q8A Message-ID: Subject: Re: How to use our stock armv7-RPI2 images with QEMU? To: Alexey Dokuchaev Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Mon, 18 Dec 2017 21:59:29 -0000 On Sat, Dec 16, 2017 at 8:32 AM, Alexey Dokuchaev wrote: > Hi there, > > I've noticed (per qemu-system-arm -machine help) that it claims to support > Raspberry Pi 2 (raspi2), so I wanted to boot one of our stock armv7-RPI2 > images, but did not find recipe at https://wiki.freebsd.org/QemuRecipes, > and my FreeBSD/arm knowledge is lacking. > > Basically I look for a fast way to setup arm6/7 VM to do some ports work. > > Could someone give me a hand here, and possibly update that wiki page? > (It covers arm64, but not arm). Thanks, > OK. The answer is "It's complicated" and I'm not sure anybody has actually done it recently. The following links may be useful. Sounds like the answer is you have to figure out how much of the SoC qemu is actually doing, and then load u-boot that's been hacked to omit the part of the initialization that causes problems... https://azeria-labs.com/emulate-raspberry-pi-with-qemu/ https://balau82.wordpress.com/2010/04/12/booting-linux-with-u-boot-on-qemu-arm/ https://www.hellion.org.uk/blog/posts/grub-on-uboot-on-qemu/ https://elinux.org/Virtual_Development_Board I'm happy to help in anyway that I can, but I don't have the time to devote to this today. I'm keen to know for both my nanobsd create qemu images for every arch we support project, as well as my create qemu images for every boot env we support to test src/stand project. Warner From owner-freebsd-arm@freebsd.org Mon Dec 18 23:57:19 2017 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 C7970E938FA for ; Mon, 18 Dec 2017 23:57:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E05C779CE for ; Mon, 18 Dec 2017 23:57:19 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBINvJZ0073241 for ; Mon, 18 Dec 2017 23:57:19 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 224440] Upgrade 11.0-STABLE to 11.1-STABLE Date: Mon, 18 Dec 2017 23:57:19 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: torres@cle.unicamp.br X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Mon, 18 Dec 2017 23:57:20 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224440 Bug ID: 224440 Summary: Upgrade 11.0-STABLE to 11.1-STABLE Product: Base System Version: 11.1-STABLE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: torres@cle.unicamp.br Dear, I'm trying to upgrade my FreeBSD 11.0-STABLE (amd64) servers to 11.1-STABLE. I looked for several points where 11.1-STABLE would be unsuccessful. I performed the following steps: mv /usr/src to /usr/src.old and executed svnlite checkout https://svn.FreeBSD.org/base/stable/11 /usr/src svnlite update /usr/src make buildworld make buildkernel make installkernel shutdown -r now To my surprise, only the kernel has upgraded to 11.1-STABLE. # freebsd-version 11.0-STABLE # freebsd-version -k 11.1-STABLE What went wrong? Where do I find the stable sources of version 11.1? Best regards Augusto --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Dec 19 05:04:41 2017 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 58931E86D87 for ; Tue, 19 Dec 2017 05:04:41 +0000 (UTC) (envelope-from 4250.10.freebsd-arm=FreeBSD.org@email-od.com) Received: from bca5.email-od.com (bca5.email-od.com [207.246.239.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2667965027 for ; Tue, 19 Dec 2017 05:04:41 +0000 (UTC) (envelope-from 4250.10.freebsd-arm=FreeBSD.org@email-od.com) DKIM-Signature: v=1; a=rsa-sha256; d=email-od.com;i=@email-od.com;s=dkim; c=relaxed/relaxed; q=dns/txt; t=1513659885; x=1516251885; h=x-thread-info:date:from:to:cc:subject:message-id:in-reply-to:references:mime-version:content-type:content-transfer-encoding; bh=dD1BkkBvJQ0ekFxH3tPMr+NTetJN8vDHWGyPVjACDYA=; b=t3KueFLOMJ80QZdBKL8wpga+SK6Lm8yxNXJAte9NeYwbfDKKdLIgZv/5vcILrbE7LLLDFl/eA2lUHK7aU81XxXTleZRhePrcxOMaCWR5DqT9a3/w3i+916h9i+1Te6WPe/efDivmWHKp2WrGRMVc2hGl2eeBq0u9girHicJOc+k= X-Thread-Info: NDI1MC4xMi44MTAwMDAwMGI3YTg0NS5mcmVlYnNkLWFybT1GcmVlQlNELm9yZw== Received: from r2.us-east.aws.in.socketlabs.com (r2.us-east.aws.in.socketlabs.com [54.85.171.149]) by bca2.email-od.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Tue, 19 Dec 2017 00:04:36 -0500 Received: from smtp.lan.sohara.org (EMTPY [89.127.62.20]) by r2.us-east.aws.in.socketlabs.com with ESMTP(version=Tls12 cipher=Aes256 bits=256); Tue, 19 Dec 2017 00:04:30 -0500 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.89 (FreeBSD)) (envelope-from ) id 1eRA4q-000GK6-QS; Tue, 19 Dec 2017 05:04:28 +0000 Date: Tue, 19 Dec 2017 05:04:28 +0000 From: Steve O'Hara-Smith To: bugzilla-noreply@freebsd.org Cc: freebsd-arm@FreeBSD.org Subject: Re: [Bug 224440] Upgrade 11.0-STABLE to 11.1-STABLE Message-Id: <20171219050428.21d9c1e0d732a080e8976d47@sohara.org> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd11.0) X-Clacks-Overhead: "GNU Terry Pratchett" Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Tue, 19 Dec 2017 05:04:41 -0000 On Mon, 18 Dec 2017 23:57:19 +0000 bugzilla-noreply@freebsd.org wrote: > I performed the following steps: > mv /usr/src to /usr/src.old and executed > svnlite checkout https://svn.FreeBSD.org/base/stable/11 /usr/src > svnlite update /usr/src > make buildworld > make buildkernel > make installkernel > shutdown -r now > To my surprise, only the kernel has upgraded to 11.1-STABLE. That should not be a surprise, you haven't done an installworld (best done in single user mode after installing the kernel) so your newly built world is still sitting in /usr/obj. You have also missed a number of other necessary steps from /usr/src/UPDATING - here's the relevant section: ---------------- To rebuild everything and install it on the current system. ----------------------------------------------------------- # Note: sometimes if you are running current you gotta do more than # is listed here if you are upgrading from a really old current. make buildworld make kernel KERNCONF=YOUR_KERNEL_HERE [1] [3] mergemaster -Fp [5] make installworld mergemaster -Fi [4] make delete-old [6] ------------------ -- Steve O'Hara-Smith From owner-freebsd-arm@freebsd.org Tue Dec 19 07:33:29 2017 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 736A7E9144B for ; Tue, 19 Dec 2017 07:33:29 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 30C7E6A98D for ; Tue, 19 Dec 2017 07:33:28 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.80.20]) by kabab.cs.huji.ac.il with esmtp id 1eRCOv-0006pV-FQ for freebsd-arm@freebsd.org; Tue, 19 Dec 2017 09:33:21 +0200 From: Daniel Braniss Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: missing thermal for allwinner h2/h3 Message-Id: Date: Tue, 19 Dec 2017 09:33:21 +0200 To: freebsd-arm X-Mailer: Apple Mail (2.3445.5.20) 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: Tue, 19 Dec 2017 07:33:29 -0000 hi, will they re appear when pulling in the Linux 4.15 dts? happy seasons, danny From owner-freebsd-arm@freebsd.org Tue Dec 19 16:24:15 2017 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 A5E78E8DFDE for ; Tue, 19 Dec 2017 16:24:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9307380085 for ; Tue, 19 Dec 2017 16:24:15 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBJGOF5H008407 for ; Tue, 19 Dec 2017 16:24:15 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 224050] RPI-B: 11-STABLE cannot mount root Date: Tue, 19 Dec 2017 16:24:15 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.1-STABLE X-Bugzilla-Keywords: regression X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: freebsd@oldach.net X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Tue, 19 Dec 2017 16:24:15 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224050 Helge Oldach changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --- Comment #4 from Helge Oldach --- This appears to be fixed by base r322694 (bug #218344). A manually built FreeBSD-11.1-STABLE-arm-armv6-RPI-B-r326951.img boots and mounts the root u= fs properly. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Dec 19 16:58:31 2017 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 98E7EE900CE for ; Tue, 19 Dec 2017 16:58:31 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B2BB81592 for ; Tue, 19 Dec 2017 16:58:31 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wr0-x234.google.com with SMTP id a41so19877664wra.6 for ; Tue, 19 Dec 2017 08:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :cc:to; bh=Nh50I5qIAGZT0ajG7F42BI5dTYh+5egh/ceNnPkXuzA=; b=VCZuQcyaR6bpsPWVlmMN0/Dj6IwR7eOyAdiPftyj3yaFuVhUQAQHak9iCPyAyaA9OL YiOuBJk8/tDyNb2BmdopMDLCJjyThmQ017dWs67zSRSTmxK52eok7t/YRjfffRPReXiN 3jY6bE0H331yEZOUX/K1N/sJNdduycV/mw+Uwn3wNDpSBvEy+aYhJJy42jqU7oZ1n4+Y lC5rKglNNwGuUtqps965a0NupivhF5jY9X31/++Oo+s7a2kX8jEi0KHN5yBQ67a7sgLK 5pt2y58Px4ymFN7gspXUq9oO0H29Tuu8pUVDmg3p3YSD76HB6o92jcw0ygqyKHULGt53 Hf5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:cc:to; bh=Nh50I5qIAGZT0ajG7F42BI5dTYh+5egh/ceNnPkXuzA=; b=n/HiyxQtLDJFl+fI0Is0RrLEKNaguLTnSpIWq8T7vVmdtSZe0/XO6k25+h4z35mqHY 5WXx+9y/cRBDvsYamYDM7pe2D2NxSiLQbx91WAHpMZ7xLLebwOaMywNSGvGDytqVan7G AxPpb3lzuwb2nVGlAUnp/F+pgJq9eHOrTwx1bc/iM1C91YMogcEHOKaCbomh4+veQaFK Y62TFuzJZWNgwsct3lTaw50mKtfDevpBzrtHtLkiQ/oLFFMTkGYDvPSWpMKbbpFN1UEr kX54nnEeRy0feotGi/xS3xK3nAlEk3xJ+MXha4sQDuG4YS889Zdwm1xwhgjCIRUHXj8X OivA== X-Gm-Message-State: AKGB3mIsKeAYPLDvrcBcr9x8SwbK1GWLuX5Mb64OSWeMz3c50t/yU5+E rWxGyNxVAKCddRxFEPSQssSKgPNU X-Google-Smtp-Source: ACJfBou+/C5oZ9gAsxPsNA5mPix9P72Oxl4ioiA3v13n99B2tNPWS+bYbJ69WUuxW8UzgAtMzFK1fg== X-Received: by 10.223.134.184 with SMTP id 53mr5472339wrx.17.1513702709074; Tue, 19 Dec 2017 08:58:29 -0800 (PST) Received: from [10.118.2.56] ([80.12.37.184]) by smtp.gmail.com with ESMTPSA id j77sm7299578wmf.36.2017.12.19.08.58.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 08:58:28 -0800 (PST) From: Sylvain Garrigues Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Tue, 19 Dec 2017 17:58:27 +0100 Subject: Re: How to use our stock armv7-RPI2 images with QEMU? Message-Id: <07FDE656-3DBA-4EB6-80F5-A7E25051DB37@gmail.com> Cc: Alexey Dokuchaev , "freebsd-arm@freebsd.org" To: Warner Losh X-Mailer: iPhone Mail (15C153) 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: Tue, 19 Dec 2017 16:58:31 -0000 Hello, > Le 18 d=C3=A9c. 2017 =C3=A0 22:59, Warner Losh a =C3=A9cr= it : >=20 >> On Sat, Dec 16, 2017 at 8:32 AM, Alexey Dokuchaev wrote: >>=20 >> Hi there, >>=20 >> I've noticed (per qemu-system-arm -machine help) that it claims to suppor= t >> Raspberry Pi 2 (raspi2), so I wanted to boot one of our stock armv7-RPI2 >> images, but did not find recipe at https://wiki.freebsd.org/QemuRecipes, >> and my FreeBSD/arm knowledge is lacking. >>=20 >> Basically I look for a fast way to setup arm6/7 VM to do some ports work.= >>=20 >> Could someone give me a hand here, and possibly update that wiki page? >> (It covers arm64, but not arm). Thanks, >>=20 >=20 > OK. The answer is "It's complicated" and I'm not sure anybody has actually= > done it recently. The trick that make it work for me is to recompile qemu with one modificatio= n: change KERNEL_LOAD_ADDR to 0x100000 instead of 0x10000 in hw/arm/boot.c Then you can boot the GENERIC kernel with the -kernel kernel.bin option and y= ou may attach the RPI2 snapshot to the VM with the -sd command. You may have to type the boot root fs to mount it at the end of the kernel i= nitialization. Just list the available partitions and adjust.=20 It works pretty well, you even have the RPI framebuffer working.=20 Cheers, Sylvain.=20 From owner-freebsd-arm@freebsd.org Tue Dec 19 18:50:13 2017 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 EBE05E9781A for ; Tue, 19 Dec 2017 18:50:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE06D65621 for ; Tue, 19 Dec 2017 18:50:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6640e7ee-e4ed-11e7-93a5-cd02e7dc7692 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 6640e7ee-e4ed-11e7-93a5-cd02e7dc7692; Tue, 19 Dec 2017 18:49:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id vBJIo5Vr001540; Tue, 19 Dec 2017 11:50:05 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1513709405.29087.2.camel@freebsd.org> Subject: Re: How to use our stock armv7-RPI2 images with QEMU? From: Ian Lepore To: Sylvain Garrigues , Warner Losh Cc: Alexey Dokuchaev , "freebsd-arm@freebsd.org" Date: Tue, 19 Dec 2017 11:50:05 -0700 In-Reply-To: <07FDE656-3DBA-4EB6-80F5-A7E25051DB37@gmail.com> References: <07FDE656-3DBA-4EB6-80F5-A7E25051DB37@gmail.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit 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: Tue, 19 Dec 2017 18:50:14 -0000 On Tue, 2017-12-19 at 17:58 +0100, Sylvain Garrigues wrote: > > The trick that make it work for me is to recompile qemu with one > modification: change KERNEL_LOAD_ADDR to 0x100000 instead of 0x10000 > in hw/arm/boot.c 0x10000 will never work for a freebsd armv6/7 kernel; the kernel must be loaded on a 2MB boundary to work with all SoCs (1MB for most).  It should just be permanently changed (via port patch or upstream or whatever) to 0x200000, which will always work. -- Ian From owner-freebsd-arm@freebsd.org Tue Dec 19 21:36:20 2017 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 99FD1EA1C8C for ; Tue, 19 Dec 2017 21:36:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6127B6C78D for ; Tue, 19 Dec 2017 21:36:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x231.google.com with SMTP id k202so6856528ioe.10 for ; Tue, 19 Dec 2017 13:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=4shE9SAaYUWUA+TD0c/QbmMm+yUSeXGDCnIFgBMrvak=; b=ckEwHcG2UIQyuefpytrKh5X6sYDcZONKxKs5i6t3M4HBSXkgj8IvRY8ToZ3lwTKCS3 yFfYmG3jnpOKNJ0e7zHr4G0STqikZHLR/WOpW50LThogSS+iqtbTbPDQmkN36Jd7ZRWt RQpNd3LEE0vwywP9BR9H3lPtdTLey/Fc1Ida9JF1AXMcuKkHoLruq+0cmFeVCJpVJE9E +vMh14mdgbp7AUsOBp0cTfL/8s9syT3HeogYWEX46g99Mw+YYwRoC9QAupTOARhUiCBN HPrgb8LdFnb2rFVx1RwEbhPe+sjeSWsmnaa5gIhm/KGypTm4FAtHqP4gmLBV0KEiQE6Y ChUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=4shE9SAaYUWUA+TD0c/QbmMm+yUSeXGDCnIFgBMrvak=; b=j68R7FUlSoLQ0hknPNgmvO57BMgV6MLWbULN8jXqvI4hMRoLZa7UiB/7CUZ8bSvtoX 7ABmjFq98RZIURtinUQt8GznSeGb5/i3PjJbGbDjgxDQ3hhDaa1g0pJWP0zrEUS0MWs2 5xS5jgrq3vSy0PT01xR61mFd0JF9XukafS84M90Lyb6Y6IBxG+/U2QGx8VKmgmIb8g8J y97pUW+iJjAWlyIqkmD0F/tCtOqQcMtGucG6/LU2S9Ojk5Pm6nNofOYUy9e7yVSE7IVT 0xmjJmpONnHm/Hvv6rCN3rTaTXRQfxkbjL8cd5zmHfF9C4WzT/Ondcr7XahZohdyeDm/ lpxw== X-Gm-Message-State: AKGB3mI21gSVf00sxBPUTnCO1fOuRKwRMxG/oEYNFgopUKPOtMl2bQ9P 7bsEd7CznYVAMRKE4iV7Z6tnD4spyY8LyrWaAniSAQ== X-Google-Smtp-Source: ACJfBovwYCqNX9CY1VRL46MrCzTOMOzooqxMIbfXZsc5p7GuNWsaqLMK4DPIXo5X4suJbHaPrEABFsQEFFIGoy24Dew= X-Received: by 10.107.18.35 with SMTP id a35mr1500298ioj.291.1513719379595; Tue, 19 Dec 2017 13:36:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:36:18 -0800 (PST) X-Originating-IP: [2607:fb90:6f6a:13fc:4073:f971:9d8e:a305] Received: by 10.79.108.204 with HTTP; Tue, 19 Dec 2017 13:36:18 -0800 (PST) In-Reply-To: <07FDE656-3DBA-4EB6-80F5-A7E25051DB37@gmail.com> References: <07FDE656-3DBA-4EB6-80F5-A7E25051DB37@gmail.com> From: Warner Losh Date: Tue, 19 Dec 2017 14:36:18 -0700 X-Google-Sender-Auth: PB8fB653mgrUjCY4Ehs8fzadV3s Message-ID: Subject: Re: How to use our stock armv7-RPI2 images with QEMU? To: Sylvain Garrigues Cc: Alexey Dokuchaev , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Tue, 19 Dec 2017 21:36:20 -0000 On Dec 19, 2017 9:58 AM, "Sylvain Garrigues" wrote: Hello, > Le 18 d=C3=A9c. 2017 =C3=A0 22:59, Warner Losh a =C3=A9c= rit : > >> On Sat, Dec 16, 2017 at 8:32 AM, Alexey Dokuchaev wrote: >> >> Hi there, >> >> I've noticed (per qemu-system-arm -machine help) that it claims to support >> Raspberry Pi 2 (raspi2), so I wanted to boot one of our stock armv7-RPI2 >> images, but did not find recipe at https://wiki.freebsd.org/QemuRecipes, >> and my FreeBSD/arm knowledge is lacking. >> >> Basically I look for a fast way to setup arm6/7 VM to do some ports work= . >> >> Could someone give me a hand here, and possibly update that wiki page? >> (It covers arm64, but not arm). Thanks, >> > > OK. The answer is "It's complicated" and I'm not sure anybody has actuall= y > done it recently. The trick that make it work for me is to recompile qemu with one modification: change KERNEL_LOAD_ADDR to 0x100000 instead of 0x10000 in hw/arm/boot.c Then you can boot the GENERIC kernel with the -kernel kernel.bin option and you may attach the RPI2 snapshot to the VM with the -sd command. You may have to type the boot root fs to mount it at the end of the kernel initialization. Just list the available partitions and adjust. It works pretty well, you even have the RPI framebuffer working. Any chance the uboot image could be used for the kernel? Warner From owner-freebsd-arm@freebsd.org Tue Dec 19 21:37:54 2017 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 1C5ABEA1E35 for ; Tue, 19 Dec 2017 21:37:54 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-100.reflexion.net [208.70.210.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C210D6C848 for ; Tue, 19 Dec 2017 21:37:53 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 23347 invoked from network); 19 Dec 2017 21:31:12 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 19 Dec 2017 21:31:12 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 19 Dec 2017 16:31:12 -0500 (EST) Received: (qmail 30184 invoked from network); 19 Dec 2017 21:31:12 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Dec 2017 21:31:12 -0000 Received: from [192.168.1.25] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 89B0BEC922F; Tue, 19 Dec 2017 13:31:11 -0800 (PST) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: rpi2 V1.1 vs. hard coded max_execution_time figures in /usr/local/share/poudriere/common.sh (package; also: extract, install, deinstall) Message-Id: Date: Tue, 19 Dec 2017 13:31:10 -0800 To: Bryan Drewery , Freebsd-arm , FreeBSD Ports X-Mailer: Apple Mail (2.3273) 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: Tue, 19 Dec 2017 21:37:54 -0000 I tied building devel/llvm50 on a rpi2 V1.1 via poudriere and it got as far as: . . . =================================================== ===> Building package for llvm50-5.0.0_6 =>> Killing timed out build after 7200 seconds This was for: ---Begin OPTIONS List--- ===> The following configuration options are available for llvm50-5.0.0_6: CLANG=on: Build clang DOCS=on: Build and/or install documentation EXTRAS=on: Extra clang tools LIT=on: Install lit and FileCheck test tools LLD=on: Install lld, the LLVM linker LLDB=on: Install lldb, the LLVM debugger But I had set in /usr/local/etc/poudriere.conf : # This defines the max time (in seconds) that a command may run for a build # before it is killed for taking too long. Default: 86400 #MAX_EXECUTION_TIME=86400 MAX_EXECUTION_TIME=432000 # This defines the time (in seconds) before a command is considered to # be in a runaway state for having no output on stdout. Default: 7200 #NOHANG_TIME=7200 NOHANG_TIME=28800 The magic 7200 is from /usr/local/share/poudriere/common.sh : package) max_execution_time=7200 . . . There is also a lack of control over: extract) max_execution_time=3600 . . . install) max_execution_time=3600 . . . deinstall) max_execution_time=3600 . . . The rpi2 is now busy constructing a bsdtar when it could have had a llvm50 package. (I wonder if the bsdtar takes less time than the package would have taken.) As stands the only way to allow such large builds on the rpi2 is to edit: /usr/local/share/poudriere/common.sh after each poudriere installation/update. The following large things did manage to build packages: lang/gcc7 devel/cmake (indirect from selecting devel/llvm50) (I avoid WITH_DEBUG for devel/llvm50 in all environments: that build is massive, needing between 24 GiBytes and 26 GiBytes for RAM+SWAP on a powerpc64, if I remember right.) Other than the hard coded max_execution_time examples I've no found any fundmental problems with using poudriere when configured as indicated below. (Being willing to give it the time it needed.) For these experiments I've used: NO_ZFS=yes USE_TMPFS=no PARALLEL_JOBS=1 ALLOW_MAKE_JOBS=yes MAX_EXECUTION_TIME=432000 NOHANG_TIME=28800 For what I tried I've not had to use MAKE_JOBS_NUMBER_LIMIT?= or MAKE_JOBS_NUMBER?= . (Say, in /usr/local/etc/poudriere.d/make.conf testing the likes of .if ${.CURDIR:M*/devel/llvm*} code.) The rpi2 has world, kernel, and its dtb file via a USB SSD Stick, not from a usdcard. The usdcard is very minimal as far as its UFS / file system goes: /etc/fstab (redirecting to the USB SSD) /boot/* (with /boot/kernel/ empty and /boot/dtb/ empty) The USB SSD stick has: # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/da0p1 195378 31305 148443 17% / devfs 0 0 0 100% /dev (/dev/da0p1 has a UFS file system.) # swapinfo Device 1K-blocks Used Avail Capacity /dev/da0p2 1572864 16876 1555988 1% === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Dec 19 22:11:06 2017 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 C062EEA3F04 for ; Tue, 19 Dec 2017 22:11:06 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 58D5A6E241 for ; Tue, 19 Dec 2017 22:11:06 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x244.google.com with SMTP id f9so6460316wmh.0 for ; Tue, 19 Dec 2017 14:11:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=PlhL3/1lKRrlML6kF34YinQKQHa679GzPbvAnobxNWU=; b=KuvnXoA1cdiExJMa7qWP5+aW5n3B4mbIJmMV/7WLCJYSnRg8UmuH5VOjjaQ2JjLyfs v6xMn0ZeGwa4/pt9ea/julefNw3ni2ki3msb/J8W/cu16dmpZEKvfHw8DW3uikZWbtd6 E5sYmhrghTqRsHA1NZ5gvU5hJGJ7gnw4G8/YOqH6j39PBgG3Q5dcdYXIVVKBUlji4uf7 6uTgDI96cRpb76ldSMwOQGKQnOebLtZcs4GlJvdIOIfznAklBEkt1Vd8+zyrOloAA3KC KgoVjQTma1CrstUA3U2E263XVblZV/6Lf8SFiK3lubXihTDzvvVfCDT0cekJOWPI5YDg LKcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=PlhL3/1lKRrlML6kF34YinQKQHa679GzPbvAnobxNWU=; b=qwEeF+WrM9LDWij3Vuu3rdfUi95cCEfsYWISHCgefG0iNggaoZgmm7RZahziMm++lU XhHrLYzHgUEZDubqVFrF+lZYSK+pjmW5J5byFBkHbC/bgbRi0PqTvj9vwV+13eSC0N4o /yZaZcPB7mXOYwxwQcH5obnIa9Ee36E9ueGvpHsoG+IVe6g5kLWzk6Yb21YCNmk0lMb0 u2H8EJFhNhNM5inYwVOZEeHbybu+AONdD1X9Tr/OqUcSUH9vWnShYHJ1xeAz+ZDleCFW abNzsTIzpVzqQM+eVviJtuaie3F0g/24o7Xf2CL9zaRsUVN/r+vTixZGOKAE/h81Hg+o 5heg== X-Gm-Message-State: AKGB3mK/BaeLBN7glWeoCBKwiQDfd5Rh5GmeJK19qpXh5x6P+Thsyrga JSKzkgEzACc/xYaquKiwtHsK2xpc X-Google-Smtp-Source: ACJfBotuVNQt7xHsk/bNSlZhCPuWL10Kb+HwvAkybxjjAGVgOy/B/P4p96KSs3he2fxZbL0HU1JQKg== X-Received: by 10.28.35.214 with SMTP id j205mr5025667wmj.72.1513721464648; Tue, 19 Dec 2017 14:11:04 -0800 (PST) Received: from macbook-pro-de-sylvain.home (2a01cb040a681000c13e2b2633da9425.ipv6.abo.wanadoo.fr. [2a01:cb04:a68:1000:c13e:2b26:33da:9425]) by smtp.gmail.com with ESMTPSA id o98sm17909937wrb.40.2017.12.19.14.11.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Dec 2017 14:11:03 -0800 (PST) From: Sylvain Garrigues Message-Id: Content-Type: multipart/mixed; boundary="Apple-Mail=_683BFFD4-2A66-4B1C-BF0F-FEDDF55D9DC0" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Re: How to use our stock armv7-RPI2 images with QEMU? Date: Tue, 19 Dec 2017 23:11:01 +0100 In-Reply-To: Cc: Alexey Dokuchaev , freebsd-arm@freebsd.org To: Warner Losh References: <07FDE656-3DBA-4EB6-80F5-A7E25051DB37@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) 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: Tue, 19 Dec 2017 22:11:06 -0000 --Apple-Mail=_683BFFD4-2A66-4B1C-BF0F-FEDDF55D9DC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Le 19 d=C3=A9c. 2017 =C3=A0 22:36, Warner Losh a =C3=A9cr= it : > Any chance the uboot image could be used for the kernel? As far as I remember, the current u-boot is stuck in an infinite loop = when run in qemu with -kernel u-boot.bin -machine raspi2, during u-boot = mmc initialization.=20 The attached ugly patch made u-boot able to go further and recognize = partitions on the sd image attached to qemu in raspi2 configuration. = This patch was just for fun, I don=E2=80=99t know what side effects it = may have. I actually tested it successfully with qemu aarch64 to load = loader.efi from the RPI3 aarch64 snapshot, but I=E2=80=99m pretty sure = the same patch would allow u-boot to load loader from an RPI2 armv7 = snapshot. Sylvain --Apple-Mail=_683BFFD4-2A66-4B1C-BF0F-FEDDF55D9DC0 Content-Disposition: attachment; filename=u-boot_qemu_raspi2.patch Content-Type: application/octet-stream; x-unix-mode=0644; name="u-boot_qemu_raspi2.patch" Content-Transfer-Encoding: 7bit --- u-boot-c253573/include/configs/rpi.h 2017-11-14 02:08:06.000000000 +0100 +++ u-boot.good/include/configs/rpi.h 2017-11-16 22:28:04.792837000 +0100 @@ -149,9 +149,7 @@ #define BOOT_TARGET_DEVICES(func) \ func(MMC, mmc, 0) \ - func(USB, usb, 0) \ - func(PXE, pxe, na) \ - func(DHCP, dhcp, na) + func(USB, usb, 0) #include #define CONFIG_EXTRA_ENV_SETTINGS \ --- u-boot-c253573/include/config_distro_bootcmd.h 2017-11-14 02:08:06.000000000 +0100 +++ u-boot.good/include/config_distro_bootcmd.h 2017-11-16 22:21:44.676970000 +0100 @@ -390,8 +390,4 @@ "run bootcmd_${target}; " \ "done\0" -#ifndef CONFIG_BOOTCOMMAND -#define CONFIG_BOOTCOMMAND "run distro_bootcmd" -#endif - #endif /* _CONFIG_CMD_DISTRO_BOOTCMD_H */ --- u-boot-c253573/drivers/mmc/bcm2835_sdhci.c 2017-11-14 02:08:06.000000000 +0100 +++ u-boot.good/drivers/mmc/bcm2835_sdhci.c 2017-11-16 22:05:42.589896000 +0100 @@ -79,11 +79,6 @@ * (Which is just as well - otherwise we'd have to nobble the DMA engine * too) */ - if (reg != SDHCI_BUFFER) { - while (timer_get_us() - bcm_host->last_write < - bcm_host->twoticks_delay) - ; - } writel(val, host->ioaddr + reg); bcm_host->last_write = timer_get_us(); --- u-boot-c253573/lib/time.c 2017-11-14 02:08:06.000000000 +0100 +++ u-boot.good/lib/time.c 2017-11-16 22:05:25.047340000 +0100 @@ -150,12 +150,6 @@ void __weak __udelay(unsigned long usec) { - uint64_t tmp; - - tmp = get_ticks() + usec_to_tick(usec); /* get current timestamp */ - - while (get_ticks() < tmp+1) /* loop till event */ - /*NOP*/; } /* ------------------------------------------------------------------------- */ --- u-boot-c253573/Kconfig 2017-11-14 02:08:06.000000000 +0100 +++ u-boot.good/Kconfig 2017-11-16 22:16:47.845851000 +0100 @@ -130,7 +130,7 @@ environments which can tolerate a "non-standard" U-Boot. Use this only if you really know what you are doing. -if EXPERT +if 1 config SYS_MALLOC_CLEAR_ON_INIT bool "Init with zeros the memory reserved for malloc (slow)" default y --- u-boot-c253573/drivers/usb/Kconfig 2017-11-14 02:08:06.000000000 +0100 +++ u-boot.good/drivers/usb/Kconfig 2017-11-16 22:17:08.072527000 +0100 @@ -71,7 +71,7 @@ Say Y here if you want to use a USB keyboard for U-Boot command line input. -if USB_KEYBOARD +if 1 choice prompt "USB keyboard polling" --Apple-Mail=_683BFFD4-2A66-4B1C-BF0F-FEDDF55D9DC0-- From owner-freebsd-arm@freebsd.org Wed Dec 20 13:28:41 2017 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 50843E88E57 for ; Wed, 20 Dec 2017 13:28:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3F4CF6D1E8 for ; Wed, 20 Dec 2017 13:28:41 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBKDSfd0070342 for ; Wed, 20 Dec 2017 13:28:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 224481] Add H3 to aw_sid driver for Allwinner SoC Date: Wed, 20 Dec 2017 13:28:40 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: eval@iptk.ru X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 20 Dec 2017 13:28:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224481 Bug ID: 224481 Summary: Add H3 to aw_sid driver for Allwinner SoC Product: Base System Version: CURRENT Hardware: arm OS: Any Status: New Severity: Affects Many People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: eval@iptk.ru Created attachment 188991 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D188991&action= =3Dedit SID driver patch For the correct operation of the aw_thermal driver, a thermal calibration function is required, presented in the aw_sid driver. However, the driver d= oes not support H3 SoC. It is known that H3 SoC has a hardware bug when reading SID (root key) - see http://linux-sunxi.org/SID_Register_Guide#SID_PRCTL I suggest a patch that more correctly implements the aw_sid driver. DTS to enable the driver device: ... sid: eeprom@1c14000 { compatible =3D "allwinner,sun8i-h3-sid"; reg =3D <0x01c14000 0x400>; }; ... The driver is tested on H2+ SoC (OrangePi Zero) --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Dec 20 14:05:29 2017 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 34F9AE8AD38 for ; Wed, 20 Dec 2017 14:05:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22A3B6E84A for ; Wed, 20 Dec 2017 14:05:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id vBKE5S29071462 for ; Wed, 20 Dec 2017 14:05:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 224481] Add H3 to aw_sid driver for Allwinner SoC Date: Wed, 20 Dec 2017 14:05:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: manu@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: Not A Bug X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 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: Wed, 20 Dec 2017 14:05:29 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D224481 Emmanuel Vadot changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Progress |Closed Resolution|--- |Not A Bug --- Comment #2 from Emmanuel Vadot --- Patch moved to phabricator, closing this entry. https://reviews.freebsd.org/D13556 --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Wed Dec 20 17:02:47 2017 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 CE09BE964D4 for ; Wed, 20 Dec 2017 17:02:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AAC5C777B5 for ; Wed, 20 Dec 2017 17:02:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBKH2i9w016150 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Dec 2017 09:02:45 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBKH2ib1016149; Wed, 20 Dec 2017 09:02:44 -0800 (PST) (envelope-from fbsd) Date: Wed, 20 Dec 2017 09:02:44 -0800 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171220170244.GA16029@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) 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: Wed, 20 Dec 2017 17:02:47 -0000 On an RPI2 at r326951 a pl2303 usb-serial adapter seems to be locking up after a few hours. In the past this could be rectified by using usbconfig to power cycle it, but now even that doesn't work. Apart from the serial device file vanishing from /dev there seems to be no other ill effect. Rebooting fixes the problem for minutes to hours. There is no explict error report in dmesg, but when usbconfig tries to power cycle the adapter the console reports: uhub_explore_handle_re_enumerate: Could not unconfigure device (ignored) usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored) usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_IOERROR usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_STALLED, ignored) usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_STALLED A second RPI2 running r326747 is subject to the same lockup, but the adapter can be unstuck using usbconfig to power cycle it. Are there any diagnostics which could shed more light on the problem? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Dec 20 18:53:10 2017 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 48133E9CAA2 for ; Wed, 20 Dec 2017 18:53:10 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [67.205.158.196]) by mx1.freebsd.org (Postfix) with ESMTP id 1FEBE7BBD3 for ; Wed, 20 Dec 2017 18:53:09 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 438A127335 for ; Wed, 20 Dec 2017 13:52:39 -0500 (EST) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id 54CF310A3B8 for ; Wed, 20 Dec 2017 12:52:37 -0600 (CST) To: "freebsd-arm@freebsd.org" From: Karl Denninger Subject: Ugh -- Pi2 problem that appears to have come from a roll-forward of microcode Message-ID: <8d8256e2-98ec-40b2-c878-4eac1d12fb0b@denninger.net> Date: Wed, 20 Dec 2017 12:52:36 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms020708050707060702080702" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Wed, 20 Dec 2017 18:53:10 -0000 This is a cryptographically signed message in MIME format. --------------ms020708050707060702080702 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've seen this one before.... Some months back I started playing with newer bootcode and dtb files on the RPI2, and rolled them back after running into serious problems with the unit not always progressing beyond the "ue0" device probe.=C2=A0 That= is, the unit would get to the "ue0" line, print it, and then lock up. ^C was ineffective on the console and sometimes - but not always - after a couple of minutes it would unlock.=C2=A0 The rest of the time, however,= you were dead unless you pulled power and restarted. This is back on 11.STABLE builds, and it appears to be linked to the roll-forward of the bootcode and DTB files that was somewhat-recently committed.=C2=A0 I was forced to go back to the older files. IMHO this needs some attention as a lockup during the device probe is a bad thing, obviously. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms020708050707060702080702 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMjIwMTg1MjM2 WjBPBgkqhkiG9w0BCQQxQgRAXGTl8OPVKfIFBxEtLjZKP4oMtUJbYSCunB8TARsyRijAgk0h C8nCcNyJVWWWcCBljiQSr69Cs+L2bXARkJ+aBjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgCvYwhfCeM/pOi3SsHK15T+C4ZR9fgIQMDLA+vwuh6b6Xej3c8sNgRHs8C0NDzuWEKy I0rPwfoBPett6Dbqtis6YZ+bcE6Wb6OD6cpn4HrEL6U2gsEWAWV4ERUwWPfK8A/aiU4yR49O gVcLNyZn3aQBJQWx0fRjsXlfr9dDXGYuWjNZ/eAuXOCSubCqPzmmRmICKX0hB7eAPyQsf4nK 7MVg6oREUmQ+ZVDXgTWC2e1T0ZRwNsRJy8+M2Qi67NRBsWVZTH1Ril2t8gVrbrxFh3Q5+qEA RGh1P3AONRNJZ8Ntvgdne1vmyh+W7xuDfGjUdol5EMSY9gyPkH1qvlYTvMQ8PxSlI2crgmvX yqYyJE/RRTOKOtkPMjwipWRMcKkklvZv0babMVZCWbX4zHd2+IcYeGbwUv0Sd8wVX9yq2+oC EjqSR/5ofkYk0FfX4+Vrn+ie1TEr06Grctu3RIpT0GLx16Vy8Rw9EIVS5nITJfM40qNhl14n bx4KshGZxyqmevdAbpQr3WZ8RaiRY9KOyFqhq21SG1mlZu3bOkVUeIshN/OyFxZIZbz0G4xx e+mYM+asKecPTPQ8lx47/+qYc7Xh+0DOFAWRQd1EevbfcX3Ry3QxFor752lB89v3POSMBsR+ rzKsoLGrhUngACw6nZ8qk4ktKeC9nJse/XqieXOvoQAAAAAAAA== --------------ms020708050707060702080702-- From owner-freebsd-arm@freebsd.org Wed Dec 20 19:13:18 2017 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 43490E9DBF8 for ; Wed, 20 Dec 2017 19:13:18 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B869F7CA9D for ; Wed, 20 Dec 2017 19:13:17 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x229.google.com with SMTP id r143so25215117lfe.13 for ; Wed, 20 Dec 2017 11:13:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MViMI5EAIJbNn8Gr8d+SujniA+XIKmHY5rq6BwqAlLA=; b=Pjfnu6Fb8z3AEkAjbq12fTWGQKLR0y7pq62P7KjSN7d7X4PnEAyiD01cL2SqeVeUYM 8zr8fFP2LNN9mr3BoUaRqU7jaf2HBCkzpl+8WR6zuWnrSddAgEkZKk8mSYig9AJaKZEu mabBYY12LZysXkP9IzICaRLKqGcpnPizfKUpZsl9dK2/t6rtI8EH8Vm8CZPSC2W2tmFz YTCJI59oc07XFq42VHytIv7BQEqqFU98kupHlmuTTOqeuOKZGA/NuL06+AeRJdLctqop HVOTfRhiKw6hUPUBBlp7odAHMrZwOaCQh1DOVQ6PVmVEY8kr0a+kS6LyV2Lt8gDkrIke 6tKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MViMI5EAIJbNn8Gr8d+SujniA+XIKmHY5rq6BwqAlLA=; b=LncKucfWX4HqfDD15Ud6xelz+uKhrJBBAQ7Ig/ZAfADYDj1P7+PidcUAFlspF35boP ng4PYQA/U4azAIMfyoKuSvBmWAzba4MOK/txDTfHRmxbACZaehJznsSboBCDGhbXhbFS BS7FKHjdUk0s7w9Cc414rRJhRnwQdxvAn7Hs0w9qCnbWohUiuQbSuIxRu4bBE9OMOqT/ QNjm4ZLg80dUfr08LJHxMjzZlx6t6xyDqlRmp+x0n13bIDOEpTf3vz8bthO4AYU6ORzU OIGy3g4e/RQkK1CgnmLiTK/1D1UneQOlIACEG/buZ48qte9rwAY6UgUElOeEri3GJq1+ bH6g== X-Gm-Message-State: AKGB3mIFuDM6CYsp2Y4W/OrXlNCZiFJjYtxkll9qFpHYSGItiNx4g6gA Bh9ykHz9dqwXLYvN/7iM+4Vh/A== X-Google-Smtp-Source: ACJfBosoTVYIPN6o/PWhfLxRoanctBez7AwJagP1od7yfuhYcZF+4pEt8s4jzAWuHjzdd+1Q+lByLA== X-Received: by 10.25.163.17 with SMTP id m17mr5242792lfe.88.1513797195137; Wed, 20 Dec 2017 11:13:15 -0800 (PST) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id 71sm3765289ljr.68.2017.12.20.11.13.14 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Dec 2017 11:13:14 -0800 (PST) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 To: freebsd-arm@freebsd.org References: <20171220170244.GA16029@www.zefox.net> From: "Jukka A. Ukkonen" Message-ID: Date: Wed, 20 Dec 2017 21:13:12 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171220170244.GA16029@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit 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: Wed, 20 Dec 2017 19:13:18 -0000 On 12/20/17 19:02, bob prohaska wrote: > On an RPI2 at r326951 a pl2303 usb-serial adapter seems to be locking up > after a few hours. In the past this could be rectified by using usbconfig > to power cycle it, but now even that doesn't work. Apart from the serial > device file vanishing from /dev there seems to be no other ill effect. > Rebooting fixes the problem for minutes to hours. > > There is no explict error report in dmesg, but when usbconfig tries to power > cycle the adapter the console reports: > > uhub_explore_handle_re_enumerate: Could not unconfigure device (ignored) > usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored) > usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_IOERROR > usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_STALLED, ignored) > usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_STALLED > > > A second RPI2 running r326747 is subject to the same lockup, but the adapter > can be unstuck using usbconfig to power cycle it. > > > Are there any diagnostics which could shed more light on the problem? > > Thanks for reading, > > bob prohaska > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > I have tried some ch341 based USB<->RS232 adapter cables which cause a similar problem when connected to any normal USB. Apparently what happens is that the voltage pump and the fanout needed to drive the RS232 draw so much current that it exceed the standard USB power output capacity, the poor ch341 becomes starved, crashes, and reboots. As a result it disappears from the USB channel for a while and then reappears again. The pl2303 based adapter cables which I have tried seem to behave just fine, though. Then again, I have not tested them with RPI. It is quite possible that larger systems can easily drive the 500 mA required by the original USB spec. I would not bet my money on the RPI doing the same thing all effortlessly. ;-) So, my guess is that the poor RPI is unable to drive enough power to your pl2303. Esp. when there are multiple USB devices draining power you will eventually exceed the RPI's power output capacity. As a result you will see a magically vanishing and reappearing USB device. Try connecting your USB gizmos through a USB hub which is equipped with a separate power unit. Typically the power units feeding RPIs are rated around 1A. You only need two USB devices consuming the whole allowed 500 mA to exceed that 1A. Then something is going to fail, either the RPI itself or one of the USB devices. --jau From owner-freebsd-arm@freebsd.org Thu Dec 21 08:08:49 2017 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 795A0E84770 for ; Thu, 21 Dec 2017 08:08:49 +0000 (UTC) (envelope-from jon@brawn.org) Received: from ahs1.r4l.com (ahs1.r4l.com [198.27.81.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 434677B526 for ; Thu, 21 Dec 2017 08:08:48 +0000 (UTC) (envelope-from jon@brawn.org) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=brawn.org; s=default; h=To:Date:Message-Id:Subject:Mime-Version:Content-Type:From: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=tjAT+OL3dMP7dbhKf2Y0FSBdlJ5almboOsiBNaJ4gyg=; b=ZBez9yWQFq9ExjRNJck1tru31s 3W8HYHVAexBB9EJPGIDQAkNTIfWDb9zQZqyYg1m2gDD2Eg79g2+mJM/urwyWixinAAh5SKi++43tT pw2sSfflrFr3BV8DtphrRaKc7XkSS/BvPW6w0pQq28RE6GFDdXzwBA1XTwsw7rtX/tFAKJ7JgW5zW I7Mk3Z7MWBD/EvuwDgMU+VeVptDq4VcCdpfw9WZ5kwukL99GxtElcDQtT5e75QHHWPoA4P6NZD94e 9bnY4Vek72AdJfB/b9mel6nBLQHJM3rfdcZNcHvlDsgPEZgrd1hKt8bm20FYAP0+HSdEZqFmIIiqX vYKHE1Sw==; Received: from [136.62.171.86] (port=57449 helo=[192.168.1.120]) by ahs1.r4l.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eRv1e-002Rfw-80 for freebsd-arm@freebsd.org; Thu, 21 Dec 2017 02:12:18 -0500 From: Jon Brawn Content-Type: multipart/signed; boundary="Apple-Mail=_E6DE8485-825D-4EA4-A2BF-223F77E0D4A5"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Subject: Is there a SoftIron Overdrive 1000 expert in the house? Message-Id: Date: Thu, 21 Dec 2017 01:12:16 -0600 To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3445.5.20) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ahs1.r4l.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brawn.org X-Get-Message-Sender-Via: ahs1.r4l.com: authenticated_id: jon@brawn.org X-Authenticated-Sender: ahs1.r4l.com: jon@brawn.org X-Source: X-Source-Args: X-Source-Dir: X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Thu, 21 Dec 2017 08:08:49 -0000 --Apple-Mail=_E6DE8485-825D-4EA4-A2BF-223F77E0D4A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Wotcha! I=E2=80=99ve managed to upset my Overdrive 1000 by trying to upgrade it = to 12.0-CURRENT, r326820. It used to boot from the internal hard drive with an older version of = 12.0. Now it is unhappy; it now starts up, prints the early info, prints the bit about pressing ESCAPE for boot options, then drops into = the UEFI Interactive shell stuff: UEFI Interactive Shell v2.1 EDK II UEFI v2.60 (SoftIron Overdrive 1000, 0x00010000) Mapping table FS0: Alias(s):HD0b65535a1:;BLK1: = PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT,07AA3FF3-E61A-11E7= -A2B0-E0FFF70020A6,0x28,0x64000) BLK0: Alias(s): PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0) BLK2: Alias(s): = PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(2,GPT,07AAD8D0-E61A-11E7= -A2B0-E0FFF70020A6,0x64028,0x73F9BFF8) BLK3: Alias(s): = PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(3,GPT,07AC2C1B-E61A-11E7= -A2B0-E0FFF70020A6,0x74000020,0x706D67) Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell>=20 Any ideas about what I do to get it to look for the kernel in = /dev/ada0p2, in /boot/=E2=80=A6 ? I=E2=80=99m new to UEFI, having never used it before. Thanks for any help y=E2=80=99all can offer. Jon.= --Apple-Mail=_E6DE8485-825D-4EA4-A2BF-223F77E0D4A5 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILEzCCBSUw ggQNoAMCAQICECQcc6QQWc3Um5HgAnmjhBYwDQYJKoZIhvcNAQELBQAwgZcxCzAJBgNVBAYTAkdC MRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoT EUNPTU9ETyBDQSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNh dGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBMB4XDTE3MTAyODAwMDAwMFoXDTE4MTAyODIzNTk1OVow HjEcMBoGCSqGSIb3DQEJARYNam9uQGJyYXduLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALEscuT73gkjXEfkaQU3QXOOIDFilHr9RV/FKPk+ZO3wyXpoChqRW+anE+kKBLSCsmoX 6HnhAmcq3j9umj5jIYwpD84m26XbWQK+uo42GZ3cAF12VvO0g/toUvI+nJcxiD39APWowPKQ4Nae 4FN4hLOcwd2zyF3LiJgq4aXXcBQxl2s1JRCb7STFl5qpp73JVbFp1MkABmESyzI6KE0LLH3hHICU d2m+Omg6L8T+RgsTEKmgTvw1hYD04ms9ttji/viI8LtR3V9p9DDGH0iSCF56kPo4WfsbfGVBs1km tw8uvB6OVNGiD0q05kR/GI4jGiMLa4UhlCC0VsYfx7ZyGEUCAwEAAaOCAeMwggHfMB8GA1UdIwQY MBaAFIKvbIz4xf6WYXzoHz0rcUhexIvAMB0GA1UdDgQWBBRYtBFf7BnRYLxKWDc5DiI35q5WVzAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGy MQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYI KwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMFoGA1UdHwRTMFEwT6BNoEuG SWh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1JTQUNsaWVudEF1dGhlbnRpY2F0aW9uYW5k U2VjdXJlRW1haWxDQS5jcmwwgYsGCCsGAQUFBwEBBH8wfTBVBggrBgEFBQcwAoZJaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2xpZW50QXV0aGVudGljYXRpb25hbmRTZWN1cmVFbWFp bENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMBgGA1UdEQQRMA+B DWpvbkBicmF3bi5vcmcwDQYJKoZIhvcNAQELBQADggEBAKZgWVdxinnS81TZvPWc8kXjtzxKSBFU 6ZXBkofX+CSRuD+Wmg4vlt6fNIaVWqWDF95qjR3TOwyb+LQJnsMyYhAl9NI6AJTxgfghzKK49MVP aC0K7V4TnWCiucJsfK+xDqZIevPFPF3mpYz7/Uf8VPbX2uK80/uUoBRroXDLyHv7fTzG8K+bHBh6 l2x2xFB04nxAhRS4yaJvOeV6ckPOHvCgHhncXQ1HoPUvV/M94K3jaURLPvSUm2tgzODJ97QDHDWM SF7xfItpAM7AVAmN0M0U8sWI/qDykqpoeOc/TrMNeRTEcuphuJASMuN+oP57T+XZFq/lOEEIw1H+ 4QZ1mnIwggXmMIIDzqADAgECAhBqm+E4O/8ra58B1dm4p1JWMA0GCSqGSIb3DQEBDAUAMIGFMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDErMCkGA1UEAxMiQ09NT0RPIFJTQSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTAeFw0xMzAxMTAwMDAwMDBaFw0yODAxMDkyMzU5NTlaMIGXMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQgQXV0 aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAL6znlesKHZ1QBbHOAOY08YYdiFQ8yV5C0y1oNF9Olg+nKcxLqf2NHbZhGra0D00SOTq 9bus3/mxgUsg/Wh/eXQ0pnp8tZ8XZWAnlyKMpjL+qUByRjXCA6RQyDMqVaVUkbIr5SU0RDX/kSsK wer3H1pT/HUrBN0X8sKtPTdGX8XAWt/VdMLBrZBlgvnkCos+KQWWCo63OTTqRvaq8aWccm+KOMjT cE6s2mj6RkalweyDI7X+7U5lNo6jzC8RTXtVV4/Vwdax720YpMPJQaDaElmOupyTf1Qib+cpukNJ nQmwygjD8m046DQkLnpXNCAGjuJy1F5NATksUsbfJAr7FLUCAwEAAaOCATwwggE4MB8GA1UdIwQY MBaAFLuvfgI9+qbxPISOre44mOzZMjLUMB0GA1UdDgQWBBSCr2yM+MX+lmF86B89K3FIXsSLwDAO BgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNVHSAECjAIMAYGBFUdIAAwTAYD VR0fBEUwQzBBoD+gPYY7aHR0cDovL2NybC5jb21vZG9jYS5jb20vQ09NT0RPUlNBQ2VydGlmaWNh dGlvbkF1dGhvcml0eS5jcmwwcQYIKwYBBQUHAQEEZTBjMDsGCCsGAQUFBzAChi9odHRwOi8vY3J0 LmNvbW9kb2NhLmNvbS9DT01PRE9SU0FBZGRUcnVzdENBLmNydDAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUAA4ICAQB4XLKBKDRPPO5fVs6fl1bsj6Jr F/bz9kkIBtTYLzXN30D+03Hj6OxCDBEaIeNmsBhrJmuubvyE7HtoSmR809AgcYboW+rcTNZ/8u/H v+GTrNI/AhqX2/kiQNxmgUPt/eJPs92Qclj0HnVyy9TnSvGkSDU7I5Px+TbO+88G4zipA2psZaWe EykgzClZlPz1FjTCkk77ZXp5cQYYexE6zeeN4/0OqqoAloFrjAF4o50YJafX8mnahjp3I2Y2mkjh k0xQfhNqbzlLWPoT3m7j7U26u7zg6swjOq8hITYc3/np5tM5aVyu6t99p17bTbY7+1RTWBviN9YJ zK8HxzObXYWBf/L+VGOYNsQDTxAk0Hbvb1j6KjUhg7fO294F29QIhhmiNOr84JHoy+fNLpfvYc/Q 9EtFOI5ISYgOxLk3nD/whbUe9rmEQXLp8MB933Ij474gwwCPUpwv9mj2PMnXoc7mbrS22XUSeTwx CTP9bcmUdp4jmIoWfhQm7X9w/Zgddg+JZ/YnIHOwsGsaTUgj7fIvxqith7DoJC91WJ8Lce3CVJqb 1XWeKIJ84F7YLXZN0oa7TktYgDdmQVxYkZo1c5noaDKH9Oq9cbm/vOYRUM1cWcef20Wkyk5S/GFy yPJwG0fR1nRas3DqAf4cXxMiEKcff7PNa4M3RGTqH0pWR8p6EjGCA7cwggOzAgEBMIGsMIGXMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3Jk MRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09NT0RPIFJTQSBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZzdSbkeACeaOEFjAJBgUr DgMCGgUAoIIB3zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEy MjEwNzEyMTdaMCMGCSqGSIb3DQEJBDEWBBSKqLh421RNGMaJ00pNbxP6EjJwRjCBvQYJKwYBBAGC NxAEMYGvMIGsMIGXMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAw DgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE9MDsGA1UEAxM0Q09N T0RPIFJTQSBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQJBxzpBBZ zdSbkeACeaOEFjCBvwYLKoZIhvcNAQkQAgsxga+ggawwgZcxCzAJBgNVBAYTAkdCMRswGQYDVQQI ExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMT0wOwYDVQQDEzRDT01PRE8gUlNBIENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg U2VjdXJlIEVtYWlsIENBAhAkHHOkEFnN1JuR4AJ5o4QWMA0GCSqGSIb3DQEBAQUABIIBAKNxhkvo pzOb2dldqpwFP0OEEsPIu73EtNW0BRedua8PnH+Jsu0BbCYsa2ROT8d0NnBrGlqQhQ/H9IuAklZc SxmcGxdGVWTLKu/PBVmv95Ss1RLtHpusi+eYsxDYM01dDPm843Am7XAZJ7EMVfpJl0Orx19G8x2G aKDsAWnv9iTGx0f1Cns4GaT6DpygbkJDk+ZZIRClJj/KQbt3L2NEXEiiH998cpPteC70GLQfXqQq D49LodDuL8/y/8kUhF5AVQHLwsgMYsny57xnyIGamtwlwjztuar1xAR7yZyEO6jJf6gfdq7DPduS 1EsjigoGhY+HFkO8nq1YnRIBVEIVzRcAAAAAAAA= --Apple-Mail=_E6DE8485-825D-4EA4-A2BF-223F77E0D4A5-- From owner-freebsd-arm@freebsd.org Thu Dec 21 14:50:42 2017 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 B1136E9B9CB for ; Thu, 21 Dec 2017 14:50:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E628693D5 for ; Thu, 21 Dec 2017 14:50:42 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-lf0-x22e.google.com with SMTP id f13so28200130lff.12 for ; Thu, 21 Dec 2017 06:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=+pH80cHc7aKlb/5sQ67CM165vOQ20EedO9UuwkRdnmM=; b=rUtNYPnr9e7c3BomwJzF5LXJBdC/LJhvP2Pd+2ayYt6dVRC0doNOgHm9TZglGTSCzW 1TqrwXayNyDqwJFMRZff2xaKEJgthJ+2IF/i3p0Y7Av4tIZMfXdVN+2Kgq7T2xOK2oxc 8fcoKqjAsqBtrtVXYQe7/z9bkCI7A556/2OICWt/+M72q5c+aUjmOs6bc9w99+INRQb8 y3pvkw9nPZ1D2zR0rnvYfyI+wuwO7N+vx8X/UnGsMND4EqrEvQ/x3GDeF3C5q3wM6GYf yFP1ogooERj60DV3U8llGLE4URF2mRebwDFNVZWAikQPOdOHKIgBTT0s2SnSQBE3vRfv eLKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=+pH80cHc7aKlb/5sQ67CM165vOQ20EedO9UuwkRdnmM=; b=NCr2DBpkE2SJoWdOY0LRDpgvjTLhJi0w7ncnOp8gpTnPUnib3yjLrETBPGlsj4hzyJ FP0bRPVedjaoospb77xMI5w+6hIyT40aOhX77Eq5Ci653nf182Gwb4v2jrqnwqwQfByp 345qTZEA2Q+tq33XQ84WZ1XmEjD0JEfx6is6YQWqMK3+jd/M8jlPJjx1VA23hbSiqC7m YlwiC+Y+vHX4FYSGLS0SiNZVQG+Z6AkdmX+5uCdaesgGf6dfdso6Bvrd2ccat/F4FVTB aHVAIKQqcAnMDj3VN8MI6SELD9pmjqdm+uadgQg7mDDaO9na5GGVtxQ+mNgT/6a/ehL+ SqlA== X-Gm-Message-State: AKGB3mI0y6Yg/tWdh7JFavq2HZTdXLrqWRDca8VAD/w4/rihg6PJeLic yzcS+xXauBXsViDN+5yOR6lVrg== X-Google-Smtp-Source: ACJfBov+BhBQTiYvgQzbvlqRZ25o8TzcNOEqqqX7/x/I2Hkw5IoCoJF8HpwURxVapyEdvPth4+d/pQ== X-Received: by 10.46.29.67 with SMTP id d64mr6716832ljd.139.1513867839854; Thu, 21 Dec 2017 06:50:39 -0800 (PST) Received: from mutt-hbsd (tor-exit1-readme.dfri.se. [171.25.193.77]) by smtp.gmail.com with ESMTPSA id j8sm4104761lje.83.2017.12.21.06.50.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 21 Dec 2017 06:50:38 -0800 (PST) Date: Thu, 21 Dec 2017 09:50:31 -0500 From: Shawn Webb To: Jon Brawn Cc: freebsd-arm@freebsd.org, imp@freebsd.org Subject: Re: Is there a SoftIron Overdrive 1000 expert in the house? Message-ID: <20171221145031.wbfbjazgpy2k5sp3@mutt-hbsd> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7qtgsp3sdv7kyvfu" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD mutt-hbsd 12.0-CURRENT FreeBSD 12.0-CURRENT X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: NeoMutt/20171027 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: Thu, 21 Dec 2017 14:50:42 -0000 --7qtgsp3sdv7kyvfu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 21, 2017 at 01:12:16AM -0600, Jon Brawn wrote: > Wotcha! >=20 > I???ve managed to upset my Overdrive 1000 by trying to upgrade it to 12.0= -CURRENT, r326820. >=20 > It used to boot from the internal hard drive with an older version of 12.= 0. Now it is unhappy; it now starts up, >=20 > prints the early info, >=20 > prints the bit about pressing ESCAPE for boot options, then drops into th= e UEFI Interactive shell stuff: >=20 > UEFI Interactive Shell v2.1 > EDK II > UEFI v2.60 (SoftIron Overdrive 1000, 0x00010000) > Mapping table > FS0: Alias(s):HD0b65535a1:;BLK1: > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT,07AA3FF= 3-E61A-11E7-A2B0-E0FFF70020A6,0x28,0x64000) > BLK0: Alias(s): > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0) > BLK2: Alias(s): > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(2,GPT,07AAD8D= 0-E61A-11E7-A2B0-E0FFF70020A6,0x64028,0x73F9BFF8) > BLK3: Alias(s): > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(3,GPT,07AC2C1= B-E61A-11E7-A2B0-E0FFF70020A6,0x74000020,0x706D67) > Press ESC in 1 seconds to skip startup.nsh or any other key to continue. > Shell>=20 >=20 > Any ideas about what I do to get it to look for the kernel in /dev/ada0p2= , in /boot/??? ? >=20 > I???m new to UEFI, having never used it before. >=20 > Thanks for any help y???all can offer. I wonder if this is due to the boot unification work Warner Losh is doing. I've CC'd him on this email. Thanks, --=20 Shawn Webb Cofounder and Security Engineer HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --7qtgsp3sdv7kyvfu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEKrq2ve9q9Ia+iT2eaoRlj1JFbu4FAlo7yjQACgkQaoRlj1JF bu4HUhAAs0X6cUnU3Oxpp1jiBnXKpM9zF0/UBB3IB4XUHaW98v78Lkl0COOJ2IvA rdqM/Butwqu1CVcKBitZbUFqkwSJRHlRFq6L87tv5m0Z1/N4z274W4czODJJAaxp mF6VIuYliuenSbmc1UVv1pe8g9gxmMnoHFzD4YhR9i9C+eX9ZcB5B8H2MIzm07wN tg7hLPJ7j8lyKuvdzAdYCb5mTWvLCHejEOCSfir6WQAdOqHNYvZ3PPeg/ziaDLC1 W6GPm/kvTXE+P7oAydKF/TU5g+KFCjVsAxUA8Wl+chWlb5MS8u+PgXSqAh/q5jVI CbF5pEPAJygAKgzUsfnF229FBejahSAhtPdGMFddFJeakvoQ81NTD0oZe5g9JuQY rp2ai9+zHE57nTeFOsLnxyDy5ct664mMkMmBer4IH/QVz0zN6b8HUw0VQBPCxEjZ yLgwOO1WR4rsK79WIwhjdtX3y2pZoKk34Uu8FZBeNlm/WNG2yRthibjhEY8ZceCi kfhYmqS/5zD/5tyKTTVfQga42wJ8OpvJcGmlyQRj/ij6c+0f0Fqumvy11RaGaEZM 8xAdj81ebb/ZmAem8mWj7AXHfCQDwYkceacRtAdhIcjounglSGlSrIIoIgDPxRxZ B79sZb9eVeKSv92VfYxTxtO1CDpz6xI6pYYLUd3ZKG5ZWy2cc34= =gSO6 -----END PGP SIGNATURE----- --7qtgsp3sdv7kyvfu-- From owner-freebsd-arm@freebsd.org Thu Dec 21 14:54:13 2017 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 EFB15E9BE88 for ; Thu, 21 Dec 2017 14:54:13 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66A8F69749 for ; Thu, 21 Dec 2017 14:54:12 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 3c7f91a4; Thu, 21 Dec 2017 15:54:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=uPiYEsMyJrQnpqXrraXUrZZm3/4=; b=A7lp99w3kZ9XV395I0aWsmdzZvpi AS5w21zmuEcgT11XuBbxVuTyUbPPFLOm7PMLcFLg/Vl9GBdy7S6I643vEoKxIY3C 53ql1ABDBmvA/3Nn91hAmvatxslNwMop6N29N76wxQDhqe3x1Q56CSZ75S3xslzR EqinmNDGXRyuJLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=Q3hY1tPMbnrjR4Z7JMqVQcePwneeW17yU7xaId6VUYKocNxdpZcRyCXx KwgAJ25x+wxdMFKtK49XbKcFil61CkhKAdDlDMiCe6cpnSRjgOaJsMJOomvJ+Ltx 9q0DYfoAfnaT/jzIpcLW8ceuE6rPOzO2FXcHP3rh2XvF8VJPXUc= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e50d7d91 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 21 Dec 2017 15:54:03 +0100 (CET) Date: Thu, 21 Dec 2017 15:54:02 +0100 From: Emmanuel Vadot To: Jon Brawn Cc: freebsd-arm@freebsd.org Subject: Re: Is there a SoftIron Overdrive 1000 expert in the house? Message-Id: <20171221155402.d0fffb529fd7cf363b35fb53@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: Thu, 21 Dec 2017 14:54:14 -0000 On Thu, 21 Dec 2017 01:12:16 -0600 Jon Brawn wrote: > Wotcha! >=20 > I?ve managed to upset my Overdrive 1000 by trying to upgrade it to 12.0-C= URRENT, r326820. >=20 > It used to boot from the internal hard drive with an older version of 12.= 0. Now it is unhappy; it now starts up, >=20 > prints the early info, >=20 > prints the bit about pressing ESCAPE for boot options, then drops into th= e UEFI Interactive shell stuff: >=20 > UEFI Interactive Shell v2.1 > EDK II > UEFI v2.60 (SoftIron Overdrive 1000, 0x00010000) > Mapping table > FS0: Alias(s):HD0b65535a1:;BLK1: > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT,07AA3FF= 3-E61A-11E7-A2B0-E0FFF70020A6,0x28,0x64000) > BLK0: Alias(s): > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0) > BLK2: Alias(s): > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(2,GPT,07AAD8D= 0-E61A-11E7-A2B0-E0FFF70020A6,0x64028,0x73F9BFF8) > BLK3: Alias(s): > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(3,GPT,07AC2C1= B-E61A-11E7-A2B0-E0FFF70020A6,0x74000020,0x706D67) > Press ESC in 1 seconds to skip startup.nsh or any other key to continue. > Shell>=20 >=20 > Any ideas about what I do to get it to look for the kernel in /dev/ada0p2= , in /boot/? ? >=20 > I?m new to UEFI, having never used it before. >=20 > Thanks for any help y?all can offer. >=20 > Jon. What happens when you directly select the drive in the firmware ? --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Dec 21 16:11:23 2017 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 BB289EA0101 for ; Thu, 21 Dec 2017 16:11:23 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 270BB6C0CB for ; Thu, 21 Dec 2017 16:11:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBLGBLKF020394 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Dec 2017 08:11:21 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBLGBKwW020393; Thu, 21 Dec 2017 08:11:21 -0800 (PST) (envelope-from fbsd) Date: Thu, 21 Dec 2017 08:11:20 -0800 From: bob prohaska To: "Jukka A. Ukkonen" Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171221161120.GA20324@www.zefox.net> References: <20171220170244.GA16029@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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: Thu, 21 Dec 2017 16:11:23 -0000 On Wed, Dec 20, 2017 at 09:13:12PM +0200, Jukka A. Ukkonen wrote: > On 12/20/17 19:02, bob prohaska wrote: > > On an RPI2 at r326951 a pl2303 usb-serial adapter seems to be locking up > > after a few hours. In the past this could be rectified by using usbconfig > > to power cycle it, but now even that doesn't work. Apart from the serial > > device file vanishing from /dev there seems to be no other ill effect. > > Rebooting fixes the problem for minutes to hours. > > > > There is no explict error report in dmesg, but when usbconfig tries to power > > cycle the adapter the console reports: > > > > uhub_explore_handle_re_enumerate: Could not unconfigure device (ignored) > > usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_IOERROR > > usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_STALLED, ignored) > > usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_STALLED > > > > > > A second RPI2 running r326747 is subject to the same lockup, but the adapter > > can be unstuck using usbconfig to power cycle it. > > > > > > Are there any diagnostics which could shed more light on the problem? > > > > Thanks for reading, > > > > bob prohaska > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > > > > So, my guess is that the poor RPI is unable to drive enough power > to your pl2303. Esp. when there are multiple USB devices draining > power you will eventually exceed the RPI's power output capacity. > As a result you will see a magically vanishing and reappearing USB > device. The Pi is on a 2.5 amp power supply, the other usb loads are a keyboard, mouse and USB flash drive, so it's unlikely to be a power issue. The problem seems to have gotten worse with the latest -current, which is what motivated my post. It's been suggested to simply give up on pl2303 devices and use ftdi but I've resisted the urge because the pl2303 adapters work fine on Mac OS and Raspbian. The adapters work correctly with Prolific's drivers and are not identified as impostors. Testing disclosed that unpowering the USB end of the adapter does not suffice to unstick it, but unpowering both ends does allow it to reset. Hopefully it's an initialization issue. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Thu Dec 21 16:19:52 2017 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 5BC42EA0C23 for ; Thu, 21 Dec 2017 16:19:52 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0B00F6C59D for ; Thu, 21 Dec 2017 16:19:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBLGJhvt032045; Thu, 21 Dec 2017 08:19:43 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBLGJhpM032044; Thu, 21 Dec 2017 08:19:43 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712211619.vBLGJhpM032044@pdx.rh.CN85.dnsmgr.net> Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 In-Reply-To: <20171221161120.GA20324@www.zefox.net> To: bob prohaska Date: Thu, 21 Dec 2017 08:19:43 -0800 (PST) CC: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Thu, 21 Dec 2017 16:19:52 -0000 > On Wed, Dec 20, 2017 at 09:13:12PM +0200, Jukka A. Ukkonen wrote: > > On 12/20/17 19:02, bob prohaska wrote: > > > On an RPI2 at r326951 a pl2303 usb-serial adapter seems to be locking up > > > after a few hours. In the past this could be rectified by using usbconfig > > > to power cycle it, but now even that doesn't work. Apart from the serial > > > device file vanishing from /dev there seems to be no other ill effect. > > > Rebooting fixes the problem for minutes to hours. > > > > > > There is no explict error report in dmesg, but when usbconfig tries to power > > > cycle the adapter the console reports: > > > > > > uhub_explore_handle_re_enumerate: Could not unconfigure device (ignored) > > > usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored) > > > usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_IOERROR > > > usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_STALLED, ignored) > > > usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_STALLED > > > > > > > > > A second RPI2 running r326747 is subject to the same lockup, but the adapter > > > can be unstuck using usbconfig to power cycle it. > > > > > > > > > Are there any diagnostics which could shed more light on the problem? > > > > > > Thanks for reading, > > > > > > bob prohaska > > > > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > > > > > > > > > > > So, my guess is that the poor RPI is unable to drive enough power > > to your pl2303. Esp. when there are multiple USB devices draining > > power you will eventually exceed the RPI's power output capacity. > > As a result you will see a magically vanishing and reappearing USB > > device. > > The Pi is on a 2.5 amp power supply, the other usb loads are a keyboard, > mouse and USB flash drive, so it's unlikely to be a power issue. The problem > seems to have gotten worse with the latest -current, which is what motivated > my post. It's been suggested to simply give up on pl2303 devices and use > ftdi but I've resisted the urge because the pl2303 adapters work fine on > Mac OS and Raspbian. > > The adapters work correctly with Prolific's drivers and are not identified > as impostors. Testing disclosed that unpowering the USB end of the adapter > does not suffice to unstick it, but unpowering both ends does allow it to > reset. Hopefully it's an initialization issue. What do you mean by unpowering both ends? If this is one of the serial adapters that has a power pin to plug in with the Gnd/Rx/Tx pins I would highly recommend you leave that power pin disconnected as connecting it can lead to power supplies in parallel and "that is a bad thing". > Thanks for reading! > > bob prohaska > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Thu Dec 21 16:31:58 2017 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 9FF31EA235C for ; Thu, 21 Dec 2017 16:31:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6800F6D0E8 for ; Thu, 21 Dec 2017 16:31:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 56882260362; Thu, 21 Dec 2017 17:31:54 +0100 (CET) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 To: bob prohaska , "Jukka A. Ukkonen" Cc: freebsd-arm@freebsd.org References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> From: Hans Petter Selasky Message-ID: Date: Thu, 21 Dec 2017 17:29:05 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171221161120.GA20324@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Thu, 21 Dec 2017 16:31:58 -0000 On 12/21/17 17:11, bob prohaska wrote: > On Wed, Dec 20, 2017 at 09:13:12PM +0200, Jukka A. Ukkonen wrote: >> On 12/20/17 19:02, bob prohaska wrote: >>> On an RPI2 at r326951 a pl2303 usb-serial adapter seems to be locking up >>> after a few hours. In the past this could be rectified by using usbconfig >>> to power cycle it, but now even that doesn't work. Apart from the serial >>> device file vanishing from /dev there seems to be no other ill effect. >>> Rebooting fixes the problem for minutes to hours. >>> >>> There is no explict error report in dmesg, but when usbconfig tries to power >>> cycle the adapter the console reports: >>> >>> uhub_explore_handle_re_enumerate: Could not unconfigure device (ignored) >>> usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_IOERROR >>> usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_STALLED, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_STALLED >>> >>> >>> A second RPI2 running r326747 is subject to the same lockup, but the adapter >>> can be unstuck using usbconfig to power cycle it. Hi, You might want to run "usbdump" with the appropriate arguments to capture all USB traffic during such a cycle. Further, you might want to only enable USB HUB debug messages to figure out why the USB stack thinks the device is going away: sysctl hw.usb.uhub.debug=17 From what I know, the RPI series of cards have a small external USB HUB on the board. All USB traffic goes through this High-Speed HUB. When you are using LOW and FULL speed, all traffic is translated from High-Speed USB into LOW and FULL speed USB. I don't rule out some kind of "bug" in this external piece of hardware. You might also try to set (my wild guess): sysctl hw.usb.no_cs_fail=1 Like already mentioned in this thread, the micro USB power input connecter on the RPI is not supposed to handle more than 500mA, regardless of how strong your power supply is. Then you need to subtract the mA's used by the CPU and other chips like ethernet. I wouldn't be surprised if ethernet functionality alone required 150mA at +5V. USB LOW/HIGH/FULL speed all use some kind of pull-UP or pull-DOWN on the data lines. This resistors are typically wired to +5V or GND (0V) on the board and transients in the voltage may be seen as a disconnect by the host or device. Regarding the DTB's. Make sure the USB data pins are correctly configured with regards to pullup/pulldown and not used as GPIOs. --HPS From owner-freebsd-arm@freebsd.org Thu Dec 21 17:57:44 2017 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 0B7AAEA67E7 for ; Thu, 21 Dec 2017 17:57:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D278270B34 for ; Thu, 21 Dec 2017 17:57:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id k202so13653549ioe.10 for ; Thu, 21 Dec 2017 09:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=nVDQFwPxblcY3pcqLNNQ0H5Slw2pUPuYhcZ7l9mF7Xc=; b=EmeN4sb6lt/RZDjNO0ads/u4YYT+q76JDxkvnmJs4pWgQojbbl77cT2EY9PxwXERYO 3e6hY4bHm0ztHfcMNpdX6HaPzvVpO21GsDM3Lbqd4he8Mt3FyI29zfKDJI2zYRV/+Od9 IZ5wUetG9SKINtWf080J6FH1yVWaQhVHvL0sUPATNQPYNSZRo+/9h/o4J3zMQAUhWS0C zHpS9bsaCxiY5bov3Ci2fc79sZpVDluL1Yc1R7AdpZJUFYd3QliMGfSNL7XzOMUltm3b g8fIcplRvF8jljFzez+7A8NQvTdEWAX3MjVFnsPUkK3HhGlDf32is+dy9THSjlhVLR5z paeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=nVDQFwPxblcY3pcqLNNQ0H5Slw2pUPuYhcZ7l9mF7Xc=; b=QszshJy1u5UrGDnWlAJmM7PkyEkl7NgO80FCR6pwAXJgI/P/nGsFWF+/5NuEKnZIUx p03W57+d2SVc9onAPDmwnlsAKEGWvB6zMdNtfP2tYCZygN7gWADnogWY/9GOdiNf3u7L kBDr653gqcu+mz2WwlEtHQ8RehOC2tWC6j3he1+M/I2sm+nF1J5F3M24zqOluZnBJmZi FNcoeSxpGlFdL4zvvhPBlAA5oLTCswl8JsD02r0Q5T79NzEEny+5tJj+2nxsaYsMQ9g4 n7Tb1DG+yFFOFSutEhZQl8Jbl3BD6ewcadwSess6X/f5qaJiMj4XEk43LSCwHJ+Wt3in Ix0g== X-Gm-Message-State: AKGB3mJeY7SX8/s4QqlJYEKzrPzxzIJsjUuiyCllVNVxt2E9jzCB9qh9 d4Lqn73MbrokJ3YzsD1vlxrLTn3PfjDOCiDBNX7/qQ== X-Google-Smtp-Source: ACJfBosXdO5cJVK6k0710/rj8CVUG8SW+QjY+cWRRsxzWra/il4ZPxibYhA+lHl8oZYOoTrBCoDmZb9Vojxrd2hOskI= X-Received: by 10.107.48.197 with SMTP id w188mr14564824iow.301.1513879062899; Thu, 21 Dec 2017 09:57:42 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Thu, 21 Dec 2017 09:57:42 -0800 (PST) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <20171221155402.d0fffb529fd7cf363b35fb53@bidouilliste.com> References: <20171221155402.d0fffb529fd7cf363b35fb53@bidouilliste.com> From: Warner Losh Date: Thu, 21 Dec 2017 10:57:42 -0700 X-Google-Sender-Auth: OO9fvf5psmiztuyU0bZ6q31_SJQ Message-ID: Subject: Re: Is there a SoftIron Overdrive 1000 expert in the house? To: Emmanuel Vadot Cc: Jon Brawn , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 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: Thu, 21 Dec 2017 17:57:44 -0000 On Thu, Dec 21, 2017 at 7:54 AM, Emmanuel Vadot wrote: > On Thu, 21 Dec 2017 01:12:16 -0600 > Jon Brawn wrote: > > > Wotcha! > > > > I?ve managed to upset my Overdrive 1000 by trying to upgrade it to > 12.0-CURRENT, r326820. > > > > It used to boot from the internal hard drive with an older version of > 12.0. Now it is unhappy; it now starts up, > > > > prints the early info, > > > > prints the bit about pressing ESCAPE for boot options, then drops into > the UEFI Interactive shell stuff: > > > > UEFI Interactive Shell v2.1 > > EDK II > > UEFI v2.60 (SoftIron Overdrive 1000, 0x00010000) > > Mapping table > > FS0: Alias(s):HD0b65535a1:;BLK1: > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT, > 07AA3FF3-E61A-11E7-A2B0-E0FFF70020A6,0x28,0x64000) > > BLK0: Alias(s): > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0) > > BLK2: Alias(s): > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(2,GPT, > 07AAD8D0-E61A-11E7-A2B0-E0FFF70020A6,0x64028,0x73F9BFF8) > > BLK3: Alias(s): > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(3,GPT, > 07AC2C1B-E61A-11E7-A2B0-E0FFF70020A6,0x74000020,0x706D67) > > Press ESC in 1 seconds to skip startup.nsh or any other key to continue. > > Shell> > > > > Any ideas about what I do to get it to look for the kernel in > /dev/ada0p2, in /boot/? ? > > > > I?m new to UEFI, having never used it before. > > > > Thanks for any help y?all can offer. > > > > Jon. > > What happens when you directly select the drive in the firmware ? > r326820 is broken for many key scenarios, including zfs boot. Please try r326888 or newer. Warner From owner-freebsd-arm@freebsd.org Thu Dec 21 18:04:44 2017 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 7ABBDEA6C96 for ; Thu, 21 Dec 2017 18:04:44 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E725370F6E for ; Thu, 21 Dec 2017 18:04:43 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id ed2912cb; Thu, 21 Dec 2017 19:04:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=XijCWjRzIgnOdm7p7CGaJqu7pHY=; b=COW1R4oqByW8R0/kbupHVmqDnQxj q8sIyDMj4tUpl8gV4t24XIipTBZyDhvIlSHyNioJx6wY/rjf3iQfo3QhqXply87b sbN6nnIsrSAeyFLlD1kTXhUJQkQ1AvfbjTFYF+sB6+m0ClYa0V0mvYhoMhLI2aIs 3PgyD4mjtL7wIYs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=idUp0cQotf/sdcTtIcm4V3DQqbAhvhT6+HobB6zjNPYnwnMZmfzuTd76 EHothQu8r1dzvOhyg+7K0a/360xxwIn6Vuh9NDeA1qvgSQDG2wHZxRk7tzx3hHew zs4KJA67Q0C55FtEv61BwAFtAAtXH3i7c3toplj6jGBP6SIWKdE= Received: from arcadia.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id d1802c86 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 21 Dec 2017 19:04:40 +0100 (CET) Date: Thu, 21 Dec 2017 19:04:38 +0100 From: Emmanuel Vadot To: Warner Losh Cc: Jon Brawn , "freebsd-arm@freebsd.org" Subject: Re: Is there a SoftIron Overdrive 1000 expert in the house? Message-Id: <20171221190438.c7dafefedf022fc8090a3da0@bidouilliste.com> In-Reply-To: References: <20171221155402.d0fffb529fd7cf363b35fb53@bidouilliste.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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: Thu, 21 Dec 2017 18:04:44 -0000 On Thu, 21 Dec 2017 10:57:42 -0700 Warner Losh wrote: > On Thu, Dec 21, 2017 at 7:54 AM, Emmanuel Vadot > wrote: > > > On Thu, 21 Dec 2017 01:12:16 -0600 > > Jon Brawn wrote: > > > > > Wotcha! > > > > > > I?ve managed to upset my Overdrive 1000 by trying to upgrade it to > > 12.0-CURRENT, r326820. > > > > > > It used to boot from the internal hard drive with an older version of > > 12.0. Now it is unhappy; it now starts up, > > > > > > prints the early info, > > > > > > prints the bit about pressing ESCAPE for boot options, then drops into > > the UEFI Interactive shell stuff: > > > > > > UEFI Interactive Shell v2.1 > > > EDK II > > > UEFI v2.60 (SoftIron Overdrive 1000, 0x00010000) > > > Mapping table > > > FS0: Alias(s):HD0b65535a1:;BLK1: > > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT, > > 07AA3FF3-E61A-11E7-A2B0-E0FFF70020A6,0x28,0x64000) > > > BLK0: Alias(s): > > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0) > > > BLK2: Alias(s): > > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(2,GPT, > > 07AAD8D0-E61A-11E7-A2B0-E0FFF70020A6,0x64028,0x73F9BFF8) > > > BLK3: Alias(s): > > > PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(3,GPT, > > 07AC2C1B-E61A-11E7-A2B0-E0FFF70020A6,0x74000020,0x706D67) > > > Press ESC in 1 seconds to skip startup.nsh or any other key to continue. > > > Shell> > > > > > > Any ideas about what I do to get it to look for the kernel in > > /dev/ada0p2, in /boot/? ? > > > > > > I?m new to UEFI, having never used it before. > > > > > > Thanks for any help y?all can offer. > > > > > > Jon. > > > > What happens when you directly select the drive in the firmware ? > > > > r326820 is broken for many key scenarios, including zfs boot. Please try > r326888 or newer. > > Warner The fact that it drop directly into the efi shell worries me a bit. I had problem like that on my Overdrive and had too re-select boot media in the firmware. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Dec 22 02:19:17 2017 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 2779EE9D731 for ; Fri, 22 Dec 2017 02:19:17 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F29A62D3E for ; Fri, 22 Dec 2017 02:19:16 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBM2J9cW021758 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Dec 2017 18:19:10 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBM2J9Lr021757; Thu, 21 Dec 2017 18:19:09 -0800 (PST) (envelope-from fbsd) Date: Thu, 21 Dec 2017 18:19:09 -0800 From: bob prohaska To: "Rodney W. Grimes" Cc: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171222021909.GB20324@www.zefox.net> References: <20171221161120.GA20324@www.zefox.net> <201712211619.vBLGJhpM032044@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712211619.vBLGJhpM032044@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 22 Dec 2017 02:19:17 -0000 On Thu, Dec 21, 2017 at 08:19:43AM -0800, Rodney W. Grimes wrote: > > What do you mean by unpowering both ends? > If this is one of the serial adapters that has a power pin > to plug in with the Gnd/Rx/Tx pins I would highly recommend > you leave that power pin disconnected as connecting it can > lead to power supplies in parallel and "that is a bad thing". > -- > Rod Grimes rgrimes@freebsd.org I should have written "disconnecting". The red wire wasn't in use. In the past unplugging and replugging the pl2303's usb connector by itself wouldn't allow FreeBSD to recognize the adapter, it was necessary to also unplug the data pigtails. The same appears true now; the adapter wasn't recognized by FreeBSD, despite repeated disconnect/reconnect cycles of the usb connector, but removed to an RPI3 (running Raspbian) it was recognized immediately. When moved back to the RPI2 running -current, it was recognized and at the moment seems to behave normally. For now I'll just leave it alone to see how long it stays up. I've got four of these adapters, and they all seem to exhibit the same behavior, but not to the same extent, among the four RPI2's on my local network. Two FTDI usb/serial adapters were substituted for the two most troublesome pl2303 devices, and all was well until the update to r326951. Is there a way to determine where/what is getting stuck? There seem to be at least three possibilities: usb, ucom and uplcom. Other usb devices seem unaffected. Thanks for reading, and any suggestions. bob prohaska From owner-freebsd-arm@freebsd.org Fri Dec 22 04:17:00 2017 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 8F73BEA44B0 for ; Fri, 22 Dec 2017 04:17:00 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5909766747 for ; Fri, 22 Dec 2017 04:16:59 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBM4GwxN022105 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Dec 2017 20:16:59 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBM4Gvow022104; Thu, 21 Dec 2017 20:16:57 -0800 (PST) (envelope-from fbsd) Date: Thu, 21 Dec 2017 20:16:57 -0800 From: bob prohaska To: Hans Petter Selasky Cc: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171222041657.GA21799@www.zefox.net> References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 22 Dec 2017 04:17:00 -0000 Hi Hans, On Thu, Dec 21, 2017 at 05:29:05PM +0100, Hans Petter Selasky wrote: > On 12/21/17 17:11, bob prohaska wrote: > > On Wed, Dec 20, 2017 at 09:13:12PM +0200, Jukka A. Ukkonen wrote: > >> On 12/20/17 19:02, bob prohaska wrote: > >>> On an RPI2 at r326951 a pl2303 usb-serial adapter seems to be locking up > >>> after a few hours. In the past this could be rectified by using usbconfig > >>> to power cycle it, but now even that doesn't work. Apart from the serial > >>> device file vanishing from /dev there seems to be no other ill effect. > >>> Rebooting fixes the problem for minutes to hours. > >>> > >>> There is no explict error report in dmesg, but when usbconfig tries to power > >>> cycle the adapter the console reports: > >>> > >>> uhub_explore_handle_re_enumerate: Could not unconfigure device (ignored) > >>> usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_IOERROR, ignored) > >>> usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_IOERROR > >>> usbd_req_re_enumerate: addr=9, set address failed! (USB_ERR_STALLED, ignored) > >>> usbd_setup_device_desc: getting device descriptor at addr 9 failed, USB_ERR_STALLED > >>> > >>> > >>> A second RPI2 running r326747 is subject to the same lockup, but the adapter > >>> can be unstuck using usbconfig to power cycle it. > > Hi, > > You might want to run "usbdump" with the appropriate arguments to > capture all USB traffic during such a cycle. > I'll try it next time the pl2303 locks up. > Further, you might want to only enable USB HUB debug messages to figure > out why the USB stack thinks the device is going away: > > sysctl hw.usb.uhub.debug=17 > I've turned that on, and the console is spitting out a lot of output. It'll make quite a haystack in which to find a needle 8-) Any hint what to look for? > From what I know, the RPI series of cards have a small external USB HUB > on the board. All USB traffic goes through this High-Speed HUB. When you > are using LOW and FULL speed, all traffic is translated from High-Speed > USB into LOW and FULL speed USB. > Would changing the baudrate have any effect? A console certainly needn't run at 115200 baud. For present purposes 9600 or less is plenty. > I don't rule out some kind of "bug" in this external piece of hardware. > Many have said pl2303 devices are unreliable, but they seem well-behaved on a Mac and on an RPI3 running Raspbian. Whatever is wrong, it seems not deterministic, but cumulative, with a touch of random. > You might also try to set (my wild guess): > sysctl hw.usb.no_cs_fail=1 > Not sure I understand what this does; is there a description somewhere? > Like already mentioned in this thread, the micro USB power input > connecter on the RPI is not supposed to handle more than 500mA, > regardless of how strong your power supply is. Then you need to subtract > the mA's used by the CPU and other chips like ethernet. I wouldn't be > surprised if ethernet functionality alone required 150mA at +5V. > Some time ago I put a voltmeter on the Pi and the voltage stayed over five volts, but of course short spikes weren't visible in such a test. On average, however, the connector seemed to handle the load. > USB LOW/HIGH/FULL speed all use some kind of pull-UP or pull-DOWN on the > data lines. This resistors are typically wired to +5V or GND (0V) on the > board and transients in the voltage may be seen as a disconnect by the > host or device. > > Regarding the DTB's. Make sure the USB data pins are correctly > configured with regards to pullup/pulldown and not used as GPIOs. > Wouldn't that sort of error lead to things not working at all? The problems observed develop after hours or sometimes days. Many thanks for your guidance! bob prohaska From owner-freebsd-arm@freebsd.org Fri Dec 22 08:02:50 2017 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 6A8E9E8772F for ; Fri, 22 Dec 2017 08:02:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2E7CC6C8B2 for ; Fri, 22 Dec 2017 08:02:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBM82kUB035489; Fri, 22 Dec 2017 00:02:46 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBM82kZp035488; Fri, 22 Dec 2017 00:02:46 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712220802.vBM82kZp035488@pdx.rh.CN85.dnsmgr.net> Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 In-Reply-To: <20171222021909.GB20324@www.zefox.net> To: bob prohaska Date: Fri, 22 Dec 2017 00:02:46 -0800 (PST) CC: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Fri, 22 Dec 2017 08:02:50 -0000 > On Thu, Dec 21, 2017 at 08:19:43AM -0800, Rodney W. Grimes wrote: > > > > What do you mean by unpowering both ends? > > If this is one of the serial adapters that has a power pin > > to plug in with the Gnd/Rx/Tx pins I would highly recommend > > you leave that power pin disconnected as connecting it can > > lead to power supplies in parallel and "that is a bad thing". > > -- > > Rod Grimes rgrimes@freebsd.org > > I should have written "disconnecting". The red wire wasn't in use. Good! That eliminates one source of potential "phase of moon" type problems. > In the past unplugging and replugging the pl2303's usb connector > by itself wouldn't allow FreeBSD to recognize the adapter, it was > necessary to also unplug the data pigtails. This is a very odd symptom, and leads me to a rare, but possible, cause of the problem, latch up. It is very strange that a device would not reset itself when its primary source of power is removed, but rather requires a ground path and possible low voltage input source to be removed before it properly resets. Cmos latchup could exibit that behavior, a next test would be to just remove the gnd pin from the data end next time the connection stops working and see if that clears the fault. You could also try removing and replacing the data end one pin at a time and see if the fault clears after any one of these, I am suspecting a latch condition in the FTDI TX pin output buffer caused by out of range voltage caused most likely by excess cable/capacitance induced ringing. > > The same appears true now; the adapter wasn't recognized by FreeBSD, > despite repeated disconnect/reconnect cycles of the usb connector, > but removed to an RPI3 (running Raspbian) it was recognized immediately. Perhaps damage to the I/O cell protection diodes over time has lead to an easy latch up condition. > When moved back to the RPI2 running -current, it was recognized and > at the moment seems to behave normally. For now I'll just leave it > alone to see how long it stays up. > > I've got four of these adapters, and they all seem to exhibit the > same behavior, but not to the same extent, among the four RPI2's on > my local network. Two FTDI usb/serial adapters were substituted for > the two most troublesome pl2303 devices, and all was well until the > update to r326951. > > Is there a way to determine where/what is getting stuck? There seem > to be at least three possibilities: usb, ucom and uplcom. Other usb > devices seem unaffected. > > Thanks for reading, and any suggestions. > > bob prohaska > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Dec 22 17:24:00 2017 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 F3652EA5B24 for ; Fri, 22 Dec 2017 17:24:00 +0000 (UTC) (envelope-from jbeich@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 DC05B7F91C for ; Fri, 22 Dec 2017 17:24:00 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id DAF8FEA5B23; Fri, 22 Dec 2017 17:24:00 +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 DA5DBEA5B22; Fri, 22 Dec 2017 17:24:00 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B8FAD7F91B; Fri, 22 Dec 2017 17:24:00 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 105246ADB; Fri, 22 Dec 2017 17:24:00 +0000 (UTC) From: Jan Beich To: Mark Linimon Cc: Adam Weinberger , arm@freebsd.org, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r456893 - head/security/1password-client References: <201712210854.vBL8swMK033835@repo.freebsd.org> Date: Fri, 22 Dec 2017 18:23:48 +0100 In-Reply-To: <201712210854.vBL8swMK033835@repo.freebsd.org> (Mark Linimon's message of "Thu, 21 Dec 2017 08:54:58 +0000 (UTC)") Message-ID: <1sjm-wuaj-wny@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" 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: Fri, 22 Dec 2017 17:24:01 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Mark Linimon writes: > Author: linimon > Date: Thu Dec 21 08:54:58 2017 > New Revision: 456893 > URL: https://svnweb.freebsd.org/changeset/ports/456893 > > Log: > The ARCH value of 'arm' is only for arm v4/v5 which are antique. Let's > try to let it build on aarch64 instead. >=20=20=20 > Approved by: portmgr (tier-2 blanket) > > Modified: > head/security/1password-client/Makefile > > Modified: head/security/1password-client/Makefile > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > --- head/security/1password-client/Makefile Thu Dec 21 08:44:38 2017 (r45= 6892) > +++ head/security/1password-client/Makefile Thu Dec 21 08:54:58 2017 (r45= 6893) > @@ -9,7 +9,7 @@ MASTER_SITES=3D https://cache.agilebits.com/dist/1P/op/p > MAINTAINER=3D adamw@FreeBSD.org > COMMENT=3D 1Password CLI client >=20=20 > -ONLY_FOR_ARCHS=3D amd64 arm i386 > +ONLY_FOR_ARCHS=3D aarch64 amd64 i386 Are you sure aarch64 can run 32bit binaries? This port installs a blob, so whether it builds is largerly irrelevant. $ tar xkvf /usr/ports/distfiles/op_freebsd_arm_v0.1.1.zip x op x op.sig $ file op op: ELF 32-bit LSB executable, ARM, EABI5 version 1 (FreeBSD), statically= linked, stripped Runtime testing: $ ssh ref12-aarch64.freebsd.org $ ./op zsh: exec format error: ./op vs. $ qemu-aarch64-static ./op Error loading ./op vs. $ qemu-arm-static ./op runtime: this system has multiple CPUs and must use atomic synchronization instructions. Recompile using GOARM=3D7. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQF8BAEBCgBmBQJaPT+kXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXREQjQ0MzY3NEM3RDIzNTc4NkUxNDkyQ0VF NEM3Nzg4MzQ3OURCRERCAAoJEOTHeINHnb3bQYwH/3gP/N/NypXQ1itxnMRHJTbu GHDeqCfjwY6j9iy91gNuAyrrkxugZufofYgn2Avr9V/9DGCzfBPvQZ4niyfArn4r R+2Hi9T3tnJPusf0U6UVgaKzihQ5fBypzRBAH8fXfdng6+wL3/YO5UEf7u2T5X8b AGp+97oOGbHdSlNC6YIxn0+Yz40S1HHo2hzByel7097f5AKhdZonYEwFuPBVkDxy vin0J7WWCDresFDHrOEmHFCwskxe2NIeOYLwrb63pcUhL5gq7eFBZhsUcv63CvNJ VJTgF7qL2cqWN2wxPh88EANEsnyHfO/ADDIU0JV3/iu8MjkrkcBiYi5j/e4Qcoc= =hKjG -----END PGP SIGNATURE----- --=-=-=-- From owner-freebsd-arm@freebsd.org Fri Dec 22 17:30:55 2017 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 CC206EA603B for ; Fri, 22 Dec 2017 17:30:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 95B327FBF6 for ; Fri, 22 Dec 2017 17:30:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBMHUrB9024194 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Dec 2017 09:30:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBMHUqdP024193; Fri, 22 Dec 2017 09:30:52 -0800 (PST) (envelope-from fbsd) Date: Fri, 22 Dec 2017 09:30:52 -0800 From: bob prohaska To: Hans Petter Selasky Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171222173052.GA23984@www.zefox.net> References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171222041657.GA21799@www.zefox.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 22 Dec 2017 17:30:55 -0000 > > On Thu, Dec 21, 2017 at 05:29:05PM +0100, Hans Petter Selasky wrote: > > Further, you might want to only enable USB HUB debug messages to figure > > out why the USB stack thinks the device is going away: > > > > sysctl hw.usb.uhub.debug=17 > > > Tried it here, using usbconfig to power cycle the adapter. Console output follows. The pl2303 is at unit 0 address 5. Console output follows: [initial state is pl2303 stuck, no /dev/cuaU0 present, command is usbconfig -u 0 -a 5 power_off] uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 5, wPortStatus=0x0101, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION usb_needs_explore: usb_bus_powerd: bus=0xd7e65000 uhub_explore: udev=0xd7daf000 addr=1 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd7db0000 addr=2 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 4, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd8cdb000 addr=6 uhub_read_port_status: port 1, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0303, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 5, wPortStatus=0x0101, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore_handle_re_enumerate: Unconfigure failed: USB_ERR_STALLED: Ignored. uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored) uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_req_re_enumerate: addr=5, set address failed! (USB_ERR_IOERROR, ignored) uhub_reset_tt_callback: TT buffer reset uhub_reset_tt_callback: TT buffer reset usbd_setup_device_desc: getting device descriptor at addr 5 failed, USB_ERR_IOERROR usb_needs_explore: usb_bus_powerd: bus=0xd7e65000 uhub_explore: udev=0xd7daf000 addr=1 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd7db0000 addr=2 uhub_read_port_status: port 1, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0503, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 4, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_explore: udev=0xd8cdb000 addr=6 uhub_read_port_status: port 1, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 2, wPortStatus=0x0303, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 3, wPortStatu Couldn't establish the timing exactly, but the resets correspond to about the time of the power cycling. After power cycling there was no /dev/cuaU0 created. Curiously, the power cycling _didn't_ trigger the error messages I saw earlier on the controlling terminal; it appeared that the power cycling was successful, even though /dev/cuaU0 wasn't created. Again, unplugging and replugging the USB connector had no effect. Disconnecting the TX, RX and ground and _then_ unplugging/replugging the USB end produced a successful resest of the adapter. Singly disconnecting TX, RX _or_ ground did nothing. Disconnecting both ends completely caused USB recognition and restored normal operation. Thanks for reading, and any ideas! bob prohaska From owner-freebsd-arm@freebsd.org Fri Dec 22 18:35:21 2017 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 3A051E823C2 for ; Fri, 22 Dec 2017 18:35:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F3C1D2B67 for ; Fri, 22 Dec 2017 18:35:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBMIZIVE024353 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Dec 2017 10:35:19 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBMIZH5h024352; Fri, 22 Dec 2017 10:35:17 -0800 (PST) (envelope-from fbsd) Date: Fri, 22 Dec 2017 10:35:16 -0800 From: bob prohaska To: "Rodney W. Grimes" Cc: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171222183516.GB23984@www.zefox.net> References: <20171222021909.GB20324@www.zefox.net> <201712220802.vBM82kZp035488@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712220802.vBM82kZp035488@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 22 Dec 2017 18:35:21 -0000 On Fri, Dec 22, 2017 at 12:02:46AM -0800, Rodney W. Grimes wrote: > > > Cmos latchup could exibit that behavior, a next test would be > to just remove the gnd pin from the data end next time the > connection stops working and see if that clears the fault. > Tried it, no effect. > You could also try removing and replacing the data end one pin > at a time and see if the fault clears after any one of these, Tried that too, likewise no effect. It seems mandatory to lift all three serial-end pins _and_ the usb connector. > I am suspecting a latch condition in the FTDI TX pin output ^^^^ did you mean Prolific? The two FTDI usb-serial adapters I have work perfectly. > buffer caused by out of range voltage caused most likely > by excess cable/capacitance induced ringing. > The cables are about three feet long, as furnished by the manufacturer. I do wonder if slowing the serial speed down might help; a console certainly needn't run at 115200 bps. It might help if I indicate the layout of the system, since I gather it's perahps a little unusual. There are four hosts, call them com, net, ns1 and ns2. They're all networked to a hub, with the usb/serial cables arranged so that each RPI2 provides terminal service to the next host in the ring: com-usb/serial-ns1-usb/serial/-ns2-usb/serial-net-usb/serial-com There was a faint tendency for hosts net and ns1 to have more usb/serial adapter lockups, so those hosts got FTDI adapters and all was well until the host called com (the test box) was upgraded to r326951. Serial link uptimes went from weeks or months to hours, for that host only. The serial cables obviously ground all four RPI2s together, I think the ethernet likewise distributes ground. Wall warts are connected to a single outlet strip, are isolated and do not distribute ground. All the cables are confined to a small shelf about one by two feet in size. It wouldn't be surprising if this turned out to be a wiring issue, but proof has so far proved elusive. Just for completeness, there's a photo of the setup at http://www.zefox.net/~fbsd/com_net_ns1_ns2 Left to right, the hosts are com, net, ns1 and ns2. I admit it isn't pretty, but is far from the biggest cable nightmare seen elsewhere. There is one device not shown, a networked printer sitting on the table above the shelf, plugged into the same outlet strip that powers everything in the photo. It has a three-wire cord and probably provides a single point ground for the whole network. In principle that should be good. Multiple paths to ground are understood to be bad in general and have been mostly avoided. Apologies for the length, thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Fri Dec 22 20:01:58 2017 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 88280E868B1 for ; Fri, 22 Dec 2017 20:01:58 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B80F64AFF for ; Fri, 22 Dec 2017 20:01:58 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBMK1tFQ038283; Fri, 22 Dec 2017 12:01:55 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBMK1sqR038282; Fri, 22 Dec 2017 12:01:54 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712222001.vBMK1sqR038282@pdx.rh.CN85.dnsmgr.net> Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 In-Reply-To: <20171222183516.GB23984@www.zefox.net> To: bob prohaska Date: Fri, 22 Dec 2017 12:01:54 -0800 (PST) CC: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Fri, 22 Dec 2017 20:01:58 -0000 > On Fri, Dec 22, 2017 at 12:02:46AM -0800, Rodney W. Grimes wrote: > > > > > > Cmos latchup could exibit that behavior, a next test would be > > to just remove the gnd pin from the data end next time the > > connection stops working and see if that clears the fault. > > > Tried it, no effect. I would need a circuit layout diagram to be certain, but I suspect that if this device does latch up it is going to stay latched until all sources of voltage are removed. > > You could also try removing and replacing the data end one pin > > at a time and see if the fault clears after any one of these, > > Tried that too, likewise no effect. It seems mandatory to lift > all three serial-end pins _and_ the usb connector. Try lifting everything but the data end gnd, that would be the USB connector, and RX and TX. > > I am suspecting a latch condition in the FTDI TX pin output > ^^^^ did you mean Prolific? > The two FTDI usb-serial adapters I have work perfectly. Ok, me bad, I should try to find a datasheet on the Prolific and see what its ESD/latchup protection rathings are. The FTDI is pretty well protected. > > > buffer caused by out of range voltage caused most likely > > by excess cable/capacitance induced ringing. > > > The cables are about three feet long, as furnished by the manufacturer. > I do wonder if slowing the serial speed down might help; a console > certainly needn't run at 115200 bps. Maybe, but probably not going to have an effect, but always worth a try. > It might help if I indicate the layout of the system, since I gather it's > perahps a little unusual. There are four hosts, call them com, net, > ns1 and ns2. They're all networked to a hub, with the usb/serial cables > arranged so that each RPI2 provides terminal service to the next host > in the ring: > > com-usb/serial-ns1-usb/serial/-ns2-usb/serial-net-usb/serial-com Ok, that is good additional data. > There was a faint tendency for hosts net and ns1 to have more usb/serial > adapter lockups, so those hosts got FTDI adapters and all was well until > the host called com (the test box) was upgraded to r326951. Serial link > uptimes went from weeks or months to hours, for that host only. > > The serial cables obviously ground all four RPI2s together, I think the > ethernet likewise distributes ground. Wall warts are connected to a single > outlet strip, are isolated and do not distribute ground. All the cables are > confined to a small shelf about one by two feet in size. I think you are correct in that the serial cables are tying all 4 systems grounds togeather, I am unclear on what the USB ground isolation rules are, I would actually suspect they are isolated. I put an ohm meter on my ftdi USB serial adapter and its gnd pin is infact tied to the shell of the USB connector, so that is a ground path. Ethernet does NOT have any ground wires, they are differential pairs and isolated via the transceiver. My pedantic side does not like this stringy "using a signal cable" as a system ground. I would rather see all 4 RPI's tied with a good ground to each other, and disconnect the serial cable gnd wire. > It wouldn't be surprising if this turned out to be a wiring issue, but > proof has so far proved elusive. Just for completeness, there's a photo > of the setup at > http://www.zefox.net/~fbsd/com_net_ns1_ns2 > Left to right, the hosts are com, net, ns1 and ns2. I admit it isn't > pretty, but is far from the biggest cable nightmare seen elsewhere. Looks okay, but this is still a poor system ground in my mind. This is not an earth ground, but a signal ground, and those are usually best done in a star topology, not a string. > There is one device not shown, a networked printer sitting on the > table above the shelf, plugged into the same outlet strip that powers > everything in the photo. It has a three-wire cord and probably provides > a single point ground for the whole network. In principle that should > be good. Multiple paths to ground are understood to be bad in general > and have been mostly avoided. There is no ground signal path in your ethernet cables, so you do not haved a "ground loop" that I can see. > Apologies for the length, thanks for reading! > > bob prohaska > > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Dec 22 20:40:51 2017 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 2E169E889C2 for ; Fri, 22 Dec 2017 20:40:51 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE4B765E73 for ; Fri, 22 Dec 2017 20:40:50 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (31.89-11-148.nextgentel.com [89.11.148.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BEA5E26006C; Fri, 22 Dec 2017 21:40:31 +0100 (CET) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 To: bob prohaska Cc: "Jukka A. Ukkonen" , freebsd-arm@freebsd.org References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> From: Hans Petter Selasky Message-ID: <7ba18476-43f5-5c59-c887-6d5e0cc186ea@selasky.org> Date: Fri, 22 Dec 2017 21:37:41 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171222041657.GA21799@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Fri, 22 Dec 2017 20:40:51 -0000 On 12/22/17 05:16, bob prohaska wrote: > Hi Hans, > >> Hi, >> >> You might want to run "usbdump" with the appropriate arguments to >> capture all USB traffic during such a cycle. >> > I'll try it next time the pl2303 locks up. > >> Further, you might want to only enable USB HUB debug messages to figure >> out why the USB stack thinks the device is going away: >> >> sysctl hw.usb.uhub.debug=17 >> > I've turned that on, and the console is spitting out a lot of output. > It'll make quite a haystack in which to find a needle 8-) Any hint > what to look for? > Hi, You should look for a port change event reporting a change in the status bits which is non-zero. >> From what I know, the RPI series of cards have a small external USB HUB >> on the board. All USB traffic goes through this High-Speed HUB. When you >> are using LOW and FULL speed, all traffic is translated from High-Speed >> USB into LOW and FULL speed USB. >> > > Would changing the baudrate have any effect? A console certainly needn't > run at 115200 baud. For present purposes 9600 or less is plenty. >> I don't rule out some kind of "bug" in this external piece of hardware. No, doesn't have anything to do with the USB packets. >> > Many have said pl2303 devices are unreliable, but they seem well-behaved > on a Mac and on an RPI3 running Raspbian. Whatever is wrong, it seems not > deterministic, but cumulative, with a touch of random. > >> You might also try to set (my wild guess): >> sysctl hw.usb.no_cs_fail=1 >> > Not sure I understand what this does; is there a description somewhere? This is a recovery mechanism, which triggers if the device appears dead, that it will automatically re-enumerate the USB device. Setting this sysctl prevents that mechanism. > >> Like already mentioned in this thread, the micro USB power input >> connecter on the RPI is not supposed to handle more than 500mA, >> regardless of how strong your power supply is. Then you need to subtract >> the mA's used by the CPU and other chips like ethernet. I wouldn't be >> surprised if ethernet functionality alone required 150mA at +5V. >> > Some time ago I put a voltmeter on the Pi and the voltage stayed over > five volts, but of course short spikes weren't visible in such a test. > On average, however, the connector seemed to handle the load. I think the USB specification mandates that the voltage must stay exactly within certain limits ... I don't remember all the details at the moment, but I think the USB 2.0 specification from usb.org will mention this. > >> USB LOW/HIGH/FULL speed all use some kind of pull-UP or pull-DOWN on the > >> data lines. This resistors are typically wired to +5V or GND (0V) on the >> board and transients in the voltage may be seen as a disconnect by the >> host or device. >> >> Regarding the DTB's. Make sure the USB data pins are correctly >> configured with regards to pullup/pulldown and not used as GPIOs. >> > Wouldn't that sort of error lead to things not working at all? The > problems observed develop after hours or sometimes days. I'm not sure. --HPS From owner-freebsd-arm@freebsd.org Fri Dec 22 20:42:21 2017 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 B42A6E88C80 for ; Fri, 22 Dec 2017 20:42:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7C7AD6614E for ; Fri, 22 Dec 2017 20:42:21 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (31.89-11-148.nextgentel.com [89.11.148.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 1BF2326006C; Fri, 22 Dec 2017 21:42:19 +0100 (CET) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 To: bob prohaska Cc: freebsd-arm@freebsd.org References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> From: Hans Petter Selasky Message-ID: <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> Date: Fri, 22 Dec 2017 21:39:30 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171222173052.GA23984@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Fri, 22 Dec 2017 20:42:21 -0000 I'm interested in messages containing wPortChange= , but with a non-zero value afterwards. --HPS From owner-freebsd-arm@freebsd.org Fri Dec 22 23:36:47 2017 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 8E40DE8CA5C for ; Fri, 22 Dec 2017 23:36:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EE736B572 for ; Fri, 22 Dec 2017 23:36:47 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBMNajYF025052 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Dec 2017 15:36:46 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBMNajZY025051; Fri, 22 Dec 2017 15:36:45 -0800 (PST) (envelope-from fbsd) Date: Fri, 22 Dec 2017 15:36:44 -0800 From: bob prohaska To: "Rodney W. Grimes" Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171222233644.GA24362@www.zefox.net> References: <20171222183516.GB23984@www.zefox.net> <201712222001.vBMK1sqR038282@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712222001.vBMK1sqR038282@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.24 (2015-08-30) 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: Fri, 22 Dec 2017 23:36:47 -0000 On Fri, Dec 22, 2017 at 12:01:54PM -0800, Rodney W. Grimes wrote: > > I would need a circuit layout diagram to be certain, but I > suspect that if this device does latch up it is going to > stay latched until all sources of voltage are removed. > If that's the case I can understand the pl2303's bad reputation. It does not obviously explain the pl2303's erratic operation on an RPI2 running FreeBSD compared to an RPI3 running Raspbian or a Mac running OSX. > > Try lifting everything but the data end gnd, that would be > the USB connector, and RX and TX. > If that didn't cause the adapter to reset it would be a miracle 8-) I'll try it next time things lock up. > > It might help if I indicate the layout of the system, since I gather it's > > perahps a little unusual. There are four hosts, call them com, net, > > ns1 and ns2. They're all networked to a hub, with the usb/serial cables > > arranged so that each RPI2 provides terminal service to the next host > > in the ring: > > > > com-usb/serial-ns1-usb/serial/-ns2-usb/serial-net-usb/serial-com > > Ok, that is good additional data. > > > There was a faint tendency for hosts net and ns1 to have more usb/serial > > adapter lockups, so those hosts got FTDI adapters and all was well until > > the host called com (the test box) was upgraded to r326951. Serial link > > uptimes went from weeks or months to hours, for that host only. > > > > The serial cables obviously ground all four RPI2s together, I think the > > ethernet likewise distributes ground. Wall warts are connected to a single > > outlet strip, are isolated and do not distribute ground. All the cables are > > confined to a small shelf about one by two feet in size. > > I think you are correct in that the serial cables are tying all 4 systems > grounds togeather, I am unclear on what the USB ground isolation rules > are, I would actually suspect they are isolated. I put an ohm meter on > my ftdi USB serial adapter and its gnd pin is infact tied to the shell > of the USB connector, so that is a ground path. > Doing the same test on my pl2303 adapters finds the shell poorly grounded. The metal USB shell is only loosely crimped to the ground plane of the circuit board, and not soldered. Pin 4 is supposed to be ground also, so maybe it doesn't matter. Still, I'm surprised enough to try soldering one of the shells to ground and will try it presently. > Ethernet does NOT have any ground wires, they are differential pairs > and isolated via the transceiver. > Ok, that's good, I think.... > My pedantic side does not like this stringy "using a signal cable" > as a system ground. I would rather see all 4 RPI's tied with a > good ground to each other, and disconnect the serial cable gnd > wire. > Basically I agree with you. I didn't like the ring topology either, but it was the only way to get serial access to all the Pi's without some sort of terminal server. > > It wouldn't be surprising if this turned out to be a wiring issue, but > > proof has so far proved elusive. Just for completeness, there's a photo > > of the setup at > > http://www.zefox.net/~fbsd/com_net_ns1_ns2 > > Left to right, the hosts are com, net, ns1 and ns2. I admit it isn't > > pretty, but is far from the biggest cable nightmare seen elsewhere. > > Looks okay, but this is still a poor system ground in my mind. This > is not an earth ground, but a signal ground, and those are usually > best done in a star topology, not a string. It occurs to me that lifting _one_ ground will break the ground loop. The serial pins at the lifted ground will have to return current through the other Pi's, which isn't good. At this point if I could make the problem dependably _worse_ I'd be at least slightly the wiser. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sat Dec 23 00:18:22 2017 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 AA11DE8D7B0 for ; Sat, 23 Dec 2017 00:18:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 83C606C822 for ; Sat, 23 Dec 2017 00:18:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBN0IKD2025163 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 22 Dec 2017 16:18:21 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBN0IJrp025162; Fri, 22 Dec 2017 16:18:19 -0800 (PST) (envelope-from fbsd) Date: Fri, 22 Dec 2017 16:18:19 -0800 From: bob prohaska To: Hans Petter Selasky Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171223001819.GB24362@www.zefox.net> References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 23 Dec 2017 00:18:22 -0000 On Fri, Dec 22, 2017 at 09:39:30PM +0100, Hans Petter Selasky wrote: > I'm interested in messages containing wPortChange= , but with a non-zero > value afterwards. > Ok, that I can understand 8-) Right now the system is running with root@www:/home/bob # sysctl hw.usb.uhub.debug=17 hw.usb.uhub.debug: 0 -> 17 root@www:/home/bob # sysctl hw.usb.no_cs_fail=1 hw.usb.no_cs_fail: 0 -> 1 There's a steady stream of lines like uhub_read_port_status: port 3, wPortStatus=0x0100, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION uhub_read_port_status: port 5, wPortStatus=0x0103, wPortChange=0x0000, err=USB_ERR_NORMAL_COMPLETION scrolling up the serial console. Does the command hw.usb.no_cs_fail: 0 -> 1 imply the output will stop (or at least slow down) once the pl2303 freezes? Thanks very much! bob prohaska From owner-freebsd-arm@freebsd.org Sat Dec 23 10:42:58 2017 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 A72CAEA2487 for ; Sat, 23 Dec 2017 10:42:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6D33B7F078 for ; Sat, 23 Dec 2017 10:42:57 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (31.89-11-148.nextgentel.com [89.11.148.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id BA445260362; Sat, 23 Dec 2017 11:42:54 +0100 (CET) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 To: bob prohaska Cc: freebsd-arm@freebsd.org References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> <20171223001819.GB24362@www.zefox.net> From: Hans Petter Selasky Message-ID: <3ed9d3f0-b61f-caf6-26e0-1a61caba7ab6@selasky.org> Date: Sat, 23 Dec 2017 11:40:02 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171223001819.GB24362@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 23 Dec 2017 10:42:58 -0000 On 12/23/17 01:18, bob prohaska wrote: > Does the command > hw.usb.no_cs_fail: 0 -> 1 imply the output will stop (or at least slow > down) once the pl2303 freezes? No. --HPS From owner-freebsd-arm@freebsd.org Sat Dec 23 12:53:30 2017 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 7F3D2EA525D for ; Sat, 23 Dec 2017 12:53:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6B3932E8A for ; Sat, 23 Dec 2017 12:53:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6A3D6EA525C; Sat, 23 Dec 2017 12:53:30 +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 69902EA525B; Sat, 23 Dec 2017 12:53:30 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47EC22E88; Sat, 23 Dec 2017 12:53:29 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id B6E92E42; Sat, 23 Dec 2017 06:53:22 -0600 (CST) Date: Sat, 23 Dec 2017 06:53:21 -0600 From: Mark Linimon To: Jan Beich Cc: Mark Linimon , Adam Weinberger , arm@freebsd.org, ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: Re: svn commit: r456893 - head/security/1password-client Message-ID: <20171223125321.GA13645@lonesome.com> References: <201712210854.vBL8swMK033835@repo.freebsd.org> <1sjm-wuaj-wny@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1sjm-wuaj-wny@FreeBSD.org> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 23 Dec 2017 12:53:30 -0000 On Fri, Dec 22, 2017 at 06:23:48PM +0100, Jan Beich wrote: > Are you sure aarch64 can run 32bit binaries? I will do a test-run on xbuild armv7 with s/aarch64/armv7/ . mcl From owner-freebsd-arm@freebsd.org Sat Dec 23 15:02:22 2017 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 ABFB0EA7A89 for ; Sat, 23 Dec 2017 15:02:22 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from mx0.gid.co.uk (mx0.gid.co.uk [194.32.164.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 52374663D7 for ; Sat, 23 Dec 2017 15:02:21 +0000 (UTC) (envelope-from rb@gid.co.uk) Received: from [192.168.0.118] (197-234-178-96.cipherwave.net [197.234.178.96] (may be forged)) by mx0.gid.co.uk (8.14.2/8.14.2) with ESMTP id vBNEuAr3059980; Sat, 23 Dec 2017 14:56:12 GMT (envelope-from rb@gid.co.uk) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 From: Bob Bishop In-Reply-To: <20171223001819.GB24362@www.zefox.net> Date: Sat, 23 Dec 2017 16:55:56 +0200 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> <20171223001819.GB24362@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3273) 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, 23 Dec 2017 15:02:22 -0000 Hi, As previously suggested, you should absolutely try connecting the pl2303 = to the Pi through a _powered_ USB hub. If it operates correctly like = that, the Pi USB ports don=E2=80=99t supply enough power to run the = pl2303 reliably and software won=E2=80=99t fix that. Note that "The USB ports on a Raspberry Pi have a design loading of = 100mA each...=E2=80=9D[1] which is the absolute minimum allowed by the = USB spec. = [1]https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/READ= ME.md -- Bob Bishop rb@gid.co.uk From owner-freebsd-arm@freebsd.org Sat Dec 23 17:32:02 2017 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 0F688E8B171 for ; Sat, 23 Dec 2017 17:32:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CB7A26D1F1 for ; Sat, 23 Dec 2017 17:32:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBNHVr25028016 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Dec 2017 09:31:54 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBNHVrtv028015; Sat, 23 Dec 2017 09:31:53 -0800 (PST) (envelope-from fbsd) Date: Sat, 23 Dec 2017 09:31:52 -0800 From: bob prohaska To: Bob Bishop Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171223173152.GA25961@www.zefox.net> References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> <20171223001819.GB24362@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) 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, 23 Dec 2017 17:32:02 -0000 On Sat, Dec 23, 2017 at 04:55:56PM +0200, Bob Bishop wrote: > > Note that "The USB ports on a Raspberry Pi have a design loading of 100mA each...???[1] which is the absolute minimum allowed by the USB spec. ^^^^^^^ maximum? > > [1]https://www.raspberrypi.org/documentation/hardware/raspberrypi/usb/README.md > The PL2303TA data sheet at https://cdn-shop.adafruit.com/datasheets/DS_PL2303TA_d20120504.pdf claims the operating current is 10 mA maximum, plus output. The output drive rating is 4 mA, which puts the total far below the Pi's limit. The other USB loads on the RPI2 are a mouse, keyboard and Sandisk Extreme 64 GB USB flash drive, which holds /var, /usr /tmp and swap. The mouse is marked 5 V, 100 mA, the keyboard is marked 5 V 1.5 A, but contains a hub of its own, so I don't know how much power the keyboard itself uses. Both are old Dell units, it's fairly clear the keyboard rating includes outboard load and it's unlikely the mouse ever draws full nameplate current. A Logitech hubless keyboard is marked 100 mA, which seems a plausible upper limit for keyboard alone. The big mystery is the USB flash drive; I can't find any specs on power consumption, the only measure is a "touch test", which reveals the drive is lukewarm to the touch with a make session running in /usr/ports. I'd guess it's around half a watt, but that's only a guess. However, there has so far been no sign of misbehavior from the USB flash drive. Are there any software tools that can display USB power consumption? At the discovery of the USB/serial problems around a year ago there was a faint positional dependence; two of the hosts in the group seemed more prone to trouble than the other two when using the PL2303 adapters. That by itself suggested some sort of physical cause, but until Rod Grimes mentioned connector shroud grounding it never occurred to me to check. Having learned since that the shrouds weren't securely grounded I've resoldered one and installed it, not expecting it to make much difference since pin 4 _is_ securely grounded and the cables are unshielded anyway. That adapter has been up for 18 hours, a recent record, though by no means an all-time record. For the moment the best course seems to be waiting and watching. Thanks to everyone for reading! bob prohaska From owner-freebsd-arm@freebsd.org Sat Dec 23 17:40:26 2017 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 9A32CE8BB87 for ; Sat, 23 Dec 2017 17:40:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5E9066D638 for ; Sat, 23 Dec 2017 17:40:26 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (31.89-11-148.nextgentel.com [89.11.148.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id C5912260362; Sat, 23 Dec 2017 18:40:17 +0100 (CET) Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 To: bob prohaska , Bob Bishop Cc: freebsd-arm@freebsd.org References: <20171220170244.GA16029@www.zefox.net> <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> <20171223001819.GB24362@www.zefox.net> <20171223173152.GA25961@www.zefox.net> From: Hans Petter Selasky Message-ID: <798971d6-54f3-0453-6393-daa79fffd552@selasky.org> Date: Sat, 23 Dec 2017 18:37:29 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171223173152.GA25961@www.zefox.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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, 23 Dec 2017 17:40:26 -0000 On 12/23/17 18:31, bob prohaska wrote: > The big mystery is the USB flash drive; I can't find any specs on > power consumption, the only measure is a "touch test", which reveals > the drive is lukewarm to the touch with a make session running in > /usr/ports. I'd guess it's around half a watt, but that's only a guess. > However, there has so far been no sign of misbehavior from the USB > flash drive. Idea: Cut a USB cable, reconnect all the wires except the red one, and put a multimeter capable of measuring mA's between. --HPS From owner-freebsd-arm@freebsd.org Sat Dec 23 19:11:26 2017 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 790A1E94808 for ; Sat, 23 Dec 2017 19:11:26 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3023570F5A for ; Sat, 23 Dec 2017 19:11:25 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id vBNJBNdE028268 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Dec 2017 11:11:23 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id vBNJBK86028267; Sat, 23 Dec 2017 11:11:20 -0800 (PST) (envelope-from fbsd) Date: Sat, 23 Dec 2017 11:11:20 -0800 From: bob prohaska To: Hans Petter Selasky Cc: Bob Bishop , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Disapearing pl2303 usb serial adapter on rpi2 Message-ID: <20171223191120.GB25961@www.zefox.net> References: <20171221161120.GA20324@www.zefox.net> <20171222041657.GA21799@www.zefox.net> <20171222173052.GA23984@www.zefox.net> <96d7cc41-33bf-1006-54a3-1cc8d9570fd2@selasky.org> <20171223001819.GB24362@www.zefox.net> <20171223173152.GA25961@www.zefox.net> <798971d6-54f3-0453-6393-daa79fffd552@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <798971d6-54f3-0453-6393-daa79fffd552@selasky.org> User-Agent: Mutt/1.5.24 (2015-08-30) 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, 23 Dec 2017 19:11:26 -0000 On Sat, Dec 23, 2017 at 06:37:29PM +0100, Hans Petter Selasky wrote: > > Idea: Cut a USB cable, reconnect all the wires except the red one, and > put a multimeter capable of measuring mA's between. > > --HPS That thought has crossed my mind, but I'm hesitant at the moment because it requires a relatively large disturbance to the host and wiring. The discovery of the USB connector shroud being not soldered to the signal ground was a real surprise, now corrected in one instance. That adapter has now run 20 hours, in contrast to the last several sessions which locked up overnight. Until the lockup can be reproduced it seems wise to minimize physical changes. I suspected a hardware problem at first, but the long (months) hiatus followed by a recurrence after upgrade to r326951 persuaded me to suspect software, since the hardware literally hadn't been touched. Now, again, I'm not so sure. Many years ago I worked on a development project with a patient software engineer, and we sparred constantly over the "Is the problem hardware or software?" question. In that case he wrote a test program that could be left carefully unchanged. It exercised the hardware we were working on and didn't touch anything else.. This was 1997, on ISA-bus computers running QNX. There seems to be an open source hardware test suite called Inquisitor, https://en.wikipedia.org/wiki/Inquisitor_(hardware_testing_software) Is there anything like it in FreeBSD? Peter Holm's stress2 suite is in the right spirit, but isn't directed at USB or ARM. Long-latency problems of the kind I'm seeing are hard to sort out under any circumstances. Grounding and shielding issues are the worst of the lot. If trouble shows up once a month, a reversion to the last working edition covers a lot of changes. Test fixtures can obscure underlying defects, like unsoldered shields. Thanks for your attention, and apologies for what's beginning to look like a red herring! bob prohaska