From owner-freebsd-arm@FreeBSD.ORG Sun Oct 26 00:05:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CC871EEA for ; Sun, 26 Oct 2014 00:05:18 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtpout002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9EF73CB6 for ; Sun, 26 Oct 2014 00:05:18 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NE000B9DYWLXF50@st11p02mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Sun, 26 Oct 2014 00:05:11 +0000 (GMT) Content-type: text/plain; charset=iso-8859-1 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: PRU on BBB From: Rui Paulo In-reply-to: <20141025224829.GC34989@cicely7.cicely.de> Date: Sat, 25 Oct 2014 17:05:08 -0700 Content-transfer-encoding: quoted-printable Message-id: <78C2D5E5-DEFB-46BA-8874-B137D6E1E00C@me.com> References: <544BA593.4020706@freenet.de> <5E3FBBA8-2CBB-4BCE-BE2C-FB044CF0BEF6@me.com> <20141025224829.GC34989@cicely7.cicely.de> To: ticso@cicely.de X-Mailer: Apple Mail (2.1990.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-25_03:2014-10-24,2014-10-25,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=1 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410250260 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 00:05:18 -0000 On Oct 25, 2014, at 15:48, Bernd Walter wrote: >=20 > On Sat, Oct 25, 2014 at 09:32:09AM -0700, Rui Paulo wrote: >> On Oct 25, 2014, at 06:28, Manuel St=FChn = wrote: >>>=20 >>> Hello list, >>>=20 >>> I'm a great fan of FreeBSD and was very glad to see, that FreeBSD = supports the beaglebone black. Even the PRUs, which I want to put into = operation, are supported by FreeBSD. But unfortunately i do not have a = clue, how the driver is intended to be used. For linux there is some = API/docu to load/start/stop and communicate with the PRU. >>>=20 >>> Did anyone put the PRUs already into operation with FreeBSD and = could give me a hint how this is done? >>=20 >> There's a work in progress PRU library: >>=20 >> https://bitbucket.org/rpaulo/libpru >>=20 >> And a program to upload binaries to the PRU: >>=20 >> https://bitbucket.org/rpaulo/pructl >>=20 >> These don't have documentation yet and you have to build them = yourself, but that should be straightforward. >>=20 >> You can use the assembler from ports: devel/pasm. >=20 > We have PRU supprt? > That's awesome. > Had been interested in PRU, but not even dreamed about existing = support. The library and the userland utility are both under active development. = I expect to have something stable before the year ends. Right now, I = can upload/reset/enable/disable the PRUs just fine. A PRU debugger is also in the works. Regards, -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sun Oct 26 03:13:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3890B7D7 for ; Sun, 26 Oct 2014 03:13:51 +0000 (UTC) Received: from mail-yh0-f50.google.com (mail-yh0-f50.google.com [209.85.213.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E61F0EF8 for ; Sun, 26 Oct 2014 03:13:50 +0000 (UTC) Received: by mail-yh0-f50.google.com with SMTP id a41so3179229yho.9 for ; Sat, 25 Oct 2014 20:13:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=hkVN1f5SGleIeh2YTnbjtPNJ+tzISgAb0jfz/lSkPz8=; b=L7+rTVl46GaORGp8lmDD7ILVY9X3SI/y2s4lNJ4t8rK14FcS1UbAuzdHUKvxjgXUQD mwt0znik3o/h4IBYTK/uUGh6WtGWGVL5weWHy02+k+iFoDwuKM96cof6zUzflikbP8jv KuHCX+3ROZzAJt+VVXq5Pf5DNEdSxyjR/IgXeZCIPxNGNbv+kEdcIAnD+mnZfi/OyxJy /o8E+jUt2K1/tMBC5e4TAeyeh4i6lvhOxtFRzZkOEMijMcKbFXgnrpXh1ot+Z8IKrJ1T BLybyqgsDcC4NbDZJ61rWM6clAuuCMYqjW9R6NBv0S2fBweNp7A1YGyrUpeY63XkjJdr Ev0g== X-Gm-Message-State: ALoCoQn4DbjIF59rlZAXtMWxL9jVJxhsV657xvD/iDagfXAM7vsCD6pbLr+yCRZNml6fpDWEUtDk X-Received: by 10.170.214.6 with SMTP id g6mr16914112ykf.34.1414293224629; Sat, 25 Oct 2014 20:13:44 -0700 (PDT) Received: from [192.168.0.14] (173-18-133-79.client.mchsi.com. [173.18.133.79]) by mx.google.com with ESMTPSA id v31sm4106840yha.16.2014.10.25.20.13.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 25 Oct 2014 20:13:44 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_61192D1A-4AFE-426B-8CAB-478BB7835D9B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: errors building xdev From: Warner Losh In-Reply-To: <1414277012.12052.655.camel@revolution.hippie.lan> Date: Sat, 25 Oct 2014 22:13:42 -0500 Message-Id: References: <20141024180208.cpn2v4gvqwms8osw@webmail.FoxValley.net> <544B4B1F.1000103@foxvalley.net> <25CA6A51-3697-4FE6-9941-A28821D681C0@bsdimp.com> <1414277012.12052.655.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: Dan Raymond , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 03:13:51 -0000 --Apple-Mail=_61192D1A-4AFE-426B-8CAB-478BB7835D9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 25, 2014, at 5:43 PM, Ian Lepore wrote: > On Sat, 2014-10-25 at 17:29 -0500, Warner Losh wrote: >> On Oct 25, 2014, at 2:02 AM, Dan Raymond = wrote: >>=20 >>>=20 >>>>> cd /usr/src/include/../sys/dev/acpica; sh = /usr/src/tools/install.sh -C -o root -g wheel -m 444 acpiio.h = //usr/armv6-freebsd/usr/include/dev/acpica >>>>> sh /usr/src/tools/install.sh -C -o root -g wheel -m 444 = acpi_hpet.h //usr/armv6-freebsd/usr/include/dev/acpica >>>>> install: acpi_hpet.h: No such file or directory >>>>> *** Error code 71 >>>> My bad. This is fixed already. Please update! >>>=20 >>> Thanks, Rui. It works now. Do you know if it was intentional that = we also need to make "xdev-links" now (for crochet)? >>=20 >> It was intentional. Honestly, I hope the various efforts to make = crochet use a well-maintained port/package for this bear fruit since the = direction xdev is going in the tree is towards shrinking what it does, = leaving only the libraries and includes and renaming the target to = sysroot or xsysroot. >>=20 >> Warner >>=20 >>=20 >=20 > Yeah, but breaking it before such a port is available seems a bit = rude. I haven=92t broken it, though I did refine the API for Sean Bruno=92s = cross build work, which wound up breaking crochet. I think he=92s gone = in a bit of a different direction, so maybe I can put the xdev-links = back into things such that crochet works in the interim. Warner --Apple-Mail=_61192D1A-4AFE-426B-8CAB-478BB7835D9B 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUTGbmAAoJEGwc0Sh9sBEAVOkQAOsjOIrIXgxeP5iq85LkMc1Q QOKsm5Up/6+B2E5KEY2LKWBQkF/ASNuZZKDd4PStSZP4eeNJRZMuSlVCIbvaqX7I auuZec/15P+TgINHU4uirk5Tw+UHTccTDyH2ANTbbgkjmOddTepOtcY/JXDben48 hOyona+6SrJL5C3XfaguCR6GrAu7Fdl3QN6ANLN7qJsZ2k2r9sk57aK5HQ8io5pP quLr8jbwofC62tZf77F4ssjPilx1rpgL5ax0DinpRhtpcAodKl/3ceN8LaE7ce7x w2EhwgRmOpOt2TDsZJV7fYsVzdeO4fA7K8d85jydUFQORHakU4t1WxDd4ZOyuauC sQAgZGVvKdN/FKYoAZqebFHR5jog14N4oxCygAlc0wSblPrfE5D0lVGYXL10++Sj 23Jj4rPlqCdNkRtCQIgoovgucXH8BtOGb7vSJD8jhlKriL8QRqzc3SUMsHhyQl1m PMpkoFecIqjUtV/Rq5kJ5f1b1J5J++vVhXpp9MVzaPetobYDCiMGFGwOazCmr7FA oMuASyg5ahOwYM1OM4Np78RsizclVIQIO9AVagu+PTHjYrM0GTGNn3fBk8nJCvuW ewtVyEiEqUQoTlRf12aA+ioyW8eimm82gV35ty922TYvUVpDg0Pl+xW4rMHVjJZf wuPQmES+zAs+tuk1Pmhs =ocB2 -----END PGP SIGNATURE----- --Apple-Mail=_61192D1A-4AFE-426B-8CAB-478BB7835D9B-- From owner-freebsd-arm@FreeBSD.ORG Sun Oct 26 07:57:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C44495C; Sun, 26 Oct 2014 07:57:28 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B3631955; Sun, 26 Oct 2014 07:57:27 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s9Q7vKBQ044691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 26 Oct 2014 09:57:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s9Q7vKBQ044691 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s9Q7vKIi044690; Sun, 26 Oct 2014 09:57:20 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 26 Oct 2014 09:57:20 +0200 From: Konstantin Belousov To: Rick Macklem Subject: Re: panic in nfs on arm Message-ID: <20141026075720.GO1877@kib.kiev.ua> References: <1388627434.7506173.1414279273153.JavaMail.root@uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1388627434.7506173.1414279273153.JavaMail.root@uoguelph.ca> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: Ronald Klop , freebsd-fs@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 07:57:28 -0000 On Sat, Oct 25, 2014 at 07:21:13PM -0400, Rick Macklem wrote: > Ronald Klop wrote: > > Hi, > > > > I got a panic on my arm computer while building a port with > > /usr/ports > > mounted from my FreeBSD-10-STABLE/amd64 machine. > > > > This is the machine which paniced: > > FreeBSD 11.0-CURRENT #1 r272028M: Tue Sep 23 17:11:45 CEST 2014 > > root@sjakie.klop.ws:/usr/obj-arm/arm.arm/usr/src-arm/sys/SHEEVAPLUG > > arm > > > > > > Tracing pid 90295 tid 100119 td 0xc5f8c960 > > db_trace_self() at db_trace_self > > pc = 0xc0bb12c8 lr = 0xc0bb1354 (db_trace_thread+0x50) > > sp = 0xdf29e5d0 fp = 0xc3e07120 > > db_trace_thread() at db_trace_thread+0x50 > > pc = 0xc0bb1354 lr = 0xc0936314 (db_command_init+0x5a4) > > sp = 0xdf29e630 fp = 0xc3e07120 > > db_command_init() at db_command_init+0x5a4 > > pc = 0xc0936314 lr = 0xc0935ad0 (db_skip_to_eol+0x484) > > sp = 0xdf29e648 fp = 0xc3e07120 > > r4 = 0xc0c8d350 r5 = 0x00000000 > > db_skip_to_eol() at db_skip_to_eol+0x484 > > pc = 0xc0935ad0 lr = 0xc0935c38 (db_command_loop+0x5c) > > sp = 0xdf29e6e8 fp = 0xc3e07120 > > r4 = 0xdf29e6fc r5 = 0xc0c8d64c > > r6 = 0x3cd90e75 r7 = 0x00000000 > > r8 = 0x00000001 r10 = 0x600000d3 > > db_command_loop() at db_command_loop+0x5c > > pc = 0xc0935c38 lr = 0xc0937f80 (X_db_sym_numargs+0xec) > > sp = 0xdf29e6f0 fp = 0xc3e07120 > > X_db_sym_numargs() at X_db_sym_numargs+0xec > > pc = 0xc0937f80 lr = 0xc0a6f0c0 (kdb_trap+0x94) > > sp = 0xdf29e808 fp = 0xc3e07120 > > r4 = 0xdf29e8f8 > > kdb_trap() at kdb_trap+0x94 > > pc = 0xc0a6f0c0 lr = 0xc0bc1d60 (badaddr_read+0x274) > > sp = 0xdf29e828 fp = 0xc3e07120 > > r4 = 0xdf29e8f8 r5 = 0x00000001 > > r6 = 0x3cd90e75 r7 = 0xc5f8c960 > > r8 = 0xdf29e8f8 r10 = 0xdf2a1eb0 > > badaddr_read() at badaddr_read+0x274 > > pc = 0xc0bc1d60 lr = 0xc0bc1e98 (badaddr_read+0x3ac) > > sp = 0xdf29e840 fp = 0xc3e07120 > > r4 = 0xc5f8c960 r5 = 0xdf29e8f8 > > r6 = 0x3cd90e05 > > badaddr_read() at badaddr_read+0x3ac > > pc = 0xc0bc1e98 lr = 0xc0bc2278 (data_abort_handler+0x10c) > > sp = 0xdf29e858 fp = 0xc3e07120 > > r4 = 0xc0cd8af8 r5 = 0xffff1004 > > data_abort_handler() at data_abort_handler+0x10c > > pc = 0xc0bc2278 lr = 0xc0bb2f40 (exception_exit) > > sp = 0xdf29e8f8 fp = 0xc3e07120 > > r4 = 0xffffffff r5 = 0xffff1004 > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 > > r8 = 0x0000000f r9 = 0x00000101 > > r10 = 0x0000001d > > exception_exit() at exception_exit > > pc = 0xc0bb2f40 lr = 0xc0b8daf8 (uma_reclaim+0x1f8) > > sp = 0xdf29e948 fp = 0xc3e07120 > > r0 = 0xba9b9127 r1 = 0x8b3de5fb > > r2 = 0xc61c1fc8 r3 = 0xba9b9126 > > r4 = 0x00000000 r5 = 0xc61c1fc8 > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 > > r8 = 0x0000000f r9 = 0x00000101 > > r10 = 0x0000001d r12 = 0x00000000 > > uma_reclaim() at uma_reclaim+0x24c > This looks to me like a crash in uma_reclaim() and I find UMA > way too obscure to understand. > > I have no idea if it might be related, but alc@ put a fix for low > memory situations in r272071 (or maybe it's r272221?). > > Might be worth trying a slightly newer kernel to see if the > problem still occurs. > > And hopefully someone more conversant with UMA (or this stack > trace) can help more. > > rick > > > pc = 0xc0b8db4c lr = 0xc0b8c800 (uma_zalloc_arg+0x2f0) > > sp = 0xdf29e978 fp = 0xdf29ec10 > > r4 = 0xc3e071d8 r5 = 0xc0e0ea00 > > r6 = 0xc3e07120 r7 = 0x00000000 > > r8 = 0x00000102 r9 = 0xdf29ecf8 > > r10 = 0xc61c0760 > > uma_zalloc_arg() at uma_zalloc_arg+0x2f0 uma_reclaim() is not called from uma_zalloc(). I think there is some issue with ddb on arm, which means that the backtrace is not useful. See below for one more. > > pc = 0xc0b8c800 lr = 0xc09e1df0 (nfscl_nget+0x308) > > sp = 0xdf29e990 fp = 0xdf29ec10 > > r4 = 0x9bb9fa43 r5 = 0x00000000 > > r6 = 0xc550dce8 r7 = 0xc3edaa00 > > r8 = 0xc3ebbac0 > > nfscl_nget() at nfscl_nget+0x308 > > pc = 0xc09e1df0 lr = 0xc09da69c (ncl_readlinkrpc+0xf60) > > sp = 0xdf29e9d8 fp = 0xdf29ea10 > > r4 = 0xc550dce8 r5 = 0x00000000 > > r6 = 0xc550dcf8 r7 = 0xdf29ecf8 > > r8 = 0xdf29ec6c r9 = 0x00000000 > > r10 = 0xdf29ed28 > > ncl_readlinkrpc() at ncl_readlinkrpc+0xf60 > > pc = 0xc09da69c lr = 0xc0bdae44 (VOP_MKDIR_APV+0x94) > > sp = 0xdf29ec40 fp = 0xbffff620 > > r4 = 0xc0c95c68 r5 = 0xdf29ec6c > > r6 = 0x00000001 r7 = 0x00020284 > > r8 = 0xffffff9c r9 = 0x00200800 > > r10 = 0xc5f8c960 > > VOP_MKDIR_APV() at VOP_MKDIR_APV+0x94 I do not see how VOP_MKDIR() may end up calling ncl_readlinkrpc(), esp. without intervening frame. > > pc = 0xc0bdae44 lr = 0xc0aca614 (kern_mkdirat+0x18c) > > sp = 0xdf29ec50 fp = 0xbffff620 > > r4 = 0xdf29ed28 r5 = 0xdf29ec90 > > r6 = 0x00000000 > > kern_mkdirat() at kern_mkdirat+0x18c > > pc = 0xc0aca614 lr = 0xc0aca684 (kern_mkdir+0x24) > > sp = 0xdf29ede0 fp = 0xbffff620 > > r4 = 0x00020290 r5 = 0xc5f8c960 > > r6 = 0x00000000 r7 = 0xc5f7f000 > > r8 = 0x00000000 r10 = 0x00013640 > > kern_mkdir() at kern_mkdir+0x24 > > pc = 0xc0aca684 lr = 0xc0aca6a8 (sys_mkdir+0x1c) > > sp = 0xdf29edf0 fp = 0xbffff620 > > sys_mkdir() at sys_mkdir+0x1c > > pc = 0xc0aca6a8 lr = 0xc0bc2884 (swi_handler+0x254) > > sp = 0xdf29edf8 fp = 0xbffff620 > > swi_handler() at swi_handler+0x254 > > pc = 0xc0bc2884 lr = 0xc0bb2ed0 (swi_exit) > > sp = 0xdf29ee60 fp = 0xbffff620 > > r4 = 0x00020290 r5 = 0x2085e8e0 > > r6 = 0x00020284 r7 = 0x00000088 > > r8 = 0x00000001 > > swi_exit() at swi_exit > > pc = 0xc0bb2ed0 lr = 0xc0bb2ed0 (swi_exit) > > sp = 0xdf29ee60 fp = 0xbffff620 > > Unable to unwind further > > > > > > Unfortunately dumping the kernel core also paniced. > > db> dump > > Physical memory: 507 MB > > Dumping 74 MB: 71 67 63 > > vm_fault(0xc4147000, 0, 1, 0) -> 0 > > Fatal kernel mode data abort: 'Translation Fault (P)' > > trapframe: 0xdf29e0b8 > > FSR=00000017, FAR=00000014, spsr=a00000d3 > > r0 =c0cd0f40, r1 =00000000, r2 =c5f8c960, r3 =00000004 > > r4 =00000000, r5 =00000000, r6 =00000000, r7 =c3ead01c > > r8 =c3ead000, r9 =c3e9e88c, r10=00000000, r11=0000000a > > r12=600000d3, ssp=df29e108, slr=c0bb4e24, pc =c0a7d060 > > > > panic: Fatal abort > > Uptime: 3d18h30m32s > > Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Oct 26 12:00:32 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3467942; Sun, 26 Oct 2014 12:00:31 +0000 (UTC) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7E1F4EBE; Sun, 26 Oct 2014 12:00:30 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0EAF3hTFSDaFve/2dsb2JhbABcg2JYBIMCyWUKhnlUAoEaAX2EAgEBAQMBAQEBIAQnIAsbDgoCAg0ZAikBCSYGCAcEARwEiBcJDbNMlAYBAQEBAQEEAQEBAQEBARuBLI8LAQEbNAeCd4FUBZZPhA6EcZRBhBQhLweBCDmBAwEBAQ X-IronPort-AV: E=Sophos;i="5.04,790,1406606400"; d="scan'208";a="163555615" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Oct 2014 08:00:29 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 6108EB413D; Sun, 26 Oct 2014 08:00:29 -0400 (EDT) Date: Sun, 26 Oct 2014 08:00:29 -0400 (EDT) From: Rick Macklem To: Konstantin Belousov Message-ID: <1340373913.7617662.1414324829387.JavaMail.root@uoguelph.ca> In-Reply-To: <20141026075720.GO1877@kib.kiev.ua> Subject: Re: panic in nfs on arm MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.209] X-Mailer: Zimbra 7.2.6_GA_2926 (ZimbraWebClient - FF3.0 (Win)/7.2.6_GA_2926) Cc: Ronald Klop , freebsd-fs@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 12:00:32 -0000 Kostik wrote: > On Sat, Oct 25, 2014 at 07:21:13PM -0400, Rick Macklem wrote: > > Ronald Klop wrote: > > > Hi, > > > > > > I got a panic on my arm computer while building a port with > > > /usr/ports > > > mounted from my FreeBSD-10-STABLE/amd64 machine. > > > > > > This is the machine which paniced: > > > FreeBSD 11.0-CURRENT #1 r272028M: Tue Sep 23 17:11:45 CEST 2014 > > > root@sjakie.klop.ws:/usr/obj-arm/arm.arm/usr/src-arm/sys/SHEEVAPLUG > > > arm > > > > > > > > > Tracing pid 90295 tid 100119 td 0xc5f8c960 > > > db_trace_self() at db_trace_self > > > pc = 0xc0bb12c8 lr = 0xc0bb1354 (db_trace_thread+0x50) > > > sp = 0xdf29e5d0 fp = 0xc3e07120 > > > db_trace_thread() at db_trace_thread+0x50 > > > pc = 0xc0bb1354 lr = 0xc0936314 > > > (db_command_init+0x5a4) > > > sp = 0xdf29e630 fp = 0xc3e07120 > > > db_command_init() at db_command_init+0x5a4 > > > pc = 0xc0936314 lr = 0xc0935ad0 (db_skip_to_eol+0x484) > > > sp = 0xdf29e648 fp = 0xc3e07120 > > > r4 = 0xc0c8d350 r5 = 0x00000000 > > > db_skip_to_eol() at db_skip_to_eol+0x484 > > > pc = 0xc0935ad0 lr = 0xc0935c38 (db_command_loop+0x5c) > > > sp = 0xdf29e6e8 fp = 0xc3e07120 > > > r4 = 0xdf29e6fc r5 = 0xc0c8d64c > > > r6 = 0x3cd90e75 r7 = 0x00000000 > > > r8 = 0x00000001 r10 = 0x600000d3 > > > db_command_loop() at db_command_loop+0x5c > > > pc = 0xc0935c38 lr = 0xc0937f80 > > > (X_db_sym_numargs+0xec) > > > sp = 0xdf29e6f0 fp = 0xc3e07120 > > > X_db_sym_numargs() at X_db_sym_numargs+0xec > > > pc = 0xc0937f80 lr = 0xc0a6f0c0 (kdb_trap+0x94) > > > sp = 0xdf29e808 fp = 0xc3e07120 > > > r4 = 0xdf29e8f8 > > > kdb_trap() at kdb_trap+0x94 > > > pc = 0xc0a6f0c0 lr = 0xc0bc1d60 (badaddr_read+0x274) > > > sp = 0xdf29e828 fp = 0xc3e07120 > > > r4 = 0xdf29e8f8 r5 = 0x00000001 > > > r6 = 0x3cd90e75 r7 = 0xc5f8c960 > > > r8 = 0xdf29e8f8 r10 = 0xdf2a1eb0 > > > badaddr_read() at badaddr_read+0x274 > > > pc = 0xc0bc1d60 lr = 0xc0bc1e98 (badaddr_read+0x3ac) > > > sp = 0xdf29e840 fp = 0xc3e07120 > > > r4 = 0xc5f8c960 r5 = 0xdf29e8f8 > > > r6 = 0x3cd90e05 > > > badaddr_read() at badaddr_read+0x3ac > > > pc = 0xc0bc1e98 lr = 0xc0bc2278 > > > (data_abort_handler+0x10c) > > > sp = 0xdf29e858 fp = 0xc3e07120 > > > r4 = 0xc0cd8af8 r5 = 0xffff1004 > > > data_abort_handler() at data_abort_handler+0x10c > > > pc = 0xc0bc2278 lr = 0xc0bb2f40 (exception_exit) > > > sp = 0xdf29e8f8 fp = 0xc3e07120 > > > r4 = 0xffffffff r5 = 0xffff1004 > > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 > > > r8 = 0x0000000f r9 = 0x00000101 > > > r10 = 0x0000001d > > > exception_exit() at exception_exit > > > pc = 0xc0bb2f40 lr = 0xc0b8daf8 (uma_reclaim+0x1f8) > > > sp = 0xdf29e948 fp = 0xc3e07120 > > > r0 = 0xba9b9127 r1 = 0x8b3de5fb > > > r2 = 0xc61c1fc8 r3 = 0xba9b9126 > > > r4 = 0x00000000 r5 = 0xc61c1fc8 > > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 > > > r8 = 0x0000000f r9 = 0x00000101 > > > r10 = 0x0000001d r12 = 0x00000000 > > > uma_reclaim() at uma_reclaim+0x24c > > This looks to me like a crash in uma_reclaim() and I find UMA > > way too obscure to understand. > > > > I have no idea if it might be related, but alc@ put a fix for low > > memory situations in r272071 (or maybe it's r272221?). > > > > Might be worth trying a slightly newer kernel to see if the > > problem still occurs. > > > > And hopefully someone more conversant with UMA (or this stack > > trace) can help more. > > > > rick > > > > > pc = 0xc0b8db4c lr = 0xc0b8c800 (uma_zalloc_arg+0x2f0) > > > sp = 0xdf29e978 fp = 0xdf29ec10 > > > r4 = 0xc3e071d8 r5 = 0xc0e0ea00 > > > r6 = 0xc3e07120 r7 = 0x00000000 > > > r8 = 0x00000102 r9 = 0xdf29ecf8 > > > r10 = 0xc61c0760 > > > uma_zalloc_arg() at uma_zalloc_arg+0x2f0 > uma_reclaim() is not called from uma_zalloc(). > I think there is some issue with ddb on arm, which means that > the backtrace is not useful. See below for one more. > Yea, I noticed that and the one below (ie. I knew the stack dump wasn't correct). I kinda hoped it was right w.r.t. the crash happening in uma_reclaim() { which only seems to be called from the pageout daemon? }, so that doesn't match up with the thread. Also, I couldn't see what the panic message actually was. Is it this one at the bottom: Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock or was that what happened when you tried to crash dump? Btw, nfscl_nget() does call uma_zalloc(M_WAITOK), but it doesn't hold a mutex when it does this. rick > > > pc = 0xc0b8c800 lr = 0xc09e1df0 (nfscl_nget+0x308) > > > sp = 0xdf29e990 fp = 0xdf29ec10 > > > r4 = 0x9bb9fa43 r5 = 0x00000000 > > > r6 = 0xc550dce8 r7 = 0xc3edaa00 > > > r8 = 0xc3ebbac0 > > > nfscl_nget() at nfscl_nget+0x308 > > > pc = 0xc09e1df0 lr = 0xc09da69c > > > (ncl_readlinkrpc+0xf60) > > > sp = 0xdf29e9d8 fp = 0xdf29ea10 > > > r4 = 0xc550dce8 r5 = 0x00000000 > > > r6 = 0xc550dcf8 r7 = 0xdf29ecf8 > > > r8 = 0xdf29ec6c r9 = 0x00000000 > > > r10 = 0xdf29ed28 > > > ncl_readlinkrpc() at ncl_readlinkrpc+0xf60 > > > pc = 0xc09da69c lr = 0xc0bdae44 (VOP_MKDIR_APV+0x94) > > > sp = 0xdf29ec40 fp = 0xbffff620 > > > r4 = 0xc0c95c68 r5 = 0xdf29ec6c > > > r6 = 0x00000001 r7 = 0x00020284 > > > r8 = 0xffffff9c r9 = 0x00200800 > > > r10 = 0xc5f8c960 > > > VOP_MKDIR_APV() at VOP_MKDIR_APV+0x94 > I do not see how VOP_MKDIR() may end up calling ncl_readlinkrpc(), > esp. without intervening frame. > > > > pc = 0xc0bdae44 lr = 0xc0aca614 (kern_mkdirat+0x18c) > > > sp = 0xdf29ec50 fp = 0xbffff620 > > > r4 = 0xdf29ed28 r5 = 0xdf29ec90 > > > r6 = 0x00000000 > > > kern_mkdirat() at kern_mkdirat+0x18c > > > pc = 0xc0aca614 lr = 0xc0aca684 (kern_mkdir+0x24) > > > sp = 0xdf29ede0 fp = 0xbffff620 > > > r4 = 0x00020290 r5 = 0xc5f8c960 > > > r6 = 0x00000000 r7 = 0xc5f7f000 > > > r8 = 0x00000000 r10 = 0x00013640 > > > kern_mkdir() at kern_mkdir+0x24 > > > pc = 0xc0aca684 lr = 0xc0aca6a8 (sys_mkdir+0x1c) > > > sp = 0xdf29edf0 fp = 0xbffff620 > > > sys_mkdir() at sys_mkdir+0x1c > > > pc = 0xc0aca6a8 lr = 0xc0bc2884 (swi_handler+0x254) > > > sp = 0xdf29edf8 fp = 0xbffff620 > > > swi_handler() at swi_handler+0x254 > > > pc = 0xc0bc2884 lr = 0xc0bb2ed0 (swi_exit) > > > sp = 0xdf29ee60 fp = 0xbffff620 > > > r4 = 0x00020290 r5 = 0x2085e8e0 > > > r6 = 0x00020284 r7 = 0x00000088 > > > r8 = 0x00000001 > > > swi_exit() at swi_exit > > > pc = 0xc0bb2ed0 lr = 0xc0bb2ed0 (swi_exit) > > > sp = 0xdf29ee60 fp = 0xbffff620 > > > Unable to unwind further > > > > > > > > > Unfortunately dumping the kernel core also paniced. > > > db> dump > > > Physical memory: 507 MB > > > Dumping 74 MB: 71 67 63 > > > vm_fault(0xc4147000, 0, 1, 0) -> 0 > > > Fatal kernel mode data abort: 'Translation Fault (P)' > > > trapframe: 0xdf29e0b8 > > > FSR=00000017, FAR=00000014, spsr=a00000d3 > > > r0 =c0cd0f40, r1 =00000000, r2 =c5f8c960, r3 =00000004 > > > r4 =00000000, r5 =00000000, r6 =00000000, r7 =c3ead01c > > > r8 =c3ead000, r9 =c3e9e88c, r10=00000000, r11=0000000a > > > r12=600000d3, ssp=df29e108, slr=c0bb4e24, pc =c0a7d060 > > > > > > panic: Fatal abort > > > Uptime: 3d18h30m32s > > > Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock > > > _______________________________________________ > > > freebsd-fs@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > > To unsubscribe, send any mail to > > > "freebsd-fs-unsubscribe@freebsd.org" > > > > > _______________________________________________ > > freebsd-fs@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > > To unsubscribe, send any mail to > > "freebsd-fs-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Sun Oct 26 12:12:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84663AB5; Sun, 26 Oct 2014 12:12:09 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4547880; Sun, 26 Oct 2014 12:12:08 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XiMfq-0004Js-AT; Sun, 26 Oct 2014 13:12:00 +0100 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: "Konstantin Belousov" , "Rick Macklem" Subject: Re: panic in nfs on arm References: <1340373913.7617662.1414324829387.JavaMail.root@uoguelph.ca> Date: Sun, 26 Oct 2014 13:11:53 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <1340373913.7617662.1414324829387.JavaMail.root@uoguelph.ca> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: bdb49c4ff80bd276e321aade33e76e02752072e2 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 503f1a2b1db20d3cc8283cfb339c155f Cc: freebsd-fs@freebsd.org, freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 12:12:09 -0000 On Sun, 26 Oct 2014 13:00:29 +0100, Rick Macklem wrote: > Kostik wrote: >> On Sat, Oct 25, 2014 at 07:21:13PM -0400, Rick Macklem wrote: >> > Ronald Klop wrote: >> > > Hi, >> > > >> > > I got a panic on my arm computer while building a port with >> > > /usr/ports >> > > mounted from my FreeBSD-10-STABLE/amd64 machine. >> > > >> > > This is the machine which paniced: >> > > FreeBSD 11.0-CURRENT #1 r272028M: Tue Sep 23 17:11:45 CEST 2014 >> > > root@sjakie.klop.ws:/usr/obj-arm/arm.arm/usr/src-arm/sys/SHEEVAPLUG >> > > arm >> > > >> > > >> > > Tracing pid 90295 tid 100119 td 0xc5f8c960 >> > > db_trace_self() at db_trace_self >> > > pc = 0xc0bb12c8 lr = 0xc0bb1354 (db_trace_thread+0x50) >> > > sp = 0xdf29e5d0 fp = 0xc3e07120 >> > > db_trace_thread() at db_trace_thread+0x50 >> > > pc = 0xc0bb1354 lr = 0xc0936314 >> > > (db_command_init+0x5a4) >> > > sp = 0xdf29e630 fp = 0xc3e07120 >> > > db_command_init() at db_command_init+0x5a4 >> > > pc = 0xc0936314 lr = 0xc0935ad0 (db_skip_to_eol+0x484) >> > > sp = 0xdf29e648 fp = 0xc3e07120 >> > > r4 = 0xc0c8d350 r5 = 0x00000000 >> > > db_skip_to_eol() at db_skip_to_eol+0x484 >> > > pc = 0xc0935ad0 lr = 0xc0935c38 (db_command_loop+0x5c) >> > > sp = 0xdf29e6e8 fp = 0xc3e07120 >> > > r4 = 0xdf29e6fc r5 = 0xc0c8d64c >> > > r6 = 0x3cd90e75 r7 = 0x00000000 >> > > r8 = 0x00000001 r10 = 0x600000d3 >> > > db_command_loop() at db_command_loop+0x5c >> > > pc = 0xc0935c38 lr = 0xc0937f80 >> > > (X_db_sym_numargs+0xec) >> > > sp = 0xdf29e6f0 fp = 0xc3e07120 >> > > X_db_sym_numargs() at X_db_sym_numargs+0xec >> > > pc = 0xc0937f80 lr = 0xc0a6f0c0 (kdb_trap+0x94) >> > > sp = 0xdf29e808 fp = 0xc3e07120 >> > > r4 = 0xdf29e8f8 >> > > kdb_trap() at kdb_trap+0x94 >> > > pc = 0xc0a6f0c0 lr = 0xc0bc1d60 (badaddr_read+0x274) >> > > sp = 0xdf29e828 fp = 0xc3e07120 >> > > r4 = 0xdf29e8f8 r5 = 0x00000001 >> > > r6 = 0x3cd90e75 r7 = 0xc5f8c960 >> > > r8 = 0xdf29e8f8 r10 = 0xdf2a1eb0 >> > > badaddr_read() at badaddr_read+0x274 >> > > pc = 0xc0bc1d60 lr = 0xc0bc1e98 (badaddr_read+0x3ac) >> > > sp = 0xdf29e840 fp = 0xc3e07120 >> > > r4 = 0xc5f8c960 r5 = 0xdf29e8f8 >> > > r6 = 0x3cd90e05 >> > > badaddr_read() at badaddr_read+0x3ac >> > > pc = 0xc0bc1e98 lr = 0xc0bc2278 >> > > (data_abort_handler+0x10c) >> > > sp = 0xdf29e858 fp = 0xc3e07120 >> > > r4 = 0xc0cd8af8 r5 = 0xffff1004 >> > > data_abort_handler() at data_abort_handler+0x10c >> > > pc = 0xc0bc2278 lr = 0xc0bb2f40 (exception_exit) >> > > sp = 0xdf29e8f8 fp = 0xc3e07120 >> > > r4 = 0xffffffff r5 = 0xffff1004 >> > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 >> > > r8 = 0x0000000f r9 = 0x00000101 >> > > r10 = 0x0000001d >> > > exception_exit() at exception_exit >> > > pc = 0xc0bb2f40 lr = 0xc0b8daf8 (uma_reclaim+0x1f8) >> > > sp = 0xdf29e948 fp = 0xc3e07120 >> > > r0 = 0xba9b9127 r1 = 0x8b3de5fb >> > > r2 = 0xc61c1fc8 r3 = 0xba9b9126 >> > > r4 = 0x00000000 r5 = 0xc61c1fc8 >> > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 >> > > r8 = 0x0000000f r9 = 0x00000101 >> > > r10 = 0x0000001d r12 = 0x00000000 >> > > uma_reclaim() at uma_reclaim+0x24c >> > This looks to me like a crash in uma_reclaim() and I find UMA >> > way too obscure to understand. >> > >> > I have no idea if it might be related, but alc@ put a fix for low >> > memory situations in r272071 (or maybe it's r272221?). >> > >> > Might be worth trying a slightly newer kernel to see if the >> > problem still occurs. >> > >> > And hopefully someone more conversant with UMA (or this stack >> > trace) can help more. >> > >> > rick >> > >> > > pc = 0xc0b8db4c lr = 0xc0b8c800 (uma_zalloc_arg+0x2f0) >> > > sp = 0xdf29e978 fp = 0xdf29ec10 >> > > r4 = 0xc3e071d8 r5 = 0xc0e0ea00 >> > > r6 = 0xc3e07120 r7 = 0x00000000 >> > > r8 = 0x00000102 r9 = 0xdf29ecf8 >> > > r10 = 0xc61c0760 >> > > uma_zalloc_arg() at uma_zalloc_arg+0x2f0 >> uma_reclaim() is not called from uma_zalloc(). >> I think there is some issue with ddb on arm, which means that >> the backtrace is not useful. See below for one more. >> > Yea, I noticed that and the one below (ie. I knew the stack dump > wasn't correct). I kinda hoped it was right w.r.t. the crash > happening in uma_reclaim() { which only seems to be called from > the pageout daemon? }, so that doesn't match up with the thread. > > Also, I couldn't see what the panic message actually was. Is it > this one at the bottom: > Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock > or was that what happened when you tried to crash dump? > > Btw, nfscl_nget() does call uma_zalloc(M_WAITOK), but it doesn't hold a > mutex > when it does this. > > rick Hi, The non-sleepable lock is not the original panic. That non-sleepable lock happened when I dumped the memory to dumpdev from the debugger. I don't have the original panic message. It was not on the serial output anymore. Is it possible to let the debugger print it again? I rebooted the machine already. Let's see if it happens again someday. Ronald. >> > > pc = 0xc0b8c800 lr = 0xc09e1df0 (nfscl_nget+0x308) >> > > sp = 0xdf29e990 fp = 0xdf29ec10 >> > > r4 = 0x9bb9fa43 r5 = 0x00000000 >> > > r6 = 0xc550dce8 r7 = 0xc3edaa00 >> > > r8 = 0xc3ebbac0 >> > > nfscl_nget() at nfscl_nget+0x308 >> > > pc = 0xc09e1df0 lr = 0xc09da69c >> > > (ncl_readlinkrpc+0xf60) >> > > sp = 0xdf29e9d8 fp = 0xdf29ea10 >> > > r4 = 0xc550dce8 r5 = 0x00000000 >> > > r6 = 0xc550dcf8 r7 = 0xdf29ecf8 >> > > r8 = 0xdf29ec6c r9 = 0x00000000 >> > > r10 = 0xdf29ed28 >> > > ncl_readlinkrpc() at ncl_readlinkrpc+0xf60 >> > > pc = 0xc09da69c lr = 0xc0bdae44 (VOP_MKDIR_APV+0x94) >> > > sp = 0xdf29ec40 fp = 0xbffff620 >> > > r4 = 0xc0c95c68 r5 = 0xdf29ec6c >> > > r6 = 0x00000001 r7 = 0x00020284 >> > > r8 = 0xffffff9c r9 = 0x00200800 >> > > r10 = 0xc5f8c960 >> > > VOP_MKDIR_APV() at VOP_MKDIR_APV+0x94 >> I do not see how VOP_MKDIR() may end up calling ncl_readlinkrpc(), >> esp. without intervening frame. >> >> > > pc = 0xc0bdae44 lr = 0xc0aca614 (kern_mkdirat+0x18c) >> > > sp = 0xdf29ec50 fp = 0xbffff620 >> > > r4 = 0xdf29ed28 r5 = 0xdf29ec90 >> > > r6 = 0x00000000 >> > > kern_mkdirat() at kern_mkdirat+0x18c >> > > pc = 0xc0aca614 lr = 0xc0aca684 (kern_mkdir+0x24) >> > > sp = 0xdf29ede0 fp = 0xbffff620 >> > > r4 = 0x00020290 r5 = 0xc5f8c960 >> > > r6 = 0x00000000 r7 = 0xc5f7f000 >> > > r8 = 0x00000000 r10 = 0x00013640 >> > > kern_mkdir() at kern_mkdir+0x24 >> > > pc = 0xc0aca684 lr = 0xc0aca6a8 (sys_mkdir+0x1c) >> > > sp = 0xdf29edf0 fp = 0xbffff620 >> > > sys_mkdir() at sys_mkdir+0x1c >> > > pc = 0xc0aca6a8 lr = 0xc0bc2884 (swi_handler+0x254) >> > > sp = 0xdf29edf8 fp = 0xbffff620 >> > > swi_handler() at swi_handler+0x254 >> > > pc = 0xc0bc2884 lr = 0xc0bb2ed0 (swi_exit) >> > > sp = 0xdf29ee60 fp = 0xbffff620 >> > > r4 = 0x00020290 r5 = 0x2085e8e0 >> > > r6 = 0x00020284 r7 = 0x00000088 >> > > r8 = 0x00000001 >> > > swi_exit() at swi_exit >> > > pc = 0xc0bb2ed0 lr = 0xc0bb2ed0 (swi_exit) >> > > sp = 0xdf29ee60 fp = 0xbffff620 >> > > Unable to unwind further >> > > >> > > >> > > Unfortunately dumping the kernel core also paniced. >> > > db> dump >> > > Physical memory: 507 MB >> > > Dumping 74 MB: 71 67 63 >> > > vm_fault(0xc4147000, 0, 1, 0) -> 0 >> > > Fatal kernel mode data abort: 'Translation Fault (P)' >> > > trapframe: 0xdf29e0b8 >> > > FSR=00000017, FAR=00000014, spsr=a00000d3 >> > > r0 =c0cd0f40, r1 =00000000, r2 =c5f8c960, r3 =00000004 >> > > r4 =00000000, r5 =00000000, r6 =00000000, r7 =c3ead01c >> > > r8 =c3ead000, r9 =c3e9e88c, r10=00000000, r11=0000000a >> > > r12=600000d3, ssp=df29e108, slr=c0bb4e24, pc =c0a7d060 >> > > >> > > panic: Fatal abort >> > > Uptime: 3d18h30m32s >> > > Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock >> > > _______________________________________________ >> > > freebsd-fs@freebsd.org mailing list >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> > > To unsubscribe, send any mail to >> > > "freebsd-fs-unsubscribe@freebsd.org" >> > > >> > _______________________________________________ >> > freebsd-fs@freebsd.org mailing list >> > http://lists.freebsd.org/mailman/listinfo/freebsd-fs >> > To unsubscribe, send any mail to >> > "freebsd-fs-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Oct 26 14:59:21 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 62A5CCA5; Sun, 26 Oct 2014 14:59:21 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 22BB1FD0; Sun, 26 Oct 2014 14:59:20 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XiPHr-0009z0-6u; Sun, 26 Oct 2014 14:59:19 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9QExHer074479; Sun, 26 Oct 2014 08:59:17 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19WVQ941P4koAD0Fz9/d8NS X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: panic in nfs on arm From: Ian Lepore To: Konstantin Belousov In-Reply-To: <20141026075720.GO1877@kib.kiev.ua> References: <1388627434.7506173.1414279273153.JavaMail.root@uoguelph.ca> <20141026075720.GO1877@kib.kiev.ua> Content-Type: text/plain; charset="us-ascii" Date: Sun, 26 Oct 2014 08:59:17 -0600 Message-ID: <1414335557.12052.672.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Ronald Klop , freebsd-fs@freebsd.org, freebsd-arm@freebsd.org, Rick Macklem X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 14:59:21 -0000 On Sun, 2014-10-26 at 09:57 +0200, Konstantin Belousov wrote: > On Sat, Oct 25, 2014 at 07:21:13PM -0400, Rick Macklem wrote: > > Ronald Klop wrote: > > > Hi, > > > > > > I got a panic on my arm computer while building a port with > > > /usr/ports > > > mounted from my FreeBSD-10-STABLE/amd64 machine. > > > > > > This is the machine which paniced: > > > FreeBSD 11.0-CURRENT #1 r272028M: Tue Sep 23 17:11:45 CEST 2014 > > > root@sjakie.klop.ws:/usr/obj-arm/arm.arm/usr/src-arm/sys/SHEEVAPLUG > > > arm > > > > > > > > > Tracing pid 90295 tid 100119 td 0xc5f8c960 > > > db_trace_self() at db_trace_self > > > pc = 0xc0bb12c8 lr = 0xc0bb1354 (db_trace_thread+0x50) > > > sp = 0xdf29e5d0 fp = 0xc3e07120 > > > db_trace_thread() at db_trace_thread+0x50 > > > pc = 0xc0bb1354 lr = 0xc0936314 (db_command_init+0x5a4) > > > sp = 0xdf29e630 fp = 0xc3e07120 > > > db_command_init() at db_command_init+0x5a4 > > > pc = 0xc0936314 lr = 0xc0935ad0 (db_skip_to_eol+0x484) > > > sp = 0xdf29e648 fp = 0xc3e07120 > > > r4 = 0xc0c8d350 r5 = 0x00000000 > > > db_skip_to_eol() at db_skip_to_eol+0x484 > > > pc = 0xc0935ad0 lr = 0xc0935c38 (db_command_loop+0x5c) > > > sp = 0xdf29e6e8 fp = 0xc3e07120 > > > r4 = 0xdf29e6fc r5 = 0xc0c8d64c > > > r6 = 0x3cd90e75 r7 = 0x00000000 > > > r8 = 0x00000001 r10 = 0x600000d3 > > > db_command_loop() at db_command_loop+0x5c > > > pc = 0xc0935c38 lr = 0xc0937f80 (X_db_sym_numargs+0xec) > > > sp = 0xdf29e6f0 fp = 0xc3e07120 > > > X_db_sym_numargs() at X_db_sym_numargs+0xec > > > pc = 0xc0937f80 lr = 0xc0a6f0c0 (kdb_trap+0x94) > > > sp = 0xdf29e808 fp = 0xc3e07120 > > > r4 = 0xdf29e8f8 > > > kdb_trap() at kdb_trap+0x94 > > > pc = 0xc0a6f0c0 lr = 0xc0bc1d60 (badaddr_read+0x274) > > > sp = 0xdf29e828 fp = 0xc3e07120 > > > r4 = 0xdf29e8f8 r5 = 0x00000001 > > > r6 = 0x3cd90e75 r7 = 0xc5f8c960 > > > r8 = 0xdf29e8f8 r10 = 0xdf2a1eb0 > > > badaddr_read() at badaddr_read+0x274 > > > pc = 0xc0bc1d60 lr = 0xc0bc1e98 (badaddr_read+0x3ac) > > > sp = 0xdf29e840 fp = 0xc3e07120 > > > r4 = 0xc5f8c960 r5 = 0xdf29e8f8 > > > r6 = 0x3cd90e05 > > > badaddr_read() at badaddr_read+0x3ac > > > pc = 0xc0bc1e98 lr = 0xc0bc2278 (data_abort_handler+0x10c) > > > sp = 0xdf29e858 fp = 0xc3e07120 > > > r4 = 0xc0cd8af8 r5 = 0xffff1004 > > > data_abort_handler() at data_abort_handler+0x10c > > > pc = 0xc0bc2278 lr = 0xc0bb2f40 (exception_exit) > > > sp = 0xdf29e8f8 fp = 0xc3e07120 > > > r4 = 0xffffffff r5 = 0xffff1004 > > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 > > > r8 = 0x0000000f r9 = 0x00000101 > > > r10 = 0x0000001d > > > exception_exit() at exception_exit > > > pc = 0xc0bb2f40 lr = 0xc0b8daf8 (uma_reclaim+0x1f8) > > > sp = 0xdf29e948 fp = 0xc3e07120 > > > r0 = 0xba9b9127 r1 = 0x8b3de5fb > > > r2 = 0xc61c1fc8 r3 = 0xba9b9126 > > > r4 = 0x00000000 r5 = 0xc61c1fc8 > > > r6 = 0x3cd90e05 r7 = 0xc0e0ea48 > > > r8 = 0x0000000f r9 = 0x00000101 > > > r10 = 0x0000001d r12 = 0x00000000 > > > uma_reclaim() at uma_reclaim+0x24c > > This looks to me like a crash in uma_reclaim() and I find UMA > > way too obscure to understand. > > > > I have no idea if it might be related, but alc@ put a fix for low > > memory situations in r272071 (or maybe it's r272221?). > > > > Might be worth trying a slightly newer kernel to see if the > > problem still occurs. > > > > And hopefully someone more conversant with UMA (or this stack > > trace) can help more. > > > > rick > > > > > pc = 0xc0b8db4c lr = 0xc0b8c800 (uma_zalloc_arg+0x2f0) > > > sp = 0xdf29e978 fp = 0xdf29ec10 > > > r4 = 0xc3e071d8 r5 = 0xc0e0ea00 > > > r6 = 0xc3e07120 r7 = 0x00000000 > > > r8 = 0x00000102 r9 = 0xdf29ecf8 > > > r10 = 0xc61c0760 > > > uma_zalloc_arg() at uma_zalloc_arg+0x2f0 > uma_reclaim() is not called from uma_zalloc(). > I think there is some issue with ddb on arm, which means that > the backtrace is not useful. See below for one more. > > > pc = 0xc0b8c800 lr = 0xc09e1df0 (nfscl_nget+0x308) > > > sp = 0xdf29e990 fp = 0xdf29ec10 > > > r4 = 0x9bb9fa43 r5 = 0x00000000 > > > r6 = 0xc550dce8 r7 = 0xc3edaa00 > > > r8 = 0xc3ebbac0 > > > nfscl_nget() at nfscl_nget+0x308 > > > pc = 0xc09e1df0 lr = 0xc09da69c (ncl_readlinkrpc+0xf60) > > > sp = 0xdf29e9d8 fp = 0xdf29ea10 > > > r4 = 0xc550dce8 r5 = 0x00000000 > > > r6 = 0xc550dcf8 r7 = 0xdf29ecf8 > > > r8 = 0xdf29ec6c r9 = 0x00000000 > > > r10 = 0xdf29ed28 > > > ncl_readlinkrpc() at ncl_readlinkrpc+0xf60 > > > pc = 0xc09da69c lr = 0xc0bdae44 (VOP_MKDIR_APV+0x94) > > > sp = 0xdf29ec40 fp = 0xbffff620 > > > r4 = 0xc0c95c68 r5 = 0xdf29ec6c > > > r6 = 0x00000001 r7 = 0x00020284 > > > r8 = 0xffffff9c r9 = 0x00200800 > > > r10 = 0xc5f8c960 > > > VOP_MKDIR_APV() at VOP_MKDIR_APV+0x94 > I do not see how VOP_MKDIR() may end up calling ncl_readlinkrpc(), > esp. without intervening frame. > Notice that the address is actually ncl_readlinkrpc+0xf60, 0xf60 is a pretty big offset into a function, it's probably in some static function that follows ncl_readlinkrpc in the source file but the symbol info has been stripped. Using addr2line on the pc and lr values will give reliable source line numbers (but I can't do that without Ronald's kernel config). -- Ian > > > pc = 0xc0bdae44 lr = 0xc0aca614 (kern_mkdirat+0x18c) > > > sp = 0xdf29ec50 fp = 0xbffff620 > > > r4 = 0xdf29ed28 r5 = 0xdf29ec90 > > > r6 = 0x00000000 > > > kern_mkdirat() at kern_mkdirat+0x18c > > > pc = 0xc0aca614 lr = 0xc0aca684 (kern_mkdir+0x24) > > > sp = 0xdf29ede0 fp = 0xbffff620 > > > r4 = 0x00020290 r5 = 0xc5f8c960 > > > r6 = 0x00000000 r7 = 0xc5f7f000 > > > r8 = 0x00000000 r10 = 0x00013640 > > > kern_mkdir() at kern_mkdir+0x24 > > > pc = 0xc0aca684 lr = 0xc0aca6a8 (sys_mkdir+0x1c) > > > sp = 0xdf29edf0 fp = 0xbffff620 > > > sys_mkdir() at sys_mkdir+0x1c > > > pc = 0xc0aca6a8 lr = 0xc0bc2884 (swi_handler+0x254) > > > sp = 0xdf29edf8 fp = 0xbffff620 > > > swi_handler() at swi_handler+0x254 > > > pc = 0xc0bc2884 lr = 0xc0bb2ed0 (swi_exit) > > > sp = 0xdf29ee60 fp = 0xbffff620 > > > r4 = 0x00020290 r5 = 0x2085e8e0 > > > r6 = 0x00020284 r7 = 0x00000088 > > > r8 = 0x00000001 > > > swi_exit() at swi_exit > > > pc = 0xc0bb2ed0 lr = 0xc0bb2ed0 (swi_exit) > > > sp = 0xdf29ee60 fp = 0xbffff620 > > > Unable to unwind further > > > > > > > > > Unfortunately dumping the kernel core also paniced. > > > db> dump > > > Physical memory: 507 MB > > > Dumping 74 MB: 71 67 63 > > > vm_fault(0xc4147000, 0, 1, 0) -> 0 > > > Fatal kernel mode data abort: 'Translation Fault (P)' > > > trapframe: 0xdf29e0b8 > > > FSR=00000017, FAR=00000014, spsr=a00000d3 > > > r0 =c0cd0f40, r1 =00000000, r2 =c5f8c960, r3 =00000004 > > > r4 =00000000, r5 =00000000, r6 =00000000, r7 =c3ead01c > > > r8 =c3ead000, r9 =c3e9e88c, r10=00000000, r11=0000000a > > > r12=600000d3, ssp=df29e108, slr=c0bb4e24, pc =c0a7d060 > > > > > > panic: Fatal abort > > > Uptime: 3d18h30m32s > > > Sleeping thread (tid 100119, pid 90295) owns a non-sleepable lock From owner-freebsd-arm@FreeBSD.ORG Sun Oct 26 20:55:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D2BCF12 for ; Sun, 26 Oct 2014 20:55:49 +0000 (UTC) Received: from mail-pd0-x233.google.com (mail-pd0-x233.google.com [IPv6:2607:f8b0:400e:c02::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 33B8666C for ; Sun, 26 Oct 2014 20:55:49 +0000 (UTC) Received: by mail-pd0-f179.google.com with SMTP id g10so4389608pdj.10 for ; Sun, 26 Oct 2014 13:55:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=gL3jFVowc8RBhwNaixmmL/cvD66NggOc7uzxooIQOqc=; b=N++bjvd7SKIFFd4cbB/ioQXcj45msjzIuzy0vSfs4C0jK5wGkjXCEjAbOSYYTDGasL QaD+xpM9sUfALCo41psuNU6/H3q8bEZbm9kdnjYBGbeJgoVsuuhCA2on+y9l2NzmrVvW n7Cck99KBhuSayq5M+mF2sEVLUsbyfvcK9TpLkL2nSxIAU/9t9ml8dNkFM3fibv96adn 3OBVGXqmmdCLCFubRZfw9ywJpGZTdKnZHIRULP3lc3Pjr9cmaAJmxFmvq3yMNMv3yHyd XfbkRIV+ilGZAsZuWW68rjtLG0KKVVlKJevIwRZ6JS9c6gQtG2Vlhy1jGcJi2ZkmDQXW I4/Q== X-Received: by 10.68.189.130 with SMTP id gi2mr4066689pbc.137.1414356948745; Sun, 26 Oct 2014 13:55:48 -0700 (PDT) Received: from [192.168.0.2] (c211-30-51-180.frank3.vic.optusnet.com.au. [211.30.51.180]) by mx.google.com with ESMTPSA id fv6sm9013181pdb.83.2014.10.26.13.55.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 Oct 2014 13:55:47 -0700 (PDT) From: Felix Friedlander Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: State of freebsd-arm Message-Id: Date: Mon, 27 Oct 2014 07:55:44 +1100 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Oct 2014 20:55:49 -0000 So I=E2=80=99ve recently seen ARM SD card images available for download = in the regular 10.1b3 download area. Are these is a useable state yet = (read: you can flash them to the SD card and boot)? I recall trying the = 10.1b1 release out and my RPi wouldn=E2=80=99t boot at all. Is = additional setup required? Sorry for such a noob question, but no-one seems to know about this that = I=E2=80=99ve asked. Felix Friedlander = From owner-freebsd-arm@FreeBSD.ORG Mon Oct 27 00:10:02 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1C1B7779 for ; Mon, 27 Oct 2014 00:10:02 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id C38219B4 for ; Mon, 27 Oct 2014 00:10:01 +0000 (UTC) Received: (qmail 1535 invoked from network) for freebsd-arm@freebsd.org; 26 Oct 2014 19:09:53 -0500 Received: from 174-29-196-237.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@174.29.196.237) by mail.foxvalley.net with SMTP; 26 Oct 2014 19:09:53 -0500 Message-ID: <544D8D53.5060100@foxvalley.net> Date: Sun, 26 Oct 2014 18:09:55 -0600 From: Dan Raymond User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org Subject: Re: new support for Raspberry Pi B+ Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 00:10:02 -0000 One small correction to my previous test results: with the 16GB Transcend card I *can* get it to boot reliably with the hw.bcm2835.sdhci.hs="0" hack. To summarize, I see no improvement regarding SD card failures between r271779 and r273702. Nor do I see any improvement between the previous commit to crochet and the current commit. I do see a minor regression: without the sdhci.hs hack I used to get 50% boot failures on my 16GB Transcend and now I get 100% boot failures. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 27 13:47:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 15C5BD37 for ; Mon, 27 Oct 2014 13:47:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F0BDC9BC for ; Mon, 27 Oct 2014 13:47:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9RDleK1072061 for ; Mon, 27 Oct 2014 13:47:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 154227] [geli] using GELI leads to panic on ARM Date: Mon, 27 Oct 2014 13:47:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: unspecified X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: kvedulv@kvedulv.de X-Bugzilla-Status: Issue Resolved X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 13:47:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=154227 kvedulv@kvedulv.de changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Issue Resolved Resolution|--- |FIXED --- Comment #2 from kvedulv@kvedulv.de --- I suppose that's fixed. closing. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 27 17:28:37 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8E18C67 for ; Mon, 27 Oct 2014 17:28:37 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFC847F6 for ; Mon, 27 Oct 2014 17:28:37 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9RHSbxr011757 for ; Mon, 27 Oct 2014 17:28:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194635] New: Speed optimisation for framebuffer console driver on Raspberry Pi Date: Mon, 27 Oct 2014 17:28:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: stefan.berndt@imoriath.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 17:28:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194635 Bug ID: 194635 Summary: Speed optimisation for framebuffer console driver on Raspberry Pi Product: Base System Version: 10.0-RELEASE Hardware: arm OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: stefan.berndt@imoriath.com Created attachment 148707 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148707&action=edit changes on /sys/arm/broadcom/bcm2835/bcm2835_fb.c Hi, I have done some speed optimisations on the Raspberry Pi's console driver. Please give this to the Raspberry Pi developers. Benchmarks (time taken to print and sroll 1 milion lines at 1440x900) : --Original FreeBSD driver-- 16 Bit per Pixel: 660 Secends 24 Bit per Pixel: 817 Secends 32 Bit per Pixel: 1086 Secends --My modifications-- 16 Bit per Pixel: 319 Secends 24 Bit per Pixel: 648 Secends 32 Bit per Pixel: 336 Secends I have tested (working) this resolutions, all BpP each : 640x480, 800x600, 1024x768, 1440x900 This is my first work on FreeBSD kernel, and i hope to fit all reqirements. Greetings Stefan Berndt -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Oct 27 20:59:32 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CE7DB20 for ; Mon, 27 Oct 2014 20:59:32 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 143AA1F5 for ; Mon, 27 Oct 2014 20:59:32 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9RKxVHL006507 for ; Mon, 27 Oct 2014 20:59:31 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194635] Speed optimisation for framebuffer console driver on Raspberry Pi Date: Mon, 27 Oct 2014 20:59:32 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: felixphew0@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Oct 2014 20:59:32 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194635 --- Comment #1 from Felix --- This seems to be pretty straightforward. Good job on your first patch, hope it gets approved! -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 28 01:06:07 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 51E0F561 for ; Tue, 28 Oct 2014 01:06:07 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38A5F1BB for ; Tue, 28 Oct 2014 01:06:07 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9S1675C031879 for ; Tue, 28 Oct 2014 01:06:07 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194635] Speed optimisation for framebuffer console driver on Raspberry Pi Date: Tue, 28 Oct 2014 01:06:07 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: rpaulo@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: priority bug_status cc bug_severity Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 01:06:07 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194635 Rui Paulo changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|--- |Normal Status|Needs Triage |Open CC| |rpaulo@FreeBSD.org Severity|Affects Only Me |Affects Many People --- Comment #2 from Rui Paulo --- Could you please upload a unified diff? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 28 05:25:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 59E918CF; Tue, 28 Oct 2014 05:25:45 +0000 (UTC) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A504F79; Tue, 28 Oct 2014 05:25:44 +0000 (UTC) Received: by mail-wg0-f44.google.com with SMTP id y10so7094673wgg.3 for ; Mon, 27 Oct 2014 22:25: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 :cc:content-type; bh=7NaODbzKAlXkDmwaNPW4fQCyQEJy5qH2KL6CLIjj2CA=; b=P7Rhf0G7wXju4uyFFDUjqfNZ4R+QSXWr6HyfAayS9iQZc01lH3xkMrAOZMmMH4q1gj /MnR+VOvr//6EVfdf0MI4z1qUHCrSLR5fofpMAfXBPcFgFn5m2nLTBjnFqjhOA2mhqr4 643n7xyqgrVUHcYaa2e5tUCrBGnnUNLkbjAJhu4sfZQFBxPzxaHH6PAueokFEVmR2mQw C1/C6SfPBmPTDI2dKdgxUjGOm9LgE4IPRDB9f2UZ0qIyojHODdnV2gf7l8xg1C/1G6pz PvUJ5YChlrAbu701ZYWdQh8B6TqJW1+CnJpAz9lOyeDKV7ckrnhBZWccKg9GMRdqh9Ji tM9Q== MIME-Version: 1.0 X-Received: by 10.180.109.17 with SMTP id ho17mr1875183wib.4.1414473942623; Mon, 27 Oct 2014 22:25:42 -0700 (PDT) Received: by 10.180.87.4 with HTTP; Mon, 27 Oct 2014 22:25:42 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Oct 2014 09:25:42 +0400 Message-ID: Subject: Fwd: Android Emulator for FreeBSD + FreeBSD/ARM port From: Alexander Tarasikov To: Gavin Atkinson Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-hackers@freebsd.org, "freebsd-arm@freebsd.org" , freebsd-emulation@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 05:25:45 -0000 Hi! I'm forwarding the message I sent directly to Gavin some time ago Also, I've pushed a small fix for the kernel compilation error and replaced a couple of __linux__ ifdefs with __FreeBSD__ in the emulator. I also think it is necessary to mount libprocfs even if using a FreeBSD build because the emulator uses /proc to find its binary The result is that I now have the emulator running on FreeBSD which has X11/Framebuffer working. Here is a screenshot in which I connect to a FreeBSD host using "ssh -Y" in Mac OS X and run the emulator https://drive.google.com/file/d/0B7wcN-tOkdeRZTlzdWh3V0d0VGM/view?usp=sharing https://github.com/astarasikov/freebsd https://github.com/astarasikov/qemu/tree/l-preview-freebsd ---------- Forwarded message ---------- From: Alexander Tarasikov Date: Tue, Oct 7, 2014 at 3:16 PM Subject: Re: Android Emulator for FreeBSD + FreeBSD/ARM port To: Gavin Atkinson On Sun, Oct 5, 2014 at 9:58 PM, Gavin Atkinson wrote: > On Sun, 7 Sep 2014, Alexander Tarasikov wrote: >> During summer as part of GSoC program I was working on porting FreeBSD >> to the Android Emulator. >> Besides, I have ported Android Emulator to run natively on x86_64 as opposed to >> using linuxulator for 32-bit support. >> >> As for the kernel side, I have implemented the support for the >> following hardware: >> *IRQ, Timer, UART >> *MMC >> *Ethernet >> *Framebuffer (using NEWCONS) >> >> It allows to mount rootfs and boot up to login prompt with raspberry >> pi sd card image. > > I'm now in a position where I'm starting to look at getting this in shape > ready to push it into the main tree. Hi! That's interesting > >> As for the emulator, it's a bit complicated. FreeBSD boots fine if you >> launch the emulator on Linux or Mac OS X. I have fixed some parts of >> the build system and headers to make it compile and pass the tests on >> FreeBSD. Unfortunately, the GUI doesn't work right now and only >> console output (virtual UART) works. > > Firstly, I'd like to get the emulator into the ports tree. I was > originally planning on using the Linux binary (I've been doing all of my > testing so far with the Linux binary) but if you have patches for FreeBSD > I think that's likely the best way forward, or it may make sense to import > both? It's complicated. Afaiu, linux compatibility mode only supports 32-bit binaries. So we'll need to rebuild the emulator on 32-bit linux (to get a 'git' version which works). If we run the emulator on Linux or OS X, everything works including framebuffer, mmc and network. As for running natively on FreeBSD, it currently supports the UART and GUI fails at some X11 call. I think we will get it working by removing some unnecessary ifdefffery. > > Then, I'd like to get the Goldfish code into the main FreeBSD tree. It > would be nice to get at least bidirectional UART working before we can do > that, are there any issues with the emulator that would prevent this? > I've also not managed to get ethernet or the framebuffer working, though > I've not looked deep into this and especially for the network interface it > may be related to how I'm running the emulator - I guess you have been > passing through a device into the emulator? > > I think once we can get the bidirectional UART fully functional, we can > push this into the tree. Also, goldfish_mmc.c is missing a copyright > statement - can you add one please? Okay, I will look into it. I will be present at irc on weekends. > > Thanks, > > Gavin -- Regards, Alexander -- Regards, Alexander From owner-freebsd-arm@FreeBSD.ORG Tue Oct 28 12:31:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8CD51B84 for ; Tue, 28 Oct 2014 12:31:47 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 281C8315 for ; Tue, 28 Oct 2014 12:31:47 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id h11so1409651wiw.6 for ; Tue, 28 Oct 2014 05:31: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=Pwde2Gm3vufM1vsNpXYCPg0PL/HRHpHUYjnJGL9gNGg=; b=PpS7C6SbIAAcfjtDUUDGbY0lcXE34qMzTUp4euYyig4oiZzzYCE+FBaBt/prZx+Gxq QsuGLsxnnYy5Cz4G6xoib0ttk3nDbqCmEOFICc8B5o2ez/PTYmZT4ewD9eOhJTFbFR3P AD73gPGEFsrzO+nKqrLFKshFGgjKVRiaV8PpLxkBjJ7DtdJrK4uWZcWe5UCS1BrJUq68 dDZvIiVs9/M+53UJUR/+jlSwGzUO0iKm1h41lQ5+IN42n25Oe+BFqbeQS8qG2sDukYyi GOWgWUvV5lVvvRa2z/xr8qNLSZLWABr5bxiKFskbI7nN8gPAQBUvsqN/Jdi4h8Cey1be gGhw== MIME-Version: 1.0 X-Received: by 10.180.39.106 with SMTP id o10mr4516637wik.54.1414499505295; Tue, 28 Oct 2014 05:31:45 -0700 (PDT) Received: by 10.216.127.72 with HTTP; Tue, 28 Oct 2014 05:31:45 -0700 (PDT) In-Reply-To: <544D8D53.5060100@foxvalley.net> References: <544D8D53.5060100@foxvalley.net> Date: Tue, 28 Oct 2014 10:31:45 -0200 Message-ID: Subject: Re: new support for Raspberry Pi B+ From: Luiz Otavio O Souza To: Dan Raymond Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 12:31:47 -0000 On 26 October 2014 22:09, Dan Raymond wrote: > One small correction to my previous test results: with the 16GB Transcend > card I *can* get it to boot reliably with the hw.bcm2835.sdhci.hs="0" hack. > > To summarize, I see no improvement regarding SD card failures between > r271779 and r273702. Nor do I see any improvement between the previous > commit to crochet and the current commit. I do see a minor regression: > without the sdhci.hs hack I used to get 50% boot failures on my 16GB > Transcend and now I get 100% boot failures. Dan, It's not a regression, it is a improvement, but as usual, it uncovered another bugs (a bug never come alone). Try 10 or 15 boots with and without the fix and check the differences on the SD card identification at dmesg, it should look like: mmcsd0: 2GB at mmc0 25.0MHz/4bit/65535-block Without the patch you'll see odd values for bus speed and width in some of the boots, they will coincide with the times that your card boots fine. What is happening here was that the controller cannot read the card identification data and it will switch to safe (and slow) defaults. With the patch the card is always identified with correct speed and bus speed, this leads to consistent failures as RPi cannot handle HS speed for some cards, whence the the use of hw.bcm2835.sdhci.hs="0" to make it work. So, to summarize: - The fix improve the card detection and identification, making it reliable. - The fix does not improve the situation of cards running into errors when working at HS. I'm still chasing other possible bugs in this driver, but no promises. Luiz From owner-freebsd-arm@FreeBSD.ORG Tue Oct 28 16:07:50 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDA57F18 for ; Tue, 28 Oct 2014 16:07:50 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4CEBFC7 for ; Tue, 28 Oct 2014 16:07:50 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s9SG7oxp000438 for ; Tue, 28 Oct 2014 16:07:50 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194635] Speed optimisation for framebuffer console driver on Raspberry Pi Date: Tue, 28 Oct 2014 16:07:50 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: stefan.berndt@imoriath.com X-Bugzilla-Status: Open X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:07:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194635 --- Comment #3 from Stefan Berndt --- Created attachment 148738 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148738&action=edit unified diff on /sys/arm/broadcom/bcm2835/bcm2835_fb.c Sure. Here comes the diff. Unified form this time. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Oct 28 16:53:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CBB82AD for ; Tue, 28 Oct 2014 16:53:12 +0000 (UTC) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BB93E81D for ; Tue, 28 Oct 2014 16:53:11 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi2so2227134wib.13 for ; Tue, 28 Oct 2014 09:53:10 -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=AM+y8Au7qo0oKAxV1S2N/iEymfRhXTWILbYhySTiD+4=; b=zayGoOZT7xyy2a5d5v4aPiVdCuzjA0k8qHOpypAJTBzCKXroitOLwQcr4ZmkUcFCPM sJacbdGuPCL0czRF3839AKfk8YQ2irybhF5SI/ykG4qiwhJfGYrTrhkE0BeIexmB5dvM uTLs75+LHnbkO1/gPKJfrpdZOOLZ12Yk09JtGcy7HSaDIhCr2kI6cAJGXHiOmWgLpuKV k3rchWSxO9fqzZRA6vA2Ta+qp8xOu4+DBWs6KRXQtvV3UmP1JWQceP+JC+iQshq10Spp R7fmz7ydlabDruq3KY6bCqYu/E6edFmyA9XS+JJpSjmAT1l3lkolMIx8cPBoFVOOiYXe RZrQ== MIME-Version: 1.0 X-Received: by 10.194.216.162 with SMTP id or2mr5795050wjc.68.1414515190080; Tue, 28 Oct 2014 09:53:10 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.216.106.136 with HTTP; Tue, 28 Oct 2014 09:53:09 -0700 (PDT) In-Reply-To: References: <544D8D53.5060100@foxvalley.net> Date: Tue, 28 Oct 2014 09:53:09 -0700 X-Google-Sender-Auth: ayiTZRasJML3W2S_cKZOHR3ZxOs Message-ID: Subject: Re: new support for Raspberry Pi B+ From: Adrian Chadd To: Luiz Otavio O Souza Content-Type: text/plain; charset=UTF-8 Cc: Dan Raymond , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 16:53:12 -0000 Hi, can you downgrade the driver speed after it's started? Ie, once you see a handful of errors, say "ok fine!" and drop down to the slower speed? -adrian On 28 October 2014 05:31, Luiz Otavio O Souza wrote: > On 26 October 2014 22:09, Dan Raymond wrote: >> One small correction to my previous test results: with the 16GB Transcend >> card I *can* get it to boot reliably with the hw.bcm2835.sdhci.hs="0" hack. >> >> To summarize, I see no improvement regarding SD card failures between >> r271779 and r273702. Nor do I see any improvement between the previous >> commit to crochet and the current commit. I do see a minor regression: >> without the sdhci.hs hack I used to get 50% boot failures on my 16GB >> Transcend and now I get 100% boot failures. > > Dan, > > It's not a regression, it is a improvement, but as usual, it uncovered > another bugs (a bug never come alone). > > Try 10 or 15 boots with and without the fix and check the differences > on the SD card identification at dmesg, it should look like: > > mmcsd0: 2GB at mmc0 > 25.0MHz/4bit/65535-block > > Without the patch you'll see odd values for bus speed and width in > some of the boots, they will coincide with the times that your card > boots fine. What is happening here was that the controller cannot read > the card identification data and it will switch to safe (and slow) > defaults. > > With the patch the card is always identified with correct speed and > bus speed, this leads to consistent failures as RPi cannot handle HS > speed for some cards, whence the the use of hw.bcm2835.sdhci.hs="0" to > make it work. > > So, to summarize: > > - The fix improve the card detection and identification, making it reliable. > > - The fix does not improve the situation of cards running into errors > when working at HS. > > I'm still chasing other possible bugs in this driver, but no promises. > > Luiz > _______________________________________________ > 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 Tue Oct 28 22:17:35 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C853CD8F for ; Tue, 28 Oct 2014 22:17:35 +0000 (UTC) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 5F651F36 for ; Tue, 28 Oct 2014 22:17:34 +0000 (UTC) Received: (qmail 19631 invoked from network) for freebsd-arm@freebsd.org; 28 Oct 2014 17:17:28 -0500 Received: from marengo.foxvalley.net (draymond@64.135.192.25) by mail.foxvalley.net with SMTP; 28 Oct 2014 17:17:28 -0500 Received: from sp7.qualcomm.com (sp7.qualcomm.com [199.106.103.57]) by webmail.FoxValley.net (Horde MIME library) with HTTP; Tue, 28 Oct 2014 17:17:28 -0500 Message-ID: <20141028171728.2n3rcc34r95gk4ck@webmail.FoxValley.net> Date: Tue, 28 Oct 2014 17:17:28 -0500 From: draymond@FoxValley.net To: Luiz Otavio O Souza Subject: Re: new support for Raspberry Pi B+ References: <544D8D53.5060100@foxvalley.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.1.2) Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2014 22:17:35 -0000 Quoting Luiz Otavio O Souza : > With the patch the card is always identified with correct speed and > bus speed, this leads to consistent failures as RPi cannot handle HS > speed for some cards, whence the the use of hw.bcm2835.sdhci.hs="0" to > make it work. Thanks, Luiz. That explains a lot. I agree this is a move in the right direction but one thing to consider is that new official images will be unusable to many people because they won't be able to add the hw.bcm2835.sdhci.hs="0" hack if it consistently fails to boot. It might be a good idea to embed the hack into official images until this gets sorted out. Do you have any ideas on the I/O errors during the partition resize operation with my SanDisk 32GB? Let me know if you want me to try anything else out. Keep up the good work. :) From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 01:26:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D5C865D for ; Wed, 29 Oct 2014 01:26:18 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 38A495F2 for ; Wed, 29 Oct 2014 01:26:17 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id CF50539D0A for ; Wed, 29 Oct 2014 10:20:57 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id A549E39D09 for ; Wed, 29 Oct 2014 10:20:57 +0900 (JST) Message-ID: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> From: "Daisuke Aoyama" To: Subject: FreeBSD 11-CURRENT on Raspberry Pi 512MB Date: Wed, 29 Oct 2014 10:20:56 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 01:26:18 -0000 I've created FreeBSD 11-CURRENT for RPi based on svn 273303. The first version is released at my Japanese blog: Download and tips http://shell.peach.ne.jp/aoyama/archives/2931 Initial setup of FreeBSD 11 on RPi http://shell.peach.ne.jp/aoyama/archives/2946 Package installation of Apache 2.4(event MPM), MySQL 5.6, PHP 5.6(ZTS) and phpMyAdmin. http://shell.peach.ne.jp/aoyama/archives/2951 The pre-build base images are available from my archives: http://www.peach.ne.jp/archives/rpi/ (Latest version is FreeBSD-armv6-11.0-RPI-B-test20-r273303-20141026.img.gz) Download and decompress it, then write it to an SD card of 8GB or more. This image is intended to use as a headless server. (No X11 and GPU 16MB) For quick playing, I provide some useful packages such as samba 4.1, AMP. This version have cpufreq(4) based frequency contoller. Clock frequencies can be dynamically changed by hand or powerd. Also realtime raw values including temperature are stored in hw.cpufreq: Example overclock at 1000MHz: # sysctl hw.cpufreq hw.cpufreq.arm_freq: 1000000000 hw.cpufreq.core_freq: 500000000 hw.cpufreq.sdram_freq: 500000000 hw.cpufreq.turbo: 1 hw.cpufreq.voltage_core: 6 hw.cpufreq.voltage_sdram_c: 1 hw.cpufreq.voltage_sdram_i: 1 hw.cpufreq.voltage_sdram_p: 1 hw.cpufreq.temperature: 50843 # sysctl dev.cpu dev.cpu.%parent: dev.cpu.0.%desc: Open Firmware CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,1176jzf-s dev.cpu.0.%parent: cpulist0 dev.cpu.0.freq: 300 dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 400/-1 300/-1 Note: Do not build kernel without patch to bcm2835_mbox.c, otherwise you get a panic in msleep. Using config is here: http://www.peach.ne.jp/archives/rpi/config/RPI-B-test20 Source and pacth is here: http://www.peach.ne.jp/archives/rpi/patch/ Local packages is here: http://www.peach.ne.jp/archives/rpi/ports/packages/All/ Pre-configured: MEM 496MB/GPU 16MB/SWAP none Clock: ARM 800MHz/Core 400MHz/SDRAM 400MHz (overclock from 700/250/400) ntpdate: 0.freebsd.pool.ntp.org portsnap: fetch and extracted powerd: enabled (min 300MHz) See also: http://www.peach.ne.jp/archives/rpi/00README.txt Enjoy 11-CURRENT world in Raspberry Pi! Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 05:31:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D8BE841C for ; Wed, 29 Oct 2014 05:31:38 +0000 (UTC) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AC7FEB7 for ; Wed, 29 Oct 2014 05:31:38 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so2420194pab.12 for ; Tue, 28 Oct 2014 22:31:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=OJmfje3lqEVvifOf8FwdKFxe1DLckhsy7bt5KCXBpws=; b=kWUM2yw6OqyHeO3Vo/sSiyCRb8bKOepqiR2Z6VA5lBVm8jCg7gCG+8i1p1obvn/2JY XUIQafVzB3jmi+aTD5tfBH9kLYxMwuxRmjkpChpErhDh4tw9OEKiqTZSLNX/zzmrQT0N tKdnLVd79Oqtf0vyIhJXDm6HC8GcPsdCzOxWP4GgLnSV8aPyNbkMA7TzqC992ggnLpV2 I48taduT6MjmfohHxLbyPzKUPNzXiZ1IsGeiEFY9Kp9GQb4vnv/JScDAgVEHitdLPJtP 4wldRguqu1/asccR1H9L8zYxVDKTdRNJj0P95h0ryTeIcX8G3Vaa7nTiv15SWReuhZ0t IjFQ== X-Received: by 10.68.250.196 with SMTP id ze4mr8325850pbc.2.1414560698264; Tue, 28 Oct 2014 22:31:38 -0700 (PDT) Received: from [192.168.0.4] (c211-30-51-180.frank3.vic.optusnet.com.au. [211.30.51.180]) by mx.google.com with ESMTPSA id ra2sm3160955pbc.27.2014.10.28.22.31.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 28 Oct 2014 22:31:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: new support for Raspberry Pi B+ From: Felix Friedlander In-Reply-To: <20141028171728.2n3rcc34r95gk4ck@webmail.FoxValley.net> Date: Wed, 29 Oct 2014 16:31:30 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <90D05C87-D695-456E-B7B4-BA863D225133@gmail.com> References: <544D8D53.5060100@foxvalley.net> <20141028171728.2n3rcc34r95gk4ck@webmail.FoxValley.net> To: draymond@FoxValley.net, freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.1990.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 05:31:38 -0000 I=E2=80=99m certainly in favour of embedding the hack in the images, as = I have been unable to implement it (I have no FreeBSD or Linux system to = edit the filesystem on, and Mac OS doesn=E2=80=99t seem to be able to = mount it even though it=E2=80=99s UFS) > On 29 Oct 2014, at 9:17 am, draymond@FoxValley.net wrote: >=20 > Quoting Luiz Otavio O Souza : >=20 >> With the patch the card is always identified with correct speed and >> bus speed, this leads to consistent failures as RPi cannot handle HS >> speed for some cards, whence the the use of hw.bcm2835.sdhci.hs=3D"0" = to >> make it work. >=20 > Thanks, Luiz. That explains a lot. I agree this is a move in the = right direction but one thing to consider is that new official images = will be unusable to many people because they won't be able to add the = hw.bcm2835.sdhci.hs=3D"0" hack if it consistently fails to boot. It = might be a good idea to embed the hack into official images until this = gets sorted out. >=20 > Do you have any ideas on the I/O errors during the partition resize = operation with my SanDisk 32GB? Let me know if you want me to try = anything else out. >=20 > Keep up the good work. :) >=20 > _______________________________________________ > 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 Wed Oct 29 06:49:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 17A473A3 for ; Wed, 29 Oct 2014 06:49:44 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DD24291E for ; Wed, 29 Oct 2014 06:49:43 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NE7003IZ1M64Q60@st11p02mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Wed, 29 Oct 2014 06:49:20 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-29_04:2014-10-28,2014-10-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410290075 Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-type: text/plain; charset=us-ascii From: Rui Paulo X-Priority: 3 In-reply-to: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> Date: Tue, 28 Oct 2014 23:49:18 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 06:49:44 -0000 On Oct 28, 2014, at 18:20, Daisuke Aoyama wrote: >=20 > I've created FreeBSD 11-CURRENT for RPi based on svn 273303. >=20 > The first version is released at my Japanese blog: >=20 > Download and tips > http://shell.peach.ne.jp/aoyama/archives/2931 > Initial setup of FreeBSD 11 on RPi > http://shell.peach.ne.jp/aoyama/archives/2946 > Package installation of Apache 2.4(event MPM), MySQL 5.6, PHP 5.6(ZTS) = and phpMyAdmin. > http://shell.peach.ne.jp/aoyama/archives/2951 >=20 > The pre-build base images are available from my archives: > http://www.peach.ne.jp/archives/rpi/ > (Latest version is = FreeBSD-armv6-11.0-RPI-B-test20-r273303-20141026.img.gz) >=20 > Download and decompress it, then write it to an SD card of 8GB or = more. > This image is intended to use as a headless server. (No X11 and GPU = 16MB) > For quick playing, I provide some useful packages such as samba 4.1, = AMP. >=20 > This version have cpufreq(4) based frequency contoller. > Clock frequencies can be dynamically changed by hand or powerd. > Also realtime raw values including temperature are stored in = hw.cpufreq: >=20 > Example overclock at 1000MHz: >=20 > # sysctl hw.cpufreq > hw.cpufreq.arm_freq: 1000000000 > hw.cpufreq.core_freq: 500000000 > hw.cpufreq.sdram_freq: 500000000 > hw.cpufreq.turbo: 1 > hw.cpufreq.voltage_core: 6 > hw.cpufreq.voltage_sdram_c: 1 > hw.cpufreq.voltage_sdram_i: 1 > hw.cpufreq.voltage_sdram_p: 1 > hw.cpufreq.temperature: 50843 >=20 > # sysctl dev.cpu > dev.cpu.%parent: > dev.cpu.0.%desc: Open Firmware CPU > dev.cpu.0.%driver: cpu > dev.cpu.0.%location: > dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,1176jzf-s > dev.cpu.0.%parent: cpulist0 > dev.cpu.0.freq: 300 > dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 = 400/-1 300/-1 >=20 >=20 > Note: > Do not build kernel without patch to bcm2835_mbox.c, otherwise you get = a panic in msleep. >=20 > Using config is here: > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test20 >=20 > Source and pacth is here: > http://www.peach.ne.jp/archives/rpi/patch/ >=20 > Local packages is here: > http://www.peach.ne.jp/archives/rpi/ports/packages/All/ >=20 >=20 > Pre-configured: >=20 > MEM 496MB/GPU 16MB/SWAP none > Clock: ARM 800MHz/Core 400MHz/SDRAM 400MHz (overclock from = 700/250/400) > ntpdate: 0.freebsd.pool.ntp.org > portsnap: fetch and extracted > powerd: enabled (min 300MHz) >=20 > See also: > http://www.peach.ne.jp/archives/rpi/00README.txt This is pretty interesting. Is anyone already helping you merge your = code to FreeBSD? Some questions: - Did you measure the power consumption when using the different = frequency values? - Could you also export the temperature in dev.cpu.0.temperature like = coretemp/amdtemp? You'd need to perform a device lookup and then lookup = its sysctl context. One suggestion I have is to move the register definition structures to a = header file like bcm2835_cpufreq.h. There are some style issues with your patch, but I think it's pretty = close to being ready. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 09:27:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0FC6D79B for ; Wed, 29 Oct 2014 09:27:07 +0000 (UTC) Received: from smtp101.iad3a.emailsrvr.com (smtp101.iad3a.emailsrvr.com [173.203.187.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D72A9B2D for ; Wed, 29 Oct 2014 09:27:06 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 6ADE31002E8; Wed, 29 Oct 2014 05:19:30 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.iad3a.emailsrvr.com (Authenticated sender: gray-AT-nxg.name) with ESMTPSA id 9FC911001CA; Wed, 29 Oct 2014 05:19:29 -0400 (EDT) X-Sender-Id: gray@nxg.name Received: from coricopat.home (host86-164-29-197.range86-164.btcentralplus.com [86.164.29.197]) (using TLSv1 with cipher AES128-SHA) by 0.0.0.0:587 (trex/5.3.2); Wed, 29 Oct 2014 09:19:30 GMT Subject: Re: new support for Raspberry Pi B+ Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=windows-1252 From: Norman Gray In-Reply-To: <90D05C87-D695-456E-B7B4-BA863D225133@gmail.com> Date: Wed, 29 Oct 2014 09:19:29 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <544D8D53.5060100@foxvalley.net> <20141028171728.2n3rcc34r95gk4ck@webmail.FoxValley.net> <90D05C87-D695-456E-B7B4-BA863D225133@gmail.com> To: Felix Friedlander X-Mailer: Apple Mail (2.1510) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 09:27:07 -0000 Felix, hello. On 2014 Oct 29, at 05:31, Felix Friedlander = wrote: > I=92m certainly in favour of embedding the hack in the images, as I = have been unable to implement it (I have no FreeBSD or Linux system to = edit the filesystem on, and Mac OS doesn=92t seem to be able to mount it = even though it=92s UFS) It's true that OS X can't mount the freebsd filesystem (slightly = disappointingly), but recall that the configuration in question[1] is on = the DOS partition of the image, which is automounted when the card = becomes visible, as /Volumes/BOOT. Caveats: ...at least in my experience on OS X 10.8.5, and if we're = talking about the same thing. Best wishes, Norman [1] = http://lists.freebsd.org/pipermail/freebsd-arm/2014-October/009390.html --=20 Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 14:53:37 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D8AC706 for ; Wed, 29 Oct 2014 14:53:37 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E40BF2E5 for ; Wed, 29 Oct 2014 14:53:36 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjUcx-000MXy-Cb; Wed, 29 Oct 2014 14:53:35 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9TErXLP080900; Wed, 29 Oct 2014 08:53:33 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 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+kpNSdHvS8SI+c6MoZmqFX X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB From: Ian Lepore To: Rui Paulo In-Reply-To: References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Oct 2014 08:53:32 -0600 Message-ID: <1414594412.17308.76.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.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 14:53:37 -0000 On Tue, 2014-10-28 at 23:49 -0700, Rui Paulo wrote: > On Oct 28, 2014, at 18:20, Daisuke Aoyama wrote: > > > > I've created FreeBSD 11-CURRENT for RPi based on svn 273303. > > > > The first version is released at my Japanese blog: > > > > Download and tips > > http://shell.peach.ne.jp/aoyama/archives/2931 > > Initial setup of FreeBSD 11 on RPi > > http://shell.peach.ne.jp/aoyama/archives/2946 > > Package installation of Apache 2.4(event MPM), MySQL 5.6, PHP 5.6(ZTS) and phpMyAdmin. > > http://shell.peach.ne.jp/aoyama/archives/2951 > > > > The pre-build base images are available from my archives: > > http://www.peach.ne.jp/archives/rpi/ > > (Latest version is FreeBSD-armv6-11.0-RPI-B-test20-r273303-20141026.img.gz) > > > > Download and decompress it, then write it to an SD card of 8GB or more. > > This image is intended to use as a headless server. (No X11 and GPU 16MB) > > For quick playing, I provide some useful packages such as samba 4.1, AMP. > > > > This version have cpufreq(4) based frequency contoller. > > Clock frequencies can be dynamically changed by hand or powerd. > > Also realtime raw values including temperature are stored in hw.cpufreq: > > > > Example overclock at 1000MHz: > > > > # sysctl hw.cpufreq > > hw.cpufreq.arm_freq: 1000000000 > > hw.cpufreq.core_freq: 500000000 > > hw.cpufreq.sdram_freq: 500000000 > > hw.cpufreq.turbo: 1 > > hw.cpufreq.voltage_core: 6 > > hw.cpufreq.voltage_sdram_c: 1 > > hw.cpufreq.voltage_sdram_i: 1 > > hw.cpufreq.voltage_sdram_p: 1 > > hw.cpufreq.temperature: 50843 > > > > # sysctl dev.cpu > > dev.cpu.%parent: > > dev.cpu.0.%desc: Open Firmware CPU > > dev.cpu.0.%driver: cpu > > dev.cpu.0.%location: > > dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,1176jzf-s > > dev.cpu.0.%parent: cpulist0 > > dev.cpu.0.freq: 300 > > dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 400/-1 300/-1 > > > > > > Note: > > Do not build kernel without patch to bcm2835_mbox.c, otherwise you get a panic in msleep. > > > > Using config is here: > > http://www.peach.ne.jp/archives/rpi/config/RPI-B-test20 > > > > Source and pacth is here: > > http://www.peach.ne.jp/archives/rpi/patch/ > > > > Local packages is here: > > http://www.peach.ne.jp/archives/rpi/ports/packages/All/ > > > > > > Pre-configured: > > > > MEM 496MB/GPU 16MB/SWAP none > > Clock: ARM 800MHz/Core 400MHz/SDRAM 400MHz (overclock from 700/250/400) > > ntpdate: 0.freebsd.pool.ntp.org > > portsnap: fetch and extracted > > powerd: enabled (min 300MHz) > > > > See also: > > http://www.peach.ne.jp/archives/rpi/00README.txt > > This is pretty interesting. Is anyone already helping you merge your code to FreeBSD? > > Some questions: > > - Did you measure the power consumption when using the different frequency values? > - Could you also export the temperature in dev.cpu.0.temperature like coretemp/amdtemp? You'd need to perform a device lookup and then lookup its sysctl context. > > One suggestion I have is to move the register definition structures to a header file like bcm2835_cpufreq.h. > Huh, and I would recommend just the opposite, including a need to clean up many of our existing drivers. If it's only used by one source file, it doesn't need to be in a header file, which is implicitly for sharing information between multiple source files. The worst is when you have foo_driverreg.h with like 4 #defines in it; that's so annoying. (A valid exception to the "only if it needs to be shared" concept might be a file that #defines hundreds-to-thousands of values.) -- Ian > There are some style issues with your patch, but I think it's pretty close to being ready. > > -- > Rui Paulo > > > > _______________________________________________ > 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 Wed Oct 29 16:49:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0CD62B15 for ; Wed, 29 Oct 2014 16:49:34 +0000 (UTC) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C0F98391 for ; Wed, 29 Oct 2014 16:49:33 +0000 (UTC) Received: by mail-pa0-f51.google.com with SMTP id kq14so3498287pab.24 for ; Wed, 29 Oct 2014 09:49:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=Lw9bw+mDoa2A/3B2II2dte0gkJ5pXlzNwMc1uTRt4rM=; b=XS72TDga9WRbqg27M3ZSMu+VGiYPxwfS5p06jsgBGqxwQRJN9P5GkinbeylY2K5YJv RiZF0yPXimVWYJF1qvt5+kIrbTlRNKB24+oKv9fNZJBCYrZPhWiPlTbVnb3ZaQqfOoHf VCQMMywtN2q1W5JF4RPx9f91IH5XoLBRDDW8St+Y6li+HOUtbjg21olTB0uVuKKwR5Ft PTOXIJNe5fBOGWJLhlJ+mdBrrk62CSPdBMxa8kNy1sffYgfq/Mg6m1QATECSCnnk/Wiy XxtP+4Mv/Emf6Yl8gFlbMKXiq5l8cujzW8uioWjxT43EijeQKp9NCMtegxKGv+9hT5KB QIFQ== X-Gm-Message-State: ALoCoQmv5+52OZaR2vBEzRWH9Gn7hsYAB2a8Gr8kUwjSm2NhcC57rRlCUVJonQ0WfDaFz5TXPJN3 X-Received: by 10.69.31.107 with SMTP id kl11mr134479pbd.167.1414601367626; Wed, 29 Oct 2014 09:49:27 -0700 (PDT) Received: from [10.64.27.26] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id s9sm4843279pdp.1.2014.10.29.09.49.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 09:49:26 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_2A553DAD-8ABB-4802-9F82-A7F42B53F1AD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB From: Warner Losh In-Reply-To: <1414594412.17308.76.camel@revolution.hippie.lan> Date: Wed, 29 Oct 2014 10:49:22 -0600 Message-Id: References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> <1414594412.17308.76.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 16:49:34 -0000 --Apple-Mail=_2A553DAD-8ABB-4802-9F82-A7F42B53F1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 29, 2014, at 8:53 AM, Ian Lepore wrote: > On Tue, 2014-10-28 at 23:49 -0700, Rui Paulo wrote: >> On Oct 28, 2014, at 18:20, Daisuke Aoyama wrote: >>>=20 >>> I've created FreeBSD 11-CURRENT for RPi based on svn 273303. >>>=20 >>> The first version is released at my Japanese blog: >>>=20 >>> Download and tips >>> http://shell.peach.ne.jp/aoyama/archives/2931 >>> Initial setup of FreeBSD 11 on RPi >>> http://shell.peach.ne.jp/aoyama/archives/2946 >>> Package installation of Apache 2.4(event MPM), MySQL 5.6, PHP = 5.6(ZTS) and phpMyAdmin. >>> http://shell.peach.ne.jp/aoyama/archives/2951 >>>=20 >>> The pre-build base images are available from my archives: >>> http://www.peach.ne.jp/archives/rpi/ >>> (Latest version is = FreeBSD-armv6-11.0-RPI-B-test20-r273303-20141026.img.gz) >>>=20 >>> Download and decompress it, then write it to an SD card of 8GB or = more. >>> This image is intended to use as a headless server. (No X11 and GPU = 16MB) >>> For quick playing, I provide some useful packages such as samba 4.1, = AMP. >>>=20 >>> This version have cpufreq(4) based frequency contoller. >>> Clock frequencies can be dynamically changed by hand or powerd. >>> Also realtime raw values including temperature are stored in = hw.cpufreq: >>>=20 >>> Example overclock at 1000MHz: >>>=20 >>> # sysctl hw.cpufreq >>> hw.cpufreq.arm_freq: 1000000000 >>> hw.cpufreq.core_freq: 500000000 >>> hw.cpufreq.sdram_freq: 500000000 >>> hw.cpufreq.turbo: 1 >>> hw.cpufreq.voltage_core: 6 >>> hw.cpufreq.voltage_sdram_c: 1 >>> hw.cpufreq.voltage_sdram_i: 1 >>> hw.cpufreq.voltage_sdram_p: 1 >>> hw.cpufreq.temperature: 50843 >>>=20 >>> # sysctl dev.cpu >>> dev.cpu.%parent: >>> dev.cpu.0.%desc: Open Firmware CPU >>> dev.cpu.0.%driver: cpu >>> dev.cpu.0.%location: >>> dev.cpu.0.%pnpinfo: name=3Dcpu@0 compat=3Darm,1176jzf-s >>> dev.cpu.0.%parent: cpulist0 >>> dev.cpu.0.freq: 300 >>> dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 = 400/-1 300/-1 >>>=20 >>>=20 >>> Note: >>> Do not build kernel without patch to bcm2835_mbox.c, otherwise you = get a panic in msleep. >>>=20 >>> Using config is here: >>> http://www.peach.ne.jp/archives/rpi/config/RPI-B-test20 >>>=20 >>> Source and pacth is here: >>> http://www.peach.ne.jp/archives/rpi/patch/ >>>=20 >>> Local packages is here: >>> http://www.peach.ne.jp/archives/rpi/ports/packages/All/ >>>=20 >>>=20 >>> Pre-configured: >>>=20 >>> MEM 496MB/GPU 16MB/SWAP none >>> Clock: ARM 800MHz/Core 400MHz/SDRAM 400MHz (overclock from = 700/250/400) >>> ntpdate: 0.freebsd.pool.ntp.org >>> portsnap: fetch and extracted >>> powerd: enabled (min 300MHz) >>>=20 >>> See also: >>> http://www.peach.ne.jp/archives/rpi/00README.txt >>=20 >> This is pretty interesting. Is anyone already helping you merge your = code to FreeBSD? >>=20 >> Some questions: >>=20 >> - Did you measure the power consumption when using the different = frequency values? >> - Could you also export the temperature in dev.cpu.0.temperature like = coretemp/amdtemp? You'd need to perform a device lookup and then lookup = its sysctl context. >>=20 >> One suggestion I have is to move the register definition structures = to a header file like bcm2835_cpufreq.h. >>=20 >=20 > Huh, and I would recommend just the opposite, including a need to = clean > up many of our existing drivers. If it's only used by one source = file, > it doesn't need to be in a header file, which is implicitly for = sharing > information between multiple source files. The worst is when you have > foo_driverreg.h with like 4 #defines in it; that's so annoying. (A > valid exception to the "only if it needs to be shared" concept might = be > a file that #defines hundreds-to-thousands of values.) I=92d peg it closer to =91dozens=92 rather than =91hundreds=92. More = than a few dozen lines of register definitions needs their own file. That=92s the point they become a distraction. It is well short of =91hundreds=92 let = alone thousands. Though I=92ve done it in the past in reg.h files (have just a few = defines), a few defines can easily live at the top of the driver. Most devices are complicated enough that the convention arose. It was only when we started having dozens of devices with a few registers and a few bits that it became annoying. Warner --Apple-Mail=_2A553DAD-8ABB-4802-9F82-A7F42B53F1AD 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUURqSAAoJEGwc0Sh9sBEADfsQAJL4/wmxjZsXDdlZsNh3829d c3sUVXPNVk84Zv3eoqd15RHk2PnWwp238eV2OiARjDLSi15Y7+WjgoFqyEqohVGh BRfKIZzV1vYEh/0FL404PBS7Fubr9LAyDTi8ETGn9yLFIz+ziWOBFUs8Rxp9vq4n dtHqPlKtDXWjv/He9/ZFnq+Qb4R7SOon2DGCYCZDRZbY3YpFvTKyYf8TEjcfyMA0 6FmWEYOK4y0yyK9uV0QBDDl7pnempiI+EtuLJcdCfreWiT1OviHDmq2aRhleBJzP lLbPWfc6Oc5QyShPBlUkad6zhOKOh/teM+A5czGPK21+cOdlI9iGYr4prkJLMtk+ knpQJaoI9XbB/sGXE7uQ5+L0HYBQ5MEyosiBkxTdhUy0wm7axCerl92wJlCnVyTr ZAlDT8z5Jfya7FT31adQ15BP8gPPCAnRU9UGE95IXnR89Q7lnINndW8HexQC+hMd dkA/rgGiTCqGirnFmTaZX+KgjWwDRtEBlLkcvRx2K0ooWZS0p5ndHg8dHPUUlMug Yr1yxHL+4C0C4ubYvtV0iDQVUvM9MdkaanKD4TU1PdjERztYZmpXBVxb3dhoj2Nx HbGfV5DOFB0Du9IChg9mh3e6IJ9RIo7GhfQk7YPMFMzxfQf4bU66uE6EtWYeYTz8 +Kt1lId3sFM/48FbiOrG =2/4L -----END PGP SIGNATURE----- --Apple-Mail=_2A553DAD-8ABB-4802-9F82-A7F42B53F1AD-- From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 17:30:19 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C8FEC95A for ; Wed, 29 Oct 2014 17:30:19 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 5017CA4A for ; Wed, 29 Oct 2014 17:30:18 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s9THTjRt086941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Oct 2014 18:29:46 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s9THTc60036358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 18:29:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s9THTcDv060817; Wed, 29 Oct 2014 18:29:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s9THTbCi060816; Wed, 29 Oct 2014 18:29:37 +0100 (CET) (envelope-from ticso) Date: Wed, 29 Oct 2014 18:29:37 +0100 From: Bernd Walter To: Luiz Otavio O Souza Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <20141029172937.GB59614@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20140825163528.d2e696cc3d03ad9bebcd239c@schwarzes.net> <20140826074951.4cf5a8fc@X220.alogt.com> <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141023022244.GB16490@cicely7.cicely.de> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Andreas Schwarz , George Rosamond , "freebsd-arm@freebsd.org" , ticso@cicely.de, Tim Kientzle X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:30:19 -0000 On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > > On 22 October 2014 18:44, Bernd Walter wrote: > > > On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > > >> On 14 October 2014 01:13, Bernd Walter wrote: > > >> > > > >> > Ok - that card problem seems random or contact related. > > >> > Whatever, it is 6 am - time to sleep ;-) > > >> > > >> I've found a missing silicon bug workaround on our driver. > > >> > > >> It's pretty recent and i'm still building new images to test with more > > >> cards, but it did fix all the instability i was seeing on the > > >> identification of one of my cards. > > >> > > >> Together with the new firmware (yes, there is another SD fix there) my > > >> RPi B rev 2 (with this same card) has gone from unusable to rock > > >> stable (i've done 80 cold boots without any damage/corruption to the > > >> card). > > >> > > >> Please, give it a try and let me know if it helps. > > > > > > Tested. > > > All I can say so far is that it is random, but your patch didn't help. > > > > Without my patch you should see the speed and the bus width changing > > over the boots and with my patch it should always be the same > > (41.6MHz/4bit): > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > > Furthermore this problem now happens on each boot try. > > > It still may be possible that it can boot, but I've tried many more > > > times than needed before. > > > > > > Timecounters tick every 10.000 msec > > > usbus0: 480Mbps High Speed USB v2.0 > > > ugen0.1: at usbus0 > > > uhub0: on usbus0 > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > mmcsd0: Error indicated: 1 Timeout > > > mmcsd0: Error indicated: 1 Timeout > > > fb0: 656x416(0x0@0,0) 16bpp > > > fb0: pitch 1312, base 0x5e006000, screen_size 545792 > > > fbd0 on fb0 > > > VT: initialize with new VT driver "fb". > > > > Ok. Can you try add the following to /boot/loader.conf ? > > > > echo hw.bcm2835.sdhci.hs=0 >> /boot/loader.conf > > > > RPi _is_ picky about the SD card, the patch won't make that go away > > but should help in a few cases. > > I know - that's the reason why I bought the B+ boards in bundle with > cards directly from Farnell. > Hoped they wouldn't make any problems under FreeBSD. > The cards unfortunately are unlabeled, just the included SD adapter > has a raspi logo. > > > There is a possibility that your card won't work in HS mode and now > > that the card identification always works, it will always go with the > > highest supported speed. The tunable should help if that is the case. > > This makes sense. > I don't remember this card/board combination, but about a year ago, when > I used other cards in other boards the speed and width wasn't always the > same. > > And you are absolutely right, with that loader.conf entry it works. > ... > mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block > ... This is another card from the same order (and hopefully same batch) in a Beaglebone Black: mmcsd0: 8GB at mmc0 48.0MHz/4bit/65535-block Interesting that the Raspberry is so picky about them, since the card clearly is capable to do such frequency. But I miss something on the Raspberry board. The B boards clearly have series resistors in the signal lines. The B+ has not. However the MMC/SD should have some pull up resistors, usually around 100k Ohms. Following the signals is hard to impossible, but there are no such resistors in a reasonable location on neither B nor B+. They might be interal in the broadcom SoC, but this is very unusual. I consider modding the SD signals on the B+ impossible, but it can be done on the B. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 17:58:27 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1405E64C for ; Wed, 29 Oct 2014 17:58:27 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C1065DC2 for ; Wed, 29 Oct 2014 17:58:26 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjXVo-000DhX-RX; Wed, 29 Oct 2014 17:58:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9THwLYl081218; Wed, 29 Oct 2014 11:58:21 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19iAutvs8mWMWqPdyOG5anB X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20141029172937.GB59614@cicely7.cicely.de> References: <20140825163528.d2e696cc3d03ad9bebcd239c@schwarzes.net> <20140826074951.4cf5a8fc@X220.alogt.com> <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Oct 2014 11:58:21 -0600 Message-ID: <1414605501.17308.97.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Andreas Schwarz , George Rosamond , "freebsd-arm@freebsd.org" , Tim Kientzle X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 17:58:27 -0000 On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: > On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > > On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > > > On 22 October 2014 18:44, Bernd Walter wrote: > > > > On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > > > >> On 14 October 2014 01:13, Bernd Walter wrote: > > > >> > > > > >> > Ok - that card problem seems random or contact related. > > > >> > Whatever, it is 6 am - time to sleep ;-) > > > >> > > > >> I've found a missing silicon bug workaround on our driver. > > > >> > > > >> It's pretty recent and i'm still building new images to test with more > > > >> cards, but it did fix all the instability i was seeing on the > > > >> identification of one of my cards. > > > >> > > > >> Together with the new firmware (yes, there is another SD fix there) my > > > >> RPi B rev 2 (with this same card) has gone from unusable to rock > > > >> stable (i've done 80 cold boots without any damage/corruption to the > > > >> card). > > > >> > > > >> Please, give it a try and let me know if it helps. > > > > > > > > Tested. > > > > All I can say so far is that it is random, but your patch didn't help. > > > > > > Without my patch you should see the speed and the bus width changing > > > over the boots and with my patch it should always be the same > > > (41.6MHz/4bit): > > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > > > > Furthermore this problem now happens on each boot try. > > > > It still may be possible that it can boot, but I've tried many more > > > > times than needed before. > > > > > > > > Timecounters tick every 10.000 msec > > > > usbus0: 480Mbps High Speed USB v2.0 > > > > ugen0.1: at usbus0 > > > > uhub0: on usbus0 > > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > mmcsd0: Error indicated: 1 Timeout > > > > mmcsd0: Error indicated: 1 Timeout > > > > fb0: 656x416(0x0@0,0) 16bpp > > > > fb0: pitch 1312, base 0x5e006000, screen_size 545792 > > > > fbd0 on fb0 > > > > VT: initialize with new VT driver "fb". > > > > > > Ok. Can you try add the following to /boot/loader.conf ? > > > > > > echo hw.bcm2835.sdhci.hs=0 >> /boot/loader.conf > > > > > > RPi _is_ picky about the SD card, the patch won't make that go away > > > but should help in a few cases. > > > > I know - that's the reason why I bought the B+ boards in bundle with > > cards directly from Farnell. > > Hoped they wouldn't make any problems under FreeBSD. > > The cards unfortunately are unlabeled, just the included SD adapter > > has a raspi logo. > > > > > There is a possibility that your card won't work in HS mode and now > > > that the card identification always works, it will always go with the > > > highest supported speed. The tunable should help if that is the case. > > > > This makes sense. > > I don't remember this card/board combination, but about a year ago, when > > I used other cards in other boards the speed and width wasn't always the > > same. > > > > And you are absolutely right, with that loader.conf entry it works. > > ... > > mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block > > ... > > This is another card from the same order (and hopefully same batch) in a Beaglebone > Black: > mmcsd0: 8GB at mmc0 48.0MHz/4bit/65535-block > Interesting that the Raspberry is so picky about them, since the card clearly is > capable to do such frequency. > > But I miss something on the Raspberry board. > The B boards clearly have series resistors in the signal lines. > The B+ has not. > However the MMC/SD should have some pull up resistors, usually > around 100k Ohms. > Following the signals is hard to impossible, but there are no such > resistors in a reasonable location on neither B nor B+. > They might be interal in the broadcom SoC, but this is very unusual. > I consider modding the SD signals on the B+ impossible, but it can > be done on the B. > > -- Pullups on sd signal lines is a recent thing. It's in the sd 4.x physical spec, in the form of requiring the standard sd data lines be pulled high or low when using the new UHS-II signals. Other than that pullups are not required on any of the lines for sd cards. At work we don't put pullups on any of them, and use a 22 ohm series on just the clock line, and that only on designs where we have to fly across a ribbon cable to get to the card socket. The thing to keep in mind about the rpi sdcard woes is that it all works in u-boot and in linux. The same cards that fail on freebsd get as far as loading freebsd... i.e., they worked fine in u-boot and didn't fail until our driver came along and touched the hardware. If you boot that same card into linux it'll work fine. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 19:10:10 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09620A6F for ; Wed, 29 Oct 2014 19:10:10 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA054809 for ; Wed, 29 Oct 2014 19:10:08 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id E9E8039D36; Thu, 30 Oct 2014 04:10:05 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id C798739D0A; Thu, 30 Oct 2014 04:10:05 +0900 (JST) Message-ID: From: "Daisuke Aoyama" To: "Rui Paulo" References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> In-Reply-To: Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB Date: Thu, 30 Oct 2014 04:10:02 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 19:10:10 -0000 Thank you for interesting. I forget to write "hw.cpufreq" is writable except temperature. > Is anyone already helping you merge your code to FreeBSD? Not yet. This is my first working on 11-CURRENT. > - Did you measure the power consumption when using the different frequency values? No. I will check. I thought that temperature was more important than power consumption. > - Could you also export the temperature in dev.cpu.0.temperature like coretemp/amdtemp? Yes, it's a good point. I have written a part of raw to kelvin conversion. Also the prop definitions are separated to bcm2835_mbox_prop.h. Now temperature is in dev.cpu. # sysctl hw.cpufreq dev.cpu hw.cpufreq.arm_freq: 300000000 hw.cpufreq.core_freq: 250000000 hw.cpufreq.sdram_freq: 400000000 hw.cpufreq.turbo: 0 hw.cpufreq.voltage_core: 0 hw.cpufreq.voltage_sdram_c: 0 hw.cpufreq.voltage_sdram_i: 0 hw.cpufreq.voltage_sdram_p: 0 hw.cpufreq.temperature: 47615 dev.cpu.%parent: dev.cpu.0.%desc: Open Firmware CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: dev.cpu.0.%pnpinfo: name=cpu@0 compat=arm,1176jzf-s dev.cpu.0.%parent: cpulist0 dev.cpu.0.freq: 300 dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 400/-1 300/-1 dev.cpu.0.temperature: 46.8C Updated source and kernel: http://www.peach.ne.jp/archives/rpi/patch/bcm2835_cpufreq.c http://www.peach.ne.jp/archives/rpi/patch/bcm2835_mbox_prop.h http://www.peach.ne.jp/archives/rpi/kernel/kernel-20141030.gz > One suggestion I have is to move the register definition structures to a header file like > bcm2835_cpufreq.h. To separate prop functions, it needs more work. I don't know where is better place. Mailbox property interface https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface is not only CPU frequencies. But mbox_if have no method for it. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 20:04:35 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADA2EF02; Wed, 29 Oct 2014 20:04:35 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E80E5E1A; Wed, 29 Oct 2014 20:04:34 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s9TK49WH094030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 29 Oct 2014 21:04:09 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s9TK44gv037690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Oct 2014 21:04:04 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s9TK430g061468; Wed, 29 Oct 2014 21:04:03 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s9TK43XQ061467; Wed, 29 Oct 2014 21:04:03 +0100 (CET) (envelope-from ticso) Date: Wed, 29 Oct 2014 21:04:03 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <20141029200403.GC59614@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1414605501.17308.97.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Andreas Schwarz , George Rosamond , Tim Kientzle , "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:04:35 -0000 On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote: > On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: > > On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > > > On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > > > > On 22 October 2014 18:44, Bernd Walter wrote: > > > > > On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > > > > >> On 14 October 2014 01:13, Bernd Walter wrote: > > > > >> > > > > > >> > Ok - that card problem seems random or contact related. > > > > >> > Whatever, it is 6 am - time to sleep ;-) > > > > >> > > > > >> I've found a missing silicon bug workaround on our driver. > > > > >> > > > > >> It's pretty recent and i'm still building new images to test with more > > > > >> cards, but it did fix all the instability i was seeing on the > > > > >> identification of one of my cards. > > > > >> > > > > >> Together with the new firmware (yes, there is another SD fix there) my > > > > >> RPi B rev 2 (with this same card) has gone from unusable to rock > > > > >> stable (i've done 80 cold boots without any damage/corruption to the > > > > >> card). > > > > >> > > > > >> Please, give it a try and let me know if it helps. > > > > > > > > > > Tested. > > > > > All I can say so far is that it is random, but your patch didn't help. > > > > > > > > Without my patch you should see the speed and the bus width changing > > > > over the boots and with my patch it should always be the same > > > > (41.6MHz/4bit): > > > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > > > > > > Furthermore this problem now happens on each boot try. > > > > > It still may be possible that it can boot, but I've tried many more > > > > > times than needed before. > > > > > > > > > > Timecounters tick every 10.000 msec > > > > > usbus0: 480Mbps High Speed USB v2.0 > > > > > ugen0.1: at usbus0 > > > > > uhub0: on usbus0 > > > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > > mmcsd0: Error indicated: 1 Timeout > > > > > mmcsd0: Error indicated: 1 Timeout > > > > > fb0: 656x416(0x0@0,0) 16bpp > > > > > fb0: pitch 1312, base 0x5e006000, screen_size 545792 > > > > > fbd0 on fb0 > > > > > VT: initialize with new VT driver "fb". > > > > > > > > Ok. Can you try add the following to /boot/loader.conf ? > > > > > > > > echo hw.bcm2835.sdhci.hs=0 >> /boot/loader.conf > > > > > > > > RPi _is_ picky about the SD card, the patch won't make that go away > > > > but should help in a few cases. > > > > > > I know - that's the reason why I bought the B+ boards in bundle with > > > cards directly from Farnell. > > > Hoped they wouldn't make any problems under FreeBSD. > > > The cards unfortunately are unlabeled, just the included SD adapter > > > has a raspi logo. > > > > > > > There is a possibility that your card won't work in HS mode and now > > > > that the card identification always works, it will always go with the > > > > highest supported speed. The tunable should help if that is the case. > > > > > > This makes sense. > > > I don't remember this card/board combination, but about a year ago, when > > > I used other cards in other boards the speed and width wasn't always the > > > same. > > > > > > And you are absolutely right, with that loader.conf entry it works. > > > ... > > > mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block > > > ... > > > > This is another card from the same order (and hopefully same batch) in a Beaglebone > > Black: > > mmcsd0: 8GB at mmc0 48.0MHz/4bit/65535-block > > Interesting that the Raspberry is so picky about them, since the card clearly is > > capable to do such frequency. > > > > But I miss something on the Raspberry board. > > The B boards clearly have series resistors in the signal lines. > > The B+ has not. > > However the MMC/SD should have some pull up resistors, usually > > around 100k Ohms. > > Following the signals is hard to impossible, but there are no such > > resistors in a reasonable location on neither B nor B+. > > They might be interal in the broadcom SoC, but this is very unusual. > > I consider modding the SD signals on the B+ impossible, but it can > > be done on the B. > > > > -- > > Pullups on sd signal lines is a recent thing. It's in the sd 4.x > physical spec, in the form of requiring the standard sd data lines be > pulled high or low when using the new UHS-II signals. Other than that > pullups are not required on any of the lines for sd cards. At work we > don't put pullups on any of them, and use a 22 ohm series on just the > clock line, and that only on designs where we have to fly across a > ribbon cable to get to the card socket. Can't say since when it is in the SD spec, saw it in the MMC, but don't know how long it is there either. Anyway - I remember them well, because I had to hand wire them on my RM9200 prototype boards. It never had been a problem until Warner added higher speed support, but I don't have series resistors on my boards. > The thing to keep in mind about the rpi sdcard woes is that it all works > in u-boot and in linux. The same cards that fail on freebsd get as far > as loading freebsd... i.e., they worked fine in u-boot and didn't fail > until our driver came along and touched the hardware. If you boot that > same card into linux it'll work fine. Do they run the cards with high clock rates? At least with u-boot there wouldn't be a real problem for them to just don't do high speed probing. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 20:16:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C45BA7C7 for ; Wed, 29 Oct 2014 20:16:33 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D555F4D for ; Wed, 29 Oct 2014 20:16:33 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjZfT-0004cI-QN; Wed, 29 Oct 2014 20:16:32 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9TKGREE081441; Wed, 29 Oct 2014 14:16:27 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX185nB72zJ/1X/mSK2QciS6d X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20141029200403.GC59614@cicely7.cicely.de> References: <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> <20141029200403.GC59614@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Oct 2014 14:16:26 -0600 Message-ID: <1414613786.17308.124.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Andreas Schwarz , George Rosamond , "freebsd-arm@freebsd.org" , Tim Kientzle X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:16:33 -0000 On Wed, 2014-10-29 at 21:04 +0100, Bernd Walter wrote: > On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote: > > On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: > > > On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > > > > On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > > > > > On 22 October 2014 18:44, Bernd Walter wrote: > > > > > > On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > > > > > >> On 14 October 2014 01:13, Bernd Walter wrote: > > > > > >> > > > > > > >> > Ok - that card problem seems random or contact related. > > > > > >> > Whatever, it is 6 am - time to sleep ;-) > > > > > >> > > > > > >> I've found a missing silicon bug workaround on our driver. > > > > > >> > > > > > >> It's pretty recent and i'm still building new images to test with more > > > > > >> cards, but it did fix all the instability i was seeing on the > > > > > >> identification of one of my cards. > > > > > >> > > > > > >> Together with the new firmware (yes, there is another SD fix there) my > > > > > >> RPi B rev 2 (with this same card) has gone from unusable to rock > > > > > >> stable (i've done 80 cold boots without any damage/corruption to the > > > > > >> card). > > > > > >> > > > > > >> Please, give it a try and let me know if it helps. > > > > > > > > > > > > Tested. > > > > > > All I can say so far is that it is random, but your patch didn't help. > > > > > > > > > > Without my patch you should see the speed and the bus width changing > > > > > over the boots and with my patch it should always be the same > > > > > (41.6MHz/4bit): > > > > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > > > > > > > > Furthermore this problem now happens on each boot try. > > > > > > It still may be possible that it can boot, but I've tried many more > > > > > > times than needed before. > > > > > > > > > > > > Timecounters tick every 10.000 msec > > > > > > usbus0: 480Mbps High Speed USB v2.0 > > > > > > ugen0.1: at usbus0 > > > > > > uhub0: on usbus0 > > > > > > mmcsd0: 8GB at mmc0 41.6MHz/4bit/65535-block > > > > > > mmcsd0: Error indicated: 1 Timeout > > > > > > mmcsd0: Error indicated: 1 Timeout > > > > > > fb0: 656x416(0x0@0,0) 16bpp > > > > > > fb0: pitch 1312, base 0x5e006000, screen_size 545792 > > > > > > fbd0 on fb0 > > > > > > VT: initialize with new VT driver "fb". > > > > > > > > > > Ok. Can you try add the following to /boot/loader.conf ? > > > > > > > > > > echo hw.bcm2835.sdhci.hs=0 >> /boot/loader.conf > > > > > > > > > > RPi _is_ picky about the SD card, the patch won't make that go away > > > > > but should help in a few cases. > > > > > > > > I know - that's the reason why I bought the B+ boards in bundle with > > > > cards directly from Farnell. > > > > Hoped they wouldn't make any problems under FreeBSD. > > > > The cards unfortunately are unlabeled, just the included SD adapter > > > > has a raspi logo. > > > > > > > > > There is a possibility that your card won't work in HS mode and now > > > > > that the card identification always works, it will always go with the > > > > > highest supported speed. The tunable should help if that is the case. > > > > > > > > This makes sense. > > > > I don't remember this card/board combination, but about a year ago, when > > > > I used other cards in other boards the speed and width wasn't always the > > > > same. > > > > > > > > And you are absolutely right, with that loader.conf entry it works. > > > > ... > > > > mmcsd0: 8GB at mmc0 25.0MHz/4bit/65535-block > > > > ... > > > > > > This is another card from the same order (and hopefully same batch) in a Beaglebone > > > Black: > > > mmcsd0: 8GB at mmc0 48.0MHz/4bit/65535-block > > > Interesting that the Raspberry is so picky about them, since the card clearly is > > > capable to do such frequency. > > > > > > But I miss something on the Raspberry board. > > > The B boards clearly have series resistors in the signal lines. > > > The B+ has not. > > > However the MMC/SD should have some pull up resistors, usually > > > around 100k Ohms. > > > Following the signals is hard to impossible, but there are no such > > > resistors in a reasonable location on neither B nor B+. > > > They might be interal in the broadcom SoC, but this is very unusual. > > > I consider modding the SD signals on the B+ impossible, but it can > > > be done on the B. > > > > > > -- > > > > Pullups on sd signal lines is a recent thing. It's in the sd 4.x > > physical spec, in the form of requiring the standard sd data lines be > > pulled high or low when using the new UHS-II signals. Other than that > > pullups are not required on any of the lines for sd cards. At work we > > don't put pullups on any of them, and use a 22 ohm series on just the > > clock line, and that only on designs where we have to fly across a > > ribbon cable to get to the card socket. > > Can't say since when it is in the SD spec, saw it in the MMC, but don't > know how long it is there either. > Anyway - I remember them well, because I had to hand wire them on my > RM9200 prototype boards. > It never had been a problem until Warner added higher speed support, but > I don't have series resistors on my boards. > > > The thing to keep in mind about the rpi sdcard woes is that it all works > > in u-boot and in linux. The same cards that fail on freebsd get as far > > as loading freebsd... i.e., they worked fine in u-boot and didn't fail > > until our driver came along and touched the hardware. If you boot that > > same card into linux it'll work fine. > > Do they run the cards with high clock rates? > At least with u-boot there wouldn't be a real problem for them to just > don't do high speed probing. > U-boot and linux both run the card at full speed... 400khz during identification, then 50mhz for cards which support it (which is virtually every card these days, certainly every card larger than 2gb). I verified the clock rates with a 'scope back when I was debugging hard on this problem, thinking that we were somehow setting the wrong rates in the driver. The signals looked right, so I think the problem must be in the timing or sequence of commands we send to the host controller. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 20:59:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 015DA7A0 for ; Wed, 29 Oct 2014 20:59:23 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BA0F7638 for ; Wed, 29 Oct 2014 20:59:23 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id kx10so3932823pab.40 for ; Wed, 29 Oct 2014 13:59:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=QUgcJmc89iMHJajlmqFnd06kKTVCuYY8tLjo8zni4AI=; b=jVxYxpiFgwxhVmHbeyGlz2NkrQlCCu8lMYPfbqbegrRn/c15vTmLwyabS1Crg9L3+E /ZgAvFFVnpA3lbX+dv3kQ4uK3wBez/owoMCcZzmGFpiYw2qFbYNsFu+jOWzkMwvkF4YC 0hqB+1Yz3v2PfSRWnb8JhnZOe2oGKYEho3AF5DbQPAcXY2mkBpM4C/MmDwJ8oLR/smRY nodnCrUd09FJgsHmF8qYm/fRqs5R30Ek+4ux9gi1PvLFxrPiHsjrP1bg8J9hi4W0/fOl pXqRLnpTUjUSdaXAUnulN7N2Crto0QOqjehQ25zl/2Wtylm2k8vqVnQdDx43zCkQT6u9 b7LA== X-Gm-Message-State: ALoCoQkTMajGBGqzxFozozG0XfTiCbsIOic1pKweGrpYWJcTLu9gNS3878q7pb6H2ytGqKZrPIyC X-Received: by 10.66.102.2 with SMTP id fk2mr4156608pab.143.1414616357161; Wed, 29 Oct 2014 13:59:17 -0700 (PDT) Received: from [10.64.27.26] (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id kv10sm5171391pab.23.2014.10.29.13.59.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 Oct 2014 13:59:16 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_AB56FC0D-97C9-4AD5-A351-732A2C752617"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices From: Warner Losh In-Reply-To: <1414613786.17308.124.camel@revolution.hippie.lan> Date: Wed, 29 Oct 2014 14:59:13 -0600 Message-Id: <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> References: <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> <20141029200403.GC59614@cicely7.cicely.de> <1414613786.17308.124.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1878.6) Cc: Andreas Schwarz , George Rosamond , "freebsd-arm@freebsd.org" , ticso@cicely.de, Tim Kientzle X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 20:59:24 -0000 --Apple-Mail=_AB56FC0D-97C9-4AD5-A351-732A2C752617 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Oct 29, 2014, at 2:16 PM, Ian Lepore wrote: > On Wed, 2014-10-29 at 21:04 +0100, Bernd Walter wrote: >> On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote: >>> On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: >>>> On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: >>>>> On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza = wrote: >>>>>> On 22 October 2014 18:44, Bernd Walter wrote: >>>>>>> On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza = wrote: >>>>>>>> On 14 October 2014 01:13, Bernd Walter wrote: >>>>>>>>>=20 >>>>>>>>> Ok - that card problem seems random or contact related. >>>>>>>>> Whatever, it is 6 am - time to sleep ;-) >>>>>>>>=20 >>>>>>>> I've found a missing silicon bug workaround on our driver. >>>>>>>>=20 >>>>>>>> It's pretty recent and i'm still building new images to test = with more >>>>>>>> cards, but it did fix all the instability i was seeing on the >>>>>>>> identification of one of my cards. >>>>>>>>=20 >>>>>>>> Together with the new firmware (yes, there is another SD fix = there) my >>>>>>>> RPi B rev 2 (with this same card) has gone from unusable to = rock >>>>>>>> stable (i've done 80 cold boots without any damage/corruption = to the >>>>>>>> card). >>>>>>>>=20 >>>>>>>> Please, give it a try and let me know if it helps. >>>>>>>=20 >>>>>>> Tested. >>>>>>> All I can say so far is that it is random, but your patch didn't = help. >>>>>>=20 >>>>>> Without my patch you should see the speed and the bus width = changing >>>>>> over the boots and with my patch it should always be the same >>>>>> (41.6MHz/4bit): >>>>>>> mmcsd0: 8GB at = mmc0 41.6MHz/4bit/65535-block >>>>>>=20 >>>>>>> Furthermore this problem now happens on each boot try. >>>>>>> It still may be possible that it can boot, but I've tried many = more >>>>>>> times than needed before. >>>>>>>=20 >>>>>>> Timecounters tick every 10.000 msec >>>>>>> usbus0: 480Mbps High Speed USB v2.0 >>>>>>> ugen0.1: at usbus0 >>>>>>> uhub0: = on usbus0 >>>>>>> mmcsd0: 8GB at = mmc0 41.6MHz/4bit/65535-block >>>>>>> mmcsd0: Error indicated: 1 Timeout >>>>>>> mmcsd0: Error indicated: 1 Timeout >>>>>>> fb0: 656x416(0x0@0,0) 16bpp >>>>>>> fb0: pitch 1312, base 0x5e006000, screen_size 545792 >>>>>>> fbd0 on fb0 >>>>>>> VT: initialize with new VT driver "fb". >>>>>>=20 >>>>>> Ok. Can you try add the following to /boot/loader.conf ? >>>>>>=20 >>>>>> echo hw.bcm2835.sdhci.hs=3D0 >> /boot/loader.conf >>>>>>=20 >>>>>> RPi _is_ picky about the SD card, the patch won't make that go = away >>>>>> but should help in a few cases. >>>>>=20 >>>>> I know - that's the reason why I bought the B+ boards in bundle = with >>>>> cards directly from Farnell. >>>>> Hoped they wouldn't make any problems under FreeBSD. >>>>> The cards unfortunately are unlabeled, just the included SD = adapter >>>>> has a raspi logo. >>>>>=20 >>>>>> There is a possibility that your card won't work in HS mode and = now >>>>>> that the card identification always works, it will always go with = the >>>>>> highest supported speed. The tunable should help if that is the = case. >>>>>=20 >>>>> This makes sense. >>>>> I don't remember this card/board combination, but about a year = ago, when >>>>> I used other cards in other boards the speed and width wasn't = always the >>>>> same. >>>>>=20 >>>>> And you are absolutely right, with that loader.conf entry it = works. >>>>> ... >>>>> mmcsd0: 8GB at = mmc0 25.0MHz/4bit/65535-block >>>>> ... >>>>=20 >>>> This is another card from the same order (and hopefully same batch) = in a Beaglebone >>>> Black: >>>> mmcsd0: 8GB at = mmc0 48.0MHz/4bit/65535-block >>>> Interesting that the Raspberry is so picky about them, since the = card clearly is >>>> capable to do such frequency. >>>>=20 >>>> But I miss something on the Raspberry board. >>>> The B boards clearly have series resistors in the signal lines. >>>> The B+ has not. >>>> However the MMC/SD should have some pull up resistors, usually >>>> around 100k Ohms. >>>> Following the signals is hard to impossible, but there are no such >>>> resistors in a reasonable location on neither B nor B+. >>>> They might be interal in the broadcom SoC, but this is very = unusual. >>>> I consider modding the SD signals on the B+ impossible, but it can >>>> be done on the B. >>>>=20 >>>> --=20 >>>=20 >>> Pullups on sd signal lines is a recent thing. It's in the sd 4.x >>> physical spec, in the form of requiring the standard sd data lines = be >>> pulled high or low when using the new UHS-II signals. Other than = that >>> pullups are not required on any of the lines for sd cards. At work = we >>> don't put pullups on any of them, and use a 22 ohm series on just = the >>> clock line, and that only on designs where we have to fly across a >>> ribbon cable to get to the card socket. >>=20 >> Can't say since when it is in the SD spec, saw it in the MMC, but = don't >> know how long it is there either. >> Anyway - I remember them well, because I had to hand wire them on my >> RM9200 prototype boards. >> It never had been a problem until Warner added higher speed support, = but >> I don't have series resistors on my boards. High speed on the RM9200 boards was always a bit dodgy anyway. :( Sorry = for the hassle. >>> The thing to keep in mind about the rpi sdcard woes is that it all = works >>> in u-boot and in linux. The same cards that fail on freebsd get as = far >>> as loading freebsd... i.e., they worked fine in u-boot and didn't = fail >>> until our driver came along and touched the hardware. If you boot = that >>> same card into linux it'll work fine. >>=20 >> Do they run the cards with high clock rates? >> At least with u-boot there wouldn't be a real problem for them to = just >> don't do high speed probing. >>=20 >=20 > U-boot and linux both run the card at full speed... 400khz during > identification, then 50mhz for cards which support it (which is > virtually every card these days, certainly every card larger than = 2gb). > I verified the clock rates with a 'scope back when I was debugging = hard > on this problem, thinking that we were somehow setting the wrong rates > in the driver. The signals looked right, so I think the problem must = be > in the timing or sequence of commands we send to the host controller. There have bugs in the past where we transition to the new speed at the wrong time, which caused issues. That might be a fruitful avenue of = inquiry. Warner --Apple-Mail=_AB56FC0D-97C9-4AD5-A351-732A2C752617 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----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUUVUhAAoJEGwc0Sh9sBEA+uAQAKucpdVfyJk1NcAxGUmQLkcS zRSSjTsDYcBxb0h6mdxNgsY61RzP6kCvCSRA0ryOVv9h9yst6SZNKjStxXgh5yc+ Oge+/f/9BwKpQpzNrJ6aM4YIu4SDogklFDmH8Lwe2+zpE/NV1Bt2uxWLnqUawDHf cudQy8SuWnVYCiZQD7P+8MN66uOpnsYTrW1d/AvsD2fQ/iAEnbJ+txa2idaEAzDV y9m3RZyxUFcFhx1kWA9+Ktl+1W4i7Hf4+7qGgJ8MRpef0RPSTG0fFX6AwaJaOizr Acc1cVcX2RxAt6Hl23pvNGYohgFSj+mn5BZKk8QqSSnFTIFMjAJElmIgNc8eQGdM aUKzhfLixe79Xva6mZOPQeFZ07/q6Izu3A4a5uN766KH5B8l62Y+l+L1O1i5O32U xZv219VCVXFYkHXo8+oHfgAB7vInxbXikq6cTh+R8Juyrm3O6WwJZ9ziowYSSfUE IvHPUHgZEi+xmg1M4yH3+J3C05CgjHh+RnQbFa2NzjyJjTAZcADgNL3UF+9s7Lks 0/os6CwiXhfg3KoQJKChpwZxrDKRmqzzLSacmOp2NYMZvbiqmLXbPXCdtwINiCkv CR6rDwIHYDiJMKTvLoBRH7cN2JWVbsxHhUZX3X/gopnTu8twvhbuoi2MkcKG41qg 6wDACJbLpEqXcqW2O4GU =OlDb -----END PGP SIGNATURE----- --Apple-Mail=_AB56FC0D-97C9-4AD5-A351-732A2C752617-- From owner-freebsd-arm@FreeBSD.ORG Wed Oct 29 21:27:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38A4D375 for ; Wed, 29 Oct 2014 21:27:21 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 043E29C7 for ; Wed, 29 Oct 2014 21:27:19 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Xjaly-000CgX-K3; Wed, 29 Oct 2014 21:27:18 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9TLRG8g081542; Wed, 29 Oct 2014 15:27:16 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 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/K8tl1YfNlfa0+Bbn9e/X2 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices From: Ian Lepore To: Warner Losh In-Reply-To: <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> References: <53FD1646.2010103@ceetonetechnology.com> <20140827021349.1273f703c6756d07fad72a16@schwarzes.net> <20141014032743.GK38905@cicely7.cicely.de> <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> <20141029200403.GC59614@cicely7.cicely.de> <1414613786.17308.124.camel@revolution.hippie.lan> <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 29 Oct 2014 15:27:16 -0600 Message-ID: <1414618036.17308.146.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" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Oct 2014 21:27:21 -0000 On Wed, 2014-10-29 at 14:59 -0600, Warner Losh wrote: > On Oct 29, 2014, at 2:16 PM, Ian Lepore wrote: > > > On Wed, 2014-10-29 at 21:04 +0100, Bernd Walter wrote: > >> On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote: > >>> On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: > >>>> On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > >>>>> On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > >>>>>> On 22 October 2014 18:44, Bernd Walter wrote: > >>>>>>> On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > >>>>>>>> On 14 October 2014 01:13, Bernd Walter wrote: [...] > >>> > >>> Pullups on sd signal lines is a recent thing. It's in the sd 4.x > >>> physical spec, in the form of requiring the standard sd data lines be > >>> pulled high or low when using the new UHS-II signals. Other than that > >>> pullups are not required on any of the lines for sd cards. At work we > >>> don't put pullups on any of them, and use a 22 ohm series on just the > >>> clock line, and that only on designs where we have to fly across a > >>> ribbon cable to get to the card socket. > >> > >> Can't say since when it is in the SD spec, saw it in the MMC, but don't > >> know how long it is there either. > >> Anyway - I remember them well, because I had to hand wire them on my > >> RM9200 prototype boards. > >> It never had been a problem until Warner added higher speed support, but > >> I don't have series resistors on my boards. > > High speed on the RM9200 boards was always a bit dodgy anyway. :( Sorry for the hassle. > Actually high-speed works fine by itself, it's the combo of high-speed and 4-wire that's problematic, because of dma overruns. It's especially bad when usb is also active, because it gets priority on the bus. If the mci dma doesn't get a bus-grant in time, it's not smart enough to stop the clock to the card, and it just looses data instead. All in all, the max reliable data rate is around 3 MB/sec when usb is enabled. -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 01:15:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 79BF4B35 for ; Thu, 30 Oct 2014 01:15:22 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C309688 for ; Thu, 30 Oct 2014 01:15:22 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NE800184GSXGV60@st11p02mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Thu, 30 Oct 2014 01:15:00 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-30_01:2014-10-29,2014-10-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410300012 Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-type: text/plain; charset=us-ascii From: Rui Paulo X-Priority: 3 In-reply-to: Date: Wed, 29 Oct 2014 18:14:57 -0700 Content-transfer-encoding: quoted-printable Message-id: <8463BC91-E979-432C-8EC3-EB676F3EE5CD@me.com> References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:15:22 -0000 On Oct 29, 2014, at 12:10, Daisuke Aoyama wrote: > Mailbox property interface > = https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface > is not only CPU frequencies. But mbox_if have no method for it. What method do you suggest? The mbox interface is very crude and naive = (I know, I wrote it) since it was just a stop gap measure to introduce = something common in the ARM SoC code. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 01:17:38 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B993DB9E for ; Thu, 30 Oct 2014 01:17:38 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C26169A for ; Thu, 30 Oct 2014 01:17:37 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NE800NUNGWR3O10@st11p02mm-asmtp001.mac.com> for freebsd-arm@freebsd.org; Thu, 30 Oct 2014 01:17:17 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-30_01:2014-10-29,2014-10-29,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410300012 Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-type: text/plain; charset=us-ascii From: Rui Paulo X-Priority: 3 In-reply-to: Date: Wed, 29 Oct 2014 18:17:14 -0700 Content-transfer-encoding: quoted-printable Message-id: <7946CCA3-26D0-4B6E-AEBB-8623CAAA9725@me.com> References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 01:17:38 -0000 On Oct 29, 2014, at 12:10, Daisuke Aoyama wrote: > Updated source and kernel: > http://www.peach.ne.jp/archives/rpi/patch/bcm2835_cpufreq.c > http://www.peach.ne.jp/archives/rpi/patch/bcm2835_mbox_prop.h > http://www.peach.ne.jp/archives/rpi/kernel/kernel-20141030.gz This code is now up for review at: https://reviews.freebsd.org/D1025 Aoyama-san, please keep an eye on this URL since there's no way for = non-committers to subscribe to changes (yet). -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 02:19:53 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2A5E258; Thu, 30 Oct 2014 02:19:53 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B5C0C35; Thu, 30 Oct 2014 02:19:52 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s9U2J6sa003279 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2014 03:19:06 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s9U2Iw2V045853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 03:18:58 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s9U2IwWP063529; Thu, 30 Oct 2014 03:18:58 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s9U2IvnW063528; Thu, 30 Oct 2014 03:18:57 +0100 (CET) (envelope-from ticso) Date: Thu, 30 Oct 2014 03:18:57 +0100 From: Bernd Walter To: Warner Losh Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <20141030021857.GD59614@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> <20141029200403.GC59614@cicely7.cicely.de> <1414613786.17308.124.camel@revolution.hippie.lan> <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Andreas Schwarz , George Rosamond , Ian Lepore , Tim Kientzle , "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 02:19:53 -0000 On Wed, Oct 29, 2014 at 02:59:13PM -0600, Warner Losh wrote: > > On Oct 29, 2014, at 2:16 PM, Ian Lepore wrote: > > > On Wed, 2014-10-29 at 21:04 +0100, Bernd Walter wrote: > >> On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote: > >>> On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: > >>>> On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > >>>>> On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > >>>>>> On 22 October 2014 18:44, Bernd Walter wrote: > >>>>>>> On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > >>>>>>>> On 14 October 2014 01:13, Bernd Walter wrote: > >>> > >>> Pullups on sd signal lines is a recent thing. It's in the sd 4.x > >>> physical spec, in the form of requiring the standard sd data lines be > >>> pulled high or low when using the new UHS-II signals. Other than that > >>> pullups are not required on any of the lines for sd cards. At work we > >>> don't put pullups on any of them, and use a 22 ohm series on just the > >>> clock line, and that only on designs where we have to fly across a > >>> ribbon cable to get to the card socket. > >> > >> Can't say since when it is in the SD spec, saw it in the MMC, but don't > >> know how long it is there either. > >> Anyway - I remember them well, because I had to hand wire them on my > >> RM9200 prototype boards. > >> It never had been a problem until Warner added higher speed support, but > >> I don't have series resistors on my boards. > > High speed on the RM9200 boards was always a bit dodgy anyway. :( Sorry for the hassle. Sorry? No - you had been just in time to catch this hardware problem as prototype. > >>> The thing to keep in mind about the rpi sdcard woes is that it all works > >>> in u-boot and in linux. The same cards that fail on freebsd get as far > >>> as loading freebsd... i.e., they worked fine in u-boot and didn't fail > >>> until our driver came along and touched the hardware. If you boot that > >>> same card into linux it'll work fine. > >> > >> Do they run the cards with high clock rates? > >> At least with u-boot there wouldn't be a real problem for them to just > >> don't do high speed probing. > >> > > > > U-boot and linux both run the card at full speed... 400khz during > > identification, then 50mhz for cards which support it (which is > > virtually every card these days, certainly every card larger than 2gb). > > I verified the clock rates with a 'scope back when I was debugging hard > > on this problem, thinking that we were somehow setting the wrong rates > > in the driver. The signals looked right, so I think the problem must be > > in the timing or sequence of commands we send to the host controller. Well... If you scope checked the frequency, it works with other software and with another controller, then it must be some strange kind of controller software handling problem. The Raspi is not a board with high speed expectations anyway. Probably we should default the highspeed sysctl to false instead of true until there is a fallback or fix. Btw I have a hardkernel board with this broadcom chip - it looks like it has pull ups... Never powered it up so far - it is said to be software compatible with the raspberry. It has a micro SD slot and a connector for an eMMC board, not sure if there is a second controller or you can't use both at the same time. Will give it a try during the next days. > There have bugs in the past where we transition to the new speed at the > wrong time, which caused issues. That might be a fruitful avenue of inquiry. I hate such bugs :-( -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 10:35:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D44436B5 for ; Thu, 30 Oct 2014 10:35:22 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9F8E275C for ; Thu, 30 Oct 2014 10:35:22 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 5452A39D36; Thu, 30 Oct 2014 19:35:14 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id 4CDD839D09; Thu, 30 Oct 2014 19:35:14 +0900 (JST) Message-ID: <840772A7305444C1B1AF7CE31A89BD7D@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Rui Paulo" References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> <7946CCA3-26D0-4B6E-AEBB-8623CAAA9725@me.com> In-Reply-To: <7946CCA3-26D0-4B6E-AEBB-8623CAAA9725@me.com> Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB Date: Thu, 30 Oct 2014 19:35:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 10:35:22 -0000 > This code is now up for review at: > > https://reviews.freebsd.org/D1025 There is some comment. About build error: It requires the patch of bcm2835_mbox.h in http://www.peach.ne.jp/archives/rpi/patch/src-r273303-20141026.patch.gz for build dependency and the patch of bcm2835_mbox.c for run dependency. Showing boot settings: The initial values are intended to use for manual tuning via hw.cpufreq. Especially, using it in the turbo state ON. (force_turbo=1 in config.txt before booting) This is different from other cpufreq drivers. Writing core clock twice: I didn't know a reason. At least, very long delay is not worked. DELAY: It is put on various places for safety after set property. (power consumption may change. don't want change without interval) Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 12:54:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4057351F; Thu, 30 Oct 2014 12:54:11 +0000 (UTC) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1028822; Thu, 30 Oct 2014 12:54:10 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id ex7so4441007wid.8 for ; Thu, 30 Oct 2014 05:54: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=ylSrnNsNkqDYzFsxvQP+1P0PVRoqgahfwGFlvrnk+cw=; b=UyWs3RD84U4Sm/8CnnH8mY5WQrU1xYNAtkhID5I/pqnNMyQtgevyfKL82UtHHnEBK9 d63fdsry8oblnQz+aQ5b60RbW1zHOWHXXl57idhgjBFtjoa6KnZcZRBTOeGVF6JYE0Of v0f4X2aO2rZs09XG6puyeYlRUGIA+hfzNLML9eq5SULFQ0pS5tRQDD8W56J1j0XiDzko ZWlyxCQhZHqG1jYCO5SwKgjO4oS2Px+GVUvQ6EGo0ujdj7KvriOQfsUXp4NWO4P4xk5p mlm+Vd7XeEOOKhcSg1IFHqRvfHVya/Xb3bmpNzEmmCptMG7b1ZR1rPY+k3br2AIfP9uu u3RQ== MIME-Version: 1.0 X-Received: by 10.180.126.9 with SMTP id mu9mr44106272wib.38.1414673649002; Thu, 30 Oct 2014 05:54:09 -0700 (PDT) Received: by 10.216.127.72 with HTTP; Thu, 30 Oct 2014 05:54:08 -0700 (PDT) In-Reply-To: <20141030021857.GD59614@cicely7.cicely.de> References: <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> <20141029200403.GC59614@cicely7.cicely.de> <1414613786.17308.124.camel@revolution.hippie.lan> <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> <20141030021857.GD59614@cicely7.cicely.de> Date: Thu, 30 Oct 2014 10:54:08 -0200 Message-ID: Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices From: Luiz Otavio O Souza To: ticso@cicely.de Content-Type: text/plain; charset=UTF-8 Cc: Andreas Schwarz , George Rosamond , Ian Lepore , Tim Kientzle , "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 12:54:11 -0000 On 30 October 2014 00:18, Bernd Walter wrote: > On Wed, Oct 29, 2014 at 02:59:13PM -0600, Warner Losh wrote: >> >> On Oct 29, 2014, at 2:16 PM, Ian Lepore wrote: >> >> > On Wed, 2014-10-29 at 21:04 +0100, Bernd Walter wrote: >> >> On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote: >> >>> On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: >> >>>> On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: >> >>>>> On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: >> >>>>>> On 22 October 2014 18:44, Bernd Walter wrote: >> >>>>>>> On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: >> >>>>>>>> On 14 October 2014 01:13, Bernd Walter wrote: >> >>> >> >>> Pullups on sd signal lines is a recent thing. It's in the sd 4.x >> >>> physical spec, in the form of requiring the standard sd data lines be >> >>> pulled high or low when using the new UHS-II signals. Other than that >> >>> pullups are not required on any of the lines for sd cards. At work we >> >>> don't put pullups on any of them, and use a 22 ohm series on just the >> >>> clock line, and that only on designs where we have to fly across a >> >>> ribbon cable to get to the card socket. >> >> >> >> Can't say since when it is in the SD spec, saw it in the MMC, but don't >> >> know how long it is there either. >> >> Anyway - I remember them well, because I had to hand wire them on my >> >> RM9200 prototype boards. >> >> It never had been a problem until Warner added higher speed support, but >> >> I don't have series resistors on my boards. >> >> High speed on the RM9200 boards was always a bit dodgy anyway. :( Sorry for the hassle. > > Sorry? > No - you had been just in time to catch this hardware problem as prototype. > >> >>> The thing to keep in mind about the rpi sdcard woes is that it all works >> >>> in u-boot and in linux. The same cards that fail on freebsd get as far >> >>> as loading freebsd... i.e., they worked fine in u-boot and didn't fail >> >>> until our driver came along and touched the hardware. If you boot that >> >>> same card into linux it'll work fine. >> >> >> >> Do they run the cards with high clock rates? >> >> At least with u-boot there wouldn't be a real problem for them to just >> >> don't do high speed probing. >> >> >> > >> > U-boot and linux both run the card at full speed... 400khz during >> > identification, then 50mhz for cards which support it (which is >> > virtually every card these days, certainly every card larger than 2gb). >> > I verified the clock rates with a 'scope back when I was debugging hard >> > on this problem, thinking that we were somehow setting the wrong rates >> > in the driver. The signals looked right, so I think the problem must be >> > in the timing or sequence of commands we send to the host controller. > > Well... > If you scope checked the frequency, it works with other software and > with another controller, then it must be some strange kind of controller > software handling problem. > The Raspi is not a board with high speed expectations anyway. > Probably we should default the highspeed sysctl to false instead of true > until there is a fallback or fix. I tried to check the SD clock frequency with the scope and just by connecting the probe on the SD clock line the card that was previously working flawless, start to exhibit some i/o errors, so i guess it is pretty sensible to capacitance load on that line (that may explain why they removed the series resistor). This lead me into another issue, where i get reading errors from card (because of the scope probe) and even when errors do not affect the filesystem neither the system (as in dd if=/dev/mmcsd0 of=/dev/zero bs=1m), the controller cannot recover from the first error and you need to reboot. If this is a real error (I cannot reproduce it reliably yet), it would explain a lot. I'll take care of change the high speed default setting for now. > > Btw I have a hardkernel board with this broadcom chip - it looks like > it has pull ups... > Never powered it up so far - it is said to be software compatible with > the raspberry. > It has a micro SD slot and a connector for an eMMC board, not sure if > there is a second controller or you can't use both at the same time. > Will give it a try during the next days. I have asked about the pull-ups before, but from nxp's AN10911, I infer that they are used for interface conditioning (ESD and EMI): http://www.nxp.com/documents/application_note/AN10911.pdf > >> There have bugs in the past where we transition to the new speed at the >> wrong time, which caused issues. That might be a fruitful avenue of inquiry. > > I hate such bugs :-( So do i :) Luiz From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 13:56:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 231CE368 for ; Thu, 30 Oct 2014 13:56:45 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CE821DD7 for ; Thu, 30 Oct 2014 13:56:44 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjqDO-000Ajv-68; Thu, 30 Oct 2014 13:56:38 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9UDuZVe083124; Thu, 30 Oct 2014 07:56:35 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19nO0hRaxD49dT4zrJY5+tS X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices From: Ian Lepore To: Luiz Otavio O Souza In-Reply-To: References: <20141014041305.GM38905@cicely7.cicely.de> <20141022204454.GA12231@cicely7.cicely.de> <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> <20141029200403.GC59614@cicely7.cicely.de> <1414613786.17308.124.camel@revolution.hippie.lan> <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> <20141030021857.GD59614@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 2014 07:56:35 -0600 Message-ID: <1414677395.17308.155.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Andreas Schwarz , George Rosamond , Tim Kientzle , "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 13:56:45 -0000 On Thu, 2014-10-30 at 10:54 -0200, Luiz Otavio O Souza wrote: > On 30 October 2014 00:18, Bernd Walter wrote: > > On Wed, Oct 29, 2014 at 02:59:13PM -0600, Warner Losh wrote: > >> > >> On Oct 29, 2014, at 2:16 PM, Ian Lepore wrote: > >> > >> > On Wed, 2014-10-29 at 21:04 +0100, Bernd Walter wrote: > >> >> On Wed, Oct 29, 2014 at 11:58:21AM -0600, Ian Lepore wrote: > >> >>> On Wed, 2014-10-29 at 18:29 +0100, Bernd Walter wrote: > >> >>>> On Thu, Oct 23, 2014 at 04:22:44AM +0200, Bernd Walter wrote: > >> >>>>> On Wed, Oct 22, 2014 at 11:43:01PM -0200, Luiz Otavio O Souza wrote: > >> >>>>>> On 22 October 2014 18:44, Bernd Walter wrote: > >> >>>>>>> On Tue, Oct 14, 2014 at 12:51:50PM -0300, Luiz Otavio O Souza wrote: > >> >>>>>>>> On 14 October 2014 01:13, Bernd Walter wrote: > >> >>> > >> >>> Pullups on sd signal lines is a recent thing. It's in the sd 4.x > >> >>> physical spec, in the form of requiring the standard sd data lines be > >> >>> pulled high or low when using the new UHS-II signals. Other than that > >> >>> pullups are not required on any of the lines for sd cards. At work we > >> >>> don't put pullups on any of them, and use a 22 ohm series on just the > >> >>> clock line, and that only on designs where we have to fly across a > >> >>> ribbon cable to get to the card socket. > >> >> > >> >> Can't say since when it is in the SD spec, saw it in the MMC, but don't > >> >> know how long it is there either. > >> >> Anyway - I remember them well, because I had to hand wire them on my > >> >> RM9200 prototype boards. > >> >> It never had been a problem until Warner added higher speed support, but > >> >> I don't have series resistors on my boards. > >> > >> High speed on the RM9200 boards was always a bit dodgy anyway. :( Sorry for the hassle. > > > > Sorry? > > No - you had been just in time to catch this hardware problem as prototype. > > > >> >>> The thing to keep in mind about the rpi sdcard woes is that it all works > >> >>> in u-boot and in linux. The same cards that fail on freebsd get as far > >> >>> as loading freebsd... i.e., they worked fine in u-boot and didn't fail > >> >>> until our driver came along and touched the hardware. If you boot that > >> >>> same card into linux it'll work fine. > >> >> > >> >> Do they run the cards with high clock rates? > >> >> At least with u-boot there wouldn't be a real problem for them to just > >> >> don't do high speed probing. > >> >> > >> > > >> > U-boot and linux both run the card at full speed... 400khz during > >> > identification, then 50mhz for cards which support it (which is > >> > virtually every card these days, certainly every card larger than 2gb). > >> > I verified the clock rates with a 'scope back when I was debugging hard > >> > on this problem, thinking that we were somehow setting the wrong rates > >> > in the driver. The signals looked right, so I think the problem must be > >> > in the timing or sequence of commands we send to the host controller. > > > > Well... > > If you scope checked the frequency, it works with other software and > > with another controller, then it must be some strange kind of controller > > software handling problem. > > The Raspi is not a board with high speed expectations anyway. > > Probably we should default the highspeed sysctl to false instead of true > > until there is a fallback or fix. > > I tried to check the SD clock frequency with the scope and just by > connecting the probe on the SD clock line the card that was previously > working flawless, start to exhibit some i/o errors, so i guess it is > pretty sensible to capacitance load on that line (that may explain why > they removed the series resistor). > > This lead me into another issue, where i get reading errors from card > (because of the scope probe) and even when errors do not affect the > filesystem neither the system (as in dd if=/dev/mmcsd0 of=/dev/zero > bs=1m), the controller cannot recover from the first error and you > need to reboot. > > If this is a real error (I cannot reproduce it reliably yet), it would > explain a lot. > Is your probe set for 10x mode? When I first looked at the clock and data signals on the rpi sdcard they looked horrible, the waveforms were anything but square. I thought I was on to something at first, maybe the board was just too underpowered. But eventually I realized I had the probe set to 1x mode and it was pulling too much current off the lines. When I switched it to 10x everything looked good. (Maybe all of this is a no-brainer to a hardware person. I'm a software person with just enough hardware knowledge to confuse himself.) -- Ian > I'll take care of change the high speed default setting for now. > > > > > Btw I have a hardkernel board with this broadcom chip - it looks like > > it has pull ups... > > Never powered it up so far - it is said to be software compatible with > > the raspberry. > > It has a micro SD slot and a connector for an eMMC board, not sure if > > there is a second controller or you can't use both at the same time. > > Will give it a try during the next days. > > I have asked about the pull-ups before, but from nxp's AN10911, I > infer that they are used for interface conditioning (ESD and EMI): > > http://www.nxp.com/documents/application_note/AN10911.pdf > > > > >> There have bugs in the past where we transition to the new speed at the > >> wrong time, which caused issues. That might be a fruitful avenue of inquiry. > > > > I hate such bugs :-( > > So do i :) > > Luiz From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 17:15:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5091BFB for ; Thu, 30 Oct 2014 17:15:22 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 10B0D805 for ; Thu, 30 Oct 2014 17:15:21 +0000 (UTC) Received: from 127.0.0.1 (bolobolo2.torservers.net [96.47.226.21]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id s9UHIaNR053124 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Thu, 30 Oct 2014 13:18:39 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Message-ID: <54527218.2090008@ceetonetechnology.com> Date: Thu, 30 Oct 2014 13:15:04 -0400 From: George Rosamond MIME-Version: 1.0 To: "freebsd-arm@freebsd.org" Subject: building cross-compiling tools on -CURRENT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:15:22 -0000 Using a new build box running head with r273764, and running into an issue building the cross compiler tools. Using source based in /usr/src on an amd64 box. I do have devel/gperf installed as per /usr/src/UPDATING. Running this from /usr/src: make TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 WITH_GCC_BOOTSTRAP=1 WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev I changed "XDEV" and "XDEV_ARCH to "TARGET" and "TARGET_ARCH" as per /usr/src/UPDATING from 20140723, but also tried "XDEV" "XDEV_ARCH". If I'm reading this right, Crochet should take that into account. I did clear out /usr/obj, updated and cleaned /usr/src... Anyone else? Here's the relevant end of the failure AFAIK: except.o: In function `nothrow_libfn_p': /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c:(.text+0x10fb): undefined reference to `libc_name_p' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[3]: stopped in /usr/src/gnu/usr.bin/cc/cc1plus *** Error code 1 Stop. make[2]: stopped in /usr/src/gnu/usr.bin/cc *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 17:22:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC6C023E for ; Thu, 30 Oct 2014 17:22:15 +0000 (UTC) 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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80C3C8ED for ; Thu, 30 Oct 2014 17:22:15 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XjtQL-0001TK-OE; Thu, 30 Oct 2014 17:22:13 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s9UHMCOT083422; Thu, 30 Oct 2014 11:22:12 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 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/elcTEDQEcgc9KI0d8ap+3 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: building cross-compiling tools on -CURRENT From: Ian Lepore To: George Rosamond In-Reply-To: <54527218.2090008@ceetonetechnology.com> References: <54527218.2090008@ceetonetechnology.com> Content-Type: text/plain; charset="us-ascii" Date: Thu, 30 Oct 2014 11:22:12 -0600 Message-ID: <1414689732.17308.173.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.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 17:22:15 -0000 On Thu, 2014-10-30 at 13:15 -0400, George Rosamond wrote: > Using a new build box running head with r273764, and running into an > issue building the cross compiler tools. Using source based in /usr/src > on an amd64 box. I do have devel/gperf installed as per /usr/src/UPDATING. > > Running this from /usr/src: > > make TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 WITH_GCC_BOOTSTRAP=1 > WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev > > I changed "XDEV" and "XDEV_ARCH to "TARGET" and "TARGET_ARCH" as per > /usr/src/UPDATING from 20140723, but also tried "XDEV" "XDEV_ARCH". If > I'm reading this right, Crochet should take that into account. > > I did clear out /usr/obj, updated and cleaned /usr/src... > > Anyone else? Here's the relevant end of the failure AFAIK: > > except.o: In function `nothrow_libfn_p': > /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c:(.text+0x10fb): > undefined reference to `libc_name_p' > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code 1 > > Stop. > make[3]: stopped in /usr/src/gnu/usr.bin/cc/cc1plus > *** Error code 1 > > Stop. > make[2]: stopped in /usr/src/gnu/usr.bin/cc > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src You might think you've tweaked enough knobs there, but I think maybe there's one more: WITH_GNUCXX When I want to test building everything with gcc instead of clang, I uncomment these in my make.conf: #WITH_GCC=yes #WITH_GNUCXX=yes #WITH_GCC_BOOTSTRAP=yes #WITHOUT_CLANG=yes #WITHOUT_CLANG_IS_CC=yes #WITHOUT_CLANG_BOOTSTRAP=yes -- Ian From owner-freebsd-arm@FreeBSD.ORG Thu Oct 30 19:11:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E5DCF12; Thu, 30 Oct 2014 19:11:01 +0000 (UTC) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B152B643; Thu, 30 Oct 2014 19:10:59 +0000 (UTC) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id s9UJAMjo014934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 30 Oct 2014 20:10:27 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id s9UJA96c053222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Oct 2014 20:10:09 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id s9UJA9HK067663; Thu, 30 Oct 2014 20:10:09 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id s9UJA8FF067662; Thu, 30 Oct 2014 20:10:08 +0100 (CET) (envelope-from ticso) Date: Thu, 30 Oct 2014 20:10:08 +0100 From: Bernd Walter To: Ian Lepore Subject: Re: sd card probing (was: FreeBSD 10.0 on Raspberry PI B+ no network devices Message-ID: <20141030191008.GE59614@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20141023022244.GB16490@cicely7.cicely.de> <20141029172937.GB59614@cicely7.cicely.de> <1414605501.17308.97.camel@revolution.hippie.lan> <20141029200403.GC59614@cicely7.cicely.de> <1414613786.17308.124.camel@revolution.hippie.lan> <6CC5D29F-C3F7-4913-9D77-D275EEDDC1DD@bsdimp.com> <20141030021857.GD59614@cicely7.cicely.de> <1414677395.17308.155.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1414677395.17308.155.camel@revolution.hippie.lan> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de Cc: Andreas Schwarz , George Rosamond , Tim Kientzle , "freebsd-arm@freebsd.org" , ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Oct 2014 19:11:01 -0000 On Thu, Oct 30, 2014 at 07:56:35AM -0600, Ian Lepore wrote: > On Thu, 2014-10-30 at 10:54 -0200, Luiz Otavio O Souza wrote: > > > > I tried to check the SD clock frequency with the scope and just by > > connecting the probe on the SD clock line the card that was previously > > working flawless, start to exhibit some i/o errors, so i guess it is > > pretty sensible to capacitance load on that line (that may explain why > > they removed the series resistor). > > Is your probe set for 10x mode? When I first looked at the clock and > data signals on the rpi sdcard they looked horrible, the waveforms were > anything but square. I thought I was on to something at first, maybe > the board was just too underpowered. But eventually I realized I had > the probe set to 1x mode and it was pulling too much current off the > lines. When I switched it to 10x everything looked good. (Maybe all of > this is a no-brainer to a hardware person. I'm a software person with > just enough hardware knowledge to confuse himself.) Yes - rule of thumb: always use the divider. In 1:1 mode you just have an unterminated cable into the scope requiring a 50 Ohm termination at scope side. Many modern scopes have a 50 Ohm termination feature, with older your need a 50 Ohm BNC inline terminator. You can only use it unterminated (and therefor high impedance) with very low frequencies below the reflection time. With divider the cable unleashes all it's black magic. Dave Jones did a nice video to explain the details: http://www.eevblog.com/2013/04/13/eevblog-453-mysteries-of-x1-oscilloscope-probes-revealed/ He also did many other very interesting videos on using scopes. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 31 04:24:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A8C054B for ; Fri, 31 Oct 2014 04:24:25 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtp001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C5A4FD for ; Fri, 31 Oct 2014 04:24:24 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEA004X7HFXJP60@st11p02mm-asmtp001.mac.com> for freebsd-arm@freebsd.org; Fri, 31 Oct 2014 03:23:59 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-31_02:2014-10-30,2014-10-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1410310033 Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-type: text/plain; charset=iso-8859-1 From: Rui Paulo X-Priority: 3 In-reply-to: <840772A7305444C1B1AF7CE31A89BD7D@ad.peach.ne.jp> Date: Thu, 30 Oct 2014 20:23:57 -0700 Content-transfer-encoding: quoted-printable Message-id: <09F2506B-11E9-43A2-A783-784AA6E39976@me.com> References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> <7946CCA3-26D0-4B6E-AEBB-8623CAAA9725@me.com> <840772A7305444C1B1AF7CE31A89BD7D@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 04:24:25 -0000 On Oct 30, 2014, at 03:35, Daisuke Aoyama wrote: >=20 >> This code is now up for review at: >> https://reviews.freebsd.org/D1025 >=20 > There is some comment. >=20 > About build error: > It requires the patch of bcm2835_mbox.h in > = http://www.peach.ne.jp/archives/rpi/patch/src-r273303-20141026.patch.gz > for build dependency and the patch of bcm2835_mbox.c for run = dependency. That patch has a lot of unrelated changes. Could you produce a patch = with svn that is just related to cpufreq and its mbox changes? > Showing boot settings: > The initial values are intended to use for manual tuning via = hw.cpufreq. > Especially, using it in the turbo state ON. (force_turbo=3D1 in = config.txt before booting) > This is different from other cpufreq drivers. Okay, but why does it need to show up in the dmesg when it boots? > Writing core clock twice: > I didn't know a reason. At least, very long delay is not worked. OK. > DELAY: > It is put on various places for safety after set property. > (power consumption may change. don't want change without interval) Ok, let's just leave it like that for now. Thanks, -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Fri Oct 31 10:35:00 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 52C42CF9 for ; Fri, 31 Oct 2014 10:35:00 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1CCF1C4A for ; Fri, 31 Oct 2014 10:35:00 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id tp5so931138ieb.8 for ; Fri, 31 Oct 2014 03:34:59 -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=+EuGp+7bkh1pxCoCqnJIMO89+H84BBgYAy8eqv3EMP4=; b=U7Kahy7QA7Verl7SnRXZUJ7duGI/MRUoKdIqRzQg/aOXLKcYWNkylLOPHeVq63FUNp nOS7opEspe6bpTwXvGpWvU/v3VVgJC6XXRxyfYaligLF8WIbuvjeDambLgTPZf3Cqy9w SedNQaFxuVkMIrLYWf3844ZOm8a07ZXLNCOETfXfotlaod2nMsyH6B3UK2IAkmaR27+5 i2PjRTru/7CpY0sE2m/EqSLlsWgcqMdZZA+HNUmR09T2PUie/ASGcF+W8n14cedcrC06 RfjR4BNDrNuq1CiySIGMawaeoP/Th7y5hfU23qgGNrF54g867Y+SEJNFBQImrjX6s0cm sx1Q== MIME-Version: 1.0 X-Received: by 10.43.119.131 with SMTP id fu3mr22872958icc.56.1414751699640; Fri, 31 Oct 2014 03:34:59 -0700 (PDT) Received: by 10.50.185.229 with HTTP; Fri, 31 Oct 2014 03:34:59 -0700 (PDT) Date: Fri, 31 Oct 2014 08:34:59 -0200 Message-ID: Subject: Ports Raspberry pi From: Henrique Utsch To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 10:35:00 -0000 Dear friend, I try compile ports on FreeBSD 11 in my rapberry pi but is too long time. I see that FreeBSD is Tier 2 and no have packages for Rasp When FreeBSD turn Tier1? How fast compile ports for Rasp on FreeBSD? Thanks Henrique T. A. Utsch www.henriqueutsch.com https://www.facebook.com/henrique.utsch From owner-freebsd-arm@FreeBSD.ORG Fri Oct 31 10:38:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4FC023D2 for ; Fri, 31 Oct 2014 10:38:48 +0000 (UTC) Received: from mail.jr-hosting.nl (mail.jr-hosting.nl [IPv6:2a01:4f8:141:5ffd::25]) by mx1.freebsd.org (Postfix) with ESMTP id 10BFECA8 for ; Fri, 31 Oct 2014 10:38:48 +0000 (UTC) Received: from [IPv6:2001:470:d701::e4bc:276a:aef3:a284] (unknown [IPv6:2001:470:d701:0:e4bc:276a:aef3:a284]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jr-hosting.nl (Postfix) with ESMTPSA id B3D204B62C; Fri, 31 Oct 2014 11:38:40 +0100 (CET) DMARC-Filter: OpenDMARC Filter v1.3.0 mail.jr-hosting.nl B3D204B62C Authentication-Results: mail.jr-hosting.nl/B3D204B62C; dmarc=none header.from=FreeBSD.org Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Subject: Re: Ports Raspberry pi From: Remko Lodder In-Reply-To: Date: Fri, 31 Oct 2014 11:38:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <18F72354-0695-468F-8D39-C2563CC5CDAF@FreeBSD.org> References: To: Henrique Utsch X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 10:38:48 -0000 > On 31 Oct 2014, at 11:34, Henrique Utsch = wrote: >=20 > Dear friend, I try compile ports on FreeBSD 11 in my rapberry pi but = is too > long time. > I see that FreeBSD is Tier 2 and no have packages for Rasp > When FreeBSD turn Tier1? > How fast compile ports for Rasp on FreeBSD? > Thanks > Henrique T. A. Utsch > www.henriqueutsch.com > https://www.facebook.com/henrique.utsch Hello, At least Sean Bruno and I have test builders that include (Sean: all, = mine just a selection) of ports. In my VM with Sean=E2=80=99s instruction on how it should work, = compiling ports does not go too fast. I am not sure whether that is a real life scenario on regular hardware as well or = that it=E2=80=99s the overhead of the VM. I think that when Sean is able to quickly produce ports on regular = hardware (amd64 fast boxes) this might change.. Cheerio Remko > _______________________________________________ > 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 31 17:07:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 03F0C57D for ; Fri, 31 Oct 2014 17:07:26 +0000 (UTC) Received: from frontend2.warwick.net (wvtcvoicemail.wvtc.com [204.255.24.103]) by mx1.freebsd.org (Postfix) with SMTP id 9641EE5F for ; Fri, 31 Oct 2014 17:07:24 +0000 (UTC) Received: (qmail 30950 invoked from network); 31 Oct 2014 17:00:44 -0000 Received: from 70.44.113.89.res-cmts.sefg.ptd.net (HELO [70.44.113.89]) (egunther@warwick.net@70.44.113.89) by frontend2.warwick.net with SMTP (735b1286-611f-11e4-9e38-001f2909bf3e); Fri, 31 Oct 2014 13:00:44 -0400 Message-ID: <1414774843.3499.18.camel@res-cmts> Subject: RPI, config.txt: overscan, not working From: ito To: freebsd-arm@freebsd.org Date: Fri, 31 Oct 2014 13:00:43 -0400 Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-MagicMail-UUID: 735b1286-611f-11e4-9e38-001f2909bf3e X-MagicMail-Authenticated: egunther@warwick.net X-MagicMail-SourceIP: 70.44.113.89 X-MagicMail-EnvelopeFrom: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 17:07:26 -0000 Hello, I have a raspberry pi, Model B Revision 2.0 (512MB) which has the logo along with: Raspberry Pi (c)2011.12 written on it. I have obtained a image for freebsd to run from here: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/10.0/ I uncompressed the image on a OpenSUSE system, and used, sudo dd if=FreeBSD-10.0-RELEASE-arm-armv6-RPI-B-20140131-r260789.img of=/dev/sdd to put the image on a micro SD... with that card and adapter I have successfully boot freebsd. The problem I am facing now is that I am using the yellow SVGA (RCA type plug) cables to use an old Television as a monitor, with this setup I have an issue with the text running off of the screen. I have tried the config.txt file with overscan_disable=0 overscan_left=20 overscan_right=20 overscan_top=20 overscan_bottom=20 added to the existing config.txt I have tried to load vesa: kldload vesa where I get a prompt that it does not exist. I looked in the kernel directory (/boot/kernel/) and there is no vesa, not sure what that means. I am assuming that there is something that is not happening with the config.txt. I saw mention of using the files here to replace the files on the pi; https://github.com/raspberrypi/firmware SO, essentially, how do I get the text to stop from spilling off of the screen (command prompt-no gui). Thank You, ito From owner-freebsd-arm@FreeBSD.ORG Fri Oct 31 19:32:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6A895291 for ; Fri, 31 Oct 2014 19:32:39 +0000 (UTC) Received: from moon.peach.ne.jp (moon.peach.ne.jp [203.141.148.98]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3197A391 for ; Fri, 31 Oct 2014 19:32:38 +0000 (UTC) Received: from moon.peach.ne.jp (localhost [127.0.0.1]) by moon.peach.ne.jp (Postfix) with ESMTP id 05AAF39D0A; Sat, 1 Nov 2014 04:32:30 +0900 (JST) Received: from artemis (unknown [172.18.0.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by moon.peach.ne.jp (Postfix) with ESMTPSA id D495439D09; Sat, 1 Nov 2014 04:32:29 +0900 (JST) Message-ID: <5DC02CC61B85442AADD2BDD28496421E@ad.peach.ne.jp> From: "Daisuke Aoyama" To: "Rui Paulo" References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> <7946CCA3-26D0-4B6E-AEBB-8623CAAA9725@me.com> <840772A7305444C1B1AF7CE31A89BD7D@ad.peach.ne.jp> <09F2506B-11E9-43A2-A783-784AA6E39976@me.com> In-Reply-To: <09F2506B-11E9-43A2-A783-784AA6E39976@me.com> Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB Date: Sat, 1 Nov 2014 04:32:25 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8117.416 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8117.416 X-Virus-Scanned: ClamAV using ClamSMTP Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 19:32:39 -0000 >That patch has a lot of unrelated changes. Could you produce a patch with svn that is just >related to cpufreq and its mbox changes? I have uploaded as: http://www.peach.ne.jp/archives/rpi/patch/cpufreq-20141101.tar.gz Please use this archive. CHANGES: modify for style(9) and 80 columns remove multiple cast remove bootverbose of error case remove unused code and g_XXXX variables fix wrong message/comments. add DPRINTF and dump into #ifdef DEBUG add tunable int for verbose and lowest_freq suppress default boot log default boot: bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 398MHz, Turbo OFF verbose boot or hw.bcm2835.cpufreq.verbose=1 by loader.conf: bcm2835_cpufreq0: Boot settings: bcm2835_cpufreq0: current ARM 700MHz, Core 250MHz, SDRAM 398MHz, Turbo OFF bcm2835_cpufreq0: max/min ARM 1000/700MHz, Core 500/250MHz, SDRAM 500/400MHz bcm2835_cpufreq0: current Core 1200mV, SDRAM_C 1200mV, SDRAM_I 1200mV, SDRAM_P 1200mV bcm2835_cpufreq0: max/min Core 1350/1200mV, SDRAM_C 1225/1200mV, SDRAM_I 1225/1200mV, SDRAM_P 1225/1200mV default (max=1000MHz): dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 400/-1 300/-1 hw.bcm2835.cpufreq.lowest_freq=500 by loader.conf (max=1000MHz): dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 >- Did you measure the power consumption when using the different frequency values? I have tried to get an ampere on USB power cable both idle and running ports/benchmarks/unixbench. Following table is the result. It's not so different on CPU idle. Power=5.10V V=0/0 300MHz idle/0.35A 1.79W 3%DOWN unixbench/0.39A 50.8C 1.99W 9%DOWN V=0/0 700MHz idle/0.36A 1.84W ------ unixbench/0.43A 54.6C 2.19W ------ V=6/1 1000MHz idle/0.40A 2.04W 10%UP unixbench/0.51A 58.3C 2.60W 19%UP Note: V=0/0 mean default voltage(1.2V/1.2V) V=6/1 mean over_voltage=6/over_voltage_sdram=1(1.35V/1.225V) All manual setting without powered Temperature is checked running only Thank you. -- Daisuke Aoyama From owner-freebsd-arm@FreeBSD.ORG Sat Nov 1 01:55:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6E246594 for ; Sat, 1 Nov 2014 01:55:01 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DCD374F for ; Sat, 1 Nov 2014 01:55:01 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NEC00MPR7ZEXT30@st11p02mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Sat, 01 Nov 2014 01:54:52 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-11-01_01:2014-10-31,2014-10-31,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1408290000 definitions=main-1411010021 Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB MIME-version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) Content-type: text/plain; charset=us-ascii From: Rui Paulo X-Priority: 3 In-reply-to: <5DC02CC61B85442AADD2BDD28496421E@ad.peach.ne.jp> Date: Fri, 31 Oct 2014 18:54:49 -0700 Content-transfer-encoding: quoted-printable Message-id: <60F13E5C-A166-497B-8CB7-6C76AFB6BDB8@me.com> References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> <7946CCA3-26D0-4B6E-AEBB-8623CAAA9725@me.com> <840772A7305444C1B1AF7CE31A89BD7D@ad.peach.ne.jp> <09F2506B-11E9-43A2-A783-784AA6E39976@me.com> <5DC02CC61B85442AADD2BDD28496421E@ad.peach.ne.jp> To: Daisuke Aoyama X-Mailer: Apple Mail (2.1990.1) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 01:55:01 -0000 On Oct 31, 2014, at 12:32, Daisuke Aoyama wrote: >=20 >> That patch has a lot of unrelated changes. Could you produce a patch = with svn that is just related to cpufreq and its mbox changes? >=20 > I have uploaded as: > http://www.peach.ne.jp/archives/rpi/patch/cpufreq-20141101.tar.gz >=20 > Please use this archive. >=20 > CHANGES: > modify for style(9) and 80 columns > remove multiple cast > remove bootverbose of error case > remove unused code and g_XXXX variables > fix wrong message/comments. > add DPRINTF and dump into #ifdef DEBUG > add tunable int for verbose and lowest_freq > suppress default boot log Thanks, I've updated the review page: https://reviews.freebsd.org/D1025 I'm going to review it again during the weekend. > default boot: >=20 > bcm2835_cpufreq0: ARM 700MHz, Core 250MHz, SDRAM 398MHz, Turbo OFF >=20 > verbose boot or hw.bcm2835.cpufreq.verbose=3D1 by loader.conf: >=20 > bcm2835_cpufreq0: Boot settings: > bcm2835_cpufreq0: current ARM 700MHz, Core 250MHz, SDRAM 398MHz, Turbo = OFF > bcm2835_cpufreq0: max/min ARM 1000/700MHz, Core 500/250MHz, SDRAM = 500/400MHz > bcm2835_cpufreq0: current Core 1200mV, SDRAM_C 1200mV, SDRAM_I 1200mV, = SDRAM_P 1200mV > bcm2835_cpufreq0: max/min Core 1350/1200mV, SDRAM_C 1225/1200mV, = SDRAM_I 1225/1200mV, SDRAM_P 1225/1200mV Cool! > default (max=3D1000MHz): > dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 = 400/-1 300/-1 >=20 > hw.bcm2835.cpufreq.lowest_freq=3D500 by loader.conf (max=3D1000MHz): > dev.cpu.0.freq_levels: 1000/-1 900/-1 800/-1 700/-1 600/-1 500/-1 >=20 >=20 >> - Did you measure the power consumption when using the different = frequency values? >=20 > I have tried to get an ampere on USB power cable both idle and running = ports/benchmarks/unixbench. > Following table is the result. It's not so different on CPU idle. >=20 > Power=3D5.10V > V=3D0/0 300MHz idle/0.35A 1.79W 3%DOWN unixbench/0.39A 50.8C 1.99W = 9%DOWN > V=3D0/0 700MHz idle/0.36A 1.84W ------ unixbench/0.43A 54.6C 2.19W = ------ > V=3D6/1 1000MHz idle/0.40A 2.04W 10%UP unixbench/0.51A 58.3C 2.60W = 19%UP >=20 > Note: > V=3D0/0 mean default voltage(1.2V/1.2V) > V=3D6/1 mean over_voltage=3D6/over_voltage_sdram=3D1(1.35V/1.225V) > All manual setting without powered > Temperature is checked running only That's interesting. Thanks for taking the time to measure it. Regards, -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sat Nov 1 07:42:01 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1371967C for ; Sat, 1 Nov 2014 07:42:01 +0000 (UTC) Received: from mail.turbocat.net (heidi.turbocat.net [88.198.202.214]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C41851F8 for ; Sat, 1 Nov 2014 07:41:59 +0000 (UTC) Received: from laptop015.home.selasky.org (cm-176.74.213.204.customer.telag.net [176.74.213.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 44D181FE022; Sat, 1 Nov 2014 08:41:50 +0100 (CET) Message-ID: <54548EC8.5020707@selasky.org> Date: Sat, 01 Nov 2014 08:42:00 +0100 From: Hans Petter Selasky User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Rui Paulo , Daisuke Aoyama Subject: Re: FreeBSD 11-CURRENT on Raspberry Pi 512MB References: <0A8390C3FC2B444B9AA8AC934B79DCD6@ad.peach.ne.jp> <7946CCA3-26D0-4B6E-AEBB-8623CAAA9725@me.com> <840772A7305444C1B1AF7CE31A89BD7D@ad.peach.ne.jp> <09F2506B-11E9-43A2-A783-784AA6E39976@me.com> <5DC02CC61B85442AADD2BDD28496421E@ad.peach.ne.jp> <60F13E5C-A166-497B-8CB7-6C76AFB6BDB8@me.com> In-Reply-To: <60F13E5C-A166-497B-8CB7-6C76AFB6BDB8@me.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 07:42:01 -0000 On 11/01/14 02:54, Rui Paulo wrote: > On Oct 31, 2014, at 12:32, Daisuke Aoyama wrote: >> >>> That patch has a lot of unrelated changes. Could you produce a patch with svn that is just related to cpufreq and its mbox changes? >> >> I have uploaded as: >> http://www.peach.ne.jp/archives/rpi/patch/cpufreq-20141101.tar.gz >> >> Please use this archive. >> >> CHANGES: >> modify for style(9) and 80 columns >> remove multiple cast >> remove bootverbose of error case >> remove unused code and g_XXXX variables >> fix wrong message/comments. >> add DPRINTF and dump into #ifdef DEBUG >> add tunable int for verbose and lowest_freq >> suppress default boot log > > Thanks, I've updated the review page: > > https://reviews.freebsd.org/D1025 > > I'm going to review it again during the weekend. > > Hi, Regarding the tunables: Why don't you make them into SYSCTLS with the TUN flag set. Then they will also be visible in the "sysctl -a" output! --HPS From owner-freebsd-arm@FreeBSD.ORG Sat Nov 1 23:38:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 087DD2CF; Sat, 1 Nov 2014 23:38:05 +0000 (UTC) Received: from feynman.konjz.org (feynman.konjz.org [64.147.119.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A90D86D0; Sat, 1 Nov 2014 23:38:04 +0000 (UTC) Received: from 127.0.0.1 (exit4.telostor.ca [62.210.74.137]) (authenticated bits=0) by feynman.konjz.org (8.14.7/8.14.4) with ESMTP id sA1NfYPs068849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 1 Nov 2014 19:41:37 -0400 (EDT) (envelope-from george@ceetonetechnology.com) Message-ID: <54556EBF.1050105@ceetonetechnology.com> Date: Sat, 01 Nov 2014 19:37:35 -0400 From: George Rosamond MIME-Version: 1.0 To: Ian Lepore Subject: Re: building cross-compiling tools on -CURRENT References: <54527218.2090008@ceetonetechnology.com> <1414689732.17308.173.camel@revolution.hippie.lan> In-Reply-To: <1414689732.17308.173.camel@revolution.hippie.lan> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 23:38:05 -0000 Ian Lepore: > On Thu, 2014-10-30 at 13:15 -0400, George Rosamond wrote: >> Using a new build box running head with r273764, and running into an >> issue building the cross compiler tools. Using source based in /usr/src >> on an amd64 box. I do have devel/gperf installed as per /usr/src/UPDATING. >> >> Running this from /usr/src: >> >> make TARGET=arm TARGET_ARCH=armv6 WITH_GCC=1 WITH_GCC_BOOTSTRAP=1 >> WITHOUT_CLANG=1 WITHOUT_CLANG_BOOTSTRAP=1 WITHOUT_CLANG_IS_CC=1 xdev >> >> I changed "XDEV" and "XDEV_ARCH to "TARGET" and "TARGET_ARCH" as per >> /usr/src/UPDATING from 20140723, but also tried "XDEV" "XDEV_ARCH". If >> I'm reading this right, Crochet should take that into account. >> >> I did clear out /usr/obj, updated and cleaned /usr/src... >> >> Anyone else? Here's the relevant end of the failure AFAIK: >> >> except.o: In function `nothrow_libfn_p': >> /usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp/except.c:(.text+0x10fb): >> undefined reference to `libc_name_p' >> cc: error: linker command failed with exit code 1 (use -v to see invocation) >> *** Error code 1 >> >> Stop. >> make[3]: stopped in /usr/src/gnu/usr.bin/cc/cc1plus >> *** Error code 1 >> >> Stop. >> make[2]: stopped in /usr/src/gnu/usr.bin/cc >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/src >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/src > > You might think you've tweaked enough knobs there, but I think maybe > there's one more: WITH_GNUCXX > > When I want to test building everything with gcc instead of clang, I > uncomment these in my make.conf: > > #WITH_GCC=yes > #WITH_GNUCXX=yes > #WITH_GCC_BOOTSTRAP=yes > #WITHOUT_CLANG=yes > #WITHOUT_CLANG_IS_CC=yes > #WITHOUT_CLANG_BOOTSTRAP=yes Thanks Ian. Tried change the above "make" command to this.. same thing. I'll wait and see.. if I'm the only one, I'll assume it's user error somewhere.... Maybe the build box should be 10- ? Is anyone else having this issue? g