From owner-freebsd-arm@FreeBSD.ORG Sun Dec 22 06:58:30 2013 Return-Path: Delivered-To: arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 535539A5 for ; Sun, 22 Dec 2013 06:58:30 +0000 (UTC) Received: from mx0.deglitch.com (backbone.deglitch.com [78.110.53.255]) by mx1.freebsd.org (Postfix) with ESMTP id 0CE5C1580 for ; Sun, 22 Dec 2013 06:58:29 +0000 (UTC) Received: from [192.168.11.7] (c-71-198-22-48.hsd1.ca.comcast.net [71.198.22.48]) by mx0.deglitch.com (Postfix) with ESMTPSA id BF52B8FC40; Sun, 22 Dec 2013 10:58:19 +0400 (MSK) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: 10.0-release proposed patch for Atmel From: Stanislav Sedov In-Reply-To: Date: Sat, 21 Dec 2013 22:58:11 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Warner Losh X-Mailer: Apple Mail (2.1822) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 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 Dec 2013 06:58:30 -0000 On Dec 21, 2013, at 10:44 PM, Warner Losh wrote: > Gentlemen, >=20 > Right now, the mountroot prompt doesn't work on Atmel CPUs. Almost all = the characters are eaten. I recently committed an elegant fix for this = into head to mask the interrupt for new characters and only do polling. >=20 > However, it touched the base uart. In an abundance of caution, the re@ = has asked me to see if I can come up with a fix w/o that. >=20 > A less elegant, less functional fix can be found at = http://people.freebsd.org/~imp/at91-mountroot-10.diff >=20 > This fix defers turning on the RXRDY bit in the interrupt mask until = we get the first interrupt after the first opening of the device. This = is sufficient for mountroot> to work, but wouldn't fix things like GELI = that prompt the user from the kernel. I think that's acceptable for 10.0 = given the typical use case for atmel. >=20 > Can the folks here that know Atmel take a look at the patch and let me = know what you think? >=20 Looks correct to me. This is probably the safest way to go and will = solve the issue for the majority of use cases as you said. Thanks! -- ST4096-RIPE