From owner-freebsd-arm@freebsd.org Sun Dec 11 03:53:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8F5FBC65D4E for ; Sun, 11 Dec 2016 03:53:16 +0000 (UTC) (envelope-from meka@tilda.center) Received: from mail.tilda.center (mail.tilda.center [188.226.130.133]) by mx1.freebsd.org (Postfix) with ESMTP id 56FD8E4D for ; Sun, 11 Dec 2016 03:53:15 +0000 (UTC) (envelope-from meka@tilda.center) Received: from hal9000.meka.no-ip.org (unknown [87.116.180.115]) by mail.tilda.center (Postfix) with ESMTPSA id 95E736172B for ; Sun, 11 Dec 2016 04:46:01 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tilda.center; s=mail; t=1481427961; bh=vYxPYGn8WsqAvejsu9pPvz8WzElv830PVE8F9Aeqrtc=; h=Date:From:To:Subject:From; b=gwb9bWDB9e/ioQCaW071Fkg1+ADWUmeyjHOi224GnNfFg5n0bntYzElJcgWBinppk CT8cx1ieKaZbKygXZ3+iDGwfYHiZ7nitDo/yGi+N33v5xp9Y2iQ7kadqeWoEtAs425 lyJ6JU9bv+mt8XWYkXJeF3ltYN/EJUELEw9kcJFI= Date: Sun, 11 Dec 2016 04:46:02 +0100 From: Goran =?utf-8?B?TWVracSH?= To: freebsd-arm@freebsd.org Subject: Arduino Due Message-ID: <20161211034602.3fylwnxfbgl4ehgx@hal9000.meka.no-ip.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hfynk4eoargnryzc" Content-Disposition: inline User-Agent: NeoMutt/20161126 (1.7.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 03:53:16 -0000 --hfynk4eoargnryzc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hello, Technically, Due is ARM based so the question is not off topic too much, I hope. Anyway, I'm having trouble with Arduino Due. On Debian all works well and the board behaves as expected. On FreeBSD, two things are kindda weird: 1. When ever I start Arduino IDE, L led stops blinking and continues blinking when IDE is closed. 2. I can read board info through IDE until I flash sketch on FreeBSD. After that I can not get the info, and the L led is lit all the time. Any tip is precious. Thank you! Regards, meka --hfynk4eoargnryzc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAlhMy/gACgkQWj1Tknov rLYglQ//brap+ithmnARi+rEwvTlYccZ3E2QCxJvoCnjYpxSxHljgzp3cLRnoMYf bg6sJ+0yz29ooTgAGxOKFhU6Ttu4iFwJWVTsQP+2mBsCeyf7opajYZn3Tbfs0XGe 89oP3yhvsnEUkwr/rpWCxUIi7RYDHKKES0uTejnGcaaM9cgNMBmBh/lXoedSpC1i wV0ktsxfUZ9DQ9qKGEEE9w72h2//9FagHGJb1egkbSniljSRUw3UHWPV6BRBkoPo 9sm55gbxZH/puGrMc9iDXCoqWvD6NnIAQ6lrP5wm/xzyiKzkyGxyVyzcFPdhzD4E gw2QZmRd632rq2LX+R/JaMi4z7JcqhVesAyscXy5eq/EtGsqXMVTord+XjuJ4KSA MW3etrvgzx/aBLV5VYKfQ6kBxhuKyVxYND/NkH8EHeFRMhBBVnxyUPHzC2p0/SXZ 6SRA8lKp8wF2pEnt4zueWm1Ey+FY2asYyahlsgxOvS8sP8Jmll3RcWnZAdRlMkZg QSH/ZiOGYfC+BH+0wAgyj7Jy5b24gGlRSyNlixurr2tKnEvMYGz1rc0LSBnL3mxJ QPVnOAt5ntYdtbuJbrcGaItaZrsmDvOa2kxccbsCs5jzJqID1AEupbM6aU7P4EUf qOjCLNq7xbkDQ8zilzs0SNcleyw628OaP+8lv7WVnkV4XfXptPU= =MDnC -----END PGP SIGNATURE----- --hfynk4eoargnryzc-- From owner-freebsd-arm@freebsd.org Sun Dec 11 09:16:02 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0DF6FC7277B for ; Sun, 11 Dec 2016 09:16:02 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from deinprogramm.de (deinprogramm.de [88.198.58.179]) by mx1.freebsd.org (Postfix) with ESMTP id C5CC21097; Sun, 11 Dec 2016 09:16:01 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from jellaby.local (pD9E7C5E6.dip0.t-ipconnect.de [217.231.197.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deinprogramm.de (Postfix) with ESMTPSA id A5A0A3028B; Sun, 11 Dec 2016 09:15:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=deinprogramm.de; s=default; t=1481447752; bh=lpj51H082VWU+b7k2kcHg8Dp8rNITb1XpLjcHp/JAU0=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=FT/v8r90TRjyMdNe10FW9JYiYpfcd0QIesUDtZo9JG/maVFoQMUOYv6tYxddG1+fc ZoPTWh0TQ5P57hzpNH0Jqp5wUbEbij3lTc30ZD+gJbW/5NFN66HXofJyDTmWy90/cf 2Ye+x+jwPLLzDzOrl3DhQSGYdC1flsYCgJKM5mK4= Received: from jellaby.local.deinprogramm.de (localhost [IPv6:::1]) by jellaby.local (Postfix) with ESMTP id 9FD729461F9C; Sun, 11 Dec 2016 10:15:53 +0100 (CET) From: Michael Sperber To: Mark Millard , jmcneill@FreeBSD.org Cc: freebsd-arm@freebsd.org Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 References: <20161124222152.dfd02dcafdc25182b6b46e50@bidouilliste.com> <66508AA3-436A-4D9E-AAB5-B85D0B4FC40C@dsl-only.net> <9C8B313C-A058-44DF-8673-D23B481CE312@dsl-only.net> <1E9515A0-06D5-4CF9-9D29-D6FF591686F4@dsl-only.net> <53608BFE-4653-4407-AFBE-7AB5E45AF2C1@dsl-only.net> Date: Sun, 11 Dec 2016 10:15:53 +0100 In-Reply-To: <53608BFE-4653-4407-AFBE-7AB5E45AF2C1@dsl-only.net> (Mark Millard's message of "Sat, 3 Dec 2016 13:01:46 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 09:16:02 -0000 So I've got debug output now: Dec 10 22:14:23 kernel: awg0: mem 0x1c30000-0x1c300ff on simplebus0 Dec 10 22:14:23 kernel: awg0: soft reset timed out Dec 10 22:14:23 kernel: awg0: BASIC_CTL_0 00000000 Dec 10 22:14:23 kernel: awg0: BASIC_CTL_1 08000001 Dec 10 22:14:23 kernel: awg0: INT_STA 40000000 Dec 10 22:14:23 kernel: awg0: INT_EN 00000000 Dec 10 22:14:23 kernel: awg0: TX_CTL_0 00000000 Dec 10 22:14:23 kernel: awg0: TX_CTL_1 00000000 Dec 10 22:14:23 kernel: awg0: TX_FLOW_CTL 00000000 Dec 10 22:14:23 kernel: awg0: TX_DMA_LIST 00000000 Dec 10 22:14:23 kernel: awg0: RX_CTL_0 00000000 Dec 10 22:14:23 kernel: awg0: RX_CTL_1 00000000 Dec 10 22:14:23 kernel: awg0: RX_DMA_LIST 00000000 Dec 10 22:14:23 kernel: awg0: RX_FRM_FLT 00000000 Dec 10 22:14:23 kernel: awg0: RX_HASH_0 00000000 Dec 10 22:14:23 kernel: awg0: RX_HASH_1 00000000 Dec 10 22:14:23 kernel: awg0: MII_CMD 00000000 Dec 10 22:14:23 kernel: awg0: ADDR_HIGH0 0000ffff Dec 10 22:14:23 kernel: awg0: ADDR_LOW0 ffffffff Dec 10 22:14:23 kernel: awg0: TX_DMA_STA 0000ffff Dec 10 22:14:23 kernel: awg0: TX_DMA_CUR_DESC ffffffff Dec 10 22:14:23 kernel: awg0: TX_DMA_CUR_BUF 0000ffff Dec 10 22:14:23 kernel: awg0: RX_DMA_STA 00000000 Dec 10 22:14:23 kernel: awg0: RX_DMA_CUR_DESC 00000000 Dec 10 22:14:23 kernel: awg0: RX_DMA_CUR_BUF 00000000 Dec 10 22:14:23 kernel: awg0: RGMII_STA 00000000 Dec 10 22:14:23 kernel: device_attach: awg0 attach returned 60 (I'd also increased the retry count from 1000 to 5000, which did not help.) Enough for a PR? -- Regards, Mike From owner-freebsd-arm@freebsd.org Sun Dec 11 09:47:30 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A2491C72EFA for ; Sun, 11 Dec 2016 09:47:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-170.reflexion.net [208.70.211.170]) (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 500821D22 for ; Sun, 11 Dec 2016 09:47:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 12295 invoked from network); 11 Dec 2016 09:47:38 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 11 Dec 2016 09:47:38 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Sun, 11 Dec 2016 04:47:40 -0500 (EST) Received: (qmail 5912 invoked from network); 11 Dec 2016 09:47:39 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 11 Dec 2016 09:47:39 -0000 Received: from [192.168.1.118] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 779D3EC8839; Sun, 11 Dec 2016 01:47:27 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 From: Mark Millard In-Reply-To: Date: Sun, 11 Dec 2016 01:47:26 -0800 Cc: jmcneill@FreeBSD.org, freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161124222152.dfd02dcafdc25182b6b46e50@bidouilliste.com> <66508AA3-436A-4D9E-AAB5-B85D0B4FC40C@dsl-only.net> <9C8B313C-A058-44DF-8673-D23B481CE312@dsl-only.net> <1E9515A0-06D5-4CF9-9D29-D6FF591686F4@dsl-only.net> <53608BFE-4653-4407-AFBE-7AB5E45AF2C1@dsl-only.net> To: Michael Sperber X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 09:47:30 -0000 To someone with appropriate background knowledge this is probably useful information. But on my level of ignorance of what things should be like I'd have to be able to compare to a register dump when it worked okay in order to have any clue what to look at. (And I'd have to find documentation to have any chance to understand anything.) I expect that with background information like that sometimes (usually?) it fails this way but other times it works and the like it should be good to submit for someone with the knowledge. I've not gotten nearly as far as you have for that issue. I've been trying to gather information on why in the new context the BPi-M3 shuts down or reboots on its own, no matter if Ethernet is connected or not. No console messages about why it shuts down. No log file information. No drop into ddb, despite how I specified the kernel configuration. In the prior environment it had been up for something like 22 days, with a mix of idle time and used time. Now it rarely stays up for more than 12 hours, even sitting idle. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Dec-11, at 1:15 AM, Michael Sperber = wrote: So I've got debug output now: Dec 10 22:14:23 kernel: awg0: mem = 0x1c30000-0x1c300ff on simplebus0 Dec 10 22:14:23 kernel: awg0: soft reset timed out Dec 10 22:14:23 kernel: awg0: BASIC_CTL_0 00000000 Dec 10 22:14:23 kernel: awg0: BASIC_CTL_1 08000001 Dec 10 22:14:23 kernel: awg0: INT_STA 40000000 Dec 10 22:14:23 kernel: awg0: INT_EN 00000000 Dec 10 22:14:23 kernel: awg0: TX_CTL_0 00000000 Dec 10 22:14:23 kernel: awg0: TX_CTL_1 00000000 Dec 10 22:14:23 kernel: awg0: TX_FLOW_CTL 00000000 Dec 10 22:14:23 kernel: awg0: TX_DMA_LIST 00000000 Dec 10 22:14:23 kernel: awg0: RX_CTL_0 00000000 Dec 10 22:14:23 kernel: awg0: RX_CTL_1 00000000 Dec 10 22:14:23 kernel: awg0: RX_DMA_LIST 00000000 Dec 10 22:14:23 kernel: awg0: RX_FRM_FLT 00000000 Dec 10 22:14:23 kernel: awg0: RX_HASH_0 00000000 Dec 10 22:14:23 kernel: awg0: RX_HASH_1 00000000 Dec 10 22:14:23 kernel: awg0: MII_CMD 00000000 Dec 10 22:14:23 kernel: awg0: ADDR_HIGH0 0000ffff Dec 10 22:14:23 kernel: awg0: ADDR_LOW0 ffffffff Dec 10 22:14:23 kernel: awg0: TX_DMA_STA 0000ffff Dec 10 22:14:23 kernel: awg0: TX_DMA_CUR_DESC ffffffff Dec 10 22:14:23 kernel: awg0: TX_DMA_CUR_BUF 0000ffff Dec 10 22:14:23 kernel: awg0: RX_DMA_STA 00000000 Dec 10 22:14:23 kernel: awg0: RX_DMA_CUR_DESC 00000000 Dec 10 22:14:23 kernel: awg0: RX_DMA_CUR_BUF 00000000 Dec 10 22:14:23 kernel: awg0: RGMII_STA 00000000 Dec 10 22:14:23 kernel: device_attach: awg0 attach returned 60 (I'd also increased the retry count from 1000 to 5000, which did not help.) Enough for a PR? --=20 Regards, Mike From owner-freebsd-arm@freebsd.org Sun Dec 11 16:09:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9FFA2C729B7 for ; Sun, 11 Dec 2016 16:09:32 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 7E45C1E24 for ; Sun, 11 Dec 2016 16:09:32 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 7AB01C729B6; Sun, 11 Dec 2016 16:09:32 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A4BBC729B5 for ; Sun, 11 Dec 2016 16:09:32 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EDCF1E23 for ; Sun, 11 Dec 2016 16:09:32 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi0-x233.google.com with SMTP id v84so65981028oie.3 for ; Sun, 11 Dec 2016 08:09:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0kA1oIFJ+IybcK63QNzVo2mgo75j1gUAhcbUOiPtfFM=; b=xdPwvRUvIEJnlw6UqHrGKQYVB6GwUL2N7XJxSVIPlRyVu0oet0HwbaweLuy5KhsK1D 7x+3s8SxXucCoKSfQZTo3JOcvDk1/27258lSg1kRS93Yz5OvUqNs1YpaL09jYWmHRHVK zppgrZxX/tZJqZFMQkBPC71lBul8CU2sx0wS8bzvu/K+vtqHpYa3mD3zabSd8ZmxGabc fVkR2p8yIjlfIMvJ8UMD/Uqkh/9oy913FOSnmoCxZ6i38QHYwjC1PVeUWK4t+wkmjdbD G73oXGY0B2icjpE97CgW95+GjfaJKbmSNWKInP9dEj6KUWeotdsaZMNBhuCtZPa+RkOr mEiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0kA1oIFJ+IybcK63QNzVo2mgo75j1gUAhcbUOiPtfFM=; b=VXm2XqlYr2fkq/6kHs8wqCA02ZinuhrIRlI/7+APRn6rtoSiHF1pmRsI0IqubPrZ70 p/DOpJ9wpoD4U02rgbo3jJ0ZViL+wH/H6PgdMvi7WdzKq5h2moeLj6GjWCs9wNvlHVw8 sfvce2Ae2o3BOrrYy1mcMSKX0SyJ/MhMGyYRtD3GMaBVSznbeOg1VrWULGud1No0CaUf hhz6tuk886E5nah9oMNWQwtI+Ad20vK2ubRdLxeI9N1p9BusBagKKD++REq13WC9EnJA M3hSoO/dlH5xER8V+C36XskRQRKmJdVzsZV6ua8xDwprsA7L23GECFxho1x1fKUOZunB U3lg== X-Gm-Message-State: AKaTC02SE8IlnQnd/f2fxL0haWhofCOdrdVfJL/TDLyw4NxVVyvBUL9eQInsXRBcFQamPgLq19WSJ1k1VZfQ/Q== X-Received: by 10.157.51.104 with SMTP id u37mr52686936otd.9.1481472571503; Sun, 11 Dec 2016 08:09:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.145.33 with HTTP; Sun, 11 Dec 2016 08:09:31 -0800 (PST) In-Reply-To: <93729768-D887-4568-8686-FE691A881BC6@cs.huji.ac.il> References: <7FD12DD6-B390-4EF3-811B-391798410BC0@cs.huji.ac.il> <1480950103.1889.251.camel@freebsd.org> <93729768-D887-4568-8686-FE691A881BC6@cs.huji.ac.il> From: Ganbold Tsagaankhuu Date: Mon, 12 Dec 2016 00:09:31 +0800 Message-ID: Subject: Re: ubldr, was Re: dtb printout To: Daniel Braniss Cc: arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 16:09:32 -0000 On Tue, Dec 6, 2016 at 5:17 PM, Daniel Braniss wrote: > > > On 5 Dec 2016, at 17:01, Ian Lepore wrote: > > > > On Mon, 2016-12-05 at 15:48 +0200, Daniel Braniss wrote: > >> Hi, > >> the short version: > >> is there a way to obtain the dtb from the kernel? > >> > >> the longer version: > >> I am developing on several different arm boards, rpi, rpi2, orangepi- > >> one, orange-pc, to mention > >> a few, and each one has a different u-boot, ubldr, dtb, and I keep > >> loosing track :-( > >> I find myself too often wondering which ddb file got loaded. > >> > >> cheers, > >> danny > > > > First: each one does NOT have a different ubldr. All ubldr.bin files > > are the same, they're not board-specific anymore. (The elf versions, > > ubldr without the .bin, may have a different load address in the elf > > header, but other than that, they're identical too and can actually be > > loaded at any address.) > > > > To see the contents of the dtb, use ofwdump. The output is not > > especially pretty. There is a manpage for it. > > > > To just get a quick reminder of which file was loaded, create a > > /boot/loader.rc.local (<-- .rc not .conf) that contains > > > > ubenv import fdtfile fdt_file > > > > Then in the running system you can use kenv and you'll see > > > > uboot.fdtfile=3D"bcm2835-rpi-b-rev2.dtb" > > > > Unfortunately, some u-boots use fdtfile, some use fdt_file. Grrr. > > > > You can, of course, use that ubenv import thing to pull any variable > > from the uboot environment into the kernel environment. If you just > > say ubenv import without naming a variable, you get all the vars > > (including vars that contain scripts, which is kind of messy). > > > > =E2=80=94 Ian > > > > as usual, I get more than I bargained for :-) > on rpi adding ubenv import worked, but on orange/allwinner I got a =E2=80= =98syntax > error=E2=80=99, > I tried to upgrade the ubldr, but so far i get: > > U-Boot SPL 2016.09 (Dec 05 2016 - 15:02:38) > DRAM: 1024 MiB > Trying to boot from MMC1 > > > U-Boot 2016.09 (Dec 05 2016 - 15:02:38 +0200) Allwinner Technology > > CPU: Allwinner H3 (SUN8I 1680) > Model: Xunlong Orange Pi PC > I2C: ready > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: SUNXI SD/MMC: 0 > reading u-boot.env > > ** Unable to read "u-boot.env" from mmc0:1 ** > Using default environment > > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > USB2: USB EHCI 1.00 > USB3: USB OHCI 1.0 > USB4: USB EHCI 1.00 > USB5: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 2 for devices... 1 USB Device(s) found > scanning bus 4 for devices... 1 USB Device(s) found > Hit any key to stop autoboot: 0 > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 223912 bytes read in 53 ms (4 MiB/s) > ## No elf image at address 0x42000000 > ## Starting application at 0x42000000 ... > Did ubldr work for you? I feel like I have same problem: Booting from: mmc 0 ubldr.bin reading ubldr.bin 228276 bytes read in 67 ms (3.2 MiB/s) ## No elf image at address 0x42000000 ## Starting application at 0x42000000 ... Ganbold > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Dec 11 17:30:03 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ECF36C72157 for ; Sun, 11 Dec 2016 17:30:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id D82101BDC for ; Sun, 11 Dec 2016 17:30:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: by mailman.ysv.freebsd.org (Postfix) id D4ACDC72156; Sun, 11 Dec 2016 17:30:03 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D29A8C72155 for ; Sun, 11 Dec 2016 17:30:03 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (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 7884E1BDB for ; Sun, 11 Dec 2016 17:30:02 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1cG7wf-000DZK-QM; Sun, 11 Dec 2016 19:29:53 +0200 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ubldr, was Re: dtb printout From: Daniel Braniss In-Reply-To: Date: Sun, 11 Dec 2016 19:29:53 +0200 Cc: arm@freebsd.org Message-Id: <2660E67D-10E4-4680-B824-EBF138FBC3FF@cs.huji.ac.il> References: <7FD12DD6-B390-4EF3-811B-391798410BC0@cs.huji.ac.il> <1480950103.1889.251.camel@freebsd.org> <93729768-D887-4568-8686-FE691A881BC6@cs.huji.ac.il> To: Ganbold Tsagaankhuu X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 17:30:04 -0000 > On 11 Dec 2016, at 6:09 PM, Ganbold Tsagaankhuu = wrote: >=20 >=20 >=20 > On Tue, Dec 6, 2016 at 5:17 PM, Daniel Braniss > wrote: >=20 > > On 5 Dec 2016, at 17:01, Ian Lepore > wrote: > > > > On Mon, 2016-12-05 at 15:48 +0200, Daniel Braniss wrote: > >> Hi, > >> the short version: > >> is there a way to obtain the dtb from the kernel? > >> > >> the longer version: > >> I am developing on several different arm boards, rpi, rpi2, = orangepi- > >> one, orange-pc, to mention > >> a few, and each one has a different u-boot, ubldr, dtb, and I keep > >> loosing track :-( > >> I find myself too often wondering which ddb file got loaded. > >> > >> cheers, > >> danny > > > > First: each one does NOT have a different ubldr. All ubldr.bin = files > > are the same, they're not board-specific anymore. (The elf = versions, > > ubldr without the .bin, may have a different load address in the elf > > header, but other than that, they're identical too and can actually = be > > loaded at any address.) > > > > To see the contents of the dtb, use ofwdump. The output is not > > especially pretty. There is a manpage for it. > > > > To just get a quick reminder of which file was loaded, create a > > /boot/loader.rc.local (<-- .rc not .conf) that contains > > > > ubenv import fdtfile fdt_file > > > > Then in the running system you can use kenv and you'll see > > > > uboot.fdtfile=3D"bcm2835-rpi-b-rev2.dtb" > > > > Unfortunately, some u-boots use fdtfile, some use fdt_file. Grrr. > > > > You can, of course, use that ubenv import thing to pull any variable > > from the uboot environment into the kernel environment. If you just > > say ubenv import without naming a variable, you get all the vars > > (including vars that contain scripts, which is kind of messy). > > > > =E2=80=94 Ian > > >=20 > as usual, I get more than I bargained for :-) > on rpi adding ubenv import worked, but on orange/allwinner I got a = =E2=80=98syntax error=E2=80=99, > I tried to upgrade the ubldr, but so far i get: >=20 > U-Boot SPL 2016.09 (Dec 05 2016 - 15:02:38) > DRAM: 1024 MiB > Trying to boot from MMC1 >=20 >=20 > U-Boot 2016.09 (Dec 05 2016 - 15:02:38 +0200) Allwinner Technology >=20 > CPU: Allwinner H3 (SUN8I 1680) > Model: Xunlong Orange Pi PC > I2C: ready > DRAM: 1 GiB > WARNING: Caches not enabled > MMC: SUNXI SD/MMC: 0 > reading u-boot.env >=20 > ** Unable to read "u-boot.env" from mmc0:1 ** > Using default environment >=20 > In: serial > Out: serial > Err: serial > Net: phy interface0 > eth0: ethernet@1c30000 > starting USB... > USB0: USB EHCI 1.00 > USB1: USB OHCI 1.0 > USB2: USB EHCI 1.00 > USB3: USB OHCI 1.0 > USB4: USB EHCI 1.00 > USB5: USB OHCI 1.0 > scanning bus 0 for devices... 1 USB Device(s) found > scanning bus 2 for devices... 1 USB Device(s) found > scanning bus 4 for devices... 1 USB Device(s) found > Hit any key to stop autoboot: 0 > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 223912 bytes read in 53 ms (4 MiB/s) > ## No elf image at address 0x42000000 > ## Starting application at 0x42000000 ... >=20 > Did ubldr work for you? > I feel like I have same problem: >=20 > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 228276 bytes read in 67 ms (3.2 MiB/s) > ## No elf image at address 0x42000000 > ## Starting application at 0x42000000 ... >=20 > Ganbold >=20 > =20 the latest one hangs, just like with you. I=E2=80=99m using an older ubldr >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Sun Dec 11 19:53:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E5714C72A2A for ; Sun, 11 Dec 2016 19:53:45 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id BCE93130E for ; Sun, 11 Dec 2016 19:53:45 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id 3910A11E2C; Sun, 11 Dec 2016 19:53:45 +0000 (UTC) Date: Sun, 11 Dec 2016 19:53:45 +0000 To: freebsd-arm@freebsd.org From: "jchandra (Jayachandran C)" Reply-to: D8751+327+0b71e6b4a223ec1d@reviews.freebsd.org Subject: [Differential] D8751: Fix gic_cpu_mask calculation Message-ID: X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , , , Thread-Topic: D8751: Fix gic_cpu_mask calculation X-Herald-Rules: <28>, <31>, <76> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk Thread-Index: YmMxMjJhMWNiZGU1NjQ5YWJiMWEyY2VmZTEy MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="b1_cbdc67fa552cf3414ffd524db01da673" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 19:53:46 -0000 --b1_cbdc67fa552cf3414ffd524db01da673 Content-Type: text/plain; charset = "utf-8" Content-Transfer-Encoding: base64 amNoYW5kcmEgY3JlYXRlZCB0aGlzIHJldmlzaW9uLgpqY2hhbmRyYSBhZGRlZCByZXZpZXdlcnM6 IGFybTY0LCBmcmVlYnNkLWFybS1saXN0LCBhbmRyZXcuCmpjaGFuZHJhIHNldCB0aGUgcmVwb3Np dG9yeSBmb3IgdGhpcyByZXZpc2lvbiB0byByUyBGcmVlQlNEIHNyYyByZXBvc2l0b3J5LgpIZXJh bGQgYWRkZWQgYSBzdWJzY3JpYmVyOiBpbXAuCgpSRVZJU0lPTiBTVU1NQVJZCiAgcjMwOTYxNiBj aGFuZ2VkIHRoZSBkZWZpbml0aW9uIG9mIEdJQ0RfSVRBUkdFVFNSKG4pIHJpZ2h0IHNoaWZ0IG4K ICBieSAyLCBidXQgdGhlIHVzYWdlIG9mIHRoZSBtYWNybyBpbiBnaWNfY3B1X21hc2soKSB3YXMg bm90IHVwZGF0ZWQKICB0byByZWZsZWN0IHRoaXMuIFRoaXMgY2F1c2VzIHRoZSBjcHUgbWFzayB0 byBiZSBjb21wdXRlZCBpbmNvcnJlY3RseS4KICAKICAgICAgICAKICAKICBGaXggdGhpcyBieSB1 cGRhdGluZyBnaWNfY3B1X21hc2soKS4gVGhpcyBmaXhlcyBhIGhhbmcgc2VlbiB3aGVuCiAgYm9v dGluZyBvbiBBUk02NCB3aXRoIFNNUCBlbmFibGVkLgoKUkVQT1NJVE9SWQogIHJTIEZyZWVCU0Qg c3JjIHJlcG9zaXRvcnkKClJFVklTSU9OIERFVEFJTAogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNk Lm9yZy9EODc1MQoKQUZGRUNURUQgRklMRVMKICBzeXMvYXJtL2FybS9naWMuYwoKQ0hBTkdFIERF VEFJTFMKCmRpZmYgLS1naXQgYS9zeXMvYXJtL2FybS9naWMuYyBiL3N5cy9hcm0vYXJtL2dpYy5j Ci0tLSBhL3N5cy9hcm0vYXJtL2dpYy5jCisrKyBiL3N5cy9hcm0vYXJtL2dpYy5jCkBAIC0xOTAs NyArMTkwLDcgQEAKIAogCS8qIFJlYWQgdGhlIGN1cnJlbnQgY3B1aWQgbWFzayBieSByZWFkaW5n IElUQVJHRVRTUnswLi43fSAqLwogCWZvciAoaSA9IDA7IGkgPCA4OyBpKyspIHsKLQkJbWFzayA9 IGdpY19kX3JlYWRfNChzYywgR0lDRF9JVEFSR0VUU1IoaSkpOworCQltYXNrID0gZ2ljX2RfcmVh ZF80KHNjLCBHSUNEX0lUQVJHRVRTUig0ICogaSkpOwogCQlpZiAobWFzayAhPSAwKQogCQkJYnJl YWs7CiAJfQoKCgpFTUFJTCBQUkVGRVJFTkNFUwogIGh0dHBzOi8vcmV2aWV3cy5mcmVlYnNkLm9y Zy9zZXR0aW5ncy9wYW5lbC9lbWFpbHByZWZlcmVuY2VzLwoKVG86IGpjaGFuZHJhLCAjYXJtNjQs IGZyZWVic2QtYXJtLWxpc3QsIGFuZHJldwpDYzogaW1wCg== --b1_cbdc67fa552cf3414ffd524db01da673 Content-Type: text/x-patch; charset=utf-8; name="D8751.22814.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="D8751.22814.patch" ZGlmZiAtLWdpdCBhL3N5cy9hcm0vYXJtL2dpYy5jIGIvc3lzL2FybS9hcm0vZ2ljLmMKLS0tIGEv c3lzL2FybS9hcm0vZ2ljLmMKKysrIGIvc3lzL2FybS9hcm0vZ2ljLmMKQEAgLTE5MCw3ICsxOTAs NyBAQAogCiAJLyogUmVhZCB0aGUgY3VycmVudCBjcHVpZCBtYXNrIGJ5IHJlYWRpbmcgSVRBUkdF VFNSezAuLjd9ICovCiAJZm9yIChpID0gMDsgaSA8IDg7IGkrKykgewotCQltYXNrID0gZ2ljX2Rf cmVhZF80KHNjLCBHSUNEX0lUQVJHRVRTUihpKSk7CisJCW1hc2sgPSBnaWNfZF9yZWFkXzQoc2Ms IEdJQ0RfSVRBUkdFVFNSKDQgKiBpKSk7CiAJCWlmIChtYXNrICE9IDApCiAJCQlicmVhazsKIAl9 Cgo= --b1_cbdc67fa552cf3414ffd524db01da673-- From owner-freebsd-arm@freebsd.org Sun Dec 11 22:01:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F147BC73A82 for ; Sun, 11 Dec 2016 22:01:26 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward1j.cmail.yandex.net (forward1j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B0EE9285 for ; Sun, 11 Dec 2016 22:01:26 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp1o.mail.yandex.net (smtp1o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::25]) by forward1j.cmail.yandex.net (Yandex) with ESMTP id 4D60720BE2 for ; Mon, 12 Dec 2016 01:01:23 +0300 (MSK) Received: from smtp1o.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp1o.mail.yandex.net (Yandex) with ESMTP id 10FD01300E77 for ; Mon, 12 Dec 2016 01:01:22 +0300 (MSK) Received: by smtp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id zQGlXHP28H-1MOmvOYD; Mon, 12 Dec 2016 01:01:22 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) X-Yandex-Suid-Status: 1 0 Subject: Re: Arduino Due To: freebsd-arm@freebsd.org References: <20161211034602.3fylwnxfbgl4ehgx@hal9000.meka.no-ip.org> From: Boris Samorodov Message-ID: <1752cc8d-fad7-141d-4950-37bb5dde9561@passap.ru> Date: Mon, 12 Dec 2016 01:01:19 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161211034602.3fylwnxfbgl4ehgx@hal9000.meka.no-ip.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Dec 2016 22:01:27 -0000 11.12.2016 06:46, Goran Mekić пишет: > Technically, Due is ARM based so the question is not off topic too much, I hope. Anyway, I'm having trouble with Arduino Due. On Debian all works well and the board behaves as expected. On FreeBSD, two things are kindda weird: > > 1. When ever I start Arduino IDE, L led stops blinking and continues blinking when IDE is closed. > 2. I can read board info through IDE until I flash sketch on FreeBSD. After that I can not get the info, and the L led is lit all the time. Do you use a FreeBSD port? Then freebsd-ports@ may be a more appropriate maillist to ask. And please include the info about your host OS, platform and port/package version of arduino. -- WBR, bsam From owner-freebsd-arm@freebsd.org Mon Dec 12 00:07:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4E160C72B09 for ; Mon, 12 Dec 2016 00:07:48 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 2D72F1F97 for ; Mon, 12 Dec 2016 00:07:47 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=yZbAit8/lYt0k4I4MCwpX6quM6hAlnlgUQwZoUuusds=; b=RQpN1/GroGf6imf3WCc/ju5Uq7 ILA+Z3DU5VPxOgGHgFZdbnahhv17w8sYeEqmkO6Y5FQflAVJgGTIMhH2+laIM9upgM53w0CfUFH19 r6peFAXFT9urQhy1IPkILI0LdFRklsVl8v7OCb/nCJNu10GB+IFA+nQav50O4xpwKWMs=; Received: from subs08-103-10-67-166.three.co.id ([103.10.67.166]:60827 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cGDE8-003txp-0A for freebsd-arm@freebsd.org; Sun, 11 Dec 2016 16:08:16 -0700 Date: Mon, 12 Dec 2016 07:08:10 +0800 From: Erich Dollansky To: freebsd-arm@freebsd.org Subject: tcsh modification to support Raspberry Pi 3 Message-ID: <20161212070755.4f1a56bd@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 00:07:48 -0000 Hi, tcsh has some environment variables 'hardcoded' which define the machine it runs on: HOSTTYPE=FreeBSD VENDOR=acorn OSTYPE=FreeBSD MACHTYPE=arm64 is what mine shows now. VENDOR and MACHTYPE have been unknown before. I modified the source /usr/src.head/contrib/tcsh/host.defs I replaced line 571: vendor : defined(arm32) || defined(__arm__)|| defined(__aarch64__) : "acorn" and inserted a new line 583 machtype: defined(arm64) || defined(__AARCH64EL__) : "arm64" I would need a little bit of hand holding to get this into the source tree. Who can help? Erich From owner-freebsd-arm@freebsd.org Mon Dec 12 03:04:42 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8834FC73E74 for ; Mon, 12 Dec 2016 03:04:42 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (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 67BD47A8 for ; Mon, 12 Dec 2016 03:04:42 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=0cjS6/6wJe0m5u428vceUQTACjQs32w+ta0uCMAEn2k=; b=oKYkkUCIkluSx3cyWltheZqNgr slR0xvpH9MMEI/Gs5KeTRi+otyipjezr7ZtsWNQGJiJDeaPdS6O76r+8xENJ13/g5yKhFxrVUCtH3 ZhFXqfOnx4TizTT+bF1T5/atZN44C/B3FehTSFNu2mW9/FFUVB4Y6DIn8oERFJJGmRi4=; Received: from subs08-103-10-67-166.three.co.id ([103.10.67.166]:60828 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cGGuu-000fj6-Tu for freebsd-arm@freebsd.org; Sun, 11 Dec 2016 20:04:41 -0700 Date: Mon, 12 Dec 2016 11:04:33 +0800 From: Erich Dollansky To: freebsd-arm@freebsd.org Subject: Raspberry Pi 3, compiled programs do not work Message-ID: <20161212110433.3d327295@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 03:04:42 -0000 Hi, it seems that there is more work to be done to get programs compiled on the Raspberry itself. Programs seem to compile but 'killed' is the only output they generate. I also noticed that the creation time is following the time. I assume, something is monitoring them for some reason. Does somebody work on this? How could I help there? Erich From owner-freebsd-arm@freebsd.org Mon Dec 12 03:26:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C9BCC7342E for ; Mon, 12 Dec 2016 03:26:12 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DD7291233 for ; Mon, 12 Dec 2016 03:26:11 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id DCA73C7342D; Mon, 12 Dec 2016 03:26:11 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DAAD8C7342C for ; Mon, 12 Dec 2016 03:26:11 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 94E841232 for ; Mon, 12 Dec 2016 03:26:11 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi0-x22c.google.com with SMTP id w63so75803913oiw.0 for ; Sun, 11 Dec 2016 19:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SVP8PrOMw70hdAnOfHN/rS6adiji4Duoh87nKZUFdIU=; b=chD767D7WfdiXXwwGTSf0nbFd1Skgfy/KBIJpwhVoK/1rz4hu9HXJJIUmU/AqvUWDZ TlOsshbbbEni7/9UyCVIlilB5wkHcLMO+JK3mUeg1EFnDh08YoQVNuzxQOP9JBrmZLlC rePJ40i9PxrYFp6Vs3nfVKtWIhnjP+GoJbu6C6Oz9IqjZLlBMMBvMfRxlto1xqKU+ooK RaRCOA3IRYjeDazN1X6YSw3yilbjKMTiPBAuq/FI7YsPydUN6LR1GuCHgzLToziHSQOe 2H0IeLMNpxbr0Vi/a9eLq9bIO1xYl5QL49erirpIq3rj8IOGPn5Krd33NN9GybagHb+m zcKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SVP8PrOMw70hdAnOfHN/rS6adiji4Duoh87nKZUFdIU=; b=gTwQDYKNMVQQ1KlwyI7xJI5+xehWxk+MjlePIp/6mexi7C7JqB9rLiJE1tbded7bqd HAgMvgsB84EtkAzgmluFBiXz1A27qWgDHwl8bRooMKLRDQtqPy1YVQ9nFLNKzNv5xN0e RQvGNXYKueIH0LlThshm5zhWnIpLxzC898GYU2lkii7Nm/9B65q8cBFn9LbxsZAhpLYW FKdgCKIldoOip82Fdt3oU+R+3norklJDFylw4TJqv80zKDUGK8JljzUd9ZYack1VjBV/ ghstgHkrQmgGmLF3gKXofaT2HsZQP+SnwivLdn0xtNBRzlpk3fg+E0xRN0jUUrP/4Cqn Z02g== X-Gm-Message-State: AKaTC02A+f2PhtfwmXIe5dhYVORlUxDVpEryoD1kB/UjItxiF5QiHo1YwQ0P74cg/uzDnkMjvMss/0NTNXyo6g== X-Received: by 10.157.0.73 with SMTP id 67mr48948342ota.141.1481513170944; Sun, 11 Dec 2016 19:26:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.145.33 with HTTP; Sun, 11 Dec 2016 19:26:10 -0800 (PST) In-Reply-To: <2660E67D-10E4-4680-B824-EBF138FBC3FF@cs.huji.ac.il> References: <7FD12DD6-B390-4EF3-811B-391798410BC0@cs.huji.ac.il> <1480950103.1889.251.camel@freebsd.org> <93729768-D887-4568-8686-FE691A881BC6@cs.huji.ac.il> <2660E67D-10E4-4680-B824-EBF138FBC3FF@cs.huji.ac.il> From: Ganbold Tsagaankhuu Date: Mon, 12 Dec 2016 11:26:10 +0800 Message-ID: Subject: Re: ubldr, was Re: dtb printout To: Daniel Braniss Cc: arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 03:26:12 -0000 On Mon, Dec 12, 2016 at 1:29 AM, Daniel Braniss wrote= : > > On 11 Dec 2016, at 6:09 PM, Ganbold Tsagaankhuu wrote= : > > > > On Tue, Dec 6, 2016 at 5:17 PM, Daniel Braniss > wrote: > >> >> > On 5 Dec 2016, at 17:01, Ian Lepore wrote: >> > >> > On Mon, 2016-12-05 at 15:48 +0200, Daniel Braniss wrote: >> >> Hi, >> >> the short version: >> >> is there a way to obtain the dtb from the kernel? >> >> >> >> the longer version: >> >> I am developing on several different arm boards, rpi, rpi2, orangepi- >> >> one, orange-pc, to mention >> >> a few, and each one has a different u-boot, ubldr, dtb, and I keep >> >> loosing track :-( >> >> I find myself too often wondering which ddb file got loaded. >> >> >> >> cheers, >> >> danny >> > >> > First: each one does NOT have a different ubldr. All ubldr.bin files >> > are the same, they're not board-specific anymore. (The elf versions, >> > ubldr without the .bin, may have a different load address in the elf >> > header, but other than that, they're identical too and can actually be >> > loaded at any address.) >> > >> > To see the contents of the dtb, use ofwdump. The output is not >> > especially pretty. There is a manpage for it. >> > >> > To just get a quick reminder of which file was loaded, create a >> > /boot/loader.rc.local (<-- .rc not .conf) that contains >> > >> > ubenv import fdtfile fdt_file >> > >> > Then in the running system you can use kenv and you'll see >> > >> > uboot.fdtfile=3D"bcm2835-rpi-b-rev2.dtb" >> > >> > Unfortunately, some u-boots use fdtfile, some use fdt_file. Grrr. >> > >> > You can, of course, use that ubenv import thing to pull any variable >> > from the uboot environment into the kernel environment. If you just >> > say ubenv import without naming a variable, you get all the vars >> > (including vars that contain scripts, which is kind of messy). >> > >> > =E2=80=94 Ian >> > >> >> as usual, I get more than I bargained for :-) >> on rpi adding ubenv import worked, but on orange/allwinner I got a >> =E2=80=98syntax error=E2=80=99, >> I tried to upgrade the ubldr, but so far i get: >> >> U-Boot SPL 2016.09 (Dec 05 2016 - 15:02:38) >> DRAM: 1024 MiB >> Trying to boot from MMC1 >> >> >> U-Boot 2016.09 (Dec 05 2016 - 15:02:38 +0200) Allwinner Technology >> >> CPU: Allwinner H3 (SUN8I 1680) >> Model: Xunlong Orange Pi PC >> I2C: ready >> DRAM: 1 GiB >> WARNING: Caches not enabled >> MMC: SUNXI SD/MMC: 0 >> reading u-boot.env >> >> ** Unable to read "u-boot.env" from mmc0:1 ** >> Using default environment >> >> In: serial >> Out: serial >> Err: serial >> Net: phy interface0 >> eth0: ethernet@1c30000 >> starting USB... >> USB0: USB EHCI 1.00 >> USB1: USB OHCI 1.0 >> USB2: USB EHCI 1.00 >> USB3: USB OHCI 1.0 >> USB4: USB EHCI 1.00 >> USB5: USB OHCI 1.0 >> scanning bus 0 for devices... 1 USB Device(s) found >> scanning bus 2 for devices... 1 USB Device(s) found >> scanning bus 4 for devices... 1 USB Device(s) found >> Hit any key to stop autoboot: 0 >> Booting from: mmc 0 ubldr.bin >> reading ubldr.bin >> 223912 bytes read in 53 ms (4 MiB/s) >> ## No elf image at address 0x42000000 >> ## Starting application at 0x42000000 ... >> > > Did ubldr work for you? > I feel like I have same problem: > > Booting from: mmc 0 ubldr.bin > reading ubldr.bin > 228276 bytes read in 67 ms (3.2 MiB/s) > ## No elf image at address 0x42000000 > ## Starting application at 0x42000000 ... > > Ganbold > > > > > > the latest one hangs, just like with you. > I=E2=80=99m using an older ubldr > Just curious, how old is your working ubldr? thanks, Ganbold > > > >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > > From owner-freebsd-arm@freebsd.org Mon Dec 12 04:01:42 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C2CCC73A75 for ; Mon, 12 Dec 2016 04:01:42 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 793E7326 for ; Mon, 12 Dec 2016 04:01:42 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 789BEC73A74; Mon, 12 Dec 2016 04:01:42 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 78458C73A73 for ; Mon, 12 Dec 2016 04:01:42 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-wj0-x230.google.com (mail-wj0-x230.google.com [IPv6:2a00:1450:400c:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0CFDD323 for ; Mon, 12 Dec 2016 04:01:42 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-wj0-x230.google.com with SMTP id tk12so61173008wjb.3 for ; Sun, 11 Dec 2016 20:01:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=zutsrLIsiohxdSq9aOhipuQXvawcVko9EQXIA+X1Tdc=; b=IuCI47ScHyYS90L71EtOdaDGRB3pneY27hp5JnQs4Fdax90k+FqqYM2f5IUe/QWKTm nttWaUy+5XZBmLW0WaGQGx1BJLGWXIOPZIO23+pIY1c5SJkxfMU5cWEsL8n7pc+wJQKo hAh4RUHuf5tLeMMu6xzIusCiTF3S47zcwEFUA2HiYC6DuhWu0yJCtKGlfjThKMYe+nS6 h0qUIlaFXp7LWJMbHa6TZsNy00sZIdRAC/dDEDeZ8R8oNPVAnM/7Rz32nx39YSZCKH9N NcWVwXSOSge4v4jqkp70T4hry/uR4F3B60dEo1MNLw9p28iGjZj/Ydrr4p3ElPdKJhV8 PCig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=zutsrLIsiohxdSq9aOhipuQXvawcVko9EQXIA+X1Tdc=; b=U3axXUTq/+1xv1s4gHhznQa3oF6k501dhalFMMaLvC9bpkoncEUFHnO8KwWnCD4Dd6 gxBSdZSmgPz6zBrs19Owy1rON32gXIRKxuvvNo6Lew3N9GckqBo2IVwzac68SQxB0FZi 0ryt2rUTV1xwxoBZl42pjopXKhNJVMzjVwvaIf3DpJN4d3/T1VzoNZ1WZBZqrDOUlbWm XlaqsyjnvMkAwZXSg83l95UOxq1Lg7pMwJLxQPS0XsU+qOom8yElm7ZXAq4v7YBAyLRM i/e9eZSirrpr3H0XRDP1ykQ8a3N5SbC+T+PsKcO/NuYmXLLK2vcD/JCOPrwwDqM5Be3j b9ew== X-Gm-Message-State: AKaTC02+3Mr5tZgJRniUJN6/VzQbyIpQZSDrv5jQAgcuEqRltbQZhgzmZ17Qa6Lt/GW2I+T82sOdQElGFcpz8Q== X-Received: by 10.194.113.2 with SMTP id iu2mr90634437wjb.32.1481515299202; Sun, 11 Dec 2016 20:01:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.153.26 with HTTP; Sun, 11 Dec 2016 20:01:38 -0800 (PST) In-Reply-To: References: <7FD12DD6-B390-4EF3-811B-391798410BC0@cs.huji.ac.il> <1480950103.1889.251.camel@freebsd.org> <93729768-D887-4568-8686-FE691A881BC6@cs.huji.ac.il> <2660E67D-10E4-4680-B824-EBF138FBC3FF@cs.huji.ac.il> From: Luiz Otavio O Souza Date: Mon, 12 Dec 2016 02:01:38 -0200 Message-ID: Subject: Re: ubldr, was Re: dtb printout To: Ganbold Tsagaankhuu Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 04:01:42 -0000 On 12 December 2016 at 01:26, Ganbold Tsagaankhuu wrote: > On Mon, Dec 12, 2016 at 1:29 AM, Daniel Braniss wrote: > >> >> On 11 Dec 2016, at 6:09 PM, Ganbold Tsagaankhuu wrote: >> >> >> Did ubldr work for you? >> I feel like I have same problem: >> >> Booting from: mmc 0 ubldr.bin >> reading ubldr.bin >> 228276 bytes read in 67 ms (3.2 MiB/s) >> ## No elf image at address 0x42000000 >> ## Starting application at 0x42000000 ... >> >> >> >> the latest one hangs, just like with you. >> I=E2=80=99m using an older ubldr >> > > Just curious, how old is your working ubldr? Hi Ganbold, ubldr and ubldr.bin are broken on -head. I haven't had the time to bisect the exact commit that introduced the problem, but I bet it was the clang-3.9 import. I'm using an old ubldr as a workaround too (initially used to confirm the issue). Luiz From owner-freebsd-arm@freebsd.org Mon Dec 12 08:38:49 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A200C73F05 for ; Mon, 12 Dec 2016 08:38:49 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mailman.ysv.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 65E036C6 for ; Mon, 12 Dec 2016 08:38:49 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6530CC73F04; Mon, 12 Dec 2016 08:38:49 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 64D0AC73F03 for ; Mon, 12 Dec 2016 08:38:49 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 26C476C5 for ; Mon, 12 Dec 2016 08:38:49 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id v84so80615358oie.3 for ; Mon, 12 Dec 2016 00:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xCF76MW5INIQggjHtS77Th3klIxpSkUrxhUWfFiqcEI=; b=RWC+004AOfP2zEFx3oAcC7H5z8w+Pp/rJdIAWgxX1V7V2qktpQzLqzbKCBqQLhtOB2 K/uLgo3+ajVueDajljqS5+qgZPCwQ8ndqwhdemSx1nRnqWQPMVCGjYL1YPZbzwdZRjjU eMUCuMeIySYcZ6AmdzFPoSWpxxl+H2xYpjnPxBy7OtZtgNuRB01LrEMED7Dr4clYDSHO zAUEuhv3pWIdxGRkhM9aeHrzlHnW6CVwET7NF6jDFQSvLFozbYDjQ9P5q1wQVTUyJi7K 29rqjMCyUYJY9Ne0mAGuifxeRRXPSwTti5GmiaBt+nmt8SRi0s3t4L6Yn+Ek3wkGN6EM +d+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xCF76MW5INIQggjHtS77Th3klIxpSkUrxhUWfFiqcEI=; b=kLKtuzEtKHTdr2KzE0GuA4g8+T2j5fnTK3RkcJZhLY2/RrjRsP4yysLA6JX1ApHcTC cBnJGgwEeRSgL3n0Z5/i62LNXftxpA6Wfqjaj5JD0pKF2YlTKAxFGBOwWr+bsIKduIXg 6smDh7o3o4WLsvcIPtBS+CI6+n+crXRc38m6VS73qPbddHCWITIHqgRBliE0UwiqIvkL IvKvHT0415AraITZ+bHPQkqnGZrjbbDAot3QCFmh9GJOdZykoB+gkTJdGOiCzOyqxY3A 1fuh+dHm+wq/8mjL82jawY3rgkJXnvaHImcbTfPITyX1nQv+jVYhe5soQglxM56AUs7A tVfA== X-Gm-Message-State: AKaTC02mMaKOOQfJ0p6iZ5weZjbLxiIooCRZGnrP1ZOs/yLLQezyQzfKPXHlNglD5umX1/VOz3GVBtGGGyFRdA== X-Received: by 10.157.10.40 with SMTP id 37mr46394970otg.190.1481531928368; Mon, 12 Dec 2016 00:38:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.145.33 with HTTP; Mon, 12 Dec 2016 00:38:48 -0800 (PST) In-Reply-To: References: <7FD12DD6-B390-4EF3-811B-391798410BC0@cs.huji.ac.il> <1480950103.1889.251.camel@freebsd.org> <93729768-D887-4568-8686-FE691A881BC6@cs.huji.ac.il> <2660E67D-10E4-4680-B824-EBF138FBC3FF@cs.huji.ac.il> From: Ganbold Tsagaankhuu Date: Mon, 12 Dec 2016 16:38:48 +0800 Message-ID: Subject: Re: ubldr, was Re: dtb printout To: Luiz Otavio O Souza Cc: Daniel Braniss , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 08:38:49 -0000 On Mon, Dec 12, 2016 at 12:01 PM, Luiz Otavio O Souza wrote: > On 12 December 2016 at 01:26, Ganbold Tsagaankhuu wrote: > > On Mon, Dec 12, 2016 at 1:29 AM, Daniel Braniss wrote: > > > >> > >> On 11 Dec 2016, at 6:09 PM, Ganbold Tsagaankhuu wrote: > >> > >> > >> Did ubldr work for you? > >> I feel like I have same problem: > >> > >> Booting from: mmc 0 ubldr.bin > >> reading ubldr.bin > >> 228276 bytes read in 67 ms (3.2 MiB/s) > >> ## No elf image at address 0x42000000 > >> ## Starting application at 0x42000000 ... > >> > >> > >> > >> the latest one hangs, just like with you. > >> I=E2=80=99m using an older ubldr > >> > > > > Just curious, how old is your working ubldr? > > Hi Ganbold, > > ubldr and ubldr.bin are broken on -head. I haven't had the time to > bisect the exact commit that introduced the problem, but I bet it was > the clang-3.9 import. > Yeah, it could be. At least r308903 (few days before clang import) works for me. Ganbold > > I'm using an old ubldr as a workaround too (initially used to confirm > the issue). > > Luiz > From owner-freebsd-arm@freebsd.org Mon Dec 12 14:55:15 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6EEFBC7369A for ; Mon, 12 Dec 2016 14:55:15 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 154456F for ; Mon, 12 Dec 2016 14:55:15 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id y205so10905913qkb.1 for ; Mon, 12 Dec 2016 06:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=1WNsSx6dLDrNbtHWvjTkAdi55Om38YFGXHYI8aT7Vqk=; b=XxpY0945etOHhWLZz1RwMfxG9miZ3Sj4CN9hAEMhMfrgrfzGG9DdAFwJuaJ0Bo5FYg N1S2CoDBGJCU9d//gE4962X1XpIajgeGlKlm/xNP69+Q6TgpowN6wzWOHhZYDNJLuLmZ rNwWWG/HJmxXn7HuAbK+uVolf5X7iTCle9zbr7UvYhdMMT6QcQem1aHWyBfv/DH8k1a4 gOm2A7ERcbCS/rf4FmHZtoCeoL2mzi/iBDhV8EDj4knA42mXWQIo/iNEAPSIFKhenuF9 h088sZJtUY3+RC9s9iEvOtVh5HGz+x0BgHbbJe732BcNEgCFdb2eYli7DoEzWBaacJPJ NE6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1WNsSx6dLDrNbtHWvjTkAdi55Om38YFGXHYI8aT7Vqk=; b=gbMpJEfd+wx6E87s7MNiaNRxgASpRF7Of5xBvGee8UihZN9+m9VWfpBH3ZASrW8Gt/ aRb3DsxJicmrjAXrQZAvXQK/ZisZz3ZMmc1GPxWTTu7+vmgDohuxuCD+ItJxwlpxE6F8 X9OpB6pEqbhZsK8Rs3M4/KioNuvozIwHId/JPcKotdKAWUZT16IviLsnhXuG7XwPHEse ZrrIERo1z9LcKmRmjwy57TyltjPL4F59QbgboP9jHX1r6/ZbQN0FmLY3NJ73EoeH6DTA z0QNLBoatqC4bH9MjFzaji92W05FYNSH1YwN/+7c6JOvppcclsdw7Mfbb7VjJjBPl2N2 wo1Q== X-Gm-Message-State: AKaTC03xDQR4jPVZz/Brn4m7u+Llw/qCCLfT4JN8YTFV8GH7KA78iX1veS8zvHAQHZHwlx30SgXgXoYAX3YsXQ== X-Received: by 10.55.154.200 with SMTP id c191mr81285756qke.117.1481554514200; Mon, 12 Dec 2016 06:55:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.167.137 with HTTP; Mon, 12 Dec 2016 06:55:13 -0800 (PST) From: Mihai Carabas Date: Mon, 12 Dec 2016 16:55:13 +0200 Message-ID: Subject: Cubieboard2 with custom bootloader To: freebsd-arm@freebsd.org, Alex Ivan Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 14:55:15 -0000 Hello everyone, We are working on bhyve hypervisor for ARM. We are trying to boot FreeBSD11 on a Cubieboard2 using a compiled u-boot from sources and it gets stuck after loading the FreeBSD kernel. We needed to compile u-boot from sources, because the precompiled one from packages exits hypervisor mode and falls back to supervisor mode. We don't have a JTAG to debug the problem. Did anyone manage to boot FreeBSD11 on Cubie2 from a compiled from sources u-boot? Thank you, Mihai Carabas From owner-freebsd-arm@freebsd.org Mon Dec 12 15:01:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D01E1C73923 for ; Mon, 12 Dec 2016 15:01:26 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9594C3E6 for ; Mon, 12 Dec 2016 15:01:26 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi0-x236.google.com with SMTP id b126so90102875oia.2 for ; Mon, 12 Dec 2016 07:01:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=flQvrugYJllZ4nXznDcNVizSd0qtXLfyYLZHbuna37Y=; b=GQtydEje0eZxZ+bki+IPFzlWU+PFfa9y78U1wzttubnV6xYyDVuv7kLgQqseUltQ1g +ZTQXE3AfcvGStOk/9UI96xMir6XTzWf9ovkzmvK+I9HxXiwU2eWHn4RJNQN2NYriGbh R8BahWM8kfsbIN64qJuyhcmxN+xJdUgriL+khz9LUbcEZqtTrZqXOgwWM0o3C+8C0GrN xh16jsWSIBMHSTfma2b26vcURwL0LjVDgPgAxmlLSLMLuWa8gWAMy/JCL9Y5Bn+KrAu/ N9WT46uJqYmomLK8y9DcOwYpDFrt6JzNnLPur0/VfItBBEi/OCbxJU80n8LJcLNNnAdr kQpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=flQvrugYJllZ4nXznDcNVizSd0qtXLfyYLZHbuna37Y=; b=J5+hToxvRhTpGnaSvBmosGgSJzmitQ3m3nzq9NV46cP9HW1vKa6FWles+3PgRco0gK m5SzVWjTZ5mlaIn7xN24iwVc5V44g3NSljdCUuX0wUpf/KSjBtQm6ZltRwrzEmjlU1wQ dDUH1zGTNkB+woU7sF9ioG8HTLpgrlOGyBpEYelbLspUToqntbGMfHLWcUX3w2VUSIpI M9CLVlp1rxrsLyeeX8KGUFihOvfeZB/6GLiT0tdaeux7jn33VeYUWh8+928mRmYdIiBg BUQjVQ+0UoQ1/w7jytWxx1Y2BfAab5xPm/H7a/T9dmjr0RtCb8ubQS0p1q1TZ4yF/W9+ j2cA== X-Gm-Message-State: AKaTC03fuB5NywsRLZMvljmDSS67Ek6/uD9PlIi+oIKV55dBnKaaDUr6DIAq6gRd2e+2ziNrj2UYaVoI3+916g== X-Received: by 10.202.225.85 with SMTP id y82mr49876768oig.209.1481554885477; Mon, 12 Dec 2016 07:01:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.145.33 with HTTP; Mon, 12 Dec 2016 07:01:25 -0800 (PST) In-Reply-To: References: From: Ganbold Tsagaankhuu Date: Mon, 12 Dec 2016 23:01:25 +0800 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Mihai Carabas Cc: "freebsd-arm@freebsd.org" , Alex Ivan Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 15:01:26 -0000 On Mon, Dec 12, 2016 at 10:55 PM, Mihai Carabas wrote: > Hello everyone, > > We are working on bhyve hypervisor for ARM. We are trying to boot FreeBSD11 > on a Cubieboard2 using a compiled u-boot from sources and it gets stuck > after loading the FreeBSD kernel. > > We needed to compile u-boot from sources, because the precompiled one from > packages exits hypervisor mode and falls back to supervisor mode. I guess you can use the port (sysutils/u-boot-cubieboard2) to build u-boot from source and use it. Ganbold > We don't > have a JTAG to debug the problem. > > Did anyone manage to boot FreeBSD11 on Cubie2 from a compiled from sources > u-boot? > > Thank you, > Mihai Carabas > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Mon Dec 12 15:05:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15099C73A66 for ; Mon, 12 Dec 2016 15:05:58 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 605258DD for ; Mon, 12 Dec 2016 15:05:56 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 215ff44b; Mon, 12 Dec 2016 16:05:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=3w8vBSwAPRNdqpi1/F4pUBgVh1g=; b=JE65KoIVE0INAgncB8mFMVhrBlpr auGbRyEa337rS6IRZYajNCjxnwwtE7+4Ft+0r6gl5zXCfu8jxmEOeOIh36LU0zOv 1LoAdRmFmsVAyfWuGLljr8dQrjjY/KlH6eQ02fv+AQDsPf0SFIhbYMf+D7OxLeQU ofS7SFj0wV7rgN4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=X1C72NVjigQIwFVqB0W1/da3lrLmnC14Ohy0cZfITvJiyYgKLOwEb275 ZCQcEld+5pjANbtOIapgGU3mehM9i200lh+lUWc//NnK6kdLG7+7X+iChiOX6rcD MWKurZHFPsHN/h4n7n6U9FIUl02r5rpqUGRZAdHaR3M7RmRwMuw= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6493bf8d TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 12 Dec 2016 16:05:53 +0100 (CET) Date: Mon, 12 Dec 2016 16:05:53 +0100 From: Emmanuel Vadot To: Mihai Carabas Cc: freebsd-arm@freebsd.org, Alex Ivan Subject: Re: Cubieboard2 with custom bootloader Message-Id: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 15:05:58 -0000 On Mon, 12 Dec 2016 16:55:13 +0200 Mihai Carabas wrote: > Hello everyone, > > We are working on bhyve hypervisor for ARM. We are trying to boot FreeBSD11 > on a Cubieboard2 using a compiled u-boot from sources and it gets stuck > after loading the FreeBSD kernel. > > We needed to compile u-boot from sources, because the precompiled one from > packages exits hypervisor mode and falls back to supervisor mode. We don't > have a JTAG to debug the problem. > > Did anyone manage to boot FreeBSD11 on Cubie2 from a compiled from sources > u-boot? > > Thank you, > Mihai Carabas > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" Hi, multiple questions : - How did you compile uboot ? - Did you try booting kernel directly or ubldr first ? - Where do it get stuck exactly ? You can find all my u-boot patches here : https://people.freebsd.org/~manu/uboot/ Those patches applies on u-boot-2016.11 and it's everything you need to have a U-Boot for Allwinner device (with some extras that you won't need too). -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Dec 12 15:07:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30677C73B02 for ; Mon, 12 Dec 2016 15:07:21 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFFBC967 for ; Mon, 12 Dec 2016 15:07:20 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by mail-qk0-x22e.google.com with SMTP id q130so85393841qke.1 for ; Mon, 12 Dec 2016 07:07:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YhGEvm6yMgqEwQ4dTWxCO5k3TfFjIufdclUpZrCWn4w=; b=U2OXHB84R0512/JoFUze9sQRC8CiKnFkp9EvLQip398ywpa6danpZIJ+XmV6p1gMsu cvqL3+thLOO+77yBHEdDUqjPMeDEUOnUY53OsGlwJwEf+0uKxNfWfF9bsRuMqEz0JR58 pxhf2m7ls3DxMRZ22Xd0kMFRBMzBxlsKyTxtn+Jer5zgQdLn/MrDL3gZjVveh8I1m4KQ stPao3khKAHWd3HhrIpb8mHen9ISXlcYZFWJqXp//+ECnjW4GSQ11ue4zeDoZvL2vWGV cHrtZKOyoTXPRkyxXcFXavHnXeUIHwvnADSLK0IUVLbkLofV61q18xFJ2eQ7MoJRYHHf hAFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YhGEvm6yMgqEwQ4dTWxCO5k3TfFjIufdclUpZrCWn4w=; b=IPVHusC79JEICFOd0XobIhsKtGts9L5QTQpT0uJXT9Hs/qeYEfzqBv86YAnBRebZJx Mvnnd+++MYB2ftCl8z9sUX28wR5VTJVnEk7qrFV78jnQJxjQXkpdGINsU/2VvuINSEoN wP5KMxMev4cj13/+1y41xxggoMunmX8rRtt8nVFBEMbZGTzdpY7AHeOpz0zLd/dQwkmQ zNM2roX2ILxePcDQ9zr0umz3IwA+fAtRCfXI1ERBfvNHY10Nc9yXrjjwCR8MT8zTLuq9 Oa+0NI5vh6SequFpDqkeBRTr4CpFowCHirjyx6zmv6DbFas5ivNrVsNVW43NGwMyWomx OAcw== X-Gm-Message-State: AKaTC03kC2ZxLJizlkT/wKiu4NsYAlKdf9TQQANH83vCYhARXSr7i9+wNbtigit8OzKmEX792jPsZQAEj8PAng== X-Received: by 10.55.103.80 with SMTP id b77mr80019359qkc.142.1481555239888; Mon, 12 Dec 2016 07:07:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.167.137 with HTTP; Mon, 12 Dec 2016 07:07:19 -0800 (PST) In-Reply-To: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> From: Mihai Carabas Date: Mon, 12 Dec 2016 17:07:19 +0200 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org, Alex Ivan Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 15:07:21 -0000 Hi Manu, Thank you very much for the patches. I will talk with Alex (at CC) at we will come with an answer. Thank you, Mihai On Mon, Dec 12, 2016 at 5:05 PM, Emmanuel Vadot wrote: > On Mon, 12 Dec 2016 16:55:13 +0200 > Mihai Carabas wrote: > > > Hello everyone, > > > > We are working on bhyve hypervisor for ARM. We are trying to boot > FreeBSD11 > > on a Cubieboard2 using a compiled u-boot from sources and it gets stuck > > after loading the FreeBSD kernel. > > > > We needed to compile u-boot from sources, because the precompiled one > from > > packages exits hypervisor mode and falls back to supervisor mode. We > don't > > have a JTAG to debug the problem. > > > > Did anyone manage to boot FreeBSD11 on Cubie2 from a compiled from > sources > > u-boot? > > > > Thank you, > > Mihai Carabas > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > Hi, multiple questions : > > - How did you compile uboot ? > - Did you try booting kernel directly or ubldr first ? > - Where do it get stuck exactly ? > > You can find all my u-boot patches here : > https://people.freebsd.org/~manu/uboot/ > > Those patches applies on u-boot-2016.11 and it's everything you need > to have a U-Boot for Allwinner device (with some extras that you won't > need too). > > -- > Emmanuel Vadot > From owner-freebsd-arm@freebsd.org Mon Dec 12 15:09:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6F802C73B5D for ; Mon, 12 Dec 2016 15:09:05 +0000 (UTC) (envelope-from meka@tilda.center) Received: from mail.tilda.center (mail.tilda.center [188.226.130.133]) by mx1.freebsd.org (Postfix) with ESMTP id 3B64C9DC for ; Mon, 12 Dec 2016 15:09:04 +0000 (UTC) (envelope-from meka@tilda.center) Received: from hal9000.meka.no-ip.org (unknown [87.116.181.51]) by mail.tilda.center (Postfix) with ESMTPSA id AB7C5612F5; Mon, 12 Dec 2016 16:08:56 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tilda.center; s=mail; t=1481555336; bh=hlDrbRhXrbJ5Iuq87fbvil/Qji/2C4TwWrAAeR9dNB4=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ksSo8ipTSVbbYYRijA7WGSVn8cvBliXlOq6C7oXBt236e6rva2wQ4m8gGlZr0VkzI iKKx+9mQ9X3cZEsPHhSzV3HiZJwRadjNj/9XsibQukKCffk77IUEhBmVFh3qd67/hi 4CguRs6OpslGgLXHhBY8GqORLApcn03OIdhQDUg8= Date: Mon, 12 Dec 2016 16:08:56 +0100 From: Goran =?utf-8?B?TWVracSH?= To: Boris Samorodov Cc: freebsd-arm@freebsd.org Subject: Re: Arduino Due Message-ID: <20161212150856.2z3kq3rscghiuvvf@hal9000.meka.no-ip.org> References: <20161211034602.3fylwnxfbgl4ehgx@hal9000.meka.no-ip.org> <1752cc8d-fad7-141d-4950-37bb5dde9561@passap.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="vyyi6ckajh7urxlr" Content-Disposition: inline In-Reply-To: <1752cc8d-fad7-141d-4950-37bb5dde9561@passap.ru> User-Agent: NeoMutt/20161126 (1.7.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 15:09:05 -0000 --vyyi6ckajh7urxlr Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Mon, Dec 12, 2016 at 01:01:19AM +0300, Boris Samorodov wrote: > Do you use a FreeBSD port? Then freebsd-ports@ may be a more > appropriate maillist to ask. And please include the info about > your host OS, platform and port/package version of arduino. I did write to the port maintainer, as I thought that if it's about the port, maintainer is the one who should hear about it. I'm running two boxes: laptop and desktop. Laptop has i7 CPU with FreeBSD 11.0-RELEASE and desktop has i5 CPU with FreeBSD 11.0-STABLE. Arduino IDE is arduino16 from the latest snapshot of ports. Thank you! Regards, meka --vyyi6ckajh7urxlr Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAlhOvYcACgkQWj1Tknov rLZyvRAAiREvKQAWh7wyxd/0ROeIu/S8nQ33IuapLG9EGpnJ59a/xlrBGPl+2H/r wpdeTHo1mYukPpAUUu9VldgreWtNFfaIQ0nhNIVMfiEnT5xrU+YDszdblgz6Ni45 dxUiwb5ur6P4gV9zkw5VoFff8dioP9WvQ/CAf2es6vmPXnEmbX+vgKtk5ttU+oy6 Yc4dDUS36aDKOlWenzkKxvPUwjkaZrcxgBR8wRmHxFH094N9ZKMFO2NeJ5FICCv7 F+fkH9/eE7gCicMTU9B536ptz03EBeffEltTYyiqLjhf8kLYylQE3P2D98lUSOX6 v+CUvUf0i4sxn+fxVP5UkRdseYQB01nW9fjebycLbVN9Bq0E5D3uu6YJ7c5Xornz n6/c5DVHJRVVtmLrs1IAgb/oOGIFnPTFwYmZ7Ajh8KHMN8T6TP3LtGPobIUv55lR qjMtDnACZ9yjJZbO7IxvUpPu/V5tfkLgGLlsCQydybHTJ7ypHignm/X85vuYaCmU eGydppFXoFOUqAJ9S3UpaZZOt3B7V8xJqYZn3VkNTOsXDM4rcQpIT9JeFMvkOXfh TyidMh7a1bLd1mHCkF/OI4wg4cI7FClqtK47UPHGTOf9as3RqiNLkMY1Nd50coGg h8U6R67M4zcnINk8+fJ8yBtKaLv43bEEkSkdk0hzicxS7L2SkYY= =uE00 -----END PGP SIGNATURE----- --vyyi6ckajh7urxlr-- From owner-freebsd-arm@freebsd.org Tue Dec 13 00:59:27 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 704C6C7418F for ; Tue, 13 Dec 2016 00:59:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x242.google.com (mail-io0-x242.google.com [IPv6:2607:f8b0:4001:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3962D1350 for ; Tue, 13 Dec 2016 00:59:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x242.google.com with SMTP id y124so25409166iof.1 for ; Mon, 12 Dec 2016 16:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=mTyomBFUkvlrcDZIO48zXu6s4Mk5n2CPlQzhlniVZ/Y=; b=fkPHkxEXHZneBxECbuUOiJJXe2R+LhLvCPumiqkXkrJj5YzH4tEwl2gUQFqjCl4jSU H4/IdhrrPGNHCZj/iSNydN1PdY5HJgQoMf64JHsW1Jn5Gf/bhSivAPpSQJQKTEPpNahZ Xm45unF0ddRfQmpOsR27fJY/wybhk0f3BR0j4v+7pZo8D7aDn7rLcPQKdXJ85se1D0Ps RZ0K4tt9ZvJIeQivqo74fF0twDrH7b0RvvMZFWWDoRXuosB2F5cfAHYn2VJcHMp+2FT/ mKnYM/1TbIBxVp4kRRsn8+PSi8pCsi1YpSwOmyvPAn5zofjJ1YG1MIz815xqtRcNKnUB YWjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=mTyomBFUkvlrcDZIO48zXu6s4Mk5n2CPlQzhlniVZ/Y=; b=jBdbw6IIzsgaqBdzQEROFuqGf/OG0qXObtTlK/4V80aIKernGpt/+WGnq9hVMBkaVG 51bzCwvs9A4F2M4q+P23AM4wb2CFqTUkdiHj9DIa9mQAOrdBk3cujx7PxjI02zxH8Ja3 9yc9QWi3veWhd4AnCSD4ZkJxkG+NKm4OfohHBiks5xEnhnQFaBwuDxzO9xQKonkhfrBg IIDwV1CNVZXd4kxGAUz9XU1WZh43nN4YDn3R4imgnzg+TKz4DtL6LRm7ca4r1SO/Rw/3 2Ac10Rgh3iEWql3nqoGN7dRUqMW/l83hU83JoLuCOv0Yd7D5ecjviRWF8o39ATWmdrmo pKPw== X-Gm-Message-State: AKaTC02E9vZLP0Iqq2fqXfGcPEBXP0ePW8a4IOBfKUt9faR/zfrFh7Go3jCoQ1MMYSzhTV25V7Y3IUbutlXkfw== X-Received: by 10.107.139.74 with SMTP id n71mr83748938iod.166.1481590766624; Mon, 12 Dec 2016 16:59:26 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.31.199 with HTTP; Mon, 12 Dec 2016 16:59:26 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> From: Warner Losh Date: Mon, 12 Dec 2016 17:59:26 -0700 X-Google-Sender-Auth: CGPqfH0IWOfcjx1UQcmySrlNzuA Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Emmanuel Vadot Cc: Mihai Carabas , "freebsd-arm@freebsd.org" , Alex Ivan Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 00:59:27 -0000 On Mon, Dec 12, 2016 at 8:05 AM, Emmanuel Vadot wrote: > On Mon, 12 Dec 2016 16:55:13 +0200 > Mihai Carabas wrote: > >> Hello everyone, >> >> We are working on bhyve hypervisor for ARM. We are trying to boot FreeBSD11 >> on a Cubieboard2 using a compiled u-boot from sources and it gets stuck >> after loading the FreeBSD kernel. >> >> We needed to compile u-boot from sources, because the precompiled one from >> packages exits hypervisor mode and falls back to supervisor mode. We don't >> have a JTAG to debug the problem. >> >> Did anyone manage to boot FreeBSD11 on Cubie2 from a compiled from sources >> u-boot? >> >> Thank you, >> Mihai Carabas >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > Hi, multiple questions : > > - How did you compile uboot ? > - Did you try booting kernel directly or ubldr first ? > - Where do it get stuck exactly ? > > You can find all my u-boot patches here : > https://people.freebsd.org/~manu/uboot/ > > Those patches applies on u-boot-2016.11 and it's everything you need > to have a U-Boot for Allwinner device (with some extras that you won't > need too). Once I get some issues ironed out with the BBB u-boot, I plan on pushing all the u-boot to this level. Or I may leave the ones that don't work at the current level since I really want to get allwinner into the fold. Then I can start to pull in some of your patches to the u-boot github branch since many are really cool. Warner From owner-freebsd-arm@freebsd.org Tue Dec 13 09:01:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EA279C74DA3 for ; Tue, 13 Dec 2016 09:01:45 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B189E1F17 for ; Tue, 13 Dec 2016 09:01:45 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi0-x22b.google.com with SMTP id b126so116354763oia.2 for ; Tue, 13 Dec 2016 01:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=S7RQl9dBh+MzKKuWJ15kyOhBl1rp1JUu5+6NnHfYJuU=; b=Y3mRxTvA7w8/aVdOAdQ9QWcOh5XMaQc2ElarLqfKiibLZhCWVpOMI3B76HCjUCa9XC VtZ92IRtg+AsCmZi9K5Mlz2eUz5KsVv38bEkGpKccs6kccdZGwn3klcWmA9kASbr+s5d GBa93SB2ZPt0wXGu1NQzjF8+z++hMQw979+fNJd7Deqs8wVXn7+/fk4TGnsAfL9ctxBf HfBn5XOTlw9gL2V/TSqoQfwE9p64koTGBMvwQHwlkuoXaQzcrv/TWAAyJErEDQKnX/o4 qHSbnjjjxa9G/dMRyVERJ0qtJXeon07EBu3yTBVwQSDBA3cIb8MiNRWF4JczAftElEj3 5zaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=S7RQl9dBh+MzKKuWJ15kyOhBl1rp1JUu5+6NnHfYJuU=; b=F7RoLu1NRLvNVjvlE0+ApV3FEBnl6/7b15s64Al7mrp5eAckcohjlp/3UemG4aZ/zb kCCJCde0plgT7TvIFOBvD96fFvlhSIejOsg90uyY7lCM7GqBPLsce4BU9nmI8f3ZACsW nkTQaLoh55c0jvr5Ue3nlBj21+LkvpYje4oXLXXmSlz0AY6OByXKHQnR5tM3BaGXQaK6 Lr7ta8isd0DGh/7OPZJxRd5kfrxwKntPANl+37XrD8aZeWrpJzkKJjt16hpF7YO6Jho8 SFycghNKxqIArKQP79LRIBS+TBF+F2Fp6JmSElDzhItd3drEsQaAYBK04lguHCYW2hHH VP6Q== X-Gm-Message-State: AKaTC006OeJ+j3U659nv8u6hBVhuHlME9yfn1ts8UkvT6kzk/wra+6GlQWNU1FpVTy/isEFUpoqZoPoDQh9sUA== X-Received: by 10.157.10.40 with SMTP id 37mr49447257otg.190.1481619704618; Tue, 13 Dec 2016 01:01:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.145.33 with HTTP; Tue, 13 Dec 2016 01:01:44 -0800 (PST) From: Ganbold Tsagaankhuu Date: Tue, 13 Dec 2016 17:01:44 +0800 Message-ID: Subject: dwc_otg problem To: freebsd-arm , Hans Petter Selasky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 09:01:46 -0000 Hi, I have trouble with dwc_otg in Rk3188 device. Kernel FreeBSD 11.0-CURRENT #134 r289559: Tue Oct 20 14:53:13 ULAT 2015 works: ... dwcotg0: mem 0x10180000-0x101bffff irq 48 on simplebus0 usbus0 on dwcotg0 dwcotg1: mem 0x101c0000-0x101fffff irq 49 on simplebus0 usbus1 on dwcotg1 uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 68 on simplebus0 uart0: console (115200,n,8,1) dwmmc0: mem 0x10214000-0x10214fff irq 55 on simplebus0 dwmmc0: Hardware version ID is 240a mmc0: on dwmmc0 cryptosoft0: Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 IPsec: Initialized Security Association Processing. usbus1: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 ugen1.1: at usbus1 uhub0: on usbus1 uhub1: on usbus0 mmcsd0: 4GB at mmc0 25.0MHz/4bit/256-block Release APs WARNING: WITNESS option enabled, expect reduced performance. WARNING: DIAGNOSTIC option enabled, expect reduced performance. Root mount waiting for: usbus1 usbus0 uhub1: 1 port with 1 removable, self powered uhub0: 1 port with 1 removable, self powered ugen1.2: at usbus1 uhub2: on usbus1 Root mount waiting for: usbus1 uhub2: 4 ports with 4 removable, self powered Root mount waiting for: usbus1 ugen1.3: at usbus1 urtwn0: on usbus1 urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R ... However recent head (FreeBSD 12.0-CURRENT #5 r309888M: Tue Dec 13 16:34:12 ULAT 2016) is not working: ... dwcotg0: mem 0x10180000-0x101bffff irq 11 on simplebus0 usbus0 on dwcotg0 dwcotg1: mem 0x101c0000-0x101fffff irq 12 on simplebus0 usbus1 on dwcotg1 uart0: <16650 or compatible> mem 0x20064000-0x200643ff irq 15 on simplebus0 uart0: console (115200,n,8,1) dwmmc0: mem 0x10214000-0x10214fff irq 17 on simplebus0 dwmmc0: Hardware version ID is 240a mmc0: on dwmmc0 cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen1.1: at usbus1 ugen0.1: at usbus0 uhub0: on usbus0 uhub1: on usbus1 mmcsd0: 4GB at mmc0 25.0MHz/4bit/256-block Release APs WARNING: WITNESS option enabled, expect reduced performance. Trying to mount root from ufs:/dev/mmcsd0s2a []... uhub0: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, ignored) usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen1.2: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device ... thanks, Ganbold From owner-freebsd-arm@freebsd.org Tue Dec 13 19:06:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8B7E2C768B5 for ; Tue, 13 Dec 2016 19:06:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 4B04D1E27 for ; Tue, 13 Dec 2016 19:06:58 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (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 1006E1FE157; Tue, 13 Dec 2016 20:06:57 +0100 (CET) Subject: Re: dwc_otg problem To: Ganbold Tsagaankhuu , freebsd-arm References: From: Hans Petter Selasky Message-ID: <5ce7a4e6-25a0-73b4-0e6b-751814c62121@selasky.org> Date: Tue, 13 Dec 2016 20:06:29 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 19:06:59 -0000 On 12/13/16 10:01, Ganbold Tsagaankhuu wrote: > usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, > ignored) > usbd_setup_device_desc: getting device descriptor at addr 2 failed, > USB_ERR_TIMEOUT > ugen1.2: at usbus1 (disconnected) > uhub_reattach_port: could not allocate new device > ... Hi, This might look like a DWC OTG IRQ problem. Can you check "vmstat -i" ? --HPS From owner-freebsd-arm@freebsd.org Tue Dec 13 21:23:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B380C76DC6 for ; Tue, 13 Dec 2016 21:23:34 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud6.xs4all.net (lb3-smtp-cloud6.xs4all.net [194.109.24.31]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 03021F84 for ; Tue, 13 Dec 2016 21:23:33 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud6.xs4all.net with ESMTP id KZNK1u00G4VixDu01ZNMhS; Tue, 13 Dec 2016 22:22:21 +0100 Reply-To: From: "John W. Kitz" To: Subject: When first hooking up a cubieboard2... Date: Tue, 13 Dec 2016 22:22:20 +0100 Message-ID: <005001d25586$fe1a22b0$fa4e6810$@Kitz@xs4all.nl> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJVhv0BwuffFY8QTsyff0TwlgYARA== Content-Language: en-us Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:23:34 -0000 Hi, When attaching a new cubieboard2 to a FreeBSD system for the first time I get: "ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x4000 umass0:4:0: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: Attempt to query device size failed: NOT READY, Medium not present da0: quirks=0x2 da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 da1: Removable Direct Access SCSI-2 device da1: 40.000MB/s transfers da1: Attempt to query device size failed: NOT READY, Medium not present da1: quirks=0x2 da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 da2: Removable Direct Access SCSI-2 device da2: 40.000MB/s transfers da2: Attempt to query device size failed: NOT READY, Medium not present da2: quirks=0x2" While looking at the hardware schematic, am I correct in assuming that da0 represents the SD card slot, and da1 and da2 represent USB port 1 and 2 respectively? Regards, Jk. From owner-freebsd-arm@freebsd.org Wed Dec 14 01:25:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D32DC75492 for ; Wed, 14 Dec 2016 01:25:52 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C6B7616B4 for ; Wed, 14 Dec 2016 01:25:51 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi0-x235.google.com with SMTP id w63so5381837oiw.0 for ; Tue, 13 Dec 2016 17:25:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UNIfTks3qWbsnfMmtX4RJjWhUW6HAhvGFar+Dumml+s=; b=Gx+Ahk10u5q26M1rLoB5zRRyrTvX86TxFgcOgVkDz5PZl0tIPkqL43G2QONHwS6DoD myf2Oip9mSCGAZG+VEzuD67ECnFxi8s1ORHKygs5W+V2iq5h8lMlDHHagBvaxwDF0xA3 TLfCiLdN4eTrsPMX41gIppjtqJZIsKts4VoPtyq9ZweS4VYZ5ZRYpKoBdQxB7XonPnC+ VPKNm9FYTwF/VDwMf5ZuP13kto8CHcnmPmN0QVtnBmeXEE/57vu2ukA76J1SlLtsd+Wb nkqntNaDDH4fmRHV9p8bg4BPEY8a6n0dEi2lwd9gSWksVCnEPLs/eNWW1MWng0u002YE +pfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UNIfTks3qWbsnfMmtX4RJjWhUW6HAhvGFar+Dumml+s=; b=sI9k2hyDIg8z4EBxJBby20q0/k+XSsyGRh0//s95TaRecKoJdsz6ON2PJj42UmuLmW +k+OvhrmuvF8RX8cu1n+dXlpkUulh7mZUnVQk1KZh3X8Gwv2modtZ1haLKny+CFTveC5 Bjlsb1wTU5Q1RaEa96fLMvhKkiB0oiHpL4E0KCHnqdSIsjsijIn4SefuCfETZwOJc3nN nE9ou/ESDx6MRf697geqd/DyzTG0QDcliuHHWhgnm/yeG12t9HtTaGvOYQ5q7gO9K4VV JFctCg/WvxqfrWViO0wLANuBhMwT6IXWGr5mu8h3Av6sDLJusd0X/olC0bKd8g6uhiTj 2MEQ== X-Gm-Message-State: AKaTC00V8/trC8IZrk/yklcgmv1yjRZ29Cmx0PxQuVls/eI2HHbOO2UWPrBmIBa5Ajp26nhoJ6mO026I6PsjFw== X-Received: by 10.202.252.133 with SMTP id a127mr51778880oii.124.1481678751095; Tue, 13 Dec 2016 17:25:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.145.33 with HTTP; Tue, 13 Dec 2016 17:25:50 -0800 (PST) In-Reply-To: <5ce7a4e6-25a0-73b4-0e6b-751814c62121@selasky.org> References: <5ce7a4e6-25a0-73b4-0e6b-751814c62121@selasky.org> From: Ganbold Tsagaankhuu Date: Wed, 14 Dec 2016 09:25:50 +0800 Message-ID: Subject: Re: dwc_otg problem To: Hans Petter Selasky Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 01:25:52 -0000 On Wed, Dec 14, 2016 at 3:06 AM, Hans Petter Selasky wrote: > On 12/13/16 10:01, Ganbold Tsagaankhuu wrote: > >> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) >> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >> USB_ERR_TIMEOUT >> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >> ignored) >> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >> USB_ERR_TIMEOUT >> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >> ignored) >> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >> USB_ERR_TIMEOUT >> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >> ignored) >> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >> USB_ERR_TIMEOUT >> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >> ignored) >> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >> USB_ERR_TIMEOUT >> ugen1.2: at usbus1 (disconnected) >> uhub_reattach_port: could not allocate new device >> ... >> > > Hi, > > This might look like a DWC OTG IRQ problem. Can you check "vmstat -i" ? I can't boot further than those messages. Ganbold > > > --HPS > From owner-freebsd-arm@freebsd.org Wed Dec 14 01:32:15 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7A3F6C75779 for ; Wed, 14 Dec 2016 01:32:15 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 400F21B5D for ; Wed, 14 Dec 2016 01:32:15 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-oi0-x234.google.com with SMTP id w63so5508740oiw.0 for ; Tue, 13 Dec 2016 17:32:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DHFBeHeP+0y2QgcgMo/QYcQswYAb1g9QdVXJhlCdUq0=; b=Q2uV7l+XXiMXWpQwwkc3U0WPny3CWyc5jIKyYn8dBOxm8LGhH6/qgVPja0n2b2KnYC aJqffnmDMBi+qA2d+qGlG59lGb3I/Zqa+YSrAdNwOu1LJyq8DWi7i+mm5LV5+5pbkGcr Tv9z2470mLePw5vNhNZMIB+JgBdiDDt8lxtE4yflK3UwnkGs/jHMbWfVezi/M53hlkN7 evlWw1RdMKhVvbXCwnb4YYRBDcPscMeQr8qVHh5CsATesWKLGgj7yNYaml0KVFGrm6Yn uwGrbqhUTGh8riXAwnsGlnWhMfWYxwELUMZMnfhX3MnIoGdgFyHBofb9XVtJAYiDJDNy kfvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DHFBeHeP+0y2QgcgMo/QYcQswYAb1g9QdVXJhlCdUq0=; b=JHlrhMmxH/ug2PdRDeb8BkVYtlEzKWzPlEUtHwf19W2Wql8Ije/GdLqnB/vG+J7Jno sx+cAo07oFTiuYVERTHxSz6Za7T8ae1yhl+r7tWac2fENy80gtXPSUL69MV6xvMuJDR+ dtj7e0JEDB9WcKdtt3NmYlTd1E70nuPq45GAup3Hob1ahzy+Suarp9xDZkZ3airKA9R5 8Pe0Xwba7Bk2BGRTckdC94u0RASz+7Vo/VUY6OuQioQ1YxGRFIW47WigehwGrf+w/8DD RLHf/uliJFjS6Bv/I7KcveIaNRXH83ppijzeGZ6khhDUY4ASp192dwoxYaCMq55+Xyof sYxA== X-Gm-Message-State: AKaTC03tKC+rX6vnadqmlYTickRVuLbc9gnvfl4mN1etZbnuYWWLZESnR6+8pQJkH+PnbuiqrjUM3L/8vVo/Wg== X-Received: by 10.157.63.165 with SMTP id r34mr55862402otc.90.1481679134604; Tue, 13 Dec 2016 17:32:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.145.33 with HTTP; Tue, 13 Dec 2016 17:32:14 -0800 (PST) In-Reply-To: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> From: Ganbold Tsagaankhuu Date: Wed, 14 Dec 2016 09:32:14 +0800 Message-ID: Subject: Re: When first hooking up a cubieboard2... To: John.Kitz@xs4all.nl Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 01:32:15 -0000 On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz wrote: > Hi, > > > > When attaching a new cubieboard2 to a FreeBSD system for the first time I > get: > > > > "ugen1.2: at usbus1 > > umass0: on usbus1 > > umass0: SCSI over Bulk-Only; quirks = 0x4000 > > umass0:4:0: Attached to scbus4 > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > da0: Removable Direct Access SCSI-2 device > > da0: 40.000MB/s transfers > > da0: Attempt to query device size failed: NOT READY, Medium not present > > da0: quirks=0x2 > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > > da1: Removable Direct Access SCSI-2 device > > da1: 40.000MB/s transfers > > da1: Attempt to query device size failed: NOT READY, Medium not present > > da1: quirks=0x2 > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > > da2: Removable Direct Access SCSI-2 device > > da2: 40.000MB/s transfers > > da2: Attempt to query device size failed: NOT READY, Medium not present > > da2: quirks=0x2" > > > > While looking at the hardware schematic, am I correct in assuming that da0 > represents the SD card slot, and da1 and da2 represent USB port 1 and 2 > respectively? > I don't remember the details, but there are 2 USB host ports exposed on the board, and 1 USB otg port. SD would be mmcsd0. Ganbold > > > > Regards, Jk. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://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 Dec 14 08:12:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B7818C77446 for ; Wed, 14 Dec 2016 08:12:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 786C519BB for ; Wed, 14 Dec 2016 08:12:31 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.129.119]) (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 BD6F31FE157; Wed, 14 Dec 2016 09:12:28 +0100 (CET) Subject: Re: dwc_otg problem To: Ganbold Tsagaankhuu References: <5ce7a4e6-25a0-73b4-0e6b-751814c62121@selasky.org> Cc: freebsd-arm From: Hans Petter Selasky Message-ID: <37250581-e9cc-dd57-0724-94769148046b@selasky.org> Date: Wed, 14 Dec 2016 09:12:01 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 08:12:31 -0000 On 12/14/16 02:25, Ganbold Tsagaankhuu wrote: > On Wed, Dec 14, 2016 at 3:06 AM, Hans Petter Selasky > wrote: > >> On 12/13/16 10:01, Ganbold Tsagaankhuu wrote: >> >>> usb_alloc_device: set address 2 failed (USB_ERR_TIMEOUT, ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> usbd_req_re_enumerate: addr=2, set address failed! (USB_ERR_TIMEOUT, >>> ignored) >>> usbd_setup_device_desc: getting device descriptor at addr 2 failed, >>> USB_ERR_TIMEOUT >>> ugen1.2: at usbus1 (disconnected) >>> uhub_reattach_port: could not allocate new device >>> ... >>> >> >> Hi, >> >> This might look like a DWC OTG IRQ problem. Can you check "vmstat -i" ? > > > I can't boot further than those messages. > > Ganbold Hi, You can possibly enable "hw.usb.dwc_otg.debug=16" from the loader. I suspect it is a problem with the FDT, that the IRQ is incorrectly mapped. --HPS From owner-freebsd-arm@freebsd.org Wed Dec 14 12:21:02 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7FF31C77F10 for ; Wed, 14 Dec 2016 12:21:02 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2820E1F87 for ; Wed, 14 Dec 2016 12:21:01 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id KoLq1u00B4VixDu01oLt5q; Wed, 14 Dec 2016 13:20:53 +0100 Reply-To: From: "John W. Kitz" To: "'Ganbold Tsagaankhuu'" Cc: References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Subject: RE: When first hooking up a cubieboard2... Date: Wed, 14 Dec 2016 13:20:54 +0100 Message-ID: <003501d25604$843a0ae0$8cae20a0$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJVqeZfEplYU54lTzaAdTubtGWkGQAWGITA Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 12:21:02 -0000 Ganbold, > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz = wrote: > Hi, > > When attaching a new cubieboard2 to a FreeBSD system for the first = time I > get: > > "ugen1.2: at usbus1 > umass0: on usbus1 > umass0: SCSI over Bulk-Only; quirks =3D 0x4000 > umass0:4:0: Attached to scbus4 > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > da0: Removable Direct Access SCSI-2 = device > da0: 40.000MB/s transfers > da0: Attempt to query device size failed: NOT READY, Medium not = present > da0: quirks=3D0x2 > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > da1: Removable Direct Access SCSI-2 = device > da1: 40.000MB/s transfers > da1: Attempt to query device size failed: NOT READY, Medium not = present > da1: quirks=3D0x2 > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > da2: Removable Direct Access SCSI-2 = device > da2: 40.000MB/s transfers > da2: Attempt to query device size failed: NOT READY, Medium not = present > da2: quirks=3D0x2" > > While looking at the hardware schematic, am I correct in assuming that = da0 > represents the SD card slot, and da1 and da2 represent USB port 1 and = 2 > respectively? > > I don't remember the details, but there are 2 USB host ports exposed = on the board, and 1 USB otg port. > SD would be mmcsd0. Well not the answer I was looking for, but this is what I got when = attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to a USB = port on an AMD64 / FreeBSD system. Since the messages all seem to refer = to removable storage devices attached to the same bus on which the = storage medium itself doesn't seem to be present, resulting in the = devices being reported as not ready, the only thing I could imagine were = the SD card slot (I believe using a converter it is possible to connect = that to a USB port as well) and the two other (i.e. non OTG) USB ports. Regards, Jk. From owner-freebsd-arm@freebsd.org Wed Dec 14 14:42:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F1E1C77C8F for ; Wed, 14 Dec 2016 14:42:22 +0000 (UTC) (envelope-from vivek@khera.org) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 291D21DAC for ; Wed, 14 Dec 2016 14:42:21 +0000 (UTC) (envelope-from vivek@khera.org) Received: by mail-qk0-x22d.google.com with SMTP id n204so22504701qke.2 for ; Wed, 14 Dec 2016 06:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khera.org; s=google11; h=mime-version:from:date:message-id:subject:to; bh=uPgKVYmwBpF7XTfxSRGoV9xespYZpNjDHjBSRQSqnQc=; b=UqWLHgP+B7+5LLxgQm8bDnhR7XdmsmtQbRhaPPREE5aXK4PeFCzMkE8DOPGiD/I389 PgLbD1ThFkd3b0AouZzwtaw0L4j893mlfQ2MC9nIbVDueh6EaDt9baa9sfj4JJxzy5AD nW5MAWklM/Nz1oTjxbAiwmp+vS+okrEbKbeOo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=uPgKVYmwBpF7XTfxSRGoV9xespYZpNjDHjBSRQSqnQc=; b=ZMU0ZVVwPLIckicoF9MjN9jFKOXpyk2OIvucX1/Nb8tZVTUzTlmvsId6GRTpPyAz4X zM9v7CeRJSvIOnIOzDUN7qmJTDDMomdiOUwX932/in3nH336RJSngFam898zPehvHEHz 54zMthE/iaXeB1PGmAZyYM1lY26XBun/BBHSzbRDl3v9hYJ/JTN06HpPCdisHXXb4m+p vlIiTI1nsAhAiowLtL+EJv5j5En0aaeuKBx0/n9L3M2LUuXV+FdfTBDlSw5bDTBjbgB1 mV6jGMQguXHmGNlMXF2+ivsBR3HPG5/9XU20NjwUhNzXUBbJZc7SYFBq3B35vB378YWN qd2g== X-Gm-Message-State: AKaTC02KpSNCV/r2CgpEEMJBSODG1L1QHM2SpQCs0sRURPsTR/sjV8qalh3y6SJ3iDILiH1nypEzP23wm2IDbg== X-Received: by 10.28.40.67 with SMTP id o64mr7506593wmo.40.1481726540527; Wed, 14 Dec 2016 06:42:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.157.205 with HTTP; Wed, 14 Dec 2016 06:42:19 -0800 (PST) From: Vick Khera Date: Wed, 14 Dec 2016 09:42:19 -0500 Message-ID: Subject: building m4 in poudriere cross-build To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 14:42:22 -0000 I have a poudriere cross-building configuration set up on a Xeon running FreebSD 11.0. The jail was set up with the "-x" option to use the native cross-build tools. This has worked really well for a while, but today I am trying to update the packages for my raspberry pi 2, and poudriere just kind of sits there in the configure step when building m4 (as a dependency trying to build subversion). I haven't built this set of packages in over a month. The logs show this: checking for dirent.h... (cached) yes checking for inttypes.h... (cached) yes checking for working C stack overflow detection... make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 make: Working in: /usr/ports/devel/m4 The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with Poudriere 3.1.14 The build jail target is 11.0-RELEASE-p5/armv6 freshly updated. I let this run for over 18 hours, and it just kept repeating that last line. Has anyone had success with this set up recently? Maybe the qemu-arm-static is not working right now? From owner-freebsd-arm@freebsd.org Wed Dec 14 15:01:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 71539C80223 for ; Wed, 14 Dec 2016 15:01:09 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 51A9AC35 for ; Wed, 14 Dec 2016 15:01:09 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [128.173.38.82] (unknown [128.173.38.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id A47AF1B8; Wed, 14 Dec 2016 10:01:02 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: building m4 in poudriere cross-build From: Paul Mather In-Reply-To: Date: Wed, 14 Dec 2016 10:01:01 -0500 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> References: To: Vick Khera X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 15:01:09 -0000 On Dec 14, 2016, at 9:42 AM, Vick Khera wrote: > I have a poudriere cross-building configuration set up on a Xeon = running > FreebSD 11.0. The jail was set up with the "-x" option to use the = native > cross-build tools. This has worked really well for a while, but today = I am > trying to update the packages for my raspberry pi 2, and poudriere = just > kind of sits there in the configure step when building m4 (as a = dependency > trying to build subversion). I haven't built this set of packages in = over a > month. >=20 > The logs show this: >=20 > checking for dirent.h... (cached) yes > checking for inttypes.h... (cached) yes > checking for working C stack overflow detection... make: Working in: > /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 > make: Working in: /usr/ports/devel/m4 >=20 > The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with Poudriere = 3.1.14 >=20 > The build jail target is 11.0-RELEASE-p5/armv6 freshly updated. >=20 > I let this run for over 18 hours, and it just kept repeating that last > line. Has anyone had success with this set up recently? Maybe the > qemu-arm-static is not working right now? I had (have) the same problem. Not only would packages like m4 just = grind away for hours on end doing nothing until Poudriere timed out the = build (after 24 hours), but other packages I use like math/gmp and = net/norm would fail to build with various errors. I use Saltstack and = so these kind of failures meant that sysutils/py-salt would be skipped = for building, meaning it fell behind that of the other architectures I = was running. In the end, I decided to simply set up Poudriere on my FreeBSD/arm = Raspberry Pi 2 system and build packages there instead. Running = natively, all these packages build correctly and once again I am able to = have up-to-date packages on my FreeBSD/arm systems. Package building = isn't as fast as on my cross-build FreeBSD/amd64 system, but at least = they actually build---slower is better than never. :-) I can only assume that the QEMU arm emulator is deficient compared to an = actual CPU on a running FreeBSD/arm system. If the official FreeBSD/arm = package repository is built via a cross-built environment using QEMU, I = presume these problems will linger until QEMU works properly. I also assume that maybe the FreeBSD/arm package builders are consider = these ports simply to be broken on FreeBSD/arm, which is why they fail = to build under QEMU, when in fact the packages do actually build on an = actual FreeBSD/arm system. At least that has been my experience for the = last few months. Cheers, Paul. From owner-freebsd-arm@freebsd.org Wed Dec 14 16:26:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54037C80349 for ; Wed, 14 Dec 2016 16:26:34 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ED70B11AE for ; Wed, 14 Dec 2016 16:26:33 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id KsSV1u00R4VixDu01sSWDH; Wed, 14 Dec 2016 17:26:31 +0100 Reply-To: From: "John W. Kitz" To: "'Ganbold Tsagaankhuu'" Cc: References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Subject: RE: When first hooking up a cubieboard2... Date: Wed, 14 Dec 2016 17:26:30 +0100 Message-ID: <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJVqeZfEplYU54lTzaAdTubtGWkGQAWGITAAAj1v6A= Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 16:26:34 -0000 Ganbold, >> On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz = wrote: >> Hi, >> >> When attaching a new cubieboard2 to a FreeBSD system for the first=20 >> time I >> get: >> >> "ugen1.2: at usbus1 >> umass0: on usbus1 >> umass0: SCSI over Bulk-Only; quirks =3D 0x4000 >> umass0:4:0: Attached to scbus4 >> >> da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 >> da0: Removable Direct Access SCSI-2=20 >> device >> da0: 40.000MB/s transfers >> da0: Attempt to query device size failed: NOT READY, Medium not=20 >> present >> da0: quirks=3D0x2 >> >> da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 >> da1: Removable Direct Access SCSI-2=20 >> device >> da1: 40.000MB/s transfers >> da1: Attempt to query device size failed: NOT READY, Medium not=20 >> present >> da1: quirks=3D0x2 >> >> da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 >> da2: Removable Direct Access SCSI-2=20 >> device >> da2: 40.000MB/s transfers >> da2: Attempt to query device size failed: NOT READY, Medium not=20 >> present >> da2: quirks=3D0x2" >> >> While looking at the hardware schematic, am I correct in assuming = that=20 >> da0 represents the SD card slot, and da1 and da2 represent USB port 1 = >> and 2 respectively? >> >> I don't remember the details, but there are 2 USB host ports exposed = on the board, and 1 USB otg port. >> SD would be mmcsd0. Well not the answer I was looking for, but this is what I got when = attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to a USB = port on >an AMD64 / FreeBSD system. Since the messages all seem to refer = to removable storage devices attached to the same bus on which the = storage medium itself doesn't seem to be present, resulting in the = devices being reported as not ready, the only thing I could imagine were = the SD card slot (I believe using a converter it is possible to connect = that to a USB port as well) and the two other (i.e. non OTG) USB ports. Looking into this a bit further is the difference maybe the result of a = different way of enumerating devices on Linux then on FreeBSD? If not, what conclusion should I draw from this? Regards, Jk. From owner-freebsd-arm@freebsd.org Wed Dec 14 18:22:45 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 27888C7660A for ; Wed, 14 Dec 2016 18:22:45 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 0BFAE2AD for ; Wed, 14 Dec 2016 18:22:44 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 43914b29-c22a-11e6-9ec7-5d8fa496b077 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 43914b29-c22a-11e6-9ec7-5d8fa496b077; Wed, 14 Dec 2016 18:22:26 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBEIMZZI004202; Wed, 14 Dec 2016 11:22:35 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481739755.1889.376.camel@freebsd.org> Subject: Re: When first hooking up a cubieboard2... From: Ian Lepore To: John.Kitz@xs4all.nl, "'Ganbold Tsagaankhuu'" Cc: freebsd-arm@freebsd.org Date: Wed, 14 Dec 2016 11:22:35 -0700 In-Reply-To: <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 18:22:45 -0000 On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: > Ganbold, > > > > > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz > > l> wrote: > > > Hi, > > > > > > When attaching a new cubieboard2 to a FreeBSD system for the > > > first  > > > time I > > > get: > > > > > > "ugen1.2: at usbus1 > > > umass0: on usbus1 > > > umass0:  SCSI over Bulk-Only; quirks = 0x4000 > > > umass0:4:0: Attached to scbus4 > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > > da0: Removable Direct Access > > > SCSI-2  > > > device > > > da0: 40.000MB/s transfers > > > da0: Attempt to query device size failed: NOT READY, Medium not  > > > present > > > da0: quirks=0x2 > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > > > da1: Removable Direct Access > > > SCSI-2  > > > device > > > da1: 40.000MB/s transfers > > > da1: Attempt to query device size failed: NOT READY, Medium not  > > > present > > > da1: quirks=0x2 > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > > > da2: Removable Direct Access > > > SCSI-2  > > > device > > > da2: 40.000MB/s transfers > > > da2: Attempt to query device size failed: NOT READY, Medium not  > > > present > > > da2: quirks=0x2" > > > > > > While looking at the hardware schematic, am I correct in assuming > > > that  > > > da0 represents the SD card slot, and da1 and da2 represent USB > > > port 1  > > > and 2 respectively? > > > > > > I don't remember the details, but there are 2 USB host ports > > > exposed on the board, and 1 USB otg port. > > > SD would be mmcsd0. > Well not the answer I was looking for, but this is what I got when > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to a > USB port on >an AMD64 / FreeBSD system. Since the messages all seem > to refer to removable storage devices attached to the same bus on > which the storage medium itself doesn't seem to be present, resulting > in the devices being reported as not ready, the only thing I could > imagine were the SD card slot (I believe using a converter it is > possible to connect that to a USB port as well) and the two other > (i.e. non OTG) USB ports. > > Looking into this a bit further is the difference maybe the result of > a different way of enumerating devices on Linux then on FreeBSD? > > If not, what conclusion should I draw from this? > > Regards, Jk. Your question actually doesn't make much sense.  I think the best answer possible about what you see when you connect a running cubieboard2 to a freebsd host is something like... What you see is entirely dependent on what software is running on the cubieboard when you connect it, and questions about what shows up and why should be addressed to whomever wrote that software. If freebsd is what's running on the board, then this is the right place to ask, but you'd have to provide more info about exactly what you're running (where you got the image or how you built it).  If you're running some linux image then the builder/distributor of that image could answer the questions. -- Ian From owner-freebsd-arm@freebsd.org Wed Dec 14 19:34:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83171C8022A for ; Wed, 14 Dec 2016 19:34:18 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2A5D71A24 for ; Wed, 14 Dec 2016 19:34:17 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id KvaD1u00A4VixDu01vaEL3; Wed, 14 Dec 2016 20:34:14 +0100 Reply-To: From: "John W. Kitz" To: "'Ian Lepore'" , "'Ganbold Tsagaankhuu'" Cc: References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> <1481739755.1889.376.camel@freebsd.org> In-Reply-To: <1481739755.1889.376.camel@freebsd.org> Subject: RE: When first hooking up a cubieboard2... Date: Wed, 14 Dec 2016 20:34:08 +0100 Message-ID: <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJWNw5IsaSzj2c6QQ2hKW/X+Zy0iwACQnAw Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 19:34:18 -0000 Gents, On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: >> Ganbold, >>=20 >> >=20 >> > >=20 >> > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz > > > l> wrote: >> > > Hi, >> > >=20 >> > > When attaching a new cubieboard2 to a FreeBSD system for the = first=20 >> > > time I >> > > get: >> > >=20 >> > > "ugen1.2: at usbus1 >> > > umass0: on usbus1 >> > > umass0:=A0=A0SCSI over Bulk-Only; quirks =3D 0x4000 >> > > umass0:4:0: Attached to scbus4 >> > >=20 >> > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 >> > > da0: Removable Direct Access >> > > SCSI-2 >> > > device >> > > da0: 40.000MB/s transfers >> > > da0: Attempt to query device size failed: NOT READY, Medium not=20 >> > > present >> > > da0: quirks=3D0x2 >> > >=20 >> > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 >> > > da1: Removable Direct Access >> > > SCSI-2 >> > > device >> > > da1: 40.000MB/s transfers >> > > da1: Attempt to query device size failed: NOT READY, Medium not=20 >> > > present >> > > da1: quirks=3D0x2 >> > >=20 >> > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 >> > > da2: Removable Direct Access >> > > SCSI-2 >> > > device >> > > da2: 40.000MB/s transfers >> > > da2: Attempt to query device size failed: NOT READY, Medium not=20 >> > > present >> > > da2: quirks=3D0x2" >> > >=20 >> > > While looking at the hardware schematic, am I correct in assuming = >> > > that >> > > da0 represents the SD card slot, and da1 and da2 represent USB=20 >> > > port 1 and 2 respectively? >> > >=20 >> > > I don't remember the details, but there are 2 USB host ports=20 >> > > exposed on the board, and 1 USB otg port. >> > > SD would be mmcsd0. >> Well not the answer I was looking for, but this is what I got when=20 >> attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to a = USB=20 >> port on >an AMD64 / FreeBSD system. Since the messages all seem to=20 >> refer to removable storage devices attached to the same bus on which=20 >> the storage medium itself doesn't seem to be present, resulting in = the=20 >> devices being reported as not ready, the only thing I could imagine=20 >> were the SD card slot (I believe using a converter it is possible to=20 >> connect that to a USB port as well) and the two other (i.e. non OTG)=20 >> USB ports. >>=20 >> Looking into this a bit further is the difference maybe the result of = >> a different way of enumerating devices on Linux then on FreeBSD? >>=20 >> If not, what conclusion should I draw from this? >>=20 > Your question actually doesn't make much sense. =A0I think the best = answer possible about what you see when you connect a running > cubieboard2 to a freebsd host is something like... > What you see is entirely dependent on what software is running on the cubieboard when you connect it, and questions about what shows up and = why > should be addressed to whomever wrote that software. I'm not referring to what I see on the cubieboard2, but as I mentioned = to what I'm seeing on the console of an AMD64 / FreeBSD system to which I'm attaching it.=20 > If freebsd is what's running on the board, then this is the right = place to ask, but you'd have to provide more info about exactly what you're > = running (where you got the image or how you built it). =A0If you're running some = linux image then the builder/distributor of that image could answer >the questions. The board is straight out of the box brand spanking new, so AFAIK = there's nothing running on it yet. Jk. From owner-freebsd-arm@freebsd.org Wed Dec 14 21:10:07 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C699C77CD4 for ; Wed, 14 Dec 2016 21:10:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 0E9BB9CD for ; Wed, 14 Dec 2016 21:10:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a8b44d6f-c241-11e6-9ec7-5d8fa496b077 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id a8b44d6f-c241-11e6-9ec7-5d8fa496b077; Wed, 14 Dec 2016 21:09:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBELA4eC004472; Wed, 14 Dec 2016 14:10:04 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481749803.1889.406.camel@freebsd.org> Subject: Re: When first hooking up a cubieboard2... From: Ian Lepore To: John.Kitz@xs4all.nl, "'Ganbold Tsagaankhuu'" Cc: freebsd-arm@freebsd.org Date: Wed, 14 Dec 2016 14:10:03 -0700 In-Reply-To: <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> <1481739755.1889.376.camel@freebsd.org> <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:10:07 -0000 On Wed, 2016-12-14 at 20:34 +0100, John W. Kitz wrote: > Gents, > > On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: > > > > > > > > Ganbold, > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz > > > > ll.n > > > > > l> wrote: > > > > > Hi, > > > > > > > > > > When attaching a new cubieboard2 to a FreeBSD system for the > > > > > first  > > > > > time I > > > > > get: > > > > > > > > > > "ugen1.2: at usbus1 > > > > > umass0: on usbus1 > > > > > umass0:  SCSI over Bulk-Only; quirks = 0x4000 > > > > > umass0:4:0: Attached to scbus4 > > > > > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > > > > da0: Removable Direct Access > > > > > SCSI-2 > > > > > device > > > > > da0: 40.000MB/s transfers > > > > > da0: Attempt to query device size failed: NOT READY, Medium > > > > > not  > > > > > present > > > > > da0: quirks=0x2 > > > > > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > > > > > da1: Removable Direct Access > > > > > SCSI-2 > > > > > device > > > > > da1: 40.000MB/s transfers > > > > > da1: Attempt to query device size failed: NOT READY, Medium > > > > > not  > > > > > present > > > > > da1: quirks=0x2 > > > > > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > > > > > da2: Removable Direct Access > > > > > SCSI-2 > > > > > device > > > > > da2: 40.000MB/s transfers > > > > > da2: Attempt to query device size failed: NOT READY, Medium > > > > > not  > > > > > present > > > > > da2: quirks=0x2" > > > > > > > > > > While looking at the hardware schematic, am I correct in > > > > > assuming  > > > > > that > > > > > da0 represents the SD card slot, and da1 and da2 represent > > > > > USB  > > > > > port 1 and 2 respectively? > > > > > > > > > > I don't remember the details, but there are 2 USB host ports  > > > > > exposed on the board, and 1 USB otg port. > > > > > SD would be mmcsd0. > > > Well not the answer I was looking for, but this is what I got > > > when  > > > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to > > > a USB  > > > port on >an AMD64 / FreeBSD system. Since the messages all seem > > > to  > > > refer to removable storage devices attached to the same bus on > > > which  > > > the storage medium itself doesn't seem to be present, resulting > > > in the  > > > devices being reported as not ready, the only thing I could > > > imagine  > > > were the SD card slot (I believe using a converter it is possible > > > to  > > > connect that to a USB port as well) and the two other (i.e. non > > > OTG)  > > > USB ports. > > > > > > Looking into this a bit further is the difference maybe the > > > result of  > > > a different way of enumerating devices on Linux then on FreeBSD? > > > > > > If not, what conclusion should I draw from this? > > > > > > > Your question actually doesn't make much sense.  I think the best > > answer > possible about what you see when you connect a running > > > > cubieboard2 to a freebsd host is something like... > > > > What you see is entirely dependent on what software is running on > > the > cubieboard when you connect it, and questions about what shows up and > why > > should be addressed to whomever wrote that software. > > I'm not referring to what I see on the cubieboard2, but as I > mentioned to > what I'm seeing on the console of an AMD64 / FreeBSD system to which > I'm > attaching it.  > > > > > If freebsd is what's running on the board, then this is the right > > place to > ask, but you'd have to provide more info about exactly what you're > > running > (where you got the image or how you built it).  If you're running > some linux > image then the builder/distributor of that image could answer >the > questions. > > The board is straight out of the box brand spanking new, so AFAIK > there's > nothing running on it yet. > > Jk. What you are seeing on the freebsd console is the devices that the software running on the cubieboard provides.  Even fresh out of the box, it is running something (presumably some linux or android distro that gets put into the nand flash at the factory). This has nothing to do with freebsd.  You'd see the same thing if you plugged it into a windows system. -- Ian From owner-freebsd-arm@freebsd.org Wed Dec 14 21:39:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD953C80B02 for ; Wed, 14 Dec 2016 21:39:48 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 06DCE1866; Wed, 14 Dec 2016 21:39:47 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 48aa9594; Wed, 14 Dec 2016 22:39:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=uqthuCmErbWG4bejCe3nKCTTuy8=; b=Usf3jtBvbTVjPGwMDsZXzV1lUw5w XuFn1zXvZdrazjvt6IswOliqsPGc5+JbUI3ZpnN42hSJxeygHgFY6xbydgbF043/ Yhmk+F3ZZCGOm87UZpwavQUTSXPAJkd1MEiqdxUkhazQUUGvQL9iLDSe7pcXJJ/o 1DVz8rFGsX3xX40= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=Cq+rRA1auxKZmD+UIUY+l3FVY6C1YRAzHVaccyROYmrAeuWXB9dp24Jg v3DWUhHs3Qy2TRNSTLDqCR377H7Bwc5QMN9kV4aDUMztD9XcOg38DZzN/Cn7sSrg +eE3T9/140EK4zHdKf67kjYLtMt4RylUVkzYGzBZTb1KDvzIGY4= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 54cb014a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 14 Dec 2016 22:39:39 +0100 (CET) Date: Wed, 14 Dec 2016 22:39:38 +0100 From: Emmanuel Vadot To: Ian Lepore Cc: John.Kitz@xs4all.nl, "'Ganbold Tsagaankhuu'" , freebsd-arm@freebsd.org Subject: Re: When first hooking up a cubieboard2... Message-Id: <20161214223938.92d9af8934b018ccd2f01148@bidouilliste.com> In-Reply-To: <1481749803.1889.406.camel@freebsd.org> References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> <1481739755.1889.376.camel@freebsd.org> <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> <1481749803.1889.406.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:39:48 -0000 On Wed, 14 Dec 2016 14:10:03 -0700 Ian Lepore wrote: > On Wed, 2016-12-14 at 20:34 +0100, John W. Kitz wrote: > > Gents, > >=20 > > On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: > > >=20 > > > >=20 > > > > Ganbold, > > > >=20 > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz > > > > > ll.n > > > > > > l> wrote: > > > > > > Hi, > > > > > >=20 > > > > > > When attaching a new cubieboard2 to a FreeBSD system for the > > > > > > first=A0 > > > > > > time I > > > > > > get: > > > > > >=20 > > > > > > "ugen1.2: at usbus1 > > > > > > umass0: on usbus1 > > > > > > umass0:=A0=A0SCSI over Bulk-Only; quirks =3D 0x4000 > > > > > > umass0:4:0: Attached to scbus4 > > > > > >=20 > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > > > > > da0: Removable Direct Access > > > > > > SCSI-2 > > > > > > device > > > > > > da0: 40.000MB/s transfers > > > > > > da0: Attempt to query device size failed: NOT READY, Medium > > > > > > not=A0 > > > > > > present > > > > > > da0: quirks=3D0x2 > > > > > >=20 > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > > > > > > da1: Removable Direct Access > > > > > > SCSI-2 > > > > > > device > > > > > > da1: 40.000MB/s transfers > > > > > > da1: Attempt to query device size failed: NOT READY, Medium > > > > > > not=A0 > > > > > > present > > > > > > da1: quirks=3D0x2 > > > > > >=20 > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > > > > > > da2: Removable Direct Access > > > > > > SCSI-2 > > > > > > device > > > > > > da2: 40.000MB/s transfers > > > > > > da2: Attempt to query device size failed: NOT READY, Medium > > > > > > not=A0 > > > > > > present > > > > > > da2: quirks=3D0x2" > > > > > >=20 > > > > > > While looking at the hardware schematic, am I correct in > > > > > > assuming=A0 > > > > > > that > > > > > > da0 represents the SD card slot, and da1 and da2 represent > > > > > > USB=A0 > > > > > > port 1 and 2 respectively? > > > > > >=20 > > > > > > I don't remember the details, but there are 2 USB host ports=A0 > > > > > > exposed on the board, and 1 USB otg port. > > > > > > SD would be mmcsd0. > > > > Well not the answer I was looking for, but this is what I got > > > > when=A0 > > > > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to > > > > a USB=A0 > > > > port on >an AMD64 / FreeBSD system. Since the messages all seem > > > > to=A0 > > > > refer to removable storage devices attached to the same bus on > > > > which=A0 > > > > the storage medium itself doesn't seem to be present, resulting > > > > in the=A0 > > > > devices being reported as not ready, the only thing I could > > > > imagine=A0 > > > > were the SD card slot (I believe using a converter it is possible > > > > to=A0 > > > > connect that to a USB port as well) and the two other (i.e. non > > > > OTG)=A0 > > > > USB ports. > > > >=20 > > > > Looking into this a bit further is the difference maybe the > > > > result of=A0 > > > > a different way of enumerating devices on Linux then on FreeBSD? > > > >=20 > > > > If not, what conclusion should I draw from this? > > > >=20 > > >=20 > > > Your question actually doesn't make much sense. =A0I think the best > > > answer > > possible about what you see when you connect a running > > >=20 > > > cubieboard2 to a freebsd host is something like... > > >=20 > > > What you see is entirely dependent on what software is running on > > > the > > cubieboard when you connect it, and questions about what shows up and > > why > > > should be addressed to whomever wrote that software. > >=20 > > I'm not referring to what I see on the cubieboard2, but as I > > mentioned to > > what I'm seeing on the console of an AMD64 / FreeBSD system to which > > I'm > > attaching it.=A0 > >=20 > > >=20 > > > If freebsd is what's running on the board, then this is the right > > > place to > > ask, but you'd have to provide more info about exactly what you're > > > running > > (where you got the image or how you built it). =A0If you're running > > some linux > > image then the builder/distributor of that image could answer >the > > questions. > >=20 > > The board is straight out of the box brand spanking new, so AFAIK > > there's > > nothing running on it yet. > >=20 > > Jk. >=20 > What you are seeing on the freebsd console is the devices that the > software running on the cubieboard provides. =A0Even fresh out of the > box, it is running something (presumably some linux or android distro > that gets put into the nand flash at the factory). >=20 > This has nothing to do with freebsd.=A0=A0You'd see the same thing if you > plugged it into a windows system. >=20 > -- Ian >=20 It can even be uboot, iirc it has gadget mode support. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Dec 14 21:51:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F862C80E38 for ; Wed, 14 Dec 2016 21:51:33 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id C7D781F7F for ; Wed, 14 Dec 2016 21:51:32 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud6.xs4all.net with ESMTP id KxqJ1u0024VixDu01xqKYp; Wed, 14 Dec 2016 22:50:19 +0100 Reply-To: From: "John W. Kitz" To: "'Ian Lepore'" , "'Ganbold Tsagaankhuu'" Cc: References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> <1481739755.1889.376.camel@freebsd.org> <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> <1481749803.1889.406.camel@freebsd.org> In-Reply-To: <1481749803.1889.406.camel@freebsd.org> Subject: RE: When first hooking up a cubieboard2... Date: Wed, 14 Dec 2016 22:50:19 +0100 Message-ID: <001701d25654$111d4c20$3357e460$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJWTnP0WAyc2fCiQHuqp0XF+hZ5QwABBgGw Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:51:33 -0000 Ian, > On Wed, 2016-12-14 at 20:34 +0100, John W. Kitz wrote: > > Gents, > >=20 > > On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: > > >=20 > > > >=20 > > > > Ganbold, > > > >=20 > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz = > > > > > ll.n > > > > > > l> wrote: > > > > > > Hi, > > > > > >=20 > > > > > > When attaching a new cubieboard2 to a FreeBSD system for the = > > > > > > first time I > > > > > > get: > > > > > >=20 > > > > > > "ugen1.2: at usbus1 > > > > > > umass0: on usbus1 > > > > > > umass0:=A0=A0SCSI over Bulk-Only; quirks =3D 0x4000 > > > > > > umass0:4:0: Attached to scbus4 > > > > > >=20 > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > > > > > da0: Removable Direct Access > > > > > > SCSI-2 > > > > > > device > > > > > > da0: 40.000MB/s transfers > > > > > > da0: Attempt to query device size failed: NOT READY, Medium=20 > > > > > > not present > > > > > > da0: quirks=3D0x2 > > > > > >=20 > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > > > > > > da1: Removable Direct Access > > > > > > SCSI-2 > > > > > > device > > > > > > da1: 40.000MB/s transfers > > > > > > da1: Attempt to query device size failed: NOT READY, Medium=20 > > > > > > not present > > > > > > da1: quirks=3D0x2 > > > > > >=20 > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > > > > > > da2: Removable Direct Access > > > > > > SCSI-2 > > > > > > device > > > > > > da2: 40.000MB/s transfers > > > > > > da2: Attempt to query device size failed: NOT READY, Medium=20 > > > > > > not present > > > > > > da2: quirks=3D0x2" > > > > > >=20 > > > > > > While looking at the hardware schematic, am I correct in=20 > > > > > > assuming that > > > > > > da0 represents the SD card slot, and da1 and da2 represent = USB=20 > > > > > > port 1 and 2 respectively? > > > > > >=20 > > > > > > I don't remember the details, but there are 2 USB host ports = > > > > > > exposed on the board, and 1 USB otg port. > > > > > > SD would be mmcsd0. > > > > Well not the answer I was looking for, but this is what I got = when=20 > > > > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to = a=20 > > > > USB port on >an AMD64 / FreeBSD system. Since the messages all=20 > > > > seem to refer to removable storage devices attached to the same=20 > > > > bus on which the storage medium itself doesn't seem to be = present,=20 > > > > resulting in the devices being reported as not ready, the only=20 > > > > thing I could imagine were the SD card slot (I believe using a=20 > > > > converter it is possible to connect that to a USB port as well)=20 > > > > and the two other (i.e. non > > > > OTG) > > > > USB ports. > > > >=20 > > > > Looking into this a bit further is the difference maybe the = result=20 > > > > of a different way of enumerating devices on Linux then on=20 > > > > FreeBSD? > > > >=20 > > > > If not, what conclusion should I draw from this? > > > >=20 > > >=20 > > > Your question actually doesn't make much sense. =A0I think the = best=20 > > > answer > > > possible about what you see when you connect a running > > >=20 > > > cubieboard2 to a freebsd host is something like... > > >=20 > > > What you see is entirely dependent on what software is running on=20 > > > the > > cubieboard when you connect it, and questions about what shows up = and=20 > > why > should be addressed to whomever wrote that software. > >=20 > > I'm not referring to what I see on the cubieboard2, but as I = mentioned=20 > > to what I'm seeing on the console of an AMD64 / FreeBSD system to=20 > > which I'm attaching it. > >=20 > >=20 > > If freebsd is what's running on the board, then this is the right=20 > > place to > > ask, but you'd have to provide more info about exactly what you're > = > > running (where you got the image or how you built it). =A0If you're=20 > > running some linux image then the builder/distributor of that image=20 > > could answer >the questions. > >=20 > > The board is straight out of the box brand spanking new, so AFAIK=20 > > there's nothing running on it yet. > >=20 > > Jk. > What you are seeing on the freebsd console is the devices that the software running on the cubieboard provides. =A0Even fresh out of the = box, it is > running something (presumably some linux or android distro that = gets put into the nand flash at the factory). > This has nothing to do with freebsd.=A0=A0You'd see the same thing if = you plugged it into a windows system. Thanks for pointing that out; I was already aware of that, but my = question was: which storage devices on the board do da0, da1 and da2 represent = 'as seen', if you will, from and on the FreeBSD system to which it is = attached? Regards, Jk. From owner-freebsd-arm@freebsd.org Wed Dec 14 21:55:28 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DA10C8001D for ; Wed, 14 Dec 2016 21:55:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 809543DB for ; Wed, 14 Dec 2016 21:55:28 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0d457e54-c248-11e6-9f67-d3961ed5a660 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 0d457e54-c248-11e6-9f67-d3961ed5a660; Wed, 14 Dec 2016 21:55:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBELtOl8004562; Wed, 14 Dec 2016 14:55:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481752524.1889.422.camel@freebsd.org> Subject: Re: When first hooking up a cubieboard2... From: Ian Lepore To: John.Kitz@xs4all.nl, "'Ganbold Tsagaankhuu'" Cc: freebsd-arm@freebsd.org Date: Wed, 14 Dec 2016 14:55:24 -0700 In-Reply-To: <001701d25654$111d4c20$3357e460$@Kitz@xs4all.nl> References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> <1481739755.1889.376.camel@freebsd.org> <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> <1481749803.1889.406.camel@freebsd.org> <001701d25654$111d4c20$3357e460$@Kitz@xs4all.nl> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:55:28 -0000 On Wed, 2016-12-14 at 22:50 +0100, John W. Kitz wrote: > Ian, > > > > > On Wed, 2016-12-14 at 20:34 +0100, John W. Kitz wrote: > > > > > > Gents, > > > > > > On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: > > > > > > > > > > > > > > > > > > > > > > > Ganbold, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz > > > > > > xs4a  > > > > > > > ll.n > > > > > > > l> wrote: > > > > > > > Hi, > > > > > > > > > > > > > > When attaching a new cubieboard2 to a FreeBSD system for > > > > > > > the  > > > > > > > first time I > > > > > > > get: > > > > > > > > > > > > > > "ugen1.2: at usbus1 > > > > > > > umass0: on usbus1 > > > > > > > umass0:  SCSI over Bulk-Only; quirks = 0x4000 > > > > > > > umass0:4:0: Attached to scbus4 > > > > > > > > > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > > > > > > da0: Removable Direct > > > > > > > Access > > > > > > > SCSI-2 > > > > > > > device > > > > > > > da0: 40.000MB/s transfers > > > > > > > da0: Attempt to query device size failed: NOT READY, > > > > > > > Medium  > > > > > > > not present > > > > > > > da0: quirks=0x2 > > > > > > > > > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > > > > > > > da1: Removable Direct > > > > > > > Access > > > > > > > SCSI-2 > > > > > > > device > > > > > > > da1: 40.000MB/s transfers > > > > > > > da1: Attempt to query device size failed: NOT READY, > > > > > > > Medium  > > > > > > > not present > > > > > > > da1: quirks=0x2 > > > > > > > > > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > > > > > > > da2: Removable Direct > > > > > > > Access > > > > > > > SCSI-2 > > > > > > > device > > > > > > > da2: 40.000MB/s transfers > > > > > > > da2: Attempt to query device size failed: NOT READY, > > > > > > > Medium  > > > > > > > not present > > > > > > > da2: quirks=0x2" > > > > > > > > > > > > > > While looking at the hardware schematic, am I correct in  > > > > > > > assuming that > > > > > > > da0 represents the SD card slot, and da1 and da2 > > > > > > > represent USB  > > > > > > > port 1 and 2 respectively? > > > > > > > > > > > > > > I don't remember the details, but there are 2 USB host > > > > > > > ports  > > > > > > > exposed on the board, and 1 USB otg port. > > > > > > > SD would be mmcsd0. > > > > > Well not the answer I was looking for, but this is what I got > > > > > when  > > > > > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) > > > > > to a  > > > > > USB port on >an AMD64 / FreeBSD system. Since the messages > > > > > all  > > > > > seem to refer to removable storage devices attached to the > > > > > same  > > > > > bus on which the storage medium itself doesn't seem to be > > > > > present,  > > > > > resulting in the devices being reported as not ready, the > > > > > only  > > > > > thing I could imagine were the SD card slot (I believe using > > > > > a  > > > > > converter it is possible to connect that to a USB port as > > > > > well)  > > > > > and the two other (i.e. non > > > > > OTG) > > > > > USB ports. > > > > > > > > > > Looking into this a bit further is the difference maybe the > > > > > result  > > > > > of a different way of enumerating devices on Linux then on  > > > > > FreeBSD? > > > > > > > > > > If not, what conclusion should I draw from this? > > > > > > > > > Your question actually doesn't make much sense.  I think the > > > > best  > > > > answer > > > > possible about what you see when you connect a running > > > > > > > > cubieboard2 to a freebsd host is something like... > > > > > > > > What you see is entirely dependent on what software is running > > > > on  > > > > the > > > cubieboard when you connect it, and questions about what shows up > > > and  > > > why > should be addressed to whomever wrote that software. > > > > > > I'm not referring to what I see on the cubieboard2, but as I > > > mentioned  > > > to what I'm seeing on the console of an AMD64 / FreeBSD system > > > to  > > > which I'm attaching it. > > > > > > > > > If freebsd is what's running on the board, then this is the > > > right  > > > place to > > > ask, but you'd have to provide more info about exactly what > > > you're >  > > > running (where you got the image or how you built it).  If > > > you're  > > > running some linux image then the builder/distributor of that > > > image  > > > could answer >the questions. > > > > > > The board is straight out of the box brand spanking new, so > > > AFAIK  > > > there's nothing running on it yet. > > > > > > Jk. > > > > What you are seeing on the freebsd console is the devices that the > software running on the cubieboard provides.  Even fresh out of the > box, it > is > running something (presumably some linux or android distro that > gets > put into the nand flash at the factory). > > > > > This has nothing to do with freebsd.  You'd see the same thing if > > you > plugged it into a windows system. > > Thanks for pointing that out; I was already aware of that, but my > question > was: which storage devices on the board do da0, da1 and da2 represent > 'as > seen', if you will, from and on the FreeBSD system to which it is > attached? > > Regards, Jk. > > And my point (which if you haven't gotten it by now I'm not sure there's any value in my repeating it again, but here goes...) is that this is not a freebsd question and I don't understand why you think anyone on a freebsd mailing list would be able to answer. -- Ian From owner-freebsd-arm@freebsd.org Wed Dec 14 21:56:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3B907C80084 for ; Wed, 14 Dec 2016 21:56:37 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 85DBD669; Wed, 14 Dec 2016 21:56:36 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 492a2637; Wed, 14 Dec 2016 22:56:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=JJx9j/IJ1TTDwbNZ3gaZFN42zPI=; b=VjBXLWZ94/z37oENPxEfFsJvPGIX lCds31NUdTLwkLcatiRlRjY4Fa4p9pEHRzm4hfdViAreVNmMvGUUMKtLk5anNUgg skiNSo2r9CILv1ckpzh/zW0GK/YhioKiaw8lTyrodHR6m/ekoFlk3yTp7gesRcb2 clnXQQq8tE7scZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=QXog84mr7nltB32TdBFMRumh7lWyFk+qNOPG3IkcFr0cp//ugfaeURvu J+XwFU91M2pXCxVputTTCf/QM7OWghRQDb6Enf5gKhH255hMFTbX4xdjAg5jkxZ4 U6NnoF3kX79veMw0sX0wq/E20S1jc6M2rVezTZRC3adO/qZCrMY= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 7cdd0bec TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 14 Dec 2016 22:56:33 +0100 (CET) Date: Wed, 14 Dec 2016 22:56:33 +0100 From: Emmanuel Vadot To: John.Kitz@xs4all.nl Cc: "'Ian Lepore'" , "'Ganbold Tsagaankhuu'" , freebsd-arm@freebsd.org Subject: Re: When first hooking up a cubieboard2... Message-Id: <20161214225633.160d9d06ddb0ae4a380ccf82@bidouilliste.com> In-Reply-To: <001701d25654$111d4c20$3357e460$@Kitz@xs4all.nl> References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> <1481739755.1889.376.camel@freebsd.org> <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> <1481749803.1889.406.camel@freebsd.org> <001701d25654$111d4c20$3357e460$@Kitz@xs4all.nl> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:56:37 -0000 On Wed, 14 Dec 2016 22:50:19 +0100 "John W. Kitz" wrote: > Ian, >=20 > > On Wed, 2016-12-14 at 20:34 +0100, John W. Kitz wrote: > > > Gents, > > >=20 > > > On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: > > > >=20 > > > > >=20 > > > > > Ganbold, > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > >=20 > > > > > > >=20 > > > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz > > > > > > ll.n > > > > > > > l> wrote: > > > > > > > Hi, > > > > > > >=20 > > > > > > > When attaching a new cubieboard2 to a FreeBSD system for the= =20 > > > > > > > first time I > > > > > > > get: > > > > > > >=20 > > > > > > > "ugen1.2: at usbus1 > > > > > > > umass0: on usbus1 > > > > > > > umass0:=A0=A0SCSI over Bulk-Only; quirks =3D 0x4000 > > > > > > > umass0:4:0: Attached to scbus4 > > > > > > >=20 > > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > > > > > > > da0: Removable Direct Access > > > > > > > SCSI-2 > > > > > > > device > > > > > > > da0: 40.000MB/s transfers > > > > > > > da0: Attempt to query device size failed: NOT READY, Medium=20 > > > > > > > not present > > > > > > > da0: quirks=3D0x2 > > > > > > >=20 > > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > > > > > > > da1: Removable Direct Access > > > > > > > SCSI-2 > > > > > > > device > > > > > > > da1: 40.000MB/s transfers > > > > > > > da1: Attempt to query device size failed: NOT READY, Medium=20 > > > > > > > not present > > > > > > > da1: quirks=3D0x2 > > > > > > >=20 > > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > > > > > > > da2: Removable Direct Access > > > > > > > SCSI-2 > > > > > > > device > > > > > > > da2: 40.000MB/s transfers > > > > > > > da2: Attempt to query device size failed: NOT READY, Medium=20 > > > > > > > not present > > > > > > > da2: quirks=3D0x2" > > > > > > >=20 > > > > > > > While looking at the hardware schematic, am I correct in=20 > > > > > > > assuming that > > > > > > > da0 represents the SD card slot, and da1 and da2 represent US= B=20 > > > > > > > port 1 and 2 respectively? > > > > > > >=20 > > > > > > > I don't remember the details, but there are 2 USB host ports= =20 > > > > > > > exposed on the board, and 1 USB otg port. > > > > > > > SD would be mmcsd0. > > > > > Well not the answer I was looking for, but this is what I got whe= n=20 > > > > > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to = a=20 > > > > > USB port on >an AMD64 / FreeBSD system. Since the messages all=20 > > > > > seem to refer to removable storage devices attached to the same=20 > > > > > bus on which the storage medium itself doesn't seem to be present= ,=20 > > > > > resulting in the devices being reported as not ready, the only=20 > > > > > thing I could imagine were the SD card slot (I believe using a=20 > > > > > converter it is possible to connect that to a USB port as well)=20 > > > > > and the two other (i.e. non > > > > > OTG) > > > > > USB ports. > > > > >=20 > > > > > Looking into this a bit further is the difference maybe the resul= t=20 > > > > > of a different way of enumerating devices on Linux then on=20 > > > > > FreeBSD? > > > > >=20 > > > > > If not, what conclusion should I draw from this? > > > > >=20 > > > >=20 > > > > Your question actually doesn't make much sense. =A0I think the best= =20 > > > > answer > > > > possible about what you see when you connect a running > > > >=20 > > > > cubieboard2 to a freebsd host is something like... > > > >=20 > > > > What you see is entirely dependent on what software is running on=20 > > > > the > > > cubieboard when you connect it, and questions about what shows up and= =20 > > > why > should be addressed to whomever wrote that software. > > >=20 > > > I'm not referring to what I see on the cubieboard2, but as I mentione= d=20 > > > to what I'm seeing on the console of an AMD64 / FreeBSD system to=20 > > > which I'm attaching it. > > >=20 > > >=20 > > > If freebsd is what's running on the board, then this is the right=20 > > > place to > > > ask, but you'd have to provide more info about exactly what you're >= =20 > > > running (where you got the image or how you built it). =A0If you're=20 > > > running some linux image then the builder/distributor of that image=20 > > > could answer >the questions. > > >=20 > > > The board is straight out of the box brand spanking new, so AFAIK=20 > > > there's nothing running on it yet. > > >=20 > > > Jk. >=20 > > What you are seeing on the freebsd console is the devices that the > software running on the cubieboard provides. =A0Even fresh out of the box= , it > is > running something (presumably some linux or android distro that gets > put into the nand flash at the factory). >=20 > > This has nothing to do with freebsd.=A0=A0You'd see the same thing if y= ou > plugged it into a windows system. >=20 > Thanks for pointing that out; I was already aware of that, but my question > was: which storage devices on the board do da0, da1 and da2 represent 'as > seen', if you will, from and on the FreeBSD system to which it is attache= d? >=20 > Regards, Jk. Probably none. What the software running on the board is doing is called usb gadget mode. It uses the OTG port to act as a device and it seems that it act as some multiple usb disk. But this doesn't mean that the device it's exporting match some device on the board. It could be directory or file on the filesystem. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Dec 14 21:58:07 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8C2DC800D3 for ; Wed, 14 Dec 2016 21:58:07 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 AD5F76E6 for ; Wed, 14 Dec 2016 21:58:06 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5d9a5390-c248-11e6-9ec7-5d8fa496b077 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 5d9a5390-c248-11e6-9ec7-5d8fa496b077; Wed, 14 Dec 2016 21:57:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBELw4sO004577; Wed, 14 Dec 2016 14:58:04 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481752684.1889.425.camel@freebsd.org> Subject: Re: building m4 in poudriere cross-build From: Ian Lepore To: Paul Mather , Vick Khera Cc: freebsd-arm@freebsd.org Date: Wed, 14 Dec 2016 14:58:04 -0700 In-Reply-To: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> References: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 21:58:07 -0000 On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote: > On Dec 14, 2016, at 9:42 AM, Vick Khera wrote: > > > > > I have a poudriere cross-building configuration set up on a Xeon > > running > > FreebSD 11.0. The jail was set up with the "-x" option to use the > > native > > cross-build tools. This has worked really well for a while, but > > today I am > > trying to update the packages for my raspberry pi 2, and poudriere > > just > > kind of sits there in the configure step when building m4 (as a > > dependency > > trying to build subversion). I haven't built this set of packages > > in over a > > month. > > > > The logs show this: > > > > checking for dirent.h... (cached) yes > > checking for inttypes.h... (cached) yes > > checking for working C stack overflow detection... make: Working > > in: > > /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > make: Working in: /usr/ports/devel/m4 > > > > The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with Poudriere > > 3.1.14 > > > > The build jail target is 11.0-RELEASE-p5/armv6 freshly updated. > > > > I let this run for over 18 hours, and it just kept repeating that > > last > > line. Has anyone had success with this set up recently? Maybe the > > qemu-arm-static is not working right now? > > I had (have) the same problem.  Not only would packages like m4 just > grind away for hours on end doing nothing until Poudriere timed out > the build (after 24 hours), but other packages I use like > math/gmp  and net/norm would fail to build with various errors.  I > use Saltstack and so these kind of failures meant that sysutils/py- > salt would be skipped for building, meaning it fell behind that of > the other architectures I was running. > > In the end, I decided to simply set up Poudriere on my FreeBSD/arm > Raspberry Pi 2 system and build packages there instead.  Running > natively, all these packages build correctly and once again I am able > to have up-to-date packages on my FreeBSD/arm systems.  Package > building isn't as fast as on my cross-build FreeBSD/amd64 system, but > at least they actually build---slower is better than never. :-) > > I can only assume that the QEMU arm emulator is deficient compared to > an actual CPU on a running FreeBSD/arm system.  If the official > FreeBSD/arm package repository is built via a cross-built environment > using QEMU, I presume these problems will linger until QEMU works > properly. > > I also assume that maybe the FreeBSD/arm package builders are > consider these ports simply to be broken on FreeBSD/arm, which is why > they fail to build under QEMU, when in fact the packages do actually > build on an actual FreeBSD/arm system.  At least that has been my > experience for the last few months. > > Cheers, > > Paul. I have successfully crossbuilt m4 using poudriere and qemu-static on freebsd 11, but I haven't tried in the past 6-8 months.  Something might have changed in the m4 port, like their configure script might be doing a stack overflow check now that it never used to do.  I could see a stack overflow test taking a long time under qemu, but 24 hours seems a bit much. -- Ian From owner-freebsd-arm@freebsd.org Wed Dec 14 22:31:03 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5F9B5C80AD0 for ; Wed, 14 Dec 2016 22:31:03 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 329611ABF; Wed, 14 Dec 2016 22:31:02 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from [172.27.0.245] (unknown [172.27.0.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 28BEF247; Wed, 14 Dec 2016 17:31:01 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: building m4 in poudriere cross-build From: Paul Mather In-Reply-To: <1481752684.1889.425.camel@freebsd.org> Date: Wed, 14 Dec 2016 17:31:00 -0500 Cc: Vick Khera , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> References: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> <1481752684.1889.425.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 22:31:03 -0000 On Dec 14, 2016, at 4:58 PM, Ian Lepore wrote: > On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote: >> On Dec 14, 2016, at 9:42 AM, Vick Khera wrote: >>=20 >>>=20 >>> I have a poudriere cross-building configuration set up on a Xeon >>> running >>> FreebSD 11.0. The jail was set up with the "-x" option to use the >>> native >>> cross-build tools. This has worked really well for a while, but >>> today I am >>> trying to update the packages for my raspberry pi 2, and poudriere >>> just >>> kind of sits there in the configure step when building m4 (as a >>> dependency >>> trying to build subversion). I haven't built this set of packages >>> in over a >>> month. >>>=20 >>> The logs show this: >>>=20 >>> checking for dirent.h... (cached) yes >>> checking for inttypes.h... (cached) yes >>> checking for working C stack overflow detection... make: Working >>> in: >>> /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>> make: Working in: /usr/ports/devel/m4 >>>=20 >>> The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with Poudriere >>> 3.1.14 >>>=20 >>> The build jail target is 11.0-RELEASE-p5/armv6 freshly updated. >>>=20 >>> I let this run for over 18 hours, and it just kept repeating that >>> last >>> line. Has anyone had success with this set up recently? Maybe the >>> qemu-arm-static is not working right now? >>=20 >> I had (have) the same problem. Not only would packages like m4 just >> grind away for hours on end doing nothing until Poudriere timed out >> the build (after 24 hours), but other packages I use like >> math/gmp and net/norm would fail to build with various errors. I >> use Saltstack and so these kind of failures meant that sysutils/py- >> salt would be skipped for building, meaning it fell behind that of >> the other architectures I was running. >>=20 >> In the end, I decided to simply set up Poudriere on my FreeBSD/arm >> Raspberry Pi 2 system and build packages there instead. Running >> natively, all these packages build correctly and once again I am able >> to have up-to-date packages on my FreeBSD/arm systems. Package >> building isn't as fast as on my cross-build FreeBSD/amd64 system, but >> at least they actually build---slower is better than never. :-) >>=20 >> I can only assume that the QEMU arm emulator is deficient compared to >> an actual CPU on a running FreeBSD/arm system. If the official >> FreeBSD/arm package repository is built via a cross-built environment >> using QEMU, I presume these problems will linger until QEMU works >> properly. >>=20 >> I also assume that maybe the FreeBSD/arm package builders are >> consider these ports simply to be broken on FreeBSD/arm, which is why >> they fail to build under QEMU, when in fact the packages do actually >> build on an actual FreeBSD/arm system. At least that has been my >> experience for the last few months. >>=20 >> Cheers, >>=20 >> Paul. >=20 > I have successfully crossbuilt m4 using poudriere and qemu-static on > freebsd 11, but I haven't tried in the past 6-8 months. Something > might have changed in the m4 port, like their configure script might = be > doing a stack overflow check now that it never used to do. I could = see > a stack overflow test taking a long time under qemu, but 24 hours = seems > a bit much. The last time I was able successfully to cross-build m4 is on = 2016-11-06. Since then, I think it has failed to get past the configure = stage and Poudriere times out. As you surmise, the last thing it does in the configure script is check = for stack overflow: =3D=3D=3D=3D=3D [[...]] checking for features.h... no checking for wctype.h... (cached) yes checking for dirent.h... (cached) yes checking for inttypes.h... (cached) yes checking for working C stack overflow detection... =3D=3D=3D=3D=3D It gets hung up on that until Poudriere times out or you CTRL-C the = build job. The m4 package is just one example. In the past they have built and = then something happens and then they don't (math/gmp is another example = like this). Some (like net/norm) I don't recall ever having managed to = cross-build. I was very surprised when I moved the FreeBSD/arm Poudriere building to = an actual Raspberry Pi and everything built fine first time. I don't = build many packages for my FreeBSD/arm systems, so it doesn't actually = take too long for me (building the jail takes longer:). Cheers, Paul. From owner-freebsd-arm@freebsd.org Wed Dec 14 22:39:28 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 16939C80D79 for ; Wed, 14 Dec 2016 22:39:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 EE4DF1FC9 for ; Wed, 14 Dec 2016 22:39:26 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 239348e5-c24e-11e6-9ec7-5d8fa496b077 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 239348e5-c24e-11e6-9ec7-5d8fa496b077; Wed, 14 Dec 2016 22:39:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBEMdOUb004644; Wed, 14 Dec 2016 15:39:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481755164.1889.430.camel@freebsd.org> Subject: Re: building m4 in poudriere cross-build From: Ian Lepore To: Paul Mather Cc: Vick Khera , freebsd-arm@freebsd.org Date: Wed, 14 Dec 2016 15:39:24 -0700 In-Reply-To: <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> References: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> <1481752684.1889.425.camel@freebsd.org> <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 22:39:28 -0000 On Wed, 2016-12-14 at 17:31 -0500, Paul Mather wrote: > On Dec 14, 2016, at 4:58 PM, Ian Lepore wrote: > > > > > On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote: > > > > > > On Dec 14, 2016, at 9:42 AM, Vick Khera wrote: > > > > > > > > > > > > > > > I have a poudriere cross-building configuration set up on a > > > > Xeon > > > > running > > > > FreebSD 11.0. The jail was set up with the "-x" option to use > > > > the > > > > native > > > > cross-build tools. This has worked really well for a while, but > > > > today I am > > > > trying to update the packages for my raspberry pi 2, and > > > > poudriere > > > > just > > > > kind of sits there in the configure step when building m4 (as a > > > > dependency > > > > trying to build subversion). I haven't built this set of > > > > packages > > > > in over a > > > > month. > > > > > > > > The logs show this: > > > > > > > > checking for dirent.h... (cached) yes > > > > checking for inttypes.h... (cached) yes > > > > checking for working C stack overflow detection... make: > > > > Working > > > > in: > > > > /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > make: Working in: /usr/ports/devel/m4 > > > > > > > > The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with > > > > Poudriere > > > > 3.1.14 > > > > > > > > The build jail target is 11.0-RELEASE-p5/armv6 freshly updated. > > > > > > > > I let this run for over 18 hours, and it just kept repeating > > > > that > > > > last > > > > line. Has anyone had success with this set up recently? Maybe > > > > the > > > > qemu-arm-static is not working right now? > > > I had (have) the same problem.  Not only would packages like m4 > > > just > > > grind away for hours on end doing nothing until Poudriere timed > > > out > > > the build (after 24 hours), but other packages I use like > > > math/gmp  and net/norm would fail to build with various > > > errors.  I > > > use Saltstack and so these kind of failures meant that > > > sysutils/py- > > > salt would be skipped for building, meaning it fell behind that > > > of > > > the other architectures I was running. > > > > > > In the end, I decided to simply set up Poudriere on my > > > FreeBSD/arm > > > Raspberry Pi 2 system and build packages there instead.  Running > > > natively, all these packages build correctly and once again I am > > > able > > > to have up-to-date packages on my FreeBSD/arm systems.  Package > > > building isn't as fast as on my cross-build FreeBSD/amd64 system, > > > but > > > at least they actually build---slower is better than never. :-) > > > > > > I can only assume that the QEMU arm emulator is deficient > > > compared to > > > an actual CPU on a running FreeBSD/arm system.  If the official > > > FreeBSD/arm package repository is built via a cross-built > > > environment > > > using QEMU, I presume these problems will linger until QEMU works > > > properly. > > > > > > I also assume that maybe the FreeBSD/arm package builders are > > > consider these ports simply to be broken on FreeBSD/arm, which is > > > why > > > they fail to build under QEMU, when in fact the packages do > > > actually > > > build on an actual FreeBSD/arm system.  At least that has been my > > > experience for the last few months. > > > > > > Cheers, > > > > > > Paul. > > I have successfully crossbuilt m4 using poudriere and qemu-static > > on > > freebsd 11, but I haven't tried in the past 6-8 months.  Something > > might have changed in the m4 port, like their configure script > > might be > > doing a stack overflow check now that it never used to do.  I could > > see > > a stack overflow test taking a long time under qemu, but 24 hours > > seems > > a bit much. > > The last time I was able successfully to cross-build m4 is on 2016- > 11-06.  Since then, I think it has failed to get past the configure > stage and Poudriere times out. > > As you surmise, the last thing it does in the configure script is > check for stack overflow: > > ===== > [[...]] > checking for features.h... no > checking for wctype.h... (cached) yes > checking for dirent.h... (cached) yes > checking for inttypes.h... (cached) yes > checking for working C stack overflow detection... > ===== > > It gets hung up on that until Poudriere times out or you CTRL-C the > build job. > > The m4 package is just one example.  In the past they have built and > then something happens and then they don't (math/gmp is another > example like this).  Some (like net/norm) I don't recall ever having > managed to cross-build. > > I was very surprised when I moved the FreeBSD/arm Poudriere building > to an actual Raspberry Pi and everything built fine first time.  I > don't build many packages for my FreeBSD/arm systems, so it doesn't > actually take too long for me (building the jail takes longer:). > > Cheers, > > Paul. Hmm, looks like nothing has changed in the m4 port for at least 8 months.  What has changed since November 6 is clang. There are many ports that fail to compile on arm that need only a tiny change to start working (for either native or cross-compile).  It doesn't take long to figure out the fixes, but it's virtually impossible to get the fixes committed.  The ports maintainers often don't know anything about arm or other platforms and are reluctant to commit changes they don't understand and can't test. -- Ian From owner-freebsd-arm@freebsd.org Wed Dec 14 23:03:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB4FCC77752 for ; Wed, 14 Dec 2016 23:03:09 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6ED391331 for ; Wed, 14 Dec 2016 23:03:09 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from webmail.xs4all.nl ([194.109.20.200]) by smtp-cloud2.xs4all.net with ESMTP id Kz361u00P4K0fSy01z36l7; Thu, 15 Dec 2016 00:03:06 +0100 Received: from costa.xs4all.nl ([82.95.89.208]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Thu, 15 Dec 2016 00:03:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 15 Dec 2016 00:03:06 +0100 From: "John W. Kitz" To: Emmanuel Vadot , 'Ian Lepore' Cc: 'Ganbold Tsagaankhuu' , freebsd-arm@freebsd.org Subject: Re: When first hooking up a cubieboard2... Reply-To: John.Kitz@xs4all.nl Mail-Reply-To: John.Kitz@xs4all.nl In-Reply-To: <20161214225633.160d9d06ddb0ae4a380ccf82@bidouilliste.com> References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <001101d25626$d4c71ad0$7e555070$@Kitz@xs4all.nl> <1481739755.1889.376.camel@freebsd.org> <001101d25641$0e794fe0$2b6befa0$@Kitz@xs4all.nl> <1481749803.1889.406.camel@freebsd.org> <001701d25654$111d4c20$3357e460$@Kitz@xs4all.nl> <20161214225633.160d9d06ddb0ae4a380ccf82@bidouilliste.com> Message-ID: <7fee533d65c2760ffb9c42d5448c3ee9@xs4all.nl> X-Sender: John.Kitz@xs4all.nl (2pdfbdJImrOBch1xFLD1XQ==) User-Agent: XS4ALL Webmail X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 23:03:09 -0000 On 2016-12-14 22:56, Emmanuel Vadot wrote: > On Wed, 14 Dec 2016 22:50:19 +0100 > "John W. Kitz" wrote: > >> Ian, >> >> > On Wed, 2016-12-14 at 20:34 +0100, John W. Kitz wrote: >> > > Gents, >> > > >> > > On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: >> > > > >> > > > > >> > > > > Ganbold, >> > > > > >> > > > > > >> > > > > > >> > > > > > > >> > > > > > > >> > > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz > > > > > > > ll.n >> > > > > > > l> wrote: >> > > > > > > Hi, >> > > > > > > >> > > > > > > When attaching a new cubieboard2 to a FreeBSD system for the >> > > > > > > first time I >> > > > > > > get: >> > > > > > > >> > > > > > > "ugen1.2: at usbus1 >> > > > > > > umass0: on usbus1 >> > > > > > > umass0:  SCSI over Bulk-Only; quirks = 0x4000 >> > > > > > > umass0:4:0: Attached to scbus4 >> > > > > > > >> > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 >> > > > > > > da0: Removable Direct Access >> > > > > > > SCSI-2 >> > > > > > > device >> > > > > > > da0: 40.000MB/s transfers >> > > > > > > da0: Attempt to query device size failed: NOT READY, Medium >> > > > > > > not present >> > > > > > > da0: quirks=0x2 >> > > > > > > >> > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 >> > > > > > > da1: Removable Direct Access >> > > > > > > SCSI-2 >> > > > > > > device >> > > > > > > da1: 40.000MB/s transfers >> > > > > > > da1: Attempt to query device size failed: NOT READY, Medium >> > > > > > > not present >> > > > > > > da1: quirks=0x2 >> > > > > > > >> > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 >> > > > > > > da2: Removable Direct Access >> > > > > > > SCSI-2 >> > > > > > > device >> > > > > > > da2: 40.000MB/s transfers >> > > > > > > da2: Attempt to query device size failed: NOT READY, Medium >> > > > > > > not present >> > > > > > > da2: quirks=0x2" >> > > > > > > >> > > > > > > While looking at the hardware schematic, am I correct in >> > > > > > > assuming that >> > > > > > > da0 represents the SD card slot, and da1 and da2 represent USB >> > > > > > > port 1 and 2 respectively? >> > > > > > > >> > > > > > > I don't remember the details, but there are 2 USB host ports >> > > > > > > exposed on the board, and 1 USB otg port. >> > > > > > > SD would be mmcsd0. >> > > > > Well not the answer I was looking for, but this is what I got when >> > > > > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to a >> > > > > USB port on >an AMD64 / FreeBSD system. Since the messages all >> > > > > seem to refer to removable storage devices attached to the same >> > > > > bus on which the storage medium itself doesn't seem to be present, >> > > > > resulting in the devices being reported as not ready, the only >> > > > > thing I could imagine were the SD card slot (I believe using a >> > > > > converter it is possible to connect that to a USB port as well) >> > > > > and the two other (i.e. non >> > > > > OTG) >> > > > > USB ports. >> > > > > >> > > > > Looking into this a bit further is the difference maybe the result >> > > > > of a different way of enumerating devices on Linux then on >> > > > > FreeBSD? >> > > > > >> > > > > If not, what conclusion should I draw from this? >> > > > > >> > > > >> > > > Your question actually doesn't make much sense.  I think the best >> > > > answer >> > > > possible about what you see when you connect a running >> > > > >> > > > cubieboard2 to a freebsd host is something like... >> > > > >> > > > What you see is entirely dependent on what software is running on >> > > > the >> > > cubieboard when you connect it, and questions about what shows up and >> > > why > should be addressed to whomever wrote that software. >> > > >> > > I'm not referring to what I see on the cubieboard2, but as I mentioned >> > > to what I'm seeing on the console of an AMD64 / FreeBSD system to >> > > which I'm attaching it. >> > > >> > > >> > > If freebsd is what's running on the board, then this is the right >> > > place to >> > > ask, but you'd have to provide more info about exactly what you're > >> > > running (where you got the image or how you built it).  If you're >> > > running some linux image then the builder/distributor of that image >> > > could answer >the questions. >> > > >> > > The board is straight out of the box brand spanking new, so AFAIK >> > > there's nothing running on it yet. >> > > >> > > Jk. >> >> > What you are seeing on the freebsd console is the devices that the >> software running on the cubieboard provides.  Even fresh out of the >> box, it >> is > running something (presumably some linux or android distro that >> gets >> put into the nand flash at the factory). >> >> > This has nothing to do with freebsd.  You'd see the same thing if you >> plugged it into a windows system. >> >> Thanks for pointing that out; I was already aware of that, but my >> question >> was: which storage devices on the board do da0, da1 and da2 represent >> 'as >> seen', if you will, from and on the FreeBSD system to which it is >> attached? >> >> Regards, Jk. > > Probably none. > What the software running on the board is doing is called usb gadget > mode. It uses the OTG port to act as a device and it seems that it act > as some multiple usb disk. But this doesn't mean that the device it's > exporting match some device on the board. It could be directory or file > on the filesystem. Ian, The question may not have been related to running FreeBSD on a cubieboard (yet), but it did involve FreeBSD, albeit on AMD64 and a ARM board. That's why I posted it here. Emmanuel, That clarified it for me, thanks. Regards, Jk. -- This email and any attachment is for authorized use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this email and its attachment(s) and inform the sender. Thank you. From owner-freebsd-arm@freebsd.org Thu Dec 15 05:15:02 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C795FC77674 for ; Thu, 15 Dec 2016 05:15:02 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F7B986F; Thu, 15 Dec 2016 05:15:01 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id uBF59fPW079133 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Dec 2016 06:09:42 +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 uBF59buF046580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Dec 2016 06:09:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id uBF59bT0006717; Thu, 15 Dec 2016 06:09:37 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id uBF59aYI006716; Thu, 15 Dec 2016 06:09:36 +0100 (CET) (envelope-from ticso) Date: Thu, 15 Dec 2016 06:09:35 +0100 From: Bernd Walter To: "John W. Kitz" Cc: Emmanuel Vadot , "'Ian Lepore'" , freebsd-arm@freebsd.org Subject: Re: When first hooking up a cubieboard2... Message-ID: <20161215050935.GL313@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <1481739755.1889.376.camel@freebsd.org> <1481749803.1889.406.camel@freebsd.org> <20161214225633.160d9d06ddb0ae4a380ccf82@bidouilliste.com> <7fee533d65c2760ffb9c42d5448c3ee9@xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <7fee533d65c2760ffb9c42d5448c3ee9@xs4all.nl> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 05:15:02 -0000 On Thu, Dec 15, 2016 at 12:03:06AM +0100, John W. Kitz wrote: > On 2016-12-14 22:56, Emmanuel Vadot wrote: > >On Wed, 14 Dec 2016 22:50:19 +0100 > >"John W. Kitz" wrote: > > > >>Ian, > >> > >>> On Wed, 2016-12-14 at 20:34 +0100, John W. Kitz wrote: > >>> > Gents, > >>> > > >>> > On Wed, 2016-12-14 at 17:26 +0100, John W. Kitz wrote: > >>> > > > >>> > > > > >>> > > > Ganbold, > >>> > > > > >>> > > > > > >>> > > > > > >>> > > > > > > >>> > > > > > > >>> > > > > > On Wed, Dec 14, 2016 at 5:22 AM, John W. Kitz >>> > > > > > ll.n > >>> > > > > > l> wrote: > >>> > > > > > Hi, > >>> > > > > > > >>> > > > > > When attaching a new cubieboard2 to a FreeBSD system for the > >>> > > > > > first time I > >>> > > > > > get: > >>> > > > > > > >>> > > > > > "ugen1.2: at usbus1 > >>> > > > > > umass0: on usbus1 > >>> > > > > > umass0:  SCSI over Bulk-Only; quirks = 0x4000 > >>> > > > > > umass0:4:0: Attached to scbus4 > >>> > > > > > > >>> > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 > >>> > > > > > da0: Removable Direct Access > >>> > > > > > SCSI-2 > >>> > > > > > device > >>> > > > > > da0: 40.000MB/s transfers > >>> > > > > > da0: Attempt to query device size failed: NOT READY, Medium > >>> > > > > > not present > >>> > > > > > da0: quirks=0x2 > >>> > > > > > > >>> > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 > >>> > > > > > da1: Removable Direct Access > >>> > > > > > SCSI-2 > >>> > > > > > device > >>> > > > > > da1: 40.000MB/s transfers > >>> > > > > > da1: Attempt to query device size failed: NOT READY, Medium > >>> > > > > > not present > >>> > > > > > da1: quirks=0x2 > >>> > > > > > > >>> > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 > >>> > > > > > da2: Removable Direct Access > >>> > > > > > SCSI-2 > >>> > > > > > device > >>> > > > > > da2: 40.000MB/s transfers > >>> > > > > > da2: Attempt to query device size failed: NOT READY, Medium > >>> > > > > > not present > >>> > > > > > da2: quirks=0x2" > >>> > > > > > > >>> > > > > > While looking at the hardware schematic, am I correct in > >>> > > > > > assuming that > >>> > > > > > da0 represents the SD card slot, and da1 and da2 represent USB > >>> > > > > > port 1 and 2 respectively? > >>> > > > > > > >>> > > > > > I don't remember the details, but there are 2 USB host ports > >>> > > > > > exposed on the board, and 1 USB otg port. > >>> > > > > > SD would be mmcsd0. > >>> > > > Well not the answer I was looking for, but this is what I got when > >>> > > > attaching the OTG port of a new cubieboard2 (NOT in FEL mode) to a > >>> > > > USB port on >an AMD64 / FreeBSD system. Since the messages all > >>> > > > seem to refer to removable storage devices attached to the same > >>> > > > bus on which the storage medium itself doesn't seem to be present, > >>> > > > resulting in the devices being reported as not ready, the only > >>> > > > thing I could imagine were the SD card slot (I believe using a > >>> > > > converter it is possible to connect that to a USB port as well) > >>> > > > and the two other (i.e. non > >>> > > > OTG) > >>> > > > USB ports. > >>> > > > > >>> > > > Looking into this a bit further is the difference maybe the result > >>> > > > of a different way of enumerating devices on Linux then on > >>> > > > FreeBSD? > >>> > > > > >>> > > > If not, what conclusion should I draw from this? > >>> > > > > >>> > > > >>> > > Your question actually doesn't make much sense.  I think the best > >>> > > answer > >>> > > possible about what you see when you connect a running > >>> > > > >>> > > cubieboard2 to a freebsd host is something like... > >>> > > > >>> > > What you see is entirely dependent on what software is running on > >>> > > the > >>> > cubieboard when you connect it, and questions about what shows up and > >>> > why > should be addressed to whomever wrote that software. > >>> > > >>> > I'm not referring to what I see on the cubieboard2, but as I mentioned > >>> > to what I'm seeing on the console of an AMD64 / FreeBSD system to > >>> > which I'm attaching it. > >>> > > >>> > > >>> > If freebsd is what's running on the board, then this is the right > >>> > place to > >>> > ask, but you'd have to provide more info about exactly what you're > > >>> > running (where you got the image or how you built it).  If you're > >>> > running some linux image then the builder/distributor of that image > >>> > could answer >the questions. > >>> > > >>> > The board is straight out of the box brand spanking new, so AFAIK > >>> > there's nothing running on it yet. > >>> > > >>> > Jk. > >> > >>> What you are seeing on the freebsd console is the devices that the > >>software running on the cubieboard provides.  Even fresh out of the > >>box, it > >>is > running something (presumably some linux or android distro that > >>gets > >>put into the nand flash at the factory). > >> > >>> This has nothing to do with freebsd.  You'd see the same thing if you > >>plugged it into a windows system. > >> > >>Thanks for pointing that out; I was already aware of that, but my > >>question > >>was: which storage devices on the board do da0, da1 and da2 represent > >>'as > >>seen', if you will, from and on the FreeBSD system to which it is > >>attached? > >> > >>Regards, Jk. > > > > Probably none. > > What the software running on the board is doing is called usb gadget > >mode. It uses the OTG port to act as a device and it seems that it act > >as some multiple usb disk. But this doesn't mean that the device it's > >exporting match some device on the board. It could be directory or file > >on the filesystem. > > Ian, > > The question may not have been related to running FreeBSD on a > cubieboard (yet), but it did involve FreeBSD, albeit on AMD64 and a ARM > board. That's why I posted it here. Sure it does involve FreeBSD, but FreeBSD sees whatever the attached device claims to be. It claims to be 3 USB mass storage devices, so FreeBSD lists 3 USB mass storage devices. But FreeBSD has no clue about what they are intended to be used for and you can't even read them, since whatever is running on the cubieboard notes them as not ready. Unless someone on the list knows what the software delivered on the cubieboard actually does, you won't get an answer. This is like plugging an USB memory stick into a FreeBSD computer and asking on a FreeBSD list what pictures are on the stick. You'd better ask the person who knows about the USB stick, right? Well - we could tell you how to read data from the stick and try to find out, but in this case the da devices are not ready, so even that is impossible. My own guess (as in starring at my crystal ball), would be that it might allow writing to an SD card if one would have been inserted. No idea why it lists 3 da devices though. Nevertheless this could easily be done with any kind of USB card reader as well, so nothing important after all. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Thu Dec 15 06:29:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9AC9C80A4E for ; Thu, 15 Dec 2016 06:29:21 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A3AB7918 for ; Thu, 15 Dec 2016 06:29:21 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by mail-qk0-x234.google.com with SMTP id n204so46477380qke.2 for ; Wed, 14 Dec 2016 22:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JolNmI4hlc0Qs6mr9mqYKIEXaQPzeYSezrekFre5a2k=; b=LaMszM+Xv3E3JP9Sf551yC0Mc5d2s3FsjrBQAJt6PYKlH3aeyX2+2ZI+Q/QWnvKu2C 4n7c52LdvhQtNIhQrwCcFnlfKS7g5OV6cZbPFOHu0W0v3ZXU6jU06G5Pl258fbXJltqI kbyZM8AJ+A+5YwTZckkoqUwDLZqyHVqfMo4xIhcfOsWA8nkOoSGgUo2tysGoxN7/As9u FJZ2TKdioersN3wyrvFwME2b9sguzNvL/MXe2fVvPzaB3tefBACZxZd6/syE1Ft6s/bk vtCY92G2TCW9L2EsIb/4OG+VSx5toY4KlTNC5Zvx0Wtm/Pa6zsBt7XiL/RPlAqYDpK0L v7fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JolNmI4hlc0Qs6mr9mqYKIEXaQPzeYSezrekFre5a2k=; b=HiVsphTnNuGVnAHKVIESGF4CUSyWuxPQrWsrVDBYSZyUW9GMlCeTD8T/TlbEUF0iIs ABsZGCQIOBL0rjn4wupJNLR9uNxpGkSVPMn6shn5CLYr7W3a9UCJRtKf1gs8OZutEwK2 CRQKhq5QTJc/XxCnnqJ5Wh4F+8fVxV61E8mOeoeEHiNAjFqbhvHSXUmxJ9cnQchwwFGt 31kklALCv7pVD9z0/xgT0NJ9y86NQsBrGgQGgc1dRQsig/ABeFE4qD86h4J0c+BMfsaa kZBurm4ZIzxnyVGg20A6Ij87NflJR0bAjFsFWP9iUhgt+HxnUk8vY6W5/EtdI9X3FmBA ISiA== X-Gm-Message-State: AIkVDXK1qUFsr6SScYPAe+224YPalvTQc4v07ZPDp+EVBnYsULQ4aanFpHLG9kI03kBjp8Ibh/LZioRQTM8zKw== X-Received: by 10.55.0.65 with SMTP id 62mr575929qka.106.1481783360790; Wed, 14 Dec 2016 22:29:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.167.137 with HTTP; Wed, 14 Dec 2016 22:29:20 -0800 (PST) In-Reply-To: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> From: Mihai Carabas Date: Thu, 15 Dec 2016 08:29:20 +0200 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org, Alex Ivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 06:29:22 -0000 Hello Manu, We've tried multiple methods: 1. precompiled u-boot from FreeBSD packages + ubldr 2. u-boot compiled from sources + your patches + ubldr 3. precompiled u-boot from FreeBSD packages + kernel 4. u-boot compiled from sources + your patches + kernel For 1 and 2 we didn't manage to start ubldr. Do we need to add any custom option to u-boot? For 3, we manage to boot it normally. With 4, we have the following error: =3D> setenv bootcmd "fatload mmc 0:1 0x42000000 kernel.bin; go 0x42000000" =3D> boot reading kernel.bin 6758372 bytes read in 589 ms (10.9 MiB/s) ## Starting application at 0x42000000 ... panic: mtx_lock() of spin mutex (null) @ /root/bhyve-ARM/src/sys/arm/arm/pmap-v6.c:6350 cpuid =3D 0 Uptime: 1s How did we compile u-boot: - we took 2016.11 from here[1] (u-boot-2016.11.tar.bz2) - apply patches and compile root@bsd:~/u-boot-2016.11 # patch -p1 -i ../ people.freebsd.org/\~manu/uboot/0001-.... root@bsd:~/u-boot-2016.11 # make CROSS_COMPILE=3Darm-none-eabi- Cubieboard2_config root@bsd:~/u-boot-2016.11 # make CROSS_COMPILE=3Darm-none-eabi- - and used the u-boot-sunxi-with-spl.bin =E2=80=8B Do you have any insight? (at least for thr 4th method) Thank you, Mihai From owner-freebsd-arm@freebsd.org Thu Dec 15 06:43:00 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2977EC81023 for ; Thu, 15 Dec 2016 06:43:00 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from forward5j.cmail.yandex.net (forward5j.cmail.yandex.net [IPv6:2a02:6b8:0:1630::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DC00910FB; Thu, 15 Dec 2016 06:42:59 +0000 (UTC) (envelope-from bsam@passap.ru) Received: from smtp2m.mail.yandex.net (smtp2m.mail.yandex.net [IPv6:2a02:6b8:0:2519::122]) by forward5j.cmail.yandex.net (Yandex) with ESMTP id E6CCA20D4C; Thu, 15 Dec 2016 09:42:47 +0300 (MSK) Received: from smtp2m.mail.yandex.net (localhost.localdomain [127.0.0.1]) by smtp2m.mail.yandex.net (Yandex) with ESMTP id 0CA862300F15; Thu, 15 Dec 2016 09:42:44 +0300 (MSK) Received: by smtp2m.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id vmpeJi5oGP-giNOtlrx; Thu, 15 Dec 2016 09:42:44 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) X-Yandex-Suid-Status: 1 0,1 0 Subject: Re: building m4 in poudriere cross-build To: Ian Lepore References: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> <1481752684.1889.425.camel@freebsd.org> <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> <1481755164.1889.430.camel@freebsd.org> Cc: freebsd-arm@freebsd.org From: Boris Samorodov Message-ID: Date: Thu, 15 Dec 2016 09:42:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <1481755164.1889.430.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 06:43:00 -0000 Hi All, 15.12.2016 01:39, Ian Lepore пишет: > There are many ports that fail to compile on arm that need only a tiny > change to start working (for either native or cross-compile). It > doesn't take long to figure out the fixes, but it's virtually > impossible to get the fixes committed. Do you have any evidence of such resistance (may be PR)? > The ports maintainers often > don't know anything about arm or other platforms and are reluctant to > commit changes they don't understand and can't test. Then committers should teach maintainers to deal with ARM specifics. Me for one would be glad to get more info how to fix ARM & ports problems. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve From owner-freebsd-arm@freebsd.org Thu Dec 15 06:51:55 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3CA3AC81354 for ; Thu, 15 Dec 2016 06:51:55 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 06D7A14EE for ; Thu, 15 Dec 2016 06:51:55 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-it0-x22e.google.com with SMTP id y23so22188163itc.0 for ; Wed, 14 Dec 2016 22:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1KXvCUXoV4QjYFtuIFYItdeMSWer1RR/FYcVcUNBo6E=; b=bBUoa8LoZKlwV72olpGdlNbtPYuGbf1mRWXz9Wa2AY5fHnwnh3XG86wBFU0n3m45kE usdPFV6Pk0e6/G1qtW1LUIzoGjZCN/U8EQTj4k0k0klSftIPBM6gx749HhM8sOMbkuJw WJTKlLknZAi3lbZOX0pAjMY2+3GVoWneZAn1KGRUssE10ASrXwWRRjpumlRtccnKNaOF /zuzZFeeuK0BfFgefDONAhy7IhBpWGyPySmFGLOWIoUTYEagHt/QoSZz9fpWG72kfF4q PSxvOrdNCOefxZPObuMbp4u8XKo4B/g41bpte0ayt1X8jeiBj6lS+V3KapgS9ajFMd5V TTHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1KXvCUXoV4QjYFtuIFYItdeMSWer1RR/FYcVcUNBo6E=; b=KgY5kNe7XR4R/jLRCSkCk9I37HKQJURXyQQ/gm8hlZsRPzWKm9cJLzbGOIGWsR5Ixa gDICC0sjlEb9Qu8eSFBKyQ+W+a6IT5l35YLsiqp6FtFtylPqAgVkxDzUEXpK1zgrXGX+ tVcl/s975EQdwdkLrli/VIlJfhgIt9gM/3KF+dNwQquGUVPXf9H0xqUx5TTy1fwJWd+F V3FxWJs2huJ2j7wNqITHOHuy+VQi36RXfI+edxQDnXMLe41gw5iNFhuSoQ+wh5oKSIo5 /sP26maN/x6qUgJQdBGlcYKiRH5chxvWP9Sb9ZBUMa/wLklSEGaomCVq/p7IggoMka0o 8q6g== X-Gm-Message-State: AKaTC02ZnFoFSu5GvbKZWClgK+S05qRMfGSJQfu2r0slYtiCNw629io1Q4wDgqqhxCaLxO9PUqX/Uy+d2hk8gg== X-Received: by 10.36.61.207 with SMTP id n198mr1233657itn.60.1481784714407; Wed, 14 Dec 2016 22:51:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.242.167 with HTTP; Wed, 14 Dec 2016 22:51:53 -0800 (PST) In-Reply-To: References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> From: Ganbold Tsagaankhuu Date: Thu, 15 Dec 2016 14:51:53 +0800 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Mihai Carabas Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" , Alex Ivan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 06:51:55 -0000 On Thu, Dec 15, 2016 at 2:29 PM, Mihai Carabas wrote: > Hello Manu, > > We've tried multiple methods: > 1. precompiled u-boot from FreeBSD packages + ubldr > 2. u-boot compiled from sources + your patches + ubldr > ubldr is broken in recent head. At least r308903 (few days before clang import) works for me. Ganbold > 3. precompiled u-boot from FreeBSD packages + kernel > 4. u-boot compiled from sources + your patches + kernel > > For 1 and 2 we didn't manage to start ubldr. Do we need to add any custom > option to u-boot? > > For 3, we manage to boot it normally. > > With 4, we have the following error: > =3D> setenv bootcmd "fatload mmc 0:1 0x42000000 kernel.bin; go 0x42000000= " > =3D> boot > reading kernel.bin > 6758372 bytes read in 589 ms (10.9 MiB/s) > ## Starting application at 0x42000000 ... > panic: mtx_lock() of spin mutex (null) @ > /root/bhyve-ARM/src/sys/arm/arm/pmap-v6.c:6350 > cpuid =3D 0 > Uptime: 1s > > How did we compile u-boot: > - we took 2016.11 from here[1] (u-boot-2016.11.tar.bz2) > > - apply patches and compile > root@bsd:~/u-boot-2016.11 # patch -p1 -i ../ > people.freebsd.org/\~manu/uboot/0001-.. > .. > root@bsd:~/u-boot-2016.11 # make CROSS_COMPILE=3Darm-none-eabi- > Cubieboard2_config > root@bsd:~/u-boot-2016.11 # make CROSS_COMPILE=3Darm-none-eabi- > > - and used the u-boot-sunxi-with-spl.bin > =E2=80=8B > Do you have any insight? (at least for thr 4th method) > > Thank you, > Mihai > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Dec 15 10:53:07 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93915C807B0 for ; Thu, 15 Dec 2016 10:53:07 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 32C26F7F for ; Thu, 15 Dec 2016 10:53:06 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud6.xs4all.net with ESMTP id LAt21u00L4VixDu01At4wy; Thu, 15 Dec 2016 11:53:04 +0100 Reply-To: From: "John W. Kitz" To: Cc: "'Emmanuel Vadot'" , "'Ian Lepore'" , References: <585066dd.1c7c630a.8fe44.4233SMTPIN_ADDED_BROKEN@mx.google.com> <1481739755.1889.376.camel@freebsd.org> <1481749803.1889.406.camel@freebsd.org> <20161214225633.160d9d06ddb0ae4a380ccf82@bidouilliste.com> <7fee533d65c2760ffb9c42d5448c3ee9@xs4all.nl> <20161215050935.GL313@cicely7.cicely.de> In-Reply-To: <20161215050935.GL313@cicely7.cicely.de> Subject: RE: When first hooking up a cubieboard2... Date: Thu, 15 Dec 2016 11:52:55 +0100 Message-ID: <000901d256c1$6a959330$3fc0b990$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJWkXm/qf9Emp/GRRaaPiFHXydWuQAK42mw Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 10:53:07 -0000 Bernd, > > > Probably none. > > > What the software running on the board is doing is called usb gadget > > > mode. It uses the OTG port to act as a device and it seems that it > > > act as some multiple usb disk. But this doesn't mean that the device > > > it's exporting match some device on the board. It could be directory > > > or file on the filesystem. > > > > Ian, > > > > The question may not have been related to running FreeBSD on a > > cubieboard (yet), but it did involve FreeBSD, albeit on AMD64 and a > > ARM board. That's why I posted it here. > > Sure it does involve FreeBSD, but FreeBSD sees whatever the attached device claims to be. > It claims to be 3 USB mass storage devices, so FreeBSD lists 3 USB mass storage devices. That was indeed my original question and both Emmanuel and you seem to confirm my initial remarks (also refer to https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/usb-disks.html, in particular section 17.4.1). So thanks for that. > But FreeBSD has no clue about what they are intended to be used for and you can't even read them, since whatever is running on the cubieboard notes > them as not ready. > Unless someone on the list knows what the software delivered on the cubieboard actually does, you won't get an answer. > This is like plugging an USB memory stick into a FreeBSD computer and asking on a FreeBSD list what pictures are on the stick. True, if I had asked about the possible content, which I didn't. > You'd better ask the person who knows about the USB stick, right? > Well - we could tell you how to read data from the stick and try to find out, but in this case the da devices are not ready, so even that is > impossible. > My own guess (as in starring at my crystal ball), would be that it might allow writing to an SD card if one would have been inserted. Based on the information so far, I guessed that too. In which case inserting an SD card would probably have resulted in a status change (from "NOT READY, Medium not present" to something else) of one of the devices da0, da1 or da2 (assuming they behave as there enumeration on the FreeBSD system would suggest). However inserting an SD card did not cause a status change. So, unless that was caused by the SD card I used (it is an older one) at this stage it probably isn't possible to write anything to an SD card in the SD card slot of the board. > No idea why it lists 3 da devices though. > Nevertheless this could easily be done with any kind of USB card reader as well, so nothing important after all. Regards, Jk. From owner-freebsd-arm@freebsd.org Thu Dec 15 11:11:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58BE3C80EA5 for ; Thu, 15 Dec 2016 11:11:59 +0000 (UTC) (envelope-from meka@tilda.center) Received: from mail.tilda.center (mail.tilda.center [188.226.130.133]) by mx1.freebsd.org (Postfix) with ESMTP id 24B1A17B9 for ; Thu, 15 Dec 2016 11:11:58 +0000 (UTC) (envelope-from meka@tilda.center) Received: from hal9000.meka.no-ip.org (unknown [87.116.180.51]) by mail.tilda.center (Postfix) with ESMTPSA id 0D28F61702; Thu, 15 Dec 2016 12:11:50 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=tilda.center; s=mail; t=1481800311; bh=JLF77n6DyK3KQ/oShfAtw8V9VhCNrQl3Q6zvwn4yvLs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gdk12FXXi89BUTQTUWpfBA1CDys6EDoqWtv9JRYDtoD5YclBpgSuQdWWlX2gYEqJ+ +mJYKzJypKL3wlFllrFQ1pQZuTPo+TZRIj4CKKPb5CUi4vFd4fGK+ixwVz1ZnbspIz Z6uj2UBvCbccwU+TShwYys1tN8c8NwBoh8yAzUQA= Date: Thu, 15 Dec 2016 12:11:51 +0100 From: Goran =?utf-8?B?TWVracSH?= To: Boris Samorodov Cc: freebsd-arm@freebsd.org Subject: Re: Arduino Due Message-ID: <20161215111151.geyecaxakyn6feau@hal9000.meka.no-ip.org> References: <20161211034602.3fylwnxfbgl4ehgx@hal9000.meka.no-ip.org> <1752cc8d-fad7-141d-4950-37bb5dde9561@passap.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y2df6tgsaandfenn" Content-Disposition: inline In-Reply-To: <1752cc8d-fad7-141d-4950-37bb5dde9561@passap.ru> User-Agent: NeoMutt/20161126 (1.7.1) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 11:11:59 -0000 --y2df6tgsaandfenn Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hello, So I did a little checks and I think it's the cross compiling that's faulty. I generated blink led .bin file on Linux and FreeBSD. I can flash any of them from FreeBSD using bossac, and Linux .bin file works, FreeBSD one doesn't (the led is always lit). I checked the commands Arduino IDE is using on Linux and FreeBSD, and they are the same. I tried this with arm-none-eabi-gcc versions 4.9, 5.3 and 6.2. As all those versions are failing, maybe it's not GCC but binutils or something like that (just a wild guess). I would be really grateful if someone could tell me how to pinpoint the error even more. Thank you! Just for reference, on Arduino Due the MCU is Cortex M3. Regards, meka --y2df6tgsaandfenn Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE1WIFkXy2ZeMKjjKEWj1TknovrLYFAlhSenMACgkQWj1Tknov rLbv4BAAgqG0YgXUrcmfWNrFSadJoIeXYX0H33fdMzko2SJgkjg8fw99f+Bol+SL H1UlgmOHczqHpxotZxgtKr6SC6XOZ7KkWlVj1sdphiJhxrrafQuwSwMdWzxR7T7h KDy12F2dCHcN3vqjbkGquOZgiegV9de51wWLjMDGcSY/LhDgzTEjx15y4ImXMFaC Aduyk6F4hgkKdLjEfSQ67ygkveOVWAzCQfroelSQgVaYlPxOBv0YWH25BRqvj7Zc kPNf8ZDzFShzXF9uPsnE+KoY+MS3QJLXzQG//QQOdvQ6zPgvOm5y7R6Pn6EQcfMh 8drjcFA0P1Eb00sutaPi9BxY/JGpVJdIpMnjf9OYxgCD1TnxddQze/j7KDkcgpKN +LRmc4lc6EyvSz1miTsx1D/d8Gwcb2JgmjMDscHzwcbl8kh5xvjY3NeBcUhOnI5T RyGdfqe43Bcv/G422jcmZLogGcgGz3zUb5wohd8bONv4JTl1aV0wMID+0TrPV7kh jMhtRdDgEnYYhQnCMJRvrE6Q9PCjJeFERdcSFFMFXIElvVM0MgU8jaiu1d5CG8jU 1Au6lUPL+eHsMNEVVtjRHx5bTAwfwDLXJyOR5NbwNBe4j/nLUMthLyJDwGFtaB1z Ek9n+q7c1JBeZ7ccL4TVUKJijq5+i2UECIgMSmuK2ovYAaPAFkE= =L9qm -----END PGP SIGNATURE----- --y2df6tgsaandfenn-- From owner-freebsd-arm@freebsd.org Thu Dec 15 11:39:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E98CBC81B10 for ; Thu, 15 Dec 2016 11:39:04 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 73B4487B for ; Thu, 15 Dec 2016 11:39:03 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id cb319bf0; Thu, 15 Dec 2016 12:39:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=tHpWOUDeuHh66iQ/8/w7gulEZLY=; b=bRriPDYqGNZWRglOA2lj3SLPp/AC DxzOSiKxnjZGT6ArqPV7HpsAWbw32rXoaOId4Jm5oK32rirm7wHz6e2+dErPR69j GlYHm8oiddXhgbi5F1TWdK7DiNCCsyselKgTQXMkLOJeCXzS2l1gaUMo4buuSOfx xThqs/uCIzsX8l4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=snZ8dsUy/vmNYw6Qz70JUVlvjhXwLLfc5nzCCQfecsI9lvD+p17xOPkv dtuKnFlFxduA6w5NAKXLA4FTW3OU++aUwCk3XMZFzzSDoBNX29lb5+LpJJSRwnCf jkvZebgA5ejpQn6XWRBOwLrQ2G2mlDgqHi3CnQR07lDre60eylM= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 97033a81 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 15 Dec 2016 12:39:00 +0100 (CET) Date: Thu, 15 Dec 2016 12:39:00 +0100 From: Emmanuel Vadot To: Mihai Carabas Cc: freebsd-arm@freebsd.org, Alex Ivan Subject: Re: Cubieboard2 with custom bootloader Message-Id: <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> In-Reply-To: References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 11:39:05 -0000 On Thu, 15 Dec 2016 08:29:20 +0200 Mihai Carabas wrote: > Hello Manu, >=20 > We've tried multiple methods: > 1. precompiled u-boot from FreeBSD packages + ubldr > 2. u-boot compiled from sources + your patches + ubldr > 3. precompiled u-boot from FreeBSD packages + kernel > 4. u-boot compiled from sources + your patches + kernel >=20 > For 1 and 2 we didn't manage to start ubldr. Do we need to add any custom > option to u-boot? >=20 > For 3, we manage to boot it normally. >=20 > With 4, we have the following error: > =3D> setenv bootcmd "fatload mmc 0:1 0x42000000 kernel.bin; go 0x42000000" > =3D> boot > reading kernel.bin > 6758372 bytes read in 589 ms (10.9 MiB/s) > ## Starting application at 0x42000000 ... > panic: mtx_lock() of spin mutex (null) @ > /root/bhyve-ARM/src/sys/arm/arm/pmap-v6.c:6350 > cpuid =3D 0 > Uptime: 1s >=20 > How did we compile u-boot: > - we took 2016.11 from here[1] (u-boot-2016.11.tar.bz2) >=20 > - apply patches and compile > root@bsd:~/u-boot-2016.11 # patch -p1 -i ../ > people.freebsd.org/\~manu/uboot/0001-.... > root@bsd:~/u-boot-2016.11 # make CROSS_COMPILE=3Darm-none-eabi- > Cubieboard2_config > root@bsd:~/u-boot-2016.11 # make CROSS_COMPILE=3Darm-none-eabi- >=20 > - and used the u-boot-sunxi-with-spl.bin > ? > Do you have any insight? (at least for thr 4th method) >=20 > Thank you, > Mihai For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 import (well only ubldr.bin for me ...) For 3 and 4 I've never tested booting kernel directly, I'll try that. Does your kernel have a static dtb compiled in ? --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Dec 15 12:27:20 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5679C76AB4 for ; Thu, 15 Dec 2016 12:27:20 +0000 (UTC) (envelope-from alexnivan@gmail.com) Received: from mail-wj0-x242.google.com (mail-wj0-x242.google.com [IPv6:2a00:1450:400c:c01::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6BA41ACB for ; Thu, 15 Dec 2016 12:27:20 +0000 (UTC) (envelope-from alexnivan@gmail.com) Received: by mail-wj0-x242.google.com with SMTP id kp2so9523133wjc.0 for ; Thu, 15 Dec 2016 04:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IP5R1uUxjas9RvhjdrKmzPwMrImIZp3NLrVos1yuEMY=; b=jlpxp5M6X7xLB0w7yN0f228bNset1V4/HBmRZ9TqMbLq5L4NVwyZ1TC/NVTcn3dlAM wjT5uskhccKJt9d94g7dYBx9eUoFd1BZx7jeMLWgwDjjsp06mCDJ8oG8wjkwJaV01VEC yGI5MnFHAVDbOOT5TK9eM+bf94apBaM2IUFmU4WweFrrTPsbYmZMhL4RoSPyooHU5s/f vVV7NS3/sSCYQSkt4IuLAXN8y2CPvUW0PgN+EXueJq9KCeWKZ0Gl4mbo4siqT1ohi4Jq DoWySjiaIo/5tXXSTPiodlQe33p8vOupNpMvknKhlhRxeL75PDmt+vD6S967Y/XiXGW8 DT6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IP5R1uUxjas9RvhjdrKmzPwMrImIZp3NLrVos1yuEMY=; b=qQFwdO57PYQHMwBX5nuqaTRKUIHnMM+T7qbtRcI6JV/HFJ5fRZ/rL47EjI53RDvxBz oo5P1daUmK3JtJyB9Gqzg4NSTUPNrcpcCTtI9VZU/pDvYnCakNMA3B7PC2qnV8c/R+P2 47Y3nQHd+wGDvP6YpaU6KXR1xpsyMyamps3O2AOsKicCznf9Cq3VoxwoNaFw1zsvNULM ZC8Uu2qqaLQrd6DGKuvcJxFzna7vJnxFncw6Dw7owOROZTJ2gfKwLRsyn2ayxZ1CbXGW wJwe1qvuyFakLNX/kVEq5u9C8wK6FNHpz/8kyRzuuQwnLaYiVnLSzhfzJ6au8W4uTH5l AZoA== X-Gm-Message-State: AKaTC00aOP/zHstyWiH9Ehg1eSAqSgIUqzmp1StZAKFkI7kS/QAxhLR8e63YckPzURd8UPE+a0D282rf4XHatA== X-Received: by 10.194.203.5 with SMTP id km5mr1299989wjc.230.1481804838930; Thu, 15 Dec 2016 04:27:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.99.10 with HTTP; Thu, 15 Dec 2016 04:26:48 -0800 (PST) In-Reply-To: <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> From: Nicolae-Alexandru Ivan Date: Thu, 15 Dec 2016 14:26:48 +0200 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Emmanuel Vadot Cc: Mihai Carabas , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:27:20 -0000 > For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 import > (well only ubldr.bin for me ...) > For 3 and 4 I've never tested booting kernel directly, I'll try that. > Does your kernel have a static dtb compiled in ? Yes, we included the device tree in the kernel binary. The options below are included in our conf. #FDT options FDT options FDT_DTB_STATIC makeoptions FDT_DTS_FILE=cubieboard2.dts From owner-freebsd-arm@freebsd.org Thu Dec 15 12:35:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 86142C76FEF for ; Thu, 15 Dec 2016 12:35:09 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ED0101219 for ; Thu, 15 Dec 2016 12:35:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 9b4ed15b; Thu, 15 Dec 2016 13:35:06 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=Og8vmxpyf6c3N7CGGHFjOznPB1Y=; b=lzcjTbPxJO13Mm1jb8U2scwFNILE O7/0K0ubT8i9vjMpYJ6JqXv01uLABbZExTZLdrbzAToE8tXVCtyixFKZxzPjY8kO NqIVJWEf1ySKKIUrphxga9DhwdoLgsz/gATM59J2YiJKW1Z0srE8liAmREfSyyST 5BOp8YD9o9Z9Z6k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=ML7ie5xBlcKeTyicu7amaXbdxxQ7QqyiFAVNKgGr4LZILJd+I8MMC592 gHS+/+CTicN76cfL0Re85aaG5SaJs7Wlxhgmmv1QFHpPpULKCy4Yux9xNoNfzfo4 DDJLBo+xUhVGuOLzSYaPYiwgmQhdxy/Mhkod/iOVGXdn74AjaR4= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8122e44c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 15 Dec 2016 13:35:06 +0100 (CET) Date: Thu, 15 Dec 2016 13:35:05 +0100 From: Emmanuel Vadot To: Nicolae-Alexandru Ivan Cc: Mihai Carabas , freebsd-arm@freebsd.org Subject: Re: Cubieboard2 with custom bootloader Message-Id: <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> In-Reply-To: References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:35:09 -0000 On Thu, 15 Dec 2016 14:26:48 +0200 Nicolae-Alexandru Ivan wrote: > > For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 import > > (well only ubldr.bin for me ...) > > For 3 and 4 I've never tested booting kernel directly, I'll try that. > > Does your kernel have a static dtb compiled in ? > > Yes, we included the device tree in the kernel binary. > The options below are included in our conf. > > #FDT > options FDT > options FDT_DTB_STATIC > makeoptions FDT_DTS_FILE=cubieboard2.dts Oh I might now, my patches introduce a FreeBSD option for uboot that disable the dcache while it's strictly disable in the ports. Do a gmake menuconfig in uboot before compiling but after gmake cubieboard2_defconfig to enable this. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Dec 15 14:15:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 14521C81062 for ; Thu, 15 Dec 2016 14:15:29 +0000 (UTC) (envelope-from vivek@khera.org) Received: from mail-wj0-x232.google.com (mail-wj0-x232.google.com [IPv6:2a00:1450:400c:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AADE7C3F for ; Thu, 15 Dec 2016 14:15:28 +0000 (UTC) (envelope-from vivek@khera.org) Received: by mail-wj0-x232.google.com with SMTP id v7so66706877wjy.2 for ; Thu, 15 Dec 2016 06:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=khera.org; s=google11; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=HfZIx3tQFGX3cbttpnpKDBywjJedzv9uhGdeG6UTQ4g=; b=EXxGXgtcbw88I5i1NoqWI7rRQpKFMcYk3kCqV/lXyY1UrHnizZS/Fdk96Na/NoYomT J4Kz/P7znQNzKvyjlETTdAVQjeV0DZzwqjkR9Pt3NFdjkwWNwXIGmFFednVNKO14Alaw i5F2uDYYhwhlXkY1HyELJHCTv6qFUiptS1B08= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=HfZIx3tQFGX3cbttpnpKDBywjJedzv9uhGdeG6UTQ4g=; b=GeTHiixmr/hLHiBBxRLFqtglwCuX5lJ851asWHeE1L308DR4sxBQLfy60IKHfDkBUk yCy8gJuMSbN/FYPkq74woJeu1lay5FwFydknyfk0wSzVktlJVSTkZkA7LYcR7g0ADCax VAoegRHg/akra86xbWu4oyR8RG+OvOjDbqyXSSBsSrsG/F4dIgfaHkasxqN6ySUNLRqa Hg1kUx7OLdb4+8Dny/23avYPKDAxVvAEaP6UiRwQcL2lo6/jClY823ls8Dq+5XJd1R2Q A6ZLHUPQqJZMf0kBPb6OsTeclyPgUGUqkrQaAr3BP9o2PVoDWIZu7RNYQ05KeZuwz6Fn 4GfQ== X-Gm-Message-State: AKaTC03ddhykbzm5UJKaRZV4giR8/nuTSE6sPROQij7xtUCDC9HDRGf/09G086YDseXr9hrfAfPS/RVZYtGxpQ== X-Received: by 10.194.93.104 with SMTP id ct8mr1833386wjb.87.1481811326371; Thu, 15 Dec 2016 06:15:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.157.205 with HTTP; Thu, 15 Dec 2016 06:15:25 -0800 (PST) In-Reply-To: References: From: Vick Khera Date: Thu, 15 Dec 2016 09:15:25 -0500 Message-ID: Subject: Re: building m4 in poudriere cross-build To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 14:15:29 -0000 On Wed, Dec 14, 2016 at 9:55 AM, Mika=C3=ABl Urankar wrote: > > There are issues with the latest version of qemu-user-static (PR > #214944 #215071), try to use an older version. Brilliant! Replacing the current qemu-user-static with the one from http://pkg.freebsd.org/FreeBSD:11:amd64/quarterly/All/qemu-user-static-2.6.= 90.g20160728.txz allowed the build of m4 to complete in about 1.5 minutes, and the remaining ports I needed built quickly after that. Thanks for the tip! From owner-freebsd-arm@freebsd.org Thu Dec 15 14:16:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 835AAC8111B for ; Thu, 15 Dec 2016 14:16:56 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 40678D60; Thu, 15 Dec 2016 14:16:55 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id B0DBA2E2; Thu, 15 Dec 2016 09:16:54 -0500 (EST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: building m4 in poudriere cross-build From: Paul Mather In-Reply-To: <1481755164.1889.430.camel@freebsd.org> Date: Thu, 15 Dec 2016 09:16:54 -0500 Cc: Vick Khera , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A18CCF9-E84E-46C1-9575-720598C8580F@gromit.dlib.vt.edu> References: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> <1481752684.1889.425.camel@freebsd.org> <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> <1481755164.1889.430.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 14:16:56 -0000 On Dec 14, 2016, at 5:39 PM, Ian Lepore wrote: > On Wed, 2016-12-14 at 17:31 -0500, Paul Mather wrote: >> On Dec 14, 2016, at 4:58 PM, Ian Lepore wrote: >>=20 >>>=20 >>> On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote: >>>>=20 >>>> On Dec 14, 2016, at 9:42 AM, Vick Khera wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> I have a poudriere cross-building configuration set up on a >>>>> Xeon >>>>> running >>>>> FreebSD 11.0. The jail was set up with the "-x" option to use >>>>> the >>>>> native >>>>> cross-build tools. This has worked really well for a while, but >>>>> today I am >>>>> trying to update the packages for my raspberry pi 2, and >>>>> poudriere >>>>> just >>>>> kind of sits there in the configure step when building m4 (as a >>>>> dependency >>>>> trying to build subversion). I haven't built this set of >>>>> packages >>>>> in over a >>>>> month. >>>>>=20 >>>>> The logs show this: >>>>>=20 >>>>> checking for dirent.h... (cached) yes >>>>> checking for inttypes.h... (cached) yes >>>>> checking for working C stack overflow detection... make: >>>>> Working >>>>> in: >>>>> /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>> make: Working in: /usr/ports/devel/m4 >>>>>=20 >>>>> The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with >>>>> Poudriere >>>>> 3.1.14 >>>>>=20 >>>>> The build jail target is 11.0-RELEASE-p5/armv6 freshly updated. >>>>>=20 >>>>> I let this run for over 18 hours, and it just kept repeating >>>>> that >>>>> last >>>>> line. Has anyone had success with this set up recently? Maybe >>>>> the >>>>> qemu-arm-static is not working right now? >>>> I had (have) the same problem. Not only would packages like m4 >>>> just >>>> grind away for hours on end doing nothing until Poudriere timed >>>> out >>>> the build (after 24 hours), but other packages I use like >>>> math/gmp and net/norm would fail to build with various >>>> errors. I >>>> use Saltstack and so these kind of failures meant that >>>> sysutils/py- >>>> salt would be skipped for building, meaning it fell behind that >>>> of >>>> the other architectures I was running. >>>>=20 >>>> In the end, I decided to simply set up Poudriere on my >>>> FreeBSD/arm >>>> Raspberry Pi 2 system and build packages there instead. Running >>>> natively, all these packages build correctly and once again I am >>>> able >>>> to have up-to-date packages on my FreeBSD/arm systems. Package >>>> building isn't as fast as on my cross-build FreeBSD/amd64 system, >>>> but >>>> at least they actually build---slower is better than never. :-) >>>>=20 >>>> I can only assume that the QEMU arm emulator is deficient >>>> compared to >>>> an actual CPU on a running FreeBSD/arm system. If the official >>>> FreeBSD/arm package repository is built via a cross-built >>>> environment >>>> using QEMU, I presume these problems will linger until QEMU works >>>> properly. >>>>=20 >>>> I also assume that maybe the FreeBSD/arm package builders are >>>> consider these ports simply to be broken on FreeBSD/arm, which is >>>> why >>>> they fail to build under QEMU, when in fact the packages do >>>> actually >>>> build on an actual FreeBSD/arm system. At least that has been my >>>> experience for the last few months. >>>>=20 >>>> Cheers, >>>>=20 >>>> Paul. >>> I have successfully crossbuilt m4 using poudriere and qemu-static >>> on >>> freebsd 11, but I haven't tried in the past 6-8 months. Something >>> might have changed in the m4 port, like their configure script >>> might be >>> doing a stack overflow check now that it never used to do. I could >>> see >>> a stack overflow test taking a long time under qemu, but 24 hours >>> seems >>> a bit much. >>=20 >> The last time I was able successfully to cross-build m4 is on 2016- >> 11-06. Since then, I think it has failed to get past the configure >> stage and Poudriere times out. >>=20 >> As you surmise, the last thing it does in the configure script is >> check for stack overflow: >>=20 >> =3D=3D=3D=3D=3D >> [[...]] >> checking for features.h... no >> checking for wctype.h... (cached) yes >> checking for dirent.h... (cached) yes >> checking for inttypes.h... (cached) yes >> checking for working C stack overflow detection... >> =3D=3D=3D=3D=3D >>=20 >> It gets hung up on that until Poudriere times out or you CTRL-C the >> build job. >>=20 >> The m4 package is just one example. In the past they have built and >> then something happens and then they don't (math/gmp is another >> example like this). Some (like net/norm) I don't recall ever having >> managed to cross-build. >>=20 >> I was very surprised when I moved the FreeBSD/arm Poudriere building >> to an actual Raspberry Pi and everything built fine first time. I >> don't build many packages for my FreeBSD/arm systems, so it doesn't >> actually take too long for me (building the jail takes longer:). >>=20 >> Cheers, >>=20 >> Paul. >=20 > Hmm, looks like nothing has changed in the m4 port for at least 8 > months. What has changed since November 6 is clang. >=20 > There are many ports that fail to compile on arm that need only a tiny > change to start working (for either native or cross-compile). It > doesn't take long to figure out the fixes, but it's virtually > impossible to get the fixes committed. The ports maintainers often > don't know anything about arm or other platforms and are reluctant to > commit changes they don't understand and can't test. That is true, but in the case of the example ports mentioned above they = don't fail to compile on arm---they just fail to compile on arm via the = QEMU arm emulator. That suggests to me that it's not so much that = certain ports are broken but that maybe clang is generating code that = the QEMU emulator chokes on whereas a real arm processor that FreeBSD = supports is fine. It seems to me that it is the QEMU emulator that may need fixing, not = individual ports. Cheers, Paul. From owner-freebsd-arm@freebsd.org Thu Dec 15 14:51:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A79C8C81E2D for ; Thu, 15 Dec 2016 14:51:01 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: from mail-yb0-f193.google.com (mail-yb0-f193.google.com [209.85.213.193]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67C49159 for ; Thu, 15 Dec 2016 14:51:00 +0000 (UTC) (envelope-from byond.lenox@gmail.com) Received: by mail-yb0-f193.google.com with SMTP id v78so3743998ybe.0 for ; Thu, 15 Dec 2016 06:51:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=06K2Kw9zd1eXsrBQxftJcgysdguunZDENJMLXDUm56Q=; b=Ko4yLDJPTbFkGBAwWyK0U/P43yT6IpcApZOqkuZj8R+hZEGqJxD6Nlz1zUcgIQg78r UmxvEw9/44Ka2jW0rhpFamt171zdYBVqNQ8Y+bOjy/cXJ2ROGc4yEkPRFveEWMDRzCbR AzEUB/ZGoRYce3ekiXfOFHb2F/TdloKTFgcKE8Zr10/patkuX+4NHFRcsWoVGsCK5vY0 rWIwRs1fZiY/N5DSOKKmYOpQqjyK/Xq1ix+Ee17czOY/IkNfM8+rq1o3rV3F6nyjd7Xo 8TFryW6kEkN6VDjF25WpTwUNQv8cNwaS8C9vMVfDHRAnELEktzydWE9jv4puXXaXNpVc pDEg== X-Gm-Message-State: AIkVDXKCBNkVGqn+q6qVJ+Pml7uzUQxbQeZOiLr5NxihzbzEvR/LEAo4Cp0oPssL8Eyypw== X-Received: by 10.37.111.84 with SMTP id k81mr1314790ybc.141.1481812622451; Thu, 15 Dec 2016 06:37:02 -0800 (PST) Received: from mail-yw0-f172.google.com (mail-yw0-f172.google.com. [209.85.161.172]) by smtp.gmail.com with ESMTPSA id a143sm630494ywe.40.2016.12.15.06.37.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Dec 2016 06:37:02 -0800 (PST) Received: by mail-yw0-f172.google.com with SMTP id a10so14645719ywa.3 for ; Thu, 15 Dec 2016 06:37:02 -0800 (PST) X-Received: by 10.129.78.205 with SMTP id c196mr1405125ywb.63.1481812622013; Thu, 15 Dec 2016 06:37:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.55.194 with HTTP; Thu, 15 Dec 2016 06:36:41 -0800 (PST) In-Reply-To: References: <20161211034602.3fylwnxfbgl4ehgx@hal9000.meka.no-ip.org> <1752cc8d-fad7-141d-4950-37bb5dde9561@passap.ru> <20161215111151.geyecaxakyn6feau@hal9000.meka.no-ip.org> From: Kyle Evans Date: Thu, 15 Dec 2016 08:36:41 -0600 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Arduino Due To: =?UTF-8?B?R29yYW4gTWVracSH?= Cc: Boris Samorodov , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 14:51:01 -0000 On Thu, Dec 15, 2016 at 5:11 AM, Goran Meki=C4=87 wrote= : > Hello, > > So I did a little checks and I think it's the cross compiling that's faul= ty. I generated blink led .bin file on Linux and FreeBSD. I can flash any o= f them from FreeBSD using bossac, and Linux .bin file works, FreeBSD one do= esn't (the led is always lit). I checked the commands Arduino IDE is using = on Linux and FreeBSD, and they are the same. I tried this with arm-none-eab= i-gcc versions 4.9, 5.3 and 6.2. As all those versions are failing, maybe i= t's not GCC but binutils or something like that (just a wild guess). I woul= d be really grateful if someone could tell me how to pinpoint the error eve= n more. Thank you! > > Just for reference, on Arduino Due the MCU is Cortex M3. > > Regards, > meka Hi, That's interesting. I was able to successfully program my Due's with FreeBSD-compiled projects a couple of times -- generally simple ones that just connected and tested the serial plotter/monitor. However, we do differ from upstream a bit in that upstream seems to be sticking to arm-none-eabi-gcc 4.8.3 -- I kind of wonder if we're missing some flags in compilation/linking, but that wouldn't really explain why my simple tests worked out. =3D( From owner-freebsd-arm@freebsd.org Thu Dec 15 16:03:17 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 380BFC8188C for ; Thu, 15 Dec 2016 16:03:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 1ACA4181D for ; Thu, 15 Dec 2016 16:03:16 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f588be20-c2df-11e6-9ec7-5d8fa496b077 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id f588be20-c2df-11e6-9ec7-5d8fa496b077; Thu, 15 Dec 2016 16:03:04 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBFG3DAC001357; Thu, 15 Dec 2016 09:03:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481817793.1972.2.camel@freebsd.org> Subject: Re: Cubieboard2 with custom bootloader From: Ian Lepore To: Emmanuel Vadot , Nicolae-Alexandru Ivan Cc: freebsd-arm@freebsd.org Date: Thu, 15 Dec 2016 09:03:13 -0700 In-Reply-To: <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:03:17 -0000 On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: > On Thu, 15 Dec 2016 14:26:48 +0200 > Nicolae-Alexandru Ivan wrote: > > > > > > > > >  For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 > > > import > > > (well only ubldr.bin for me ...) > > >  For 3 and 4 I've never tested booting kernel directly, I'll try > > > that. > > >  Does your kernel have a static dtb compiled in ? > > Yes, we included the device tree in the kernel binary. > > The options below are included in our conf. > > > > #FDT > > options FDT > > options FDT_DTB_STATIC > > makeoptions FDT_DTS_FILE=cubieboard2.dts >  Oh I might now, my patches introduce a FreeBSD option for uboot that > disable the dcache while it's strictly disable in the ports. >  Do a gmake menuconfig in uboot before compiling but after gmake > cubieboard2_defconfig to enable this. > It shouldn't be necessary to disable dcache, but it does need to be flushed before launching ubldr or the kernel; especially, it needs the icache sync'd.  The stock uboot does the needed cache work only in the path that launches linux that has been packaged as an image file (and before launching vxworks I think).  For freebsd the needed cache ops must be patched into two places, the bootelf path and the go path. -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 15 16:07:27 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B8FBC81A9A for ; Thu, 15 Dec 2016 16:07:27 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 4EB7D1B22 for ; Thu, 15 Dec 2016 16:07:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9a65cf65-c2e0-11e6-9f67-d3961ed5a660 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 9a65cf65-c2e0-11e6-9f67-d3961ed5a660; Thu, 15 Dec 2016 16:07:40 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBFG7O9D001370; Thu, 15 Dec 2016 09:07:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481818044.1972.6.camel@freebsd.org> Subject: Re: building m4 in poudriere cross-build From: Ian Lepore To: Paul Mather Cc: Vick Khera , freebsd-arm@freebsd.org Date: Thu, 15 Dec 2016 09:07:24 -0700 In-Reply-To: <5A18CCF9-E84E-46C1-9575-720598C8580F@gromit.dlib.vt.edu> References: <706A6D47-21F3-4017-8CD4-C651F37900E6@gromit.dlib.vt.edu> <1481752684.1889.425.camel@freebsd.org> <144A0FFB-730E-42C4-8FE6-7387505145A0@gromit.dlib.vt.edu> <1481755164.1889.430.camel@freebsd.org> <5A18CCF9-E84E-46C1-9575-720598C8580F@gromit.dlib.vt.edu> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 16:07:27 -0000 On Thu, 2016-12-15 at 09:16 -0500, Paul Mather wrote: > On Dec 14, 2016, at 5:39 PM, Ian Lepore wrote: > > > > > On Wed, 2016-12-14 at 17:31 -0500, Paul Mather wrote: > > > > > > On Dec 14, 2016, at 4:58 PM, Ian Lepore wrote: > > > > > > > > > > > > > > > On Wed, 2016-12-14 at 10:01 -0500, Paul Mather wrote: > > > > > > > > > > > > > > > On Dec 14, 2016, at 9:42 AM, Vick Khera > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I have a poudriere cross-building configuration set up on a > > > > > > Xeon > > > > > > running > > > > > > FreebSD 11.0. The jail was set up with the "-x" option to > > > > > > use > > > > > > the > > > > > > native > > > > > > cross-build tools. This has worked really well for a while, > > > > > > but > > > > > > today I am > > > > > > trying to update the packages for my raspberry pi 2, and > > > > > > poudriere > > > > > > just > > > > > > kind of sits there in the configure step when building m4 > > > > > > (as a > > > > > > dependency > > > > > > trying to build subversion). I haven't built this set of > > > > > > packages > > > > > > in over a > > > > > > month. > > > > > > > > > > > > The logs show this: > > > > > > > > > > > > checking for dirent.h... (cached) yes > > > > > > checking for inttypes.h... (cached) yes > > > > > > checking for working C stack overflow detection... make: > > > > > > Working > > > > > > in: > > > > > > /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > make: Working in: /usr/ports/devel/m4 > > > > > > > > > > > > The build machine is: FreeBSD 11.0-RELEASE-p5/amd64 with > > > > > > Poudriere > > > > > > 3.1.14 > > > > > > > > > > > > The build jail target is 11.0-RELEASE-p5/armv6 freshly > > > > > > updated. > > > > > > > > > > > > I let this run for over 18 hours, and it just kept > > > > > > repeating > > > > > > that > > > > > > last > > > > > > line. Has anyone had success with this set up recently? > > > > > > Maybe > > > > > > the > > > > > > qemu-arm-static is not working right now? > > > > > I had (have) the same problem.  Not only would packages like > > > > > m4 > > > > > just > > > > > grind away for hours on end doing nothing until Poudriere > > > > > timed > > > > > out > > > > > the build (after 24 hours), but other packages I use like > > > > > math/gmp  and net/norm would fail to build with various > > > > > errors.  I > > > > > use Saltstack and so these kind of failures meant that > > > > > sysutils/py- > > > > > salt would be skipped for building, meaning it fell behind > > > > > that > > > > > of > > > > > the other architectures I was running. > > > > > > > > > > In the end, I decided to simply set up Poudriere on my > > > > > FreeBSD/arm > > > > > Raspberry Pi 2 system and build packages there > > > > > instead.  Running > > > > > natively, all these packages build correctly and once again I > > > > > am > > > > > able > > > > > to have up-to-date packages on my FreeBSD/arm > > > > > systems.  Package > > > > > building isn't as fast as on my cross-build FreeBSD/amd64 > > > > > system, > > > > > but > > > > > at least they actually build---slower is better than never. > > > > > :-) > > > > > > > > > > I can only assume that the QEMU arm emulator is deficient > > > > > compared to > > > > > an actual CPU on a running FreeBSD/arm system.  If the > > > > > official > > > > > FreeBSD/arm package repository is built via a cross-built > > > > > environment > > > > > using QEMU, I presume these problems will linger until QEMU > > > > > works > > > > > properly. > > > > > > > > > > I also assume that maybe the FreeBSD/arm package builders are > > > > > consider these ports simply to be broken on FreeBSD/arm, > > > > > which is > > > > > why > > > > > they fail to build under QEMU, when in fact the packages do > > > > > actually > > > > > build on an actual FreeBSD/arm system.  At least that has > > > > > been my > > > > > experience for the last few months. > > > > > > > > > > Cheers, > > > > > > > > > > Paul. > > > > I have successfully crossbuilt m4 using poudriere and qemu- > > > > static > > > > on > > > > freebsd 11, but I haven't tried in the past 6-8 > > > > months.  Something > > > > might have changed in the m4 port, like their configure script > > > > might be > > > > doing a stack overflow check now that it never used to do.  I > > > > could > > > > see > > > > a stack overflow test taking a long time under qemu, but 24 > > > > hours > > > > seems > > > > a bit much. > > > The last time I was able successfully to cross-build m4 is on > > > 2016- > > > 11-06.  Since then, I think it has failed to get past the > > > configure > > > stage and Poudriere times out. > > > > > > As you surmise, the last thing it does in the configure script is > > > check for stack overflow: > > > > > > ===== > > > [[...]] > > > checking for features.h... no > > > checking for wctype.h... (cached) yes > > > checking for dirent.h... (cached) yes > > > checking for inttypes.h... (cached) yes > > > checking for working C stack overflow detection... > > > ===== > > > > > > It gets hung up on that until Poudriere times out or you CTRL-C > > > the > > > build job. > > > > > > The m4 package is just one example.  In the past they have built > > > and > > > then something happens and then they don't (math/gmp is another > > > example like this).  Some (like net/norm) I don't recall ever > > > having > > > managed to cross-build. > > > > > > I was very surprised when I moved the FreeBSD/arm Poudriere > > > building > > > to an actual Raspberry Pi and everything built fine first > > > time.  I > > > don't build many packages for my FreeBSD/arm systems, so it > > > doesn't > > > actually take too long for me (building the jail takes longer:). > > > > > > Cheers, > > > > > > Paul. > > Hmm, looks like nothing has changed in the m4 port for at least 8 > > months.  What has changed since November 6 is clang. > > > > There are many ports that fail to compile on arm that need only a > > tiny > > change to start working (for either native or cross-compile).  It > > doesn't take long to figure out the fixes, but it's virtually > > impossible to get the fixes committed.  The ports maintainers often > > don't know anything about arm or other platforms and are reluctant > > to > > commit changes they don't understand and can't test. > > That is true, but in the case of the example ports mentioned above > they don't fail to compile on arm---they just fail to compile on arm > via the QEMU arm emulator.  That suggests to me that it's not so much > that certain ports are broken but that maybe clang is generating code > that the QEMU emulator chokes on whereas a real arm processor that > FreeBSD supports is fine. > > It seems to me that it is the QEMU emulator that may need fixing, not > individual ports. > > Cheers, It sounds like that's true (qemu is broken) in this case, but in general there are many ports that fail to build or crossbuild on arm that need only small changes to work. On the other hand, there are some that will never work right because we've made some bad choices, such as claiming that armv6 and armv7 are basically the same thing.  The ports contain #ifdef stuff that makes assumptions like "armv6 can never be multicore so I don't need to do memory barrier operations". -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 15 17:13:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73D84C81465 for ; Thu, 15 Dec 2016 17:13:10 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 67A57FF0; Thu, 15 Dec 2016 17:13:10 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 4D44D2E3; Thu, 15 Dec 2016 17:13:10 +0000 (UTC) Date: Thu, 15 Dec 2016 17:13:08 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: manu@FreeBSD.org, ed@FreeBSD.org, emaste@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <475248174.98.1481821990324.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #4379 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 17:13:10 -0000 FreeBSD_HEAD_arm64 - Build #4379 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/4379/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/4379/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/4379/console Change summaries: 310117 by manu: Add information about interrupts in the Allwinner padconf files and correct some pin numbering. While here switch to my freebsd mail address in the copyright. MFC after: 3 days 310116 by ed: Document the existence of the {0, 6, ...} sysctl. 310114 by emaste: newvers.sh: correct typo in comment Submitted by: lidl The end of the build log: [...truncated 183846 lines...] cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_map.o -MTvm_map.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_map.c --- uma_core.o --- ctfconvert -L VERSION -g uma_core.o --- vm_meter.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_meter.o -MTvm_meter.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_meter.c --- vm_kern.o --- ctfconvert -L VERSION -g vm_kern.o --- vm_mmap.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_mmap.o -MTvm_mmap.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_mmap.c --- vm_meter.o --- ctfconvert -L VERSION -g vm_meter.o --- vm_object.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_object.o -MTvm_object.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_object.c --- vm_mmap.o --- ctfconvert -L VERSION -g vm_mmap.o --- vm_page.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_page.o -MTvm_page.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_page.c --- vm_object.o --- ctfconvert -L VERSION -g vm_object.o --- vm_pageout.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_pageout.o -MTvm_pageout.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_pageout.c --- ffs_softdep.o --- ctfconvert -L VERSION -g ffs_softdep.o --- vm_pager.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_pager.o -MTvm_pager.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_pager.c --- vm_map.o --- ctfconvert -L VERSION -g vm_map.o --- vm_phys.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_phys.o -MTvm_phys.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_phys.c /usr/src/sys/vm/vm_phys.c:274:1: warning: unused function 'vm_rr_selectdomain' [-Wunused-function] vm_rr_selectdomain(void) ^ --- vm_pager.o --- ctfconvert -L VERSION -g vm_pager.o --- vm_radix.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_radix.o -MTvm_radix.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_radix.c ctfconvert -L VERSION -g vm_radix.o --- vm_reserv.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_reserv.o -MTvm_reserv.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_reserv.c --- vm_page.o --- ctfconvert -L VERSION -g vm_page.o --- vm_domain.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_domain.o -MTvm_domain.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_domain.c --- vm_pageout.o --- ctfconvert -L VERSION -g vm_pageout.o --- vm_domain.o --- ctfconvert -L VERSION -g vm_domain.o --- vm_unix.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vm_unix.o -MTvm_unix.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vm_unix.c --- vnode_pager.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.vnode_pager.o -MTvnode_pager.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/vm/vnode_pager.c --- vm_reserv.o --- ctfconvert -L VERSION -g vm_reserv.o --- xdr.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.xdr.o -MTxdr.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/xdr/xdr.c --- vm_phys.o --- 1 warning generated. ctfconvert -L VERSION -g vm_phys.o --- xdr_array.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.xdr_array.o -MTxdr_array.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/xdr/xdr_array.c --- vm_unix.o --- ctfconvert -L VERSION -g vm_unix.o --- xdr_mbuf.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.xdr_mbuf.o -MTxdr_mbuf.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/xdr/xdr_mbuf.c --- xdr_array.o --- ctfconvert -L VERSION -g xdr_array.o --- xdr_mem.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.xdr_mem.o -MTxdr_mem.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/xdr/xdr_mem.c ctfconvert -L VERSION -g xdr_mem.o --- xdr_reference.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.xdr_reference.o -MTxdr_reference.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/xdr/xdr_reference.c --- xdr.o --- ctfconvert -L VERSION -g xdr.o --- xdr_sizeof.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.xdr_sizeof.o -MTxdr_sizeof.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/xdr/xdr_sizeof.c --- xdr_reference.o --- ctfconvert -L VERSION -g xdr_reference.o --- a10_ehci.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.a10_ehci.o -MTa10_ehci.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm/allwinner/a10_ehci.c --- xdr_mbuf.o --- ctfconvert -L VERSION -g xdr_mbuf.o --- a10_gpio.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.a10_gpio.o -MTa10_gpio.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm/allwinner/a10_gpio.c --- xdr_sizeof.o --- ctfconvert -L VERSION -g xdr_sizeof.o --- a10_mmc.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.a10_mmc.o -MTa10_mmc.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm/allwinner/a10_mmc.c --- a10_ehci.o --- ctfconvert -L VERSION -g a10_ehci.o --- a64_padconf.o --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/arm64.aarch64/usr/src/tmp -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD -MF.depend.a64_padconf.o -MTa64_padconf.o -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/arm/allwinner/a64/a64_padconf.c /usr/src/sys/arm/allwinner/a64/a64_padconf.c:44:87: error: expected '}' { "PB0", 1, 0, { "gpio_in", "gpio_out", "uart2", NULL, "jtag", NULL, "pb_eint0" } 6, 0}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:44:2: note: to match this '{' { "PB0", 1, 0, { "gpio_in", "gpio_out", "uart2", NULL, "jtag", NULL, "pb_eint0" } 6, 0}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:45:88: error: expected '}' { "PB1", 1, 1, { "gpio_in", "gpio_out", "uart2", NULL, "jtag", "sim", "pb_eint1" } 6, 1}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:45:2: note: to match this '{' { "PB1", 1, 1, { "gpio_in", "gpio_out", "uart2", NULL, "jtag", "sim", "pb_eint1" } 6, 1}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:46:88: error: expected '}' { "PB2", 1, 2, { "gpio_in", "gpio_out", "uart2", NULL, "jtag", "sim", "pb_eint2" } 6, 2}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:46:2: note: to match this '{' { "PB2", 1, 2, { "gpio_in", "gpio_out", "uart2", NULL, "jtag", "sim", "pb_eint2" } 6, 2}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:47:90: error: expected '}' { "PB3", 1, 3, { "gpio_in", "gpio_out", "uart2", "i2s0", "jtag", "sim", "pb_eint3" } 6, 3}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:47:2: note: to match this '{' { "PB3", 1, 3, { "gpio_in", "gpio_out", "uart2", "i2s0", "jtag", "sim", "pb_eint3" } 6, 3}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:48:87: error: expected '}' { "PB4", 1, 4, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint4" } 6, 4}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:48:2: note: to match this '{' { "PB4", 1, 4, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint4" } 6, 4}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:49:87: error: expected '}' { "PB5", 1, 5, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint5" } 6, 5}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:49:2: note: to match this '{' { "PB5", 1, 5, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint5" } 6, 5}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:50:87: error: expected '}' { "PB6", 1, 6, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint6" } 6, 6}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:50:2: note: to match this '{' { "PB6", 1, 6, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint6" } 6, 6}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:51:87: error: expected '}' { "PB7", 1, 7, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint7" } 6, 7}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:51:2: note: to match this '{' { "PB7", 1, 7, { "gpio_in", "gpio_out", "aif2", "pcm0", NULL, "sim", "pb_eint7" } 6, 7}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:52:85: error: expected '}' { "PB8", 1, 8, { "gpio_in", "gpio_out", NULL, NULL, "uart0", NULL, "pb_eint8" } 6, 8}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:52:2: note: to match this '{' { "PB8", 1, 8, { "gpio_in", "gpio_out", NULL, NULL, "uart0", NULL, "pb_eint8" } 6, 8}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:53:85: error: expected '}' { "PB9", 1, 9, { "gpio_in", "gpio_out", NULL, NULL, "uart0", NULL, "pb_eint9" } 6, 9}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:53:2: note: to match this '{' { "PB9", 1, 9, { "gpio_in", "gpio_out", NULL, NULL, "uart0", NULL, "pb_eint9" } 6, 9}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:126:84: error: expected '}' { "PG0", 6, 0, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint0" } 6, 0}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:126:2: note: to match this '{' { "PG0", 6, 0, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint0" } 6, 0}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:127:84: error: expected '}' { "PG1", 6, 1, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint1" } 6, 1}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:127:2: note: to match this '{' { "PG1", 6, 1, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint1" } 6, 1}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:128:84: error: expected '}' { "PG2", 6, 2, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint2" } 6, 2}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:128:2: note: to match this '{' { "PG2", 6, 2, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint2" } 6, 2}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:129:84: error: expected '}' { "PG3", 6, 3, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint3" } 6, 3}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:129:2: note: to match this '{' { "PG3", 6, 3, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint3" } 6, 3}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:130:84: error: expected '}' { "PG4", 6, 4, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint4" } 6, 4}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:130:2: note: to match this '{' { "PG4", 6, 4, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint4" } 6, 4}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:131:84: error: expected '}' { "PG5", 6, 5, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint5" } 6, 5}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:131:2: note: to match this '{' { "PG5", 6, 5, { "gpio_in", "gpio_out", "mmc1", NULL, NULL, NULL, "pg_eint5" } 6, 5}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:132:85: error: expected '}' { "PG6", 6, 6, { "gpio_in", "gpio_out", "uart1", NULL, NULL, NULL, "pg_eint6" } 6, 6}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:132:2: note: to match this '{' { "PG6", 6, 6, { "gpio_in", "gpio_out", "uart1", NULL, NULL, NULL, "pg_eint6" } 6, 6}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:133:85: error: expected '}' { "PG7", 6, 7, { "gpio_in", "gpio_out", "uart1", NULL, NULL, NULL, "pg_eint7" } 6, 7}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:133:2: note: to match this '{' { "PG7", 6, 7, { "gpio_in", "gpio_out", "uart1", NULL, NULL, NULL, "pg_eint7" } 6, 7}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:134:85: error: expected '}' { "PG8", 6, 8, { "gpio_in", "gpio_out", "uart1", NULL, NULL, NULL, "pg_eint8" } 6, 8}, ^ /usr/src/sys/arm/allwinner/a64/a64_padconf.c:134:2: note: to match this '{' { "PG8", 6, 8, { "gpio_in", "gpio_out", "uart1", NULL, NULL, NULL, "pg_eint8" } 6, 8}, ^ fatal error: too many errors emitted, stopping now [-ferror-limit=] 20 errors generated. *** [a64_padconf.o] Error code 1 bmake[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC --- vnode_pager.o --- ctfconvert -L VERSION -g vnode_pager.o --- a10_gpio.o --- ctfconvert -L VERSION -g a10_gpio.o --- a10_mmc.o --- ctfconvert -L VERSION -g a10_mmc.o 1 error bmake[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC *** [buildkernel] Error code 2 bmake[1]: stopped in /usr/src 1 error bmake[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [WARNINGS] Skipping publisher since build result is FAILURE [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson7846417062909795390.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::101:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Thu Dec 15 18:48:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B602C81E3A for ; Thu, 15 Dec 2016 18:48:51 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DC3851519; Thu, 15 Dec 2016 18:48:50 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id c14c2f5f; Thu, 15 Dec 2016 19:48:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=wpZ7n36XWEreR/Fp/E7twgXtYdU=; b=sPE+fP3g8b4AuDTsIBlFqrlOeSFr akzWH1nMlXZ+5OdBUe1cbYbNOOQQW4UeLHBeSB/UtHfNgYhdyAo7vL4MnMZnIb0k UBZhRz+iNPv1AjSLheVgvYdAXu1sKgl8uQulrqs1kUTiXdEY7NSXXQHWYEeko6Xr 6KfOrRl08W01G6o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=DdI0YJ/aqecSQpIhQGzQFiXYOxUbslZrffUpg+R7c8lctZ6vgxSEc7MK Ovgq9a16LOGTrteJZWZgBhTzFqSLa7Eo2rkTOdNeckk2eCpXG54Wuqbv/sIjQ/hW kfQmXUwSzH0CCLoXFUC3AAEIvDXV+lc5yIG5DG8QD+/cSHPirP0= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id fdaa15d8 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 15 Dec 2016 19:48:47 +0100 (CET) Date: Thu, 15 Dec 2016 19:48:47 +0100 From: Emmanuel Vadot To: Ian Lepore Cc: Nicolae-Alexandru Ivan , freebsd-arm@freebsd.org Subject: Re: Cubieboard2 with custom bootloader Message-Id: <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> In-Reply-To: <1481817793.1972.2.camel@freebsd.org> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 18:48:51 -0000 On Thu, 15 Dec 2016 09:03:13 -0700 Ian Lepore wrote: > On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: > > On Thu, 15 Dec 2016 14:26:48 +0200 > > Nicolae-Alexandru Ivan wrote: > >=20 > > >=20 > > > >=20 > > > > =A0For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 > > > > import > > > > (well only ubldr.bin for me ...) > > > > =A0For 3 and 4 I've never tested booting kernel directly, I'll try > > > > that. > > > > =A0Does your kernel have a static dtb compiled in ? > > > Yes, we included the device tree in the kernel binary. > > > The options below are included in our conf. > > >=20 > > > #FDT > > > options FDT > > > options FDT_DTB_STATIC > > > makeoptions FDT_DTS_FILE=3Dcubieboard2.dts > > =A0Oh I might now, my patches introduce a FreeBSD option for uboot that > > disable the dcache while it's strictly disable in the ports. > > =A0Do a gmake menuconfig in uboot before compiling but after gmake > > cubieboard2_defconfig to enable this. > >=20 >=20 > It shouldn't be necessary to disable dcache, but it does need to be > flushed before launching ubldr or the kernel; especially, it needs the > icache sync'd. =A0The stock uboot does the needed cache work only in the > path that launches linux that has been packaged as an image file (and > before launching vxworks I think). =A0For freebsd the needed cache ops > must be patched into two places, the bootelf path and the go path. >=20 > -- Ian Well the dcache has been strictly disabled in most of our port for quite some times now. I'll run some test so see if it's still needed and update the port if it's not. And it raise a question: Why couldn't we flush the dcache at the start of ubldr for arm if it's needed ? I'm gonna try to upstream by "FreeBSD config" v2 patches soon so I want to do it right. --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Dec 15 19:52:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9742BC81011 for ; Thu, 15 Dec 2016 19:52:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 8ABE21C59; Thu, 15 Dec 2016 19:52:16 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 899FE2E7; Thu, 15 Dec 2016 19:52:16 +0000 (UTC) Date: Thu, 15 Dec 2016 19:52:15 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: andrew@FreeBSD.org, manu@FreeBSD.org, asomers@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <377736475.100.1481831536569.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <475248174.98.1481821990324.JavaMail.jenkins@jenkins-9.freebsd.org> References: <475248174.98.1481821990324.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #4380 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 19:52:16 -0000 FreeBSD_HEAD_arm64 - Build #4380 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/4380/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/4380/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/4380/console Change summaries: 310124 by andrew: Add -fPIC to the ubldr build. Without this the self relocation code will try to use an absolute address in a switch statement, jumping to an invalid memory location. Sponsored by: ABT Systems Ltd 310122 by manu: Fix building arm64 kernel after r310117 Pointy hat: me MFC after: 3 days 310118 by asomers: Fix ls_tests:o_flag with ZFS TMPDIR Unlike UFS or TMPFS, ZFS sets uarch automatically whenever a file is updated. The test must explicitly clear uarch to be portable across filesystems. Also, it doesn't need to run as root. PR: 215179 MFC after: 4 weeks Sponsored by: Spectra Logic Corp Differential Revision: https://reviews.freebsd.org/D8741 From owner-freebsd-arm@freebsd.org Thu Dec 15 19:53:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38A04C810D6 for ; Thu, 15 Dec 2016 19:53:51 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 C7E0F1DE7 for ; Thu, 15 Dec 2016 19:53:50 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 32b71eb2-c300-11e6-9673-39b5816e8152 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 32b71eb2-c300-11e6-9673-39b5816e8152; Thu, 15 Dec 2016 19:53:51 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBFJrhql001697; Thu, 15 Dec 2016 12:53:43 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481831623.1972.24.camel@freebsd.org> Subject: Re: Cubieboard2 with custom bootloader From: Ian Lepore To: Emmanuel Vadot Cc: Nicolae-Alexandru Ivan , freebsd-arm@freebsd.org Date: Thu, 15 Dec 2016 12:53:43 -0700 In-Reply-To: <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 19:53:51 -0000 On Thu, 2016-12-15 at 19:48 +0100, Emmanuel Vadot wrote: > On Thu, 15 Dec 2016 09:03:13 -0700 > Ian Lepore wrote: > > > > > On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: > > > > > > On Thu, 15 Dec 2016 14:26:48 +0200 > > > Nicolae-Alexandru Ivan wrote: > > > > > > > > > > > > > > > > > > > > > > > > > >  For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 > > > > > import > > > > > (well only ubldr.bin for me ...) > > > > >  For 3 and 4 I've never tested booting kernel directly, I'll > > > > > try > > > > > that. > > > > >  Does your kernel have a static dtb compiled in ? > > > > Yes, we included the device tree in the kernel binary. > > > > The options below are included in our conf. > > > > > > > > #FDT > > > > options FDT > > > > options FDT_DTB_STATIC > > > > makeoptions FDT_DTS_FILE=cubieboard2.dts > > >  Oh I might now, my patches introduce a FreeBSD option for uboot > > > that > > > disable the dcache while it's strictly disable in the ports. > > >  Do a gmake menuconfig in uboot before compiling but after gmake > > > cubieboard2_defconfig to enable this. > > > > > It shouldn't be necessary to disable dcache, but it does need to be > > flushed before launching ubldr or the kernel; especially, it needs > > the > > icache sync'd.  The stock uboot does the needed cache work only in > > the > > path that launches linux that has been packaged as an image file > > (and > > before launching vxworks I think).  For freebsd the needed cache > > ops > > must be patched into two places, the bootelf path and the go path. > > > > -- Ian >  Well the dcache has been strictly disabled in most of our port for > quite some times now. >  I'll run some test so see if it's still needed and update the port > if > it's not. >  And it raise a question: Why couldn't we flush the dcache at the > start > of ubldr for arm if it's needed ? >  I'm gonna try to upstream by "FreeBSD config" v2 patches soon so I > want to do it right. > Dcache has been enabled in the uboot ports I was taking care of for a long time; any of those ports have the needed patches for cache maintenance before launching ubldr or the kernel.  See for example u- boot-rpi, the patches for cmd_boot and cmd_elf. The cache maintenance must be done *before* jumping to the ubldr or kernel entry point, or else it's possible to jump to bad code (stale cached data) that hangs or crashes. -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 15 20:01:20 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C05D8C813ED for ; Thu, 15 Dec 2016 20:01:20 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1444A6AE; Thu, 15 Dec 2016 20:01:19 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 45932436; Thu, 15 Dec 2016 21:01:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=s/ek+KaPnJVt7OuZljE+4hPJnU4=; b=YRRiyPpVS4Yn1brCaevCLM8+Dxzu qZVf9fc/TdAEWg4BiHOxHOFxlt3BPhIH3FPiWZ8Y1crmWYhv4/U0Amu1cTqAeggm Au08bOf/6jB1C25cl5WGcN5qOPnhzQsUwbMSBneqBuU7E/13SCoQci894R2894Ou CmzMOg+jznjlJ/Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=gXSOTP0Jk7q9B/Hmuui5ZIrj0BOiBvEZkrm4ANYQocdr1I4G8ghzPJ76 zxUdNliA0smHKRJFuIGyQ6Oxtl71lY6fjE/+shusyEoTY35rFRsVc0OlUYwr69Eq rUhIqrg5d+oo434sQRSimFQ//srp7VMeDqoxUiNHV8l7Cm8BZ/8= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8cf5fe47 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 15 Dec 2016 21:01:16 +0100 (CET) Date: Thu, 15 Dec 2016 21:01:15 +0100 From: Emmanuel Vadot To: Ian Lepore Cc: Nicolae-Alexandru Ivan , freebsd-arm@freebsd.org Subject: Re: Cubieboard2 with custom bootloader Message-Id: <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> In-Reply-To: <1481831623.1972.24.camel@freebsd.org> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> <1481831623.1972.24.camel@freebsd.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:01:20 -0000 On Thu, 15 Dec 2016 12:53:43 -0700 Ian Lepore wrote: > On Thu, 2016-12-15 at 19:48 +0100, Emmanuel Vadot wrote: > > On Thu, 15 Dec 2016 09:03:13 -0700 > > Ian Lepore wrote: > >=20 > > >=20 > > > On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: > > > >=20 > > > > On Thu, 15 Dec 2016 14:26:48 +0200 > > > > Nicolae-Alexandru Ivan wrote: > > > >=20 > > > > >=20 > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > =A0For 1 and 2, as Ganbold said ubldr is broken since clang 3.9 > > > > > > import > > > > > > (well only ubldr.bin for me ...) > > > > > > =A0For 3 and 4 I've never tested booting kernel directly, I'll > > > > > > try > > > > > > that. > > > > > > =A0Does your kernel have a static dtb compiled in ? > > > > > Yes, we included the device tree in the kernel binary. > > > > > The options below are included in our conf. > > > > >=20 > > > > > #FDT > > > > > options FDT > > > > > options FDT_DTB_STATIC > > > > > makeoptions FDT_DTS_FILE=3Dcubieboard2.dts > > > > =A0Oh I might now, my patches introduce a FreeBSD option for uboot > > > > that > > > > disable the dcache while it's strictly disable in the ports. > > > > =A0Do a gmake menuconfig in uboot before compiling but after gmake > > > > cubieboard2_defconfig to enable this. > > > >=20 > > > It shouldn't be necessary to disable dcache, but it does need to be > > > flushed before launching ubldr or the kernel; especially, it needs > > > the > > > icache sync'd. =A0The stock uboot does the needed cache work only in > > > the > > > path that launches linux that has been packaged as an image file > > > (and > > > before launching vxworks I think). =A0For freebsd the needed cache > > > ops > > > must be patched into two places, the bootelf path and the go path. > > >=20 > > > -- Ian > > =A0Well the dcache has been strictly disabled in most of our port for > > quite some times now. > > =A0I'll run some test so see if it's still needed and update the port > > if > > it's not. > > =A0And it raise a question: Why couldn't we flush the dcache at the > > start > > of ubldr for arm if it's needed ? > > =A0I'm gonna try to upstream by "FreeBSD config" v2 patches soon so I > > want to do it right. > >=20 >=20 > Dcache has been enabled in the uboot ports I was taking care of for a > long time; any of those ports have the needed patches for cache > maintenance before launching ubldr or the kernel. =A0See for example u- > boot-rpi, the patches for cmd_boot and cmd_elf. Yes I've seen that, I'll confirm that it isn't needed on Allwinner and do some patch. > The cache maintenance must be done *before* jumping to the ubldr or > kernel entry point, or else it's possible to jump to bad code (stale > cached data) that hangs or crashes. Ok, so newbie question on cache here, why does Linux doesn't need this ? and what can we do (if possible) to avoid the need of cache flush ? --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Dec 15 20:06:54 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 43DBFC814E6 for ; Thu, 15 Dec 2016 20:06:54 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 D6E168F8 for ; Thu, 15 Dec 2016 20:06:53 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 0531533e-c302-11e6-9673-39b5816e8152 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 0531533e-c302-11e6-9673-39b5816e8152; Thu, 15 Dec 2016 20:06:53 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBFK6k5u001740; Thu, 15 Dec 2016 13:06:46 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481832406.1972.29.camel@freebsd.org> Subject: Re: Cubieboard2 with custom bootloader From: Ian Lepore To: Emmanuel Vadot Cc: Nicolae-Alexandru Ivan , freebsd-arm@freebsd.org Date: Thu, 15 Dec 2016 13:06:46 -0700 In-Reply-To: <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> <1481831623.1972.24.camel@freebsd.org> <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:06:54 -0000 On Thu, 2016-12-15 at 21:01 +0100, Emmanuel Vadot wrote: > On Thu, 15 Dec 2016 12:53:43 -0700 > Ian Lepore wrote: > > > > > On Thu, 2016-12-15 at 19:48 +0100, Emmanuel Vadot wrote: > > > > > > On Thu, 15 Dec 2016 09:03:13 -0700 > > > Ian Lepore wrote: > > > > > > > > > > > > > > > On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: > > > > > > > > > > > > > > > On Thu, 15 Dec 2016 14:26:48 +0200 > > > > > Nicolae-Alexandru Ivan wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  For 1 and 2, as Ganbold said ubldr is broken since clang > > > > > > > 3.9 > > > > > > > import > > > > > > > (well only ubldr.bin for me ...) > > > > > > >  For 3 and 4 I've never tested booting kernel directly, > > > > > > > I'll > > > > > > > try > > > > > > > that. > > > > > > >  Does your kernel have a static dtb compiled in ? > > > > > > Yes, we included the device tree in the kernel binary. > > > > > > The options below are included in our conf. > > > > > > > > > > > > #FDT > > > > > > options FDT > > > > > > options FDT_DTB_STATIC > > > > > > makeoptions FDT_DTS_FILE=cubieboard2.dts > > > > >  Oh I might now, my patches introduce a FreeBSD option for > > > > > uboot > > > > > that > > > > > disable the dcache while it's strictly disable in the ports. > > > > >  Do a gmake menuconfig in uboot before compiling but after > > > > > gmake > > > > > cubieboard2_defconfig to enable this. > > > > > > > > > It shouldn't be necessary to disable dcache, but it does need > > > > to be > > > > flushed before launching ubldr or the kernel; especially, it > > > > needs > > > > the > > > > icache sync'd.  The stock uboot does the needed cache work only > > > > in > > > > the > > > > path that launches linux that has been packaged as an image > > > > file > > > > (and > > > > before launching vxworks I think).  For freebsd the needed > > > > cache > > > > ops > > > > must be patched into two places, the bootelf path and the go > > > > path. > > > > > > > > -- Ian > > >  Well the dcache has been strictly disabled in most of our port > > > for > > > quite some times now. > > >  I'll run some test so see if it's still needed and update the > > > port > > > if > > > it's not. > > >  And it raise a question: Why couldn't we flush the dcache at the > > > start > > > of ubldr for arm if it's needed ? > > >  I'm gonna try to upstream by "FreeBSD config" v2 patches soon so > > > I > > > want to do it right. > > > > > Dcache has been enabled in the uboot ports I was taking care of for > > a > > long time; any of those ports have the needed patches for cache > > maintenance before launching ubldr or the kernel.  See for example > > u- > > boot-rpi, the patches for cmd_boot and cmd_elf. >  Yes I've seen that, I'll confirm that it isn't needed on Allwinner > and > do some patch. > > > > > The cache maintenance must be done *before* jumping to the ubldr or > > kernel entry point, or else it's possible to jump to bad code > > (stale > > cached data) that hangs or crashes. >  Ok, so newbie question on cache here, why does Linux doesn't need > this ? and what can we do (if possible) to avoid the need of cache > flush ? > Linux does need it... that's what I said originally: u-boot only does the necessary cache maintaince when launching the linux kernel using the bootm family of commands that handle zImage type files (look for a symbol in uboot named "prepare_for_linux()" or something close to that spelling).  For the other flavors of boot command (bootelf, go, maybe others) it does nothing, it just jumps to the entry point, often hanging when it does.  The prepare_for_linux() code does some things that we don't need, so when I wrote the patches for bootelf and go I made them just call the needed cache cleaning routines directly. -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 15 20:09:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 87D5BC815D7 for ; Thu, 15 Dec 2016 20:09:10 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 6593B984 for ; Thu, 15 Dec 2016 20:09:10 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5e6c6a55-c302-11e6-9f67-d3961ed5a660 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 5e6c6a55-c302-11e6-9f67-d3961ed5a660; Thu, 15 Dec 2016 20:09:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBFK964l001746; Thu, 15 Dec 2016 13:09:06 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481832546.1972.31.camel@freebsd.org> Subject: Re: Cubieboard2 with custom bootloader From: Ian Lepore To: Emmanuel Vadot Cc: Nicolae-Alexandru Ivan , freebsd-arm@freebsd.org Date: Thu, 15 Dec 2016 13:09:06 -0700 In-Reply-To: <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> <1481831623.1972.24.camel@freebsd.org> <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:09:10 -0000 On Thu, 2016-12-15 at 21:01 +0100, Emmanuel Vadot wrote: > On Thu, 15 Dec 2016 12:53:43 -0700 > Ian Lepore wrote: > > > > > On Thu, 2016-12-15 at 19:48 +0100, Emmanuel Vadot wrote: > > > > > > On Thu, 15 Dec 2016 09:03:13 -0700 > > > Ian Lepore wrote: > > > > > > > > > > > > > > > On Thu, 2016-12-15 at 13:35 +0100, Emmanuel Vadot wrote: > > > > > > > > > > > > > > > On Thu, 15 Dec 2016 14:26:48 +0200 > > > > > Nicolae-Alexandru Ivan wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >  For 1 and 2, as Ganbold said ubldr is broken since clang > > > > > > > 3.9 > > > > > > > import > > > > > > > (well only ubldr.bin for me ...) > > > > > > >  For 3 and 4 I've never tested booting kernel directly, > > > > > > > I'll > > > > > > > try > > > > > > > that. > > > > > > >  Does your kernel have a static dtb compiled in ? > > > > > > Yes, we included the device tree in the kernel binary. > > > > > > The options below are included in our conf. > > > > > > > > > > > > #FDT > > > > > > options FDT > > > > > > options FDT_DTB_STATIC > > > > > > makeoptions FDT_DTS_FILE=cubieboard2.dts > > > > >  Oh I might now, my patches introduce a FreeBSD option for > > > > > uboot > > > > > that > > > > > disable the dcache while it's strictly disable in the ports. > > > > >  Do a gmake menuconfig in uboot before compiling but after > > > > > gmake > > > > > cubieboard2_defconfig to enable this. > > > > > > > > > It shouldn't be necessary to disable dcache, but it does need > > > > to be > > > > flushed before launching ubldr or the kernel; especially, it > > > > needs > > > > the > > > > icache sync'd.  The stock uboot does the needed cache work only > > > > in > > > > the > > > > path that launches linux that has been packaged as an image > > > > file > > > > (and > > > > before launching vxworks I think).  For freebsd the needed > > > > cache > > > > ops > > > > must be patched into two places, the bootelf path and the go > > > > path. > > > > > > > > -- Ian > > >  Well the dcache has been strictly disabled in most of our port > > > for > > > quite some times now. > > >  I'll run some test so see if it's still needed and update the > > > port > > > if > > > it's not. > > >  And it raise a question: Why couldn't we flush the dcache at the > > > start > > > of ubldr for arm if it's needed ? > > >  I'm gonna try to upstream by "FreeBSD config" v2 patches soon so > > > I > > > want to do it right. > > > > > Dcache has been enabled in the uboot ports I was taking care of for > > a > > long time; any of those ports have the needed patches for cache > > maintenance before launching ubldr or the kernel.  See for example > > u- > > boot-rpi, the patches for cmd_boot and cmd_elf. >  Yes I've seen that, I'll confirm that it isn't needed on Allwinner > and > do some patch. > > > > > The cache maintenance must be done *before* jumping to the ubldr or > > kernel entry point, or else it's possible to jump to bad code > > (stale > > cached data) that hangs or crashes. >  Ok, so newbie question on cache here, why does Linux doesn't need > this ? and what can we do (if possible) to avoid the need of cache > flush ? > I should mention, btw, that enabling the cache does make a huge difference.  For a wandboard with caches disabled, loading and launching the kernel takes 8 or 9 seconds, with dcache enabled it's less than 1 second. -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 15 20:42:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06003C8247A for ; Thu, 15 Dec 2016 20:42:32 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1E7319D; Thu, 15 Dec 2016 20:42:31 +0000 (UTC) (envelope-from mihai.carabas@gmail.com) Received: by mail-qt0-x22a.google.com with SMTP id n6so69026116qtd.1; Thu, 15 Dec 2016 12:42:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WHqf0ePVgF6fHV2tFOlDi+kdm5cLPt9lfqsFuhi7F0I=; b=Io9dby6L8xrC/6E9vdmw4ePRLsNnGbGI2vL/JNAIhDneLcXvO7VQIrTd2BeNyIm4i+ Xiu1ZA1VRPKupZ8XGRWUOXQiLOhrlCtSZfopvooFnd62r/9ufwD7+BTF1ZsNtRDjZ/1m raL8wBDQjIGe3twbB/G3ZVbv+uYqDRLD7TdIy0KuRxXEey9avqixCIi1J0RbzVk9488G DmSN8urIqzVb59CJDgkUdgDXDM7JQavuunyND62LAvV+hne1o58R7G1m8StZt0I/XMuK YiPDCtHMYkrcNcxZrVoTRsfM2wAiI9iihojEVfPeHifWGXbuxUQEKKxnQwFfdqKarPRu b4vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WHqf0ePVgF6fHV2tFOlDi+kdm5cLPt9lfqsFuhi7F0I=; b=DHjOVDNuYKD11pevmiVoxJHib1b3woPFjSN8AmptvsiFoS4xmeTS0D/Ob/EqhCpll8 OnpZ59igHnOgaLX6reAUPywDQKpTAufcobLbzEzGz0lbD5wYCaZanVUkMAozweYLAUYe 8fbqZgJdQVYlUKbMfE5txqt6kqwSxZJytPZEw/V8x6ulqDIpBV+DTaNsDYs6oHfTP8ib uLj5xCeTJ95UE1Zy/nnhSSlM+Zom4mz/3qWkJ03W2GN5m8+0hk0VR81mx79fnG3oTgKU 56GSrZfi+9gcBunL35SGEtSlLhgECa6rgM/Qr5NzSdEGrFRJDG6RrG1AytRdVux9xGBU +52w== X-Gm-Message-State: AIkVDXK8d5GRvQn0/Is5bdmkGoYXrNHFwRV8sLARIR6NEXC0tTM9t2wTo/Lp8sKTvQ+O0jM0u2/f5trQiDljew== X-Received: by 10.200.43.167 with SMTP id m36mr1935006qtm.117.1481834550742; Thu, 15 Dec 2016 12:42:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.167.137 with HTTP; Thu, 15 Dec 2016 12:42:30 -0800 (PST) In-Reply-To: <1481832546.1972.31.camel@freebsd.org> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> <1481831623.1972.24.camel@freebsd.org> <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> <1481832546.1972.31.camel@freebsd.org> From: Mihai Carabas Date: Thu, 15 Dec 2016 22:42:30 +0200 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Ian Lepore Cc: Emmanuel Vadot , Nicolae-Alexandru Ivan , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:42:32 -0000 > > > > I should mention, btw, that enabling the cache does make a huge > difference. For a wandboard with caches disabled, loading and > launching the kernel takes 8 or 9 seconds, with dcache enabled it's > less than 1 second. > Ian thank you for your answers. Do you have anywhere the patches for u-boot if we want to compile it from sources? Mihai From owner-freebsd-arm@freebsd.org Thu Dec 15 20:54:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF69CC8275D for ; Thu, 15 Dec 2016 20:54:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 BE65F97B for ; Thu, 15 Dec 2016 20:54:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9776d476-c308-11e6-9ec7-5d8fa496b077 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 9776d476-c308-11e6-9ec7-5d8fa496b077; Thu, 15 Dec 2016 20:53:55 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uBFKs535001811; Thu, 15 Dec 2016 13:54:05 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1481835245.1972.42.camel@freebsd.org> Subject: Re: Cubieboard2 with custom bootloader From: Ian Lepore To: Mihai Carabas Cc: Emmanuel Vadot , Nicolae-Alexandru Ivan , freebsd-arm@freebsd.org Date: Thu, 15 Dec 2016 13:54:05 -0700 In-Reply-To: References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> <1481831623.1972.24.camel@freebsd.org> <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> <1481832546.1972.31.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 20:54:14 -0000 On Thu, 2016-12-15 at 22:42 +0200, Mihai Carabas wrote: > > > > > > > > > > I should mention, btw, that enabling the cache does make a huge > > difference.  For a wandboard with caches disabled, loading and > > launching the kernel takes 8 or 9 seconds, with dcache enabled it's > > less than 1 second. > > > Ian thank you for your answers. Do you have anywhere the patches for > u-boot > if we want to compile it from sources? > > Mihai The patches I'm referring to are part of the checked-in u-boot ports.  They used to be in beaglebone and rpi at least, but the beaglebone stuff appears to currently be in a state of flux.  The rpi port still has the patches, though.  The patches aren't rpi-specific, I've been using them on all arm u-boot stuff (I have uncommited changes for wandboard and other imx6 systems, and we use this stuff at $work too). https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi/files/patch-common_cmd__elf.c?view=co https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi/files/patch-common_cmd__boot.c?view=co The last version of u-boot I know for sure those two patches apply cleanly to was 2016.01; I haven't looked at any u-boot releases since then. -- Ian From owner-freebsd-arm@freebsd.org Thu Dec 15 21:13:50 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A658C82BC8 for ; Thu, 15 Dec 2016 21:13:50 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb1-smtp-cloud6.xs4all.net (lb1-smtp-cloud6.xs4all.net [194.109.24.24]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 961CD128D for ; Thu, 15 Dec 2016 21:13:48 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud6.xs4all.net with ESMTP id LMDk1u00S4VixDu01MDmrz; Thu, 15 Dec 2016 22:13:46 +0100 Reply-To: From: "John W. Kitz" To: Cc: Subject: When first hooking up a cubieboard2... Date: Thu, 15 Dec 2016 22:13:47 +0100 Message-ID: <004301d25718$20f5d8a0$62e189e0$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJXGB/xbh7VFhDER82JtB2Zvc1ZbA== Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 21:13:50 -0000 Emmanuel, Earlier I wrote: >> > > > > > > da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 >> > > > > > > da1 at umass-sim0 bus 0 scbus4 target 0 lun 1 >> > > > > > > da2 at umass-sim0 bus 0 scbus4 target 0 lun 2 On 2016-12-14 22:56, you wrote: > What the software running on the board is doing is called usb gadget > mode. It uses the OTG port to act as a device and it seems that it act > as some multiple usb disk. But this doesn't mean that the device it's > exporting match some device on the board. It could be directory or file > on the filesystem. This already clarified the question I had: Today I found an example of a startup log online and copied a part of that here: [ 1.840000] android_usb gadget: Mass Storage Function, version: 2009/09/11 [ 1.840000] android_usb gadget: Number of LUNs=3 [ 1.850000] lun0: LUN: removable file: (no medium) [ 1.850000] lun1: LUN: removable file: (no medium) [ 1.860000] lun2: LUN: removable file: (no medium) This fully clarifies it for me. Again thanks, Jk. From owner-freebsd-arm@freebsd.org Thu Dec 15 21:30:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3095BC82E0F for ; Thu, 15 Dec 2016 21:30:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x241.google.com (mail-it0-x241.google.com [IPv6:2607:f8b0:4001:c0b::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1BCA195F for ; Thu, 15 Dec 2016 21:30:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x241.google.com with SMTP id 75so380757ite.1 for ; Thu, 15 Dec 2016 13:30:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=3qcTz48nYqU7MPI5GbzlRSXeEj7gXtM0f6p2Q0eCjo8=; b=V7FGoihWqUDPL57ANPMFrWaqVK1R9ls5yhNfuOL/mAFloHeieDL/s/0mAwzbg6JRWm kVhUxucgL9Es9fmffygIoCIXwZ74U8tOHnz8fVZ/fCWnmzEuiKxLkjh1jx/IHt/r1ZPg uWhcEdWeOpFIcaVfTQAp598XPVysCeIseuImJgT8I4gDafNWKAWeWCBY7DmQLfji3zGr 9H5c5rfC+1hVFpIwfRvguolFMNjAXAGNCY0mzTc2GPxHkoOnXeXcsBd2lZh86ttaqvYf v7QBgjb40g6cXJXuIUU41jmKoQU3hvMrN97NwtgTwfe4oTht1QkpXZTH3/P9/Ubv2+lE fBow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=3qcTz48nYqU7MPI5GbzlRSXeEj7gXtM0f6p2Q0eCjo8=; b=dVDTabei4pzZxzYLCkD9yGaztrahmUEVPZ9xYpvLFiZ/H6CJUywllbwefVTZexABNB rsO2B4/iSNxUDD2Ia1+isNYdtiO/onvJto/TqgE1Nf9naCa1KkqeElnIVKNXGF6FvTz3 uVcgONIRxDJDWoGuyqP2F7HWe+bXKL5QiOzjT05q4xsiDFj1jFWH5iCSQNmFEA9xZU4H epPKVgQkYlfwVmZ3MXFUmNlD0utbnvyaW4fLC1q+oAtWa/IPL5T/CYuA8n4NJSTPJOGO 48ForY7PapdS7rZQ1JAnDWSDkATo6smYJlXZBkLwXA3IxjOB4d4fxSOvM4yQFWwJaWYK 7ANA== X-Gm-Message-State: AKaTC02nNdG54KvEb/aJgzk2kkuXH9+qEsrQnc97loICan74xbu2QLEQnJhsPjB6ecHihrUBwXLmHoB93uiZwg== X-Received: by 10.36.61.207 with SMTP id n198mr450604itn.60.1481837403244; Thu, 15 Dec 2016 13:30:03 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.22.135 with HTTP; Thu, 15 Dec 2016 13:30:02 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <1481835245.1972.42.camel@freebsd.org> References: <20161212160553.dee9d435125f9c6b67355d21@bidouilliste.com> <20161215123900.f141d13bd9814d43feb3f736@bidouilliste.com> <20161215133505.a7ffa64924f3be052840b828@bidouilliste.com> <1481817793.1972.2.camel@freebsd.org> <20161215194847.efbfcd94694e6c71dacdc16a@bidouilliste.com> <1481831623.1972.24.camel@freebsd.org> <20161215210115.b224a164cb32abef56b86e7d@bidouilliste.com> <1481832546.1972.31.camel@freebsd.org> <1481835245.1972.42.camel@freebsd.org> From: Warner Losh Date: Thu, 15 Dec 2016 13:30:02 -0800 X-Google-Sender-Auth: sx3zaR0yv040fujzu5EQm5NGbW8 Message-ID: Subject: Re: Cubieboard2 with custom bootloader To: Ian Lepore Cc: Mihai Carabas , Nicolae-Alexandru Ivan , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 21:30:04 -0000 On Thu, Dec 15, 2016 at 12:54 PM, Ian Lepore wrote: > On Thu, 2016-12-15 at 22:42 +0200, Mihai Carabas wrote: >> > >> > >> > >> > >> > I should mention, btw, that enabling the cache does make a huge >> > difference. For a wandboard with caches disabled, loading and >> > launching the kernel takes 8 or 9 seconds, with dcache enabled it's >> > less than 1 second. >> > >> Ian thank you for your answers. Do you have anywhere the patches for >> u-boot >> if we want to compile it from sources? >> >> Mihai > > The patches I'm referring to are part of the checked-in u-boot ports. > They used to be in beaglebone and rpi at least, but the beaglebone > stuff appears to currently be in a state of flux. The rpi port still > has the patches, though. The patches aren't rpi-specific, I've been > using them on all arm u-boot stuff (I have uncommited changes for > wandboard and other imx6 systems, and we use this stuff at $work too). > > https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi/files/patch-common_cmd__elf.c?view=co > https://svnweb.freebsd.org/ports/head/sysutils/u-boot-rpi/files/patch-common_cmd__boot.c?view=co > > The last version of u-boot I know for sure those two patches apply > cleanly to was 2016.01; I haven't looked at any u-boot releases since > then. I haven't dropped them in u-boot-master, since it pulls from my tree where these patches are applied to allow wider sharing of a known-good-for-freebsd tree. Warner From owner-freebsd-arm@freebsd.org Fri Dec 16 12:16:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 757DFC82EA5 for ; Fri, 16 Dec 2016 12:16:22 +0000 (UTC) (envelope-from admin@x135.save85off.com) Received: from x135.save85off.com (x135.save85off.com [43.240.238.135]) by mx1.freebsd.org (Postfix) with ESMTP id 4158D1D80 for ; Fri, 16 Dec 2016 12:16:21 +0000 (UTC) (envelope-from admin@x135.save85off.com) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=save85off; d=x135.save85off.com; h=MIME-Version:From:To:Date:Subject:Content-Type:Content-Transfer-Encoding; i=admin@x135.save85off.com; bh=cRoyr1LaDIzZve/KOVAOHFPoLfw=; b=YwlGnC+pZ/r0lBB4O6Rx735bl+IJKcCLdDaHC6R/CfUxakvli+M33buuwZ9qhQery/i2p3cu2W0N c1BBmdPgBB7yP87kKz5D6QCMgxqGXzIJhp7muHZVnJ34EhfF+5CHPdk9qabV/2Wnql+xJjFFxZ2o Z97MNLzhAMLVb/+X/6U= DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=save85off; d=x135.save85off.com; b=CWlJoqkEtqlKMmjuobf1McHK4GM7oZVisbCk0vd/6JppnCcNfrsv1MSt9bEjyudxmUzJ3WHoIFlQ f4tkazUZ1cJb8MSqQQdiWr/VytXR9AYVa4WeKHxx4J4INxPgZBK3VNa/abOfprgilfLd9HsbezBq mqvBy+RcOfFaMoLNDQg=; From: "UGG Big Deals" To: freebsd-arm@freebsd.org Date: 16 Dec 2016 20:04:05 +0800 Subject: Are you taking time for YOU this Christmas? win 188$ MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 12:16:22 -0000