From owner-freebsd-arm@freebsd.org Sun Jan 22 19:07: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 D7C0ECBD658 for ; Sun, 22 Jan 2017 19:07:06 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (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 A9B50ABF for ; Sun, 22 Jan 2017 19:07:06 +0000 (UTC) (envelope-from gonzo@bluezbox.com) Received: from [127.0.0.1] (helo=id.bluezbox.com) by id.bluezbox.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1cVNTg-000GLe-CP; Sun, 22 Jan 2017 11:07:01 -0800 Received: (from gonzo@localhost) by id.bluezbox.com (8.15.2/8.15.2/Submit) id v0MJ6xGG062845; Sun, 22 Jan 2017 11:06:59 -0800 (PST) (envelope-from gonzo@bluezbox.com) X-Authentication-Warning: id.bluezbox.com: gonzo set sender to gonzo@bluezbox.com using -f Date: Sun, 22 Jan 2017 11:06:59 -0800 From: Oleksandr Tymoshenko To: Dustin Marquess Cc: Hans Petter Selasky , "freebsd-arm@freebsd.org" Subject: Re: Getting the kernel to let go of my UART! Message-ID: <20170122190659.GA62786@bluezbox.com> References: <48f8cbc1-3814-b9f6-0e3a-ebe97466d1df@selasky.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD/11.0-RELEASE-p2 (amd64) User-Agent: Mutt/1.6.1 (2016-04-27) X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Dustin Marquess (dmarquess@gmail.com) wrote: > On Sunday, January 22, 2017, Hans Petter Selasky wrote: > > > On 01/22/17 06:07, Dustin Marquess wrote: > > > >> [Sorry if this is somewhat of a dupe, I have yet to find a solution] > >> > >> I've been running FreeBSD on my Pi 3s for a little over a month now, > >> first using gonzo's SMP code + a home cross-compiled kernel, and then > >> I moved to the HardenedBSD images. All of them work great except one > >> issue that's driving me nuts... > >> > >> The downside to the Pi 3 vs some other boards is that there's really > >> only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with > >> a GPS board. > >> > >> 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and > >> that's "fixed". > >> > >> 2nd issue: Even with a USB keyboard attached and HDMI output > >> connected, FreeBSD still wants to steal the first uart (ttyu0) as a > >> console port. I thought that would be fine as long as I use "-m -n > >> -q" in the boot config to disable kernel output and then "conscontrol > >> delete ttyu0". Well, that KIND of works. It seems to work fine when > >> using 115200bps, but trying to change the baud rate to match the GPS > >> unit doesn't seem to work at all, I'm guessing because it's still set > >> as an available console? > >> > >> hint.uart.0.flags="0x0" doesn't work, as it still marks it as a > >> console. console="efi" seems to be the only setting that works, > >> "vidconsole" and "nullconsole" both don't work. > >> > >> Is there a way to stop the kernel from trying to claim the UART as a > >> console? > >> > > > > I think so, have a look in /etc/ttys and comment out the ttyu0 line. > > > > Sadly, I already did that. There's no getty running, but dmesg still shows > the kernel marking it as a console. [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: selasky.org] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 19:07:06 -0000 Dustin Marquess (dmarquess@gmail.com) wrote: > On Sunday, January 22, 2017, Hans Petter Selasky wrote: > > > On 01/22/17 06:07, Dustin Marquess wrote: > > > >> [Sorry if this is somewhat of a dupe, I have yet to find a solution] > >> > >> I've been running FreeBSD on my Pi 3s for a little over a month now, > >> first using gonzo's SMP code + a home cross-compiled kernel, and then > >> I moved to the HardenedBSD images. All of them work great except one > >> issue that's driving me nuts... > >> > >> The downside to the Pi 3 vs some other boards is that there's really > >> only one UART tied to the GPIO pins. I'm trying to feed my Pi 3 with > >> a GPS board. > >> > >> 1st issue: The NMEA stream upsets U-boot. Fine, compiled my own and > >> that's "fixed". > >> > >> 2nd issue: Even with a USB keyboard attached and HDMI output > >> connected, FreeBSD still wants to steal the first uart (ttyu0) as a > >> console port. I thought that would be fine as long as I use "-m -n > >> -q" in the boot config to disable kernel output and then "conscontrol > >> delete ttyu0". Well, that KIND of works. It seems to work fine when > >> using 115200bps, but trying to change the baud rate to match the GPS > >> unit doesn't seem to work at all, I'm guessing because it's still set > >> as an available console? > >> > >> hint.uart.0.flags="0x0" doesn't work, as it still marks it as a > >> console. console="efi" seems to be the only setting that works, > >> "vidconsole" and "nullconsole" both don't work. > >> > >> Is there a way to stop the kernel from trying to claim the UART as a > >> console? > >> > > > > I think so, have a look in /etc/ttys and comment out the ttyu0 line. > > > > Sadly, I already did that. There's no getty running, but dmesg still shows > the kernel marking it as a console. Just a random idea, try adding hw.fdt.console=foo0 to /boot/loader.conf This should force uart_cpu_fdt_probe to fail. -- gonzo