From owner-freebsd-arm@freebsd.org Sun Mar 20 13:30:24 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BAD8AD6F1E for ; Sun, 20 Mar 2016 13:30:24 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1466F1D7C for ; Sun, 20 Mar 2016 13:30:24 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x234.google.com with SMTP id h198so92859788lfh.0 for ; Sun, 20 Mar 2016 06:30:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=K+ywFeV/vnBIkTM/hr1qmZjtSV6lEMVT7dYd3uY852o=; b=SwJ7gl8WCMwmID1qljvByb/ZL6BUwrr42MNgWaDU0rNHVKdW8E/rY6ERjOiyUczIHp raH/s5I/dwBSB4O1zhWC3epAme0wnoH/axfXcK9Jy8I6Y5GzPeqr5W0pljR9Usat6h8/ WW9jCUQ0DF2XobGckl9nS8DD/YxM1SD0dZ1a2i6a304CGQuBiYGqiLfpI8CgRDGFIc92 jtfS8TxkC/93t5fG+daqQzISQ8GwaO7ovUVxZh5xLeLWufTZLkd867Q5ceer5h6xkrcD iaGC38u9lkKghP+qncOoeAhIiGt0j0wYyFsMhnazXjUTF1J3hMmeqMV/Vf106wF1oCCU PQVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=K+ywFeV/vnBIkTM/hr1qmZjtSV6lEMVT7dYd3uY852o=; b=QUvI5RmVewhxUngHo0xTOzaItbh281iutNg+8YZmNu/hUISBFH+fopydKJFWnfQ+0w 9OqB0kCgjTdhPex1SkNuSmsJYoq5kd6zV/w67eeoEka2ZctEQUoqhVQ0h3yQd1jc39Oj hv8arFCVcKgw/jCgGGti2Z0c7gyq4Gsl3McHMuehvDwSkdNS68ucJ9r6QizbOZcd0r0e KbnT5Hi19LKev77HuCRratHD2BlvicI/A+lsFnANWSDRCAoW+RZoBcDU0ulXfr4lyHJ3 ePp7QzqqvgLbD385FmFS+XSSQ1bJxIX7wi+mJpa1Vz0ItEJ/IiRlHNvYcpqlwRbYwiHQ mAOA== X-Gm-Message-State: AD7BkJLSsSO5d4dI1ts9WRWwhAf+GGh/JLDDR/+fEPzEWBNl9cynr1XifkIw4CWkQkxxOw== X-Received: by 10.25.0.194 with SMTP id 185mr9380239lfa.4.1458480622185; Sun, 20 Mar 2016 06:30:22 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id g14sm3583225lfb.8.2016.03.20.06.30.21 for (version=TLSv1/SSLv3 cipher=OTHER); Sun, 20 Mar 2016 06:30:21 -0700 (PDT) To: freebsd-arm From: "Jukka A. Ukkonen" Subject: A little confusing inconsistency Message-ID: <56EEA5EC.9080704@gmail.com> Date: Sun, 20 Mar 2016 15:30:20 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 13:30:24 -0000 Hello all, Why does sysctl report hw.platform on arm and hw.model on amd64? The content is apparently intended to be analogous. E.g. on RPI2 ... hw.platform: bcm2836 and then on amd64 ... hw.model: AMD Opteron(tm) Processor 4162 EE Is this just a little lapsus or intentional for some reason? I noticed this when I tried bsdstats on RPI2. It complained about missing OID hw.model. --jau From owner-freebsd-arm@freebsd.org Sun Mar 20 14:43:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0C181AD7325 for ; Sun, 20 Mar 2016 14:43:37 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id C4BC91833 for ; Sun, 20 Mar 2016 14:43:35 +0000 (UTC) (envelope-from ilya@bakulin.de) DKIM-Filter: OpenDKIM Filter v2.10.3 olymp.kibab.com 7318F4E673 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1458485005; bh=ElcVmE5KutOQd1JHs6fc8ZoknEVy1QfOJ02SlFDzhgk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=jUO2zXJJ/MPO7fmaibagGt7Jit6asWTBfWa3guBX0gFyYEBvo0t+euW3Uv6rhF+dT pypVSNWtBu5amy0NhwJ+gG/WxWmB0zYYlmih8yiISZjj97O16fBNS3vW1q4x+EzxB1 IwTnkafDQu37Cr8SK/sh+ghXrYGA9wxBej3b2sOE= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 20 Mar 2016 15:43:25 +0100 From: Ilya Bakulin To: Russell Haley Cc: freebsd-arm Subject: Re: Fwd: SDIO Patch D4761.diff Not Building For Me Organization: Deglitch Networks In-Reply-To: References: Message-ID: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> X-Sender: ilya@bakulin.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 14:43:37 -0000 On 2016-03-18 20:06, Russell Haley wrote: > Ilya, > > I have tried re-compiling with the "corrected" include file in > /sys/dev/mmc/mmc.c (#include ?) > > I can't include my build output because it's over 200kb in size and > Pastebin.com crashes all my browsers here at work. I will email it to > you separately. > > Thanks, > > Russ Please use IMX6MMC kernel config file, it has all necessary modifications. dev/mmc/mmc.c should not be built at all because it's the old MMC stack implementation. If it fails, try adding "MODULES_OVERRIDE=" when calling make, because we don't need any modules anyway. I have updated instructions on https://bakulin.de/freebsd/mmccam.html to include kernel config names. -- Ilya From owner-freebsd-arm@freebsd.org Sun Mar 20 16:07:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11D12AD620F for ; Sun, 20 Mar 2016 16:07:34 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D39CC211 for ; Sun, 20 Mar 2016 16:07:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22a.google.com with SMTP id m184so187406317iof.1 for ; Sun, 20 Mar 2016 09:07:33 -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; bh=PYC2H6Y9REaVn+vAwNkDkBAIu0fyF7tvA0fP16MpIpQ=; b=Q3El3jN8Pjy6ZIX8NJMUBx9KbSczfiKgTDfniFt84wdt9vsiWw9glbe5veZnIggPjv C0rUS9pe83IU5I0YcYnhMsbOdEhcBFIkoVzpqfg/vHnVFPdbmwtOMcvx7LWQ8U+9Cjek 1ZIRxP/2TP3LVJj3Za3+GSxwEbkBIttg56RGNi/YCetDRuoieMAfTcp+YHigFiiyJKi5 qBNEq1IY/1BgYNEc2szBbjB+t2JHKbxxR+cPwZ1AbBZXxFB1mVpMg7bifPjoqQU2TJFn 8dBAS/BuuScHj9ehqLyyTkGejEm6ephAO8XNbNkyNUnGp9Ch/WiWY2TlAfik3ivrzkaY PpsQ== 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; bh=PYC2H6Y9REaVn+vAwNkDkBAIu0fyF7tvA0fP16MpIpQ=; b=AR8fZYUPp6h01QFz3CKVA7H+wujNsHzq8cBzAbSj7RwoXfeSdzjk7UyVlGQHTCm+j3 igAi3u8RVIaY/8lgZnRmtL8Werhvk5KYZjdyaHNyIlsdQWDz140wvUzqh7epk1uW0ejs JAj8Mfg1xi87BiXYxX0pgJ3tSr6ToDzmOHZiG6CuTvc+ecwcbZOO+BqCb8xBcvBnRcVB nrrxh3DpQk6q/cbzwnFfvTYa63wbrG4esh1U899Jg7csP8UH1HdzbKMxdAttAdRrhjAG ic3m1Q95YF6Ez5T65m9Y+OM15rZ+KmM9QQwVccZAvC4tyGaAzM23hK8depcSMmy5fP7P nD3A== X-Gm-Message-State: AD7BkJLGMin8EBKcIdcbxbhTcLT9sy8RlYrk+Y4+PrLjBXSMMtIZw1eH0oklDSKzZM2uVkGEDkuAvIT9UnVvZw== MIME-Version: 1.0 X-Received: by 10.107.35.82 with SMTP id j79mr2981585ioj.123.1458490053342; Sun, 20 Mar 2016 09:07:33 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Sun, 20 Mar 2016 09:07:33 -0700 (PDT) In-Reply-To: <56EEA5EC.9080704@gmail.com> References: <56EEA5EC.9080704@gmail.com> Date: Sun, 20 Mar 2016 09:07:33 -0700 Message-ID: Subject: Re: A little confusing inconsistency From: Adrian Chadd To: "Jukka A. Ukkonen" Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 16:07:34 -0000 It's just some inconsistency in how it's done. -a On 20 March 2016 at 06:30, Jukka A. Ukkonen wrote: > > Hello all, > > Why does sysctl report hw.platform on arm and hw.model on amd64? > The content is apparently intended to be analogous. > > E.g. on RPI2 ... > hw.platform: bcm2836 > > and then on amd64 ... > hw.model: AMD Opteron(tm) Processor 4162 EE > > Is this just a little lapsus or intentional for some reason? > I noticed this when I tried bsdstats on RPI2. It complained > about missing OID hw.model. > > --jau > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Mar 20 16:17:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 06020AD6560 for ; Sun, 20 Mar 2016 16:17:32 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 DAFC7A93 for ; Sun, 20 Mar 2016 16:17:31 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 36be8ac3-eeb7-11e5-827e-7d17a39bef25 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 20 Mar 2016 16:17:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2KGHNal006152; Sun, 20 Mar 2016 10:17:23 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458490643.68920.73.camel@freebsd.org> Subject: Re: A little confusing inconsistency From: Ian Lepore To: "Jukka A. Ukkonen" , freebsd-arm Date: Sun, 20 Mar 2016 10:17:23 -0600 In-Reply-To: <56EEA5EC.9080704@gmail.com> References: <56EEA5EC.9080704@gmail.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 16:17:32 -0000 On Sun, 2016-03-20 at 15:30 +0200, Jukka A. Ukkonen wrote: > Hello all, > > Why does sysctl report hw.platform on arm and hw.model on amd64? > The content is apparently intended to be analogous. > > E.g. on RPI2 ... > hw.platform: bcm2836 > > and then on amd64 ... > hw.model: AMD Opteron(tm) Processor 4162 EE > > Is this just a little lapsus or intentional for some reason? > I noticed this when I tried bsdstats on RPI2. It complained > about missing OID hw.model. In the armv6 world, driven by FDT data, hw.model should be the value from the device tree model property. But that isn't going to lead to "consistency" either, because then it will be "Wandboard Quad" or something similar. -- Ian From owner-freebsd-arm@freebsd.org Sun Mar 20 16:49:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 53979AD6D24 for ; Sun, 20 Mar 2016 16:49:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 43F35F41 for ; Sun, 20 Mar 2016 16:49:16 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2KGnGAG083487 for ; Sun, 20 Mar 2016 16:49:16 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 207728] [patch] duplicated FREEBSD_BOOT_LOADER config option in sys/arm/broadcom/bcm2835/std.rpi Date: Sun, 20 Mar 2016 16:49:16 +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: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ian@FreeBSD.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc bug_status 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.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Mar 2016 16:49:16 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207728 Ian Lepore changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |ian@FreeBSD.org Status|New |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Mon Mar 21 10:35:33 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59936AD762D for ; Mon, 21 Mar 2016 10:35:33 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D58B9C07; Mon, 21 Mar 2016 10:35:32 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lb0-x22e.google.com with SMTP id oe12so123833196lbc.0; Mon, 21 Mar 2016 03:35:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=/yOQsV4xzpRFzQpkCkdIXM5F98DPXsdXq73W9CHInbc=; b=ZPakF5Qb0lkKWHPnbJZTCM1UHOu2VYDwfo+xOR6JmzNYPTU1eAjRcf7SELvjZV5ZxU KFnA2ZnetLw92xMLYt8xjnIRLsfc7MiM71fZsSlueC9ljGnxyS9RaGGIYn4Rv5sscLQi m7EQaTmsV8yg6gnF4qpSAmP6kLMkKpQiG7uVsouAnX1kYbsZNzbV7BtUQbnNyignFChI n1hEVNCFuKQhJERhDNUp2OUDRmXYt08KjfnYvkknXwM+UqwBhGwhJW1i+9nr6qvlEn8C yUTjJXEdwTLb76aZUfVeX4tprkKo6cb6rW3x499E+Xe/QYWa7Ornqn0yVoEjAgkekRjG vNSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=/yOQsV4xzpRFzQpkCkdIXM5F98DPXsdXq73W9CHInbc=; b=Nnhh07c2miO6xHY92DTlDwXGxsuMmX4eWYHjjpL8tM5xutRE1gOLWSOI20ROtNoxZL l12rlxsQuEgdHb4/jzxEr2ltmhIrUkJ5pXZ6lYyWhKqeqvAh8s9WYaIdWU/lg1HyrY2q rXQpu/S9An+lGkLpylOJeWW3VXHx0FtF6Pjjvu8CUMI9Xq5/CudVagEiiiDosyKFVc3E Jw371MzsEN2MiKdlQsZDAi88ELFLNwuJPG574DfB4c4RU1l3sUtanitJJ/AOJqbZCPnU 0JAjC94KUGhffOtmHYIASVJ21STYVJz2OLteoBJ7WCtWZqlMHHRbH/KLX+ZjmQW4sig2 sWUA== X-Gm-Message-State: AD7BkJL9AxTivOsInRXRXlkyaqeWf1vtlOyogiOj3rbJhJGAcs2GBLxLMqOz5vSJYnnh/A== X-Received: by 10.112.150.133 with SMTP id ui5mr10311818lbb.12.1458556531042; Mon, 21 Mar 2016 03:35:31 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id m8sm4323275lfe.32.2016.03.21.03.35.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 03:35:30 -0700 (PDT) Subject: Re: A little confusing inconsistency To: Ian Lepore , freebsd-arm References: <56EEA5EC.9080704@gmail.com> <1458490643.68920.73.camel@freebsd.org> From: "Jukka A. Ukkonen" Message-ID: <56EFCE71.3060405@gmail.com> Date: Mon, 21 Mar 2016 12:35:29 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458490643.68920.73.camel@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 10:35:33 -0000 On 03/20/16 18:17, Ian Lepore wrote: > On Sun, 2016-03-20 at 15:30 +0200, Jukka A. Ukkonen wrote: >> Hello all, >> >> Why does sysctl report hw.platform on arm and hw.model on amd64? >> The content is apparently intended to be analogous. >> >> E.g. on RPI2 ... >> hw.platform: bcm2836 >> >> and then on amd64 ... >> hw.model: AMD Opteron(tm) Processor 4162 EE >> >> Is this just a little lapsus or intentional for some reason? >> I noticed this when I tried bsdstats on RPI2. It complained >> about missing OID hw.model. > > In the armv6 world, driven by FDT data, hw.model should be the value > from the device tree model property. But that isn't going to lead to > "consistency" either, because then it will be "Wandboard Quad" or > something similar. Somehow my mind works such that I would expect hw.model to contain additional information about a specific CPU model because there can be a lot of variants of the same CPU architecture. E.g. bcm2836 certainly matches that purpose. Similarly I would expect hw.platform to tell something about the mother board or that sort of info, like "Wandboard Quad", "Raspberry Pi 2 Model B", "Super Micro H8DCL-6F", etc. In my mind it would make sense to have sysctl report something like... hw.machine: arm hw.machine_arch: armv6hf hw.model: bcm2836 hw.platform: Raspberry Pi 2 Model B Of course armv6hf could be only armv6, and bcm2836 might equally well be something like "bcm2836,cortex-a7". Anyhow some consistency about which OIDs can be expected to be available and what is their content would be nice. --jau From owner-freebsd-arm@freebsd.org Mon Mar 21 13:10:57 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D83FEAD6ABA for ; Mon, 21 Mar 2016 13:10:57 +0000 (UTC) (envelope-from thelostadmin@gmail.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A0420755 for ; Mon, 21 Mar 2016 13:10:57 +0000 (UTC) (envelope-from thelostadmin@gmail.com) Received: by mail-io0-x22e.google.com with SMTP id m184so208518346iof.1 for ; Mon, 21 Mar 2016 06:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:references:to:in-reply-to; bh=b9EYga64hHO68QimGPnn2ZyICIEJQ4UKtjPgSM7Le8c=; b=hf2waO9c+fCJZHsUJAloXyrULvcXKEQ47/qHHj3mMvv8bIHHLQBzSzQVVlKATciQgK LtL5dQ3JZVBs7iPfsIV6HOTCraPIi/ztzEd412lGEaGgQMR6u27Zi2wfSfR/aNZl3gnY C9Fh+BTeXurSZ2gPJJurZaNMh8MyDeb3/JwH8J6BuKwvMETko6gyatli2v5iTojVIkr6 a5Ax6aL7IfcWdBp2JaCMn6uDgLsEU1J8I8944W478rC8jiJeslddLlEjHAMBnsvn3So8 9lfjXZ45XPLjXoyxBybDspqH8FGzJjROrWw/J6Er4p1D7OfDNI80OOVDXrMNTkBB4lvm jWsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :references:to:in-reply-to; bh=b9EYga64hHO68QimGPnn2ZyICIEJQ4UKtjPgSM7Le8c=; b=eiXCypepj9zqaJCHyhO3Q+N6a3E05zgYvKD9ndZGzkWejVxlJTmfObCztCFJvj6sk7 rI76BYgyUxUPE+sY6OVEUCrL6qpbnl0gfgGJWTPCsKZaznehJmjJpCWlqDn8OzjxfIPY 52hhiS4qJ0sDUUlak4TOQg9Q5EKBPH5szlUISCgehsLWUIocHImUSEAqxpUxaiHK98cQ 7bXhSqb/bUqSS7bP7Qipu9l551uUyrV+E98oBXeV4R8/JZzZytHPZenUV4Vkzz51X+Td OVlm8i030RxQEakUKId+hTLBg/TWv/cTDZayp6TYsM6W4qZx+N6b6rL7b6wFBy96dH/T PxcQ== X-Gm-Message-State: AD7BkJL9E6BNgbQd9nGZEcXP70dLTtm9eFZbuWaEWF1PuR6bqRscMKCsZpH3uhELfY1tMA== X-Received: by 10.107.151.74 with SMTP id z71mr33797087iod.43.1458565857025; Mon, 21 Mar 2016 06:10:57 -0700 (PDT) Received: from imac.suntrap.ca ([45.72.133.64]) by smtp.gmail.com with ESMTPSA id qa4sm5316040igb.14.2016.03.21.06.10.56 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 06:10:56 -0700 (PDT) From: The Lost Admin Message-Id: <2E5FD93C-C6EE-46DE-9D9B-BE2EAB566EC5@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FreeBSD on R-Pi and BBB: Odds and ends Date: Mon, 21 Mar 2016 09:10:57 -0400 References: <20160315213246.00a9cbc9@gmail.com> <20160316035220.0C49F406057@ip-64-139-1-69.sjc.megapath.net> <20160316112710.2065ac2c@zee.home> <20160316093403.GZ35640@home.opsec.eu> <20160316122433.1b9532af@zee.home> To: freebsd-arm@freebsd.org In-Reply-To: <20160316122433.1b9532af@zee.home> X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 13:10:57 -0000 The Lost Admin thelostadmin@gmail.com > On Mar 16, 2016, at 6:24 AM, Borodin Oleg wrote: >=20 > On Wed, 16 Mar 2016 10:34:03 +0100 > Kurt Jaeger wrote: >=20 >> Hi! >>=20 >>>> onborodin@gmail.com said: =20 >>>>>> There is nothing on the R-Pi web page that tells you that there = are 2=20 >>>>>> different packages to download for the Raspberry Pi: RPI-B and = RPI2. =20 >>>>=20 >>>>> RPI2 in development. =20 >>>>=20 >>>> OK. I was commenting on the wiki page for Raspberry Pi at: >>>> https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi >>>>=20 >>>> It doesn't use either "RPI2" or "development". >>>> I was pointing out what confused me in case anybody wanted to = improve that=20 >>>> page. =20 >>>=20 >>>> I think a paragraph that said something like >>>> "FreeBSD-10.2-RELEASE-arm-armv6-RPI-B" works on B and B+.=20 >>>> For Pi 2, you need "FreeBSD-11.0-CURRENT-arm-armv6-RPI2". >>>> would have been very helpful to me. >>>>=20 >>>=20 >>> I agree, the page can misinform novices and have some information >>> lag. Sorry, I have not right to edit this. =20 >>=20 >> Please create a wiki account and fix the wikipage: >>=20 >> = https://wiki.freebsd.org/action/newaccount/FrontPage?action=3Dnewaccount >>=20 >=20 > Hmm, I made login to the wiki and check right for editing _before_ = send mail to maillist. > I have on top "Immutable Page" and "You are not allowed to edit this = page" after raise edit action. >=20 >=20 > With best regards, >=20 > Oleg Borodin > onborodin@gmail.com I noticed that same problem (the lack of direction for downloads = depending you which model Pi you have) and tried to fix it myself. I = discovered that I couldn=E2=80=99t as well and then noticed the need for = a sponsor. I can=E2=80=99t say I blame the team for wanting to make sure = people don=E2=80=99t make a mess of the wiki but I didn=E2=80=99t find = any instructions on how to obtain a sponsor (not that I looked very = hard). > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Mar 21 15:16:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6113AD89B6 for ; Mon, 21 Mar 2016 15:16:29 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E83A7D9 for ; Mon, 21 Mar 2016 15:16:29 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x22c.google.com with SMTP id e196so34578861lfg.1 for ; Mon, 21 Mar 2016 08:16:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=5PVAoR3KIxhcB0WUfd71ebkYzQJUMR4lCyzuoJcgcHc=; b=mIspvM3Y9ckGBgbbQAsBea1qHCRLhknvBIhieWKKIoTXLlKik0h5OnhAb4vqij5tBY /Gmf5nCWvS9GTc0ADyzFU969GLCDm2sIBBQxT3x8lyC8Jgk/x4kcKktwe2mIenEZPVwB RUTtmjuuVghT0CGy49Heba3ufwbS9HdzbC2Aah5Jk6iXnLju4XwxhSKNXdxhQ5obfhs1 eE3Ad3N5fgjIp+JuecfBrlmhIo9pIDZTVoXQ4UOmoIHPE9+SkSKK/VKYDhfKgRL/5ge3 ZtJoAxkI0mQPKlChe4DDW1EKIM/zzG0j0532DGoID8c86VxTk4sL1LkH091eAdPg+OYG sWQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=5PVAoR3KIxhcB0WUfd71ebkYzQJUMR4lCyzuoJcgcHc=; b=ddfsojPRRRy/R/0TQ9OI64HL7nefF6xxi5TUkyYc5ZUv02Aetk3rgAAOssZyZlZ8sK ZJcR/RgcT9HiNX7PeWsOC0beG/U5/w3IJ5EdSEmqIhzyqZZg4Kmu0lB3QJiWZbSf6C6w AchfQXZTQRMrd29cbbRcdECbfjS6Lc4JVATK37mu3UqlfUKW22dY1WC6Ngmz8CBnJNz/ 337vWTLtoR+I25RmKrP5IE85iXkOii+LYsCdJ4vrLLNqXAKUQ1dcsJ7mqzYVl9ZpWsyP ayEuF53vDBfVL5V7+1PvdIoCOt0CseduNjNgf9VKKCUBQATIE7YNxxMf/K+qjSxdJ+KL T52A== X-Gm-Message-State: AD7BkJLJzhTKUsorUkJfXvWNE3BWgNxdm5wM3ejmg/ZO15iWTf1YKFnn+pLLvCJdhAeuaA== X-Received: by 10.25.18.98 with SMTP id h95mr119359lfi.113.1458573387154; Mon, 21 Mar 2016 08:16:27 -0700 (PDT) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id c126sm4677730lfb.2.2016.03.21.08.16.26 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 08:16:26 -0700 (PDT) To: freebsd-arm From: "Jukka A. Ukkonen" Subject: RPI2 panics while trying sleepq_add Message-ID: <56F01049.4020108@gmail.com> Date: Mon, 21 Mar 2016 17:16:25 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:16:29 -0000 Hello, Has anyone else seen symptoms similar to those described below? The RPI2 experiences odd panics displaying complaints like... <----------> panic: sleepq_add: td 0xc3a5e370 to sleep on wchan 0xc3afd000 with sleeping prohinited cpuid = 0 KBD: enter: panic [ thread pid 11 tid 100008 ] Stopped at $d.10: lrdb r15, [r15, r15, ror r15]! db> <-----------> It does not seem to matter anything whether the system is busy or relatively idle. What seems to be common to these panics is that in most cases when they happen the keyboard hasn't been touched for a while. This is just a wild guess, but maybe the kernel tries to put something in some low energy mode and fails. If I leave the thing doing something on its own for a while, when I get backsome 5 to 15 minutes later the poor RPI2 has fallen on its face showing the panic message similar to the one shown above. Have you seen this happening? Any ideas what might be going on? --jau From owner-freebsd-arm@freebsd.org Mon Mar 21 15:52:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C7EEBAD832D for ; Mon, 21 Mar 2016 15:52:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 952B6D2E; Mon, 21 Mar 2016 15:52:18 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x234.google.com with SMTP id kc10so70627462igb.0; Mon, 21 Mar 2016 08:52:18 -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; bh=X0xiwhtsdrh237S1v8H2UnBXTUmOsuuc/VB7Yzj9xpE=; b=ibK1V5fgZBnQNivg4JyPJtHuMmkrEuvptTLemLO+kymyNWUAtVf3twH94wHLJnz7s+ FTOf1CIyVb5b9hdR6h9U25u7XhDjIRz9znLWKIs8p6zgfeRZwmL1o9/fM4yBhvh/6+cc CDPRaIx7kfpb/syREjZQSb9pCKcQwd/5wV+cFETOl6GFoCIMo3/i/QxCnHUkoYqupdup nAVCQYsufzTrOZ3R3PzbeoZ9p/HtMrncMTujbWLoPgCTXl+CcxJY9sx7RwFCXYmSy4+K KWZ8xEuzwYRqswjnNz/pLZulm9joTGG9Iz5ntYFPy6HrgM4OOSfBV+eeG6Tx1ASRIvmT V+3g== 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; bh=X0xiwhtsdrh237S1v8H2UnBXTUmOsuuc/VB7Yzj9xpE=; b=cIcQ8gITl7Of1Fi3B7wK8dpCc3yJACOOlzCTPr7Amj9Hi21Gg+bn2mI9kX6ONkzfaE 3qoxB//z80NTGmssz4d4uIgaZ67hJKeTGm5i3RTLGOfhpxIU4io6jPpa14sSU1ADOuzJ QpHwOa4LzAVLUONHSQyfKgHFhIoADBCOjQn9MN7NdzIudOmymRZGoZjcNMaH3CrLbuGI MHFCe4m9GEPjLpU+P9dVx1m3SZdvGMbdOcdU94+kg6O6vNk4ytashgCSqNg3lsl/F8iB YJVoEkPPlj9SKposHZXLiK22kyhg2znRmEf7crYWWg08Akb+cTyeeg9T1Pr9zrXKxB1E LWAw== X-Gm-Message-State: AD7BkJJGz6V9NR99CuLVgMDY+5hDECwMt0V+BSgYToTbgPQivs0dLmF+/5sAknVMeqkLKHPO5M55NNGqxyxyAg== MIME-Version: 1.0 X-Received: by 10.50.157.39 with SMTP id wj7mr12481135igb.61.1458575538007; Mon, 21 Mar 2016 08:52:18 -0700 (PDT) Received: by 10.36.14.19 with HTTP; Mon, 21 Mar 2016 08:52:17 -0700 (PDT) In-Reply-To: <56EFCE71.3060405@gmail.com> References: <56EEA5EC.9080704@gmail.com> <1458490643.68920.73.camel@freebsd.org> <56EFCE71.3060405@gmail.com> Date: Mon, 21 Mar 2016 08:52:17 -0700 Message-ID: Subject: Re: A little confusing inconsistency From: Adrian Chadd To: "Jukka A. Ukkonen" Cc: Ian Lepore , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:52:18 -0000 Heh, well, what's missing is this description but for a larger set of existing boards. eg: * arm/arm64 :) * some i386, some amd64 * some mips (but mips is mostly easy - we don't necessarily get a "we're running on this platform!" string unless we compile it in) * sparc64 * powerpc If you can come up with examples that make sense for the platforms then we can all figure out how to implement it. It's adhoc because there's no formalish spec or guidelines for implementing. -a From owner-freebsd-arm@freebsd.org Mon Mar 21 15:53:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D2648AD83BF for ; Mon, 21 Mar 2016 15:53:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 91857EE6 for ; Mon, 21 Mar 2016 15:53:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x22b.google.com with SMTP id o5so129951363iod.2 for ; Mon, 21 Mar 2016 08:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=kF38i+Qj7Fo0XyhhzjwpSyLWIHlHf7g5Eurh6sl6+ac=; b=rao+fegHM0YEt0dRBqUB+pLtqwsBwdTeTB/pUi1ybNPiuYCt5zHBKM+KS+2EvMRa9f hLLOdvnE77s9LQC3RbjVMsrEoXOuBYZnyLrhbuTlem/bpv/igFivmv8dp/b3RkzZ3F7A dYV0qaqHnFVz/muyZMy1tdYAmxnSNS2ZfgJfV2KMqIHS8gmGP49QBIKTHrIl3k/bnuAN oXTZ55TUe4JTkxobChla7DZtO0kwhiIlmctnHNGuuipaYCkCgkzUqtAVdvgFxksNvtWN btH0w0Bzg24OdCyWb7lBLrLQ6xbEuUwC2ps8o/Veg9199SYR296mrGw55U2+KCF8u0es +ULA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kF38i+Qj7Fo0XyhhzjwpSyLWIHlHf7g5Eurh6sl6+ac=; b=St976A1emrzMEiNqcKRTZjh48Jeda/JTsOPwg0fepviCNaG4yn4Gi/pOPMy6NKqEfg CPQuUTQVAA2iVksESlc86OX60CuToHgO5IhFTirfZrLaW2Yqkt0RlPixMf3TtHgVe71V StfqIUKF9ZHmAlm5tLeKqkHnjlQ3VTBZ5VYUI1i0SbGorZhjGsuSCoTMvch7trh4t/Cr heh/6cRUHeGRssEBDCUoJz9snoq1INrau5LQkkOO18g9YSdSI1a7SKk6Yn1Dc7g65n1d kr9LsXuUi0bB86GMI2GmJi7KCBMfdcGJJayCW77bQc6Sznxb/nHHEO9rDZShWeFqKm3p 8KQA== X-Gm-Message-State: AD7BkJI2nl1UvKmFwY9LOjkTwUD/xqMf54YnoWVQbt3Z3xIxlU2Pf3mmOGl+u01pCNJ1T1fQ9TxPIbN85wpdBg== MIME-Version: 1.0 X-Received: by 10.107.19.73 with SMTP id b70mr28356921ioj.75.1458575610969; Mon, 21 Mar 2016 08:53:30 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.36.14.19 with HTTP; Mon, 21 Mar 2016 08:53:30 -0700 (PDT) In-Reply-To: <56F01049.4020108@gmail.com> References: <56F01049.4020108@gmail.com> Date: Mon, 21 Mar 2016 08:53:30 -0700 X-Google-Sender-Auth: 3NOtFZFUOQhB8xoChVABwHchJ54 Message-ID: Subject: Re: RPI2 panics while trying sleepq_add From: Adrian Chadd To: "Jukka A. Ukkonen" Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 15:53:31 -0000 hiya, are you able to post a backtrace ('bt') from the db> prompt? That'll be a good start in narrowing down what the issue is. (It's a bad sleep whilst a non-sleep lock is held, but we need to know the code path :) -a On 21 March 2016 at 08:16, Jukka A. Ukkonen wrote: > > Hello, > > Has anyone else seen symptoms similar to those described below? > > The RPI2 experiences odd panics displaying complaints like... > > <----------> > > panic: sleepq_add: td 0xc3a5e370 to sleep on wchan 0xc3afd000 with > sleeping prohinited > cpuid = 0 > KBD: enter: panic > [ thread pid 11 tid 100008 ] > Stopped at $d.10: lrdb r15, [r15, r15, ror r15]! > db> > > <-----------> > > It does not seem to matter anything whether the system is busy > or relatively idle. What seems to be common to these panics is > that in most cases when they happen the keyboard hasn't been > touched for a while. This is just a wild guess, but maybe the > kernel tries to put something in some low energy mode and fails. > > If I leave the thing doing something on its own for a while, > when I get backsome 5 to 15 minutes later the poor RPI2 has > fallen on its face showing the panic message similar to the > one shown above. > > Have you seen this happening? Any ideas what might be going on? > > --jau > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Mar 21 17:17:17 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0CA29AD779E for ; Mon, 21 Mar 2016 17:17:17 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B7765BCB for ; Mon, 21 Mar 2016 17:17:16 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id e185so222521845vkb.1 for ; Mon, 21 Mar 2016 10:17:16 -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; bh=2CVSEtsrnPDlVzxkZOKPGqtA35NuOWr8ca7dTmM0uK4=; b=ioUJhTC5HYGLQJH/NpSq414PXj7BWxvzZ/ftZihVo4lb9xTNlLfeTbeff30CYAZ2Rg thYNv04Qtg1nxBzhm0esChd04rSIC20qng2FFjt4xICvpFAKJArEQZ6BZPjjIuaMde7G 6qY43EpyTjFifnBn6wOJKdvNlzZYpLMoJx1Ze7WSBOpSh5v+3gUT4LPj/uxHfQ95oj5D 15dMBiBDgmUIMQ3o271CL1lZsq5Yc0Y1pEmuIxK/2dGE/PwmbMoz+becnM5spQq6EV/Q 9AOVl1jaG6sDuG0x2i2ATP875hRWkKOgiqnTZc2x5m8+WSee33CDkBDaQB1/hxDKBf3F tAoA== 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; bh=2CVSEtsrnPDlVzxkZOKPGqtA35NuOWr8ca7dTmM0uK4=; b=SD4WkQrEhSC62xqz7zg0ngoxJ8twGdxJJHSSMoUUgm56QY6/PpqTLUay4v4OCrArDq TokhFoGduqqM/ICqeExT+hM71BtZm/XTxZztrHUcGdtR+0pHB4X4b8gEMJgCV46v5Mfr Kll2sMoewIhtnHCTeNfjPnuWcZYPhuzue9zhz7JSVBBxQxsjUT49fQbRYBfLjwPuX6MO uaSASLtUjECVHiOL+Txsi0WB6Rx5tFrZrzul9fjgoW4MZgPQU4N2KNXWYQ0SN1n3WOp0 eucHuDJsW8qZdgllspF4uKafsDocM06T9si8Uh3fys885MvHQ2TzMHzCKt8Cwpw2w4Gj MTJQ== X-Gm-Message-State: AD7BkJIT8OpdLP1/5PCelFf7jaikvo7qmyzDpZ3edex0ynVk6t5EwKJqIHxOqYTCuVX/O7Pw8VKWu3jpkWS3Rw== MIME-Version: 1.0 X-Received: by 10.31.56.151 with SMTP id f145mr33164829vka.107.1458580635530; Mon, 21 Mar 2016 10:17:15 -0700 (PDT) Received: by 10.31.54.13 with HTTP; Mon, 21 Mar 2016 10:17:15 -0700 (PDT) In-Reply-To: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> Date: Mon, 21 Mar 2016 10:17:15 -0700 Message-ID: Subject: Re: Fwd: SDIO Patch D4761.diff Not Building For Me From: Russell Haley To: Ilya Bakulin Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 17:17:17 -0000 Ilya, Sorry, I forgot that you had proper instructions (got lost in all the emails I guess?). I'll try this again as soon as possible. Thanks, Russ On Sun, Mar 20, 2016 at 7:43 AM, Ilya Bakulin wrote: > On 2016-03-18 20:06, Russell Haley wrote: >> >> Ilya, >> >> I have tried re-compiling with the "corrected" include file in >> /sys/dev/mmc/mmc.c (#include ?) >> >> I can't include my build output because it's over 200kb in size and >> Pastebin.com crashes all my browsers here at work. I will email it to >> you separately. >> >> Thanks, >> >> Russ > > > Please use IMX6MMC kernel config file, it has all necessary modifications. > dev/mmc/mmc.c should not be built at all because it's the old MMC stack > implementation. If it fails, try adding "MODULES_OVERRIDE=" when calling > make, because we don't need any modules anyway. > > I have updated instructions on https://bakulin.de/freebsd/mmccam.html to > include kernel config names. > > -- > Ilya From owner-freebsd-arm@freebsd.org Mon Mar 21 18:18:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8DE32AD8E2C for ; Mon, 21 Mar 2016 18:18:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47BC41C97 for ; Mon, 21 Mar 2016 18:18:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2LHxqX0083949; Mon, 21 Mar 2016 10:59:52 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2LHxqFB083948; Mon, 21 Mar 2016 10:59:52 -0700 (PDT) (envelope-from fbsd) Date: Mon, 21 Mar 2016 10:59:52 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Effect of partitioning on wear-leveling Message-ID: <20160321175952.GA83908@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 18:18:13 -0000 To the extent that FreeBSD on ARM uses wear leveling on flash devices, does the partition layout have any effect on how or if wear leveling works? The puzzle at hand is an RPI2 with /boot/msdos and / on the microSD card and /usr on USB flash. /var and /tmp will be on microSD, but it's not clear whether they should be in the / partition or isolated. Thanks for reading, and any guidance! bob prohaska From owner-freebsd-arm@freebsd.org Mon Mar 21 19:01:28 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2D772AD6A83 for ; Mon, 21 Mar 2016 19:01:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 E8B8BB5A for ; Mon, 21 Mar 2016 19:01:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 49241122-ef97-11e5-827e-7d17a39bef25 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 21 Mar 2016 19:01:14 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2LJ1O3l009336; Mon, 21 Mar 2016 13:01:24 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458586884.68920.96.camel@freebsd.org> Subject: Re: Effect of partitioning on wear-leveling From: Ian Lepore To: bob prohaska , freebsd-arm@freebsd.org Date: Mon, 21 Mar 2016 13:01:24 -0600 In-Reply-To: <20160321175952.GA83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:01:28 -0000 On Mon, 2016-03-21 at 10:59 -0700, bob prohaska wrote: > To the extent that FreeBSD on ARM uses wear leveling on flash > devices, > does the partition layout have any effect on how or if wear leveling > works? > > The puzzle at hand is an RPI2 with /boot/msdos and / on the microSD > card > and /usr on USB flash. /var and /tmp will be on microSD, but it's not > clear > whether they should be in the / partition or isolated. > > Thanks for reading, and any guidance! > Freebsd does no wear-leveling, it's up to the microcontrollers within the storage devices to do that. Those controllers have no notion of partitioning or filesystem layout and do whatever they want to do internally about wear leveling. That leads to the mildly disturbing situation of having blocks from a readonly filesystem and blocks from a writable filesystem sharing the same flash erase-block inside the device. One likes to think of the data in a readonly filesystem as safely protected from the read-modify -write activity that happens at the flash erase-block level, but no such g'tee is made on any mmc, sd, or usb flash-based devices I know of. - Ian From owner-freebsd-arm@freebsd.org Mon Mar 21 19:56:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B26BEAD76C4 for ; Mon, 21 Mar 2016 19:56:04 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 974B336B; Mon, 21 Mar 2016 19:56:04 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 2C2BE1DA4; Mon, 21 Mar 2016 19:56:04 +0000 (UTC) Date: Mon, 21 Mar 2016 19:56:01 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: davidcs@FreeBSD.org, bdrewery@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <706059411.113.1458590163702.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2669 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 19:56:04 -0000 FreeBSD_HEAD_arm64 - Build #2669 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2669/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2669/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2669/console Change summaries: 297155 by davidcs: Modifications to achieve a common source base from FreeBSD7.x thru 10.x MFC after:5 days 297154 by bdrewery: DIRDEPS_BUILD: Update dependencies. Sponsored by: EMC / Isilon Storage Division The end of the build log: Started by an SCM change Building remotely on kyua4.nyi.freebsd.org (jailer) in workspace /jenkins/workspace/FreeBSD_HEAD_arm64 Updating svn://svnmir.freebsd.org/base/head at revision '2016-03-21T19:54:29.220 +0000' U sys/dev/bxe/bxe.c U sys/dev/bxe/bxe.h AU sys/boot/geli/Makefile.depend U sys/boot/i386/gptboot/Makefile.depend U sys/boot/i386/gptzfsboot/Makefile.depend U sys/boot/i386/libi386/Makefile.depend U sys/boot/i386/loader/Makefile.depend U sys/boot/i386/zfsloader/Makefile.depend U sbin/kldstat/Makefile.depend U targets/pseudo/userland/misc/Makefile.depend At revision 297155 No emails were triggered. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson2377857674975169892.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + true + sudo umount FreeBSD_HEAD_arm64/usr/src + true + sudo umount FreeBSD_HEAD_arm64/dev + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 + true + sudo rm -fr FreeBSD_HEAD_arm64 ERROR: Build step failed with exception java.lang.IllegalStateException: Invalid object ID 373 iota=374 at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:386) at hudson.remoting.ExportTable.get(ExportTable.java:330) at hudson.remoting.Channel.getExportedObject(Channel.java:633) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:599) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:62) at java.lang.Thread.run(Thread.java:745) at ......remote call to kyua4.nyi.freebsd.org(Native Method) at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416) at hudson.remoting.UserResponse.retrieve(UserRequest.java:220) at hudson.remoting.Channel.call(Channel.java:781) at hudson.remoting.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:250) at com.sun.proxy.$Proxy50.join(Unknown Source) at hudson.Launcher$RemoteLauncher$ProcImpl.join(Launcher.java:991) at hudson.tasks.CommandInterpreter.join(CommandInterpreter.java:135) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:95) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:64) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782) at hudson.model.Build$BuildExecution.build(Build.java:205) at hudson.model.Build$BuildExecution.doRun(Build.java:162) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:534) at hudson.model.Run.execute(Run.java:1738) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:410) Caused by: java.lang.Exception: Object was recently deallocated #373 (ref.0) : object=null type=hudson.Launcher$RemoteLaunchCallable$1 interfaces=[hudson.Launcher$RemoteProcess] Created at Mon Mar 21 19:56:00 GMT 2016 at hudson.remoting.ExportTable$Entry.(ExportTable.java:99) at hudson.remoting.ExportTable.export(ExportTable.java:305) at hudson.remoting.Channel.internalExport(Channel.java:629) at hudson.remoting.Channel.export(Channel.java:620) at hudson.remoting.Channel.export(Channel.java:590) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1150) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1113) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:62) at java.lang.Thread.run(Thread.java:745) Released at Mon Mar 21 19:56:00 GMT 2016 at hudson.remoting.ExportTable$Entry.release(ExportTable.java:131) at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:414) at hudson.remoting.Channel.unexport(Channel.java:641) at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:43) at hudson.remoting.Channel$1.handle(Channel.java:501) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: Command hudson.remoting.UnexportCommand@5d3705f created at at hudson.remoting.Command.(Command.java:67) at hudson.remoting.Command.(Command.java:50) at hudson.remoting.UnexportCommand.(UnexportCommand.java:33) at hudson.remoting.RemoteInvocationHandler$PhantomReferenceImpl.cleanup(RemoteInvocationHandler.java:360) at hudson.remoting.RemoteInvocationHandler$PhantomReferenceImpl.access$700(RemoteInvocationHandler.java:319) at hudson.remoting.RemoteInvocationHandler$Unexporter.run(RemoteInvocationHandler.java:420) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.Exception: Proxy hudson.remoting.RemoteInvocationHandler@175 was created for interface hudson.Launcher$RemoteProcess at hudson.remoting.RemoteInvocationHandler.(RemoteInvocationHandler.java:125) at hudson.remoting.RemoteInvocationHandler.wrap(RemoteInvocationHandler.java:137) at hudson.remoting.Channel.export(Channel.java:621) at hudson.remoting.Channel.export(Channel.java:590) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1150) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1113) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:62) ... 1 more at hudson.remoting.ExportTable.diagnoseInvalidId(ExportTable.java:379) at hudson.remoting.ExportTable.get(ExportTable.java:330) at hudson.remoting.Channel.getExportedObject(Channel.java:633) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:599) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:583) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:542) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:62) at java.lang.Thread.run(Thread.java:745) Caused by: Released at Mon Mar 21 19:56:00 GMT 2016 at hudson.remoting.ExportTable$Entry.release(ExportTable.java:131) at hudson.remoting.ExportTable.unexportByOid(ExportTable.java:414) at hudson.remoting.Channel.unexport(Channel.java:641) at hudson.remoting.UnexportCommand.execute(UnexportCommand.java:43) at hudson.remoting.Channel$1.handle(Channel.java:501) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: Command hudson.remoting.UnexportCommand@425d73a5 created at at hudson.remoting.Command.(Command.java:67) at hudson.remoting.Command.(Command.java:50) at hudson.remoting.UnexportCommand.(UnexportCommand.java:33) at hudson.remoting.RemoteInvocationHandler$PhantomReferenceImpl.cleanup(RemoteInvocationHandler.java:360) at hudson.remoting.RemoteInvocationHandler$PhantomReferenceImpl.access$700(RemoteInvocationHandler.java:319) at hudson.remoting.RemoteInvocationHandler$Unexporter.run(RemoteInvocationHandler.java:420) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.Exception: Proxy hudson.remoting.RemoteInvocationHandler@175 was created for interface hudson.Launcher$RemoteProcess at hudson.remoting.RemoteInvocationHandler.(RemoteInvocationHandler.java:125) at hudson.remoting.RemoteInvocationHandler.wrap(RemoteInvocationHandler.java:137) at hudson.remoting.Channel.export(Channel.java:621) at hudson.remoting.Channel.export(Channel.java:590) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1150) at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:1113) at hudson.remoting.UserRequest.perform(UserRequest.java:120) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at hudson.remoting.Engine$1$1.run(Engine.java:62) ... 1 more Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson6431604994184891839.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 jail: "FreeBSD_HEAD_arm64" not found + true + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address + true + sudo umount FreeBSD_HEAD_arm64/usr/src umount: FreeBSD_HEAD_arm64/usr/src: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/usr/src: unknown file system + true + sudo umount FreeBSD_HEAD_arm64/dev umount: FreeBSD_HEAD_arm64/dev: statfs: No such file or directory umount: FreeBSD_HEAD_arm64/dev: unknown file system + true + sudo rm -fr FreeBSD_HEAD_arm64 + sudo chflags -R noschg FreeBSD_HEAD_arm64 chflags: FreeBSD_HEAD_arm64: No such file or directory + true + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Mon Mar 21 20:25:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0F45EAD7E30 for ; Mon, 21 Mar 2016 20:25:23 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0101.outbound.protection.outlook.com [65.55.169.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "MSIT Machine Auth CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CBBB240; Mon, 21 Mar 2016 20:25:18 +0000 (UTC) (envelope-from david.somayajulu@qlogic.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qlgc.onmicrosoft.com; s=selector1-qlogic-com; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CMAX+e2zeJMCnTJ2VAieigP9kmMuSJPdFWzTddgqD20=; b=aHJbdXO4l8DzMBb8teBZ7a9aHAir0jkhhwmMhom4zaw2zU51MnbZS/OKA2qbMxU7M1dED/ncqPCgII7K5oxuWoCYMgieaTsroxlnC9f5SeVrNR0QdnVWT53U8aeog9KvL39pdkE3aDoYY+70yeGdWuNIJ+dzzX1FXmtbkioyjH8= Received: from DM2PR11MB0222.namprd11.prod.outlook.com (10.160.132.25) by DM2PR11MB0222.namprd11.prod.outlook.com (10.160.132.25) with Microsoft SMTP Server (TLS) id 15.1.443.12; Mon, 21 Mar 2016 20:11:01 +0000 Received: from DM2PR11MB0222.namprd11.prod.outlook.com ([10.160.132.25]) by DM2PR11MB0222.namprd11.prod.outlook.com ([10.160.132.25]) with mapi id 15.01.0443.014; Mon, 21 Mar 2016 20:11:01 +0000 From: David Somayajulu To: "jenkins-admin@FreeBSD.org" , "davidcs@FreeBSD.org" , "bdrewery@FreeBSD.org" , "freebsd-arm@FreeBSD.org" Subject: RE: FreeBSD_HEAD_arm64 - Build #2669 - Failure Thread-Topic: FreeBSD_HEAD_arm64 - Build #2669 - Failure Thread-Index: AQHRg6u4d0hl/5/yf0qcgzGRFh5XkJ9kU/VQ Date: Mon, 21 Mar 2016 20:11:00 +0000 Message-ID: References: <706059411.113.1458590163702.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <706059411.113.1458590163702.JavaMail.jenkins@jenkins-9.freebsd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: FreeBSD.org; dkim=none (message not signed) header.d=none;FreeBSD.org; dmarc=none action=none header.from=qlogic.com; x-originating-ip: [198.186.0.2] x-ms-office365-filtering-correlation-id: 68466672-cee1-44a4-168d-08d351c4ec74 x-microsoft-exchange-diagnostics: 1; DM2PR11MB0222; 5:WbpJizOv2Val+syoWEW8/hU2HfahrOO5DNiuPwESIs00GYggA/Kr0NhGOZFQNv9NS0IxMNzIT8vo1bz+pNFX1h91CiKOxrEK1CN4vV6dvBcC3UWdw6DIeGPIsxzyrU3c0oSDEDhyV0GUbo+7742rtw==; 24:YDjc+dudPthqBE2k+WR/rNfg1+43J+oJ54syTy6cau89ZmP+SKJqqw9bz0uJ8IJHwPskkPh7IQUUImSFseBdLB7lft6AFGtNNvA6TRg/AJo=; 20:8gKYcAT0o/U6c8eU99aKOgEntcwzCl284CPSEmocx961IS5cdearksB0/dXmrXAQQ0PpwJ8w8I5a8K43uTcsY9NnzYTZEwKn9tugigIicGS4/bVrApfHgh8nS4k0YibZy4HibfbtSgRhw6tBtVX4kE0fm0edKzYV8/wBv9O+0rM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR11MB0222; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DM2PR11MB0222; BCL:0; PCL:0; RULEID:; SRVR:DM2PR11MB0222; x-forefront-prvs: 0888B1D284 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(54534003)(13624006)(377454003)(33656002)(87936001)(19580405001)(86362001)(19580395003)(76576001)(74316001)(2201001)(66066001)(50986999)(76176999)(54356999)(450100001)(102836003)(3846002)(6116002)(1096002)(1220700001)(2906002)(586003)(106116001)(122556002)(5008740100001)(3280700002)(3660700001)(107886002)(189998001)(5890100001)(2501003)(10400500002)(92566002)(77096005)(15975445007)(81166005)(5001770100001)(2950100001)(2900100001)(11100500001)(5004730100002)(5003600100002)(99286002)(5002640100001)(15760500001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR11MB0222; H:DM2PR11MB0222.namprd11.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: qlogic.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2016 20:11:00.9967 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d68a1f9-1490-4d0e-8767-a87dab3ef2ba X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR11MB0222 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 20:25:23 -0000 SGksDQpJdCBkb2Vzbid0IGFwcGVhciB0aGF0IA0KCTI5NzE1NSBieSBkYXZpZGNzOg0KCU1vZGlm aWNhdGlvbnMgdG8gYWNoaWV2ZSBhIGNvbW1vbiBzb3VyY2UgYmFzZSBmcm9tIEZyZWVCU0Q3Lngg dGhydSAxMC54DQoNCmlzIHRoZSBjYXVzZS4NCg0KVGhhbmtzDQpEYXZpZCBTLg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGplbmtpbnMtYWRtaW5ARnJlZUJTRC5vcmcgW21haWx0 bzpqZW5raW5zLWFkbWluQEZyZWVCU0Qub3JnXSANClNlbnQ6IE1vbmRheSwgTWFyY2ggMjEsIDIw MTYgMTI6NTYgUE0NClRvOiBkYXZpZGNzQEZyZWVCU0Qub3JnOyBiZHJld2VyeUBGcmVlQlNELm9y ZzsgamVua2lucy1hZG1pbkBGcmVlQlNELm9yZzsgZnJlZWJzZC1hcm1ARnJlZUJTRC5vcmcNClN1 YmplY3Q6IEZyZWVCU0RfSEVBRF9hcm02NCAtIEJ1aWxkICMyNjY5IC0gRmFpbHVyZQ0KDQpGcmVl QlNEX0hFQURfYXJtNjQgLSBCdWlsZCAjMjY2OSAtIEZhaWx1cmU6DQoNCkJ1aWxkIGluZm9ybWF0 aW9uOiBodHRwczovL2plbmtpbnMuRnJlZUJTRC5vcmcvam9iL0ZyZWVCU0RfSEVBRF9hcm02NC8y NjY5Lw0KRnVsbCBjaGFuZ2UgbG9nOiBodHRwczovL2plbmtpbnMuRnJlZUJTRC5vcmcvam9iL0Zy ZWVCU0RfSEVBRF9hcm02NC8yNjY5L2NoYW5nZXMNCkZ1bGwgYnVpbGQgbG9nOiBodHRwczovL2pl bmtpbnMuRnJlZUJTRC5vcmcvam9iL0ZyZWVCU0RfSEVBRF9hcm02NC8yNjY5L2NvbnNvbGUNCg0K Q2hhbmdlIHN1bW1hcmllczoNCg0KMjk3MTU1IGJ5IGRhdmlkY3M6DQpNb2RpZmljYXRpb25zIHRv IGFjaGlldmUgYSBjb21tb24gc291cmNlIGJhc2UgZnJvbSBGcmVlQlNENy54IHRocnUgMTAueA0K DQpNRkMgYWZ0ZXI6NSBkYXlzDQoNCjI5NzE1NCBieSBiZHJld2VyeToNCkRJUkRFUFNfQlVJTEQ6 IFVwZGF0ZSBkZXBlbmRlbmNpZXMuDQoNClNwb25zb3JlZCBieToJRU1DIC8gSXNpbG9uIFN0b3Jh Z2UgRGl2aXNpb24NCg0KDQoNClRoZSBlbmQgb2YgdGhlIGJ1aWxkIGxvZzoNCg0KU3RhcnRlZCBi eSBhbiBTQ00gY2hhbmdlDQpCdWlsZGluZyByZW1vdGVseSBvbiBreXVhNC5ueWkuZnJlZWJzZC5v cmcgKGphaWxlcikgaW4gd29ya3NwYWNlIC9qZW5raW5zL3dvcmtzcGFjZS9GcmVlQlNEX0hFQURf YXJtNjQNClVwZGF0aW5nIHN2bjovL3N2bm1pci5mcmVlYnNkLm9yZy9iYXNlL2hlYWQgYXQgcmV2 aXNpb24gJzIwMTYtMDMtMjFUMTk6NTQ6MjkuMjIwICswMDAwJw0KVSAgICAgICAgIHN5cy9kZXYv YnhlL2J4ZS5jDQpVICAgICAgICAgc3lzL2Rldi9ieGUvYnhlLmgNCkFVICAgICAgICBzeXMvYm9v dC9nZWxpL01ha2VmaWxlLmRlcGVuZA0KVSAgICAgICAgIHN5cy9ib290L2kzODYvZ3B0Ym9vdC9N YWtlZmlsZS5kZXBlbmQNClUgICAgICAgICBzeXMvYm9vdC9pMzg2L2dwdHpmc2Jvb3QvTWFrZWZp bGUuZGVwZW5kDQpVICAgICAgICAgc3lzL2Jvb3QvaTM4Ni9saWJpMzg2L01ha2VmaWxlLmRlcGVu ZA0KVSAgICAgICAgIHN5cy9ib290L2kzODYvbG9hZGVyL01ha2VmaWxlLmRlcGVuZA0KVSAgICAg ICAgIHN5cy9ib290L2kzODYvemZzbG9hZGVyL01ha2VmaWxlLmRlcGVuZA0KVSAgICAgICAgIHNi aW4va2xkc3RhdC9NYWtlZmlsZS5kZXBlbmQNClUgICAgICAgICB0YXJnZXRzL3BzZXVkby91c2Vy bGFuZC9taXNjL01ha2VmaWxlLmRlcGVuZA0KQXQgcmV2aXNpb24gMjk3MTU1DQoNCk5vIGVtYWls cyB3ZXJlIHRyaWdnZXJlZC4NCltGcmVlQlNEX0hFQURfYXJtNjRdICQgL2Jpbi9zaCAteGUgL3Rt cC9odWRzb24yMzc3ODU3Njc0OTc1MTY5ODkyLnNoDQorIGV4cG9ydCAnUEFUSD0vc2JpbjovYmlu Oi91c3Ivc2JpbjovdXNyL2JpbjovdXNyL2xvY2FsL3NiaW46L3Vzci9sb2NhbC9iaW4nDQorIGV4 cG9ydCAnam5hbWU9RnJlZUJTRF9IRUFEX2FybTY0Jw0KKyBlY2hvICdjbGVhbiB1cCBqYWlsIEZy ZWVCU0RfSEVBRF9hcm02NCcNCmNsZWFuIHVwIGphaWwgRnJlZUJTRF9IRUFEX2FybTY0DQorIHN1 ZG8gamFpbCAtciBGcmVlQlNEX0hFQURfYXJtNjQNCisgdHJ1ZQ0KKyBzdWRvIGlmY29uZmlnIGln YjAgaW5ldDYgMjYxMDoxYzE6MTo2MDdjOjoxMDQ6MSAtYWxpYXMgdHJ1ZSBzdWRvIA0KKyB1bW91 bnQgRnJlZUJTRF9IRUFEX2FybTY0L3Vzci9zcmMgdHJ1ZSBzdWRvIHVtb3VudCANCisgRnJlZUJT RF9IRUFEX2FybTY0L2RldiB0cnVlIHN1ZG8gcm0gLWZyIEZyZWVCU0RfSEVBRF9hcm02NCBzdWRv IA0KKyBjaGZsYWdzIC1SIG5vc2NoZyBGcmVlQlNEX0hFQURfYXJtNjQgdHJ1ZSBzdWRvIHJtIC1m ciANCisgRnJlZUJTRF9IRUFEX2FybTY0DQpFUlJPUjogQnVpbGQgc3RlcCBmYWlsZWQgd2l0aCBl eGNlcHRpb24NCmphdmEubGFuZy5JbGxlZ2FsU3RhdGVFeGNlcHRpb246IEludmFsaWQgb2JqZWN0 IElEIDM3MyBpb3RhPTM3NA0KCWF0IGh1ZHNvbi5yZW1vdGluZy5FeHBvcnRUYWJsZS5kaWFnbm9z ZUludmFsaWRJZChFeHBvcnRUYWJsZS5qYXZhOjM4NikNCglhdCBodWRzb24ucmVtb3RpbmcuRXhw b3J0VGFibGUuZ2V0KEV4cG9ydFRhYmxlLmphdmE6MzMwKQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5D aGFubmVsLmdldEV4cG9ydGVkT2JqZWN0KENoYW5uZWwuamF2YTo2MzMpDQoJYXQgaHVkc29uLnJl bW90aW5nLlJlbW90ZUludm9jYXRpb25IYW5kbGVyJFJQQ1JlcXVlc3QucGVyZm9ybShSZW1vdGVJ bnZvY2F0aW9uSGFuZGxlci5qYXZhOjU5OSkNCglhdCBodWRzb24ucmVtb3RpbmcuUmVtb3RlSW52 b2NhdGlvbkhhbmRsZXIkUlBDUmVxdWVzdC5jYWxsKFJlbW90ZUludm9jYXRpb25IYW5kbGVyLmph dmE6NTgzKQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5SZW1vdGVJbnZvY2F0aW9uSGFuZGxlciRSUENS ZXF1ZXN0LmNhbGwoUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIuamF2YTo1NDIpDQoJYXQgaHVkc29u LnJlbW90aW5nLlVzZXJSZXF1ZXN0LnBlcmZvcm0oVXNlclJlcXVlc3QuamF2YToxMjApDQoJYXQg aHVkc29uLnJlbW90aW5nLlVzZXJSZXF1ZXN0LnBlcmZvcm0oVXNlclJlcXVlc3QuamF2YTo0OCkN CglhdCBodWRzb24ucmVtb3RpbmcuUmVxdWVzdCQyLnJ1bihSZXF1ZXN0LmphdmE6MzI2KQ0KCWF0 IGh1ZHNvbi5yZW1vdGluZy5JbnRlcmNlcHRpbmdFeGVjdXRvclNlcnZpY2UkMS5jYWxsKEludGVy Y2VwdGluZ0V4ZWN1dG9yU2VydmljZS5qYXZhOjY4KQ0KCWF0IGphdmEudXRpbC5jb25jdXJyZW50 LkZ1dHVyZVRhc2sucnVuKEZ1dHVyZVRhc2suamF2YToyNjYpDQoJYXQgamF2YS51dGlsLmNvbmN1 cnJlbnQuVGhyZWFkUG9vbEV4ZWN1dG9yLnJ1bldvcmtlcihUaHJlYWRQb29sRXhlY3V0b3IuamF2 YToxMTQyKQ0KCWF0IGphdmEudXRpbC5jb25jdXJyZW50LlRocmVhZFBvb2xFeGVjdXRvciRXb3Jr ZXIucnVuKFRocmVhZFBvb2xFeGVjdXRvci5qYXZhOjYxNykNCglhdCBodWRzb24ucmVtb3Rpbmcu RW5naW5lJDEkMS5ydW4oRW5naW5lLmphdmE6NjIpDQoJYXQgamF2YS5sYW5nLlRocmVhZC5ydW4o VGhyZWFkLmphdmE6NzQ1KQ0KCWF0IC4uLi4uLnJlbW90ZSBjYWxsIHRvIGt5dWE0Lm55aS5mcmVl YnNkLm9yZyhOYXRpdmUgTWV0aG9kKQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5DaGFubmVsLmF0dGFj aENhbGxTaXRlU3RhY2tUcmFjZShDaGFubmVsLmphdmE6MTQxNikNCglhdCBodWRzb24ucmVtb3Rp bmcuVXNlclJlc3BvbnNlLnJldHJpZXZlKFVzZXJSZXF1ZXN0LmphdmE6MjIwKQ0KCWF0IGh1ZHNv bi5yZW1vdGluZy5DaGFubmVsLmNhbGwoQ2hhbm5lbC5qYXZhOjc4MSkNCglhdCBodWRzb24ucmVt b3RpbmcuUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIuaW52b2tlKFJlbW90ZUludm9jYXRpb25IYW5k bGVyLmphdmE6MjUwKQ0KCWF0IGNvbS5zdW4ucHJveHkuJFByb3h5NTAuam9pbihVbmtub3duIFNv dXJjZSkNCglhdCBodWRzb24uTGF1bmNoZXIkUmVtb3RlTGF1bmNoZXIkUHJvY0ltcGwuam9pbihM YXVuY2hlci5qYXZhOjk5MSkNCglhdCBodWRzb24udGFza3MuQ29tbWFuZEludGVycHJldGVyLmpv aW4oQ29tbWFuZEludGVycHJldGVyLmphdmE6MTM1KQ0KCWF0IGh1ZHNvbi50YXNrcy5Db21tYW5k SW50ZXJwcmV0ZXIucGVyZm9ybShDb21tYW5kSW50ZXJwcmV0ZXIuamF2YTo5NSkNCglhdCBodWRz b24udGFza3MuQ29tbWFuZEludGVycHJldGVyLnBlcmZvcm0oQ29tbWFuZEludGVycHJldGVyLmph dmE6NjQpDQoJYXQgaHVkc29uLnRhc2tzLkJ1aWxkU3RlcE1vbml0b3IkMS5wZXJmb3JtKEJ1aWxk U3RlcE1vbml0b3IuamF2YToyMCkNCglhdCBodWRzb24ubW9kZWwuQWJzdHJhY3RCdWlsZCRBYnN0 cmFjdEJ1aWxkRXhlY3V0aW9uLnBlcmZvcm0oQWJzdHJhY3RCdWlsZC5qYXZhOjc4MikNCglhdCBo dWRzb24ubW9kZWwuQnVpbGQkQnVpbGRFeGVjdXRpb24uYnVpbGQoQnVpbGQuamF2YToyMDUpDQoJ YXQgaHVkc29uLm1vZGVsLkJ1aWxkJEJ1aWxkRXhlY3V0aW9uLmRvUnVuKEJ1aWxkLmphdmE6MTYy KQ0KCWF0IGh1ZHNvbi5tb2RlbC5BYnN0cmFjdEJ1aWxkJEFic3RyYWN0QnVpbGRFeGVjdXRpb24u cnVuKEFic3RyYWN0QnVpbGQuamF2YTo1MzQpDQoJYXQgaHVkc29uLm1vZGVsLlJ1bi5leGVjdXRl KFJ1bi5qYXZhOjE3MzgpDQoJYXQgaHVkc29uLm1vZGVsLkZyZWVTdHlsZUJ1aWxkLnJ1bihGcmVl U3R5bGVCdWlsZC5qYXZhOjQzKQ0KCWF0IGh1ZHNvbi5tb2RlbC5SZXNvdXJjZUNvbnRyb2xsZXIu ZXhlY3V0ZShSZXNvdXJjZUNvbnRyb2xsZXIuamF2YTo5OCkNCglhdCBodWRzb24ubW9kZWwuRXhl Y3V0b3IucnVuKEV4ZWN1dG9yLmphdmE6NDEwKQ0KQ2F1c2VkIGJ5OiBqYXZhLmxhbmcuRXhjZXB0 aW9uOiBPYmplY3Qgd2FzIHJlY2VudGx5IGRlYWxsb2NhdGVkDQogICAgIzM3MyAocmVmLjApIDog b2JqZWN0PW51bGwgdHlwZT1odWRzb24uTGF1bmNoZXIkUmVtb3RlTGF1bmNoQ2FsbGFibGUkMSBp bnRlcmZhY2VzPVtodWRzb24uTGF1bmNoZXIkUmVtb3RlUHJvY2Vzc10NCiAgICAgIENyZWF0ZWQg YXQgTW9uIE1hciAyMSAxOTo1NjowMCBHTVQgMjAxNg0KICAgIAlhdCBodWRzb24ucmVtb3Rpbmcu RXhwb3J0VGFibGUkRW50cnkuPGluaXQ+KEV4cG9ydFRhYmxlLmphdmE6OTkpDQogICAgCWF0IGh1 ZHNvbi5yZW1vdGluZy5FeHBvcnRUYWJsZS5leHBvcnQoRXhwb3J0VGFibGUuamF2YTozMDUpDQog ICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5DaGFubmVsLmludGVybmFsRXhwb3J0KENoYW5uZWwuamF2 YTo2MjkpDQogICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5DaGFubmVsLmV4cG9ydChDaGFubmVsLmph dmE6NjIwKQ0KICAgIAlhdCBodWRzb24ucmVtb3RpbmcuQ2hhbm5lbC5leHBvcnQoQ2hhbm5lbC5q YXZhOjU5MCkNCiAgICAJYXQgaHVkc29uLkxhdW5jaGVyJFJlbW90ZUxhdW5jaENhbGxhYmxlLmNh bGwoTGF1bmNoZXIuamF2YToxMTUwKQ0KICAgIAlhdCBodWRzb24uTGF1bmNoZXIkUmVtb3RlTGF1 bmNoQ2FsbGFibGUuY2FsbChMYXVuY2hlci5qYXZhOjExMTMpDQogICAgCWF0IGh1ZHNvbi5yZW1v dGluZy5Vc2VyUmVxdWVzdC5wZXJmb3JtKFVzZXJSZXF1ZXN0LmphdmE6MTIwKQ0KICAgIAlhdCBo dWRzb24ucmVtb3RpbmcuVXNlclJlcXVlc3QucGVyZm9ybShVc2VyUmVxdWVzdC5qYXZhOjQ4KQ0K ICAgIAlhdCBodWRzb24ucmVtb3RpbmcuUmVxdWVzdCQyLnJ1bihSZXF1ZXN0LmphdmE6MzI2KQ0K ICAgIAlhdCBodWRzb24ucmVtb3RpbmcuSW50ZXJjZXB0aW5nRXhlY3V0b3JTZXJ2aWNlJDEuY2Fs bChJbnRlcmNlcHRpbmdFeGVjdXRvclNlcnZpY2UuamF2YTo2OCkNCiAgICAJYXQgamF2YS51dGls LmNvbmN1cnJlbnQuRnV0dXJlVGFzay5ydW4oRnV0dXJlVGFzay5qYXZhOjI2NikNCiAgICAJYXQg amF2YS51dGlsLmNvbmN1cnJlbnQuVGhyZWFkUG9vbEV4ZWN1dG9yLnJ1bldvcmtlcihUaHJlYWRQ b29sRXhlY3V0b3IuamF2YToxMTQyKQ0KICAgIAlhdCBqYXZhLnV0aWwuY29uY3VycmVudC5UaHJl YWRQb29sRXhlY3V0b3IkV29ya2VyLnJ1bihUaHJlYWRQb29sRXhlY3V0b3IuamF2YTo2MTcpDQog ICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5FbmdpbmUkMSQxLnJ1bihFbmdpbmUuamF2YTo2MikNCiAg ICAJYXQgamF2YS5sYW5nLlRocmVhZC5ydW4oVGhyZWFkLmphdmE6NzQ1KQ0KICAgICAgUmVsZWFz ZWQgYXQgTW9uIE1hciAyMSAxOTo1NjowMCBHTVQgMjAxNg0KICAgIAlhdCBodWRzb24ucmVtb3Rp bmcuRXhwb3J0VGFibGUkRW50cnkucmVsZWFzZShFeHBvcnRUYWJsZS5qYXZhOjEzMSkNCiAgICAJ YXQgaHVkc29uLnJlbW90aW5nLkV4cG9ydFRhYmxlLnVuZXhwb3J0QnlPaWQoRXhwb3J0VGFibGUu amF2YTo0MTQpDQogICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5DaGFubmVsLnVuZXhwb3J0KENoYW5u ZWwuamF2YTo2NDEpDQogICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5VbmV4cG9ydENvbW1hbmQuZXhl Y3V0ZShVbmV4cG9ydENvbW1hbmQuamF2YTo0MykNCiAgICAJYXQgaHVkc29uLnJlbW90aW5nLkNo YW5uZWwkMS5oYW5kbGUoQ2hhbm5lbC5qYXZhOjUwMSkNCiAgICAJYXQgaHVkc29uLnJlbW90aW5n LlN5bmNocm9ub3VzQ29tbWFuZFRyYW5zcG9ydCRSZWFkZXJUaHJlYWQucnVuKFN5bmNocm9ub3Vz Q29tbWFuZFRyYW5zcG9ydC5qYXZhOjYwKQ0KICAgIENhdXNlZCBieTogQ29tbWFuZCBodWRzb24u cmVtb3RpbmcuVW5leHBvcnRDb21tYW5kQDVkMzcwNWYgY3JlYXRlZCBhdA0KICAgIAlhdCBodWRz b24ucmVtb3RpbmcuQ29tbWFuZC48aW5pdD4oQ29tbWFuZC5qYXZhOjY3KQ0KICAgIAlhdCBodWRz b24ucmVtb3RpbmcuQ29tbWFuZC48aW5pdD4oQ29tbWFuZC5qYXZhOjUwKQ0KICAgIAlhdCBodWRz b24ucmVtb3RpbmcuVW5leHBvcnRDb21tYW5kLjxpbml0PihVbmV4cG9ydENvbW1hbmQuamF2YToz MykNCiAgICAJYXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUludm9jYXRpb25IYW5kbGVyJFBoYW50 b21SZWZlcmVuY2VJbXBsLmNsZWFudXAoUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIuamF2YTozNjAp DQogICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5SZW1vdGVJbnZvY2F0aW9uSGFuZGxlciRQaGFudG9t UmVmZXJlbmNlSW1wbC5hY2Nlc3MkNzAwKFJlbW90ZUludm9jYXRpb25IYW5kbGVyLmphdmE6MzE5 KQ0KICAgIAlhdCBodWRzb24ucmVtb3RpbmcuUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIkVW5leHBv cnRlci5ydW4oUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIuamF2YTo0MjApDQogICAgCWF0IGphdmEu dXRpbC5jb25jdXJyZW50LkV4ZWN1dG9ycyRSdW5uYWJsZUFkYXB0ZXIuY2FsbChFeGVjdXRvcnMu amF2YTo1MTEpDQogICAgCWF0IGphdmEudXRpbC5jb25jdXJyZW50LkZ1dHVyZVRhc2sucnVuKEZ1 dHVyZVRhc2suamF2YToyNjYpDQogICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5BdG1vc3RPbmVUaHJl YWRFeGVjdXRvciRXb3JrZXIucnVuKEF0bW9zdE9uZVRocmVhZEV4ZWN1dG9yLmphdmE6MTEwKQ0K ICAgIAlhdCBqYXZhLmxhbmcuVGhyZWFkLnJ1bihUaHJlYWQuamF2YTo3NDUpDQogICAgQ2F1c2Vk IGJ5OiBqYXZhLmxhbmcuRXhjZXB0aW9uOiBQcm94eSBodWRzb24ucmVtb3RpbmcuUmVtb3RlSW52 b2NhdGlvbkhhbmRsZXJAMTc1IHdhcyBjcmVhdGVkIGZvciBpbnRlcmZhY2UgaHVkc29uLkxhdW5j aGVyJFJlbW90ZVByb2Nlc3MNCiAgICAJYXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUludm9jYXRp b25IYW5kbGVyLjxpbml0PihSZW1vdGVJbnZvY2F0aW9uSGFuZGxlci5qYXZhOjEyNSkNCiAgICAJ YXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUludm9jYXRpb25IYW5kbGVyLndyYXAoUmVtb3RlSW52 b2NhdGlvbkhhbmRsZXIuamF2YToxMzcpDQogICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5DaGFubmVs LmV4cG9ydChDaGFubmVsLmphdmE6NjIxKQ0KICAgIAlhdCBodWRzb24ucmVtb3RpbmcuQ2hhbm5l bC5leHBvcnQoQ2hhbm5lbC5qYXZhOjU5MCkNCiAgICAJYXQgaHVkc29uLkxhdW5jaGVyJFJlbW90 ZUxhdW5jaENhbGxhYmxlLmNhbGwoTGF1bmNoZXIuamF2YToxMTUwKQ0KICAgIAlhdCBodWRzb24u TGF1bmNoZXIkUmVtb3RlTGF1bmNoQ2FsbGFibGUuY2FsbChMYXVuY2hlci5qYXZhOjExMTMpDQog ICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5Vc2VyUmVxdWVzdC5wZXJmb3JtKFVzZXJSZXF1ZXN0Lmph dmE6MTIwKQ0KICAgIAlhdCBodWRzb24ucmVtb3RpbmcuVXNlclJlcXVlc3QucGVyZm9ybShVc2Vy UmVxdWVzdC5qYXZhOjQ4KQ0KICAgIAlhdCBodWRzb24ucmVtb3RpbmcuUmVxdWVzdCQyLnJ1bihS ZXF1ZXN0LmphdmE6MzI2KQ0KICAgIAlhdCBodWRzb24ucmVtb3RpbmcuSW50ZXJjZXB0aW5nRXhl Y3V0b3JTZXJ2aWNlJDEuY2FsbChJbnRlcmNlcHRpbmdFeGVjdXRvclNlcnZpY2UuamF2YTo2OCkN CiAgICAJYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRnV0dXJlVGFzay5ydW4oRnV0dXJlVGFzay5q YXZhOjI2NikNCiAgICAJYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuVGhyZWFkUG9vbEV4ZWN1dG9y LnJ1bldvcmtlcihUaHJlYWRQb29sRXhlY3V0b3IuamF2YToxMTQyKQ0KICAgIAlhdCBqYXZhLnV0 aWwuY29uY3VycmVudC5UaHJlYWRQb29sRXhlY3V0b3IkV29ya2VyLnJ1bihUaHJlYWRQb29sRXhl Y3V0b3IuamF2YTo2MTcpDQogICAgCWF0IGh1ZHNvbi5yZW1vdGluZy5FbmdpbmUkMSQxLnJ1bihF bmdpbmUuamF2YTo2MikNCiAgICAJLi4uIDEgbW9yZQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5FeHBv cnRUYWJsZS5kaWFnbm9zZUludmFsaWRJZChFeHBvcnRUYWJsZS5qYXZhOjM3OSkNCglhdCBodWRz b24ucmVtb3RpbmcuRXhwb3J0VGFibGUuZ2V0KEV4cG9ydFRhYmxlLmphdmE6MzMwKQ0KCWF0IGh1 ZHNvbi5yZW1vdGluZy5DaGFubmVsLmdldEV4cG9ydGVkT2JqZWN0KENoYW5uZWwuamF2YTo2MzMp DQoJYXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUludm9jYXRpb25IYW5kbGVyJFJQQ1JlcXVlc3Qu cGVyZm9ybShSZW1vdGVJbnZvY2F0aW9uSGFuZGxlci5qYXZhOjU5OSkNCglhdCBodWRzb24ucmVt b3RpbmcuUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIkUlBDUmVxdWVzdC5jYWxsKFJlbW90ZUludm9j YXRpb25IYW5kbGVyLmphdmE6NTgzKQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5SZW1vdGVJbnZvY2F0 aW9uSGFuZGxlciRSUENSZXF1ZXN0LmNhbGwoUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIuamF2YTo1 NDIpDQoJYXQgaHVkc29uLnJlbW90aW5nLlVzZXJSZXF1ZXN0LnBlcmZvcm0oVXNlclJlcXVlc3Qu amF2YToxMjApDQoJYXQgaHVkc29uLnJlbW90aW5nLlVzZXJSZXF1ZXN0LnBlcmZvcm0oVXNlclJl cXVlc3QuamF2YTo0OCkNCglhdCBodWRzb24ucmVtb3RpbmcuUmVxdWVzdCQyLnJ1bihSZXF1ZXN0 LmphdmE6MzI2KQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5JbnRlcmNlcHRpbmdFeGVjdXRvclNlcnZp Y2UkMS5jYWxsKEludGVyY2VwdGluZ0V4ZWN1dG9yU2VydmljZS5qYXZhOjY4KQ0KCWF0IGphdmEu dXRpbC5jb25jdXJyZW50LkZ1dHVyZVRhc2sucnVuKEZ1dHVyZVRhc2suamF2YToyNjYpDQoJYXQg amF2YS51dGlsLmNvbmN1cnJlbnQuVGhyZWFkUG9vbEV4ZWN1dG9yLnJ1bldvcmtlcihUaHJlYWRQ b29sRXhlY3V0b3IuamF2YToxMTQyKQ0KCWF0IGphdmEudXRpbC5jb25jdXJyZW50LlRocmVhZFBv b2xFeGVjdXRvciRXb3JrZXIucnVuKFRocmVhZFBvb2xFeGVjdXRvci5qYXZhOjYxNykNCglhdCBo dWRzb24ucmVtb3RpbmcuRW5naW5lJDEkMS5ydW4oRW5naW5lLmphdmE6NjIpDQoJYXQgamF2YS5s YW5nLlRocmVhZC5ydW4oVGhyZWFkLmphdmE6NzQ1KQ0KQ2F1c2VkIGJ5OiAgIFJlbGVhc2VkIGF0 IE1vbiBNYXIgMjEgMTk6NTY6MDAgR01UIDIwMTYNCglhdCBodWRzb24ucmVtb3RpbmcuRXhwb3J0 VGFibGUkRW50cnkucmVsZWFzZShFeHBvcnRUYWJsZS5qYXZhOjEzMSkNCglhdCBodWRzb24ucmVt b3RpbmcuRXhwb3J0VGFibGUudW5leHBvcnRCeU9pZChFeHBvcnRUYWJsZS5qYXZhOjQxNCkNCglh dCBodWRzb24ucmVtb3RpbmcuQ2hhbm5lbC51bmV4cG9ydChDaGFubmVsLmphdmE6NjQxKQ0KCWF0 IGh1ZHNvbi5yZW1vdGluZy5VbmV4cG9ydENvbW1hbmQuZXhlY3V0ZShVbmV4cG9ydENvbW1hbmQu amF2YTo0MykNCglhdCBodWRzb24ucmVtb3RpbmcuQ2hhbm5lbCQxLmhhbmRsZShDaGFubmVsLmph dmE6NTAxKQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5TeW5jaHJvbm91c0NvbW1hbmRUcmFuc3BvcnQk UmVhZGVyVGhyZWFkLnJ1bihTeW5jaHJvbm91c0NvbW1hbmRUcmFuc3BvcnQuamF2YTo2MCkNCkNh dXNlZCBieTogQ29tbWFuZCBodWRzb24ucmVtb3RpbmcuVW5leHBvcnRDb21tYW5kQDQyNWQ3M2E1 IGNyZWF0ZWQgYXQNCglhdCBodWRzb24ucmVtb3RpbmcuQ29tbWFuZC48aW5pdD4oQ29tbWFuZC5q YXZhOjY3KQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5Db21tYW5kLjxpbml0PihDb21tYW5kLmphdmE6 NTApDQoJYXQgaHVkc29uLnJlbW90aW5nLlVuZXhwb3J0Q29tbWFuZC48aW5pdD4oVW5leHBvcnRD b21tYW5kLmphdmE6MzMpDQoJYXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUludm9jYXRpb25IYW5k bGVyJFBoYW50b21SZWZlcmVuY2VJbXBsLmNsZWFudXAoUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIu amF2YTozNjApDQoJYXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUludm9jYXRpb25IYW5kbGVyJFBo YW50b21SZWZlcmVuY2VJbXBsLmFjY2VzcyQ3MDAoUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIuamF2 YTozMTkpDQoJYXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUludm9jYXRpb25IYW5kbGVyJFVuZXhw b3J0ZXIucnVuKFJlbW90ZUludm9jYXRpb25IYW5kbGVyLmphdmE6NDIwKQ0KCWF0IGphdmEudXRp bC5jb25jdXJyZW50LkV4ZWN1dG9ycyRSdW5uYWJsZUFkYXB0ZXIuY2FsbChFeGVjdXRvcnMuamF2 YTo1MTEpDQoJYXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRnV0dXJlVGFzay5ydW4oRnV0dXJlVGFz ay5qYXZhOjI2NikNCglhdCBodWRzb24ucmVtb3RpbmcuQXRtb3N0T25lVGhyZWFkRXhlY3V0b3Ik V29ya2VyLnJ1bihBdG1vc3RPbmVUaHJlYWRFeGVjdXRvci5qYXZhOjExMCkNCglhdCBqYXZhLmxh bmcuVGhyZWFkLnJ1bihUaHJlYWQuamF2YTo3NDUpDQpDYXVzZWQgYnk6IGphdmEubGFuZy5FeGNl cHRpb246IFByb3h5IGh1ZHNvbi5yZW1vdGluZy5SZW1vdGVJbnZvY2F0aW9uSGFuZGxlckAxNzUg d2FzIGNyZWF0ZWQgZm9yIGludGVyZmFjZSBodWRzb24uTGF1bmNoZXIkUmVtb3RlUHJvY2Vzcw0K CWF0IGh1ZHNvbi5yZW1vdGluZy5SZW1vdGVJbnZvY2F0aW9uSGFuZGxlci48aW5pdD4oUmVtb3Rl SW52b2NhdGlvbkhhbmRsZXIuamF2YToxMjUpDQoJYXQgaHVkc29uLnJlbW90aW5nLlJlbW90ZUlu dm9jYXRpb25IYW5kbGVyLndyYXAoUmVtb3RlSW52b2NhdGlvbkhhbmRsZXIuamF2YToxMzcpDQoJ YXQgaHVkc29uLnJlbW90aW5nLkNoYW5uZWwuZXhwb3J0KENoYW5uZWwuamF2YTo2MjEpDQoJYXQg aHVkc29uLnJlbW90aW5nLkNoYW5uZWwuZXhwb3J0KENoYW5uZWwuamF2YTo1OTApDQoJYXQgaHVk c29uLkxhdW5jaGVyJFJlbW90ZUxhdW5jaENhbGxhYmxlLmNhbGwoTGF1bmNoZXIuamF2YToxMTUw KQ0KCWF0IGh1ZHNvbi5MYXVuY2hlciRSZW1vdGVMYXVuY2hDYWxsYWJsZS5jYWxsKExhdW5jaGVy LmphdmE6MTExMykNCglhdCBodWRzb24ucmVtb3RpbmcuVXNlclJlcXVlc3QucGVyZm9ybShVc2Vy UmVxdWVzdC5qYXZhOjEyMCkNCglhdCBodWRzb24ucmVtb3RpbmcuVXNlclJlcXVlc3QucGVyZm9y bShVc2VyUmVxdWVzdC5qYXZhOjQ4KQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5SZXF1ZXN0JDIucnVu KFJlcXVlc3QuamF2YTozMjYpDQoJYXQgaHVkc29uLnJlbW90aW5nLkludGVyY2VwdGluZ0V4ZWN1 dG9yU2VydmljZSQxLmNhbGwoSW50ZXJjZXB0aW5nRXhlY3V0b3JTZXJ2aWNlLmphdmE6NjgpDQoJ YXQgamF2YS51dGlsLmNvbmN1cnJlbnQuRnV0dXJlVGFzay5ydW4oRnV0dXJlVGFzay5qYXZhOjI2 NikNCglhdCBqYXZhLnV0aWwuY29uY3VycmVudC5UaHJlYWRQb29sRXhlY3V0b3IucnVuV29ya2Vy KFRocmVhZFBvb2xFeGVjdXRvci5qYXZhOjExNDIpDQoJYXQgamF2YS51dGlsLmNvbmN1cnJlbnQu VGhyZWFkUG9vbEV4ZWN1dG9yJFdvcmtlci5ydW4oVGhyZWFkUG9vbEV4ZWN1dG9yLmphdmE6NjE3 KQ0KCWF0IGh1ZHNvbi5yZW1vdGluZy5FbmdpbmUkMSQxLnJ1bihFbmdpbmUuamF2YTo2MikNCgku Li4gMSBtb3JlDQpCdWlsZCBzdGVwICdFeGVjdXRlIHNoZWxsJyBtYXJrZWQgYnVpbGQgYXMgZmFp bHVyZSBbUG9zdEJ1aWxkU2NyaXB0XSAtIEV4ZWN1dGlvbiBwb3N0IGJ1aWxkIHNjcmlwdHMuDQpb RnJlZUJTRF9IRUFEX2FybTY0XSAkIC9iaW4vc2ggLXhlIC90bXAvaHVkc29uNjQzMTYwNDk5NDE4 NDg5MTgzOS5zaA0KKyBleHBvcnQgJ1BBVEg9L3NiaW46L2JpbjovdXNyL3NiaW46L3Vzci9iaW46 L3Vzci9sb2NhbC9zYmluOi91c3IvbG9jYWwvYmluJw0KKyBleHBvcnQgJ2puYW1lPUZyZWVCU0Rf SEVBRF9hcm02NCcNCisgZWNobyAnY2xlYW4gdXAgamFpbCBGcmVlQlNEX0hFQURfYXJtNjQnDQpj bGVhbiB1cCBqYWlsIEZyZWVCU0RfSEVBRF9hcm02NA0KKyBzdWRvIGphaWwgLXIgRnJlZUJTRF9I RUFEX2FybTY0DQpqYWlsOiAiRnJlZUJTRF9IRUFEX2FybTY0IiBub3QgZm91bmQNCisgdHJ1ZQ0K KyBzdWRvIGlmY29uZmlnIGlnYjAgaW5ldDYgMjYxMDoxYzE6MTo2MDdjOjoxMDQ6MSAtYWxpYXMN CmlmY29uZmlnOiBpb2N0bCAoU0lPQ0RJRkFERFIpOiBDYW4ndCBhc3NpZ24gcmVxdWVzdGVkIGFk ZHJlc3MNCisgdHJ1ZQ0KKyBzdWRvIHVtb3VudCBGcmVlQlNEX0hFQURfYXJtNjQvdXNyL3NyYw0K dW1vdW50OiBGcmVlQlNEX0hFQURfYXJtNjQvdXNyL3NyYzogc3RhdGZzOiBObyBzdWNoIGZpbGUg b3IgZGlyZWN0b3J5DQp1bW91bnQ6IEZyZWVCU0RfSEVBRF9hcm02NC91c3Ivc3JjOiB1bmtub3du IGZpbGUgc3lzdGVtDQorIHRydWUNCisgc3VkbyB1bW91bnQgRnJlZUJTRF9IRUFEX2FybTY0L2Rl dg0KdW1vdW50OiBGcmVlQlNEX0hFQURfYXJtNjQvZGV2OiBzdGF0ZnM6IE5vIHN1Y2ggZmlsZSBv ciBkaXJlY3RvcnkNCnVtb3VudDogRnJlZUJTRF9IRUFEX2FybTY0L2RldjogdW5rbm93biBmaWxl IHN5c3RlbQ0KKyB0cnVlDQorIHN1ZG8gcm0gLWZyIEZyZWVCU0RfSEVBRF9hcm02NA0KKyBzdWRv IGNoZmxhZ3MgLVIgbm9zY2hnIEZyZWVCU0RfSEVBRF9hcm02NA0KY2hmbGFnczogRnJlZUJTRF9I RUFEX2FybTY0OiBObyBzdWNoIGZpbGUgb3IgZGlyZWN0b3J5DQorIHRydWUNCisgc3VkbyBybSAt ZnIgRnJlZUJTRF9IRUFEX2FybTY0DQpFbWFpbCB3YXMgdHJpZ2dlcmVkIGZvcjogRmFpbHVyZSAt IEFueQ0KU2VuZGluZyBlbWFpbCBmb3IgdHJpZ2dlcjogRmFpbHVyZSAtIEFueQ0K From owner-freebsd-arm@freebsd.org Mon Mar 21 22:11:55 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A7F8DAD8E46 for ; Mon, 21 Mar 2016 22:11:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72B5332A; Mon, 21 Mar 2016 22:11:55 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2LMBr4m084485; Mon, 21 Mar 2016 15:11:53 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2LMBrRD084484; Mon, 21 Mar 2016 15:11:53 -0700 (PDT) (envelope-from fbsd) Date: Mon, 21 Mar 2016 15:11:53 -0700 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160321221153.GB83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458586884.68920.96.camel@freebsd.org> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:11:55 -0000 On Mon, Mar 21, 2016 at 01:01:24PM -0600, Ian Lepore wrote: > > Freebsd does no wear-leveling, it's up to the microcontrollers within > the storage devices to do that. > > Those controllers have no notion of partitioning or filesystem layout > and do whatever they want to do internally about wear leveling. That > leads to the mildly disturbing situation of having blocks from a > readonly filesystem and blocks from a writable filesystem sharing the > same flash erase-block inside the device. One likes to think of the > data in a readonly filesystem as safely protected from the read-modify > -write activity that happens at the flash erase-block level, but no > such g'tee is made on any mmc, sd, or usb flash-based devices I know > of. > > - Ian > Ok, thanks. It sounds like /var and /tmp could be confined to limited-size partitions while still permitting wear leveling to use other, less-used parts of the device. So, if a block nominally in /var reaches end of life can the wear leveling controller start stashing data anywhere on the device? As a practical matter, should I even be worrying about this? Folks once made a big deal of partitioning storage so a runaway process couldn't choke the whole machine. Is the precaution still worth taking on ARM? bob prohaska From owner-freebsd-arm@freebsd.org Mon Mar 21 22:41:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2544CAD8532 for ; Mon, 21 Mar 2016 22:41:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 0C362C93 for ; Mon, 21 Mar 2016 22:41:12 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 09923358-efb6-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Mon, 21 Mar 2016 22:41:22 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2LMfA1S009972; Mon, 21 Mar 2016 16:41:10 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458600070.68920.107.camel@freebsd.org> Subject: Re: Effect of partitioning on wear-leveling From: Ian Lepore To: bob prohaska Cc: freebsd-arm@freebsd.org Date: Mon, 21 Mar 2016 16:41:10 -0600 In-Reply-To: <20160321221153.GB83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 22:41:13 -0000 On Mon, 2016-03-21 at 15:11 -0700, bob prohaska wrote: > On Mon, Mar 21, 2016 at 01:01:24PM -0600, Ian Lepore wrote: > > > > Freebsd does no wear-leveling, it's up to the microcontrollers > > within > > the storage devices to do that. > > > > Those controllers have no notion of partitioning or filesystem > > layout > > and do whatever they want to do internally about wear leveling. > > That > > leads to the mildly disturbing situation of having blocks from a > > readonly filesystem and blocks from a writable filesystem sharing > > the > > same flash erase-block inside the device. One likes to think of > > the > > data in a readonly filesystem as safely protected from the read > > -modify > > -write activity that happens at the flash erase-block level, but no > > such g'tee is made on any mmc, sd, or usb flash-based devices I > > know > > of. > > > > - Ian > > > Ok, thanks. It sounds like /var and /tmp could be confined to limited > -size > partitions while still permitting wear leveling to use other, less > -used > parts of the device. So, if a block nominally in /var reaches end of > life > can the wear leveling controller start stashing data anywhere on the > device? > > As a practical matter, should I even be worrying about this? Folks > once > made a big deal of partitioning storage so a runaway process couldn't > choke the whole machine. Is the precaution still worth taking on ARM? > > bob prohaska My point was: every block written to the device might end up anywhere on the device. A block written to /var might end up right next to a block from the rootfs that's mounted read-only. Furthermore, the device may decide to move blocks around internally that you haven't even written to for months or years. For example, if a 1MB erase block only contains a few 512 byte areas with live data, the controller might just move those to a more-used 1MB block and erase the original so that the original block is ready for new data in the future without an erase delay. It keeps a translation table off to the side so that it knows when you ask for block N, that's currently living in its idea of block M somewhere else. So, it makes no sense to me to worry about any of this. There's basically nothing you can do with partitioning that has any deterministic effect on where the data gets stored in the device. Also, it's been my experience that it's impossible to "wear out" an sdcard. I once ran a program that just wrote random data continuously at full speed to a 512MB card for several months nonstop. No noticible effect on the card. I actually still use that card today (in one of our older products whose filesystem image only needs about 40MB). -- Ian From owner-freebsd-arm@freebsd.org Mon Mar 21 23:02:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FCEFAD8932 for ; Mon, 21 Mar 2016 23:02:44 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 601AF1639; Mon, 21 Mar 2016 23:02:44 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 8BA9D1E15; Mon, 21 Mar 2016 23:02:44 +0000 (UTC) Date: Mon, 21 Mar 2016 23:02:42 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: emaste@FreeBSD.org, jhb@FreeBSD.org, bdrewery@FreeBSD.org, avos@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <539525482.116.1458601364489.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <706059411.113.1458590163702.JavaMail.jenkins@jenkins-9.freebsd.org> References: <706059411.113.1458590163702.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2670 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2016 23:02:44 -0000 FreeBSD_HEAD_arm64 - Build #2670 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2670/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2670/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2670/console Change summaries: 297168 by jhb: Regen. 297167 by jhb: Fully handle size_t lengths in AIO requests. First, update the return types of aio_return() and aio_waitcomplete() to ssize_t. POSIX requires aio_return() to return a ssize_t so that it can represent all return values from read() and write(). aio_waitcomplete() should use ssize_t for the same reason. aio_return() has used ssize_t in since r31620 but the manpage and system call entry were not updated. aio_waitcomplete() has always returned int. Note that this does not require new system call stubs as this is effectively only an API change in how the compiler interprets the return value. Second, allow aio_nbytes values up to IOSIZE_MAX instead of just INT_MAX. aio_read/write should now honor the same length limits as normal read/write. Third, use longs instead of ints in the aio_return() and aio_waitcomplete() system call functions so that the 64-bit size_t in the in-kernel aiocb isn't truncated to 32-bits before being copied out to userland or being returned. Finally, a simple test has been added to verify the bounds checking on the maximum read size from a file. 297166 by avos: rum: do not try to restore bssid/TSF synchronization when device is not associated. Tested with WUSB54GC, STA mode. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5543 297165 by avos: rum: separate some microcontroller vendor-specific requests into rum_do_mcu_request() This change should be no-op. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5542 297164 by avos: net80211: enable software beacon miss timer in SLEEP state Tested with WUSB54GC, STA mode (w/ power saving enabled) Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5545 297163 by emaste: Remove tools/vt/setfont It is included in vidcontrol as of r266836. Sponsored by: The FreeBSD Foundation 297162 by avos: net80211: add missing SLEEP -> AUTH state transition for station mode. Reviewed by: adrian Differential Revision: https://reviews.freebsd.org/D5269 297161 by bdrewery: Attempt to use the namecache for openat(2) path resolution. This finishes the work done in D2810. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 297160 by bdrewery: Document openat(2) behavior. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 297159 by bdrewery: Use curthread for vn_fullpath. No functional change. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 297158 by bdrewery: Consolidate open(2) and openat(2) code. MFC after: 2 weeks Sponsored by: EMC / Isilon Storage Division 297157 by bdrewery: Stop tracking stat(2). None of lstat(2), fstat(2), fstatat(2) were tracked either. The other filemon implementations also do not track stat(2), nor does bmake utilize it. The act of opening a file for read should be enough to decide that a file is a dependency. There could be rare cases where just having a file would cause a dependency but it is unlikely. MFC after: 2 weeks Also noted by: sjg Sponsored by: EMC / Isilon Storage Division 297156 by bdrewery: Track filemon usage via a proc.p_filemon pointer rather than its own lists. - proc.p_filemon is added which is protected by PROC_LOCK. This improves performance and avoids double-fork issues, taking allproc_lock while in syscalls, and walking the process tree in syscalls. A particular proc.p_filemon can only be changed to NULL or another filemon, or the filemon inherited, while the filemon->lock is held. - Filemon are reference counted. On the last reference the log will be closed. - When closing the devfs file handle, the filemon will be detached from all processes and inheritance prevented. - Disallow attaching to a process already being traced since filemon is typically intended to be used on children only. This is allowed for curproc as bmake relies on this behavior for rare cases when combining .MAKE with .META. - Detach any previously tracked process on ioctl(FILEMON_SET_PID). - Handle error from devfs_set_cdevpriv() in filemon_open(). - The global filemon lock and lists are removed. - A free list is no longer kept. Previously this list was forever-expanding and never garbage cleaned. - No longer loses track of double-forks. If the process holding the filemon handle closes it will close the log rather than wait on a daemonized process, but it will log all activity until it closes its handle. The filemon will be removed from the process and not inherited. - A separate process count is kept only as an optimization for forced detachment to avoid taking allproc_lock and walking the entire process tree. - struct filemon access is protected by sx(9) filemon->lock as it was before. - Add more comments and KASSERTS. MFC after: 2 weeks Reviewed by: kib, mjg, markj (all on previous versions) Sponsored by: EMC / Isilon Storage Division Differential Revision: https://reviews.freebsd.org/D5520 From owner-freebsd-arm@freebsd.org Tue Mar 22 02:15:27 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92E62AD8B27 for ; Tue, 22 Mar 2016 02:15:27 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 67228CBF for ; Tue, 22 Mar 2016 02:15:27 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-ig0-x231.google.com with SMTP id nk17so85330740igb.1 for ; Mon, 21 Mar 2016 19:15:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eA3LKnOP27pxw1jS/Mq95urAn/2yZyxkF/li19pJD+o=; b=Rg+o2/+dqJ0z/GUmnfwmoQmKG+BAP4BN7ZQuSZONEL61pe1f+M2tgIfTQrGJvoHWCX OTw+B2PAHOJTzwDOsjeSyfdInDtH2YIG5xrNJOxwR1jGqb/ulqsYZ57AW8h1b6b2ht6F EIJIzFm2xihNwNUj4kyW8t8OIHQSKl84WHBl0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eA3LKnOP27pxw1jS/Mq95urAn/2yZyxkF/li19pJD+o=; b=ORft9lrDR991hSZpdHnFXaCDDCcdJIbBGDo/DrRa+85A9hULtm7yJGMh5GEcCX7/+g 90FOwnt6/CkB8S50AOJaZe19tGoHSicxSfAj0+GeL2JLdXuRUwTwN/T5LuMzaEJAAp/1 ije0By5TuIKrnIRiip0HxVt0P8FMuDphusfR6LOwMYAOT4+3y80RDM2V8PPJYxOfysys oKn2TYQq1WrgXycitnUQiOOsCxxL+0DVanZaOofzaYCWFeBexmkL706AIy9LSkrV1mnu MazRqEkdCTfpH96wI2KvtR/ZTeCL9PBhdpne5T7q/DC4gIuRxD70txObz9Tw85FoF2Ko NzCA== X-Gm-Message-State: AD7BkJLpkc7VRqplcPhJV7i/RN331TP/r0l4LHNbIzSP/x+jCsIYsORelcPB0dh6qYrdvbPb X-Received: by 10.50.160.11 with SMTP id xg11mr2238047igb.28.1458612926642; Mon, 21 Mar 2016 19:15:26 -0700 (PDT) Received: from [172.29.100.56] (63-156-62-129.dia.static.qwest.net. [63.156.62.129]) by smtp.gmail.com with ESMTPSA id s12sm2164012ioi.24.2016.03.21.19.15.24 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 21 Mar 2016 19:15:25 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Effect of partitioning on wear-leveling From: Jim Thompson X-Mailer: iPhone Mail (13D15) In-Reply-To: <1458600070.68920.107.camel@freebsd.org> Date: Mon, 21 Mar 2016 20:15:24 -0600 Cc: bob prohaska , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> To: Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 02:15:27 -0000 > On Mar 21, 2016, at 4:41 PM, Ian Lepore wrote: >=20 > Also, it's been my experience that it's impossible to "wear out" an > sdcard. I once ran a program that just wrote random data continuously > at full speed to a 512MB card for several months nonstop. No noticible > effect on the card. I actually still use that card today (in one of > our older products whose filesystem image only needs about 40MB). Now try random power fails while writing. It won't last through 1000 of the= m. (eMMC is way better here.)= From owner-freebsd-arm@freebsd.org Tue Mar 22 02:38:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FCC5AD8FEB for ; Tue, 22 Mar 2016 02:38:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5C07C7DC for ; Tue, 22 Mar 2016 02:38:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x232.google.com with SMTP id 124so78808175iov.3 for ; Mon, 21 Mar 2016 19:38:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=dmXXigBnwN3vwnSbiJIkvWXdomxI64mkHdnmwO4+Ai0=; b=TZY8tHZhJ5ZAU56N77pZFx0sIO+XrNGftKlwdMVtUEaoz+4Glr3+/n0BxEhxYicEUy O68wH/GlS7UsT1YepH9Zn0YSHOGPI9Yg2rFQqAdvHM0jgj9gps3T/ZInxB7GOGYvnTtl EcrfN2ryNrCafR3Djryr2rIzmoto90k/igs+wMFkIG7WqYbxJ0uVl6wKJKinoDIbnBuq JOj073mbGWuOU/eB72uZiYbAypWUmWpWiCPAcCpaH+YIQg1f/5DYm+u48MPstlEo26Wn z7eF6EAGc2tjE0PFcFH0hogtl8AU6+DO2y9gwilFMm4xQxdepQUh+QnV+S7EPVjkT3yq OsVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=dmXXigBnwN3vwnSbiJIkvWXdomxI64mkHdnmwO4+Ai0=; b=EqQfYoJ8GZOU+Nk5q/Rub686NRYMqkLPs9VWQnlnF6tx1/e6I3RG9/030pdgwKE1yH wkSTAn6wQvvIfA3bY6zpopcL1lykrsWPaXM8i8/TEoLRbfbKpBIP0F46YmpdJRqREWD2 q3xjgtAcvzXgsEIfkhUR1FgKcQqWWpYIhXBp4f+v91PrkM3VIEXe0k9bILCl8pVoL4LH xjLI56QzAJY3BULqfdWvfPUy4tgHPDNHRxOBF+JnNGg9rGH7Sc8X/kLZoaNl5Yo1qAlH CiICwtTfEXk/FbYMVpJWHj6XKf31EoG3BdzLpQ3TFbMPU3jKIRceuyZcmnemE1Fg3ZzW ugRg== X-Gm-Message-State: AD7BkJJu2DeYNrQQXvcASE53H8t7mkXQ8S05couBJLUci0UmLFqks5bDbOUoL0hOsXwfw00qCHXmbDsdHMaonQ== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr29657340ioe.135.1458614293739; Mon, 21 Mar 2016 19:38:13 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Mon, 21 Mar 2016 19:38:13 -0700 (PDT) X-Originating-IP: [2607:fb90:125:5e44:0:1b:257b:6d01] Received: by 10.36.65.230 with HTTP; Mon, 21 Mar 2016 19:38:13 -0700 (PDT) In-Reply-To: <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> Date: Mon, 21 Mar 2016 20:38:13 -0600 X-Google-Sender-Auth: 413POKoLou--gC0IE4tya8ime_w Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Jim Thompson Cc: Ian Lepore , freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 02:38:14 -0000 On Mar 21, 2016 8:15 PM, "Jim Thompson" wrote: > > > > On Mar 21, 2016, at 4:41 PM, Ian Lepore wrote: > > > > Also, it's been my experience that it's impossible to "wear out" an > > sdcard. I once ran a program that just wrote random data continuously > > at full speed to a 512MB card for several months nonstop. No noticible > > effect on the card. I actually still use that card today (in one of > > our older products whose filesystem image only needs about 40MB). > > Now try random power fails while writing. It won't last through 1000 of them. (eMMC is way better One thing that people forget is that the underlying blocks that are written are completely independent of what lba is used to write it. So the notion that you have blocks normally part of /var or /tmp no longer makes sense. Between writing blocks in different order and garbage collection, modern SD cards do a good job of wear averaging. How much you've written to the drive in total drives wear out these days. Warner From owner-freebsd-arm@freebsd.org Tue Mar 22 03:28:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 70D3CAD891D for ; Tue, 22 Mar 2016 03:28:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3EC191CAC; Tue, 22 Mar 2016 03:28:35 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2M3SXns085150; Mon, 21 Mar 2016 20:28:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2M3SWEt085149; Mon, 21 Mar 2016 20:28:32 -0700 (PDT) (envelope-from fbsd) Date: Mon, 21 Mar 2016 20:28:32 -0700 From: bob prohaska To: Ian Lepore Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160322032832.GC83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458600070.68920.107.camel@freebsd.org> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 03:28:35 -0000 On Mon, Mar 21, 2016 at 04:41:10PM -0600, Ian Lepore wrote: > > Also, it's been my experience that it's impossible to "wear out" an > sdcard. I once ran a program that just wrote random data continuously > at full speed to a 512MB card for several months nonstop. No noticible > effect on the card. I actually still use that card today (in one of > our older products whose filesystem image only needs about 40MB). > > Have you ever checked to see how much of the 512 MB capacity remains? Seems that quite a lot of decay wouldn't show up if you're using less than 10% of the device's capacity. Thank you! bob prohaska From owner-freebsd-arm@freebsd.org Tue Mar 22 03:34:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1907EAD8AFC for ; Tue, 22 Mar 2016 03:34:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D8F1D1F53 for ; Tue, 22 Mar 2016 03:34:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2M3YIOC085175; Mon, 21 Mar 2016 20:34:18 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2M3YIgQ085174; Mon, 21 Mar 2016 20:34:18 -0700 (PDT) (envelope-from fbsd) Date: Mon, 21 Mar 2016 20:34:17 -0700 From: bob prohaska To: Warner Losh Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160322033417.GD83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> 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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 03:34:22 -0000 On Mon, Mar 21, 2016 at 08:38:13PM -0600, Warner Losh wrote: > > One thing that people forget is that the underlying blocks that are written > are completely independent of what lba is used to write it. So the notion > that you have blocks normally part of /var or /tmp no longer makes sense. > Between writing blocks in different order and garbage collection, modern SD > cards do a good job of wear averaging. How much you've written to the drive > in total drives wear out these days. > How do modern flash devices report end of life? Do problems show up in error logs, or does the device simply refuse to work with no warning? Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Tue Mar 22 03:47:43 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 63E9DAD8D00 for ; Tue, 22 Mar 2016 03:47:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3194F38B for ; Tue, 22 Mar 2016 03:47:43 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-pf0-x232.google.com with SMTP id u190so292162162pfb.3 for ; Mon, 21 Mar 2016 20:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:from:in-reply-to:date:cc:message-id :references:to; bh=e/wNeQocCtaO8I5KrR5VtuVW5ylz6rwrf7RpIPFMN/I=; b=nbVfF+rMUt+dwtB4e/VjT6gSMGG+eY4Lm35Nkz4Z9syJa+SQZ8gO6R5Xk7R8TzfhOS vByXwXWIJubKQgFg999GaXlmvoKkgobE6oHOQb+fKN6pizj/ZCDmjxjP/LXRpSUSt6k/ Kid50aIdDe4PFzzTe5BDdnG7DXy+U1bxzv7/ibgT+wQ1X4kAoDvUlnnqwtTN7hGUM/1r Pp0Af4NueX1RzuuI+PRFBWFEBr7kmOPZXSXqrJKNxRNuJK4rLPJyJ3EgWCrLrOBHhGkV lz35CPCdLaCsg8L+iyU/GjNWp2Aka/FZUf1ZN3geQcZcnCE4iMI6+06RGPUL+gdsNhxW 7w3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:from:in-reply-to :date:cc:message-id:references:to; bh=e/wNeQocCtaO8I5KrR5VtuVW5ylz6rwrf7RpIPFMN/I=; b=dQNyjyJUUD8j4IM5oA/3riKwubCJ+FpXunbhv6VJbyOc6wh485xhEIV4dpfiRw3v99 RqD263adi0O5XUnXedAwE+7btirunsRaXGFqA87ytzGEHBUFAcu0349ZDgmG1V6Qr9OG IEwTmxUJr6Glw7Fe+j5QYVJAVXyJUN8g7mi8RZwUnEfDBSc56fcImnf/HznBrPW/tXKb bW5jZkcUO7aR9KcWskuGcjjyqDmzcVjLanZQt9YAIphsNJddCOdtPfR8Yp476S11d6Qw 3pF0wZsgkf6RaySJQjFLROiPXuFoeIKw19pqxr9QHJxrATei2w3qAZhgCbQFfn6PG/QM X8rw== X-Gm-Message-State: AD7BkJKSK/olbF2NfDfWM2UXwedMaSQKB7xfCJSYTV4LhB0gHrulTo/n7bqbSNQ7fZbCGg== X-Received: by 10.66.90.199 with SMTP id by7mr50440953pab.113.1458618462722; Mon, 21 Mar 2016 20:47:42 -0700 (PDT) Received: from [100.127.129.191] ([69.53.245.19]) by smtp.gmail.com with ESMTPSA id v74sm3695257pfa.7.2016.03.21.20.47.41 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Mar 2016 20:47:42 -0700 (PDT) Sender: Warner Losh Subject: Re: Effect of partitioning on wear-leveling Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8C9DC301-4A05-4F2E-A703-6D525CB13CFC"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <20160322032832.GC83908@www.zefox.net> Date: Mon, 21 Mar 2016 21:47:39 -0600 Cc: Ian Lepore , freebsd-arm@freebsd.org Message-Id: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <20160322032832.GC83908@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 03:47:43 -0000 --Apple-Mail=_8C9DC301-4A05-4F2E-A703-6D525CB13CFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 21, 2016, at 9:28 PM, bob prohaska wrote: >=20 > On Mon, Mar 21, 2016 at 04:41:10PM -0600, Ian Lepore wrote: >>=20 >> Also, it's been my experience that it's impossible to "wear out" an >> sdcard. I once ran a program that just wrote random data = continuously >> at full speed to a 512MB card for several months nonstop. No = noticible >> effect on the card. I actually still use that card today (in one of >> our older products whose filesystem image only needs about 40MB). >>=20 >>=20 > Have you ever checked to see how much of the 512 MB capacity remains? > Seems that quite a lot of decay wouldn't show up if you're using less > than 10% of the device's capacity. If you are writing to only 10% of the LBA range, you should have 90% of the LBA range in addition to the normal reserve. This should mean that = you=E2=80=99ve got 10x the normal reserve (since normally the reserve is in the 10% = range, give or take). SD cards don=E2=80=99t lose capacity. Then tend to fail = read-only or read-never when they reach their end of life. So let=E2=80=99s do the math. 512MB cards tended to have write speeds of = maybe 6MB/s. At 6MB/s, that=E2=80=99s about 518MB/day, or one drive write per day. = Most SD cards, when you can find a rating, are good for between 0.3 and 1 drive write = per day over their life (some are more durable, granted). 0.3 DWPD would mean = that we=E2=80=99re putting wear not he part at 3x the normal rate. Over several month, = that=E2=80=99s nowhere near the 3 year design point that most SD cards implement. It=E2=80=99s = maybe 2 years of wear tops. If it=E2=80=99s a better card, it isn=E2=80=99t even one year = worth of writes. So it isn=E2=80=99t too surprising that Ian=E2=80=99s experience = wasn=E2=80=99t so horrible. I ran a similar experiments and failed to wear things out. It wasn=E2=80=99t until I = worked at a NAND card maker that I ever wore out NAND. And to do that I had to wear out = some tiny percentage of the drive by artificially limiting the range of NAND = used to a range of erase blocks (usually around 50 or maybe 10 GB of space) and = writing at full speed (something in the neighborhood of 1GB/s) would give maybe 50 P/E cycles an hour (due to swell limitations), leading to wear out = over a long weekend=E2=80=A6 And that=E2=80=99s using ~1% of the capacity of the = drive at a time. Warner --Apple-Mail=_8C9DC301-4A05-4F2E-A703-6D525CB13CFC 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 iQIcBAEBCgAGBQJW8MBcAAoJEGwc0Sh9sBEAJWkP/R/Jf+tROSgcTlhhJC2Z4S5W zi0knjml1KFchPzEpxkAwvmmBVrNLewbDgAYYO9UZtzw4b+wAtLBG/Hj/AB1V/tR RcCtvsm8ovTjpJQxzDEZ7UvGW1oecjMwjYHkrW11JbkGmuMsrH03KyxYv+E7YLc/ hdEFjNA9+jFy52lTIsu2r37/CXshyzt1BLIJS1enyGXq7ByV1e7XJ/E23AaXXoNe 3y4FRqddZIHE9vK8wp2HPEksCk9BGqtaqThtSWB0VuOK0gsxiP+kgS+ARrwHBv90 KjZReSTtScQlDFg0jNj2V2LV/cjL6QGITSUsO3fAiPHrfkQErrfdNVx91WHAF1EK lKRa59MGyxcA4zYPtvJ3be+z7O6DCVDZ8e4dYgkqPDPma3YucotSzHaX+XczomAa 76WiBB4oRRifmlqMjdSjKd+NCNQx3z/dyzjSlwISv9JHHcX14SMNFDX2OlWCd9WH dJvO8qXlGWC3bFBYjfISlvNKuTKLkl3CktKPQDb4PVknZG3VVzTLrJa4gXoizkQo vAcAEBcYjY3DUdAA5nkfdVe4nJV0tJUiEiwt7iRAisy5wuCwhDh4/TXSVebwFss0 c605dUMFHXNciCzGG9mBf0wTR7QFDgWwzkxCA3cgJHVy32epHRmacNW/iLXrjLDm XTEfRIa8Fs3pS0vPoYCc =k5q9 -----END PGP SIGNATURE----- --Apple-Mail=_8C9DC301-4A05-4F2E-A703-6D525CB13CFC-- From owner-freebsd-arm@freebsd.org Tue Mar 22 03:48:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42AA6AD8D4F for ; Tue, 22 Mar 2016 03:48:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0FC553F3 for ; Tue, 22 Mar 2016 03:48:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: by mail-pf0-x236.google.com with SMTP id 4so160118286pfd.0 for ; Mon, 21 Mar 2016 20:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=sender:subject:mime-version:from:in-reply-to:date:cc:message-id :references:to; bh=SuNV5x3Wh2ZiIQF3K0IR5pJPplvH58vYHkKLxAyb0uc=; b=XW17cPOPFqJOh4qHBHwY7qRWCaIm31FVarEG5fUYRtpWUSnOQSz7un5N4v70szoyzl 3w7uVr1PFC0vdStu19Apk22JHkiRW6NmcuT/Jq7ZcNTecCfC8A4vHMIJfU3Tbo4BJKIP JKzT4f9DMYJsJNIVzJM5VaoouhgfKtQtWgfH5cLj4xse4mkBhqjdKsgh9NC7E0Gisual scp6yddgio5GsrdBFYEMrLJI9hyiOJd7CUhRWdCItoGo9i/4L09TF958hGVdZOcZsMwK Th4vXqF1z4v1MsaMWWkHBdMj1zJqX2NwL5S8CcdEq4qPxTCd6VGk5sPkQf7V5eFzTzdy nKVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:from:in-reply-to :date:cc:message-id:references:to; bh=SuNV5x3Wh2ZiIQF3K0IR5pJPplvH58vYHkKLxAyb0uc=; b=Wo+O4MJBApNvo/Zt9dr0v4v44IyGIjxrv4iecQFYv6Y0Pp16YWtu3n0RK8A6yJVyCe 4u/5+lP5TyuNHvU1P+sY3+dgrLLIN3nd/MW3ksY32EEAISnPULb+KE5yyPD7vHrnH7Gd mnJwWC77M+td+vnW+MuM8lkAW4dZ28ZtC/y2mT3oFxV9dRhLK70KkbP4u2tDNBJVr4RW xtxjm8vzvWbozyCLxG88qn9dhjzjDQ5CqfN6zynGiBtTznDE953LodCry0zPkMoQcROB 07NgUGH6j6yLRfvHCj5jtX6Tci2LDKw58vzIobzDhn9by++HGSQfDEp8FwfGeYWOXVOL M+uw== X-Gm-Message-State: AD7BkJL2yPiejJzf1klRsmQX4FWg5qzyOstJmE35q2MwWtcqFGcs5tBD2MKu0VBQZ2tdzQ== X-Received: by 10.66.147.103 with SMTP id tj7mr50900641pab.72.1458618495659; Mon, 21 Mar 2016 20:48:15 -0700 (PDT) Received: from [100.127.129.191] ([69.53.245.19]) by smtp.gmail.com with ESMTPSA id v74sm3695257pfa.7.2016.03.21.20.48.14 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 21 Mar 2016 20:48:15 -0700 (PDT) Sender: Warner Losh Subject: Re: Effect of partitioning on wear-leveling Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_95B15785-E754-4610-8D2E-9D1794AE60F8"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5.2 From: Warner Losh In-Reply-To: <20160322033417.GD83908@www.zefox.net> Date: Mon, 21 Mar 2016 21:48:14 -0600 Cc: freebsd-arm@freebsd.org Message-Id: <271EF73A-077C-44A5-8B58-721405800B9F@bsdimp.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 03:48:16 -0000 --Apple-Mail=_95B15785-E754-4610-8D2E-9D1794AE60F8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 21, 2016, at 9:34 PM, bob prohaska wrote: >=20 > On Mon, Mar 21, 2016 at 08:38:13PM -0600, Warner Losh wrote: >>=20 >> One thing that people forget is that the underlying blocks that are = written >> are completely independent of what lba is used to write it. So the = notion >> that you have blocks normally part of /var or /tmp no longer makes = sense. >> Between writing blocks in different order and garbage collection, = modern SD >> cards do a good job of wear averaging. How much you've written to the = drive >> in total drives wear out these days. >>=20 >=20 > How do modern flash devices report end of life? Do problems show up in = error > logs, or does the device simply refuse to work with no warning? Undefined. Either it goes read-only or read-never. :) Warner --Apple-Mail=_95B15785-E754-4610-8D2E-9D1794AE60F8 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 iQIcBAEBCgAGBQJW8MB+AAoJEGwc0Sh9sBEAY+UQALWv0nTW1z2mEW6yPucnNZBw iuXg0LiUWVDUVDzMVHWxizNs9tydK6JCO7LeSBX21Oz3yXJjHnR/LKmktMYGtkWC RAvawN8Cdu0ksRNLlvNPp9qx/wc2wwflCocaHSC8zur+4WL+u9VVQFtjSMzoSuyN ZqO/IEHu6w0oeW/c+eg+zA96fnwa1604cH7u1cZ8PEIak4SVFOJXqTnRbjdrcyAj XxeRjEa7lsW8LAu5x4T5hog7htlkY0OyKt9ImFSHMIDl/WvPIQVWqDKG4w5prPdx UdcIm1JfTa5nVNvgiZmEq2JQ6xnAZxL0APiObGv4J4v8P/taTdCOlX2AEAJwXlyx +IT37+iSWZgdYHXPOBvmAZywras1If677jZhuxgYJwm7dDBtjyMJtrFkpER9LGp8 3EWnz6YgB7FrvlIpycAwg77UeSpK6ll30a8X4aw8K1cjdLM/DAqvI7c26E+cb4Oj hCFzI4nvQ4K1fUrZFdCfm+PvFs3YkaHknunU2e1IPF+sq5VPimJ3rf/xhgb4v9Lg p2AdWTZ1inVorBq8awi2Qk35DCXj+NIeQhOHgn9PirFCIbaPqX+cJV0Awh2UmnbW Kc6hkSDVkdy2OMUF862gsiDnBED2FYrkjiqT7QDUoWC8DtsyXQ+TFf2hsmgNFO4L q0J+Oew4G5aD1633Qd6v =43AU -----END PGP SIGNATURE----- --Apple-Mail=_95B15785-E754-4610-8D2E-9D1794AE60F8-- From owner-freebsd-arm@freebsd.org Tue Mar 22 04:39:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCF38AD69B9 for ; Tue, 22 Mar 2016 04:39:38 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 867B97E2 for ; Tue, 22 Mar 2016 04:39:38 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x231.google.com with SMTP id k1so240150433vkb.0 for ; Mon, 21 Mar 2016 21:39: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; bh=3FhTsMCBaf1e1QL+Q+Z2tIFEfjF+YHmU0PMH8jZvCJw=; b=P8tnYBlsLI50W+6AEgHS5AU/pdELvMp1ObYKuIQeHeMyr2kee56bkiCA+LQuKHDFmx 0hNAfFbwxKnSfsrBeW0WGpVWWPr4n+mNK2+ceEj6p2O5pes8N1RNjocxIlmqMB0Is0L/ JCd9Lj6swNI2epb8jhQHxp6/C9Rg2YAWtBmg8ScVb6PomZltiylw5s5awNjDJZuTbf0n tZv3bY8Fj46P0amB1XYQEw8UYQ3swDDYpvmTaY2cHyhIMnBQ/8Jbi7A+I2QPrPnhea2j FzkoCdVJyK9vY8rf715uUK4QApT0rBf5/SPLomeQskLbxwJwjB/dHJxR17DepEZtlEfa iV3Q== 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; bh=3FhTsMCBaf1e1QL+Q+Z2tIFEfjF+YHmU0PMH8jZvCJw=; b=V2pLyxrXGnPmtoE2rw7YCkUmCYDCZWx66RLVE5FitriXNErzhsAPYDhHXee5nuRPjT rXLDZUUybzexreJASfisjFEvnl1j8P0qn5bimPSJMhv5lY1fuiZUIZgP6Cv7/4ecMj/W vgGIXYu2UDXB3LJKRgxPm/RPov+LG8laKkW+MX4bxEvoKrGvewkyCAN/K+pCETkQie6Y 3p56LrbHKLL1ws8AXDeIhQsa9V7rdbIDNyMAF9Mbrakgx9jeV+XNRc9n0jN1XDp8qvB6 c3lIZlRi+LO3yLc22kMNerXViX1dLHGcOBtyjIvlbqiHCS++GG0NjvtZkNwODcByj2J6 R4Xw== X-Gm-Message-State: AD7BkJJepEfn9cYSuIEZ/pGsAw4e5Um81B9B5/c/26CixR9jyOQi1n2g011gWU7Q6J/K0Mx+Lubp6jRmT6WuAA== MIME-Version: 1.0 X-Received: by 10.31.45.143 with SMTP id t137mr33267372vkt.143.1458621577747; Mon, 21 Mar 2016 21:39:37 -0700 (PDT) Received: by 10.31.54.13 with HTTP; Mon, 21 Mar 2016 21:39:37 -0700 (PDT) In-Reply-To: <271EF73A-077C-44A5-8B58-721405800B9F@bsdimp.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <271EF73A-077C-44A5-8B58-721405800B9F@bsdimp.com> Date: Mon, 21 Mar 2016 21:39:37 -0700 Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Russell Haley To: Warner Losh Cc: bob prohaska , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 04:39:38 -0000 How long can nand go without power before it starts to lose data integrity? Thanks, Russ On Mon, Mar 21, 2016 at 8:48 PM, Warner Losh wrote: > >> On Mar 21, 2016, at 9:34 PM, bob prohaska wrote: >> >> On Mon, Mar 21, 2016 at 08:38:13PM -0600, Warner Losh wrote: >>> >>> One thing that people forget is that the underlying blocks that are written >>> are completely independent of what lba is used to write it. So the notion >>> that you have blocks normally part of /var or /tmp no longer makes sense. >>> Between writing blocks in different order and garbage collection, modern SD >>> cards do a good job of wear averaging. How much you've written to the drive >>> in total drives wear out these days. >>> >> >> How do modern flash devices report end of life? Do problems show up in error >> logs, or does the device simply refuse to work with no warning? > > Undefined. Either it goes read-only or read-never. :) > > Warner > From owner-freebsd-arm@freebsd.org Tue Mar 22 04:55:43 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 40C5AAD6DE7 for ; Tue, 22 Mar 2016 04:55:43 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0121EE5E for ; Tue, 22 Mar 2016 04:55:42 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x22e.google.com with SMTP id z68so5316582vkg.3 for ; Mon, 21 Mar 2016 21:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=pksZGFoHN0tNWQaNOt045BvGV9V3AxX2wnGdnDYJp9A=; b=yeV4+HEKQvP9MOjHoOQQ466VyiPIN3L2rneV1Dm5n7IuLh97DaL56Z5ILYNCfAEjYS qXM4qzAMBhn9YNrLocahuGjnPjKgxrjt2cIFNIxViQ8pvV0LuZ87/lB4BIkxbkl1f4q5 BpPjrzWzY6mxmQUDQ2XBLpzi1KHhJz/felzO4J9V+RdXtPgxFs7GB1XXgpQVovXHLVI1 3Bb3GdWrRn2OzDTvdF90yM6SwKPjOqU1eCIsZ1w8FqfrO6NnIioTcQc8D4zLZePLwCTp HXYQbbyeW+tBrm0Jgpjzl5IRKe8FVMC9kbi2meanxmfA3g4xv3i3oOCgOW7sPHXqfvXq Il5w== 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; bh=pksZGFoHN0tNWQaNOt045BvGV9V3AxX2wnGdnDYJp9A=; b=HD/moCJSKoSDA42B1bF1Kq/odSwVkPE6J8wQQELXznLMV3MShSg6uoTZjMnJedRaVm nrSjUqD7VbzK3C7W8wOI+5kbEwauLYknMSikOq5CUely0sFlbYVRKncxGoKsBsoISxtE Bt6k2VfrHMNUbqUcFIXy+0y92I6Tnta7zxmfhzAconubm0sQyx1SkzZ/N+HVNbpQUti0 2Yk6X/Z4pIweGBN0Qaw8gzeEaF3XPG6WHszPscnw+Mo55XuBF/C5QEv2lItD2RB0ZFj6 kuUmyO6dQYx9M1x9c/xM4r0yJQzXnAcDmFfYe3yzi9WrZ/lWr5q7XeveA0EsK1ob7rvN pTeQ== X-Gm-Message-State: AD7BkJJDg9Vwx/wAzl6tGP/pZ4BCYBDlCNbFgWpRj/B/3naS3FMn/yJH6q4DAU2fFar+tdp79hgy2X8EdXQE7A== MIME-Version: 1.0 X-Received: by 10.176.0.139 with SMTP id 11mr3114368uaj.36.1458622538998; Mon, 21 Mar 2016 21:55:38 -0700 (PDT) Received: by 10.31.54.13 with HTTP; Mon, 21 Mar 2016 21:55:38 -0700 (PDT) In-Reply-To: References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> Date: Mon, 21 Mar 2016 21:55:38 -0700 Message-ID: Subject: Fwd: Fwd: SDIO Patch D4761.diff Not Building For Me From: Russell Haley To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 04:55:43 -0000 Ilya, Adding "MODULES_OVERRIDE=" worked, thanks so much Ilya. I've got something early in the morning so it's going to have to wait until tomorrow night to get tested. :( make TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6MMC MODULES_OVERRIDE= -j20 buildkernel .... --- kernel.full --- linking kernel.full ctfmerge -L VERSION -g -o kernel.full ... text data bss dec hex filename 5852361 317316 1196032 7365709 0x70644d kernel.full --- kernel.debug --- objcopy --only-keep-debug kernel.full kernel.debug --- kernel --- objcopy --strip-debug --add-gnu-debuglink=kernel.debug kernel.full kernel -------------------------------------------------------------- >>> Kernel build for IMX6MMC completed on Tue Mar 22 04:50:12 UTC 2016 -------------------------------------------------------------- Thanks! Russ On Mon, Mar 21, 2016 at 10:17 AM, Russell Haley wrote: > Ilya, > > Sorry, I forgot that you had proper instructions (got lost in all the > emails I guess?). I'll try this again as soon as possible. > > Thanks, > > Russ > > On Sun, Mar 20, 2016 at 7:43 AM, Ilya Bakulin wrote: >> On 2016-03-18 20:06, Russell Haley wrote: >>> >>> Ilya, >>> >>> I have tried re-compiling with the "corrected" include file in >>> /sys/dev/mmc/mmc.c (#include ?) >>> >>> I can't include my build output because it's over 200kb in size and >>> Pastebin.com crashes all my browsers here at work. I will email it to >>> you separately. >>> >>> Thanks, >>> >>> Russ >> >> >> Please use IMX6MMC kernel config file, it has all necessary modifications. >> dev/mmc/mmc.c should not be built at all because it's the old MMC stack >> implementation. If it fails, try adding "MODULES_OVERRIDE=" when calling >> make, because we don't need any modules anyway. >> >> I have updated instructions on https://bakulin.de/freebsd/mmccam.html to >> include kernel config names. >> >> -- >> Ilya From owner-freebsd-arm@freebsd.org Tue Mar 22 05:33:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 230D1AD8628 for ; Tue, 22 Mar 2016 05:33:09 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 08EB1E29 for ; Tue, 22 Mar 2016 05:33:08 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 170E7406061; Mon, 21 Mar 2016 22:32:59 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Russell Haley cc: freebsd-arm , hmurray@megapathdsl.net From: Hal Murray Subject: Re: Effect of partitioning on wear-leveling In-Reply-To: Message from Russell Haley of "Mon, 21 Mar 2016 21:39:37 PDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Mar 2016 22:32:59 -0700 Message-Id: <20160322053259.170E7406061@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 05:33:09 -0000 > How long can nand go without power before it starts to lose data integrity? I just looked at a data sheet. It said "Data retention: 10 years". It didn't specify if that was powered or unpowered. That was from the marketing stuff on the front page rather than the details inside that I would trust. It probably depends on the temperature. That is probably a very conservative number. -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Tue Mar 22 06:14:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 987DCAD8D44 for ; Tue, 22 Mar 2016 06:14:46 +0000 (UTC) (envelope-from erich@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D6BB1C9; Tue, 22 Mar 2016 06:14:46 +0000 (UTC) (envelope-from erich@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=HimVlmjPvrleSI6SGldmxNRKRm5c78hQNrXbtLlElDc=; b=iZjP2HDVuXw1hgxfzaA4ev6jXd AL68W0G+WxyoRLBdhLhvECgwluF0FxI8q7REo+8B3wPUj9/h/nHGO5+k8+5sajsB3dgWUaxKU9sqP /kc5Wkm6Aa/+Q1UzIWEnlogpzQaRebg2oP/S9Zm6N1WajV/olf97MIvnjX/iDyJHNy68=; Received: from [114.124.32.239] (port=53232 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1aiFaR-003x8l-6p; Tue, 22 Mar 2016 00:14:40 -0600 Date: Tue, 22 Mar 2016 14:14:32 +0800 From: Erich Dollansky To: bob prohaska Cc: Ian Lepore , freebsd-arm@freebsd.org Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160322141432.3f0a3a61@X220.alogt.com> In-Reply-To: <20160321221153.GB83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> Organization: ALO Green Technologies 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: erich@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erich@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 06:14:46 -0000 Hi, On Mon, 21 Mar 2016 15:11:53 -0700 bob prohaska wrote: > On Mon, Mar 21, 2016 at 01:01:24PM -0600, Ian Lepore wrote: > > > > Freebsd does no wear-leveling, it's up to the microcontrollers > > within the storage devices to do that. > > > > Those controllers have no notion of partitioning or filesystem > > layout and do whatever they want to do internally about wear > > leveling. That leads to the mildly disturbing situation of having > > blocks from a readonly filesystem and blocks from a writable > > filesystem sharing the same flash erase-block inside the device. > > One likes to think of the data in a readonly filesystem as safely > > protected from the read-modify -write activity that happens at the > > flash erase-block level, but no such g'tee is made on any mmc, sd, > > or usb flash-based devices I know of. > > > > - Ian > > > Ok, thanks. It sounds like /var and /tmp could be confined to > limited-size partitions while still permitting wear leveling to use > other, less-used parts of the device. So, if a block nominally > in /var reaches end of life can the wear leveling controller start > stashing data anywhere on the device? > > As a practical matter, should I even be worrying about this? Folks > once made a big deal of partitioning storage so a runaway process > couldn't choke the whole machine. Is the precaution still worth > taking on ARM? > we use memory disk for /var and /tmp. If you really need the content of these directories, you could write them back to flash by a script every hour or so and save all the writes between. Do not forget the flash devices used in Raspberries & Co. cannot be compared with the flash devices used in flash disk. Erich From owner-freebsd-arm@freebsd.org Tue Mar 22 06:27:15 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 072A9AD801F for ; Tue, 22 Mar 2016 06:27:15 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8FE7AAEA; Tue, 22 Mar 2016 06:27:14 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u2M6QgO2044432 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Mar 2016 17:26:48 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u2M6Qa4w085351 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 17:26:36 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u2M6QZLh085350; Tue, 22 Mar 2016 17:26:35 +1100 (AEDT) (envelope-from peter) Date: Tue, 22 Mar 2016 17:26:35 +1100 From: Peter Jeremy To: Warner Losh Cc: bob prohaska , freebsd-arm@freebsd.org, Ian Lepore Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160322062635.GD64087@server.rulingia.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <20160322032832.GC83908@www.zefox.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig" Content-Disposition: inline In-Reply-To: X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Tue, 22 Mar 2016 17:26:48 +1100 (AEDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 06:27:15 -0000 --H+4ONPRPur6+Ovig Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Mar-21 21:47:39 -0600, Warner Losh wrote: >So let=E2=80=99s do the math. 512MB cards tended to have write speeds of m= aybe 6MB/s. >At 6MB/s, that=E2=80=99s about 518MB/day, or one drive write per day. Most= SD cards, I think you dropped some zeroes there. 6MB/s =3D=3D 518,400MB/day =3D=3D 5= 18GB/day. That's 1000 drive writes/day - which is non-trivial. --=20 Peter Jeremy --H+4ONPRPur6+Ovig Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJW8OWbXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0oewP/jETUqplvA7JwDb9AlK4zc5c VMN3Gym70pWp/scbtk1X0yyWryxtvSCH+R5RyNoJGEPfPD8+VFlVbRcTHfCzRL1E UImmQVqDytn/f2DGMMVOkdHXgy+5ADTZFigw6H51kp+5xmRaWm7KfyycGcxat00H 9qTHGoTfI3hp12YzWm0ym+fJ1NCqJsnKPpDleCu4saqAOMFcqdi5PPt1p+YOm5GN 0PhuuhkFISgTMaAHyTlQxWP2mRrjgPJlmgnwCAeTRtUHog+tqmLUN8mMbfZ0PzL8 Vu6R21wJ1/moil18c83PW1NotQry6emLA7eAaj9c3rDpqwJwXhLgY6MEfvFAFzm/ Sn3ziFPNJ+HsJHvdBVehUcrtBFLy0CyUbr1/zEuD+Y4y9GgG7GsYGgGW1XMDQEz0 rley36mUV+WxFrojvEzpnxsv5TU3Q3uhaNk+22z7YHXObTYgQoYWHBU45Cyu/DiC qoSaSxopwPoBsuLS9igY5kKk8cWxa4Mb+m2RjeqwXtx4AZfEw1hzCohE7q5/IRnk +Srfon80YxZOvPj1iqyP9+V2muW47/X1eJRatBwis/m5puHU+c2qRO+IG59biXbK u5Pcgq/yDXImc5fl5jPg1HKGsmYZscNrD0tzl59Bs3YMVTayRRDPjGGi0Hb4uott ICWObwKPhdbH5G3FjvvN =0hNm -----END PGP SIGNATURE----- --H+4ONPRPur6+Ovig-- From owner-freebsd-arm@freebsd.org Tue Mar 22 06:45:07 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CA5FAD84FB for ; Tue, 22 Mar 2016 06:45:07 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by mx1.freebsd.org (Postfix) with ESMTP id 275DA690 for ; Tue, 22 Mar 2016 06:45:06 +0000 (UTC) (envelope-from hmurray@megapathdsl.net) Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id C7FA9406061; Mon, 21 Mar 2016 23:45:02 -0700 (PDT) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: freebsd-arm@freebsd.org From: Hal Murray Subject: Re: Effect of partitioning on wear-leveling In-Reply-To: Message from Peter Jeremy of "Tue, 22 Mar 2016 17:26:35 +1100." <20160322062635.GD64087@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 21 Mar 2016 23:45:02 -0700 Message-Id: <20160322064502.C7FA9406061@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 06:45:07 -0000 > That's 1000 drive writes/day - which is non-trivial. Has anybody worked out the numbers for something like writing 100 bytes to a log file and flushing things? I think that turns into 2 page writes, one for the data and one for the directory info. This sort of hand waving assumes that wear leveling works well. -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Tue Mar 22 07:20:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2835AAD8AE6 for ; Tue, 22 Mar 2016 07:20:37 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9D77D681 for ; Tue, 22 Mar 2016 07:20:35 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u2M7KP0s044601 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 22 Mar 2016 18:20:31 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u2M7KJFE085661 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Mar 2016 18:20:19 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u2M7KIWo085660; Tue, 22 Mar 2016 18:20:18 +1100 (AEDT) (envelope-from peter) Date: Tue, 22 Mar 2016 18:20:18 +1100 From: Peter Jeremy To: Hal Murray Cc: freebsd-arm@freebsd.org Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160322072018.GF64087@server.rulingia.com> References: <20160322062635.GD64087@server.rulingia.com> <20160322064502.C7FA9406061@ip-64-139-1-69.sjc.megapath.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tMbDGjvJuJijemkf" Content-Disposition: inline In-Reply-To: <20160322064502.C7FA9406061@ip-64-139-1-69.sjc.megapath.net> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Tue, 22 Mar 2016 18:20:31 +1100 (AEDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 07:20:37 -0000 --tMbDGjvJuJijemkf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2016-Mar-21 23:45:02 -0700, Hal Murray wrote: >Has anybody worked out the numbers for something like writing 100 bytes to= a=20 >log file and flushing things? I think that turns into 2 page writes, one = for=20 >the data and one for the directory info. I assume you mean something like write(2) then fsync(2). If you're talking UFS, it's at least 2 synchronous writes (more if you need to grow the file across a block boundary). There's also an asynchronous update to the timestamp in the first superblock. ZFS is radically different and I'm not sure how many blocks wind up being written - but around 10 plus 4 per device in the pool seems likely. --=20 Peter Jeremy --tMbDGjvJuJijemkf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJW8PIyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs0yjMQAJMt2ucNxgwoyrFdX3u33gnc Q/bFqzHf9M9eyRyA9g0DL9mvVGwR5RxYCVL8/Q7Nfq3WZxevOto1hSO/P6JpxZ9/ FHDogMEPbpt468q93/oi4O5qs3YX0HkfBT3T1k2iArAmUxtSQHRa2qpQmy5w8dIU UsKDimX2TZFd+K5ACF29DYCiKafMQ/t36p0uIPTDOn/fp2WhDG+KCGRlK8UHGrRz Y4Shaq1nDFpvJ5CFX7sOCMAy3kCIh6CHzk/n84P9cadgrqJ4++q/55MraayQvzTH A4dE9n3CiOVqY+0e6qlw0+PQV1Nax+OQ5TNd9t+ZXPehuDCuIBlqj+vB+ji5Kw2y 479Xbk7aHws6I1Z/FZvSSr5j107qJ05LKdt7clmAKGRgEorwbgNJU1D7VfruuOPx MeeuXeSJOcDOcq0WGInvWghKQfzny+jT6sGERqyoukomMIQZaKushKC0uiHFfYFH GMpWHWDxefAR8loVkoPDl0z0wehsftRyDltRHZ45V8a6O725+ua2xYuCUmaNACcA o1s/wfma21T8rwBj/d28umYuQM3N+mF+aoazSBu60u+wm8WS/vM/r8oJhelDsYYg +xKiE4aLuqCn+jMwhq6BeoFvFJv0TaHBM9vLHojHE9MxRSis4Kpscw7UPmmjK+bg 5SWjF1fShsUzQKpRHqqs =CQ7v -----END PGP SIGNATURE----- --tMbDGjvJuJijemkf-- From owner-freebsd-arm@freebsd.org Tue Mar 22 07:22:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C6A3FAD8C79 for ; Tue, 22 Mar 2016 07:22:51 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7FF087F for ; Tue, 22 Mar 2016 07:22:51 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References: In-Reply-To:Message-ID:Subject:Cc:To:From:Date; bh=Xa1/+HwCZ8hzRC1Fu/PuDhu6a02hSvCgelYgB26SpJY=; b=p9GcdKDRJwyWbal/sJh3NDN1QA 2CrgIv+z7O5bijGeFVwhlcOccEAGyQlUiTQaogKooXKa2tdHxJd6jBXyYPn7m03vPF7Y/ixQYaxMF 2lhXgAF0OVIwXP6O5wZKuSE9hShMZ0PbzfPjBH2JkbS16Xt+1PZmJQSgemRRmow3Wdus=; Received: from [114.124.39.27] (port=39866 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1aiGeP-004MBs-PI; Tue, 22 Mar 2016 01:22:50 -0600 Date: Tue, 22 Mar 2016 15:22:45 +0800 From: Erich Dollansky To: Russell Haley Cc: Warner Losh , freebsd-arm Subject: Re: Effect of partitioning on wear-leveling Message-ID: <20160322152245.623de990@X220.alogt.com> In-Reply-To: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <271EF73A-077C-44A5-8B58-721405800B9F@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Authenticated-Sender: sl-508-2.slc.westdc.net: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 07:22:51 -0000 Hi, On Mon, 21 Mar 2016 21:39:37 -0700 Russell Haley wrote: > How long can nand go without power before it starts to lose data > integrity? as said, the manufacturers say 10 years. But those 10 years start with the writing of the data. As we do not know when the internal controller does the writing when moving data in the background, we only can assume a minimal 10 years since the purchase of the device. Erich From owner-freebsd-arm@freebsd.org Tue Mar 22 11:49:08 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8AAA7AD82F4 for ; Tue, 22 Mar 2016 11:49:08 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) Received: from mail-01.thismonkey.com (mail-01.thismonkey.com [220.244.217.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail-01.thismonkey.com", Issuer "Thismonkey IT Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E101D3DD for ; Tue, 22 Mar 2016 11:49:07 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) X-TM-Via-MX: mail-01.thismonkey.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thismonkey.com; s=mail-01; t=1458645921; bh=VPH/0U2gvpAHpGHO/dKuTLB5kslWe4LIjomsEntqf5k=; h=Date:From:To:Subject; b=hgs6jWPufdmLFhSXk62PAHWxu8cvacv6qc9/GvyLGdg2ibVAWolUpiMEojKZ7JQnk LGu8WrKGUnNnE0nY/Lqqz2niL/Zck6247OplVfqjZBrikci6IWWvR0++tLZF2QEJ6Y GAof5L+Z41SVsbgbCiyVKOZWBOeZCh6TSqX3G1Is= DMARC-Filter: OpenDMARC Filter v1.3.0 mail-01.thismonkey.com u2MBPLY0097254 Authentication-Results: mail-01/u2MBPLY0097254; dmarc=none header.from=thismonkey.com Authentication-Results: mail-01; spf=pass smtp.mailfrom=freebsd-lists-5@thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [10.1.1.32]) by mail-01.thismonkey.com (8.14.9/8.14.9) with ESMTP id u2MBPLY0097254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 22 Mar 2016 22:25:21 +1100 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.14.9/8.14.9) with ESMTP id u2MBPLhQ053175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 22 Mar 2016 22:25:21 +1100 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.14.9/8.14.9/Submit) id u2MBPL4L053173 for freebsd-arm@freebsd.org; Tue, 22 Mar 2016 22:25:21 +1100 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Date: Tue, 22 Mar 2016 22:25:21 +1100 From: Scott To: freebsd-arm@freebsd.org Subject: net-mgmt/cdpd failing on RPi Message-ID: <20160322112520.GA51636@thismonkey.com> Mail-Followup-To: freebsd-arm@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Greylist: inspected by milter-greylist-4.5.11 (mail-01.thismonkey.com [10.1.2.50]); Tue, 22 Mar 2016 22:25:21 +1100 (EST) for IP:'10.1.1.32' DOMAIN:'utility-01.thismonkey.com' HELO:'utility-01.thismonkey.com' FROM:'freebsd-lists-5@thismonkey.com' RCPT:'' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.11 (mail-01.thismonkey.com [10.1.2.50]); Tue, 22 Mar 2016 22:25:21 +1100 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 11:49:08 -0000 Hi all, I've compiled net-mgmt/cdpd (cdpd-1.0.4.1) on the system: FreeBSD network-01.thismonkey.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r287930: Fri Sep 18 04:03:40 UTC 2015 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm and when I run it it simply genereates its help message and exits. On a differnet system it forks and works fine: FreeBSD nas-01.thismonkey.com 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16 22:34:59 UTC 2014 root@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 Here is a truss on the failing RPi: (failing rpi)# truss cdpd -i ue0 mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0xa5a5a5a500000015) = 537108480 (0x2003a000) issetugid() = 0 (0x0) lstat("/etc",{ mode=drwxr-xr-x ,inode=31234,size=2560,blksize=32768 }) = 0 (0x0) lstat("/etc/libmap.conf",{ mode=-rw-r--r-- ,inode=34379,size=102,blksize=32768 }) = 0 (0x0) openat(AT_FDCWD,"/etc/libmap.conf",O_CLOEXEC,00) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=34379,size=102,blksize=32768 }) = 0 (0x0) mmap(0x0,102,PROT_READ,MAP_PRIVATE,80,0xa5a5a5a50000864b) = 537071616 (0x20031000) close(3) = 0 (0x0) lstat("/usr",{ mode=drwxr-xr-x ,inode=62474,size=512,blksize=32768 }) = 0 (0x0) lstat("/usr/local",{ mode=drwxr-xr-x ,inode=62585,size=512,blksize=32768 }) = 0 (0x0) lstat("/usr/local/etc",{ mode=drwxr-xr-x ,inode=125718,size=1024,blksize=32768 }) = 0 (0x0) lstat("/usr/local/etc/libmap.d",{ mode=drwxr-xr-x ,inode=187430,size=512,blksize=32768 }) = 0 (0x0) open("/usr/local/etc/libmap.d",O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0145) = 3 (0x3) __sysctl(0xbfbfe678,0x2,0x20039774,0xbfbfe674,0x200389dc,0x6) = 0 (0x0) fstatfs(0x3,0xbfbfe698,0x20039774,0xbfbfe674,0x0,0x0) = 0 (0x0) munmap(0x20041000,4096) = 0 (0x0) mmap(0x0,40960,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0xa5a5a5a500001000) = 537137152 (0x20041000) getdirentries(0x3,0x20042000,0x1000,0x20040014,0x20040000,0xbfbfe8e6) = 24 (0x18) getdirentries(0x3,0x20042000,0x1000,0x20040014,0x20040000,0xbfbfe8e6) = 0 (0x0) close(3) = 0 (0x0) munmap(0x20031000,102) = 0 (0x0) openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_CLOEXEC,00) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0B\0\0\0\0"...,128) = 128 (0x80) lseek(3,0x8000000000,SEEK_SET) = 128 (0x80) read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,66) = 66 (0x42) close(3) = 0 (0x0) access("/lib/libpcap.so.8",F_OK) = 0 (0x0) openat(AT_FDCWD,"/lib/libpcap.so.8",O_CLOEXEC|O_VERIFY,00) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=94166,size=296288,blksize=32768 }) = 0 (0x0) mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077940496,0xa5a5a5a520023c24) = 537071616 (0x20031000) mmap(0x0,331776,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,537071700,0xa5a5a5a520031074) = 537178112 (0x2004b000) mmap(0x2004b000,294912,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537071700,0xa5a5a5a520031074) = 537178112 (0x2004b000) mmap(0x2009a000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537071700,0xa5a5a5a520031074) = 537501696 (0x2009a000) mmap(0x2009b000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537071700,0xa5a5a5a520031074) = 537505792 (0x2009b000) munmap(0x20031000,4096) = 0 (0x0) close(3) = 0 (0x0) access("/lib/libc.so.7",F_OK) = 0 (0x0) openat(AT_FDCWD,"/lib/libc.so.7",O_CLOEXEC|O_VERIFY,00) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=94031,size=1561128,blksize=32768 }) = 0 (0x0) mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077940496,0xa5a5a5a520023c24) = 537071616 (0x20031000) mmap(0x0,1630208,PROT_NONE,MAP_ALIGNED_SUPER|MAP_PRIVATE|MAP_ANON|MAP_NOCORE,537071700,0xa5a5a5a520031074) = 537919488 (0x20100000) mmap(0x20100000,1474560,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537071700,0xa5a5a5a520031074) = 537919488 (0x20100000) mmap(0x2026f000,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537071700,0xa5a5a5a520031074) = 539422720 (0x2026f000) mmap(0x20277000,94208,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537071700,0xa5a5a5a520031074) = 539455488 (0x20277000) munmap(0x20031000,4096) = 0 (0x0) close(3) = 0 (0x0) munmap(0x20046000,20480) = 0 (0x0) mmap(0x0,69632,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0xa5a5a5a500008000) = 537509888 (0x2009c000) sysarch(0x2,0x20045200) = 0 (0x0) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) __sysctl(0xbfbff148,0x2,0x2028c908,0xbfbff144,0x6,0xa) = 0 (0x0) readlink("/etc/malloc.conf",0xbfbfed1f,1024) ERR#2 'No such file or directory' issetugid() = 0 (0x0) break(0x159b0) = 0 (0x0) mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,664,0xa5a5a5a5bfbfed1f) = 539549696 (0x2028e000) munmap(0x2028e000,2097152) = 0 (0x0) mmap(0x0,4190208,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1077941608,0xa5a5a5a520196d88) = 539549696 (0x2028e000) munmap(0x2028e000,1515520) = 0 (0x0) munmap(0x20600000,577536) = 0 (0x0) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) mmap(0x0,2097152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1077940136,0xa5a5a5a5201091d4) = 543162368 (0x20600000) openat(AT_FDCWD,"/dev/bpf",O_RDWR,00) = 3 (0x3) ioctl(3,BIOCVERSION,0xbfbff234) = 0 (0x0) __sysctl(0xbfbfeca4,0x2,0xbfbfed0c,0xbfbfeca0,0x100,0x206161f0) = 0 (0x0) __sysctl(0xbfbfeca4,0x2,0xbfbfee0c,0xbfbfeca0,0x100,0x0) = 0 (0x0) __sysctl(0xbfbfeca4,0x2,0xbfbfef0c,0xbfbfeca0,0x100,0xbfbfef0c) = 0 (0x0) __sysctl(0xbfbfeca4,0x2,0xbfbff00c,0xbfbfeca0,0x100,0xbfbff00c) = 0 (0x0) __sysctl(0xbfbfeca4,0x2,0xbfbff10c,0xbfbfeca0,0x0,0xbfbff10c) = 0 (0x0) ioctl(3,BIOCSETBUFMODE,0xbfbfecfc) ERR#22 'Invalid argument' ioctl(3,BIOCGBLEN,0xbfbff21c) = 0 (0x0) ioctl(3,BIOCSBLEN,0xbfbff21c) = 0 (0x0) ioctl(3,BIOCSETIF,0xbfbff238) = 0 (0x0) ioctl(3,BIOCGDLT,0xbfbff21c) = 0 (0x0) ioctl(3,BIOCGDLTLIST,0xbfbff228) = 0 (0x0) ioctl(3,BIOCGDLTLIST,0xbfbff228) = 0 (0x0) ioctl(3,BIOCSHDRCMPLT,0xbfbff220) = 0 (0x0) ioctl(3,BIOCGBLEN,0xbfbff21c) = 0 (0x0) ioctl(3,BIOCSETF,0xbfbff20c) = 0 (0x0) fstat(1,{ mode=crw--w---- ,inode=78,size=0,blksize=4096 }) = 0 (0x0) ioctl(1,TIOCGETA,0xbfbfef74) = 0 (0x0) Usage: cdpd [-i iface] [-t time] [-dhor] [-c|-l] write(1,"Usage: cdpd [-i iface] [-t time]"...,49) = 49 (0x31) -a : send announces on all ethernet interfaces with IP addresses configured write(1,"-a : send announces on all "...,81) = 81 (0x51) -c : do NOT send CDP packets (enabled by default) write(1,"-c : do NOT send CDP packet"...,55) = 55 (0x37) -d : increase debug level and do not daemonise write(1,"-d : increase debug level a"...,52) = 52 (0x34) -i name : interface to send cdp packets on (only ethernet ones supported) write(1,"-i name : interface to send cdp "...,74) = 74 (0x4a) -h : this help message write(1,"-h : this help message\n",28) = 28 (0x1c) -o : run once - send only one packet over each interface and exit write(1,"-o : run once - send only o"...,71) = 71 (0x47) -l : do NOT send LLDP packets (enabled by default) write(1,"-l : do NOT send LLDP packe"...,56) = 56 (0x38) -r : announce host as a Router-capable device (Station by default) write(1,"-r : announce host as a Rou"...,72) = 72 (0x48) -t time : period between announces (60 sec by default) write(1,"-t time : period between announc"...,55) = 55 (0x37) write(1,"\n",1) = 1 (0x1) Copyright (c) 2001-2008, Alexandre Snarskii write(1,"Copyright (c) 2001-2008, Alexand"...,44) = 44 (0x2c) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,{ SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2 },{ }) = 0 (0x0) sigprocmask(SIG_SETMASK,{ },0x0) = 0 (0x0) process exit, rval = 1 (working amb64)# truss cdpd -i bge0 mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366156800 (0x80061f000) issetugid(0x80081ef30,0x7fffffffefcb,0x40,0x0,0xffff80080081ff65,0x0) = 0 (0x0) lstat("/etc",{ mode=drwxr-xr-x ,inode=2487936,size=2560,blksize=32768 }) = 0 (0x0) lstat("/etc/libmap.conf",{ mode=-rw-r--r-- ,inode=2488017,size=112,blksize=32768 }) = 0 (0x0) open("/etc/libmap.conf",O_CLOEXEC,01760) = 3 (0x3) fstat(3,{ mode=-rw-r--r-- ,inode=2488017,size=112,blksize=32768 }) = 0 (0x0) mmap(0x0,112,PROT_READ,MAP_PRIVATE,3,0x0) = 34366189568 (0x800627000) close(3) = 0 (0x0) lstat("/usr",{ mode=drwxr-xr-x ,inode=160512,size=512,blksize=32768 }) = 0 (0x0) lstat("/usr/local",{ mode=drwxr-xr-x ,inode=160523,size=512,blksize=32768 }) = 0 (0x0) lstat("/usr/local/etc",{ mode=drwxr-xr-x ,inode=264040,size=2048,blksize=32768 }) = 0 (0x0) lstat("/usr/local/etc/libmap.d",{ mode=drwxr-xr-x ,inode=645449,size=512,blksize=32768 }) = 0 (0x0) open("/usr/local/etc/libmap.d",O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0165) = 3 (0x3) __sysctl(0x7fffffffc058,0x2,0x80081fb5c,0x7fffffffc050,0x0,0x0) = 0 (0x0) fstatfs(0x3,0x7fffffffc098,0x80081fb5c,0x7fffffffc050,0x0,0x0) = 0 (0x0) mmap(0x0,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366193664 (0x800628000) getdirentries(0x3,0x800625000,0x1000,0x800624028,0x0,0x0) = 24 (0x18) getdirentries(0x3,0x800625000,0x1000,0x800624028,0x18,0x0) = 0 (0x0) close(3) = 0 (0x0) munmap(0x800627000,112) = 0 (0x0) open("/var/run/ld-elf.so.hints",O_CLOEXEC,00) = 3 (0x3) read(3,"Ehnt\^A\0\0\0\M^@\0\0\0B\0\0\0\0"...,128) = 128 (0x80) lseek(3,0x80,SEEK_SET) = 128 (0x80) read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,66) = 66 (0x42) close(3) = 0 (0x0) access("/lib/libpcap.so.8",0) = 0 (0x0) open("/lib/libpcap.so.8",O_CLOEXEC,030517770) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=240788,size=266448,blksize=32768 }) = 0 (0x0) mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34366189568 (0x800627000) mmap(0x0,2367488,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34368258048 (0x800820000) mmap(0x800820000,258048,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0) = 34368258048 (0x800820000) mmap(0x800a5f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x3f000) = 34370613248 (0x800a5f000) mmap(0x800a61000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34370621440 (0x800a61000) munmap(0x800627000,4096) = 0 (0x0) close(3) = 0 (0x0) access("/lib/libc.so.7",0) = 0 (0x0) open("/lib/libc.so.7",O_CLOEXEC,030517770) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=240781,size=1567216,blksize=32768 }) = 0 (0x0) mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,3,0x0) = 34366189568 (0x800627000) mmap(0x0,3772416,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 34370625536 (0x800a62000) mmap(0x800a62000,1458176,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,3,0x0) = 34370625536 (0x800a62000) mmap(0x800dc6000,49152,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,3,0x164000) = 34374180864 (0x800dc6000) mmap(0x800dd2000,167936,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0) = 34374230016 (0x800dd2000) munmap(0x800627000,4096) = 0 (0x0) close(3) = 0 (0x0) munmap(0x80062b000,24576) = 0 (0x0) mmap(0x0,102400,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34366205952 (0x80062b000) sysarch(0x81,0x7fffffffd008,0x4,0x0,0xffffffffff877080,0xf0000000) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) readlink("/etc/malloc.conf",0x7fffffffc730,1024) ERR#2 'No such file or directory' issetugid(0x800b9d93e,0x7fffffffc730,0xffffffffffffffff,0x0,0x3b,0xffffffff0fffffff) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34374397952 (0x800dfb000) munmap(0x800dfb000,4194304) = 0 (0x0) mmap(0x0,8384512,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34374397952 (0x800dfb000) munmap(0x800dfb000,2117632) = 0 (0x0) munmap(0x801400000,2072576) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) mmap(0x0,4194304,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 34380709888 (0x801400000) open("/dev/bpf",O_RDWR,041115760) = 3 (0x3) ioctl(3,BIOCVERSION,0xffffcfd8) = 0 (0x0) __sysctl(0x7fffffffca20,0x2,0x7fffffffca98,0x7fffffffca18,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffca20,0x2,0x7fffffffcb98,0x7fffffffca18,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffca20,0x2,0x7fffffffcc98,0x7fffffffca18,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffca20,0x2,0x7fffffffcd98,0x7fffffffca18,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffca20,0x2,0x7fffffffce98,0x7fffffffca18,0x0,0x0) = 0 (0x0) ioctl(3,BIOCSETBUFMODE,0xffffca7c) ERR#22 'Invalid argument' ioctl(3,BIOCGBLEN,0xffffcfb4) = 0 (0x0) ioctl(3,BIOCSBLEN,0xffffcfb4) = 0 (0x0) ioctl(3,BIOCSETIF,0xffffcfe0) = 0 (0x0) ioctl(3,BIOCGDLT,0xffffcfb4) = 0 (0x0) ioctl(3,BIOCGDLTLIST,0xffffcfc0) = 0 (0x0) ioctl(3,BIOCGDLTLIST,0xffffcfc0) = 0 (0x0) ioctl(3,BIOCSHDRCMPLT,0xffffcfb8) = 0 (0x0) ioctl(3,BIOCGBLEN,0xffffcfb4) = 0 (0x0) ioctl(3,BIOCSETF,0xffffcf98) = 0 (0x0) __sysctl(0x7fffffffd0e0,0x2,0x606620,0x7fffffffd0d8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd0e0,0x2,0x606720,0x7fffffffd0d8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd0e0,0x2,0x606820,0x7fffffffd0d8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd0e0,0x2,0x606920,0x7fffffffd0d8,0x0,0x0) = 0 (0x0) __sysctl(0x7fffffffd0e0,0x2,0x606a20,0x7fffffffd0d8,0x0,0x0) = 0 (0x0) sigaction(SIGHUP,{ SIG_IGN 0x0 ss_t },{ SIG_DFL 0x0 ss_t }) = 0 (0x0) fork() = 17553 (0x4491) process exit, rval = 0 Thanks in advance for any help, Scott From owner-freebsd-arm@freebsd.org Tue Mar 22 12:12:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8898BAD73F5 for ; Tue, 22 Mar 2016 12:12:16 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 535DA1A4B for ; Tue, 22 Mar 2016 12:12:16 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-io0-x22c.google.com with SMTP id 124so88920423iov.3 for ; Tue, 22 Mar 2016 05:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=t3ZGL4FoaDMpTNkd7iOfCbhDOGt65nQxgInffKw0488=; b=S6KZkEz3K6nXmoIP6LxGHtIK4sxLAOcXePnw0VYXoOOnwa2gSlOEn+c72L1ZrOedIc q1enORvIQXBIsvtV+0EPpxNh2zubOg7NegA+c12SYkYe8gxpvec7CLSGOVIBya1q+Kzh uwzYTLE8n65WGruvcdU0Iz9XJq1+Qo7S7baEWAX86rrkTIcvhyIU/S3P8Gc6p0hJR/8J ayfnJ9VTaZbU7FlOI9QFNeRONQAFZRNnh1HvU0I3Yzj71SHuwj3f0bYNcLb1gJXUfkgO LWmfTfmo43aJEpwmCg9rLJPdcOTXnpndNPTnQYQ7BfiyL72qvBzKxWRl+feY/p7KpAmx 72bw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=t3ZGL4FoaDMpTNkd7iOfCbhDOGt65nQxgInffKw0488=; b=IegguinANoG5v+Qbx5MeSiOhaPovJ2QyMc+Yb2TGZPhMF8RbQg605+KBRzR6ySlIdV V6wQYVW96ab0cJZyBScXB+WQUlrYSM2OqWsWtahwy5g5vV9QbRNOFhuYuxZG3gAU3L3G G2BaANtfKEp0jzlS/IDeeo3McywZKpGWTMTSx6V2tDDwknVusuxz1xG1XQRbnxtdzrrJ 6QbLhPfnVKoFvlrKDfJ8/hwlTW8mZbTkWk0Kefmj/s5Hv0InPRxrPhpCPGjLs1o5MK1j q66Ww8COsyXRwg4BifIgGVI+p3wIGHnB1gwDA0vVEc+zPTy5kQ8czeSDX/ZoXVKnMGgT 4jDg== X-Gm-Message-State: AD7BkJJNNH4PMNnLvqgQPusWO2nVd7GxaBPR4079agsQit3rKYD6d1Wiv0Ua742mOn8f1aSuuSCZCYilpo6Z9w== X-Received: by 10.107.156.76 with SMTP id f73mr2178699ioe.196.1458648735681; Tue, 22 Mar 2016 05:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.38.73 with HTTP; Tue, 22 Mar 2016 05:11:46 -0700 (PDT) In-Reply-To: <20160322062635.GD64087@server.rulingia.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <20160322032832.GC83908@www.zefox.net> <20160322062635.GD64087@server.rulingia.com> From: Jia-Shiun Li Date: Tue, 22 Mar 2016 20:11:46 +0800 Message-ID: Subject: Re: Effect of partitioning on wear-leveling 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.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 12:12:16 -0000 On Tue, Mar 22, 2016 at 2:26 PM, Peter Jeremy wrote: > On 2016-Mar-21 21:47:39 -0600, Warner Losh wrote: > >So let=E2=80=99s do the math. 512MB cards tended to have write speeds of= maybe > 6MB/s. > >At 6MB/s, that=E2=80=99s about 518MB/day, or one drive write per day. Mo= st SD > cards, > > I think you dropped some zeroes there. 6MB/s =3D=3D 518,400MB/day =3D=3D > 518GB/day. > That's 1000 drive writes/day - which is non-trivial. > > btw at the days of 512MB cards they are mostly made of SLC nand flash, some were beginning to transition to MLC. They are different from TLC these days in terms of endurance. From owner-freebsd-arm@freebsd.org Tue Mar 22 12:34:28 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36ACAAD7CD3 for ; Tue, 22 Mar 2016 12:34:28 +0000 (UTC) (envelope-from wma@semihalf.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 198A06D2 for ; Tue, 22 Mar 2016 12:34:28 +0000 (UTC) (envelope-from wma@semihalf.com) Received: by mailman.ysv.freebsd.org (Postfix) id 18D1BAD7CD2; Tue, 22 Mar 2016 12:34:28 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 18667AD7CD1 for ; Tue, 22 Mar 2016 12:34:28 +0000 (UTC) (envelope-from wma@semihalf.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D238E6D0 for ; Tue, 22 Mar 2016 12:34:27 +0000 (UTC) (envelope-from wma@semihalf.com) Received: by mail-vk0-x236.google.com with SMTP id z68so16917693vkg.3 for ; Tue, 22 Mar 2016 05:34:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=qAObfuHb7D96dwcd6GWBaZMjm0iq0ViS2WOHElNnZUo=; b=UfuXoksfxXH5svD/R9LuS8G2Pu0q/3+d13XE6WTEWYC1TkXuITHgv15PYS4R/I0Uln msvbEnh7ZWDAwx4yCDq9qjSaj99/heDZbWDFSkxCJuCaOQnNrjUgN39NkshB7hLJPYZp j7c+PXZGYq++HZYz3DaHK3vZVmSnydkW2Q6ODSFMK0NcrHXLMouR9P2BkSbtHsKQCDkc AFmz9ZXFuP8nQoFt+ddPdZtOlPqmA/KdZ6cOb0jkr+J+q0ypJ5jNgrW8/wDGoO3M1vh3 FyfsYDOeDBnftaRxAafVYn7R/XT/Y976p4xR1KSyeAEGfd4pQRTe7GNBVK7sU1ApSLZQ 6z5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qAObfuHb7D96dwcd6GWBaZMjm0iq0ViS2WOHElNnZUo=; b=W4LJlNiXCmT1I5iI79sgvbTxdwL1dF79nw4dYBn0zxzixW3VlulMAZ4EarSQw6RjQA 2qlIq01+u4zfuLVHJo0QY2ZwLp6SmGK47wU7bAoYy80Xx9PJ3LM4zkwOlhEEspcg5lww 7skciVRgGzkN1tFLwmmxtQBDANKjAkW89SWa3OFgVimbRY5VxsdYtlh8UDLsdL3lbOwi Xe/UKGzJ5Dk/hQ5eqRIvn05e3DIz/QsKDs015cGQO7U1uRZON4996PG+bdLU+S/r/AdA D80RAf8m8O71wgpQRiL7J1RrZvFR8gOe2sV3pctt8QlVAzrG0fAShwAZVOhrDwuPskFw 496Q== X-Gm-Message-State: AD7BkJJvM/NBz4IyW6AL4lvcWV2od8U16sj8U4WjJp0tqgVBesUywtRIxSVmPS3+iKTN+X6GEba+KiILwb+N8w== X-Received: by 10.31.134.71 with SMTP id i68mr473145vkd.46.1458650066963; Tue, 22 Mar 2016 05:34:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.112.71 with HTTP; Tue, 22 Mar 2016 05:34:07 -0700 (PDT) From: Wojciech Macek Date: Tue, 22 Mar 2016 13:34:07 +0100 Message-ID: Subject: ARM64 buildworld failure on ThunderX To: Ed Maste , arm@freebsd.org, arm64-dev Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 12:34:28 -0000 Hello, I was debugging strange userspace crashes during native aarch64 buildworld, and I think that it is highly probable that they are caused by issues with recent toolchain or system libraries. The same test as below, but run on older sources (the one with clang-3.6) is just fine, build succeeds and soelim does not crash. I'd like to get some feedback if anyone do or did see similar behavior or how this might be pushed forward. I can provide binaries, logs and whatever is necessary. The application that fails is a soelim (in about 95% of all cases): --- be_BY.CP1131.LC_CTYPE --- --- all_subdir_share/doc --- --- all_subdir_share/doc/usd --- groff: soelim: Signal 11 (core dumped) --- all_subdir_share/i18n --- sed "s/CPx/CP10007/" /root/freebsd-arm64/share/i18n/esdb/CP/CP.src > CP10007.src --- all_subdir_share/i18n/csmapper --- --- UCS%CP950.mps --- --- all_subdir_share/ctypedef --- When I try to manually call the application, it coredumps too. root@thunder_crb4:~/freebsd-arm64 # find /usr/obj/ -name soelim /usr/obj/root/freebsd-arm64/tmp/usr/lib/debug/usr/tests/usr.bin/soelim /usr/obj/root/freebsd-arm64/tmp/usr/tests/usr.bin/soelim /usr/obj/root/freebsd-arm64/tmp/legacy/usr/bin/soelim /usr/obj/root/freebsd-arm64/tmp/root/freebsd-arm64/usr.bin/soelim /usr/obj/root/freebsd-arm64/tmp/root/freebsd-arm64/usr.bin/soelim/soelim /usr/obj/root/freebsd-arm64/usr.bin/soelim root@thunder_crb4:~/freebsd-arm64 # /usr/obj/root/freebsd-arm64/tmp/root/freebsd-arm64/usr.bin/soelim/soelim Segmentation fault (core dumped) root@thunder_crb4:~/freebsd-arm64 # Steps to reproduce: 1. Clone the FreeBSD HEAD 2. Call "make buildworld -j48 -DNO_CLEAN" 3. Relax and wait for the crash to happen... Regards, wma From owner-freebsd-arm@freebsd.org Tue Mar 22 15:42:17 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4EDDDAD8DB1 for ; Tue, 22 Mar 2016 15:42:17 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 1461E69A for ; Tue, 22 Mar 2016 15:42:16 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9d8706a8-f044-11e5-827e-7d17a39bef25 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 22 Mar 2016 15:41:59 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2MFgAJD011759; Tue, 22 Mar 2016 09:42:11 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458661330.1091.11.camel@freebsd.org> Subject: Re: Effect of partitioning on wear-leveling From: Ian Lepore To: Peter Jeremy , Warner Losh Cc: freebsd-arm@freebsd.org Date: Tue, 22 Mar 2016 09:42:10 -0600 In-Reply-To: <20160322062635.GD64087@server.rulingia.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <20160322032832.GC83908@www.zefox.net> <20160322062635.GD64087@server.rulingia.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 15:42:17 -0000 On Tue, 2016-03-22 at 17:26 +1100, Peter Jeremy wrote: > On 2016-Mar-21 21:47:39 -0600, Warner Losh wrote: > > So lets do the math. 512MB cards tended to have write speeds of > > maybe 6MB/s. > > At 6MB/s, thats about 518MB/day, or one drive write per day. Most > > SD cards, > > I think you dropped some zeroes there. 6MB/s == 518,400MB/day == > 518GB/day. > That's 1000 drive writes/day - which is non-trivial. > Because the hardware I was using was old and buggy (byte-swapping all data in software, etc), the actual IO rate was just under 1MB/sec, but that's still closer to the kind of numbers you mention than to Warner's. -- Ian From owner-freebsd-arm@freebsd.org Tue Mar 22 18:46:11 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B2EDAD922F for ; Tue, 22 Mar 2016 18:46:11 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C229115B9 for ; Tue, 22 Mar 2016 18:46:10 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by mail-yw0-x230.google.com with SMTP id h65so123292813ywe.0 for ; Tue, 22 Mar 2016 11:46: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:from:date:message-id:subject:to; bh=wE1oBGrP2mK3ajRvwn7mdU6ITX5Ari6RN+gED6HMOYE=; b=V1LXMdvSJ+RAAPzOJ0zSpoHhuwGmmXykUrrAxyjkKDslhWf34G9xTU+uNuXMk3/DLT TrM3Lt430x/v/PQdS5ZXbzdFMpk5Z+k9AQdfGUKwjdIsbkwJ+2J8h5nGxkXB6ATlrMa7 pjeZo9kwbTPRYc1YLneNwmLf4xaTkfrjjw9roG7MPlw1EdpQoAn9KdBUjhom6SLl644E OOzx8qxek+bAn/YDouMhAsCHfHJ3IVhDhnNCzUZrigBvXJS6wRflq/dePW6Qz/yjPjyv N1kc8akg78qWIM1sUWA6GPxBArBj1Y5sMbXqDffDhw6XO1rvIyEZ6EOFIxxbQtuPG6Tn d1NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=wE1oBGrP2mK3ajRvwn7mdU6ITX5Ari6RN+gED6HMOYE=; b=cdIyxtbknY5/kMjC/rchGzrYqX2xB9a8zUdJeX7Prk5TuuqtwhUZnG0Dmz2FxaRJxp RhwhpuWb9pL1U4N2w7UA/I987jgO62QOxa9j6tDjnL7LYcQzhtAjczcMWK5Iq5MPIrfY +S+oVY3RlMdeuYz2wUsYpPAvR+DlINHnHCiNzGPHvA/1lAZ7AINyYHV1I/+Z2YUodOrR DX/7CvKh+qUb5YzcGzKIE4KDh6n7V1/wkU9K2FSNktdZORyqyM/UALxvOIgGby5gEt2q KsqdQzJUL2OfzzjUnZERJNf6zBgiRzFBT5/1cWcZP5uSrpilsgV9Pe6zxIdfkpnHpiwk eyYg== X-Gm-Message-State: AD7BkJIZd7KIuymBasNiObsfX8bRkuDy3LDOItIbMzl0c6Z3wd3zCX6i2v0m+7Yc8y+QvFPQ04jJjEpbLvEpaQ== X-Received: by 10.129.159.196 with SMTP id w187mr19501131ywg.225.1458672369974; Tue, 22 Mar 2016 11:46:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.36.198 with HTTP; Tue, 22 Mar 2016 11:45:30 -0700 (PDT) In-Reply-To: <20160322112520.GA51636@thismonkey.com> References: <20160322112520.GA51636@thismonkey.com> From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= Date: Tue, 22 Mar 2016 19:45:30 +0100 Message-ID: Subject: Re: net-mgmt/cdpd failing on RPi To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2016 18:46:11 -0000 2016-03-22 12:25 GMT+01:00 Scott : > Hi all, > > I've compiled net-mgmt/cdpd (cdpd-1.0.4.1) on the system: > FreeBSD network-01.thismonkey.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 > r287930: Fri Sep 18 04:03:40 UTC 2015 > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm > > and when I run it it simply genereates its help message and exits. Hi, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208216 From owner-freebsd-arm@freebsd.org Wed Mar 23 01:24:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D8A3A92624 for ; Wed, 23 Mar 2016 01:24:22 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1676C18DC for ; Wed, 23 Mar 2016 01:24:21 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2N1OD3L088184; Tue, 22 Mar 2016 18:24:14 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2N1ODfd088183; Tue, 22 Mar 2016 18:24:13 -0700 (PDT) (envelope-from fbsd) Date: Tue, 22 Mar 2016 18:24:13 -0700 From: bob prohaska To: freebsd-arm@freebsd.org Subject: Using one RPI2 as a serial terminal for a second RPI2 Message-ID: <20160323012413.GA86944@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 01:24:22 -0000 Is there a way to operate an RPI2 single user with the HDMI monitor and a USB keyboard? Is it practical to cross-connect the UART pins and use cu on one RPI2 to communicate with a second? If not, is there a USB-to-3.3v UART adapter which uses existing FreeBSD drivers? Amazon.com is full of cables, but most speak only of Windows and Mac OS X. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Wed Mar 23 01:44:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3AEBDA92B6C for ; Wed, 23 Mar 2016 01:44:29 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E571C13C2 for ; Wed, 23 Mar 2016 01:44:28 +0000 (UTC) (envelope-from kabaev@gmail.com) Received: by mail-qg0-x230.google.com with SMTP id w104so1330483qge.1 for ; Tue, 22 Mar 2016 18:44:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version; bh=Kvungz4drzQ/Oylx2/7BG4JRH/288WjHOptlrxAHXyM=; b=yvv07GIGVnxXY6IkQloc3ofBk8GZzc9FzP49qSExpq8yUQqY+wnl0PLH7Jhl4KCVGo AO7gimxsx79a6WQwd6mpZm3T6qp0i9rOVriNIdkAQyLLUtttvZ8JO06y8CQfjqe/me4v 3qaOiBu7fPZbifGDnS9GBALfaGaHhjVIQnsGkSutR9GGH9LecQbnKTB8IiQs5x3+qYkq MHCzrF8tOHYDNS2cLN+BhUQ/0/8nLmPQh9JDeY0gtJfC10ClHvtYwpAkDPRR20SJrYm9 l/KLGAs6pVpse9y4QHmnCjwLAk4raul2n9AXlTHCioZVxeto0n/oGtL7uBHWF6oBptZh /Lww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version; bh=Kvungz4drzQ/Oylx2/7BG4JRH/288WjHOptlrxAHXyM=; b=fWGHfVK34ZilnbYQoL0e5X8Ce4Q6LJZ/35DHCdgCgFUNK151C00TLIE1Z69jD9OBZe P5YUXGpgedqa+qGtABeS5YWB9lCsZXuWt2bDvWFQkao2E7J1SniP65UMs8DNQ721Ulht wDj9ohY/unL2BcD5KAWfOVXyUUaniWB+fUXP1LGnFOYZkmIMzPmmhsMPrlEKCRVfiMO/ dWJpArUxrqQOCIqEGorehDFHNBM2Nci3Q9bm9Pj7cJoEnfekP9WVTnFwk4LJ/VJh/q1S r+sqwT1siFXFS34O+qCM7+h8jbM5MXlqK1OLTkcfxBBiQKLk9XipjRzLPYQXjh6u7QR5 EBGw== X-Gm-Message-State: AD7BkJJhvLd8jNVfWTfQ9o/a67X6D3J2PHVovX3PhCJZ1ai6loMDr8TcpOOx8hP4aBMWmg== X-Received: by 10.140.230.207 with SMTP id a198mr271640qhc.94.1458697468049; Tue, 22 Mar 2016 18:44:28 -0700 (PDT) Received: from kan ([2601:18f:802:4680:226:18ff:fe00:232e]) by smtp.gmail.com with ESMTPSA id v70sm79747qge.25.2016.03.22.18.44.27 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 18:44:27 -0700 (PDT) Date: Tue, 22 Mar 2016 21:44:22 -0400 From: Alexander Kabaev To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 Message-ID: <20160322214422.00e3bcf8@kan> In-Reply-To: <20160323012413.GA86944@www.zefox.net> References: <20160323012413.GA86944@www.zefox.net> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/95eKE/eQ89RTkL7n5Tfq_1j"; protocol="application/pgp-signature" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 01:44:29 -0000 --Sig_/95eKE/eQ89RTkL7n5Tfq_1j Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Tue, 22 Mar 2016 18:24:13 -0700 bob prohaska wrote: > Is there a way to operate an RPI2 single user with the HDMI monitor > and a USB keyboard? =20 >=20 > Is it practical to cross-connect the UART pins and use cu on one RPI2 > to communicate with a second?=20 >=20 > If not, is there a USB-to-3.3v UART adapter which > uses existing FreeBSD drivers? Amazon.com is full of cables, but most > speak only of Windows and Mac OS X.=20 >=20 > Thanks for reading! >=20 > bob prohaska > =20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I do not see why cross-connect would not work, so that is certainly an option. Also, virtually every USB-to-UART cable out there is based on either UFTDI or Prolific chips, both of which are supported quite well under FreeBSD. --=20 Alexander Kabaev --Sig_/95eKE/eQ89RTkL7n5Tfq_1j Content-Type: application/pgp-signature Content-Description: OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJW8fT2XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDNUY3RDk5NTk5QjY0MUUxM0M1MTU2OTEw NzEzMjI5OTkyNzkyRTdFAAoJEAcTIpmSeS5+8YYQAJ4GWv8yjtZ+/OvJdyUkj4QT gJS/d5F1jIqp1xAFe4ShiZaimb/0VYlkc8PgaNgsJBHhIaWvmWHNSj7MHDX9zsaZ TP9Pu7TGP6QgOxnqyip6gR8Rl+NVaXCzcpnv8inE9Qc4/K67CLM17hoOrsDNY5I6 BM5s/uTbVSUe6NXb/6LYL02DJGY33NzKU36KyVXQK2cKKhimycyb0lCXmNZY8RRI QF48U/VAA4PGqvYugLUko0lvTIkTyjdk9Ho+DUp1cd4zxJXjtwLwPnDneV3Aefgo 2+1JnKglnHMXJP1H8+R591qq/3nb6kW67yK8/NgaXWqK6kCR4l4+ufMwRL1BqxEC a7YnNzZDcaNCzV62KH4v0tb/q26XZq7cy0tX+7DUYNsYfYt6SWfRhDCrntZPIMX3 n22rPy7iBwptdlOlXxNlJIbUecXcm0KkZxZ/Xd2/i81+D1CDCzOP6lqdc2RkxL6b WRrPAc1Hbxsd1sROC2ajjR5xH5Q/rtIBx6AE4aBHMlj1kdlIO+Yg/UMW+bMpNa8a yBHENWUMsKm024gJBPfFsD2KUim4oKsYCIL1Jgxt/wI78MjXq/IANyQpLieU5IA7 5tDrA2Rf5MYKSVApFhnWOsMSk7SsEbkT4KD38wCnDMM5z5/U9kEGom13y2HlUaOh oCzVwmwIndcvhuTUfWuA =e75i -----END PGP SIGNATURE----- --Sig_/95eKE/eQ89RTkL7n5Tfq_1j-- From owner-freebsd-arm@freebsd.org Wed Mar 23 01:55:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 253D0A92ECF for ; Wed, 23 Mar 2016 01:55:37 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (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 E2B8E1BC2 for ; Wed, 23 Mar 2016 01:55:36 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 49a28f9f-f09a-11e5-827e-7d17a39bef25 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 23 Mar 2016 01:55:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2N1tSnK012686; Tue, 22 Mar 2016 19:55:28 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458698128.1091.32.camel@freebsd.org> Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 From: Ian Lepore To: bob prohaska , freebsd-arm@freebsd.org Date: Tue, 22 Mar 2016 19:55:28 -0600 In-Reply-To: <20160323012413.GA86944@www.zefox.net> References: <20160323012413.GA86944@www.zefox.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 01:55:37 -0000 On Tue, 2016-03-22 at 18:24 -0700, bob prohaska wrote: > Is there a way to operate an RPI2 single user with the HDMI monitor > and a USB keyboard? > > Is it practical to cross-connect the UART pins and use cu on one RPI2 > to > communicate with a second? > > If not, is there a USB-to-3.3v UART adapter which > uses existing FreeBSD drivers? Amazon.com is full of cables, but most > speak only of Windows and Mac OS X. > > Thanks for reading! > > bob prohaska > Chances are good any of those usb serial adapters on amazon work fine on freebsd. Certainly anything based on an FTDI chipset will, I've got 9 of them plugged into this machine right now. :) -- Ian From owner-freebsd-arm@freebsd.org Wed Mar 23 01:58:02 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0FCDCA92F06 for ; Wed, 23 Mar 2016 01:58:02 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5CDE1C33 for ; Wed, 23 Mar 2016 01:58:01 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2N1vxm1088272; Tue, 22 Mar 2016 18:57:59 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2N1vxEC088271; Tue, 22 Mar 2016 18:57:59 -0700 (PDT) (envelope-from fbsd) Date: Tue, 22 Mar 2016 18:57:58 -0700 From: bob prohaska To: Alexander Kabaev Cc: freebsd-arm@freebsd.org Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 Message-ID: <20160323015758.GC86944@www.zefox.net> References: <20160323012413.GA86944@www.zefox.net> <20160322214422.00e3bcf8@kan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160322214422.00e3bcf8@kan> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 01:58:02 -0000 Hi Alexander, On Tue, Mar 22, 2016 at 09:44:22PM -0400, Alexander Kabaev wrote: > > I do not see why cross-connect would not work, so that is certainly an > option. Also, virtually every USB-to-UART cable out there is based on Ok, that is encouraging. > either UFTDI or Prolific chips, both of which are supported quite well > under FreeBSD. Prolific is a new keyword to me, thank you! > -- > Alexander Kabaev bob prohaska From owner-freebsd-arm@freebsd.org Wed Mar 23 03:23:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A46659D922E for ; Wed, 23 Mar 2016 03:23:32 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from mippet.ci.com.au (mippet.ci.com.au [192.65.182.30]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mippet.ci.com.au", Issuer "Corinthian Engineering Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 359B11054 for ; Wed, 23 Mar 2016 03:23:31 +0000 (UTC) (envelope-from rpp@ci.com.au) Received: from jodi.ci.com.au (jodi.ci.com.au [192.168.1.21]) by mippet.ci.COM.AU (8.14.7/8.14.9/CE140428) with ESMTP id u2N3COh0035265 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 Mar 2016 14:12:24 +1100 (AEDT) (envelope-from rpp@ci.com.au) Received: from jodi.ci.com.au (localhost [127.0.0.1]) by jodi.ci.com.au (8.15.2/8.15.2) with ESMTP id u2N3CO7H090053; Wed, 23 Mar 2016 14:12:24 +1100 (AEDT) (envelope-from rpp@jodi.ci.com.au) Received: (from rpp@localhost) by jodi.ci.com.au (8.15.2/8.15.2/Submit) id u2N3COee090052; Wed, 23 Mar 2016 14:12:24 +1100 (AEDT) (envelope-from rpp) Date: Wed, 23 Mar 2016 14:12:24 +1100 From: Richard Perini To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 Message-ID: <20160323031224.GA89990@jodi.ci.com.au> References: <20160323012413.GA86944@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160323012413.GA86944@www.zefox.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 03:23:32 -0000 On Tue, Mar 22, 2016 at 06:24:13PM -0700, bob prohaska wrote: > > Is there a way to operate an RPI2 single user with the HDMI monitor > and a USB keyboard? > > Is it practical to cross-connect the UART pins and use cu on one RPI2 to > communicate with a second? > > If not, is there a USB-to-3.3v UART adapter which > uses existing FreeBSD drivers? Amazon.com is full of cables, but most > speak only of Windows and Mac OS X. > > Thanks for reading! I do exactly that, but using a USB to TTL cable and minicom: https://www.adafruit.com/products/954 -- Richard Perini Ramico Australia Pty Ltd Sydney, Australia rpp@ci.com.au +61 2 9552 5500 ----------------------------------------------------------------------------- "The difference between theory and practice is that in theory there is no difference, but in practice there is" From owner-freebsd-arm@freebsd.org Wed Mar 23 03:41:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E4A169D94CC for ; Wed, 23 Mar 2016 03:41:09 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BFF0014CE for ; Wed, 23 Mar 2016 03:41:09 +0000 (UTC) (envelope-from tim@kientzle.com) Received: by mail-pf0-x235.google.com with SMTP id n5so6509474pfn.2 for ; Tue, 22 Mar 2016 20:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kientzle-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9wSWq3piNJvhHM6PfaCVj3w5c/oZqSO9Mop0Up8hHok=; b=OFdw54S+UnNDR2MSQTvo4ca7ZDQ5LCkvAvgtHM1zr806jpCp0ETPllPM08EU21QJak e7E0Wf4EdGfPJ4fm5kh8dmfIvjQvOGp79LrG8U2Huy+FS9u9N/pj1W1+Fv1HzyFT+YEh kk6QCPLD6HNGv6I7AGWKn2Ebhb7XGsu0WLvc8xy26qpTWgeHhZYezARhrPAZ6nURp3Qw k+od9pcOK4hG44ByCB8D2x2z6PC5OGCV8t5KoOvAPBF34QaSCgmk54X0gXHmGblGVx2V KTz7HEFRl/0lUp/9zPQCdmuq/bOmlKnDkxfovSQMGQqSfb9Jn/rG/0Mgx9AqG6Z7b+b0 oVdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9wSWq3piNJvhHM6PfaCVj3w5c/oZqSO9Mop0Up8hHok=; b=i2Tk1fAkvY48AVaRVI+d1yo05B99CyBBXo0wiziEC+j1IPW46cHdnLvHSvlP+SClyD PnP7ZhWRtwze5vgy0/6nrRGxltCodFBaiu8FtcaMjxbd7QAGkGSJ+Gk4FFGLNyz5QtYF YZ7XHB6TiWG9MGcqCSscIFz03qCQGKe7sF6o7Q2RUMhBaqgxtuDMjpPwkEUlW9riXQIH /5plvXeK/lVxbP7T7MKsqyOf/ay9y0xxfetL30CS6KJYNfNwXTafZ/udlx3t8AXadeWP J6zHUAPvT7iBIShL5MbcJIU8uKvuDylfucAthsdGGnM31D0XWYNpxPDjFdKqE5zSS6va Butw== X-Gm-Message-State: AD7BkJLJlWWmtMTjJATrths0SXTJyKPSCFaCB1xye7MMo4+16Jzm9q1MZIIPhFgYWod0nw== X-Received: by 10.66.253.193 with SMTP id ac1mr826667pad.121.1458704469072; Tue, 22 Mar 2016 20:41:09 -0700 (PDT) Received: from [192.168.1.102] (c-24-6-102-176.hsd1.ca.comcast.net. [24.6.102.176]) by smtp.gmail.com with ESMTPSA id v74sm528072pfa.7.2016.03.22.20.41.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 22 Mar 2016 20:41:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 From: Tim Kientzle In-Reply-To: <20160323012413.GA86944@www.zefox.net> Date: Tue, 22 Mar 2016 20:41:27 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <69EA3E96-4182-49B2-88AA-E885CF344BCB@kientzle.com> References: <20160323012413.GA86944@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 03:41:10 -0000 > On Mar 22, 2016, at 6:24 PM, bob prohaska wrote: > > > Is there a way to operate an RPI2 single user with the HDMI monitor > and a USB keyboard? > > Is it practical to cross-connect the UART pins and use cu on one RPI2 to > communicate with a second? Should work fine. > > If not, is there a USB-to-3.3v UART adapter which > uses existing FreeBSD drivers? Amazon.com is full of cables, but most > speak only of Windows and Mac OS X. > The common Adafru.it/954 cable works fine with a FreeBSD host. Tim From owner-freebsd-arm@freebsd.org Wed Mar 23 03:49:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 323A69D96A4 for ; Wed, 23 Mar 2016 03:49:04 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DAEB71950 for ; Wed, 23 Mar 2016 03:49:03 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: by mail-yw0-x22f.google.com with SMTP id g3so4476875ywa.3 for ; Tue, 22 Mar 2016 20:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=yyl0+nO4Xgm9KbEerLxCQr7KkTaK6fq2p+CV3fa/eq0=; b=y2+UX1bG388FSLRF6+mw5d250Sh5NJrRO5k2Y2xzPKegG7CTtL9c1l4/SNI+T08i7J wJZZSol49lxbsXcK4PYf5PxFOMVim0srIC2tWhiLfjlDmRPQEwXNO2sX6IulsyoqYmpu MJBjKvZZ6CEiBnQ2gMshMOLiagqeJzw7Z3Edjya853DwLdQDRxtb4yOCiuZmq1tc8Mpp o/yFen+Mx/lF6rE1zMjlgP20pXjDEkObqEIp7Cdhs3Byw1ZoMev5XBKJ9FJNjkGzlpZ5 0IMJDui+61rRGfOQG5VsQIdMqeXmNGfMC8ng3f8VIiMxANvfxjur8vcig4Wr2MZ9z1fl 7bQQ== 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; bh=yyl0+nO4Xgm9KbEerLxCQr7KkTaK6fq2p+CV3fa/eq0=; b=SMt+goGCq6THfAiqDRUf5I5zEFPRPqb4umBetwG0y8I4Zvi45eKZdIVDCfTxaI6skI yPzH6jniZ0t8QsrjNpt7T9g9KDrarWioImvzBxhYOoh5c8mBzYgfHEArS3wUG8R7ux6d s1eLvGbRrHQXMirUf8dkSiwiE2JEC45CNsuw199hs5vc6nW0FtFPTmR++7Yc9fTtdfjQ cAGwg577yFfozn5s3s9sVtOifXi1cso273ZUpqg3VpKGfSp5EhXFwPMGI2HMW0kadZtB SwX/FvtIqajNvTixha5zJztONgiLvcFb14QyaxrXkPWrCEn7voY3uvoRsG0lDa3r/55V O2DQ== X-Gm-Message-State: AD7BkJKcyI/pL2uLiClDpLYFFra4duyLeNmpUUoEkCpa8LxHmQ6ZPIL/AY6zkeckL4GLgW6Qw9fbZrVpAcrZMQ== MIME-Version: 1.0 X-Received: by 10.129.109.19 with SMTP id i19mr271536ywc.50.1458704943149; Tue, 22 Mar 2016 20:49:03 -0700 (PDT) Received: by 10.129.103.133 with HTTP; Tue, 22 Mar 2016 20:49:03 -0700 (PDT) In-Reply-To: <20160323012413.GA86944@www.zefox.net> References: <20160323012413.GA86944@www.zefox.net> Date: Wed, 23 Mar 2016 00:49:03 -0300 Message-ID: Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 From: Luiz Otavio O Souza To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 03:49:04 -0000 On 22 March 2016 at 22:24, bob prohaska wrote: > > Is there a way to operate an RPI2 single user with the HDMI monitor > and a USB keyboard? Try this: # sysctl kern.console=ttyv0 and then: # shutdown now Luiz From owner-freebsd-arm@freebsd.org Wed Mar 23 05:16:21 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6877AB4842 for ; Wed, 23 Mar 2016 05:16:21 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7387D18D1 for ; Wed, 23 Mar 2016 05:16:21 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x236.google.com with SMTP id e6so5947730vkh.2 for ; Tue, 22 Mar 2016 22:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=WLlnYxM3ly18gjlZv/NUOwnBRrOwAsN1xyh0QX99HCE=; b=FJB4er7ITJkQ5MMJouugHu/thJBM+tOXTkRD03Lhymxpg2EIDN3eY4outolbVe5Lho oq6jUagPkL6krb7I3NhSjfdVmb/u/RS1TsFdCjoeDG/Ltqq6+bkdqcJPaXkbabJ10tIw TVj/Azk72oojSA6nV42jY1VgWQS75AjH8UDAPqpRN7zm6+LTog6H7uGt68ykYGAnWjiF 9CkFbNeU6yMQr82ZzaxyRPTD6C1eB7BXVupWAI034P912pjMBkpYkYU2MHdmZ6M0q/Qa DcGM2vqzRzpMSPl1Nk8BjZOScoIzsOc0tZM4y+QQ4jTZHSVqY7odqmd9sRlWQBYXq34/ tcwQ== 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; bh=WLlnYxM3ly18gjlZv/NUOwnBRrOwAsN1xyh0QX99HCE=; b=AlhsCISzFU/47bXnDY2uYcjO6Cdlhtp5sGfxQPaAsa9BWrrHVHcVNG5Nuqzxje/0vA jO7qnk8aNk3SjEWIDb+8UaQsofGClqeyUEnddsLYnSfZ+8TF0+vLOSAxyfKWDKsfn1jf ZDozn+dO/TXTxs1ZEXzVQA07/E9xK8FXOwwN9ToG2zkXqcoEwXCxilUAEClR+tpSgNmB Ja6cz/lfOFHcFYUJS9cM6Qx17MUu0ZQprDq62zlWuw0JfMBIW30y6ivjFp9E3fgwSnI8 ZrYFgl7uytT4OX/8rT4g8Gg1YvVaSoQkth9CJYHwblRM5QTKnAS7vXsYwtrs9M5xQa9o jJ6w== X-Gm-Message-State: AD7BkJK9Vy6L0ulj0YbyRPPwOt1DY9VDN4Ig7ZzfJ3F6i5LaMCDoEp7db3BMAiRzp+0fIfoG0/HtbfvJncuRZQ== MIME-Version: 1.0 X-Received: by 10.176.0.139 with SMTP id 11mr488365uaj.36.1458710179162; Tue, 22 Mar 2016 22:16:19 -0700 (PDT) Received: by 10.31.54.13 with HTTP; Tue, 22 Mar 2016 22:16:19 -0700 (PDT) In-Reply-To: References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> Date: Tue, 22 Mar 2016 22:16:19 -0700 Message-ID: Subject: Re: Fwd: SDIO Patch D4761.diff Not Building For Me From: Russell Haley To: Ilya Bakulin , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 05:16:21 -0000 Hi Ilya, Mixed success tonight. I tried to install the kernel but got an error: /usr/git/kibab/src% make ARCH=armv6 TARGET_ARCH=armv6 KERNCONF=IMX6MMC installkernel DESTDIR=/mnt/sdcard resulted in (The full output is at Pastebin here: http://pastebin.com/uX3GARg4): ===> ipfilter (install) install -o root -g wheel -m 555 ipl.ko /mnt/sdcard/boot/kernel/ install: ipl.ko: No such file or directory *** Error code 71 Stop. bmake[4]: stopped in /usr/git/kibab/src/sys/modules/ipfilter *** Error code 1 Stop. bmake[3]: stopped in /usr/git/kibab/src/sys/modules *** Error code 1 Stop. bmake[2]: stopped in /usr/obj/arm.armv6/usr/git/kibab/src/sys/IMX6MMC *** Error code 1 Stop. bmake[1]: stopped in /usr/git/kibab/src *** Error code 1 Stop. make: stopped in /usr/git/kibab/src SO instead, since it was a working image I just copied the kernel in root@JailBird:/usr/obj/arm.armv6/usr/git/kibab/src/sys/IMX6MMC% cp kernel /mnt/sdcard/boot/kernel/ Well, it booted the kernel and then spewed output and eventually ended with a failed DHCP request (?). Here is the pastebin of said output. http://pastebin.com/zpZdgsQJ I'm going to start going through the output. Thanks! Russ On Mon, Mar 21, 2016 at 9:54 PM, Russell Haley wrote: > Adding "MODULES_OVERRIDE=" worked, thanks so much Ilya. I've got > something early in the morning so it's going to have to wait until > tomorrow night to get tested. :( > > make TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6MMC MODULES_OVERRIDE= > -j20 buildkernel > > .... > > --- kernel.full --- > linking kernel.full > ctfmerge -L VERSION -g -o kernel.full ... > text data bss dec hex filename > 5852361 317316 1196032 7365709 0x70644d kernel.full > --- kernel.debug --- > objcopy --only-keep-debug kernel.full kernel.debug > --- kernel --- > objcopy --strip-debug --add-gnu-debuglink=kernel.debug kernel.full kernel > -------------------------------------------------------------- >>>> Kernel build for IMX6MMC completed on Tue Mar 22 04:50:12 UTC 2016 > -------------------------------------------------------------- > > Thanks! > > Russ > > On Mon, Mar 21, 2016 at 10:17 AM, Russell Haley wrote: >> Ilya, >> >> Sorry, I forgot that you had proper instructions (got lost in all the >> emails I guess?). I'll try this again as soon as possible. >> >> Thanks, >> >> Russ >> >> On Sun, Mar 20, 2016 at 7:43 AM, Ilya Bakulin wrote: >>> On 2016-03-18 20:06, Russell Haley wrote: >>>> >>>> Ilya, >>>> >>>> I have tried re-compiling with the "corrected" include file in >>>> /sys/dev/mmc/mmc.c (#include ?) >>>> >>>> I can't include my build output because it's over 200kb in size and >>>> Pastebin.com crashes all my browsers here at work. I will email it to >>>> you separately. >>>> >>>> Thanks, >>>> >>>> Russ >>> >>> >>> Please use IMX6MMC kernel config file, it has all necessary modifications. >>> dev/mmc/mmc.c should not be built at all because it's the old MMC stack >>> implementation. If it fails, try adding "MODULES_OVERRIDE=" when calling >>> make, because we don't need any modules anyway. >>> >>> I have updated instructions on https://bakulin.de/freebsd/mmccam.html to >>> include kernel config names. >>> >>> -- >>> Ilya From owner-freebsd-arm@freebsd.org Wed Mar 23 06:32:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A81D1AD7BBD for ; Wed, 23 Mar 2016 06:32:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 781381439 for ; Wed, 23 Mar 2016 06:32:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22b.google.com with SMTP id c63so20169167iof.0 for ; Tue, 22 Mar 2016 23:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=kPqt5OsJaWJC2UMutxlshIU3ZK58Dtju312aGiuCX5k=; b=AeOjO/sG0WWbCXh6vkObA4WGG3u9jQIF0zR6uiUmARupAsXCLv0yJWuuo+WYAWgpCq WwM9BVD3lRIppRwGWTqZ6zm8rfb//iCrGk9YKMq5cxY77goBlPyKbgtPHF6pz+KXeyq1 BeZO+38sf7LGz+nep2o0/p9bc9yuk8cSh7+p9fVf2+xoKd2F2TbI+Nqyt7X57gJZrGo1 sdd+2thpAQsjMXVOd06owAKk2z5AZyfQM10nigLgZvffE4tknLD7x6dLRiXLDMSly0N0 twxYHEVw+wZe0wSLRFVleGwMMxG4RQrZNu4vo0Q6RiFCCuH0MECwf5hKP3mQ/yVs79Sb dmuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=kPqt5OsJaWJC2UMutxlshIU3ZK58Dtju312aGiuCX5k=; b=Hhtf51eKadYbToQ9R6O0i/yY/08IG9A8fmerqfcEc7sPPWGtTfGhmmsFTvxwUMEaOJ ThPyIcP0B0A/2rsZ4TWPaV/n7NJjdFAvuYez3Mrs29m4Y57I/d0hfPNflti9kJL7lbar OpN64uAik/L0+lfirgG9Jd9tPx6IrjktxCU2uciWuq9DF+/VcMDqW0pLyHuSALzDmtCf k9sJc8p80wNMAV2WQuAhamp/dHLb9oloj4AC5hX/LGpbVLflMUVpdwIiQJ1zMoYGQEx6 9b2t4PKUPKeLO0L2Enyx9RpTZC9xawyk3bf21iOhzmtAppgExWTyVbZ0rZEnpGuZYCAc ze2w== X-Gm-Message-State: AD7BkJJtsZhwuap0blZErfFFq/oe75ESeXQgs/GoaxMTWrZFxp8DrkKqQE77ArD6r/SOx3yVRI79OGttR1ji7g== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr1538941ioe.135.1458714750813; Tue, 22 Mar 2016 23:32:30 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Tue, 22 Mar 2016 23:32:30 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <271EF73A-077C-44A5-8B58-721405800B9F@bsdimp.com> Date: Wed, 23 Mar 2016 00:32:30 -0600 X-Google-Sender-Auth: R8-2uE69UqGDXELFcVl6MZJZBdY Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Russell Haley Cc: bob prohaska , freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:32:31 -0000 On Mon, Mar 21, 2016 at 10:39 PM, Russell Haley wrote: > How long can nand go without power before it starts to lose data integrity? > It depends on the NAND. Most NAND is spec'd for 1 of 3 common values: 1 month, 3 months or 1 year. This spec is the 'end of life' spec, and always at 40C. When the NAND is worn out, it will still be readable after it has been off for this period of time. Temperature does have a lot to do with it. At 0C, NAND can last up to 80 times longer, in theory. Likewise, at 70C, it will age 80 times faster. It's generally an Arrhenius relationship between temperature and data retention. The hotter the nand, the less long data lasts, though the faster the program and erase times (and the greater damage each P/E cycle causes). The colder the nand, the longer the retention, but the slower the program and erase times are. NAND chips, by themselves, generally don't care power on or not. Devices they are put in care a great deal. Part of the garbage collection that's done by NAND devices ensures that the data is never put at undue risk. That's done by copying the active data out of blocks that are too old, or too hard to read. The details vary FTL to FTL, some will scan the device once in a while to make sure data can still be written, others do it mechanically with the passage of time. Data can be too hard to read if it is too old, or if it has been read too many times... Warner From owner-freebsd-arm@freebsd.org Wed Mar 23 06:36:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6387AD7C91 for ; Wed, 23 Mar 2016 06:36:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6E935150C for ; Wed, 23 Mar 2016 06:36:39 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id 124so19985063iov.3 for ; Tue, 22 Mar 2016 23:36:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=P/fe7SkyuuqUDclH23kx39f91iZhJqPQfVsrJR8OScc=; b=V8IxuMT9QFsq0UyNswa4n3/V89iIQwUyBciLEneM0JqmBTYH4gokUk/JyW9nvFWQJ9 RGCluhH4uexViZAzdTpJtOdvV353Ilzcl9JPkQyno95yPFxksZq64KBGNeX/ot4LA+eg pT0ELSn/T3PY0PAQyPwQodJnf/L7v/z9PnTvQBZdfffCjxtQkluoTBO/IMDk68BY7wnj 5QELIESObGE9ctcM2Pc/v5p1295Bn9Te6TFH6IZii7J19WusWsz3qj7qEGUyr/J2yiMq EWhRTQTlYv8Rk0846YsyqrHkPOWkhpnOETxcRU7dwhDzCot8PzlpaKHgV/xZzDhnoEjN emgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=P/fe7SkyuuqUDclH23kx39f91iZhJqPQfVsrJR8OScc=; b=XGcWDklYL7CTl3gDlBrvrfeycEcnH5D5dE1TELLMA0teXYIElik+X+mnIVhUYt4uyA 5lOvWwoOxqfuFt5sroF7k8wBLIcDUrN6lGgdibLVDHkZuuM7YOPVmS4vfQQhp4V6J5kz E+g8GVM0zRDpB/4lw4exOJUsGBpZxarnsQ7qPjRxIqOAa3HYkhgK6BvxdeXGswh24F/e ucs97USi0m/ybFVUe/JoDQ440dyFpvxp09tlCSjGvPdQUTbCreFD+QsyoH67prreJYYC fngPuFYDMOUACuLbJYOb0DeVkk/n9DBTA5/kwFsTE2aSPFg10DaySzUn56cfkJsFtQkZ 01ow== X-Gm-Message-State: AD7BkJLfJkHVAHLGznbAamfhqjAXAk8e+tGh8y4y3hHpiKSsscFgPNKA1VuxW9T5dLtw/vWBVLSJD/eFkIJEqg== MIME-Version: 1.0 X-Received: by 10.50.30.134 with SMTP id s6mr21215665igh.36.1458714998856; Tue, 22 Mar 2016 23:36:38 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Tue, 22 Mar 2016 23:36:38 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160322141432.3f0a3a61@X220.alogt.com> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <20160322141432.3f0a3a61@X220.alogt.com> Date: Wed, 23 Mar 2016 00:36:38 -0600 X-Google-Sender-Auth: oae0YMDEVjMzpcFxmEIK_LvF-VY Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Erich Dollansky Cc: bob prohaska , "freebsd-arm@freebsd.org" , Ian Lepore Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:36:39 -0000 On Tue, Mar 22, 2016 at 12:14 AM, Erich Dollansky wrote: > Hi, > > On Mon, 21 Mar 2016 15:11:53 -0700 > bob prohaska wrote: > > > On Mon, Mar 21, 2016 at 01:01:24PM -0600, Ian Lepore wrote: > > > > > > Freebsd does no wear-leveling, it's up to the microcontrollers > > > within the storage devices to do that. > > > > > > Those controllers have no notion of partitioning or filesystem > > > layout and do whatever they want to do internally about wear > > > leveling. That leads to the mildly disturbing situation of having > > > blocks from a readonly filesystem and blocks from a writable > > > filesystem sharing the same flash erase-block inside the device. > > > One likes to think of the data in a readonly filesystem as safely > > > protected from the read-modify -write activity that happens at the > > > flash erase-block level, but no such g'tee is made on any mmc, sd, > > > or usb flash-based devices I know of. > > > > > > - Ian > > > > > Ok, thanks. It sounds like /var and /tmp could be confined to > > limited-size partitions while still permitting wear leveling to use > > other, less-used parts of the device. So, if a block nominally > > in /var reaches end of life can the wear leveling controller start > > stashing data anywhere on the device? > > > > As a practical matter, should I even be worrying about this? Folks > > once made a big deal of partitioning storage so a runaway process > > couldn't choke the whole machine. Is the precaution still worth > > taking on ARM? > > > we use memory disk for /var and /tmp. If you really need the content of > these directories, you could write them back to flash by a script every > hour or so and save all the writes between. > > Do not forget the flash devices used in Raspberries & Co. cannot be > compared with the flash devices used in flash disk. Raspberries don't have flash. :) SD cards generally use similar NAND to consumer grade SSDs, but have firmware optimized for the digital camera market. There are some differences, but the chips are basically the same under the hood. Many of the optimizations trade off speed for longevity differently between SSDs and SD cards. NVME adds a new layer of fun to all this, but even there tweaks to the different program and erase algorithms are extensive. Warner From owner-freebsd-arm@freebsd.org Wed Mar 23 06:43:54 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B18BAD7EC6 for ; Wed, 23 Mar 2016 06:43:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 31D3F195A for ; Wed, 23 Mar 2016 06:43:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22a.google.com with SMTP id o5so20385540iod.2 for ; Tue, 22 Mar 2016 23:43:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=YFtXPUPPFrseJZ7TUv5rE1QtUw0F+wvhUD+TnhL6L7o=; b=AjqfOcyQroS/QyfyFWkJRslrzOCWLbB5vAxAPX6VQxGCX2gsQfWJSWRncTeshFd+UR vsqDKDnL+RR9y1mgK9WrVIiz9PzA3I8S2bw0SmJlxzK8qUs0L6l46srnRmiAL9Sp+bxw tW90xur/D/1LPsf1OsfhpDZ0oEMJ62lPDp+8CI/1l3khyKHDXMxOhC07qxxY4eR1xpXG 6SJnGjf3omiyfAFsN4oKambNLUYdP6a7Sstw7Aq3zJLUwr3Mb7VVIV3znbLxo8PUtL+K /Gha1FM7gJLmKeYO3lbxfhZZ+hbX7yZv41Z/GJ7nCG1HXgF2o8Q0nvhqwr5B9Dhn7Z9J 6xxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YFtXPUPPFrseJZ7TUv5rE1QtUw0F+wvhUD+TnhL6L7o=; b=BAk54DyTPblavp9wF70fpZOo+g6Pauatkh6hiy3pPwvWJLL9oh9EVQSsd9PwmNJAPg pjiDU8ZF0WekZEjSJWj8tUf+58P2Atxj7TNUj6hdAwwE8Lx2xb2cCbfzEvx4S6Oltkop 29NvDoLgL1dGvfsKCOrwvhQdL278d0rQGKZ5Bxlqj3wrd7fzB3eN58jeGkv+XXYws3ns AG34IEHBO9U8VvqyFUXRpa4+TJ5gVUNleeqMkzXBWmir2+mHGmHkz1hvo4yBLM/NoD8v z4NMByHq7FRnG29/ru+Zk4tMqhjuTrYUJ2ee/aLWaYQduqb2bzgwd4QneO4cPYyBxGZE GNww== X-Gm-Message-State: AD7BkJJ8GW0HENo0ZczQmq/NJrgMmbvtAK/WI7K5xjaF+9XBlnlzehrtvEQ1SVWHlmn9b5Q8J47qxYCHYhnMnA== MIME-Version: 1.0 X-Received: by 10.107.14.209 with SMTP id 200mr1609577ioo.73.1458715433618; Tue, 22 Mar 2016 23:43:53 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Tue, 22 Mar 2016 23:43:53 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <20160322032832.GC83908@www.zefox.net> <20160322062635.GD64087@server.rulingia.com> Date: Wed, 23 Mar 2016 00:43:53 -0600 X-Google-Sender-Auth: 0f72gJTd_QxpYt8x5UhtEiTTYSo Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Jia-Shiun Li Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:43:54 -0000 On Tue, Mar 22, 2016 at 6:11 AM, Jia-Shiun Li wrote: > On Tue, Mar 22, 2016 at 2:26 PM, Peter Jeremy wrote: > > > On 2016-Mar-21 21:47:39 -0600, Warner Losh wrote: > > >So let=E2=80=99s do the math. 512MB cards tended to have write speeds = of maybe > > 6MB/s. > > >At 6MB/s, that=E2=80=99s about 518MB/day, or one drive write per day. = Most SD > > cards, > > > > I think you dropped some zeroes there. 6MB/s =3D=3D 518,400MB/day =3D= =3D > > 518GB/day. > > That's 1000 drive writes/day - which is non-trivial. > Yes, I must have. I think I must be misremembering the speed. Also, DD spee= d on the 512MB drives I just tried is closer to 3MB/s and writes through the file system are closer to 1MB for big writes and 500k for small writes... Still that's not enough of difference to make up for the while error. Maybe a factor of 10? > > > btw at the days of 512MB cards they are mostly made of SLC nand flash, > some were beginning to transition to MLC. They are different from TLC the= se > days in terms of endurance. That may explain it. SLC parts generally were good for 50k or 100k cycles, while MLC parts are good for 2k-5k. TTLC parts maybe 1k. The 1 drive write per da= y drives generally are at the low end of MLC or the high end of TLC. So that's another factor of 100 there maybe? Warner From owner-freebsd-arm@freebsd.org Wed Mar 23 06:45:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 938F4AD7F1E for ; Wed, 23 Mar 2016 06:45:35 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 5C7A719EE for ; Wed, 23 Mar 2016 06:45:34 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id VAA20311; Tue, 22 Mar 2016 21:49:23 -0600 (MDT) Message-Id: <201603230349.VAA20311@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 22 Mar 2016 21:49:19 -0600 To: bob prohaska , Warner Losh From: Brett Glass Subject: Re: Effect of partitioning on wear-leveling Cc: freebsd-arm@freebsd.org In-Reply-To: <20160322033417.GD83908@www.zefox.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:45:35 -0000 At 09:34 PM 3/21/2016, bob prohaska wrote: >How do modern flash devices report end of life? Do problems show up in error >logs, or does the device simply refuse to work with no warning? Depends upon the device. SSDs will give you a warning via SMART; they will begin to retire blocks and swap in reserved blocks. Simpler devices such as memory cards and USB sticks will simply die. I use SSDs in mission-critical applications, so that I have at least a fighting chance of replacing them before there's an outage. --Brett Glass From owner-freebsd-arm@freebsd.org Wed Mar 23 06:45:54 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 24439AD7F55 for ; Wed, 23 Mar 2016 06:45:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E04FC1A40 for ; Wed, 23 Mar 2016 06:45:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22d.google.com with SMTP id c63so20674267iof.0 for ; Tue, 22 Mar 2016 23:45:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=I0uqVNUbYFRNSRiz9wuoIDN0pjeLkU2nLEkRpcu84EA=; b=wnIIJJ2LLpMMQTFKABWVyBmfC9m4dlghDVoTw+NlnvqwfFzQ8f5asCRR0JUgkqyRux OQq7STwapjoNGIjY0q1NbX6mQQUcPyN3W8ZqJj04aa0A5DJSKh6tcHCRsleUROEQ16+t O2YeI4PgRYeLiWOMHCMn1YfNYosKyKyC6p+6JWsNPoP+wL2Wn5uIM+0ySCFFU/D8hEn8 2iprdQQL0PmYB72Gp4XEWnOQ7l/t+ldBGYtIt6bMHJOZJifmUsQdCsEA2+1FYJcH8VgE bPzGKTB2FKnOfmVYElSGp670AC9vz0XiGMRwGnTuej1/n7ItQtMqf4fTlq++MAqYwsu8 lSCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=I0uqVNUbYFRNSRiz9wuoIDN0pjeLkU2nLEkRpcu84EA=; b=Nho2Cx+4Gxy/ZC/aX7nerRgVoKhnIYZHjj4oxktLzkQvimz+NZsJFCkKEU1P7J8DYb mxLESKS01boOfpoQCubqs4GGkETt03S6ZL+b0HD7/J5wQlocK7Eu4VBQWXFb+yxh2aO5 1uCo7WYawW7DpJRlz3gwjGV2/ZHpIVyDBExlWOQhnH4yMUY2KLBWKO+EIWx2HpqBc+VY Z+3YB8uDxQSD4E/Gi8NOAZsvKSbycY7gokjwGemW+qPSgQVeIefeUFr5/obVdl8uVW50 4ffxWfbvbboJwmWzIWQinu/TF40fExj28GDGnfeb04W4080Pyxl3vfuvZvADYTeboH9q 8YMg== X-Gm-Message-State: AD7BkJKPqu3QY0frybXEZegvnu4S8Uk5UVaih23+ORdMAxg8C922sk81LM77N7Rv4Vuxoez88jrtlRX0C+0PQQ== MIME-Version: 1.0 X-Received: by 10.50.67.113 with SMTP id m17mr1745308igt.52.1458715553471; Tue, 22 Mar 2016 23:45:53 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Tue, 22 Mar 2016 23:45:53 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <201603230349.VAA20311@mail.lariat.net> References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <201603230349.VAA20311@mail.lariat.net> Date: Wed, 23 Mar 2016 00:45:53 -0600 X-Google-Sender-Auth: LaSRHHiM353rbhWx77-KSGgjpT0 Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Brett Glass Cc: bob prohaska , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 06:45:54 -0000 On Tue, Mar 22, 2016 at 9:49 PM, Brett Glass wrote: > At 09:34 PM 3/21/2016, bob prohaska wrote: > > How do modern flash devices report end of life? Do problems show up in >> error >> logs, or does the device simply refuse to work with no warning? >> > > Depends upon the device. SSDs will give you a warning via SMART; they will > begin to retire blocks and swap in reserved blocks. Simpler devices such > as memory > cards and USB sticks will simply die. I use SSDs in mission-critical > applications, > so that I have at least a fighting chance of replacing them before there's > an outage. Hope your SSDs are better at reporting things than ours. We've seen some SSDs just fail even though the previous SMART data said we've used maybe 20% of the drive's write ability.... Warner From owner-freebsd-arm@freebsd.org Wed Mar 23 07:55:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02825AD8C6A for ; Wed, 23 Mar 2016 07:55:47 +0000 (UTC) (envelope-from oliver.psotta@posteo.de) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.posteo.de", Issuer "StartCom Class 3 Primary Intermediate Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA9BE12FE for ; Wed, 23 Mar 2016 07:55:46 +0000 (UTC) (envelope-from oliver.psotta@posteo.de) Received: from dovecot03.posteo.de (dovecot03.posteo.de [172.16.0.13]) by mout01.posteo.de (Postfix) with ESMTPS id 7FA2020CC4 for ; Wed, 23 Mar 2016 08:55:37 +0100 (CET) Received: from mail.posteo.de (localhost [127.0.0.1]) by dovecot03.posteo.de (Postfix) with ESMTPSA id 3qVMLc6PBgz5vMp for ; Wed, 23 Mar 2016 08:55:36 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Effect of partitioning on wear-leveling From: Oliver Psotta In-Reply-To: Date: Wed, 23 Mar 2016 08:55:33 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <201603230349.VAA20311@mail.lariat.net> To: "freebsd-arm@freebsd.org" X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 07:55:48 -0000 Which SSDs failed on you, Warner? There sure are some rotten apples, but the Samsung 840 pro, for example, were (are) quite reliable. -Oliver > On 23 Mar 2016, at 07:45, Warner Losh wrote: > > Hope your SSDs are better at reporting things than ours. We've seen some > SSDs > just fail even though the previous SMART data said we've used maybe 20% of > the > drive's write ability.... From owner-freebsd-arm@freebsd.org Wed Mar 23 08:02:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59DF9ADA363 for ; Wed, 23 Mar 2016 08:02:41 +0000 (UTC) (envelope-from onborodin@gmail.com) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E2302182B for ; Wed, 23 Mar 2016 08:02:40 +0000 (UTC) (envelope-from onborodin@gmail.com) Received: by mail-wm0-x235.google.com with SMTP id p65so12441708wmp.0 for ; Wed, 23 Mar 2016 01:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:organization :mime-version:content-transfer-encoding; bh=N8liGZ3bDIbxpunq06VEuuWrK6g74lejzrn/B86TpRE=; b=XS01ZMI/ZG7PJrH69C1ldohIdPkuoOtEy6MsR8jFby6ZmEmu5kFVSmGElgRvDJ1HUW UNPh7p6Ktk7dyAaC4BgRlBTqTiXwsYn37itWAPlmGJA2DDbxvXYoh+jdEp2r73Xo64jB kvYMvIBZAApb+NtuHDo5isWaYDfasX6sCghXiPk5HzgpKL+ihHWCbbdODZ73TsZTIgAz MkST4ai8Q3WDLOpnSC4GKP/uxfhYwDKetBa+HnTTGUZquV45nCC8RcwCLslyj8z3Zimv Wr7wjdNRHEosgdY/2SQ4lZchFCw2CdTqpr/lp1a+HZWGtXdcAa7jyqXxT6po+kxzte9o 1DHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=N8liGZ3bDIbxpunq06VEuuWrK6g74lejzrn/B86TpRE=; b=HePZPoWDGlQ91WqZLx116AF0TnJC7SD9XANt1VtTkygMV8FVL7JO1FNA2j0IZLmFzP c09SPlOKiLC1CpzhPrFPo0XAqOvEwRoQiguWD0RhPQTeSha/rbolvc+7EpmmMqHNaHVK V7nnVHylZH8GP9aYYgK56yaFvesVkBJcLs+xGSP43JpCyePpz0MrbAVuklt5vCXRwKmi NPv/rEkdgeVAUrLpr5p6MSEHJwGaDbhryTAEW8586un5zb+Qip6d6VzPZSNewft+1hpL EIzKe6XMXnNsiREGt4/2UGsgAw5gA9taHZw+9BtrcK8MSdiScgtFESM8tObpifDvpDWV sIWA== X-Gm-Message-State: AD7BkJJim9o1mibCRFM3knk9b/KCD3svbuDC6FTvONybX8QP7oaqbDgaXXlyzAYSsz3ggA== X-Received: by 10.28.172.132 with SMTP id v126mr2250327wme.28.1458720159455; Wed, 23 Mar 2016 01:02:39 -0700 (PDT) Received: from zee.home (mail-kgd.lazurit.us. [195.191.50.4]) by smtp.gmail.com with ESMTPSA id k124sm1597955wmb.11.2016.03.23.01.02.38 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Mar 2016 01:02:39 -0700 (PDT) Date: Wed, 23 Mar 2016 10:02:32 +0200 From: Borodin Oleg To: freebsd-arm@freebsd.org Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 Message-ID: <20160323100232.00576347@zee.home> In-Reply-To: References: <20160323012413.GA86944@www.zefox.net> Organization: The Home X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.28; i386-pc-freebsd10) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 08:02:41 -0000 On Wed, 23 Mar 2016 00:49:03 -0300 Luiz Otavio O Souza wrote: > On 22 March 2016 at 22:24, bob prohaska wrote: > > > > Is there a way to operate an RPI2 single user with the HDMI monitor > > and a USB keyboard? > > Try this: > > # sysctl kern.console=ttyv0 > > and then: > > # shutdown now How use usb keyboard _before_ kernel loading, with uboot/loader? --- With best regards, Oleg Borodin onborodin@gmail.com From owner-freebsd-arm@freebsd.org Wed Mar 23 11:00:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8155FADA576 for ; Wed, 23 Mar 2016 11:00:26 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp.kibab.com [5.9.14.202]) by mx1.freebsd.org (Postfix) with ESMTP id 491D91239 for ; Wed, 23 Mar 2016 11:00:25 +0000 (UTC) (envelope-from ilya@bakulin.de) DKIM-Filter: OpenDKIM Filter v2.10.3 olymp.kibab.com C51904E7C5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1458730817; bh=YidI9Pg3fFIdyLxVKduT7+ZR7FQmVdXdfJWSKAqkBNU=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=dhFplESy/ZBevI7xF5dJdbHEKZFCmhJ8+ilzfL+0DE48tyinP8J3cKQWh69wHZPn1 wZzoCGjMANPcXMERrtvoqXOAqQni8faiLnmdDd1zTAbOW8ZCBMgPY2NEUe1RVpt1P5 IlcKeoAPYGDXIhPx9zIXfrIRxTisyBI69fMuRE1M= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 23 Mar 2016 12:00:17 +0100 From: Ilya Bakulin To: Russell Haley Cc: freebsd-arm Subject: Re: Fwd: SDIO Patch D4761.diff Not Building For Me Organization: Deglitch Networks In-Reply-To: References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> Message-ID: X-Sender: ilya@bakulin.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 11:00:26 -0000 On 2016-03-23 06:16, Russell Haley wrote: > Hi Ilya, > > Mixed success tonight. I tried to install the kernel but got an error: You should give MODULES_OVERRIDE= to installkernel as well. > > Well, it booted the kernel and then spewed output and eventually ended > with a failed DHCP request (?). Here is the pastebin of said output. > I never copy the newly built kernel to the SD card. Instead I configure U-Boot+ubldr to boot kernel from TFTP and mount root over NFS, it's much faster and it's impossible to crash filesystem if the kernel crashes. I guess you should set ROOTDEVNAME manually in the kernel config file and disable NFSCLIENT-related options. From your boot log it's clear that the system boots and probes SD cards. There are two slots and none of them has SDIO card in it. From what I find about Hummingboard, it actually doesn't have WiFi SDIO chips on it. -- Ilya From owner-freebsd-arm@freebsd.org Wed Mar 23 13:00:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CE76FADAF36 for ; Wed, 23 Mar 2016 13:00:46 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 BE956198D for ; Wed, 23 Mar 2016 13:00:46 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id 7F7AB239E54; Wed, 23 Mar 2016 09:00:45 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.1 Received: from [127.0.0.1] (vnat600.ejoco.com [166.108.32.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id A5C01239440 for ; Wed, 23 Mar 2016 09:00:41 -0400 (EDT) To: freebsd-arm@freebsd.org From: Nikolai Lifanov Subject: does arm64-rpi3 snapshot work? Message-ID: <56F29377.8060202@mail.lifanov.com> Date: Wed, 23 Mar 2016 09:00:39 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 13:00:46 -0000 I tried booting my Raspberry Pi 3 with this snapshot: https://people.freebsd.org/~andrew/arm64/rpi3-20160306.img.xz I also tried to build one from this branch: https://github.com/zxombie/freebsd/commits/arm64-rpi3 I tried updating to the latest firmware, but I still get a rainbow screen every time. Is there anything obvious that I'm missing? - Nikolai Lifanov From owner-freebsd-arm@freebsd.org Wed Mar 23 13:04:49 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BEFA5ADB108 for ; Wed, 23 Mar 2016 13:04:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7ABD31EF3 for ; Wed, 23 Mar 2016 13:04:49 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qg0-x22d.google.com with SMTP id u110so10855461qge.3 for ; Wed, 23 Mar 2016 06:04:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=HdoAPb4y9+WAkjtLxTo9CBf3B6p3EceTGZ+jckwecb8=; b=Qch/kSKOPJhX0hFq/+vEA4PPbSwDtDRjTzt/2FyVmaqHYUkQUnsALQgEEXWSh6vaoO ylWBd3UgFKP/tbwnlq9xBv8izTEXNuGOujTOxRji6/rHNS+AKkGWXHL4pYmovI6VBFBN NI1kv4yKGXjPyxpvOohxIXkdLsWx5QQ10Yhwh3uTOQV1KY+yX9cYJIpzcXg4df0DjARl F4/QIaUvsc6QiLreHE0CZAwwU5AZR4u+WYFAdCeFr2BrEQNLplM7Q0od7fXRFpMaks5S cBv0s2YhRAoLSr1L8QfOPnrvXPlLfcwpAdUe5ZRazm6K1Wig0ea78kMb1xMu/of7/IfI YEoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=HdoAPb4y9+WAkjtLxTo9CBf3B6p3EceTGZ+jckwecb8=; b=TKrZb9d8Wg9wbrvY55X0+OuhbH/4u3R6fHl7oYdzLgtIta/7ml24Bj20gXbZyXALDn VwwAubNGDUovyps2JGuKNGmHv2s7kjWxMlqooFHDRrtTM8iY2L7nRi+GowB+CoEOsvjF N83mASHULx9iUGBYYNV223RL9lXj2vzTsVdjgWhUvWm0hGoPoqHBL10AlKR6u4OtCnER rBViKOG4rI8SrNAxlUfO/Bif/HmRYVmPchNtgHC0BqGOQTGt+4vqO68yxz2X/S+Rkhvb M7JN7xhPO0UO5r8geS9npX3fMmnpTxmo5/e7B6sP3SDfxHv1HgQmDA9isGLHZX5HKNGD S/Zg== X-Gm-Message-State: AD7BkJLEXg2+f+6t7lVwPedVz/+POS0ddAucXQYzb2Aqn54hSmbTYuog5FsIUWhAik3vWX9u X-Received: by 10.140.232.15 with SMTP id d15mr3513652qhc.87.1458738288266; Wed, 23 Mar 2016 06:04:48 -0700 (PDT) Received: from mutt-hardenedbsd ([63.88.83.105]) by smtp.gmail.com with ESMTPSA id 2sm1016206qgi.33.2016.03.23.06.04.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Mar 2016 06:04:46 -0700 (PDT) Date: Wed, 23 Mar 2016 09:04:44 -0400 From: Shawn Webb To: Nikolai Lifanov Cc: freebsd-arm@freebsd.org Subject: Re: does arm64-rpi3 snapshot work? Message-ID: <20160323130444.GA65661@mutt-hardenedbsd> References: <56F29377.8060202@mail.lifanov.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fdj2RfSjLxBAspz7" Content-Disposition: inline In-Reply-To: <56F29377.8060202@mail.lifanov.com> X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 13:04:49 -0000 --fdj2RfSjLxBAspz7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 23, 2016 at 09:00:39AM -0400, Nikolai Lifanov wrote: > I tried booting my Raspberry Pi 3 with this snapshot: > https://people.freebsd.org/~andrew/arm64/rpi3-20160306.img.xz >=20 > I also tried to build one from this branch: > https://github.com/zxombie/freebsd/commits/arm64-rpi3 >=20 > I tried updating to the latest firmware, but I still get a > rainbow screen every time. >=20 > Is there anything obvious that I'm missing? Hey Nikolai, I believe the snapshots are meant more for connecting a serial cable up to the RPI3 rather than using the HDMI output. RPI3 support itself is very immature at this point. Only one of the four cores is activated. I'm sure Andrew Turner and others could probably shed more light on what work has been done and what's left to do. Thanks, --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --fdj2RfSjLxBAspz7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW8pRqAAoJEGqEZY9SRW7uhfIQAI94yUbKXXsl0qAV6nx3FPDc ZfBKqeJXdy416yszVr/UxR0ZQ5BA2j91xjTg8hUp40MYvdn4xfBxP0EOyWZ2VZHT kyQ4Qufw6/tE1DHu+baVUungwGP7yM4QwdnJ8jJMjX3wZ38Q1c7GqmGaGdTM/mlD EyXCcGe7+MVA7cznMgq5sFSB2d56OAM75RHZjrKCAgrEGvB/KmUGHgZYvztRVJKL t0grAVGUjq6iq0rEs3GHh4GzBRpy4JLMJP+edAoYhnKFT9L2jYA3q0hLqY8DEVKE MbOlxNgpx7rpXavm4ypUsxygaac4+UuNr04V8be14u37vvjpVlhElTOfxy9bluBk AQSYs4RBfoupiKvAW0mGe/teJCDmxidGXPdLo1jc/XHnY5VLRhy+98gVaLV6iHLv 8FCNXxoKe1mNCJpNCbe0A15xuBTsJNDJ1YPF+S8t+t2k9RT1uIx9ieGOLJO5rBah rmhwKYnRKSqqOv8FqK0xpS/Hd5AWNr1CIdsvx80CFznbcdf+wewtyAyzM21R0nEr e321IBgF8eGal+GoLZ8HF+hy2GQmnYaAidazFbxdw2AunM4mxnpFwKzpw4ild0l4 00brPsW3mXYr+MFo42o/Xn1DfT7P7WUI+5Lj/+ceL2HZPyssp6sBlhShPoDJUYzz +GR87BRndc34ni3KvjwZ =NXBi -----END PGP SIGNATURE----- --fdj2RfSjLxBAspz7-- From owner-freebsd-arm@freebsd.org Wed Mar 23 13:38:53 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C07FADB8B8 for ; Wed, 23 Mar 2016 13:38:53 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2EF9D1193 for ; Wed, 23 Mar 2016 13:38:52 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from pmather.lib.vt.edu (pmather.lib.vt.edu [128.173.126.193]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id E85A67FD; Wed, 23 Mar 2016 09:30:47 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 From: Paul Mather In-Reply-To: <69EA3E96-4182-49B2-88AA-E885CF344BCB@kientzle.com> Date: Wed, 23 Mar 2016 09:30:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <819B54EA-899A-40A0-9057-DDA94A88406C@gromit.dlib.vt.edu> References: <20160323012413.GA86944@www.zefox.net> <69EA3E96-4182-49B2-88AA-E885CF344BCB@kientzle.com> To: freebsd-arm X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 13:38:53 -0000 On Mar 22, 2016, at 11:41 PM, Tim Kientzle wrote: > On Mar 22, 2016, at 6:24 PM, bob prohaska wrote: >>=20 >>=20 >> Is there a way to operate an RPI2 single user with the HDMI monitor >> and a USB keyboard? =20 >>=20 >> Is it practical to cross-connect the UART pins and use cu on one RPI2 = to=20 >> communicate with a second?=20 >=20 > Should work fine. >=20 >>=20 >> If not, is there a USB-to-3.3v UART adapter which >> uses existing FreeBSD drivers? Amazon.com is full of cables, but most >> speak only of Windows and Mac OS X.=20 >>=20 >=20 > The common Adafru.it/954 cable works fine with a FreeBSD host. I have one of those and it uses the Prolific chipset. It works fine = under FreeBSD/amd64 10-STABLE. It attaches using the uplcom(4) driver: ugen2.2: at usbus2 uplcom0: on usbus2=20 Cheers, Paul.= From owner-freebsd-arm@freebsd.org Wed Mar 23 14:06:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0233ADBCD7 for ; Wed, 23 Mar 2016 14:06:22 +0000 (UTC) (envelope-from tuexen@fh-muenster.de) 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 "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9E8721F92 for ; Wed, 23 Mar 2016 14:06:22 +0000 (UTC) (envelope-from tuexen@fh-muenster.de) Received: from [192.168.1.101] (p508F1867.dip0.t-ipconnect.de [80.143.24.103]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 3C0F51C0AC9C1; Wed, 23 Mar 2016 15:06:18 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: does arm64-rpi3 snapshot work? From: Michael Tuexen In-Reply-To: <20160323130444.GA65661@mutt-hardenedbsd> Date: Wed, 23 Mar 2016 15:06:16 +0100 Cc: Nikolai Lifanov , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <87B9563B-2B16-4C2D-8C45-A9A97E3A8DC5@fh-muenster.de> References: <56F29377.8060202@mail.lifanov.com> <20160323130444.GA65661@mutt-hardenedbsd> To: Shawn Webb X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 14:06:22 -0000 > On 23 Mar 2016, at 14:04, Shawn Webb wrote: > > On Wed, Mar 23, 2016 at 09:00:39AM -0400, Nikolai Lifanov wrote: >> I tried booting my Raspberry Pi 3 with this snapshot: >> https://people.freebsd.org/~andrew/arm64/rpi3-20160306.img.xz >> >> I also tried to build one from this branch: >> https://github.com/zxombie/freebsd/commits/arm64-rpi3 >> >> I tried updating to the latest firmware, but I still get a >> rainbow screen every time. >> >> Is there anything obvious that I'm missing? > > Hey Nikolai, > > I believe the snapshots are meant more for connecting a serial cable up > to the RPI3 rather than using the HDMI output. RPI3 support itself is That snapshot supports the serial interface, but it has no modules build not does it have support for the ethernet interface. > very immature at this point. Only one of the four cores is activated. > I'm sure Andrew Turner and others could probably shed more light on > what work has been done and what's left to do. That would be great. Especially, if the RPI-3 is on their agenda... Best regards Michael > > Thanks, > > -- > Shawn Webb > HardenedBSD > > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE From owner-freebsd-arm@freebsd.org Wed Mar 23 15:02:08 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB37BADA9EB for ; Wed, 23 Mar 2016 15:02:08 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) Received: from mail-01.thismonkey.com (mail-01.thismonkey.com [220.244.217.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mail-01.thismonkey.com", Issuer "Thismonkey IT Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0BA8C1D1C for ; Wed, 23 Mar 2016 15:02:07 +0000 (UTC) (envelope-from freebsd-lists-5@thismonkey.com) X-TM-Via-MX: mail-01.thismonkey.com DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=thismonkey.com; s=mail-01; t=1458745316; bh=Gtz5OdVMHR767Bhbnd+yBkgxAIwbiT4ZEcv8vm2LO6Q=; h=Date:From:To:Subject:References:In-Reply-To; b=OZxbFokIb0LRbHPFN8EiwwhTvUxpeeojLoVC5LJqlM1rRruieTPcbPeLDjqjJ2pCP Y9UYoPi1wFsJegdGaOTyA7r09/bMKA62XhGqZCg9OyhJWmDBQfoR6qG8udT9cqB67K S+De0C85wc/xjwbzJoaazZFfJ/cIurPheWwhkA68= DMARC-Filter: OpenDMARC Filter v1.3.0 mail-01.thismonkey.com u2NF1ukN016322 Authentication-Results: mail-01/u2NF1ukN016322; dmarc=none header.from=thismonkey.com Authentication-Results: mail-01; spf=pass smtp.mailfrom=freebsd-lists-5@thismonkey.com Received: from utility-01.thismonkey.com (utility-01.thismonkey.com [10.1.1.32]) by mail-01.thismonkey.com (8.14.9/8.14.9) with ESMTP id u2NF1ukN016322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 24 Mar 2016 02:01:56 +1100 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: from utility-01.thismonkey.com (localhost [127.0.0.1]) by utility-01.thismonkey.com (8.14.9/8.14.9) with ESMTP id u2NF1ua1011455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 24 Mar 2016 02:01:56 +1100 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Received: (from root@localhost) by utility-01.thismonkey.com (8.14.9/8.14.9/Submit) id u2NF1tUp011454 for freebsd-arm@freebsd.org; Thu, 24 Mar 2016 02:01:55 +1100 (EST) (envelope-from freebsd-lists-5@thismonkey.com) Date: Thu, 24 Mar 2016 02:01:55 +1100 From: Scott To: freebsd-arm@freebsd.org Subject: Re: net-mgmt/cdpd failing on RPi (Mika?l Urankar) Message-ID: <20160323150155.GA10429@thismonkey.com> Mail-Followup-To: 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.5.23 (2014-03-12) X-Greylist: inspected by milter-greylist-4.5.11 (mail-01.thismonkey.com [10.1.2.50]); Thu, 24 Mar 2016 02:01:56 +1100 (EST) for IP:'10.1.1.32' DOMAIN:'utility-01.thismonkey.com' HELO:'utility-01.thismonkey.com' FROM:'freebsd-lists-5@thismonkey.com' RCPT:'' X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.11 (mail-01.thismonkey.com [10.1.2.50]); Thu, 24 Mar 2016 02:01:56 +1100 (EST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 15:02:08 -0000 > > Hi all, > > > > I've compiled net-mgmt/cdpd (cdpd-1.0.4.1) on the system: > > FreeBSD network-01.thismonkey.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 > > r287930: Fri Sep 18 04:03:40 UTC 2015 > > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm > > > > and when I run it it simply genereates its help message and exits. > > Hi, > see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208216 > Hi! Thanks for the quick reply. That patch worked perfectly, thanks. Just for my education: did the truss output assist at all? If so, what was the relevant line(s) that led to the patch? Scott From owner-freebsd-arm@freebsd.org Wed Mar 23 15:29:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAB51ADAF4F for ; Wed, 23 Mar 2016 15:29:48 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8C8931961 for ; Wed, 23 Mar 2016 15:29:48 +0000 (UTC) (envelope-from mikael.urankar@gmail.com) Received: by mail-yw0-x231.google.com with SMTP id g127so24155131ywf.2 for ; Wed, 23 Mar 2016 08:29: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:from:date:message-id:subject:to; bh=z7qFoVb9ZNTy5Wy1oZwJx/3ogSrZ8mhIvWjFHqukRmE=; b=xGRB51Ju4RJGq9Tg2bP+9Rs4mN5MnPGe/Q/DYxYVJhrqvhI3rrCCwbxC/bafw2PwX3 AlJbSc/Zjlb2/aQGBNjbd+8OVtSxAKzfEwMRBxzTBfgmm+wFjsvTkJRds7KoA8yCmKGM YX8yAOSBsNXYUhC/udzyLDmhIhbmJAnFWyElJH246i/HmdrtFZq1XEQ0azMh2LyySy15 ULlxCdWDr8ZKXW2Hu586loZnyN/RCd0/RmPhlsxF+cjg4Yrh0l+pCV1p+XqvrXDB1Yna ng4WTUQjHqFcS2hwH2uJPk4sQ4fx8bJjjq2+suViGcQWnjoW6xKEmzbgFBfhGHUSGbSk ysFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=z7qFoVb9ZNTy5Wy1oZwJx/3ogSrZ8mhIvWjFHqukRmE=; b=iUE8zf1ZcqWuSjSlMrYKowcl8VcuCzuOkIhIImAGkZSbr+ctHuqNN8rkk6ly7Clcuk OBAUD495cG8FS+AD83+ZagvdQbnnrc9iStEjepBMcsW3E8/ISSQuNo9F1GP0D3NuN004 /Tl2dLMVBVbkvcXWB5OpY7FX/rPGQDAGAsXsUekyTsmOMzQid6DD5vpXQVswkgXbYcV4 q+PwQfPZZDVoBq7GPBKeyZ7Dv1zg10qFX7jKCwXGGwuEVJPitVYe00yLkJihrEDCJ+Km bxH2k47ziI6QiPxjY+0ulp1KMUDBoXcO1kfIo/JF5Xsxladcuua+10nOBNDb5fXUQcSE Aedw== X-Gm-Message-State: AD7BkJLXPgK0yL7wID87Qbx1Hj6svHu4pTnfBUJJqu104wIQS20x8TeQ665FHOAjJTbIXE9us0DStMvudfvFKg== X-Received: by 10.129.53.145 with SMTP id c139mr1657272ywa.170.1458746987716; Wed, 23 Mar 2016 08:29:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.36.198 with HTTP; Wed, 23 Mar 2016 08:29:08 -0700 (PDT) In-Reply-To: <20160323150155.GA10429@thismonkey.com> References: <20160323150155.GA10429@thismonkey.com> From: =?UTF-8?Q?Mika=C3=ABl_Urankar?= Date: Wed, 23 Mar 2016 16:29:08 +0100 Message-ID: Subject: Re: net-mgmt/cdpd failing on RPi (Mika?l Urankar) To: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 15:29:48 -0000 2016-03-23 16:01 GMT+01:00 Scott : >> > Hi all, >> > >> > I've compiled net-mgmt/cdpd (cdpd-1.0.4.1) on the system: >> > FreeBSD network-01.thismonkey.com 11.0-CURRENT FreeBSD 11.0-CURRENT #0 >> > r287930: Fri Sep 18 04:03:40 UTC 2015 >> > root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/RPI2 arm >> > >> > and when I run it it simply genereates its help message and exits. >> >> Hi, >> see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208216 >> > Hi! > > Thanks for the quick reply. That patch worked perfectly, thanks. > > Just for my education: did the truss output assist at all? If so, what was > the relevant line(s) that led to the patch? truss was of no help. The warning in the build log [1] led me on track: cdpd.c:617:43: warning: comparison of constant -1 with expression of type 'char' is always true [-Wtautological-constant-out-of-range-compare] while((c=getopt(argc,argv,"i:dt:hoalcr"))!=EOF) { [1] http://beefy8.nyi.freebsd.org/data/head-armv6-default/p410528_s296455/logs/cdpd-1.0.4.1.log From owner-freebsd-arm@freebsd.org Wed Mar 23 15:31:53 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3EA51ADB050 for ; Wed, 23 Mar 2016 15:31:53 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 2C68C1AA4 for ; Wed, 23 Mar 2016 15:31:52 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id 262EF239E57; Wed, 23 Mar 2016 11:31:52 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT, URIBL_BLOCKED shortcircuit=ham autolearn=disabled version=3.4.1 Received: from [127.0.0.1] (vnat600.ejoco.com [166.108.32.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.lifanov.com (Postfix) with ESMTPSA id 749F1239440; Wed, 23 Mar 2016 11:31:47 -0400 (EDT) Subject: Re: does arm64-rpi3 snapshot work? To: Michael Tuexen , Shawn Webb References: <56F29377.8060202@mail.lifanov.com> <20160323130444.GA65661@mutt-hardenedbsd> <87B9563B-2B16-4C2D-8C45-A9A97E3A8DC5@fh-muenster.de> Cc: freebsd-arm@freebsd.org From: Nikolai Lifanov Message-ID: <56F2B6E2.70306@mail.lifanov.com> Date: Wed, 23 Mar 2016 11:31:46 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <87B9563B-2B16-4C2D-8C45-A9A97E3A8DC5@fh-muenster.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 15:31:53 -0000 On 03/23/16 10:06, Michael Tuexen wrote: >> On 23 Mar 2016, at 14:04, Shawn Webb wrote: >> >> On Wed, Mar 23, 2016 at 09:00:39AM -0400, Nikolai Lifanov wrote: >>> I tried booting my Raspberry Pi 3 with this snapshot: >>> https://people.freebsd.org/~andrew/arm64/rpi3-20160306.img.xz >>> >>> I also tried to build one from this branch: >>> https://github.com/zxombie/freebsd/commits/arm64-rpi3 >>> >>> I tried updating to the latest firmware, but I still get a >>> rainbow screen every time. >>> >>> Is there anything obvious that I'm missing? >> >> Hey Nikolai, >> >> I believe the snapshots are meant more for connecting a serial cable up >> to the RPI3 rather than using the HDMI output. RPI3 support itself is > That snapshot supports the serial interface, but it has no modules build > not does it have support for the ethernet interface. Ohh, no ethernet! I was waiting for my RJ45 lights to start blinking to find out that the board is booting... >> very immature at this point. Only one of the four cores is activated. >> I'm sure Andrew Turner and others could probably shed more light on >> what work has been done and what's left to do. > That would be great. Especially, if the RPI-3 is on their agenda... > > Best regards > Michael >> >> Thanks, >> >> -- >> Shawn Webb >> HardenedBSD >> >> GPG Key ID: 0x6A84658F52456EEE >> GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > - Nikolai Lifanov From owner-freebsd-arm@freebsd.org Wed Mar 23 15:38:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9A3EADB100 for ; Wed, 23 Mar 2016 15:38:04 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A2E7B1DFC for ; Wed, 23 Mar 2016 15:38:04 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 3fb51e9f-f10d-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 23 Mar 2016 15:38:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2NFbu0w014223; Wed, 23 Mar 2016 09:37:56 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458747476.1091.35.camel@freebsd.org> Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 From: Ian Lepore To: Borodin Oleg , freebsd-arm@freebsd.org Date: Wed, 23 Mar 2016 09:37:56 -0600 In-Reply-To: <20160323100232.00576347@zee.home> References: <20160323012413.GA86944@www.zefox.net> <20160323100232.00576347@zee.home> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 15:38:05 -0000 On Wed, 2016-03-23 at 10:02 +0200, Borodin Oleg wrote: > On Wed, 23 Mar 2016 00:49:03 -0300 > Luiz Otavio O Souza wrote: > > > On 22 March 2016 at 22:24, bob prohaska wrote: > > > > > > Is there a way to operate an RPI2 single user with the HDMI > > > monitor > > > and a USB keyboard? > > > > Try this: > > > > # sysctl kern.console=ttyv0 > > > > and then: > > > > # shutdown now > > > How use usb keyboard _before_ kernel loading, with uboot/loader? > That cannot be done, because u-boot still doesn't have support for low -speed usb devices on rpi. At least, it didn't last time I checked (in January), I think there's a new version of u-boot out, I'll try to find time to test it soon. -- Ian From owner-freebsd-arm@freebsd.org Wed Mar 23 16:09:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC493ADB80C for ; Wed, 23 Mar 2016 16:09:18 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 823C11C3A for ; Wed, 23 Mar 2016 16:09:18 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x22f.google.com with SMTP id z68so25426006vkg.3 for ; Wed, 23 Mar 2016 09:09:18 -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; bh=NwpiMf3Pt5Dax/a6ysWfhw1RxUa6kzXFoDwXdj1Cb5U=; b=S3wTrHImxbJLpIe8n9Nq+s9bKjI2zsfzs2xk0MKp1WvFmRYgAZevq8GPRDTngjzQAz 2MIMxi4L2fu9/z3ZfHv4eurEIKoK8vF0+cf8ZHeCqsoSskd1sHrU/W64dQjcMTLzUM4B sSes/BOgwrmJoRTu9iJ7F70c+EwD0NQZI+lGG46IkF5TsnrIdtxH2NWGdBbG7y3WqVnl dZTw4+f9Lm69+6pYOzLbhBf0t3zcDtPchyY4aBi1DmpbNpb5PsWgAO5NmGuEb0zcpqKO 9aMEKk7jK0/WxyKZgxI/btmwy1McPJsrDgbXmWc1W46Adtvm3xpSiC1qHZ697st0/c+y rDIw== 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; bh=NwpiMf3Pt5Dax/a6ysWfhw1RxUa6kzXFoDwXdj1Cb5U=; b=ezJM9AudyGc8j+hzsahOLbeMOZmATjRpRDNfB+O1px9wttqvV9bHmPpEhkHBPua4me OY44f/KWJ/8YNeCr78usGZ+p0pU8LS3rxnHqC6qxuYU/YxbQsX36Z9h7VPCT+7Bw6aR3 muUdCkcpiZQQdbBVQrztuVxwe9UgPzPs4UeT2s1d3CEhjE9/jAUhqls77CgMgI505tuS G4pRTncRMQ/94PGMssAJ4dvGrMCUoSOStIQUCngHnB7jmQk3T0L3teWf3xz4tis/le0R UT8O8mWulGo4074yLxKiXVRNxY6hapNvwr0wmpVWXpJrPf0WywQRnkZpR/TzPfiZJ2CV YDrQ== X-Gm-Message-State: AD7BkJKlKQtQc4AeMpOVCjGsv5aDA3lB/UBUcTlvYUED7Yks+4vfmzoE5uj1DMIvgAcT2x2HBb+kUHBzR9jstw== MIME-Version: 1.0 X-Received: by 10.31.8.205 with SMTP id 196mr2007574vki.144.1458749357568; Wed, 23 Mar 2016 09:09:17 -0700 (PDT) Received: by 10.31.54.13 with HTTP; Wed, 23 Mar 2016 09:09:17 -0700 (PDT) In-Reply-To: References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> Date: Wed, 23 Mar 2016 09:09:17 -0700 Message-ID: Subject: Re: Fwd: SDIO Patch D4761.diff Not Building For Me From: Russell Haley To: Ilya Bakulin Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 16:09:18 -0000 On Wed, Mar 23, 2016 at 4:00 AM, Ilya Bakulin wrote: > On 2016-03-23 06:16, Russell Haley wrote: >> >> Hi Ilya, >> >> Mixed success tonight. I tried to install the kernel but got an error: > > > You should give MODULES_OVERRIDE= to installkernel as well. > Great, Thank you. >> >> Well, it booted the kernel and then spewed output and eventually ended >> with a failed DHCP request (?). Here is the pastebin of said output. >> > > I never copy the newly built kernel to the SD card. > Instead I configure U-Boot+ubldr to boot kernel from TFTP and mount root > over NFS, it's much faster and it's impossible to crash filesystem if the > kernel crashes. > I guess you should set ROOTDEVNAME manually in the kernel config file and > disable NFSCLIENT-related options. Thanks for this advice. I have had something similar working before (I had rootfs on USB) so should be able to get that running this weekend > From your boot log it's clear that the system boots and probes SD cards. Yes, very exciting to see!!! I will be looking to try and match debug output with code paths asap. > There are two slots and none of them has SDIO card in it. > From what I find about Hummingboard, it actually doesn't have WiFi SDIO > chips on it. I don't understand. It was booted using an SD card? Also, here is the information about the board and the Wi-Fi (the Solid-Run site can be hard to navigate): Carrier Board spec: http://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard:hbpro This is my SOM: http://wiki.solid-run.com/doku.php?id=products:imx6:microsom:dual&s[]=bcm4330 Schematic. I believe page 5 shows the SDIO WIFI module interface? http://wiki.solid-run.com/lib/exe/fetch.php?media=imx6:microsom:docs:sr-usom-mx6-rev-1_3-simplified-schematics.pdf Broadcom BCM4330 http://linux-sunxi.org/images/0/05/4330-DS206-R.pdf I have used it successfully through Kodi and Debian (Raspbian specifically) Thanks, Russ From owner-freebsd-arm@freebsd.org Wed Mar 23 16:43:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 751FBADBEE7 for ; Wed, 23 Mar 2016 16:43:41 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 546C01FCE for ; Wed, 23 Mar 2016 16:43:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 6a3d858f-f116-11e5-b278-7d22021d92d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Wed, 23 Mar 2016 16:43:47 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2NGhYJL014306; Wed, 23 Mar 2016 10:43:34 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458751414.1091.47.camel@freebsd.org> Subject: Re: about netbooting on armv6 [was: Fwd: SDIO Patch D4761.diff Not Building For Me] From: Ian Lepore To: Russell Haley , Ilya Bakulin Cc: freebsd-arm Date: Wed, 23 Mar 2016 10:43:34 -0600 In-Reply-To: References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 16:43:41 -0000 On Wed, 2016-03-23 at 09:09 -0700, Russell Haley wrote: > On Wed, Mar 23, 2016 at 4:00 AM, Ilya Bakulin > wrote: > > On 2016-03-23 06:16, Russell Haley wrote: > > > > > > Hi Ilya, > > > > > > Mixed success tonight. I tried to install the kernel but got an > > > error: > > > > > > You should give MODULES_OVERRIDE= to installkernel as well. > > > Great, Thank you. > > > > > > Well, it booted the kernel and then spewed output and eventually > > > ended > > > with a failed DHCP request (?). Here is the pastebin of said > > > output. > > > > > > > I never copy the newly built kernel to the SD card. > > Instead I configure U-Boot+ubldr to boot kernel from TFTP and mount > > root > > over NFS, it's much faster and it's impossible to crash filesystem > > if the > > kernel crashes. > > I guess you should set ROOTDEVNAME manually in the kernel config > > file and > > disable NFSCLIENT-related options. > > Thanks for this advice. I have had something similar working before > (I > had rootfs on USB) so should be able to get that running this weekend > > > From your boot log it's clear that the system boots and probes SD > > cards. > > Yes, very exciting to see!!! I will be looking to try and match debug > output with code paths asap. > > > There are two slots and none of them has SDIO card in it. > > From what I find about Hummingboard, it actually doesn't have WiFi > > SDIO > > chips on it. > > I don't understand. It was booted using an SD card? Also, here is the > information about the board and the Wi-Fi (the Solid-Run site can be > hard to navigate): > > Carrier Board spec: > http://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard:hbpr > o > > This is my SOM: > http://wiki.solid-run.com/doku.php?id=products:imx6:microsom:dual&s[] > =bcm4330 > > Schematic. I believe page 5 shows the SDIO WIFI module interface? > http://wiki.solid-run.com/lib/exe/fetch.php?media=imx6:microsom:docs: > sr-usom-mx6-rev-1_3-simplified-schematics.pdf > > Broadcom BCM4330 > http://linux-sunxi.org/images/0/05/4330-DS206-R.pdf > > I have used it successfully through Kodi and Debian (Raspbian > specifically) > > Thanks, > Russ The quick and easy config for netbooting armv6 these days is to set a few vars in your uboot env. This assumes that you let uboot load ubldr.bin from sdcard, and then have ubldr load the kernel and the kernel will mount nfsroot. If you have a dhcp server to provide an IP, this is all you need in uboot env: loaderdev=net rootpath=:/ If you manually configure the ip, add these: ipaddr= netmask=255.etc.etc.etc When ubldr loads the kernel via nfs, it also sets up all the info needed to mount root via nfs and passes the info to the kernel in env vars. It will also set vfs.root.mountfrom to the server:path you set in the rootpath var in uboot, which gets the initial root fs mount done. You still need an /etc/fstab that also has the nfs mount info for the nfsroot, so that the rc scripts can remount root writable. All you need in the kernel config is options NFSCL, NFSLOCKD, NFS_ROOT and all of those are already standard in all armv6 kernels. You don't need to change the ROOTDEVNAME option because the vfs.root.mountfrom overrides it (ROOTDEVNAME is used as a fallback if the nfs mount fails). -- Ian From owner-freebsd-arm@freebsd.org Wed Mar 23 18:22:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5C5BDADB2DC for ; Wed, 23 Mar 2016 18:22:38 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 051D310D7; Wed, 23 Mar 2016 18:22:37 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2NIMZaO093814; Wed, 23 Mar 2016 11:22:35 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2NIMZWe093813; Wed, 23 Mar 2016 11:22:35 -0700 (PDT) (envelope-from fbsd) Date: Wed, 23 Mar 2016 11:22:35 -0700 From: bob prohaska To: Ian Lepore Cc: Borodin Oleg , freebsd-arm@freebsd.org, bob prohaska Subject: Re: Using one RPI2 as a serial terminal for a second RPI2 Message-ID: <20160323182235.GF86944@www.zefox.net> References: <20160323012413.GA86944@www.zefox.net> <20160323100232.00576347@zee.home> <1458747476.1091.35.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1458747476.1091.35.camel@freebsd.org> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 18:22:38 -0000 On Wed, Mar 23, 2016 at 09:37:56AM -0600, Ian Lepore wrote: > On Wed, 2016-03-23 at 10:02 +0200, Borodin Oleg wrote: > > On Wed, 23 Mar 2016 00:49:03 -0300 > > Luiz Otavio O Souza wrote: > > > > > On 22 March 2016 at 22:24, bob prohaska wrote: > > > > > > > > Is there a way to operate an RPI2 single user with the HDMI > > > > monitor > > > > and a USB keyboard? > > > > > > Try this: > > > > > > # sysctl kern.console=ttyv0 > > > > > > and then: > > > > > > # shutdown now > > > > > > How use usb keyboard _before_ kernel loading, with uboot/loader? > > > > That cannot be done, because u-boot still doesn't have support for low > -speed usb devices on rpi. At least, it didn't last time I checked (in > January), I think there's a new version of u-boot out, I'll try to find > time to test it soon. > > -- Ian I just tried it over a serial console at the single-user prompt, the HDMI display and USB keyboard didn't react at all: # mount -a # sysctl kern.console=ttyv0 kern.console: ttyu0,ttyv0,/ttyu0,ttyv0, -> ttyv0,ttyu0,/ttyu0,ttyv0, but no change at the keyboard or display. Next I tried rebooting and presenting the command to the U-boot prompt. It reacted with an error message: Rebooting... U-Boot 2015.04 (May 30 2015 - 22:13:58) DRAM: 944 MiB WARNING: Caches not enabled RPI 2 Model B MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 U-Boot> sysctl kern.console=ttyv0 Unknown command 'sysctl' - try 'help' U-Boot> Might this have something to do with the "**unable to read...." warning? Boots seem to work despite the error. If the command merely suffices to allow the FreeBSD kernel to interact with the USB keyboard and HDMI console in single user mode that would be a huge step forward. There has been no need to intervene with U-boot. All that's required is a way to recover from startup errors that put the system in single-user mode. Could it be invoked by something akin to device hints? Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Mar 23 19:03:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8955BADB8F8 for ; Wed, 23 Mar 2016 19:03:35 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5775C119F; Wed, 23 Mar 2016 19:03:35 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pa0-x235.google.com with SMTP id tt10so2344614pab.3; Wed, 23 Mar 2016 12:03:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to:cc; bh=Yn8DcvAW9Wn66/8bQLxQJsjqaqM5LUu4WYx5MaZivRE=; b=nfSHmfiXKzyJsv8t8rnHGXUpTm3Fh5rce+OTCSJP38utmExiPOEWJy78WM8WxPRmmn AZpxPqDQ1Ji2hBPPKcZ4IQfCKdWRXtsQqsXOpwKr2+77j+MNLPmBtHqAzHzQBHB6igzJ Rg3ssh3eDJng9XqTAdhwXuWTib5U9RNpMscytZL2mwltpeEXelRJM/mI7TxeFJpTYOYB t8MW55mfMS6YLYEaVtjildloumsQ3lXbCNT3CHu94QHPRghtWKqtVheTPYxeKeGvs6ps lfvp19oGM8sL7DyV3WqB2D7braeEZ2N5e8SszxJaUN48eN6KbGdl0ofPNsbW8eOsAAsC qbjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to:cc; bh=Yn8DcvAW9Wn66/8bQLxQJsjqaqM5LUu4WYx5MaZivRE=; b=cjtT2LWAlb4v10Tc2s6XC+DrPu2v2QOTkLaFb0zfYnS1xG4gUu6JftV2k5GZYRGlz5 MinjghdIFRcFDlwyZMGh9LQHnLDLqh5NSTJY3KcsGgyU6+OvlKE/F0FxOVITwAy0JXWD jZ7AsloYNx5qhnTaQaC2RWS2YDEVp6ePzZHkdrWEZwJ5xeo0GiPp/kGZOyKorBPuxEge Pe5aOtpjX84P5FD4TLIGawFtW/nnqTr/ri+J3i9G2MsSmp9nyO5wEU3Pftr0Fb/DFFXR livlums4ng5EzBf0onMrCprkQAs7JjX3sbvGs8o0xmN+pb2Ked+Bk0S4zd1p3EqtoQBa TuDg== X-Gm-Message-State: AD7BkJIjHajFIdVGUrbFYJwQgSTvd0mU2IyTT8PjekZNwqWyYMxhZjmZsRykLcUrFbnEyw== X-Received: by 10.66.248.198 with SMTP id yo6mr6499445pac.54.1458759814826; Wed, 23 Mar 2016 12:03:34 -0700 (PDT) Received: from [127.0.0.1] (mail.questertangent.com. [184.69.10.202]) by smtp.gmail.com with ESMTPSA id u21sm5859776pfa.60.2016.03.23.12.03.33 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Mar 2016 12:03:34 -0700 (PDT) Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160323190333.4370514.70354.4134@gmail.com> Date: Wed, 23 Mar 2016 12:03:33 -0700 Subject: Re: about netbooting on armv6 [was: Fwd: SDIO Patch D4761.diff Not Building For Me] From: Russell Haley In-Reply-To: <1458751414.1091.47.camel@freebsd.org> References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> <1458751414.1091.47.camel@freebsd.org> To: Ian Lepore , Ilya Bakulin Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2016 19:03:35 -0000 Awesome. Thanks, Ian! Now I have to decide if I want to sleep tonight or tr= y netbooting. Nah, I'll sleep when I'm dead... Russ Sent=A0from=A0my=A0BlackBerry=A010=A0smartphone=A0on=A0the=A0Koodo=A0networ= k. =A0 Original Message =A0 From: Ian Lepore Sent: Wednesday, March 23, 2016 9:43 AM To: Russell Haley; Ilya Bakulin Cc: freebsd-arm Subject: Re: about netbooting on armv6 [was: Fwd: SDIO Patch D4761.diff Not= Building For Me] On Wed, 2016-03-23 at 09:09 -0700, Russell Haley wrote: > On Wed, Mar 23, 2016 at 4:00 AM, Ilya Bakulin > wrote: > > On 2016-03-23 06:16, Russell Haley wrote: > > >=20 > > > Hi Ilya, > > >=20 > > > Mixed success tonight. I tried to install the kernel but got an > > > error: > >=20 > >=20 > > You should give MODULES_OVERRIDE=3D to installkernel as well. > >=20 > Great, Thank you. > > >=20 > > > Well, it booted the kernel and then spewed output and eventually > > > ended > > > with a failed DHCP request (?). Here is the pastebin of said > > > output. > > >=20 > >=20 > > I never copy the newly built kernel to the SD card. > > Instead I configure U-Boot+ubldr to boot kernel from TFTP and mount > > root > > over NFS, it's much faster and it's impossible to crash filesystem > > if the > > kernel crashes. > > I guess you should set ROOTDEVNAME manually in the kernel config > > file and > > disable NFSCLIENT-related options. >=20 > Thanks for this advice. I have had something similar working before > (I > had rootfs on USB) so should be able to get that running this weekend >=20 > > From your boot log it's clear that the system boots and probes SD > > cards. >=20 > Yes, very exciting to see!!! I will be looking to try and match debug > output with code paths asap. >=20 > > There are two slots and none of them has SDIO card in it. > > From what I find about Hummingboard, it actually doesn't have WiFi > > SDIO > > chips on it. >=20 > I don't understand. It was booted using an SD card? Also, here is the > information about the board and the Wi-Fi (the Solid-Run site can be > hard to navigate): >=20 > Carrier Board spec: > http://wiki.solid-run.com/doku.php?id=3Dproducts:imx6:hummingboard:hbpr > o >=20 > This is my SOM: > http://wiki.solid-run.com/doku.php?id=3Dproducts:imx6:microsom:dual&s[] > =3Dbcm4330 >=20 > Schematic. I believe page 5 shows the SDIO WIFI module interface? > http://wiki.solid-run.com/lib/exe/fetch.php?media=3Dimx6:microsom:docs: > sr-usom-mx6-rev-1_3-simplified-schematics.pdf >=20 > Broadcom BCM4330 > http://linux-sunxi.org/images/0/05/4330-DS206-R.pdf >=20 > I have used it successfully through Kodi and Debian (Raspbian > specifically) >=20 > Thanks, > Russ The quick and easy config for netbooting armv6 these days is to set a few vars in your uboot env. This assumes that you let uboot load ubldr.bin from sdcard, and then have ubldr load the kernel and the kernel will mount nfsroot. If you have a dhcp server to provide an IP, this is all you need in uboot env: loaderdev=3Dnet rootpath=3D:/ If you manually configure the ip, add these: ipaddr=3D netmask=3D255.etc.etc.etc When ubldr loads the kernel via nfs, it also sets up all the info needed to mount root via nfs and passes the info to the kernel in env vars. It will also set vfs.root.mountfrom to the server:path you set in the rootpath var in uboot, which gets the initial root fs mount done. You still need an /etc/fstab that also has the nfs mount info for the nfsroot, so that the rc scripts can remount root writable. All you need in the kernel config is options NFSCL, NFSLOCKD, NFS_ROOT and all of those are already standard in all armv6 kernels. You don't need to change the ROOTDEVNAME option because the vfs.root.mountfrom overrides it (ROOTDEVNAME is used as a fallback if the nfs mount fails). -- Ian From owner-freebsd-arm@freebsd.org Thu Mar 24 04:05:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD314AD6989 for ; Thu, 24 Mar 2016 04:05:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8B6571F31 for ; Thu, 24 Mar 2016 04:05:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22e.google.com with SMTP id c63so77243263iof.0 for ; Wed, 23 Mar 2016 21:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=GG/WScSjcfWtomP7tAMnNttPN6Np/Hv5CrQw5rtsNmo=; b=sQJdYh0oWXfIbzE2CYBnmHqH5O9U2dUQLv6ydf3rSSJ88daY9bMnx/VKtnwCJQHN+B cn+PDKqw7Vg7SOn72KMhB08n7/YJGRqs0OdNPlc3Yr6nflRH4tf9T1OaTcGSIxT9OV2h MD0dl4KjRJEZLCK5cFZ9rjSFOBj8b+ixkitvugfKnEOXimXsW/axPKs4GHW+Xl66QZ6Q C3NCJSowGZg3aOl1w9KLQrHTj39SJKa3WpAd3zCe9gbmcbgKOzttrc3XSJaC43jmpA2E 3mT8OXPx2iEUg7r0GtUPLMS5cpMDulsZAD67mdWhQFPrQWJJKiIaPds9RLdl6mfQULk5 R6tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GG/WScSjcfWtomP7tAMnNttPN6Np/Hv5CrQw5rtsNmo=; b=cT0i6MhTjAbvLuiyqP+UK3h14yyAM48f0GK4/4tgSxD1X6A1JEHCeOMKPGT6hO4nO6 yzAETEThBJwqDHx2T4OCoAZdIlMfBMlL/4m24Pc4BOxpCOXPRmLBsKGtRwE5J1hz0s/V MZx/2J3j8CJCegyOPtdnWCoGuUf+mv0OhV2zv5r1aQ3MjHxHsCbLO50bMF2oXwtuyDhJ TaqUsBHK2H47Vy8XbSma6j+WmoVc0v4tvM5mtAc4QZTmILV4O44IUgFuhvITOkrSjYlE VIPIQi4Aq+3rH+PH7tUY95ZfESPKkBaEa5IHLTMTMalix96W8XvGZosm3g75QCEGntOh W8zg== X-Gm-Message-State: AD7BkJKVFrpunKOihzehXm1h3j7W1lvzBQ8l+AJRfRlCxMdmImQ66FnpxxLky01tFEZowDx8n8Xz2YYXZfCF2A== MIME-Version: 1.0 X-Received: by 10.107.14.209 with SMTP id 200mr6617630ioo.73.1458792311757; Wed, 23 Mar 2016 21:05:11 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Wed, 23 Mar 2016 21:05:11 -0700 (PDT) X-Originating-IP: [50.253.99.174] Received: by 10.36.65.230 with HTTP; Wed, 23 Mar 2016 21:05:11 -0700 (PDT) In-Reply-To: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <201603230349.VAA20311@mail.lariat.net> Date: Wed, 23 Mar 2016 22:05:11 -0600 X-Google-Sender-Auth: 0f_PB6H_cTenffsFDqAe9hGJ940 Message-ID: Subject: Re: Effect of partitioning on wear-leveling From: Warner Losh To: Oliver Psotta Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 04:05:12 -0000 When you have a fleet of thousands of ssds, you'll get failures no matter the quality... Warner On Mar 23, 2016 1:55 AM, "Oliver Psotta" wrote: > Which SSDs failed on you, Warner? There sure are some rotten apples, > but the Samsung 840 pro, for example, were (are) quite reliable. > > -Oliver > > > On 23 Mar 2016, at 07:45, Warner Losh wrote: > > > > Hope your SSDs are better at reporting things than ours. We've seen some > > SSDs > > just fail even though the previous SMART data said we've used maybe 20% > of > > the > > drive's write ability.... > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Thu Mar 24 08:08:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4E0AADCA03 for ; Thu, 24 Mar 2016 08:08:37 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 37E551BE1; Thu, 24 Mar 2016 08:08:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from chamsa.cs.huji.ac.il ([132.65.80.19]) by kabab.cs.huji.ac.il with esmtp id 1aj0BZ-000FYl-BX; Thu, 24 Mar 2016 10:00:05 +0200 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: about netbooting on armv6 [was: Fwd: SDIO Patch D4761.diff Not Building For Me] From: Daniel Braniss In-Reply-To: <1458751414.1091.47.camel@freebsd.org> Date: Thu, 24 Mar 2016 10:00:05 +0200 Cc: Russell Haley , Ilya Bakulin , freebsd-arm Message-Id: References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> <1458751414.1091.47.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 08:08:37 -0000 > On 23 Mar 2016, at 18:43, Ian Lepore wrote: >=20 > On Wed, 2016-03-23 at 09:09 -0700, Russell Haley wrote: >> On Wed, Mar 23, 2016 at 4:00 AM, Ilya Bakulin >> wrote: >>> On 2016-03-23 06:16, Russell Haley wrote: >>>>=20 >>>> Hi Ilya, >>>>=20 >>>> Mixed success tonight. I tried to install the kernel but got an >>>> error: >>>=20 >>>=20 >>> You should give MODULES_OVERRIDE=3D to installkernel as well. >>>=20 >> Great, Thank you. >>>>=20 >>>> Well, it booted the kernel and then spewed output and eventually >>>> ended >>>> with a failed DHCP request (?). Here is the pastebin of said >>>> output. >>>>=20 >>>=20 >>> I never copy the newly built kernel to the SD card. >>> Instead I configure U-Boot+ubldr to boot kernel from TFTP and mount >>> root >>> over NFS, it's much faster and it's impossible to crash filesystem >>> if the >>> kernel crashes. >>> I guess you should set ROOTDEVNAME manually in the kernel config >>> file and >>> disable NFSCLIENT-related options. >>=20 >> Thanks for this advice. I have had something similar working before >> (I >> had rootfs on USB) so should be able to get that running this weekend >>=20 >>> =46rom your boot log it's clear that the system boots and probes SD >>> cards. >>=20 >> Yes, very exciting to see!!! I will be looking to try and match debug >> output with code paths asap. >>=20 >>> There are two slots and none of them has SDIO card in it. >>> =46rom what I find about Hummingboard, it actually doesn't have WiFi >>> SDIO >>> chips on it. >>=20 >> I don't understand. It was booted using an SD card? Also, here is the >> information about the board and the Wi-Fi (the Solid-Run site can be >> hard to navigate): >>=20 >> Carrier Board spec: >> http://wiki.solid-run.com/doku.php?id=3Dproducts:imx6:hummingboard:hbpr= >> o >>=20 >> This is my SOM: >> http://wiki.solid-run.com/doku.php?id=3Dproducts:imx6:microsom:dual&s[]= >> =3Dbcm4330 >>=20 >> Schematic. I believe page 5 shows the SDIO WIFI module interface? >> http://wiki.solid-run.com/lib/exe/fetch.php?media=3Dimx6:microsom:docs:= >> sr-usom-mx6-rev-1_3-simplified-schematics.pdf >>=20 >> Broadcom BCM4330 >> http://linux-sunxi.org/images/0/05/4330-DS206-R.pdf >>=20 >> I have used it successfully through Kodi and Debian (Raspbian >> specifically) >>=20 >> Thanks, >> Russ >=20 > The quick and easy config for netbooting armv6 these days is to set a > few vars in your uboot env. This assumes that you let uboot load > ubldr.bin from sdcard, and then have ubldr load the kernel and the > kernel will mount nfsroot. >=20 > If you have a dhcp server to provide an IP, this is all you need in > uboot env: >=20 > loaderdev=3Dnet > rootpath=3D:/ you can set the footpath via dhcp / dhcpd.conf: option root-path =E2=80=9Cnfs:ip.root.host:/path-to-root=E2=80=9D; >=20 > If you manually configure the ip, add these: >=20 > ipaddr=3D > netmask=3D255.etc.etc.etc >=20 > When ubldr loads the kernel via nfs, it also sets up all the info > needed to mount root via nfs and passes the info to the kernel in env > vars. It will also set vfs.root.mountfrom to the server:path you set > in the rootpath var in uboot, which gets the initial root fs mount > done. You still need an /etc/fstab that also has the nfs mount info > for the nfsroot, so that the rc scripts can remount root writable. >=20 > All you need in the kernel config is options NFSCL, NFSLOCKD, NFS_ROOT > and all of those are already standard in all armv6 kernels. You don't > need to change the ROOTDEVNAME option because the vfs.root.mountfrom > overrides it (ROOTDEVNAME is used as a fallback if the nfs mount > fails). >=20 > -- Ian >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Thu Mar 24 12:16:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 725F1ADB19F for ; Thu, 24 Mar 2016 12:16:48 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1D2B21CD2 for ; Thu, 24 Mar 2016 12:16:47 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from macbook.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id 45D3A956; Thu, 24 Mar 2016 08:16:46 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Effect of partitioning on wear-leveling From: Paul Mather In-Reply-To: Date: Thu, 24 Mar 2016 08:16:45 -0400 Cc: Oliver Psotta , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160321175952.GA83908@www.zefox.net> <1458586884.68920.96.camel@freebsd.org> <20160321221153.GB83908@www.zefox.net> <1458600070.68920.107.camel@freebsd.org> <1973487B-0AA7-468D-A9CC-319FBE2122F0@netgate.com> <20160322033417.GD83908@www.zefox.net> <201603230349.VAA20311@mail.lariat.net> To: Warner Losh X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 12:16:48 -0000 On Mar 24, 2016, at 12:05 AM, Warner Losh wrote: > When you have a fleet of thousands of ssds, you'll get failures no = matter > the quality... Pertinent to discussion of SSD failures is this article about the topic, = which summarises a FAST 2016 paper on the subject: = http://www.zdnet.com/article/ssd-reliability-in-the-real-world-googles-exp= erience/ Here are the "key conclusions" from the ZDNet article (and I quote): "=E2=80=A2 Ignore Uncorrectable Bit Error Rate (UBER) specs. A = meaningless number. =E2=80=A2 Good news: Raw Bit Error Rate (RBER) increases slower than = expected from wearout and is not correlated with UBER or other failures. =E2=80=A2 High-end SLC drives are no more reliable that MLC drives. =E2=80=A2 Bad news: SSDs fail at a lower rate than disks, but UBER rate = is higher (see below for what this means). =E2=80=A2 SSD age, not usage, affects reliability. =E2=80=A2 Bad blocks in new SSDs are common, and drives with a large = number of bad blocks are much more likely to lose hundreds of other = blocks, most likely due to die or chip failure. =E2=80=A2 30-80 percent of SSDs develop at least one bad block and 2-7 = percent develop at least one bad chip in the first four years of = deployment." Cheers, Paul. >=20 > Warner > On Mar 23, 2016 1:55 AM, "Oliver Psotta" = wrote: >=20 >> Which SSDs failed on you, Warner? There sure are some rotten apples, >> but the Samsung 840 pro, for example, were (are) quite reliable. >>=20 >> -Oliver >>=20 >>> On 23 Mar 2016, at 07:45, Warner Losh wrote: >>>=20 >>> Hope your SSDs are better at reporting things than ours. We've seen = some >>> SSDs >>> just fail even though the previous SMART data said we've used maybe = 20% >> of >>> the >>> drive's write ability.... >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >=20 From owner-freebsd-arm@freebsd.org Thu Mar 24 15:29:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 010F6ADC0AC for ; Thu, 24 Mar 2016 15:29:51 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D8F01A6B for ; Thu, 24 Mar 2016 15:29:50 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id p65so71149313wmp.0 for ; Thu, 24 Mar 2016 08:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=ZPLw3jvR44lT7InjEDKFy5Fnut7/vSlyOprs/JIbv2w=; b=wfwWE7vu5VLkGqqirTapHuf7zUGJ/yp3MGGFnUCjQFzIVN1kCcE1/7BwzEcsmrz6PM 18k+ODQU6SrCoutchkISPJmCOzbQdSTKR0Pw5EMArj+9nm8lcIRKjF17Mgjb8zoeSCbX 6FB23txohBXskueCdHnoxfnBjBMv5ByLHB0Bw637zU8cZ+urQCI8enqOhlO++hFNOLzN FBALZUJ4wyiLP0ClG/XSsk2a44Zmsef8A6+GnySWxUVTOk9w99DFOzNNvKTl/3y+dRiY e8SO18WIIa0a+mNytEThHzOwm1X0eikOPglIsHE3aV903xSqltFBkUWFPqo7ohmkSe+1 7PKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=ZPLw3jvR44lT7InjEDKFy5Fnut7/vSlyOprs/JIbv2w=; b=NMXgb++6E1HlxyvQ/w/NyznjeNqVeGMTTufHfq2gxPlZmwjmFI2m+EltpqAlq/4BV3 EZ/2wcpiPft6fwIdOPmSwCygWq9tTBJUR/XxVJ1UkALOwe3Jdtp3pjXEfFPfr5d04cjs NroyZuzSEj3MMBOziQvYsCcy256snJnixWyJkQ/pVARCXgdP41to8BAXVNqev3QbJZsy FxjxEc5bn6N6pgSCyKxMtfohe7cw5ACREHbSJmF45uwZiDKeQ3C5pKhzleUJHR32pcP8 giWJUJdbvCUZT0K3tSxlRcdbbtUZPx5ajoJwQAEdqAsepRHtPfaEcUf3m4RbN1pgULUs 2iQQ== X-Gm-Message-State: AD7BkJKArdn/Cm56mQ+YWY7A/qQQsGXGjm15ajj3yZ13kZ7u3LPxJknsIKzIQstfOzCGBQ== X-Received: by 10.194.201.166 with SMTP id kb6mr10750502wjc.125.1458833368839; Thu, 24 Mar 2016 08:29:28 -0700 (PDT) Received: from [192.168.0.4] ([81.56.235.196]) by smtp.gmail.com with ESMTPSA id y72sm8255510wmh.21.2016.03.24.08.29.26 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Mar 2016 08:29:27 -0700 (PDT) From: Sylvain Garrigues Subject: Booting kernel.bin directly on Raspberry Pi / external DTB support Message-Id: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> Date: Thu, 24 Mar 2016 16:29:26 +0100 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 15:29:51 -0000 Hello, I have written a small (ugly) patch to be able to boot a kernel directly = without the ubldr loader while still using an external DTB (Linux-style = booting may pass the DTB location pointer in the r2 register). The patch is here: https://reviews.freebsd.org/differential/diff/14577/=20= I tested my patch successfully with the QEMU emulator with the -dtb = option available in recent versions, using a VERSATILEPB kernel without = FDT_STATIC. # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash -cpu = arm1176 -dtb versatilepb.dtb FYI, once the kernel is built, here is the script to build the = versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 = registers): https://reviews.freebsd.org/P92 = I also tested successfully my patch on my Raspberry Pi 2 using U-BOOT = and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI = option): u-boot> fatload mmc 0 0x200000 kernel.bin u-boot> go 0x200000 That works. So now I thought I could even bypass u-boot and launch kernel.bin = directly from the Pi firmware=E2=80=A6 But it doesn=E2=80=99t work, I = don=E2=80=99t understand why, and that is why I am writing here. Here is the config.txt which I thought would work: kernel=3Dkernel.bin (instead of u-boot.bin) kernel_address=3D0x200000 (line added because a FreeBSD kernel needs to = be loaded on a 1MB or 2MB boundary) device_tree=3Drpi2.dtb device_tree_address=3D0x100 disable_commandline_tags=3D1 What am I missing? Is it even possible to boot kernel.bin directly on = the Pi (with my patch)? I found this static minimalist loader from = Andrew here: = https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b3= 9acd710c = - does it mean such a loader is necessary before the kernel? Thanks, Sylvain PS: I know the =C2=AB official and supported =C2=BB way of booting = FreeBSD on the Pi is the u-boot + ubldr combination. I just would like = to finish this experiment and understand why kernel.bin cannot be booted = directly.= From owner-freebsd-arm@freebsd.org Thu Mar 24 15:50:27 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEF87ADC7E8 for ; Thu, 24 Mar 2016 15:50:27 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 947A61B19 for ; Thu, 24 Mar 2016 15:50:27 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-f54.google.com with SMTP id u125so18536303wmg.1 for ; Thu, 24 Mar 2016 08:50:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=bIe3MZqGLoDCu8FuNhWgYV3UFlN0BfR2pHXZ97xCdpw=; b=cImLlfQp/yKADaBGiviWfxoVeeJ9x1463FoNErI6UA9pjaVyowQYndisMrDJXiqUwT mNlnbXVAO7b7PvZkkczZz/xLO47NbNzMZAaUlNaTWyaKQ70Qcmq757MRyHoLaRhB+PyY HKZW0sKKNkaFPvQfV/AfLq57N4CZt54Qs8nbku5RGKjHl/sfx6Ej9T1zbYZuhOLX3ujl lgul8zK07ukft/MA1wHNWGT4NvNcblh2qvxMR/cpZzAdXIqrRgK7N4XbChskQxpdFQKh tj86/RFuiSusINJ4JTDY+/VmqSgQ8ITwAbpiEwA0Ti92WuzA46T4bIA+ky55jl1tSFRf vubQ== X-Gm-Message-State: AD7BkJKiftdneb8tsa8ab8Q3LwHYvlX5LlaOIRtbRnaFXm/c4ct/0cvc6n4KDW8uBhzoXQ== X-Received: by 10.194.6.234 with SMTP id e10mr10709351wja.118.1458834281747; Thu, 24 Mar 2016 08:44:41 -0700 (PDT) Received: from [192.168.0.4] ([81.56.235.196]) by smtp.gmail.com with ESMTPSA id c128sm27533134wma.11.2016.03.24.08.44.40 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Mar 2016 08:44:40 -0700 (PDT) From: sylvain@sylvaingarrigues.com Subject: Booting kernel.bin directly on Raspberry Pi / external DTB support Message-Id: <83488D96-F585-4A89-B53A-8E2E60BA3BD3@sylvaingarrigues.com> Date: Thu, 24 Mar 2016 16:44:40 +0100 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 15:50:28 -0000 Hello, I have written a small (ugly) patch to be able to boot a kernel directly = without the ubldr loader while still using an external DTB (Linux-style = booting may pass the DTB location pointer in the r2 register). The patch is here: https://reviews.freebsd.org/differential/diff/14577/ = =20 I tested my patch successfully with the QEMU emulator with the -dtb = option available in recent versions, using a VERSATILEPB kernel without = FDT_STATIC. # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash -cpu = arm1176 -dtb versatilepb.dtb FYI, once the kernel is built, here is the script to build the = versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 = registers): https://reviews.freebsd.org/P92 = I also tested successfully my patch on my Raspberry Pi 2 using U-BOOT = and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI = option): u-boot> fatload mmc 0 0x200000 kernel.bin u-boot> go 0x200000 That works. So now I thought I could even bypass u-boot and launch kernel.bin = directly from the Pi firmware=E2=80=A6 But it doesn=E2=80=99t work, I = don=E2=80=99t understand why, and that is why I am writing here. Here is the config.txt which I thought would work: kernel=3Dkernel.bin (instead of u-boot.bin) kernel_address=3D0x200000 (line added because a FreeBSD kernel needs to = be loaded on a 1MB or 2MB boundary) device_tree=3Drpi2.dtb device_tree_address=3D0x100 disable_commandline_tags=3D1 What am I missing? Is it even possible to boot kernel.bin directly on = the Pi (with my patch)? I found this static minimalist loader from = Andrew here: = https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b3= 9acd710c = - does it mean such a loader is necessary before the kernel? Thanks, Sylvain PS: I know the =C2=AB official and supported =C2=BB way of booting = FreeBSD on the Pi is the u-boot + ubldr combination. I just would like = to finish this experiment and understand why kernel.bin cannot be booted = directly.= From owner-freebsd-arm@freebsd.org Thu Mar 24 19:37:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B12E1ADBD08; Thu, 24 Mar 2016 19:37:19 +0000 (UTC) (envelope-from foxii@bk.ru) Received: from fallback1.mail.ru (fallback1.mail.ru [94.100.181.184]) by mx1.freebsd.org (Postfix) with ESMTP id 5D2F71DED; Thu, 24 Mar 2016 19:37:18 +0000 (UTC) (envelope-from foxii@bk.ru) Received: from f173.i.mail.ru (f173.i.mail.ru [94.100.178.91]) by fallback1.mail.ru (mPOP.Fallback_MX) with ESMTP id 0C9D06C2F738; Thu, 24 Mar 2016 22:06:16 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bk.ru; s=mail; h=Content-Type:Message-ID:Reply-To:Date:MIME-Version:Subject:To:From; bh=3UzJU63EH+uaP1oDo7acTLbcz8H/qVao2MDF7qm4jak=; b=XopBwU96ahHiQ2GHlj/9SRpzFEbTvLXsmfJ3u5C2W+aeNbiLTcySkpExi9U63JsR/95EZsZv5MmefFzF59hd3h9XQXYvEol7aRYHD9YelfITK28tMsmd64bA60ugaG5jSkmQxO72aRoGOQPMH9mC8god7E0MeMjFkFLYFLlncyc=; Received: from [31.44.58.133] (ident=mail) by f173.i.mail.ru with local (envelope-from ) id 1ajAa5-0007U5-Qo; Thu, 24 Mar 2016 22:06:06 +0300 Received: from [31.44.58.133] by e.mail.ru with HTTP; Thu, 24 Mar 2016 22:06:05 +0300 From: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= To: freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-amd64@FreeBSD.org Subject: =?UTF-8?B?cXVlc3Rpb24gb24gc3VwcG9ydCBwcm9jZXNzb3IgSW50ZWwgQXRvbSBaMzcz?= =?UTF-8?B?NUY=?= MIME-Version: 1.0 X-Mailer: Mail.Ru Mailer 1.0 X-Originating-IP: [31.44.58.133] Date: Thu, 24 Mar 2016 22:06:05 +0300 Reply-To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= X-Priority: 3 (Normal) Message-ID: <1458846365.574939838@f173.i.mail.ru> X-Mras: Ok X-Spam: undefined Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 19:37:19 -0000 IEhlbGxvLCBwbGVhc2UgdGVsbCBtZSB3aGV0aGVyIHRoZSBGcmVlQlNEIG9wZXJhdGluZyBzeXN0 ZW0gSW50ZWwgQXRvbSBaMzczNUY/wqBXaGljaCBkaXN0cmlidXRpb24gSSBuZWVkIHRvIGRvd25s b2FkPwoKCgE= From owner-freebsd-arm@freebsd.org Thu Mar 24 19:39:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66B82ADBE35 for ; Thu, 24 Mar 2016 19:39:32 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 303111F3A for ; Thu, 24 Mar 2016 19:39:32 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by mail-io0-x230.google.com with SMTP id c63so97584097iof.0 for ; Thu, 24 Mar 2016 12:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ambient-md-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=PxNb59yuuJJyNKGn0p/AojQ1579fwx4OQzbT14Ac3KQ=; b=RCbeaFth4MkX2ySwjMkkd+Z7MXtrMwvJTc0e51GjPTgrYghqGSjecU9Bg0oex7Xl0y o3dyEdtjLTn77S0coLjoYqm87LhRq1NrOYYKSagnjMmgsVX8VG854RCs/JLL7q4fFw2a oDAqXiuGrfbifRK3w2Axo1rRH/qu2+dhL0KyTNLlhXoLLSCYFrAFf0MvGBQYStdeLyC0 42yuEroVDjLafTUAjNh1mx72AGPJD8wrRomFFERfyJnQ0WjZSneR89OO5/4L+Ftt7gUv tF4QOi2DmRDboLsH4h0DwKUCf5blt69IrRGQ36Ot/dCKGhZG8rLdzOMBAgxlruqruhnF eBgg== 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; bh=PxNb59yuuJJyNKGn0p/AojQ1579fwx4OQzbT14Ac3KQ=; b=N3SCdthUYgd4KYL6cY9o2LoaEchHydaBiPSqGiJ5ZGwEpUQ/ARDUtwXpYzhmuVwD6J x8lYZJnqBu9xfeagWl1xIm/dgXA/9wZJFui7fZLf8ZQuDS5S3tRRmbOiK8Eke94+IKVX pQmznP29b0bYyRmSUquix6f/Lsh7q4yUOQcAd4hAA6lqYmeXhNKzOnjk51c345MrTXIO ZiDEvkH0wd6WjRo4/yWJ2DYyOfwhpJK/vY/IMytooGB6utPuRJ0UK6+hKqJxRFMiX7J7 ew1RfGcuXft+G0CllP0JDLv1MmUc+YoO+fgqPfpfDogArlaM9Sgit0EnpNouMux0pMzC NKVg== X-Gm-Message-State: AD7BkJI6Z96HxnDc0qdsTf4i4s4+LcgO9T8VbCwx9BQ9zsfYbI+jDBgUX1ypDE9+LXHVRK834B1XJtK7/OpZ1A== MIME-Version: 1.0 X-Received: by 10.107.14.142 with SMTP id 136mr10155270ioo.94.1458848371145; Thu, 24 Mar 2016 12:39:31 -0700 (PDT) Received: by 10.79.11.71 with HTTP; Thu, 24 Mar 2016 12:39:31 -0700 (PDT) X-Originating-IP: [207.96.192.66] Received: by 10.79.11.71 with HTTP; Thu, 24 Mar 2016 12:39:31 -0700 (PDT) In-Reply-To: <1458846365.574939838@f173.i.mail.ru> References: <1458846365.574939838@f173.i.mail.ru> Date: Thu, 24 Mar 2016 15:39:31 -0400 Message-ID: Subject: Re: question on support processor Intel Atom Z3735F From: peter garshtja To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= Cc: freebsd-arch@freebsd.org, freebsd-amd64@freebsd.org, freebsd-arm@freebsd.org, freebsd-current@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 19:39:32 -0000 Hi Vladimir, I believe you need x86 arch. Regards On Mar 24, 2016 3:37 PM, "=D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=80"= wrote: > Hello, please tell me whether the FreeBSD operating system Intel Atom > Z3735F? Which distribution I need to download? > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Thu Mar 24 19:46:55 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10855ADC100; Thu, 24 Mar 2016 19:46:55 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id CA38F1439; Thu, 24 Mar 2016 19:46:54 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [127.0.0.1] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EEBBFF48; Thu, 24 Mar 2016 22:46:50 +0300 (MSK) Reply-To: lev@FreeBSD.org Subject: Re: question on support processor Intel Atom Z3735F References: <1458846365.574939838@f173.i.mail.ru> To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= , freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-amd64@FreeBSD.org From: Lev Serebryakov Organization: FreeBSD Message-ID: <56F44422.6050107@FreeBSD.org> Date: Thu, 24 Mar 2016 22:46:42 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <1458846365.574939838@f173.i.mail.ru> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="VsglVVQiJDluXDFjul55pI78WllaStjHE" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 19:46:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --VsglVVQiJDluXDFjul55pI78WllaStjHE Content-Type: multipart/mixed; boundary="0LAwAIaSmtCVnVFNXgwK8jdJGxPQ1bGj0" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: =?UTF-8?B?0JLQu9Cw0LTQuNC80LjRgA==?= , freebsd-arch@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-arm@FreeBSD.org, freebsd-amd64@FreeBSD.org Message-ID: <56F44422.6050107@FreeBSD.org> Subject: Re: question on support processor Intel Atom Z3735F References: <1458846365.574939838@f173.i.mail.ru> In-Reply-To: <1458846365.574939838@f173.i.mail.ru> --0LAwAIaSmtCVnVFNXgwK8jdJGxPQ1bGj0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 24.03.2016 22:06, =D0=92=D0=BB=D0=B0=D0=B4=D0=B8=D0=BC=D0=B8=D1=80 wro= te: > Intel Atom Z3735F Both x86 (32 bit) and amd64 (64 bit) will do. It depends on available memory. If you have 4GB or more installed, try amd64. --=20 // Lev Serebryakov --0LAwAIaSmtCVnVFNXgwK8jdJGxPQ1bGj0-- --VsglVVQiJDluXDFjul55pI78WllaStjHE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJW9EQoXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePo+wP/0AOjwXT2CTdDLzc9IqK8phs QXkImc/jbP05oDClzORbK3sM1F3bQ7QY2Zs+7YNS6skC6u702dLDNQKtE1rtlujJ Ozkb/tLA7xmZNJ/Id41qp/f39CyD3Sfj77l07zuZxFWVePbYEWlNZT2GxyYeaZ5j AMAr4hr/Wg/MlFUMDd5EvrQSGs84v/EHkn7tlv53wnM+aJsizJEdDQaNgkD9WBdN SFmRXu7kFpCb3v0vskl7A0XLP6kg5WNBcgs4tRkJwSnNfIBzkKR8har8cDl9GJof uTKfMUZDg7sp0jtJCsRuCo0DO7GAFdWOOfo6jkioP+rrB62Jjhxwh79WwJ7iOkxh 9CLohrmWP75PezxAq4gpImlx12msgsQvTzQwYd2GWFd0pZrwRLdQS86owAGXeAC6 BkCOkkl05ljsMMygzXAt3UXXkteqifGduaAtJDBcPnbcvv5VKwOAOyvx26wwB5x/ 83nEc9Hqrimb5O8NJVJ/IZR2gBhNQQ2J6/WSenGHx0oe22ggNVgf5B8haDx/Ak2J NicxV6uykpgVnSc8UBZEJsWiMc4MRgONXefCoPJ3SgwEnvEM49WfE1Vml+tFxXq4 DKm/gyUzHngYgCDeYDkeEWvPtlrXdO3N2tyyp1cb/net4w1NHGHmS4FDMUgW2CxF 8ZHIItrzGRnGaZajKW76 =YGny -----END PGP SIGNATURE----- --VsglVVQiJDluXDFjul55pI78WllaStjHE-- From owner-freebsd-arm@freebsd.org Thu Mar 24 19:55:38 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 00570ADC431 for ; Thu, 24 Mar 2016 19:55:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBD1D1C42 for ; Thu, 24 Mar 2016 19:55:37 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 64683f97-f1fa-11e5-b278-7d22021d92d7 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Thu, 24 Mar 2016 19:55:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2OJtSIo017141; Thu, 24 Mar 2016 13:55:29 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458849328.1091.56.camel@freebsd.org> Subject: Re: about netbooting on armv6 [was: Fwd: SDIO Patch D4761.diff Not Building For Me] From: Ian Lepore To: Daniel Braniss Cc: freebsd-arm , Ilya Bakulin Date: Thu, 24 Mar 2016 13:55:28 -0600 In-Reply-To: References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> <1458751414.1091.47.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-13" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Mar 2016 19:55:38 -0000 On Thu, 2016-03-24 at 10:00 +0200, Daniel Braniss wrote: > > On 23 Mar 2016, at 18:43, Ian Lepore wrote: > > > > On Wed, 2016-03-23 at 09:09 -0700, Russell Haley wrote: > > > On Wed, Mar 23, 2016 at 4:00 AM, Ilya Bakulin > > > wrote: > > > > On 2016-03-23 06:16, Russell Haley wrote: > > > > > > > > > > Hi Ilya, > > > > > > > > > > Mixed success tonight. I tried to install the kernel but got > > > > > an > > > > > error: > > > > > > > > > > > > You should give MODULES_OVERRIDE= to installkernel as well. > > > > > > > Great, Thank you. > > > > > > > > > > Well, it booted the kernel and then spewed output and > > > > > eventually > > > > > ended > > > > > with a failed DHCP request (?). Here is the pastebin of said > > > > > output. > > > > > > > > > > > > > I never copy the newly built kernel to the SD card. > > > > Instead I configure U-Boot+ubldr to boot kernel from TFTP and > > > > mount > > > > root > > > > over NFS, it's much faster and it's impossible to crash > > > > filesystem > > > > if the > > > > kernel crashes. > > > > I guess you should set ROOTDEVNAME manually in the kernel > > > > config > > > > file and > > > > disable NFSCLIENT-related options. > > > > > > Thanks for this advice. I have had something similar working > > > before > > > (I > > > had rootfs on USB) so should be able to get that running this > > > weekend > > > > > > > From your boot log it's clear that the system boots and probes > > > > SD > > > > cards. > > > > > > Yes, very exciting to see!!! I will be looking to try and match > > > debug > > > output with code paths asap. > > > > > > > There are two slots and none of them has SDIO card in it. > > > > From what I find about Hummingboard, it actually doesn't have > > > > WiFi > > > > SDIO > > > > chips on it. > > > > > > I don't understand. It was booted using an SD card? Also, here is > > > the > > > information about the board and the Wi-Fi (the Solid-Run site can > > > be > > > hard to navigate): > > > > > > Carrier Board spec: > > > http://wiki.solid-run.com/doku.php?id=products:imx6:hummingboard: > > > hbpr > > > o > > > > > > This is my SOM: > > > http://wiki.solid-run.com/doku.php?id=products:imx6:microsom:dual > > > &s[] > > > =bcm4330 > > > > > > Schematic. I believe page 5 shows the SDIO WIFI module interface? > > > http://wiki.solid-run.com/lib/exe/fetch.php?media=imx6:microsom:d > > > ocs: > > > sr-usom-mx6-rev-1_3-simplified-schematics.pdf > > > > > > Broadcom BCM4330 > > > http://linux-sunxi.org/images/0/05/4330-DS206-R.pdf > > > > > > I have used it successfully through Kodi and Debian (Raspbian > > > specifically) > > > > > > Thanks, > > > Russ > > > > The quick and easy config for netbooting armv6 these days is to set > > a > > few vars in your uboot env. This assumes that you let uboot load > > ubldr.bin from sdcard, and then have ubldr load the kernel and the > > kernel will mount nfsroot. > > > > If you have a dhcp server to provide an IP, this is all you need in > > uboot env: > > > > loaderdev=net > > rootpath=:/ > > you can set the footpath via dhcp / dhcpd.conf: > > option root-path nfs:ip.root.host:/path-to-root; I suspect more people will have the ability to set uboot env vars than to set options in their dhcp server (which I've found from talking to people is all too often some ISP-provided appliance with little or not configuration access). -- Ian From owner-freebsd-arm@freebsd.org Fri Mar 25 05:29:27 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B1C2ADC89F for ; Fri, 25 Mar 2016 05:29:27 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C22F51FAE; Fri, 25 Mar 2016 05:29:26 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x234.google.com with SMTP id e6so82299859vkh.2; Thu, 24 Mar 2016 22:29: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-transfer-encoding; bh=GG6twwQzUaILWnlazs7Cfau7iEE9w6f/RHTQZjyF1PQ=; b=uTH4YesVAy73EN/kNl+/C0srqr8XjAtCrIxThxggYEhHYuVAUqz4gN8NCgsXpfs3WQ LMLXcDjBlA/SWtsuXXxOvVTqzJBThvBGA/o6tE5smAZUR39IqLw9JR4A1RLCKypqg3cN bOj7npuCqaPegPOFX9GxdfOkXOvNzRxTxOvLO3Uc7IOOw1tcSLBJPfd3b0CS7FBKXmvs 2+lfRXrtgtD7HpGnRVb3vgIJrr7yIimIPj8CBgL+IExmtwyXrih6dQml0F74U6ybey98 fEAsVMqgnycC3BpYfT+kj50WubCkPXl0KkIMA8eesVYblO/GAB5mMUP2tHL8y5WnfwTN oiNQ== 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-transfer-encoding; bh=GG6twwQzUaILWnlazs7Cfau7iEE9w6f/RHTQZjyF1PQ=; b=E7onAE80Fo/7+yDuFBNk76EtfX3zhk3fT7ecVCnf4W/L2DsiloVjrfZq7A99xWxNdf Be4SvgSxnjJYnA8tvFSmwqfFZviDBdFhJeEJ0jdV/NEW/kGPXAG7YxLAGdX1LhR3U2rt HQEMze2NR/r9GmoInao79WN980SOPul/VTg1jhlYfW19lJfvxryrduzibmtMJXS/nHw8 yyGeNpiqQ+i/yTd1zx4FTRTM8TvUcOVwhS0zjEnRjx9S1mWmexgJ8JCNHnzn15gTKAuI x2hWrlIXWI68tM4aBwDonv2Q121W8q0KhNtcwQSsZRMLm09YW4ImgJSPJNr1VUgP43WP okgA== X-Gm-Message-State: AD7BkJILj599KHzHHgu9LSfJy2HUD1LLjXIkK99XRiNXkCmZkIldVqiJhKqdw8SopBFRfr9g9d6mGwCQlwU1+w== MIME-Version: 1.0 X-Received: by 10.31.56.151 with SMTP id f145mr6592625vka.107.1458883765887; Thu, 24 Mar 2016 22:29:25 -0700 (PDT) Received: by 10.31.54.13 with HTTP; Thu, 24 Mar 2016 22:29:25 -0700 (PDT) In-Reply-To: <1458849328.1091.56.camel@freebsd.org> References: <5432b449f37a481bc7099fbab25fbd2e@bakulin.de> <1458751414.1091.47.camel@freebsd.org> <1458849328.1091.56.camel@freebsd.org> Date: Thu, 24 Mar 2016 22:29:25 -0700 Message-ID: Subject: Re: about netbooting on armv6 [was: Fwd: SDIO Patch D4761.diff Not Building For Me] From: Russell Haley To: Ian Lepore Cc: Daniel Braniss , freebsd-arm , Ilya Bakulin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 05:29:27 -0000 On Thu, Mar 24, 2016 at 12:55 PM, Ian Lepore wrote: > On Thu, 2016-03-24 at 10:00 +0200, Daniel Braniss wrote: >> > On 23 Mar 2016, at 18:43, Ian Lepore wrote: >> > >> > On Wed, 2016-03-23 at 09:09 -0700, Russell Haley wrote: >> > > On Wed, Mar 23, 2016 at 4:00 AM, Ilya Bakulin >> > > wrote: >> > > > On 2016-03-23 06:16, Russell Haley wrote: >> > > > > >> > > > > Hi Ilya, >> > > > > >> > > > > Mixed success tonight. I tried to install the kernel but got >> > > > > an >> > > > > error: >> > > > >> > > > >> > > > You should give MODULES_OVERRIDE=3D to installkernel as well. >> > > > >> > > Great, Thank you. >> > > > > >> > > > > Well, it booted the kernel and then spewed output and >> > > > > eventually >> > > > > ended >> > > > > with a failed DHCP request (?). Here is the pastebin of said >> > > > > output. >> > > > > >> > > > >> > > > I never copy the newly built kernel to the SD card. >> > > > Instead I configure U-Boot+ubldr to boot kernel from TFTP and >> > > > mount >> > > > root >> > > > over NFS, it's much faster and it's impossible to crash >> > > > filesystem >> > > > if the >> > > > kernel crashes. >> > > > I guess you should set ROOTDEVNAME manually in the kernel >> > > > config >> > > > file and >> > > > disable NFSCLIENT-related options. >> > > >> > > Thanks for this advice. I have had something similar working >> > > before >> > > (I >> > > had rootfs on USB) so should be able to get that running this >> > > weekend >> > > >> > > > From your boot log it's clear that the system boots and probes >> > > > SD >> > > > cards. >> > > >> > > Yes, very exciting to see!!! I will be looking to try and match >> > > debug >> > > output with code paths asap. >> > > >> > > > There are two slots and none of them has SDIO card in it. >> > > > From what I find about Hummingboard, it actually doesn't have >> > > > WiFi >> > > > SDIO >> > > > chips on it. >> > > >> > > I don't understand. It was booted using an SD card? Also, here is >> > > the >> > > information about the board and the Wi-Fi (the Solid-Run site can >> > > be >> > > hard to navigate): >> > > >> > > Carrier Board spec: >> > > http://wiki.solid-run.com/doku.php?id=3Dproducts:imx6:hummingboard: >> > > hbpr >> > > o >> > > >> > > This is my SOM: >> > > http://wiki.solid-run.com/doku.php?id=3Dproducts:imx6:microsom:dual >> > > &s[] >> > > =3Dbcm4330 >> > > >> > > Schematic. I believe page 5 shows the SDIO WIFI module interface? >> > > http://wiki.solid-run.com/lib/exe/fetch.php?media=3Dimx6:microsom:d >> > > ocs: >> > > sr-usom-mx6-rev-1_3-simplified-schematics.pdf >> > > >> > > Broadcom BCM4330 >> > > http://linux-sunxi.org/images/0/05/4330-DS206-R.pdf >> > > >> > > I have used it successfully through Kodi and Debian (Raspbian >> > > specifically) >> > > >> > > Thanks, >> > > Russ >> > >> > The quick and easy config for netbooting armv6 these days is to set >> > a >> > few vars in your uboot env. This assumes that you let uboot load >> > ubldr.bin from sdcard, and then have ubldr load the kernel and the >> > kernel will mount nfsroot. >> > >> > If you have a dhcp server to provide an IP, this is all you need in >> > uboot env: >> > >> > loaderdev=3Dnet >> > rootpath=3D:/ >> >> you can set the footpath via dhcp / dhcpd.conf: >> >> option root-path =E2=80=9Cnfs:ip.root.host:/path-to-root=E2=80=9D; > > I suspect more people will have the ability to set uboot env vars than > to set options in their dhcp server (which I've found from talking to > people is all too often some ISP-provided appliance with little or not > configuration access). I have complete control over my un-patchable 100mb wireless-b d-link router! I even tore the antennas off for security. lolz Russ From owner-freebsd-arm@freebsd.org Fri Mar 25 05:32:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8E520ADCA27 for ; Fri, 25 Mar 2016 05:32:10 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 22B9B11CD for ; Fri, 25 Mar 2016 05:32:09 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u2P5PHfD027477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Mar 2016 06:25:18 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u2P5PBr2044822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Mar 2016 06:25:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u2P5PAwM051778; Fri, 25 Mar 2016 06:25:10 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u2P5P9N6051777; Fri, 25 Mar 2016 06:25:09 +0100 (CET) (envelope-from ticso) Date: Fri, 25 Mar 2016 06:25:09 +0100 From: Bernd Walter To: Sylvain Garrigues Cc: freebsd-arm Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support Message-ID: <20160325052509.GE48704@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 05:32:10 -0000 On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: > Hello, > > I have written a small (ugly) patch to be able to boot a kernel directly without the ubldr loader while still using an external DTB (Linux-style booting may pass the DTB location pointer in the r2 register). > The patch is here: https://reviews.freebsd.org/differential/diff/14577/ > > I tested my patch successfully with the QEMU emulator with the -dtb option available in recent versions, using a VERSATILEPB kernel without FDT_STATIC. > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash -cpu arm1176 -dtb versatilepb.dtb > FYI, once the kernel is built, here is the script to build the versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 registers): https://reviews.freebsd.org/P92 > > I also tested successfully my patch on my Raspberry Pi 2 using U-BOOT and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI option): > u-boot> fatload mmc 0 0x200000 kernel.bin > u-boot> go 0x200000 > > That works. > > So now I thought I could even bypass u-boot and launch kernel.bin directly from the Pi firmware??? But it doesn???t work, I don???t understand why, and that is why I am writing here. > Here is the config.txt which I thought would work: > > kernel=kernel.bin (instead of u-boot.bin) > kernel_address=0x200000 (line added because a FreeBSD kernel needs to be loaded on a 1MB or 2MB boundary) > device_tree=rpi2.dtb > device_tree_address=0x100 > disable_commandline_tags=1 > > What am I missing? Is it even possible to boot kernel.bin directly on the Pi (with my patch)? I found this static minimalist loader from Andrew here: https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b39acd710c - does it mean such a loader is necessary before the kernel? > > Thanks, > Sylvain > > PS: I know the official and supported way of booting FreeBSD on the Pi is the u-boot + ubldr combination. I just would like to finish this experiment and understand why kernel.bin cannot be booted directly. I don't know if it is part of ubldr, or if there is any additional code, which runs before ubldr, but the Pis won't boot with the ARM CPU. Somewhere in the boot path is GPU bootcode, which then enables the ARM CPU. You also need low level HW init, such as setting up the clocks and RAM, which is not done in the Kernel. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Mar 25 05:48:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 978BEADCDAD for ; Fri, 25 Mar 2016 05:48:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 697721740 for ; Fri, 25 Mar 2016 05:48:10 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22c.google.com with SMTP id m184so105557763iof.1 for ; Thu, 24 Mar 2016 22:48:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+vb/JcTWNY9peI2k5HgZhymXjpeoRLGXj5YARlemNMI=; b=0cp4eoNqjqR0axzmTUj2k0SXRPfAtb1dP0I5Hnvl15zox3Yg4ASoTmXaBGzVvb1g6M aSwCCyDdFDtuuWfVn+qTMYuR9IxAHdhfWXVUo6GaCfWCTsH8N4BHMDhgXU820wIXoxq0 4iAPwWVsUwN9nRKg2GiCrNx7S9fJBdLtYPx2Jd6fZ8iPIaOpbIp9cgYnj4KMCxA08F0S TbzOxMeoY4ZDdkA9F5KKfiTzU/wXO29Fk8V18tB8cpc7M3P1BnoHg3E5I1uVU1MsE7jY VLGygviaSQ9w4ClutlOKwCfrpOm73faVpP9T7ZbLSmU2nIEx6qok6k7+jmV58L75Isz+ WfMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+vb/JcTWNY9peI2k5HgZhymXjpeoRLGXj5YARlemNMI=; b=f7s0s/Q1FbuY7MlCFYG8a8bSGPe5cyCDaq6DDRPONXueNz/cHQZUxE5A7M/PpDG+5t wsHtkp/9srlPMYZWAchNJNX7iRtVAZ/+6n59V6CI1yGq0a8lCqrD65y26xUxYsnt2lo+ nC6iCd9Tptpka2e1ho6gNu1Bp+3qce7YNjRNh1k+B6Mzqbtgw7voYvPdVgarFp8cn2Y2 zMZAY0KUbdhOW2SFj4vLfHvA/lrKtVB4GQmJQOdclzz31STtYcc2LbH5vD4mNMCY19n5 pbLbuf1MeN202sZlC8vJ3m16ANpVT81uzK4vvEVPO06ta3cV9LKDCqP+IuvPAfax4+QE VXeQ== X-Gm-Message-State: AD7BkJIRfpPFmXd4WvvXH1UNHqM9OgkXGgjPFWgTdtcQIwuR5SgMfiXQqzVXZH/Q9tE+AN96pcnxlfYSpbU1dQ== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr11685502ioe.135.1458884889742; Thu, 24 Mar 2016 22:48:09 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Thu, 24 Mar 2016 22:48:09 -0700 (PDT) X-Originating-IP: [50.253.99.174] In-Reply-To: <20160325052509.GE48704@cicely7.cicely.de> References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> Date: Thu, 24 Mar 2016 23:48:09 -0600 X-Google-Sender-Auth: FsRT5etkqWqhTNrORX4qWP3fKdY Message-ID: Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Warner Losh To: ticso@cicely.de Cc: Sylvain Garrigues , freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 05:48:10 -0000 On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter wrote: > On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: > > Hello, > > > > I have written a small (ugly) patch to be able to boot a kernel directl= y > without the ubldr loader while still using an external DTB (Linux-style > booting may pass the DTB location pointer in the r2 register). > > The patch is here: https://reviews.freebsd.org/differential/diff/14577/ > > > > I tested my patch successfully with the QEMU emulator with the -dtb > option available in recent versions, using a VERSATILEPB kernel without > FDT_STATIC. > > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash -cpu > arm1176 -dtb versatilepb.dtb > > FYI, once the kernel is built, here is the script to build the > versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 > registers): https://reviews.freebsd.org/P92 < > https://reviews.freebsd.org/P92> > > > > I also tested successfully my patch on my Raspberry Pi 2 using U-BOOT > and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI option)= : > > u-boot> fatload mmc 0 0x200000 kernel.bin > > u-boot> go 0x200000 > > > > That works. > > > > So now I thought I could even bypass u-boot and launch kernel.bin > directly from the Pi firmware??? But it doesn???t work, I don???t > understand why, and that is why I am writing here. > > Here is the config.txt which I thought would work: > > > > kernel=3Dkernel.bin (instead of u-boot.bin) > > kernel_address=3D0x200000 (line added because a FreeBSD kernel needs to= be > loaded on a 1MB or 2MB boundary) > > device_tree=3Drpi2.dtb > > device_tree_address=3D0x100 > > disable_commandline_tags=3D1 > > > > What am I missing? Is it even possible to boot kernel.bin directly on > the Pi (with my patch)? I found this static minimalist loader from Andrew > here: > https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c > < > https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c> > - does it mean such a loader is necessary before the kernel? > > > > Thanks, > > Sylvain > > > > PS: I know the =C2=AB official and supported =C2=BB way of booting Free= BSD on the > Pi is the u-boot + ubldr combination. I just would like to finish this > experiment and understand why kernel.bin cannot be booted directly. > > I don't know if it is part of ubldr, or if there is any additional code, > which runs before ubldr, but the Pis won't boot with the ARM CPU. > Somewhere in the boot path is GPU bootcode, which then enables the ARM > CPU. > You also need low level HW init, such as setting up the clocks and RAM, > which is not done in the Kernel. > What you are missing it the hardware init code that's in u-boot.bin. This code sets up the board after the on-board GPU loads it into the ARM's address space. That code sets up the ARM side of the world and hands off the code to ubldr which finds the dtb and does the normal /boot/loader things as well (loading modules, setting tunables and the like) then hands off to the kernel. You can eliminate ubldr without a huge amount of effort, as you've found. However, eliminating u-boot.bin is going to be a lot more work/ tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is quite a bit different than between the initial bootstrap and u-boot.bin. So you can't just drop in kernel.bin and have it work without replicating that interface. Warner From owner-freebsd-arm@freebsd.org Fri Mar 25 09:13:20 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A654CADDF50 for ; Fri, 25 Mar 2016 09:13:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (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 42E911877 for ; Fri, 25 Mar 2016 09:13:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18317 invoked from network); 25 Mar 2016 09:13:19 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Mar 2016 09:13:19 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Fri, 25 Mar 2016 05:13:22 -0400 (EDT) Received: (qmail 12730 invoked from network); 25 Mar 2016 09:13:22 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 25 Mar 2016 09:13:22 -0000 X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 314421C43BC; Fri, 25 Mar 2016 02:13:17 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Running arm64 current on ODROID C2 [fwd from freebsd-current] Date: Fri, 25 Mar 2016 02:13:17 -0700 Message-Id: <6AA65CE9-0DB7-49D4-98FD-EEA38039D5F6@dsl-only.net> Cc: pldrouin@gmail.com To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 09:13:20 -0000 [I'm just forwarding someone's question from freebsd-current to = free-bsd-arm here. I hope to someday use my ORDROID-C2 with FreeBSD so I = noticed this.] > Pierre-Luc Drouin pldrouin at gmail.com=20 > Thu Mar 24 13:14:11 UTC 2016 >=20 > Hi, >=20 > I would like to run arm64 current on an ODROID C2 (Amlogic S905 A53 = 64bit > ARMv8). I was going to try configuring u-boot to either use an ELF = kernel > and boot it with bootelf or a kernel.bin produced with objcopy. and = boot it > with the go command. I was looking at the wiki instruction page for = the > ODROID C1 and the one for arm64. Is there any known issue that will = prevent > me for successfully run arm64 current on this type of device? Note = that I > don't care about video for now. >=20 > Thanks! =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Mar 25 17:55:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21C31ADD4C5 for ; Fri, 25 Mar 2016 17:55:16 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B1BF31BDB for ; Fri, 25 Mar 2016 17:55:15 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x22b.google.com with SMTP id l68so30249891wml.1 for ; Fri, 25 Mar 2016 10:55:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=mpWViMSwBRN6cf1K13R/aTLkygpy81GWBpBtm9KY+0Y=; b=JMh8PAALd1pbpoRGTS6PzkMGy517E0ac3eXhr4oy6xvPgS5nW/wI5AUwvqbfv2DRdg tFbGDNkxq+yS1DnSgaG7AXT5Em6eyn2fOnd0WqSPMpTDbH1QdcbyBnPBEh2MyaDzvUlL Ni22VvkXc/c+4BqadBWOZlrLG2kNUtoBZtraeET9rhrrzlVsstu9GmMbMU+dGDK16u7k zx+ZAYlVC7Bm4sXTB7xF7balrjxj3hNycSQhbwmfnI1l8l9NzkDIZ6uFygZvrCjNsLcZ sE40vU611YClvKljdpEsNZIj9hbC17J1bJT+2+oUgzrmXRSLLwP+5KifiHCnT4czFG+o 59cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mpWViMSwBRN6cf1K13R/aTLkygpy81GWBpBtm9KY+0Y=; b=gCXThoBWh9WLpTb96AQMRspG8NXljMfSHp6kES7scSYstDW0oyXAMWPOT8WKH1kIN/ sbglxw3IHU4GfeX05lBvlizlv1wt+w3gd1ruMPdz63ExSZzlADKxTeeECoLZLlARMcd1 AzJiwB6E8FUjs7vHESqM3DIL8VVh7rO4orVnE8XuY/zaiAC/iuT5YaBYbAp+/Po9LRax 9pi9MkaEEMFBKwJ4mhCqmeK14hYOec77UUSy7CvDuyeXGG6DGYWC4T7RVpzwLlDw2ouj 9M0Cq5vtVNgG+pxjiSXibUPYcpHYUkoIRJrfJ8l0Pwjpj2pKp4lwpSeAS2Ck9HlfOSJh Tfag== X-Gm-Message-State: AD7BkJL9u4Hk/HiY20F+Dz80MGGFmapcAO0HN8WSLydKhZKJIQhbsiHUjPGtmB7sAxkWAg== X-Received: by 10.28.131.141 with SMTP id f135mr39356889wmd.33.1458928514249; Fri, 25 Mar 2016 10:55:14 -0700 (PDT) Received: from [192.168.0.4] ([81.56.235.196]) by smtp.gmail.com with ESMTPSA id q139sm4089817wmd.2.2016.03.25.10.55.12 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Mar 2016 10:55:13 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Sylvain Garrigues In-Reply-To: Date: Fri, 25 Mar 2016 18:55:11 +0100 Cc: ticso@cicely.de, freebsd-arm Message-Id: <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> To: Warner Losh X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 17:55:16 -0000 Thank you.=20 I wanted to boot the kernel directly so as to: 1/ remove the dependency on a 3rd party loader 2/ reduce boot time and make it comparable with NetBSD and Linux (which = don=E2=80=99t use u-boot) NetBSD and Linux on the Pi boot so much faster than our FreeBSD image: = less than 1 second after power-up, the first kernel copyright line = appears on my LCD. For the FreeBSD images, the longest part is ubldr = loading the kernel. It takes around 4/5 seconds (with the same SD card). I used recent u-boot versions (the current u-boot-rpi2 port is getting = old and is not in sync with the u-boot-rpi port recently updated), tried = with dcache enabled, but the boot process still takes several seconds, = most of the time being spent in ubldr loading the kernel. I have no idea how we could improve the booting time? I wanted to = experiment with booting the kernel directly as the first ARM program on = my Pi, but as you explained I need some init code. I managed to compile = Andrew=E2=80=99s one = (https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c = ) but I don=E2=80=99t know how to use it. Andrew, if you read = this ;-) Best, Sylvain. =20 > Le 25 mars 2016 =C3=A0 06:48, Warner Losh a =C3=A9crit = : >=20 >=20 >=20 > On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter = > wrote: > On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: > > Hello, > > > > I have written a small (ugly) patch to be able to boot a kernel = directly without the ubldr loader while still using an external DTB = (Linux-style booting may pass the DTB location pointer in the r2 = register). > > The patch is here: = https://reviews.freebsd.org/differential/diff/14577/ = > > > > I tested my patch successfully with the QEMU emulator with the -dtb = option available in recent versions, using a VERSATILEPB kernel without = FDT_STATIC. > > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash = -cpu arm1176 -dtb versatilepb.dtb > > FYI, once the kernel is built, here is the script to build the = versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 = registers): https://reviews.freebsd.org/P92 = > > > > > I also tested successfully my patch on my Raspberry Pi 2 using = U-BOOT and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI = option): > > u-boot> fatload mmc 0 0x200000 kernel.bin > > u-boot> go 0x200000 > > > > That works. > > > > So now I thought I could even bypass u-boot and launch kernel.bin = directly from the Pi firmware??? But it doesn???t work, I don???t = understand why, and that is why I am writing here. > > Here is the config.txt which I thought would work: > > > > kernel=3Dkernel.bin (instead of u-boot.bin) > > kernel_address=3D0x200000 (line added because a FreeBSD kernel needs = to be loaded on a 1MB or 2MB boundary) > > device_tree=3Drpi2.dtb > > device_tree_address=3D0x100 > > disable_commandline_tags=3D1 > > > > What am I missing? Is it even possible to boot kernel.bin directly = on the Pi (with my patch)? I found this static minimalist loader from = Andrew here: = https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b3= 9acd710c = > - does it mean such a loader is necessary before the kernel? > > > > Thanks, > > Sylvain > > > > PS: I know the =C2=AB official and supported =C2=BB way of booting = FreeBSD on the Pi is the u-boot + ubldr combination. I just would like = to finish this experiment and understand why kernel.bin cannot be booted = directly. >=20 > I don't know if it is part of ubldr, or if there is any additional = code, > which runs before ubldr, but the Pis won't boot with the ARM CPU. > Somewhere in the boot path is GPU bootcode, which then enables the ARM > CPU. > You also need low level HW init, such as setting up the clocks and = RAM, > which is not done in the Kernel. >=20 > What you are missing it the hardware init code that's in u-boot.bin. = This code sets up > the board after the on-board GPU loads it into the ARM's address = space. That code > sets up the ARM side of the world and hands off the code to ubldr = which finds the dtb > and does the normal /boot/loader things as well (loading modules, = setting tunables > and the like) then hands off to the kernel. You can eliminate ubldr = without a huge > amount of effort, as you've found. However, eliminating u-boot.bin is = going to be > a lot more work/ >=20 > tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is quite = a bit different > than between the initial bootstrap and u-boot.bin. So you can't just = drop in kernel.bin > and have it work without replicating that interface. >=20 > Warner From owner-freebsd-arm@freebsd.org Fri Mar 25 18:01:47 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C381BADD624 for ; Fri, 25 Mar 2016 18:01:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8366A1D7A for ; Fri, 25 Mar 2016 18:01:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ig0-x232.google.com with SMTP id nk17so16522697igb.1 for ; Fri, 25 Mar 2016 11:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=nUKg+C1+4O35iG/ShxqXSctwN0A39nW8gnsDg4iiiUg=; b=L1JhOkdrAUPiN9LznoruNdhLuHSYlpHGWRb0PLqFoQEcfVi2kF8udH8tyd4+1L3hcj pNkiTZfdvFtomD63uKeY75a+Wns0y4dcS/its4/pbhkBE3WcGp9JnZC292tlIEdRRR3p EP/qkLrnxL7CxxcS/Lc25Ud4FTDZqAFRypjL81nhs+EwWWzdSsFc5BMmh3uRjerwDIlZ Cfw2ay5P19Q4f+hDr4Q6Jfl2baSePkACi9AJDU5aA6z90hDtMMr0RgpbMgcxiogI9GUs VL8PcFOZOVXVSCqjHeSvjuu19Jg0ucMbzL4ad/nHkzC4xjy1iUflAhD1AgMcA46+L8xG Te1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nUKg+C1+4O35iG/ShxqXSctwN0A39nW8gnsDg4iiiUg=; b=Z3W9dtq/YYnp+/NW27cvHuzuLs4+kczqo3vShkFQ3mADlxdXqg50XrZyfNeGSilu9P JV87MSlXwtqHytJXCb0JdGriuV3lxuzGUklu9kduZQTpwSfJXoazMf2IsSNQ25jr8T56 fINwIByt1HzkJxwNxQZoJg3JWnDqRb/qvccKqgvvpAm2bcGd+CA2uCwE65kCVdyvna4V tG1BmD23yykDSeIJ691XdAM+LGbamikzHTGiSvVaGTdmbBQL7xSBpJQ1NbBSFLEXwJFi XJ9kE2iN3enaYuyLYTZcGS5waosjoZ1slL5Ard0d7nqyBtYcNHeJdiyVjdQDbAcUrh4e Gqvw== X-Gm-Message-State: AD7BkJLMs/PM5rWUT3b1nqUHc3qJoDofUR7WXmUoj3HL4LHS9f6GSzbJHoIZbcAAFMI28QrvEkXrkd+5kuPSJA== MIME-Version: 1.0 X-Received: by 10.50.50.198 with SMTP id e6mr35826791igo.57.1458928906877; Fri, 25 Mar 2016 11:01:46 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Fri, 25 Mar 2016 11:01:46 -0700 (PDT) X-Originating-IP: [69.53.245.70] In-Reply-To: <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> Date: Fri, 25 Mar 2016 12:01:46 -0600 X-Google-Sender-Auth: 6Hb07LE_QkZJFjqZeW9qKrP0-gA Message-ID: Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Warner Losh To: Sylvain Garrigues Cc: ticso@cicely.de, freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 18:01:47 -0000 On Fri, Mar 25, 2016 at 11:55 AM, Sylvain Garrigues wrote: > Thank you. > > I wanted to boot the kernel directly so as to: > 1/ remove the dependency on a 3rd party loader > 2/ reduce boot time and make it comparable with NetBSD and Linux (which > don=E2=80=99t use u-boot) > > NetBSD and Linux on the Pi boot so much faster than our FreeBSD image: > less than 1 second after power-up, the first kernel copyright line appear= s > on my LCD. For the FreeBSD images, the longest part is ubldr loading the > kernel. It takes around 4/5 seconds (with the same SD card). > > I used recent u-boot versions (the current u-boot-rpi2 port is getting ol= d > and is not in sync with the u-boot-rpi port recently updated), tried with > dcache enabled, but the boot process still takes several seconds, most of > the time being spent in ubldr loading the kernel. > > I have no idea how we could improve the booting time? I wanted to > experiment with booting the kernel directly as the first ARM program on m= y > Pi, but as you explained I need some init code. I managed to compile > Andrew=E2=80=99s one ( > https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c) > but I don=E2=80=99t know how to use it. Andrew, if you read this ;-) > > I wonder if the loader could be more efficient at loading off the SD card= . The SD cards can do 10-20MB/s easily, and the ARM kernel is around 5MB last time I checked. 5 seconds is 1MB/s, which is much slower than we know the hardware can do. I don't know if that's because the callback mechanism in u-boot.bin is so slow (that's what ubldr uses to load the kernel), or there's something inherently slow about our loader. Some analysis here might be quite useful. I'm guessing that we're not getting all the benefits from streaming read mode because we're doing I/Os that are tiny for some reason. But I haven't looked to make sure. What's the speed when booting directly from u-boot.bin? Warner > Le 25 mars 2016 =C3=A0 06:48, Warner Losh a =C3=A9crit : > > > > On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter > wrote: > >> On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: >> > Hello, >> > >> > I have written a small (ugly) patch to be able to boot a kernel >> directly without the ubldr loader while still using an external DTB >> (Linux-style booting may pass the DTB location pointer in the r2 registe= r). >> > The patch is here: https://reviews.freebsd.org/differential/diff/14577= / >> > >> > I tested my patch successfully with the QEMU emulator with the -dtb >> option available in recent versions, using a VERSATILEPB kernel without >> FDT_STATIC. >> > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash -cpu >> arm1176 -dtb versatilepb.dtb >> > FYI, once the kernel is built, here is the script to build the >> versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 >> registers): https://reviews.freebsd.org/P92 < >> https://reviews.freebsd.org/P92> >> > >> > I also tested successfully my patch on my Raspberry Pi 2 using U-BOOT >> and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI option= ): >> > u-boot> fatload mmc 0 0x200000 kernel.bin >> > u-boot> go 0x200000 >> > >> > That works. >> > >> > So now I thought I could even bypass u-boot and launch kernel.bin >> directly from the Pi firmware??? But it doesn???t work, I don???t >> understand why, and that is why I am writing here. >> > Here is the config.txt which I thought would work: >> > >> > kernel=3Dkernel.bin (instead of u-boot.bin) >> > kernel_address=3D0x200000 (line added because a FreeBSD kernel needs t= o >> be loaded on a 1MB or 2MB boundary) >> > device_tree=3Drpi2.dtb >> > device_tree_address=3D0x100 >> > disable_commandline_tags=3D1 >> > >> > What am I missing? Is it even possible to boot kernel.bin directly on >> the Pi (with my patch)? I found this static minimalist loader from Andre= w >> here: >> https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1= b39acd710c >> < >> https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1= b39acd710c> >> - does it mean such a loader is necessary before the kernel? >> > >> > Thanks, >> > Sylvain >> > >> > PS: I know the =C2=AB official and supported =C2=BB way of booting Fre= eBSD on the >> Pi is the u-boot + ubldr combination. I just would like to finish this >> experiment and understand why kernel.bin cannot be booted directly. >> >> I don't know if it is part of ubldr, or if there is any additional code, >> which runs before ubldr, but the Pis won't boot with the ARM CPU. >> Somewhere in the boot path is GPU bootcode, which then enables the ARM >> CPU. >> You also need low level HW init, such as setting up the clocks and RAM, >> which is not done in the Kernel. >> > > What you are missing it the hardware init code that's in u-boot.bin. This > code sets up > the board after the on-board GPU loads it into the ARM's address space. > That code > sets up the ARM side of the world and hands off the code to ubldr which > finds the dtb > and does the normal /boot/loader things as well (loading modules, setting > tunables > and the like) then hands off to the kernel. You can eliminate ubldr > without a huge > amount of effort, as you've found. However, eliminating u-boot.bin is > going to be > a lot more work/ > > tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is quite a > bit different > than between the initial bootstrap and u-boot.bin. So you can't just drop > in kernel.bin > and have it work without replicating that interface. > > Warner > > > From owner-freebsd-arm@freebsd.org Fri Mar 25 18:15:03 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB786ADD834 for ; Fri, 25 Mar 2016 18:15:03 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2691212F1 for ; Fri, 25 Mar 2016 18:15:03 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id l68so30738543wml.1 for ; Fri, 25 Mar 2016 11:15:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=CGIzn7eboh4kaEGbWIsPKCgt2Rg1XnxgIsXOXD3NMJM=; b=t+CN2HnYwRQVBQ9hbxGCw13qYkG1jW+rAK8WrdARnV93Fq8K4NNHcKQCAOmJqJf/cl GvC0afd+AM+iPUZH/dyV/db68qyrD8y6I5Rsl+DUrA+fbfRVClhb8XKVZzXEHvyR7Key Kzihhu6Lcu0n7+MDMWYxTXphLKNhd8Ip1ZJ0/El6ndptNqkbDDS45mnN7fn5PYwZiXYb awgrVXLAaFW2PEKc1jPxVQ9bh7oSr0QIdZlWBYTmF2xk0k5IzZWroYyHaLGd+LIA4lrR lQ3NNQjB2s9h3EoPBDcs7iVJipoFKwGXDx1YoHEIuhvhTgqRTBldSatkVwg2nqJLQlKC Jlzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=CGIzn7eboh4kaEGbWIsPKCgt2Rg1XnxgIsXOXD3NMJM=; b=lj0my5eD/D+Wl3KN4H+wzz867KmFIp/y/KwzdGZGKalOwFd4djj7RmzYi4O/GDa0ae Yqn1tzAvcWFi52zYpjBIWs4TUrxMGN+8yHN/OczIKeEPIvLEeHzWOxfhV/1Qk1ihGpQL ILhwSg0tO/7mKhg+W2USuc60FsQRV/kP2EBKqZEtYu/nVh9IeMIl949LSWRnqSqTbG99 PUeWkRC8ONXWk7dfdhZDDW+KDiF6Hed+9evHqoS/2twJuSuw3U2Ayr+r9M3x6vhuj1Rt gTHV2Y6n+seTZbjwejL/jB57iyF3BqFwtNDviJ17dlVHieddQhHGJIBayvBfeOIjlbcN qJ1Q== X-Gm-Message-State: AD7BkJIu8++Sgd/f943og1qE8ntBtZW/xhpW/u8OrYoEN+2xq9PDjFw0r1PjkwF6eTp0cQ== X-Received: by 10.194.143.8 with SMTP id sa8mr18257767wjb.64.1458929700976; Fri, 25 Mar 2016 11:15:00 -0700 (PDT) Received: from [192.168.0.4] ([81.56.235.196]) by smtp.gmail.com with ESMTPSA id p189sm4138237wmb.7.2016.03.25.11.14.59 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Mar 2016 11:14:59 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Sylvain Garrigues In-Reply-To: Date: Fri, 25 Mar 2016 19:14:58 +0100 Cc: ticso@cicely.de, freebsd-arm Message-Id: <2A98ACB7-2815-4169-951A-0123C71D9987@gmail.com> References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 18:15:03 -0000 u-boot> fatload mmc 0 0x100000 kernel.bin takes around the same time than ubldr (actually slightly less, let=E2=80=99= s say 4s - but that=E2=80=99s still so slow...) Happy to help or test anything to get FreeBSD=E2=80=99s kernel first = line appear on the screen near =C2=AB instantaneously =C2=BB (~ 1s) like = our NetBSD or Linux friends. Sylvain > Le 25 mars 2016 =C3=A0 19:01, Warner Losh a =C3=A9crit = : >=20 >=20 >=20 > On Fri, Mar 25, 2016 at 11:55 AM, Sylvain Garrigues > wrote: > Thank you.=20 >=20 > I wanted to boot the kernel directly so as to: > 1/ remove the dependency on a 3rd party loader > 2/ reduce boot time and make it comparable with NetBSD and Linux = (which don=E2=80=99t use u-boot) >=20 > NetBSD and Linux on the Pi boot so much faster than our FreeBSD image: = less than 1 second after power-up, the first kernel copyright line = appears on my LCD. For the FreeBSD images, the longest part is ubldr = loading the kernel. It takes around 4/5 seconds (with the same SD card). >=20 > I used recent u-boot versions (the current u-boot-rpi2 port is getting = old and is not in sync with the u-boot-rpi port recently updated), tried = with dcache enabled, but the boot process still takes several seconds, = most of the time being spent in ubldr loading the kernel. >=20 > I have no idea how we could improve the booting time? I wanted to = experiment with booting the kernel directly as the first ARM program on = my Pi, but as you explained I need some init code. I managed to compile = Andrew=E2=80=99s one = (https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c = ) but I don=E2=80=99t know how to use it. Andrew, if you read = this ;-) >=20 > I wonder if the loader could be more efficient at loading off the SD = card. The SD cards can do 10-20MB/s easily, and the ARM kernel is around = 5MB last time I checked. 5 seconds is 1MB/s, which is much slower than = we know the hardware can do. I don't know if that's because the callback = mechanism in u-boot.bin is so slow (that's what ubldr uses to load the = kernel), or there's something inherently slow about our loader. Some = analysis here might be quite useful. I'm guessing that we're not getting = all the benefits from streaming read mode because we're doing I/Os that = are tiny for some reason. But I haven't looked to make sure. >=20 > What's the speed when booting directly from u-boot.bin? >=20 > Warner >=20 >=20 >=20 > =20 >> Le 25 mars 2016 =C3=A0 06:48, Warner Losh > a =C3=A9crit : >>=20 >>=20 >>=20 >> On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter = > wrote: >> On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: >> > Hello, >> > >> > I have written a small (ugly) patch to be able to boot a kernel = directly without the ubldr loader while still using an external DTB = (Linux-style booting may pass the DTB location pointer in the r2 = register). >> > The patch is here: = https://reviews.freebsd.org/differential/diff/14577/ = >> > >> > I tested my patch successfully with the QEMU emulator with the -dtb = option available in recent versions, using a VERSATILEPB kernel without = FDT_STATIC. >> > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash = -cpu arm1176 -dtb versatilepb.dtb >> > FYI, once the kernel is built, here is the script to build the = versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 = registers): https://reviews.freebsd.org/P92 = > >> > >> > I also tested successfully my patch on my Raspberry Pi 2 using = U-BOOT and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI = option): >> > u-boot> fatload mmc 0 0x200000 kernel.bin >> > u-boot> go 0x200000 >> > >> > That works. >> > >> > So now I thought I could even bypass u-boot and launch kernel.bin = directly from the Pi firmware??? But it doesn???t work, I don???t = understand why, and that is why I am writing here. >> > Here is the config.txt which I thought would work: >> > >> > kernel=3Dkernel.bin (instead of u-boot.bin) >> > kernel_address=3D0x200000 (line added because a FreeBSD kernel = needs to be loaded on a 1MB or 2MB boundary) >> > device_tree=3Drpi2.dtb >> > device_tree_address=3D0x100 >> > disable_commandline_tags=3D1 >> > >> > What am I missing? Is it even possible to boot kernel.bin directly = on the Pi (with my patch)? I found this static minimalist loader from = Andrew here: = https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b3= 9acd710c = > - does it mean such a loader is necessary before the kernel? >> > >> > Thanks, >> > Sylvain >> > >> > PS: I know the =C2=AB official and supported =C2=BB way of booting = FreeBSD on the Pi is the u-boot + ubldr combination. I just would like = to finish this experiment and understand why kernel.bin cannot be booted = directly. >>=20 >> I don't know if it is part of ubldr, or if there is any additional = code, >> which runs before ubldr, but the Pis won't boot with the ARM CPU. >> Somewhere in the boot path is GPU bootcode, which then enables the = ARM >> CPU. >> You also need low level HW init, such as setting up the clocks and = RAM, >> which is not done in the Kernel. >>=20 >> What you are missing it the hardware init code that's in u-boot.bin. = This code sets up >> the board after the on-board GPU loads it into the ARM's address = space. That code >> sets up the ARM side of the world and hands off the code to ubldr = which finds the dtb >> and does the normal /boot/loader things as well (loading modules, = setting tunables >> and the like) then hands off to the kernel. You can eliminate ubldr = without a huge >> amount of effort, as you've found. However, eliminating u-boot.bin is = going to be >> a lot more work/ >>=20 >> tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is quite = a bit different >> than between the initial bootstrap and u-boot.bin. So you can't just = drop in kernel.bin >> and have it work without replicating that interface. >>=20 >> Warner From owner-freebsd-arm@freebsd.org Fri Mar 25 18:18:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 19B32ADD8FB for ; Fri, 25 Mar 2016 18:18:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D36C51572 for ; Fri, 25 Mar 2016 18:18:15 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x22f.google.com with SMTP id v187so90589126ioe.2 for ; Fri, 25 Mar 2016 11:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=uakb0/R4z6GxxVIXCXljnv0uxAw5Q5EVcgUSWrVdw5o=; b=V8q2JCWuiBIHQrxbLTPrEUEhhP8H6eXi2K8pJ5VhuX5dRFlboYtI33Umjq55D4YkDF /Oe84aJkmTRL++YXi4bhBC42naa4RXeIhc7wblx1sFKftKc26S/1rMewGjEojZxd1v2A 5o5KsCw9OhGBCEYmqfGnFIyqzVAa7vKeafkoryAKE0ElqNTK5SJkjXE0SHY0VAJDaKel Nog4PPXh/gNzcJUJFuwh/VZIrqrPqFQS30dBC4j+qM5V2q4CpeHIzCZAblZh7c4Sxndc THIY3aLxbuNVPb9bEb731yuEsPcP58Cs32s8UixKS/FLaZQIXfHoKxDHMbkFBeu7Xk2/ 5cyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=uakb0/R4z6GxxVIXCXljnv0uxAw5Q5EVcgUSWrVdw5o=; b=BwJeFDhnL3F7JVUcO2gAsVuJnM/2ftaIXVALRZ7fzvJT6bSn4D58mb6YJHwfJX/7lO X+uB3XFdgpHQbTOPPNozYBYomE7XOPSSJ+pfIyKYQtE8PclRq3AaDbNu0TYftOxsKDlE tWI8DqTswtO6hTrPQaXzh8lm5NHbp0Da/rAT0TJdxkUphpCPyPPkoizPWUQmUbjrZim/ yQ5w26RRIPn05ItULNDjqPgu4KmqXx2CN632pGs0hX2bm3ZBEWr2jQgQ9fszUD7uHOI2 yZKYfATcTI6PUXDBEEYqsa4ayv1Nl9wpYlUjmGcH5Iz5iuhmq+ERp/wapdPT77q/fnMJ TGbw== X-Gm-Message-State: AD7BkJLTupbulaME+W9j2y/YiT7qOQ3qidcaZ3awrLjL72F8LPYJ3q5g5+cAkdD+8/ccknRhuRzAEutu0m6ZdA== MIME-Version: 1.0 X-Received: by 10.107.155.206 with SMTP id d197mr14476378ioe.135.1458929895223; Fri, 25 Mar 2016 11:18:15 -0700 (PDT) Sender: wlosh@bsdimp.com Received: by 10.36.65.230 with HTTP; Fri, 25 Mar 2016 11:18:15 -0700 (PDT) X-Originating-IP: [69.53.245.70] In-Reply-To: <2A98ACB7-2815-4169-951A-0123C71D9987@gmail.com> References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> <2A98ACB7-2815-4169-951A-0123C71D9987@gmail.com> Date: Fri, 25 Mar 2016 12:18:15 -0600 X-Google-Sender-Auth: 6KhcVNa7J0ormnwvji8_xAEyyIg Message-ID: Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Warner Losh To: Sylvain Garrigues Cc: ticso@cicely.de, freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 18:18:16 -0000 Have you looked at NetBSD to see what they do? It sounds like the SD driver in the boot roms is much faster than the one in u-boot.bin. Perhaps there's some init code we could import? Also, what are the kernel sizes? Maybe their kernel is smaller than ours for some reason and we should look at why... Warner On Fri, Mar 25, 2016 at 12:14 PM, Sylvain Garrigues wrote: > u-boot> fatload mmc 0 0x100000 kernel.bin > > takes around the same time than ubldr (actually slightly less, let=E2=80= =99s say > 4s - but that=E2=80=99s still so slow...) > > Happy to help or test anything to get FreeBSD=E2=80=99s kernel first line= appear > on the screen near =C2=AB instantaneously =C2=BB (~ 1s) like our NetBSD o= r Linux > friends. > > Sylvain > > > Le 25 mars 2016 =C3=A0 19:01, Warner Losh a =C3=A9crit : > > > > On Fri, Mar 25, 2016 at 11:55 AM, Sylvain Garrigues > wrote: > >> Thank you. >> >> I wanted to boot the kernel directly so as to: >> 1/ remove the dependency on a 3rd party loader >> 2/ reduce boot time and make it comparable with NetBSD and Linux (which >> don=E2=80=99t use u-boot) >> >> NetBSD and Linux on the Pi boot so much faster than our FreeBSD image: >> less than 1 second after power-up, the first kernel copyright line appea= rs >> on my LCD. For the FreeBSD images, the longest part is ubldr loading the >> kernel. It takes around 4/5 seconds (with the same SD card). >> >> I used recent u-boot versions (the current u-boot-rpi2 port is getting >> old and is not in sync with the u-boot-rpi port recently updated), tried >> with dcache enabled, but the boot process still takes several seconds, m= ost >> of the time being spent in ubldr loading the kernel. >> >> I have no idea how we could improve the booting time? I wanted to >> experiment with booting the kernel directly as the first ARM program on = my >> Pi, but as you explained I need some init code. I managed to compile >> Andrew=E2=80=99s one ( >> https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1= b39acd710c) >> but I don=E2=80=99t know how to use it. Andrew, if you read this ;-) >> >> I wonder if the loader could be more efficient at loading off the SD > card. The SD cards can do 10-20MB/s easily, and the ARM kernel is around > 5MB last time I checked. 5 seconds is 1MB/s, which is much slower than we > know the hardware can do. I don't know if that's because the callback > mechanism in u-boot.bin is so slow (that's what ubldr uses to load the > kernel), or there's something inherently slow about our loader. Some > analysis here might be quite useful. I'm guessing that we're not getting > all the benefits from streaming read mode because we're doing I/Os that a= re > tiny for some reason. But I haven't looked to make sure. > > What's the speed when booting directly from u-boot.bin? > > Warner > > > > > >> Le 25 mars 2016 =C3=A0 06:48, Warner Losh a =C3=A9crit = : >> >> >> >> On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter >> wrote: >> >>> On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: >>> > Hello, >>> > >>> > I have written a small (ugly) patch to be able to boot a kernel >>> directly without the ubldr loader while still using an external DTB >>> (Linux-style booting may pass the DTB location pointer in the r2 regist= er). >>> > The patch is here: >>> https://reviews.freebsd.org/differential/diff/14577/ >>> > >>> > I tested my patch successfully with the QEMU emulator with the -dtb >>> option available in recent versions, using a VERSATILEPB kernel without >>> FDT_STATIC. >>> > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash -cpu >>> arm1176 -dtb versatilepb.dtb >>> > FYI, once the kernel is built, here is the script to build the >>> versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 >>> registers): https://reviews.freebsd.org/P92 < >>> https://reviews.freebsd.org/P92> >>> > >>> > I also tested successfully my patch on my Raspberry Pi 2 using U-BOOT >>> and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI optio= n): >>> > u-boot> fatload mmc 0 0x200000 kernel.bin >>> > u-boot> go 0x200000 >>> > >>> > That works. >>> > >>> > So now I thought I could even bypass u-boot and launch kernel.bin >>> directly from the Pi firmware??? But it doesn???t work, I don???t >>> understand why, and that is why I am writing here. >>> > Here is the config.txt which I thought would work: >>> > >>> > kernel=3Dkernel.bin (instead of u-boot.bin) >>> > kernel_address=3D0x200000 (line added because a FreeBSD kernel needs = to >>> be loaded on a 1MB or 2MB boundary) >>> > device_tree=3Drpi2.dtb >>> > device_tree_address=3D0x100 >>> > disable_commandline_tags=3D1 >>> > >>> > What am I missing? Is it even possible to boot kernel.bin directly on >>> the Pi (with my patch)? I found this static minimalist loader from Andr= ew >>> here: >>> https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b= 1b39acd710c >>> < >>> https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b= 1b39acd710c> >>> - does it mean such a loader is necessary before the kernel? >>> > >>> > Thanks, >>> > Sylvain >>> > >>> > PS: I know the =C2=AB official and supported =C2=BB way of booting Fr= eeBSD on >>> the Pi is the u-boot + ubldr combination. I just would like to finish t= his >>> experiment and understand why kernel.bin cannot be booted directly. >>> >>> I don't know if it is part of ubldr, or if there is any additional code= , >>> which runs before ubldr, but the Pis won't boot with the ARM CPU. >>> Somewhere in the boot path is GPU bootcode, which then enables the ARM >>> CPU. >>> You also need low level HW init, such as setting up the clocks and RAM, >>> which is not done in the Kernel. >>> >> >> What you are missing it the hardware init code that's in u-boot.bin. Thi= s >> code sets up >> the board after the on-board GPU loads it into the ARM's address space. >> That code >> sets up the ARM side of the world and hands off the code to ubldr which >> finds the dtb >> and does the normal /boot/loader things as well (loading modules, settin= g >> tunables >> and the like) then hands off to the kernel. You can eliminate ubldr >> without a huge >> amount of effort, as you've found. However, eliminating u-boot.bin is >> going to be >> a lot more work/ >> >> tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is quite a >> bit different >> than between the initial bootstrap and u-boot.bin. So you can't just dro= p >> in kernel.bin >> and have it work without replicating that interface. >> >> Warner >> >> > From owner-freebsd-arm@freebsd.org Fri Mar 25 18:23:00 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48A77ADDA85 for ; Fri, 25 Mar 2016 18:23:00 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 25CB91871 for ; Fri, 25 Mar 2016 18:22:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 9f804c06-f2b6-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Fri, 25 Mar 2016 18:23:07 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2PIMoLU019394; Fri, 25 Mar 2016 12:22:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1458930170.1091.65.camel@freebsd.org> Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Ian Lepore To: Warner Losh , Sylvain Garrigues Cc: freebsd-arm , ticso@cicely.de Date: Fri, 25 Mar 2016 12:22:50 -0600 In-Reply-To: References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> Content-Type: text/plain; charset="iso-8859-7" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 18:23:00 -0000 On Fri, 2016-03-25 at 12:01 -0600, Warner Losh wrote: > On Fri, Mar 25, 2016 at 11:55 AM, Sylvain Garrigues > > wrote: > > > Thank you. > > > > I wanted to boot the kernel directly so as to: > > 1/ remove the dependency on a 3rd party loader > > 2/ reduce boot time and make it comparable with NetBSD and Linux > > (which > > dont use u-boot) > > > > NetBSD and Linux on the Pi boot so much faster than our FreeBSD > > image: > > less than 1 second after power-up, the first kernel copyright line > > appears > > on my LCD. For the FreeBSD images, the longest part is ubldr > > loading the > > kernel. It takes around 4/5 seconds (with the same SD card). > > > > I used recent u-boot versions (the current u-boot-rpi2 port is > > getting old > > and is not in sync with the u-boot-rpi port recently updated), > > tried with > > dcache enabled, but the boot process still takes several seconds, > > most of > > the time being spent in ubldr loading the kernel. > > > > I have no idea how we could improve the booting time? I wanted to > > experiment with booting the kernel directly as the first ARM > > program on my > > Pi, but as you explained I need some init code. I managed to > > compile > > Andrews one ( > > https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d > > 997b1b39acd710c) > > but I dont know how to use it. Andrew, if you read this ;-) > > > > I wonder if the loader could be more efficient at loading off the > > SD card. > The SD cards can do 10-20MB/s easily, and the ARM kernel is around > 5MB last > time I checked. 5 seconds is 1MB/s, which is much slower than we know > the > hardware can do. I don't know if that's because the callback > mechanism in > u-boot.bin is so slow (that's what ubldr uses to load the kernel), or > there's something inherently slow about our loader. Some analysis > here > might be quite useful. I'm guessing that we're not getting all the > benefits > from streaming read mode because we're doing I/Os that are tiny for > some > reason. But I haven't looked to make sure. > > What's the speed when booting directly from u-boot.bin? > > Warner To be clear here, the time it takes to get from hitting reset to the freebsd copyright on my rpi using u-boot and ubldr is 2.5 - 3 seconds. Considering some of the serious bugs we haven't had time to fix yet, this is just not a thing we need to waste a lot of effort on. -- Ian From owner-freebsd-arm@freebsd.org Fri Mar 25 21:35:53 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A0F6DADEB13 for ; Fri, 25 Mar 2016 21:35:53 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E971610B9 for ; Fri, 25 Mar 2016 21:35:52 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x234.google.com with SMTP id l68so34990127wml.1 for ; Fri, 25 Mar 2016 14:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=86A0mDRygApykRcebwqD6OKC1FS2gXUJag+SxIy1gMI=; b=dWLO/DnCzIBvTSUcVdug/3XYy4R/Cku+TEXcT75dg3jJLuC8Kh8xGT3rPQR6FYwL0v 94NQvooONuFgRlrGyXmHvDIgC3Ip6/Rd2/oxA4JKlgAPHuQhwCtqNnJKaZwHKpQROS8n BfkY2K89aBq7aloR6J3+lub1OD0uTXk1wJ6/AhdFz7TTphKunMfRW+/W4Kl4CcPM824K id8tlobu6VN53+RzkjNqJp8rrvitNhLZXIXzBL22n36BkYqnvqRnl6Rnq2PB9eCqr5p/ 5Wm0/UZYETAtf/374SiP5oehkCtTax59HBCmBqqau9Ygck0hkQpebseZPhwRm7XCB4pJ 5l7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=86A0mDRygApykRcebwqD6OKC1FS2gXUJag+SxIy1gMI=; b=D4DoJx7xotpiYhhCoZk6DwC81NmQsMo4D0nz1xCW/SFM5IC9wCF2DzrdsxZOzRLB/1 hI6iygG4e4bKLuiQlLA8t0yrxvVHxUf/Pnuja7RvSCSTZ4T9Jq5pIFRYeeJJeJGCCmG5 gFwUkz9lHfjernDCqEXIcsGklB9x+sLWPf/R8uhj9Sz3q90IhPF0obveUk2BI8VYyUsk mSvsIPC01WGIV9h2GFIJR4tZi/MLc+kIzhvlwLTOyP9EVzYH0/FABnB5+cf3Q0S6BTS6 /rnAvX6SZyacyP5vqG0pLIascgUBkdyC0Op+tLxxetbQQHSwF6/D5RKAqI271+4X4dvK APfw== X-Gm-Message-State: AD7BkJKThSHOuc1gEg8Sb6qrj/7cDV06mgjJT2uzNF4AAvogd3aQDsoIvVN36lgeQuSl6g== X-Received: by 10.28.109.4 with SMTP id i4mr481846wmc.44.1458941750104; Fri, 25 Mar 2016 14:35:50 -0700 (PDT) Received: from [192.168.0.4] ([81.56.235.196]) by smtp.gmail.com with ESMTPSA id up6sm13593604wjc.6.2016.03.25.14.35.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 25 Mar 2016 14:35:48 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: Booting kernel.bin directly on Raspberry Pi / external DTB support From: Sylvain Garrigues In-Reply-To: Date: Fri, 25 Mar 2016 22:35:47 +0100 Cc: ticso@cicely.de, freebsd-arm Message-Id: References: <1CCA59DC-5539-4CFB-81BA-0112E2120B3B@gmail.com> <20160325052509.GE48704@cicely7.cicely.de> <97BB142C-D335-469B-9514-D1210E869C5D@gmail.com> <2A98ACB7-2815-4169-951A-0123C71D9987@gmail.com> To: Warner Losh X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 21:35:53 -0000 > Le 25 mars 2016 =C3=A0 19:18, Warner Losh a =C3=A9crit = : >=20 > Have you looked at NetBSD to see what they do? It sounds like the SD = driver in the boot roms is much faster than the one in u-boot.bin. = Perhaps there's some init code we could import? Also, what are the = kernel sizes? Maybe their kernel is smaller than ours for some reason = and we should look at why... NetBSD=E2=80=99s kernel size for RPI2 is around 5.5MB which is similar = to our kernel. It is booted directly by the firmware and no specific config.txt is = required. So it looks exactly like a linux kernel, it even has a = cmdline.txt file which allows the passing of boot parameters (root=3Dld0a = console=3Dfb) You mentioned the ARM side of the RPI needs to be set up before being = able to run the FreeBSD kernel: for my understanding, any idea about = what the FreeBSD kernel requires exactly (apart from the metadata and = all the module loading stuff)? I mean what does it need in terms of = board set up - i.e. in other words what does u-boot does that is = required by the FreeBSD kernel? I was under the understanding that the = firmware sets up everything and even patches the DTB with board specific = values (memory size, etc). Given that the firmware passes the patched = DTB to the binary it loads, I expected the kernel.bin to boot directly, = but I am obviously wrong and lack some embedded knowledge.=20 I am sorry to ask here, I guess my questions aren=E2=80=99t of interest = to many people, but I want to learn more and can=E2=80=99t find = documentation on this matter. =20 Cheers, Sylvain.=20 > On Fri, Mar 25, 2016 at 12:14 PM, Sylvain Garrigues > wrote: > u-boot> fatload mmc 0 0x100000 kernel.bin >=20 > takes around the same time than ubldr (actually slightly less, let=E2=80= =99s say 4s - but that=E2=80=99s still so slow...) >=20 > Happy to help or test anything to get FreeBSD=E2=80=99s kernel first = line appear on the screen near =C2=AB instantaneously =C2=BB (~ 1s) like = our NetBSD or Linux friends. >=20 > Sylvain >=20 >=20 >> Le 25 mars 2016 =C3=A0 19:01, Warner Losh > a =C3=A9crit : >>=20 >>=20 >>=20 >> On Fri, Mar 25, 2016 at 11:55 AM, Sylvain Garrigues > wrote: >> Thank you.=20 >>=20 >> I wanted to boot the kernel directly so as to: >> 1/ remove the dependency on a 3rd party loader >> 2/ reduce boot time and make it comparable with NetBSD and Linux = (which don=E2=80=99t use u-boot) >>=20 >> NetBSD and Linux on the Pi boot so much faster than our FreeBSD = image: less than 1 second after power-up, the first kernel copyright = line appears on my LCD. For the FreeBSD images, the longest part is = ubldr loading the kernel. It takes around 4/5 seconds (with the same SD = card). >>=20 >> I used recent u-boot versions (the current u-boot-rpi2 port is = getting old and is not in sync with the u-boot-rpi port recently = updated), tried with dcache enabled, but the boot process still takes = several seconds, most of the time being spent in ubldr loading the = kernel. >>=20 >> I have no idea how we could improve the booting time? I wanted to = experiment with booting the kernel directly as the first ARM program on = my Pi, but as you explained I need some init code. I managed to compile = Andrew=E2=80=99s one = (https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b= 39acd710c = ) but I don=E2=80=99t know how to use it. Andrew, if you read = this ;-) >>=20 >> I wonder if the loader could be more efficient at loading off the SD = card. The SD cards can do 10-20MB/s easily, and the ARM kernel is around = 5MB last time I checked. 5 seconds is 1MB/s, which is much slower than = we know the hardware can do. I don't know if that's because the callback = mechanism in u-boot.bin is so slow (that's what ubldr uses to load the = kernel), or there's something inherently slow about our loader. Some = analysis here might be quite useful. I'm guessing that we're not getting = all the benefits from streaming read mode because we're doing I/Os that = are tiny for some reason. But I haven't looked to make sure. >>=20 >> What's the speed when booting directly from u-boot.bin? >>=20 >> Warner >>=20 >>=20 >>=20 >> =20 >>> Le 25 mars 2016 =C3=A0 06:48, Warner Losh > a =C3=A9crit : >>>=20 >>>=20 >>>=20 >>> On Thu, Mar 24, 2016 at 11:25 PM, Bernd Walter = > wrote: >>> On Thu, Mar 24, 2016 at 04:29:26PM +0100, Sylvain Garrigues wrote: >>> > Hello, >>> > >>> > I have written a small (ugly) patch to be able to boot a kernel = directly without the ubldr loader while still using an external DTB = (Linux-style booting may pass the DTB location pointer in the r2 = register). >>> > The patch is here: = https://reviews.freebsd.org/differential/diff/14577/ = >>> > >>> > I tested my patch successfully with the QEMU emulator with the = -dtb option available in recent versions, using a VERSATILEPB kernel = without FDT_STATIC. >>> > # qemu-system-arm -M versatilepb -m 128M -kernel versatile.flash = -cpu arm1176 -dtb versatilepb.dtb >>> > FYI, once the kernel is built, here is the script to build the = versatile.flash (adapted from gonzo, no longer need to clear the r0-r3 = registers): https://reviews.freebsd.org/P92 = > >>> > >>> > I also tested successfully my patch on my Raspberry Pi 2 using = U-BOOT and the RPI2 kernel with my patch applied (and the LINUX_BOOT_ABI = option): >>> > u-boot> fatload mmc 0 0x200000 kernel.bin >>> > u-boot> go 0x200000 >>> > >>> > That works. >>> > >>> > So now I thought I could even bypass u-boot and launch kernel.bin = directly from the Pi firmware??? But it doesn???t work, I don???t = understand why, and that is why I am writing here. >>> > Here is the config.txt which I thought would work: >>> > >>> > kernel=3Dkernel.bin (instead of u-boot.bin) >>> > kernel_address=3D0x200000 (line added because a FreeBSD kernel = needs to be loaded on a 1MB or 2MB boundary) >>> > device_tree=3Drpi2.dtb >>> > device_tree_address=3D0x100 >>> > disable_commandline_tags=3D1 >>> > >>> > What am I missing? Is it even possible to boot kernel.bin directly = on the Pi (with my patch)? I found this static minimalist loader from = Andrew here: = https://github.com/freebsd/freebsd/commit/074d37d46c3f9b282cd2d849d997b1b3= 9acd710c = > - does it mean such a loader is necessary before the kernel? >>> > >>> > Thanks, >>> > Sylvain >>> > >>> > PS: I know the =C2=AB official and supported =C2=BB way of booting = FreeBSD on the Pi is the u-boot + ubldr combination. I just would like = to finish this experiment and understand why kernel.bin cannot be booted = directly. >>>=20 >>> I don't know if it is part of ubldr, or if there is any additional = code, >>> which runs before ubldr, but the Pis won't boot with the ARM CPU. >>> Somewhere in the boot path is GPU bootcode, which then enables the = ARM >>> CPU. >>> You also need low level HW init, such as setting up the clocks and = RAM, >>> which is not done in the Kernel. >>>=20 >>> What you are missing it the hardware init code that's in u-boot.bin. = This code sets up >>> the board after the on-board GPU loads it into the ARM's address = space. That code >>> sets up the ARM side of the world and hands off the code to ubldr = which finds the dtb >>> and does the normal /boot/loader things as well (loading modules, = setting tunables >>> and the like) then hands off to the kernel. You can eliminate ubldr = without a huge >>> amount of effort, as you've found. However, eliminating u-boot.bin = is going to be >>> a lot more work/ >>>=20 >>> tl;dr: The interface between u-boot.bin and ubldr/kernel.bin is = quite a bit different >>> than between the initial bootstrap and u-boot.bin. So you can't just = drop in kernel.bin >>> and have it work without replicating that interface. >>>=20 >>> Warner >=20 >=20 From owner-freebsd-arm@freebsd.org Fri Mar 25 23:39:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F52FADD792 for ; Fri, 25 Mar 2016 23:39:06 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D388719C2 for ; Fri, 25 Mar 2016 23:39:05 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u2PNcn9W033508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 26 Mar 2016 00:38:49 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u2PNchG1061796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2016 00:38:43 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u2PNcgbQ053696; Sat, 26 Mar 2016 00:38:42 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u2PNcfoR053695; Sat, 26 Mar 2016 00:38:41 +0100 (CET) (envelope-from ticso) Date: Sat, 26 Mar 2016 00:38:41 +0100 From: Bernd Walter To: freebsd-arm@freebsd.org Cc: Bernd Walter Subject: Official images without noatime Message-ID: <20160325233841.GK48704@cicely7.cicely.de> Reply-To: ticso@cicely.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2016 23:39:06 -0000 /boot/msdos has noatime, but / hasn't. Considering SD media I think using noatime per default is a good idea to avoid increased riscs of data loss on power failures. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Sat Mar 26 09:33:11 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3DF3FADB35F for ; Sat, 26 Mar 2016 09:33:11 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id F36F21BEA for ; Sat, 26 Mar 2016 09:33:07 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ajkaX-000KD4-LZ for freeBSD-arm@freebsd.org; Sat, 26 Mar 2016 12:32:57 +0300 From: Daniel Braniss Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: WARNING: too long kenv string .. Message-Id: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> Date: Sat, 26 Mar 2016 12:33:18 +0300 To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 09:33:11 -0000 hi, with today=E2=80=99s current(*), I=E2=80=99m getting the kenv truncated = and so can=E2=80=99t continue with netboot rip-b. is there a parameter to change this? thanks, danny *: I see that kern_environment.c changed on the 10th of August= From owner-freebsd-arm@freebsd.org Sat Mar 26 09:35:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D47CADB3E1 for ; Sat, 26 Mar 2016 09:35:41 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D16171CBE for ; Sat, 26 Mar 2016 09:35:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ajkd5-000KEB-P0 for freeBSD-arm@freebsd.org; Sat, 26 Mar 2016 12:35:35 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: WARNING: too long kenv string .. From: Daniel Braniss In-Reply-To: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> Date: Sat, 26 Mar 2016 12:35:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> To: freebsd-arm X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 09:35:41 -0000 > On 26 Mar 2016, at 12:33 PM, Daniel Braniss = wrote: >=20 > hi, > with today=E2=80=99s current(*), I=E2=80=99m getting the kenv = truncated and so can=E2=80=99t continue > with netboot rip-b. s/rip/rpi/ =E2=80=94 no pun intended :-) > is there a parameter to change this? > thanks, > danny >=20 > *: I see that kern_environment.c changed on the 10th of August > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Mar 26 09:44:57 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 381B8ADB667 for ; Sat, 26 Mar 2016 09:44:57 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id F3FA311DB for ; Sat, 26 Mar 2016 09:44:56 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 08FA23AC81; Sat, 26 Mar 2016 10:44:49 +0100 (CET) Subject: Re: WARNING: too long kenv string .. To: Daniel Braniss , freebsd-arm References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> From: meloun X-Enigmail-Draft-Status: N1110 Organization: Miracle Group Message-ID: <56F65A10.80607@miracle.cz> Date: Sat, 26 Mar 2016 10:44:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sat, 26 Mar 2016 10:44:49 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 09:44:57 -0000 Dne 26.03.2016 v 10:35 Daniel Braniss napsal(a): > >> On 26 Mar 2016, at 12:33 PM, Daniel Braniss wrote: >> >> hi, >> with todays current(*), Im getting the kenv truncated and so cant continue >> with netboot rip-b. > s/rip/rpi/ no pun intended :-) > >> is there a parameter to change this? >> thanks, >> danny >> >> *: I see that kern_environment.c changed on the 10th of August >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > Are you at r297286 or later? I just committed some changes that can may be cause of this(r297284, r297285 and r297286). Also, more details are needed... Michal From owner-freebsd-arm@freebsd.org Sat Mar 26 10:29:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8C8DDADD368 for ; Sat, 26 Mar 2016 10:29:01 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4ABEB1B81 for ; Sat, 26 Mar 2016 10:29:00 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ajlSk-000Kld-ML; Sat, 26 Mar 2016 13:28:58 +0300 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: WARNING: too long kenv string .. From: Daniel Braniss In-Reply-To: <56F65A10.80607@miracle.cz> Date: Sat, 26 Mar 2016 13:29:19 +0300 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> <56F65A10.80607@miracle.cz> To: meloun X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 10:29:01 -0000 > On 26 Mar 2016, at 12:44 PM, meloun wrote: >=20 > Dne 26.03.2016 v 10:35 Daniel Braniss napsal(a): >>=20 >>> On 26 Mar 2016, at 12:33 PM, Daniel Braniss = wrote: >>>=20 >>> hi, >>> with today=E2=80=99s current(*), I=E2=80=99m getting the kenv = truncated and so can=E2=80=99t continue >>> with netboot rip-b. >> s/rip/rpi/ =E2=80=94 no pun intended :-) >>=20 >>> is there a parameter to change this? >>> thanks, >>> danny >>>=20 >>> *: I see that kern_environment.c changed on the 10th of August >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>=20 >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>=20 >=20 > Are you at r297286 or later? I just committed some changes that can = may > be cause of this(r297284, r297285 and r297286). it=E2=80=99s now r297286 > Also, more details are needed=E2=80=A6 I=E2=80=99m net booting an RPI-B, it loads alright, but early on it complains: Booting [/boot/kernel/kernel]... =20 Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x0x2200100... Kernel args: (null) ARM Debug Architecture not supported KDB: debugger backends: ddb KDB: current backend: ddb Copyright (c) 1992-2016 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 #16 r297286M: Sat Mar 26 11:47:32 IDT 2016 = danny@rnd:/home/obj/rnd/armv6/rpi/arm.armv6/r+d/vanilla/11/src/sys/RPI-B = arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on = LLVM 3.8.0) VT: init without driver. WARNING: too long kenv string, ignoring dma.dmachans=3D0x7f35 = bcm2708_fb.fbwidth=3D656 bcm2708_fb.fbheight=3D416 bcm2708.boardrev=3D0x10= bcm2708.serial=3D0x48bc91a1 smsc95xx.macaddr=3DB8:27:EB:BC:91:A1 = bcm2708.disk_led_gpio=3D47 bcm2708.disk_led_active_low=3D0 = sdhci-bcm2708.emmc_clock_freq=3D250000000 vc_mem.mem_base=3D0x1ec00000 = vc_mem.mem_size=3D0x20000000 console=3DttyAMA0,115200 = kgdboc=3DttyAMA0,115200 console=3Dtty1 root=3D/dev/mmcblk0p2 = rootfstype=3Dext4 rootwait sema_sysinit CPU: ARM1176JZ-S rev 7 (ARM11J core) >=20 > Michal >=20 >=20 From owner-freebsd-arm@freebsd.org Sat Mar 26 11:03:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30784ADDB4E for ; Sat, 26 Mar 2016 11:03:39 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id EC02B1E47 for ; Sat, 26 Mar 2016 11:03:38 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 769233AC8C; Sat, 26 Mar 2016 12:03:37 +0100 (CET) Subject: Re: WARNING: too long kenv string .. To: Daniel Braniss References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> <56F65A10.80607@miracle.cz> Cc: freebsd-arm From: meloun X-Enigmail-Draft-Status: N1110 Organization: Miracle Group Message-ID: <56F66C89.6040803@miracle.cz> Date: Sat, 26 Mar 2016 12:03:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sat, 26 Mar 2016 12:03:37 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 11:03:39 -0000 Dne 26.03.2016 v 11:29 Daniel Braniss napsal(a): > >> On 26 Mar 2016, at 12:44 PM, meloun wrote: >> >> Dne 26.03.2016 v 10:35 Daniel Braniss napsal(a): >>> >>>> On 26 Mar 2016, at 12:33 PM, Daniel Braniss wrote: >>>> >>>> hi, >>>> with todays current(*), Im getting the kenv truncated and so cant continue >>>> with netboot rip-b. >>> s/rip/rpi/ no pun intended :-) >>> >>>> is there a parameter to change this? >>>> thanks, >>>> danny >>>> >>>> *: I see that kern_environment.c changed on the 10th of August >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>> >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>> >> >> Are you at r297286 or later? I just committed some changes that can may >> be cause of this(r297284, r297285 and r297286). > its now r297286 >> Also, more details are needed > Im net booting an RPI-B, it loads alright, > but early on it complains: > > Booting [/boot/kernel/kernel]... > Using DTB provided by U-Boot at address 0x100. > Kernel entry at 0x0x2200100... > Kernel args: (null) > ARM Debug Architecture not supported > KDB: debugger backends: ddb > KDB: current backend: ddb > Copyright (c) 1992-2016 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 #16 r297286M: Sat Mar 26 11:47:32 IDT 2016 > danny@rnd:/home/obj/rnd/armv6/rpi/arm.armv6/r+d/vanilla/11/src/sys/RPI-B arm > FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM 3.8.0) > VT: init without driver. > WARNING: too long kenv string, ignoring dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0x10 bcm2708.serial=0x48bc91a1 smsc95xx.macaddr=B8:27:EB:BC:91:A1 bcm2708.disk_led_gpio=47 bcm2708.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait > sema_sysinit > CPU: ARM1176JZ-S rev 7 (ARM11J core) Can you please test if r297283 also fails? I don't have access to RPI at this moment, sorry. Problem is that somebody puts original linux bootargs into kernel environment - this can be caused by my pathes, or by any change in ubldr itself. Michal From owner-freebsd-arm@freebsd.org Sat Mar 26 11:32:36 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8E71ADE480 for ; Sat, 26 Mar 2016 11:32:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4C77F1092 for ; Sat, 26 Mar 2016 11:32:36 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ajmSE-000LRG-2k; Sat, 26 Mar 2016 14:32:30 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: WARNING: too long kenv string .. From: Daniel Braniss In-Reply-To: <56F66C89.6040803@miracle.cz> Date: Sat, 26 Mar 2016 14:32:51 +0300 Cc: freebsd-arm Message-Id: References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> <56F65A10.80607@miracle.cz> <56F66C89.6040803@miracle.cz> To: meloun X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 11:32:36 -0000 > On 26 Mar 2016, at 2:03 PM, meloun wrote: >=20 > Dne 26.03.2016 v 11:29 Daniel Braniss napsal(a): >>=20 >>> On 26 Mar 2016, at 12:44 PM, meloun wrote: >>>=20 >>> Dne 26.03.2016 v 10:35 Daniel Braniss napsal(a): >>>>=20 >>>>> On 26 Mar 2016, at 12:33 PM, Daniel Braniss = wrote: >>>>>=20 >>>>> hi, >>>>> with today=E2=80=99s current(*), I=E2=80=99m getting the kenv = truncated and so can=E2=80=99t continue >>>>> with netboot rip-b. >>>> s/rip/rpi/ =E2=80=94 no pun intended :-) >>>>=20 >>>>> is there a parameter to change this? >>>>> thanks, >>>>> danny >>>>>=20 >>>>> *: I see that kern_environment.c changed on the 10th of August >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>=20 >>>> _______________________________________________ >>>> freebsd-arm@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>=20 >>>=20 >>> Are you at r297286 or later? I just committed some changes that can = may >>> be cause of this(r297284, r297285 and r297286). >> it=E2=80=99s now r297286 >>> Also, more details are needed=E2=80=A6 >> I=E2=80=99m net booting an RPI-B, it loads alright, >> but early on it complains: >>=20 >> Booting [/boot/kernel/kernel]... =20 >> Using DTB provided by U-Boot at address 0x100. >> Kernel entry at 0x0x2200100... >> Kernel args: (null) >> ARM Debug Architecture not supported >> KDB: debugger backends: ddb >> KDB: current backend: ddb >> Copyright (c) 1992-2016 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 #16 r297286M: Sat Mar 26 11:47:32 IDT 2016 >> = danny@rnd:/home/obj/rnd/armv6/rpi/arm.armv6/r+d/vanilla/11/src/sys/RPI-B = arm >> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on = LLVM 3.8.0) >> VT: init without driver. >> WARNING: too long kenv string, ignoring dma.dmachans=3D0x7f35 = bcm2708_fb.fbwidth=3D656 bcm2708_fb.fbheight=3D416 bcm2708.boardrev=3D0x10= bcm2708.serial=3D0x48bc91a1 smsc95xx.macaddr=3DB8:27:EB:BC:91:A1 = bcm2708.disk_led_gpio=3D47 bcm2708.disk_led_active_low=3D0 = sdhci-bcm2708.emmc_clock_freq=3D250000000 vc_mem.mem_base=3D0x1ec00000 = vc_mem.mem_size=3D0x20000000 console=3DttyAMA0,115200 = kgdboc=3DttyAMA0,115200 console=3Dtty1 root=3D/dev/mmcblk0p2 = rootfstype=3Dext4 rootwait >> sema_sysinit >> CPU: ARM1176JZ-S rev 7 (ARM11J core) >=20 > Can you please test if r297283 also fails? I don't have access to RPI = at > this moment, sorry. >=20 i will, but this will take some time. in the meantime, booting from the SD card has the same issue. > Problem is that somebody puts original linux bootargs into kernel > environment - this can be caused by my pathes, or by any change in = ubldr > itself. >=20 > Michal From owner-freebsd-arm@freebsd.org Sat Mar 26 11:49:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E200ADE9EB for ; Sat, 26 Mar 2016 11:49:31 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from srv56-45.cdn.bestreaming.com (ns330343.ip-37-187-119.eu [37.187.119.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "amnesiac", Issuer "amnesiac" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 131BA1E1C for ; Sat, 26 Mar 2016 11:49:29 +0000 (UTC) (envelope-from fbl@aoek.com) Received: from mail.yourbox.net (localhost [IPv6:::1]) by srv56-45.cdn.bestreaming.com (8.15.2/8.15.2) with ESMTP id u2QBpd9b046854; Sat, 26 Mar 2016 12:51:39 +0100 (CET) (envelope-from fbl@aoek.com) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Sat, 26 Mar 2016 12:51:38 +0100 From: =?UTF-8?Q?Jos=C3=A9_P=C3=A9rez?= To: ticso@cicely.de Cc: freebsd-arm@freebsd.org Subject: Re: Official images without noatime In-Reply-To: <20160325233841.GK48704@cicely7.cicely.de> References: <20160325233841.GK48704@cicely7.cicely.de> Message-ID: X-Sender: fbl@aoek.com User-Agent: Roundcube Webmail/1.1.3 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 11:49:31 -0000 Hi, agree, in fact I have noatime on / as well. Shall be the default. Cheers, --- Jos Prez El 2016-03-26 00:38, Bernd Walter escribi: > /boot/msdos has noatime, but / hasn't. > Considering SD media I think using noatime per default is a good > idea to avoid increased riscs of data loss on power failures. From owner-freebsd-arm@freebsd.org Sat Mar 26 12:24:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D0A40ADD662 for ; Sat, 26 Mar 2016 12:24:10 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from mail.miracle.cz (mail.miracle.cz [193.84.128.19]) by mx1.freebsd.org (Postfix) with ESMTP id 5AAD1199A for ; Sat, 26 Mar 2016 12:24:09 +0000 (UTC) (envelope-from meloun@miracle.cz) Received: from [193.84.128.50] (meloun.ad.miracle.cz [193.84.128.50]) by mail.miracle.cz (Postfix) with ESMTPSA id 70F453AC81; Sat, 26 Mar 2016 13:24:08 +0100 (CET) Subject: Re: WARNING: too long kenv string .. To: Daniel Braniss References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> <56F65A10.80607@miracle.cz> <56F66C89.6040803@miracle.cz> Cc: freebsd-arm From: meloun Organization: Miracle Group Message-ID: <56F67F68.9020403@miracle.cz> Date: Sat, 26 Mar 2016 13:24:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.miracle.cz); Sat, 26 Mar 2016 13:24:08 +0100 (CET) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 12:24:10 -0000 Dne 26.03.2016 v 12:32 Daniel Braniss napsal(a): > >> On 26 Mar 2016, at 2:03 PM, meloun > > wrote: >> >> Dne 26.03.2016 v 11:29 Daniel Braniss napsal(a): >>> >>>> On 26 Mar 2016, at 12:44 PM, meloun >>> > wrote: >>>> >>>> Dne 26.03.2016 v 10:35 Daniel Braniss napsal(a): >>>>> >>>>>> On 26 Mar 2016, at 12:33 PM, Daniel Braniss >>>>> > wrote: >>>>>> >>>>>> hi, >>>>>> with todays current(*), Im getting the kenv truncated and so >>>>>> cant continue >>>>>> with netboot rip-b. >>>>> s/rip/rpi/ no pun intended :-) >>>>> >>>>>> is there a parameter to change this? >>>>>> thanks, >>>>>> danny >>>>>> >>>>>> *: I see that kern_environment.c changed on the 10th of August >>>>>> _______________________________________________ >>>>>> freebsd-arm@freebsd.org mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>>>> >>>>> _______________________________________________ >>>>> freebsd-arm@freebsd.org mailing list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" >>>>> >>>> >>>> Are you at r297286 or later? I just committed some changes that can may >>>> be cause of this(r297284, r297285 and r297286). >>> its now r297286 >>>> Also, more details are needed >>> Im net booting an RPI-B, it loads alright, >>> but early on it complains: >>> >>> Booting [/boot/kernel/kernel]... >>> Using DTB provided by U-Boot at address 0x100. >>> Kernel entry at 0x0x2200100... >>> Kernel args: (null) >>> ARM Debug Architecture not supported >>> KDB: debugger backends: ddb >>> KDB: current backend: ddb >>> Copyright (c) 1992-2016 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 #16 r297286M: Sat Mar 26 11:47:32 IDT 2016 >>> danny@rnd:/home/obj/rnd/armv6/rpi/arm.armv6/r+d/vanilla/11/src/sys/RPI-B >>> arm >>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on >>> LLVM 3.8.0) >>> VT: init without driver. >>> WARNING: too long kenv string, ignoring dma.dmachans=0x7f35 >>> bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2708.boardrev=0x10 >>> bcm2708.serial=0x48bc91a1 smsc95xx.macaddr=B8:27:EB:BC:91:A1 >>> bcm2708.disk_led_gpio=47 bcm2708.disk_led_active_low=0 >>> sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 >>> vc_mem.mem_size=0x20000000 console=ttyAMA0,115200 >>> kgdboc=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 >>> rootfstype=ext4 rootwait >>> sema_sysinit >>> CPU: ARM1176JZ-S rev 7 (ARM11J core) >> >> Can you please test if r297283 also fails? I don't have access to RPI at >> this moment, sorry. >> > i will, but this will take some time. > in the meantime, booting from the SD card has the same issue. > >> Problem is that somebody puts original linux bootargs into kernel >> environment - this can be caused by my pathes, or by any change in ubldr >> itself. >> >> Michal > Nevermind, I found it (I hope), my fault. Fixed in r297292. Sorry for breakage. Michal From owner-freebsd-arm@freebsd.org Sat Mar 26 12:31:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 008C3ADD70B for ; Sat, 26 Mar 2016 12:31:18 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 876201C45 for ; Sat, 26 Mar 2016 12:31:16 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ajnMz-000Lzs-SM; Sat, 26 Mar 2016 15:31:10 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: WARNING: too long kenv string .. From: Daniel Braniss In-Reply-To: <56F67F68.9020403@miracle.cz> Date: Sat, 26 Mar 2016 15:31:30 +0300 Cc: freebsd-arm Message-Id: <78A9C812-8DD8-4CBA-B9A2-0F3033F7E426@cs.huji.ac.il> References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> <56F65A10.80607@miracle.cz> <56F66C89.6040803@miracle.cz> <56F67F68.9020403@miracle.cz> To: meloun X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 12:31:18 -0000 > On 26 Mar 2016, at 3:24 PM, meloun wrote: >=20 > Dne 26.03.2016 v 12:32 Daniel Braniss napsal(a): >>=20 >>> On 26 Mar 2016, at 2:03 PM, meloun >>> >> wrote: >>>=20 >>> Dne 26.03.2016 v 11:29 Daniel Braniss napsal(a): >>>>=20 >>>>> On 26 Mar 2016, at 12:44 PM, meloun >>>>> >> wrote: >>>>>=20 >>>>> Dne 26.03.2016 v 10:35 Daniel Braniss napsal(a): >>>>>>=20 >>>>>>> On 26 Mar 2016, at 12:33 PM, Daniel Braniss >>>>>>> >> = wrote: >>>>>>>=20 >>>>>>> hi, >>>>>>> with today=E2=80=99s current(*), I=E2=80=99m getting the kenv = truncated and so >>>>>>> can=E2=80=99t continue >>>>>>> with netboot rip-b. >>>>>> s/rip/rpi/ =E2=80=94 no pun intended :-) >>>>>>=20 >>>>>>> is there a parameter to change this? >>>>>>> thanks, >>>>>>> danny >>>>>>>=20 >>>>>>> *: I see that kern_environment.c changed on the 10th of August >>>>>>> _______________________________________________ >>>>>>> freebsd-arm@freebsd.org = > = mailing list >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = >>>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = " >>>>>>=20 >>>>>> _______________________________________________ >>>>>> freebsd-arm@freebsd.org = > = mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>>=20 >>>>>=20 >>>>> Are you at r297286 or later? I just committed some changes that = can may >>>>> be cause of this(r297284, r297285 and r297286). >>>> it=E2=80=99s now r297286 >>>>> Also, more details are needed=E2=80=A6 >>>> I=E2=80=99m net booting an RPI-B, it loads alright, >>>> but early on it complains: >>>>=20 >>>> Booting [/boot/kernel/kernel]... =20 >>>> Using DTB provided by U-Boot at address 0x100. >>>> Kernel entry at 0x0x2200100... >>>> Kernel args: (null) >>>> ARM Debug Architecture not supported >>>> KDB: debugger backends: ddb >>>> KDB: current backend: ddb >>>> Copyright (c) 1992-2016 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 #16 r297286M: Sat Mar 26 11:47:32 IDT 2016 >>>> = danny@rnd:/home/obj/rnd/armv6/rpi/arm.armv6/r+d/vanilla/11/src/sys/RPI-B >>>> arm >>>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based = on >>>> LLVM 3.8.0) >>>> VT: init without driver. >>>> WARNING: too long kenv string, ignoring dma.dmachans=3D0x7f35 >>>> bcm2708_fb.fbwidth=3D656 bcm2708_fb.fbheight=3D416 = bcm2708.boardrev=3D0x10 >>>> bcm2708.serial=3D0x48bc91a1 smsc95xx.macaddr=3DB8:27:EB:BC:91:A1 >>>> bcm2708.disk_led_gpio=3D47 bcm2708.disk_led_active_low=3D0 >>>> sdhci-bcm2708.emmc_clock_freq=3D250000000 = vc_mem.mem_base=3D0x1ec00000 >>>> vc_mem.mem_size=3D0x20000000 console=3DttyAMA0,115200 >>>> kgdboc=3DttyAMA0,115200 console=3Dtty1 root=3D/dev/mmcblk0p2 >>>> rootfstype=3Dext4 rootwait >>>> sema_sysinit >>>> CPU: ARM1176JZ-S rev 7 (ARM11J core) >>>=20 >>> Can you please test if r297283 also fails? I don't have access to = RPI at >>> this moment, sorry. >>>=20 >> i will, but this will take some time. >> in the meantime, booting from the SD card has the same issue. >>=20 >>> Problem is that somebody puts original linux bootargs into kernel >>> environment - this can be caused by my pathes, or by any change in = ubldr >>> itself. >>>=20 >>> Michal >>=20 >=20 > Nevermind, I found it (I hope), my fault. Fixed in r297292. > Sorry for breakage. i=E2=80=99ll try it ASAP thanks danny > Michal From owner-freebsd-arm@freebsd.org Sat Mar 26 12:32:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D12CAADD871; Sat, 26 Mar 2016 12:32:44 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: from mail.lifanov.com (mail.lifanov.com [206.125.175.12]) (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 C08911E71; Sat, 26 Mar 2016 12:32:44 +0000 (UTC) (envelope-from lifanov@mail.lifanov.com) Received: by mail.lifanov.com (Postfix, from userid 58) id B6C36239E54; Sat, 26 Mar 2016 08:32:38 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.lifanov.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.1 Received: from app.lifanov.com (chat.lifanov.com [206.125.175.13]) by mail.lifanov.com (Postfix) with ESMTPA id 7D914239E52; Sat, 26 Mar 2016 08:32:35 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 26 Mar 2016 08:32:34 -0400 From: Nikolai Lifanov To: freebsd-arm@freebsd.org Cc: owner-freebsd-arm@freebsd.org, freebsd-arm-request@freebsd.org Subject: Re: Official images without noatime In-Reply-To: References: Message-ID: <4b23b28ffae59216b5dde8f28f665330@mail.lifanov.com> X-Sender: lifanov@mail.lifanov.com User-Agent: Roundcube Webmail/1.1.4 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 12:32:44 -0000 > > Hi, > agree, in fact I have noatime on / as well. Shall be the default. > > > > Cheers, > > > --- > Jos? P?rez > > El 2016-03-26 00:38, Bernd Walter escribi?: >> /boot/msdos has noatime, but / hasn't. >> Considering SD media I think using noatime per default is a good >> idea to avoid increased riscs of data loss on power failures. > Since we also default to SU-no-J, power failure can be quite bad during, say, installworld. With / noatime, I had my RPI2 lose files like /usr/bin/cmp, /bin/ls, and /bin/cat during a power loss. Since it's not even possible to cleanly shut down this platform, I'm for enabling noatime for / on at least for RPI and RPI2 platforms. - Nikolai Lifanov From owner-freebsd-arm@freebsd.org Sat Mar 26 12:38:48 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BBEE8ADD9AA for ; Sat, 26 Mar 2016 12:38:48 +0000 (UTC) (envelope-from robin43774@qq.com) Received: from smtpproxy32.qq.com (smtpproxy32.qq.com [103.7.31.14]) (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 2DDAD1172 for ; Sat, 26 Mar 2016 12:38:47 +0000 (UTC) (envelope-from robin43774@qq.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=qq.com; s=s201512; t=1458995856; bh=3U5o3tTL5DLCrP70ct3VSi6XF+ArMOZnQ/9sOJehy5s=; h=From:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:Date:Message-ID; b=q2Hduut4KB5d9ZoSBdjSNkjBa85fbboY2P9lIWXszfujcTT2J6dcO51HDokwBQRJ5 A7PszoipJBVop1LrbzbDBxFrS05X+fY48PHfwrvYjVAdJAdzSTcJIWa1MhI3zb8Ehz zo+Fl+WZ7nbVXh5P8DREO8H+rRKW0jPpLTy8rqlc= X-QQ-FEAT: T8v0qjBg/kUGaZGN1RS9d4jGxG1uPwAXLdNgz/MssQG8ng6e1CHe9CDHeHED1 w/RLGj7DrSoUH0oEI/vv8+LQzyS1JQqEMiYkulxxM9qB9ROC/0eWOGUtsg4CCgoTmwH+2l4 2I7IIqv7f0SdBCAQIZqqa8yBcC91UvJmJBivYIP5jTeQ8llikd6szdMfWBZTTLI94/+xgQx tutjJmxqoBjzrsXJfl4EOJeHgw/Ai7cIje3Stotvi7AZplGk9RzXULlcAlfYz5+I= X-QQ-SSF: 00000000000000F000000000000000M X-HAS-ATTACH: no X-QQ-BUSINESS-ORIGIN: 2 X-Originating-IP: 115.190.196.123 X-QQ-STYLE: X-QQ-mid: webmail752t1458995855t7415126 From: "=?gb18030?B?1PPB+g==?=" To: "=?gb18030?B?ZnJlZWJzZC1hcm0=?=" Subject: Care to porting FreeBSD to super cheap OPI-PC? Mime-Version: 1.0 Date: Sat, 26 Mar 2016 20:37:35 +0800 X-Priority: 3 Message-ID: X-QQ-MIME: TCMime 1.0 by Tencent X-Mailer: QQMail 2.x X-QQ-Mailer: QQMail 2.x X-QQ-SENDSIZE: 520 X-QQ-Bgrelay: 1 Content-Type: text/plain; charset="gb18030" Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 12:38:48 -0000 RnJlZUJTRCBEZXZlbG9wZXJzDQogR3JlZXRpbmdzLCBJIGJvdWdodCBhIHN1cGVyIGNoZWFw IGRldmVsb3AgYm9hcmQgY2FsbGVkIE9yYW5nZVBpIFBDLiBJdCBpcyBhIEFsbHdpbm5lciBI MyBTb0MuIEkgY2FuIHJ1biBVYnVudHUgRGViaWFuIEFyY2hMaW51eCBGZWRvcmEgYW5kIE9w ZW5XUlQgb24gaXQuIEJ1dCBJIHdvdWxkIGxpa2UgdG8gc2VlIEZyZWVCU0QgcnVubmluZyBv biBpdC4gVGhpcyBpcyBhIEFsbHdpbm5lciBIMyBiYXNlZCBxdWFkLWNvcmUgYm9hcmQgcnVu cyBwcmV0dHkgZmFzdC4gQW55b25lIGludGVyZXN0ZWQgcG9ydGluZyBGcmVlQlNEIHRvIHRo aXMgYm9hcmQgd2lsbCBiZSBhcHByZWNpYXRlZC4gSSBjYW4gY29udGFjdCB0aGUgbWFudWZh Y3RyaW5nIGNvbXBhbnkgdG8gc2VuZCBkZXZlbG9wZXJzIGhlcmUgc29tZSBzYW1wbGUgYm9h cmRzIGZvciBkZXZlbG9waW5nIHB1cnBvc2UgaWYgc29tZW9uZSBpbnRlcmVzdGVkLiBCLnQu dy4gc3VueGktbGludXggYW5kIGEgZmV3IGZhbnMgaGF2ZSBhZGRlZCBtYWlubGluZSBzdXBw b3J0IGZvciBBbGx3aW5uZXIgSDMuIEluIGNhc2UgeW91IGFyZSBpbnRlcmVzdGVkLg0KIFlv dSBjYW4gY2hlY2sgdGhlIE9yYW5nZXBpIHdlYnNpdGUgYW5kIGZvcnVtIGZvciBtb3JlIGlu Zm8uDQogaHR0cDovL3d3dy5vcmFuZ2VwaS5vcmcvDQogWW91IGNhbiBhbHNvIGNoZWNrIGFy bWJpYW4gZm9ydW0gZm9yIGluZm8gYWJvdXQgdGhpcyBib2FyZC4NCiBodHRwOi8vd3d3LmFy bWJpYW4uY29tLw0KIFJlZ2FyZHMNCiBSb2Jpbg== From owner-freebsd-arm@freebsd.org Sat Mar 26 14:20:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B46F9ADEA31 for ; Sat, 26 Mar 2016 14:20:14 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5EDBF197B for ; Sat, 26 Mar 2016 14:20:14 +0000 (UTC) (envelope-from guyyur@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id l68so52534439wml.0 for ; Sat, 26 Mar 2016 07:20: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; bh=+lr2UpPoek5XdFL6vJ5eo+eCZS7Zqu076FMNhBgLtqE=; b=rhcPS0IofQNBrZoYJZfe/mWIpXzD4Xudb7zu3Xw/5nSSuGj9RL7MYRulS9pVBt/y7f Nlfq9f2ReCtTU6w6HHsbkLrTljh+osfFui7a4GOjJBC+/rEedYVLbKHvRzfgPs3fNjbU /LE9L5Is3+ivwX4Jh+W6lt8tzLcgkJY4TvmjGo6N5zvLrrZoHj/aUBUHIE2Bdmj83tGU Zwnh0PqHEAfWpQXma9tAdBdg6f/iJAB0z3rlGK6xChhOd0o0Z9h3J/MmtOxUvSBY2sEC t5zf11Fsicv2uTvv19dV5Bm+BQuMv4A3QZj3d/Asw4XClb9HKzNOD4J99sccMwEI5Wcb VljQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=+lr2UpPoek5XdFL6vJ5eo+eCZS7Zqu076FMNhBgLtqE=; b=c+dnjepaNpXZ25Ror7FmjhIQyyIaz3EXPGcUHRDgGArIvorwiAPf/Zr4fMQtNrMixa Z4FooXNQhf9V0x3LFjH+hgkvoPzuak1hmNlCIXj1tYbBGdoOesRtsFCjhpu8g4OKZSCb sn9zH3qc14kPG5V6v5GDcuhVGi/+GU9aqVpOK7AQkqrjLd4TmyvacCZQsVT47/d/6Quc HBLrAhz78NHHH/rzgFRu8eP6MMaC9MywJdL1Io7w64SwkFff79FOe8pSpzsxrqL/7ZSI xxMGqu1h/MPavTgLYFwEbysNF0GTlI2GIFQt7WUJQLv1Jd5y6wFBMn0pqbl5ZqM+bG8e kLdw== X-Gm-Message-State: AD7BkJILwL+OeB4EqC3IUP5nPMMp+TNTrPQW1xZkx2aeCXiPrbyt7NOADu09qmwURiPul0Fe/IAIBsIyJTaHew== MIME-Version: 1.0 X-Received: by 10.28.225.198 with SMTP id y189mr2118489wmg.94.1459002012686; Sat, 26 Mar 2016 07:20:12 -0700 (PDT) Received: by 10.28.224.84 with HTTP; Sat, 26 Mar 2016 07:20:12 -0700 (PDT) Date: Sat, 26 Mar 2016 17:20:12 +0300 Message-ID: Subject: ODROID C1+ dwc doesn't pass rx multicast ipv6 packets unless in promiscuous mode From: Guy Yur To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 14:20:14 -0000 Hi, I am running rtadvd on my ODROID C1+ and router solicitation messages sent from other hosts are not seen in tcpdump unless I put the NIC in promiscuous mode. I was able to pass the multicast packets by switching to the NetBSD dwc_gmac driver registers AWIN_GMAC_MAC_HTHIGH, AWIN_GMAC_MAC_HTLOW instead of HASH_TABLE_REG(n) and using only the upper 6 bits instead of the upper 8 bits. http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/ic/dwc_gmac.c?only_with_tag=MAIN The linux driver stmmac only uses HASH_TABLE_REG(n) (0x500 + (0x4 * n)) if the hash table size is 128 or 256. If the hash table size is 64 it uses AWIN_GMAC_MAC_HTHIGH (0x8) and AWIN_GMAC_MAC_HTLOW (0xc). The hash table size defaults to 64 and can be overridden from dts snps,multicast-filter-bins. socfpga.dtsi defines it as 256 on linux so the Altera Cyclone has 8 bits and if_dwc works for it but not for the ODROID C1+ which only has 6 bits. Guy From owner-freebsd-arm@freebsd.org Sat Mar 26 14:32:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A586DADED26 for ; Sat, 26 Mar 2016 14:32:40 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3174511BF for ; Sat, 26 Mar 2016 14:32:39 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from imac.bs.cs.huji.ac.il ([132.65.179.42]) by kabab.cs.huji.ac.il with esmtp id 1ajpGT-000NBi-3V; Sat, 26 Mar 2016 17:32:33 +0300 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: WARNING: too long kenv string .. From: Daniel Braniss In-Reply-To: <78A9C812-8DD8-4CBA-B9A2-0F3033F7E426@cs.huji.ac.il> Date: Sat, 26 Mar 2016 17:32:54 +0300 Cc: freebsd-arm Message-Id: <1D93A8E1-8808-4B26-A3E5-6A2FC8729AE9@cs.huji.ac.il> References: <5CF7F07B-B853-4964-8F0B-78BEC0B28919@cs.huji.ac.il> <0FE2A25F-25EE-435A-8177-AA98D49696FA@cs.huji.ac.il> <56F65A10.80607@miracle.cz> <56F66C89.6040803@miracle.cz> <56F67F68.9020403@miracle.cz> <78A9C812-8DD8-4CBA-B9A2-0F3033F7E426@cs.huji.ac.il> To: meloun X-Mailer: Apple Mail (2.3112) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 14:32:40 -0000 > On 26 Mar 2016, at 3:31 PM, Daniel Braniss = wrote: >=20 >>=20 >> On 26 Mar 2016, at 3:24 PM, meloun > wrote: >>=20 >> Dne 26.03.2016 v 12:32 Daniel Braniss napsal(a): >>>=20 >>>> On 26 Mar 2016, at 2:03 PM, meloun > >>>> = >>> wrote: >>>>=20 >>>> Dne 26.03.2016 v 11:29 Daniel Braniss napsal(a): >>>>>=20 >>>>>> On 26 Mar 2016, at 12:44 PM, meloun > >>>>>> = >>> wrote: >>>>>>=20 >>>>>> Dne 26.03.2016 v 10:35 Daniel Braniss napsal(a): >>>>>>>=20 >>>>>>>> On 26 Mar 2016, at 12:33 PM, Daniel Braniss = = > >>>>>>>> = >>> wrote: >>>>>>>>=20 >>>>>>>> hi, >>>>>>>> with today=E2=80=99s current(*), I=E2=80=99m getting the kenv = truncated and so >>>>>>>> can=E2=80=99t continue >>>>>>>> with netboot rip-b. >>>>>>> s/rip/rpi/ =E2=80=94 no pun intended :-) >>>>>>>=20 >>>>>>>> is there a parameter to change this? >>>>>>>> thanks, >>>>>>>> danny >>>>>>>>=20 >>>>>>>> *: I see that kern_environment.c changed on the 10th of August >>>>>>>> _______________________________________________ >>>>>>>> freebsd-arm@freebsd.org = > = = >> = mailing list >>>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm = = > >>>>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org = = >" >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> freebsd-arm@freebsd.org = > = = >> = mailing list >>>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>>>>>> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >>>>>>>=20 >>>>>>=20 >>>>>> Are you at r297286 or later? I just committed some changes that = can may >>>>>> be cause of this(r297284, r297285 and r297286). >>>>> it=E2=80=99s now r297286 >>>>>> Also, more details are needed=E2=80=A6 >>>>> I=E2=80=99m net booting an RPI-B, it loads alright, >>>>> but early on it complains: >>>>>=20 >>>>> Booting [/boot/kernel/kernel]... =20 >>>>> Using DTB provided by U-Boot at address 0x100. >>>>> Kernel entry at 0x0x2200100... >>>>> Kernel args: (null) >>>>> ARM Debug Architecture not supported >>>>> KDB: debugger backends: ddb >>>>> KDB: current backend: ddb >>>>> Copyright (c) 1992-2016 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 #16 r297286M: Sat Mar 26 11:47:32 IDT 2016 >>>>> = danny@rnd:/home/obj/rnd/armv6/rpi/arm.armv6/r+d/vanilla/11/src/sys/RPI-B >>>>> arm >>>>> FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based = on >>>>> LLVM 3.8.0) >>>>> VT: init without driver. >>>>> WARNING: too long kenv string, ignoring dma.dmachans=3D0x7f35 >>>>> bcm2708_fb.fbwidth=3D656 bcm2708_fb.fbheight=3D416 = bcm2708.boardrev=3D0x10 >>>>> bcm2708.serial=3D0x48bc91a1 smsc95xx.macaddr=3DB8:27:EB:BC:91:A1 >>>>> bcm2708.disk_led_gpio=3D47 bcm2708.disk_led_active_low=3D0 >>>>> sdhci-bcm2708.emmc_clock_freq=3D250000000 = vc_mem.mem_base=3D0x1ec00000 >>>>> vc_mem.mem_size=3D0x20000000 console=3DttyAMA0,115200 >>>>> kgdboc=3DttyAMA0,115200 console=3Dtty1 root=3D/dev/mmcblk0p2 >>>>> rootfstype=3Dext4 rootwait >>>>> sema_sysinit >>>>> CPU: ARM1176JZ-S rev 7 (ARM11J core) >>>>=20 >>>> Can you please test if r297283 also fails? I don't have access to = RPI at >>>> this moment, sorry. >>>>=20 >>> i will, but this will take some time. >>> in the meantime, booting from the SD card has the same issue. >>>=20 >>>> Problem is that somebody puts original linux bootargs into kernel >>>> environment - this can be caused by my pathes, or by any change in = ubldr >>>> itself. >>>>=20 >>>> Michal >>>=20 >>=20 >> Nevermind, I found it (I hope), my fault. Fixed in r297292. >> Sorry for breakage. > i=E2=80=99ll try it ASAP tried, and it now works! now it=E2=80=99s back to figuring out why the net stops working! > thanks > danny >=20 >> Michal >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Sat Mar 26 15:48:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EAF6EADDB56 for ; Sat, 26 Mar 2016 15:48:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) 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 CFCB51240 for ; Sat, 26 Mar 2016 15:48:09 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u2QFm9oE018588 for ; Sat, 26 Mar 2016 15:48:09 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 208308] Adding USB flash drive to fstab kills ue0 on Raspberry Pi 2 Date: Sat, 26 Mar 2016 15:48:09 +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: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dhorton668@hotmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 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.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 15:48:10 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D208308 Bug ID: 208308 Summary: Adding USB flash drive to fstab kills ue0 on Raspberry Pi 2 Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: dhorton668@hotmail.com Created attachment 168654 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D168654&action= =3Dedit dmesg output from a successful boot noting differences from hung boot. I am using FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160308-r296485.img and experiencing a problem with USB flash drives and the built-in RPi Ethernet.= In summary, as soon as I add my USB flash drive to /etc/fstab, the system will never complete the boot process and ue0 never change the link state. Once = this happens, disconnecting the flash drive from the RPi and rebooting does not help. Only if the flash drive is never added to /etc/fstab, will the syst= em boot normally.=20=20 I don't recall experiencing this problem when using FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160127-r294912.img and wonder if the = new problem may have been introduced by changes made for "Bug 199446 - arm Raspberry Pi panic without ethernet connected on boot" Here is how to reproduce it: 1) Install FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160308-r296485.img 2) Insert a USB flash drive 3) Create a UFS filesystem on da0p1 4) Add /dev/da0p1 to /etc/fstab 5) Restart the Raspberry Pi Troubleshooting steps I've taken: Erased (dd if=3D/dev/zero of=3D/dev/da0) the flash drive and set up partiti= on again) Used different brand of flash drive. Added the option 'noauto' to fstab. Used another, known good RPi2. Used another, known good power supply. Used another, known good SD card. None of the above makes a difference and still results in the hung boot. Additional troubleshooting: I swapped components (flash drive, power supply, SD card and RPi itself) wi= th a Linux-based media center. I cannot reproduce the problem on the media cent= er. Workaround: Do not add flash drive to fstab, but mount manually after booting. I am attaching the dmesg output from a successful boot when the flash drive= is not in fstab. Unfortunately I cannot include dmesg output from the hung bo= ot, but I do notice that the 'ue0: link state changed to DOWN' and 'ue0: link s= tate changed to UP' lines never appear on the screen. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Mar 26 16:15:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0BF31ADE147 for ; Sat, 26 Mar 2016 16:15:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E1CA613F0 for ; Sat, 26 Mar 2016 16:15:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f17971a4-f36d-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 26 Mar 2016 16:15:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2QGF5pg021828; Sat, 26 Mar 2016 10:15:05 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1459008905.1091.100.camel@freebsd.org> Subject: Re: Official images without noatime From: Ian Lepore To: Nikolai Lifanov , freebsd-arm@freebsd.org Date: Sat, 26 Mar 2016 10:15:05 -0600 In-Reply-To: <4b23b28ffae59216b5dde8f28f665330@mail.lifanov.com> References: <4b23b28ffae59216b5dde8f28f665330@mail.lifanov.com> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 16:15:09 -0000 On Sat, 2016-03-26 at 08:32 -0400, Nikolai Lifanov wrote: > > > > Hi, > > agree, in fact I have noatime on / as well. Shall be the default. > > > > > > > > Cheers, > > > > > > --- > > Jos? P?rez > > > > El 2016-03-26 00:38, Bernd Walter escribi?: > > > /boot/msdos has noatime, but / hasn't. > > > Considering SD media I think using noatime per default is a good > > > idea to avoid increased riscs of data loss on power failures. > > > > Since we also default to SU-no-J, power failure can be quite bad > during, > say, installworld. > With / noatime, I had my RPI2 lose files like /usr/bin/cmp, /bin/ls, > and > /bin/cat during a power loss. > Since it's not even possible to cleanly shut down this platform, I'm > for > enabling noatime for / on > at least for RPI and RPI2 platforms. I'm not sure why you think SU-no-J has anything to do with power failure, but before it turns into some kind of mythology let me just remind people that journaling does not enhance the ability to recover a filesystem, it only makes it faster to do so (when it doesn't fail completely, which it does all too often as seen with the numerous reports, some recent, of "it was finally fixed when I reran fsck without using the journal"). To get that boot-time speedup in recovery it has to do more writing as it goes (writing metadata to the journal and then again to the live filesystem all the time). Given the slow speed of sdcard writes, that's a steep price to pay to save 2 or 3 seconds of boot time after a power fail. Again: journaling doesn't add reliability, it only speeds recovery. On tiny sdcard filesystems the speedup is hardly noticible. -- Ian From owner-freebsd-arm@freebsd.org Sat Mar 26 18:07:57 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 342D0ADEB38 for ; Sat, 26 Mar 2016 18:07:57 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C747A1E21 for ; Sat, 26 Mar 2016 18:07:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.14.9/8.14.5) with ESMTP id u2QI7nUp006496; Sat, 26 Mar 2016 11:07:49 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.14.9/8.14.5/Submit) id u2QI7m6E006495; Sat, 26 Mar 2016 11:07:48 -0700 (PDT) (envelope-from fbsd) Date: Sat, 26 Mar 2016 11:07:48 -0700 From: bob prohaska To: bob prohaska Cc: freebsd-arm@FreeBSD.org Subject: Re: [Bug 208308] Adding USB flash drive to fstab kills ue0 on Raspberry Pi 2 Message-ID: <20160326180748.GG86944@www.zefox.net> 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-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 18:07:57 -0000 I'd like to confirm mischief when trying to add a flash device to /etc/fstab, though the symptoms I observed were slightly different. I'm using the latest snapshot, I think it's dated March 8. After adding a /usr partition to /etc/fstab and rebooting it appeared that the system was trying to mount filesystems before /dev was populated, reporting that the device file wasn't found and going to single-user. Once in single-user, the device file existed and could be mounted. Attempts to add a "late" option didn't seem to help, eventually I gave up and rewrote the image to start over, thinking I'd made a mistake. Maybe not....or else I have company 8-) Unfortunately I didn't save the console messages. This bug report seems to imply use of the video console, and IIRC, I saw the same output on the monitor, though I wasn't paying close attention to it. The system is now running buildworld of R297293 using hand-mounted /usr and swap. It's on the same SanDisk Extreme 32 GB flash drive. If there's a particular snapshot or revision that's worth trying please post. Thanks for reading, bob prohaska On Sat, Mar 26, 2016 at 03:48:09PM +0000, bugzilla-noreply@freebsd.org wrote: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208308 > > Bug ID: 208308 > Summary: Adding USB flash drive to fstab kills ue0 on Raspberry > Pi 2 > Product: Base System > Version: 11.0-CURRENT > Hardware: arm > OS: Any > Status: New > Severity: Affects Only Me > Priority: --- > Component: arm > Assignee: freebsd-arm@FreeBSD.org > Reporter: dhorton668@hotmail.com > > Created attachment 168654 > --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=168654&action=edit > dmesg output from a successful boot noting differences from hung boot. > > I am using FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160308-r296485.img and > experiencing a problem with USB flash drives and the built-in RPi Ethernet. In > summary, as soon as I add my USB flash drive to /etc/fstab, the system will > never complete the boot process and ue0 never change the link state. Once this > happens, disconnecting the flash drive from the RPi and rebooting does not > help. Only if the flash drive is never added to /etc/fstab, will the system > boot normally. > > I don't recall experiencing this problem when using > FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160127-r294912.img and wonder if the new > problem may have been introduced by changes made for "Bug 199446 - arm > Raspberry Pi panic without ethernet connected on boot" > > Here is how to reproduce it: > 1) Install FreeBSD-11.0-CURRENT-arm-armv6-RPI2-20160308-r296485.img > 2) Insert a USB flash drive > 3) Create a UFS filesystem on da0p1 > 4) Add /dev/da0p1 to /etc/fstab > 5) Restart the Raspberry Pi > > > Troubleshooting steps I've taken: > Erased (dd if=/dev/zero of=/dev/da0) the flash drive and set up partition > again) > Used different brand of flash drive. > Added the option 'noauto' to fstab. > Used another, known good RPi2. > Used another, known good power supply. > Used another, known good SD card. > > None of the above makes a difference and still results in the hung boot. > > > Additional troubleshooting: > I swapped components (flash drive, power supply, SD card and RPi itself) with a > Linux-based media center. I cannot reproduce the problem on the media center. > > > Workaround: > Do not add flash drive to fstab, but mount manually after booting. > > > I am attaching the dmesg output from a successful boot when the flash drive is > not in fstab. Unfortunately I cannot include dmesg output from the hung boot, > but I do notice that the 'ue0: link state changed to DOWN' and 'ue0: link state > changed to UP' lines never appear on the screen. > > -- > You are receiving this mail because: > You are the assignee for the bug. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Mar 26 18:14:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9520BADED01 for ; Sat, 26 Mar 2016 18:14:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76ED9133D for ; Sat, 26 Mar 2016 18:14:09 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 91a39bd7-f37e-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 26 Mar 2016 18:14:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2QIE4qH022215; Sat, 26 Mar 2016 12:14:04 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1459016044.1091.107.camel@freebsd.org> Subject: Re: [Bug 208308] Adding USB flash drive to fstab kills ue0 on Raspberry Pi 2 From: Ian Lepore To: bob prohaska Cc: freebsd-arm@FreeBSD.org Date: Sat, 26 Mar 2016 12:14:04 -0600 In-Reply-To: <20160326180748.GG86944@www.zefox.net> References: <20160326180748.GG86944@www.zefox.net> Content-Type: text/plain; charset="us-ascii" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 18:14:09 -0000 On Sat, 2016-03-26 at 11:07 -0700, bob prohaska wrote: > I'd like to confirm mischief when trying to add a flash device to > /etc/fstab, > though the symptoms I observed were slightly different. I'm using the > latest > snapshot, I think it's dated March 8. > > After adding a /usr partition to /etc/fstab and rebooting it appeared > that > the system was trying to mount filesystems before /dev was populated, > reporting > that the device file wasn't found and going to single-user. Once in > single-user, > the device file existed and could be mounted. Attempts to add a > "late" option > didn't seem to help, eventually I gave up and rewrote the image to > start over, > thinking I'd made a mistake. Maybe not....or else I have company 8-) > Unfortunately > I didn't save the console messages. > > > This bug report seems to imply use of the video console, and IIRC, I > saw > the same output on the monitor, though I wasn't paying close > attention > to it. > > The system is now running buildworld of R297293 using hand-mounted > /usr > and swap. It's on the same SanDisk Extreme 32 GB flash drive. If > there's > a particular snapshot or revision that's worth trying please post. > > Thanks for reading, > > bob prohaska Normally the boot process waits only for the root filesystem device to appear. You might try adding an unconditional boot delay to /boot/loader.conf, to give time for usb devices to arrive, like kern.cam.boot_delay="10000" The number is delay in milliseconds. -- Ian From owner-freebsd-arm@freebsd.org Sat Mar 26 18:22:10 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17B6CADEF0D for ; Sat, 26 Mar 2016 18:22:10 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA5B21A58; Sat, 26 Mar 2016 18:22:09 +0000 (UTC) (envelope-from sylgar@gmail.com) Received: by mail-wm0-x22e.google.com with SMTP id l68so44538055wml.0; Sat, 26 Mar 2016 11:22:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=lYHpNrTqULgG2DfjI0Frls4qnzAeEuc1R4V26pMVQtA=; b=XoqpK8cwr0e8hTA5aQFJN7stZRZr2d69ytULnfw7JDBfnzxexCENTuAGBJ36lf21eF IS2iRQqv1U04knMmiVz1DulFSO6yO+S403F5KaHsihjjLxO0mWezheWO1o1D8qyI3ceN BfXhkiP8jhUvz9xUM4InUQVRcGC2DhY99tVJC18eujY69j4MSBIg36uGZ15mKj2V72Q6 Y2O/IW8TaRipJinoUmyofJ/vXe6k99NPGZjSdll6rRR3P8MJpNOFN6XD/92/vekcivFT XJLrBLGfA+w/IgpDyso44xMhVa8WVq6U5v6AUGlw2rCYMPtfXOtbTDu9OVbBEDk6PyKV JbXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=lYHpNrTqULgG2DfjI0Frls4qnzAeEuc1R4V26pMVQtA=; b=LBTXV50mRu5exsEPdo/h7LDdHogWrUKy4pTMHPQelJ80zqdLy1TMQVDifG+P/rSZNf wdlHIa4hZRhSaYRx8i1xWL2/Xqg1AH2Zj32zTsjstYUvHNZos4bem7rg4BDW07vR9cmd F3fZ5GHGEmpCvSq1RsNUcFJbTYh+sREAE0ZlghN/VrNRXvJgRvy0fqEKQZ0Pe40XfH0Z bcL/O/8qH1kGLEPoTflbQQhRbHMrgE6bRvBR04OMUtgXfTaJt2Pl1wrZysyi/bSuhuBf +ecjExNBWcbT5NCwV28Tj0ipvLE+12gDigsEUrHkQ10vRf4a5LZtGuy1CGAAL8EZ+UmK /2vA== X-Gm-Message-State: AD7BkJJDYzL/ZmhQEk9fcuI8d/1YphRbHPcud5NBUGfdIgSFPeEyTZdGg5MQZiM1VGwSig== X-Received: by 10.195.13.115 with SMTP id ex19mr17581179wjd.56.1459016528256; Sat, 26 Mar 2016 11:22:08 -0700 (PDT) Received: from [192.168.0.4] ([81.56.235.196]) by smtp.gmail.com with ESMTPSA id p125sm2536799wmd.16.2016.03.26.11.22.06 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 26 Mar 2016 11:22:06 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: [Bug 208308] Adding USB flash drive to fstab kills ue0 on Raspberry Pi 2 From: Sylvain Garrigues In-Reply-To: <1459016044.1091.107.camel@freebsd.org> Date: Sat, 26 Mar 2016 19:22:05 +0100 Cc: bob prohaska , freebsd-arm@FreeBSD.org Message-Id: References: <20160326180748.GG86944@www.zefox.net> <1459016044.1091.107.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 18:22:10 -0000 I fixed the same problem using the =E2=80=98late=E2=80=99 mount option = in /etc/fstab. > Le 26 mars 2016 =C3=A0 19:14, Ian Lepore a =C3=A9crit = : >=20 > On Sat, 2016-03-26 at 11:07 -0700, bob prohaska wrote: >> I'd like to confirm mischief when trying to add a flash device to >> /etc/fstab, >> though the symptoms I observed were slightly different. I'm using the >> latest >> snapshot, I think it's dated March 8. >>=20 >> After adding a /usr partition to /etc/fstab and rebooting it appeared >> that >> the system was trying to mount filesystems before /dev was populated, >> reporting >> that the device file wasn't found and going to single-user. Once in >> single-user, >> the device file existed and could be mounted. Attempts to add a >> "late" option >> didn't seem to help, eventually I gave up and rewrote the image to >> start over, >> thinking I'd made a mistake. Maybe not....or else I have company 8-) >> Unfortunately >> I didn't save the console messages. >>=20 >>=20 >> This bug report seems to imply use of the video console, and IIRC, I >> saw >> the same output on the monitor, though I wasn't paying close >> attention=20 >> to it. >>=20 >> The system is now running buildworld of R297293 using hand-mounted >> /usr >> and swap. It's on the same SanDisk Extreme 32 GB flash drive. If >> there's >> a particular snapshot or revision that's worth trying please post. >>=20 >> Thanks for reading, >>=20 >> bob prohaska >=20 > Normally the boot process waits only for the root filesystem device to > appear. You might try adding an unconditional boot delay to > /boot/loader.conf, to give time for usb devices to arrive, like >=20 > kern.cam.boot_delay=3D"10000" >=20 > The number is delay in milliseconds. >=20 > -- Ian >=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm = > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org = " From owner-freebsd-arm@freebsd.org Sat Mar 26 18:40:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 58072ADE2B7 for ; Sat, 26 Mar 2016 18:40:29 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3D5131680 for ; Sat, 26 Mar 2016 18:40:28 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 3ba6afa3-f382-11e5-9036-c33267960ba8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.34.117.227 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.34.117.227]) by outbound2.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sat, 26 Mar 2016 18:40:37 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.14.9) with ESMTP id u2QIeJuS022298; Sat, 26 Mar 2016 12:40:19 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1459017619.1091.109.camel@freebsd.org> Subject: Re: [Bug 208308] Adding USB flash drive to fstab kills ue0 on Raspberry Pi 2 From: Ian Lepore To: Sylvain Garrigues Cc: freebsd-arm@FreeBSD.org Date: Sat, 26 Mar 2016 12:40:19 -0600 In-Reply-To: References: <20160326180748.GG86944@www.zefox.net> <1459016044.1091.107.camel@freebsd.org> Content-Type: text/plain; charset="iso-2022-jp" X-Mailer: Evolution 3.16.5 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 18:40:29 -0000 On Sat, 2016-03-26 at 19:22 +0100, Sylvain Garrigues wrote: > I fixed the same problem using the ‘late’ mount option in /etc/fstab. > 'late' doesn't imply waiting, it just means it happens later in the rc scripts. no g'tee that any new devices have appeared between early and late mounting, but if you're lucky maybe it usually works. Maybe we need a specific devwait script, similar to netwait (which really needs to be split into two scripts, netif_wait and netip_wait). -- Ian > > > Le 26 mars 2016 19:14, Ian Lepore a crit : > > > > On Sat, 2016-03-26 at 11:07 -0700, bob prohaska wrote: > > > I'd like to confirm mischief when trying to add a flash device to > > > /etc/fstab, > > > though the symptoms I observed were slightly different. I'm using > > > the > > > latest > > > snapshot, I think it's dated March 8. > > > > > > After adding a /usr partition to /etc/fstab and rebooting it > > > appeared > > > that > > > the system was trying to mount filesystems before /dev was > > > populated, > > > reporting > > > that the device file wasn't found and going to single-user. Once > > > in > > > single-user, > > > the device file existed and could be mounted. Attempts to add a > > > "late" option > > > didn't seem to help, eventually I gave up and rewrote the image > > > to > > > start over, > > > thinking I'd made a mistake. Maybe not....or else I have company > > > 8-) > > > Unfortunately > > > I didn't save the console messages. > > > > > > > > > This bug report seems to imply use of the video console, and > > > IIRC, I > > > saw > > > the same output on the monitor, though I wasn't paying close > > > attention > > > to it. > > > > > > The system is now running buildworld of R297293 using hand > > > -mounted > > > /usr > > > and swap. It's on the same SanDisk Extreme 32 GB flash drive. If > > > there's > > > a particular snapshot or revision that's worth trying please > > > post. > > > > > > Thanks for reading, > > > > > > bob prohaska > > > > Normally the boot process waits only for the root filesystem device > > to > > appear. You might try adding an unconditional boot delay to > > /boot/loader.conf, to give time for usb devices to arrive, like > > > > kern.cam.boot_delay="10000" > > > > The number is delay in milliseconds. > > > > -- Ian > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing > > list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm < > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm> > > To unsubscribe, send any mail to " > > freebsd-arm-unsubscribe@freebsd.org > freebsd-arm-unsubscribe@freebsd.org>" > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org > " > From owner-freebsd-arm@freebsd.org Sat Mar 26 21:35:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4CFA3ADDA9E for ; Sat, 26 Mar 2016 21:35:18 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E07791CDB; Sat, 26 Mar 2016 21:35:17 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u2QLYjGH045688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 26 Mar 2016 22:34:52 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u2QLYdi9079935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 26 Mar 2016 22:34:39 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u2QLYcii063923; Sat, 26 Mar 2016 22:34:38 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u2QLYbsK063922; Sat, 26 Mar 2016 22:34:37 +0100 (CET) (envelope-from ticso) Date: Sat, 26 Mar 2016 22:34:37 +0100 From: Bernd Walter To: Ian Lepore Cc: Nikolai Lifanov , freebsd-arm@freebsd.org Subject: Re: Official images without noatime Message-ID: <20160326213437.GA63809@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <4b23b28ffae59216b5dde8f28f665330@mail.lifanov.com> <1459008905.1091.100.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1459008905.1091.100.camel@freebsd.org> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2016 21:35:18 -0000 On Sat, Mar 26, 2016 at 10:15:05AM -0600, Ian Lepore wrote: > On Sat, 2016-03-26 at 08:32 -0400, Nikolai Lifanov wrote: > > > > > > Hi, > > > agree, in fact I have noatime on / as well. Shall be the default. > > > > > > > > > > > > Cheers, > > > > > > > > > --- > > > Jos? P?rez > > > > > > El 2016-03-26 00:38, Bernd Walter escribi?: > > > > /boot/msdos has noatime, but / hasn't. > > > > Considering SD media I think using noatime per default is a good > > > > idea to avoid increased riscs of data loss on power failures. > > > > > > > Since we also default to SU-no-J, power failure can be quite bad > > during, > > say, installworld. > > With / noatime, I had my RPI2 lose files like /usr/bin/cmp, /bin/ls, > > and > > /bin/cat during a power loss. > > Since it's not even possible to cleanly shut down this platform, I'm > > for > > enabling noatime for / on You can cleanly shuttdown a Pi as well as any other system via shutdown(8) or even halt(8). > > at least for RPI and RPI2 platforms. This is related to flash media internal structure, not to RPIs. With SD cards on the higher risc end. Every flash write can lead to serveral unreadable blocks. Since there is no fixed relation between logical and phycial block numbers corruption can happen everywhere on the media. The more you write the higher the risc. But flash media also write flash cells when purely reading, since it need some kind of refresh from time to time. The risc for a power failure during refresh writes are less likely however. > I'm not sure why you think SU-no-J has anything to do with power > failure, but before it turns into some kind of mythology let me just > remind people that journaling does not enhance the ability to recover a > filesystem, it only makes it faster to do so (when it doesn't fail > completely, which it does all too often as seen with the numerous > reports, some recent, of "it was finally fixed when I reran fsck > without using the journal"). I would say the risc for data loss on power failure is even higher with J, since it also writes the journal. > To get that boot-time speedup in recovery it has to do more writing as > it goes (writing metadata to the journal and then again to the live > filesystem all the time). Given the slow speed of sdcard writes, > that's a steep price to pay to save 2 or 3 seconds of boot time after a > power fail. > > Again: journaling doesn't add reliability, it only speeds recovery. On > tiny sdcard filesystems the speedup is hardly noticible. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.