From owner-freebsd-arm@FreeBSD.ORG Sun Apr 27 18:37:43 2014 Return-Path: Delivered-To: freebsd-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 9E3E3EB8 for ; Sun, 27 Apr 2014 18:37:43 +0000 (UTC) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F42113D1 for ; Sun, 27 Apr 2014 18:37:43 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id up15so5002348pbc.34 for ; Sun, 27 Apr 2014 11:37:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=hQXjj0mP/tlBYtJ2NddRzs6auMwW7oSyQ0cGm0BeobQ=; b=cFNx5QV0SN07Szd3hmjomqmdH9HYCJu2nlTlKYSCSOn768Q0TQ0KZ83P/GL7JXY1RR /NaCUuzuiFMZIx2sraZI6Nj3UaMf2VUwVJk8igrs1tWgTG3mp3QN8f4EA4hnXlvlUhsK gYlI0kKpPFlr5bkN3tDM0ZBK3/zQOblUoWKuH0NWkhMhxM1DQx5Pe3RgdUSkmXxJnUGr PYYxgP0b/kVSpQ2pDOGqLJqnunv5GXlI+KxwJirjKE6xhK3D5fASQf8gegZYJHbGk1wA 1OntizfA+2C32ITZp9CTrCME5JeA9mnwotb74aHRqa9w0xNi1zEEkfX7Sk2rHNIxJ82r bTnQ== X-Gm-Message-State: ALoCoQnPMGe2RXoYL4C6eWSwh3CKGq89ckDThwG1FMe4iR1QbhfXfUm2bS5ZXxio99RnkBEyIA8A X-Received: by 10.66.227.193 with SMTP id sc1mr20826738pac.102.1398623433648; Sun, 27 Apr 2014 11:30:33 -0700 (PDT) Received: from [10.64.25.6] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id pl10sm29740560pbb.56.2014.04.27.11.30.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Apr 2014 11:30:32 -0700 (PDT) Sender: Warner Losh Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Looking for FreeBSD u-boot/kernel debugging help (BeagleBone Black) From: Warner Losh In-Reply-To: <1398618296.61646.161.camel@revolution.hippie.lan> Date: Sun, 27 Apr 2014 12:30:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <35FCA9EC-1569-494D-B193-90926D802219@bsdimp.com> References: <20140426233438.49123B827@mail.bitblocks.com> <1398618296.61646.161.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1874) Cc: Bakul Shah , FreeBSD ARM 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, 27 Apr 2014 18:37:43 -0000 On Apr 27, 2014, at 11:04 AM, Ian Lepore wrote: > On Sat, 2014-04-26 at 16:34 -0700, Bakul Shah wrote: >> On Sat, 26 Apr 2014 18:29:35 EDT Winston Smith = wrote: >>> I also discovered that if I disconnect = my >>> serial terminal and reconnect it, it seems to bring the FreeBSD = kernel >>> to a debug prompt of sorts -- is there any documentation on this? >>=20 >> I suspect disconnecting/reconnecting the serial cable looks like >> a break to the kernel and that drops it into the debugger "ddb". >> [Though I can't seem to send a real break to it using kermit!] >>=20 >> Type c and hit return to continue.=20 >>=20 >> To disable this behavior I think you can do >> sysctl debug.kbd.break_to_debugger=3D0 >> or add >> debug.kbd.break_to_debugger=3D0 >> to /etc/sysctl.conf >>=20 >> man 1 ddb -- for debugger commands >> man 4 ddb -- for kernel config options to control ddb behavior >=20 > That's exactly correct -- connecting the cable sometimes leads to a > spurious break being asserted on the line (a break is just a long > sequence of zeroes with no start/stop/data bit transitions). >=20 > It's possible to configure a kernel without BREAK_TO_DEBUGGER and with > ALT_BREAK_TO_DEBUGGER. That eliminates most line-noise spurious = breaks > but still allows the ~ ^b break sequence (which could = theoretically > happen in a burst of line noise, but not likely). A few of our = kernels > have BREAK_TO_DEBUGGER in the config, and I think that's probably a > mistake. Most folks these days don't know anything about breaks or = how > to generate one on purpose. =20 >=20 > Any objections to removing them and using only the safer ALT_BREAK > option? Please leave it in the ATMEL config, but I think you can remove it from = the rest (including the specific atmel SoC boards). Warner=