From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 04:49:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 393C0A6C for ; Sun, 28 Sep 2014 04:49:36 +0000 (UTC) Received: from mail-qa0-x232.google.com (mail-qa0-x232.google.com [IPv6:2607:f8b0:400d:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED0E2EFE for ; Sun, 28 Sep 2014 04:49:35 +0000 (UTC) Received: by mail-qa0-f50.google.com with SMTP id j7so7684600qaq.9 for ; Sat, 27 Sep 2014 21:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VtvQ0U16VvyWx52/AKTni9U0upxNp1SmOwPw9hvh33U=; b=ImrJRskNmQM1oEnkd5VrhBHPfRJvlZcmfzMO7MuibeKwIUCrjGZUoC2CWUepm5mEwO H2Y8Ly5psoXaLkU9qz6zQ17CMnlCcTVGJJusxnMQHwTR8163NYUvaJCPYo0k69iBzE7S l1aWcYq9/cZ9dOBKLaXR0gJ4eIPvLyu/7wMJNN2SPE8XAz1zOuG0oPl3uQ44AsUlqtya gF9meS4wlSQJzY4zTSRU2m/nSaHjJmIRYAFb7yWDPTIy5dHOsoqLpR8dRR8CQF7fAEow 6ragA6LY3plerUFTz6vjbNfnOYEQdmzElbiRSi9tKMGaHnWN0LRq5UInRJZmPMPLXOwz lgWQ== MIME-Version: 1.0 X-Received: by 10.140.102.9 with SMTP id v9mr19584157qge.38.1411879774983; Sat, 27 Sep 2014 21:49:34 -0700 (PDT) Received: by 10.140.154.15 with HTTP; Sat, 27 Sep 2014 21:49:34 -0700 (PDT) In-Reply-To: References: Date: Sat, 27 Sep 2014 21:49:34 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 04:49:36 -0000 I will attempt to load the kernel from tftp as soon as I can. I will need to figure out how to get ethernet to the unit. I know nothing about u-boot so forgive my ignorance but I was hoping to modify the Arndale configuration to work such as: # mmc read 1 0x70800000 0x800 0x1800; #go 0x70800000; and then point the rootfs to /dev/da1s1 On another note, do you know where I could find out more about the missing MTD support? BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many cool projects, so little time... Thanks, Russ On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > On Sep 27, 2014, at 13:31, Russell Haley wrote: > > > > Rui, > > > > So no MTD means the NAND on the SOM is out, but can I boot the kernel > and load rootfs from the microSD, like in this example: > > =E2=80=A2 > > ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; g= o > 0x40f00000" > > > > ARNDALE5250 # saveenv > > > > ARNDALE5250 # boot > > You can't use the Arndale config since the load addresses are different. > You should be able to load a kernel from the network. Can you do that? > > -- > Rui Paulo > > > > From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 07:12:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2B20FCA8 for ; Sun, 28 Sep 2014 07:12:43 +0000 (UTC) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EBDC7CFD for ; Sun, 28 Sep 2014 07:12:42 +0000 (UTC) Received: by mail-pa0-f42.google.com with SMTP id bj1so5365933pad.29 for ; Sun, 28 Sep 2014 00:12:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=PgCwDhqjdq1UA4uc4Marum2mkg7l/43qP3bdC5e+Q7M=; b=m2Txg/xdeAHk91e0EO6R44SIQV47r6ziLTpaPCEcRcuyEBIr0NxhorZmBgcwWDVSbZ PV3nsvn9cVQNFWxAO22qosTATIVb3zZiCGUkgoAibQVheSOROsDDN3djR018cQ+nIsVj wpdtRyBGAFhCgpIxwXPNHWbGJBe/sKUo146FeCBd5kOA/o+sfuRNbjUd2Ua0qkc72jGJ SAOVvn9YtPiC9mZVEVk5YvxDc9o77/JyB/U4WrjTQglOzc283USMwE8H9Dk7By6M1OHe shy9beq2G+aSNLgFhdyA90XgP/F3DhL/D1ej0Z2jziMrz/4NHohm4sMBO8VYFor4kAQm RNkQ== X-Gm-Message-State: ALoCoQkDQVj8SS0YHNxogdO83x+O3F01000WErerodPa2qX2FX5vwQlYu5513JEYu/GDqmDjQZaS X-Received: by 10.70.89.132 with SMTP id bo4mr46932196pdb.35.1411888355924; Sun, 28 Sep 2014 00:12:35 -0700 (PDT) Received: from [172.20.12.175] ([69.63.206.125]) by mx.google.com with ESMTPSA id d5sm9064709pbu.45.2014.09.28.00.12.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 00:12:35 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_FF9DF287-E0E9-42CA-AA66-721E50BB8232"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Sun, 28 Sep 2014 00:12:32 -0700 Message-Id: References: To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 07:12:43 -0000 --Apple-Mail=_FF9DF287-E0E9-42CA-AA66-721E50BB8232 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 27, 2014, at 9:49 PM, Russell Haley wrote: > I will attempt to load the kernel from tftp as soon as I can. I will = need > to figure out how to get ethernet to the unit. >=20 > I know nothing about u-boot so forgive my ignorance but I was hoping = to > modify the Arndale configuration to work such as: >=20 > # mmc read 1 0x70800000 0x800 0x1800; > #go 0x70800000; >=20 > and then point the rootfs to /dev/da1s1 >=20 > On another note, do you know where I could find out more about the = missing > MTD support? A spec for the NAND controller is needed to make that work=85 Is one = about? Warner > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many = cool > projects, so little time... >=20 > Thanks, >=20 > Russ >=20 > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: >=20 >> On Sep 27, 2014, at 13:31, Russell Haley = wrote: >>>=20 >>> Rui, >>>=20 >>> So no MTD means the NAND on the SOM is out, but can I boot the = kernel >> and load rootfs from the microSD, like in this example: >>> =95 >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; = go >> 0x40f00000" >>>=20 >>> ARNDALE5250 # saveenv >>>=20 >>> ARNDALE5250 # boot >>=20 >> You can't use the Arndale config since the load addresses are = different. >> You should be able to load a kernel from the network. Can you do = that? >>=20 >> -- >> Rui Paulo >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" --Apple-Mail=_FF9DF287-E0E9-42CA-AA66-721E50BB8232 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJ7TgAAoJEGwc0Sh9sBEAhmMQAJc3+/nwcko/dXAybQD3TCH1 HCNO43Lk/VaCbbkvGY9ZrWNXEsfZebewcFt2KizgJpA1dV2iuR9lxEFw4kyIdcKO DOsCq5qCCa3dSpRPrNHquJnW7dHd14ZyeXq9T7d20k7KVIrmHenoL94YM9Wv0LDL AOi94TB8lC2a10PqmXDs1q+AYg/69uFGGXknk5X1wE6WR51Mk3rLKGhw3Az0BfD1 qv70Urx5fZsFfS3e77nRIjEkpXI3X4etK5PbsDpJNx35PbuXgct/Ysa39jPKPgwo oqFcBP8DFGx8xbBVbY/yg3A5Yln4fB4NH6nF+58350anGHZ//lEFhbiDXX/fVUga 90EyjERop6uAhexw5E4iERs/b+YIN/CQKuBicyIktGIMSoTLgeeYjbW4KJ+VqHoy NvirOlAT72vCmCna8UgpykkkzlsfuVoQTATuH0zZZtMfftiThG3ASuVnmvXzSEgS qLv59jNF5NmfA5GdE93SBLT8dv7VXchih4laLuKdxaeWK5oKoFX/aLec+W2j/LzE fYKIMnh0KxoZeFuAkZXoXqSWtXt3omJNP41Ww1VKdZSbGgMCIJv9aKP91BfqCw0f XYQGUPEztpSL4Ip83O5wuceMP/WlGuAaGcUIqS9ceRspVFEAeFIoSE+n48u8Sop+ CGui7trB4Ix1EkQyHCKc =+A0e -----END PGP SIGNATURE----- --Apple-Mail=_FF9DF287-E0E9-42CA-AA66-721E50BB8232-- From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 07:25:54 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9B6B6F13 for ; Sun, 28 Sep 2014 07:25:54 +0000 (UTC) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com [IPv6:2607:f8b0:400e:c02::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E4E3DCC for ; Sun, 28 Sep 2014 07:25:54 +0000 (UTC) Received: by mail-pd0-f173.google.com with SMTP id w10so5663633pde.18 for ; Sun, 28 Sep 2014 00:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to:cc; bh=a8DY1RlfWYUukehjGPQFhDdchqs+6X+SQ0Ac53hHB+c=; b=YukMupQYW3W2U68Z7nqdPTgouneuqGf3hGpLKVZNHwmvclxp8NJLp3OsLP2rRX5gzq U0KS7lo4LIFLF/29+/l0JdaDzdUJVpU4taiIC8LlaOj/rnVu29PnrMkX86ec5ZNC0Cl3 Of7wpuXzWEJgZlr2pQm4YIgPoBHlgkjoKc6uN6KN9C0GeQz139J3U7G06TFqkQAvNMEJ /A5EK4Byyf33QyaYWX69RSi/MOTk80+9dXKiLn7qke3mM3AioKtHAgxgolJkMtpRzKp/ oRPFFDGfQ6SB+x+nWbgjTlC6UoY1mOCcU5JD7+8qM34AZhV0KRtgIb5iV9c8JyWId7HB qMAQ== X-Received: by 10.70.129.33 with SMTP id nt1mr1271386pdb.166.1411889153962; Sun, 28 Sep 2014 00:25:53 -0700 (PDT) Received: from [127.0.0.1] ([216.113.200.184]) by mx.google.com with ESMTPSA id g13sm9167050pat.45.2014.09.28.00.25.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 00:25:53 -0700 (PDT) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.2.1.3247) Message-ID: <20140928072552.6008977.32039.589@gmail.com> Date: Sun, 28 Sep 2014 00:25:52 -0700 Subject: Re: Digi CCWMX53 From: russ.haley@gmail.com In-Reply-To: References: To: Warner Losh Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 07:25:54 -0000 I'll check at work on Tuesday when I'm in.=C2=A0 Thanks, Russ Sent from my BlackBerry 10 smartphone. =C2=A0 Original Message =C2=A0 From: Warner Losh Sent: Sunday, September 28, 2014 12:12 AM To: Russell Haley Cc: Rui Paulo; freebsd-arm@freebsd.org Subject: Re: Digi CCWMX53 On Sep 27, 2014, at 9:49 PM, Russell Haley wrote: > I will attempt to load the kernel from tftp as soon as I can. I will need > to figure out how to get ethernet to the unit. >=20 > I know nothing about u-boot so forgive my ignorance but I was hoping to > modify the Arndale configuration to work such as: >=20 > # mmc read 1 0x70800000 0x800 0x1800; > #go 0x70800000; >=20 > and then point the rootfs to /dev/da1s1 >=20 > On another note, do you know where I could find out more about the missing > MTD support? A spec for the NAND controller is needed to make that work=E2=80=A6 Is one = about? Warner > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many cool > projects, so little time... >=20 > Thanks, >=20 > Russ >=20 > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: >=20 >> On Sep 27, 2014, at 13:31, Russell Haley wrote: >>>=20 >>> Rui, >>>=20 >>> So no MTD means the NAND on the SOM is out, but can I boot the kernel >> and load rootfs from the microSD, like in this example: >>> =E2=80=A2 >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; go >> 0x40f00000" >>>=20 >>> ARNDALE5250 # saveenv >>>=20 >>> ARNDALE5250 # boot >>=20 >> You can't use the Arndale config since the load addresses are different. >> You should be able to load a kernel from the network. Can you do that? >>=20 >> -- >> Rui Paulo >>=20 >>=20 >>=20 >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 09:55:41 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3EB2DEFF for ; Sun, 28 Sep 2014 09:55:41 +0000 (UTC) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C896FC85 for ; Sun, 28 Sep 2014 09:55:40 +0000 (UTC) Received: by mail-wi0-f169.google.com with SMTP id hi2so3050931wib.2 for ; Sun, 28 Sep 2014 02:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:date:reply-to:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=g9FwlLumxtW6DcUPuMxD/ejUxKIwPC3nSl56SHUCyHI=; b=hzHrxTVehj6dmrlwSPFsOoA8mfQomUktUA64wLivLjAcSJkEP8eBq2WfBeEa00/SXU 8I24vLXzREX9AJkPeYw4k+NGfYFPACsbHhVSzpQ0wdf7+rJRi45yIYCWCjIxzTyZOf1H M8eJ7JzcyVDZvVB/BjKavKQWMCofJYqQem1SOCHfsq0ClmGcL+ks5BVEewWF6hjFpOkH qt/gTMtVOkPZ3nGs0NWeUEarLG2LFT3mD5g31OS+SeOAnDpeNjgfZu8vFgzz5vwb10ff kN/Q3xNBn1/aqxG5W6KAheziGvWntm6QGQzFh0SwVdh4WgEyxo1As9nEQWSiRTa5uxBB AjjA== X-Received: by 10.194.250.103 with SMTP id zb7mr36540054wjc.52.1411898138889; Sun, 28 Sep 2014 02:55:38 -0700 (PDT) Received: from [192.168.0.11] (178-83-152-199.dynamic.hispeed.ch. [178.83.152.199]) by mx.google.com with ESMTPSA id hu3sm11526111wjb.17.2014.09.28.02.55.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 28 Sep 2014 02:55:38 -0700 (PDT) From: Mattia Rossi X-Google-Original-From: Mattia Rossi Message-ID: <5427DB19.4000304@gmail.com> Date: Sun, 28 Sep 2014 11:55:37 +0200 Reply-To: mattia.rossi.mate@gmail.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Ronald Klop , freebsd-arm@freebsd.org Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 09:55:41 -0000 On 27/09/14 10:57, Ronald Klop wrote: > On Fri, 26 Sep 2014 14:19:08 +0200, Mattia Rossi > wrote: > >> This might be part of the weird FFS issues the Dreamplug has and >> no-one knows why they're happening. > > I don't know if it is related, but my Sheevaplug also has issues with > ffs while running 11-CURRENT. The fs gets corrupted or something. > Which is not fixed by fsck. Every run of fsck finds more unlinked > files and removes them. Also files which are stable on the fs since > installation like /lib/*. I've had a discussion with Ian Lepore about this, and he actually found out that fsck is broken. > This ffs corruption + panic mostly happened while installing ports on > the first day of operation. > > But, the day before yesterday I compiled with gcc again instead of > clang and it seems to run stable for 2 days now. This is interesting though.. How do I switch to gcc as compiler for world? I'd like to test that, and to see if it's really a clang problem. > > Unfortunately I don't have the backtraces of the crashes anymore. > > NB: running 11-CURRENT from usb-stick with ports mounted via nfs. Well, it's pretty much the same I have, only that the dreamplug has an internal sd card which is attached via usb. I have ports on nfs as well. > > Ronald. > > >> The panic occurred while running nsd-control reload (which should >> simply re-read a config file from disk). I was previously editing >> files without issues. >> >> Result is the following: >> >> vm_fault(0xc10a0000, d0238000, 2, 0) -> 2 >> Fatal kernel mode data abort: 'Permission Fault (P)' >> trapframe: 0xde019898 >> FSR=0000000f, FAR=d0238120, spsr=20000013 >> r0 =d0238120, r1 =00000e60, r2 =00000000, r3 =00000000 >> r4 =00000120, r5 =00000000, r6 =c3f3f6c0, r7 =00001000 >> r8 =c443e880, r9 =00000000, r10=c3d69000, r11=de019a20 >> r12=d0238120, ssp=de0198e8, slr=c0d53828, pc =c0de521c >> >> [ thread pid 21116 tid 100073 ] >> Stopped at memset+0x48: undge 0xa0cc20f8 >> db> >> db> bt >> Tracing pid 21116 tid 100073 td 0xc3e97000 >> db_trace_self() at db_trace_self >> pc = 0xc0dd5418 lr = 0xc094f8a8 (db_hex2dec+0x490) >> sp = 0xde0195a0 fp = 0xde0195b8 >> r10 = 0xc0f5e8c8 >> db_hex2dec() at db_hex2dec+0x490 >> pc = 0xc094f8a8 lr = 0xc094f260 (db_command_loop+0x300) >> sp = 0xde0195c0 fp = 0xde019660 >> r4 = 0x00000000 r5 = 0x00000000 >> r6 = 0x00000000 >> db_command_loop() at db_command_loop+0x300 >> pc = 0xc094f260 lr = 0xc094efb0 (db_command_loop+0x50) >> sp = 0xde019668 fp = 0xde019678 >> r4 = 0xc0e2dfe4 r5 = 0xc0e4402e >> r6 = 0xc0f5e8b4 r7 = 0xc0ef62b8 >> r8 = 0xc0f52754 r9 = 0xc0f52750 >> r10 = 0xc3e97000 >> db_command_loop() at db_command_loop+0x50 >> pc = 0xc094efb0 lr = 0xc09519ec (X_db_symbol_values+0x250) >> sp = 0xde019680 fp = 0xde0197a0 >> r4 = 0x00000000 r5 = 0xc0f5e8c0 >> r6 = 0xc0f52778 >> X_db_symbol_values() at X_db_symbol_values+0x250 >> pc = 0xc09519ec lr = 0xc0b37b08 (kdb_trap+0xc4) >> sp = 0xde0197a8 fp = 0xde0197c8 >> r4 = 0x00000000 r5 = 0x0000000f >> r6 = 0xc0f52778 r7 = 0xc0ef62b8 >> kdb_trap() at kdb_trap+0xc4 >> pc = 0xc0b37b08 lr = 0xc0de7c60 (data_abort_handler+0x7f8) >> sp = 0xde0197d0 fp = 0xde0197e8 >> r4 = 0xde019898 r5 = 0x0000000f >> r6 = 0x600000d3 r7 = 0xd0238120 >> r8 = 0x00000000 r9 = 0xc0f648d4 >> r10 = 0xc3e97000 >> data_abort_handler() at data_abort_handler+0x7f8 >> pc = 0xc0de7c60 lr = 0xc0de7a28 (data_abort_handler+0x5c0) >> sp = 0xde0197f0 fp = 0xde019890 >> r4 = 0xc10a0000 r5 = 0x00000013 >> r6 = 0xde019eb0 r7 = 0x00000002 >> data_abort_handler() at data_abort_handler+0x5c0 >> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >> sp = 0xde019898 fp = 0xde019a20 >> r4 = 0xffffffff r5 = 0xffff1004 >> r6 = 0xc3f3f6c0 r7 = 0x00001000 >> r8 = 0xc443e880 r9 = 0x00000000 >> r10 = 0xc3d69000 >> exception_exit() at exception_exit >> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >> sp = 0xde0198e8 fp = 0xde019a20 >> r0 = 0xd0238120 r1 = 0x00000e60 >> r2 = 0x00000000 r3 = 0x00000000 >> r4 = 0x00000120 r5 = 0x00000000 >> r6 = 0xc3f3f6c0 r7 = 0x00001000 >> r8 = 0xc443e880 r9 = 0x00000000 >> r10 = 0xc3d69000 r12 = 0xd0238120 >> memset() at memset+0x48 >> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >> sp = 0xde0198e8 fp = 0xde019a20 >> Unwind failure (no registers changed) >> >> The sad thing is, that with fsck broken for the dreamplug, I have to >> re-format the disk, reinstall everything and recreate the config >> files which I didn't manage to copy to a safe place beforehand :-( >> >> Before I do that I'll leave the system in debugging mode for a few >> days, in case someone can help and needs some more information. >> >> Cheers, >> >> Mat >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 11:18:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 412F8260 for ; Sun, 28 Sep 2014 11:18:33 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 252C85EE for ; Sun, 28 Sep 2014 11:18:32 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id B6E1E5C0B9; Sun, 28 Sep 2014 11:18:25 +0000 (UTC) Date: Sun, 28 Sep 2014 12:18:18 +0100 From: Andrew Turner To: Warner Losh Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140928121818.741e7e7e@bender.lan> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 11:18:33 -0000 On Mon, 19 May 2014 09:40:33 -0600 Warner Losh wrote: > Greetings, > > MK_ARM_EABI is going to die in current. It is the default for all > platforms currently. I’m eliminating it as a build option. It must > die because it invisibly (to uname) effects the ABI. > > So, to that end, I see two options: > > (1) Retire and remove oabi support. > (2) Retain oabi support, but change its name to armo and armoeb. > > The rough consensus of arm developers I’ve polled now, and in the > past, is that we just let oabi support die now that EABI support is > working for everybody. > > Before I pull the trigger on this, however, I must ask if anybody has > a problem with my doing option (1), and if so, what keeps you using > oabi. > > Comments? As far as I know all the problems with ARM EABI on armeb mentioned in this thread have been fixed. I think we should now retire the oabi support and remove MK_ARM_EABI. Andrew From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 12:41:23 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AA4F72E1 for ; Sun, 28 Sep 2014 12:41:23 +0000 (UTC) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.81]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6A43FCEE for ; Sun, 28 Sep 2014 12:41:22 +0000 (UTC) Received: from smtp.greenhost.nl ([213.108.104.138]) by smarthost1.greenhost.nl with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1XYDmm-0005EB-TU; Sun, 28 Sep 2014 14:41:14 +0200 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes To: freebsd-arm@freebsd.org, "Mattia Rossi" Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <5427DB19.4000304@gmail.com> Date: Sun, 28 Sep 2014 14:41:08 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <5427DB19.4000304@gmail.com> User-Agent: Opera Mail/12.16 (FreeBSD) X-Authenticated-As-Hash: 398f5522cb258ce43cb679602f8cfe8b62a256d1 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.3.1 X-Scan-Signature: 96329e479c93ffb0716cf569fedf443d X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 12:41:23 -0000 On Sun, 28 Sep 2014 11:55:37 +0200, Mattia Rossi wrote: > On 27/09/14 10:57, Ronald Klop wrote: >> On Fri, 26 Sep 2014 14:19:08 +0200, Mattia Rossi >> wrote: >> >>> This might be part of the weird FFS issues the Dreamplug has and >>> no-one knows why they're happening. >> >> I don't know if it is related, but my Sheevaplug also has issues with >> ffs while running 11-CURRENT. The fs gets corrupted or something. Which >> is not fixed by fsck. Every run of fsck finds more unlinked files and >> removes them. Also files which are stable on the fs since installation >> like /lib/*. > I've had a discussion with Ian Lepore about this, and he actually found > out that fsck is broken. >> This ffs corruption + panic mostly happened while installing ports on >> the first day of operation. >> >> But, the day before yesterday I compiled with gcc again instead of >> clang and it seems to run stable for 2 days now. > This is interesting though.. How do I switch to gcc as compiler for > world? I'd like to test that, and to see if it's really a clang problem. I put this in the environment. export WITH_GCC=yes export WITH_GNUCXX=yes export WITH_GCC_BOOTSTRAP=yes export WITHOUT_CLANG=yes export WITHOUT_CLANG_IS_CC=yes export WITHOUT_CLANG_BOOTSTRAP=yes Got that from this email: http://lists.freebsd.org/pipermail/freebsd-arm/2014-August/009001.html Regards, Ronald. >> >> Unfortunately I don't have the backtraces of the crashes anymore. >> >> NB: running 11-CURRENT from usb-stick with ports mounted via nfs. > Well, it's pretty much the same I have, only that the dreamplug has an > internal sd card which is attached via usb. I have ports on nfs as well. >> >> Ronald. >> >> >>> The panic occurred while running nsd-control reload (which should >>> simply re-read a config file from disk). I was previously editing >>> files without issues. >>> >>> Result is the following: >>> >>> vm_fault(0xc10a0000, d0238000, 2, 0) -> 2 >>> Fatal kernel mode data abort: 'Permission Fault (P)' >>> trapframe: 0xde019898 >>> FSR=0000000f, FAR=d0238120, spsr=20000013 >>> r0 =d0238120, r1 =00000e60, r2 =00000000, r3 =00000000 >>> r4 =00000120, r5 =00000000, r6 =c3f3f6c0, r7 =00001000 >>> r8 =c443e880, r9 =00000000, r10=c3d69000, r11=de019a20 >>> r12=d0238120, ssp=de0198e8, slr=c0d53828, pc =c0de521c >>> >>> [ thread pid 21116 tid 100073 ] >>> Stopped at memset+0x48: undge 0xa0cc20f8 >>> db> >>> db> bt >>> Tracing pid 21116 tid 100073 td 0xc3e97000 >>> db_trace_self() at db_trace_self >>> pc = 0xc0dd5418 lr = 0xc094f8a8 (db_hex2dec+0x490) >>> sp = 0xde0195a0 fp = 0xde0195b8 >>> r10 = 0xc0f5e8c8 >>> db_hex2dec() at db_hex2dec+0x490 >>> pc = 0xc094f8a8 lr = 0xc094f260 (db_command_loop+0x300) >>> sp = 0xde0195c0 fp = 0xde019660 >>> r4 = 0x00000000 r5 = 0x00000000 >>> r6 = 0x00000000 >>> db_command_loop() at db_command_loop+0x300 >>> pc = 0xc094f260 lr = 0xc094efb0 (db_command_loop+0x50) >>> sp = 0xde019668 fp = 0xde019678 >>> r4 = 0xc0e2dfe4 r5 = 0xc0e4402e >>> r6 = 0xc0f5e8b4 r7 = 0xc0ef62b8 >>> r8 = 0xc0f52754 r9 = 0xc0f52750 >>> r10 = 0xc3e97000 >>> db_command_loop() at db_command_loop+0x50 >>> pc = 0xc094efb0 lr = 0xc09519ec (X_db_symbol_values+0x250) >>> sp = 0xde019680 fp = 0xde0197a0 >>> r4 = 0x00000000 r5 = 0xc0f5e8c0 >>> r6 = 0xc0f52778 >>> X_db_symbol_values() at X_db_symbol_values+0x250 >>> pc = 0xc09519ec lr = 0xc0b37b08 (kdb_trap+0xc4) >>> sp = 0xde0197a8 fp = 0xde0197c8 >>> r4 = 0x00000000 r5 = 0x0000000f >>> r6 = 0xc0f52778 r7 = 0xc0ef62b8 >>> kdb_trap() at kdb_trap+0xc4 >>> pc = 0xc0b37b08 lr = 0xc0de7c60 (data_abort_handler+0x7f8) >>> sp = 0xde0197d0 fp = 0xde0197e8 >>> r4 = 0xde019898 r5 = 0x0000000f >>> r6 = 0x600000d3 r7 = 0xd0238120 >>> r8 = 0x00000000 r9 = 0xc0f648d4 >>> r10 = 0xc3e97000 >>> data_abort_handler() at data_abort_handler+0x7f8 >>> pc = 0xc0de7c60 lr = 0xc0de7a28 (data_abort_handler+0x5c0) >>> sp = 0xde0197f0 fp = 0xde019890 >>> r4 = 0xc10a0000 r5 = 0x00000013 >>> r6 = 0xde019eb0 r7 = 0x00000002 >>> data_abort_handler() at data_abort_handler+0x5c0 >>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >>> sp = 0xde019898 fp = 0xde019a20 >>> r4 = 0xffffffff r5 = 0xffff1004 >>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>> r8 = 0xc443e880 r9 = 0x00000000 >>> r10 = 0xc3d69000 >>> exception_exit() at exception_exit >>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>> sp = 0xde0198e8 fp = 0xde019a20 >>> r0 = 0xd0238120 r1 = 0x00000e60 >>> r2 = 0x00000000 r3 = 0x00000000 >>> r4 = 0x00000120 r5 = 0x00000000 >>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>> r8 = 0xc443e880 r9 = 0x00000000 >>> r10 = 0xc3d69000 r12 = 0xd0238120 >>> memset() at memset+0x48 >>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>> sp = 0xde0198e8 fp = 0xde019a20 >>> Unwind failure (no registers changed) >>> >>> The sad thing is, that with fsck broken for the dreamplug, I have to >>> re-format the disk, reinstall everything and recreate the config files >>> which I didn't manage to copy to a safe place beforehand :-( >>> >>> Before I do that I'll leave the system in debugging mode for a few >>> days, in case someone can help and needs some more information. >>> >>> Cheers, >>> >>> Mat >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 15:21:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4D238CCD for ; Sun, 28 Sep 2014 15:21:34 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2117911C for ; Sun, 28 Sep 2014 15:21:34 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XYGHu-0009H3-Rq; Sun, 28 Sep 2014 15:21:26 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8SFLP2h009944; Sun, 28 Sep 2014 09:21:25 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX183GtMl/gBgH/FQf1jm9ZEH X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Digi CCWMX53 From: Ian Lepore To: Rui Paulo In-Reply-To: <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com> References: <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com> Content-Type: text/plain; charset="us-ascii" Date: Sun, 28 Sep 2014 09:21:25 -0600 Message-ID: <1411917685.66615.309.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org, Russell Haley X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 15:21:34 -0000 On Sat, 2014-09-27 at 09:30 -0700, Rui Paulo wrote: > On Sep 26, 2014, at 23:19, Russell Haley wrote: > > > > Fantastic, > > > > Thanks so much Warner and Rui. > > > > Rui I've been pouring over your page trying to glean as much as I could > > from it. I'm working with someone else and he tried booting from the > > addresses on your page but since I wasn't building with the cross compiler > > the kernel was never going to boot. He was wondering why the offset for the > > go command when booting from the network (setenv bootcmd 'dhcp; tftpboot > > 0x70800000 kernel.ccwmx53; go 0x70800100')? > > The offset is the entry point of the ELF file. I think we could use U-Boot's bootelf, but I forgot if it works. > > -- > Rui Paulo We can use bootelf on ubldr, but not on the kernel, because our kernel linker script doesn't fill in the physical load address properly in the elf header (it would try to load the virtual address). So the two options for launching the kernel directly are: load kernel; go load kernel.bin; go The standard no-suffix kernel file is an elf binary with the wrong load address in the header, and the header is 0x100 bytes, so the entry point is immediately after that. The kernel.bin file is exactly the same as kernel, but with the elf header stripped off, so the entry point is at an offset of zero. An interesting thing about our kernel is that it can be loaded at any 1MB boundary in physical memory, not just the address it was linked at. There's no way to represent that in an elf header. This is true of both kernel and kernel.bin. -- Ian From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 16:34:53 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27C67CDF for ; Sun, 28 Sep 2014 16:34:53 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EFC4C9DD for ; Sun, 28 Sep 2014 16:34:52 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCM000J9E1U7B40@st11p02mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Sun, 28 Sep 2014 16:34:44 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-28_03:2014-09-26,2014-09-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409280186 Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.4\)) Subject: Re: Digi CCWMX53 From: Rui Paulo In-reply-to: Date: Sun, 28 Sep 2014 09:34:41 -0700 Content-transfer-encoding: quoted-printable Message-id: References: To: Warner Losh X-Mailer: Apple Mail (2.1985.4) Cc: freebsd-arm@freebsd.org, Russell Haley X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 16:34:53 -0000 On Sep 28, 2014, at 00:12, Warner Losh wrote: > A spec for the NAND controller is needed to make that work=85 Is one = about? We have access to U-Boot's source code, so that could also work. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 16:36:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C1A69D27; Sun, 28 Sep 2014 16:36:47 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtp002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 968349EC; Sun, 28 Sep 2014 16:36:47 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCM00NCQE4R1P50@st11p02mm-asmtp002.mac.com>; Sun, 28 Sep 2014 16:36:29 +0000 (GMT) Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.4\)) Subject: Re: Digi CCWMX53 From: Rui Paulo In-reply-to: <1411917685.66615.309.camel@revolution.hippie.lan> Date: Sun, 28 Sep 2014 09:36:27 -0700 Content-transfer-encoding: quoted-printable Message-id: <44EB751E-E53F-46C8-809C-655002C57BC6@me.com> References: <42B4958F-21B2-4ABB-82C9-3F0B328EFED0@me.com> <1411917685.66615.309.camel@revolution.hippie.lan> To: Ian Lepore X-Mailer: Apple Mail (2.1985.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-28_03:2014-09-26,2014-09-28,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409280187 Cc: freebsd-arm@freebsd.org, Russell Haley X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 16:36:47 -0000 On Sep 28, 2014, at 08:21, Ian Lepore wrote: > We can use bootelf on ubldr, but not on the kernel, because our kernel > linker script doesn't fill in the physical load address properly in = the > elf header (it would try to load the virtual address). >=20 > So the two options for launching the kernel directly are: >=20 > load kernel; go > load kernel.bin; go >=20 > The standard no-suffix kernel file is an elf binary with the wrong = load > address in the header, and the header is 0x100 bytes, so the entry = point > is immediately after that. The kernel.bin file is exactly the same as > kernel, but with the elf header stripped off, so the entry point is at > an offset of zero. >=20 > An interesting thing about our kernel is that it can be loaded at any > 1MB boundary in physical memory, not just the address it was linked = at. > There's no way to represent that in an elf header. This is true of = both > kernel and kernel.bin. Ah, I think I made it work once when I set the KERNPHYS (or KERNVIRT?) = to match the load address. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 17:19:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1F9C80F for ; Sun, 28 Sep 2014 17:19:18 +0000 (UTC) Received: from mail-pd0-f175.google.com (mail-pd0-f175.google.com [209.85.192.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A1448D83 for ; Sun, 28 Sep 2014 17:19:18 +0000 (UTC) Received: by mail-pd0-f175.google.com with SMTP id v10so14495799pde.20 for ; Sun, 28 Sep 2014 10:19:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=SJlbkqi5tWoLnpbnCQ/M0GG8mmCN2NU6crwIirMNFFg=; b=arJ56vZxu2g4NtiXMr0Nki4ELxySqj9HUcSXZbUFLU5mtb2KAZU3NLkKKlCTIDLNem NfUh6bGzNLb4IvbXeUsZ7vvvtjEG7/jXMAEkstetfy2VNqh9EWWdTiSvWCnslb1qhE3d j5wUVXWxHI19ji2G7cq6B870ubOaG4DpS5/r0jrVdhI2VgBE7i3Krl+Srg2RPjnjttuI nHbTY/IkCo+Bo7O6Sxnym15hV4q3bFhuj0LlxB/RKYhBVHBlYHFI/tljrhF8Qn/YeS0g CJ3mGe7l+b3XA4H9tiov+6OCBhFA9MUL/QQVy7a/GvMe599XubGydjqH0S7+O08y982c eHNw== X-Gm-Message-State: ALoCoQm7y3Mvt9BrGBvjQ2aLGBYdjKKfpHM47/UKQhFUTEq9sFsZ8JmCJFj/Iy4+2QISmp+FvPij X-Received: by 10.66.191.7 with SMTP id gu7mr53096588pac.32.1411924751871; Sun, 28 Sep 2014 10:19:11 -0700 (PDT) Received: from [172.20.12.175] ([12.145.98.24]) by mx.google.com with ESMTPSA id ki1sm10181410pdb.59.2014.09.28.10.19.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 10:19:11 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_683A035C-2C3F-4A70-B167-6FE44242FF56"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: MK_ARM_EABI to retire in current From: Warner Losh In-Reply-To: <20140928121818.741e7e7e@bender.lan> Date: Sun, 28 Sep 2014 10:19:09 -0700 Message-Id: References: <20140928121818.741e7e7e@bender.lan> To: Andrew Turner X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 17:19:19 -0000 --Apple-Mail=_683A035C-2C3F-4A70-B167-6FE44242FF56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 28, 2014, at 4:18 AM, Andrew Turner wrote: > On Mon, 19 May 2014 09:40:33 -0600 > Warner Losh wrote: >=20 >> Greetings, >>=20 >> MK_ARM_EABI is going to die in current. It is the default for all >> platforms currently. I=92m eliminating it as a build option. It must >> die because it invisibly (to uname) effects the ABI. >>=20 >> So, to that end, I see two options: >>=20 >> (1) Retire and remove oabi support. >> (2) Retain oabi support, but change its name to armo and armoeb. >>=20 >> The rough consensus of arm developers I=92ve polled now, and in the >> past, is that we just let oabi support die now that EABI support is >> working for everybody. >>=20 >> Before I pull the trigger on this, however, I must ask if anybody has >> a problem with my doing option (1), and if so, what keeps you using >> oabi. >>=20 >> Comments? >=20 > As far as I know all the problems with ARM EABI on armeb mentioned > in this thread have been fixed. I think we should now retire the oabi > support and remove MK_ARM_EABI. I=92m game. I think we should move forward on option #1. We=92ve had no = issues in the 10.1 release related to this that I=92m aware of. Should there be = no further objections, my plan is to move forward with this later this week. Warner --Apple-Mail=_683A035C-2C3F-4A70-B167-6FE44242FF56 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKEMNAAoJEGwc0Sh9sBEAkMIP/1ceBEbvJuPZzpMKEDNGxALa N8fQfEL0gwqOeUQPTKGvCmgQN8LtpaZToYRZIZh3KBoknYDVd/UgV4sbRgpVCScb fXyGruHAfbXpWPaDpRCC6Sv9STnyVrstGVnhps6DsKKG1ai49W8/yWnDQ66uPY6z YVF465/6yS8zQAmMCF2j3Zc7xum19Towsvp0ptRJW67tzl+N9BBdsv+SvQqHXmAY ocMLLUj65a5fKgFGXFn6fYLjd7KSt2NAE5uFzU4Uy7PEjNS59JcuSaAc2atg/x0F Esn6oEik1bFk2wCBVqcvgakVgztrzY9OQ3LqfthUQGYTS7v+VW2BT6HBA/aganRO sT/XfuiGz0dQqOxE/6u80jpSEjKM48fljLTYv2p1+brqBtSPqPL1fNXnWdf6rqV0 /E7lK+/HcYTvlM3ACZ9Wdc7ssS4SlEMrMa7pR0pga5Fcfpz4uwHoFkukIdtNZsif il2n5IdiPVXa4HSWt5wxXvWkzu2bI0SO7NnaQ50Vyt/oNjtIIY53CFSvHM6eLsRZ Sx6evJoAzPRLGh2r/DJdxfdh6WF7neiK5kBYdELnuZGPKhpMWD0RqvNiUGjlzjfM isIMhttuw5lPn7zN+mh9IEB16tnNG6m+8n4N5BqLTydobtvk1dO1cDoFS2RyFx4Q z9nUQF09nQWP3b33me5b =MuGK -----END PGP SIGNATURE----- --Apple-Mail=_683A035C-2C3F-4A70-B167-6FE44242FF56-- From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 17:29:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 18E42DF5 for ; Sun, 28 Sep 2014 17:29:58 +0000 (UTC) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8E43E67 for ; Sun, 28 Sep 2014 17:29:57 +0000 (UTC) Received: by mail-pa0-f46.google.com with SMTP id kq14so3050720pab.33 for ; Sun, 28 Sep 2014 10:29:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=dZ2xFz3DvIYhyLaUauzBFt9BTAvRnflRPrrPZ5gaKKE=; b=a3N5J3Ca/Ju+ox3KFR+75HPQd58MfJpcoIiz5rAIr06QLpc0esmrTyzlwvmAm0TnR7 Cm+b9zfkUgF3YJTCoLISUudKY15+I+kNubnh81Xt3LZ7mhVzspbNl+HpPNg+Uvpn/hMd iFX28zEOB1pyk+lekuYSiqtYIa7EozUTMG5sntW4HaGzV8mchRYmQGNLf17p6hqrYsbe XgwhADee7bEnUqZ0V1vfkV2/XASpNjbV6jrehBSBJnxixH6LNSSCrI4MugC6rxowdIqj eEXnLWLf+15Y/NC0UPGBDH/lNVnDbIPM/PvqBJC8Ow2+rh8qeW+JKZkTq1igP7F0mF3Z h4hw== X-Gm-Message-State: ALoCoQkKWq7DIuZJy5q2Ixo79xEdLVjwrOdWjvq1CEpDxb7+zkZ7eq67i2DklqywQ6aAab/OyDtq X-Received: by 10.66.179.140 with SMTP id dg12mr51661011pac.76.1411925390880; Sun, 28 Sep 2014 10:29:50 -0700 (PDT) Received: from [172.20.12.175] ([12.145.98.24]) by mx.google.com with ESMTPSA id f2sm10222053pdd.25.2014.09.28.10.29.49 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Sep 2014 10:29:50 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_DD7944DE-663E-41EE-ADAF-997C2C5B05D7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Sun, 28 Sep 2014 10:29:47 -0700 Message-Id: References: To: Rui Paulo X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org, Russell Haley X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 17:29:58 -0000 --Apple-Mail=_DD7944DE-663E-41EE-ADAF-997C2C5B05D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 28, 2014, at 9:34 AM, Rui Paulo wrote: > On Sep 28, 2014, at 00:12, Warner Losh wrote: >> A spec for the NAND controller is needed to make that work=85 Is one = about? >=20 > We have access to U-Boot's source code, so that could also work. Right. Access to Linux sources too. Without a spec, however, it is my = experience that this source code is helpful, but often incomplete. Warner --Apple-Mail=_DD7944DE-663E-41EE-ADAF-997C2C5B05D7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKEWMAAoJEGwc0Sh9sBEArdQQANOBB6iShdOJv93jFZKad4s8 zIDxbjht2TM7EtgXJLKLsajkkNkG7Ar+PFs/zEJbbeyA+G+GPwuUe5hEmqbuHCLH F35GFIEzpvStxF58uTZm9WEKosKbXSrgsonGyvr70HPS7tgKORzaN5M4xEOI9BD3 N2DzUqSoYpDKXmT+A3IlGDPeb+JydoA3+AMEJIWgNBHV6+Cow4CPghKABQLymFbe 2U0dpKZjc7FIAg6f0mbRi8W7ZCiUnFGou/1u3RZiclTY+ryk8d6gODG3RStYiOBr 2bcdCdJwG1IZbpihBVGmPqsfq+ghmCxFZrUO6d6PWIsZtdcT4mOKmvk7wAnqXLNt Fe5V6wWm6ocryHWDBXn5JnTI7+iyPgqax0KRPTJG9FV7sxJdGKz6jXxXnshzHzXE mqxLd5gCUICpGtSqLMo7muXPGt0P+RbDH9TPBahOAY8A0H+JZQ14I719PyFckbto slHhIhDEQOpGcthLX0KfDIIo+S4xEOib7sF24Hkud1Q+6uWiO7reJGZOY95wBVOl nbDiCxNAiOogz56PEz+WDh/jsrrTzN5tKpVDQYqtun8mou3pxIUQ4RZ9Ks/2kGhP at6IjNQSco1K09dSgMgvkIt+49DA/Ch6YtRY9bKLWvCMIsyCTGuaHJOWoAPaPmIr 2XUYZk8Yd9IBTDOz/IdP =sEV3 -----END PGP SIGNATURE----- --Apple-Mail=_DD7944DE-663E-41EE-ADAF-997C2C5B05D7-- From owner-freebsd-arm@FreeBSD.ORG Sun Sep 28 20:12:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AB1FF863 for ; Sun, 28 Sep 2014 20:12:47 +0000 (UTC) Received: from mail-yk0-x22e.google.com (mail-yk0-x22e.google.com [IPv6:2607:f8b0:4002:c07::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E385FED for ; Sun, 28 Sep 2014 20:12:47 +0000 (UTC) Received: by mail-yk0-f174.google.com with SMTP id q9so4381980ykb.19 for ; Sun, 28 Sep 2014 13:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fTfXaaQAPbSJFvsxBpjBtE0h1wXzuKqZ4N3Bsk8rEc0=; b=VKisYPMnr/xwStWroX5RuEn8qRb3z4ghKqjNukAGmb+3J/GAbOxQu0dHpaTCla+eFC GoUVY/dxYakkj11cyslwUVK/NgSilEbDrwl8pf6rvoKuLvMF5jdqkWpCU7ntBVqMw/yO 6X3IodDRM2rw1a4Be5Qrf0Wo3h+BiTw7dcVAsvc72qSVOo+C2ZBjgKSczESTFIDlcSa9 IvZjDhTuGg19SvenvZRtaNDnNjT7sjP7Y5Wbo2b93GB6XId6RtvyIJfZicxWARCJPXj/ 8DE/JeX7abU3VFFjsD50OKuUCF3jH44ORyep8Wgdbcg3+toMHHN1oQ43mdkZ7WL7amnA lHNw== MIME-Version: 1.0 X-Received: by 10.236.133.65 with SMTP id p41mr50608399yhi.73.1411935166508; Sun, 28 Sep 2014 13:12:46 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Sun, 28 Sep 2014 13:12:46 -0700 (PDT) In-Reply-To: References: Date: Sun, 28 Sep 2014 13:12:46 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 20:12:47 -0000 Rui, I was able to get a linux compatible copy of uboot to load a file from the network last night. I don't have a working BSD kernel right now and it wouldn't boot any of the uimage kernels I tried to upload. I'll work on getting a BSD kernel to build. Russ On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > On Sep 27, 2014, at 13:31, Russell Haley wrote: > > > > Rui, > > > > So no MTD means the NAND on the SOM is out, but can I boot the kernel > and load rootfs from the microSD, like in this example: > > =E2=80=A2 > > ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; g= o > 0x40f00000" > > > > ARNDALE5250 # saveenv > > > > ARNDALE5250 # boot > > You can't use the Arndale config since the load addresses are different. > You should be able to load a kernel from the network. Can you do that? > > -- > Rui Paulo > > > > From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 00:03:55 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EFD32721 for ; Mon, 29 Sep 2014 00:03:55 +0000 (UTC) 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 CA072A87 for ; Mon, 29 Sep 2014 00:03:55 +0000 (UTC) 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; bh=TsM1s/A5spphH3zAriHqJnnezVtuddRHPe1Do8ssJcY=; b=AchoMk/2MbWErUn8/pw6g1ptPOvsnEq2m81wj9YVNAKh+O5Q/eOBoCbyrNXjIMz8M6NUCzs9imvKxWSREHwkHICQuKflG4VzJ8yIjAPKEIqXRlSWL2IHle5PeE5GjNIF/ujw8jlJkIhzlZM+DaLRdmmyGUXflFPjmqhahbwyIk8=; Received: from [182.5.36.225] (port=25148 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYORR-000M7F-1X for freebsd-arm@freebsd.org; Sun, 28 Sep 2014 18:03:49 -0600 Date: Mon, 29 Sep 2014 08:03:37 +0800 From: Erich Dollansky To: freebsd-arm@freebsd.org Subject: Documentation for using GPIO Message-ID: <20140929080337.46bbb5a3@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-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 00:03:56 -0000 Hi, is there some documentation available of how to use GPIO on a Raspberry Pi B+ than man gpio, man gpioctl etc? All the documentation I found was for Linux. Of course, I would like to avoid Linux. Erich From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 01:12:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 64D93493; Mon, 29 Sep 2014 01:12:48 +0000 (UTC) Date: Sun, 28 Sep 2014 21:12:43 -0400 From: Glen Barber To: Erich Dollansky Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929011243.GF75063@hub.FreeBSD.org> References: <20140928155118.GA75063@hub.FreeBSD.org> <20140929090149.34aa1927@X220.alogt.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ShzNbizneSsKYyOp" Content-Disposition: inline In-Reply-To: <20140929090149.34aa1927@X220.alogt.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:12:49 -0000 --ShzNbizneSsKYyOp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [Added freebsd-arm@ and BCC'd re@] On Mon, Sep 29, 2014 at 09:01:49AM +0800, Erich Dollansky wrote: > On Sun, 28 Sep 2014 11:51:18 -0400 > Glen Barber wrote: > > The third BETA build of the 10.1-RELEASE release cycle is now > > available on the FTP servers for the amd64, armv6, i386, ia64, > > powerpc, powerpc64 and sparc64 architectures. > >=20 > is the Raspberry B+ supported or just the Raspberry B? >=20 I am unsure, and do not have access to a RaspberryPi B+ to test. The freebsd-arm@ list is the best place to find the answer to this question. Glen --ShzNbizneSsKYyOp Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUKLILAAoJEAMUWKVHj+KTz8YQAIxhCaPp0X0HGjD+RyVp6V+J tmv/RPGMGwZrfOA+o+FYf91/DWHypV8z/V7Jtbx9xJqcRf4dm8zw1SIii1x4bBKT mhMtxjGNoD+29uPWF2u4b2l46271Mm7uSIIPXQucAt+Pfxg1p20WBbZdhits6NIv iIoLiHtj8qipfsYUpnuiLe0lXCo9Ts+zwibVyKt1HzBDwZb+/N0JkY8ny02rJUga C9w+wL4KfWrZnYPV/fNbym5xp3Ngx2Jzy+1NgKq78mQyD00/qGvZ/0CpRa21oLxm UGxraKywxGsnsz5Uvrr7XlvzVCqJ/wHIaUbR3/EcFDzvxNDesBX1wUU+ZsnqSraQ yBDIfHmu8qgzIzVZqEev9barVIy7MiBW/eIawdHrhSSgIBJWU7VIDw1ENS50bqxW R8ke/00y2wqyt4sZw74ljScSmG1z8Wie8jvZmnY7DW6EHZdMH0hhUNB8nipO7iwm r8lLhm61di0NI5BYWP6iyoGxhV93f17q3pcYhTYv+YejBKPnUUCmYL2S73JeK9XQ 1C0Wit11PTv+Mxy6ZhQ/JfuKknJQBP7ruyq/NIR9p7quXTcHqwErVf+YoQszylr9 kAasduFf18nAUMuIMhnCE0o/5slTFLkCxORUlE2sxnT0OrpJkYivWuLagPnUTPRe U8OcD6baTyFIdVuwdJrW =lRT+ -----END PGP SIGNATURE----- --ShzNbizneSsKYyOp-- From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 01:28:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 196D67EF; Mon, 29 Sep 2014 01:28:48 +0000 (UTC) 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 E11AF19C; Mon, 29 Sep 2014 01:28:47 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Jv3uWBRJOm4FtQAfXPG0agr3GI6ifffAzd/eGZMMxYY=; b=ZSoHEDdbZSAvOWx4zBPr4rmkXAiCNYv/7nPMDJtvteUf71+OBgetok8V1RD7GWjuYdq9Fak0iYUh+mpncrsvGM+E+NsEPM7SKXO/bNSvAdWDTc9QNJbWmSZznUBXDXh7+cYofAeAdWHq4i6b2ypzD0IZzklKVEhrbNE7ebZ/msA=; Received: from [182.5.36.225] (port=56286 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYPld-0011sM-V9; Sun, 28 Sep 2014 19:28:46 -0600 Date: Mon, 29 Sep 2014 09:28:35 +0800 From: Erich Dollansky To: Glen Barber Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929092835.6313304a@X220.alogt.com> In-Reply-To: <20140929011243.GF75063@hub.FreeBSD.org> References: <20140928155118.GA75063@hub.FreeBSD.org> <20140929090149.34aa1927@X220.alogt.com> <20140929011243.GF75063@hub.FreeBSD.org> 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-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 01:28:48 -0000 Hi, On Sun, 28 Sep 2014 21:12:43 -0400 Glen Barber wrote: > [Added freebsd-arm@ and BCC'd re@] > > On Mon, Sep 29, 2014 at 09:01:49AM +0800, Erich Dollansky wrote: > > On Sun, 28 Sep 2014 11:51:18 -0400 > > Glen Barber wrote: > > > The third BETA build of the 10.1-RELEASE release cycle is now > > > available on the FTP servers for the amd64, armv6, i386, ia64, > > > powerpc, powerpc64 and sparc64 architectures. > > > > > is the Raspberry B+ supported or just the Raspberry B? > > > > I am unsure, and do not have access to a RaspberryPi B+ to test. The > freebsd-arm@ list is the best place to find the answer to this > question. > I have one. I will give the build a try after the machine has finished its current task. This can take days. Erich From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 02:36:21 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 161CB569; Mon, 29 Sep 2014 02:36:20 +0000 (UTC) Date: Sun, 28 Sep 2014 22:36:16 -0400 From: Glen Barber To: Erich Dollansky Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929023616.GG75063@hub.FreeBSD.org> References: <20140928155118.GA75063@hub.FreeBSD.org> <20140929090149.34aa1927@X220.alogt.com> <20140929011243.GF75063@hub.FreeBSD.org> <20140929092835.6313304a@X220.alogt.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jb2K77FXt9dSeH4m" Content-Disposition: inline In-Reply-To: <20140929092835.6313304a@X220.alogt.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 02:36:21 -0000 --jb2K77FXt9dSeH4m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote: > On Sun, 28 Sep 2014 21:12:43 -0400 > Glen Barber wrote: > > > is the Raspberry B+ supported or just the Raspberry B? > >=20 > > I am unsure, and do not have access to a RaspberryPi B+ to test. The > > freebsd-arm@ list is the best place to find the answer to this > > question. > >=20 > I have one. I will give the build a try after the machine has finished > its current task. This can take days. >=20 Why not try the images already available here? http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ Glen --jb2K77FXt9dSeH4m Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUKMWgAAoJEAMUWKVHj+KTURUP/jNRO/pi8K/RFofR3BYD3K4D O2yzo43Sgb6U0MuqZfhe/vb96EmeFDKtpEXtcz99PmPzOCDOoyA8MTcnR2yYc3r7 P6Sk1FfBWVws/HeLQrt3gm168y1Uevm7QZYzaOGr3u+5eT78nA42kKPRvXN6ksuh ieOsiIJOYaKFGqd4vUA3o52t8EPA4XCUzHVw8diTWAb/4Iv3EGLGFpRe7ihnJL+1 GjwoOfQ4VcC6uVWI/AD3jttmohAxDWjMuVP22x4cWghVYpQmysTocA+7EAE1bYTj FHdRqBvlLbVSKCqQOBPKg2EEaM37ieH/wSZzL7RV1LE8RPvan3fKfPvMyoSsD51L bNJAiLRuPlRT71dlunX6/hf6fpF5nfg/p9txzAdYBUoYTDyZjiBL9ZYD9uIkl8oE HHRJ1WSCvdI8RV08DqgooQY32CAuhNNMhNRGK62D+w14bidCp9TRIn8E+25ez4Ni GBR64YmNydeGaoQ5zXkyjGxS7jRKZfWNXWJFKhRwpdGijSX6qH2Qn2w9L3OjWQUx yY2yHc84EsSNsa9GJ9JZtBKpAjWKKb+zERSISipn/vhPvHnQaZyLTvX0/bYP3XtQ WVHL/DOfao2DZ22KaEB1SPRtU9f7Ag5vHCVli552wOp61xSwMhdQ+2TaoO3N3coo ieddglEiAhk3Xg1R0Q+I =iu20 -----END PGP SIGNATURE----- --jb2K77FXt9dSeH4m-- From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 03:33:08 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D7A7A1F0; Mon, 29 Sep 2014 03:33:08 +0000 (UTC) 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 9EB27F90; Mon, 29 Sep 2014 03:33:08 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=jCroS9HO9ZZwOvleBBQNz+R88MQAvh9MzMb86/+uhyM=; b=wSZnF7QTWYxGiDnor+TnXkFibXuRoZWgF/ochvUnQH7YAb2yinFwyNv4NLXjH27wkdM25mZy6VtdVx5D6Ev/XsJpKSVTO80CznQ8DF13VqgB0Quz6wC6PqQN5fMRN1LpPghqVgInoKTvjv6hS5m3yGkVFxYzUqRni9L56i6Kq7c=; Received: from [182.5.36.225] (port=41535 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYRhu-0021U9-Kd; Sun, 28 Sep 2014 21:33:03 -0600 Date: Mon, 29 Sep 2014 11:32:30 +0800 From: Erich Dollansky To: Glen Barber Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929113230.144be5da@X220.alogt.com> In-Reply-To: <20140929023616.GG75063@hub.FreeBSD.org> References: <20140928155118.GA75063@hub.FreeBSD.org> <20140929090149.34aa1927@X220.alogt.com> <20140929011243.GF75063@hub.FreeBSD.org> <20140929092835.6313304a@X220.alogt.com> <20140929023616.GG75063@hub.FreeBSD.org> 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-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 03:33:09 -0000 Hi, On Sun, 28 Sep 2014 22:36:16 -0400 Glen Barber wrote: > On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote: > > On Sun, 28 Sep 2014 21:12:43 -0400 > > Glen Barber wrote: > > > > is the Raspberry B+ supported or just the Raspberry B? > > > > > > I am unsure, and do not have access to a RaspberryPi B+ to test. > > > The freebsd-arm@ list is the best place to find the answer to this > > > question. > > > > > I have one. I will give the build a try after the machine has > > finished its current task. This can take days. > > > > Why not try the images already available here? > > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ yes, why not. I downloaded it already and still start to test it later. Is there somewhere a documentation of how this image was build? Erich From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 04:01:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 241E76BE; Mon, 29 Sep 2014 04:01:28 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D66042DB; Mon, 29 Sep 2014 04:01:27 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8T41QRr016219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2014 21:01:27 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8T41QuD016218; Sun, 28 Sep 2014 21:01:26 -0700 (PDT) (envelope-from jmg) Date: Sun, 28 Sep 2014 21:01:26 -0700 From: John-Mark Gurney To: Mattia Rossi Subject: Re: Random Kernel Panic on Dreamplug (FS related) Message-ID: <20140929040126.GG43300@funkthat.com> Mail-Followup-To: Mattia Rossi , freebsd-arm , Ian Lepore References: <542559BC.7090100@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542559BC.7090100@gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 28 Sep 2014 21:01:27 -0700 (PDT) Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 04:01:28 -0000 Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > This might be part of the weird FFS issues the Dreamplug has and no-one > knows why they're happening. Are you running w/ FFS journaling? If so, try turning it off, but keeping softupdates on.. > data_abort_handler() at data_abort_handler+0x5c0 > pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > sp = 0xde019898 fp = 0xde019a20 > r4 = 0xffffffff r5 = 0xffff1004 > r6 = 0xc3f3f6c0 r7 = 0x00001000 > r8 = 0xc443e880 r9 = 0x00000000 > r10 = 0xc3d69000 > exception_exit() at exception_exit > pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > sp = 0xde0198e8 fp = 0xde019a20 > r0 = 0xd0238120 r1 = 0x00000e60 > r2 = 0x00000000 r3 = 0x00000000 > r4 = 0x00000120 r5 = 0x00000000 > r6 = 0xc3f3f6c0 r7 = 0x00001000 > r8 = 0xc443e880 r9 = 0x00000000 > r10 = 0xc3d69000 r12 = 0xd0238120 > memset() at memset+0x48 > pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > sp = 0xde0198e8 fp = 0xde019a20 > Unwind failure (no registers changed) No more beyond this? If you could run addr2line on 0xc0d53828 so that we know where in ffs_truncate it's failing, that'd be very nice... > The sad thing is, that with fsck broken for the dreamplug, I have to > re-format the disk, reinstall everything and recreate the config files > which I didn't manage to copy to a safe place beforehand :-( > > Before I do that I'll leave the system in debugging mode for a few days, > in case someone can help and needs some more information. > > Cheers, > > Mat > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 04:05:34 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F71274A for ; Mon, 29 Sep 2014 04:05:34 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B1932F8 for ; Mon, 29 Sep 2014 04:05:33 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8T45VLx016285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 28 Sep 2014 21:05:32 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8T45U6U016284; Sun, 28 Sep 2014 21:05:30 -0700 (PDT) (envelope-from jmg) Date: Sun, 28 Sep 2014 21:05:30 -0700 From: John-Mark Gurney To: Andrew Turner Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140929040530.GH43300@funkthat.com> Mail-Followup-To: Andrew Turner , Warner Losh , freebsd-arm References: <20140928121818.741e7e7e@bender.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140928121818.741e7e7e@bender.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Sun, 28 Sep 2014 21:05:32 -0700 (PDT) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 04:05:34 -0000 Andrew Turner wrote this message on Sun, Sep 28, 2014 at 12:18 +0100: > On Mon, 19 May 2014 09:40:33 -0600 > Warner Losh wrote: > > > Greetings, > > > > MK_ARM_EABI is going to die in current. It is the default for all > > platforms currently. I?m eliminating it as a build option. It must > > die because it invisibly (to uname) effects the ABI. > > > > So, to that end, I see two options: > > > > (1) Retire and remove oabi support. > > (2) Retain oabi support, but change its name to armo and armoeb. > > > > The rough consensus of arm developers I?ve polled now, and in the > > past, is that we just let oabi support die now that EABI support is > > working for everybody. > > > > Before I pull the trigger on this, however, I must ask if anybody has > > a problem with my doing option (1), and if so, what keeps you using > > oabi. > > > > Comments? > > As far as I know all the problems with ARM EABI on armeb mentioned > in this thread have been fixed. I think we should now retire the oabi > support and remove MK_ARM_EABI. Yeh, I don't know of any issues, though my AVILA board isn't 100% stable as I did get this recently: panic: Fatal abort panic: mtx_lock() by idle thread 0xc0e66320 on sleep mutex eventhandler @ /usr/src.avila/sys/kern/subr_eventhandler.c:251 But, I don't think this is related to EABI... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 04:33:34 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1DD02CB8; Mon, 29 Sep 2014 04:33:34 +0000 (UTC) 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 E92C28A1; Mon, 29 Sep 2014 04:33:33 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=K6IFUiXlsH2QnzSUBqtIcMm2tZyMGN0zOj8J0pmZS18=; b=D8Bjg2GMe0x11Z2qQ2hJ2/LA4UFWE/5eTG6ztxEzu4WhbIvxn2JWd4J7U3ZqDvaPBINGBrESiBra4dZMk7UWx2tkK/gdzSvFLJsxfB9B5uDRZg8WirL83fGcwK5WxXUhyFdckawSHYP/FJZXkmO6/rhQHREiHdDLVzZcLl5Eyzw=; Received: from [182.5.36.225] (port=61812 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYSeR-002RcD-Uy; Sun, 28 Sep 2014 22:33:32 -0600 Date: Mon, 29 Sep 2014 12:33:27 +0800 From: Erich Dollansky To: Glen Barber Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929123327.6ab0207c@X220.alogt.com> In-Reply-To: <20140929023616.GG75063@hub.FreeBSD.org> References: <20140928155118.GA75063@hub.FreeBSD.org> <20140929090149.34aa1927@X220.alogt.com> <20140929011243.GF75063@hub.FreeBSD.org> <20140929092835.6313304a@X220.alogt.com> <20140929023616.GG75063@hub.FreeBSD.org> 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-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 04:33:34 -0000 Hi, On Sun, 28 Sep 2014 22:36:16 -0400 Glen Barber wrote: > On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote: > > On Sun, 28 Sep 2014 21:12:43 -0400 > > Glen Barber wrote: > > > > is the Raspberry B+ supported or just the Raspberry B? > > > > > > I am unsure, and do not have access to a RaspberryPi B+ to test. > > > The freebsd-arm@ list is the best place to find the answer to this > > > question. > > > > > I have one. I will give the build a try after the machine has > > finished its current task. This can take days. > > > > Why not try the images already available here? > > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ > I have tried it now several times. All with the same result. The machine seems to start as the partition is fully expanded. The USB interface does not seem to be recognised. As I do not have monitor cable here, I am not able to do further testing. I will try now to compile the CURRENT sources and see what will happen there. Erich From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 05:46:02 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE32D553; Mon, 29 Sep 2014 05:46:02 +0000 (UTC) Received: from mail2.asahi-net.or.jp (mail2.asahi-net.or.jp [202.224.39.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9E3B4F0B; Mon, 29 Sep 2014 05:46:02 +0000 (UTC) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) by mailssl.asahi-net.or.jp (Postfix) with ESMTP id A023411F01; Mon, 29 Sep 2014 14:27:16 +0900 (JST) Date: Mon, 29 Sep 2014 14:27:12 +0900 (JST) Message-Id: <20140929.142712.117419748410715004.shigeru@os-hackers.jp> To: erichsfreebsdlist@alogt.com Subject: Re: FreeBSD 10.1-BETA3 Now Available From: YAMAMOTO Shigeru In-Reply-To: <20140929123327.6ab0207c@X220.alogt.com> References: <20140929092835.6313304a@X220.alogt.com> <20140929023616.GG75063@hub.FreeBSD.org> <20140929123327.6ab0207c@X220.alogt.com> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gjb@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 05:46:02 -0000 Hi, >>>>> "Erich" == Erich Dollansky writes: > On Sun, 28 Sep 2014 22:36:16 -0400 > Glen Barber wrote: > > Why not try the images already available here? > > > > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ > > > I have tried it now several times. All with the same result. > > The machine seems to start as the partition is fully expanded. The USB > interface does not seem to be recognised. It seems me it is same problem, http://lists.freebsd.org/pipermail/freebsd-arm/2014-July/008872.html Please try to use newer firmware image in your SD image. Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 05:52:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D2EF3875; Mon, 29 Sep 2014 05:52:49 +0000 (UTC) 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 529D9FD; Mon, 29 Sep 2014 05:52:49 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=iwrhMRgdRiiybrRgx3ECsdeZv4+DPHyaUIKGWg6N28k=; b=cQ16HR8GhlMQnASSLqpzLRGuEKEDFWYvhRZf8gAVTxb/ny+PnNJge9UjlMCPH7aAd49PdqypERGE3CSIKfF6S9qL2OhPwDrMgqTClJPPVqbcKYDw2R6LBibM8vJSNMHDedVhAdqB9JOx7/2R3RNDjmLez3VprAFMixq0UC8t0n4=; Received: from [182.5.36.225] (port=12285 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYTt9-003ct6-Gu; Sun, 28 Sep 2014 23:52:48 -0600 Date: Mon, 29 Sep 2014 13:52:32 +0800 From: Erich Dollansky To: YAMAMOTO Shigeru Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929135232.07844765@X220.alogt.com> In-Reply-To: <20140929.142712.117419748410715004.shigeru@os-hackers.jp> References: <20140929092835.6313304a@X220.alogt.com> <20140929023616.GG75063@hub.FreeBSD.org> <20140929123327.6ab0207c@X220.alogt.com> <20140929.142712.117419748410715004.shigeru@os-hackers.jp> 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-Source: X-Source-Args: X-Source-Dir: Cc: gjb@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 05:52:49 -0000 Hi, On Mon, 29 Sep 2014 14:27:12 +0900 (JST) YAMAMOTO Shigeru wrote: > >>>>> "Erich" == Erich Dollansky writes: > > On Sun, 28 Sep 2014 22:36:16 -0400 > > Glen Barber wrote: > > > Why not try the images already available here? > > > > > > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ > > > > > I have tried it now several times. All with the same result. > > > > The machine seems to start as the partition is fully expanded. The > > USB interface does not seem to be recognised. > > It seems me it is same problem, > http://lists.freebsd.org/pipermail/freebsd-arm/2014-July/008872.html > > Please try to use newer firmware image in your SD image. > it seems that this does not solve the problem. I have copied the firmware from a media with a running system to the new image but it did not boot properly either. I am currently compiling 11 on the Raspberry itself. Let me see how far I will come with it. Erich From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 05:54:26 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A0127AB9; Mon, 29 Sep 2014 05:54:26 +0000 (UTC) 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 77B4113D; Mon, 29 Sep 2014 05:54:26 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=dbdghB+28OW5cyGosVkIpJ3xuADZeVSQOW+AY7tF0/Y=; b=FO3QiuPn8hO8s0GC79QuwlnrJ40Ti730jnpo9oWIDEPc5OkfyBv/gWLS/TSPRrbBBZNBnpdY6RZJ06Sv+F8loO1wplE3q82zL5CVk8GwiDjA3cPPpb3egWJ//jq3pV2CU0vDZBLLTEf4R6ib1zq81C5TTouK7NMuHQH+xECIRHg=; Received: from [182.5.36.225] (port=21010 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYTui-003enK-SM; Sun, 28 Sep 2014 23:54:25 -0600 Date: Mon, 29 Sep 2014 13:54:19 +0800 From: Erich Dollansky To: YAMAMOTO Shigeru Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929135419.0eb10c46@X220.alogt.com> In-Reply-To: <20140929.142712.117419748410715004.shigeru@os-hackers.jp> References: <20140929092835.6313304a@X220.alogt.com> <20140929023616.GG75063@hub.FreeBSD.org> <20140929123327.6ab0207c@X220.alogt.com> <20140929.142712.117419748410715004.shigeru@os-hackers.jp> 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-Source: X-Source-Args: X-Source-Dir: Cc: gjb@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 05:54:26 -0000 Hi, On Mon, 29 Sep 2014 14:27:12 +0900 (JST) YAMAMOTO Shigeru wrote: > > It seems me it is same problem, > http://lists.freebsd.org/pipermail/freebsd-arm/2014-July/008872.html > > Please try to use newer firmware image in your SD image. > I forgot to mention that the running Raspberry is using you image. Erich From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 08:42:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3394DC6E; Mon, 29 Sep 2014 08:42:33 +0000 (UTC) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9BFA57B0; Mon, 29 Sep 2014 08:42:32 +0000 (UTC) Received: by mail-wi0-f179.google.com with SMTP id d1so453995wiv.6 for ; Mon, 29 Sep 2014 01:42:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=lKm6fKjfBXyMH2Zza4Ngk+zS6IFPo6L5IFP49mDHfz8=; b=DJoCwjjbuPiVCwiFqD0GoYZYnEjSCezTxg5CWK+6cNMMXMPJ2hAtuJp30PHIRr29rD ciRJxxCzR5ICPP7bKntCNonnS6/mtd4IOc7xi9Uwvc242Paj9+ZV71OY0hNwnDfeaV1b 5aRu+3jMBnI8fLtNNssdDBZeoOMrPNbGqPOB7r5Q0O4x3pr8YkO36BtjG4PI6itJjYcU 7OxHGN9gPloSLrYCuSYa2hDfO/kHW2nqhL0S9ecccH+hYKJHf18DQLxb71AdvRmjRPpL e1AuFy5QIKzWq2/kuHpzhQiGCj+DLh4Mp+b6Dbeq+pFlkf3QrEEGH9KIwo24MnbIb2yg 9XEA== X-Received: by 10.194.206.103 with SMTP id ln7mr42840840wjc.30.1411980149816; Mon, 29 Sep 2014 01:42:29 -0700 (PDT) Received: from [192.168.0.129] (209.212.173.83.static.wline.lns.sme.cust.swisscom.ch. [83.173.212.209]) by mx.google.com with ESMTPSA id fl6sm10893871wib.21.2014.09.29.01.42.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Sep 2014 01:42:29 -0700 (PDT) Message-ID: <54291B74.5010307@gmail.com> Date: Mon, 29 Sep 2014 10:42:28 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm , jmg@funkthat.com Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> In-Reply-To: <20140929040126.GG43300@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 08:42:33 -0000 Am 29.09.2014 06:01, schrieb John-Mark Gurney: > Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >> This might be part of the weird FFS issues the Dreamplug has and no-one >> knows why they're happening. > Are you running w/ FFS journaling? If so, try turning it off, but > keeping softupdates on.. No journaling, no softupdates. I'll try enabling softupdates next time. don't know if it will panic though > >> data_abort_handler() at data_abort_handler+0x5c0 >> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >> sp = 0xde019898 fp = 0xde019a20 >> r4 = 0xffffffff r5 = 0xffff1004 >> r6 = 0xc3f3f6c0 r7 = 0x00001000 >> r8 = 0xc443e880 r9 = 0x00000000 >> r10 = 0xc3d69000 >> exception_exit() at exception_exit >> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >> sp = 0xde0198e8 fp = 0xde019a20 >> r0 = 0xd0238120 r1 = 0x00000e60 >> r2 = 0x00000000 r3 = 0x00000000 >> r4 = 0x00000120 r5 = 0x00000000 >> r6 = 0xc3f3f6c0 r7 = 0x00001000 >> r8 = 0xc443e880 r9 = 0x00000000 >> r10 = 0xc3d69000 r12 = 0xd0238120 >> memset() at memset+0x48 >> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >> sp = 0xde0198e8 fp = 0xde019a20 >> Unwind failure (no registers changed) > No more beyond this? If you could run addr2line on 0xc0d53828 so > that we know where in ffs_truncate it's failing, that'd be very > nice... So I was trying to save the coredump in order to reboot and run addr2line, but that failed: Physical memory: 504 MB Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f 20 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable (da0:umass-sim0:0:0:0): Error 5, Retries exhausted Aborting dump due to I/O error. ** DUMP FAILED (ERROR 5) ** So I guess this error is related to the CAM errors I'm getting from time to time. I was hoping that those errors were related to the INVARIANTS option that slowed down the system and thus might have triggered CAM errors, but obviously the SD Card seems to be the real issue here. So no crashdump for further analysis. Interestingly the CAM errors didn't show up on the terminal as other times, the kernel just panicked straight away. But I've got the addr2line output, even though I'm not sure it makes any difference: addr2line -f -e /mnt/kernel.debug 0xc0d53828 ffs_truncate /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 >> The sad thing is, that with fsck broken for the dreamplug, I have to >> re-format the disk, reinstall everything and recreate the config files >> which I didn't manage to copy to a safe place beforehand :-( Didn't get around yet on checking whether the fsck issue persists if everything is compiled with gcc. Will take a bit, as I'm going to be on holidays for the next one and a half weeks. Fact is though, fsck is broken on the Dreamplug (ARMv5TE), at least when run on EVERY device that is attached via USB and if compiled with CLANG. >> >> Before I do that I'll leave the system in debugging mode for a few days, >> in case someone can help and needs some more information. Currently I've run fsck on all the disks/cards that had a working world for the dreamplug on it, so they're all gone. Can't do eny debugging atm. I'll let you know hoe the gcc build goes once I'm back from holidays though. Cheers, Mat From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 13:49:22 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F2A4E5F7 for ; Mon, 29 Sep 2014 13:49:21 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C644EC9E for ; Mon, 29 Sep 2014 13:49:21 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XYbKD-000EvU-OM; Mon, 29 Sep 2014 13:49:14 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8TDnC6Y012030; Mon, 29 Sep 2014 07:49:12 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18rpvP4/gb5wjga6SpVtHQb X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Random Kernel Panic on Dreamplug (FS related) From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140929040126.GG43300@funkthat.com> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Mon, 29 Sep 2014 07:49:11 -0600 Message-ID: <1411998551.66615.328.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 13:49:22 -0000 On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote: > Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > > This might be part of the weird FFS issues the Dreamplug has and no-one > > knows why they're happening. > > Are you running w/ FFS journaling? If so, try turning it off, but > keeping softupdates on.. > It's not an SU+J problem, or even an SU problem. fsck finds non-existant errors on filesystems known to be clean, and if write-enabled it will corrupt the good filesystem when attempting to correct those "errors". This is on armv4 only, not v6. I tested with and without softupdates on. I tested with UFS1 and UFS2 filesystems. You can even do a newfs followed immediately by an fsck on it and it will corrupt the fs. The one thing I haven't done is opened a PR for this. > > data_abort_handler() at data_abort_handler+0x5c0 > > pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > > sp = 0xde019898 fp = 0xde019a20 > > r4 = 0xffffffff r5 = 0xffff1004 > > r6 = 0xc3f3f6c0 r7 = 0x00001000 > > r8 = 0xc443e880 r9 = 0x00000000 > > r10 = 0xc3d69000 > > exception_exit() at exception_exit > > pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > > sp = 0xde0198e8 fp = 0xde019a20 > > r0 = 0xd0238120 r1 = 0x00000e60 > > r2 = 0x00000000 r3 = 0x00000000 > > r4 = 0x00000120 r5 = 0x00000000 > > r6 = 0xc3f3f6c0 r7 = 0x00001000 > > r8 = 0xc443e880 r9 = 0x00000000 > > r10 = 0xc3d69000 r12 = 0xd0238120 > > memset() at memset+0x48 > > pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > > sp = 0xde0198e8 fp = 0xde019a20 > > Unwind failure (no registers changed) > > No more beyond this? If you could run addr2line on 0xc0d53828 so > that we know where in ffs_truncate it's failing, that'd be very > nice... > Some time in the past 4-6 weeks something has gone wrong with kernel stack backtraces. Sometimes you get a full useful traceback, and more often it ends at the function that triggered the exception, always with a "no registers changed" message. -- Ian > > The sad thing is, that with fsck broken for the dreamplug, I have to > > re-format the disk, reinstall everything and recreate the config files > > which I didn't manage to copy to a safe place beforehand :-( > > > > Before I do that I'll leave the system in debugging mode for a few days, > > in case someone can help and needs some more information. > > > > Cheers, > > > > Mat From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 14:06:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2091ECDF for ; Mon, 29 Sep 2014 14:06:15 +0000 (UTC) Received: from mail-yk0-x234.google.com (mail-yk0-x234.google.com [IPv6:2607:f8b0:4002:c07::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF23AEAF for ; Mon, 29 Sep 2014 14:06:14 +0000 (UTC) Received: by mail-yk0-f180.google.com with SMTP id q9so946010ykb.39 for ; Mon, 29 Sep 2014 07:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9PjNAHWe5TaxaYgD4x8bgELXOyVFeb/B4EcMBs1h5uY=; b=ylSLzH6Y0zWilKsfbd3SUCRYDuYh4PFP2GEZuefpIfI00X45/j3h2+Q6gReOfj6FAg nTusUVqHPZ5LwAZo0qLv1NU3pZnsYQJocwE+8yhqy6BtlRGf1D1lB/LqfyXip7WSXtSd zCLq9ImkXkynDhQr+squXzK/l4n2o/NYAr2eImukwLOHmlJzs5w8ZJA4Ez6UvxKwx7Fz G7DsduAdbD7GFWz4fLicKZ0sEpwd+cOmyZjItF3SmwuNQZXGgNVNVeQYqLtVTplJxFzH hIfs0x9RzEtcVGIqvZFlag4StFpCdqh3OvmM4FCBMuv+qr9mN1uU7s2ivvBUBlR+/v18 mnKQ== MIME-Version: 1.0 X-Received: by 10.236.47.166 with SMTP id t26mr2901656yhb.104.1411999573963; Mon, 29 Sep 2014 07:06:13 -0700 (PDT) Received: by 10.170.138.84 with HTTP; Mon, 29 Sep 2014 07:06:13 -0700 (PDT) Date: Mon, 29 Sep 2014 16:06:13 +0200 Message-ID: Subject: Build RPI packages on a 64bit host From: Zsolt Udvari To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:06:15 -0000 Hi list! I've trying [1] to build packages for Raspberry Pi (B). I've an installed amd64 FreeBSD on my laptop. "For 32-bit targets (i.e. armv6) use an 32-bit host (i.e. i386) or compat-32." How can I use "compat-32"? Should I create a 32-bit chroot, and inside this chroot should I create a build system for arm as written at [1]? Thanks for helping. Zsolt [1] https://wiki.freebsd.org/QemuUserModeHowTo From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 14:24:50 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 837AC653; Mon, 29 Sep 2014 14:24:49 +0000 (UTC) Date: Mon, 29 Sep 2014 10:24:45 -0400 From: Glen Barber To: Erich Dollansky Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20140929142445.GQ75063@hub.FreeBSD.org> References: <20140928155118.GA75063@hub.FreeBSD.org> <20140929090149.34aa1927@X220.alogt.com> <20140929011243.GF75063@hub.FreeBSD.org> <20140929092835.6313304a@X220.alogt.com> <20140929023616.GG75063@hub.FreeBSD.org> <20140929113230.144be5da@X220.alogt.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="nDoN7yiCo0/V4Duf" Content-Disposition: inline In-Reply-To: <20140929113230.144be5da@X220.alogt.com> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:24:50 -0000 --nDoN7yiCo0/V4Duf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Sep 29, 2014 at 11:32:30AM +0800, Erich Dollansky wrote: > On Sun, 28 Sep 2014 22:36:16 -0400 > Glen Barber wrote: > > On Mon, Sep 29, 2014 at 09:28:35AM +0800, Erich Dollansky wrote: > > Why not try the images already available here? > >=20 > > http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ >=20 > yes, why not. I downloaded it already and still start to test it later. >=20 > Is there somewhere a documentation of how this image was build? >=20 The arm images are currently built using Crochet. The documentation is in the README.md file here: https://github.com/kientzle/crochet-freebsd Glen --nDoN7yiCo0/V4Duf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUKWutAAoJEAMUWKVHj+KTX0gP/RsiT7fNRO7VH+jillRFw32v lMCcZ/BSM+IKTHTA2VhhYcw2dhiv0eJlFIW6cLafbU3GVdjWFlPXh3l5MvT2UtHI gTd/UnWrG82PQJXkn8f2K8h5k7ARLUBDxiIUsR77KnMLvtCet4LMoB0+9YhpD5hG hXF1gyZ8QNFJxotb218i1SmfRE7Y0shk3K+wBfiHsIUGElxxh6+jByypSPGbU75I piNGEwDnKrs3ItIaqLVtpZSIi5wT1JyECFT07sboSWnY8IHQHbcmrObfdvpyhhxr G8t31gnUKUhUY8V/Lkmt2ScXq0qL1NrYKMQm97laYBvTpvxoIhCQ0CKh+hzZ7ODJ DrnonDTOhy5RA8Sy26cRVmVljRNotunjISzDhKSeyJ5+0UD43oaRvmp4ch1AutzG /SsZniRUU/rG6S3yDkCFPYnIDqRCKkoluoq6ZN4vbOyczbfk5JFAwce+pJ57EUvm In6mAr7vfmvuUgSwKQbeQptxnGtPKMCc88+Xuk7Ue1hxpz+MG9QCajfDy+5dq0EB +zmau8+CvXutQt6ufoweCfE6E8bjkkOx6POQbW8uDtkkBCPrIwTDGi9OAcC/3ROb TaDdbnsmPW0e7iQD+UGpZKqlV+sGsC+fLnVY4Pt/RKdcYUQAOunO5djXC78It1LN Jwqe2E1yVnQOe6FKQ6AO =Ak+q -----END PGP SIGNATURE----- --nDoN7yiCo0/V4Duf-- From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 16:28:28 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D73E05E6 for ; Mon, 29 Sep 2014 16:28:28 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BE40514B for ; Mon, 29 Sep 2014 16:28:28 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8TGSSYI051040 for ; Mon, 29 Sep 2014 16:28:28 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Mon, 29 Sep 2014 16:28:29 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 16:28:28 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 --- Comment #1 from Danilo Egea Gondolfo --- Same problem on HEAD r272282. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Mon Sep 29 19:27:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CF50A945 for ; Mon, 29 Sep 2014 19:27:28 +0000 (UTC) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 55A93A90 for ; Mon, 29 Sep 2014 19:27:27 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id n15so4160909lbi.26 for ; Mon, 29 Sep 2014 12:27:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OB+V9H4rcE22DyyXjqGuBIVzOQHt4FxXhbxEiMLKQgk=; b=Kc0eCNJ8p4hoiEObk2HFDgKJzUD31dUK+A4pNLDDNPI8+mydCoE3bqzK8Av4TS5qdU pUSfxlZxPow4TqsZaaEudsYQsSo7ZQy2un+4XJck2VYyFrrxXQVFdVKbjkeAcYdGEwlF Omg4vwqp1PpK21NAEm7y4PWJhKOmA3ZaU9n7UrJoGuawASKy7uJ4ZYgRAGNk/Wp1yxFn 6NFa1TTAiG2rsEXQ8zBGfIKeDhB1c+EL4JcKJiR1zuEgioy/NTDNwJ0nNKKEcmSYQWwZ 63qsn1SlNx5Kfkpe/sRMNG5MWJMXN5iAK5P1C0rOhuct7DbIJRdlvEhL+b9O25jRDHEu yWww== MIME-Version: 1.0 X-Received: by 10.112.160.163 with SMTP id xl3mr39316277lbb.80.1412018846102; Mon, 29 Sep 2014 12:27:26 -0700 (PDT) Received: by 10.112.126.39 with HTTP; Mon, 29 Sep 2014 12:27:26 -0700 (PDT) In-Reply-To: <20140929080337.46bbb5a3@X220.alogt.com> References: <20140929080337.46bbb5a3@X220.alogt.com> Date: Mon, 29 Sep 2014 16:27:26 -0300 Message-ID: Subject: Re: Documentation for using GPIO From: Luiz Otavio O Souza To: Erich Dollansky Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 19:27:28 -0000 On 28 September 2014 21:03, Erich Dollansky wrote: > Hi, > > is there some documentation available of how to use GPIO on a Raspberry > Pi B+ than man gpio, man gpioctl etc? > > All the documentation I found was for Linux. Of course, I would like to > avoid Linux. Hi Erich, Unfortunately not, there is the Wiki page (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much. But we can try to help you whenever possible, just post your questions and we'll try to address them. Regards, Luiz From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 00:16:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D0DF4D6 for ; Tue, 30 Sep 2014 00:16:40 +0000 (UTC) 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 A7CE0DD0 for ; Tue, 30 Sep 2014 00:16:40 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=y9IWHjdHkr0uIqoD7rf6S/eVFQNj90TZdvHHzlae7os=; b=RonkXncfd0hqLBNA5rdSdt2rtnI2TsNJl1/k5CNEBQOlV4THJJJvlxNtq9VdtbVpF+8n0QwIa1YE9R5qVWMeGJfNyob3N0/BP3mnYK0NOYc2ScX1QCT9zwurKnAWp1DxYX+PcJVOCYgF3GUeLEXe5ahlZyWr1xMTB6AbT0yK9uk=; Received: from [182.5.218.90] (port=18446 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYl7J-002K1W-7R; Mon, 29 Sep 2014 18:16:34 -0600 Date: Tue, 30 Sep 2014 08:16:18 +0800 From: Erich Dollansky To: Luiz Otavio O Souza Subject: Re: Documentation for using GPIO Message-ID: <20140930081618.122a0c79@X220.alogt.com> In-Reply-To: References: <20140929080337.46bbb5a3@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-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 00:16:40 -0000 Hi Luiz, On Mon, 29 Sep 2014 16:27:26 -0300 Luiz Otavio O Souza wrote: > > is there some documentation available of how to use GPIO on a > > Raspberry Pi B+ than man gpio, man gpioctl etc? > > > Unfortunately not, there is the Wiki page > (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much. > I ave read this. > But we can try to help you whenever possible, just post your questions > and we'll try to address them. I am currently working on a C program which should use GPIO to switch relais and read the state of switches via GPIO. I would like to make this program as simple as possible by creating first a layer which provides then functions like set (Pin), reset (Pin) and read (Pin) only. Of course plus the things needed to open, close and configure the interface. The best I have found until now are the sources of gpioctl. I am currently looking at the source. Is this the best start? Erich From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 00:43:20 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E0E67EB for ; Tue, 30 Sep 2014 00:43:20 +0000 (UTC) Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A792FDC for ; Tue, 30 Sep 2014 00:43:19 +0000 (UTC) Received: by mail-ie0-f174.google.com with SMTP id tr6so2598289ieb.5 for ; Mon, 29 Sep 2014 17:43:13 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=MGYBBFh/ED3avoGO+FbYbToKz4dzrz9eusALoWnF6O8=; b=fdxP/L1QRkeFss13hJzbW9AeRnuZ9n2DPDQSQbTAKLA58h0Ter+0cdany40OtIXKBX ZBwBPDDThGe/o8f+Et2RaZLC/oLA5eKa9IJcz5ivFd+C8hJ9domXpPZzy7F4byDZsWFb gSGWegJO0IboRBAPPKuMiEOll+Z8d5IRvdyqjBAmgnsv9qi20Wgg0nGfA8/fZeG36ziS ORYl5+WECd1sDon7jPeUTEQ588Ok/E9VSQRDt026XbzNV+oAZeK3rBZVONpWENk6Am6P J2ewmRWhzV5NLoSVfxRHqLqzirPmh0SXrCwUEjYYobt9bRZr0K4lkWtq/l+z+nnxmR7J dZQQ== X-Gm-Message-State: ALoCoQlFluRGFaGCxft9V+p2k5Q1jysrUolPmULSBwHRvrbjYK2zKIYoAicYAUbkYcXT9Hc/p6MU MIME-Version: 1.0 X-Received: by 10.42.90.80 with SMTP id j16mr45572337icm.27.1412037473969; Mon, 29 Sep 2014 17:37:53 -0700 (PDT) Received: by 10.64.13.33 with HTTP; Mon, 29 Sep 2014 17:37:53 -0700 (PDT) In-Reply-To: <20140930081618.122a0c79@X220.alogt.com> References: <20140929080337.46bbb5a3@X220.alogt.com> <20140930081618.122a0c79@X220.alogt.com> Date: Mon, 29 Sep 2014 18:37:53 -0600 Message-ID: Subject: Re: Documentation for using GPIO From: Tom Everett To: Erich Dollansky Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 00:43:20 -0000 I published a simple example here. https://github.com/teverett/gpioexample On Mon, Sep 29, 2014 at 6:16 PM, Erich Dollansky < erichsfreebsdlist@alogt.com> wrote: > Hi Luiz, > > On Mon, 29 Sep 2014 16:27:26 -0300 > Luiz Otavio O Souza wrote: > > > > is there some documentation available of how to use GPIO on a > > > Raspberry Pi B+ than man gpio, man gpioctl etc? > > > > > Unfortunately not, there is the Wiki page > > (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much. > > > I ave read this. > > > But we can try to help you whenever possible, just post your questions > > and we'll try to address them. > > I am currently working on a C program which should use GPIO to switch > relais and read the state of switches via GPIO. I would like to make > this program as simple as possible by creating first a layer which > provides then functions like set (Pin), reset (Pin) and read (Pin) > only. Of course plus the things needed to open, close and configure the > interface. > > The best I have found until now are the sources of gpioctl. I am > currently looking at the source. > > Is this the best start? > > Erich > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- A better world shall emerge based on faith and understanding - Douglas MacArthur From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 01:37:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 100B2115 for ; Tue, 30 Sep 2014 01:37:25 +0000 (UTC) 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 DCE83303 for ; Tue, 30 Sep 2014 01:37:24 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=F7PyTJHC9BUE0G5ULxEWuC2XxmpSDg3lPhd6BJERYQM=; b=MbWk/CUaNs3rKrVZq82Sy/1VgcyFON1bCSgZv37ZplWSQXsXd3qnYEuGpvO0puCYGpB7WvSN75rCl3nNp2KCt2aDviwtAHxpqaoYsv0i/0HBR9ayiL1bx8l7M+yvIyq+6Mwr5FMiKHz4pKis8D2O66n9zeTk7eKPHaQbRiyMTDo=; Received: from [182.5.218.90] (port=29362 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYmNX-003A8v-2W; Mon, 29 Sep 2014 19:37:23 -0600 Date: Tue, 30 Sep 2014 09:37:13 +0800 From: Erich Dollansky To: Tom Everett Subject: Re: Documentation for using GPIO Message-ID: <20140930093713.438c9016@X220.alogt.com> In-Reply-To: References: <20140929080337.46bbb5a3@X220.alogt.com> <20140930081618.122a0c79@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-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 01:37:25 -0000 Hi, On Mon, 29 Sep 2014 18:37:53 -0600 Tom Everett wrote: > I published a simple example here. > > https://github.com/teverett/gpioexample > thanks. I already have it on my machine. Your own site has many other useful information too. One general note. At least for me, it is very often very difficult when things are very simple but the simplicity is not stated in documentation. Erich > On Mon, Sep 29, 2014 at 6:16 PM, Erich Dollansky < > erichsfreebsdlist@alogt.com> wrote: > > > Hi Luiz, > > > > On Mon, 29 Sep 2014 16:27:26 -0300 > > Luiz Otavio O Souza wrote: > > > > > > is there some documentation available of how to use GPIO on a > > > > Raspberry Pi B+ than man gpio, man gpioctl etc? > > > > > > > Unfortunately not, there is the Wiki page > > > (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much. > > > > > I ave read this. > > > > > But we can try to help you whenever possible, just post your > > > questions and we'll try to address them. > > > > I am currently working on a C program which should use GPIO to > > switch relais and read the state of switches via GPIO. I would like > > to make this program as simple as possible by creating first a > > layer which provides then functions like set (Pin), reset (Pin) > > and read (Pin) only. Of course plus the things needed to open, > > close and configure the interface. > > > > The best I have found until now are the sources of gpioctl. I am > > currently looking at the source. > > > > Is this the best start? > > > > Erich > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > > "freebsd-arm-unsubscribe@freebsd.org" > > > > > From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 01:48:48 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E95A5202 for ; Tue, 30 Sep 2014 01:48:48 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D0FA0379 for ; Tue, 30 Sep 2014 01:48:48 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s8U1mmb7068861 for ; Tue, 30 Sep 2014 01:48:48 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Tue, 30 Sep 2014 01:48:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 01:48:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 --- Comment #2 from Danilo Egea Gondolfo --- I reverted just r271973 (on 10-stable) and the system boots again. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 03:14:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 192EC3A5 for ; Tue, 30 Sep 2014 03:14:26 +0000 (UTC) Received: from mail-yh0-x236.google.com (mail-yh0-x236.google.com [IPv6:2607:f8b0:4002:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D115EE3C for ; Tue, 30 Sep 2014 03:14:25 +0000 (UTC) Received: by mail-yh0-f54.google.com with SMTP id f10so2846351yha.27 for ; Mon, 29 Sep 2014 20:14:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YfmvJ9OHBjgX3pJpxv1mXq2k/jZfGrTaPVaHftsg6Ts=; b=ftqp5gplYplpnGCp+kteR8FKq1gZAyhtx2m9PGSEUXeWO9MCTZCwKrYXnQAm9EAnY5 SUO7v+lQTRJvlz+2NW4vciottVvABZcP9mGPBKeUup60Ud+kcMgWNYxjdEU/JujBhXsL 21Im4y4zuqc6XyNE3sfAwTgx+gNZC4YSL7fD4JW3pvjMh+Wr0H2f0Rx35cQQRBg8QfRa GjngfUqSZK6bPrRy+gR0Ve3+RJFj9EM7rValLY2kW/fVkM2vo67p7Fup8NMJzMyL3x6c mLbteR9Y3cmkfxBgGxRTz7Fp6pqtbcLLn9C7XZhqL4fyTRLs0djTRHxePvD3d/Z6QTMv ioDg== MIME-Version: 1.0 X-Received: by 10.236.1.167 with SMTP id 27mr62181868yhd.21.1412046864822; Mon, 29 Sep 2014 20:14:24 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Mon, 29 Sep 2014 20:14:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Sep 2014 20:14:24 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Tim Kientzle Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 03:14:26 -0000 Tim, > FreeBSD source has an 'xdev' target that builds and installs a set of cross-tools. In particular, it can install cross-versions of the same GCC or clang used by the rest of FreeBSD. Where can I find more information on cross compiling on FreeBSD? Thanks Russ On Sat, Sep 27, 2014 at 11:53 AM, Tim Kientzle wrote: > > On Sep 26, 2014, at 10:38 PM, Russell Haley wrote: > > > 1) Can anyone give me the correct u-boot enviroment variables or > reference > > to the u-boot process to boot the completed freebsd kernel. Specifically > on > > a CCWMX53 if possible, but I have linux references to port from. Where > > would I look for an example? > > There are two general approaches being used: > > 1) Have U-Boot load and boot the kernel directly. This can sometimes be > done with an unmodified Linux U-Boot. > > 2) Have U-Boot load FreeBSDs scriptable 'ubldr' and have that load the > kernel. This provides more flexibility in the boot process but usually > requires rebuilding U-Boot. In particular, you'll need to: > * Add CONFIG_CMD_ELF option to U-Boot so it can load `ubldr' which is > an ELF executable > * Add CONFIG_CMD_API option to U-Boot so `ubldr' can access U-Boot's > drivers for hardware access (`ubldr' itself has to be compiled for each > board to adjust the load address but is otherwise completely generic). > * Adjust the U-Boot startup scripts to set FDT environment variables > and load ubldr. You can look at the U-Boot patches for various boards > supported by Crochet to see how this has been done elsewhere: > github.com/kientlze/crochet-freebsd > > > > 2) Do I need to create a cross compiler? Reference 1 says yes, reference > > two says no. Help! > > In most cases, the FreeBSD build system will build a cross-compiler for > it's own use, so you generally don't need to install a cross compiler to > cross-build FreeBSD proper. However, U-Boot is not part of FreeBSD so you > may need to install a separate cross-compiler to build that. > > > > > Ref.1 Build a cross compiler > > https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard > > This is using a cross-compiler from ports to build U-Boot. It uses the > FreeBSD build machinery to cross-build the FreeBSD kernel and world. (When > you specify TARGET_ARCH, FreeBSD's 'buildworld' target will build and use a > suitable cross-compiler. Also, 'buildkernel' will reuse the cross-compiler > built by 'buildworld', so you do not need 'kernel-toolchain' as long as you > 'buildworld' first.) > > > > > Ref 2. No cross compiler/ make toolchain > > https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD > > This example only talks about building *world*, and the 'buildworld' > target builds the necessary cross-tools transparently. In particular, > since it doesn't talk about building out-of-tree boot loaders such as > U-Boot, it does not need to talk about building/installing an explicit > cross-compiler. > > For cross-compilers, you have three options: > * Ports. > * After a successful buildworld, you can 'make TARGET=xyz ... buildenv' > to get a shell with suitable path settings to reuse the cross-tools from > the buildworld stage. Use 'buildenvvar' to just get the environment for > use in scripts. > * FreeBSD source has an 'xdev' target that builds and installs a set of > cross-tools. In particular, it can install cross-versions of the same GCC > or clang used by the rest of FreeBSD. This facility has changed a lot > recently, so ask if you need the current command line. > > Hope this clarifies things, > > Tim > > From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 04:41:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9780019A for ; Tue, 30 Sep 2014 04:41:40 +0000 (UTC) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 334CB852 for ; Tue, 30 Sep 2014 04:41:40 +0000 (UTC) Received: by mail-wi0-f171.google.com with SMTP id ho1so4704464wib.4 for ; Mon, 29 Sep 2014 21:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WkKgbFrHd+yNdaKecoE2WNMcbLSNdEohB7cE7XC03NU=; b=gHeT16rzZ+Eh54c5h5M0y2Imb/KMVuddVy7AWDuKTGQ4D3kRvY2lxFyNbFQ8l8rRSg qBaQfV292/XBIapklWa1hkGMk8wT355tAvCRI9WIuCtfRVI0NgXfAxpPEHWtr78XI91C W4MDV+p3k4AleHh/QqFOE2H0Mfv5wRDpAd9E8tLNvkOXRrOxIm1IoniwXW2KNcik0OcG zEnkiHPe38GiyOVU3BrK2Mstg+nx+9XAWvQ5z3rJPCJ95sw5KzSQYqZ+fmZ4FMetRAXk DikFArKd+JeYo8DXKWiyS+jpAiFw9pHo+2fe7pAv3uq2+GQAhCzUAQq5pWvriYUuH3Io yYGA== MIME-Version: 1.0 X-Received: by 10.180.74.9 with SMTP id p9mr2716888wiv.54.1412052098295; Mon, 29 Sep 2014 21:41:38 -0700 (PDT) Received: by 10.216.166.198 with HTTP; Mon, 29 Sep 2014 21:41:38 -0700 (PDT) In-Reply-To: <20140930081618.122a0c79@X220.alogt.com> References: <20140929080337.46bbb5a3@X220.alogt.com> <20140930081618.122a0c79@X220.alogt.com> Date: Tue, 30 Sep 2014 01:41:38 -0300 Message-ID: Subject: Re: Documentation for using GPIO From: Luiz Otavio O Souza To: Erich Dollansky Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 04:41:40 -0000 On 29 September 2014 21:16, Erich Dollansky wrote: > Hi Luiz, > > On Mon, 29 Sep 2014 16:27:26 -0300 > Luiz Otavio O Souza wrote: > >> > is there some documentation available of how to use GPIO on a >> > Raspberry Pi B+ than man gpio, man gpioctl etc? >> > >> Unfortunately not, there is the Wiki page >> (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much. >> > I ave read this. > >> But we can try to help you whenever possible, just post your questions >> and we'll try to address them. > > I am currently working on a C program which should use GPIO to switch > relais and read the state of switches via GPIO. I would like to make > this program as simple as possible by creating first a layer which > provides then functions like set (Pin), reset (Pin) and read (Pin) > only. Of course plus the things needed to open, close and configure the > interface. > > The best I have found until now are the sources of gpioctl. I am > currently looking at the source. > > Is this the best start? You can use the excellent rpaulo's libgpio: https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06bbade8d/libgpio.h?at=default It provides all the GPIO low level functions in a clear and simple way. Luiz From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 05:02:36 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F00A536E for ; Tue, 30 Sep 2014 05:02:36 +0000 (UTC) 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 C8E66A18 for ; Tue, 30 Sep 2014 05:02:36 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=fhR/Z9zNawQAY2bMg6+Av9aBMPB8FYWMOdkz8yLnMew=; b=bhfcGtoVjOlAHkJjbPLC+3k5Xwj4KRZ0ublS2wVN8R6jObW0N7/FoOkqH0uJn3T2HEerihq7EkOAQEUwC671Ku52pVgB66KrVYOParvp5EnJsAFIkN+LQlRYbryWl+0kWSBXYsGooiF57zBf3a6VzglxsgHFKZl4VvgY0WCC3Zc=; Received: from [182.5.218.90] (port=23612 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XYpa6-001RfP-FG; Mon, 29 Sep 2014 23:02:35 -0600 Date: Tue, 30 Sep 2014 13:02:29 +0800 From: Erich Dollansky To: Luiz Otavio O Souza Subject: Re: Documentation for using GPIO Message-ID: <20140930130229.610ef43e@X220.alogt.com> In-Reply-To: References: <20140929080337.46bbb5a3@X220.alogt.com> <20140930081618.122a0c79@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-Source: X-Source-Args: X-Source-Dir: Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 05:02:37 -0000 Hi Luiz, On Tue, 30 Sep 2014 01:41:38 -0300 Luiz Otavio O Souza wrote: > On 29 September 2014 21:16, Erich Dollansky wrote: > > On Mon, 29 Sep 2014 16:27:26 -0300 > > Luiz Otavio O Souza wrote: > > > >> > is there some documentation available of how to use GPIO on a > >> > Raspberry Pi B+ than man gpio, man gpioctl etc? > >> > > >> Unfortunately not, there is the Wiki page > >> (https://wiki.freebsd.org/FreeBSD/GPIO) but it doesn't add much. > >> > > I ave read this. > > > >> But we can try to help you whenever possible, just post your > >> questions and we'll try to address them. > > > > I am currently working on a C program which should use GPIO to > > switch relais and read the state of switches via GPIO. I would like > > to make this program as simple as possible by creating first a > > layer which provides then functions like set (Pin), reset (Pin) > > and read (Pin) only. Of course plus the things needed to open, > > close and configure the interface. > > > > The best I have found until now are the sources of gpioctl. I am > > currently looking at the source. > > > > Is this the best start? > > You can use the excellent rpaulo's libgpio: > > https://bitbucket.org/rpaulo/libgpio/src/1dfe793d0b0cd6caff2e196cf667a5c06bbade8d/libgpio.h?at=default > > It provides all the GPIO low level functions in a clear and simple > way. this looks good too. Erich From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 05:15:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C43E43F for ; Tue, 30 Sep 2014 05:15:15 +0000 (UTC) Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F1D71B20 for ; Tue, 30 Sep 2014 05:15:14 +0000 (UTC) Received: by mail-yh0-f42.google.com with SMTP id t59so1163382yho.1 for ; Mon, 29 Sep 2014 22:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EokoSkx8OvqRqsEfTRs0moTg/AUxI5VP0ZYTDfafPxk=; b=YzjFzIcCoII6+G9m2VlT2UplzIxppwH5/2tEUR76EEtAWfoj9/d+lzglNMU5Jh3rU9 n+imnNwLu93Vd84zNl/XsDiYOPfOwjJ8Svs3mCnNLmgj4EwG+6Uh1IB04C1bVls31DrA vrZanHiFJm0tt0XKO1nW/pA5e5OtiX57eKT4Tq1VbRHzrG9IyDR3JJ0nEezPO4c7hWQT VMYy7OLvONEvqowJwO2IyeItDdWKKH2ptTnkZqMC8wQdy/gIaMN+uXz2YiGY8FJjJVao ouBhOpuTjBP7Gzn1gZzPHlh6u+v6e06sq6cCtMdmwVlU1150DYwZ5NbwYfVrI6NIgg1B /5/Q== MIME-Version: 1.0 X-Received: by 10.236.227.162 with SMTP id d32mr9903459yhq.100.1412054114153; Mon, 29 Sep 2014 22:15:14 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Mon, 29 Sep 2014 22:15:14 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Sep 2014 22:15:14 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 05:15:15 -0000 Rui, I've been able to build a kernel and upload it - again using a "Linux" version of the CCWMX53 u-boot - but it didn't boot. I cloned your git repo but I'm confuded (confused and befuddled or just a typo?) on how to cross compile it. Do I set "devenvvar" (?) to somehow point into my latest buildworld output and then just call make? Again I can only point to the arndale board setup but even those instructions "feel" incomplete to my novice brain. Any direction you could provide would be great. Here is my latest boot output: U-Boot 2009.08 - dub-1.6.4.1 - (Sep 25 2014 - 09:51:55) - GCC 4.4.6 for ConnectCore for i.MX53 on a JumpStart Kit Development Board I2C: ready NAND: 512 MiB MMC: FSL_ESDHC: 0, FSL_ESDHC: 1 DRAM: 1 GB In: serial Out: serial Err: serial Net: FEC0 [PRIME] Hit any key to stop autoboot: 0 FEC: enable RMII gasket Using FEC0 device TFTP from server 192.168.0.55; our IP address is 192.168.0.1 Filename 'kernel.bin'. Load address: 0x70800000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ############ done Bytes transferred =3D 4934472 (4b4b48 hex) ## Starting application at 0x70800100 ... Thanks again! Russ On Sun, Sep 28, 2014 at 1:12 PM, Russell Haley wrote= : > Rui, > > I was able to get a linux compatible copy of uboot to load a file from th= e > network last night. I don't have a working BSD kernel right now and it > wouldn't boot any of the uimage kernels I tried to upload. I'll work on > getting a BSD kernel to build. > > Russ > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > >> On Sep 27, 2014, at 13:31, Russell Haley wrote: >> > >> > Rui, >> > >> > So no MTD means the NAND on the SOM is out, but can I boot the kernel >> and load rootfs from the microSD, like in this example: >> > =E2=80=A2 >> > ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; >> go 0x40f00000" >> > >> > ARNDALE5250 # saveenv >> > >> > ARNDALE5250 # boot >> >> You can't use the Arndale config since the load addresses are different. >> You should be able to load a kernel from the network. Can you do that? >> >> -- >> Rui Paulo >> >> >> >> > From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 06:32:48 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 53CFD6C9 for ; Tue, 30 Sep 2014 06:32:48 +0000 (UTC) Received: from mail-yh0-x22d.google.com (mail-yh0-x22d.google.com [IPv6:2607:f8b0:4002:c01::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 150A8348 for ; Tue, 30 Sep 2014 06:32:48 +0000 (UTC) Received: by mail-yh0-f45.google.com with SMTP id a41so5774888yho.4 for ; Mon, 29 Sep 2014 23:32:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=oRcliR3LP59lWKoiqWIUJ65e0K1rT/1IyXELnr+kHY4=; b=SlIVonJ28H0GWw5aUY1X/RY1rh9WMfpMqoJFffWMTokI+9L+uZdYXE2zxXu13fnqwB Hd52x6yml2QAxqGIC7EDDkS/0sYWgh1Z/WwCGuOEUbGHGqyt+Bh8shlu443Qe1q01MEt gK0W6H4j/ktjQ2+/glKFEF8pzW0fEIhXid3l/PjbLyTpXC9Hh/LTUGV4faDrHuduWV26 QEC++M8zXMPms6u3z6+LRr+UIxYUmz1/iXrg3NNwIM4XiH7aburyFBE+YQHwB05AyzvI s76KrPN2/ZzLHQF6HA8lTBbvXmFUqemFPaJuCwd1Nu2pp9iHRumnq+M2zmt++O1D7hG1 ts/A== MIME-Version: 1.0 X-Received: by 10.236.42.75 with SMTP id i51mr50283914yhb.43.1412058766835; Mon, 29 Sep 2014 23:32:46 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Mon, 29 Sep 2014 23:32:46 -0700 (PDT) In-Reply-To: References: Date: Mon, 29 Sep 2014 23:32:46 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Rui Paulo , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 06:32:48 -0000 OH MY GOD IT BOOTED HOLY CRAP THANK YOU SO MUCH I THINK I JUST PEED MYSELF THIS IS SO F'ING COOL!!!!!! On Mon, Sep 29, 2014 at 11:03 PM, Rui Paulo wrote: > On Sep 29, 2014, at 22:15, Russell Haley wrote: > > > > Rui, > > > > I've been able to build a kernel and upload it - again using a "Linux" > > version of the CCWMX53 u-boot - but it didn't boot. I cloned your git > repo > > but I'm confuded (confused and befuddled or just a typo?) on how to cross > > compile it. Do I set "devenvvar" (?) to somehow point into my latest > > buildworld output and then just call make? Again I can only point to the > > arndale board setup but even those instructions "feel" incomplete to my > > novice brain. > > I've added instructions here: > > https://wiki.freebsd.org/Digi-CCWMX53 > > NOTE: you don't need to install a new U-Boot to boot FreeBSD. > > > Any direction you could provide would be great. Here is my > > latest boot output: > > > > > > U-Boot 2009.08 - dub-1.6.4.1 - (Sep 25 2014 - 09:51:55) - GCC 4.4.6 > > for ConnectCore for i.MX53 on a JumpStart Kit Development Board > > I2C: ready > > NAND: 512 MiB > > MMC: FSL_ESDHC: 0, FSL_ESDHC: 1 > > DRAM: 1 GB > > In: serial > > Out: serial > > Err: serial > > Net: FEC0 [PRIME] > > Hit any key to stop autoboot: 0 > > FEC: enable RMII gasket > > Using FEC0 device > > TFTP from server 192.168.0.55; our IP address is 192.168.0.1 > > Filename 'kernel.bin'. > > Load address: 0x70800000 > > Loading: > ################################################################# > > ################################################################# > > ################################################################# > > ################################################################# > > ################################################################# > > ############ > > done > > Bytes transferred = 4934472 (4b4b48 hex) > > ## Starting application at 0x70800100 ... > > Have you tried the regular kernel? kernel.bin probably has the load > address set to 0. > > -- > Rui Paulo > > > > From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 07:04:24 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08FF9F17 for ; Tue, 30 Sep 2014 07:04:24 +0000 (UTC) Received: from st11p02mm-asmtp001.mac.com (st11p02mm-asmtpout001.mac.com [17.172.220.236]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2869882 for ; Tue, 30 Sep 2014 07:04:23 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp001.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCP00GNPA5YYT00@st11p02mm-asmtp001.mac.com> for freebsd-arm@freebsd.org; Tue, 30 Sep 2014 06:03:36 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-09-30_04:2014-09-29,2014-09-30,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409300070 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1985.4\)) Subject: Re: Digi CCWMX53 From: Rui Paulo In-reply-to: Date: Mon, 29 Sep 2014 23:03:33 -0700 Content-transfer-encoding: quoted-printable Message-id: References: To: Russell Haley X-Mailer: Apple Mail (2.1985.4) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 07:04:24 -0000 On Sep 29, 2014, at 22:15, Russell Haley wrote: >=20 > Rui, >=20 > I've been able to build a kernel and upload it - again using a "Linux" > version of the CCWMX53 u-boot - but it didn't boot. I cloned your git = repo > but I'm confuded (confused and befuddled or just a typo?) on how to = cross > compile it. Do I set "devenvvar" (?) to somehow point into my latest > buildworld output and then just call make? Again I can only point to = the > arndale board setup but even those instructions "feel" incomplete to = my > novice brain. I've added instructions here: https://wiki.freebsd.org/Digi-CCWMX53 NOTE: you don't need to install a new U-Boot to boot FreeBSD. > Any direction you could provide would be great. Here is my > latest boot output: >=20 >=20 > U-Boot 2009.08 - dub-1.6.4.1 - (Sep 25 2014 - 09:51:55) - GCC 4.4.6 > for ConnectCore for i.MX53 on a JumpStart Kit Development Board > I2C: ready > NAND: 512 MiB > MMC: FSL_ESDHC: 0, FSL_ESDHC: 1 > DRAM: 1 GB > In: serial > Out: serial > Err: serial > Net: FEC0 [PRIME] > Hit any key to stop autoboot: 0 > FEC: enable RMII gasket > Using FEC0 device > TFTP from server 192.168.0.55; our IP address is 192.168.0.1 > Filename 'kernel.bin'. > Load address: 0x70800000 > Loading: = ################################################################# > = ################################################################# > = ################################################################# > = ################################################################# > = ################################################################# > ############ > done > Bytes transferred =3D 4934472 (4b4b48 hex) > ## Starting application at 0x70800100 ... Have you tried the regular kernel? kernel.bin probably has the load = address set to 0. =20 -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 11:29:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D315AE; Tue, 30 Sep 2014 11:29:39 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E574DAA7; Tue, 30 Sep 2014 11:29:38 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8UBTbkB042338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 04:29:37 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8UBTb1g042337; Tue, 30 Sep 2014 04:29:37 -0700 (PDT) (envelope-from jmg) Date: Tue, 30 Sep 2014 04:29:37 -0700 From: John-Mark Gurney To: Mattia Rossi Subject: Re: Random Kernel Panic on Dreamplug (FS related) Message-ID: <20140930112937.GU43300@funkthat.com> Mail-Followup-To: Mattia Rossi , freebsd-arm , Ian Lepore References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54291B74.5010307@gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 30 Sep 2014 04:29:37 -0700 (PDT) Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 11:29:39 -0000 Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: > > Am 29.09.2014 06:01, schrieb John-Mark Gurney: > >Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > >>This might be part of the weird FFS issues the Dreamplug has and no-one > >>knows why they're happening. > >Are you running w/ FFS journaling? If so, try turning it off, but > >keeping softupdates on.. > No journaling, no softupdates. I'll try enabling softupdates next time. > don't know if it will panic though > > > >>data_abort_handler() at data_abort_handler+0x5c0 > >> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > >> sp = 0xde019898 fp = 0xde019a20 > >> r4 = 0xffffffff r5 = 0xffff1004 > >> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >> r8 = 0xc443e880 r9 = 0x00000000 > >> r10 = 0xc3d69000 > >>exception_exit() at exception_exit > >> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >> sp = 0xde0198e8 fp = 0xde019a20 > >> r0 = 0xd0238120 r1 = 0x00000e60 > >> r2 = 0x00000000 r3 = 0x00000000 > >> r4 = 0x00000120 r5 = 0x00000000 > >> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >> r8 = 0xc443e880 r9 = 0x00000000 > >> r10 = 0xc3d69000 r12 = 0xd0238120 > >>memset() at memset+0x48 > >> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >> sp = 0xde0198e8 fp = 0xde019a20 > >>Unwind failure (no registers changed) > >No more beyond this? If you could run addr2line on 0xc0d53828 so > >that we know where in ffs_truncate it's failing, that'd be very > >nice... > So I was trying to save the coredump in order to reboot and run > addr2line, but that failed: > > Physical memory: 504 MB > Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f 20 > 00 00 01 00 > (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > Aborting dump due to I/O error. > > ** DUMP FAILED (ERROR 5) ** > > So I guess this error is related to the CAM errors I'm getting from time > to time. I was hoping that those errors were related to the INVARIANTS > option that slowed down the system and thus might have triggered CAM > errors, but obviously the SD Card seems to be the real issue here. > So no crashdump for further analysis. That's fine.. w/ the addr2line we have some lines to explore... > Interestingly the CAM errors didn't show up on the terminal as other > times, the kernel just panicked straight away. Hmm.. that is odd.. someone who knows the SD card layer should look at this part... It could be that the SD card driver doesn't handle dumping (there is this global flag that gets set) properly and the driver needs to behave differently when it's set... > But I've got the addr2line output, even though I'm not sure it makes any > difference: > > addr2line -f -e /mnt/kernel.debug 0xc0d53828 > > ffs_truncate > /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 can you give me the contents of the line? and a few lines of context around it? In HEAD's source, this is DOINGASYNC, and there is no call to memset, nor a variable assignment that would result in memset being called... > >>The sad thing is, that with fsck broken for the dreamplug, I have to > >>re-format the disk, reinstall everything and recreate the config files > >>which I didn't manage to copy to a safe place beforehand :-( > Didn't get around yet on checking whether the fsck issue persists if > everything is compiled with gcc. Will take a bit, as I'm going to be on > holidays for the next one and a half weeks. Fact is though, fsck is > broken on the Dreamplug (ARMv5TE), at least when run on EVERY device > that is attached via USB and if compiled with CLANG. > >> > >>Before I do that I'll leave the system in debugging mode for a few days, > >>in case someone can help and needs some more information. > Currently I've run fsck on all the disks/cards that had a working world > for the dreamplug on it, so they're all gone. Can't do eny debugging > atm. I'll let you know hoe the gcc build goes once I'm back from > holidays though. Hmmm. this is also worth investigating as it could be that clang is producing bad code somewhere... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 11:34:45 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9B5F1C4; Tue, 30 Sep 2014 11:34:45 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A641BB7A; Tue, 30 Sep 2014 11:34:45 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8UBYiua042436 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 04:34:45 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8UBYi53042435; Tue, 30 Sep 2014 04:34:44 -0700 (PDT) (envelope-from jmg) Date: Tue, 30 Sep 2014 04:34:44 -0700 From: John-Mark Gurney To: Ian Lepore Subject: Re: Random Kernel Panic on Dreamplug (FS related) Message-ID: <20140930113444.GV43300@funkthat.com> Mail-Followup-To: Ian Lepore , Mattia Rossi , freebsd-arm References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <1411998551.66615.328.camel@revolution.hippie.lan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1411998551.66615.328.camel@revolution.hippie.lan> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 30 Sep 2014 04:34:45 -0700 (PDT) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 11:34:45 -0000 Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600: > On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote: > > Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > > > This might be part of the weird FFS issues the Dreamplug has and no-one > > > knows why they're happening. > > > > Are you running w/ FFS journaling? If so, try turning it off, but > > keeping softupdates on.. > > > > It's not an SU+J problem, or even an SU problem. fsck finds > non-existant errors on filesystems known to be clean, and if > write-enabled it will corrupt the good filesystem when attempting to > correct those "errors". This is on armv4 only, not v6. I tested with > and without softupdates on. I tested with UFS1 and UFS2 filesystems. > You can even do a newfs followed immediately by an fsck on it and it > will corrupt the fs. > > The one thing I haven't done is opened a PR for this. Hmm... I just tested this on my AVILA board, and I don't see this on either UFS1 or UFS2... Are you doing this via HD or md? My testing was via a 64MB md as I don't have a good way to attach external storage to my board... If you really are seeing immediate corruption to an SD card, then I'd make sure that the card is getting the correct data written to it... I'd suggest trying to run ZFS since it checksums everything it writes, but not sure if it'd run, and if so, how well... > > > data_abort_handler() at data_abort_handler+0x5c0 > > > pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > > > sp = 0xde019898 fp = 0xde019a20 > > > r4 = 0xffffffff r5 = 0xffff1004 > > > r6 = 0xc3f3f6c0 r7 = 0x00001000 > > > r8 = 0xc443e880 r9 = 0x00000000 > > > r10 = 0xc3d69000 > > > exception_exit() at exception_exit > > > pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > > > sp = 0xde0198e8 fp = 0xde019a20 > > > r0 = 0xd0238120 r1 = 0x00000e60 > > > r2 = 0x00000000 r3 = 0x00000000 > > > r4 = 0x00000120 r5 = 0x00000000 > > > r6 = 0xc3f3f6c0 r7 = 0x00001000 > > > r8 = 0xc443e880 r9 = 0x00000000 > > > r10 = 0xc3d69000 r12 = 0xd0238120 > > > memset() at memset+0x48 > > > pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > > > sp = 0xde0198e8 fp = 0xde019a20 > > > Unwind failure (no registers changed) > > > > No more beyond this? If you could run addr2line on 0xc0d53828 so > > that we know where in ffs_truncate it's failing, that'd be very > > nice... > > > > Some time in the past 4-6 weeks something has gone wrong with kernel > stack backtraces. Sometimes you get a full useful traceback, and more > often it ends at the function that triggered the exception, always with > a "no registers changed" message. > > -- Ian > > > > The sad thing is, that with fsck broken for the dreamplug, I have to > > > re-format the disk, reinstall everything and recreate the config files > > > which I didn't manage to copy to a safe place beforehand :-( > > > > > > Before I do that I'll leave the system in debugging mode for a few days, > > > in case someone can help and needs some more information. > > > > > > Cheers, > > > > > > Mat > -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 12:14:33 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F1B03F3; Tue, 30 Sep 2014 12:14:32 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 34298FCF; Tue, 30 Sep 2014 12:14:32 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id hz20so3502790lab.11 for ; Tue, 30 Sep 2014 05:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type; bh=fqVmmDrgqyGl4OIT7maES3T1uXHhMLqGpLuRnxGcDwE=; b=ALnzl0K4oJnZ9K4dAgZ1kir4aaIVDUJCZ8pZ4RxwtL65LybJbrWgoRSDok7b5ZgqEy 6wdZ2ACOtTLQFK+xnk7MuMHhZLEXJnU0jtPVCOb182t7fFlJ/8a9abGAJ3m/l9RXdeFn Umc0u7tSbu8cNHpEIeeAXDjyl9HL58z7cI5FMdjXGAHeT5hd2zTacFzK5bEhcTyH5wi+ ip7+73BCtWT4C062Ay2FSzrf2XI7DvD5RDNgwxJbcHCDGUFGK7VZXZfzaTy+76fKGnQC uRkhNneI69JbwBKOpP6SAEfB3tE39hnYlV8Y34NWy8g/p6Pb23LBdbzzZA8WSF5QWq6Z 5vgw== X-Received: by 10.152.206.35 with SMTP id ll3mr11099430lac.88.1412079269983; Tue, 30 Sep 2014 05:14:29 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:65fd:7630:d87f:4cbe? ([2001:1620:ff0:c51:65fd:7630:d87f:4cbe]) by mx.google.com with ESMTPSA id oh4sm2745079lbc.19.2014.09.30.05.14.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 05:14:29 -0700 (PDT) Message-ID: <542A9EA4.70109@gmail.com> Date: Tue, 30 Sep 2014 14:14:28 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm , jmg@funkthat.com Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> In-Reply-To: <20140930112937.GU43300@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 12:14:33 -0000 Am 30.09.2014 13:29, schrieb John-Mark Gurney: > Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: >> Am 29.09.2014 06:01, schrieb John-Mark Gurney: >>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >>>> This might be part of the weird FFS issues the Dreamplug has and no-one >>>> knows why they're happening. >>> Are you running w/ FFS journaling? If so, try turning it off, but >>> keeping softupdates on.. >> No journaling, no softupdates. I'll try enabling softupdates next time. >> don't know if it will panic though >>>> data_abort_handler() at data_abort_handler+0x5c0 >>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >>>> sp = 0xde019898 fp = 0xde019a20 >>>> r4 = 0xffffffff r5 = 0xffff1004 >>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>> r8 = 0xc443e880 r9 = 0x00000000 >>>> r10 = 0xc3d69000 >>>> exception_exit() at exception_exit >>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>> sp = 0xde0198e8 fp = 0xde019a20 >>>> r0 = 0xd0238120 r1 = 0x00000e60 >>>> r2 = 0x00000000 r3 = 0x00000000 >>>> r4 = 0x00000120 r5 = 0x00000000 >>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>> r8 = 0xc443e880 r9 = 0x00000000 >>>> r10 = 0xc3d69000 r12 = 0xd0238120 >>>> memset() at memset+0x48 >>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>> sp = 0xde0198e8 fp = 0xde019a20 >>>> Unwind failure (no registers changed) >>> No more beyond this? If you could run addr2line on 0xc0d53828 so >>> that we know where in ffs_truncate it's failing, that'd be very >>> nice... >> So I was trying to save the coredump in order to reboot and run >> addr2line, but that failed: >> >> Physical memory: 504 MB >> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 >> 00 00 01 00 >> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable >> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >> Aborting dump due to I/O error. >> >> ** DUMP FAILED (ERROR 5) ** >> >> So I guess this error is related to the CAM errors I'm getting from time >> to time. I was hoping that those errors were related to the INVARIANTS >> option that slowed down the system and thus might have triggered CAM >> errors, but obviously the SD Card seems to be the real issue here. >> So no crashdump for further analysis. > That's fine.. w/ the addr2line we have some lines to explore... > >> Interestingly the CAM errors didn't show up on the terminal as other >> times, the kernel just panicked straight away. > Hmm.. that is odd.. someone who knows the SD card layer should look > at this part... It could be that the SD card driver doesn't handle > dumping (there is this global flag that gets set) properly and the driver > needs to behave differently when it's set... I also need to grab a new SD card, just to make sure it's really not the card. > >> But I've got the addr2line output, even though I'm not sure it makes any >> difference: >> >> addr2line -f -e /mnt/kernel.debug 0xc0d53828 >> >> ffs_truncate >> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 > can you give me the contents of the line? and a few lines of context > around it? In HEAD's source, this is DOINGASYNC, and there is no call > to memset, nor a variable assignment that would result in memset being > called... Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): ip->i_size = length; DIP_SET(ip, i_size, length); if (bp->b_bufsize == fs->fs_bsize) bp->b_flags |= B_CLUSTEROK; if (flags & IO_SYNC) bwrite(bp); 321: else if (DOINGASYNC(vp)) bdwrite(bp); else bawrite(bp); ip->i_flag |= IN_CHANGE | IN_UPDATE; return (ffs_update(vp, !DOINGASYNC(vp))); No idea what's going on. >>>> The sad thing is, that with fsck broken for the dreamplug, I have to >>>> re-format the disk, reinstall everything and recreate the config files >>>> which I didn't manage to copy to a safe place beforehand :-( >> Didn't get around yet on checking whether the fsck issue persists if >> everything is compiled with gcc. Will take a bit, as I'm going to be on >> holidays for the next one and a half weeks. Fact is though, fsck is >> broken on the Dreamplug (ARMv5TE), at least when run on EVERY device >> that is attached via USB and if compiled with CLANG. >>>> Before I do that I'll leave the system in debugging mode for a few days, >>>> in case someone can help and needs some more information. >> Currently I've run fsck on all the disks/cards that had a working world >> for the dreamplug on it, so they're all gone. Can't do eny debugging >> atm. I'll let you know hoe the gcc build goes once I'm back from >> holidays though. > Hmmm. this is also worth investigating as it could be that clang is > producing bad code somewhere... I'm trying to get kernel and world compiled with gcc atm. It fails though, as somehow the armv7 code is currently broken... and the toolchain build is not happy. In file included from /usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36: ./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined (followed by a few more of those) My build command: make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES -DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel installworld From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 12:30:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 736BAAD8; Tue, 30 Sep 2014 12:30:12 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4E72C1E1; Tue, 30 Sep 2014 12:30:12 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s8UCUA0b043273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Sep 2014 05:30:11 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s8UCUAws043272; Tue, 30 Sep 2014 05:30:10 -0700 (PDT) (envelope-from jmg) Date: Tue, 30 Sep 2014 05:30:10 -0700 From: John-Mark Gurney To: Mattia Rossi Subject: Re: Random Kernel Panic on Dreamplug (FS related) Message-ID: <20140930123010.GZ43300@funkthat.com> Mail-Followup-To: Mattia Rossi , freebsd-arm , Ian Lepore References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <542A9EA4.70109@gmail.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Tue, 30 Sep 2014 05:30:11 -0700 (PDT) Cc: freebsd-arm , Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 12:30:12 -0000 Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200: > > Am 30.09.2014 13:29, schrieb John-Mark Gurney: > >Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: > >>Am 29.09.2014 06:01, schrieb John-Mark Gurney: > >>>Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > >>>>This might be part of the weird FFS issues the Dreamplug has and no-one > >>>>knows why they're happening. > >>>Are you running w/ FFS journaling? If so, try turning it off, but > >>>keeping softupdates on.. > >>No journaling, no softupdates. I'll try enabling softupdates next time. > >>don't know if it will panic though > >>>>data_abort_handler() at data_abort_handler+0x5c0 > >>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > >>>> sp = 0xde019898 fp = 0xde019a20 > >>>> r4 = 0xffffffff r5 = 0xffff1004 > >>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >>>> r8 = 0xc443e880 r9 = 0x00000000 > >>>> r10 = 0xc3d69000 > >>>>exception_exit() at exception_exit > >>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >>>> sp = 0xde0198e8 fp = 0xde019a20 > >>>> r0 = 0xd0238120 r1 = 0x00000e60 > >>>> r2 = 0x00000000 r3 = 0x00000000 > >>>> r4 = 0x00000120 r5 = 0x00000000 > >>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >>>> r8 = 0xc443e880 r9 = 0x00000000 > >>>> r10 = 0xc3d69000 r12 = 0xd0238120 > >>>>memset() at memset+0x48 > >>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >>>> sp = 0xde0198e8 fp = 0xde019a20 > >>>>Unwind failure (no registers changed) > >>>No more beyond this? If you could run addr2line on 0xc0d53828 so > >>>that we know where in ffs_truncate it's failing, that'd be very > >>>nice... > >>So I was trying to save the coredump in order to reboot and run > >>addr2line, but that failed: > >> > >>Physical memory: 504 MB > >>Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 > >>00 00 01 00 > >>(da0:umass-sim0:0:0:0): CAM status: Resource Unavailable > >>(da0:umass-sim0:0:0:0): Error 5, Retries exhausted > >>Aborting dump due to I/O error. > >> > >>** DUMP FAILED (ERROR 5) ** > >> > >>So I guess this error is related to the CAM errors I'm getting from time > >>to time. I was hoping that those errors were related to the INVARIANTS > >>option that slowed down the system and thus might have triggered CAM > >>errors, but obviously the SD Card seems to be the real issue here. > >>So no crashdump for further analysis. > >That's fine.. w/ the addr2line we have some lines to explore... > > > >>Interestingly the CAM errors didn't show up on the terminal as other > >>times, the kernel just panicked straight away. > >Hmm.. that is odd.. someone who knows the SD card layer should look > >at this part... It could be that the SD card driver doesn't handle > >dumping (there is this global flag that gets set) properly and the driver > >needs to behave differently when it's set... > > I also need to grab a new SD card, just to make sure it's really not the > card. > > > > >>But I've got the addr2line output, even though I'm not sure it makes any > >>difference: > >> > >>addr2line -f -e /mnt/kernel.debug 0xc0d53828 > >> > >>ffs_truncate > >>/usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 > >can you give me the contents of the line? and a few lines of context > >around it? In HEAD's source, this is DOINGASYNC, and there is no call > >to memset, nor a variable assignment that would result in memset being > >called... > > Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): > > ip->i_size = length; > DIP_SET(ip, i_size, length); > if (bp->b_bufsize == fs->fs_bsize) > bp->b_flags |= B_CLUSTEROK; > if (flags & IO_SYNC) > bwrite(bp); > 321: else if (DOINGASYNC(vp)) > bdwrite(bp); > else > bawrite(bp); > ip->i_flag |= IN_CHANGE | IN_UPDATE; > return (ffs_update(vp, !DOINGASYNC(vp))); > > No idea what's going on. ok, could you send me the output of objdump -dSl, but you only need to include the part from XXXXX : to the next XXX: line... probably off list as it'll be quite long... > >>>>The sad thing is, that with fsck broken for the dreamplug, I have to > >>>>re-format the disk, reinstall everything and recreate the config files > >>>>which I didn't manage to copy to a safe place beforehand :-( > >>Didn't get around yet on checking whether the fsck issue persists if > >>everything is compiled with gcc. Will take a bit, as I'm going to be on > >>holidays for the next one and a half weeks. Fact is though, fsck is > >>broken on the Dreamplug (ARMv5TE), at least when run on EVERY device > >>that is attached via USB and if compiled with CLANG. > >>>>Before I do that I'll leave the system in debugging mode for a few days, > >>>>in case someone can help and needs some more information. > >>Currently I've run fsck on all the disks/cards that had a working world > >>for the dreamplug on it, so they're all gone. Can't do eny debugging > >>atm. I'll let you know hoe the gcc build goes once I'm back from > >>holidays though. > >Hmmm. this is also worth investigating as it could be that clang is > >producing bad code somewhere... > > I'm trying to get kernel and world compiled with gcc atm. It fails > though, as somehow the armv7 code is currently broken... and the > toolchain build is not happy. > > In file included from > /usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36: > ./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined > > (followed by a few more of those) > > My build command: > > make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist > KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES > -DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel > installworld Not sure about this... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 13:46:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 84D4D3C2 for ; Tue, 30 Sep 2014 13:46:30 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 45189D53 for ; Tue, 30 Sep 2014 13:46:29 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XYxl5-000LCX-SR; Tue, 30 Sep 2014 13:46:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8UDkQE9014419; Tue, 30 Sep 2014 07:46:26 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18SlJlEDe9c3OHpHz2ldQk0 X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Random Kernel Panic on Dreamplug (FS related) From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140930112937.GU43300@funkthat.com> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 2014 07:46:26 -0600 Message-ID: <1412084786.66615.356.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 13:46:30 -0000 On Tue, 2014-09-30 at 04:29 -0700, John-Mark Gurney wrote: > Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: > > > > Am 29.09.2014 06:01, schrieb John-Mark Gurney: > > >Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > > >>This might be part of the weird FFS issues the Dreamplug has and no-one > > >>knows why they're happening. > > >Are you running w/ FFS journaling? If so, try turning it off, but > > >keeping softupdates on.. > > No journaling, no softupdates. I'll try enabling softupdates next time. > > don't know if it will panic though > > > > > >>data_abort_handler() at data_abort_handler+0x5c0 > > >> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > > >> sp = 0xde019898 fp = 0xde019a20 > > >> r4 = 0xffffffff r5 = 0xffff1004 > > >> r6 = 0xc3f3f6c0 r7 = 0x00001000 > > >> r8 = 0xc443e880 r9 = 0x00000000 > > >> r10 = 0xc3d69000 > > >>exception_exit() at exception_exit > > >> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > > >> sp = 0xde0198e8 fp = 0xde019a20 > > >> r0 = 0xd0238120 r1 = 0x00000e60 > > >> r2 = 0x00000000 r3 = 0x00000000 > > >> r4 = 0x00000120 r5 = 0x00000000 > > >> r6 = 0xc3f3f6c0 r7 = 0x00001000 > > >> r8 = 0xc443e880 r9 = 0x00000000 > > >> r10 = 0xc3d69000 r12 = 0xd0238120 > > >>memset() at memset+0x48 > > >> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > > >> sp = 0xde0198e8 fp = 0xde019a20 > > >>Unwind failure (no registers changed) > > >No more beyond this? If you could run addr2line on 0xc0d53828 so > > >that we know where in ffs_truncate it's failing, that'd be very > > >nice... > > So I was trying to save the coredump in order to reboot and run > > addr2line, but that failed: > > > > Physical memory: 504 MB > > Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f 20 > > 00 00 01 00 > > (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable > > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > > Aborting dump due to I/O error. > > > > ** DUMP FAILED (ERROR 5) ** > > > > So I guess this error is related to the CAM errors I'm getting from time > > to time. I was hoping that those errors were related to the INVARIANTS > > option that slowed down the system and thus might have triggered CAM > > errors, but obviously the SD Card seems to be the real issue here. > > So no crashdump for further analysis. > > That's fine.. w/ the addr2line we have some lines to explore... > > > Interestingly the CAM errors didn't show up on the terminal as other > > times, the kernel just panicked straight away. > > Hmm.. that is odd.. someone who knows the SD card layer should look > at this part... It could be that the SD card driver doesn't handle > dumping (there is this global flag that gets set) properly and the driver > needs to behave differently when it's set... > On this model of dreamplug, an sdcard is just a usb drive; internally there is a usb<->sd adapter chip, the same one used in many usb multi-format card reader/writers. There's no part of the sdhci/mmc/mmcsd driver stack involved. > > But I've got the addr2line output, even though I'm not sure it makes any > > difference: > > > > addr2line -f -e /mnt/kernel.debug 0xc0d53828 > > > > ffs_truncate > > /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 > > can you give me the contents of the line? and a few lines of context > around it? In HEAD's source, this is DOINGASYNC, and there is no call > to memset, nor a variable assignment that would result in memset being > called... > > > >>The sad thing is, that with fsck broken for the dreamplug, I have to > > >>re-format the disk, reinstall everything and recreate the config files > > >>which I didn't manage to copy to a safe place beforehand :-( > > Didn't get around yet on checking whether the fsck issue persists if > > everything is compiled with gcc. Will take a bit, as I'm going to be on > > holidays for the next one and a half weeks. Fact is though, fsck is > > broken on the Dreamplug (ARMv5TE), at least when run on EVERY device > > that is attached via USB and if compiled with CLANG. > > >> > > >>Before I do that I'll leave the system in debugging mode for a few days, > > >>in case someone can help and needs some more information. > > Currently I've run fsck on all the disks/cards that had a working world > > for the dreamplug on it, so they're all gone. Can't do eny debugging > > atm. I'll let you know hoe the gcc build goes once I'm back from > > holidays though. > > Hmmm. this is also worth investigating as it could be that clang is > producing bad code somewhere... > I tested with a gcc build of -current yesterday and got the same results as with clang -- fsck on a freshly-formatted filesystem says it's corrupted, even when the formatting was done on a non-armv4 system. Also, this is not related to usb or sdcards per se. You can get the same results with a sata drive, or even md(4) (but interestingly, some sizes of md disk have problems and some don't). -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:05:16 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5FAD0170; Tue, 30 Sep 2014 14:05:16 +0000 (UTC) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD1E2F84; Tue, 30 Sep 2014 14:05:15 +0000 (UTC) Received: by mail-lb0-f174.google.com with SMTP id p9so1536383lbv.33 for ; Tue, 30 Sep 2014 07:05:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=JjqUw6WWChcVY6g7VTtBTZxbSWUJnU/9bjrLiK5EuII=; b=gbPnjRJ3lLLGaLT6/X9Z2CXwaPtdMzqm2TdPUclssMlss5Zq+ZRejHQgRW/i+v6Y2I TS5NKvWMUWt38+DrxUGj2+tB5L8jTGpkkeaw935ylWDttE2IiR3OMLlMINbO+hUkcSgI odaAF3q3U+vbZWtfTtxrFTn2ff6OEcNSWVxntZeE4b8Xp2ltZ/tJRWoXjStYNeFOIrf5 rc19v2QzTfNgzLU2j0GotMGCzrSAQre7aAABWXUPF6NP4mSSdu8qC7t8bS6UsUSc2r5D 6I0QvppV311M/jdy2Q3VkeNvO9v6jkc64PplXGaK0ArBsvMUVkF63ZamysM3CZ7yejqV GgLQ== X-Received: by 10.152.7.193 with SMTP id l1mr48037144laa.62.1412085913538; Tue, 30 Sep 2014 07:05:13 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:65fd:7630:d87f:4cbe? ([2001:1620:ff0:c51:65fd:7630:d87f:4cbe]) by mx.google.com with ESMTPSA id jv4sm6099946lbc.35.2014.09.30.07.05.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 07:05:12 -0700 (PDT) Message-ID: <542AB897.3020309@gmail.com> Date: Tue, 30 Sep 2014 16:05:11 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: freebsd-arm , jmg@funkthat.com Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> <20140930123010.GZ43300@funkthat.com> In-Reply-To: <20140930123010.GZ43300@funkthat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:05:16 -0000 Am 30.09.2014 14:30, schrieb John-Mark Gurney: > Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200: >> Am 30.09.2014 13:29, schrieb John-Mark Gurney: >>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: >>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney: >>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one >>>>>> knows why they're happening. >>>>> Are you running w/ FFS journaling? If so, try turning it off, but >>>>> keeping softupdates on.. >>>> No journaling, no softupdates. I'll try enabling softupdates next time. >>>> don't know if it will panic though >>>>>> data_abort_handler() at data_abort_handler+0x5c0 >>>>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >>>>>> sp = 0xde019898 fp = 0xde019a20 >>>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>> r10 = 0xc3d69000 >>>>>> exception_exit() at exception_exit >>>>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>> r0 = 0xd0238120 r1 = 0x00000e60 >>>>>> r2 = 0x00000000 r3 = 0x00000000 >>>>>> r4 = 0x00000120 r5 = 0x00000000 >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>> r10 = 0xc3d69000 r12 = 0xd0238120 >>>>>> memset() at memset+0x48 >>>>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>> Unwind failure (no registers changed) >>>>> No more beyond this? If you could run addr2line on 0xc0d53828 so >>>>> that we know where in ffs_truncate it's failing, that'd be very >>>>> nice... >>>> So I was trying to save the coredump in order to reboot and run >>>> addr2line, but that failed: >>>> >>>> Physical memory: 504 MB >>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 >>>> 00 00 01 00 >>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable >>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >>>> Aborting dump due to I/O error. >>>> >>>> ** DUMP FAILED (ERROR 5) ** >>>> >>>> So I guess this error is related to the CAM errors I'm getting from time >>>> to time. I was hoping that those errors were related to the INVARIANTS >>>> option that slowed down the system and thus might have triggered CAM >>>> errors, but obviously the SD Card seems to be the real issue here. >>>> So no crashdump for further analysis. >>> That's fine.. w/ the addr2line we have some lines to explore... >>> >>>> Interestingly the CAM errors didn't show up on the terminal as other >>>> times, the kernel just panicked straight away. >>> Hmm.. that is odd.. someone who knows the SD card layer should look >>> at this part... It could be that the SD card driver doesn't handle >>> dumping (there is this global flag that gets set) properly and the driver >>> needs to behave differently when it's set... >> I also need to grab a new SD card, just to make sure it's really not the >> card. >> >>>> But I've got the addr2line output, even though I'm not sure it makes any >>>> difference: >>>> >>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828 >>>> >>>> ffs_truncate >>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 >>> can you give me the contents of the line? and a few lines of context >>> around it? In HEAD's source, this is DOINGASYNC, and there is no call >>> to memset, nor a variable assignment that would result in memset being >>> called... >> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): >> >> ip->i_size = length; >> DIP_SET(ip, i_size, length); >> if (bp->b_bufsize == fs->fs_bsize) >> bp->b_flags |= B_CLUSTEROK; >> if (flags & IO_SYNC) >> bwrite(bp); >> 321: else if (DOINGASYNC(vp)) >> bdwrite(bp); >> else >> bawrite(bp); >> ip->i_flag |= IN_CHANGE | IN_UPDATE; >> return (ffs_update(vp, !DOINGASYNC(vp))); >> >> No idea what's going on. > ok, could you send me the output of objdump -dSl, but you only need > to include the part from XXXXX : to the next XXX: > line... probably off list as it'll be quite long... I'm sorry, but given that I just broke all my working worlds using fsck, I'm not going to be able to do that until I'm back from holidays.... currently working on the stuff remotely and after today's work day, I'm not going to be able to get my hands on the dreamplug. From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:05:19 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F086172 for ; Tue, 30 Sep 2014 14:05:19 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 21523F86 for ; Tue, 30 Sep 2014 14:05:18 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XYy3J-000Fii-8k; Tue, 30 Sep 2014 14:05:17 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8UE5GSP014474; Tue, 30 Sep 2014 08:05:16 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18gzKRTSZuPt6DLhrpN+bHM X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Random Kernel Panic on Dreamplug (FS related) From: Ian Lepore To: John-Mark Gurney In-Reply-To: <20140930113444.GV43300@funkthat.com> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <1411998551.66615.328.camel@revolution.hippie.lan> <20140930113444.GV43300@funkthat.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 2014 08:05:15 -0600 Message-ID: <1412085915.66615.360.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:05:19 -0000 On Tue, 2014-09-30 at 04:34 -0700, John-Mark Gurney wrote: > Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600: > > On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote: > > > Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > > > > This might be part of the weird FFS issues the Dreamplug has and no-one > > > > knows why they're happening. > > > > > > Are you running w/ FFS journaling? If so, try turning it off, but > > > keeping softupdates on.. > > > > > > > It's not an SU+J problem, or even an SU problem. fsck finds > > non-existant errors on filesystems known to be clean, and if > > write-enabled it will corrupt the good filesystem when attempting to > > correct those "errors". This is on armv4 only, not v6. I tested with > > and without softupdates on. I tested with UFS1 and UFS2 filesystems. > > You can even do a newfs followed immediately by an fsck on it and it > > will corrupt the fs. > > > > The one thing I haven't done is opened a PR for this. > > Hmm... I just tested this on my AVILA board, and I don't see this on > either UFS1 or UFS2... Are you doing this via HD or md? My testing was > via a 64MB md as I don't have a good way to attach external storage to > my board... > > If you really are seeing immediate corruption to an SD card, then I'd > make sure that the card is getting the correct data written to it... > There isn't actually any corruption on the filesystem until fsck starts trying to fix what it thinks is wrong. That is, fsck -n will report problems, you then move that drive to a non-armv4 system and fsck there reports no problems. If you let armv4 fsck "fix" problems then move the drive to another system and re-check, the filesystem IS corrupted at that point. > I'd suggest trying to run ZFS since it checksums everything it writes, > but not sure if it'd run, and if so, how well... > afaik, nobody has ever tried zfs on any arm platform. Maybe it just works. I'd love to hear from someone about it. I don't have time myself to learn to configure and administer it. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:07:51 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31E2A224 for ; Tue, 30 Sep 2014 14:07:51 +0000 (UTC) Received: from nibbler.fubar.geek.nz (nibbler.fubar.geek.nz [199.48.134.198]) by mx1.freebsd.org (Postfix) with ESMTP id 144B0FAB for ; Tue, 30 Sep 2014 14:07:50 +0000 (UTC) Received: from bender.lan (97e07ab1.skybroadband.com [151.224.122.177]) by nibbler.fubar.geek.nz (Postfix) with ESMTPSA id 1CB355CF51; Tue, 30 Sep 2014 14:07:49 +0000 (UTC) Date: Tue, 30 Sep 2014 15:07:43 +0100 From: Andrew Turner To: Warner Losh Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140930150743.15999c12@bender.lan> In-Reply-To: References: <20140928121818.741e7e7e@bender.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:07:51 -0000 On Sun, 28 Sep 2014 10:19:09 -0700 Warner Losh wrote: > > On Sep 28, 2014, at 4:18 AM, Andrew Turner > wrote: > > > On Mon, 19 May 2014 09:40:33 -0600 > > Warner Losh wrote: > > > >> Greetings, > >> > >> MK_ARM_EABI is going to die in current. It is the default for all > >> platforms currently. I’m eliminating it as a build option. It must > >> die because it invisibly (to uname) effects the ABI. > >> > >> So, to that end, I see two options: > >> > >> (1) Retire and remove oabi support. > >> (2) Retain oabi support, but change its name to armo and armoeb. > >> > >> The rough consensus of arm developers I’ve polled now, and in the > >> past, is that we just let oabi support die now that EABI support is > >> working for everybody. > >> > >> Before I pull the trigger on this, however, I must ask if anybody > >> has a problem with my doing option (1), and if so, what keeps you > >> using oabi. > >> > >> Comments? > > > > As far as I know all the problems with ARM EABI on armeb mentioned > > in this thread have been fixed. I think we should now retire the > > oabi support and remove MK_ARM_EABI. > > I’m game. I think we should move forward on option #1. We’ve had no > issues in the 10.1 release related to this that I’m aware of. Should > there be no further objections, my plan is to move forward with this > later this week. I've created a change for review at [1]. Andrew [1] https://reviews.freebsd.org/D876 From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:15:47 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E1DB502; Tue, 30 Sep 2014 14:15:47 +0000 (UTC) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9A3E0124; Tue, 30 Sep 2014 14:15:46 +0000 (UTC) Received: by mail-la0-f43.google.com with SMTP id gb8so10831060lab.30 for ; Tue, 30 Sep 2014 07:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=4KfAUvdRSmbaZ299sJoCuRisYBqoor8NNkzaO/IXdbg=; b=zbYeNH1Kuvdqat/KG9XCeYuyoiQEbV/M4yjVpzbsBFPfmgTrYlYKOdu5P2dTkLUPgn MME6pt160heLqS8dzbAFSGU73HMu8aRqpO03nxUXFqnfltM7aMrqnAcADcZHLBHHoGD6 +Y6eK3X/IqdCtXL/l+nci5kj1v7mgh3UZls0T7F0Yccl0bqBHeBEXlkdUi/846NONgu1 BRWlZo2/zj4Le1nApSYyf6vOyllx6qi2cXcIjiPKcEx6pxj+hoASIq6y0JoQLmAfR3Wy +eJefwBPMT8a/R1EJWMUU8bgp0QoqX0GA3xsw4hwrYaptNOFMDacaBF4VVDRGM9YyobM Ksbg== X-Received: by 10.112.180.137 with SMTP id do9mr44642730lbc.63.1412086544612; Tue, 30 Sep 2014 07:15:44 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:65fd:7630:d87f:4cbe? ([2001:1620:ff0:c51:65fd:7630:d87f:4cbe]) by mx.google.com with ESMTPSA id ll12sm6067703lac.45.2014.09.30.07.15.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 07:15:44 -0700 (PDT) Message-ID: <542ABB0F.8080201@gmail.com> Date: Tue, 30 Sep 2014 16:15:43 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore , freebsd-arm Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <1411998551.66615.328.camel@revolution.hippie.lan> <20140930113444.GV43300@funkthat.com> <1412085915.66615.360.camel@revolution.hippie.lan> In-Reply-To: <1412085915.66615.360.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:15:47 -0000 Am 30.09.2014 16:05, schrieb Ian Lepore: > On Tue, 2014-09-30 at 04:34 -0700, John-Mark Gurney wrote: >> Ian Lepore wrote this message on Mon, Sep 29, 2014 at 07:49 -0600: >>> On Sun, 2014-09-28 at 21:01 -0700, John-Mark Gurney wrote: >>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >>>>> This might be part of the weird FFS issues the Dreamplug has and no-one >>>>> knows why they're happening. >>>> Are you running w/ FFS journaling? If so, try turning it off, but >>>> keeping softupdates on.. >>>> >>> It's not an SU+J problem, or even an SU problem. fsck finds >>> non-existant errors on filesystems known to be clean, and if >>> write-enabled it will corrupt the good filesystem when attempting to >>> correct those "errors". This is on armv4 only, not v6. I tested with >>> and without softupdates on. I tested with UFS1 and UFS2 filesystems. >>> You can even do a newfs followed immediately by an fsck on it and it >>> will corrupt the fs. >>> >>> The one thing I haven't done is opened a PR for this. >> Hmm... I just tested this on my AVILA board, and I don't see this on >> either UFS1 or UFS2... Are you doing this via HD or md? My testing was >> via a 64MB md as I don't have a good way to attach external storage to >> my board... >> >> If you really are seeing immediate corruption to an SD card, then I'd >> make sure that the card is getting the correct data written to it... >> > There isn't actually any corruption on the filesystem until fsck starts > trying to fix what it thinks is wrong. That is, fsck -n will report > problems, you then move that drive to a non-armv4 system and fsck there > reports no problems. If you let armv4 fsck "fix" problems then move the > drive to another system and re-check, the filesystem IS corrupted at > that point. > >> I'd suggest trying to run ZFS since it checksums everything it writes, >> but not sure if it'd run, and if so, how well... >> > afaik, nobody has ever tried zfs on any arm platform. Maybe it just > works. I'd love to hear from someone about it. I don't have time > myself to learn to configure and administer it. I think there are at least a few people that tried it (http://lists.freebsd.org/pipermail/freebsd-arm/2014-February/007455.html). I've tried it as well (on an external ESATA disk), but had some performance problems, which I think could be resolved if I would run a bootloader (which I don't). The other solution would be to apply the following patch, and tweak performance via sysctls on a running system: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=187594 Anyhow, first things first.. From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:17:45 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 225A9570 for ; Tue, 30 Sep 2014 14:17:45 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D6F27136 for ; Tue, 30 Sep 2014 14:17:44 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XYyFL-000NgS-Nu; Tue, 30 Sep 2014 14:17:43 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8UEHgOT014502; Tue, 30 Sep 2014 08:17:42 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19uvsQLOejs8b6/I2co7C+K X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Random Kernel Panic on Dreamplug (FS related) From: Ian Lepore To: Mattia Rossi In-Reply-To: <542A9EA4.70109@gmail.com> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 2014 08:17:41 -0600 Message-ID: <1412086661.66615.361.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:17:45 -0000 On Tue, 2014-09-30 at 14:14 +0200, Mattia Rossi wrote: > Am 30.09.2014 13:29, schrieb John-Mark Gurney: > > Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: > >> Am 29.09.2014 06:01, schrieb John-Mark Gurney: > >>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > >>>> This might be part of the weird FFS issues the Dreamplug has and no-one > >>>> knows why they're happening. > >>> Are you running w/ FFS journaling? If so, try turning it off, but > >>> keeping softupdates on.. > >> No journaling, no softupdates. I'll try enabling softupdates next time. > >> don't know if it will panic though > >>>> data_abort_handler() at data_abort_handler+0x5c0 > >>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > >>>> sp = 0xde019898 fp = 0xde019a20 > >>>> r4 = 0xffffffff r5 = 0xffff1004 > >>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >>>> r8 = 0xc443e880 r9 = 0x00000000 > >>>> r10 = 0xc3d69000 > >>>> exception_exit() at exception_exit > >>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >>>> sp = 0xde0198e8 fp = 0xde019a20 > >>>> r0 = 0xd0238120 r1 = 0x00000e60 > >>>> r2 = 0x00000000 r3 = 0x00000000 > >>>> r4 = 0x00000120 r5 = 0x00000000 > >>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >>>> r8 = 0xc443e880 r9 = 0x00000000 > >>>> r10 = 0xc3d69000 r12 = 0xd0238120 > >>>> memset() at memset+0x48 > >>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >>>> sp = 0xde0198e8 fp = 0xde019a20 > >>>> Unwind failure (no registers changed) > >>> No more beyond this? If you could run addr2line on 0xc0d53828 so > >>> that we know where in ffs_truncate it's failing, that'd be very > >>> nice... > >> So I was trying to save the coredump in order to reboot and run > >> addr2line, but that failed: > >> > >> Physical memory: 504 MB > >> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 > >> 00 00 01 00 > >> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable > >> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > >> Aborting dump due to I/O error. > >> > >> ** DUMP FAILED (ERROR 5) ** > >> > >> So I guess this error is related to the CAM errors I'm getting from time > >> to time. I was hoping that those errors were related to the INVARIANTS > >> option that slowed down the system and thus might have triggered CAM > >> errors, but obviously the SD Card seems to be the real issue here. > >> So no crashdump for further analysis. > > That's fine.. w/ the addr2line we have some lines to explore... > > > >> Interestingly the CAM errors didn't show up on the terminal as other > >> times, the kernel just panicked straight away. > > Hmm.. that is odd.. someone who knows the SD card layer should look > > at this part... It could be that the SD card driver doesn't handle > > dumping (there is this global flag that gets set) properly and the driver > > needs to behave differently when it's set... > > I also need to grab a new SD card, just to make sure it's really not the > card. > > > > >> But I've got the addr2line output, even though I'm not sure it makes any > >> difference: > >> > >> addr2line -f -e /mnt/kernel.debug 0xc0d53828 > >> > >> ffs_truncate > >> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 > > can you give me the contents of the line? and a few lines of context > > around it? In HEAD's source, this is DOINGASYNC, and there is no call > > to memset, nor a variable assignment that would result in memset being > > called... > > Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): > > ip->i_size = length; > DIP_SET(ip, i_size, length); > if (bp->b_bufsize == fs->fs_bsize) > bp->b_flags |= B_CLUSTEROK; > if (flags & IO_SYNC) > bwrite(bp); > 321: else if (DOINGASYNC(vp)) > bdwrite(bp); > else > bawrite(bp); > ip->i_flag |= IN_CHANGE | IN_UPDATE; > return (ffs_update(vp, !DOINGASYNC(vp))); > > No idea what's going on. > > >>>> The sad thing is, that with fsck broken for the dreamplug, I have to > >>>> re-format the disk, reinstall everything and recreate the config files > >>>> which I didn't manage to copy to a safe place beforehand :-( > >> Didn't get around yet on checking whether the fsck issue persists if > >> everything is compiled with gcc. Will take a bit, as I'm going to be on > >> holidays for the next one and a half weeks. Fact is though, fsck is > >> broken on the Dreamplug (ARMv5TE), at least when run on EVERY device > >> that is attached via USB and if compiled with CLANG. > >>>> Before I do that I'll leave the system in debugging mode for a few days, > >>>> in case someone can help and needs some more information. > >> Currently I've run fsck on all the disks/cards that had a working world > >> for the dreamplug on it, so they're all gone. Can't do eny debugging > >> atm. I'll let you know hoe the gcc build goes once I'm back from > >> holidays though. > > Hmmm. this is also worth investigating as it could be that clang is > > producing bad code somewhere... > > I'm trying to get kernel and world compiled with gcc atm. It fails > though, as somehow the armv7 code is currently broken... and the > toolchain build is not happy. > > In file included from > /usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36: > ./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined > > (followed by a few more of those) > > My build command: > > make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist > KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES > -DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel > installworld The build was broken briefly yesterday, you must have grabbed it during that window. But... I did a gcc build and got the same results as with clang. -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:19:58 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09EBC6D0 for ; Tue, 30 Sep 2014 14:19:58 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BD87B176 for ; Tue, 30 Sep 2014 14:19:57 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XYyHU-000P4h-Kp; Tue, 30 Sep 2014 14:19:56 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s8UEJtZE014511; Tue, 30 Sep 2014 08:19:55 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ZvQPcsdDII3Em8eB9or9i X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Random Kernel Panic on Dreamplug (FS related) From: Ian Lepore To: Mattia Rossi In-Reply-To: <542AB897.3020309@gmail.com> References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> <20140930123010.GZ43300@funkthat.com> <542AB897.3020309@gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 30 Sep 2014 08:19:55 -0600 Message-ID: <1412086795.66615.363.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:19:58 -0000 On Tue, 2014-09-30 at 16:05 +0200, Mattia Rossi wrote: > Am 30.09.2014 14:30, schrieb John-Mark Gurney: > > Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200: > >> Am 30.09.2014 13:29, schrieb John-Mark Gurney: > >>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: > >>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney: > >>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: > >>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one > >>>>>> knows why they're happening. > >>>>> Are you running w/ FFS journaling? If so, try turning it off, but > >>>>> keeping softupdates on.. > >>>> No journaling, no softupdates. I'll try enabling softupdates next time. > >>>> don't know if it will panic though > >>>>>> data_abort_handler() at data_abort_handler+0x5c0 > >>>>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) > >>>>>> sp = 0xde019898 fp = 0xde019a20 > >>>>>> r4 = 0xffffffff r5 = 0xffff1004 > >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >>>>>> r8 = 0xc443e880 r9 = 0x00000000 > >>>>>> r10 = 0xc3d69000 > >>>>>> exception_exit() at exception_exit > >>>>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >>>>>> sp = 0xde0198e8 fp = 0xde019a20 > >>>>>> r0 = 0xd0238120 r1 = 0x00000e60 > >>>>>> r2 = 0x00000000 r3 = 0x00000000 > >>>>>> r4 = 0x00000120 r5 = 0x00000000 > >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 > >>>>>> r8 = 0xc443e880 r9 = 0x00000000 > >>>>>> r10 = 0xc3d69000 r12 = 0xd0238120 > >>>>>> memset() at memset+0x48 > >>>>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) > >>>>>> sp = 0xde0198e8 fp = 0xde019a20 > >>>>>> Unwind failure (no registers changed) > >>>>> No more beyond this? If you could run addr2line on 0xc0d53828 so > >>>>> that we know where in ffs_truncate it's failing, that'd be very > >>>>> nice... > >>>> So I was trying to save the coredump in order to reboot and run > >>>> addr2line, but that failed: > >>>> > >>>> Physical memory: 504 MB > >>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 > >>>> 00 00 01 00 > >>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable > >>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > >>>> Aborting dump due to I/O error. > >>>> > >>>> ** DUMP FAILED (ERROR 5) ** > >>>> > >>>> So I guess this error is related to the CAM errors I'm getting from time > >>>> to time. I was hoping that those errors were related to the INVARIANTS > >>>> option that slowed down the system and thus might have triggered CAM > >>>> errors, but obviously the SD Card seems to be the real issue here. > >>>> So no crashdump for further analysis. > >>> That's fine.. w/ the addr2line we have some lines to explore... > >>> > >>>> Interestingly the CAM errors didn't show up on the terminal as other > >>>> times, the kernel just panicked straight away. > >>> Hmm.. that is odd.. someone who knows the SD card layer should look > >>> at this part... It could be that the SD card driver doesn't handle > >>> dumping (there is this global flag that gets set) properly and the driver > >>> needs to behave differently when it's set... > >> I also need to grab a new SD card, just to make sure it's really not the > >> card. > >> > >>>> But I've got the addr2line output, even though I'm not sure it makes any > >>>> difference: > >>>> > >>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828 > >>>> > >>>> ffs_truncate > >>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 > >>> can you give me the contents of the line? and a few lines of context > >>> around it? In HEAD's source, this is DOINGASYNC, and there is no call > >>> to memset, nor a variable assignment that would result in memset being > >>> called... > >> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): > >> > >> ip->i_size = length; > >> DIP_SET(ip, i_size, length); > >> if (bp->b_bufsize == fs->fs_bsize) > >> bp->b_flags |= B_CLUSTEROK; > >> if (flags & IO_SYNC) > >> bwrite(bp); > >> 321: else if (DOINGASYNC(vp)) > >> bdwrite(bp); > >> else > >> bawrite(bp); > >> ip->i_flag |= IN_CHANGE | IN_UPDATE; > >> return (ffs_update(vp, !DOINGASYNC(vp))); > >> > >> No idea what's going on. > > ok, could you send me the output of objdump -dSl, but you only need > > to include the part from XXXXX : to the next XXX: > > line... probably off list as it'll be quite long... > I'm sorry, but given that I just broke all my working worlds using fsck, > I'm not going to be able to do that until I'm back from holidays.... > currently working on the stuff remotely and after today's work day, I'm > not going to be able to get my hands on the dreamplug. > > BTW, for anyone playing with this problem, step one is to edit your /etc/fstab and set the fsck pass number to 0 for all filesystems. There's a risk of filesystem corruption after a crash, but it's smaller than the 100% corruption rate of letting fsck run. :) -- Ian From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:26:04 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E3C59AEE; Tue, 30 Sep 2014 14:26:04 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3C7CE25F; Tue, 30 Sep 2014 14:26:03 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id n15so8426901lbi.29 for ; Tue, 30 Sep 2014 07:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=mOM4gQAsKWMlLROVg16SKTd8x/bX/7UfdaZk0GhKwv4=; b=lsddPrJV9i+TeJP6AhvCiq4Ny+gkD5o5da6vvp7jEUi4HWfUXUKP23g8C9IqC1Ss1v 7QCpsCJqNX/5ibElCKw9tZ1EjjlDFaIzCBbBruD4lu5mCxbzHr+gJ0UhFCFTRFqISY8F wbn0gkidIIURB5UboF1sI9OjM8OYIOfdtOeW4yP6t5Azj+bNuenrPKvkVU+ipLrIpRcI u1DKUu2CO7GqSqciBFHY3Yx+XFJc5SPUZgdkAAZuDrnvBbUzTkeYb2dKhFmBRkF8Bu33 3i3kUoOBXD6l+TNSkOAfrVmyv8HtkF0A2RsZSzmlI3AcD0+bLDBAdiLNv/SJrHvXxKGh IWMg== X-Received: by 10.112.34.210 with SMTP id b18mr45305851lbj.62.1412087161471; Tue, 30 Sep 2014 07:26:01 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:65fd:7630:d87f:4cbe? ([2001:1620:ff0:c51:65fd:7630:d87f:4cbe]) by mx.google.com with ESMTPSA id ug7sm6076493lac.48.2014.09.30.07.26.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 07:26:00 -0700 (PDT) Message-ID: <542ABD76.1050602@gmail.com> Date: Tue, 30 Sep 2014 16:25:58 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> <1412086661.66615.361.camel@revolution.hippie.lan> In-Reply-To: <1412086661.66615.361.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:26:05 -0000 Am 30.09.2014 16:17, schrieb Ian Lepore: > On Tue, 2014-09-30 at 14:14 +0200, Mattia Rossi wrote: >> Am 30.09.2014 13:29, schrieb John-Mark Gurney: >>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: >>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney: >>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one >>>>>> knows why they're happening. >>>>> Are you running w/ FFS journaling? If so, try turning it off, but >>>>> keeping softupdates on.. >>>> No journaling, no softupdates. I'll try enabling softupdates next time. >>>> don't know if it will panic though >>>>>> data_abort_handler() at data_abort_handler+0x5c0 >>>>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >>>>>> sp = 0xde019898 fp = 0xde019a20 >>>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>> r10 = 0xc3d69000 >>>>>> exception_exit() at exception_exit >>>>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>> r0 = 0xd0238120 r1 = 0x00000e60 >>>>>> r2 = 0x00000000 r3 = 0x00000000 >>>>>> r4 = 0x00000120 r5 = 0x00000000 >>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>> r10 = 0xc3d69000 r12 = 0xd0238120 >>>>>> memset() at memset+0x48 >>>>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>> Unwind failure (no registers changed) >>>>> No more beyond this? If you could run addr2line on 0xc0d53828 so >>>>> that we know where in ffs_truncate it's failing, that'd be very >>>>> nice... >>>> So I was trying to save the coredump in order to reboot and run >>>> addr2line, but that failed: >>>> >>>> Physical memory: 504 MB >>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 >>>> 00 00 01 00 >>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable >>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >>>> Aborting dump due to I/O error. >>>> >>>> ** DUMP FAILED (ERROR 5) ** >>>> >>>> So I guess this error is related to the CAM errors I'm getting from time >>>> to time. I was hoping that those errors were related to the INVARIANTS >>>> option that slowed down the system and thus might have triggered CAM >>>> errors, but obviously the SD Card seems to be the real issue here. >>>> So no crashdump for further analysis. >>> That's fine.. w/ the addr2line we have some lines to explore... >>> >>>> Interestingly the CAM errors didn't show up on the terminal as other >>>> times, the kernel just panicked straight away. >>> Hmm.. that is odd.. someone who knows the SD card layer should look >>> at this part... It could be that the SD card driver doesn't handle >>> dumping (there is this global flag that gets set) properly and the driver >>> needs to behave differently when it's set... >> I also need to grab a new SD card, just to make sure it's really not the >> card. >> >>>> But I've got the addr2line output, even though I'm not sure it makes any >>>> difference: >>>> >>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828 >>>> >>>> ffs_truncate >>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 >>> can you give me the contents of the line? and a few lines of context >>> around it? In HEAD's source, this is DOINGASYNC, and there is no call >>> to memset, nor a variable assignment that would result in memset being >>> called... >> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): >> >> ip->i_size = length; >> DIP_SET(ip, i_size, length); >> if (bp->b_bufsize == fs->fs_bsize) >> bp->b_flags |= B_CLUSTEROK; >> if (flags & IO_SYNC) >> bwrite(bp); >> 321: else if (DOINGASYNC(vp)) >> bdwrite(bp); >> else >> bawrite(bp); >> ip->i_flag |= IN_CHANGE | IN_UPDATE; >> return (ffs_update(vp, !DOINGASYNC(vp))); >> >> No idea what's going on. >> >>>>>> The sad thing is, that with fsck broken for the dreamplug, I have to >>>>>> re-format the disk, reinstall everything and recreate the config files >>>>>> which I didn't manage to copy to a safe place beforehand :-( >>>> Didn't get around yet on checking whether the fsck issue persists if >>>> everything is compiled with gcc. Will take a bit, as I'm going to be on >>>> holidays for the next one and a half weeks. Fact is though, fsck is >>>> broken on the Dreamplug (ARMv5TE), at least when run on EVERY device >>>> that is attached via USB and if compiled with CLANG. >>>>>> Before I do that I'll leave the system in debugging mode for a few days, >>>>>> in case someone can help and needs some more information. >>>> Currently I've run fsck on all the disks/cards that had a working world >>>> for the dreamplug on it, so they're all gone. Can't do eny debugging >>>> atm. I'll let you know hoe the gcc build goes once I'm back from >>>> holidays though. >>> Hmmm. this is also worth investigating as it could be that clang is >>> producing bad code somewhere... >> I'm trying to get kernel and world compiled with gcc atm. It fails >> though, as somehow the armv7 code is currently broken... and the >> toolchain build is not happy. >> >> In file included from >> /usr/devel/dreamplug/sys/arm/arm/cpufunc_asm_armv7.S:36: >> ./machine/sysreg.h:97:5: error: "__ARM_ARCH" is not defined >> >> (followed by a few more of those) >> >> My build command: >> >> make TARGET=arm TARGET_ARCH=arm DESTDIR=/usr/devel/dreamplug-dist >> KERNCONF=DREAMPLUG-1001 -DWITHOUT_SHAREDOCS -DWITHOUT_EXAMPLES >> -DWITHOUT_HTML -DWITHOUT_MAN -DWITHOUT_GAMES toolchain buildworld kernel >> installworld > > The build was broken briefly yesterday, you must have grabbed it during > that window. > > But... I did a gcc build and got the same results as with clang. > Thanks, I just read that, so I'm going to pass on this :-) From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 14:29:30 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 10E0FB89; Tue, 30 Sep 2014 14:29:30 +0000 (UTC) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 52A20299; Tue, 30 Sep 2014 14:29:29 +0000 (UTC) Received: by mail-la0-f52.google.com with SMTP id hz20so3691543lab.25 for ; Tue, 30 Sep 2014 07:29:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=vjB/FGCxYS9ucM0ep36SlNY+qBFS0ycWWYTcot8CQQQ=; b=gg4bFQCNHcVE6EndT8NlaCJlplkN70x9CbQ5NaFbfsLKtrzFI4CVI5f5LLS9oUulHA y9Rgd7rjs2pHdVDLzvijIPC8PW0/BMYZv6MMdGes3C2HPOQyFu6HxVPi/ukFgA/FvwvX uQ7GPK4Cj8ZpP2Qsz9tsINblaSh2K1t/Okkfg80qL6BoHRA+YkKYr9PvhkRrW9DBBIIg o1GI4y8NfcneQ2pEMnc0wpb/Q7PneLYVZ+2euE2paNbPNamE4wutKfM0krfkPsRFtV9N ZBAqyoQAryPxqYdT0V/X0C6b6kKpV8JdhaOaIQM3iJEWmBwXem9NNyMINcKcyD6vK/5m JGXA== X-Received: by 10.152.5.100 with SMTP id r4mr25570887lar.41.1412087367351; Tue, 30 Sep 2014 07:29:27 -0700 (PDT) Received: from ?IPv6:2001:1620:ff0:c51:65fd:7630:d87f:4cbe? ([2001:1620:ff0:c51:65fd:7630:d87f:4cbe]) by mx.google.com with ESMTPSA id kw10sm6129942lbc.17.2014.09.30.07.29.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 07:29:26 -0700 (PDT) Message-ID: <542ABE45.3020402@gmail.com> Date: Tue, 30 Sep 2014 16:29:25 +0200 From: Mattia Rossi User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ian Lepore Subject: Re: Random Kernel Panic on Dreamplug (FS related) References: <542559BC.7090100@gmail.com> <20140929040126.GG43300@funkthat.com> <54291B74.5010307@gmail.com> <20140930112937.GU43300@funkthat.com> <542A9EA4.70109@gmail.com> <20140930123010.GZ43300@funkthat.com> <542AB897.3020309@gmail.com> <1412086795.66615.363.camel@revolution.hippie.lan> In-Reply-To: <1412086795.66615.363.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 14:29:30 -0000 Am 30.09.2014 16:19, schrieb Ian Lepore: > On Tue, 2014-09-30 at 16:05 +0200, Mattia Rossi wrote: >> Am 30.09.2014 14:30, schrieb John-Mark Gurney: >>> Mattia Rossi wrote this message on Tue, Sep 30, 2014 at 14:14 +0200: >>>> Am 30.09.2014 13:29, schrieb John-Mark Gurney: >>>>> Mattia Rossi wrote this message on Mon, Sep 29, 2014 at 10:42 +0200: >>>>>> Am 29.09.2014 06:01, schrieb John-Mark Gurney: >>>>>>> Mattia Rossi wrote this message on Fri, Sep 26, 2014 at 14:19 +0200: >>>>>>>> This might be part of the weird FFS issues the Dreamplug has and no-one >>>>>>>> knows why they're happening. >>>>>>> Are you running w/ FFS journaling? If so, try turning it off, but >>>>>>> keeping softupdates on.. >>>>>> No journaling, no softupdates. I'll try enabling softupdates next time. >>>>>> don't know if it will panic though >>>>>>>> data_abort_handler() at data_abort_handler+0x5c0 >>>>>>>> pc = 0xc0de7a28 lr = 0xc0dd711c (exception_exit) >>>>>>>> sp = 0xde019898 fp = 0xde019a20 >>>>>>>> r4 = 0xffffffff r5 = 0xffff1004 >>>>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>>>> r10 = 0xc3d69000 >>>>>>>> exception_exit() at exception_exit >>>>>>>> pc = 0xc0dd711c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>>>> r0 = 0xd0238120 r1 = 0x00000e60 >>>>>>>> r2 = 0x00000000 r3 = 0x00000000 >>>>>>>> r4 = 0x00000120 r5 = 0x00000000 >>>>>>>> r6 = 0xc3f3f6c0 r7 = 0x00001000 >>>>>>>> r8 = 0xc443e880 r9 = 0x00000000 >>>>>>>> r10 = 0xc3d69000 r12 = 0xd0238120 >>>>>>>> memset() at memset+0x48 >>>>>>>> pc = 0xc0de521c lr = 0xc0d53828 (ffs_truncate+0xaa8) >>>>>>>> sp = 0xde0198e8 fp = 0xde019a20 >>>>>>>> Unwind failure (no registers changed) >>>>>>> No more beyond this? If you could run addr2line on 0xc0d53828 so >>>>>>> that we know where in ffs_truncate it's failing, that'd be very >>>>>>> nice... >>>>>> So I was trying to save the coredump in order to reboot and run >>>>>> addr2line, but that failed: >>>>>> >>>>>> Physical memory: 504 MB >>>>>> Dumping 67 MB:(da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 01 d5 1f20 >>>>>> 00 00 01 00 >>>>>> (da0:umass-sim0:0:0:0): CAM status: Resource Unavailable >>>>>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >>>>>> Aborting dump due to I/O error. >>>>>> >>>>>> ** DUMP FAILED (ERROR 5) ** >>>>>> >>>>>> So I guess this error is related to the CAM errors I'm getting from time >>>>>> to time. I was hoping that those errors were related to the INVARIANTS >>>>>> option that slowed down the system and thus might have triggered CAM >>>>>> errors, but obviously the SD Card seems to be the real issue here. >>>>>> So no crashdump for further analysis. >>>>> That's fine.. w/ the addr2line we have some lines to explore... >>>>> >>>>>> Interestingly the CAM errors didn't show up on the terminal as other >>>>>> times, the kernel just panicked straight away. >>>>> Hmm.. that is odd.. someone who knows the SD card layer should look >>>>> at this part... It could be that the SD card driver doesn't handle >>>>> dumping (there is this global flag that gets set) properly and the driver >>>>> needs to behave differently when it's set... >>>> I also need to grab a new SD card, just to make sure it's really not the >>>> card. >>>> >>>>>> But I've got the addr2line output, even though I'm not sure it makes any >>>>>> difference: >>>>>> >>>>>> addr2line -f -e /mnt/kernel.debug 0xc0d53828 >>>>>> >>>>>> ffs_truncate >>>>>> /usr/devel/dreamplug/sys/ufs/ffs/ffs_inode.c:321 >>>>> can you give me the contents of the line? and a few lines of context >>>>> around it? In HEAD's source, this is DOINGASYNC, and there is no call >>>>> to memset, nor a variable assignment that would result in memset being >>>>> called... >>>> Same here.. The file hasn't been changed in a while (Fri, 31 May 2013): >>>> >>>> ip->i_size = length; >>>> DIP_SET(ip, i_size, length); >>>> if (bp->b_bufsize == fs->fs_bsize) >>>> bp->b_flags |= B_CLUSTEROK; >>>> if (flags & IO_SYNC) >>>> bwrite(bp); >>>> 321: else if (DOINGASYNC(vp)) >>>> bdwrite(bp); >>>> else >>>> bawrite(bp); >>>> ip->i_flag |= IN_CHANGE | IN_UPDATE; >>>> return (ffs_update(vp, !DOINGASYNC(vp))); >>>> >>>> No idea what's going on. >>> ok, could you send me the output of objdump -dSl, but you only need >>> to include the part from XXXXX : to the next XXX: >>> line... probably off list as it'll be quite long... >> I'm sorry, but given that I just broke all my working worlds using fsck, >> I'm not going to be able to do that until I'm back from holidays.... >> currently working on the stuff remotely and after today's work day, I'm >> not going to be able to get my hands on the dreamplug. >> >> > BTW, for anyone playing with this problem, step one is to edit > your /etc/fstab and set the fsck pass number to 0 for all filesystems. > There's a risk of filesystem corruption after a crash, but it's smaller > than the 100% corruption rate of letting fsck run. :) > Of course! Great idea :-) Sometimes just can't think of the right tweak to save a lot of pain... Anyhow, I just found out, that I was rebooting the dreamplug from the sd card instead of the usb stick the whole time, and the usb stick hasn't been damaged enough by fsck, so it actually booted :-) I'll send the objdump soon. From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 16:25:12 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BD91E150; Tue, 30 Sep 2014 16:25:12 +0000 (UTC) Received: from mail1.asahi-net.or.jp (mail1.asahi-net.or.jp [202.224.39.197]) by mx1.freebsd.org (Postfix) with ESMTP id 82955360; Tue, 30 Sep 2014 16:25:11 +0000 (UTC) Received: from localhost (w142149.ppp.asahi-net.or.jp [121.1.142.149]) by mailssl.asahi-net.or.jp (Postfix) with ESMTP id E3C0A192ED; Wed, 1 Oct 2014 01:05:31 +0900 (JST) Date: Wed, 01 Oct 2014 01:05:28 +0900 (JST) Message-Id: <20141001.010528.1222668648660002950.shigeru@os-hackers.jp> To: erichsfreebsdlist@alogt.com Subject: Re: FreeBSD 10.1-BETA3 Now Available From: YAMAMOTO Shigeru In-Reply-To: <20140929.142712.117419748410715004.shigeru@os-hackers.jp> References: <20140929023616.GG75063@hub.FreeBSD.org> <20140929123327.6ab0207c@X220.alogt.com> <20140929.142712.117419748410715004.shigeru@os-hackers.jp> X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: gjb@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 16:25:12 -0000 Hi, >>>>> "shigeru" == YAMAMOTO Shigeru writes: >>>>> "Erich" == Erich Dollansky writes: >> On Sun, 28 Sep 2014 22:36:16 -0400 Glen Barber wrote: >> Why not try the images already available here? >> http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ >> I have tried it now several times. All with the same result. I get SD image, FreeBSD-10.1-BETA3-arm-armv6-RPI-B.img.bz2, from that URL. When using original SD image, I can't boot because a kernel does not find root file system. I get a new firmware from https://github.com/raspberrypi/firmware/ and I replace *.dat, *.elf in SD image. # git clone https://github.com/raspberrypi/firmware.git # mount_msdosfs /dev/da0s1 /mnt # cp ./firmware/boot/*.dat /mnt/. # cp ./firmware/boot/*.elf /mnt/. # umount /mnt After replacing firmware image in SD image, I can boot RaspberryPi B+. ------------------------------------------------------------------------ root@raspberry-pi:~ # dmesg KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.1-BETA3 #0 r272167: Fri Sep 26 16:53:33 UTC 2014 root@releng1.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI-B arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 VT: init without driver. CPU: ARM1176JZ-S rev 7 (ARM11J core) Supported features: ARM_ISA THUMB2 JAZELLE ARMv4 Security_Ext WB enabled LABT branch prediction enabled 16KB/32B 4-way instruction cache 16KB/32B 4-way write-back-locking-C data cache real memory = 536866816 (511 MB) avail memory = 482893824 (460 MB) random: initialized kbd0 at kbdmux0 ofwbus0: simplebus0: mem 0x20000000-0x20ffffff on ofwbus0 intc0: mem 0xb200-0xb3ff on simplebus0 systimer0: mem 0x3000-0x3fff irq 8,9,10,11 on simplebus0 Event timer "BCM2835 Event Timer 3" frequency 1000000 Hz quality 1000 Timecounter "BCM2835 Timecounter" frequency 1000000 Hz quality 1000 bcmwd0: mem 0x10001c-0x100027 on simplebus0 gpio0: mem 0x200000-0x2000af irq 57,59,58,60 on simplebus0 gpio0: read-only pins: 46,47,48,49,50,51,52,53. gpio0: reserved pins: 48,49,50,51,52,53. gpioc0: on gpio0 gpiobus0: on gpio0 gpioled0: at pin(s) 16 on gpiobus0 iichb0: mem 0x205000-0x20501f irq 61 on simplebus0 iicbus0: on iichb0 iic0: on iicbus0 iichb1: mem 0x804000-0x80401f irq 61 on simplebus0 iicbus1: on iichb1 iic1: on iicbus1 spi0: mem 0x204000-0x20401f irq 62 on simplebus0 spibus0: on spi0 bcm_dma0: mem 0x7000-0x7fff,0xe05000-0xe05fff irq 24,25,26,27,28,29,30,31,32,33,34,35,36 on simplebus0 mbox0: mem 0xb880-0xb8bf irq 1 on simplebus0 sdhci_bcm0: mem 0x300000-0x3000ff irq 70 on simplebus0 mmc0: on sdhci_bcm0 uart0: mem 0x201000-0x201fff irq 65 on simplebus0 uart0: console (115200,n,8,1) dwcotg0: mem 0x980000-0x99ffff irq 17 on simplebus0 usbus0 on dwcotg0 fb0: on ofwbus0 simplebus1: on ofwbus0 simplebus1: could not get ranges device_attach: simplebus1 attach returned 6 Timecounters tick every 10.000 msec usbus0: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 uhub0: 1 port with 1 removable, self powered mmcsd0: 2GB at mmc0 25.0MHz/1bit/65535-block fb0: 656x416(0x0@0,0) 16bpp fb0: pitch 1312, base 0x5e006000, screen_size 545792 fbd0 on fb0 VT: initialize with new VT driver "fb". ugen0.2: at usbus0 uhub1: on usbus0 uhub1: MTT enabled random: unblocking device. Root mount waiting for: usbus0 uhub1: 5 ports with 4 removable, self powered Root mount waiting for: usbus0 ugen0.3: at usbus0 smsc0: on usbus0 Trying to mount root from ufs:/dev/mmcsd0s2a [rw,noatime]... smsc0: chip 0xec00, rev. 0002 miibus0: on smsc0 ukphy0: PHY 1 on miibus0 warning: no time-of-day clock registered, system time will not be set accurately ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ue0: on smsc0 ue0: Ethernet address: b8:27:eb:50:ce:e0 GEOM_PART: mmcsd0s2 was automatically resized. Use `gpart commit mmcsd0s2` to save changes or `gpart undo mmcsd0s2` to revert them. smsc0: chip 0xec00, rev. 0002 ------------------------------------------------------------------------ Thanks, --- YAMAMOTO Shigeru From owner-freebsd-arm@FreeBSD.ORG Tue Sep 30 23:50:29 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6EC3E4A; Tue, 30 Sep 2014 23:50:29 +0000 (UTC) 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 AF7447AD; Tue, 30 Sep 2014 23:50:29 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=9srXlKHWug3VGnwCWNXjDMuA6Rj+RrMKJOJYOIemyzU=; b=XIx/Rw2ZCFbpomLes9PkmzjcOssyFb8hpGGBGD8HrdytITczKcFZ6CgMcocawmYdlAcJlrJ8sS8CWW1nQ12zg87Bjj2sejvPCiBcjmNOpZgtTYGfGpdQKm3wq5NAslTLXGBkSlEZlJaYLhDMfhBUb+eJWpML5a0nBop8KOsJ4HM=; Received: from [182.1.53.165] (port=53968 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZ7Bb-000zRk-86; Tue, 30 Sep 2014 17:50:28 -0600 Date: Wed, 1 Oct 2014 07:50:17 +0800 From: Erich Dollansky To: YAMAMOTO Shigeru Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20141001075017.04a1b002@X220.alogt.com> In-Reply-To: <20141001.010528.1222668648660002950.shigeru@os-hackers.jp> References: <20140929023616.GG75063@hub.FreeBSD.org> <20140929123327.6ab0207c@X220.alogt.com> <20140929.142712.117419748410715004.shigeru@os-hackers.jp> <20141001.010528.1222668648660002950.shigeru@os-hackers.jp> 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-Source: X-Source-Args: X-Source-Dir: Cc: gjb@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 23:50:30 -0000 Hi, On Wed, 01 Oct 2014 01:05:28 +0900 (JST) YAMAMOTO Shigeru wrote: > >>>>> "shigeru" == YAMAMOTO Shigeru writes: > >>>>> "Erich" == Erich Dollansky writes: > >> On Sun, 28 Sep 2014 22:36:16 -0400 Glen Barber > >> wrote: Why not try the images already available here? > >> http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ > >> I have tried it now several times. All with the same result. > > I get SD image, FreeBSD-10.1-BETA3-arm-armv6-RPI-B.img.bz2, from that > URL. > > When using original SD image, I can't boot because a kernel does not > find root file system. > I do not see any messages as I still do not have a monitor cable. > I get a new firmware from https://github.com/raspberrypi/firmware/ > and I replace *.dat, *.elf in SD image. > It seems that I did something wrong then. The Raspberry is currently compiling world. It should be finished with it only tomorrow. > # git clone https://github.com/raspberrypi/firmware.git > # mount_msdosfs /dev/da0s1 /mnt > # cp ./firmware/boot/*.dat /mnt/. > # cp ./firmware/boot/*.elf /mnt/. > # umount /mnt > I replaced all files. Erich From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 02:58:25 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1881B6A for ; Wed, 1 Oct 2014 02:58:25 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2368BB3 for ; Wed, 1 Oct 2014 02:58:24 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id rd3so299562pab.4 for ; Tue, 30 Sep 2014 19:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:subject:message-id:date:to:mime-version; bh=wQ/fA31JOUdVgAyXVE10jG8sfpCTzMsWivNBZnzPp4Y=; b=jj7tC1IcVz7N0LoY9wsbZPgeR5a9f6zEy3IQ4P0ubQVkCJsL9BJB6AyrokLP1yq2Ep jnQNezqRRnM+92lfGAZOMwqzT583MajmQ/2lcI0pdf353wiKaUveIYM6H+qg5Qo0uPoN WCz/taDbj/PYMQPkNCRVedMEsDEVmT/zN7RVh9sEL++JH31hsACV7/b+uz9dMjp396d5 YsWl7VikcEBpPRYtKp7zeacxnxv63WdyygOWF96HF3VuteFJk6fF3nimPdZ/ad9+HBKs 8INoOJaoftInGr8EPErTWB9ARcJDMbS8XYszJh0JIRATvOkhl659FYux/nD9KnU69Ym1 M/bQ== X-Received: by 10.66.150.5 with SMTP id ue5mr72850824pab.129.1412132304449; Tue, 30 Sep 2014 19:58:24 -0700 (PDT) Received: from [172.16.1.21] (123-100-93-24.dynamic.dsl.netguardian.co.nz. [123.100.93.24]) by mx.google.com with ESMTPSA id uf6sm16524782pac.16.2014.09.30.19.58.21 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 30 Sep 2014 19:58:23 -0700 (PDT) From: Stephen Woolerton Subject: Forwarding traffic on Pi - no longer works Message-Id: <8B684D61-641A-4D47-B37B-8C2699BCA0C9@gmail.com> Date: Wed, 1 Oct 2014 15:58:16 +1300 To: freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 02:58:25 -0000 Hi everyone, Just wondering if anyone else is having an issue with nat and network = forwarding, on FreeBSD 10.x releases since June.=20 Here is the configuration - home network on the built-in NIC, "ue0" - Internet router attached to an Apple USB adaptor, "ue1" - rc.conf has gateway_enable=3D"YES" - pf.conf pretty much just has a NAT rule pf.conf -------------- int_if=3D"ue0" ext_if=3D"ue1" localnet =3D $int_if:network nat on $ext_if from $localnet to any -> ($ext_if) pass in all pass out all ------------------------- I've tried a number of releases since early June, including 10.1 beta3, = but they all fail to forward packets using the configuration above. As a = check I also set up a fresh image based on my June snapshot, with just = the settings above and forwarding worked. Both adaptors are working fine on the Pi itself.=20 Thanks Stephen From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 06:48:15 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 367D1F42 for ; Wed, 1 Oct 2014 06:48:15 +0000 (UTC) Received: from mail-yh0-x229.google.com (mail-yh0-x229.google.com [IPv6:2607:f8b0:4002:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA32BEA1 for ; Wed, 1 Oct 2014 06:48:14 +0000 (UTC) Received: by mail-yh0-f41.google.com with SMTP id i57so72457yha.28 for ; Tue, 30 Sep 2014 23:48:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tDZvZaIb0i+vApAhPiUq3U8m+IR1bGw+lyNsjuK+oPo=; b=U+c63FDNdmsHkFZtw2OM9cxugXLBUQDjUkVljoDnUWK84Ond2dYRUt9sTgWQqGCLMu 5m4sNNH3S6QYMuii48CnrWJZ/AdpXUQfdV3Q6Y0G6o/oGQe8nAWeEj6eZJnH83qDTcWW xm7//nUvC+0xLT6jQ5OcH1cxLiNwEmaxZg8LgtBZB6/ChNdtsfE9/XknKIKsRiKRUs+c UTU/3cYtXRnHii3/k5uHENSNdzXpf6lmuGSVMGKgj+N5eDdITTHj7aF5cfaGxCGvOiGO cQcdzVa+ASbHk5DssAKigmpwy9Y2xWvnVz8cinwVuBUi2Gr+za33mJE8QWcwjpWJoRQp BikQ== MIME-Version: 1.0 X-Received: by 10.236.124.33 with SMTP id w21mr2127688yhh.73.1412146094089; Tue, 30 Sep 2014 23:48:14 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Tue, 30 Sep 2014 23:48:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 23:48:14 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 06:48:15 -0000 Warner, First, I was just watching your 2010 talk on supporting FreeBSD in a commercial environment. Has there been any updates in the process of maintaining a commercial branch in the last 4 years (not that I have any commercial ventures yet! lolz)? Anyway, I talked to an Engineer about the NAND controller spec and he chided me for being naive (poor little software developer, in way over his head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, which I have yet to find on the Digi site. I have however found this hardware reference: http://ftp1.digi.com/support/documentation/90001270_E.pdf >From Page 41: NAND flash memory The ConnectCore for i.MX53 module provides 8GB of NAND flash memory. On the module in the development kits a 512MByte, 2Kbyte page, NAND flash chip is used. This NAND flash device is connected to NAND flash Chip Select 0. The NAND flash controller signals are available on the module connectors. There are pin references to NAND further down in the section "GPIO multiplexing table in the ConnectCore for i.MX53 module" on page 44 and 49. I fear this is not the information we are looking for. I have found another u-boot fork for the CCWMX53 on github here: https://github.com/Varcain/uboot-ccwmx53-digi With what seems to be the information about booting from NAND here: https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl If you can let me know what I am looking for I can both ask a more directed question at work and also perform a better search. I have also started looking over the Architecture handbook as well because I have a feeling there is going to be lots of driver code in my future. Okay, I need to stop staying up this late! Good Night, Russ On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wrote: > > On Sep 27, 2014, at 9:49 PM, Russell Haley wrote: > > > I will attempt to load the kernel from tftp as soon as I can. I will ne= ed > > to figure out how to get ethernet to the unit. > > > > I know nothing about u-boot so forgive my ignorance but I was hoping to > > modify the Arndale configuration to work such as: > > > > # mmc read 1 0x70800000 0x800 0x1800; > > #go 0x70800000; > > > > and then point the rootfs to /dev/da1s1 > > > > On another note, do you know where I could find out more about the > missing > > MTD support? > > A spec for the NAND controller is needed to make that work=E2=80=A6 Is o= ne about? > > Warner > > > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many co= ol > > projects, so little time... > > > > Thanks, > > > > Russ > > > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > > > >> On Sep 27, 2014, at 13:31, Russell Haley wrote: > >>> > >>> Rui, > >>> > >>> So no MTD means the NAND on the SOM is out, but can I boot the kernel > >> and load rootfs from the microSD, like in this example: > >>> =E2=80=A2 > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; = go > >> 0x40f00000" > >>> > >>> ARNDALE5250 # saveenv > >>> > >>> ARNDALE5250 # boot > >> > >> You can't use the Arndale config since the load addresses are differen= t. > >> You should be able to load a kernel from the network. Can you do that= ? > >> > >> -- > >> Rui Paulo > >> > >> > >> > >> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 06:49:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6601F86 for ; Wed, 1 Oct 2014 06:49:49 +0000 (UTC) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 879A3EAA for ; Wed, 1 Oct 2014 06:49:49 +0000 (UTC) Received: by mail-yh0-f47.google.com with SMTP id c41so69484yho.34 for ; Tue, 30 Sep 2014 23:49:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=7q42TvzOcN4eVLEjsLIv5XaJguZBCLbXoKcM5Ow5tfw=; b=LzUFhrbfRRs4O0U9rcL4AyNCkMybxy2DsPhppET7b7qXArpl1Cy2Zn7HQHJYWD16I9 9FpMZK3RSAaoEo7WocAAQbL8Hir3XXwyhYJfRitmPzA+OvoLXPHgr6fH1c+oLNbc8cdN hJQjce1KM4F0DI/aQ1Nav5GAm5EA80jAAgbBs9p5VllJFbDWIC9e435v9txDPXXl7YO4 3h5ouT9f95XN1lMuaksxcE+WfBKbtsGL2VZY4rg1PCx9ThGAbOeqbf5g/UIMCZnhD8By LKqPR8jfdmGfHyiCRcb6N3XiWeEDaHR2gmWxewyQaFNN4p/xJSr3x4JW+PW2veKv4Dk9 HexA== MIME-Version: 1.0 X-Received: by 10.236.133.165 with SMTP id q25mr75474681yhi.62.1412146188729; Tue, 30 Sep 2014 23:49:48 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Tue, 30 Sep 2014 23:49:48 -0700 (PDT) In-Reply-To: References: Date: Tue, 30 Sep 2014 23:49:48 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh , Rui Paulo , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 06:49:50 -0000 Warner, Oh, and I am confused about how to tell the kernel where to load rootfs from. Any information you can direct me towards would be grand! Russ On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wrote: > > On Sep 27, 2014, at 9:49 PM, Russell Haley wrote: > > > I will attempt to load the kernel from tftp as soon as I can. I will ne= ed > > to figure out how to get ethernet to the unit. > > > > I know nothing about u-boot so forgive my ignorance but I was hoping to > > modify the Arndale configuration to work such as: > > > > # mmc read 1 0x70800000 0x800 0x1800; > > #go 0x70800000; > > > > and then point the rootfs to /dev/da1s1 > > > > On another note, do you know where I could find out more about the > missing > > MTD support? > > A spec for the NAND controller is needed to make that work=E2=80=A6 Is o= ne about? > > Warner > > > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many co= ol > > projects, so little time... > > > > Thanks, > > > > Russ > > > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > > > >> On Sep 27, 2014, at 13:31, Russell Haley wrote: > >>> > >>> Rui, > >>> > >>> So no MTD means the NAND on the SOM is out, but can I boot the kernel > >> and load rootfs from the microSD, like in this example: > >>> =E2=80=A2 > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin; = go > >> 0x40f00000" > >>> > >>> ARNDALE5250 # saveenv > >>> > >>> ARNDALE5250 # boot > >> > >> You can't use the Arndale config since the load addresses are differen= t. > >> You should be able to load a kernel from the network. Can you do that= ? > >> > >> -- > >> Rui Paulo > >> > >> > >> > >> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 08:00:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 846D541E for ; Wed, 1 Oct 2014 08:00:49 +0000 (UTC) Received: from mail-s93.mailgun.info (mail-s93.mailgun.info [184.173.153.221]) by mx1.freebsd.org (Postfix) with ESMTP id DC50E98A for ; Wed, 1 Oct 2014 08:00:48 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=soundestdirect.com; q=dns/txt; s=pic; t=1412150448; h=Date: Message-Id: List-Unsubscribe: From: To: Subject: Content-Type: Mime-Version: Sender; bh=xpzfCj5yqYkMqbC3iMSvH7PwoTQKrGdyI75W6+DrEUg=; b=YcPTp3oDoOqXEtC2OMhDEJlPGYy81iWN3I1jdfysge2c6D5WBQC3ksQiLxGbZTC+RTxKXDv/ 673OYvzebAIEmpSSDl9FlV8UiohIo0WVmxNEYQ3RL+ST4aLzt5ENxs3+Xh0nB+i+ndwuCck/ docaoJswb9auo5mZC8Nr8yi8s0E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=soundestdirect.com; s=pic; q=dns; h=Date: Message-Id: List-Unsubscribe: From: To: Subject: Content-Type: Mime-Version: Sender; b=cc5+iRq1PYUBDm1ePwb7aMR2hBiTJKZI12TRG5dc8EzK4afG5mPBRoWgHTJIIY9I5S7BUM qUNUDoCiVVYgZsuC0IPKS2y3C8jkpdZmD4m3b2E4ZBZxbzNZoh6+CAYlDxx8bbl3Z51OX1LO XwG+7jFNBxOBZhRRM3xnqAXAZpZr0= Received: from [127.0.0.1] (app-1.radar.soundest.net [192.96.207.97]) by mxa.mailgun.org with ESMTP id 542bb4ad.6989fc0-in1; Wed, 01 Oct 2014 08:00:45 -0000 (UTC) Date: Wed, 01 Oct 2014 08:00:34 GMT Message-Id: <57011f39a53dee361e452a8e858743@app-1> From: "Johan Watson" To: freebsd-arm@freebsd.org Subject: October Specials from Furnways Mime-Version: 1.0 X-Mailgun-Sid: WyJiMWI3MSIsICJmcmVlYnNkLWFybUBmcmVlYnNkLm9yZyIsICI1ODNjNSJd Sender: sales=furnways.co.za@soundestdirect.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:00:49 -0000 Hospitality Furniture [Web version](http://furnways-uoonf0.soundestdirect.= com/view/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 95/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 94/542ba73858026ef77f21399c/54264699fe7da963021cb803) Furnways - Corporate Turnkey Solutions [**Furnways is a leading office furniture supplier**](http://furnways-uoonf= 0.soundestdirect.com/link/542ba6f558026ef77f213993/542ba73858026ef77f21399c= /54264699fe7da963021cb803) in South Africa. WE offer the widest range of = products, from executive desks [to school furniture](http://furnways-uoonf0= .soundestdirect.com/link/542ba6f558026ef77f213992/542ba73858026ef77f21399c/= 54264699fe7da963021cb803). We are the biggest online furniture store in = Africa, delivering high quality products at affordable prices, = understanding our customers' need to acquire top of the line furniture for = their business with reasonable investments. If you are looking for stylish = furniture for your office, hotel or restaurant, then this is the perfect = place for you, as we specialize in creating innovative and chic designs for= your furniture. [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213991= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Wimpey Side Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213991/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Available in over 20 Colours 5 Year Warranty. R240.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213991/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213990= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Wimpey Arm Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213990/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Available in over 20 Colours 5 Year Warranty. R260.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213990/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398f= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Wimpey Ultra Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398f/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Available in over 20 Colours 5 Year Warranty. R280.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398f/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398e= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Chloe Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398e/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Available in over 20 Colours 5 Year Warranty. R480.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398e/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398d= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Alpine Chairs ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398d/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Available in over 20 Colours 5 Year Warranty. R132.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398d/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398c= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Avatar Caf=C3=A9 Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398c/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Available in over 20 Colours 5 Year Warranty. R260.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398c/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398b= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Double Pedestal Desk ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398b/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) 32mm Melamine Top 1800mm*900mm Single Pedestal: R2865 Available in a variety of colours 5 Year Warranty R3540.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398b/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f21398a= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Rectangular Tables ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f21398a/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) 16mm Melamine Tops Available in Oak, Mahogany or Supawood 1800 * 900 From R1093 1400 * 700 From R663 1200 * 600 From R504=C2=A0 5 Year Warranty R504.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f21398a/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213989= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Perforated Metal Set ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213989/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Contains: 2 tier letter tray Paper bin Pencil cup Paper cube 5 Year Warranty **Available in Siver for R1428** Black/White: R1165.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213989/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213988= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Big & Tall Heavy Duty Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213988/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) Supports Up to 150kg Leather Seat Chrome base Chrome arms with polyurethane pads 5 Year Warranty R3496.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213988/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213987= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Spine Ergonomic High Back Chair ](http://furnways-uoonf0.soundestdirect.= com/link/542ba6f558026ef77f213987/542ba73858026ef77f21399c/54264699fe7da963= 021cb803) 2 Part shell Permanent contact mechanism Adjustable arms Available in leather Loads of extras and materials available 5 Year Warranty R1750.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213987/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213986= /542ba73858026ef77f21399c/54264699fe7da963021cb803) [ Lucea 1500 Ergonomic Typist Chair ](http://furnways-uoonf0.soundestdirect= .com/link/542ba6f558026ef77f213986/542ba73858026ef77f21399c/54264699fe7da96= 3021cb803) Ergonomic shaped back with rake and height adjustment Standard with black nylon base Available in leather Loads of extras and materials available 5 Year Warranty R811.00 =C2=A0=C2=A0=C2=A0 [ Buy now ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef7= 7f213986/542ba73858026ef77f21399c/54264699fe7da963021cb803) [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f2139= 85/542ba73858026ef77f21399c/54264699fe7da963021cb803) =C2=A0[ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f= 213984/542ba73858026ef77f21399c/54264699fe7da963021cb803)=C2=A0 =C2=A0[ = ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213983/5= 42ba73858026ef77f21399c/54264699fe7da963021cb803)=C2=A0 =C2=A0[ = ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213982/5= 42ba73858026ef77f21399c/54264699fe7da963021cb803)=C2=A0 [sales@furnways.co.za](mailto:sales@furnways.co.za) Furnways Lonehill Boulevard , 22 , Sandton , 2062 , South Africa All prices are in ZAR and excludes VAT and delivery =C2=A9 2014 Furnways [Unsubscribe](http://furnways-uoonf0.soundestdirect.= com/unsubscribe/542ba73858026ef77f21399c/54264699fe7da963021cb803) Proudly delivered by [ ](http://furnways-uoonf0.soundestdirect.com/link/542ba6f558026ef77f213981= /542ba73858026ef77f21399c/54264699fe7da963021cb803) From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 08:33:12 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08E96E2D for ; Wed, 1 Oct 2014 08:33:12 +0000 (UTC) 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 D53F7D4B for ; Wed, 1 Oct 2014 08:33:11 +0000 (UTC) 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; bh=rxAUbyEfcnWCOjOr1sqLhE2BwnNhqVIjjeiqS9dccbY=; b=qVUSy7P1d/rOq2R3HvXFobs47jcmBwmB6CsM1hgCsNFd+rh47sfxd+uQ6kJZm00Cmlbue6PCX/ohblmKp6py/BLMzO6LlsZUCy8Dsk212F5ej+HyeSihtJGQ796dJOU61HOnRzwJTPXfrVmZRIucchvcafrv8OeMjK1oI9+ZEd8=; Received: from [182.1.53.165] (port=30866 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZFLL-000BZR-VG for freebsd-arm@freebsd.org; Wed, 01 Oct 2014 02:33:04 -0600 Date: Wed, 1 Oct 2014 16:33:00 +0800 From: Erich Dollansky To: freebsd-arm@freebsd.org Subject: Signal 9 when compiling world on Raspberry Message-ID: <20141001163300.438384e9@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-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:33:12 -0000 Hi, I tried to compile world of CURRENT on a Raspberry but always get signal 9 here. I have tried this on two different Raspberry B+. The filesystem in use is mounted via NFS. The machine is also running CURRENT from July. All settings are the default for a Raspberry B+. Whould I exclude the build of CLang? Erich ===> lib/clang/libllvmx86desc (depend) tblgen -gen-instr-info -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86 -d X86GenInstrInfo.inc.d -o X86GenInstrInfo.inc.h /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/X86.td tblgen -gen-register-info -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86 -d X86GenRegisterInfo.inc.d -o X86GenRegisterInfo.inc.h /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/X86.td tblgen -gen-subtarget -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86 -d X86GenSubtargetInfo.inc.d -o X86GenSubtargetInfo.inc.h /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/X86.td rm -f .depend CC='cc ' mkdep -f .depend -a -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/.. -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc -I. -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86ELFRelocationInfo.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MachORelocationInfo.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86WinCOFFObjectWriter.cpp ===> lib/clang/libllvmx86disassembler (depend) tblgen -gen-disassembler -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/include -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86 -d X86GenDisassemblerTables.inc.d -o X86GenDisassemblerTables.inc.h /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86/X86.td *** Signal 9 Stop. make[6]: stopped in /usr/src/lib/clang/libllvmx86disassembler *** Error code 1 From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 08:44:49 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41CBF3CD for ; Wed, 1 Oct 2014 08:44:49 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 165C4EB8 for ; Wed, 1 Oct 2014 08:44:48 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s918imRs056274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Oct 2014 01:44:48 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s918il7d056273; Wed, 1 Oct 2014 01:44:47 -0700 (PDT) (envelope-from jmg) Date: Wed, 1 Oct 2014 01:44:47 -0700 From: John-Mark Gurney To: Russell Haley Subject: Re: Digi CCWMX53 Message-ID: <20141001084447.GR43300@funkthat.com> Mail-Followup-To: Russell Haley , Tim Kientzle , freebsd-arm@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Wed, 01 Oct 2014 01:44:48 -0700 (PDT) Cc: Tim Kientzle , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 08:44:49 -0000 Russell Haley wrote this message on Mon, Sep 29, 2014 at 20:14 -0700: > Tim, > > > FreeBSD source has an 'xdev' target that builds and installs a set of > cross-tools. In particular, it can install cross-versions of the same GCC > or clang used by the rest of FreeBSD. > > Where can I find more information on cross compiling on FreeBSD? check out: https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD Though MAKEOBJDIRPREFIX isn't required, and neither is TARGET... now using an external tool chain is a different topic.. > On Sat, Sep 27, 2014 at 11:53 AM, Tim Kientzle wrote: > > > > > On Sep 26, 2014, at 10:38 PM, Russell Haley wrote: > > > > > 1) Can anyone give me the correct u-boot enviroment variables or > > reference > > > to the u-boot process to boot the completed freebsd kernel. Specifically > > on > > > a CCWMX53 if possible, but I have linux references to port from. Where > > > would I look for an example? > > > > There are two general approaches being used: > > > > 1) Have U-Boot load and boot the kernel directly. This can sometimes be > > done with an unmodified Linux U-Boot. > > > > 2) Have U-Boot load FreeBSDs scriptable 'ubldr' and have that load the > > kernel. This provides more flexibility in the boot process but usually > > requires rebuilding U-Boot. In particular, you'll need to: > > * Add CONFIG_CMD_ELF option to U-Boot so it can load `ubldr' which is > > an ELF executable > > * Add CONFIG_CMD_API option to U-Boot so `ubldr' can access U-Boot's > > drivers for hardware access (`ubldr' itself has to be compiled for each > > board to adjust the load address but is otherwise completely generic). > > * Adjust the U-Boot startup scripts to set FDT environment variables > > and load ubldr. You can look at the U-Boot patches for various boards > > supported by Crochet to see how this has been done elsewhere: > > github.com/kientlze/crochet-freebsd > > > > > > > 2) Do I need to create a cross compiler? Reference 1 says yes, reference > > > two says no. Help! > > > > In most cases, the FreeBSD build system will build a cross-compiler for > > it's own use, so you generally don't need to install a cross compiler to > > cross-build FreeBSD proper. However, U-Boot is not part of FreeBSD so you > > may need to install a separate cross-compiler to build that. > > > > > > > > Ref.1 Build a cross compiler > > > https://wiki.freebsd.org/FreeBSD/arm/ArndaleBoard > > > > This is using a cross-compiler from ports to build U-Boot. It uses the > > FreeBSD build machinery to cross-build the FreeBSD kernel and world. (When > > you specify TARGET_ARCH, FreeBSD's 'buildworld' target will build and use a > > suitable cross-compiler. Also, 'buildkernel' will reuse the cross-compiler > > built by 'buildworld', so you do not need 'kernel-toolchain' as long as you > > 'buildworld' first.) > > > > > > > > Ref 2. No cross compiler/ make toolchain > > > https://wiki.freebsd.org/A_Brief_Guide_To_Cross_Compiling_FreeBSD > > > > This example only talks about building *world*, and the 'buildworld' > > target builds the necessary cross-tools transparently. In particular, > > since it doesn't talk about building out-of-tree boot loaders such as > > U-Boot, it does not need to talk about building/installing an explicit > > cross-compiler. > > > > For cross-compilers, you have three options: > > * Ports. > > * After a successful buildworld, you can 'make TARGET=xyz ... buildenv' > > to get a shell with suitable path settings to reuse the cross-tools from > > the buildworld stage. Use 'buildenvvar' to just get the environment for > > use in scripts. > > * FreeBSD source has an 'xdev' target that builds and installs a set of > > cross-tools. In particular, it can install cross-versions of the same GCC > > or clang used by the rest of FreeBSD. This facility has changed a lot > > recently, so ask if you need the current command line. > > > > Hope this clarifies things, > > > > Tim > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 15:03:56 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5D898CF0 for ; Wed, 1 Oct 2014 15:03:56 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 202F8315 for ; Wed, 1 Oct 2014 15:03:55 +0000 (UTC) Received: from [73.34.117.227] (helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1XZLRU-000OVC-Am; Wed, 01 Oct 2014 15:03:48 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s91F3kjb016934; Wed, 1 Oct 2014 09:03:46 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 73.34.117.227 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18iCMiFdlvn3GzD+bCVR0Jf X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: Signal 9 when compiling world on Raspberry From: Ian Lepore To: Erich Dollansky In-Reply-To: <20141001163300.438384e9@X220.alogt.com> References: <20141001163300.438384e9@X220.alogt.com> Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Oct 2014 09:03:45 -0600 Message-ID: <1412175825.66615.375.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 15:03:56 -0000 On Wed, 2014-10-01 at 16:33 +0800, Erich Dollansky wrote: > Hi, > > I tried to compile world of CURRENT on a Raspberry but always get signal > 9 here. I have tried this on two different Raspberry B+. The filesystem > in use is mounted via NFS. > > The machine is also running CURRENT from July. > > All settings are the default for a Raspberry B+. > > Whould I exclude the build of CLang? > > Erich > > > ===> lib/clang/libllvmx86desc (depend) > tblgen -gen-instr-info > -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include > -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86 > -d X86GenInstrInfo.inc.d -o > X86GenInstrInfo.inc.h /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/X86.td > tblgen -gen-register-info > -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include > -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86 > -d X86GenRegisterInfo.inc.d -o > X86GenRegisterInfo.inc.h /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/X86.td > tblgen -gen-subtarget > -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include > -I /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86 > -d X86GenSubtargetInfo.inc.d -o > X86GenSubtargetInfo.inc.h /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/X86.td > rm -f .depend CC='cc ' mkdep -f .depend -a > -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/.. > -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/include > -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/tools/clang/include > -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc > -I. > -I/usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/../../lib/clang/include > -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS > -D__STDC_CONSTANT_MACROS > -DLLVM_DEFAULT_TARGET_TRIPLE=\"armv6-gnueabi-freebsd11.0\" > -DLLVM_HOST_TRIPLE=\"armv6-unknown-freebsd11.0\" > -DDEFAULT_SYSROOT=\"\" /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86AsmBackend.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86ELFRelocationInfo.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MCAsmInfo.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MCTargetDesc.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MachORelocationInfo.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp /usr/src/lib/clang/libllvmx86desc/../../../contrib/llvm/lib/Target/X86/MCTargetDesc/X86WinCOFFObjectWriter.cpp > ===> lib/clang/libllvmx86disassembler (depend) tblgen > -gen-disassembler > -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/include > -I /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86 > -d X86GenDisassemblerTables.inc.d -o > X86GenDisassemblerTables.inc.h /usr/src/lib/clang/libllvmx86disassembler/../../../contrib/llvm/lib/Target/X86/X86.td > *** Signal 9 > > Stop. > make[6]: stopped in /usr/src/lib/clang/libllvmx86disassembler > *** Error code 1 SIGKILL? I'll bet you've also got an "out of swap space" message in /var/log/messages related to this? It's a bit galling that it dies on an x86 component we don't even need built for arm. -- Ian From owner-freebsd-arm@FreeBSD.ORG Wed Oct 1 23:54:28 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DBE834BD; Wed, 1 Oct 2014 23:54:28 +0000 (UTC) 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 B4E54100; Wed, 1 Oct 2014 23:54:28 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=7KpvZFBZ9I43dcrNa664lYLn6coS04ZzEJJByH/zeDc=; b=c/mtCoqAXJfmP0gzwV2AWXyPe/JylYeVRb8utn9hWxL/u8fkkm9dN4o5+tf4daRUwp4pTLCxuxOzOhepZYR5pgRYuNipjPPHZixOpLelmPA6qHqmIxlep+z99KOpyzq67l0ELbPCTWOo0LFneWEBwrWtQo17an099xaQ45YUChY=; Received: from [182.4.74.116] (port=61596 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZTj0-0013Ca-SF; Wed, 01 Oct 2014 17:54:27 -0600 Date: Thu, 2 Oct 2014 07:54:22 +0800 From: Erich Dollansky To: Ian Lepore Subject: Re: Signal 9 when compiling world on Raspberry Message-ID: <20141002075422.07a56aba@X220.alogt.com> In-Reply-To: <1412175825.66615.375.camel@revolution.hippie.lan> References: <20141001163300.438384e9@X220.alogt.com> <1412175825.66615.375.camel@revolution.hippie.lan> 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-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 23:54:29 -0000 Hi, On Wed, 01 Oct 2014 09:03:45 -0600 Ian Lepore wrote: > > *** Signal 9 > > > > Stop. > > make[6]: stopped in /usr/src/lib/clang/libllvmx86disassembler > > *** Error code 1 > > SIGKILL? I'll bet you've also got an "out of swap space" message > in /var/log/messages related to this? > yes, you got it. I did not even check messages. > It's a bit galling that it dies on an x86 component we don't even need > built for arm. Yes, this is the real irony. Erich From owner-freebsd-arm@FreeBSD.ORG Thu Oct 2 21:01:35 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F9D1428 for ; Thu, 2 Oct 2014 21:01:35 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id EBBDBFF0 for ; Thu, 2 Oct 2014 21:01:34 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s92L1YSP014893 for ; Thu, 2 Oct 2014 21:01:34 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194101] New: Packet forwarding not working with nat Date: Thu, 02 Oct 2014 21:01:35 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-BETA3 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: direct727@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:01:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194101 Bug ID: 194101 Summary: Packet forwarding not working with nat Product: Base System Version: 10.1-BETA3 Hardware: arm OS: Any Status: Needs Triage Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: direct727@gmail.com My Pi running FreeBSD 10.1 BETA3 will not forward packets. The Pi is configured with a nat rule in PF. Fowarding was working on all builds prior to 7 June, and sometime after this, nat has stopped working. - primary network on the built-in NIC, "ue0" - Internet router attached to USB network adaptor, "ue1" - rc.conf has gateway_enable="YES" - pf.conf pretty much just has a NAT rule pf.conf -------------- int_if="ue0" ext_if="ue1" localnet = $int_if:network nat on $ext_if from $localnet to any -> ($ext_if) pass in all pass out all Have tried multiple releases from early August onwards - all have this fault. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 2 21:34:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2A3B9529 for ; Thu, 2 Oct 2014 21:34:26 +0000 (UTC) Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E85A766D for ; Thu, 2 Oct 2014 21:34:25 +0000 (UTC) Received: by mail-pa0-f48.google.com with SMTP id eu11so3822pac.7 for ; Thu, 02 Oct 2014 14:34:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=7apnc2KC6NmdgnaEDtBq2c/qlJM3ILc+OW1XMStY944=; b=mEjAT7V/vyZs8khKMIe6ciafedGfx562oJ91XZpD7V+eDRd8eu9VfS0COTdT97f56Z Fq1Xxw/DjLe+hCnxYRTEHYb5VMP69bQmXNapIfAMD/tKZcLGSsu41F0eWop5iyIYaxIQ D/F6VIVPI2i6A1CSPibABtg1AYPcBmHBHaWvw2rqNiK1d6aFUzsAXSGxRnj+fpyewp+E bWCvzKxsbLBe2O84+p55SW0gxtHLkWI6RvGSrlMGmVTxgb0G48wFA+1/byL9fs++mnkg 4/9LFl6I/Fxq8O+BZxCmMx3r6lbqfm2fE14BWaf3fbbCK7xrsOQVQNfVzAJ5Tsm++ScN CRNQ== X-Gm-Message-State: ALoCoQmwQja4vTH9MbeivLVex2yzvJPm3qXXfTC+InF11iExyRfz9oJUt0xTVWYykw4cUNHxmLDy X-Received: by 10.66.228.36 with SMTP id sf4mr2300252pac.32.1412285659474; Thu, 02 Oct 2014 14:34:19 -0700 (PDT) Received: from lgwl-kheung.corp.netflix.com (dc1-prod.netflix.com. [69.53.236.251]) by mx.google.com with ESMTPSA id qr1sm4739928pbc.50.2014.10.02.14.34.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Oct 2014 14:34:18 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_FF9DBD8C-C340-49CF-9711-79091376FF5C"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Thu, 2 Oct 2014 15:34:15 -0600 Message-Id: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> References: To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:34:26 -0000 --Apple-Mail=_FF9DBD8C-C340-49CF-9711-79091376FF5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Oct 1, 2014, at 12:48 AM, Russell Haley wrote: > Warner,=20 >=20 > First, I was just watching your 2010 talk on supporting FreeBSD in a = commercial environment. Has there been any updates in the process of = maintaining a commercial branch in the last 4 years (not that I have any = commercial ventures yet! lolz)? >=20 > Anyway, I talked to an Engineer about the NAND controller spec and he = chided me for being naive (poor little software developer, in way over = his head. tisk tisk). He mentioned a FIVE THOUSAND page reference = manual, which I have yet to find on the Digi site.=20 URL + section number. 5k pages doesn=92t necessarily mean it will be = useful, though. :( > I have however found this hardware reference: >=20 > http://ftp1.digi.com/support/documentation/90001270_E.pdf >=20 > =46rom Page 41: >=20 > NAND flash memory > The ConnectCore for i.MX53 module provides 8GB of NAND flash memory. = On the module in > the development kits a 512MByte, 2Kbyte page, NAND flash chip is used. = This NAND flash > device is connected to NAND flash Chip Select 0. > The NAND flash controller signals are available on the module = connectors. This basically says nothing more useful than =93There=92s NAND on this = board that=92s 4Gbits on CS0.=94 which is useful, but far from = sufficient. How do I program the DMA so that ECC is added to the OOB = areas of that NAND? How do I set different ECC tables? How do I do ECC = error correction and detection? If you can=92t answer that sort of = question from the docs you have, then they aren=92t helpful enough. > There are pin references to NAND further down in the section "GPIO = multiplexing table in the ConnectCore for i.MX53 module" on page 44 and = 49.=20 >=20 > I fear this is not the information we are looking for.=20 Not really. The GPIO info might be mildly helpful in a few cases=20 > I have found another u-boot fork for the CCWMX53 on github here: = https://github.com/Varcain/uboot-ccwmx53-digi >=20 > With what seems to be the information about booting from NAND here: = https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >=20 > If you can let me know what I am looking for I can both ask a more = directed question at work and also perform a better search.=20 >=20 > I have also started looking over the Architecture handbook as well = because I have a feeling there is going to be lots of driver code in my = future. A good first step would be to get a URL or search string to get the URL = for that big spec. It is of the right size to possibly be useful, but = sometimes really long specs have 1-2 page descriptions of things like = the SD controller or the NAND controller that you need special NDAs + = business arrangements to get, so it is hard to say=85 Warner >=20 > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wrote: >=20 > On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: >=20 > > I will attempt to load the kernel from tftp as soon as I can. I will = need > > to figure out how to get ethernet to the unit. > > > > I know nothing about u-boot so forgive my ignorance but I was hoping = to > > modify the Arndale configuration to work such as: > > > > # mmc read 1 0x70800000 0x800 0x1800; > > #go 0x70800000; > > > > and then point the rootfs to /dev/da1s1 > > > > On another note, do you know where I could find out more about the = missing > > MTD support? >=20 > A spec for the NAND controller is needed to make that work=85 Is one = about? >=20 > Warner >=20 >=20 > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many = cool > > projects, so little time... > > > > Thanks, > > > > Russ > > > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > > > >> On Sep 27, 2014, at 13:31, Russell Haley = wrote: > >>> > >>> Rui, > >>> > >>> So no MTD means the NAND on the SOM is out, but can I boot the = kernel > >> and load rootfs from the microSD, like in this example: > >>> =95 > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 = kernel.bin; go > >> 0x40f00000" > >>> > >>> ARNDALE5250 # saveenv > >>> > >>> ARNDALE5250 # boot > >> > >> You can't use the Arndale config since the load addresses are = different. > >> You should be able to load a kernel from the network. Can you do = that? > >> > >> -- > >> Rui Paulo > >> > >> > >> > >> > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 >=20 --Apple-Mail=_FF9DBD8C-C340-49CF-9711-79091376FF5C Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJULcTXAAoJEGwc0Sh9sBEAxykP/0UDuX7ExVELl8GHlFGHrc7R 5BvMUZg4r8/mhVJ77NGYmzKP1FijZXlp1QBUnamUZN192VI1GDSOGT+o2o+rpo/G /Bv66NzlLaPQycKdUUseNauETQeRhNrS8Kj8SmisZRDLMP3xv45zh6CjrQJ9bETZ +BZk1iUrea4ti/17JVLnZtTDJFaW2ghfI/49T/8POyP0VXH16gv3qpfAhVnDpl4+ 8DpiPfets/8CFPtB4aiWIg4bWLZ4BuKoLMLIHvLSTIRp6ySAGtqp/X5Jr0hyOBKY WshFmtHAQxtTjdz9v4Vnh1ygG3zm6+JMY3YjVhFPOMCJyeI8aNqXn2MA2WYOqeMv z9RMtZRtuTEroD6b93YLREZpFBdr4AMxI//TPBfOPemBnKfkapaLJhva0iGhmUGg /Lw3iwvPNkJOKycKlggqbq74VvRHA9fukOUWhtkK+G2HzfJUq7SUidCzEjmrQIxt LMrMQeSWgiQV757s6ZfAt23YqVUeClpIZAUiR6VlF3cPpL5sXLlpj9KOhVXyEQdC F7rhDQWSpBOcZucXtII95OrULDwjV2WCenUDODut2Lc+C22HArr4lJJGN8ux9ZRi AcSAqcxc0yrSLYKQjwnQxzGVrV4y600DzYF4GnpaBWt/Brvui27YDZuulkX1Bld9 ssWF6kh64JPhw2+dO/q1 =Qxg6 -----END PGP SIGNATURE----- --Apple-Mail=_FF9DBD8C-C340-49CF-9711-79091376FF5C-- From owner-freebsd-arm@FreeBSD.ORG Thu Oct 2 21:45:45 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6F5FE7E1 for ; Thu, 2 Oct 2014 21:45:45 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 576177C8 for ; Thu, 2 Oct 2014 21:45:45 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s92LjjIc074485 for ; Thu, 2 Oct 2014 21:45:45 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194101] Packet forwarding not working with nat Date: Thu, 02 Oct 2014 21:45:45 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-BETA3 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: hselasky@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:45:45 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194101 Hans Petter Selasky changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hselasky@FreeBSD.org --- Comment #1 from Hans Petter Selasky --- Hi, Can this issue be related to IP packet hardware checksumming? Do you see if incoming or only outgoing traffic is dumped? --HPS -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Thu Oct 2 21:54:08 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 46A2A883 for ; Thu, 2 Oct 2014 21:54:08 +0000 (UTC) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1105E88F for ; Thu, 2 Oct 2014 21:54:07 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id x19so12960ier.34 for ; Thu, 02 Oct 2014 14:54:01 -0700 (PDT) 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:date :message-id:subject:from:to:cc:content-type; bh=hvOG9xZvx85u0T8YHvn6+cVZOmEoP4qZ24afVhCm8xs=; b=J+vfkuCLNlDEdDM1PaXFia9bUXyAnYWTkFpoRK+W4ggErp3EsC5s6SoCdGw3DtIBcn moUpK702J5CyFdGI2BtDywqLl6gRzT6KemK1guj0YdKNXke1XPZrFyabubEPU/1SOitf iEApN/D5fv5mipvMtcBw0wGghGlu5cKtlBa2j1NpwfxR6mcGrjVd/FPhWb1KzHjvtQKM hR87dkUhVohs/OWCRu3J74zhv1gm4UwvFQPNGCEqWUmbHczDl+B+WrSALHA42h6d6U6x SgCGSt+dusBhphIWHSV/cMlNzCZllO+WhXgt2no/2WHWhDB88CGNYcAO8TKHs1YOOriF Bkwg== X-Gm-Message-State: ALoCoQnpMCABUFL6DVAzBToKWX9inRabD9KK10r/gYhGQ44i15ZA/CCTrma1B5xoQtOg2Uv8X6SN MIME-Version: 1.0 X-Received: by 10.50.29.44 with SMTP id g12mr8697980igh.1.1412286841182; Thu, 02 Oct 2014 14:54:01 -0700 (PDT) Received: by 10.107.4.194 with HTTP; Thu, 2 Oct 2014 14:54:01 -0700 (PDT) In-Reply-To: <2c451765bffb43e8b9dab56927bb351a@e15be-02.zdv.Uni-Mainz.DE> References: <542271AE.6070807@andrew.cmu.edu> <2c451765bffb43e8b9dab56927bb351a@e15be-02.zdv.Uni-Mainz.DE> Date: Thu, 2 Oct 2014 17:54:01 -0400 Message-ID: Subject: Re: Jetson TK1 board support From: David Rayson To: =?UTF-8?B?V2Vpw58sIERyLiBKw7xyZ2Vu?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 21:54:08 -0000 How much work do you think would be needed to get the SD controller working? Would it simply be a matter of doing the appropriate initialization (wouldn't U-Boot do this already even?), enabling it in the device tree, and using the standard FreeBSD SDHCI driver, or is there something more complicated that would need to be done? (This would probably be simple to test, but I don't have access to the hardware right now) --David On Fri, Sep 26, 2014 at 4:39 PM, Wei=C3=9F, Dr. J=C3=BCrgen wrote: > Hi, > > sorry, I did not have any time during the week. > > I just sent a mail to the list with a link to my changes. > > Only serial, USB2 and PCIe/Ethernet hardware is working - so no > SATA. > > The drivers rely on u-boot to initialize the hardware. While this > is ok for pinmux, other initializations should be done by the > drivers. > > The interrupt handling for PCIe is rather ad hoc. The interrupt > routing should honor the FDT description. > > The Tegra platform has a GIC with extensions for interrupt > routing. I just made a copy of the GIC code end extended it > in a few cases. There should probably be a mechanism to do > this without duplicating code. > > I changed some non tegra files to get FreeBSD running on the > hardware. There should be better solutions, which can be merged > back to the FreeBSD source tree. For example the problem > with cache coherency due to aggressive L2 prefetch awaits > a real solution. > > There is no code to change the cpu clock yet. > > There is no support for SDHCI or EMMC. > > So I would consider this a first step, which allows to do > native development on the platform. > > Besides that, the kernel seems to be quite stable - at least with > the compiles I did. > > Regards > > Juergen > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitung, > weiss@uni-mainz.de |55099 Mainz, Tel: +49(6131)39-26361, FAX: > +49(6131)39-26407 > > > > -----Original Message----- > > From: owner-freebsd-arm@freebsd.org [mailto: > owner-freebsd-arm@freebsd.org] On Behalf Of > > David Rayson > > Sent: Wednesday, September 24, 2014 9:25 AM > > To: freebsd-arm@freebsd.org > > Subject: Re: Jetson TK1 board support > > > > Hi, > > > > What other work would be useful to get this port working well? I might > > be interested in working on improving it, but first I want to make sure > > I have a clear sense of what's been done so far (and how stable/not it > > is) and what still remains to be done. > > > > --David > > > > > Hi, > > > > > > I have a rather rough port of FreeBSD current on arm to Jetson TK1. I > > > used Stephen Warren's tegra u-boot sources, which initialize and > configure > > > USB and PCIe. > > > > > > So SMP, USB and the onboard PCIe Ethernet adapter work. > > > > > > After Ian's changes to busdma_machdep-v6 (r269212) I had problems wit= h > > > cache coherency with the Ethernet adapter. Seems this is due to the > aggressive > > > L2 prefetcher of Cortex A15. Disabling L2 prefetch does help, as well > as > > > invalidating the cache a second time after the dma transfer. I'm not > > > sure what the correct solution to this problem is. I wonder how > > > other Cortex A15 platforms (exynos5) handle this. > > > > > > I will probably be able to do some cleanups and put patches on the we= b > > > within a week. > > > > > > Regards > > > > > > Juergen > > > > > > Juergen Weiss |Universitaet Mainz, Zentrum fuer Datenverarbeitun= g, > > > weiss at uni-mainz.de < > http://lists.freebsd.org/mailman/listinfo/freebsd-arm> |55099 > > Mainz, Tel: +49(6131)39-26361, FAX: +49(6131)39-26407 > > > > > > >/ -----Original Message----- > > > />/ From:owner-freebsd-arm at freebsd.org > > [mailto: > owner-freebsd-arm at > > freebsd.org ] > On Behalf Of > > > />/ Ian Lepore > > > />/ Sent: Sunday, September 21, 2014 3:44 PM > > > />/ To: Lundberg, Johannes > > > />/ Cc:freebsd-arm at freebsd.org < > http://lists.freebsd.org/mailman/listinfo/freebsd- > > arm> > > > />/ Subject: Re: Jetson TK1 board support > > > />/ > > > />/ On Sun, 2014-09-21 at 16:45 +0900, Lundberg, Johannes wrote: > > > />/ > Great! > > > />/ > > > > />/ > What I've done so far is > > > />/ > > > > />/ > - build and patch (enable API) u-boot-nvidia on freebsd (i > think i got it > > > />/ > fromgit://nv-tegra.nvidia.com/3rdparty/u-boot.git, the normal > u-boot > > > />/ > wouldn't work...) > > > />/ > - flash u-boot-dtb-tegra.img onto the board's mmc using > nvidia's flash tool > > > />/ > on ubuntu > > > />/ > - build an image using crochet and dd to sd card (so far I > copied the > > > />/ > beaglebone setup, just to get a ubldr and a kernel file) > > > />/ > > > > />/ > > > > />/ > From u-boot I can see all devices. I load ubldr with > > > />/ > fatload mmc 1:1 0x80200000 ubldr > > > />/ > bootelf 0x80200000 > > > />/ > > > > />/ > ubldr load fine but, from ubldr I can only see the mmc 0 and > net devices. > > > />/ > There's no sd card (mmc 1), and no ufs partition.. > > > />/ > > > > />/ > > > > />/ > > > > />/ > > > > />/ > -- > > > />/ > Johannes Lundberg > > > />/ > BRILLIANTSERVICE CO., LTD. > > > />/ > > > > />/ > On Fri, Sep 19, 2014 at 8:25 PM, John Howie thehowies.com > > > wrote: > > > />/ > > > > />/ > > Hi all, > > > />/ > > > > > />/ > > I am up for testing and supporting this board. I ordered and > received > > > />/ > > mine, but have not really had a chance to use it due to work > to-date. The > > > />/ > > good news is the next few months I will have bandwidth. > > > />/ > > > > > />/ > > Regards, > > > />/ > > > > > />/ > > John > > > />/ > > > > > />/ > > > > > />/ > > On 9/19/14, 12:15 PM, "Lundberg, Johannes" > > > />/ > > > > wrote: > > > />/ > > > > > />/ > > >Hi > > > />/ > > > > > > />/ > > >I started working on adding the Jetson TK1 board to Crochet= . > Is there any > > > />/ > > >work in progress on this? > > > />/ > > >I guess there is quite a lot of work that has to been done > to get full > > > />/ > > >support for it in the kernel as well.. > > > />/ > > > > > > />/ > > >Best regards > > > />/ > > >-- > > > />/ > > >Johannes Lundberg > > > />/ > > > > > > />/ > > > />/ You may have to change some u-boot options to support multiple > mmc/sd > > > />/ interfaces. Look in the config header for > CONFIG_SYS_MMC_MAX_DEVICE; if > > > />/ it's not there you may need to add it. For wandboard I also had > to add > > > />/ a freescale-specific one, CONFIG_SYS_FSL_USDHC_NUM, so there may > be > > > />/ something like that you need to find as well. > > > />/ > > > />/ -- Ian > > > />/ > > > />/ > > > />/ _______________________________________________ > > > />/ freebsd-arm at freebsd.org < > http://lists.freebsd.org/mailman/listinfo/freebsd-arm> > > mailing list > > > />/ http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > />/ To unsubscribe, send any mail to "freebsd-arm-unsubscribe at > freebsd.org > > "/ > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 00:35:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0037BA7 for ; Fri, 3 Oct 2014 00:35:40 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CFB739B4 for ; Fri, 3 Oct 2014 00:35:40 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s930Zefb091264 for ; Fri, 3 Oct 2014 00:35:40 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 194101] Packet forwarding not working with nat Date: Fri, 03 Oct 2014 00:35:41 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.1-BETA3 X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: direct727@gmail.com X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 00:35:41 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194101 --- Comment #2 from direct727@gmail.com --- More testing... it turns out that the behaviour of packet forwarding with pf nat, on arm, has changed over the last six weeks or so. With my early July and early August images I could not get packets forwarded over the Pi no matter what I tried. Now with 10.1-BETA3, the Pi is in fact forwarding packets on the simplest possible ruleset as described in the initial bug report. I can boot the machine and nat is working from boot. However, if I use the production pf.conf file that I'm currently running on an x86 machine, I get the following behaviour:- 1. On boot, no forwarding 2. Log in, then "service pf restart", and suddenly packet forwarding works. (Same pf.conf as on the x86 machine, nothing else changed) So something in my production pf.conf is causing the pf service to trip up at boot time on arm. Friday here, and I won't be able to get back on this till next week. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 03:42:18 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 97DEBB27; Fri, 3 Oct 2014 03:42:18 +0000 (UTC) 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 7126CD08; Fri, 3 Oct 2014 03:42:18 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=T3N92iOf3FKWEZ3ZCLXRa/UTxBl61SjCh+UFscLv9cU=; b=cEvNuCRvJThO6TiALQxYIDn4PbfcqTtSOodD7NYIhHoMNa+yJoUQChgTltjS06ekO3Fy7Y0+EbaHv7xgZCnL9eSzaoVNEDiovSfLvengYfnsHV/blE2+1j97H9Qry853nw+xpiVWAmHlKZAeiLY8cwq+UEd6DfCquXnw1mF3uss=; Received: from [182.8.76.161] (port=10913 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XZtl1-000D6s-JH; Thu, 02 Oct 2014 21:42:16 -0600 Date: Fri, 3 Oct 2014 11:42:08 +0800 From: Erich Dollansky To: YAMAMOTO Shigeru Subject: Re: FreeBSD 10.1-BETA3 Now Available Message-ID: <20141003114208.44b82af0@X220.alogt.com> In-Reply-To: <20141001.010528.1222668648660002950.shigeru@os-hackers.jp> References: <20140929023616.GG75063@hub.FreeBSD.org> <20140929123327.6ab0207c@X220.alogt.com> <20140929.142712.117419748410715004.shigeru@os-hackers.jp> <20141001.010528.1222668648660002950.shigeru@os-hackers.jp> 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-Source: X-Source-Args: X-Source-Dir: Cc: gjb@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-stable@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 03:42:18 -0000 Hi, On Wed, 01 Oct 2014 01:05:28 +0900 (JST) YAMAMOTO Shigeru wrote: > >>>>> "shigeru" == YAMAMOTO Shigeru writes: > >>>>> "Erich" == Erich Dollansky writes: > >> On Sun, 28 Sep 2014 22:36:16 -0400 Glen Barber > >> wrote: Why not try the images already available here? > >> http://ftp.freebsd.org/pub/FreeBSD/releases/ISO-IMAGES/10.1/ > >> I have tried it now several times. All with the same result. > > I get SD image, FreeBSD-10.1-BETA3-arm-armv6-RPI-B.img.bz2, from that > URL. > > When using original SD image, I can't boot because a kernel does not > find root file system. > > I get a new firmware from https://github.com/raspberrypi/firmware/ > and I replace *.dat, *.elf in SD image. > > # git clone https://github.com/raspberrypi/firmware.git > # mount_msdosfs /dev/da0s1 /mnt > # cp ./firmware/boot/*.dat /mnt/. > # cp ./firmware/boot/*.elf /mnt/. > # umount /mnt > > After replacing firmware image in SD image, I can boot RaspberryPi B+. I did this again after realising that my firmware version could be outdated. And yes, after copying the files, the Raspberry booted with the network becoming available. I am fighting at the moment with a very strange thing. I work a lot with jails. After building 10.1 from sources for the Raspberry and a reboot on the machine used, my jails do not connect to the network anymore. I also compiled now most of my software I will need on the Raspberry itself without major problems. Erich From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 04:44:26 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 81C3F2DF for ; Fri, 3 Oct 2014 04:44:26 +0000 (UTC) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3F2AE250 for ; Fri, 3 Oct 2014 04:44:26 +0000 (UTC) Received: by mail-yk0-f171.google.com with SMTP id 79so122389ykr.30 for ; Thu, 02 Oct 2014 21:44:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=teXpkfArkK32rGup/QdfTq3O5tmWJ+Eydqc5XjGJx8E=; b=AYtNe/hQjkJZnww/vpx6TINwI7tTWTZr2CSBlJ0ZudN9dvt7NNo3Jqq4rEOVvE7o/5 42iliADwQGXCAAvEVRkA9O80gzXTKa4BE1wpDy+HjJkmOq/J07NNxqRwX3x2Piq8Aaot uqztxaRfYw/oDNbI8bsHDbpoz2JWV83lCffIR/inXVmrneg4EbmoaskhoExtc8+9ggaz xhJS+UMgH8Su9QsbYTbiAk0k3ZfLHOAyEKEZkinrj7jUsRUw26lF04zUwrk8fl/amkwM HCnEzmMRrtHvk75fMjcWaVuP9pxS6HXulDN5QWC7MlMWU/fz2eQCIvWT8fGmOEIJsJDi rxng== MIME-Version: 1.0 X-Received: by 10.236.223.74 with SMTP id u70mr4586075yhp.154.1412311465188; Thu, 02 Oct 2014 21:44:25 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Thu, 2 Oct 2014 21:44:25 -0700 (PDT) In-Reply-To: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> Date: Thu, 2 Oct 2014 21:44:25 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 04:44:26 -0000 Warner, I was looking for a Digi reference but it turns out the Nand Flash Controller is part of the Freescale Processor. Here is the link to the Reference Manual: cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. Is this relevant to what you are looking at doing? https://wiki.freebsd.org/NAND I also found something called CHFS for NetBSD that looks interesting: http://chewiefs.sed.hu/home Thanks, Russ On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: > > On Oct 1, 2014, at 12:48 AM, Russell Haley wrote: > > > Warner, > > > > First, I was just watching your 2010 talk on supporting FreeBSD in a > commercial environment. Has there been any updates in the process of > maintaining a commercial branch in the last 4 years (not that I have any > commercial ventures yet! lolz)? > > > > Anyway, I talked to an Engineer about the NAND controller spec and he > chided me for being naive (poor little software developer, in way over hi= s > head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, whi= ch > I have yet to find on the Digi site. > > URL + section number. 5k pages doesn=E2=80=99t necessarily mean it will b= e useful, > though. :( > > > I have however found this hardware reference: > > > > http://ftp1.digi.com/support/documentation/90001270_E.pdf > > > > From Page 41: > > > > NAND flash memory > > The ConnectCore for i.MX53 module provides 8GB of NAND flash memory. On > the module in > > the development kits a 512MByte, 2Kbyte page, NAND flash chip is used. > This NAND flash > > device is connected to NAND flash Chip Select 0. > > The NAND flash controller signals are available on the module connector= s. > > This basically says nothing more useful than =E2=80=9CThere=E2=80=99s NAN= D on this board > that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is useful, but far from suff= icient. How do I > program the DMA so that ECC is added to the OOB areas of that NAND? How d= o > I set different ECC tables? How do I do ECC error correction and detectio= n? > If you can=E2=80=99t answer that sort of question from the docs you have,= then they > aren=E2=80=99t helpful enough. > > > There are pin references to NAND further down in the section "GPIO > multiplexing table in the ConnectCore for i.MX53 module" on page 44 and 4= 9. > > > > I fear this is not the information we are looking for. > > Not really. The GPIO info might be mildly helpful in a few cases > > > I have found another u-boot fork for the CCWMX53 on github here: > https://github.com/Varcain/uboot-ccwmx53-digi > > > > With what seems to be the information about booting from NAND here: > https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl > > > > If you can let me know what I am looking for I can both ask a more > directed question at work and also perform a better search. > > > > I have also started looking over the Architecture handbook as well > because I have a feeling there is going to be lots of driver code in my > future. > > A good first step would be to get a URL or search string to get the URL > for that big spec. It is of the right size to possibly be useful, but > sometimes really long specs have 1-2 page descriptions of things like the > SD controller or the NAND controller that you need special NDAs + busines= s > arrangements to get, so it is hard to say=E2=80=A6 > > Warner > > > > > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wrote: > > > > On Sep 27, 2014, at 9:49 PM, Russell Haley wrote= : > > > > > I will attempt to load the kernel from tftp as soon as I can. I will > need > > > to figure out how to get ethernet to the unit. > > > > > > I know nothing about u-boot so forgive my ignorance but I was hoping = to > > > modify the Arndale configuration to work such as: > > > > > > # mmc read 1 0x70800000 0x800 0x1800; > > > #go 0x70800000; > > > > > > and then point the rootfs to /dev/da1s1 > > > > > > On another note, do you know where I could find out more about the > missing > > > MTD support? > > > > A spec for the NAND controller is needed to make that work=E2=80=A6 Is= one > about? > > > > Warner > > > > > > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many > cool > > > projects, so little time... > > > > > > Thanks, > > > > > > Russ > > > > > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > > > > > >> On Sep 27, 2014, at 13:31, Russell Haley > wrote: > > >>> > > >>> Rui, > > >>> > > >>> So no MTD means the NAND on the SOM is out, but can I boot the kern= el > > >> and load rootfs from the microSD, like in this example: > > >>> =E2=80=A2 > > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bin= ; > go > > >> 0x40f00000" > > >>> > > >>> ARNDALE5250 # saveenv > > >>> > > >>> ARNDALE5250 # boot > > >> > > >> You can't use the Arndale config since the load addresses are > different. > > >> You should be able to load a kernel from the network. Can you do > that? > > >> > > >> -- > > >> Rui Paulo > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org= " > > > > > > From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 06:06:44 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B85B780E for ; Fri, 3 Oct 2014 06:06:44 +0000 (UTC) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7403CB2B for ; Fri, 3 Oct 2014 06:06:44 +0000 (UTC) Received: by mail-yk0-f178.google.com with SMTP id 9so147286ykp.23 for ; Thu, 02 Oct 2014 23:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=X8P4YLDonkuLQuww1reg04BifsDo0VYeH4N5OaRJpcE=; b=N8m+vKwM3j7xHaSLWLlewKQMEyJV8YfDivrSPkBOJGJ7lzzeUHHAxL23sDazIzbw22 SPLBSUMFq90cBmNLHRQ3f7YwSjmcpgMUETNphl9j4bZy4OTYbbMaOE59sz4iXLFUAglQ QgBQhCLKbyAGAWQEJIShJnR4/NduWTDC36c+wzLfZLedG1Jlx88/rv7k1XygL3I5ZCAd cNbv69GAbdWtT1yANcdTPF7fOqdhH8UYtQAVy3zB82Sp59U0hw8lxeTQba4xZBfpXlTr 8KCS6V1zFnLp8fUBd87GpEkufQMrVUuIwjGy771NVPSfxM+GS8i4BUzmRxpqMwVsfyja xm4g== MIME-Version: 1.0 X-Received: by 10.236.91.100 with SMTP id g64mr4990467yhf.11.1412316403116; Thu, 02 Oct 2014 23:06:43 -0700 (PDT) Received: by 10.170.208.13 with HTTP; Thu, 2 Oct 2014 23:06:43 -0700 (PDT) In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> Date: Thu, 2 Oct 2014 23:06:43 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 06:06:44 -0000 Gentlemen, So one of my next steps is to get rootfs to mount. I THINK I have found out that the kernel uses an option in the kernel config file called ROOTDEVNAME. That - as far as I can tell - means the root device name is set at compile time? In my current case I wanted to boot the kernel I already have and then use the manual process to load rootfs. I tried using installworld on a 4 GB USB stick. This is my process: gpart create -s mbr da4 gpart add -t freebsd da4 sudo newfs /dev/da4s1 mount /dev/da4s1 /usr/jails/FreeArm2/mnt/usb make TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt/usb installworld distribution This *seemed* to work but I did not get a nifty little message at the end of installworld telling me the install process was completed successfully as I did with buildworld or buildkernel. Once my kernel booted and I got to the manual prompt I used the following command: mountroot> ufs:/dev/da1s1a #also tried ufs:/dev/da1s1 Trying to mount root from ufs:/dev/da1s1a []... mountroot: waiting for device /dev/da1s1a ... Mounting from ufs:/dev/da1s1a failed with error 19. boo. :( So, my questions are: 1) Is a 4GB USB drive enough space? 2) Did the lack of "nifty little message" mean installworld failed? I didn't get any error messages, it just seemed to stop (i.e. a new command prompt). 3) Is my above partitioning correct? I just found this article that says I should be using GPT not MBR: http://www.wonkity.com/~wblock/docs/html/disksetup.html 4) Is my assumption that the rootfs is hard coded into the kernel true or is this one of many of my over simplifications? Could anyone point me to some good documentation about this? I would normally spend much more time researching this myself but I'm so close to having something to play with I'm becoming impatient!!! Many Thanks and good night. Russ On Thu, Oct 2, 2014 at 9:44 PM, Russell Haley wrote: > Warner, > > I was looking for a Digi reference but it turns out the Nand Flash > Controller is part of the Freescale Processor. Here is the link to the > Reference Manual: > > cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf > > The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. > > Is this relevant to what you are looking at doing? > https://wiki.freebsd.org/NAND > > I also found something called CHFS for NetBSD that looks interesting: > http://chewiefs.sed.hu/home > > Thanks, > Russ > > > > > > > > On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: > >> >> On Oct 1, 2014, at 12:48 AM, Russell Haley wrote: >> >> > Warner, >> > >> > First, I was just watching your 2010 talk on supporting FreeBSD in a >> commercial environment. Has there been any updates in the process of >> maintaining a commercial branch in the last 4 years (not that I have any >> commercial ventures yet! lolz)? >> > >> > Anyway, I talked to an Engineer about the NAND controller spec and he >> chided me for being naive (poor little software developer, in way over h= is >> head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, wh= ich >> I have yet to find on the Digi site. >> >> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it will = be >> useful, though. :( >> >> > I have however found this hardware reference: >> > >> > http://ftp1.digi.com/support/documentation/90001270_E.pdf >> > >> > From Page 41: >> > >> > NAND flash memory >> > The ConnectCore for i.MX53 module provides 8GB of NAND flash memory. O= n >> the module in >> > the development kits a 512MByte, 2Kbyte page, NAND flash chip is used. >> This NAND flash >> > device is connected to NAND flash Chip Select 0. >> > The NAND flash controller signals are available on the module >> connectors. >> >> This basically says nothing more useful than =E2=80=9CThere=E2=80=99s NA= ND on this board >> that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is useful, but far from suf= ficient. How do I >> program the DMA so that ECC is added to the OOB areas of that NAND? How = do >> I set different ECC tables? How do I do ECC error correction and detecti= on? >> If you can=E2=80=99t answer that sort of question from the docs you have= , then they >> aren=E2=80=99t helpful enough. >> >> > There are pin references to NAND further down in the section "GPIO >> multiplexing table in the ConnectCore for i.MX53 module" on page 44 and = 49. >> > >> > I fear this is not the information we are looking for. >> >> Not really. The GPIO info might be mildly helpful in a few cases >> >> > I have found another u-boot fork for the CCWMX53 on github here: >> https://github.com/Varcain/uboot-ccwmx53-digi >> > >> > With what seems to be the information about booting from NAND here: >> https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >> > >> > If you can let me know what I am looking for I can both ask a more >> directed question at work and also perform a better search. >> > >> > I have also started looking over the Architecture handbook as well >> because I have a feeling there is going to be lots of driver code in my >> future. >> >> A good first step would be to get a URL or search string to get the URL >> for that big spec. It is of the right size to possibly be useful, but >> sometimes really long specs have 1-2 page descriptions of things like th= e >> SD controller or the NAND controller that you need special NDAs + busine= ss >> arrangements to get, so it is hard to say=E2=80=A6 >> >> Warner >> >> > >> > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wrote: >> > >> > On Sep 27, 2014, at 9:49 PM, Russell Haley >> wrote: >> > >> > > I will attempt to load the kernel from tftp as soon as I can. I will >> need >> > > to figure out how to get ethernet to the unit. >> > > >> > > I know nothing about u-boot so forgive my ignorance but I was hoping >> to >> > > modify the Arndale configuration to work such as: >> > > >> > > # mmc read 1 0x70800000 0x800 0x1800; >> > > #go 0x70800000; >> > > >> > > and then point the rootfs to /dev/da1s1 >> > > >> > > On another note, do you know where I could find out more about the >> missing >> > > MTD support? >> > >> > A spec for the NAND controller is needed to make that work=E2=80=A6 I= s one >> about? >> > >> > Warner >> > >> > >> > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many >> cool >> > > projects, so little time... >> > > >> > > Thanks, >> > > >> > > Russ >> > > >> > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: >> > > >> > >> On Sep 27, 2014, at 13:31, Russell Haley >> wrote: >> > >>> >> > >>> Rui, >> > >>> >> > >>> So no MTD means the NAND on the SOM is out, but can I boot the >> kernel >> > >> and load rootfs from the microSD, like in this example: >> > >>> =E2=80=A2 >> > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 >> kernel.bin; go >> > >> 0x40f00000" >> > >>> >> > >>> ARNDALE5250 # saveenv >> > >>> >> > >>> ARNDALE5250 # boot >> > >> >> > >> You can't use the Arndale config since the load addresses are >> different. >> > >> You should be able to load a kernel from the network. Can you do >> that? >> > >> >> > >> -- >> > >> Rui Paulo >> > >> >> > >> >> > >> >> > >> >> > > _______________________________________________ >> > > freebsd-arm@freebsd.org mailing list >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g >> " >> > >> > >> >> > From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 06:16:09 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D51958FC for ; Fri, 3 Oct 2014 06:16:09 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtpout002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9175BEE for ; Fri, 3 Oct 2014 06:16:09 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCU000PKUQGRJ80@st11p02mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Fri, 03 Oct 2014 06:15:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-03_04:2014-10-03,2014-10-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410030067 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1988\)) Subject: Re: Digi CCWMX53 From: Rui Paulo In-reply-to: Date: Thu, 02 Oct 2014 23:15:51 -0700 Content-transfer-encoding: 7bit Message-id: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> To: Russell Haley X-Mailer: Apple Mail (2.1988) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 06:16:10 -0000 On Oct 2, 2014, at 23:06, Russell Haley wrote: > > Gentlemen, > > So one of my next steps is to get rootfs to mount. I THINK I have found out > that the kernel uses an option in the kernel config file > called ROOTDEVNAME. That - as far as I can tell - means the root device > name is set at compile time? In my current case I wanted to boot the kernel > I already have and then use the manual process to load rootfs. I tried > using installworld on a 4 GB USB stick. This is my process: > > gpart create -s mbr da4 > gpart add -t freebsd da4 > sudo newfs /dev/da4s1 > mount /dev/da4s1 /usr/jails/FreeArm2/mnt/usb > > make TARGET_ARCH=armv6 DESTDIR=/mnt/usb installworld distribution > > This *seemed* to work but I did not get a nifty little message at the end > of installworld telling me the install process was completed successfully > as I did with buildworld or buildkernel. > > Once my kernel booted and I got to the manual prompt I used the following > command: > > mountroot> ufs:/dev/da1s1a #also tried ufs:/dev/da1s1 > > Trying to mount root from ufs:/dev/da1s1a []... > mountroot: waiting for device /dev/da1s1a ... > Mounting from ufs:/dev/da1s1a failed with error 19. > > boo. :( > > So, my questions are: > > 1) Is a 4GB USB drive enough space? Yes > 2) Did the lack of "nifty little message" mean installworld failed? I > didn't get any error messages, it just seemed to stop (i.e. a new command > prompt). No > 3) Is my above partitioning correct? I just found this article that says I > should be using GPT not MBR: > http://www.wonkity.com/~wblock/docs/html/disksetup.html It should still work. > 4) Is my assumption that the rootfs is hard coded into the kernel true or > is this one of many of my over simplifications? Could anyone point me to > some good documentation about this? It's hard coded if you use the ROOTDEVNAME option. > I would normally spend much more time researching this myself but I'm so > close to having something to play with I'm becoming impatient!!! Are you sure it's da1? It's not da0? Can you show us the boot log? -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 07:05:40 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74D18CC7 for ; Fri, 3 Oct 2014 07:05:40 +0000 (UTC) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 30116F92 for ; Fri, 3 Oct 2014 07:05:40 +0000 (UTC) Received: by mail-yh0-f44.google.com with SMTP id i57so168068yha.31 for ; Fri, 03 Oct 2014 00:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=wanvrB2/IdpKVM8zLQQ3V9bhGw+XtyNUxbpJjiZD880=; b=iwKCeukxuw3RC4Ig+W1KTV739QpQamPrFHFDCDv040TaKhnXS/sDtd0L4EhZg7Xv0A mVRQ0clyTsP+fjozxU/BOj6bejbfI7RIKUJej2wm2V0ZTa3aEpY2hDtKMoWUlwrV9YWo BRd7oKpoo8eporhfu7c7HP68B0RGg95UC0PlAB3NMrJfJxDxIead26zDBFQReqB9DhnL ZVFKBsir8JWT/DtzNu2QbyEYNVJn7tDmm6xkbAk2qD2HzpZc2gDfmyNVaNcXaxEl+Qep zT6hSVrB6frSGNNWi/xOJQVlrPtQVvp9BLaBskwWUbzbs5IUtr9Pkp/HsHCNgscHjVvM bgRQ== MIME-Version: 1.0 X-Received: by 10.236.70.229 with SMTP id p65mr5488245yhd.50.1412319939044; Fri, 03 Oct 2014 00:05:39 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Fri, 3 Oct 2014 00:05:38 -0700 (PDT) In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> Date: Fri, 3 Oct 2014 00:05:38 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 07:05:40 -0000 > It's hard coded if you use the ROOTDEVNAME option. Does this mean there is another option besides kernel config or manual load at boot time? I'm more than happy to read the handbook (RTFH?) if you can point me to a section? Here is my boot log including my load attempt: U-Boot 2009.08 - dub-1.6.4.1 - (Sep 25 2014 - 09:51:55) - GCC 4.4.6 for ConnectCore for i.MX53 on a JumpStart Kit Development Board I2C: ready NAND: 512 MiB MMC: FSL_ESDHC: 0, FSL_ESDHC: 1 DRAM: 1 GB In: serial Out: serial Err: serial Net: FEC0 [PRIME] Hit any key to stop autoboot: 0 FEC: enable RMII gasket Using FEC0 device TFTP from server 192.168.0.55; our IP address is 192.168.0.1 Filename 'kernel'. Load address: 0x70800000 Loading: T ################################################################= # ################################################################# ################################################################# ################################################################# ################################################################# ################################################################# ################# done Bytes transferred =3D 5962108 (5af97c hex) ## Starting application at 0x70800100 ... KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2014 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #0 r272269: Sun Sep 28 23:47:53 PDT 2014 root@FreeArm2:/usr/obj/arm.armv6/usr/src/sys/DIGI-CCWMX53 arm FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 WARNING: WITNESS option enabled, expect reduced performance. Preloaded elf kernel "kernel" at 0xc086faec. CPU: Cortex A8-r2 rev 5 (Cortex-A core) Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext WB disabled EABT branch prediction enabled LoUU:2 LoC:2 LoUIS:1 Cache level 1: 32KB/64B 4-way data cache WT WB Read-Alloc 32KB/64B 4-way instruction cache Read-Alloc Cache level 2: 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc real memory =3D 536870912 (512 MB) avail memory =3D 514514944 (490 MB) Physical memory chunk(s): 0x70000000 - 0x7fffffff, 256 MB ( 65536 pages) 0xb0000000 - 0xbfffffff, 256 MB ( 65536 pages) Excluded memory regions: 0x70800000 - 0x710bbfff, 8 MB ( 2236 pages) NoAlloc Static device mappings: 0x50000000 - 0x500fffff mapped at VA 0xffe00000 0x53f00000 - 0x53ffffff mapped at VA 0xffd00000 0x63f00000 - 0x63ffffff mapped at VA 0xffc00000 random device not loaded; using insecure entropy wlan: <802.11 Link Layer> null: openfirm: Falling back to random adaptor random: initialized mem: nfslock: pseudo-device ofwbus0: ofwbus0: type unknown (no driver attached) simplebus0: on ofwbus0 tzic0: mem 0xfffc000-0xfffffff on simplebu= s0 simplebus1: on ofwbus0 simplebus2: on simplebus1 imxccm0: mem 0x53fd4000-0x53fd7fff,0x63f80000-0x63f83fff,0x63f84000-0x63f87fff,0x63f8800= 0-0x63f8bfff irq 71,72 on simplebus2 imxccm0: PLL1=3D800MHz, PLL2=3D400MHz, PLL3=3D216MHz imxccm0: CPU clock=3D800000000, UART clock=3D66666666 imxccm0: mainbus clock=3D400000000, ahb clock=3D133333333 ipg clock=3D66666666 perclk=3D33333333 gpio0: mem 0x53f84000-0x53f87fff irq 50,51,42,43,44,45,46,47,48,49 on simplebus2 gpioc0: on gpio0 gpiobus0: on gpio0 gpio1: mem 0x53f88000-0x53f8bfff irq 52,53 on simplebus2 simplebus2: no default resources for rid =3D 2, type =3D 1 gpioc1: on gpio1 gpiobus1: on gpio1 gpio2: mem 0x53f8c000-0x53f8ffff irq 54,55 on simplebus2 simplebus2: no default resources for rid =3D 2, type =3D 1 gpioc2: on gpio2 gpiobus2: on gpio2 gpio3: mem 0x53f90000-0x53f93fff irq 56,57 on simplebus2 simplebus2: no default resources for rid =3D 2, type =3D 1 gpioc3: on gpio3 gpiobus3: on gpio3 gpio4: mem 0x53fdc000-0x53fdffff irq 103,104 on simplebus2 simplebus2: no default resources for rid =3D 2, type =3D 1 gpioc4: on gpio4 gpiobus4: on gpio4 gpio5: mem 0x53fe0000-0x53fe3fff irq 105,106 on simplebus2 simplebus2: no default resources for rid =3D 2, type =3D 1 gpioc5: on gpio5 gpiobus5: on gpio5 gpio6: mem 0x53fe4000-0x53fe7fff irq 107,108 on simplebus2 simplebus2: no default resources for rid =3D 2, type =3D 1 gpioc6: on gpio6 gpiobus6: on gpio6 simplebus3: on simplebus2 simplebus3: mem 0x50004000-0x50007fff irq 1 compat fsl,imx53-esdhc (no driver attached) simplebus3: mem 0x50008000-0x5000bfff irq 2 compat fsl,imx53-esdhc (no driver attached) simplebus3: mem 0x5000c000-0x5000ffff irq 33 disabled compat fsl,imx53-uart (no driver attached) simplebus3: mem 0x50010000-0x50013fff irq 36 disabled compat fsl,imx53-ecspi (no driver attached) simplebus3: mem 0x50014000-0x50017fff irq 30 compat fsl,imx53-ssi (no driver attached) simplebus3: mem 0x50020000-0x50023fff irq 3 disabled compat fsl,imx53-esdhc (no driver attached) simplebus3: mem 0x50024000-0x50027fff irq 4 disabled compat fsl,imx53-esdhc (no driver attached) simplebus3: mem 0x50030000-0x50033fff irq 70 disabled compat fsl,imx53-ata (no driver attached) usbphy0: on simplebus2 usbphy1: on simplebus2 ehci0: mem 0x53f80000-0x53f801ff irq 18 on simplebus2 ehci0: [GIANT-LOCKED] usbus0: EHCI version 1.0 usbus0 on ehci0 ehci0: usbpf: Attached ehci1: mem 0x53f80200-0x53f803ff irq 14 on simplebus2 ehci1: [GIANT-LOCKED] usbus1: EHCI version 1.0 usbus1 on ehci1 ehci1: usbpf: Attached simplebus2: mem 0x53f80400-0x53f805ff irq 16 disabled compat fsl,imx53-usb (no driver attached) simplebus2: mem 0x53f80600-0x53f807ff irq 17 disabled compat fsl,imx53-usb (no driver attached) simplebus2: mem 0x53f80800-0x53f809ff compat fsl,imx53-usbmisc (no driver attached) imx_wdog0: mem 0x53f98000-0x53f9bfff irq 58 on simplebus2 simplebus2: mem 0x53f9c000-0x53f9ffff irq 59 disabled compat fsl,imx53-wdt (no driver attached) simplebus2: mem 0x53f94000-0x53f97fff irq 60 disabled compat fsl,imx53-kpp (no driver attached) imx_gpt0: mem 0x53fa0000-0x53fa3fff irq 39 on simplebus2 imx_gpt0: Running on 11111KHz clock, base freq 66666666Hz CR=3D0x0000027d, PR=3D0x00000005 Event timer "iMXGPT" frequency 11111111 Hz quality 800 Timecounter "iMXGPT" frequency 11111111 Hz quality 1000 simplebus2: mem 0x53fa4000-0x53fa7fff irq 24,25 disabled compat fsl,imx53-srtc (no driver attached) simplebus2: mem 0x53fa8000-0x53fabfff irq 7 compat fsl,imx53-iomux (no driver attached) simplebus2: mem 0x53fac000-0x53faffff irq 40 disabled compat fsl,imx53-epit (no driver attached) simplebus2: mem 0x53fb0000-0x53fb3fff irq 41 disabled compat fsl,imx53-epit (no driver attached) simplebus2: mem 0x53fb4000-0x53fb7fff irq 61 disabled compat fsl,imx53-pwm (no driver attached) simplebus2: mem 0x53fb8000-0x53fbbfff irq 94 disabled compat fsl,imx53-pwm (no driver attached) uart0: mem 0x53fbc000-0x53fbffff irq 31 on simplebus2 uart0: console (115200,n,8,1) uart0: fast interrupt uart1: mem 0x53fc0000-0x53fc3fff irq 32 on simplebus2 uart1: fast interrupt uart2: mem 0x53ff0000-0x53ff3fff irq 13 on simplebus2 uart2: fast interrupt simplebus2: mem 0x53fd0000-0x53fd3fff irq 75 disabled compat fsl,imx53-src (no driver attached) simplebus2: mem 0x53fd8000-0x53fdbfff irq 73,74 disabled compat fsl,imx53-gpc (no driver attached) iichb0: mem 0x53fec000-0x53feffff irq 64 on simplebus2 iicbus0: on iichb0 iic0: on iicbus0 iicbus0: at addr 0x48 simplebus4: on simplebus1 uart3: mem 0x63f90000-0x63f93fff irq 32 on simplebus4 uart3: fast interrupt simplebus4: mem 0x63fac000-0x63faffff irq 37 disabled compat fsl,imx53-ecspi (no driver attached) simplebus4: mem 0x63fb0000-0x63fb3fff irq 6 compat fsl,imx53-sdma (no driver attached) simplebus4: mem 0x63fc0000-0x63fc3fff irq 38 disabled compat fsl,imx53-cspi (no driver attached) iichb1: mem 0x63fc4000-0x63fc7fff irq 63 on simplebus4 iicbus1: on iichb1 iic1: on iicbus1 iichb2: mem 0x63fc8000-0x63fcbfff irq 62 on simplebus4 iicbus2: on iichb2 iic2: on iicbus2 simplebus4: mem 0x63fcc000-0x63fcffff irq 29 disabled compat fsl,imx53-ssi (no driver attached) simplebus4: mem 0x63fd4000-0x63fd7fff compat fsl,imx53-audmux (no driver attached) simplebus4: mem 0x63fe8000-0x63febfff irq 96 disabled compat fsl,imx51-ssi (no driver attached) ffec0: mem 0x63fec000-0x63feffff irq 87 on simplebus4 ffec0: MAC address 00:40:9d:76:33:08: miibus0: on ffec0 smscphy0: PHY 0 on miibus0 smscphy0: OUI 0x00800f, model 0x000f, rev. 1 smscphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto ffec0: bpf attached ffec0: Ethernet address: 00:40:9d:76:33:08 simplebus4: (no driver attached) simplebus5: on ofwbus0 atapci0: mem 0x10000000-0x10003fff irq 28 on simplebus5 ata2: at channel 0 on atapci0 simplebus5: mem 0x1e000000-0x1e007fff,0x1e008000-0x1e00ffff,0x1e018000-0x1e01ffff,0x1e02000= 0-0x1e027fff,0x1e028000-0x1e02ffff,0x1e030000-0x1e037fff,0x1e038000-0x1e03f= fff,0x1e040000-0x1e047fff,0x1e048000-0x1e04ffff,0x1e050000-0x1e057fff,0x1e0= 58000-0x1e05ffff,0x1e060000-0x1e067fff,0x1e068000-0x1e06ffff,0x1f000000-0x1= f01ffff,0x1f020000-0x1f03ffff,0x1f040000-0x1f05ffff,0x1f060000-0x1f07ffff,0= x1f080000-0x1f09ffff irq 10,11 compat fsl,ipu3 (no driver attached) Timecounters tick every 10.000 msec tcp_init: net.inet.tcp.tcbhashsize auto tuned to 4096 lo0: bpf attached random: unblocking device. lock order reversal: 1st 0xc0872400 entropy harvest mutex (entropy harvest mutex) @ /usr/src/sys/dev/random/random_harvestq.c:198 2nd 0xc27f1a20 uart_hwmtx (uart_hwmtx) @ /usr/src/sys/dev/uart/uart_cpu.h:= 94 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc047e0d0 lr =3D 0xc0139fdc (db_fetch_ksymtab+0x16c) sp =3D 0xdcfc49b0 fp =3D 0xdcfc4ac8 r10 =3D 0xc27f1a20 db_fetch_ksymtab() at db_fetch_ksymtab+0x16c pc =3D 0xc0139fdc lr =3D 0xc029e104 (kdb_backtrace+0x38) sp =3D 0xdcfc4ad0 fp =3D 0xdcfc4ad8 r4 =3D 0xc05cd3d4 r5 =3D 0xc04d0d52 r6 =3D 0xc04c3c2e r7 =3D 0xc04c3692 kdb_backtrace() at kdb_backtrace+0x38 pc =3D 0xc029e104 lr =3D 0xc02b89d4 (witness_checkorder+0xe4c) sp =3D 0xdcfc4ae0 fp =3D 0xdcfc4b30 r4 =3D 0xc04c3b1e witness_checkorder() at witness_checkorder+0xe4c pc =3D 0xc02b89d4 lr =3D 0xc02543b0 (__mtx_lock_spin_flags+0xc0) sp =3D 0xdcfc4b38 fp =3D 0xdcfc4b58 r4 =3D 0x00000000 r5 =3D 0xc05bd644 r6 =3D 0xc27f1a20 r7 =3D 0xc27f1a30 r8 =3D 0x0000005e r9 =3D 0xc04c3c2b r10 =3D 0xdcfc4ce0 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc0 pc =3D 0xc02543b0 lr =3D 0xc016d1c0 (uart_tty_detach+0x9a4) sp =3D 0xdcfc4b60 fp =3D 0xdcfc4b70 r4 =3D 0x0000006c r5 =3D 0xc05bd644 r6 =3D 0xc05cd3d0 r7 =3D 0xc05bde78 r8 =3D 0xc0592f70 r9 =3D 0xc05bde40 uart_tty_detach() at uart_tty_detach+0x9a4 pc =3D 0xc016d1c0 lr =3D 0xc021e31c (cnputc+0x80) sp =3D 0xdcfc4b78 fp =3D 0xdcfc4b90 r4 =3D 0x0000006c r5 =3D 0xc0585a80 r6 =3D 0xc05cd3d0 cnputc() at cnputc+0x80 pc =3D 0xc021e31c lr =3D 0xc02a4088 (kvprintf+0x135c) sp =3D 0xdcfc4b98 fp =3D 0xdcfc4c00 r4 =3D 0x0000006c r5 =3D 0xdcfc4ce0 r6 =3D 0xc0873ae8 r7 =3D 0x00000005 r8 =3D 0x00000000 r9 =3D 0xc02a3ef8 kvprintf() at kvprintf+0x135c pc =3D 0xc02a4088 lr =3D 0xc02a2dd0 (kvprintf+0xa4) sp =3D 0xdcfc4c08 fp =3D 0xdcfc4cc8 r4 =3D 0xc2614cd8 r5 =3D 0xc04e1e3b r6 =3D 0x00000000 r7 =3D 0x00000000 r8 =3D 0x00000000 r9 =3D 0xc02a3ef8 r10 =3D 0xdcfc4ce0 kvprintf() at kvprintf+0xa4 pc =3D 0xc02a2dd0 lr =3D 0xc02a45fc (printf+0x50) sp =3D 0xdcfc4cd0 fp =3D 0xdcfc4d00 r4 =3D 0xc2614cd8 r5 =3D 0xc0840a6c r6 =3D 0x00000000 r7 =3D 0x00000601 r8 =3D 0xc0840a60 r9 =3D 0xc0840a5c r10 =3D 0xc05cddfc printf() at printf+0x50 pc =3D 0xc02a45fc lr =3D 0xc02b872c (witness_checkorder+0xba4) sp =3D 0xdcfc4d18 fp =3D 0xdcfc4d68 witness_checkorder() at witness_checkorder+0xba4 pc =3D 0xc02b872c lr =3D 0xc02543b0 (__mtx_lock_spin_flags+0xc0) sp =3D 0xdcfc4d70 fp =3D 0xdcfc4d90 r4 =3D 0x00000000 r5 =3D 0xc276a960 r6 =3D 0xc05cddfc r7 =3D 0xc05cde0c r8 =3D 0x000000fb r9 =3D 0xc04e016c r10 =3D 0xc05bcf90 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc0 pc =3D 0xc02543b0 lr =3D 0xc02aabcc (sleepq_lock+0x34) sp =3D 0xdcfc4d98 fp =3D 0xdcfc4d98 r4 =3D 0xc016a068 r5 =3D 0xc276a960 r6 =3D 0xc05bcf80 r7 =3D 0xc04b381f r8 =3D 0xc276cc80 r9 =3D 0x00000000 sleepq_lock() at sleepq_lock+0x34 pc =3D 0xc02aabcc lr =3D 0xc02708dc (msleep_spin_sbt+0x7c) sp =3D 0xdcfc4da0 fp =3D 0xdcfc4de8 msleep_spin_sbt() at msleep_spin_sbt+0x7c pc =3D 0xc02708dc lr =3D 0xc01693c0 (random_harvestq_init+0x288) sp =3D 0xdcfc4df0 fp =3D 0xdcfc4e38 r4 =3D 0xc016a068 r5 =3D 0xc04c368f r6 =3D 0xc05bcf80 r7 =3D 0x00000000 r8 =3D 0x0000003a r9 =3D 0x00000000 r10 =3D 0xc05bcf90 random_harvestq_init() at random_harvestq_init+0x288 pc =3D 0xc01693c0 lr =3D 0xc02370c8 (fork_exit+0x84) sp =3D 0xdcfc4e40 fp =3D 0xdcfc4e58 r4 =3D 0xc276cc80 r5 =3D 0xc276a960 r6 =3D 0xc0169214 r7 =3D 0xc016a068 r8 =3D 0xdcfc4e60 r9 =3D 0x00000000 r10 =3D 0x00000000 fork_exit() at fork_exit+0x84 pc =3D 0xc02370c8 lr =3D 0xc047fd48 (swi_exit) sp =3D 0xdcfc4e60 fp =3D 0x00000000 r4 =3D 0xc0169214 r5 =3D 0xc016a068 r6 =3D 0x08343d00 r7 =3D 0x02602204 r8 =3D 0x00000000 swi_exit() at swi_exit pc =3D 0xc047fd48 lr =3D 0xc047fd48 (swi_exit) sp =3D 0xdcfc4e60 fp =3D 0x00000000 Unable to unwind further lock order reversal: 1st 0xc0872400 entropy harvest mutex (entropy harvest mutex) @ /usr/src/sys/dev/random/random_harvestq.c:198 2nd 0xc05cddfc sleepq chain (sleepq chain) @ /usr/src/sys/kern/subr_sleepqueue.c:251 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc047e0d0 lr =3D 0xc0139fdc (db_fetch_ksymtab+0x16c) sp =3D 0xdcfc4be8 fp =3D 0xdcfc4d00 r10 =3D 0xc05cddfc db_fetch_ksymtab() at db_fetch_ksymtab+0x16c pc =3D 0xc0139fdc lr =3D 0xc029e104 (kdb_backtrace+0x38) sp =3D 0xdcfc4d08 fp =3D 0xdcfc4d10 r4 =3D 0xc05cd3d4 r5 =3D 0xc04d0d52 r6 =3D 0xc04e016f r7 =3D 0xc04c3692 kdb_backtrace() at kdb_backtrace+0x38 pc =3D 0xc029e104 lr =3D 0xc02b89d4 (witness_checkorder+0xe4c) sp =3D 0xdcfc4d18 fp =3D 0xdcfc4d68 r4 =3D 0xc04e0154 witness_checkorder() at witness_checkorder+0xe4c pc =3D 0xc02b89d4 lr =3D 0xc02543b0 (__mtx_lock_spin_flags+0xc0) sp =3D 0xdcfc4d70 fp =3D 0xdcfc4d90 r4 =3D 0x00000000 r5 =3D 0xc276a960 r6 =3D 0xc05cddfc r7 =3D 0xc05cde0c r8 =3D 0x000000fb r9 =3D 0xc04e016c r10 =3D 0xc05bcf90 __mtx_lock_spin_flags() at __mtx_lock_spin_flags+0xc0 pc =3D 0xc02543b0 lr =3D 0xc02aabcc (sleepq_lock+0x34) sp =3D 0xdcfc4d98 fp =3D 0xdcfc4d98 r4 =3D 0xc016a068 r5 =3D 0xc276a960 r6 =3D 0xc05bcf80 r7 =3D 0xc04b381f r8 =3D 0xc276cc80 r9 =3D 0x00000000 sleepq_lock() at sleepq_lock+0x34 pc =3D 0xc02aabcc lr =3D 0xc02708dc (msleep_spin_sbt+0x7c) sp =3D 0xdcfc4da0 fp =3D 0xdcfc4de8 msleep_spin_sbt() at msleep_spin_sbt+0x7c pc =3D 0xc02708dc lr =3D 0xc01693c0 (random_harvestq_init+0x288) sp =3D 0xdcfc4df0 fp =3D 0xdcfc4e38 r4 =3D 0xc016a068 r5 =3D 0xc04c368f r6 =3D 0xc05bcf80 r7 =3D 0x00000000 r8 =3D 0x0000003a r9 =3D 0x00000000 r10 =3D 0xc05bcf90 random_harvestq_init() at random_harvestq_init+0x288 pc =3D 0xc01693c0 lr =3D 0xc02370c8 (fork_exit+0x84) sp =3D 0xdcfc4e40 fp =3D 0xdcfc4e58 r4 =3D 0xc276cc80 r5 =3D 0xc276a960 r6 =3D 0xc0169214 r7 =3D 0xc016a068 r8 =3D 0xdcfc4e60 r9 =3D 0x00000000 r10 =3D 0x00000000 fork_exit() at fork_exit+0x84 pc =3D 0xc02370c8 lr =3D 0xc047fd48 (swi_exit) sp =3D 0xdcfc4e60 fp =3D 0x00000000 r4 =3D 0xc0169214 r5 =3D 0xc016a068 r6 =3D 0x08343d00 r7 =3D 0x02602204 r8 =3D 0x00000000 swi_exit() at swi_exit pc =3D 0xc047fd48 lr =3D 0xc047fd48 (swi_exit) sp =3D 0xdcfc4e60 fp =3D 0x00000000 Unable to unwind further usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ata2: reset tp1 mask=3D01 ostat0=3D14 ostat1=3D00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: stat0=3D0x14 err=3D0x00 lsb=3D0x00 msb=3D0x00 ata2: reset tp2 stat0=3D94 stat1=3D00 devices=3D0x0 ugen1.1: at usbus1 uhub0: on usbus= 1 ugen0.1: at usbus0 uhub1: on usbus= 0 WARNING: WITNESS 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 Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ufs:/dev/da1s1a Trying to mount root from ufs:/dev/da1s1a []... mountroot: waiting for device /dev/da1s1a ... Mounting from ufs:/dev/da1s1a failed with error 19. mountroot> mountroot> ufs:/dev/da1s1a Invalid file system specification. mountroot> ountroot: waiting for device /dev/da1s1a ... Trying to mount root from ountroot: [waiting]... Mounting from ountroot: failed with error 2: unknown file system. mountroot> Here is my attempt at using da0: mountroot> ufs:/dev/da0s1 Trying to mount root from ufs:/dev/da0s1 []... mountroot: waiting for device /dev/da0s1 ... Mounting from ufs:/dev/da0s1 failed with error 19. mountroot> ufs:/dev/da0s1a Trying to mount root from ufs:/dev/da0s1a []... mountroot: waiting for device /dev/da0s1a ... Mounting from ufs:/dev/da0s1a failed with error 19. mountroot> Good Night, Russ On Thu, Oct 2, 2014 at 11:15 PM, Rui Paulo wrote: > On Oct 2, 2014, at 23:06, Russell Haley wrote: >> >> Gentlemen, >> >> So one of my next steps is to get rootfs to mount. I THINK I have found = out >> that the kernel uses an option in the kernel config file >> called ROOTDEVNAME. That - as far as I can tell - means the root device >> name is set at compile time? In my current case I wanted to boot the ker= nel >> I already have and then use the manual process to load rootfs. I tried >> using installworld on a 4 GB USB stick. This is my process: >> >> gpart create -s mbr da4 >> gpart add -t freebsd da4 >> sudo newfs /dev/da4s1 >> mount /dev/da4s1 /usr/jails/FreeArm2/mnt/usb >> >> make TARGET_ARCH=3Darmv6 DESTDIR=3D/mnt/usb installworld distribution >> >> This *seemed* to work but I did not get a nifty little message at the e= nd >> of installworld telling me the install process was completed successfull= y >> as I did with buildworld or buildkernel. >> >> Once my kernel booted and I got to the manual prompt I used the followin= g >> command: >> >> mountroot> ufs:/dev/da1s1a #also tried ufs:/dev/da1s1 >> >> Trying to mount root from ufs:/dev/da1s1a []... >> mountroot: waiting for device /dev/da1s1a ... >> Mounting from ufs:/dev/da1s1a failed with error 19. >> >> boo. :( >> >> So, my questions are: >> >> 1) Is a 4GB USB drive enough space? > > Yes > >> 2) Did the lack of "nifty little message" mean installworld failed? I >> didn't get any error messages, it just seemed to stop (i.e. a new comman= d >> prompt). > > No > >> 3) Is my above partitioning correct? I just found this article that says= I >> should be using GPT not MBR: >> http://www.wonkity.com/~wblock/docs/html/disksetup.html > > It should still work. > >> 4) Is my assumption that the rootfs is hard coded into the kernel true o= r >> is this one of many of my over simplifications? Could anyone point me to >> some good documentation about this? > > It's hard coded if you use the ROOTDEVNAME option. > >> I would normally spend much more time researching this myself but I'm so >> close to having something to play with I'm becoming impatient!!! > > Are you sure it's da1? It's not da0? Can you show us the boot log? > > -- > Rui Paulo > > > From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 09:25:59 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F35799E9 for ; Fri, 3 Oct 2014 09:25:59 +0000 (UTC) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mail-n.franken.de", Issuer "Thawte DV SSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B3864F9B for ; Fri, 3 Oct 2014 09:25:59 +0000 (UTC) Received: from [192.168.1.104] (p548191A3.dip0.t-ipconnect.de [84.129.145.163]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 594D51C0E9725 for ; Fri, 3 Oct 2014 11:25:57 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI From: Michael Tuexen In-Reply-To: Date: Fri, 3 Oct 2014 11:25:56 +0200 Content-Transfer-Encoding: 7bit Message-Id: <64F3E0D1-B159-4B54-B339-70EFA73AB800@freebsd.org> References: To: freebsd-arm@FreeBSD.org X-Mailer: Apple Mail (2.1878.6) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 09:26:00 -0000 On 30 Sep 2014, at 03:48, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 > > --- Comment #2 from Danilo Egea Gondolfo --- > I reverted just r271973 (on 10-stable) and the system boots again. I can confirm that head panics during boot with panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 Best regards Michael > > -- > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 13:33:07 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 27AB574 for ; Fri, 3 Oct 2014 13:33:07 +0000 (UTC) Received: from mailgate-01.zdv.uni-mainz.de (mailgate-01.zdv.Uni-Mainz.DE [IPv6:2001:4c80:40:62d:203:ffff:fe5d:b2f1]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "IronPort Appliance Demo Certificate", Issuer "IronPort Appliance Demo Certificate" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 794A3D80 for ; Fri, 3 Oct 2014 13:33:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uni-mainz.de; i=@uni-mainz.de; q=dns/txt; s=ironport; t=1412343187; x=1443879187; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5y7vNjXD4eV0ku0D8IGuK8hy/a6+/QkO+a7PV6CWlbA=; b=d3ghKWZJ3bsphZ0suK2dRA8kc4yTdb+Or+xPA+cZ5fob8LF+Sll6HhSH DoBwj0iY7OKPNJ39eSwZE5smPBiGwCSfGCQlv8pDEm/FCavYRRfemKkNB Cp9t0dbf6fn8MJqVP/aJDC82CJqNqerqaVPxVrImxDOQcPXPT4Hs4WVHk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArkEAEakLlQKXgZY/2dsb2JhbABgDoJddlgEgn7HdgqGeVQCGYEHAXuEAwEBAQQBAQEgERogCwwEAgEIDgMEAQEBAgIjAwICAiUBCQEUAQgIAgQIAgQBBAEHEgECBIgdAQypG5V9AReBLIkMhSUBATQbBwaCMEESgUIFljCECoQxO4VxQI1ngWoggRlAbAeBCDmBAgEBAQ X-IPAS-Result: ArkEAEakLlQKXgZY/2dsb2JhbABgDoJddlgEgn7HdgqGeVQCGYEHAXuEAwEBAQQBAQEgERogCwwEAgEIDgMEAQEBAgIjAwICAiUBCQEUAQgIAgQIAgQBBAEHEgECBIgdAQypG5V9AReBLIkMhSUBATQbBwaCMEESgUIFljCECoQxO4VxQI1ngWoggRlAbAeBCDmBAgEBAQ Received: from e14hub-02.zdv.uni-mainz.de ([10.94.6.88]) by mailgate-01.zdv.uni-mainz.de with ESMTP/TLS/AES128-SHA; 03 Oct 2014 15:33:03 +0200 Received: from e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9239) by E14HUB-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:21d:d8ff:feb7:1c60) with Microsoft SMTP Server (TLS) id 14.3.210.2; Fri, 3 Oct 2014 15:33:03 +0200 Received: from e15be-02.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:8fb0) by e15be-03.zdv.Uni-Mainz.DE (2001:4c80:40:606:92e2:baff:fe19:9239) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 3 Oct 2014 15:33:02 +0200 Received: from e15be-02.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:8fb0]) by e15be-02.zdv.Uni-Mainz.DE ([fe80::92e2:baff:fe19:8fb0%15]) with mapi id 15.00.0995.028; Fri, 3 Oct 2014 15:33:02 +0200 From: =?utf-8?B?V2Vpw58sICBEci4gSsO8cmdlbg==?= To: 'David Rayson' Subject: RE: Jetson TK1 board support Thread-Topic: Jetson TK1 board support Thread-Index: AQHP18iUBDzcFmGHMkWO9pZPd3gkEJwT3s2wgAlm2oCAASHcUA== Date: Fri, 3 Oct 2014 13:33:01 +0000 Message-ID: References: <542271AE.6070807@andrew.cmu.edu> <2c451765bffb43e8b9dab56927bb351a@e15be-02.zdv.Uni-Mainz.DE> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.93.178.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "freebsd-arm@freebsd.org" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 13:33:07 -0000 SWYgeW91IGVuYWJsZSB0aGUgc2RoY2kgY29udHJvbGxlcihzKSBpbiB0aGUgZmR0LCB0aGUgY29u dHJvbGxlcnMgYW5kDQp0aGUgY2FyZHMgYXJlIChhdCBsZWFzdCBwYXJ0aWFsbHkpIHJlY29nbml6 ZWQuIFJlYWQgZGF0YSB0cmFuc2ZlcnMNCmZyb20gdGhlIHNkIGNhcmQgc2xvdCByZXR1cm4gb25s eSBkYXRhIGJ5dGVzIHdpdGggemVybyBjb250ZW50cy4NClRoZSBxdWlyayBpbiB0aGUgZmR0IHNo b3VsZCBkaXNhYmxlIERNQS4gVGhlIHRyYW5zZmVycyBhcmUgZG9uZQ0KaW4gcGlvIG1vZGUuDQoN ClUtYm9vdCBzaG91bGQgYWxyZWFkeSBoYXZlIGluaXRpYWxpemVkIHRoZSBjb250cm9sbGVycy4g QnV0IHRoZQ0KZ2VuZXJpYyBzZGhjaSBkcml2ZXIgdHJpZXMgYXQgbGVhc3QgdG8gc2V0IGZyZXF1 ZW5jeSBhbmQgYnVzIHdpZHRoDQphY2NvcmRpbmcgdG8gdGhlIGNhcmRzIHByZXNlbnQuIEZvciB0 aGUgRU1NQyBpdCBjZXJ0YWlubHkgZG9lcw0Kbm90IGtub3cgaG93IHRvIGhhbmRsZSA4IGJpdCB0 cmFuc2ZlcnMgd2l0aG91dCBmdXJ0aGVyIGhlbHAgDQpmcm9tIGEgdGVncmEgc3BlY2lmaWMgZHJp dmVyIGV4dGVuc2lvbnMuDQoNCkp1ZXJnZW4NCg0KSnVlcmdlbiBXZWlzcyAgICAgIHxVbml2ZXJz aXRhZXQgTWFpbnosIFplbnRydW0gZnVlciBEYXRlbnZlcmFyYmVpdHVuZywNCndlaXNzQHVuaS1t YWluei5kZSB8NTUwOTkgTWFpbnosIFRlbDogKzQ5KDYxMzEpMzktMjYzNjEsIEZBWDogKzQ5KDYx MzEpMzktMjY0MDcNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZp ZCBSYXlzb24gW21haWx0bzpkcmF5c29uQGFuZHJldy5jbXUuZWR1XQ0KPiBTZW50OiBUaHVyc2Rh eSwgT2N0b2JlciAwMiwgMjAxNCAxMTo1NCBQTQ0KPiBUbzogV2Vpw58sIERyLiBKw7xyZ2VuDQo+ IENjOiBmcmVlYnNkLWFybUBmcmVlYnNkLm9yZw0KPiBTdWJqZWN0OiBSZTogSmV0c29uIFRLMSBi b2FyZCBzdXBwb3J0DQo+IA0KPiBIb3cgbXVjaCB3b3JrIGRvIHlvdSB0aGluayB3b3VsZCBiZSBu ZWVkZWQgdG8gZ2V0IHRoZSBTRCBjb250cm9sbGVyIHdvcmtpbmc/ICBXb3VsZCBpdA0KPiBzaW1w bHkgYmUgYSBtYXR0ZXIgb2YgZG9pbmcgdGhlIGFwcHJvcHJpYXRlIGluaXRpYWxpemF0aW9uICh3 b3VsZG4ndCBVLUJvb3QgZG8gdGhpcw0KPiBhbHJlYWR5IGV2ZW4/KSwgZW5hYmxpbmcgaXQgaW4g dGhlIGRldmljZSB0cmVlLCBhbmQgdXNpbmcgdGhlIHN0YW5kYXJkIEZyZWVCU0QgU0RIQ0kNCj4g ZHJpdmVyLCBvciBpcyB0aGVyZSBzb21ldGhpbmcgbW9yZSBjb21wbGljYXRlZCB0aGF0IHdvdWxk IG5lZWQgdG8gYmUgZG9uZT8NCj4gDQo+IA0KPiAoVGhpcyB3b3VsZCBwcm9iYWJseSBiZSBzaW1w bGUgdG8gdGVzdCwgYnV0IEkgZG9uJ3QgaGF2ZSBhY2Nlc3MgdG8gdGhlIGhhcmR3YXJlIHJpZ2h0 IG5vdykNCj4gDQo+IA0KPiAtLURhdmlkDQo+IA0KPiANCj4gT24gRnJpLCBTZXAgMjYsIDIwMTQg YXQgNDozOSBQTSwgV2Vpw58sIERyLiBKw7xyZ2VuIDx3ZWlzc0B1bmktbWFpbnouZGU+IHdyb3Rl Og0KPiANCj4gDQo+IAlIaSwNCj4gDQo+IAlzb3JyeSwgSSBkaWQgbm90IGhhdmUgYW55IHRpbWUg ZHVyaW5nIHRoZSB3ZWVrLg0KPiANCj4gCUkganVzdCBzZW50IGEgbWFpbCB0byB0aGUgbGlzdCB3 aXRoIGEgbGluayB0byBteSBjaGFuZ2VzLg0KPiANCj4gCU9ubHkgc2VyaWFsLCBVU0IyIGFuZCBQ Q0llL0V0aGVybmV0IGhhcmR3YXJlIGlzIHdvcmtpbmcgLSBzbyBubw0KPiAJU0FUQS4NCj4gDQo+ IAlUaGUgZHJpdmVycyByZWx5IG9uIHUtYm9vdCB0byBpbml0aWFsaXplIHRoZSBoYXJkd2FyZS4g V2hpbGUgdGhpcw0KPiAJaXMgb2sgZm9yIHBpbm11eCwgb3RoZXIgaW5pdGlhbGl6YXRpb25zIHNo b3VsZCBiZSBkb25lIGJ5IHRoZQ0KPiAJZHJpdmVycy4NCj4gDQo+IAlUaGUgaW50ZXJydXB0IGhh bmRsaW5nIGZvciBQQ0llIGlzIHJhdGhlciBhZCBob2MuIFRoZSBpbnRlcnJ1cHQNCj4gCXJvdXRp bmcgc2hvdWxkIGhvbm9yIHRoZSBGRFQgZGVzY3JpcHRpb24uDQo+IA0KPiAJVGhlIFRlZ3JhIHBs YXRmb3JtIGhhcyBhIEdJQyB3aXRoIGV4dGVuc2lvbnMgZm9yIGludGVycnVwdA0KPiAJcm91dGlu Zy4gSSBqdXN0IG1hZGUgYSBjb3B5IG9mIHRoZSBHSUMgY29kZSBlbmQgZXh0ZW5kZWQgaXQNCj4g CWluIGEgZmV3IGNhc2VzLiBUaGVyZSBzaG91bGQgcHJvYmFibHkgYmUgYSBtZWNoYW5pc20gdG8g ZG8NCj4gCXRoaXMgd2l0aG91dCBkdXBsaWNhdGluZyBjb2RlLg0KPiANCj4gCUkgY2hhbmdlZCBz b21lIG5vbiB0ZWdyYSBmaWxlcyB0byBnZXQgRnJlZUJTRCBydW5uaW5nIG9uIHRoZQ0KPiAJaGFy ZHdhcmUuIFRoZXJlIHNob3VsZCBiZSBiZXR0ZXIgc29sdXRpb25zLCB3aGljaCBjYW4gYmUgbWVy Z2VkDQo+IAliYWNrIHRvIHRoZSBGcmVlQlNEIHNvdXJjZSB0cmVlLiBGb3IgZXhhbXBsZSB0aGUg cHJvYmxlbQ0KPiAJd2l0aCBjYWNoZSBjb2hlcmVuY3kgZHVlIHRvIGFnZ3Jlc3NpdmUgTDIgcHJl ZmV0Y2ggYXdhaXRzDQo+IAlhIHJlYWwgc29sdXRpb24uDQo+IA0KPiAJVGhlcmUgaXMgbm8gY29k ZSB0byBjaGFuZ2UgdGhlIGNwdSBjbG9jayB5ZXQuDQo+IA0KPiAJVGhlcmUgaXMgbm8gc3VwcG9y dCBmb3IgU0RIQ0kgb3IgRU1NQy4NCj4gDQo+IAlTbyBJIHdvdWxkIGNvbnNpZGVyIHRoaXMgYSBm aXJzdCBzdGVwLCB3aGljaCBhbGxvd3MgdG8gZG8NCj4gCW5hdGl2ZSBkZXZlbG9wbWVudCBvbiB0 aGUgcGxhdGZvcm0uDQo+IA0KPiAJQmVzaWRlcyB0aGF0LCB0aGUga2VybmVsIHNlZW1zIHRvIGJl IHF1aXRlIHN0YWJsZSAtIGF0IGxlYXN0IHdpdGgNCj4gCXRoZSBjb21waWxlcyBJIGRpZC4NCj4g DQo+IAlSZWdhcmRzDQo+IA0KPiAJSnVlcmdlbg0KPiANCj4gCUp1ZXJnZW4gV2Vpc3MgICAgICB8 VW5pdmVyc2l0YWV0IE1haW56LCBaZW50cnVtIGZ1ZXIgRGF0ZW52ZXJhcmJlaXR1bmcsDQo+IAl3 ZWlzc0B1bmktbWFpbnouZGUgfDU1MDk5IE1haW56LCBUZWw6ICs0OSg2MTMxKTM5LTI2MzYxIDx0 ZWw6JTJCNDklMjg2MTMxJTI5MzktMjYzNjE+DQo+ICwgRkFYOiArNDkoNjEzMSkzOS0yNjQwNyA8 dGVsOiUyQjQ5JTI4NjEzMSUyOTM5LTI2NDA3Pg0KPiANCj4gDQo+IAk+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IAk+IEZyb206IG93bmVyLWZyZWVic2QtYXJtQGZyZWVic2Qub3JnIFtt YWlsdG86b3duZXItZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmddIE9uDQo+IEJlaGFsZiBPZg0KPiAJ PiBEYXZpZCBSYXlzb24NCj4gCT4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjQsIDIwMTQg OToyNSBBTQ0KPiAJPiBUbzogZnJlZWJzZC1hcm1AZnJlZWJzZC5vcmcNCj4gCT4gU3ViamVjdDog UmU6IEpldHNvbiBUSzEgYm9hcmQgc3VwcG9ydA0KPiAJPg0KPiAJPiBIaSwNCj4gCT4NCj4gCT4g V2hhdCBvdGhlciB3b3JrIHdvdWxkIGJlIHVzZWZ1bCB0byBnZXQgdGhpcyBwb3J0IHdvcmtpbmcg d2VsbD8gIEkgbWlnaHQNCj4gCT4gYmUgaW50ZXJlc3RlZCBpbiB3b3JraW5nIG9uIGltcHJvdmlu ZyBpdCwgYnV0IGZpcnN0IEkgd2FudCB0byBtYWtlIHN1cmUNCj4gCT4gSSBoYXZlIGEgY2xlYXIg c2Vuc2Ugb2Ygd2hhdCdzIGJlZW4gZG9uZSBzbyBmYXIgKGFuZCBob3cgc3RhYmxlL25vdCBpdA0K PiAJPiBpcykgYW5kIHdoYXQgc3RpbGwgcmVtYWlucyB0byBiZSBkb25lLg0KPiAJPg0KPiAJPiAt LURhdmlkDQo+IAk+DQo+IAk+ID4gSGksDQo+IAk+ID4NCj4gCT4gPiBJIGhhdmUgYSByYXRoZXIg cm91Z2ggcG9ydCBvZiBGcmVlQlNEIGN1cnJlbnQgb24gYXJtIHRvIEpldHNvbiBUSzEuIEkNCj4g CT4gPiB1c2VkIFN0ZXBoZW4gV2FycmVuJ3MgdGVncmEgdS1ib290IHNvdXJjZXMsIHdoaWNoIGlu aXRpYWxpemUgYW5kIGNvbmZpZ3VyZQ0KPiAJPiA+IFVTQiBhbmQgUENJZS4NCj4gCT4gPg0KPiAJ PiA+IFNvIFNNUCwgVVNCIGFuZCB0aGUgb25ib2FyZCBQQ0llIEV0aGVybmV0IGFkYXB0ZXIgd29y ay4NCj4gCT4gPg0KPiAJPiA+IEFmdGVyIElhbidzIGNoYW5nZXMgdG8gYnVzZG1hX21hY2hkZXAt djYgKHIyNjkyMTIpIEkgaGFkIHByb2JsZW1zIHdpdGgNCj4gCT4gPiBjYWNoZSBjb2hlcmVuY3kg d2l0aCB0aGUgRXRoZXJuZXQgYWRhcHRlci4gU2VlbXMgdGhpcyBpcyBkdWUgdG8gdGhlIGFnZ3Jl c3NpdmUNCj4gCT4gPiBMMiBwcmVmZXRjaGVyIG9mIENvcnRleCBBMTUuIERpc2FibGluZyBMMiBw cmVmZXRjaCBkb2VzIGhlbHAsIGFzIHdlbGwgYXMNCj4gCT4gPiBpbnZhbGlkYXRpbmcgdGhlIGNh Y2hlIGEgc2Vjb25kIHRpbWUgYWZ0ZXIgdGhlIGRtYSB0cmFuc2Zlci4gSSdtIG5vdA0KPiAJPiA+ IHN1cmUgd2hhdCB0aGUgY29ycmVjdCBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gaXMuIEkgd29u ZGVyIGhvdw0KPiAJPiA+IG90aGVyIENvcnRleCBBMTUgcGxhdGZvcm1zIChleHlub3M1KSBoYW5k bGUgdGhpcy4NCj4gCT4gPg0KPiAJPiA+IEkgd2lsbCBwcm9iYWJseSBiZSBhYmxlIHRvIGRvIHNv bWUgY2xlYW51cHMgYW5kIHB1dCBwYXRjaGVzIG9uIHRoZSB3ZWINCj4gCT4gPiB3aXRoaW4gYSB3 ZWVrLg0KPiAJPiA+DQo+IAk+ID4gUmVnYXJkcw0KPiAJPiA+DQo+IAk+ID4gSnVlcmdlbg0KPiAJ PiA+DQo+IAk+ID4gSnVlcmdlbiBXZWlzcyAgICAgIHxVbml2ZXJzaXRhZXQgTWFpbnosIFplbnRy dW0gZnVlciBEYXRlbnZlcmFyYmVpdHVuZywNCj4gCT4gPiB3ZWlzcyBhdCB1bmktbWFpbnouZGUg IDxodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNkLWFybT4N Cj4gfDU1MDk5DQo+IAk+IE1haW56LCBUZWw6ICs0OSg2MTMxKTM5LTI2MzYxIDx0ZWw6JTJCNDkl Mjg2MTMxJTI5MzktMjYzNjE+ICwgRkFYOiArNDkoNjEzMSkzOS0NCj4gMjY0MDcgPHRlbDolMkI0 OSUyODYxMzElMjkzOS0yNjQwNz4NCj4gCT4gPg0KPiAJPiA+ID4vICAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiAJPiA+IC8+LyAgRnJvbTpvd25lci1mcmVlYnNkLWFybSBhdCBmcmVlYnNk Lm9yZw0KPiAJPiA8aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJl ZWJzZC1hcm0+ICBbbWFpbHRvOm93bmVyLWZyZWVic2QtYXJtDQo+IGF0DQo+IAk+IGZyZWVic2Qu b3JnICA8aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1h cm0+XSBPbiBCZWhhbGYgT2YNCj4gCT4gPiAvPi8gIElhbiBMZXBvcmUNCj4gCT4gPiAvPi8gIFNl bnQ6IFN1bmRheSwgU2VwdGVtYmVyIDIxLCAyMDE0IDM6NDQgUE0NCj4gCT4gPiAvPi8gIFRvOiBM dW5kYmVyZywgSm9oYW5uZXMNCj4gCT4gPiAvPi8gIENjOmZyZWVic2QtYXJtIGF0IGZyZWVic2Qu b3JnDQo+IDxodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9mcmVlYnNk LQ0KPiAJPiBhcm0+DQo+IAk+ID4gLz4vICBTdWJqZWN0OiBSZTogSmV0c29uIFRLMSBib2FyZCBz dXBwb3J0DQo+IAk+ID4gLz4vDQo+IAk+ID4gLz4vICBPbiBTdW4sIDIwMTQtMDktMjEgYXQgMTY6 NDUgKzA5MDAsIEx1bmRiZXJnLCBKb2hhbm5lcyB3cm90ZToNCj4gCT4gPiAvPi8gID4gR3JlYXQh DQo+IAk+ID4gLz4vICA+DQo+IAk+ID4gLz4vICA+IFdoYXQgSSd2ZSBkb25lIHNvIGZhciBpcw0K PiAJPiA+IC8+LyAgPg0KPiAJPiA+IC8+LyAgPiAtIGJ1aWxkIGFuZCBwYXRjaCAoZW5hYmxlIEFQ SSkgdS1ib290LW52aWRpYSBvbiBmcmVlYnNkIChpIHRoaW5rIGkgZ290IGl0DQo+IAk+ID4gLz4v ICA+IGZyb21naXQ6Ly9udi10ZWdyYS5udmlkaWEuY29tLzNyZHBhcnR5L3UtYm9vdC5naXQsICB0 aGUgbm9ybWFsIHUtYm9vdA0KPiAJPiA+IC8+LyAgPiB3b3VsZG4ndCB3b3JrLi4uKQ0KPiAJPiA+ IC8+LyAgPiAtIGZsYXNoIHUtYm9vdC1kdGItdGVncmEuaW1nIG9udG8gdGhlIGJvYXJkJ3MgbW1j IHVzaW5nIG52aWRpYSdzIGZsYXNoDQo+IHRvb2wNCj4gCT4gPiAvPi8gID4gb24gdWJ1bnR1DQo+ IAk+ID4gLz4vICA+IC0gYnVpbGQgYW4gaW1hZ2UgdXNpbmcgY3JvY2hldCBhbmQgZGQgdG8gc2Qg Y2FyZCAoc28gZmFyIEkgY29waWVkIHRoZQ0KPiAJPiA+IC8+LyAgPiBiZWFnbGVib25lIHNldHVw LCBqdXN0IHRvIGdldCBhIHVibGRyIGFuZCBhIGtlcm5lbCBmaWxlKQ0KPiAJPiA+IC8+LyAgPg0K PiAJPiA+IC8+LyAgPg0KPiAJPiA+IC8+LyAgPiBGcm9tIHUtYm9vdCBJIGNhbiBzZWUgYWxsIGRl dmljZXMuIEkgbG9hZCB1YmxkciB3aXRoDQo+IAk+ID4gLz4vICA+IGZhdGxvYWQgbW1jIDE6MSAw eDgwMjAwMDAwIHVibGRyDQo+IAk+ID4gLz4vICA+IGJvb3RlbGYgMHg4MDIwMDAwMA0KPiAJPiA+ IC8+LyAgPg0KPiAJPiA+IC8+LyAgPiB1YmxkciBsb2FkIGZpbmUgYnV0LCBmcm9tIHVibGRyIEkg Y2FuIG9ubHkgc2VlIHRoZSBtbWMgMCBhbmQgbmV0IGRldmljZXMuDQo+IAk+ID4gLz4vICA+IFRo ZXJlJ3Mgbm8gc2QgY2FyZCAobW1jIDEpLCBhbmQgbm8gdWZzIHBhcnRpdGlvbi4uDQo+IAk+ID4g Lz4vICA+DQo+IAk+ID4gLz4vICA+DQo+IAk+ID4gLz4vICA+DQo+IAk+ID4gLz4vICA+DQo+IAk+ ID4gLz4vICA+IC0tDQo+IAk+ID4gLz4vICA+IEpvaGFubmVzIEx1bmRiZXJnDQo+IAk+ID4gLz4v ICA+IEJSSUxMSUFOVFNFUlZJQ0UgQ08uLCBMVEQuDQo+IAk+ID4gLz4vICA+DQo+IAk+ID4gLz4v ICA+IE9uIEZyaSwgU2VwIDE5LCAyMDE0IGF0IDg6MjUgUE0sIEpvaG4gSG93aWUgPGpvaG4gYXQg dGhlaG93aWVzLmNvbQ0KPiAJPiA8aHR0cDovL2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlz dGluZm8vZnJlZWJzZC1hcm0+PiB3cm90ZToNCj4gCT4gPiAvPi8gID4NCj4gCT4gPiAvPi8gID4g PiBIaSBhbGwsDQo+IAk+ID4gLz4vICA+ID4NCj4gCT4gPiAvPi8gID4gPiBJIGFtIHVwIGZvciB0 ZXN0aW5nIGFuZCBzdXBwb3J0aW5nIHRoaXMgYm9hcmQuIEkgb3JkZXJlZCBhbmQgcmVjZWl2ZWQN Cj4gCT4gPiAvPi8gID4gPiBtaW5lLCBidXQgaGF2ZSBub3QgcmVhbGx5IGhhZCBhIGNoYW5jZSB0 byB1c2UgaXQgZHVlIHRvIHdvcmsgdG8tZGF0ZS4NCj4gVGhlDQo+IAk+ID4gLz4vICA+ID4gZ29v ZCBuZXdzIGlzIHRoZSBuZXh0IGZldyBtb250aHMgSSB3aWxsIGhhdmUgYmFuZHdpZHRoLg0KPiAJ PiA+IC8+LyAgPiA+DQo+IAk+ID4gLz4vICA+ID4gUmVnYXJkcywNCj4gCT4gPiAvPi8gID4gPg0K PiAJPiA+IC8+LyAgPiA+IEpvaG4NCj4gCT4gPiAvPi8gID4gPg0KPiAJPiA+IC8+LyAgPiA+DQo+ IAk+ID4gLz4vICA+ID4gT24gOS8xOS8xNCwgMTI6MTUgUE0sICJMdW5kYmVyZywgSm9oYW5uZXMi DQo+IAk+ID4gLz4vICA+ID4gPGpvaGFubmVzIGF0IGJyaWxsaWFudHNlcnZpY2UuY28uanANCj4g CT4gPGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtYXJt Pj4gd3JvdGU6DQo+IAk+ID4gLz4vICA+ID4NCj4gCT4gPiAvPi8gID4gPiA+SGkNCj4gCT4gPiAv Pi8gID4gPiA+DQo+IAk+ID4gLz4vICA+ID4gPkkgc3RhcnRlZCB3b3JraW5nIG9uIGFkZGluZyB0 aGUgSmV0c29uIFRLMSBib2FyZCB0byBDcm9jaGV0LiBJcyB0aGVyZQ0KPiBhbnkNCj4gCT4gPiAv Pi8gID4gPiA+d29yayBpbiBwcm9ncmVzcyBvbiB0aGlzPw0KPiAJPiA+IC8+LyAgPiA+ID5JIGd1 ZXNzIHRoZXJlIGlzIHF1aXRlIGEgbG90IG9mIHdvcmsgdGhhdCBoYXMgdG8gYmVlbiBkb25lIHRv IGdldCBmdWxsDQo+IAk+ID4gLz4vICA+ID4gPnN1cHBvcnQgZm9yIGl0IGluIHRoZSBrZXJuZWwg YXMgd2VsbC4uDQo+IAk+ID4gLz4vICA+ID4gPg0KPiAJPiA+IC8+LyAgPiA+ID5CZXN0IHJlZ2Fy ZHMNCj4gCT4gPiAvPi8gID4gPiA+LS0NCj4gCT4gPiAvPi8gID4gPiA+Sm9oYW5uZXMgTHVuZGJl cmcNCj4gCT4gPiAvPi8gID4gPiA+DQo+IAk+ID4gLz4vDQo+IAk+ID4gLz4vICBZb3UgbWF5IGhh dmUgdG8gY2hhbmdlIHNvbWUgdS1ib290IG9wdGlvbnMgdG8gc3VwcG9ydCBtdWx0aXBsZSBtbWMv c2QNCj4gCT4gPiAvPi8gIGludGVyZmFjZXMuICBMb29rIGluIHRoZSBjb25maWcgaGVhZGVyIGZv ciBDT05GSUdfU1lTX01NQ19NQVhfREVWSUNFOyBpZg0KPiAJPiA+IC8+LyAgaXQncyBub3QgdGhl cmUgeW91IG1heSBuZWVkIHRvIGFkZCBpdC4gIEZvciB3YW5kYm9hcmQgSSBhbHNvIGhhZCB0byBh ZGQNCj4gCT4gPiAvPi8gIGEgZnJlZXNjYWxlLXNwZWNpZmljIG9uZSwgQ09ORklHX1NZU19GU0xf VVNESENfTlVNLCBzbyB0aGVyZSBtYXkgYmUNCj4gCT4gPiAvPi8gIHNvbWV0aGluZyBsaWtlIHRo YXQgeW91IG5lZWQgdG8gZmluZCBhcyB3ZWxsLg0KPiAJPiA+IC8+Lw0KPiAJPiA+IC8+LyAgLS0g SWFuDQo+IAk+ID4gLz4vDQo+IAk+ID4gLz4vDQo+IAk+ID4gLz4vICBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiAJPiA+IC8+LyAgZnJlZWJzZC1hcm0g YXQgZnJlZWJzZC5vcmcNCj4gPGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2ZyZWVic2QtYXJtPg0KPiAJPiBtYWlsaW5nIGxpc3QNCj4gCT4gPiAvPi8gIGh0dHA6Ly9s aXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtYXJtDQo+IAk+ID4gLz4v ICBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1hcm0tdW5zdWJzY3Jp YmUgYXQgZnJlZWJzZC5vcmcNCj4gCT4gPGh0dHA6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2ZyZWVic2QtYXJtPiIvDQo+IAk+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IAk+IGZyZWVic2QtYXJtQGZyZWVic2Qub3JnIG1haWxp bmcgbGlzdA0KPiAJPiBodHRwOi8vbGlzdHMuZnJlZWJzZC5vcmcvbWFpbG1hbi9saXN0aW5mby9m cmVlYnNkLWFybQ0KPiAJPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJz ZC1hcm0tdW5zdWJzY3JpYmVAZnJlZWJzZC5vcmciDQo+IA0KPiANCg0K From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 15:15:25 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3C4298C6 for ; Fri, 3 Oct 2014 15:15:25 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 23614B1A for ; Fri, 3 Oct 2014 15:15:25 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s93FFPY8016832 for ; Fri, 3 Oct 2014 15:15:25 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Fri, 03 Oct 2014 15:15:25 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc see_also Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:15:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emaste@freebsd.org See Also| |https://bugs.freebsd.org/bu | |gzilla/show_bug.cgi?id=1922 | |48 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 15:16:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6937B970 for ; Fri, 3 Oct 2014 15:16:33 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 50671B34 for ; Fri, 3 Oct 2014 15:16:33 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s93FGXoP017398 for ; Fri, 3 Oct 2014 15:16:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Fri, 03 Oct 2014 15:16:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: vt X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: emaste@freebsd.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: keywords Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 15:16:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 Ed Maste changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |vt --- Comment #3 from Ed Maste --- Can you attach the output from a verbose boot? -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 19:42:49 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 837E6149 for ; Fri, 3 Oct 2014 19:42:49 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B4ECCD3 for ; Fri, 3 Oct 2014 19:42:49 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s93Jgn1b077352 for ; Fri, 3 Oct 2014 19:42:49 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Fri, 03 Oct 2014 19:42:49 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: vt X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 19:42:49 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 --- Comment #4 from Danilo Egea Gondolfo --- The verbose boot don't show any extra information. loader> show LINES=24 boot_multicons=YES boot_verbose=YES bootfile=kernel console=uboot currdev=disk0s2a: interpret=OK kernel=kernel kernel_options= kernelname=/boot/kernel/kernel loaddev=disk0s2a: loader_conf_files=/boot/device.hints /boot/loader.conf /boot/loader.conf.local mac_ifoff=NO module_path=/boot/kernel;/boot/modules prompt=loader> loader> boot -v Booting... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x100100... Kernel args: -v panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 Uptime: 1s -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Fri Oct 3 20:18:05 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 83AB7652 for ; Fri, 3 Oct 2014 20:18:05 +0000 (UTC) Received: from st11p02mm-asmtp002.mac.com (st11p02mm-asmtpout002.mac.com [17.172.220.237]) (using TLSv1 with cipher DES-CBC3-SHA (112/168 bits)) (Client CN "smtp.me.com", Issuer "VeriSign Class 3 Extended Validation SSL SGC CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5744FF9E for ; Fri, 3 Oct 2014 20:18:04 +0000 (UTC) Received: from fukuyama.hsd1.ca.comcast.net (unknown [73.162.13.215]) by st11p02mm-asmtp002.mac.com (Oracle Communications Messaging Server 7u4-27.10(7.0.4.27.9) 64bit (built Jun 6 2014)) with ESMTPSA id <0NCV00AMJXPSL230@st11p02mm-asmtp002.mac.com> for freebsd-arm@freebsd.org; Fri, 03 Oct 2014 20:17:54 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52,1.0.28,0.0.0000 definitions=2014-10-03_08:2014-10-03,2014-10-03,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1410030202 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 8.0 \(1988\)) Subject: Re: Digi CCWMX53 From: Rui Paulo In-reply-to: Date: Fri, 03 Oct 2014 13:17:52 -0700 Content-transfer-encoding: quoted-printable Message-id: <6CB3D473-64B6-4D03-AD7E-10A38CD23E9E@me.com> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> To: Russell Haley X-Mailer: Apple Mail (2.1988) Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Oct 2014 20:18:05 -0000 On Oct 3, 2014, at 00:05, Russell Haley wrote: >=20 > Here is my boot log including my load attempt: Oh, I forgot: you need to initialise USB before booting. There's a usb = command in u-boot. Try 'usb init' or something similar. That should = bring up the USB hardware. -- Rui Paulo From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 11:27:33 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3D41A213 for ; Sat, 4 Oct 2014 11:27:33 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 24B3663B for ; Sat, 4 Oct 2014 11:27:33 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s94BRX0G015605 for ; Sat, 4 Oct 2014 11:27:33 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Sat, 04 Oct 2014 11:27:33 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: vt X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dumbbell@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: attachments.created Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 11:27:33 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193981 --- Comment #5 from Jean-S=C3=A9bastien P=C3=A9dron = --- Created attachment 147966 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D147966&action= =3Dedit vtterm_cnprobe: Only recompute term size if screen size !=3D 0 I see that there's no vt(4) driver built into RPI-B kernel configuration, therefore, the screen size is unknown (and set to 0). Could you please try the attached patch? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 16:44:58 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7AC3969C for ; Sat, 4 Oct 2014 16:44:58 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 620C399A for ; Sat, 4 Oct 2014 16:44:58 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s94GiwDD097438 for ; Sat, 4 Oct 2014 16:44:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Sat, 04 Oct 2014 16:44:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: vt X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 16:44:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 --- Comment #6 from Danilo Egea Gondolfo --- It works! Tested on 10 and head. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 17:31:41 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DDAAC31B for ; Sat, 4 Oct 2014 17:31:41 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4D33D77 for ; Sat, 4 Oct 2014 17:31:41 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s94HVfqx036688 for ; Sat, 4 Oct 2014 17:31:41 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Sat, 04 Oct 2014 17:31:42 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: vt X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dumbbell@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 17:31:42 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193981 --- Comment #7 from Jean-S=C3=A9bastien P=C3=A9dron = --- I never used a RaspberryPi, so my question might be stupid: does it have a video output? If yes, do you see a working console if you plug in a monitor? --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 17:42:04 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7699846 for ; Sat, 4 Oct 2014 17:42:04 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AE96BEFB for ; Sat, 4 Oct 2014 17:42:04 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s94Hg49g065684 for ; Sat, 4 Oct 2014 17:42:04 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Sat, 04 Oct 2014 17:42:04 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: vt X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: danilo@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 17:42:04 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193981 --- Comment #8 from Danilo Egea Gondolfo --- At this moment I have just a usb/serial cable. I can test with a monitor but just on next Monday. Maybe someone in freebsd-arm@ can do it. -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 18:29:43 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 934727B0 for ; Sat, 4 Oct 2014 18:29:43 +0000 (UTC) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4EF13395 for ; Sat, 4 Oct 2014 18:29:42 +0000 (UTC) Received: by mail-ob0-f171.google.com with SMTP id va2so2314622obc.16 for ; Sat, 04 Oct 2014 11:29:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=rcd+1JiXY+Gqn6RsB0LUVK2f/pnmvooSRc52Ip3ZVj4=; b=R+7pMMZQg1inlnwFkI/8wz4swL3F6BY/wLXPAhxIplviYNKg00LwuQZ2/u2EvBRxAU ClXbNrf4tzJriuQ+PwxJXZwt5qXEld09hb3ddnlEXU6PT/SbRPNprftLVZw0fxDdc37v /+N/0tJruCi8Yh/9C3hXoGgiNrlpFgszCk2cpPQcRgEmRuOEPOh8h6z5ehdj4+9mitFo 6AJMUQUZt2qa1PTKVB0PJ5Hn4zFQa1sWKDQzBKa8j/htWCPWXHSQy11qiarVRz964Y3E p/0+RbJWFkU3UGr0dsk4t6uI9mo3o3EGu6fR3CJ7mqpCzi760M2jhJBdT1tYs8A/zMGW jzEg== X-Gm-Message-State: ALoCoQlxULsS1YjAEyu99ucY556BT+m9VmFtxBTcwi47hryAp/rlaWNPXP1Q/UXq6yHyAF+6rDGa X-Received: by 10.182.63.105 with SMTP id f9mr15749422obs.59.1412445902249; Sat, 04 Oct 2014 11:05:02 -0700 (PDT) Received: from bsdimp.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id fj8sm6696887obc.10.2014.10.04.11.05.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 04 Oct 2014 11:05:01 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_67C87F7A-F051-4E36-82B2-11311A86BC80"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Digi CCWMX53 From: Warner Losh In-Reply-To: Date: Sat, 4 Oct 2014 12:05:19 -0600 Message-Id: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> To: Russell Haley X-Mailer: Apple Mail (2.1878.6) Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 18:29:43 -0000 --Apple-Mail=_67C87F7A-F051-4E36-82B2-11311A86BC80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hey Russ, A quick read suggests all, or nearly all, of the data needed to write a = full NFC for this chip is present. The programming and read sequences = and information about ECC error rates appear to be readily available. = The exact ECC used, however, appears opaque. This may or may not be a = problem. It even appears to have command sequencing built into the = controller. This is a great feature, but one the current code doesn=92t = make use of. Warner On Oct 2, 2014, at 10:44 PM, Russell Haley wrote: > Warner,=20 >=20 > I was looking for a Digi reference but it turns out the Nand Flash = Controller is part of the Freescale Processor. Here is the link to the = Reference Manual: >=20 > cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >=20 > The NAND Flash Controller is in Chapter 51 page 3571 to page 3647.=20 >=20 > Is this relevant to what you are looking at doing? = https://wiki.freebsd.org/NAND >=20 > I also found something called CHFS for NetBSD that looks interesting: = http://chewiefs.sed.hu/home >=20 > Thanks,=20 > Russ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: >=20 > On Oct 1, 2014, at 12:48 AM, Russell Haley = wrote: >=20 > > Warner, > > > > First, I was just watching your 2010 talk on supporting FreeBSD in a = commercial environment. Has there been any updates in the process of = maintaining a commercial branch in the last 4 years (not that I have any = commercial ventures yet! lolz)? > > > > Anyway, I talked to an Engineer about the NAND controller spec and = he chided me for being naive (poor little software developer, in way = over his head. tisk tisk). He mentioned a FIVE THOUSAND page reference = manual, which I have yet to find on the Digi site. >=20 > URL + section number. 5k pages doesn=92t necessarily mean it will be = useful, though. :( >=20 > > I have however found this hardware reference: > > > > http://ftp1.digi.com/support/documentation/90001270_E.pdf > > > > =46rom Page 41: > > > > NAND flash memory > > The ConnectCore for i.MX53 module provides 8GB of NAND flash memory. = On the module in > > the development kits a 512MByte, 2Kbyte page, NAND flash chip is = used. This NAND flash > > device is connected to NAND flash Chip Select 0. > > The NAND flash controller signals are available on the module = connectors. >=20 > This basically says nothing more useful than =93There=92s NAND on this = board that=92s 4Gbits on CS0.=94 which is useful, but far from = sufficient. How do I program the DMA so that ECC is added to the OOB = areas of that NAND? How do I set different ECC tables? How do I do ECC = error correction and detection? If you can=92t answer that sort of = question from the docs you have, then they aren=92t helpful enough. >=20 > > There are pin references to NAND further down in the section "GPIO = multiplexing table in the ConnectCore for i.MX53 module" on page 44 and = 49. > > > > I fear this is not the information we are looking for. >=20 > Not really. The GPIO info might be mildly helpful in a few cases >=20 > > I have found another u-boot fork for the CCWMX53 on github here: = https://github.com/Varcain/uboot-ccwmx53-digi > > > > With what seems to be the information about booting from NAND here: = https://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl > > > > If you can let me know what I am looking for I can both ask a more = directed question at work and also perform a better search. > > > > I have also started looking over the Architecture handbook as well = because I have a feeling there is going to be lots of driver code in my = future. >=20 > A good first step would be to get a URL or search string to get the = URL for that big spec. It is of the right size to possibly be useful, = but sometimes really long specs have 1-2 page descriptions of things = like the SD controller or the NAND controller that you need special NDAs = + business arrangements to get, so it is hard to say=85 >=20 > Warner >=20 > > > > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh = wrote: > > > > On Sep 27, 2014, at 9:49 PM, Russell Haley = wrote: > > > > > I will attempt to load the kernel from tftp as soon as I can. I = will need > > > to figure out how to get ethernet to the unit. > > > > > > I know nothing about u-boot so forgive my ignorance but I was = hoping to > > > modify the Arndale configuration to work such as: > > > > > > # mmc read 1 0x70800000 0x800 0x1800; > > > #go 0x70800000; > > > > > > and then point the rootfs to /dev/da1s1 > > > > > > On another note, do you know where I could find out more about the = missing > > > MTD support? > > > > A spec for the NAND controller is needed to make that work=85 Is = one about? > > > > Warner > > > > > > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so = many cool > > > projects, so little time... > > > > > > Thanks, > > > > > > Russ > > > > > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: > > > > > >> On Sep 27, 2014, at 13:31, Russell Haley = wrote: > > >>> > > >>> Rui, > > >>> > > >>> So no MTD means the NAND on the SOM is out, but can I boot the = kernel > > >> and load rootfs from the microSD, like in this example: > > >>> =95 > > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 = kernel.bin; go > > >> 0x40f00000" > > >>> > > >>> ARNDALE5250 # saveenv > > >>> > > >>> ARNDALE5250 # boot > > >> > > >> You can't use the Arndale config since the load addresses are = different. > > >> You should be able to load a kernel from the network. Can you do = that? > > >> > > >> -- > > >> Rui Paulo > > >> > > >> > > >> > > >> > > > _______________________________________________ > > > freebsd-arm@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm > > > To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" > > > > >=20 >=20 --Apple-Mail=_67C87F7A-F051-4E36-82B2-11311A86BC80 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUMDbfAAoJEGwc0Sh9sBEAX68QANnGQiChMTro8dOT2SQDWLBh eCnTsqsJGNkNrsKxQjWsrGFt7IvOmMs5jA3iCiA6vhrLx2bSD2twFiuX4ZX9LID1 4dJ9hhj+Z3C0h3yHOBr+cKUsDjvrJ1WG+dMlSNiLa4Aa4gMw+GHF63nOPx4sTlsj P4dSsJzRpKpE4eYUm8qGh4FF5QJsSGiBt0RVe/2KWxET0UhCQjB+XI/tGTK7lsyj OiuPFssaG3uV6hWlAqIpKtzpaBTuQZvRi4iwSwteICuU/LHHupp4ul+Vz7+VHkBP W2jtvzD15/nEb0AbUcFgfiFYEK4iWjzlRden6DcRLbWI/2YxOb9EDpWh6RP42w+K DU3nLRwifkYSKTHHTdbJXNZuTHNBbO3xlX9NNHDSbCz6y9CDWzSO8c/NmyH2BQfD IjpsvEYkZ059ctIeKbpwx65vn8E4lP8igWvQoVCtxmMHiBGLzBPbUFQ6RDcXb9cV SPSOR7eU352wEt+jopUdj2U38Py0acQfgcuOPLOGING0nSONxNATu4hx0T05Ednx D7/RCAXFO5vHbkZir7J5SpjrayIHKDfhJa8bdqH8a4xsmP2BrurTqhSWTI56JQ+h Zpbkjtul56xuSiaYIno4/uiym0c7vahH0V083VFE0845jQP/Tl+AA/X+tH9xVCpj 72NHvC3VuNt42h4oZfc3 =iy1O -----END PGP SIGNATURE----- --Apple-Mail=_67C87F7A-F051-4E36-82B2-11311A86BC80-- From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 18:35:52 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4663AB58 for ; Sat, 4 Oct 2014 18:35:52 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2CF24643 for ; Sat, 4 Oct 2014 18:35:52 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id s94IZqZL045916 for ; Sat, 4 Oct 2014 18:35:52 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 193981] panic: vtbuf_fill_locked begin.tp_row 0 must be < screen height 0 on Raspberry PI Date: Sat, 04 Oct 2014 18:35:52 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 10.0-STABLE X-Bugzilla-Keywords: vt X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dumbbell@FreeBSD.org X-Bugzilla-Status: Needs Triage X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: dumbbell@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 18:35:52 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D193981 Jean-S=C3=A9bastien P=C3=A9dron changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-arm@FreeBSD.org |dumbbell@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 18:49:58 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C5914F59 for ; Sat, 4 Oct 2014 18:49:58 +0000 (UTC) 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 9A7E8794 for ; Sat, 4 Oct 2014 18:49:58 +0000 (UTC) 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; bh=vp3eMk85aWG+C8ww+l9qPDiLOiMLo1DDOc6gmwky7Yc=; b=A2jahjlA/DXj5Yj+Ne0FuFTlnaQb0BdXGR6ygXh1N+2WrjDCuqXM4LGo6X3xz804I18t20Z553zBNzmrCmLo/CtjpXNZml5KxBTaKQNZ1ZvIgTE8wzfFeA5RdpTdvyB69iAIFUK8f8q/g4bgJS+jUaGmraV3ULAOMRdjTTQ8b9k=; Received: from [182.5.31.141] (port=55685 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XaUOu-000Ole-6K for freebsd-arm@FreeBSD.org; Sat, 04 Oct 2014 12:49:52 -0600 Date: Sun, 5 Oct 2014 02:49:35 +0800 From: Erich Dollansky To: freebsd-arm@FreeBSD.org Subject: nss make configure stops without error message Message-ID: <20141005024935.6e9de9f3@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-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 18:49:58 -0000 Hi, when I try a make configure in /usr/ports/security/nss on a Raspberry running 10.1BETA3, I get this error without any hint of the cause: *** Error code 1 Stop. make[1]: stopped in /usr/ports/security/nss *** Error code 1 Stop. make: stopped in /usr/ports/security/nss Any idea? Erich From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 19:43:40 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9C94ECFA for ; Sat, 4 Oct 2014 19:43:40 +0000 (UTC) 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 75E6ACB6 for ; Sat, 4 Oct 2014 19:43:40 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=EWiTINmWIobyu5e91Ww+J+jHZcvU1jpMRIQVp8p1to0=; b=IO0ntcIVX1Us2hqr7loPYy/Yhcb1YLSY3//P31kTSYpWjy5SrqZb4IG56thCvYBUQMJZzQ39jlIQlW0lDR/IZTPs5KZNPHJHEvfynjgclf23WLq+HMm2gR2XeuPh513eo8ZfKCjRASfxNKEI3F0xmupB05YsnSHcwb7Lx+f02t0=; Received: from [182.5.31.141] (port=30866 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XaVEw-0012eZ-M2; Sat, 04 Oct 2014 13:43:39 -0600 Date: Sun, 5 Oct 2014 03:43:34 +0800 From: Erich Dollansky To: "Herbert J. Skuhra" Subject: Re: nss make configure stops without error message Message-ID: <20141005034334.711fd5d9@X220.alogt.com> In-Reply-To: <86r3ynwsrs.wl-hskuhra@eumx.net> References: <20141005024935.6e9de9f3@X220.alogt.com> <86r3ynwsrs.wl-hskuhra@eumx.net> 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-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 19:43:40 -0000 Hi, On Sat, 04 Oct 2014 21:15:35 +0200 "Herbert J. Skuhra" wrote: > Hi, > > On Sun, 5 Oct 2014 02:49:35 +0800 > Erich Dollansky wrote: > > > when I try a make configure in > > > > /usr/ports/security/nss > > > > on a Raspberry running 10.1BETA3, I get this error without any hint > > of the cause: > > > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/ports/security/nss > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/security/nss > > > > Any idea? > > Is your ports tree up-to-date? I've seen this with vulnerable ports. > Try to run 'make -d e configure' or 'make -d A configure'. it was one or two weeks old but I am just downloading the new ports. Thanks. Erich From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 19:53:34 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFE1BE8C for ; Sat, 4 Oct 2014 19:53:34 +0000 (UTC) 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 AB489D8B for ; Sat, 4 Oct 2014 19:53:34 +0000 (UTC) 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:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=pFa5HnJz6I5S7ORZq1dqXSi7rRPtWp61TyaElCSYXp8=; b=AXc4AVKhW8aiwrASMhIVYQ2MMqI+BC0B0xgl/IfiMJSopgzl6vDDpPvuPMvTAO7rQ4lNMxgo1UZuNfA8VkEz2Ls/SW1X7AlUkImLaBrMsGdgZpL6UGTQUr/bSycBDFORPaCdQ5ZSBTgq69kstJP+gQ1Z37cmfp+wLoPddE2oXgo=; Received: from [182.5.31.141] (port=11630 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XaVOW-001A1y-Qp; Sat, 04 Oct 2014 13:53:33 -0600 Date: Sun, 5 Oct 2014 03:53:27 +0800 From: Erich Dollansky To: "Herbert J. Skuhra" Subject: Re: nss make configure stops without error message Message-ID: <20141005035327.70dbbbef@X220.alogt.com> In-Reply-To: <86r3ynwsrs.wl-hskuhra@eumx.net> References: <20141005024935.6e9de9f3@X220.alogt.com> <86r3ynwsrs.wl-hskuhra@eumx.net> 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-Source: X-Source-Args: X-Source-Dir: Cc: freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 19:53:34 -0000 Hi, updating the ports tree and downloading then a new nss version solved the problem. I wondered very much as I use the same ports tree for several machines and nss installation only failed on the Raspberry. Erich On Sat, 04 Oct 2014 21:15:35 +0200 "Herbert J. Skuhra" wrote: > Hi, > > On Sun, 5 Oct 2014 02:49:35 +0800 > Erich Dollansky wrote: > > > Hi, > > > > when I try a make configure in > > > > /usr/ports/security/nss > > > > on a Raspberry running 10.1BETA3, I get this error without any hint > > of the cause: > > > > *** Error code 1 > > > > Stop. > > make[1]: stopped in /usr/ports/security/nss > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/ports/security/nss > > > > Any idea? > > Is your ports tree up-to-date? I've seen this with vulnerable ports. > Try to run 'make -d e configure' or 'make -d A configure'. > > -- > Herbert From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 19:57:54 2014 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 56614F35 for ; Sat, 4 Oct 2014 19:57:54 +0000 (UTC) Received: from owm.eumx.net (eumx.net [91.82.101.43]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 09431DB0 for ; Sat, 4 Oct 2014 19:57:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=eumx.net; h=date :message-id:from:to:cc:subject:in-reply-to:references :mime-version:content-type; s=default; bh=uDmJ3sfVAQcBjxcfQED6eP DcfTE=; b=ojlw3uXTFiNsI1LT+eqOpz5gHq2l/cnAXJVc+dQTreM3PSIkiBe/BQ DD3hsNyKWXs0FuY1FDbU6Lpb3RVMcy0Kj7Pg0xdI1UC2uRAzWpMuTNlWQv55Ng+y ElNypu6Feu91nBiA60lEEbn1ItKlg3D4wbGFH5aw/+/jsUIHRaDoc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=eumx.net; h=date:message-id :from:to:cc:subject:in-reply-to:references:mime-version :content-type; q=dns; s=default; b=zfRjokhSRDTMzaiYs0l1wEnEjvi6X 5FPRFWsnSuuZT3Wlpr1EbEaWX6tfaJujWsyiSqduVg1m/97i6b2BhppnDDNcN3CA iqbN4g3bMWjacjFlkyGI4+S8JMTFWFAuTHRia74rR9rgyblcvX3w58FzL79Baetb UnU4EDbYbuXPII= Date: Sat, 04 Oct 2014 21:15:35 +0200 Message-ID: <86r3ynwsrs.wl-hskuhra@eumx.net> From: "Herbert J. Skuhra" To: freebsd-arm@FreeBSD.org Subject: Re: nss make configure stops without error message In-Reply-To: <20141005024935.6e9de9f3@X220.alogt.com> References: <20141005024935.6e9de9f3@X220.alogt.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/25.0.50 (i386-pc-freebsd10.1) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 19:57:54 -0000 Hi, On Sun, 5 Oct 2014 02:49:35 +0800 Erich Dollansky wrote: > Hi, > > when I try a make configure in > > /usr/ports/security/nss > > on a Raspberry running 10.1BETA3, I get this error without any hint of > the cause: > > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/security/nss > *** Error code 1 > > Stop. > make: stopped in /usr/ports/security/nss > > Any idea? Is your ports tree up-to-date? I've seen this with vulnerable ports. Try to run 'make -d e configure' or 'make -d A configure'. -- Herbert From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 22:57:39 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6FDB4A74 for ; Sat, 4 Oct 2014 22:57:39 +0000 (UTC) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F25B12E for ; Sat, 4 Oct 2014 22:57:39 +0000 (UTC) Received: by mail-yk0-f182.google.com with SMTP id 131so1148581ykp.13 for ; Sat, 04 Oct 2014 15:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G519CfwBdubLt3yHDAQ/pR/madpCBM502F+3L495dhs=; b=tbCIymOw7qxCwMxycLjNPo8n2EMAtVjL5EPxV90R0eod2lzX0A3/G04UYZvBnIyp1x 0MD55qna4K1XbVt7znfGCy4ZrQVehVxINIhBGeEOjRxm5zTQVonb08UIr/BH7t7ZXDS5 FH622Xk8pTbYwyzV+N8XDnsCb5YeQ7qdvAqOt4GFGPrexj5vegO0vhD9LWm+ytFzqbTH 57nZEgoSGo27lHXBZDC1c5iFcmwblLcv03JS1Re/JJpsztTAtHX3kp9ApAB3uezgq5Tr ZKZuyDX6jxZoqcypGOC8H33B1BgCF0o4XltQLFLG0jNyWRgF1qVjBHGbP18O5JdIzZrx eSRg== MIME-Version: 1.0 X-Received: by 10.236.150.138 with SMTP id z10mr8289413yhj.138.1412463458265; Sat, 04 Oct 2014 15:57:38 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Sat, 4 Oct 2014 15:57:38 -0700 (PDT) In-Reply-To: <6CB3D473-64B6-4D03-AD7E-10A38CD23E9E@me.com> References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> <6CB3D473-64B6-4D03-AD7E-10A38CD23E9E@me.com> Date: Sat, 4 Oct 2014 15:57:38 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Rui Paulo Content-Type: text/plain; charset=UTF-8 Cc: freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 22:57:39 -0000 Thanks Rui! Awesome, I was able to get it to boot and load the userland (terminology?)! The command was actually "usb start". On Fri, Oct 3, 2014 at 1:17 PM, Rui Paulo wrote: > On Oct 3, 2014, at 00:05, Russell Haley wrote: >> >> Here is my boot log including my load attempt: > > Oh, I forgot: you need to initialise USB before booting. There's a usb command in u-boot. Try 'usb init' or something similar. That should bring up the USB hardware. > > -- > Rui Paulo > > > From owner-freebsd-arm@FreeBSD.ORG Sat Oct 4 23:15:11 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BCAAF61 for ; Sat, 4 Oct 2014 23:15:11 +0000 (UTC) Received: from mail-yh0-x231.google.com (mail-yh0-x231.google.com [IPv6:2607:f8b0:4002:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0AFF82E1 for ; Sat, 4 Oct 2014 23:15:10 +0000 (UTC) Received: by mail-yh0-f49.google.com with SMTP id a41so1165417yho.36 for ; Sat, 04 Oct 2014 16:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LdZtfveb61484xZiGpniQ76A5yo2m9bQMQdGVmtUq/c=; b=GAT+AQ5tQzE3tZ8rm4DbTSIje5Zf7ASrjddBXyGOs0YQlzgrNx8ZLduglpbXIxqw0W OOxixEHLlVehBiVPqVWvlT1HJKN67ZCtLMIWrOJ6IWfX5vYkFcgFrD6j+7EW4OTGs/2w CON+WIbdQLxphq0vOWWMw1vbY03dBydNB5SQBIUd/VQz7OYsqvwPp/cvTEUZp/rMxGyr no1q/agqoRorUAiFDmbhRBwpTfiRJBVqMCHO/AncjD1Zt2q4Z6m/TqpEW7ZDFOF+BAdq 2yIESjCa8LoR8ibq9PdIPPYnq45osJDT3sDcXv+qt9Rha1vpjtQcwqgs8Uqp8csHGTw2 6WEw== MIME-Version: 1.0 X-Received: by 10.236.207.69 with SMTP id m45mr21570533yho.6.1412464510124; Sat, 04 Oct 2014 16:15:10 -0700 (PDT) Received: by 10.170.186.141 with HTTP; Sat, 4 Oct 2014 16:15:10 -0700 (PDT) In-Reply-To: References: <27A69721-D93D-4D4C-883A-718CFFF52B21@bsdimp.com> Date: Sat, 4 Oct 2014 16:15:10 -0700 Message-ID: Subject: Re: Digi CCWMX53 From: Russell Haley To: Warner Losh Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-arm@freebsd.org, Rui Paulo X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 23:15:11 -0000 Warner, That's great news! I had a scan and it seemed pretty thorough (albiet from a novice point of view). The pre-canned jobs looked promising. As much as I'm hoping your intention is to fix this FOR me, could you point me towards the code for the mtd support? Many thanks to everyone for helping. I've had more progress in the last two weeks than I have in the previous six months. lolz Russ On Sat, Oct 4, 2014 at 11:05 AM, Warner Losh wrote: > Hey Russ, > > A quick read suggests all, or nearly all, of the data needed to write a f= ull NFC for this chip is present. The programming and read sequences and in= formation about ECC error rates appear to be readily available. The exact E= CC used, however, appears opaque. This may or may not be a problem. It even= appears to have command sequencing built into the controller. This is a gr= eat feature, but one the current code doesn=E2=80=99t make use of. > > Warner > > On Oct 2, 2014, at 10:44 PM, Russell Haley wrote: > >> Warner, >> >> I was looking for a Digi reference but it turns out the Nand Flash Contr= oller is part of the Freescale Processor. Here is the link to the Reference= Manual: >> >> cache.freescale.com/files/32bit/doc/ref_manual/iMX53RM.pdf >> >> The NAND Flash Controller is in Chapter 51 page 3571 to page 3647. >> >> Is this relevant to what you are looking at doing? https://wiki.freebsd.= org/NAND >> >> I also found something called CHFS for NetBSD that looks interesting: ht= tp://chewiefs.sed.hu/home >> >> Thanks, >> Russ >> >> >> >> >> >> >> >> On Thu, Oct 2, 2014 at 2:34 PM, Warner Losh wrote: >> >> On Oct 1, 2014, at 12:48 AM, Russell Haley wrote: >> >> > Warner, >> > >> > First, I was just watching your 2010 talk on supporting FreeBSD in a c= ommercial environment. Has there been any updates in the process of maintai= ning a commercial branch in the last 4 years (not that I have any commercia= l ventures yet! lolz)? >> > >> > Anyway, I talked to an Engineer about the NAND controller spec and he = chided me for being naive (poor little software developer, in way over his = head. tisk tisk). He mentioned a FIVE THOUSAND page reference manual, which= I have yet to find on the Digi site. >> >> URL + section number. 5k pages doesn=E2=80=99t necessarily mean it will = be useful, though. :( >> >> > I have however found this hardware reference: >> > >> > http://ftp1.digi.com/support/documentation/90001270_E.pdf >> > >> > From Page 41: >> > >> > NAND flash memory >> > The ConnectCore for i.MX53 module provides 8GB of NAND flash memory. O= n the module in >> > the development kits a 512MByte, 2Kbyte page, NAND flash chip is used.= This NAND flash >> > device is connected to NAND flash Chip Select 0. >> > The NAND flash controller signals are available on the module connecto= rs. >> >> This basically says nothing more useful than =E2=80=9CThere=E2=80=99s NA= ND on this board that=E2=80=99s 4Gbits on CS0.=E2=80=9D which is useful, bu= t far from sufficient. How do I program the DMA so that ECC is added to the= OOB areas of that NAND? How do I set different ECC tables? How do I do ECC= error correction and detection? If you can=E2=80=99t answer that sort of q= uestion from the docs you have, then they aren=E2=80=99t helpful enough. >> >> > There are pin references to NAND further down in the section "GPIO mul= tiplexing table in the ConnectCore for i.MX53 module" on page 44 and 49. >> > >> > I fear this is not the information we are looking for. >> >> Not really. The GPIO info might be mildly helpful in a few cases >> >> > I have found another u-boot fork for the CCWMX53 on github here: https= ://github.com/Varcain/uboot-ccwmx53-digi >> > >> > With what seems to be the information about booting from NAND here: ht= tps://github.com/Varcain/uboot-ccwmx53-digi/tree/master/nand_spl >> > >> > If you can let me know what I am looking for I can both ask a more dir= ected question at work and also perform a better search. >> > >> > I have also started looking over the Architecture handbook as well bec= ause I have a feeling there is going to be lots of driver code in my future= . >> >> A good first step would be to get a URL or search string to get the URL = for that big spec. It is of the right size to possibly be useful, but somet= imes really long specs have 1-2 page descriptions of things like the SD con= troller or the NAND controller that you need special NDAs + business arrang= ements to get, so it is hard to say=E2=80=A6 >> >> Warner >> >> > >> > On Sun, Sep 28, 2014 at 12:12 AM, Warner Losh wrote: >> > >> > On Sep 27, 2014, at 9:49 PM, Russell Haley wrot= e: >> > >> > > I will attempt to load the kernel from tftp as soon as I can. I will= need >> > > to figure out how to get ethernet to the unit. >> > > >> > > I know nothing about u-boot so forgive my ignorance but I was hoping= to >> > > modify the Arndale configuration to work such as: >> > > >> > > # mmc read 1 0x70800000 0x800 0x1800; >> > > #go 0x70800000; >> > > >> > > and then point the rootfs to /dev/da1s1 >> > > >> > > On another note, do you know where I could find out more about the m= issing >> > > MTD support? >> > >> > A spec for the NAND controller is needed to make that work=E2=80=A6 I= s one about? >> > >> > Warner >> > >> > >> > > BTW, I thought your wireless mesh stuff was pretty cool. Ah, so many= cool >> > > projects, so little time... >> > > >> > > Thanks, >> > > >> > > Russ >> > > >> > > On Sat, Sep 27, 2014 at 2:35 PM, Rui Paulo wrote: >> > > >> > >> On Sep 27, 2014, at 13:31, Russell Haley wro= te: >> > >>> >> > >>> Rui, >> > >>> >> > >>> So no MTD means the NAND on the SOM is out, but can I boot the ker= nel >> > >> and load rootfs from the microSD, like in this example: >> > >>> =E2=80=A2 >> > >>> ARNDALE5250 # setenv bootcmd "fatload mmc 0:1 0x40f00000 kernel.bi= n; go >> > >> 0x40f00000" >> > >>> >> > >>> ARNDALE5250 # saveenv >> > >>> >> > >>> ARNDALE5250 # boot >> > >> >> > >> You can't use the Arndale config since the load addresses are diffe= rent. >> > >> You should be able to load a kernel from the network. Can you do t= hat? >> > >> >> > >> -- >> > >> Rui Paulo >> > >> >> > >> >> > >> >> > >> >> > > _______________________________________________ >> > > freebsd-arm@freebsd.org mailing list >> > > http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.or= g" >> > >> > >> >> >