From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 12:27:55 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9B93DFD9 for ; Sun, 20 Oct 2013 12:27:55 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 28E7225FD for ; Sun, 20 Oct 2013 12:27:55 +0000 (UTC) Received: by mail-wi0-f178.google.com with SMTP id hn9so2812537wib.17 for ; Sun, 20 Oct 2013 05:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9VjFU7spxXYgF23IRJtwydEkEnuuZ3M257MZIDbQNY4=; b=w1uxhKAYQzMx84o9HZJwmMNJ2Y2ZpxvX2hel7kd+EmewJ7X82nO9McIIuVtyIa+hg4 S68aOTQqiV3AXOk6c9Q8iSYW/AI4MN3ZDrj79H2d7XvB/e7RPHfcaeaK7Fc2i4aGLHQs Z2P73Uhl9xLOefuqlLpWcbAIpBQjRO04BDQyebRdtZyErnYev5XVLEsUDkl0RSWOc6lA 0wrIALdxe2ZBzFZEFidtdJMsbJvRv6bSwg8VIhhz36TosqIOt+FZJngeY9XrBZ5TKosd 5GQq/7a7U/6DUiayUKo/VL0Aj3lQK+3NDiDpW93wRyMArwm/FL+/wn5BY6qGci1TU/FN CF9Q== MIME-Version: 1.0 X-Received: by 10.194.175.133 with SMTP id ca5mr9487094wjc.19.1382272073359; Sun, 20 Oct 2013 05:27:53 -0700 (PDT) Received: by 10.216.254.67 with HTTP; Sun, 20 Oct 2013 05:27:53 -0700 (PDT) Date: Sun, 20 Oct 2013 14:27:53 +0200 Message-ID: Subject: AVILA npe problem ? From: Berislav Purgar To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 12:27:55 -0000 Hello .. me again :) Is there a way to get right PHY for npe0 on GW2345-F board for switch to work? This board have switch (KS8995) with 4 LAN ports and one WAN port (npe0 npe1) .. I got PHY for WAN (npe1 PHY=5) from openwrt but on openwrt for npe0 PHY is 32 (freebsd support PHY to 31 ? ). If i put PHY=2 port 2 on switch is active but ports 1 3 4 no .. PHY=4 is for port 4 on switch but no 1 2 3, so is there way to get right PHY for all ports ?? Some examples: PHY=0 for npe0 (default AVILA.hints) ixpqmgr0: on ixp0 npe0: on ixp0 npe0: MAC at 0xc8009000 npe0: MII at 0xc8009000 npe0: load fw image IXP425.NPE-B Func 0x2 Rev 2.1 npe0: attaching PHYs failed npe0: cannot activate npe device_attach: npe0 attach returned 6 npe1: on ixp0 npe1: MAC at 0xc800a000 npe1: MII at 0xc8009000 npe1: load fw image IXP425.NPE-C Func 0x5 Rev 2.1 miibus0: on npe1 ukphy0: PHY 5 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto npe1: Ethernet address: 00:d0:12:13:59:23 and PHY=2 for npe0 (only port 2 is active on switch) uart1: on ixp0 ixpqmgr0: on ixp0 npe0: on ixp0 npe0: MAC at 0xc8009000 npe0: MII at 0xc8009000 npe0: load fw image IXP425.NPE-B Func 0x2 Rev 2.1 miibus0: on npe0 ukphy0: PHY 2 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto npe0: Ethernet address: 00:d0:12:03:59:23 npe1: on ixp0 npe1: MAC at 0xc800a000 npe1: MII at 0xc8009000 npe1: load fw image IXP425.NPE-C Func 0x5 Rev 2.1 miibus1: on npe1 ukphy1: PHY 5 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto npe1: Ethernet address: 00:d0:12:13:59:23 Beri From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 15:26:21 2013 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 ESMTP id 396E4B68 for ; Sun, 20 Oct 2013 15:26:21 +0000 (UTC) (envelope-from stl@koffein.net) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 1B6E72E33 for ; Sun, 20 Oct 2013 15:26:20 +0000 (UTC) Received: from homiemail-a4.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by hapkido.dreamhost.com (Postfix) with ESMTP id 461FDDC493 for ; Sun, 20 Oct 2013 08:26:14 -0700 (PDT) Received: from homiemail-a4.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTP id 3DADC51C063 for ; Sun, 20 Oct 2013 08:26:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h=from:to :subject:date:message-id:mime-version:content-type: content-transfer-encoding; s=koffein.net; bh=OUVp4su4yYdy8FcTQIH Wo7/4lK8=; b=2jigZouEJHyFRxcQDxf9hrUYe/PDSFfYe+5fX9ZznAAT/qyIYOl 8G8lj3ofSmXK5+nyqSa9GULVSy8/H5LTlGAgtMLounJgFEThcXl1d0ZHj3cBZijD npkoE+5s1vmSjr64ZnC3oVnpJJ3jNkZgj8b+PQWzZursOPs/kjbeCU3w= Received: from localhost (unknown [213.211.139.38]) (Authenticated sender: stl@koffein.net) by homiemail-a4.g.dreamhost.com (Postfix) with ESMTPA id DAA7A51C05F for ; Sun, 20 Oct 2013 08:26:07 -0700 (PDT) From: Steven Lawrance To: freebsd-arm Subject: pl011 UART driver (as used on Raspberry Pi) baud rate divisor Date: Sun, 20 Oct 2013 17:25:24 +0200 Message-Id: <1382282023-sup-4600@luwak.koffein.net> User-Agent: Sup/0.14.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-1382282724-191894-1322-3059-1-=" Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 15:26:21 -0000 --=-1382282724-191894-1322-3059-1-= Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Hi all, attached is a small patch to calculate the baud rate divisor for the pl011 UART. The existing code used hardcoded values which work for a UARTCLK frequency of 3Mhz and a baud rate of 115200. If my calculations are correct, the same values should still end up being set on the RPI but this patch allows it to work on an i.MX233 with a fixed 24MHz clock frequency and it obeys the values in the FDT. Is someone able to test it on the Raspberry Pi? cheers, -- Steven Lawrance stl@koffein.net --=-1382282724-191894-1322-3059-1-= Content-Disposition: attachment; filename="pl011_baudrate.patch" Content-Type: application/octet-stream; name="pl011_baudrate.patch" Content-Transfer-Encoding: base64 SW5kZXg6IHN5cy9kZXYvdWFydC91YXJ0X2Rldl9wbDAxMS5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT0KLS0tIHN5cy9kZXYvdWFydC91YXJ0X2Rldl9wbDAx MS5jCShyZXZpc2lvbiAyNTY3NzkpCisrKyBzeXMvZGV2L3VhcnQvdWFydF9k ZXZfcGwwMTEuYwkoYXJiZXRza29waWEpCkBAIC0xNDcsOSArMTQ3LDYgQEAK IAkJYnJlYWs7CiAJfQogCi0JLyogVE9ETzogQ2FsY3VsYXRlIGRpdmlzb3Jz ICovCi0JYmF1ZCA9ICgweDEgPDwgMTYpIHwgMHgyODsKLQogCWlmIChzdG9w Yml0cyA9PSAyKQogCQlsaW5lIHw9IExDUl9IX1NUUDI7CiAJZWxzZQpAQCAt MTY0LDggKzE2MSwxMSBAQAogCWxpbmUgJj0gIH5MQ1JfSF9GRU47CiAJY3Ry bCB8PSAoQ1JfUlhFIHwgQ1JfVFhFIHwgQ1JfVUFSVEVOKTsKIAotCV9fdWFy dF9zZXRyZWcoYmFzLCBVQVJUX0lCUkQsICgodWludDMyX3QpKGJhdWQgPj4g MTYpKSAmIElCUkRfQkRJVklOVCk7Ci0JX191YXJ0X3NldHJlZyhiYXMsIFVB UlRfRkJSRCwgKHVpbnQzMl90KShiYXVkKSAmIEZCUkRfQkRJVkZSQUMpOwor CWlmIChiYXMtPnJjbGsgIT0gMCAmJiBiYXVkcmF0ZSAhPSAwKSB7CisJCWJh dWQgPSBiYXMtPnJjbGsgKiA0IC8gYmF1ZHJhdGU7CisJCV9fdWFydF9zZXRy ZWcoYmFzLCBVQVJUX0lCUkQsICgodWludDMyX3QpKGJhdWQgPj4gNikpICYg SUJSRF9CRElWSU5UKTsKKwkJX191YXJ0X3NldHJlZyhiYXMsIFVBUlRfRkJS RCwgKHVpbnQzMl90KShiYXVkICYgMHgzRikgJiBGQlJEX0JESVZGUkFDKTsK Kwl9CiAKIAkvKiBBZGQgY29uZmlnLiB0byBsaW5lIGJlZm9yZSByZWVuYWJs aW5nIFVBUlQgKi8KIAlfX3VhcnRfc2V0cmVnKGJhcywgVUFSVF9MQ1JfSCwg KF9fdWFydF9nZXRyZWcoYmFzLCBVQVJUX0xDUl9IKSAmCg== --=-1382282724-191894-1322-3059-1-=-- From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 16:13:35 2013 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 ESMTP id 11D5A9A6; Sun, 20 Oct 2013 16:13:35 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C9EC620E7; Sun, 20 Oct 2013 16:13:34 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VXvdD-0001xU-Tk; Sun, 20 Oct 2013 17:13:33 +0100 From: Mark Robert Vaughan Murray Content-Type: multipart/signed; boundary="Apple-Mail=_E99821B8-0642-4A65-9C48-B0CF61B5C7EE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Sun, 20 Oct 2013 17:13:31 +0100 Subject: ARM counter registers and get_cyclecount() To: freebsd-arm Message-Id: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) X-SA-Score: -1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 16:13:35 -0000 --Apple-Mail=_E99821B8-0642-4A65-9C48-B0CF61B5C7EE Content-Type: multipart/mixed; boundary="Apple-Mail=_92E64D00-B74B-488C-B31F-CFD2CA82718B" --Apple-Mail=_92E64D00-B74B-488C-B31F-CFD2CA82718B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks I asked a similar question to this a month or so ago, then got involved = in other work, so apologies for the repetition! The random(4) device benefits from having a decent hardware = get_cyclecount() implementation. In i386 and arm, we have a stopgap = version that uses binuptime(), which is slow and prone to quantisation = error. I've hacked up a minimalist hardware version for ARMv6/RPI (which is the = only ARM I have access to, and I'm keen to use it for other things as = well), and I'm looking for improvement advice and/or commit blessing. Things it could conceivably do better: 1) The counter is 32 bits only. At clocks of hundreds-of-megahertz, this = will overflow in some 10's of seconds to maybe a minute, so it would be = nice (but to essential) to trap the overflow with an interrupt and = increment an upper-half counter, making a 64-bit counter. 2) Set up the debug/profile/counter registers as some kind of device = (suggestion from a couple of months back that I have no more information = on)? 3) Support more ARM arches in a more general way? I have very little ARM = hardware (only other is a BeagleBoard-xM) to test/develop this on. Anyone interested in helping me or taking this over? :-) M --=20 Mark R V Murray --Apple-Mail=_92E64D00-B74B-488C-B31F-CFD2CA82718B Content-Disposition: attachment; filename=arm.diff Content-Type: application/octet-stream; name="arm.diff" Content-Transfer-Encoding: 7bit Index: sys/arm/arm/locore.S =================================================================== --- sys/arm/arm/locore.S (revision 256775) +++ sys/arm/arm/locore.S (working copy) @@ -175,6 +175,18 @@ mcr p15, 0, r0, c13, c0, 1 /* Set ASID to 0 */ #endif +#if defined(CPU_CORTEXA) + /* TODO: Better to do access to these counters as some kind of device? + * This is 32 bits. Use interrupt to make 64 bits? Random number generator + * doesn't care, but others might. See get_cyclecount(). + */ + + mov r7, #0x8000000F /* Set INTENS to 0 to block interrupts */ + mcr p15, 0, r7, c9, c14, 2 + mov r7, #1 /* Set PMNC[0] to 1 to enable CCNT */ + mcr p15, 0, r7, c9, c12, 0 +#endif + /* Set the Domain Access register. Very important! */ mov r0, #((DOMAIN_CLIENT << (PMAP_DOMAIN_KERNEL*2)) | DOMAIN_CLIENT) mcr p15, 0, r0, c3, c0, 0 Index: sys/arm/include/cpu.h =================================================================== --- sys/arm/include/cpu.h (revision 256775) +++ sys/arm/include/cpu.h (working copy) @@ -13,11 +13,21 @@ static __inline uint64_t get_cyclecount(void) { +#if defined(CPU_CORTEXA) + uint32_t ccnt; + + /* + * Read CCNT. Curses! Its only 32 bits. + * Fix this catching overflow with interrupt in locore.S? + */ + __asm __volatile("mrc p15, 0, %0, c9, c13, 0": "=r" (ccnt)); + return ((uint64_t)ccnt); +#else struct bintime bt; binuptime(&bt); return ((uint64_t)bt.sec << 56 | bt.frac >> 8); - +#endif } #endif --Apple-Mail=_92E64D00-B74B-488C-B31F-CFD2CA82718B Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii --Apple-Mail=_92E64D00-B74B-488C-B31F-CFD2CA82718B-- --Apple-Mail=_E99821B8-0642-4A65-9C48-B0CF61B5C7EE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUmQBK958vKOKE6LNAQpFsQP9HFU1je1H+A+xNWudnwBnzfQ3B4XKeD1T qP8hcUNj+mEwlrF+R0HU38k0gAPgGIJw0L9jNTapMonvE56vKrphfKqf8RSfBs3b LYN2FpVIX7ciFV7zzT1cBZB7YHhWSvE5q4Xx2ekU2ldU0DKJ3eZKAOgHnwbRu0TO 77NiU50LnVE= =6JGW -----END PGP SIGNATURE----- --Apple-Mail=_E99821B8-0642-4A65-9C48-B0CF61B5C7EE-- From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 22:03:26 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6CA7C6B8; Sun, 20 Oct 2013 22:03:26 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 41D5123A7; Sun, 20 Oct 2013 22:03:25 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VY15p-000NGn-0b; Sun, 20 Oct 2013 22:03:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9KM3MNj033234; Sun, 20 Oct 2013 16:03:22 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/OH79+rkLSF/p5n3UWuJre Subject: Re: ARM counter registers and get_cyclecount() From: Ian Lepore To: Mark Robert Vaughan Murray In-Reply-To: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Oct 2013 16:03:22 -0600 Message-ID: <1382306602.92499.117.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 22:03:26 -0000 On Sun, 2013-10-20 at 17:13 +0100, Mark Robert Vaughan Murray wrote: > Hi folks > > I asked a similar question to this a month or so ago, then got involved in other work, so apologies for the repetition! > > The random(4) device benefits from having a decent hardware get_cyclecount() implementation. In i386 and arm, we have a stopgap version that uses binuptime(), which is slow and prone to quantisation error. > > I've hacked up a minimalist hardware version for ARMv6/RPI (which is the only ARM I have access to, and I'm keen to use it for other things as well), and I'm looking for improvement advice and/or commit blessing. > > Things it could conceivably do better: > > 1) The counter is 32 bits only. At clocks of hundreds-of-megahertz, this will overflow in some 10's of seconds to maybe a minute, so it would be nice (but to essential) to trap the overflow with an interrupt and increment an upper-half counter, making a 64-bit counter. > Wouldn't that amount to creating a one-off implementation of binuptime()? (Except not one-off, but one-per-SoC-off). Does it really benefit from being a 64-bit counter? In what way do the upper bits help contribute to whatever random(4) does with the counter to generate entropy? > 2) Set up the debug/profile/counter registers as some kind of device (suggestion from a couple of months back that I have no more information on)? > Not all SoCs have such a thing. > 3) Support more ARM arches in a more general way? I have very little ARM hardware (only other is a BeagleBoard-xM) to test/develop this on. > This is the way to solve #2, for some definition of solve. For example, any platform that can do so would implement a cpu_get_fastcounter() function, and a weak-linkage default implementation would return binuptime() or something like that. But then there's likely to be quibbling over what "fast" means. -- Ian > Anyone interested in helping me or taking this over? :-) > > M From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 22:30:12 2013 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 ESMTP id C8816D95; Sun, 20 Oct 2013 22:30:12 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8E1B224EA; Sun, 20 Oct 2013 22:30:12 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VY1Vh-0002PR-Hz; Sun, 20 Oct 2013 23:30:11 +0100 Subject: Re: ARM counter registers and get_cyclecount() Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <1382306602.92499.117.camel@revolution.hippie.lan> Date: Sun, 20 Oct 2013 23:30:08 +0100 Message-Id: <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1510) X-SA-Score: -1.0 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 22:30:13 -0000 --Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Oct 2013, at 23:03, Ian Lepore wrote: > On Sun, 2013-10-20 at 17:13 +0100, Mark Robert Vaughan Murray wrote: >> Hi folks >>=20 >> I asked a similar question to this a month or so ago, then got = involved in other work, so apologies for the repetition! >>=20 >> The random(4) device benefits from having a decent hardware = get_cyclecount() implementation. In i386 and arm, we have a stopgap = version that uses binuptime(), which is slow and prone to quantisation = error. >>=20 >> I've hacked up a minimalist hardware version for ARMv6/RPI (which is = the only ARM I have access to, and I'm keen to use it for other things = as well), and I'm looking for improvement advice and/or commit blessing. >>=20 >> Things it could conceivably do better: >>=20 >> 1) The counter is 32 bits only. At clocks of hundreds-of-megahertz, = this will overflow in some 10's of seconds to maybe a minute, so it = would be nice (but to essential) to trap the overflow with an interrupt = and increment an upper-half counter, making a 64-bit counter. >>=20 >=20 > Wouldn't that amount to creating a one-off implementation of > binuptime()? (Except not one-off, but one-per-SoC-off). Not sure, but its get_cyclecount() that I'm trying to get to work on as = many systems/SoCs as possible. On amd64 and i386 (not the really early ones) get_cyclecount() reads the = TSC register (64-bit). This is hardware, and the timing info is really = useful for stochastic event timestamping due to its resolution. Last time I looked at binuptime(), it was not nearly as good in the low = bits due to quantisation error. > Does it really benefit from being a 64-bit counter? In what way do = the > upper bits help contribute to whatever random(4) does with the counter > to generate entropy? Not much, its just tidier. If there is a wrap in-between the = measurements used to calculate a delta-T, the result will look funny, = but not lose any resolute due to the wrap. This may make verifying the = entropy harder, but not impossible. >> 2) Set up the debug/profile/counter registers as some kind of device = (suggestion from a couple of months back that I have no more information = on)? >>=20 >=20 > Not all SoCs have such a thing. Sure, but is it worthwhile for those that do, and if so how? (What API = etc) >> 3) Support more ARM arches in a more general way? I have very little = ARM hardware (only other is a BeagleBoard-xM) to test/develop this on. >>=20 >=20 > This is the way to solve #2, for some definition of solve. For = example, > any platform that can do so would implement a cpu_get_fastcounter() > function, and a weak-linkage default implementation would return > binuptime() or something like that. But then there's likely to be > quibbling over what "fast" means. Well, we already have get_cyclecount() on most arches, and as its just a = wrapper for binuptime() in arm, I'm trying to fix it :-) M --=20 Mark R V Murray --Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUmRZcN58vKOKE6LNAQoMTgP/Ukw1hcoN0xkjKB2kwX+n5tXDmRwUCp8L Z1EQyFA030ku8/KFs5jYMnMV1t86GSYTYg8zQLn3IAWprosPckkC0nEXLUibJ0Qy JTjheXCpG1MhbWPxgWPb0DJI/g60xMnmmhftN6nFnA+9gZvduokMYSAr/M1OX4jv HdJc23NTzp0= =hbd7 -----END PGP SIGNATURE----- --Apple-Mail=_57C39E63-16B4-4034-8F2E-29841BEB4A2C-- From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 22:49:19 2013 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 ESMTP id B95FEFC; Sun, 20 Oct 2013 22:49:19 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DBE525C5; Sun, 20 Oct 2013 22:49:19 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VY1oE-0000bp-9Y; Sun, 20 Oct 2013 22:49:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9KMnFuR033256; Sun, 20 Oct 2013 16:49:15 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19mQQGvPL7eZHfrAbuM2Myd Subject: Re: ARM counter registers and get_cyclecount() From: Ian Lepore To: Mark Robert Vaughan Murray In-Reply-To: <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Oct 2013 16:49:15 -0600 Message-ID: <1382309355.92499.127.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 22:49:19 -0000 On Sun, 2013-10-20 at 23:30 +0100, Mark Robert Vaughan Murray wrote: > On 20 Oct 2013, at 23:03, Ian Lepore wrote: > > > On Sun, 2013-10-20 at 17:13 +0100, Mark Robert Vaughan Murray wrote: > >> Hi folks > >> > >> I asked a similar question to this a month or so ago, then got involved in other work, so apologies for the repetition! > >> > >> The random(4) device benefits from having a decent hardware get_cyclecount() implementation. In i386 and arm, we have a stopgap version that uses binuptime(), which is slow and prone to quantisation error. > >> > >> I've hacked up a minimalist hardware version for ARMv6/RPI (which is the only ARM I have access to, and I'm keen to use it for other things as well), and I'm looking for improvement advice and/or commit blessing. > >> > >> Things it could conceivably do better: > >> > >> 1) The counter is 32 bits only. At clocks of hundreds-of-megahertz, this will overflow in some 10's of seconds to maybe a minute, so it would be nice (but to essential) to trap the overflow with an interrupt and increment an upper-half counter, making a 64-bit counter. > >> > > > > Wouldn't that amount to creating a one-off implementation of > > binuptime()? (Except not one-off, but one-per-SoC-off). > > Not sure, but its get_cyclecount() that I'm trying to get to work on as many systems/SoCs as possible. > > On amd64 and i386 (not the really early ones) get_cyclecount() reads the TSC register (64-bit). This is hardware, and the timing info is really useful for stochastic event timestamping due to its resolution. > > Last time I looked at binuptime(), it was not nearly as good in the low bits due to quantisation error. > Could you be thinking of getbinuptime()? It returns the time as of the last tick, but binuptime() goes all the way to the hardware to return the time right now (and it handles counter rollover and such). There may be faster clocks available, which still gives get_cyclecount() some value, but binuptime() as a fallback implementation isn't horrible if the timecounter is already using the fastest clock available (or at least using one that's reasonable fast). I think we've been here before, but: get_cyclecount() is a HORRIBLE name. I would be fairly reluctant to implement that using a clock that runs slower than the cpu clock, because you'd just be lying, and nothing about the name makes it clear that the result might be something other than what the name promises. (And there aren't many arm SoCs that have a counter that fast.) There are other complexities that come to mind... things like clocks that run slower or even stop in power-saving modes, is that a problem? -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 23:01:06 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3F9324FD; Sun, 20 Oct 2013 23:01:06 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 03F5626A6; Sun, 20 Oct 2013 23:01:06 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VY1za-0002Ru-Tt; Mon, 21 Oct 2013 00:01:04 +0100 Subject: Re: ARM counter registers and get_cyclecount() Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FE892B73-F41E-414B-8EE8-D6837A37D3F2"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <1382309355.92499.127.camel@revolution.hippie.lan> Date: Mon, 21 Oct 2013 00:01:02 +0100 Message-Id: <25608D4E-C299-498A-8F77-3548D711F419@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> <1382309355.92499.127.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1510) X-SA-Score: -1.0 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 23:01:06 -0000 --Apple-Mail=_FE892B73-F41E-414B-8EE8-D6837A37D3F2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 20 Oct 2013, at 23:49, Ian Lepore wrote: >> Last time I looked at binuptime(), it was not nearly as good in the = low bits due to quantisation error. >>=20 >=20 > Could you be thinking of getbinuptime()? It returns the time as of = the > last tick, but binuptime() goes all the way to the hardware to return > the time right now (and it handles counter rollover and such). There > may be faster clocks available, which still gives get_cyclecount() = some > value, but binuptime() as a fallback implementation isn't horrible if > the timecounter is already using the fastest clock available (or at > least using one that's reasonable fast). I'm thinking of the numbers I see when I print the output of = get_cyclecount() while harvesting stochastic events on various = platforms. > I think we've been here before, but: get_cyclecount() is a HORRIBLE > name. I would be fairly reluctant to implement that using a clock = that > runs slower than the cpu clock, because you'd just be lying, and = nothing > about the name makes it clear that the result might be something other > than what the name promises. (And there aren't many arm SoCs that = have > a counter that fast.) Sigh. I'm not nearly as concerned with the name as I am with getting the = fastest available hardware counter as I can find. > There are other complexities that come to mind... things like clocks > that run slower or even stop in power-saving modes, is that a problem? Yup :-(. But if its fast and the highest-resolution non-quantised timing = available, I guess I'll use it. What I don't want is numbers with lots = of low bits being non random/skipped; I'd rather have a slower counter = still incrementing from the bottom bit up. If its running at = CPU/Instruction clock speed, it will do. M --=20 Mark R V Murray --Apple-Mail=_FE892B73-F41E-414B-8EE8-D6837A37D3F2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUmRgrt58vKOKE6LNAQqkJgQAsCspAT5s5BZa6xgfwbmYyfFXNcgDPt4/ 4BPvr1f0/PjZ8kN/DIAkLConfAfY4QlVnPCwSuKTE6w60Uj8GAkjkrndd4aP3ogY pkWOQUxzPwPXsPIhUpSo2zcb1PKdtIObr/hL44k69kLMjDQpSnb5VWbN58+WWlut gcgSZaI4lr8= =WX+l -----END PGP SIGNATURE----- --Apple-Mail=_FE892B73-F41E-414B-8EE8-D6837A37D3F2-- From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 16:36:18 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id B0F77EC0 for ; Sun, 20 Oct 2013 16:36:18 +0000 (UTC) (envelope-from gosha-necr@yandex.ru) Received: from forward3h.mail.yandex.net (forward3h.mail.yandex.net [IPv6:2a02:6b8:0:f05::3]) by mx1.freebsd.org (Postfix) with ESMTP id 665F321D2 for ; Sun, 20 Oct 2013 16:36:18 +0000 (UTC) Received: from web2h.yandex.ru (web2h.yandex.ru [84.201.186.31]) by forward3h.mail.yandex.net (Yandex) with ESMTP id 6D9BD1360C02 for ; Sun, 20 Oct 2013 20:36:15 +0400 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web2h.yandex.ru (Yandex) with ESMTP id EF8527419E9; Sun, 20 Oct 2013 20:36:14 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1382286975; bh=W4o7isiioD/4YLdxzRsZCWnP2xIA918O5TjObTWyL4k=; h=From:To:Subject:Date; b=S3LFi37s23aAHSjIIPotV7ogS0LpD64WunxpNYqom6DwFPAA56QU38I3Xpu87UFe+ DyFMMjUGbyYzrJkYXZ40eAVsTd7yOEe55OJlLfiMFUuNf9/wbBSS1uWVGveeHb4Fm4 kFRlIbyhrY1CZLt6L7S9/ZNqFPaC2FyuZ37AOpEk= Received: from net245.234.188-30.ertelecom.ru (net245.234.188-30.ertelecom.ru [188.234.245.30]) by web2h.yandex.ru with HTTP; Sun, 20 Oct 2013 20:36:14 +0400 From: =?koi8-r?B?59XM0cXXIOfP28E=?= To: freebsd-arm@freebsd.org Subject: Is NVidia Tegra {2,3,4} platform support exists or WIP? Message-Id: <280441382286974@web2h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Sun, 20 Oct 2013 22:36:14 +0600 X-Mailman-Approved-At: Sun, 20 Oct 2013 23:02:41 +0000 MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 16:36:18 -0000 Good day! There are many tablet devices based on that NVidia platform. Is it any work for bringing FreeBSD on that devices? Thank you! From owner-freebsd-arm@FreeBSD.ORG Sun Oct 20 23:58:13 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 4E1CC721; Sun, 20 Oct 2013 23:58:13 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 207382A95; Sun, 20 Oct 2013 23:58:12 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VY2so-000InH-0k; Sun, 20 Oct 2013 23:58:06 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9KNw3dt033287; Sun, 20 Oct 2013 17:58:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19GkM+Rm2tpdWR1zi+FfzQ6 Subject: Re: ARM counter registers and get_cyclecount() From: Ian Lepore To: Mark Robert Vaughan Murray In-Reply-To: <25608D4E-C299-498A-8F77-3548D711F419@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> <1382309355.92499.127.camel@revolution.hippie.lan> <25608D4E-C299-498A-8F77-3548D711F419@FreeBSD.org> Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Oct 2013 17:58:03 -0600 Message-ID: <1382313483.92499.136.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Oct 2013 23:58:13 -0000 On Mon, 2013-10-21 at 00:01 +0100, Mark Robert Vaughan Murray wrote: > On 20 Oct 2013, at 23:49, Ian Lepore wrote: > > >> Last time I looked at binuptime(), it was not nearly as good in the low bits due to quantisation error. > >> > > > > Could you be thinking of getbinuptime()? It returns the time as of the > > last tick, but binuptime() goes all the way to the hardware to return > > the time right now (and it handles counter rollover and such). There > > may be faster clocks available, which still gives get_cyclecount() some > > value, but binuptime() as a fallback implementation isn't horrible if > > the timecounter is already using the fastest clock available (or at > > least using one that's reasonable fast). > > I'm thinking of the numbers I see when I print the output of get_cyclecount() while harvesting stochastic events on various platforms. > > > I think we've been here before, but: get_cyclecount() is a HORRIBLE > > name. I would be fairly reluctant to implement that using a clock that > > runs slower than the cpu clock, because you'd just be lying, and nothing > > about the name makes it clear that the result might be something other > > than what the name promises. (And there aren't many arm SoCs that have > > a counter that fast.) > > Sigh. > > I'm not nearly as concerned with the name as I am with getting the fastest available hardware counter as I can find. > > > There are other complexities that come to mind... things like clocks > > that run slower or even stop in power-saving modes, is that a problem? > > Yup :-(. But if its fast and the highest-resolution non-quantised timing available, I guess I'll use it. What I don't want is numbers with lots of low bits being non random/skipped; I'd rather have a slower counter still incrementing from the bottom bit up. If its running at CPU/Instruction clock speed, it will do. > > M On the very newest arm boards I have there are counters that can run as fast as 66 MHz (cpu runs at 800-1000 MHz). That's by far the fastest I've seen yet. On older boards it's likely to be a few MHz at best. It's a pity you don't think the names are important. IMO, the names of things are at least as important as the implementation (and often more so, because they're harder to change and that puts a greater premium on getting them right). -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 00:03:06 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 13396847 for ; Mon, 21 Oct 2013 00:03:06 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from ozelot.schwarzes.net (ozelot.schwarzes.net [62.109.78.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9BD182AF3 for ; Mon, 21 Oct 2013 00:03:04 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) by ozelot.schwarzes.net (8.14.7/8.14.7) with ESMTP id r9KNh6j2019158 for ; Mon, 21 Oct 2013 01:43:06 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: freebsd-arm@FreeBSD.org Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Mon, 21 Oct 2013 01:42:36 +0200 (CEST) Message-ID: <43584768717.406e8ebb@mail.schwarzes.net> User-Agent: YAM/2.9-dev (MorphOS; PPC; rv:20131017r7173) Subject: raspberry pi BCM2708 hardware watchdog MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (ozelot.schwarzes.net [62.109.78.34]); Mon, 21 Oct 2013 01:43:06 +0200 (CEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 00:03:06 -0000 Hi, the BCM2708 SoC contain a hardware watchdog, using it, would be a good solution for the people which are running a remote rpi 24/7 to avoid these sudden system freezes. The watchdog (bcmwd0) is found when booting, but I'm not able to use it with the watchdogd (which is using /dev/fido to communicate with the watchdog). Seems that something is still missing. Any ideas? root@pizelot:~ # dmesg | grep Watchdog bcmwd0: mem 0x2010001c-0x20100027 on simplebus0 root@pizelot:~ # /etc/rc.d/watchdogd start Starting watchdogd. watchdogd: watchdog_patpat failed: Operation not supported watchdogd: patting the dog: Operation not supported /etc/rc.d/watchdogd: WARNING: failed to start watchdogd best regards, Andreas From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 02:04:39 2013 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 ESMTP id 3C9EF2FD for ; Mon, 21 Oct 2013 02:04:39 +0000 (UTC) (envelope-from johnsstephenelder@gmail.com) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BF4E02101 for ; Mon, 21 Oct 2013 02:04:38 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id u14so2022128lbd.29 for ; Sun, 20 Oct 2013 19:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZLA2nRgfLrOX0A1wOcQbFuI8MJ2VtM/z7C8UJKUWR3Y=; b=a1X2FUZCFRR1o/AoIkyfvKjyIQe2DhfCAM9/J/X/N4jEpckTw82ySEbNQzC6t91OAM VaSQrv9bJvb3BYlYR4x/rSgBVdlojTmrjif5J3B2wbSoECEIzHEIQuuWM/yHF+lozrTA Bc/n07xH5l59aCAYjoXkXKVrj8bt+gWPhnnRsGFaj1Gc+e1KR6JW2KKXcOHxKbsr+shK 0D21BkObFwyEdOAvhIVdWpzSn54yS5eq4zVKe7d3B7Jfd4kckS6sbbpoUfNRIGSjnc7K SzoRbjWtqftK0fq9Vn939NcUYDYA8hd1wwygfJl1lP2xfD8b1lHReJuksvZkcIXo55oA 11yA== MIME-Version: 1.0 X-Received: by 10.112.51.101 with SMTP id j5mr11274266lbo.17.1382321076763; Sun, 20 Oct 2013 19:04:36 -0700 (PDT) Received: by 10.112.147.102 with HTTP; Sun, 20 Oct 2013 19:04:36 -0700 (PDT) Date: Mon, 21 Oct 2013 10:04:36 +0800 Message-ID: Subject: About Cubieboard buildkernel Error From: John Elder To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 02:04:39 -0000 Hi, I have read this https://wiki.freebsd.org/FreeBSD/arm/Cubieboard # truncate -s 1024M cubie.img # mdconfig -f cubie.img -u0 # newfs /dev/md0 # mount /dev/md0 /mnt # make TARGET_ARCH=armv6 kernel-toolchain But I cant run # make TARGET_ARCH=armv6 KERNCONF=CUBIEBOARD buildkernel From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 02:05:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1972D337 for ; Mon, 21 Oct 2013 02:05:06 +0000 (UTC) (envelope-from johnsstephenelder@gmail.com) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F6EF2105 for ; Mon, 21 Oct 2013 02:05:05 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id ep20so2155807lab.34 for ; Sun, 20 Oct 2013 19:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=cGP0EWe+j8azxFKV46M7+bTS1mB/xpEKv+ffb5trV2I=; b=NPuG7QJ7um4XvyPKlhmhrriiDwQeiHL2w3cRxxJLBCdywjEcZPquJ0D347eGTnN6gA j8BVUL2YXc3HYjWuyUJc+VryeyGYqs+/33Fb947Ju5ZnZO04CqEYpy1VEipUdDNibSm9 lQmNyKXjA6MigeiKmAld29pK2vO3Zn/Z5SFjQzWlYzJ1repT7vF2Mf9BGJzwkqoC8qeL LkBJUV8gCcJCypnhcE5NKWkSNKU7p/I0fGPGfxt4L4JWDDgxorktbDxmCHTchWLVymf5 tTqjevXjLWba3yF9BCmrMhLRnKuXEdq2NId/HTCPUtQnb5dcYjjlKfvvIWOVtVsxWxK2 B37g== MIME-Version: 1.0 X-Received: by 10.152.26.72 with SMTP id j8mr11799185lag.19.1382321103567; Sun, 20 Oct 2013 19:05:03 -0700 (PDT) Received: by 10.112.147.102 with HTTP; Sun, 20 Oct 2013 19:05:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 10:05:03 +0800 Message-ID: Subject: Re: About Cubieboard buildkernel Error From: John Elder To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 02:05:06 -0000 It shows : -------------------------------------------------------------- >>> stage 2.3: build tools -------------------------------------------------------------- cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD; PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:/usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make SSP_CFLAGS= -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD -f /usr/src/sys/dev/aic7xxx/aicasm/Makefile Warning: Object directory not changed from original /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD cc -O2 -pipe -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c cc -O2 -pipe -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c cc -O2 -pipe -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wno-pointer-sign -c aicasm_gram.c cc1: warnings being treated as errors aicasm_gram.c:1539: warning: no previous prototype for 'yyparse' *** Error code 1 Stop in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD. On Mon, Oct 21, 2013 at 10:04 AM, John Elder wrote: > Hi, > I have read this https://wiki.freebsd.org/FreeBSD/arm/Cubieboard > > # truncate -s 1024M cubie.img # mdconfig -f cubie.img -u0 # newfs /dev/md0 # mount /dev/md0 /mnt # make TARGET_ARCH=armv6 kernel-toolchain > > But I cant run # make TARGET_ARCH=armv6 KERNCONF=CUBIEBOARD buildkernel > > From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 02:06:10 2013 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 ESMTP id B8E3737E for ; Mon, 21 Oct 2013 02:06:10 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ie0-x233.google.com (mail-ie0-x233.google.com [IPv6:2607:f8b0:4001:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8AD50210F for ; Mon, 21 Oct 2013 02:06:10 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id aq17so10823747iec.10 for ; Sun, 20 Oct 2013 19:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=V+WWRjBxXPR7/w286+svtXAE5F7dUgSrECZr/099pyE=; b=NY1C4pJ0v3MFTCLX5NvxwDtizcyFKc6OKLMDJkptyHwSjPO0o4bBNwgzBD9l+gYqRa HsUjEKAxp7c1GE5kX1vMOsDkrYfb14ZXPaTpqPNmLU32NN+7MmSVjcTYX5qWW5HRwJ7Z OekSZS3peNf62gKDP+0fcp8mn2xO5aF7TGEptnML7ln56VBXksMizlS4h/LZxZDJ5+pX EWKho00+5JP5BsgqlTRhEjqiECeFhJSmhmV/9vcAHJkrGs8o0IMDr+3Vx5hs+Q9xWCsw aWmP1MUZXY6VyV65pT8UI2v0VJFRtPvNkf3dRYGtqktmGB+po+MHR6RQz/wXJWs9gjUR KBSA== MIME-Version: 1.0 X-Received: by 10.42.29.129 with SMTP id r1mr4774icc.44.1382321169186; Sun, 20 Oct 2013 19:06:09 -0700 (PDT) Received: by 10.64.18.14 with HTTP; Sun, 20 Oct 2013 19:06:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Oct 2013 10:06:09 +0800 Message-ID: Subject: Re: About Cubieboard buildkernel Error From: Ganbold Tsagaankhuu To: John Elder Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 02:06:10 -0000 On Mon, Oct 21, 2013 at 10:04 AM, John Elder wrote: > Hi, > I have read this https://wiki.freebsd.org/FreeBSD/arm/Cubieboard > > # truncate -s 1024M cubie.img # mdconfig -f cubie.img -u0 # newfs > /dev/md0 # mount /dev/md0 /mnt # make TARGET_ARCH=armv6 > kernel-toolchain > > But I cant run # make TARGET_ARCH=armv6 KERNCONF=CUBIEBOARD buildkernel > What error you have? Ganbold > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://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 Oct 21 02:24:30 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 86AA06E6 for ; Mon, 21 Oct 2013 02:24:30 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5CEC721D0 for ; Mon, 21 Oct 2013 02:24:30 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VY5AT-0008Be-3p; Mon, 21 Oct 2013 02:24:29 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9L2OQJF033360; Sun, 20 Oct 2013 20:24:26 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19jJDa9Grx9YPMxPgAYQIU8 Subject: Re: About Cubieboard buildkernel Error From: Ian Lepore To: John Elder In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Sun, 20 Oct 2013 20:24:26 -0600 Message-ID: <1382322266.92499.139.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 02:24:30 -0000 On Mon, 2013-10-21 at 10:05 +0800, John Elder wrote: > It shows : > -------------------------------------------------------------- > >>> stage 2.3: build tools > -------------------------------------------------------------- > cd /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD; > PATH=/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/sbin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/bin:/usr/obj/arm.armv6/usr/src/tmp/legacy/usr/games:/usr/obj/arm.armv6/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin > MAKESRCPATH=/usr/src/sys/dev/aic7xxx/aicasm make SSP_CFLAGS= > -DNO_CPU_CFLAGS -DNO_CTF -DEARLY_BUILD -f > /usr/src/sys/dev/aic7xxx/aicasm/Makefile > Warning: Object directory not changed from original > /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD > cc -O2 -pipe -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wno-pointer-sign -c /usr/src/sys/dev/aic7xxx/aicasm/aicasm.c > cc -O2 -pipe -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wno-pointer-sign -c > /usr/src/sys/dev/aic7xxx/aicasm/aicasm_symbol.c > cc -O2 -pipe -I. -I/usr/src/sys/dev/aic7xxx/aicasm -std=gnu99 > -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter > -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type > -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter > -Wcast-align -Wno-pointer-sign -c aicasm_gram.c > cc1: warnings being treated as errors > aicasm_gram.c:1539: warning: no previous prototype for 'yyparse' > *** Error code 1 > > Stop in /usr/obj/arm.armv6/usr/src/sys/CUBIEBOARD. That happens when your build machine is running too old a version of freebsd. I used to have that problem on my 8.3 machine and eventually I just compiled the latest version of yacc and installed it to get around the problem. (I have to use 8.x for $work.) -- Ian From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 07:58:37 2013 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 ESMTP id 68FF82BF; Mon, 21 Oct 2013 07:58:37 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF5521E2; Mon, 21 Oct 2013 07:58:37 +0000 (UTC) Received: from [2001:470:9174:1:13a:7afc:940b:ecd7] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VYANm-0003Hg-9P; Mon, 21 Oct 2013 08:58:35 +0100 Subject: Re: ARM counter registers and get_cyclecount() Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: multipart/signed; boundary="Apple-Mail=_B80B1C2D-A2DA-4E05-B2EF-1E35C39EEBD1"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark Robert Vaughan Murray In-Reply-To: <1382313483.92499.136.camel@revolution.hippie.lan> Date: Mon, 21 Oct 2013 08:58:33 +0100 Message-Id: <448247EB-EE2D-438D-81DA-B2D415C14D8A@FreeBSD.org> References: <0D53AF4E-9EC4-42E1-8D9E-1ECB87A9CCE6@FreeBSD.org> <1382306602.92499.117.camel@revolution.hippie.lan> <78B77E93-BE2E-4CA2-9D1B-F994B795FABB@FreeBSD.org> <1382309355.92499.127.camel@revolution.hippie.lan> <25608D4E-C299-498A-8F77-3548D711F419@FreeBSD.org> <1382313483.92499.136.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1510) X-SA-Score: -1.0 Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 07:58:37 -0000 --Apple-Mail=_B80B1C2D-A2DA-4E05-B2EF-1E35C39EEBD1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 21 Oct 2013, at 00:58, Ian Lepore wrote: >>> There are other complexities that come to mind... things like clocks >>> that run slower or even stop in power-saving modes, is that a = problem? >>=20 >> Yup :-(. But if its fast and the highest-resolution non-quantised = timing available, I guess I'll use it. What I don't want is numbers with = lots of low bits being non random/skipped; I'd rather have a slower = counter still incrementing from the bottom bit up. If its running at = CPU/Instruction clock speed, it will do. >>=20 >> M >=20 > On the very newest arm boards I have there are counters that can run = as > fast as 66 MHz (cpu runs at 800-1000 MHz). That's by far the fastest > I've seen yet. On older boards it's likely to be a few MHz at best. Yuk :-(. I was hoping for some approximation to = 1-increment-per-instruction or close. > It's a pity you don't think the names are important. IMO, the names = of > things are at least as important as the implementation (and often more > so, because they're harder to change and that puts a greater premium = on > getting them right). I don't think its unimportant; I think it is another thread of = conversation. Right now i'm looking for a working counter with the right = physical characteristics. What name the beastie gets will likely be = apparent when its found/written. M --=20 Mark R V Murray --Apple-Mail=_B80B1C2D-A2DA-4E05-B2EF-1E35C39EEBD1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUmTeqd58vKOKE6LNAQp5iwP8CbSPQ4AtlaUmqBwmR8rGESjXvPZ6HCoF E5e0vw5//1DRNo1soj5uD0JDGSbvar0TPXLv1kbMgl7tWXpv3UmXrmdPnC7nfE+G q/LKN651mVuTLJdxq7iC+uA9qI+Xr3rhVyUL9Ph4mBujQyAT0x4l2Z+J0ZQ/RMOm +w+mjsWwquw= =wY+O -----END PGP SIGNATURE----- --Apple-Mail=_B80B1C2D-A2DA-4E05-B2EF-1E35C39EEBD1-- From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 11:06:44 2013 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 ESMTP id CF061999 for ; Mon, 21 Oct 2013 11:06:44 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9DE4C2E09 for ; Mon, 21 Oct 2013 11:06:44 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id r9LB6iLN018572 for ; Mon, 21 Oct 2013 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id r9LB6iqA018570 for freebsd-arm@FreeBSD.org; Mon, 21 Oct 2013 11:06:44 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 21 Oct 2013 11:06:44 GMT Message-Id: <201310211106.r9LB6iqA018570@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 11:06:44 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/182544 arm [patch] ARM busdma_machdep-v6.c o arm/182060 arm make buildworld fails on Raspberry PI o arm/181722 arm gdb on ARM unable to sensibly debug core file from ass o arm/181718 arm threads caused hung on ARM/RPI o arm/181601 arm Sporadic failure of root mount on ARM/Raspberry o arm/180080 arm Unmapped buffers on ARMv7 big-RAM boards o arm/179688 arm [patch] [rpi] serial console eats some characters at m o arm/179532 arm wireless networking on ARM o arm/178495 arm buildworld fail on arm/raspberry pi o arm/177687 arm gdb gets installed but does not know the EABI version o arm/177686 arm assertion failed in ld-elf.so.1 when invoking telnet w o arm/177685 arm [kernel] [patch] Correct return type and usage of at91 o arm/177538 arm tunefs(8) and mount(8) can not access a newfs(8)'d fil o arm/175803 arm building xdev for arm failing o arm/175605 arm please fix build binutils-2.23.1 in raspberry pi o arm/173617 arm Dreamplug exhibits eSATA file corruption using network o kern/171096 arm [arm][xscale][ixp]Allow 16bit access on PCI bus o arm/166256 arm build fail in pmap.c o arm/162159 arm [panic] USB errors leading to panic on DockStar 9.0-RC o arm/161110 arm /usr/src/sys/arm/include/signal.h is bad o arm/161044 arm devel/icu does not build on arm o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) p arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/134368 arm [new driver] [patch] nslu2_led driver for the LEDs on 28 problems total. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 12:21:33 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 ESMTP id 06E5DBDF; Mon, 21 Oct 2013 12:21:33 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C14A52475; Mon, 21 Oct 2013 12:21:32 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9LCLVb7041098; Mon, 21 Oct 2013 08:21:31 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9LCLVXU041096; Mon, 21 Oct 2013 12:21:31 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 21 Oct 2013 12:21:31 GMT Message-Id: <201310211221.r9LCLVXU041096@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 12:21:33 -0000 TB --- 2013-10-21 08:40:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-21 08:40:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-21 08:40:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-10-21 08:40:19 - cleaning the object tree TB --- 2013-10-21 08:40:19 - /usr/local/bin/svn stat /src TB --- 2013-10-21 08:40:24 - At svn revision 256834 TB --- 2013-10-21 08:40:25 - building world TB --- 2013-10-21 08:40:25 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 08:40:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 08:40:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 08:40:25 - SRCCONF=/dev/null TB --- 2013-10-21 08:40:25 - TARGET=arm TB --- 2013-10-21 08:40:25 - TARGET_ARCH=arm TB --- 2013-10-21 08:40:25 - TZ=UTC TB --- 2013-10-21 08:40:25 - __MAKE_CONF=/dev/null TB --- 2013-10-21 08:40:25 - cd /src TB --- 2013-10-21 08:40:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Oct 21 08:40:34 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 21 11:44:46 UTC 2013 TB --- 2013-10-21 11:44:46 - generating LINT kernel config TB --- 2013-10-21 11:44:46 - cd /src/sys/arm/conf TB --- 2013-10-21 11:44:46 - /usr/bin/make -B LINT TB --- 2013-10-21 11:44:46 - cd /src/sys/arm/conf TB --- 2013-10-21 11:44:46 - /usr/sbin/config -m LINT TB --- 2013-10-21 11:44:46 - building LINT kernel TB --- 2013-10-21 11:44:46 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 11:44:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 11:44:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 11:44:46 - SRCCONF=/dev/null TB --- 2013-10-21 11:44:46 - TARGET=arm TB --- 2013-10-21 11:44:46 - TARGET_ARCH=arm TB --- 2013-10-21 11:44:46 - TZ=UTC TB --- 2013-10-21 11:44:46 - __MAKE_CONF=/dev/null TB --- 2013-10-21 11:44:46 - cd /src TB --- 2013-10-21 11:44:46 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 21 11:44:46 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Oct 21 12:08:41 UTC 2013 TB --- 2013-10-21 12:08:41 - cd /src/sys/arm/conf TB --- 2013-10-21 12:08:41 - /usr/sbin/config -m AC100 TB --- 2013-10-21 12:08:41 - skipping AC100 kernel TB --- 2013-10-21 12:08:41 - cd /src/sys/arm/conf TB --- 2013-10-21 12:08:41 - /usr/sbin/config -m ARMADAXP TB --- 2013-10-21 12:08:41 - skipping ARMADAXP kernel TB --- 2013-10-21 12:08:41 - cd /src/sys/arm/conf TB --- 2013-10-21 12:08:41 - /usr/sbin/config -m ARNDALE TB --- 2013-10-21 12:08:41 - skipping ARNDALE kernel TB --- 2013-10-21 12:08:41 - cd /src/sys/arm/conf TB --- 2013-10-21 12:08:41 - /usr/sbin/config -m ATMEL TB --- 2013-10-21 12:08:41 - building ATMEL kernel TB --- 2013-10-21 12:08:41 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 12:08:41 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 12:08:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 12:08:41 - SRCCONF=/dev/null TB --- 2013-10-21 12:08:41 - TARGET=arm TB --- 2013-10-21 12:08:41 - TARGET_ARCH=arm TB --- 2013-10-21 12:08:41 - TZ=UTC TB --- 2013-10-21 12:08:41 - __MAKE_CONF=/dev/null TB --- 2013-10-21 12:08:41 - cd /src TB --- 2013-10-21 12:08:41 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Mon Oct 21 12:08:41 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Mon Oct 21 12:12:30 UTC 2013 TB --- 2013-10-21 12:12:30 - cd /src/sys/arm/conf TB --- 2013-10-21 12:12:30 - /usr/sbin/config -m AVILA TB --- 2013-10-21 12:12:30 - skipping AVILA kernel TB --- 2013-10-21 12:12:30 - cd /src/sys/arm/conf TB --- 2013-10-21 12:12:30 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-10-21 12:12:30 - skipping BEAGLEBONE kernel TB --- 2013-10-21 12:12:30 - cd /src/sys/arm/conf TB --- 2013-10-21 12:12:30 - /usr/sbin/config -m BWCT TB --- 2013-10-21 12:12:30 - building BWCT kernel TB --- 2013-10-21 12:12:30 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 12:12:30 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 12:12:30 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 12:12:30 - SRCCONF=/dev/null TB --- 2013-10-21 12:12:30 - TARGET=arm TB --- 2013-10-21 12:12:30 - TARGET_ARCH=arm TB --- 2013-10-21 12:12:30 - TZ=UTC TB --- 2013-10-21 12:12:30 - __MAKE_CONF=/dev/null TB --- 2013-10-21 12:12:30 - cd /src TB --- 2013-10-21 12:12:30 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Mon Oct 21 12:12:31 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Mon Oct 21 12:15:11 UTC 2013 TB --- 2013-10-21 12:15:11 - cd /src/sys/arm/conf TB --- 2013-10-21 12:15:11 - /usr/sbin/config -m CAMBRIA TB --- 2013-10-21 12:15:11 - skipping CAMBRIA kernel TB --- 2013-10-21 12:15:11 - cd /src/sys/arm/conf TB --- 2013-10-21 12:15:11 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-10-21 12:15:11 - building CNS11XXNAS kernel TB --- 2013-10-21 12:15:11 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 12:15:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 12:15:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 12:15:11 - SRCCONF=/dev/null TB --- 2013-10-21 12:15:11 - TARGET=arm TB --- 2013-10-21 12:15:11 - TARGET_ARCH=arm TB --- 2013-10-21 12:15:11 - TZ=UTC TB --- 2013-10-21 12:15:11 - __MAKE_CONF=/dev/null TB --- 2013-10-21 12:15:11 - cd /src TB --- 2013-10-21 12:15:11 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Mon Oct 21 12:15:11 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Mon Oct 21 12:18:47 UTC 2013 TB --- 2013-10-21 12:18:47 - cd /src/sys/arm/conf TB --- 2013-10-21 12:18:47 - /usr/sbin/config -m CRB TB --- 2013-10-21 12:18:47 - skipping CRB kernel TB --- 2013-10-21 12:18:47 - cd /src/sys/arm/conf TB --- 2013-10-21 12:18:47 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-10-21 12:18:47 - skipping CUBIEBOARD kernel TB --- 2013-10-21 12:18:47 - cd /src/sys/arm/conf TB --- 2013-10-21 12:18:47 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2013-10-21 12:18:47 - skipping CUBIEBOARD2 kernel TB --- 2013-10-21 12:18:47 - cd /src/sys/arm/conf TB --- 2013-10-21 12:18:47 - /usr/sbin/config -m DB-78XXX TB --- 2013-10-21 12:18:47 - building DB-78XXX kernel TB --- 2013-10-21 12:18:47 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 12:18:47 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 12:18:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 12:18:47 - SRCCONF=/dev/null TB --- 2013-10-21 12:18:47 - TARGET=arm TB --- 2013-10-21 12:18:47 - TARGET_ARCH=arm TB --- 2013-10-21 12:18:47 - TZ=UTC TB --- 2013-10-21 12:18:47 - __MAKE_CONF=/dev/null TB --- 2013-10-21 12:18:47 - cd /src TB --- 2013-10-21 12:18:47 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Mon Oct 21 12:18:47 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] ~~~~~~~~~~ ^ /src/sys/ufs/ffs/ffs_softdep.c:570:6: error: use of undeclared identifier 'secondary_writes' secondary_writes != 0 || ^ /src/sys/ufs/ffs/ffs_softdep.c:572:6: error: use of undeclared identifier 'secondary_accwrites' secondary_accwrites != mp->mnt_secondary_accwrites) ^ 6 errors generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/DB-78XXX *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-21 12:21:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-21 12:21:31 - ERROR: failed to build DB-78XXX kernel TB --- 2013-10-21 12:21:31 - 10271.07 user 2050.07 system 13272.02 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 20:49:28 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1206EDE6 for ; Mon, 21 Oct 2013 20:49:28 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-h21.telenor.se (smtprelay-h21.telenor.se [195.54.99.196]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C16EA2511 for ; Mon, 21 Oct 2013 20:49:27 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-h21.telenor.se (Postfix) with ESMTP id 976E9E99B1 for ; Mon, 21 Oct 2013 22:31:33 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At5dACuOZVJV5V4+PGdsb2JhbABZgweBDIdkoi2RIIJ6gS4XAwEBAQE4NYIlAQEFMgEjIxALDgouLQwKFAaIHQG6Ro9bB4QpA48ZmSOEejo X-IronPort-AV: E=Sophos;i="4.93,542,1378850400"; d="scan'208";a="637250251" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb2.telenor.se with ESMTP; 21 Oct 2013 22:31:33 +0200 Received: from localhost ([127.0.0.1] helo=webmail.alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VYM8S-000AWi-8e; Mon, 21 Oct 2013 22:31:32 +0200 Received: from 85.229.94.156 (SquirrelMail authenticated user alvis) by webmail.alvermark.net with HTTP; Mon, 21 Oct 2013 22:31:32 +0200 (CEST) Message-ID: <42970.85.229.94.156.1382387492.squirrel@webmail.alvermark.net> In-Reply-To: <1382282023-sup-4600@luwak.koffein.net> References: <1382282023-sup-4600@luwak.koffein.net> Date: Mon, 21 Oct 2013 22:31:32 +0200 (CEST) Subject: Re: pl011 UART driver (as used on Raspberry Pi) baud rate divisor From: "Jakob Alvermark" To: "Steven Lawrance" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 20:49:28 -0000 On Sun, October 20, 2013 17:25, Steven Lawrance wrote: > Hi all, > > this patch allows it to work on an i.MX233 with a fixed 24MHz > clock frequency and it obeys the values in the FDT. This makes me curious, FreeBSD on i.MX233? I happen to have a board lying here... Jakob From owner-freebsd-arm@FreeBSD.ORG Mon Oct 21 23:12:35 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6231B56F; Mon, 21 Oct 2013 23:12:35 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2845D2E00; Mon, 21 Oct 2013 23:12:34 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9LNCYpc023500; Mon, 21 Oct 2013 19:12:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9LNCYAr023499; Mon, 21 Oct 2013 23:12:34 GMT (envelope-from tinderbox@freebsd.org) Date: Mon, 21 Oct 2013 23:12:34 GMT Message-Id: <201310212312.r9LNCYAr023499@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 23:12:35 -0000 TB --- 2013-10-21 19:30:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-21 19:30:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-21 19:30:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-10-21 19:30:19 - cleaning the object tree TB --- 2013-10-21 19:33:04 - /usr/local/bin/svn stat /src TB --- 2013-10-21 19:33:07 - At svn revision 256858 TB --- 2013-10-21 19:33:08 - building world TB --- 2013-10-21 19:33:08 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 19:33:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 19:33:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 19:33:08 - SRCCONF=/dev/null TB --- 2013-10-21 19:33:08 - TARGET=arm TB --- 2013-10-21 19:33:08 - TARGET_ARCH=arm TB --- 2013-10-21 19:33:08 - TZ=UTC TB --- 2013-10-21 19:33:08 - __MAKE_CONF=/dev/null TB --- 2013-10-21 19:33:08 - cd /src TB --- 2013-10-21 19:33:08 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Mon Oct 21 19:33:14 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Mon Oct 21 22:35:36 UTC 2013 TB --- 2013-10-21 22:35:36 - generating LINT kernel config TB --- 2013-10-21 22:35:36 - cd /src/sys/arm/conf TB --- 2013-10-21 22:35:36 - /usr/bin/make -B LINT TB --- 2013-10-21 22:35:36 - cd /src/sys/arm/conf TB --- 2013-10-21 22:35:36 - /usr/sbin/config -m LINT TB --- 2013-10-21 22:35:36 - building LINT kernel TB --- 2013-10-21 22:35:36 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 22:35:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 22:35:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 22:35:36 - SRCCONF=/dev/null TB --- 2013-10-21 22:35:36 - TARGET=arm TB --- 2013-10-21 22:35:36 - TARGET_ARCH=arm TB --- 2013-10-21 22:35:36 - TZ=UTC TB --- 2013-10-21 22:35:36 - __MAKE_CONF=/dev/null TB --- 2013-10-21 22:35:36 - cd /src TB --- 2013-10-21 22:35:36 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Oct 21 22:35:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Mon Oct 21 22:59:18 UTC 2013 TB --- 2013-10-21 22:59:18 - cd /src/sys/arm/conf TB --- 2013-10-21 22:59:18 - /usr/sbin/config -m AC100 TB --- 2013-10-21 22:59:18 - skipping AC100 kernel TB --- 2013-10-21 22:59:18 - cd /src/sys/arm/conf TB --- 2013-10-21 22:59:18 - /usr/sbin/config -m ARMADAXP TB --- 2013-10-21 22:59:18 - skipping ARMADAXP kernel TB --- 2013-10-21 22:59:18 - cd /src/sys/arm/conf TB --- 2013-10-21 22:59:18 - /usr/sbin/config -m ARNDALE TB --- 2013-10-21 22:59:18 - skipping ARNDALE kernel TB --- 2013-10-21 22:59:18 - cd /src/sys/arm/conf TB --- 2013-10-21 22:59:18 - /usr/sbin/config -m ATMEL TB --- 2013-10-21 22:59:18 - building ATMEL kernel TB --- 2013-10-21 22:59:18 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 22:59:18 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 22:59:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 22:59:18 - SRCCONF=/dev/null TB --- 2013-10-21 22:59:18 - TARGET=arm TB --- 2013-10-21 22:59:18 - TARGET_ARCH=arm TB --- 2013-10-21 22:59:18 - TZ=UTC TB --- 2013-10-21 22:59:18 - __MAKE_CONF=/dev/null TB --- 2013-10-21 22:59:18 - cd /src TB --- 2013-10-21 22:59:18 - /usr/bin/make -B buildkernel KERNCONF=ATMEL >>> Kernel build for ATMEL started on Mon Oct 21 22:59:19 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for ATMEL completed on Mon Oct 21 23:03:11 UTC 2013 TB --- 2013-10-21 23:03:11 - cd /src/sys/arm/conf TB --- 2013-10-21 23:03:11 - /usr/sbin/config -m AVILA TB --- 2013-10-21 23:03:11 - skipping AVILA kernel TB --- 2013-10-21 23:03:11 - cd /src/sys/arm/conf TB --- 2013-10-21 23:03:11 - /usr/sbin/config -m BEAGLEBONE TB --- 2013-10-21 23:03:11 - skipping BEAGLEBONE kernel TB --- 2013-10-21 23:03:11 - cd /src/sys/arm/conf TB --- 2013-10-21 23:03:11 - /usr/sbin/config -m BWCT TB --- 2013-10-21 23:03:11 - building BWCT kernel TB --- 2013-10-21 23:03:11 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 23:03:11 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 23:03:11 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 23:03:11 - SRCCONF=/dev/null TB --- 2013-10-21 23:03:11 - TARGET=arm TB --- 2013-10-21 23:03:11 - TARGET_ARCH=arm TB --- 2013-10-21 23:03:11 - TZ=UTC TB --- 2013-10-21 23:03:11 - __MAKE_CONF=/dev/null TB --- 2013-10-21 23:03:11 - cd /src TB --- 2013-10-21 23:03:11 - /usr/bin/make -B buildkernel KERNCONF=BWCT >>> Kernel build for BWCT started on Mon Oct 21 23:03:11 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for BWCT completed on Mon Oct 21 23:05:46 UTC 2013 TB --- 2013-10-21 23:05:46 - cd /src/sys/arm/conf TB --- 2013-10-21 23:05:46 - /usr/sbin/config -m CAMBRIA TB --- 2013-10-21 23:05:46 - skipping CAMBRIA kernel TB --- 2013-10-21 23:05:46 - cd /src/sys/arm/conf TB --- 2013-10-21 23:05:46 - /usr/sbin/config -m CNS11XXNAS TB --- 2013-10-21 23:05:46 - building CNS11XXNAS kernel TB --- 2013-10-21 23:05:46 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 23:05:46 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 23:05:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 23:05:46 - SRCCONF=/dev/null TB --- 2013-10-21 23:05:46 - TARGET=arm TB --- 2013-10-21 23:05:46 - TARGET_ARCH=arm TB --- 2013-10-21 23:05:46 - TZ=UTC TB --- 2013-10-21 23:05:46 - __MAKE_CONF=/dev/null TB --- 2013-10-21 23:05:46 - cd /src TB --- 2013-10-21 23:05:46 - /usr/bin/make -B buildkernel KERNCONF=CNS11XXNAS >>> Kernel build for CNS11XXNAS started on Mon Oct 21 23:05:46 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for CNS11XXNAS completed on Mon Oct 21 23:09:23 UTC 2013 TB --- 2013-10-21 23:09:23 - cd /src/sys/arm/conf TB --- 2013-10-21 23:09:23 - /usr/sbin/config -m CRB TB --- 2013-10-21 23:09:23 - skipping CRB kernel TB --- 2013-10-21 23:09:23 - cd /src/sys/arm/conf TB --- 2013-10-21 23:09:23 - /usr/sbin/config -m CUBIEBOARD TB --- 2013-10-21 23:09:23 - skipping CUBIEBOARD kernel TB --- 2013-10-21 23:09:23 - cd /src/sys/arm/conf TB --- 2013-10-21 23:09:23 - /usr/sbin/config -m CUBIEBOARD2 TB --- 2013-10-21 23:09:23 - skipping CUBIEBOARD2 kernel TB --- 2013-10-21 23:09:23 - cd /src/sys/arm/conf TB --- 2013-10-21 23:09:23 - /usr/sbin/config -m DB-78XXX TB --- 2013-10-21 23:09:23 - building DB-78XXX kernel TB --- 2013-10-21 23:09:23 - CROSS_BUILD_TESTING=YES TB --- 2013-10-21 23:09:23 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-21 23:09:23 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-21 23:09:23 - SRCCONF=/dev/null TB --- 2013-10-21 23:09:23 - TARGET=arm TB --- 2013-10-21 23:09:23 - TARGET_ARCH=arm TB --- 2013-10-21 23:09:23 - TZ=UTC TB --- 2013-10-21 23:09:23 - __MAKE_CONF=/dev/null TB --- 2013-10-21 23:09:23 - cd /src TB --- 2013-10-21 23:09:23 - /usr/bin/make -B buildkernel KERNCONF=DB-78XXX >>> Kernel build for DB-78XXX started on Mon Oct 21 23:09:23 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] rm -f hack.c cat /src/sys/conf/ldscript.arm|sed s/KERNPHYSADDR/0x00900000/g| sed s/KERNVIRTADDR/0xc0900000/g > ldscript.arm MAKE=/obj/src/make.amd64/bmake sh /src/sys/conf/newvers.sh DB-88F78XX cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te -funwind-tables -mllvm -arm-enable-ehabi -ffreestanding -Werror vers.c linking kernel ffs_vfsops.o: In function `db_show_ffs': /src/sys/ufs/ffs/ffs_vfsops.c:(.text+0x1250): undefined reference to `db_print_ffs' /src/sys/ufs/ffs/ffs_vfsops.c:(.text+0x1288): undefined reference to `db_print_ffs' *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/DB-78XXX *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-21 23:12:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-21 23:12:33 - ERROR: failed to build DB-78XXX kernel TB --- 2013-10-21 23:12:33 - 10270.07 user 2033.16 system 13334.24 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 03:22:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 00A2BF46 for ; Tue, 22 Oct 2013 03:22:22 +0000 (UTC) (envelope-from johnsstephenelder@gmail.com) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 83B2C29E3 for ; Tue, 22 Oct 2013 03:22:22 +0000 (UTC) Received: by mail-lb0-f172.google.com with SMTP id c11so5360452lbj.17 for ; Mon, 21 Oct 2013 20:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=rkap86rEPjoIKLiwqRob12ttq+6Sk3Yx1uyy9QViuBc=; b=khsQ8f9MxUqFUokh+lwH2cnMDlJ972d/8WFklMYElcSkRHdv0JctoFXPFwHe8GXijF 5E327sIe0RLI9bo90YoeIF7WWjn+SscpMkS/mOgQKVTkc1mT/yghD+KJvGzl1axdVCxj xWjTvjHG+gYzf44c3TfuR1t48b11FKn7ANqXlW5J7cCmROOA44xNjg5iOA7EQCVjvtrs BeY3U0rzD4+O92AdYMoDgAl1lsP9TecelUIkBuOWAG6QXd4vaKTkn03mu9wbY4VZnGR/ T5eznSiyAoZim2mm7uqP5BIMGlamWOlU0S+g9mLO1TKlXY9y/mtaIEs5VB4scjGRpxlG X4lQ== MIME-Version: 1.0 X-Received: by 10.152.6.169 with SMTP id c9mr4775669laa.28.1382412140563; Mon, 21 Oct 2013 20:22:20 -0700 (PDT) Received: by 10.112.147.102 with HTTP; Mon, 21 Oct 2013 20:22:20 -0700 (PDT) Date: Tue, 22 Oct 2013 11:22:20 +0800 Message-ID: Subject: About building world for armv6 errors From: John Elder To: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 03:22:23 -0000 Hi, I have FreeBSD 9.1 and I am having error (not full error, because it is big) when building world for armv6. I use the CURRENT src code.=E2=80=8B buildworld.txt =E2=80=8BWho can help me to solve this problem? Thanks From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 04:22:41 2013 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 ESMTP id B8E13722 for ; Tue, 22 Oct 2013 04:22:41 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 594FC2C55 for ; Tue, 22 Oct 2013 04:22:41 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id z12so7446385wgg.0 for ; Mon, 21 Oct 2013 21:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=FEgKIEzi5evdXlQ+W7avhtW8qJ8E9q81vrDEweXho5A=; b=C5VLUKB+zDlxhK4YPZEeoN90wNXxzYMuLGfuz42cDpyTuRCGkk30godaCDEQwBe/ds yqNSKHEiEcwIXLZJorHGpHZZNMtd6fdnoIcxyLoVky97dklfvZ7fK44g1+K51FmWA50n JalP8SC+cMxZwlRCEEQ54eaoDrgKfyKnOjvV/ANykkuwyVRE4swgon3LJBmWIWTDOj9l 479s/Mh1EIIyuaeNuvRksO5uTmQ1NAga48aSGTL583Q779z3R5HvXVtZPArpYLTAP7Xu Mqa9v00CH/0mjWbqr8XwG0SektgkQDP6VCrf3HlEL4SP76TmHDTaziKw5dcSTfr2leC9 GK0A== X-Received: by 10.180.211.48 with SMTP id mz16mr8494652wic.63.1382415759318; Mon, 21 Oct 2013 21:22:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.206.132 with HTTP; Mon, 21 Oct 2013 21:22:09 -0700 (PDT) In-Reply-To: <43584768717.406e8ebb@mail.schwarzes.net> References: <43584768717.406e8ebb@mail.schwarzes.net> From: Jia-Shiun Li Date: Tue, 22 Oct 2013 12:22:09 +0800 Message-ID: Subject: Re: raspberry pi BCM2708 hardware watchdog To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 04:22:41 -0000 On Mon, Oct 21, 2013 at 7:42 AM, Andreas Schwarz wrote: > The watchdog (bcmwd0) is found when booting, but I'm not able to use it with the > watchdogd (which is using /dev/fido to communicate with the watchdog). Seems > that something is still missing. Any ideas? According to source, it appears to be empty inside. It needs someone to fulfill it with love^H^H^H^Hcode. Jia-Shiun. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 04:57:03 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 6F5C8A94 for ; Tue, 22 Oct 2013 04:57:03 +0000 (UTC) (envelope-from stl@koffein.net) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id 5306A2D8F for ; Tue, 22 Oct 2013 04:57:03 +0000 (UTC) Received: from homiemail-a9.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by hapkido.dreamhost.com (Postfix) with ESMTP id 5F0CC8311 for ; Mon, 21 Oct 2013 21:56:57 -0700 (PDT) Received: from homiemail-a9.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTP id 6A1C762606F; Mon, 21 Oct 2013 21:56:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h= content-type:from:to:cc:subject:in-reply-to:references:date :message-id:content-transfer-encoding; s=koffein.net; bh=3YFRdT2 ep6kANr2apw3D1tK5OWc=; b=etYG0Puhbo4kW5zz787BKPJdhwMsF5hEXN6g37v lubD1hyeCXNKtw6GJSMM0+3/jOwLFAQsj1ZxgQKICLHIWCx2BD/9QhCkduArXNGc bbet0p0xe5C5mRfHDX0SKZaG6hyt9ljrhoCLdY2Sel6XHH5o/kt7kPxb0aBhQs95 /TS4= Received: from localhost (unknown [213.211.139.38]) (Authenticated sender: stl@koffein.net) by homiemail-a9.g.dreamhost.com (Postfix) with ESMTPA id DF7F262606E; Mon, 21 Oct 2013 21:56:50 -0700 (PDT) Content-Type: text/plain; charset=UTF-8 From: Steven Lawrance To: Jakob Alvermark Subject: Re: pl011 UART driver (as used on Raspberry Pi) baud rate divisor In-reply-to: <42970.85.229.94.156.1382387492.squirrel@webmail.alvermark.net> References: <1382282023-sup-4600@luwak.koffein.net> <42970.85.229.94.156.1382387492.squirrel@webmail.alvermark.net> Date: Tue, 22 Oct 2013 06:56:05 +0200 Message-Id: <1382417301-sup-1012@luwak.koffein.net> User-Agent: Sup/0.14.1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 04:57:03 -0000 Excerpts from Jakob Alvermark's message of 2013-10-21 22:31:32 +0200: > On Sun, October 20, 2013 17:25, Steven Lawrance wrote: > > this patch allows it to work on an i.MX233 with a fixed 24MHz > > clock frequency and it obeys the values in the FDT. >=20 > This makes me curious, FreeBSD on i.MX233? > I happen to have a board lying here... I have just been playing around in my spare time and haven't gotten too far yet. The board I'm using is an OLinuXino-MINI-WiFi from Olimex. At the moment, it always panics somewhere very early in the boot, e.g.: http://pastebin.com/UmkcxpUd Steven From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 06:05:26 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0F940769 for ; Tue, 22 Oct 2013 06:05:26 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B2D51207A for ; Tue, 22 Oct 2013 06:05:25 +0000 (UTC) Received: from [207.81.161.55] (helo=[192.168.1.66]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VYUSj-0003eu-EA; Mon, 21 Oct 2013 22:25:03 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: raspberry pi BCM2708 hardware watchdog From: Oleksandr Tymoshenko In-Reply-To: <43584768717.406e8ebb@mail.schwarzes.net> Date: Mon, 21 Oct 2013 22:24:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43584768717.406e8ebb@mail.schwarzes.net> To: Andreas Schwarz X-Mailer: Apple Mail (2.1510) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: On 2013-10-20, at 4:42 PM, Andreas Schwarz wrote: > > Hi, > > the BCM2708 SoC contain a hardware watchdog, using it, would be a good solution > for the people which are running a remote rpi 24/7 to avoid these sudden system > freezes. > > The watchdog (bcmwd0) is found when booting, but I'm not able to use it with the > watchdogd (which is using /dev/fido to communicate with the watchdog). Seems > that something is still missing. Any ideas? > > root@pizelot:~ # dmesg | grep Watchdog > bcmwd0: mem 0x2010001c-0x20100027 on simplebus0 > > root@pizelot:~ # /etc/rc.d/watchdogd start > Starting watchdogd. > watchdogd: watchdog_patpat failed: Operation not supported > watchdogd: patting the dog: Operation not supported > /etc/rc.d/watchdogd: WARNING: failed to start watchdogd [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] 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: strcmp.org] Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 06:05:26 -0000 On 2013-10-20, at 4:42 PM, Andreas Schwarz = wrote: >=20 > Hi, >=20 > the BCM2708 SoC contain a hardware watchdog, using it, would be a good = solution > for the people which are running a remote rpi 24/7 to avoid these = sudden system=20 > freezes. >=20 > The watchdog (bcmwd0) is found when booting, but I'm not able to use = it with the=20 > watchdogd (which is using /dev/fido to communicate with the watchdog). = Seems > that something is still missing. Any ideas? >=20 > root@pizelot:~ # dmesg | grep Watchdog > bcmwd0: mem 0x2010001c-0x20100027 on = simplebus0 >=20 > root@pizelot:~ # /etc/rc.d/watchdogd start > Starting watchdogd. > watchdogd: watchdog_patpat failed: Operation not supported > watchdogd: patting the dog: Operation not supported > /etc/rc.d/watchdogd: WARNING: failed to start watchdogd Watchdog was used for rebooting device only. I've just committed = support for=20 actual watchdog function: = http://svnweb.freebsd.org/changeset/base/256871 From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 08:26:26 2013 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 ESMTP id E19A31DC for ; Tue, 22 Oct 2013 08:26:26 +0000 (UTC) (envelope-from 01aurelien@gmail.com) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7F62527D4 for ; Tue, 22 Oct 2013 08:26:26 +0000 (UTC) Received: by mail-ea0-f174.google.com with SMTP id z15so3985094ead.19 for ; Tue, 22 Oct 2013 01:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:to:date:content-type:mime-version :content-transfer-encoding; bh=Aa/cZQveyExbC/I+mYRf6lA1UBYRyZnT0/RItvGRPWk=; b=afPjNIem4ayShI6NZJuaPHj8+7v9ZUFumvNATgXrR8ZdhWwz5DeX0Y4Z1UQMPlvkVn jkshHfGTmV0g2k+1x1huVEamizlme+S/8v+5MpW9oVuVnj4zAMp2E9sPIIZWtjxyL7iK L3TUDt6iHueOzYBsWmci5WhJnvxkIO4Gj4lrNmNqg5icwKTIDOf7R1n1+dwhd/G+mCc/ P+gv5yR/y+OT7SSjFIpFwQc1LHYLLPADMrgd0j/g0ylU1gTYt2R4r2q6x4N7ZVrACS3K CQY94eKHw0Uv4y57KH0zeBJHs/9ZWCQD9SEhB62D05Kf/nI8zAHAWJPNL368/LnD2QHl BYfQ== X-Received: by 10.14.246.197 with SMTP id q45mr504748eer.120.1382430384825; Tue, 22 Oct 2013 01:26:24 -0700 (PDT) Received: from [128.141.43.162] (pb-d-128-141-43-162.cern.ch. [128.141.43.162]) by mx.google.com with ESMTPSA id bn13sm53915357eeb.11.2013.10.22.01.26.23 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Tue, 22 Oct 2013 01:26:24 -0700 (PDT) Message-ID: <1382430274.4378.2.camel@pandabook> Subject: glib20 compilation issue From: Aurelien Martin <01aurelien@gmail.com> To: freebsd-arm@freebsd.org Date: Tue, 22 Oct 2013 10:24:34 +0200 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 08:26:26 -0000 Hi all :) Unfortunately I didn't succeed to compile irssi due to glib20 compilation errors http://pastebin.com/sz60kXPq My config: * portsnap fetch update + pormaster -a -> OK * FreeBSD rpi 10.0-CURRENT FreeBSD 10.0-CURRENT #84 r252209M: Thu Jun 27 09:09:14 EDT 2013 * Tried both GCC or CLANG in /etc/make.conf Thanks by advance From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 09:08:16 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 75547BE1 for ; Tue, 22 Oct 2013 09:08:16 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from smtprelay-b21.telenor.se (smtprelay-b21.telenor.se [195.54.99.212]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 2EF6929EB for ; Tue, 22 Oct 2013 09:08:15 +0000 (UTC) Received: from ipb2.telenor.se (ipb2.telenor.se [195.54.127.165]) by smtprelay-b21.telenor.se (Postfix) with ESMTP id 47CDDEAEFC for ; Tue, 22 Oct 2013 10:37:21 +0200 (CEST) X-SENDER-IP: [85.229.94.62] X-LISTENER: [smtp.bredband.net] X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq5cAAs4ZlJV5V4+PGdsb2JhbABZgwc4TgaqKIVtji2BJBcDAQEBATg1giUBAQUyASMjEAsOCi4tDAoUBogdAQMFunWPRgeEKQOPGYofiySDYIR6Og X-IronPort-AV: E=Sophos;i="4.93,546,1378850400"; d="scan'208";a="637666553" Received: from c-3e5ee555.06-11-73746f31.cust.bredbandsbolaget.se (HELO sigyn.alvermark.net) ([85.229.94.62]) by ipb2.telenor.se with ESMTP; 22 Oct 2013 10:37:21 +0200 Received: from localhost ([127.0.0.1] helo=webmail.alvermark.net) by sigyn.alvermark.net with esmtp (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VYXSk-000CRR-K8; Tue, 22 Oct 2013 10:37:14 +0200 Received: from 212.247.8.97 (SquirrelMail authenticated user alvis) by webmail.alvermark.net with HTTP; Tue, 22 Oct 2013 10:37:14 +0200 (CEST) Message-ID: <52937.212.247.8.97.1382431034.squirrel@webmail.alvermark.net> Date: Tue, 22 Oct 2013 10:37:14 +0200 (CEST) Subject: Re: pl011 UART driver (as used on Raspberry Pi) baud rate divisor From: "Jakob Alvermark" To: "Steven Lawrance" User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit References: <1382282023-sup-4600@luwak.koffein.net> <42970.85.229.94.156.1382387492.squirrel@webmail.alvermark.net> <1382417301-sup-1012@luwak.koffein.net> In-Reply-To: <1382417301-sup-1012@luwak.koffein.net> Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 09:08:16 -0000 On Tue, October 22, 2013 06:56, Steven Lawrance wrote: > Excerpts from Jakob Alvermark's message of 2013-10-21 22:31:32 +0200: > >> On Sun, October 20, 2013 17:25, Steven Lawrance wrote: >> >>> this patch allows it to work on an i.MX233 with a fixed 24MHz clock >>> frequency and it obeys the values in the FDT. >> >> This makes me curious, FreeBSD on i.MX233? >> I happen to have a board lying here... >> > > I have just been playing around in my spare time and haven't gotten > too far yet. The board I'm using is an OLinuXino-MINI-WiFi from Olimex. > At the moment, it always panics somewhere very early in the > boot, e.g.: http://pastebin.com/UmkcxpUd Cool, I have the OLinuXino-MICRO myself. How do you boot it? U-boot? I guess you know NetBSD recently got support: http://www.asd.fi/cgi-bin/blog.cgi/NetBSD/NetBSD_OLinuXino.1024px If I could help in any way let me know Jakob From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 10:43:21 2013 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 ESMTP id 5EE3EEB4 for ; Tue, 22 Oct 2013 10:43:21 +0000 (UTC) (envelope-from freebsd.asc@strcmp.org) Received: from ozelot.schwarzes.net (ozelot.schwarzes.net [62.109.78.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E48142FF6 for ; Tue, 22 Oct 2013 10:43:20 +0000 (UTC) Received: from [62.109.78.35] (mosquito.schwarzes.net [62.109.78.35]) by ozelot.schwarzes.net (8.14.7/8.14.7) with ESMTP id r9MAh8Xb023774; Tue, 22 Oct 2013 12:43:08 +0200 (CEST) (envelope-from freebsd.asc@strcmp.org) From: Andreas Schwarz To: Oleksandr Tymoshenko Mail-Reply-To: Andreas Schwarz Mail-Followup-To: freebsd-arm@FreeBSD.org Date: Tue, 22 Oct 2013 12:42:06 +0200 (CEST) Message-ID: <435a3398131.16b97ee7@mail.schwarzes.net> In-Reply-To: References: <43584768717.406e8ebb@mail.schwarzes.net> User-Agent: YAM/2.9-dev (MorphOS; PPC; rv:20131017r7173) Subject: Re: raspberry pi BCM2708 hardware watchdog MIME-Version: 1.0 Content-Type: text/plain X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (ozelot.schwarzes.net [62.109.78.34]); Tue, 22 Oct 2013 12:43:09 +0200 (CEST) Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 10:43:21 -0000 On 21.10.13, Oleksandr Tymoshenko wrote: > On 2013-10-20, at 4:42 PM, Andreas Schwarz wrote: >> The watchdog (bcmwd0) is found when booting, but I'm not able to use it with the >> watchdogd (which is using /dev/fido to communicate with the watchdog). Seems >> that something is still missing. Any ideas? >> >> root@pizelot:~ # dmesg | grep Watchdog >> bcmwd0: mem 0x2010001c-0x20100027 on simplebus0 >> >> root@pizelot:~ # /etc/rc.d/watchdogd start >> Starting watchdogd. >> watchdogd: watchdog_patpat failed: Operation not supported >> watchdogd: patting the dog: Operation not supported >> /etc/rc.d/watchdogd: WARNING: failed to start watchdogd > > Watchdog was used for rebooting device only. I've just committed support for > actual watchdog function: http://svnweb.freebsd.org/changeset/base/256871 Rebooting is fine, thank you very much. Regards -- PGP: 0x661AB571 From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 11:47:01 2013 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 ESMTP id 08CCCCD1 for ; Tue, 22 Oct 2013 11:47:01 +0000 (UTC) (envelope-from stl@koffein.net) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by mx1.freebsd.org (Postfix) with ESMTP id DE834240A for ; Tue, 22 Oct 2013 11:47:00 +0000 (UTC) Received: from homiemail-a6.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by hapkido.dreamhost.com (Postfix) with ESMTP id 709DDDEDD8 for ; Tue, 22 Oct 2013 04:47:00 -0700 (PDT) Received: from homiemail-a6.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTP id 2140C59806C for ; Tue, 22 Oct 2013 04:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=koffein.net; h= content-type:from:to:subject:in-reply-to:references:date :message-id:content-transfer-encoding; s=koffein.net; bh=1PWFnN+ ujgANI5DwX8zvgV2dMGM=; b=Qu5NfsCFFhEuljM1Q34tKIn4scY+xNFwEvkY01h hAVm/+HfySVff61uL8PLcURSe5NgTZxpFO53XTX00pgShUFPckKP4IxQePUE019s 2OvdVrRwsS5V4dyQzu3ADy9wRtA8vUDEuw8CClT1SA10O0w+0ALuDgG38Q+ZtZtU pPFI= Received: from localhost (unknown [213.211.139.38]) (Authenticated sender: stl@koffein.net) by homiemail-a6.g.dreamhost.com (Postfix) with ESMTPA id A56B759806B for ; Tue, 22 Oct 2013 04:46:53 -0700 (PDT) Content-Type: text/plain; charset=UTF-8 From: Steven Lawrance To: Jakob Alvermark Subject: Re: pl011 UART driver (as used on Raspberry Pi) baud rate divisor In-reply-to: <52937.212.247.8.97.1382431034.squirrel@webmail.alvermark.net> References: <1382282023-sup-4600@luwak.koffein.net> <42970.85.229.94.156.1382387492.squirrel@webmail.alvermark.net> <1382417301-sup-1012@luwak.koffein.net> <52937.212.247.8.97.1382431034.squirrel@webmail.alvermark.net> Date: Tue, 22 Oct 2013 13:30:48 +0200 Message-Id: <1382440896-sup-3285@luwak.koffein.net> User-Agent: Sup/0.14.1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 22 Oct 2013 12:12:00 +0000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 11:47:01 -0000 Excerpts from Jakob Alvermark's message of 2013-10-22 10:37:14 +0200: > Cool, I have the OLinuXino-MICRO myself. > How do you boot it? U-boot? Yep, using U-Boot and ubldr. I'm actually using crochet to build images for the SD card, which needed a couple of extra steps to create a "bootstream" image to go into the first partition. The tool you need for that is called elftosb, mentioned here: http://www.jann.cc/2013/02/07/u_boot_for_the_imx233_olinuxino.html It compiles fine on FreeBSD with a couple of trivial modifications. Perhaps a port for that would be nice? > I guess you know NetBSD recently got support: > http://www.asd.fi/cgi-bin/blog.cgi/NetBSD/NetBSD_OLinuXino.1024px Thanks, I hadn't seen that. Steven From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 17:54:06 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 0C9E71D9 for ; Tue, 22 Oct 2013 17:54:06 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9D56D2B6B for ; Tue, 22 Oct 2013 17:54:05 +0000 (UTC) Received: by mail-we0-f172.google.com with SMTP id q58so8663293wes.3 for ; Tue, 22 Oct 2013 10:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=BKY4WUVu1JldB0eN7focK/+VOsuMHiS9fgThOtkO5Kw=; b=TK0I0oTT9YWdTmrl5F8zjXZKPv+D1O/SxyBieQisYqrnnYLBDvYgj1ZSSkcRYofKKE U81OhhqbHCmiZr81rkXXrUal0eNpmv1jHk2vrCRwm+yqcXRgwJBj3D2fIT6YRMvMG2+q Y5wY5Qqdin7ZAPSIOITZ0oCuuPM8/s+KWmJyUj3ALRbEAQUnmcCH83MzvmJjCB0pBITz RbIlFk+clIwUAIT0jD6hxPoy3TcPyjqb6jTMKEQGA0zhYQ34JdZJ/0OLML2D4lV3tITx SEykxYYpd6jK3hlgplcKHTftDE/D6QziSDGwJ7FBdF7xiZLRaBAbDVsqNEBmUmSFUU59 W4bg== MIME-Version: 1.0 X-Received: by 10.194.77.167 with SMTP id t7mr19802458wjw.27.1382464443999; Tue, 22 Oct 2013 10:54:03 -0700 (PDT) Received: by 10.217.141.3 with HTTP; Tue, 22 Oct 2013 10:54:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 22 Oct 2013 19:54:03 +0200 Message-ID: Subject: Re: AVILA kernel From: Berislav Purgar To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 17:54:06 -0000 On Wed, Oct 16, 2013 at 7:46 PM, Berislav Purgar wrote: > Hello .. > > finally i got gatewroks GW2345 board but now i got stuck on loading > kernel. it stops on copyright message: > > RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 > IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 > Default server: 10.42.1.1 > RedBoot> load -b 0x200000 kernel > Using default protocol (TFTP) > Address offset = 0x40000000 > Entry point: 0x00200100, address range: 0x00200000-0x007817c8 > RedBoot> go > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 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.0-CURRENT #0 r256593M: Wed Oct 16 19:14:51 CEST 2013 > root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA arm > gcc version 4.2.1 20070831 patched [FreeBSD] > > on stock AVILA conf. file i got panic : > > RedBoot> ip > IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0 > Default server: 192.168.3.1 > RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 > IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 > Default server: 10.42.1.1 > RedBoot> load -b 0x200000 kernel > Using default protocol (TFTP) > Address offset = 0x40000000 > Entry point: 0x00200100, address range: 0x00200000-0x006a9808 > RedBoot> go > panic: mtx_lock() of spin mutex pmap @ /usr/src/sys/arm/arm/pmap.c:3676 > Uptime: 1s > > > tnx > :( .. still no solutions for this problem ? Beri From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 21:58:12 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 17C037E3 for ; Tue, 22 Oct 2013 21:58:12 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8C9C52B62 for ; Tue, 22 Oct 2013 21:58:10 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r9MLvjS9063522; Tue, 22 Oct 2013 23:57:45 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r9MLvjna063521; Tue, 22 Oct 2013 23:57:45 +0200 (CEST) (envelope-from mlfbsd) Date: Tue, 22 Oct 2013 23:57:45 +0200 From: Olivier Houchard To: Berislav Purgar Subject: Re: AVILA kernel Message-ID: <20131022215744.GA63463@ci0.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 21:58:12 -0000 On Tue, Oct 22, 2013 at 07:54:03PM +0200, Berislav Purgar wrote: > :( .. still no solutions for this problem ? > > Beri Hi Berislav, I just tested, and apart from a few issues with the npe driver which I fixed, it seems to work fine. My board has 128MB of RAM, but I tried to limit it to 64MB, and it worked as well. Can you test the kernel at http://www.ci0.org/kernel and tell me if it works for you ? If not, I'll dig in my stuff to see if I can find another avila board. The only thing I can think of, on top of my mind, is I'm still using gcc to compile my kernels, and you may be using clang. As I don't think clang has been tested much with big-endian arm, maybe there're a few issues there. If you're using it, can you try to switch to gcc to see if it is any better ? Thanks ! Olivier From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 22:27:57 2013 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 ESMTP id BAE483B4 for ; Tue, 22 Oct 2013 22:27:57 +0000 (UTC) (envelope-from mlfbsd@kanar.ci0.org) Received: from kanar.ci0.org (unknown [IPv6:2a01:e0b:1:150:ca0a:a9ff:fef1:a4c9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54E992D07 for ; Tue, 22 Oct 2013 22:27:57 +0000 (UTC) Received: from kanar.ci0.org (pluxor@localhost [127.0.0.1]) by kanar.ci0.org (8.14.5/8.14.5) with ESMTP id r9MMRVK7063687; Wed, 23 Oct 2013 00:27:31 +0200 (CEST) (envelope-from mlfbsd@kanar.ci0.org) Received: (from mlfbsd@localhost) by kanar.ci0.org (8.14.5/8.14.5/Submit) id r9MMRVUe063686; Wed, 23 Oct 2013 00:27:31 +0200 (CEST) (envelope-from mlfbsd) Date: Wed, 23 Oct 2013 00:27:31 +0200 From: Olivier Houchard To: Andrew Turner Subject: Re: AVILA kernel Message-ID: <20131022222731.GA63670@ci0.org> References: <20131022215744.GA63463@ci0.org> <20131022232323.35652386@bender.Home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131022232323.35652386@bender.Home> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Berislav Purgar , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 22:27:57 -0000 On Tue, Oct 22, 2013 at 11:23:23PM +0100, Andrew Turner wrote: > On Tue, 22 Oct 2013 23:57:45 +0200 > Olivier Houchard wrote: > > The only thing I can think of, on top of my mind, is I'm still using > > gcc to compile my kernels, and you may be using clang. As I don't > > think clang has been tested much with big-endian arm, maybe there're > > a few issues there. If you're using it, can you try to switch to gcc > > to see if it is any better ? > > Clang has no support for big-endian ARM. There is someone working on > it, but last time I looked it was not upstreamed. Then I guess it rules out a potential clang problem. I'm quite at a loss as to why it would work for me, and am quite interested in hearing if my kernel works for Berislav or not. Olivier From owner-freebsd-arm@FreeBSD.ORG Tue Oct 22 22:33:10 2013 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 ESMTP id 3EBE1559 for ; Tue, 22 Oct 2013 22:33:10 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 214CC2D73 for ; Tue, 22 Oct 2013 22:33:09 +0000 (UTC) Received: from bender.Home (97e5e46b.skybroadband.com [151.229.228.107]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 424675E30F; Tue, 22 Oct 2013 22:23:30 +0000 (UTC) Date: Tue, 22 Oct 2013 23:23:23 +0100 From: Andrew Turner To: Olivier Houchard Subject: Re: AVILA kernel Message-ID: <20131022232323.35652386@bender.Home> In-Reply-To: <20131022215744.GA63463@ci0.org> References: <20131022215744.GA63463@ci0.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Berislav Purgar , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 22:33:10 -0000 On Tue, 22 Oct 2013 23:57:45 +0200 Olivier Houchard wrote: > The only thing I can think of, on top of my mind, is I'm still using > gcc to compile my kernels, and you may be using clang. As I don't > think clang has been tested much with big-endian arm, maybe there're > a few issues there. If you're using it, can you try to switch to gcc > to see if it is any better ? Clang has no support for big-endian ARM. There is someone working on it, but last time I looked it was not upstreamed. Andrew From owner-freebsd-arm@FreeBSD.ORG Wed Oct 23 07:31:30 2013 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 ESMTP id 432AF6CF for ; Wed, 23 Oct 2013 07:31:30 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id C2C602938 for ; Wed, 23 Oct 2013 07:31:29 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so364082wes.21 for ; Wed, 23 Oct 2013 00:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t/VcYMbJ/eXIrlJBbaQndkGQtF0pFzEPp9nEUIB5oz0=; b=CzrCFPgPaZwxP/XtF6V8k90eKAYZ9rVfQCGPX4T+Sog5u8z6zjfIEiK1nO5fvS2YX/ FKh4IMU6vxUgaN0vEn0aaGv74z0WCEMy3aUsn6GPEem4U7BoAYNEb2+yGtWdGG0OvxvK Eud8JLUcH7/FiSFhMNPTf5JEo9Eir2oWbhgnTdkzXa9WG77hEX9Y/2f2JeLFilPDO6Hp CdNpgaR53pzkEXMRfLPi/jLolRt5sOkje13X5mT/dSf5iSx7uo6YqOCst8U3It+Sd84c N36nn9a5OhJ3DgFiXWySpYJ2Z9mk+xfEq1nSessXtmBKhQTAdUsVHlaM6NCwn87lFIdn 136g== MIME-Version: 1.0 X-Received: by 10.194.110.166 with SMTP id ib6mr260844wjb.14.1382513487985; Wed, 23 Oct 2013 00:31:27 -0700 (PDT) Received: by 10.217.141.3 with HTTP; Wed, 23 Oct 2013 00:31:27 -0700 (PDT) In-Reply-To: <20131022222731.GA63670@ci0.org> References: <20131022215744.GA63463@ci0.org> <20131022232323.35652386@bender.Home> <20131022222731.GA63670@ci0.org> Date: Wed, 23 Oct 2013 09:31:27 +0200 Message-ID: Subject: Re: AVILA kernel From: Berislav Purgar To: Olivier Houchard Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 07:31:30 -0000 On Wed, Oct 23, 2013 at 12:27 AM, Olivier Houchard wrote: > On Tue, Oct 22, 2013 at 11:23:23PM +0100, Andrew Turner wrote: > > On Tue, 22 Oct 2013 23:57:45 +0200 > > Olivier Houchard wrote: > > > The only thing I can think of, on top of my mind, is I'm still using > > > gcc to compile my kernels, and you may be using clang. As I don't > > > think clang has been tested much with big-endian arm, maybe there're > > > a few issues there. If you're using it, can you try to switch to gcc > > > to see if it is any better ? > > > > Clang has no support for big-endian ARM. There is someone working on > > it, but last time I looked it was not upstreamed. > > Then I guess it rules out a potential clang problem. I'm quite at a loss > as to why it would work for me, and am quite interested in hearing if my > kernel works for Berislav or not. > > Olivier > Hi Olivier ... it works !!!! :))))) .. now what i need to do ?? == Executing boot script in 5.000 seconds - enter ^C to abort RedBoot> fis load boot2.freebsd RedBoot> go FreeBSD ARM (Gateworks Avila) boot2 v0.4 - Default: /boot/kernel/kernel boot: Could not locate "ufs:ROOTDEVNAME" to fix kernel boot device, check ROOTDEVNAMEt KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 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.0-CURRENT #185: Tue Oct 22 23:48:55 CEST 2013 doginou@hulglah.ci0.org:/usr/src/sys/arm/compile/AVILA arm gcc version 4.2.1 20070831 patched [FreeBSD] CPU: IXP425 533MHz rev 1 (ARMv5TE) (XScale core) Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way instruction cache 32KB/32B 32-way write-back-locking data cache real memory = 67108864 (64 MB) SET CLEAN SVA TO c20e4000 avail memory = 57012224 (54 MB) random device not loaded; using insecure entropy SETTING UP IDLE THREAD YOYOYOYOYOYOYO random: initialized ixp0: ixp0: 37fff pcib0: on ixp0 pci0: on pcib0 ath0: irq 27 at device 2.0 on pci0 ath0: AR9220 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ixpclk0: on ixp0 ixpiic0: on ixp0 iicbb0: on ixpiic0 iicbus0: on iicbb0 master-only iic0: on iicbus0 ad74180: at addr 0x50 on iicbus0 ds1672_rtc0: at addr 0xd0 on iicbus0 ixpwdog0: on ixp0 uart0: on ixp0 uart0: console (115200,n,8,1) uart1: on ixp0 ixpqmgr0: on ixp0 npe0: on ixp0 npe0: MAC at 0xc8009000 npe0: MII at 0xc8009000 npe0: load fw image IXP425.NPE-B Func 0x2 Rev 2.1 npe0: attaching PHYs failed npe0: cannot activate npe device_attach: npe0 attach returned 6 npe1: on ixp0 npe1: MAC at 0xc800a000 npe1: MII at 0xc8009000 npe1: load fw image IXP425.NPE-C Func 0x5 Rev 2.1 miibus0: on npe1 ukphy0: PHY 1 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto npe1: Ethernet address: 00:d0:12:13:59:23 ata_avila0: on ixp0 ata0: on ata_avila0 led_avila0: on ixp0 gpio_avila0: on ixp0 gpioc0: on gpio_avila0 gpiobus0: on gpio_avila0 Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000 Timecounters tick every 10.000 msec ada0 at ata0 bus 0 scbus0 target 0 lun 0 ada0: CFA-4 device ada0: Serial Number AHZ080609133711 ada0: 16.700MB/s transfers (PIO4, PIO 512bytes) ada0: 3825MB (7835184 512 byte sectors: 16H 63S/T 7773C) ada0: Previously was known as ad0 bootpc_init: wired to interface 'npe0' Beri From owner-freebsd-arm@FreeBSD.ORG Wed Oct 23 19:49:58 2013 Return-Path: Delivered-To: arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 446AFFFC; Wed, 23 Oct 2013 19:49:58 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 177492B74; Wed, 23 Oct 2013 19:49:57 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9NJnvHW097684; Wed, 23 Oct 2013 15:49:57 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9NJnvWL097681; Wed, 23 Oct 2013 19:49:57 GMT (envelope-from tinderbox@freebsd.org) Date: Wed, 23 Oct 2013 19:49:57 GMT Message-Id: <201310231949.r9NJnvWL097681@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2013 19:49:58 -0000 TB --- 2013-10-23 16:30:19 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-23 16:30:19 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-23 16:30:19 - starting HEAD tinderbox run for arm/arm TB --- 2013-10-23 16:30:19 - cleaning the object tree TB --- 2013-10-23 16:30:19 - /usr/local/bin/svn stat /src TB --- 2013-10-23 16:30:24 - At svn revision 256981 TB --- 2013-10-23 16:30:25 - building world TB --- 2013-10-23 16:30:25 - CROSS_BUILD_TESTING=YES TB --- 2013-10-23 16:30:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-23 16:30:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-23 16:30:25 - SRCCONF=/dev/null TB --- 2013-10-23 16:30:25 - TARGET=arm TB --- 2013-10-23 16:30:25 - TARGET_ARCH=arm TB --- 2013-10-23 16:30:25 - TZ=UTC TB --- 2013-10-23 16:30:25 - __MAKE_CONF=/dev/null TB --- 2013-10-23 16:30:25 - cd /src TB --- 2013-10-23 16:30:25 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Wed Oct 23 16:30:31 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Oct 23 19:34:00 UTC 2013 TB --- 2013-10-23 19:34:00 - generating LINT kernel config TB --- 2013-10-23 19:34:00 - cd /src/sys/arm/conf TB --- 2013-10-23 19:34:00 - /usr/bin/make -B LINT TB --- 2013-10-23 19:34:00 - cd /src/sys/arm/conf TB --- 2013-10-23 19:34:00 - /usr/sbin/config -m LINT TB --- 2013-10-23 19:34:00 - building LINT kernel TB --- 2013-10-23 19:34:00 - CROSS_BUILD_TESTING=YES TB --- 2013-10-23 19:34:00 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-23 19:34:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-23 19:34:00 - SRCCONF=/dev/null TB --- 2013-10-23 19:34:00 - TARGET=arm TB --- 2013-10-23 19:34:00 - TARGET_ARCH=arm TB --- 2013-10-23 19:34:00 - TZ=UTC TB --- 2013-10-23 19:34:00 - __MAKE_CONF=/dev/null TB --- 2013-10-23 19:34:00 - cd /src TB --- 2013-10-23 19:34:00 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Wed Oct 23 19:34:01 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] /src/sys/arm/mv/gpio.c:641:12: note: did you mean 'OF_xref_phandle'? ctrl = OF_xref_handle(fdt32_to_cpu(gpios[0])); ^~~~~~~~~~~~~~ OF_xref_phandle /src/sys/dev/ofw/openfirm.h:133:11: note: 'OF_xref_phandle' declared here phandle_t OF_xref_phandle(phandle_t xref); ^ 1 error generated. *** Error code 1 Stop. bmake[1]: stopped in /obj/arm.arm/src/sys/LINT *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-23 19:49:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-23 19:49:57 - ERROR: failed to build LINT kernel TB --- 2013-10-23 19:49:57 - 9340.68 user 1841.09 system 11977.34 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Thu Oct 24 06:53:44 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id C83D898 for ; Thu, 24 Oct 2013 06:53:44 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 311A62E40 for ; Thu, 24 Oct 2013 06:53:44 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so1834698wes.21 for ; Wed, 23 Oct 2013 23:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=X6ZHJr8cRJF/7lxf9qNdU39fstphGinWj0BAMb2Fkfk=; b=pnGxo4X0CJjP4Nz++Tk6lg7w1Ifq4HYq+y+/MYTIu5drs4XD1RTzv9s+i4TXwqay4O b+A6DGVCKR0rD8AGUUq1t6gGXTnV7U+VcHX1R6CROozNmwgiKiEesS4bpN4RY7Oa2y2O 1ywbweBXPSvz73DSdNgpa45b8Vsa7xhjuEYSNG8zFH5JBmisuliwAUQSkqtWeBxkqcvO IkTz8f/MUvn7l8LeYt9V80GojpQT+Wg8Y17Nf9s4clUUobxUIWukkVuetnLkndYEPnFF eIplKYFaDIEslBHV95CkjaU6CdZF9NL+VLN9MQniybGFGjcX+7CqSqSzQYZpKhc7LAuh 1d+g== MIME-Version: 1.0 X-Received: by 10.180.126.103 with SMTP id mx7mr691699wib.39.1382597621443; Wed, 23 Oct 2013 23:53:41 -0700 (PDT) Received: by 10.217.141.3 with HTTP; Wed, 23 Oct 2013 23:53:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Oct 2013 08:53:41 +0200 Message-ID: Subject: Re: AVILA kernel From: Berislav Purgar To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 06:53:44 -0000 On Wed, Oct 16, 2013 at 7:46 PM, Berislav Purgar wrote: > Hello .. > > finally i got gatewroks GW2345 board but now i got stuck on loading > kernel. it stops on copyright message: > > RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 > IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 > Default server: 10.42.1.1 > RedBoot> load -b 0x200000 kernel > Using default protocol (TFTP) > Address offset = 0x40000000 > Entry point: 0x00200100, address range: 0x00200000-0x007817c8 > RedBoot> go > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2013 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.0-CURRENT #0 r256593M: Wed Oct 16 19:14:51 CEST 2013 > root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA arm > gcc version 4.2.1 20070831 patched [FreeBSD] > > on stock AVILA conf. file i got panic : > > RedBoot> ip > IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0 > Default server: 192.168.3.1 > RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 > IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 > Default server: 10.42.1.1 > RedBoot> load -b 0x200000 kernel > Using default protocol (TFTP) > Address offset = 0x40000000 > Entry point: 0x00200100, address range: 0x00200000-0x006a9808 > RedBoot> go > panic: mtx_lock() of spin mutex pmap @ /usr/src/sys/arm/arm/pmap.c:3676 > Uptime: 1s > > > tnx > Ok .. i manage to do something but still i got problem .. first of all i have to disable ARM_EABI in src.conf WITHOUT_ARM_EABI=yes after that i have to build kernel-toolchain make TARGET=arm TARGET_ARCH=armeb kernel-toolchain and kernel make TARGET=arm TARGET_ARCH=armeb KERNCONF=AVILA buildkernel result is here : RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 Default server: 10.42.1.1 RedBoot> load -b 0x200000 kernel Using default protocol (TFTP) Address offset = 0x40000000 Entry point: 0x00200100, address range: 0x00200000-0x006ad228 RedBoot> go KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2013 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.0-CURRENT #1 r256953:257039M: Thu Oct 24 08:47:18 CEST 2013 root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA arm gcc version 4.2.1 20070831 patched [FreeBSD] CPU: IXP425 533MHz rev 1 (ARMv5TE) (XScale core) Big-endian DC enabled IC enabled WB enabled LABT branch prediction enabled 32KB/32B 32-way instruction cache 32KB/32B 32-way write-back-locking data cache real memory = 67108864 (64 MB) avail memory = 57012224 (54 MB) random device not loaded; using insecure entropy random: initialized ixp0: ixp0: 37fff pcib0: on ixp0 pci0: on pcib0 ath0: irq 27 at device 2.0 on pci0 ath0: AR9220 mac 128.2 RF5133 phy 13.0 ath0: 2GHz radio: 0x0000; 5GHz radio: 0x00c0 ixpclk0: on ixp0 ixpiic0: on ixp0 iicbb0: on ixpiic0 iicbus0: on iicbb0 master-only iic0: on iicbus0 ad74180: at addr 0x50 on iicbus0 ds1672_rtc0: at addr 0xd0 on iicbus0 ixpwdog0: on ixp0 uart0: on ixp0 uart0: console (115200,n,8,1) uart1: on ixp0 ixpqmgr0: on ixp0 npe0: on ixp0 npe0: MAC at 0xc8009000 npe0: MII at 0xc8009000 npe0: load fw image IXP425.NPE-B Func 0x2 Rev 2.1 miibus0: on npe0 ukphy0: PHY 2 on miibus0 ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto npe0: Ethernet address: 00:d0:12:03:59:23 npe1: on ixp0 npe1: MAC at 0xc800a000 npe1: MII at 0xc8009000 npe1: load fw image IXP425.NPE-C Func 0x5 Rev 2.1 miibus1: on npe1 ukphy1: PHY 5 on miibus1 ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto npe1: Ethernet address: 00:d0:12:13:59:23 ata_avila0: on ixp0 ata0: on ata_avila0 led_avila0: on ixp0 gpio_avila0: on ixp0 gpioc0: on gpio_avila0 gpiobus0: on gpio_avila0 Timecounter "IXP4XX Timer" frequency 66666600 Hz quality 1000 Timecounters tick every 10.000 msec Fatal kernel mode data abort: 'Alignment Fault 3' trapframe: 0xc00facd8 FSR=00000003, FAR=c00faed4, spsr=a00000d3 r0 =c06b4110, r1 =c0e89000, r2 =c00faebc, r3 =10000280 r4 =c06b4110, r5 =c0e89000, r6 =c06c5c94, r7 =c06cc6c0 r8 =c06b4110, r9 =00000000, r10=00000104, r11=c00fad5c r12=c00fad0c, ssp=c00fad2c, slr=c03c8b34, pc =c057a1d0 [ thread pid 0 tid 100019 ] Stopped at cpu_switch+0x28: und 0xe1c281f8 db> db> bt Tracing pid 0 tid 100019 td 0xc0e89000 db_trace_self() at db_trace_self+0xc scp=0xc0569430 rlv=0xc0569480 (db_trace_thread+0x3c) rsp=0xc00fa9c8 rfp=0xc00fa9d4 db_trace_thread() at db_trace_thread+0xc scp=0xc0569450 rlv=0xc022b93c (db_command_init+0x648) rsp=0xc00fa9d8 rfp=0xc00fa9f4 db_command_init() at db_command_init+0x570 scp=0xc022b864 rlv=0xc022afe4 (db_skip_to_eol+0x49c) rsp=0xc00fa9f8 rfp=0xc00faa9c r5=0x00000000 r4=0xc066d1f4 db_skip_to_eol() at db_skip_to_eol+0x1d0 scp=0xc022ad18 rlv=0xc022b150 (db_command_loop+0x60) rsp=0xc00faaa0 rfp=0xc00faaac r10=0x600000d3 r8=0x00000003 r7=0x00000000 r6=0xc00faed4 r5=0xc066d4c4 r4=0xc00faab8 db_command_loop() at db_command_loop+0xc scp=0xc022b0fc rlv=0xc022d630 (X_db_sym_numargs+0xf4) rsp=0xc00faab0 rfp=0xc00fabcc X_db_sym_numargs() at X_db_sym_numargs+0x14 scp=0xc022d550 rlv=0xc03d5f9c (kdb_trap+0xa8) rsp=0xc00fabd0 rfp=0xc00fabf4 r4=0xc00facd8 kdb_trap() at kdb_trap+0xc scp=0xc03d5f00 rlv=0xc057a83c (badaddr_read+0x280) rsp=0xc00fabf8 rfp=0xc00fac14 r10=0x00000104 r8=0xc00facd8 r7=0xc0e89000 r6=0xc00faed4 r5=0x00000003 r4=0xc00facd8 badaddr_read() at badaddr_read+0xfc scp=0xc057a6b8 rlv=0xc057ac98 (prefetch_abort_handler+0x404) rsp=0xc00fac18 rfp=0xc00fac30 r6=0xc06c5c94 r5=0xc00facd8 r4=0xc0e89000 prefetch_abort_handler() at prefetch_abort_handler+0x3bc scp=0xc057ac50 rlv=0xc057adec (data_abort_handler+0x118) rsp=0xc00fac34 rfp=0xc00facd4 r5=0xffff1004 r4=0xc06cc008 data_abort_handler() at data_abort_handler+0xc scp=0xc057ace0 rlv=0xc056accc (exception_exit) rsp=0xc00facd8 rfp=0xc00fad5c r10=0x00000104 r9=0x00000000 r8=0xc06b4110 r7=0xc06cc6c0 r6=0xc06c5c94 r5=0xffff1004 r4=0xffffffff sched_switch() at sched_switch+0xc scp=0xc03c8990 rlv=0xc03aa6bc (mi_switch+0x204) rsp=0xc00fad60 rfp=0xc00fad88 r6=0x5ab0dd5d r5=0x00000000 r4=0x5ab0dd5d mi_switch() at mi_switch+0xc scp=0xc03aa4c4 rlv=0xc03e2d30 (sleepq_type+0x1d4) rsp=0xc00fad8c rfp=0xc00fadac r10=0xc0689c2c r9=0xffffe980 r8=0x00000000 r7=0xc05ec068 r6=0xc06c5c90 r5=0xc0689c2c r4=0xc06b4110 sleepq_type() at sleepq_type+0x80 scp=0xc03e2bdc rlv=0xc03e33a4 (sleepq_timedwait+0x6c) rsp=0xc00fadb0 rfp=0xc00fadcc r8=0xffffe9bb r7=0x00000000 r6=0xc06b4110 r5=0xc05ec068 r4=0xc0689c2c sleepq_timedwait() at sleepq_timedwait+0xc scp=0xc03e3344 rlv=0xc03aaf54 (_sleep+0x340) rsp=0xc00fadd0 rfp=0xc00fae18 r7=0x00000000 r6=0xc06c4098 r5=0x00000000 r4=0x00000000 _sleep() at _sleep+0xc scp=0xc03aac20 rlv=0xc03c8de0 (__stack_chk_fail+0x1ac) rsp=0xc00fae1c rfp=0xc00faea0 r10=0xffffe980 r9=0x0000003b r8=0x00000000 r7=0xc0689c2c r6=0x0000003c r5=0xc06c4098 r4=0x00000000 __stack_chk_fail() at __stack_chk_fail+0x114 scp=0xc03c8d48 rlv=0xc0359cf8 (mi_startup+0xf8) rsp=0xc00faea4 rfp=0xc00faeb8 r10=0x0000000a r9=0x00200100 r8=0x00000001 r7=0x002001b0 r6=0x00000000 r5=0x002001bc r4=0xc061f25c mi_startup() at mi_startup+0xc scp=0xc0359c0c rlv=0xc0200274 (btext+0x174) rsp=0xc00faebc rfp=0x00000000 r5=0x002001bc r4=0x002002b4 db> and what's the problem now? Beri From owner-freebsd-arm@FreeBSD.ORG Thu Oct 24 14:54:34 2013 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 ESMTP id DE135CA9 for ; Thu, 24 Oct 2013 14:54:33 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 482ED2394 for ; Thu, 24 Oct 2013 14:54:33 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id q59so2417547wes.25 for ; Thu, 24 Oct 2013 07:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=eqBvwpBVmxYVCqoY5EX4H8b5rtYjKNVfIopqxW1labU=; b=p0WDC+sY32Lj2aazfCNizvVZJ2ODXX0pBnnxXzk7njiNs9D9kNUhyWys9kUb+IeomA CXmI7bjgty5s2OeDTYPc2wTAQ4MmaHz1G98u6QpksdOcYMUlH6AGLqATFkqGkIeDF5el 7ZDRoTtow79YbbCB8ahNLE9N3UBzaKBwcvsE2RdjFVj0OBtwlZ7OgmWDfpSYlCX/Wt7I x/TjNw9ODLarMcw6KXi2yw0+BbgvbyX1bWCdKdVcfps511zvmMRvYoEMY8tNjY4AzbCD YMjLTdK/mh9H6WuxpVyC6nMZArmMXGgjz1R75fibe9zFzhGvEAq9JBqBh0TS/2V+2m04 Y5ng== MIME-Version: 1.0 X-Received: by 10.194.216.103 with SMTP id op7mr219342wjc.93.1382626471628; Thu, 24 Oct 2013 07:54:31 -0700 (PDT) Received: by 10.217.141.3 with HTTP; Thu, 24 Oct 2013 07:54:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Oct 2013 16:54:31 +0200 Message-ID: Subject: Re: AVILA kernel From: Berislav Purgar To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 14:54:34 -0000 On Thu, Oct 24, 2013 at 8:53 AM, Berislav Purgar wrote: > > > > On Wed, Oct 16, 2013 at 7:46 PM, Berislav Purgar wrote: > >> Hello .. >> >> finally i got gatewroks GW2345 board but now i got stuck on loading >> kernel. it stops on copyright message: >> >> RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 >> IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 >> Default server: 10.42.1.1 >> RedBoot> load -b 0x200000 kernel >> Using default protocol (TFTP) >> Address offset = 0x40000000 >> Entry point: 0x00200100, address range: 0x00200000-0x007817c8 >> RedBoot> go >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2013 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.0-CURRENT #0 r256593M: Wed Oct 16 19:14:51 CEST 2013 >> root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA arm >> gcc version 4.2.1 20070831 patched [FreeBSD] >> >> on stock AVILA conf. file i got panic : >> >> RedBoot> ip >> IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0 >> Default server: 192.168.3.1 >> RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 >> IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 >> Default server: 10.42.1.1 >> RedBoot> load -b 0x200000 kernel >> Using default protocol (TFTP) >> Address offset = 0x40000000 >> Entry point: 0x00200100, address range: 0x00200000-0x006a9808 >> RedBoot> go >> panic: mtx_lock() of spin mutex pmap @ /usr/src/sys/arm/arm/pmap.c:3676 >> Uptime: 1s >> >> >> tnx >> > > Ok .. i manage to do something but still i got problem .. first of all i > have to disable ARM_EABI in src.conf > WITHOUT_ARM_EABI=yes > > after that i have to build kernel-toolchain > make TARGET=arm TARGET_ARCH=armeb kernel-toolchain > > and kernel > make TARGET=arm TARGET_ARCH=armeb KERNCONF=AVILA buildkernel > > result is here : > > > RedBoot> ip -h 10.42.1.1 -l > 10.42.1.11 > IP: 10.42.1.11/255.255.255.0, Gateway: > 0.0.0.0 > Default server: > 10.42.1.1 > RedBoot> load -b 0x200000 > kernel > Using default protocol > (TFTP) > Address offset = > 0x40000000 > Entry point: 0x00200100, address range: > 0x00200000-0x006ad228 > RedBoot> > go > KDB: debugger backends: > ddb > KDB: current backend: > ddb > Copyright (c) 1992-2013 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.0-CURRENT #1 r256953:257039M: Thu Oct 24 08:47:18 CEST > 2013 > root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA > arm > gcc version 4.2.1 20070831 patched > [FreeBSD] > CPU: IXP425 533MHz rev 1 (ARMv5TE) (XScale > core) > Big-endian DC enabled IC enabled WB enabled LABT branch prediction > enabled > 32KB/32B 32-way instruction > cache > 32KB/32B 32-way write-back-locking data > cache > real memory = 67108864 (64 > MB) > avail memory = 57012224 (54 > MB) > random device not loaded; using insecure > entropy > random: > initialized > ixp0: IXP4XX> > ixp0: > 37fff > pcib0: on > ixp0 > pci0: on > pcib0 > ath0: irq 27 at device 2.0 on > pci0 > ath0: AR9220 mac 128.2 RF5133 phy > 13.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: > 0x00c0 > ixpclk0: on > ixp0 > ixpiic0: on > ixp0 > iicbb0: on > ixpiic0 > iicbus0: on iicbb0 > master-only > iic0: on > iicbus0 > ad74180: at addr 0x50 on > iicbus0 > ds1672_rtc0: at addr 0xd0 on > iicbus0 > ixpwdog0: on > ixp0 > uart0: on > ixp0 > uart0: console > (115200,n,8,1) > uart1: on > ixp0 > ixpqmgr0: on > ixp0 > npe0: on > ixp0 > npe0: MAC at > 0xc8009000 > npe0: MII at > 0xc8009000 > npe0: load fw image IXP425.NPE-B Func 0x2 Rev > 2.1 > miibus0: on > npe0 > ukphy0: PHY 2 on > miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > auto > npe0: Ethernet address: > 00:d0:12:03:59:23 > npe1: on > ixp0 > npe1: MAC at > 0xc800a000 > npe1: MII at > 0xc8009000 > npe1: load fw image IXP425.NPE-C Func 0x5 Rev > 2.1 > miibus1: on > npe1 > ukphy1: PHY 5 on > miibus1 > ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > auto > npe1: Ethernet address: > 00:d0:12:13:59:23 > ata_avila0: on > ixp0 > ata0: on > ata_avila0 > led_avila0: on > ixp0 > gpio_avila0: on > ixp0 > gpioc0: on > gpio_avila0 > gpiobus0: on > gpio_avila0 > Timecounter "IXP4XX Timer" frequency 66666600 Hz quality > 1000 > Timecounters tick every 10.000 > msec > Fatal kernel mode data abort: 'Alignment Fault > 3' > trapframe: > 0xc00facd8 > FSR=00000003, FAR=c00faed4, > spsr=a00000d3 > r0 =c06b4110, r1 =c0e89000, r2 =c00faebc, r3 > =10000280 > r4 =c06b4110, r5 =c0e89000, r6 =c06c5c94, r7 > =c06cc6c0 > r8 =c06b4110, r9 =00000000, r10=00000104, > r11=c00fad5c > r12=c00fad0c, ssp=c00fad2c, slr=c03c8b34, pc > =c057a1d0 > > > [ thread pid 0 tid 100019 > ] > Stopped at cpu_switch+0x28: und > 0xe1c281f8 > db> > > db> > bt > Tracing pid 0 tid 100019 td > 0xc0e89000 > db_trace_self() at > db_trace_self+0xc > scp=0xc0569430 rlv=0xc0569480 > (db_trace_thread+0x3c) > rsp=0xc00fa9c8 > rfp=0xc00fa9d4 > db_trace_thread() at > db_trace_thread+0xc > scp=0xc0569450 rlv=0xc022b93c > (db_command_init+0x648) > rsp=0xc00fa9d8 > rfp=0xc00fa9f4 > db_command_init() at > db_command_init+0x570 > scp=0xc022b864 rlv=0xc022afe4 > (db_skip_to_eol+0x49c) > rsp=0xc00fa9f8 > rfp=0xc00faa9c > r5=0x00000000 > r4=0xc066d1f4 > db_skip_to_eol() at > db_skip_to_eol+0x1d0 > scp=0xc022ad18 rlv=0xc022b150 > (db_command_loop+0x60) > rsp=0xc00faaa0 > rfp=0xc00faaac > r10=0x600000d3 > r8=0x00000003 > r7=0x00000000 r6=0xc00faed4 r5=0xc066d4c4 > r4=0xc00faab8 > db_command_loop() at > db_command_loop+0xc > scp=0xc022b0fc rlv=0xc022d630 > (X_db_sym_numargs+0xf4) > rsp=0xc00faab0 > rfp=0xc00fabcc > X_db_sym_numargs() at > X_db_sym_numargs+0x14 > scp=0xc022d550 rlv=0xc03d5f9c > (kdb_trap+0xa8) > rsp=0xc00fabd0 > rfp=0xc00fabf4 > > r4=0xc00facd8 > kdb_trap() at > kdb_trap+0xc > scp=0xc03d5f00 rlv=0xc057a83c > (badaddr_read+0x280) > rsp=0xc00fabf8 > rfp=0xc00fac14 > r10=0x00000104 > r8=0xc00facd8 > r7=0xc0e89000 r6=0xc00faed4 r5=0x00000003 > r4=0xc00facd8 > badaddr_read() at > badaddr_read+0xfc > scp=0xc057a6b8 rlv=0xc057ac98 > (prefetch_abort_handler+0x404) > rsp=0xc00fac18 > rfp=0xc00fac30 > r6=0xc06c5c94 > r5=0xc00facd8 > > r4=0xc0e89000 > prefetch_abort_handler() at > prefetch_abort_handler+0x3bc > scp=0xc057ac50 rlv=0xc057adec > (data_abort_handler+0x118) > rsp=0xc00fac34 > rfp=0xc00facd4 > r5=0xffff1004 > r4=0xc06cc008 > data_abort_handler() at > data_abort_handler+0xc > scp=0xc057ace0 rlv=0xc056accc > (exception_exit) > rsp=0xc00facd8 > rfp=0xc00fad5c > r10=0x00000104 > r9=0x00000000 > r8=0xc06b4110 r7=0xc06cc6c0 r6=0xc06c5c94 > r5=0xffff1004 > > r4=0xffffffff > sched_switch() at > sched_switch+0xc > scp=0xc03c8990 rlv=0xc03aa6bc > (mi_switch+0x204) > rsp=0xc00fad60 > rfp=0xc00fad88 > r6=0x5ab0dd5d > r5=0x00000000 > > r4=0x5ab0dd5d > mi_switch() at > mi_switch+0xc > scp=0xc03aa4c4 rlv=0xc03e2d30 > (sleepq_type+0x1d4) > rsp=0xc00fad8c > rfp=0xc00fadac > r10=0xc0689c2c > r9=0xffffe980 > r8=0x00000000 r7=0xc05ec068 r6=0xc06c5c90 > r5=0xc0689c2c > > r4=0xc06b4110 > sleepq_type() at > sleepq_type+0x80 > scp=0xc03e2bdc rlv=0xc03e33a4 > (sleepq_timedwait+0x6c) > rsp=0xc00fadb0 > rfp=0xc00fadcc > r8=0xffffe9bb > r7=0x00000000 > r6=0xc06b4110 r5=0xc05ec068 > r4=0xc0689c2c > sleepq_timedwait() at > sleepq_timedwait+0xc > scp=0xc03e3344 rlv=0xc03aaf54 > (_sleep+0x340) > rsp=0xc00fadd0 > rfp=0xc00fae18 > r7=0x00000000 > r6=0xc06c4098 > r5=0x00000000 > r4=0x00000000 > _sleep() at > _sleep+0xc > scp=0xc03aac20 rlv=0xc03c8de0 > (__stack_chk_fail+0x1ac) > rsp=0xc00fae1c > rfp=0xc00faea0 > r10=0xffffe980 > r9=0x0000003b > r8=0x00000000 r7=0xc0689c2c r6=0x0000003c > r5=0xc06c4098 > > r4=0x00000000 > __stack_chk_fail() at > __stack_chk_fail+0x114 > scp=0xc03c8d48 rlv=0xc0359cf8 > (mi_startup+0xf8) > rsp=0xc00faea4 > rfp=0xc00faeb8 > r10=0x0000000a > r9=0x00200100 > r8=0x00000001 r7=0x002001b0 r6=0x00000000 > r5=0x002001bc > > r4=0xc061f25c > mi_startup() at > mi_startup+0xc > scp=0xc0359c0c rlv=0xc0200274 > (btext+0x174) > rsp=0xc00faebc > rfp=0x00000000 > r5=0x002001bc > r4=0x002002b4 > db> > > and what's the problem now? > > Beri > Nobody ?? From owner-freebsd-arm@FreeBSD.ORG Thu Oct 24 15:58:34 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1CD7ABF2; Thu, 24 Oct 2013 15:58:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B25CD27B4; Thu, 24 Oct 2013 15:58:33 +0000 (UTC) Received: by mail-qe0-f45.google.com with SMTP id 8so1570296qea.32 for ; Thu, 24 Oct 2013 08:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=E+/bOD5UDJhTVrTzfZe+3l8e0YAEPF1wPTbf4nCsjog=; b=Oh95OCfV6zKmWcYS0SPKHyUiLAURhOKusYo4dW/U8OichWdA+em5OaikY4fKWRcssc iKFpCAYRC+TeZx5bW0SSMlB7HuPgxOIbBqcCS1O5hqhl1H/lzSl73A9LUF1sPOY74Aug 9twJo0KiMl3XWk3625WCCYmP5Dy0ji0eNvUX07tkKfeQ/r4a96YsIg92GEzpwOoIuEI+ +WD1J9FoYg6pRdxFpbo4N7kxVLKsxMgNy9yqofOGqtlgcYhcHqwFUItGY7UDZovNnlal 9Y2EfaCLMITbF9BfRA9nC2LOZ2uVeONiqaQ/2VVawiFtGkS2avKfTHO/E2dRemjLSOCe LY/g== MIME-Version: 1.0 X-Received: by 10.224.157.14 with SMTP id z14mr4999497qaw.90.1382630312770; Thu, 24 Oct 2013 08:58:32 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.224.207.66 with HTTP; Thu, 24 Oct 2013 08:58:32 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Oct 2013 08:58:32 -0700 X-Google-Sender-Auth: a8U-qZnmk-BJdmXFLOHo6e2eAeU Message-ID: Subject: Re: AVILA kernel From: Adrian Chadd To: Berislav Purgar , Andrew Turner Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 15:58:34 -0000 The EABI guy is Andrew Turner. Andrew - any ideas? -adrian On 23 October 2013 23:53, Berislav Purgar wrote: > On Wed, Oct 16, 2013 at 7:46 PM, Berislav Purgar > wrote: > > > Hello .. > > > > finally i got gatewroks GW2345 board but now i got stuck on loading > > kernel. it stops on copyright message: > > > > RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 > > IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 > > Default server: 10.42.1.1 > > RedBoot> load -b 0x200000 kernel > > Using default protocol (TFTP) > > Address offset = 0x40000000 > > Entry point: 0x00200100, address range: 0x00200000-0x007817c8 > > RedBoot> go > > KDB: debugger backends: ddb > > KDB: current backend: ddb > > Copyright (c) 1992-2013 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.0-CURRENT #0 r256593M: Wed Oct 16 19:14:51 CEST 2013 > > root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA arm > > gcc version 4.2.1 20070831 patched [FreeBSD] > > > > on stock AVILA conf. file i got panic : > > > > RedBoot> ip > > IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0 > > Default server: 192.168.3.1 > > RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 > > IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 > > Default server: 10.42.1.1 > > RedBoot> load -b 0x200000 kernel > > Using default protocol (TFTP) > > Address offset = 0x40000000 > > Entry point: 0x00200100, address range: 0x00200000-0x006a9808 > > RedBoot> go > > panic: mtx_lock() of spin mutex pmap @ /usr/src/sys/arm/arm/pmap.c:3676 > > Uptime: 1s > > > > > > tnx > > > > Ok .. i manage to do something but still i got problem .. first of all i > have to disable ARM_EABI in src.conf > WITHOUT_ARM_EABI=yes > > after that i have to build kernel-toolchain > make TARGET=arm TARGET_ARCH=armeb kernel-toolchain > > and kernel > make TARGET=arm TARGET_ARCH=armeb KERNCONF=AVILA buildkernel > > result is here : > > RedBoot> ip -h 10.42.1.1 -l > 10.42.1.11 > IP: 10.42.1.11/255.255.255.0, Gateway: > 0.0.0.0 > Default server: > 10.42.1.1 > RedBoot> load -b 0x200000 > kernel > Using default protocol > (TFTP) > Address offset = > 0x40000000 > Entry point: 0x00200100, address range: > 0x00200000-0x006ad228 > RedBoot> > go > KDB: debugger backends: > ddb > KDB: current backend: > ddb > Copyright (c) 1992-2013 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.0-CURRENT #1 r256953:257039M: Thu Oct 24 08:47:18 CEST > 2013 > root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA > arm > gcc version 4.2.1 20070831 patched > [FreeBSD] > CPU: IXP425 533MHz rev 1 (ARMv5TE) (XScale > core) > Big-endian DC enabled IC enabled WB enabled LABT branch prediction > enabled > 32KB/32B 32-way instruction > cache > 32KB/32B 32-way write-back-locking data > cache > real memory = 67108864 (64 > MB) > avail memory = 57012224 (54 > MB) > random device not loaded; using insecure > entropy > random: > initialized > ixp0: IXP4XX> > ixp0: > 37fff > pcib0: on > ixp0 > pci0: on > pcib0 > ath0: irq 27 at device 2.0 on > pci0 > ath0: AR9220 mac 128.2 RF5133 phy > 13.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: > 0x00c0 > ixpclk0: on > ixp0 > ixpiic0: on > ixp0 > iicbb0: on > ixpiic0 > iicbus0: on iicbb0 > master-only > iic0: on > iicbus0 > ad74180: at addr 0x50 on > iicbus0 > ds1672_rtc0: at addr 0xd0 on > iicbus0 > ixpwdog0: on > ixp0 > uart0: on > ixp0 > uart0: console > (115200,n,8,1) > uart1: on > ixp0 > ixpqmgr0: on > ixp0 > npe0: on > ixp0 > npe0: MAC at > 0xc8009000 > npe0: MII at > 0xc8009000 > npe0: load fw image IXP425.NPE-B Func 0x2 Rev > 2.1 > miibus0: on > npe0 > ukphy0: PHY 2 on > miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > auto > npe0: Ethernet address: > 00:d0:12:03:59:23 > npe1: on > ixp0 > npe1: MAC at > 0xc800a000 > npe1: MII at > 0xc8009000 > npe1: load fw image IXP425.NPE-C Func 0x5 Rev > 2.1 > miibus1: on > npe1 > ukphy1: PHY 5 on > miibus1 > ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > auto > npe1: Ethernet address: > 00:d0:12:13:59:23 > ata_avila0: on > ixp0 > ata0: on > ata_avila0 > led_avila0: on > ixp0 > gpio_avila0: on > ixp0 > gpioc0: on > gpio_avila0 > gpiobus0: on > gpio_avila0 > Timecounter "IXP4XX Timer" frequency 66666600 Hz quality > 1000 > Timecounters tick every 10.000 > msec > Fatal kernel mode data abort: 'Alignment Fault > 3' > trapframe: > 0xc00facd8 > FSR=00000003, FAR=c00faed4, > spsr=a00000d3 > r0 =c06b4110, r1 =c0e89000, r2 =c00faebc, r3 > =10000280 > r4 =c06b4110, r5 =c0e89000, r6 =c06c5c94, r7 > =c06cc6c0 > r8 =c06b4110, r9 =00000000, r10=00000104, > r11=c00fad5c > r12=c00fad0c, ssp=c00fad2c, slr=c03c8b34, pc > =c057a1d0 > > > [ thread pid 0 tid 100019 > ] > Stopped at cpu_switch+0x28: und > 0xe1c281f8 > db> > > db> > bt > Tracing pid 0 tid 100019 td > 0xc0e89000 > db_trace_self() at > db_trace_self+0xc > scp=0xc0569430 rlv=0xc0569480 > (db_trace_thread+0x3c) > rsp=0xc00fa9c8 > rfp=0xc00fa9d4 > db_trace_thread() at > db_trace_thread+0xc > scp=0xc0569450 rlv=0xc022b93c > (db_command_init+0x648) > rsp=0xc00fa9d8 > rfp=0xc00fa9f4 > db_command_init() at > db_command_init+0x570 > scp=0xc022b864 rlv=0xc022afe4 > (db_skip_to_eol+0x49c) > rsp=0xc00fa9f8 > rfp=0xc00faa9c > r5=0x00000000 > r4=0xc066d1f4 > db_skip_to_eol() at > db_skip_to_eol+0x1d0 > scp=0xc022ad18 rlv=0xc022b150 > (db_command_loop+0x60) > rsp=0xc00faaa0 > rfp=0xc00faaac > r10=0x600000d3 > r8=0x00000003 > r7=0x00000000 r6=0xc00faed4 r5=0xc066d4c4 > r4=0xc00faab8 > db_command_loop() at > db_command_loop+0xc > scp=0xc022b0fc rlv=0xc022d630 > (X_db_sym_numargs+0xf4) > rsp=0xc00faab0 > rfp=0xc00fabcc > X_db_sym_numargs() at > X_db_sym_numargs+0x14 > scp=0xc022d550 rlv=0xc03d5f9c > (kdb_trap+0xa8) > rsp=0xc00fabd0 > rfp=0xc00fabf4 > > r4=0xc00facd8 > kdb_trap() at > kdb_trap+0xc > scp=0xc03d5f00 rlv=0xc057a83c > (badaddr_read+0x280) > rsp=0xc00fabf8 > rfp=0xc00fac14 > r10=0x00000104 > r8=0xc00facd8 > r7=0xc0e89000 r6=0xc00faed4 r5=0x00000003 > r4=0xc00facd8 > badaddr_read() at > badaddr_read+0xfc > scp=0xc057a6b8 rlv=0xc057ac98 > (prefetch_abort_handler+0x404) > rsp=0xc00fac18 > rfp=0xc00fac30 > r6=0xc06c5c94 > r5=0xc00facd8 > > r4=0xc0e89000 > prefetch_abort_handler() at > prefetch_abort_handler+0x3bc > scp=0xc057ac50 rlv=0xc057adec > (data_abort_handler+0x118) > rsp=0xc00fac34 > rfp=0xc00facd4 > r5=0xffff1004 > r4=0xc06cc008 > data_abort_handler() at > data_abort_handler+0xc > scp=0xc057ace0 rlv=0xc056accc > (exception_exit) > rsp=0xc00facd8 > rfp=0xc00fad5c > r10=0x00000104 > r9=0x00000000 > r8=0xc06b4110 r7=0xc06cc6c0 r6=0xc06c5c94 > r5=0xffff1004 > > r4=0xffffffff > sched_switch() at > sched_switch+0xc > scp=0xc03c8990 rlv=0xc03aa6bc > (mi_switch+0x204) > rsp=0xc00fad60 > rfp=0xc00fad88 > r6=0x5ab0dd5d > r5=0x00000000 > > r4=0x5ab0dd5d > mi_switch() at > mi_switch+0xc > scp=0xc03aa4c4 rlv=0xc03e2d30 > (sleepq_type+0x1d4) > rsp=0xc00fad8c > rfp=0xc00fadac > r10=0xc0689c2c > r9=0xffffe980 > r8=0x00000000 r7=0xc05ec068 r6=0xc06c5c90 > r5=0xc0689c2c > > r4=0xc06b4110 > sleepq_type() at > sleepq_type+0x80 > scp=0xc03e2bdc rlv=0xc03e33a4 > (sleepq_timedwait+0x6c) > rsp=0xc00fadb0 > rfp=0xc00fadcc > r8=0xffffe9bb > r7=0x00000000 > r6=0xc06b4110 r5=0xc05ec068 > r4=0xc0689c2c > sleepq_timedwait() at > sleepq_timedwait+0xc > scp=0xc03e3344 rlv=0xc03aaf54 > (_sleep+0x340) > rsp=0xc00fadd0 > rfp=0xc00fae18 > r7=0x00000000 > r6=0xc06c4098 > r5=0x00000000 > r4=0x00000000 > _sleep() at > _sleep+0xc > scp=0xc03aac20 rlv=0xc03c8de0 > (__stack_chk_fail+0x1ac) > rsp=0xc00fae1c > rfp=0xc00faea0 > r10=0xffffe980 > r9=0x0000003b > r8=0x00000000 r7=0xc0689c2c r6=0x0000003c > r5=0xc06c4098 > > r4=0x00000000 > __stack_chk_fail() at > __stack_chk_fail+0x114 > scp=0xc03c8d48 rlv=0xc0359cf8 > (mi_startup+0xf8) > rsp=0xc00faea4 > rfp=0xc00faeb8 > r10=0x0000000a > r9=0x00200100 > r8=0x00000001 r7=0x002001b0 r6=0x00000000 > r5=0x002001bc > > r4=0xc061f25c > mi_startup() at > mi_startup+0xc > scp=0xc0359c0c rlv=0xc0200274 > (btext+0x174) > rsp=0xc00faebc > rfp=0x00000000 > r5=0x002001bc > r4=0x002002b4 > db> > > and what's the problem now? > > Beri > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Thu Oct 24 18:37:27 2013 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 ESMTP id 47E89549 for ; Thu, 24 Oct 2013 18:37:27 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 94DDC21DF for ; Thu, 24 Oct 2013 18:37:26 +0000 (UTC) Received: by mail-wg0-f45.google.com with SMTP id z12so2809900wgg.24 for ; Thu, 24 Oct 2013 11:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=QVek/+X1l2B1tqWmTzrTudxogdyoECXmvMdTHU8IX6Y=; b=zsBkyCuxqZmjWsa5vDlIOijzkgtJDW8g5w2O3YKBYkhERs4v2S8aGgKgXvhaKHd14S mcE/NO/Qs11Zx/Fn1ghxkbRqcYcFdNYZxm6XnwvU0b81N+DrO7NPt1IafCpR6edVwBRZ bxAWHMPc1l4pudru6n7TswHf+mkqddIwBe+MlZKo40i1Zzc7lam7WOSghCvZTAn/Kygh Ei0BGnqUBDcU+dMOTKEo/xM3V9TSjmzZgTi6SXgXPwRFDG0qMrn9Xv0XEwm7+NUs6er1 oMx9c1IHx4asvIZ0pKThK2DPz/CEqbt8ZtBWBTlrJPFlOnJ9QHJ9UCChjG0a3eNnLPe/ YCjg== MIME-Version: 1.0 X-Received: by 10.180.126.103 with SMTP id mx7mr3388802wib.39.1382639844916; Thu, 24 Oct 2013 11:37:24 -0700 (PDT) Received: by 10.217.141.3 with HTTP; Thu, 24 Oct 2013 11:37:24 -0700 (PDT) In-Reply-To: References: Date: Thu, 24 Oct 2013 20:37:24 +0200 Message-ID: Subject: Re: AVILA kernel From: Berislav Purgar To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2013 18:37:27 -0000 On Thu, Oct 24, 2013 at 8:53 AM, Berislav Purgar wrote: > > > > On Wed, Oct 16, 2013 at 7:46 PM, Berislav Purgar wrote: > >> Hello .. >> >> finally i got gatewroks GW2345 board but now i got stuck on loading >> kernel. it stops on copyright message: >> >> RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 >> IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 >> Default server: 10.42.1.1 >> RedBoot> load -b 0x200000 kernel >> Using default protocol (TFTP) >> Address offset = 0x40000000 >> Entry point: 0x00200100, address range: 0x00200000-0x007817c8 >> RedBoot> go >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2013 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.0-CURRENT #0 r256593M: Wed Oct 16 19:14:51 CEST 2013 >> root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA arm >> gcc version 4.2.1 20070831 patched [FreeBSD] >> >> on stock AVILA conf. file i got panic : >> >> RedBoot> ip >> IP: 192.168.3.2/255.255.255.0, Gateway: 0.0.0.0 >> Default server: 192.168.3.1 >> RedBoot> ip -h 10.42.1.1 -l 10.42.1.11 >> IP: 10.42.1.11/255.255.255.0, Gateway: 0.0.0.0 >> Default server: 10.42.1.1 >> RedBoot> load -b 0x200000 kernel >> Using default protocol (TFTP) >> Address offset = 0x40000000 >> Entry point: 0x00200100, address range: 0x00200000-0x006a9808 >> RedBoot> go >> panic: mtx_lock() of spin mutex pmap @ /usr/src/sys/arm/arm/pmap.c:3676 >> Uptime: 1s >> >> >> tnx >> > > Ok .. i manage to do something but still i got problem .. first of all i > have to disable ARM_EABI in src.conf > WITHOUT_ARM_EABI=yes > > after that i have to build kernel-toolchain > make TARGET=arm TARGET_ARCH=armeb kernel-toolchain > > and kernel > make TARGET=arm TARGET_ARCH=armeb KERNCONF=AVILA buildkernel > > result is here : > > > RedBoot> ip -h 10.42.1.1 -l > 10.42.1.11 > IP: 10.42.1.11/255.255.255.0, Gateway: > 0.0.0.0 > Default server: > 10.42.1.1 > RedBoot> load -b 0x200000 > kernel > Using default protocol > (TFTP) > Address offset = > 0x40000000 > Entry point: 0x00200100, address range: > 0x00200000-0x006ad228 > RedBoot> > go > KDB: debugger backends: > ddb > KDB: current backend: > ddb > Copyright (c) 1992-2013 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.0-CURRENT #1 r256953:257039M: Thu Oct 24 08:47:18 CEST > 2013 > root@brzi:/usr/obj/arm.armeb/usr/src/sys/AVILA > arm > gcc version 4.2.1 20070831 patched > [FreeBSD] > CPU: IXP425 533MHz rev 1 (ARMv5TE) (XScale > core) > Big-endian DC enabled IC enabled WB enabled LABT branch prediction > enabled > 32KB/32B 32-way instruction > cache > 32KB/32B 32-way write-back-locking data > cache > real memory = 67108864 (64 > MB) > avail memory = 57012224 (54 > MB) > random device not loaded; using insecure > entropy > random: > initialized > ixp0: IXP4XX> > ixp0: > 37fff > pcib0: on > ixp0 > pci0: on > pcib0 > ath0: irq 27 at device 2.0 on > pci0 > ath0: AR9220 mac 128.2 RF5133 phy > 13.0 > ath0: 2GHz radio: 0x0000; 5GHz radio: > 0x00c0 > ixpclk0: on > ixp0 > ixpiic0: on > ixp0 > iicbb0: on > ixpiic0 > iicbus0: on iicbb0 > master-only > iic0: on > iicbus0 > ad74180: at addr 0x50 on > iicbus0 > ds1672_rtc0: at addr 0xd0 on > iicbus0 > ixpwdog0: on > ixp0 > uart0: on > ixp0 > uart0: console > (115200,n,8,1) > uart1: on > ixp0 > ixpqmgr0: on > ixp0 > npe0: on > ixp0 > npe0: MAC at > 0xc8009000 > npe0: MII at > 0xc8009000 > npe0: load fw image IXP425.NPE-B Func 0x2 Rev > 2.1 > miibus0: on > npe0 > ukphy0: PHY 2 on > miibus0 > ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > auto > npe0: Ethernet address: > 00:d0:12:03:59:23 > npe1: on > ixp0 > npe1: MAC at > 0xc800a000 > npe1: MII at > 0xc8009000 > npe1: load fw image IXP425.NPE-C Func 0x5 Rev > 2.1 > miibus1: on > npe1 > ukphy1: PHY 5 on > miibus1 > ukphy1: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, > auto > npe1: Ethernet address: > 00:d0:12:13:59:23 > ata_avila0: on > ixp0 > ata0: on > ata_avila0 > led_avila0: on > ixp0 > gpio_avila0: on > ixp0 > gpioc0: on > gpio_avila0 > gpiobus0: on > gpio_avila0 > Timecounter "IXP4XX Timer" frequency 66666600 Hz quality > 1000 > Timecounters tick every 10.000 > msec > Fatal kernel mode data abort: 'Alignment Fault > 3' > trapframe: > 0xc00facd8 > FSR=00000003, FAR=c00faed4, > spsr=a00000d3 > r0 =c06b4110, r1 =c0e89000, r2 =c00faebc, r3 > =10000280 > r4 =c06b4110, r5 =c0e89000, r6 =c06c5c94, r7 > =c06cc6c0 > r8 =c06b4110, r9 =00000000, r10=00000104, > r11=c00fad5c > r12=c00fad0c, ssp=c00fad2c, slr=c03c8b34, pc > =c057a1d0 > > > [ thread pid 0 tid 100019 > ] > Stopped at cpu_switch+0x28: und > 0xe1c281f8 > db> > > db> > bt > Tracing pid 0 tid 100019 td > 0xc0e89000 > db_trace_self() at > db_trace_self+0xc > scp=0xc0569430 rlv=0xc0569480 > (db_trace_thread+0x3c) > rsp=0xc00fa9c8 > rfp=0xc00fa9d4 > db_trace_thread() at > db_trace_thread+0xc > scp=0xc0569450 rlv=0xc022b93c > (db_command_init+0x648) > rsp=0xc00fa9d8 > rfp=0xc00fa9f4 > db_command_init() at > db_command_init+0x570 > scp=0xc022b864 rlv=0xc022afe4 > (db_skip_to_eol+0x49c) > rsp=0xc00fa9f8 > rfp=0xc00faa9c > r5=0x00000000 > r4=0xc066d1f4 > db_skip_to_eol() at > db_skip_to_eol+0x1d0 > scp=0xc022ad18 rlv=0xc022b150 > (db_command_loop+0x60) > rsp=0xc00faaa0 > rfp=0xc00faaac > r10=0x600000d3 > r8=0x00000003 > r7=0x00000000 r6=0xc00faed4 r5=0xc066d4c4 > r4=0xc00faab8 > db_command_loop() at > db_command_loop+0xc > scp=0xc022b0fc rlv=0xc022d630 > (X_db_sym_numargs+0xf4) > rsp=0xc00faab0 > rfp=0xc00fabcc > X_db_sym_numargs() at > X_db_sym_numargs+0x14 > scp=0xc022d550 rlv=0xc03d5f9c > (kdb_trap+0xa8) > rsp=0xc00fabd0 > rfp=0xc00fabf4 > > r4=0xc00facd8 > kdb_trap() at > kdb_trap+0xc > scp=0xc03d5f00 rlv=0xc057a83c > (badaddr_read+0x280) > rsp=0xc00fabf8 > rfp=0xc00fac14 > r10=0x00000104 > r8=0xc00facd8 > r7=0xc0e89000 r6=0xc00faed4 r5=0x00000003 > r4=0xc00facd8 > badaddr_read() at > badaddr_read+0xfc > scp=0xc057a6b8 rlv=0xc057ac98 > (prefetch_abort_handler+0x404) > rsp=0xc00fac18 > rfp=0xc00fac30 > r6=0xc06c5c94 > r5=0xc00facd8 > > r4=0xc0e89000 > prefetch_abort_handler() at > prefetch_abort_handler+0x3bc > scp=0xc057ac50 rlv=0xc057adec > (data_abort_handler+0x118) > rsp=0xc00fac34 > rfp=0xc00facd4 > r5=0xffff1004 > r4=0xc06cc008 > data_abort_handler() at > data_abort_handler+0xc > scp=0xc057ace0 rlv=0xc056accc > (exception_exit) > rsp=0xc00facd8 > rfp=0xc00fad5c > r10=0x00000104 > r9=0x00000000 > r8=0xc06b4110 r7=0xc06cc6c0 r6=0xc06c5c94 > r5=0xffff1004 > > r4=0xffffffff > sched_switch() at > sched_switch+0xc > scp=0xc03c8990 rlv=0xc03aa6bc > (mi_switch+0x204) > rsp=0xc00fad60 > rfp=0xc00fad88 > r6=0x5ab0dd5d > r5=0x00000000 > > r4=0x5ab0dd5d > mi_switch() at > mi_switch+0xc > scp=0xc03aa4c4 rlv=0xc03e2d30 > (sleepq_type+0x1d4) > rsp=0xc00fad8c > rfp=0xc00fadac > r10=0xc0689c2c > r9=0xffffe980 > r8=0x00000000 r7=0xc05ec068 r6=0xc06c5c90 > r5=0xc0689c2c > > r4=0xc06b4110 > sleepq_type() at > sleepq_type+0x80 > scp=0xc03e2bdc rlv=0xc03e33a4 > (sleepq_timedwait+0x6c) > rsp=0xc00fadb0 > rfp=0xc00fadcc > r8=0xffffe9bb > r7=0x00000000 > r6=0xc06b4110 r5=0xc05ec068 > r4=0xc0689c2c > sleepq_timedwait() at > sleepq_timedwait+0xc > scp=0xc03e3344 rlv=0xc03aaf54 > (_sleep+0x340) > rsp=0xc00fadd0 > rfp=0xc00fae18 > r7=0x00000000 > r6=0xc06c4098 > r5=0x00000000 > r4=0x00000000 > _sleep() at > _sleep+0xc > scp=0xc03aac20 rlv=0xc03c8de0 > (__stack_chk_fail+0x1ac) > rsp=0xc00fae1c > rfp=0xc00faea0 > r10=0xffffe980 > r9=0x0000003b > r8=0x00000000 r7=0xc0689c2c r6=0x0000003c > r5=0xc06c4098 > > r4=0x00000000 > __stack_chk_fail() at > __stack_chk_fail+0x114 > scp=0xc03c8d48 rlv=0xc0359cf8 > (mi_startup+0xf8) > rsp=0xc00faea4 > rfp=0xc00faeb8 > r10=0x0000000a > r9=0x00200100 > r8=0x00000001 r7=0x002001b0 r6=0x00000000 > r5=0x002001bc > > r4=0xc061f25c > mi_startup() at > mi_startup+0xc > scp=0xc0359c0c rlv=0xc0200274 > (btext+0x174) > rsp=0xc00faebc > rfp=0x00000000 > r5=0x002001bc > r4=0x002002b4 > db> > > and what's the problem now? > > Beri > finally ... Olivier send me some patches and now i have working kernel .. Olivier told me that these patches are for another problems and maybe my problem with aligment is fixed by accident. Here is patch from Olivier : http://www.ci0.org/arm_patch.diff From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 17:34:16 2013 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 ESMTP id 88545627 for ; Fri, 25 Oct 2013 17:34:16 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 14DFA25A7 for ; Fri, 25 Oct 2013 17:34:15 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id h11so1439650wiv.4 for ; Fri, 25 Oct 2013 10:34:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Y6wYUgNKuEiOdFKeTG2LPJyRpaYO6wdtJXUiuCNwa7I=; b=UxiKK4Uyj2kKXQSAgK7HRVUnm9S8mwSojBxS6kHOWzkd/rYg0XCIZQAcNYvZvIkEan 3786o4OvNWVuBRhLepcc4E4uYs/9yZaukA1+Y7zOu/D7lwGw6yg6UHom7nsC8yerQi/i /mr4RS4hz6xrh8JbaO98r6jh94p517EygeQt0sqFmtVrApqkejLv01ZhCrK9oNHxoeRv bVrVKZjqIc68ylL8r2LHJJc34gIrevL6hl8GnNHy6Kmu35eS8p1klRaIF1VOORlvJN6f BD/J5hlA8XRqlpw97PBSYnG4nXPB/bMTpV2t6K/YJr6vqrdJF6qSBv50uZya1WM/lVRI BsKA== MIME-Version: 1.0 X-Received: by 10.194.239.40 with SMTP id vp8mr8439584wjc.45.1382722454523; Fri, 25 Oct 2013 10:34:14 -0700 (PDT) Received: by 10.217.141.3 with HTTP; Fri, 25 Oct 2013 10:34:14 -0700 (PDT) In-Reply-To: References: Date: Fri, 25 Oct 2013 19:34:14 +0200 Message-ID: Subject: Re: AVILA kernel From: Berislav Purgar To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:34:16 -0000 On Thu, Oct 24, 2013 at 8:37 PM, Berislav Purgar wrote: > > finally ... Olivier send me some patches and now i have working kernel .. > Olivier told me that these patches are for another problems and maybe my > problem with aligment is fixed by accident. > > Here is patch from Olivier : http://www.ci0.org/arm_patch.diff > > > > > > :( .. ahhh .. I give up ... problems never end .. i made buildworld (WITHOUT_ARM_EABI in src.conf) installworld distribution for NFSboot .. Everything is fine until initialization network interfaces .. i goot errors from ifconfig for all interfaces about missing address_family.. after that boot finish to login prompt. everything else works OK !!!?! root@avila:~ # ifconfig ath0: flags=8843 metric 0 mtu 2290 npe0: flags=8843 metric 0 mtu 1500 options=80008 npe1: flags=8802 metric 0 mtu 1500 options=80008 lo0: flags=8049 metric 0 mtu 16384 options=600003 wlan0: flags=8843 metric 0 mtu 1500 root@avila:~ # root@avila:~ # ifconfig npe1 192.168.5.1/24 ifconfig: Please specify an address_family. usage: ifconfig interface address_family [address [dest_address]] [parameters] ifconfig interface create ifconfig -a [-d] [-m] [-u] [-v] [address_family] ifconfig -l [-d] [-u] [address_family] ifconfig [-d] [-m] [-u] [-v] root@avila:~ # so .. no luck for me .. back to 9.1 :) :) Beri From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 17:43:08 2013 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 ESMTP id 799E3C17 for ; Fri, 25 Oct 2013 17:43:08 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4F26D2669 for ; Fri, 25 Oct 2013 17:43:07 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VZlPe-000KYn-Cl; Fri, 25 Oct 2013 17:43:06 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9PHh44G046907; Fri, 25 Oct 2013 11:43:04 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+9s15iEvn3TiYp6He9OkOv Subject: Re: AVILA kernel From: Ian Lepore To: Berislav Purgar In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Oct 2013 11:43:04 -0600 Message-ID: <1382722984.1170.108.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 17:43:08 -0000 On Fri, 2013-10-25 at 19:34 +0200, Berislav Purgar wrote: > On Thu, Oct 24, 2013 at 8:37 PM, Berislav Purgar wrote: > > > > > finally ... Olivier send me some patches and now i have working kernel .. > > Olivier told me that these patches are for another problems and maybe my > > problem with aligment is fixed by accident. > > > > Here is patch from Olivier : http://www.ci0.org/arm_patch.diff > > > > > > > > > > > > > :( .. ahhh .. I give up ... problems never end .. > > i made buildworld (WITHOUT_ARM_EABI in src.conf) installworld distribution > for NFSboot .. Everything is fine until initialization network interfaces > .. i goot errors from ifconfig for all interfaces about missing > address_family.. after that boot finish to login prompt. everything else > works OK !!!?! > > root@avila:~ # ifconfig > ath0: flags=8843 metric 0 mtu 2290 > npe0: flags=8843 metric 0 mtu 1500 > options=80008 > npe1: flags=8802 metric 0 mtu 1500 > options=80008 > lo0: flags=8049 metric 0 mtu 16384 > options=600003 > wlan0: flags=8843 metric 0 mtu 1500 > root@avila:~ # > root@avila:~ # ifconfig npe1 192.168.5.1/24 > ifconfig: Please specify an address_family. > usage: ifconfig interface address_family [address [dest_address]] > [parameters] > ifconfig interface create > ifconfig -a [-d] [-m] [-u] [-v] [address_family] > ifconfig -l [-d] [-u] [address_family] > ifconfig [-d] [-m] [-u] [-v] > root@avila:~ # > > so .. no luck for me .. back to 9.1 :) :) > > Beri try ifconfig nep1 inet 192.168.5.1/24 -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 18:11:47 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 3CD53429; Fri, 25 Oct 2013 18:11:47 +0000 (UTC) (envelope-from bpurgar@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95B9227DA; Fri, 25 Oct 2013 18:11:46 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t61so4161616wes.41 for ; Fri, 25 Oct 2013 11:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=X8xk7wVKJQzYSgI2DEKVtXB7ZqFEcLMPwpWKC9gTWVk=; b=rWWV5Rjrw80CKQqF8RPr8dfmCUw8NyPVx3zj9Ld39hvU+Z/Huhjse0HverX09X5Ar0 BaDkoLfUhNh4BD3mMMfSOwY/xjfBRXRi8uak3h71I8aJVuzFatd751SI9ZbVWf+23IBJ Lg0T1Tuu6fe8iMGru+b8CV/Bx+0pMwW59mvtxbLbOR3MG/GWlAwSSlVeUZRLulItBvVT WhI9CPA68GZ6VefC68JnKIFva96d3dJTITXq/jAfKQ8H9wFKbDLspfGqOY2ViwgARnwR WkMUtJRbhx/y5XTqjxILcUGOKW+NgHQrfKvUR+CsAJD9I72VcodmL7mMGO1LHpN8QCke qbAw== MIME-Version: 1.0 X-Received: by 10.180.39.34 with SMTP id m2mr3647314wik.26.1382724704942; Fri, 25 Oct 2013 11:11:44 -0700 (PDT) Received: by 10.217.141.3 with HTTP; Fri, 25 Oct 2013 11:11:44 -0700 (PDT) In-Reply-To: <1382722984.1170.108.camel@revolution.hippie.lan> References: <1382722984.1170.108.camel@revolution.hippie.lan> Date: Fri, 25 Oct 2013 20:11:44 +0200 Message-ID: Subject: Re: AVILA kernel From: Berislav Purgar To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 18:11:47 -0000 On Fri, Oct 25, 2013 at 7:43 PM, Ian Lepore wrote: > On Fri, 2013-10-25 at 19:34 +0200, Berislav Purgar wrote: > > On Thu, Oct 24, 2013 at 8:37 PM, Berislav Purgar > wrote: > > > > > > > > finally ... Olivier send me some patches and now i have working kernel > .. > > > Olivier told me that these patches are for another problems and maybe > my > > > problem with aligment is fixed by accident. > > > > > > Here is patch from Olivier : http://www.ci0.org/arm_patch.diff > > > > > > > > > > > > > > > > > > > > :( .. ahhh .. I give up ... problems never end .. > > > > i made buildworld (WITHOUT_ARM_EABI in src.conf) installworld > distribution > > for NFSboot .. Everything is fine until initialization network interfaces > > .. i goot errors from ifconfig for all interfaces about missing > > address_family.. after that boot finish to login prompt. everything else > > works OK !!!?! > > > > root@avila:~ # ifconfig > > ath0: flags=8843 metric 0 mtu > 2290 > > npe0: flags=8843 metric 0 mtu > 1500 > > options=80008 > > npe1: flags=8802 metric 0 mtu 1500 > > options=80008 > > lo0: flags=8049 metric 0 mtu 16384 > > options=600003 > > wlan0: flags=8843 metric 0 mtu > 1500 > > root@avila:~ # > > root@avila:~ # ifconfig npe1 192.168.5.1/24 > > ifconfig: Please specify an address_family. > > usage: ifconfig interface address_family [address [dest_address]] > > [parameters] > > ifconfig interface create > > ifconfig -a [-d] [-m] [-u] [-v] [address_family] > > ifconfig -l [-d] [-u] [address_family] > > ifconfig [-d] [-m] [-u] [-v] > > root@avila:~ # > > > > so .. no luck for me .. back to 9.1 :) :) > > > > Beri > > try ifconfig nep1 inet 192.168.5.1/24 > > -- Ian > > > i tried that .. same .. tried inet6 .. same .. root@avila:~ # ifconfig npe1 inet 192.168.5.1/24 ifconfig: Please specify an address_family. usage: ifconfig interface address_family [address [dest_address]] [parameters] ifconfig interface create ifconfig -a [-d] [-m] [-u] [-v] [address_family] ifconfig -l [-d] [-u] [address_family] ifconfig [-d] [-m] [-u] [-v] root@avila:~ # ifconfig npe1 inet6 2001:15c0:672a::aaa prefixlen 64 ifconfig: Please specify an address_family. usage: ifconfig interface address_family [address [dest_address]] [parameters] ifconfig interface create ifconfig -a [-d] [-m] [-u] [-v] [address_family] ifconfig -l [-d] [-u] [address_family] ifconfig [-d] [-m] [-u] [-v] root@avila:~ # but /rescue/ifconfig is OK .. WTF ???????? root@avila:~ # /rescue/ifconfig npe1 npe1: flags=8802 metric 0 mtu 1500 options=80008 ether 00:d0:12:13:59:23 nd6 options=29 media: Ethernet autoselect (none) status: no carrier root@avila:~ # root@avila:~ # ls -al /sbin/ifconfig -r-xr-xr-x 1 root wheel 132784 Oct 25 17:47 /sbin/ifconfig root@avila:~ # ls -al /rescue/ifconfig -r-xr-xr-x 135 root wheel 5611624 Oct 25 10:08 /rescue/ifconfig root@avila:~ # From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 20:37:13 2013 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 ESMTP id 870CE7A8 for ; Fri, 25 Oct 2013 20:37:13 +0000 (UTC) (envelope-from ssl.qlt@gmail.com) Received: from mail-ea0-x242.google.com (mail-ea0-x242.google.com [IPv6:2a00:1450:4013:c01::242]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 22F812F7D for ; Fri, 25 Oct 2013 20:37:12 +0000 (UTC) Received: by mail-ea0-f194.google.com with SMTP id q16so314068ead.5 for ; Fri, 25 Oct 2013 13:37:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=kK563GcOCZ6V+D5oMuL7yS8e2cMSWzGZMSu8c9zJ4qQ=; b=VLv56gmKKWm+gQYJrGE5OhCx84d2COuRN3fUhPZ0rS01NrLdHEjfDs1ugYZhvaKKCw p6mHHl4wwIcK6qUkX9USA4fLMooMZoHT/OcMJ1GXofiholA24x+9vR9/Ft16zmCb0L3r yHmOrET84sCoLT8Cgb0Qyxyw9ukEG0tGm4vwzY3M40hNx4dr0ZK990qJrhEWePwIl5lm Ib4ag7YnaaKC0iRS0SJmJuX0dRteH/K1g0sPPQcl5ZajnELX/y1anINfJX2D3fL1uFad Fu0CsP/n82JhYalpeOsWZzQi6Y3idGGRUQRQSdwAwunUoyB/GAt2RGx0hvZ08MDeJezS ygtA== MIME-Version: 1.0 X-Received: by 10.204.247.71 with SMTP id mb7mr3673003bkb.7.1382733431387; Fri, 25 Oct 2013 13:37:11 -0700 (PDT) Received: by 10.204.231.209 with HTTP; Fri, 25 Oct 2013 13:37:11 -0700 (PDT) Date: Fri, 25 Oct 2013 13:37:11 -0700 Message-ID: Subject: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? From: Steven Lee To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 20:37:13 -0000 Hello, In the process of upgrading my Dreamplug from the stable/9 branch to the stable/10 branch, I have run into a fairly significant file corruption problem. The steps that create this problem are as follows: 1. Cross-compile the kernel and buildworld from the stable/10 branch on a separate host. 2. Install the kernel and installworld on a usb stick drive 3. Boot the Dreamplug from the usb drive There are no problems that show up to this point, the Dreamplug boots with no errors. 4. Copy the kernel from the usb drive to the internal sd card 5. Copy the root filesystem from the usb drive to the internal sd card using (dump | restore) It is at step 5 that the error manifests itself, as I found that approximately 20 shell scripts in the /etc/rc.d directory had been randomly corrupted with strings of null characters (in groups of 32). I assume that the rest of the file system was compromised in a similar fashion. The bug is repeatable, however the corruption is somewhat random, so each time different files are corrupted in different places. When I followed the exact same steps from the stable/9 branch, the problem did not occur, so there is clearly some type of regression error between the 9 and 10 branches. After searching through the arm mailing list, I attempted to work around the problem by: - mounting the file systems with -o noclusterr -o noclusterrw - mounting the file systems with -o sync - as per comments on bug arm/158950, attempted to modify the pmap.c functions to change the cache from write-back mode to write-through mode but all of these attempts were ineffective. Given that I am relatively new to FreeBSD, I was hoping to get any insights as to any next steps that might make sense in terms of either working around the problem, narrowing down the bug, or any obvious rookie mistakes I am making before I give up and revert back to the 9 branch. Thanks for your help! Regards, Steve From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 21:03:14 2013 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 1C13C2B7 for ; Fri, 25 Oct 2013 21:03:14 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E518C2179 for ; Fri, 25 Oct 2013 21:03:13 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VZoXI-000JO7-Lg; Fri, 25 Oct 2013 21:03:12 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9PL3Am6047075; Fri, 25 Oct 2013 15:03:10 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18DtOz1bc0HSwc4EHJkRc9d Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? From: Ian Lepore To: Steven Lee In-Reply-To: References: Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Oct 2013 15:03:10 -0600 Message-ID: <1382734990.1170.132.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:03:14 -0000 On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote: > Hello, > > In the process of upgrading my Dreamplug from the stable/9 branch to the > stable/10 branch, I have run into a fairly > significant file corruption problem. The steps that create this problem > are as follows: > > 1. Cross-compile the kernel and buildworld from the stable/10 branch on a > separate host. > 2. Install the kernel and installworld on a usb stick drive > 3. Boot the Dreamplug from the usb drive > > There are no problems that show up to this point, the Dreamplug boots with > no errors. > > 4. Copy the kernel from the usb drive to the internal sd card > 5. Copy the root filesystem from the usb drive to the internal sd card > using (dump | restore) > > It is at step 5 that the error manifests itself, as I found that > approximately 20 shell scripts in the /etc/rc.d directory > had been randomly corrupted with strings of null characters (in groups of > 32). I assume that the rest of the file system > was compromised in a similar fashion. The bug is repeatable, however the > corruption is somewhat random, so > each time different files are corrupted in different places. > > When I followed the exact same steps from the stable/9 branch, the problem > did not occur, so there is clearly some > type of regression error between the 9 and 10 branches. > > After searching through the arm mailing list, I attempted to work around > the problem by: > - mounting the file systems with -o noclusterr -o noclusterrw > - mounting the file systems with -o sync > - as per comments on bug arm/158950, attempted to modify the pmap.c > functions to change the cache from > write-back mode to write-through mode > > but all of these attempts were ineffective. > > Given that I am relatively new to FreeBSD, I was hoping to get any insights > as to any next steps that might make > sense in terms of either working around the problem, narrowing down the > bug, or any obvious rookie mistakes I > am making before I give up and revert back to the 9 branch. > > Thanks for your help! > > Regards, On my dreamplug (model 1001) both the internal and external sd cards are actually usb devices (they show up as /dev/da0 and da1, not mmcsd0/1). I'm not sure if that's true on all models or not. Are you using the stock kernel config (DREAMPLUG-1001)? If not, have you got "option USB_HOST_ALIGN=32" in your kernel config? Corruption in 32 byte chunks is almost always partial cacheline flush problems, but I haven't seen that happen on dreamplug for a long time (and when I did see it, it was with a sata drive). -- Ian From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 21:38:27 2013 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 ESMTP id 9DA8AA59 for ; Fri, 25 Oct 2013 21:38:27 +0000 (UTC) (envelope-from ssl.qlt@gmail.com) Received: from mail-ea0-x241.google.com (mail-ea0-x241.google.com [IPv6:2a00:1450:4013:c01::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 26A732389 for ; Fri, 25 Oct 2013 21:38:27 +0000 (UTC) Received: by mail-ea0-f193.google.com with SMTP id o10so324455eaj.0 for ; Fri, 25 Oct 2013 14:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SQkVYztS5QO7Mw+vUjMxK4SsmQAIZg2JqQ+gHo7G9SA=; b=ATWK42RiSExJm93anzORieCunn17SYXMnUHtd0JywNV1pzdYDgQlci8ijsnPZM9Coz UoTp5yQ29hTPAhvqU+D79YycK1i9m3vNcZhFev3hZMc+uV0XgUUP7YCAW+BRlsmfUgQM tehiMf9YXPKaPp86QJ5Ysv+ffj4WnhyXD12fruUHJs4dN0fVy8HFiAYm4N/fYAaP/M+u RfeXe7x56L3UYrH3s8cmgTAD5b+Ru3D10hKlbvGB4xrB1OFW7rwP1EW7igePBLr7xI4q kMm8QdmIJ1ppHH0JvFhwKGjjPEoAhWhYJYvL1Ct4sPHBFiU2x8h/FeQSpcqojhbGdb6y H3nA== MIME-Version: 1.0 X-Received: by 10.204.168.197 with SMTP id v5mr1852bky.24.1382737104644; Fri, 25 Oct 2013 14:38:24 -0700 (PDT) Received: by 10.204.231.209 with HTTP; Fri, 25 Oct 2013 14:38:24 -0700 (PDT) In-Reply-To: References: <1382734990.1170.132.camel@revolution.hippie.lan> Date: Fri, 25 Oct 2013 14:38:24 -0700 Message-ID: Subject: Fwd: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? From: Steven Lee To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 21:38:27 -0000 ---------- Forwarded message ---------- From: Steven Lee Date: Fri, Oct 25, 2013 at 2:37 PM Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? To: Ian Lepore Ian, thanks for your reply. I am using the DREAMPLUG-1001 stock kernel config, and you are right the internal sd card shows up as a usb device, /dev/da0. As I mentioned, I tried modifying pmap.c as per one of your suggestions to an earlier poster / problem, but it didn't seem to help the issue. I changed the pmap_pte_init_arm10() function to look like the pmap_pte_init_arm9() function. Any other thoughts about things to try? Since it seems like this is a regression between 9 and 10, are you aware of any specific cache related changes to the usb driver between the branches? - Steve On Fri, Oct 25, 2013 at 2:03 PM, Ian Lepore wrote: > On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote: > > Hello, > > > > In the process of upgrading my Dreamplug from the stable/9 branch to the > > stable/10 branch, I have run into a fairly > > significant file corruption problem. The steps that create this problem > > are as follows: > > > > 1. Cross-compile the kernel and buildworld from the stable/10 branch on a > > separate host. > > 2. Install the kernel and installworld on a usb stick drive > > 3. Boot the Dreamplug from the usb drive > > > > There are no problems that show up to this point, the Dreamplug boots > with > > no errors. > > > > 4. Copy the kernel from the usb drive to the internal sd card > > 5. Copy the root filesystem from the usb drive to the internal sd card > > using (dump | restore) > > > > It is at step 5 that the error manifests itself, as I found that > > approximately 20 shell scripts in the /etc/rc.d directory > > had been randomly corrupted with strings of null characters (in groups of > > 32). I assume that the rest of the file system > > was compromised in a similar fashion. The bug is repeatable, however the > > corruption is somewhat random, so > > each time different files are corrupted in different places. > > > > When I followed the exact same steps from the stable/9 branch, the > problem > > did not occur, so there is clearly some > > type of regression error between the 9 and 10 branches. > > > > After searching through the arm mailing list, I attempted to work around > > the problem by: > > - mounting the file systems with -o noclusterr -o noclusterrw > > - mounting the file systems with -o sync > > - as per comments on bug arm/158950, attempted to modify the pmap.c > > functions to change the cache from > > write-back mode to write-through mode > > > > but all of these attempts were ineffective. > > > > Given that I am relatively new to FreeBSD, I was hoping to get any > insights > > as to any next steps that might make > > sense in terms of either working around the problem, narrowing down the > > bug, or any obvious rookie mistakes I > > am making before I give up and revert back to the 9 branch. > > > > Thanks for your help! > > > > Regards, > > On my dreamplug (model 1001) both the internal and external sd cards are > actually usb devices (they show up as /dev/da0 and da1, not mmcsd0/1). > I'm not sure if that's true on all models or not. > > Are you using the stock kernel config (DREAMPLUG-1001)? If not, have > you got "option USB_HOST_ALIGN=32" in your kernel config? > > Corruption in 32 byte chunks is almost always partial cacheline flush > problems, but I haven't seen that happen on dreamplug for a long time > (and when I did see it, it was with a sata drive). > > -- Ian > > From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 22:01:06 2013 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 ESMTP id 8AB17E80 for ; Fri, 25 Oct 2013 22:01:06 +0000 (UTC) (envelope-from ian@FreeBSD.org) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4C91D24FB for ; Fri, 25 Oct 2013 22:01:06 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1VZpRJ-000AXb-9m; Fri, 25 Oct 2013 22:01:05 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id r9PM13WE047127; Fri, 25 Oct 2013 16:01:03 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/5D4aY0JIqcZtfPv3omr/I Subject: Re: Fwd: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? From: Ian Lepore To: Steven Lee In-Reply-To: References: <1382734990.1170.132.camel@revolution.hippie.lan> Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Oct 2013 16:01:02 -0600 Message-ID: <1382738462.1170.153.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 22:01:06 -0000 That old advice was based on bugs in old code that has been fixed. I've just been double-checking that the various fixes are in 10 (some of them were things I submitted a PR for before I became a committer). I'm not sure about the usb driver, but there have been big changes in the dma cache coherency code between 9 and 10, although much of that is the fixes I was alluding to. Basically what you're doing is a usb->usb copy, I'll see if I can recreate the corruption on my dreamplug here the same way. -- Ian On Fri, 2013-10-25 at 14:38 -0700, Steven Lee wrote: > ---------- Forwarded message ---------- > From: Steven Lee > Date: Fri, Oct 25, 2013 at 2:37 PM > Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption error - > cache related? > To: Ian Lepore > > > Ian, thanks for your reply. > > I am using the DREAMPLUG-1001 stock kernel config, and you are right the > internal sd card shows up as a usb device, /dev/da0. > > As I mentioned, I tried modifying pmap.c as per one of your suggestions to > an earlier poster / problem, but it didn't seem to help the issue. I > changed the pmap_pte_init_arm10() function to look like the > pmap_pte_init_arm9() function. > > Any other thoughts about things to try? Since it seems like this is a > regression between 9 and 10, are you aware of any specific cache related > changes to the usb driver between the branches? > > - Steve > > > On Fri, Oct 25, 2013 at 2:03 PM, Ian Lepore wrote: > > > On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote: > > > Hello, > > > > > > In the process of upgrading my Dreamplug from the stable/9 branch to the > > > stable/10 branch, I have run into a fairly > > > significant file corruption problem. The steps that create this problem > > > are as follows: > > > > > > 1. Cross-compile the kernel and buildworld from the stable/10 branch on a > > > separate host. > > > 2. Install the kernel and installworld on a usb stick drive > > > 3. Boot the Dreamplug from the usb drive > > > > > > There are no problems that show up to this point, the Dreamplug boots > > with > > > no errors. > > > > > > 4. Copy the kernel from the usb drive to the internal sd card > > > 5. Copy the root filesystem from the usb drive to the internal sd card > > > using (dump | restore) > > > > > > It is at step 5 that the error manifests itself, as I found that > > > approximately 20 shell scripts in the /etc/rc.d directory > > > had been randomly corrupted with strings of null characters (in groups of > > > 32). I assume that the rest of the file system > > > was compromised in a similar fashion. The bug is repeatable, however the > > > corruption is somewhat random, so > > > each time different files are corrupted in different places. > > > > > > When I followed the exact same steps from the stable/9 branch, the > > problem > > > did not occur, so there is clearly some > > > type of regression error between the 9 and 10 branches. > > > > > > After searching through the arm mailing list, I attempted to work around > > > the problem by: > > > - mounting the file systems with -o noclusterr -o noclusterrw > > > - mounting the file systems with -o sync > > > - as per comments on bug arm/158950, attempted to modify the pmap.c > > > functions to change the cache from > > > write-back mode to write-through mode > > > > > > but all of these attempts were ineffective. > > > > > > Given that I am relatively new to FreeBSD, I was hoping to get any > > insights > > > as to any next steps that might make > > > sense in terms of either working around the problem, narrowing down the > > > bug, or any obvious rookie mistakes I > > > am making before I give up and revert back to the 9 branch. > > > > > > Thanks for your help! > > > > > > Regards, > > > > On my dreamplug (model 1001) both the internal and external sd cards are > > actually usb devices (they show up as /dev/da0 and da1, not mmcsd0/1). > > I'm not sure if that's true on all models or not. > > > > Are you using the stock kernel config (DREAMPLUG-1001)? If not, have > > you got "option USB_HOST_ALIGN=32" in your kernel config? > > > > Corruption in 32 byte chunks is almost always partial cacheline flush > > problems, but I haven't seen that happen on dreamplug for a long time > > (and when I did see it, it was with a sata drive). > > > > -- Ian > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 23:22:28 2013 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 ESMTP id 4726375B; Fri, 25 Oct 2013 23:22:28 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B464298C; Fri, 25 Oct 2013 23:22:27 +0000 (UTC) Received: by mail-wg0-f48.google.com with SMTP id b13so4399812wgh.3 for ; Fri, 25 Oct 2013 16:22:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TSuvg5ZmqX25Qr9Iu5keNFEZl0TQBC9fPY4Vr9wXIYw=; b=oFvHnh5tU2VPsmfZWbGIpe0J1JJN2VPQKbo7WouDBU8e0aw7K+nBByVFuYeqPdlh0H he4E9K+SEXg4RwK9QdN2RwR+S2fRZPi9io4r1eX/9wDvOg1P/Q6kEQdoCi0Fv08iNuEt tbWnwyqKG0lKzBilTRiZnkNZvQa9WGNTA1xzy7sWtT07QLiEekBS/4wGc30NPz6g59m3 A0mF4OFNuXj8tZ//ZcNGVJKCGV7+Qj9oYrKR9Et9lukLIeecGlP7Owigg1d7f4YdVqz4 agcSHHzQtONFj5ANmZYBl0H9MqNoxCAN7vtZhgCrsdDUbMk80ngsfhuWJe6YD/KmGu2b Awsw== MIME-Version: 1.0 X-Received: by 10.194.206.5 with SMTP id lk5mr9396238wjc.46.1382743345609; Fri, 25 Oct 2013 16:22:25 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.209.194 with HTTP; Fri, 25 Oct 2013 16:22:24 -0700 (PDT) In-Reply-To: <52536AD4.4070603@FreeBSD.org> References: <52536AD4.4070603@FreeBSD.org> Date: Sat, 26 Oct 2013 01:22:24 +0200 X-Google-Sender-Auth: OcolvhHiP-yoJUaWY9G_Yc0dx2o Message-ID: Subject: Re: Changes to Armada XP From: Zbigniew Bodek To: "freebsd-arm@freebsd.org" Content-Type: multipart/mixed; boundary=047d7b874c42eeab0904e99905f6 Cc: Kevin Lo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:22:28 -0000 --047d7b874c42eeab0904e99905f6 Content-Type: text/plain; charset=ISO-8859-1 Hello again. Apart from the earlier mentioned patches I would like to add some more: 0004 - some clean-ups to generic ARM code related to AXP 0005 - some AXP based boards have different SoC registers' base address so we need to correct configuration variables and eventually DT to map this properly and boot without problems on any type of u-boot. 0006 - just modifying the kernel load address. If I commit this I will change the entry on AXP wiki page accordingly. 0007 - removal of the obsolete PJ4Bv6 code 0008 - disabling explicit TLB broadcasting using IPI. PJ4Bv7 is capable of doing this in HW More detailed descriptions are of course in commit-logs. Please test those patches if you like and send your remarks if there are any. I would like to commit this (and previous patches) by the end of Saturday 26th because I'm stashing this for quite some time now. So if there will be no objections I will do as described :) Thank you and best regards Zbigniew Bodek 2013/10/8 Kevin Lo : > Zbigniew Bodek wrote: >> >> Hello. >> >> I would like to commit two patches for Armada XP. >> >> 0002 - is enabling busy-detection for UART on Armada XP. Combined with >> another patch for ns8250 UART (posted in the separate e-mail) this fixes >> UART IF issues on Armada XP. >> >> 0003 - enables SATA interface on Armada XP. >> >> If there are no objections then I would like to commit them in the near >> future. > > > Works for me. Tested on the Openblocks AX3. Thanks! > >> >> Best regards >> Zbigniew Bodek > > > Kevin --047d7b874c42eeab0904e99905f6 Content-Type: application/octet-stream; name="0004-Remove-hard-coded-mappings-related-to-Armada-XP-supp.patch" Content-Disposition: attachment; filename="0004-Remove-hard-coded-mappings-related-to-Armada-XP-supp.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hn817ii70 RnJvbSAwMzBkNzIzMTBjNGIwMGQyYjk5N2FhZjIzYTE0OTZhNDllZTBkNTQ1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogU2F0LCAxMiBPY3QgMjAxMyAwMDowNjowNSArMDIwMApTdWJqZWN0OiBbUEFUQ0ggNC84XSBS ZW1vdmUgaGFyZC1jb2RlZCBtYXBwaW5ncyByZWxhdGVkIHRvIEFybWFkYSBYUCBzdXBwb3J0CgpB cm1hZGEgWFAgaW5pdGlhbGl6YXRpb24gZmxvdyByZXF1aXJlcyBTb0MgcmVnaXN0ZXJzIHRvIGJl Cm1hcHBlZCB2ZXJ5IGVhcmx5IGluIG9yZGVyIHRvIGNvbmZpZ3VyZSBTbm9vcCBGaWx0ZXIgZm9y IFNNUC4KQWRkaXRpb25hbCBtYXBwaW5nIGluIGxvY29yZS5TIGlzIHJlZHVuZGFudCBhcyBwcm9w ZXIgbWFwcGluZyBpcwptYWRlIGluIHBtYXBfZGV2bWFwX2Jvb3RzdHJhcCgpIHByaW9yIHRvIGNh bGxpbmcgY3B1X3NldHVwKCkgd2hpY2gKY29uZmlndXJlcyB0aGUgU25vb3AgRmlsdGVyLgpGb3Ig c2Vjb25kYXJ1IENQVXMgaXQgaXMgYmV0dGVyIHRvIHBhc3MgVkEgb2YgdGhlIFNvQwpyZWdpc3Rl cnMgZGVmaW5lZCBpbiBNVl9CQVNFIGFuZCBQQSBjb25zaXN0ZW50IHdpdGggdGhlIHZhbHVlCmlu IHRoZSBEZXZpY2UgVHJlZS4KCkFwcHJvdmVkIGJ5Ogljb2duZXQgKG1lbnRvcikKLS0tCiBzeXMv YXJtL2FybS9sb2NvcmUuUyAgICAgfCA0IC0tLS0KIHN5cy9hcm0vYXJtL21wX21hY2hkZXAuYyB8 IDggKysrKysrLS0KIDIgZmlsZXMgY2hhbmdlZCwgNiBpbnNlcnRpb25zKCspLCA2IGRlbGV0aW9u cygtKQoKZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2xvY29yZS5TIGIvc3lzL2FybS9hcm0vbG9j b3JlLlMKaW5kZXggZWNkN2Y1My4uNjc4ZjNiZiAxMDA2NDQKLS0tIGEvc3lzL2FybS9hcm0vbG9j b3JlLlMKKysrIGIvc3lzL2FybS9hcm0vbG9jb3JlLlMKQEAgLTI2NiwxMCArMjY2LDYgQEAgbW11 X2luaXRfdGFibGU6CiAJLyogbWFwIFZBIDB4YzAwMDAwMDAuLjB4YzNmZmZmZmYgdG8gUEEgKi8K IAlNTVVfSU5JVChLRVJOQkFTRSwgUEhZU0FERFIsIDY0LCBMMV9UWVBFX1N8TDFfU0hBUkVEfEwx X1NfQ3xMMV9TX0FQKEFQX0tSVykpCiAJTU1VX0lOSVQoMHg0ODAwMDAwMCwgMHg0ODAwMDAwMCwg MSwgTDFfVFlQRV9TfEwxX1NIQVJFRHxMMV9TX0N8TDFfU19BUChBUF9LUlcpKQotI2lmIGRlZmlu ZWQoQ1BVX01WX1BKNEIpCi0JLyogbWFwIFZBIDB4ZjEwMDAwMDAuLjB4ZjExMDAwMDAgdG8gUEEg MHhkMDAwMDAwMCAqLwotCU1NVV9JTklUKDB4ZjEwMDAwMDAsIDB4ZDAwMDAwMDAsIDEsIEwxX1RZ UEVfU3xMMV9TSEFSRUR8TDFfU19CfEwxX1NfQVAoQVBfS1JXKSkKLSNlbmRpZiAvKiBDUFVfTVZf UEo0QiAqLwogI2VuZGlmIC8qIFNNUCAqLwogCS53b3JkIDAJLyogZW5kIG9mIHRhYmxlICovCiAj ZW5kaWYKZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL21wX21hY2hkZXAuYyBiL3N5cy9hcm0vYXJt L21wX21hY2hkZXAuYwppbmRleCAyZTVlMWQzLi5jNjJlMzExIDEwMDY0NAotLS0gYS9zeXMvYXJt L2FybS9tcF9tYWNoZGVwLmMKKysrIGIvc3lzL2FybS9hcm0vbXBfbWFjaGRlcC5jCkBAIC01Miw2 ICs1MiwxMCBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAjaWZkZWYgVkZQCiAjaW5jbHVkZSA8 bWFjaGluZS92ZnAuaD4KICNlbmRpZgorI2lmZGVmIENQVV9NVl9QSjRCCisjaW5jbHVkZSA8YXJt L212L212d2luLmg+CisjaW5jbHVkZSA8ZGV2L2ZkdC9mZHRfY29tbW9uLmg+CisjZW5kaWYKIAog I2luY2x1ZGUgIm9wdF9zbXAuaCIKIApAQCAtMTMxLDggKzEzNSw4IEBAIGNwdV9tcF9zdGFydCh2 b2lkKQogCiAjaWYgZGVmaW5lZChDUFVfTVZfUEo0QikKIAkvKiBBZGQgQVJNQURBWFAgcmVnaXN0 ZXJzIHJlcXVpcmVkIGZvciBzbm9vcCBmaWx0ZXIgaW5pdGlhbGl6YXRpb24gKi8KLQkoKGludCAq KSh0ZW1wX3BhZ2V0YWJsZV92YSkpWzB4ZjEwMDAwMDAgPj4gTDFfU19TSElGVF0gPQotCSAgICBM MV9UWVBFX1N8TDFfU0hBUkVEfEwxX1NfQnxMMV9TX0FQKEFQX0tSVyl8MHhkMDAwMDAwMDsKKwko KGludCAqKSh0ZW1wX3BhZ2V0YWJsZV92YSkpW01WX0JBU0UgPj4gTDFfU19TSElGVF0gPQorCSAg ICBMMV9UWVBFX1N8TDFfU0hBUkVEfEwxX1NfQnxMMV9TX0FQKEFQX0tSVyl8ZmR0X2ltbXJfcGE7 CiAjZW5kaWYKIAogCXRlbXBfcGFnZXRhYmxlID0gKHZvaWQqKSh2dG9waHlzKHRlbXBfcGFnZXRh YmxlX3ZhKSk7Ci0tIAoxLjguNAoK --047d7b874c42eeab0904e99905f6 Content-Type: application/octet-stream; name="0005-Fix-up-DTB-for-Armada-XP-registers-base-according-to.patch" Content-Disposition: attachment; filename="0005-Fix-up-DTB-for-Armada-XP-registers-base-according-to.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hn817iid1 RnJvbSAzMmI1M2M4ZDcwYTMyNmI3MzkxNWE4N2JlYmM0ZDI1NGM0M2JiZjcxIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogVHVlLCAyMiBPY3QgMjAxMyAwMDo0OTowMCArMDIwMApTdWJqZWN0OiBbUEFUQ0ggNS84XSBG aXgtdXAgRFRCIGZvciBBcm1hZGEgWFAgcmVnaXN0ZXJzJyBiYXNlIGFjY29yZGluZyB0byB0aGUK IGFjdHVhbCBzZXR0aW5ncwoKRGVwZW5kaW5nIG9uIHUtYm9vdCdzIGZsYXZvciBzb21lIGJvYXJk cyBoYXZlIHRoZWlyIFNvQyByZWdpc3RlcnMKYmFzZSBhZGRyZXNzIGNvbmZpZ3VyZWQgdG8gMHhE MDAwMDAwMCBhbmQgb3RoZXIgdG8gMHhGMTAwMDAwMC4KVS1ib290IGlzIHBhc3NpbmcgY3VycmVu dGx5IHNldCB2YWx1ZSB2aWEgQ1AxNSByZWdpc3Rlci4KSW4gb3JkZXIgdG8gY3JlYXRlIHByb3Bl ciBtYXBwaW5nIGZvciBTb0MgcmVnaXN0ZXJzIGFuZCBhbGxvdyBmdXJ0aGVyCnN1Y2Nlc3NmdWwg aW5pdGlhbGl6YXRpb24gaXQgaXMgbmVjZXNzYXJ5IHRvIHJlcGxhY2UgZmR0X2ltbXJfcGEgd2l0 aAp0aGUgcmVhbCB2YWx1ZSBhbmQgZXZlbnR1YWxseSBmaXgtdXAgZGV2aWNlIHRyZWUgYmxvYi4K CkFwcHJvdmVkIGJ5Ogljb2duZXQgKG1lbnRvcikKLS0tCiBzeXMvYXJtL212L2NvbW1vbi5jICAg ICB8IDcwICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysK IHN5cy9hcm0vbXYvbXZfbWFjaGRlcC5jIHwgMTMgKysrKysrKysrCiAyIGZpbGVzIGNoYW5nZWQs IDgzIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9zeXMvYXJtL212L2NvbW1vbi5jIGIvc3lz L2FybS9tdi9jb21tb24uYwppbmRleCAyZmFmYzY1Li40NGMyMmNiIDEwMDY0NAotLS0gYS9zeXMv YXJtL212L2NvbW1vbi5jCisrKyBiL3N5cy9hcm0vbXYvY29tbW9uLmMKQEAgLTIwOTEsOSArMjA5 MSw3OSBAQCBmZHRfZml4dXBfYnVzZnJlcShwaGFuZGxlX3Qgcm9vdCkKIAkJT0Zfc2V0cHJvcChz YiwgImJ1cy1mcmVxdWVuY3kiLCAodm9pZCAqKSZmcmVxLCBzaXplb2YoZnJlcSkpOwogfQogCitz dGF0aWMgdm9pZAorZmR0X2ZpeHVwX3JhbmdlcyhwaGFuZGxlX3Qgcm9vdCkKK3sKKwlwaGFuZGxl X3Qgbm9kZTsKKwlwY2VsbF90IHBhcl9hZGRyX2NlbGxzLCBhZGRyX2NlbGxzLCBzaXplX2NlbGxz OworCXBjZWxsX3QgcmFuZ2VzWzNdLCByZWdbMl0sICpyYW5nZXNwdHI7CisJaW50IGxlbiwgdHVw bGVfc2l6ZSwgdHVwbGVzX2NvdW50OworCXVpbnQzMl90IGJhc2U7CisKKwkvKiBGaXgtdXAgU29D IHJhbmdlcyBhY2NvcmRpbmcgdG8gcmVhbCBmZHRfaW1tcl9wYSAqLworCWlmICgobm9kZSA9IGZk dF9maW5kX2NvbXBhdGlibGUocm9vdCwgInNpbXBsZS1idXMiLCAxKSkgIT0gMCkgeworCQlpZiAo ZmR0X2FkZHJzaXplX2NlbGxzKG5vZGUsICZhZGRyX2NlbGxzLCAmc2l6ZV9jZWxscykgPT0gMCAm JgorCQkgICAgKHBhcl9hZGRyX2NlbGxzID0gZmR0X3BhcmVudF9hZGRyX2NlbGxzKG5vZGUpIDw9 IDIpKSB7CisJCQl0dXBsZV9zaXplID0gc2l6ZW9mKHBjZWxsX3QpICogKHBhcl9hZGRyX2NlbGxz ICsKKwkJCSAgIGFkZHJfY2VsbHMgKyBzaXplX2NlbGxzKTsKKwkJCWxlbiA9IE9GX2dldHByb3Ao bm9kZSwgInJhbmdlcyIsIHJhbmdlcywKKwkJCSAgICBzaXplb2YocmFuZ2VzKSk7CisJCQl0dXBs ZXNfY291bnQgPSBsZW4gLyB0dXBsZV9zaXplOworCQkJLyogVW5leHBlY3RlZCBzZXR0aW5ncyBh cmUgbm90IHN1cHBvcnRlZCAqLworCQkJaWYgKHR1cGxlc19jb3VudCAhPSAxKQorCQkJCWdvdG8g Zml4dXBfZmFpbGVkOworCisJCQlyYW5nZXNwdHIgPSAmcmFuZ2VzWzBdOworCQkJcmFuZ2VzcHRy ICs9IHBhcl9hZGRyX2NlbGxzOworCQkJYmFzZSA9IGZkdF9kYXRhX2dldCgodm9pZCAqKXJhbmdl c3B0ciwgYWRkcl9jZWxscyk7CisJCQkqcmFuZ2VzcHRyID0gY3B1X3RvX2ZkdDMyKGZkdF9pbW1y X3BhKTsKKwkJCWlmIChPRl9zZXRwcm9wKG5vZGUsICJyYW5nZXMiLCAodm9pZCAqKSZyYW5nZXNb MF0sCisJCQkgICAgc2l6ZW9mKHJhbmdlcykpIDwgMCkKKwkJCQlnb3RvIGZpeHVwX2ZhaWxlZDsK KwkJfQorCX0KKworCS8qIEZpeC11cCBQQ0llIHJlZyBhY2NvcmRpbmcgdG8gcmVhbCBQQ0llIHJl Z2lzdGVycycgUEEgKi8KKwlpZiAoKG5vZGUgPSBmZHRfZmluZF9jb21wYXRpYmxlKHJvb3QsICJt cnZsLHBjaWUiLCAxKSkgIT0gMCkgeworCQlpZiAoZmR0X2FkZHJzaXplX2NlbGxzKE9GX3BhcmVu dChub2RlKSwgJnBhcl9hZGRyX2NlbGxzLAorCQkgICAgJnNpemVfY2VsbHMpID09IDApIHsKKwkJ CXR1cGxlX3NpemUgPSBzaXplb2YocGNlbGxfdCkgKiAocGFyX2FkZHJfY2VsbHMgKworCQkJICAg IHNpemVfY2VsbHMpOworCQkJbGVuID0gT0ZfZ2V0cHJvcChub2RlLCAicmVnIiwgcmVnLCBzaXpl b2YocmVnKSk7CisJCQl0dXBsZXNfY291bnQgPSBsZW4gLyB0dXBsZV9zaXplOworCQkJLyogVW5l eHBlY3RlZCBzZXR0aW5ncyBhcmUgbm90IHN1cHBvcnRlZCAqLworCQkJaWYgKHR1cGxlc19jb3Vu dCAhPSAxKQorCQkJCWdvdG8gZml4dXBfZmFpbGVkOworCisJCQliYXNlID0gZmR0X2RhdGFfZ2V0 KCh2b2lkICopJnJlZ1swXSwgcGFyX2FkZHJfY2VsbHMpOworCQkJYmFzZSAmPSB+MHhGRjAwMDAw MDsKKwkJCWJhc2UgfD0gZmR0X2ltbXJfcGE7CisJCQlyZWdbMF0gPSBjcHVfdG9fZmR0MzIoYmFz ZSk7CisJCQlpZiAoT0Zfc2V0cHJvcChub2RlLCAicmVnIiwgKHZvaWQgKikmcmVnWzBdLAorCQkJ ICAgIHNpemVvZihyZWcpKSA8IDApCisJCQkJZ290byBmaXh1cF9mYWlsZWQ7CisJCX0KKwl9CisJ LyogRml4LXVwIHN1Y2NlZWRlZC4gTWF5IHJldHVybiBhbmQgY29udGludWUgKi8KKwlyZXR1cm47 CisKK2ZpeHVwX2ZhaWxlZDoKKwl3aGlsZSAoMSkgeworCQkvKgorCQkgKiBJbiBjYXNlIG9mIGFu eSBlcnJvciB3aGlsZSBmaXhpbmcgcmFuZ2VzIGp1c3QgaGFuZy4KKwkJICoJMS4gTm8gbWVzc2Fn ZSBjYW4gYmUgZGlzcGxheWVkIHlldCBzaW5jZSBjb25zb2xlCisJCSAqCSAgIGlzIG5vdCBpbml0 aWFsaXplZC4KKwkJICoJMi4gR29pbmcgZnVydGhlciB3aWxsIGNhdXNlIGZhaWx1cmUgb24gYnVz X3NwYWNlX21hcCgpCisJCSAqCSAgIHJlbHlpbmcgb24gdGhlIHdyb25nIHJhbmdlcyBvciBkYXRh IGFib3J0IHdoZW4KKwkJICoJICAgYWNjZXNzaW5nIFBDSWUgcmVnaXN0ZXJzLgorCQkgKi8KKwl9 Cit9CisKIHN0cnVjdCBmZHRfZml4dXBfZW50cnkgZmR0X2ZpeHVwX3RhYmxlW10gPSB7CiAJeyAi bXJ2bCxEQi04OEY2MjgxIiwgJmZkdF9maXh1cF9idXNmcmVxIH0sCiAJeyAibXJ2bCxEQi03ODQ2 MCIsICZmZHRfZml4dXBfYnVzZnJlcSB9LAorCXsgIm1ydmwsREItNzg0NjAiLCAmZmR0X2ZpeHVw X3JhbmdlcyB9LAogCXsgTlVMTCwgTlVMTCB9CiB9OwogCmRpZmYgLS1naXQgYS9zeXMvYXJtL212 L212X21hY2hkZXAuYyBiL3N5cy9hcm0vbXYvbXZfbWFjaGRlcC5jCmluZGV4IDU4ZDE4M2UuLmJk ZjMwMjcgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vbXYvbXZfbWFjaGRlcC5jCisrKyBiL3N5cy9hcm0v bXYvbXZfbWFjaGRlcC5jCkBAIC0zMjYsNiArMzI2LDE5IEBAIHBsYXRmb3JtX2Rldm1hcF9pbml0 KHZvaWQpCiAJaSA9IDA7CiAJcG1hcF9kZXZtYXBfYm9vdHN0cmFwX3RhYmxlID0gJmZkdF9kZXZt YXBbMF07CiAKKyNpZmRlZiBTT0NfTVZfQVJNQURBWFAKKwl2bV9wYWRkcl90IGN1cl9pbW1yX3Bh OworCisJLyoKKwkgKiBBY3F1aXJlIFNvQyByZWdpc3RlcnMnIGJhc2UgcGFzc2VkIGJ5IHUtYm9v dCBhbmQgZmlsbCBkZXZtYXAKKwkgKiBhY2NvcmRpbmdseS4gRFRCIGlzIGdvaW5nIHRvIGJlIG1v ZGlmaWVkIGJhc2luZyBvbiB0aGlzIGRhdGEKKwkgKiBsYXRlci4KKwkgKi8KKwlfX2FzbSBfX3Zv bGF0aWxlKCJtcmMgcDE1LCA0LCAlMCwgYzE1LCBjMCwgMCIgOiAiPXIiIChjdXJfaW1tcl9wYSkp OworCWN1cl9pbW1yX3BhID0gKGN1cl9pbW1yX3BhIDw8IDEzKSAmIDB4ZmYwMDAwMDA7CisJaWYg KGN1cl9pbW1yX3BhICE9IDApCisJCWZkdF9pbW1yX3BhID0gY3VyX2ltbXJfcGE7CisjZW5kaWYK IAkvKgogCSAqIElNTVIgcmFuZ2UuCiAJICovCi0tIAoxLjguNAoK --047d7b874c42eeab0904e99905f6 Content-Type: application/octet-stream; name="0006-Change-Armada-XP-kernel-load-address-to-the-u-boot-s.patch" Content-Disposition: attachment; filename="0006-Change-Armada-XP-kernel-load-address-to-the-u-boot-s.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hn817iih2 RnJvbSAxMGM3MmUwN2ZiNGIyODEwZDhjMTM1MDliOTBlZjkzNDI1YTM3OThlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogVHVlLCAyMiBPY3QgMjAxMyAwMTowNjo1MiArMDIwMApTdWJqZWN0OiBbUEFUQ0ggNi84XSBD aGFuZ2UgQXJtYWRhIFhQIGtlcm5lbCBsb2FkIGFkZHJlc3MgdG8gdGhlIHUtYm9vdCdzIGVuZAog YWRkcmVzcwoKTG9hZGluZyBrZXJuZWwgdG8gMHhmMDAwMDAgaGFzIG5vIHByYWN0aWNhbCByZWFz b24uClN0YXJ0aW5nIGl0IGZyb20gdGhlIHUtYm9vdCdzIGhpZ2hlc3QgcG9zc2libGUgZW5kIGFk ZHJlc3MKKDJNQiBjb3VudGluZyBmcm9tIDB4MCkgbWFrZXMgbW9yZSBzZW5zZS4KCkFwcHJvdmVk IGJ5Ogljb2duZXQgKG1lbnRvcikKLS0tCiBzeXMvYXJtL212L2FybWFkYXhwL3N0ZC5hcm1hZGF4 cCB8IDEyICsrKysrKy0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDYgaW5zZXJ0aW9ucygrKSwgNiBk ZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9zeXMvYXJtL212L2FybWFkYXhwL3N0ZC5hcm1hZGF4 cCBiL3N5cy9hcm0vbXYvYXJtYWRheHAvc3RkLmFybWFkYXhwCmluZGV4IGJmMmE1ZjYuLmQ3MzFh ZDMgMTAwNjQ0Ci0tLSBhL3N5cy9hcm0vbXYvYXJtYWRheHAvc3RkLmFybWFkYXhwCisrKyBiL3N5 cy9hcm0vbXYvYXJtYWRheHAvc3RkLmFybWFkYXhwCkBAIC0xLDE2ICsxLDE2IEBACiAjICRGcmVl QlNEJAogCi0jIGtlcm5lbCBnZXRzIGxvYWRlZCBhdCAweDAwZjAwMDAwIGJ5IHRoZSBsb2FkZXIs IGJ1dCBydW5zIGF0IHZpcnR1YWwgYWRkcmVzcwotIyAweGMwZjAwMDAwLiAgUkFNIHN0YXJ0cyBh dCAwLiAgV2UgcHV0IHRoZSBwYWdldGFibGUgYXQgYSByZWFzb25hYmxlIHBsYWNlCisjIGtlcm5l bCBnZXRzIGxvYWRlZCBhdCAweDAwMjAwMDAwIGJ5IHRoZSBsb2FkZXIsIGJ1dCBydW5zIGF0IHZp cnR1YWwgYWRkcmVzcworIyAweGMwMjAwMDAwLiAgUkFNIHN0YXJ0cyBhdCAwLiAgV2UgcHV0IHRo ZSBwYWdldGFibGUgYXQgYSByZWFzb25hYmxlIHBsYWNlCiAjIGluIG1lbW9yeSwgYnV0IG1heSBu ZWVkIHRvIGJvdW5jZSBpdCBoaWdoZXIgaWYgdGhlcmUncyBhIHByb2JsZW0gd2l0aCB0aGlzLgog IyBXZSBjb3VsZCBwYXBlciBvdmVyIHRoaXMgYnkgbG9hZGluZyB0aGUga2VybmVsIGF0IDB4YzAw MDAwMDAgdmlydHVhbCwgYnV0CiAjIHRoYXQgbGVhZHMgdG8gb3RoZXIgY29tcGxpY2F0aW9ucywg c28gd2UnbGwganVzdCByZWNsYWltIHRoZSBsb3dlciByZWdpb24gb2YKICMgcmFtIGFmdGVyIHdl J3JlIGxvYWRlZC4gIFB1dCB0aGUgcGFnZSB0YWJsZXMgZm9yIHN0YXJ0dXAgYXQgMU1CLgotbWFr ZW9wdGlvbnMJS0VSTlBIWVNBRERSPTB4MDBmMDAwMDAKLW1ha2VvcHRpb25zCUtFUk5WSVJUQURE Uj0weGMwZjAwMDAwCittYWtlb3B0aW9ucwlLRVJOUEhZU0FERFI9MHgwMDIwMDAwMAorbWFrZW9w dGlvbnMJS0VSTlZJUlRBRERSPTB4YzAyMDAwMDAKIAotb3B0aW9ucwkJS0VSTlBIWVNBRERSPTB4 MDBmMDAwMDAKLW9wdGlvbnMJCUtFUk5WSVJUQUREUj0weGMwZjAwMDAwCitvcHRpb25zCQlLRVJO UEhZU0FERFI9MHgwMDIwMDAwMAorb3B0aW9ucwkJS0VSTlZJUlRBRERSPTB4YzAyMDAwMDAKIG9w dGlvbnMJCVBIWVNBRERSPTB4MDAwMDAwMDAKIG9wdGlvbnMJCVNUQVJUVVBfUEFHRVRBQkxFX0FE RFI9MHgwMDEwMDAwMAogCi0tIAoxLjguNAoK --047d7b874c42eeab0904e99905f6 Content-Type: application/octet-stream; name="0007-Remove-not-working-and-deprecated-PJ4Bv6-support.patch" Content-Disposition: attachment; filename="0007-Remove-not-working-and-deprecated-PJ4Bv6-support.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hn817iil3 RnJvbSA5YzhhMWRkNzc4MDViM2I0YmNlNzgzOTEwNTAxOWU5Yjg4MzIwZWE4IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogVHVlLCAyMiBPY3QgMjAxMyAwMTo1Mjo0OSArMDIwMApTdWJqZWN0OiBbUEFUQ0ggNy84XSBS ZW1vdmUgbm90IHdvcmtpbmcgYW5kIGRlcHJlY2F0ZWQgUEo0QnY2IHN1cHBvcnQKClNoZWV2YSBQ SjRCdjYgLSBiYXNlZCBjaGlwcyB3ZXJlIG9ubHkgcHJvdG90eXBlcyBmb3IgVjcgY2xhc3MgQXJt YWRhClNvQyBmYW1pbHkuIEN1cnJlbnQgaW4tdHJlZSBzdXBwb3J0IGZvciBQSjRCdjYgd2lsbCBu b3Qgd29yayBhbmQgYWxzbwp0aGVyZSBzaG91bGQgYmUgbm8gcGxhdGZvcm1zIGluIGFjdGl2ZSB1 c2UgdGhhdCB3b3VsZCBpbmNvcnBvcmF0ZSB0aGF0CkNQVSByZXZpc2lvbi4KCkFwcHJvdmVkIGJ5 Ogljb2duZXQgKG1lbnRvcikKLS0tCiBzeXMvYXJtL2FybS9jcHVmdW5jLmMgICAgICAgICAgfCAx MTQgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KIHN5cy9hcm0vYXJtL2NwdWZ1 bmNfYXNtX3BqNGIuUyB8IDEzMiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQogc3lzL2FybS9hcm0vaWRlbnRjcHUuYyAgICAgICAgIHwgICA4IC0tLQogc3lzL2FybS9p bmNsdWRlL2FybXJlZy5oICAgICAgIHwgICA0IC0tCiBzeXMvYXJtL2luY2x1ZGUvY3B1ZnVuYy5o ICAgICAgfCAgIDkgLS0tCiA1IGZpbGVzIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgMjY1IGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2NwdWZ1bmMuYyBiL3N5cy9hcm0v YXJtL2NwdWZ1bmMuYwppbmRleCA4Mjg2MTg4Li5jMmU4NWU4IDEwMDY0NAotLS0gYS9zeXMvYXJt L2FybS9jcHVmdW5jLmMKKysrIGIvc3lzL2FybS9hcm0vY3B1ZnVuYy5jCkBAIC01NDEsNjUgKzU0 MSw2IEBAIHN0cnVjdCBjcHVfZnVuY3Rpb25zIHBqNGJ2N19jcHVmdW5jcyA9IHsKIAogCXBqNGJ2 N19zZXR1cAkJCS8qIGNwdSBzZXR1cAkJKi8KIH07Ci0KLXN0cnVjdCBjcHVfZnVuY3Rpb25zIHBq NGJ2Nl9jcHVmdW5jcyA9IHsKLQkvKiBDUFUgZnVuY3Rpb25zICovCi0KLQljcHVmdW5jX2lkLAkJ CS8qIGlkCQkJKi8KLQlhcm0xMV9kcmFpbl93cml0ZWJ1ZiwJCS8qIGNwd2FpdAkJKi8KLQotCS8q IE1NVSBmdW5jdGlvbnMgKi8KLQotCWNwdWZ1bmNfY29udHJvbCwJCS8qIGNvbnRyb2wJCSovCi0J Y3B1ZnVuY19kb21haW5zLAkJLyogRG9tYWluCQkqLwotCXBqNGJfc2V0dHRiLAkJCS8qIFNldHR0 YgkJKi8KLQljcHVmdW5jX2ZhdWx0c3RhdHVzLAkJLyogRmF1bHRzdGF0dXMJCSovCi0JY3B1ZnVu Y19mYXVsdGFkZHJlc3MsCQkvKiBGYXVsdGFkZHJlc3MJCSovCi0KLQkvKiBUTEIgZnVuY3Rpb25z ICovCi0KLQlhcm0xMV90bGJfZmx1c2hJRCwJCS8qIHRsYl9mbHVzaElECQkqLwotCWFybTExX3Rs Yl9mbHVzaElEX1NFLAkJLyogdGxiX2ZsdXNoSURfU0UJKi8KLQlhcm0xMV90bGJfZmx1c2hJLAkJ LyogdGxiX2ZsdXNoSQkJKi8KLQlhcm0xMV90bGJfZmx1c2hJX1NFLAkJLyogdGxiX2ZsdXNoSV9T RQkqLwotCWFybTExX3RsYl9mbHVzaEQsCQkvKiB0bGJfZmx1c2hECQkqLwotCWFybTExX3RsYl9m bHVzaERfU0UsCQkvKiB0bGJfZmx1c2hEX1NFCSovCi0KLQkvKiBDYWNoZSBvcGVyYXRpb25zICov Ci0JYXJtdjZfaWNhY2hlX3N5bmNfYWxsLAkJLyogaWNhY2hlX3N5bmNfYWxsCSovCi0JcGo0Yl9p Y2FjaGVfc3luY19yYW5nZSwJCS8qIGljYWNoZV9zeW5jX3JhbmdlCSovCi0KLQlhcm12Nl9kY2Fj aGVfd2JpbnZfYWxsLAkJLyogZGNhY2hlX3diaW52X2FsbAkqLwotCXBqNGJfZGNhY2hlX3diaW52 X3JhbmdlLAkvKiBkY2FjaGVfd2JpbnZfcmFuZ2UJKi8KLQlwajRiX2RjYWNoZV9pbnZfcmFuZ2Us CQkvKiBkY2FjaGVfaW52X3JhbmdlCSovCi0JcGo0Yl9kY2FjaGVfd2JfcmFuZ2UsCQkvKiBkY2Fj aGVfd2JfcmFuZ2UJKi8KLQotCWFybXY2X2lkY2FjaGVfd2JpbnZfYWxsLAkvKiBpZGNhY2hlX3di aW52X2FsbAkqLwotCXBqNGJfaWRjYWNoZV93Ymludl9yYW5nZSwJLyogaWRjYWNoZV93Ymludl9h bGwJKi8KLQotCSh2b2lkICopY3B1ZnVuY19udWxsb3AsCQkvKiBsMmNhY2hlX3diaW52X2FsbAkq LwotCSh2b2lkICopY3B1ZnVuY19udWxsb3AsCQkvKiBsMmNhY2hlX3diaW52X3JhbmdlCSovCi0J KHZvaWQgKiljcHVmdW5jX251bGxvcCwJCS8qIGwyY2FjaGVfaW52X3JhbmdlCSovCi0JKHZvaWQg KiljcHVmdW5jX251bGxvcCwJCS8qIGwyY2FjaGVfd2JfcmFuZ2UJKi8KLQotCS8qIE90aGVyIGZ1 bmN0aW9ucyAqLwotCi0JcGo0Yl9kcmFpbl9yZWFkYnVmLAkJLyogZmx1c2hfcHJlZmV0Y2hidWYJ Ki8KLQlhcm0xMV9kcmFpbl93cml0ZWJ1ZiwJCS8qIGRyYWluX3dyaXRlYnVmCSovCi0JcGo0Yl9m bHVzaF9icm5jaHRndF9hbGwsCS8qIGZsdXNoX2JybmNodGd0X0MJKi8KLQlwajRiX2ZsdXNoX2Jy bmNodGd0X3ZhLAkJLyogZmx1c2hfYnJuY2h0Z3RfRQkqLwotCi0JKHZvaWQgKiljcHVmdW5jX251 bGxvcCwJCS8qIHNsZWVwCQkqLwotCi0JLyogU29mdCBmdW5jdGlvbnMgKi8KLQotCWNwdWZ1bmNf bnVsbF9maXh1cCwJCS8qIGRhdGFhYnRfZml4dXAJKi8KLQljcHVmdW5jX251bGxfZml4dXAsCQkv KiBwcmVmZXRjaGFidF9maXh1cAkqLwotCi0JYXJtMTFfY29udGV4dF9zd2l0Y2gsCQkvKiBjb250 ZXh0X3N3aXRjaAkqLwotCi0JcGo0YnY2X3NldHVwCQkJLyogY3B1IHNldHVwCQkqLwotfTsKICNl bmRpZiAvKiBDUFVfTVZfUEo0QiAqLwogCiAjaWZkZWYgQ1BVX1NBMTEwCkBAIC0xNDk3LDI3ICsx NDM4LDE0IEBAIHNldF9jcHVmdW5jcygpCiAjZW5kaWYgLyogQ1BVX0NPUlRFWEEgKi8KIAkJCiAj aWYgZGVmaW5lZChDUFVfTVZfUEo0QikKLQlpZiAoY3B1dHlwZSA9PSBDUFVfSURfTVY4OFNWNTgx WF9WNiB8fAotCSAgICBjcHV0eXBlID09IENQVV9JRF9NVjg4U1Y1ODFYX1Y3IHx8CisJaWYgKGNw dXR5cGUgPT0gQ1BVX0lEX01WODhTVjU4MVhfVjcgfHwKIAkgICAgY3B1dHlwZSA9PSBDUFVfSURf TVY4OFNWNTg0WF9WNyB8fAotCSAgICBjcHV0eXBlID09IENQVV9JRF9BUk1fODhTVjU4MVhfVjYg fHwKIAkgICAgY3B1dHlwZSA9PSBDUFVfSURfQVJNXzg4U1Y1ODFYX1Y3KSB7Ci0JCWlmIChjcHVf cGZyKDApICYgQVJNX1BGUjBfVEhVTUJFRV9NQVNLKQotCQkJY3B1ZnVuY3MgPSBwajRidjdfY3B1 ZnVuY3M7Ci0JCWVsc2UKLQkJCWNwdWZ1bmNzID0gcGo0YnY2X2NwdWZ1bmNzOwotCi0JCWdldF9j YWNoZXR5cGVfY3AxNSgpOwotCQlwbWFwX3B0ZV9pbml0X21tdV92NigpOwotCQlnb3RvIG91dDsK LQl9IGVsc2UgaWYgKGNwdXR5cGUgPT0gQ1BVX0lEX0FSTV84OFNWNTg0WF9WNiB8fAotCSAgICBj cHV0eXBlID09IENQVV9JRF9NVjg4U1Y1ODRYX1Y2KSB7Ci0JCWNwdWZ1bmNzID0gcGo0YnY2X2Nw dWZ1bmNzOworCQljcHVmdW5jcyA9IHBqNGJ2N19jcHVmdW5jczsKIAkJZ2V0X2NhY2hldHlwZV9j cDE1KCk7CiAJCXBtYXBfcHRlX2luaXRfbW11X3Y2KCk7CiAJCWdvdG8gb3V0OwogCX0KLQogI2Vu ZGlmIC8qIENQVV9NVl9QSjRCICovCiAjaWZkZWYgQ1BVX1NBMTEwCiAJaWYgKGNwdXR5cGUgPT0g Q1BVX0lEX1NBMTEwKSB7CkBAIC0yNDQ3LDQ0ICsyMzc1LDYgQEAgYXJtMTF4Nl9zZXR1cChjaGFy ICphcmdzKQogCiAjaWZkZWYgQ1BVX01WX1BKNEIKIHZvaWQKLXBqNGJ2Nl9zZXR1cChjaGFyICph cmdzKQotewotCWludCBjcHVjdHJsOwotCi0JcGo0Yl9jb25maWcoKTsKLQotCWNwdWN0cmwgPSBD UFVfQ09OVFJPTF9NTVVfRU5BQkxFOwotI2lmbmRlZiBBUk0zMl9ESVNBQkxFX0FMSUdOTUVOVF9G QVVMVFMKLQljcHVjdHJsIHw9IENQVV9DT05UUk9MX0FGTFRfRU5BQkxFOwotI2VuZGlmCi0JY3B1 Y3RybCB8PSBDUFVfQ09OVFJPTF9EQ19FTkFCTEU7Ci0JY3B1Y3RybCB8PSAoMHhmIDw8IDMpOwot I2lmZGVmIF9fQVJNRUJfXwotCWNwdWN0cmwgfD0gQ1BVX0NPTlRST0xfQkVORF9FTkFCTEU7Ci0j ZW5kaWYKLQljcHVjdHJsIHw9IENQVV9DT05UUk9MX1NZU1RfRU5BQkxFOwotCWNwdWN0cmwgfD0g Q1BVX0NPTlRST0xfQlBSRF9FTkFCTEU7Ci0JY3B1Y3RybCB8PSBDUFVfQ09OVFJPTF9JQ19FTkFC TEU7Ci0JaWYgKHZlY3Rvcl9wYWdlID09IEFSTV9WRUNUT1JTX0hJR0gpCi0JCWNwdWN0cmwgfD0g Q1BVX0NPTlRST0xfVkVDUkVMT0M7Ci0JY3B1Y3RybCB8PSAoMHg1IDw8IDE2KTsKLQljcHVjdHJs IHw9IENQVV9DT05UUk9MX1Y2X0VYVFBBR0U7Ci0JLyogWFhYIG5vdCB5ZXQgKi8KLQkvKiBjcHVj dHJsIHw9IENQVV9DT05UUk9MX0wyX0VOQUJMRTsgKi8KLQotCS8qIE1ha2Ugc3VyZSBjYWNoZXMg YXJlIGNsZWFuLiAgKi8KLQljcHVfaWRjYWNoZV93Ymludl9hbGwoKTsKLQljcHVfbDJjYWNoZV93 Ymludl9hbGwoKTsKLQotCS8qIFNldCB0aGUgY29udHJvbCByZWdpc3RlciAqLwotCWN0cmwgPSBj cHVjdHJsOwotCWNwdV9jb250cm9sKDB4ZmZmZmZmZmYsIGNwdWN0cmwpOwotCi0JY3B1X2lkY2Fj aGVfd2JpbnZfYWxsKCk7Ci0JY3B1X2wyY2FjaGVfd2JpbnZfYWxsKCk7Ci19Ci0KLXZvaWQKIHBq NGJ2N19zZXR1cChhcmdzKQogCWNoYXIgKmFyZ3M7CiB7CmRpZmYgLS1naXQgYS9zeXMvYXJtL2Fy bS9jcHVmdW5jX2FzbV9wajRiLlMgYi9zeXMvYXJtL2FybS9jcHVmdW5jX2FzbV9wajRiLlMKaW5k ZXggZTYxODJmYi4uZDhkNDAwYyAxMDA2NDQKLS0tIGEvc3lzL2FybS9hcm0vY3B1ZnVuY19hc21f cGo0Yi5TCisrKyBiL3N5cy9hcm0vYXJtL2NwdWZ1bmNfYXNtX3BqNGIuUwpAQCAtMzQsOSArMzQs NiBAQCBfX0ZCU0RJRCgiJEZyZWVCU0QkIik7CiAKICNpbmNsdWRlIDxtYWNoaW5lL3BhcmFtLmg+ CiAKLS5McGo0Yl9jYWNoZV9saW5lX3NpemU6Ci0JLndvcmQJX0NfTEFCRUwoYXJtX3BkY2FjaGVf bGluZV9zaXplKQotCiAuTHBqNGJfc2ZfY3RybF9yZWc6CiAJLndvcmQJMHhmMTAyMTgyMAogCkBA IC01MiwxMzUgKzQ5LDYgQEAgRU5UUlkocGo0Yl9zZXR0dGIpCiAJUkVUCiBFTkQocGo0Yl9zZXR0 dGIpCiAKLUVOVFJZX05QKGFybXY2X2ljYWNoZV9zeW5jX2FsbCkKLQkvKgotCSAqIFdlIGFzc3Vt ZSB0aGF0IHRoZSBjb2RlIGhlcmUgY2FuIG5ldmVyIGJlIG91dCBvZiBzeW5jIHdpdGggdGhlCi0J ICogZGNhY2hlLCBzbyB0aGF0IHdlIGNhbiBzYWZlbHkgZmx1c2ggdGhlIEljYWNoZSBhbmQgZmFs bCB0aHJvdWdoCi0JICogaW50byB0aGUgRGNhY2hlIGNsZWFuaW5nIGNvZGUuCi0JICovCi0JbW92 CXIwLCAjMAotCW1jcglwMTUsIDAsIHIwLCBjNywgYzUsIDAJLyogSW52YWxpZGF0ZSBJQ2FjaGUg Ki8KLQltY3IJcDE1LCAwLCByMCwgYzcsIGMxMCwgMAkvKiBDbGVhbiAoZG9uJ3QgaW52YWxpZGF0 ZSkgRENhY2hlICovCi0JbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTAsIDQJLyogZHJhaW4gdGhlIHdy aXRlIGJ1ZmZlciAqLwotCVJFVAotRU5EKGFybXY2X2ljYWNoZV9zeW5jX2FsbCkKLQotRU5UUlko cGo0Yl9pY2FjaGVfc3luY19yYW5nZSkKLQlzdWIJcjEsIHIxLCAjMQotCWFkZAlyMSwgcjAsIHIx Ci0JbWNycglwMTUsIDAsIHIxLCByMCwgYzUJLyogaW52YWxpZGF0ZSBJQyByYW5nZSAqLwotCW1j cnIJcDE1LCAwLCByMSwgcjAsIGMxMgkvKiBjbGVhbiBEQyByYW5nZSAqLwotCW1jcglwMTUsIDAs IHIwLCBjNywgYzEwLCA0CS8qIGRyYWluIHRoZSB3cml0ZSBidWZmZXIgKi8KLQlSRVQKLUVORChw ajRiX2ljYWNoZV9zeW5jX3JhbmdlKQotCi1FTlRSWShwajRiX2RjYWNoZV9pbnZfcmFuZ2UpCi0J bGRyCWlwLCAuTHBqNGJfY2FjaGVfbGluZV9zaXplCi0JbGRyCWlwLCBbaXBdCi0Jc3ViCXIxLCBy MSwgIzEJCS8qIERvbid0IG92ZXJydW4gKi8KLQlzdWIJcjMsIGlwLCAjMQotCWFuZAlyMiwgcjAs IHIzCi0JYWRkCXIxLCByMSwgcjIKLQliaWMJcjAsIHIwLCByMwotCi0JbWNyCXAxNSwgMCwgcjAs IGM3LCBjMTAsIDUgIC8qIERhdGEgTWVtb3J5IEJhcnJpZXIgZXJyOjQ0MTMgKi8KLTE6Ci0JbWNy CXAxNSwgMCwgcjAsIGM3LCBjNiwgMQotCWFkZAlyMCwgcjAsIGlwCi0Jc3VicwlyMSwgcjEsIGlw Ci0JYnBsCTFiCi0JbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTAsIDQJLyogZHJhaW4gdGhlIHdyaXRl IGJ1ZmZlciAqLwotCVJFVAotRU5EKHBqNGJfZGNhY2hlX2ludl9yYW5nZSkKLQotRU5UUlkoYXJt djZfaWRjYWNoZV93Ymludl9hbGwpCi0JbW92CXIwLCAjMAotCW1jcglwMTUsIDAsIHIwLCBjNywg YzUsIDAJLyogaW52YWxpZGF0ZSBJQ2FjaGUgKi8KLQltY3IJcDE1LCAwLCByMCwgYzcsIGMxNCwg MAkvKiBjbGVhbiBhbmQgaW52YWxpZGF0ZSBEQ2FjaGUgKi8KLQltY3IJcDE1LCAwLCByMCwgYzcs IGMxMCwgNAkvKiBkcmFpbiB0aGUgd3JpdGUgYnVmZmVyICovCi0JUkVUCi1FTkQoYXJtdjZfaWRj YWNoZV93Ymludl9hbGwpCi0KLUVOVFJZKGFybXY2X2RjYWNoZV93Ymludl9hbGwpCi0JbW92CXIw LCAjMAotCW1jcglwMTUsIDAsIHIwLCBjNywgYzE0LCAwCS8qIGNsZWFuIGFuZCBpbnZhbGlkYXRl IERDYWNoZSAqLwotCW1jcglwMTUsIDAsIHIwLCBjNywgYzEwLCA0CS8qIGRyYWluIHRoZSB3cml0 ZSBidWZmZXIgKi8KLQlSRVQKLUVORChhcm12Nl9kY2FjaGVfd2JpbnZfYWxsKQotCi1FTlRSWShw ajRiX2lkY2FjaGVfd2JpbnZfcmFuZ2UpCi0JbGRyCWlwLCAuTHBqNGJfY2FjaGVfbGluZV9zaXpl Ci0JbGRyCWlwLCBbaXBdCi0Jc3ViCXIxLCByMSwgIzEJCS8qIERvbid0IG92ZXJydW4gKi8KLQlz dWIJcjMsIGlwLCAjMQotCWFuZAlyMiwgcjAsIHIzCi0JYWRkCXIxLCByMSwgcjIKLQliaWMJcjAs IHIwLCByMwotCi0JbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTAsIDUgIC8qIERhdGEgTWVtb3J5IEJh cnJpZXIgZXJyOjQ2MTEgKi8KLTE6Ci0jaWZkZWYgU01QCi0JLyogUmVxdWVzdCBmb3Igb3duZXJz aGlwICovCi0JbGRyCXIyLCBbcjBdCi0Jc3RyCXIyLCBbcjBdCi0jZW5kaWYKLQltY3IJcDE1LCAw LCByMCwgYzcsIGM1LCAxCi0JbWNyCXAxNSwgMCwgcjAsIGM3LCBjMTQsIDEJLyogTDJDIGNsZWFu IGFuZCBpbnZhbGlkYXRlIGVudHJ5ICovCi0JYWRkCXIwLCByMCwgaXAKLQlzdWJzCXIxLCByMSwg aXAKLQlicGwJMWIKLQltY3IJcDE1LCAwLCByMCwgYzcsIGMxMCwgNAkvKiBkcmFpbiB0aGUgd3Jp dGUgYnVmZmVyICovCi0JUkVUCi1FTkQocGo0Yl9pZGNhY2hlX3diaW52X3JhbmdlKQotCi1FTlRS WShwajRiX2RjYWNoZV93Ymludl9yYW5nZSkKLQlsZHIJaXAsIC5McGo0Yl9jYWNoZV9saW5lX3Np emUKLQlsZHIJaXAsIFtpcF0KLQlzdWIJcjEsIHIxLCAjMQkJLyogRG9uJ3Qgb3ZlcnJ1biAqLwot CXN1YglyMywgaXAsICMxCi0JYW5kCXIyLCByMCwgcjMKLQlhZGQJcjEsIHIxLCByMgotCWJpYwly MCwgcjAsIHIzCi0KLQltY3IJcDE1LCAwLCByMCwgYzcsIGMxMCwgNSAgLyogRGF0YSBNZW1vcnkg QmFycmllciBlcnI6NDYxMSAqLwotMToKLSNpZmRlZiBTTVAKLQkvKiBSZXF1ZXN0IGZvciBvd25l cnNoaXAgKi8KLQlsZHIJcjIsIFtyMF0KLQlzdHIJcjIsIFtyMF0KLSNlbmRpZgotCW1jcglwMTUs IDAsIHIwLCBjNywgYzE0LCAxCi0JYWRkCXIwLCByMCwgaXAKLQlzdWJzCXIxLCByMSwgaXAKLQli cGwJMWIKLQltY3IJcDE1LCAwLCByMCwgYzcsIGMxMCwgNAkvKiBkcmFpbiB0aGUgd3JpdGUgYnVm ZmVyICovCi0JUkVUCi1FTkQocGo0Yl9kY2FjaGVfd2JpbnZfcmFuZ2UpCi0KLUVOVFJZKHBqNGJf ZGNhY2hlX3diX3JhbmdlKQotCWxkcglpcCwgLkxwajRiX2NhY2hlX2xpbmVfc2l6ZQotCWxkcglp cCwgW2lwXQotCXN1YglyMSwgcjEsICMxCQkvKiBEb24ndCBvdmVycnVuICovCi0Jc3ViCXIzLCBp cCwgIzEKLQlhbmQJcjIsIHIwLCByMwotCWFkZAlyMSwgcjEsIHIyCi0JYmljCXIwLCByMCwgcjMK LQotCW1jcglwMTUsIDAsIHIwLCBjNywgYzEwLCA1ICAvKiBEYXRhIE1lbW9yeSBCYXJyaWVyIGVy cjo0NjExICovCi0xOgotI2lmZGVmIFNNUAotCS8qIFJlcXVlc3QgZm9yIG93bmVyc2hpcCAqLwot CWxkcglyMiwgW3IwXQotCXN0cglyMiwgW3IwXQotI2VuZGlmCi0JbWNyCXAxNSwgMCwgcjAsIGM3 LCBjMTAsIDEJLyogTDJDIGNsZWFuIHNpbmdsZSBlbnRyeSBieSBNVkEgKi8KLQlhZGQJcjAsIHIw LCBpcAotCXN1YnMJcjEsIHIxLCBpcAotCWJwbAkxYgotCW1jcglwMTUsIDAsIHIwLCBjNywgYzEw LCA0CS8qIGRyYWluIHRoZSB3cml0ZSBidWZmZXIgKi8KLQlSRVQKLUVORChwajRiX2RjYWNoZV93 Yl9yYW5nZSkKLQogRU5UUlkocGo0Yl9kcmFpbl9yZWFkYnVmKQogCW1jcglwMTUsIDAsIHIwLCBj NywgYzUsIDQJLyogZmx1c2ggcHJlZmV0Y2ggYnVmZmVycyAqLwogCVJFVApkaWZmIC0tZ2l0IGEv c3lzL2FybS9hcm0vaWRlbnRjcHUuYyBiL3N5cy9hcm0vYXJtL2lkZW50Y3B1LmMKaW5kZXggMGJj Zjg2ZS4uMjE5ZDQ5YyAxMDA2NDQKLS0tIGEvc3lzL2FybS9hcm0vaWRlbnRjcHUuYworKysgYi9z eXMvYXJtL2FybS9pZGVudGNwdS5jCkBAIC0zMjMsMTggKzMyMywxMCBAQCBjb25zdCBzdHJ1Y3Qg Y3B1aWR0YWIgY3B1aWRzW10gPSB7CiAKIAl7IENQVV9JRF9NVjg4RlI1NzFfVkQsCUNQVV9DTEFT U19NQVJWRUxMLAkiRmVyb2Nlb24gODhGUjU3MS1WRCIsCiAJICBnZW5lcmljX3N0ZXBwaW5ncyB9 LAotCXsgQ1BVX0lEX01WODhTVjU4MVhfVjYsCUNQVV9DTEFTU19NQVJWRUxMLAkiU2hlZXZhIDg4 U1Y1ODF4IiwKLQkgIGdlbmVyaWNfc3RlcHBpbmdzIH0sCi0JeyBDUFVfSURfQVJNXzg4U1Y1ODFY X1Y2LCBDUFVfQ0xBU1NfTUFSVkVMTCwJIlNoZWV2YSA4OFNWNTgxeCIsCi0JICBnZW5lcmljX3N0 ZXBwaW5ncyB9LAogCXsgQ1BVX0lEX01WODhTVjU4MVhfVjcsCUNQVV9DTEFTU19NQVJWRUxMLAki U2hlZXZhIDg4U1Y1ODF4IiwKIAkgIGdlbmVyaWNfc3RlcHBpbmdzIH0sCiAJeyBDUFVfSURfQVJN Xzg4U1Y1ODFYX1Y3LCBDUFVfQ0xBU1NfTUFSVkVMTCwJIlNoZWV2YSA4OFNWNTgxeCIsCiAJICBn ZW5lcmljX3N0ZXBwaW5ncyB9LAotCXsgQ1BVX0lEX01WODhTVjU4NFhfVjYsCUNQVV9DTEFTU19N QVJWRUxMLAkiU2hlZXZhIDg4U1Y1ODR4IiwKLQkgIGdlbmVyaWNfc3RlcHBpbmdzIH0sCi0JeyBD UFVfSURfQVJNXzg4U1Y1ODRYX1Y2LCBDUFVfQ0xBU1NfTUFSVkVMTCwJIlNoZWV2YSA4OFNWNTg0 eCIsCi0JICBnZW5lcmljX3N0ZXBwaW5ncyB9LAogCXsgQ1BVX0lEX01WODhTVjU4NFhfVjcsCUNQ VV9DTEFTU19NQVJWRUxMLAkiU2hlZXZhIDg4U1Y1ODR4IiwKIAkgIGdlbmVyaWNfc3RlcHBpbmdz IH0sCiAKZGlmZiAtLWdpdCBhL3N5cy9hcm0vaW5jbHVkZS9hcm1yZWcuaCBiL3N5cy9hcm0vaW5j bHVkZS9hcm1yZWcuaAppbmRleCBiYmE0MjU2Li5hMDdjMmY4IDEwMDY0NAotLS0gYS9zeXMvYXJt L2luY2x1ZGUvYXJtcmVnLmgKKysrIGIvc3lzL2FybS9pbmNsdWRlL2FybXJlZy5oCkBAIC0xNzMs MTQgKzE3MywxMCBAQAogI2RlZmluZSBDUFVfSURfTVY4OEZSNTcxXzQxCTB4NDExNTkyNjAgLyog TWFydmVsbCBGZXJvY2VvbiA4OEZSNTcxLVZEIENvcmUgKGFjdHVhbCBJRCBmcm9tIENQVSByZWcp ICovCiAjZW5kaWYKIAotI2RlZmluZSBDUFVfSURfTVY4OFNWNTgxWF9WNgkJMHg1NjBGNTgxMCAv KiBNYXJ2ZWxsIFNoZWV2YSA4OFNWNTgxeCB2NiBDb3JlICovCiAjZGVmaW5lIENQVV9JRF9NVjg4 U1Y1ODFYX1Y3CQkweDU2MUY1ODEwIC8qIE1hcnZlbGwgU2hlZXZhIDg4U1Y1ODF4IHY3IENvcmUg Ki8KLSNkZWZpbmUgQ1BVX0lEX01WODhTVjU4NFhfVjYJCTB4NTYxRjU4NDAgLyogTWFydmVsbCBT aGVldmEgODhTVjU4NHggdjYgQ29yZSAqLwogI2RlZmluZSBDUFVfSURfTVY4OFNWNTg0WF9WNwkJ MHg1NjJGNTg0MCAvKiBNYXJ2ZWxsIFNoZWV2YSA4OFNWNTg0eCB2NyBDb3JlICovCiAvKiBNYXJ2 ZWxsJ3MgQ1BVSURzIHdpdGggQVJNIElEIGluIGltcGxlbWVudG9yIGZpZWxkICovCi0jZGVmaW5l IENQVV9JRF9BUk1fODhTVjU4MVhfVjYJCTB4NDEwZmI3NjAgLyogTWFydmVsbCBTaGVldmEgODhT VjU4MXggdjYgQ29yZSAqLwogI2RlZmluZSBDUFVfSURfQVJNXzg4U1Y1ODFYX1Y3CQkweDQxM0ZD MDgwIC8qIE1hcnZlbGwgU2hlZXZhIDg4U1Y1ODF4IHY3IENvcmUgKi8KLSNkZWZpbmUgQ1BVX0lE X0FSTV84OFNWNTg0WF9WNgkJMHg0MTBGQjAyMCAvKiBNYXJ2ZWxsIFNoZWV2YSA4OFNWNTg0eCB2 NiBDb3JlICovCiAKICNkZWZpbmUJQ1BVX0lEX0ZBNTI2CQkweDY2MDE1MjYwCiAjZGVmaW5lCUNQ VV9JRF9GQTYyNlRFCQkweDY2MDU2MjYwCmRpZmYgLS1naXQgYS9zeXMvYXJtL2luY2x1ZGUvY3B1 ZnVuYy5oIGIvc3lzL2FybS9pbmNsdWRlL2NwdWZ1bmMuaAppbmRleCAwN2M4MjU4Li42YmE5NmM1 IDEwMDY0NAotLS0gYS9zeXMvYXJtL2luY2x1ZGUvY3B1ZnVuYy5oCisrKyBiL3N5cy9hcm0vaW5j bHVkZS9jcHVmdW5jLmgKQEAgLTQ4MiwxNCArNDgyLDYgQEAgdm9pZAlhcm0xMV9kcmFpbl93cml0 ZWJ1Zgkodm9pZCk7CiAKIHZvaWQJcGo0Yl9zZXR0dGIJCQkodV9pbnQpOwogCi12b2lkCXBqNGJf aWNhY2hlX3N5bmNfcmFuZ2UJCSh2bV9vZmZzZXRfdCwgdm1fc2l6ZV90KTsKLQotdm9pZAlwajRi X2RjYWNoZV93Ymludl9yYW5nZQkJKHZtX29mZnNldF90LCB2bV9zaXplX3QpOwotdm9pZAlwajRi X2RjYWNoZV9pbnZfcmFuZ2UJCSh2bV9vZmZzZXRfdCwgdm1fc2l6ZV90KTsKLXZvaWQJcGo0Yl9k Y2FjaGVfd2JfcmFuZ2UJCSh2bV9vZmZzZXRfdCwgdm1fc2l6ZV90KTsKLQotdm9pZAlwajRiX2lk Y2FjaGVfd2JpbnZfcmFuZ2UJKHZtX29mZnNldF90LCB2bV9zaXplX3QpOwotCiB2b2lkCXBqNGJf ZHJhaW5fcmVhZGJ1ZgkJKHZvaWQpOwogdm9pZAlwajRiX2ZsdXNoX2JybmNodGd0X2FsbAkJKHZv aWQpOwogdm9pZAlwajRiX2ZsdXNoX2JybmNodGd0X3ZhCQkodV9pbnQpOwpAQCAtNTIzLDcgKzUx NSw2IEBAIHZvaWQJYXJtdjdfZHJhaW5fd3JpdGVidWYJCSh2b2lkKTsKIHZvaWQJYXJtdjdfc2V2 CQkJKHZvaWQpOwogdV9pbnQJYXJtdjdfYXV4Y3RybAkJCSh1X2ludCwgdV9pbnQpOwogdm9pZAlw ajRidjdfc2V0dXAJCQkoY2hhciAqc3RyaW5nKTsKLXZvaWQJcGo0YnY2X3NldHVwCQkJKGNoYXIg KnN0cmluZyk7CiB2b2lkCXBqNGJfY29uZmlnCQkJKHZvaWQpOwogCiBpbnQJZ2V0X2NvcmVfaWQJ CQkodm9pZCk7Ci0tIAoxLjguNAoK --047d7b874c42eeab0904e99905f6 Content-Type: application/octet-stream; name="0008-Switch-off-explicit-broadcasting-of-the-TLB-flush-op.patch" Content-Disposition: attachment; filename="0008-Switch-off-explicit-broadcasting-of-the-TLB-flush-op.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hn817iio4 RnJvbSBjY2U4NjliNTlkODJkNTA3NmFlMDYwMGZkOWRhNGY0MmNkZjZjMjM5IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogVHVlLCAyMiBPY3QgMjAxMyAwMjo0MTozNyArMDIwMApTdWJqZWN0OiBbUEFUQ0ggOC84XSBT d2l0Y2ggb2ZmIGV4cGxpY2l0IGJyb2FkY2FzdGluZyBvZiB0aGUgVExCIGZsdXNoCiBvcGVyYXRp b25zIGZvciBQSjRCIENQVQoKU2luY2UgQ1BVX01WX1BKNEIgZGVzY3JpYmVzIEFSTXY3IGNvbXBs aWFudCBDUFUgdGhlcmUgaXMgbm8gbmVlZCBmb3IKc2VuZGluZyBhbiBJUEkgZWFjaCB0aW1lIHdo ZW4gVExCIGlzIGZsdXNoZWQgaW4gYW55IHdheS4KCkFwcHJvdmVkIGJ5Ogljb2duZXQgKG1lbnRv cikKLS0tCiBzeXMvYXJtL2luY2x1ZGUvY3B1ZnVuYy5oIHwgMiArLQogMSBmaWxlIGNoYW5nZWQs IDEgaW5zZXJ0aW9uKCspLCAxIGRlbGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvc3lzL2FybS9pbmNs dWRlL2NwdWZ1bmMuaCBiL3N5cy9hcm0vaW5jbHVkZS9jcHVmdW5jLmgKaW5kZXggNmJhOTZjNS4u ZDNlOWViZSAxMDA2NDQKLS0tIGEvc3lzL2FybS9pbmNsdWRlL2NwdWZ1bmMuaAorKysgYi9zeXMv YXJtL2luY2x1ZGUvY3B1ZnVuYy5oCkBAIC0xODgsNyArMTg4LDcgQEAgZXh0ZXJuIHVfaW50IGNw dXR5cGU7CiAjZWxzZQogdm9pZCB0bGJfYnJvYWRjYXN0KGludCk7CiAKLSNpZmRlZiBDUFVfQ09S VEVYQQorI2lmIGRlZmluZWQoQ1BVX0NPUlRFWEEpIHx8IGRlZmluZWQoQ1BVX01WX1BKNEIpCiAj ZGVmaW5lIFRMQl9CUk9BRENBU1QJLyogTm8gbmVlZCB0byBleHBsaWNpdGVseSBzZW5kIGFuIElQ SSAqLwogI2Vsc2UKICNkZWZpbmUgVExCX0JST0FEQ0FTVAl0bGJfYnJvYWRjYXN0KDcpCi0tIAox LjguNAoK --047d7b874c42eeab0904e99905f6-- From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 23:36:52 2013 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 ESMTP id 0C03D989 for ; Fri, 25 Oct 2013 23:36:52 +0000 (UTC) (envelope-from www@kenobi.freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [8.8.178.118]) by mx1.freebsd.org (Postfix) with ESMTP id E8E2C2A18 for ; Fri, 25 Oct 2013 23:36:51 +0000 (UTC) Received: by kenobi.freebsd.org (Postfix, from userid 80) id D3A1369886F; Fri, 25 Oct 2013 19:36:51 -0400 (EDT) From: bugzilla-daemon@kenobi.freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 182216] New: Just test Date: Sat, 26 Oct 2013 03:36:51 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: FreeBSD X-Bugzilla-Component: arm X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: gonzo@bluezbox.com X-Bugzilla-Status: CONFIRMED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: bug_id short_desc classification product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: X-Bugzilla-URL: http://kenobi.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:36:52 -0000 http://kenobi.freebsd.org/bugzilla/show_bug.cgi?id=182216 Bug ID: 182216 Summary: Just test Classification: Unclassified Product: FreeBSD Version: 10.0-CURRENT Hardware: PC OS: Mac OS Status: CONFIRMED Severity: enhancement Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: gonzo@bluezbox.com testing if adding from web works -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 25 23:40:17 2013 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 ESMTP id F0CE9B95 for ; Fri, 25 Oct 2013 23:40:17 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [88.198.91.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AAD0E2A34 for ; Fri, 25 Oct 2013 23:40:17 +0000 (UTC) Received: from [207.81.161.55] (helo=[192.168.1.66]) by id.bluezbox.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1VZqzG-000LW6-4T for freebsd-arm@FreeBSD.org; Fri, 25 Oct 2013 16:40:16 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [Bug 182216] New: Just test From: Oleksandr Tymoshenko In-Reply-To: Date: Fri, 25 Oct 2013 16:39:56 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: To: "freebsd-arm@FreeBSD.org List" X-Mailer: Apple Mail (2.1510) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Oops! Sorry for the spam [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -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.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2013 23:40:18 -0000 Oops! Sorry for the spam From owner-freebsd-arm@FreeBSD.ORG Sat Oct 26 00:14:53 2013 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 ESMTP id 614F4105; Sat, 26 Oct 2013 00:14:53 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9765C2BCB; Sat, 26 Oct 2013 00:14:52 +0000 (UTC) Received: by mail-we0-f176.google.com with SMTP id w62so4476515wes.21 for ; Fri, 25 Oct 2013 17:14:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Z3xllQRO0jqF5u77/jZ/MAvxmI/flYrNGm0/PcZJPvs=; b=BjWaHyjaO9MqPXEnowfUYZLlAjZyxaLpG4n4T9pJxd+8udwdtWpT27RLOlbNI12E8w dh0tdCLuJXrhwdGFhptehNLwMFFbfPaLWdYC6iG5eeWbJnj9mgCY/A7rsn8lJ9FESVHg fGt/8TVwjsRKY6vFr8nV6JecvhKV7CCpTepLcQmPWtAZSvEjdnfSk6hCNodSzwJYOmmq cSsjS9SijqqZLR4ICDOd1FdcYLBDnTv0bDvrauK+wSOE1x35rLR674pSKyE89F5fbvA1 8mBa5LZMTa7v4dU337JFESO13tjzgO+qAdzPS5Jz3qZF8PNz32T3CHyyH3s4o9W00Rr2 enfA== MIME-Version: 1.0 X-Received: by 10.194.176.163 with SMTP id cj3mr9477292wjc.8.1382746491120; Fri, 25 Oct 2013 17:14:51 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.209.194 with HTTP; Fri, 25 Oct 2013 17:14:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Oct 2013 02:14:50 +0200 X-Google-Sender-Auth: h6RAnr6P2r3Fv02KPefPv1btXeA Message-ID: Subject: Re: Changes to UART ns8250 From: Zbigniew Bodek To: "freebsd-embedded@freebsd.org" Content-Type: multipart/mixed; boundary=089e013cbfea6b0db604e999c193 Cc: "freebsd-arm@freebsd.org" , freebsd-current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 00:14:53 -0000 --089e013cbfea6b0db604e999c193 Content-Type: text/plain; charset=ISO-8859-1 Hello Everyone, I'm attaching the newest version of the ns8250 UART patch. After some discussions I decided to go with busy-wait + timeout solution. The applied delay should handle exotic corner cases (please notice that we can't use ns8250_delay() to get the actual single transmission time since we know that LCR is locked). If there are no objections then I would like to commit this soon. Best regards Zbigniew Bodek 2013/10/9 Zbigniew Bodek : > Hello Ganbold. > > Thank you for testing the patch and pointing those issue out. > My detection log from Armada XP: > > uart0: <16550 or compatible> mem 0xd0012000-0xd001201f irq 41 on simplebus0 > uart0: console (115200,n,8,1) > uart1: <16550 or compatible> mem 0xd0012100-0xd001211f irq 42 on simplebus0 > uart2: <16550 or compatible> mem 0xd0012200-0xd001221f irq 43 on simplebus0 > uart3: <16550 or compatible> mem 0xd0012300-0xd001231f irq 44 on simplebus0 > > Is there a possibility to download a datasheet for RK30xx so that I could > verify what is required for it's UART? > The patch is causing that we only wait until UART is not busy anymore. I > can't find why would that cause problems > if your UART requires busy detection anyway. > > Best regards > Zbigniew Bodek > > > > 2013/10/9 Ganbold Tsagaankhuu >> >> >> >> >> On Tue, Oct 8, 2013 at 9:58 AM, Ganbold Tsagaankhuu >> wrote: >>> >>> Zbigniew, >>> >>> >>> On Tue, Oct 8, 2013 at 3:54 AM, Zbigniew Bodek wrote: >>>> >>>> Hello. >>>> >>>> I would like to present a patch for ns8250 serial that I would like to >>>> commit in the near future (if there are no objections). >>>> >>>> The patch is fixing newest DesignWare UART with busy detection. >>>> During frequency divisors configuration when UART is busy transferring >>>> or >>>> receiving data, line control register manipulation will not take effect. >>>> Therefore, we will not set divisor latch access bit and we will corrupt >>>> LCR >>>> instead of configuring divisors. >>>> It is necessary to wait until UART finishes all transfers to proceed >>>> with >>>> the configuration. >>>> >>>> This was detected on Armada XP as UART fails on this issue 100/100 >>>> attempts. >>>> The patch was tested by kevlo@ and me and it works on our Armada XP - >>>> based >>>> systems. >>>> >>>> Please send your comment or remarks if there are any. >>> >>> >>> I'm trying your patch on r254983. >>> Tried on 2 boards (Cubieboard2 (Allwinner A20 SoC - dual Cortex A7) and >>> Radxa Rock (Rockchip RK3188 - Quad Cortex A9)). Both seem to have some sort >>> of DesignWare uart. >>> >>> 1. It works fine on Cubieboard2. Uart dmesg is like: >>> >>> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0 >>> uart0: console (115200,n,8,1) >>> >>> 2. No any printing on screen in case of Radxa Rock. Without your patch >>> uart dmesg is like: >>> >>> uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on >>> simplebus0 >>> uart0: console (115200,n,8,1) >>> >>> In case of RK3188 SoC, it seems booting FreeBSD kernel seems very >>> fragile, not sure yet what is causing the problem. >>> Even with stock ns8250 some version later than r254983 didn't show/print >>> anything on serial console few days ago. >>> Only thing so far I know is this r254983 (with some patch) works in my >>> case on RK3188 SoC based board. >> >> >> >> Zbigniew, >> >> Just tried again your patch on RK30xx board. I was able to see boot >> messages on screen. >> This uart detected as: >> ... >> uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on >> simplebus0 >> uart0: console (115200,n,8,1) >> uart0: fast interrupt >> ... >> Can you show me your uart detection log? >> It seems this DW uart of RK30xx is different than DW uart of A10/A20. >> Boot simply stops printing "start_init: trying /sbin/init". >> >> thanks, >> >> Ganbold >> >> >>> >>> >>> thanks, >>> >>> Ganbold >>> >>> >>> >>>> >>>> >>>> Best regards >>>> Zbigniew Bodek >>>> >>>> _______________________________________________ >>>> freebsd-current@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to >>>> "freebsd-current-unsubscribe@freebsd.org" >>> >>> >> > --089e013cbfea6b0db604e999c193 Content-Type: application/octet-stream; name="0001-Wait-for-DesignWare-UART-transfers-completion-before.patch" Content-Disposition: attachment; filename="0001-Wait-for-DesignWare-UART-transfers-completion-before.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hn83jw4x0 RnJvbSAwYjIxZTI2MDYwZmM5Y2RmMjNlMTBmZDFiMWJlNTY2YjVjNzM4ZjJiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBaYmlnbmlldyBCb2RlayA8emJiQHNlbWloYWxmLmNvbT4KRGF0 ZTogU2F0LCA1IE9jdCAyMDEzIDAyOjI1OjIzICswMjAwClN1YmplY3Q6IFtQQVRDSF0gV2FpdCBm b3IgRGVzaWduV2FyZSBVQVJUIHRyYW5zZmVycyBjb21wbGV0aW9uIGJlZm9yZQogYWNjZXNzaW5n IGxpbmUgY29udHJvbAoKV2hlbiB1c2luZyBEVyBVQVJUIHdpdGggQlVTWSBkZXRlY3Rpb24gaXQg aXMgbmVjZXNzYXJ5IHRvIHdhaXQKdW50aWwgYWxsIHNlcmlhbCB0cmFuc2ZlcnMgYXJlIGZpbmlz aGVkIGJlZm9yZSBtYW5pcHVsYXRpbmcgdGhlCmxpbmUgY29udHJvbC4gTENSIHdpbGwgbm90IGJl IGFmZmVjdGVkIHdoZW4gVUFSVCBpcyBidXN5LgpJbiBhZGRpdGlvbiwgaWYgRGl2aXNvciBMYXRj aCBBY2Nlc3MgQml0IGlzIGJlaW5nIHNldCBpbiBvcmRlciB0bwptb2RpZnkgVUFSVCBkaXZpc29y czoKMS4gV2Ugd2lsbCBnZXQgQlVTWSBpbnRlcnJ1cHQgaWYgaW50ZXJydXB0cyBhcmUgZW5hYmxl ZC4KMi4gQmVjYXVzZSBMQ1Igd2lsbCBub3QgYmUgYWZmZWN0ZWQgdGhlIFRIUiBhbmQgKGV2ZW4g d29yc2UpIElFUgogICBjb250ZW50cyB3aWxsIGJlIGNvcnJ1cHRlZC4gVGhpcyB3aWxsIGxlYWQg dG8gY29uc29sZSBoYW5nLgoKQXBwcm92ZWQgYnk6CWNvZ25ldCAobWVudG9yKQotLS0KIHN5cy9k ZXYvaWMvbnMxNjU1MC5oICAgICAgICAgICB8ICAxICsKIHN5cy9kZXYvdWFydC91YXJ0X2Rldl9u czgyNTAuYyB8IDI2ICsrKysrKysrKysrKysrKysrKysrKysrKystCiAyIGZpbGVzIGNoYW5nZWQs IDI2IGluc2VydGlvbnMoKyksIDEgZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9zeXMvZGV2L2lj L25zMTY1NTAuaCBiL3N5cy9kZXYvaWMvbnMxNjU1MC5oCmluZGV4IDY1OWY1OTEuLjMzYTdkZDEg MTAwNjQ0Ci0tLSBhL3N5cy9kZXYvaWMvbnMxNjU1MC5oCisrKyBiL3N5cy9kZXYvaWMvbnMxNjU1 MC5oCkBAIC0xODUsNiArMTg1LDcgQEAKICNkZWZpbmUgRFdfUkVHX1VTUgkzMQkvKiBEZXNpZ25X YXJlIGRlcml2ZWQgVWFydCBTdGF0dXMgUmVnICovCiAjZGVmaW5lIGNvbV91c3IJCTM5CS8qIE9j dGVvbiAxNjc1MC8xNjU1MCBVYXJ0IFN0YXR1cyBSZWcgKi8KICNkZWZpbmUgUkVHX1VTUgkJY29t X3VzcgorI2RlZmluZSBVU1JfQlVTWQkxCS8qIFVhcnQgQnVzeS4gU2VyaWFsIHRyYW5zZmVyIGlu IHByb2dyZXNzICovCiAjZGVmaW5lIFVTUl9UWEZJRk9fTk9URlVMTCAyICAgIC8qIFVhcnQgVFgg RklGTyBOb3QgZnVsbCAqLwogCiAvKiAxNjk1MCByZWdpc3RlciAjMS4gIEFjY2VzcyBlbmFibGVk IGJ5IEFDUls3XS4gIEFsc28gcmVxdWlyZXMgIUxDUls3XS4gKi8KZGlmZiAtLWdpdCBhL3N5cy9k ZXYvdWFydC91YXJ0X2Rldl9uczgyNTAuYyBiL3N5cy9kZXYvdWFydC91YXJ0X2Rldl9uczgyNTAu YwppbmRleCAyMTFkMTEzLi4yNDliZTRjIDEwMDY0NAotLS0gYS9zeXMvZGV2L3VhcnQvdWFydF9k ZXZfbnM4MjUwLmMKKysrIGIvc3lzL2Rldi91YXJ0L3VhcnRfZGV2X25zODI1MC5jCkBAIC02NDcs MTEgKzY0NywzNSBAQCBpbnQKIG5zODI1MF9idXNfcGFyYW0oc3RydWN0IHVhcnRfc29mdGMgKnNj LCBpbnQgYmF1ZHJhdGUsIGludCBkYXRhYml0cywKICAgICBpbnQgc3RvcGJpdHMsIGludCBwYXJp dHkpCiB7CisJc3RydWN0IG5zODI1MF9zb2Z0YyAqbnM4MjUwOwogCXN0cnVjdCB1YXJ0X2JhcyAq YmFzOwotCWludCBlcnJvcjsKKwlpbnQgZXJyb3IsIGxpbWl0OwogCisJbnM4MjUwID0gKHN0cnVj dCBuczgyNTBfc29mdGMqKXNjOwogCWJhcyA9ICZzYy0+c2NfYmFzOwogCXVhcnRfbG9jayhzYy0+ c2NfaHdtdHgpOworCS8qCisJICogV2hlbiB1c2luZyBEVyBVQVJUIHdpdGggQlVTWSBkZXRlY3Rp b24gaXQgaXMgbmVjZXNzYXJ5IHRvIHdhaXQKKwkgKiB1bnRpbCBhbGwgc2VyaWFsIHRyYW5zZmVy cyBhcmUgZmluaXNoZWQgYmVmb3JlIG1hbmlwdWxhdGluZyB0aGUKKwkgKiBsaW5lIGNvbnRyb2wu IExDUiB3aWxsIG5vdCBiZSBhZmZlY3RlZCB3aGVuIFVBUlQgaXMgYnVzeS4KKwkgKi8KKwlpZiAo bnM4MjUwLT5idXN5X2RldGVjdCAhPSAwKSB7CisJCS8qCisJCSAqIFBpY2sgYW4gYXJiaXRyYXJ5 IGhpZ2ggbGltaXQgdG8gYXZvaWQgZ2V0dGluZyBzdHVjayBpbgorCQkgKiBhbiBpbmZpbml0ZSBs b29wIGluIGNhc2Ugd2hlbiB0aGUgaGFyZHdhcmUgaXMgYnJva2VuLgorCQkgKi8KKwkJbGltaXQg PSAxMCAqIDEwMjQ7CisJCXdoaWxlICgoKHVhcnRfZ2V0cmVnKGJhcywgRFdfUkVHX1VTUikgJiBV U1JfQlVTWSkgIT0gMCkgJiYKKwkJICAgIC0tbGltaXQpCisJCQlERUxBWSg0KTsKKworCQlpZiAo bGltaXQgPD0gMCkgeworCQkJLyogVUFSVCBhcHBlYXJzIHRvIGJlIHN0dWNrICovCisJCQl1YXJ0 X3VubG9jayhzYy0+c2NfaHdtdHgpOworCQkJcmV0dXJuIChFSU8pOworCQl9CisJfQorCiAJZXJy b3IgPSBuczgyNTBfcGFyYW0oYmFzLCBiYXVkcmF0ZSwgZGF0YWJpdHMsIHN0b3BiaXRzLCBwYXJp dHkpOwogCXVhcnRfdW5sb2NrKHNjLT5zY19od210eCk7CiAJcmV0dXJuIChlcnJvcik7Ci0tIAox LjguNAoK --089e013cbfea6b0db604e999c193-- From owner-freebsd-arm@FreeBSD.ORG Sat Oct 26 01:40:23 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 79E65DD5; Sat, 26 Oct 2013 01:40:23 +0000 (UTC) (envelope-from ssl.qlt@gmail.com) Received: from mail-bk0-x241.google.com (mail-bk0-x241.google.com [IPv6:2a00:1450:4008:c01::241]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CB8FA2F17; Sat, 26 Oct 2013 01:40:22 +0000 (UTC) Received: by mail-bk0-f65.google.com with SMTP id w14so276348bkz.8 for ; Fri, 25 Oct 2013 18:40:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WoU9Netn8lyOkYJwetRV2VpJgEwwiUnevtBm8fO5Bzw=; b=DRtKVXm4oM6Rgj0NV7B5n+wMj54MBkqvLHcna9E4QHyE/Cfg3X8WKivBphEmBMhkGv HEXd5TvKAYoMNteVCrJvgRDrdXQpdmCb8vjMUZUkGTkWBUqY9uhcAONhGiKDw57w7kIx Bg2n0TWYYScbFNsgTikctyfKtKyIeD288kQYwQEu+Vsx3sxnQcxyjYo9ZTYoscYJMOQ4 ZGIRjclc2AjpEnv3ya2IenRATz5f0mt2dOGRm/R1j4LCs1bbDXF/XoR4lIpO436/4hc2 wZWc82Q+v29UdYJSWlQZ7KWksnJc7utLxDRsJ+N//5MhE8N9uM+8XMdMlI5cwhEOtEhI CZtw== MIME-Version: 1.0 X-Received: by 10.204.229.76 with SMTP id jh12mr231891bkb.44.1382751620929; Fri, 25 Oct 2013 18:40:20 -0700 (PDT) Received: by 10.204.231.209 with HTTP; Fri, 25 Oct 2013 18:40:20 -0700 (PDT) In-Reply-To: <1382738462.1170.153.camel@revolution.hippie.lan> References: <1382734990.1170.132.camel@revolution.hippie.lan> <1382738462.1170.153.camel@revolution.hippie.lan> Date: Fri, 25 Oct 2013 18:40:20 -0700 Message-ID: Subject: Re: Fwd: Dreamplug stable/10 usb - sd file transfer corruption error - cache related? From: Steven Lee To: Ian Lepore Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 01:40:23 -0000 Ian, thanks for taking a look to see if you can recreate the problem. In case it makes any difference in behavior, the command I used for the transfer was: (dump -0Lf - /) | (cd /mnt/flash_root ; restore -rf -) with /dev/da2s2 mounted at / and /dev/da0s2 mounted at /mnt/flash_root Regards, Steve On Fri, Oct 25, 2013 at 3:01 PM, Ian Lepore wrote: > That old advice was based on bugs in old code that has been fixed. I've > just been double-checking that the various fixes are in 10 (some of them > were things I submitted a PR for before I became a committer). I'm not > sure about the usb driver, but there have been big changes in the dma > cache coherency code between 9 and 10, although much of that is the > fixes I was alluding to. > > Basically what you're doing is a usb->usb copy, I'll see if I can > recreate the corruption on my dreamplug here the same way. > > -- Ian > > On Fri, 2013-10-25 at 14:38 -0700, Steven Lee wrote: > > ---------- Forwarded message ---------- > > From: Steven Lee > > Date: Fri, Oct 25, 2013 at 2:37 PM > > Subject: Re: Dreamplug stable/10 usb - sd file transfer corruption error > - > > cache related? > > To: Ian Lepore > > > > > > Ian, thanks for your reply. > > > > I am using the DREAMPLUG-1001 stock kernel config, and you are right the > > internal sd card shows up as a usb device, /dev/da0. > > > > As I mentioned, I tried modifying pmap.c as per one of your suggestions > to > > an earlier poster / problem, but it didn't seem to help the issue. I > > changed the pmap_pte_init_arm10() function to look like the > > pmap_pte_init_arm9() function. > > > > Any other thoughts about things to try? Since it seems like this is a > > regression between 9 and 10, are you aware of any specific cache related > > changes to the usb driver between the branches? > > > > - Steve > > > > > > On Fri, Oct 25, 2013 at 2:03 PM, Ian Lepore wrote: > > > > > On Fri, 2013-10-25 at 13:37 -0700, Steven Lee wrote: > > > > Hello, > > > > > > > > In the process of upgrading my Dreamplug from the stable/9 branch to > the > > > > stable/10 branch, I have run into a fairly > > > > significant file corruption problem. The steps that create this > problem > > > > are as follows: > > > > > > > > 1. Cross-compile the kernel and buildworld from the stable/10 branch > on a > > > > separate host. > > > > 2. Install the kernel and installworld on a usb stick drive > > > > 3. Boot the Dreamplug from the usb drive > > > > > > > > There are no problems that show up to this point, the Dreamplug boots > > > with > > > > no errors. > > > > > > > > 4. Copy the kernel from the usb drive to the internal sd card > > > > 5. Copy the root filesystem from the usb drive to the internal sd > card > > > > using (dump | restore) > > > > > > > > It is at step 5 that the error manifests itself, as I found that > > > > approximately 20 shell scripts in the /etc/rc.d directory > > > > had been randomly corrupted with strings of null characters (in > groups of > > > > 32). I assume that the rest of the file system > > > > was compromised in a similar fashion. The bug is repeatable, > however the > > > > corruption is somewhat random, so > > > > each time different files are corrupted in different places. > > > > > > > > When I followed the exact same steps from the stable/9 branch, the > > > problem > > > > did not occur, so there is clearly some > > > > type of regression error between the 9 and 10 branches. > > > > > > > > After searching through the arm mailing list, I attempted to work > around > > > > the problem by: > > > > - mounting the file systems with -o noclusterr -o noclusterrw > > > > - mounting the file systems with -o sync > > > > - as per comments on bug arm/158950, attempted to modify the pmap.c > > > > functions to change the cache from > > > > write-back mode to write-through mode > > > > > > > > but all of these attempts were ineffective. > > > > > > > > Given that I am relatively new to FreeBSD, I was hoping to get any > > > insights > > > > as to any next steps that might make > > > > sense in terms of either working around the problem, narrowing down > the > > > > bug, or any obvious rookie mistakes I > > > > am making before I give up and revert back to the 9 branch. > > > > > > > > Thanks for your help! > > > > > > > > Regards, > > > > > > On my dreamplug (model 1001) both the internal and external sd cards > are > > > actually usb devices (they show up as /dev/da0 and da1, not mmcsd0/1). > > > I'm not sure if that's true on all models or not. > > > > > > Are you using the stock kernel config (DREAMPLUG-1001)? If not, have > > > you got "option USB_HOST_ALIGN=32" in your kernel config? > > > > > > Corruption in 32 byte chunks is almost always partial cacheline flush > > > problems, but I haven't seen that happen on dreamplug for a long time > > > (and when I did see it, it was with a sata drive). > > > > > > -- Ian > > > > > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > From owner-freebsd-arm@FreeBSD.ORG Sat Oct 26 14:12:59 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 ESMTP id EEC91691; Sat, 26 Oct 2013 14:12:59 +0000 (UTC) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B45692F83; Sat, 26 Oct 2013 14:12:59 +0000 (UTC) Received: from freebsd-current.sentex.ca (localhost [127.0.0.1]) by freebsd-current.sentex.ca (8.14.5/8.14.5) with ESMTP id r9QECwEu091435; Sat, 26 Oct 2013 10:12:58 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: (from tinderbox@localhost) by freebsd-current.sentex.ca (8.14.5/8.14.5/Submit) id r9QECw3f091433; Sat, 26 Oct 2013 14:12:58 GMT (envelope-from tinderbox@freebsd.org) Date: Sat, 26 Oct 2013 14:12:58 GMT Message-Id: <201310261412.r9QECw3f091433@freebsd-current.sentex.ca> X-Authentication-Warning: freebsd-current.sentex.ca: tinderbox set sender to FreeBSD Tinderbox using -f Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Subject: [head tinderbox] failure on arm/arm Precedence: bulk X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 14:13:00 -0000 TB --- 2013-10-26 11:10:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-26 11:10:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 des@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-26 11:10:18 - starting HEAD tinderbox run for arm/arm TB --- 2013-10-26 11:10:18 - cleaning the object tree TB --- 2013-10-26 11:10:18 - /usr/local/bin/svn stat /src TB --- 2013-10-26 11:10:23 - At svn revision 257155 TB --- 2013-10-26 11:10:24 - building world TB --- 2013-10-26 11:10:24 - CROSS_BUILD_TESTING=YES TB --- 2013-10-26 11:10:24 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-26 11:10:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-26 11:10:24 - SRCCONF=/dev/null TB --- 2013-10-26 11:10:24 - TARGET=arm TB --- 2013-10-26 11:10:24 - TARGET_ARCH=arm TB --- 2013-10-26 11:10:24 - TZ=UTC TB --- 2013-10-26 11:10:24 - __MAKE_CONF=/dev/null TB --- 2013-10-26 11:10:24 - cd /src TB --- 2013-10-26 11:10:24 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Oct 26 11:10:30 UTC 2013 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] ===> usr.sbin/pkg (all) cc -O -pipe -I/src/usr.sbin/pkg/../../contrib/libyaml/include -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /src/usr.sbin/pkg/pkg.c cc -O -pipe -I/src/usr.sbin/pkg/../../contrib/libyaml/include -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /src/usr.sbin/pkg/dns_utils.c cc -O -pipe -I/src/usr.sbin/pkg/../../contrib/libyaml/include -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -c /src/usr.sbin/pkg/config.c cc -O -pipe -I/src/usr.sbin/pkg/../../contrib/libyaml/include -std=gnu99 -Qunused-arguments -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wmissing-variable-declarations -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -L/obj/arm.arm/src/tmp/usr/lib/private -rpath /usr/lib/private -o pkg pkg.o dns_utils.o config.o -larchive -lelf -lfetch -lyaml -lsbuf -lssl /obj/arm.arm/src/tmp/usr/bin/ld: B: invalid DSO for symbol `EVP_PKEY_free' definition /obj/arm.arm/src/tmp/lib/libcrypto.so.7: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. bmake[3]: stopped in /src/usr.sbin/pkg *** Error code 1 Stop. bmake[2]: stopped in /src/usr.sbin *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2013-10-26 14:12:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-10-26 14:12:58 - ERROR: failed to build world TB --- 2013-10-26 14:12:58 - 8623.70 user 1635.68 system 10959.70 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-arm-arm.full From owner-freebsd-arm@FreeBSD.ORG Sat Oct 26 16:43:09 2013 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 ESMTP id 68F32DDE for ; Sat, 26 Oct 2013 16:43:09 +0000 (UTC) (envelope-from kientzle@freebsd.org) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 45BFD272C for ; Sat, 26 Oct 2013 16:43:08 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r9QGgqlY031219; Sat, 26 Oct 2013 16:42:52 GMT (envelope-from kientzle@freebsd.org) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 3eqc8ifrgx5sufkwds4bw2rug2; Sat, 26 Oct 2013 16:42:52 +0000 (UTC) (envelope-from kientzle@freebsd.org) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: About building world for armv6 errors From: Tim Kientzle In-Reply-To: Date: Sat, 26 Oct 2013 09:42:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: John Elder X-Mailer: Apple Mail (2.1510) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 16:43:09 -0000 On Oct 21, 2013, at 8:22 PM, John Elder = wrote: > Hi, > I have FreeBSD 9.1 and I am having error (not full error, because it = is > big) when building world for armv6. I use the CURRENT src code.=E2=80=8B= > = buildworld.txt > =E2=80=8BWho can help me to solve this problem? How are you building? If you are using -j, then you should try again without -j (parallel = builds interleave the output and make it hard to see errors). Tim From owner-freebsd-arm@FreeBSD.ORG Sat Oct 26 17:33:26 2013 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 ESMTP id BD8E8FA8; Sat, 26 Oct 2013 17:33:26 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 37FDC2956; Sat, 26 Oct 2013 17:33:26 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id q59so5030136wes.39 for ; Sat, 26 Oct 2013 10:33:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dceXQSfwUegQELW3/naT1PMQRCugx0WceXsiCiOgLVo=; b=bFjOfc4TkDgoIFiSsJJPiIluvZD7zVNEyPp6CpkibQM4SWGZ26cbK+9RdrBEU5cumO B2RMRg1LVB+I6hhXEXU/LBVzgBeZvhnzyqUwlxhGRvMNa9i3bPZWvPojaVTuuEzMx9uW fcEMVAwpdw09xBnOhOUDjITGUSga20eMY/8dBH6GCkPJm1Sc5fx0pgjJALy5swWvCZnx eZVaNNys6P7fNP+upKD678ynQw4EMB52gJLfFhegC6O6D6bz3qorWm/mbCI4LD44fe2M LwUAhoiRXLcG+9k0LSR3QCpreb5ojbo34ZecgEEiOrn6ax8jf3Dpk+3y5uNT1lGWIO+t FNZA== MIME-Version: 1.0 X-Received: by 10.194.201.225 with SMTP id kd1mr11883616wjc.35.1382808804665; Sat, 26 Oct 2013 10:33:24 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.209.194 with HTTP; Sat, 26 Oct 2013 10:33:24 -0700 (PDT) In-Reply-To: References: <52536AD4.4070603@FreeBSD.org> Date: Sat, 26 Oct 2013 19:33:24 +0200 X-Google-Sender-Auth: WbYVv73TYbADDpsnz4K7iMomYA8 Message-ID: Subject: Re: Changes to Armada XP From: Zbigniew Bodek To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: Kevin Lo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 17:33:26 -0000 Hello Everyone. Patches 0002 & 0003 are committed: http://svnweb.freebsd.org/base?view=revision&revision=257171 http://svnweb.freebsd.org/base?view=revision&revision=257170 Patches 0004-0008 will be committed on Monday. Best regards Zbigniew Bodek 2013/10/26 Zbigniew Bodek : > Hello again. > > Apart from the earlier mentioned patches I would like to add some more: > > 0004 - some clean-ups to generic ARM code related to AXP > 0005 - some AXP based boards have different SoC registers' base > address so we need to > correct configuration variables and eventually DT to map > this properly and > boot without problems on any type of u-boot. > 0006 - just modifying the kernel load address. If I commit this I will > change the entry on AXP wiki page accordingly. > 0007 - removal of the obsolete PJ4Bv6 code > 0008 - disabling explicit TLB broadcasting using IPI. PJ4Bv7 is > capable of doing this in HW > > More detailed descriptions are of course in commit-logs. > Please test those patches if you like and send your remarks if there are any. > > I would like to commit this (and previous patches) by the end of Saturday 26th > because I'm stashing this for quite some time now. > So if there will be no objections I will do as described :) > > Thank you and best regards > Zbigniew Bodek > > > 2013/10/8 Kevin Lo : >> Zbigniew Bodek wrote: >>> >>> Hello. >>> >>> I would like to commit two patches for Armada XP. >>> >>> 0002 - is enabling busy-detection for UART on Armada XP. Combined with >>> another patch for ns8250 UART (posted in the separate e-mail) this fixes >>> UART IF issues on Armada XP. >>> >>> 0003 - enables SATA interface on Armada XP. >>> >>> If there are no objections then I would like to commit them in the near >>> future. >> >> >> Works for me. Tested on the Openblocks AX3. Thanks! >> >>> >>> Best regards >>> Zbigniew Bodek >> >> >> Kevin From owner-freebsd-arm@FreeBSD.ORG Sat Oct 26 17:34:53 2013 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 ESMTP id 29098FF3; Sat, 26 Oct 2013 17:34:53 +0000 (UTC) (envelope-from zbodek@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6DE1B2962; Sat, 26 Oct 2013 17:34:52 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id q59so5030868wes.39 for ; Sat, 26 Oct 2013 10:34:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=fdupMNvNV7iNKDLsxaHz3zAnxb6jObrT7HjK718SNDE=; b=d+mIP9MBM4WF/zY/O4qDwmeytidrecibVw4EoS6XV5S2VbsuV5TFZiXK7EkHaRJyw/ /F7ldC6a02/uZlA9HoeEkyarPZ7o5r/kVE4GtMMr8j3gNpy8WduvbMOVRse7M/bge96k mvF1Ekyp8ICi2wOPoa++KiJ7gUpBSsS9tKkzknENrSN6FtUcWTu6sTx83rgfJgwJMNie FpbfPSBUc7k2ZaYGdua+YKOrdWN1exXhBspa//+5ovlZFcjgQXBCcnqGZ62qiXYtZ0fj Sl/kCaHL/b2/i9WdMI2OmWN0mKVUTX29Ag9h752GNHA7W0fRGUxQcLdKcL3aoH2amycK FvaA== MIME-Version: 1.0 X-Received: by 10.194.185.73 with SMTP id fa9mr12001667wjc.29.1382808890912; Sat, 26 Oct 2013 10:34:50 -0700 (PDT) Sender: zbodek@gmail.com Received: by 10.216.209.194 with HTTP; Sat, 26 Oct 2013 10:34:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 26 Oct 2013 19:34:50 +0200 X-Google-Sender-Auth: V__ooUaHA_RSj98gAGL-i6AVcTA Message-ID: Subject: Re: Changes to UART ns8250 From: Zbigniew Bodek To: "freebsd-embedded@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-arm@freebsd.org" , freebsd-current X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 17:34:53 -0000 Hello again. I've just committed the patch: http://svnweb.freebsd.org/base?view=revision&revision=257170 Thanks and best regards Zbigniew Bodek 2013/10/26 Zbigniew Bodek : > Hello Everyone, > > I'm attaching the newest version of the ns8250 UART patch. > After some discussions I decided to go with busy-wait + timeout solution. > The applied delay should handle exotic corner cases (please notice > that we can't use ns8250_delay() > to get the actual single transmission time since we know that LCR is locked). > > If there are no objections then I would like to commit this soon. > > Best regards > Zbigniew Bodek > > 2013/10/9 Zbigniew Bodek : >> Hello Ganbold. >> >> Thank you for testing the patch and pointing those issue out. >> My detection log from Armada XP: >> >> uart0: <16550 or compatible> mem 0xd0012000-0xd001201f irq 41 on simplebus0 >> uart0: console (115200,n,8,1) >> uart1: <16550 or compatible> mem 0xd0012100-0xd001211f irq 42 on simplebus0 >> uart2: <16550 or compatible> mem 0xd0012200-0xd001221f irq 43 on simplebus0 >> uart3: <16550 or compatible> mem 0xd0012300-0xd001231f irq 44 on simplebus0 >> >> Is there a possibility to download a datasheet for RK30xx so that I could >> verify what is required for it's UART? >> The patch is causing that we only wait until UART is not busy anymore. I >> can't find why would that cause problems >> if your UART requires busy detection anyway. >> >> Best regards >> Zbigniew Bodek >> >> >> >> 2013/10/9 Ganbold Tsagaankhuu >>> >>> >>> >>> >>> On Tue, Oct 8, 2013 at 9:58 AM, Ganbold Tsagaankhuu >>> wrote: >>>> >>>> Zbigniew, >>>> >>>> >>>> On Tue, Oct 8, 2013 at 3:54 AM, Zbigniew Bodek wrote: >>>>> >>>>> Hello. >>>>> >>>>> I would like to present a patch for ns8250 serial that I would like to >>>>> commit in the near future (if there are no objections). >>>>> >>>>> The patch is fixing newest DesignWare UART with busy detection. >>>>> During frequency divisors configuration when UART is busy transferring >>>>> or >>>>> receiving data, line control register manipulation will not take effect. >>>>> Therefore, we will not set divisor latch access bit and we will corrupt >>>>> LCR >>>>> instead of configuring divisors. >>>>> It is necessary to wait until UART finishes all transfers to proceed >>>>> with >>>>> the configuration. >>>>> >>>>> This was detected on Armada XP as UART fails on this issue 100/100 >>>>> attempts. >>>>> The patch was tested by kevlo@ and me and it works on our Armada XP - >>>>> based >>>>> systems. >>>>> >>>>> Please send your comment or remarks if there are any. >>>> >>>> >>>> I'm trying your patch on r254983. >>>> Tried on 2 boards (Cubieboard2 (Allwinner A20 SoC - dual Cortex A7) and >>>> Radxa Rock (Rockchip RK3188 - Quad Cortex A9)). Both seem to have some sort >>>> of DesignWare uart. >>>> >>>> 1. It works fine on Cubieboard2. Uart dmesg is like: >>>> >>>> uart0: <16750 or compatible> mem 0x1c28000-0x1c283ff irq 33 on simplebus0 >>>> uart0: console (115200,n,8,1) >>>> >>>> 2. No any printing on screen in case of Radxa Rock. Without your patch >>>> uart dmesg is like: >>>> >>>> uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on >>>> simplebus0 >>>> uart0: console (115200,n,8,1) >>>> >>>> In case of RK3188 SoC, it seems booting FreeBSD kernel seems very >>>> fragile, not sure yet what is causing the problem. >>>> Even with stock ns8250 some version later than r254983 didn't show/print >>>> anything on serial console few days ago. >>>> Only thing so far I know is this r254983 (with some patch) works in my >>>> case on RK3188 SoC based board. >>> >>> >>> >>> Zbigniew, >>> >>> Just tried again your patch on RK30xx board. I was able to see boot >>> messages on screen. >>> This uart detected as: >>> ... >>> uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on >>> simplebus0 >>> uart0: console (115200,n,8,1) >>> uart0: fast interrupt >>> ... >>> Can you show me your uart detection log? >>> It seems this DW uart of RK30xx is different than DW uart of A10/A20. >>> Boot simply stops printing "start_init: trying /sbin/init". >>> >>> thanks, >>> >>> Ganbold >>> >>> >>>> >>>> >>>> thanks, >>>> >>>> Ganbold >>>> >>>> >>>> >>>>> >>>>> >>>>> Best regards >>>>> Zbigniew Bodek >>>>> >>>>> _______________________________________________ >>>>> freebsd-current@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>> To unsubscribe, send any mail to >>>>> "freebsd-current-unsubscribe@freebsd.org" >>>> >>>> >>> >> From owner-freebsd-arm@FreeBSD.ORG Sat Oct 26 19:39:54 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 ESMTP id 4630BDB9 for ; Sat, 26 Oct 2013 19:39:54 +0000 (UTC) (envelope-from info@serv4.energyefficency-dr.biz) Received: from serv4.energyefficency-dr.biz (unknown [IPv6:2001:1b40:5600:900:4321:1234:2483:b0e2]) by mx1.freebsd.org (Postfix) with ESMTP id C84BF2F0B for ; Sat, 26 Oct 2013 19:39:53 +0000 (UTC) Received: from 12-132-34-174.10d.protectedgroup.com (75-1-102-116.lightspeed.snantx.sbcglobal.net [75.1.102.116]) by serv4.energyefficency-dr.biz (Postfix) with ESMTPA id 1870063E16C8 for ; Sat, 26 Oct 2013 23:37:34 +0400 (MSD) From: "Dennis Roberts" Subject: Solar Windows Webinar - US AIR FORCE APPROVED - See thru radiant barrier To: "arm" MIME-Version: 1.0 Organization: http://www.inflectorglobal.com Date: Sat, 26 Oct 2013 14:39:41 -0500 Message-Id: <20131026193954.4630BDB9@hub.freebsd.org> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Oct 2013 19:39:54 -0000 =EF=BB=BFA Billion Dollar Company just joined us from the middle east = - droberts43@sbcglobal.net What is an Inflector Window Insulator? http://www.youtube.com/watch?v=3D= 21DiKS5mt4k =20 =20 Energy Efficiency Done Right presents information on the In'Flector Se= e Through Radiant Barrier Window and Skylight Insulator and the Energy= Efficiency Industry. We will examine the growth of the energy efficie= ncy, conservation, energy independence, and carbon emmission industrie= s and explain opportunities to represent or purchase our Insulator pro= ducts. Register for a session now by clicking a date below: Date:Tuesday, November 19, 2013 Time:10:00 AM - 11:00 AM CST https://www1.gotomeeting.com/register/167965728 Date:Tuesday, November 19, 2013 Time:8:00 PM - 9:00 PM CST https://www1.gotomeeting.com/register/601053328 =20 Once registered you will receive an email confirming your registration= with information you need to join the Webinar. =20 Unsubscribe by email Keith Roberts 10854 Lake Path San Antonio, TX 78217 Inflector Window Insulators - See Thru Radiant Barrier droberts43@sbcglobal.net This is an advetisement for a webinar!