From owner-freebsd-arm@freebsd.org Sun Nov 20 03:12:31 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 08A55C47D0E for ; Sun, 20 Nov 2016 03:12:31 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 77BA211AF for ; Sun, 20 Nov 2016 03:12:29 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id uAK3CNBp033357 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 20 Nov 2016 04:12:24 +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 uAK3CL2G036542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 20 Nov 2016 04:12:21 +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 uAK3CK6p078508; Sun, 20 Nov 2016 04:12:20 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id uAK3CK00078507; Sun, 20 Nov 2016 04:12:20 +0100 (CET) (envelope-from ticso) Date: Sun, 20 Nov 2016 04:12:20 +0100 From: Bernd Walter To: Peter Garshtja Cc: "freebsd-arm@freebsd.org" Subject: Re: python: spidev Message-ID: <20161120031219.GM34078@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <71a6710e-c7c3-473f-042a-37cb00d309e2@ambient-md.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71a6710e-c7c3-473f-042a-37cb00d309e2@ambient-md.com> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 03:12:31 -0000 On Sat, Nov 19, 2016 at 03:02:29PM -0500, Peter Garshtja wrote: > Greetings, > > Has anybody experience with python spidev library on RPI2 FreeBSD 11 ? > > I have a led matrix max7219 trying to connect it with gpio, and > apparently python spidev library is only for linux, i just wonder if > there any chances to run this library on freebsd ? FreeBSD has a driver for the hardware SPI on the supported rasperry boards, but unfortunately no support to access it from userland. The only way to use SPI from userland is to either do a slow bitbang via GPIO from userland, or by writing a kernel driver. With such a small matrix doing bitbang via GPIO from usrland should be fast enough and it isn't very difficult. A few weeks ago I did a bigger matrix of 800 APA102 LEDs, which are also SPI and in that case I really needed high speed. I did wrote a kernel driver for that case. It basicly does nothing more than creating a /dev/apa102 device and all data you write into it will be pushed out via SPI. The FreeBSD raspberry SPI driver only supports a common SPI frequency and mode via sysctl interface, which may be a problem if you want to access different devices. If you want to experiment with that driver I can publish the code. It had been used on a raspberry 1 B+, but should work on any board with a supported SPI controller. > here is the tutorial that i tried to follow in order to make this led > matrix working on rpi2 under freebsd. > > https://github.com/rm-hull/max7219 > -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Sun Nov 20 12:32: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 1C6ACC49253 for ; Sun, 20 Nov 2016 12:32:43 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AB69CC87 for ; Sun, 20 Nov 2016 12:32:42 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id ACYW1u00E4VixDu01CYYMp; Sun, 20 Nov 2016 13:32:32 +0100 Reply-To: From: "John W. Kitz" To: "'freebsd-arm'" References: <58306c9b.4e79630a.a07d9.cf58SMTPIN_ADDED_BROKEN@mx.google.com> <58309eb5.9942620a.e27b3.24f7SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Subject: RE: Creating FreeBSD/arm bootable SD card for Cubieboards from FreeBSD 11.0 image files for Wintel only users. Date: Sun, 20 Nov 2016 13:32:30 +0100 Message-ID: <001d01d2432a$2a960d50$7fc227f0$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AdJCoNfOdHKVHFfsTe+u3V7iHc4wDAAhzsyg Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 12:32:43 -0000 On Sat, Nov 19, 2016 at 11:48 AM, John W. Kitz = wrote: >> To rephrase my question; am I correct in assuming that the FreeBSD=20 >> release >> 11.0 SD-card image file contains everything one needs to do a first=20 >> time installation of FreeBSD on a cubieboard or cubieboard2? I.e. I = do=20 >> not or do no longer need to install the SPL loader and U-boot = programs=20 >> on the SD-card, since they are either an integral part of or not=20 >> needed when using the image file. >Yes. If you can image the file onto an SD card verbatim, and the image = is exactly right for your board, that's all you need to do. If you are = trying >to use the image not on a Cubieboard2, but on something newer, = then you'll need to install the right u-boot package and follow the = directions in the >readme file to put the combined SPL+uboot.img file = onto your card. You may also need to copy a .DTB file for your board and = possibly a newer kernel >depending on how different things are. > >https://www.raspberrypi.org/documentation/installation/installing-images= /windows.md >might be helpful for you, since images are images, even though that = site is for the Raspberry Pi. All, Thanks for the various replies. In lieu of the availability of an image file for one of the more recent = Cubie products I am planning to give it a try on a cubieboard2. Does anybody on this list happen to know if future FreeBSD releases are = planned to include images for more recent Cubie hardware? Jk. From owner-freebsd-arm@freebsd.org Sun Nov 20 13:18: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 0F7DFC4A225 for ; Sun, 20 Nov 2016 13:18:21 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (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 7519DCFD for ; Sun, 20 Nov 2016 13:18:19 +0000 (UTC) (envelope-from freebsd-arm@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Sun, 20 Nov 2016 14:13:06 +0100 id 00E5480D.5831A162.000178DD Date: Sun, 20 Nov 2016 14:13:05 +0100 From: Milan Obuch To: Jared McNeill Cc: freebsd-arm@freebsd.org Subject: Re: aw_thermal breakage on Allwinner H3 SoC Message-ID: <20161120141305.27d20efc@zeta.dino.sk> In-Reply-To: References: <20161024165820.16e6dd6f@zeta.dino.sk> <20161025180314.38ea1e96@zeta.dino.sk> <20161025202609.0958c55d@zeta.dino.sk> <20161025213913.310b502e@zeta.dino.sk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.29; i386-portbld-freebsd10.3) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 13:18:21 -0000 On Sat, 19 Nov 2016 11:03:09 -0400 (AST) Jared McNeill wrote: > On Tue, 25 Oct 2016, Milan Obuch wrote: > > > One more observation: booting verbose shows following > > aw_thermal0: mem > > 0x1c25000-0x1c253ff irq 29 on simplebus0 aw_thermal0: #0: alarm 42C > > hyst 15C shut 65C > > > > which is for me wrong - shutdown temperature 65 degrees is > > unacceptably low. > > In r308833 I've increased the shutdown temperature to 105 as well as > adjusted the temperature conversion formulas to match the BSP. Along > with that, I've bumped the alarm threshold to 90C. It's working well > on the two different H3 boards I have, can you give it a shot? > > Cheers, > Jared Hi, I build new kernel using svn revision 308866, now it changed to aw_thermal0: mem 0x1c25000-0x1c253ff irq 29 on simplebus0 aw_thermal0: #0: alarm 90C hyst 15C shut 105C so I will try to put some load on it. This should lead to higher temperatures, currently I have 67 degrees. I am interested in longer lasting load... Thanks for notice. Regards, Milan From owner-freebsd-arm@freebsd.org Sun Nov 20 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 6DD1BC4C23A for ; Sun, 20 Nov 2016 18:46:11 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::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 2B6979E1 for ; Sun, 20 Nov 2016 18:46:11 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-qt0-x231.google.com with SMTP id p16so190367603qta.0 for ; Sun, 20 Nov 2016 10:46:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=HZfe2ntmIttstwv0KyPzdqZEV6MztR94K8+VlR7NOwE=; b=MEaF8Iob/Uz9OgqdLMvMfYdsf6vY5PVX7fMQDuhMoPHWtvF2s+GfM79Rk2leSsZy0C b4rn9fdBqhHuwwixgc0CCEO5qUTRUfzQl8rHmdo2iruMeb/9A2/PXUFPq74LTXlyFLQK qp9Vsm0WSRgMTjWbnnPyRqADY7WeSdrAGzI3aZp1KQt4r98JV2b6dg5+jAqUVQlHBB7U 5awi3fPiy1KG6cjetKff73ogjKcXSMnkAmsKy+fG/1y2bfBO9W1v0RqsG5mnlCZjHx1H 4+wBlVWOIj5m0qzQFMW3ISC3bjFQGdry+0yWjbrCyGrhhUUCUc2bltgeT4MMJ6OZrv8P 6khQ== 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=HZfe2ntmIttstwv0KyPzdqZEV6MztR94K8+VlR7NOwE=; b=R+FS1NGce2Gnrc+JgWWeBYa0SVa5Pusc+C81nGZYYl5tkBGTiPxr9tm7hxT1CKGFeW m4za9cEv5xG1/MqW8r1WcSXROK9XFouws0p3E8euJr3jx4f1sA3I38SjFJlHFM8HZRVW pLWSK0mN512DVo0CLSZLsmGJjZWSgt3MIG3jKgPjAAD/ipwlRDBxSdRJZm0X92P5m0vy tWDf2oMKJwKG4l+CN76pSlutHtUcgXrkSei7GTuMKpFPchtZjAw8p4pNMDsFnldgSEb2 jn40vgEY9w1mS2+c7OnQblQ6ATQjPdKTyDhA9XQE2OA2RWqMX4Hmq089aNVm2/yEBebH N7vg== X-Gm-Message-State: AKaTC02FDtGVuk3XdxzmGDF4V6kkboOMcAItzAsZ9bfIQxVXGk4r3xSGxta3ySAj210LpS67QKTi5liiW44v0A== X-Received: by 10.237.62.202 with SMTP id o10mr5911890qtf.2.1479667570255; Sun, 20 Nov 2016 10:46:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.210 with HTTP; Sun, 20 Nov 2016 10:46:09 -0800 (PST) From: Lee D Date: Sun, 20 Nov 2016 13:46:09 -0500 Message-ID: Subject: SD-Card bug, eject without umount To: freebsd-arm Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 18:46:11 -0000 I am running 10.3 on Xilinx Zynq. I've noticed an SD-Card bug. If I am writing to an SD-Card, and then eject the SD-Card without unmounting, everything appears to be fine. However if I then try to umount the SD-Card, the umount program hangs. The rest of the system keeps running. If I eject the SD-Card while NOT writing, but mounted, then I can later umount OK. This is a problem because the user can eject the card at any time, even while the application is writing to it. It's OK to lose data, but the situation needs to be recoverable, and apparently it is not. I noticed a post on FreeBSD.org here: http://freebsdfoundation.blogspot.com/2009/08/safe-removal-of-active-disk-devices.html They talk about fixing the kernel so that SD-Cards may be ejected while mounted without causing a kernel panic. However they don't say anything about what happens if you interrupt a write operation. Does anybody know if there is anything I can do to make it so that umount doesn't hang in this situation? Thanks. From owner-freebsd-arm@freebsd.org Sun Nov 20 19:08: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 8EB91C4C64D for ; Sun, 20 Nov 2016 19:08:53 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 43099136A for ; Sun, 20 Nov 2016 19:08:53 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-qk0-x22b.google.com with SMTP id q130so326319150qke.1 for ; Sun, 20 Nov 2016 11:08:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AhhlUaetM6q8NcL4587gSeK066qn0JdvNtHJ4OovDy0=; b=E8sIGwXwuVnrM8wYMUgnU+udQP2tMBPqHkqb79F8pht4wcZjX6eWrlB2TROUdDCW+p 6byUic+DrJ47E+ovrj/rDsQZU0bFxBKYS/5lTolphj873Yz/E9NmGUi6zyTf1ciU9z4o 3Uy/I9AJN+vZoiYm/EPKun5AxvscWB0Pxw+0+1YBo5rGNC6aQEcH6TpCUox0CNAoGyTB 4sGI5/fWpqEuQqZX8bD0T3MZYbPjcY9QWfbun1WT7u166Mf/KW2tR3nxYnJYs4tyHmqQ wBrrZdb3Y9vfmGo7MRx9dk4cWLYri4tmGhyZ4JIv+qmv4MlPlgYQYdwXazZfTk677/70 LsyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AhhlUaetM6q8NcL4587gSeK066qn0JdvNtHJ4OovDy0=; b=F3Zs6nBNOma0PiiUhDCPANACPH+jVeDz7Z8y62i4PRMiogX7vRndZV2VrrL6Kceq/1 ScaBqfPHqKNcH/b0BpKGhwYuSogF1PifsEDFV8gJpET3y2U7ZHSIGtB91eI9Hp8y8+U+ d4hSo/eAwz7h94uDEdN15xRtxym9GWeZHc7msOVDs5vgZFo7tO0BL/IUf4UgseIG2ecq CuzdzWI21hwv1RkhzNsWl4/V4dPx44MkmxheO6HNqJX46D7CczBXDh0oaAn7AOJvBwK0 N9J6Tjx1DKL35ykWYuh8W4wf6gNU15zRmkk7uDi8AxHm1cjkV+IEep0zggBHxttL1MBZ SALg== X-Gm-Message-State: AKaTC026jBhpC8mE5nlTcSXpDoUGrlonGPqjTIk6Lm3X20jzMukqJ6eYvmsLqDyotGDTv336dxhhIc1xwMzU8Q== X-Received: by 10.55.153.4 with SMTP id b4mr13107083qke.163.1479668932415; Sun, 20 Nov 2016 11:08:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.210 with HTTP; Sun, 20 Nov 2016 11:08:52 -0800 (PST) In-Reply-To: <234108602.628399.1478324542467@mail.yahoo.com> References: <234108602.628399.1478324542467.ref@mail.yahoo.com> <234108602.628399.1478324542467@mail.yahoo.com> From: Lee D Date: Sun, 20 Nov 2016 14:08:52 -0500 Message-ID: Subject: Re: Low level boot loader for freebsd To: girivs82@yahoo.com Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 19:08:53 -0000 On Sat, Nov 5, 2016 at 1:42 AM, Shankar Giri via freebsd-arm < freebsd-arm@freebsd.org> wrote: > Serious problems with blank emails, so I'm using my alternate email > address. Hopefully this will go through.-----------------------------------Just > an idea I'm throwing out. I decided to do a bit of baremetal coding on my > Jetson-TK1 that got me thinking. Right now FreeBSD relies on uboot as the > low level bootloader and ubldr uses the u-boot API to bootstrap on top of > it. I'm thinking of extending the functionality of ubldr to remove the > u-boot dependency and use our own baremetal lowlevel hookups (well, name > might have to be changed since it won't be using u-boot > anymore). Advantages:1. Low level bootstrapping code part of FreeBSD tree. > Using the libstand library and the low level hookups, we'd get the low > level bootloader compiled while building world+kernel.2. Sharing the same > fdt. Since the low level bootloader uses the same dts/dtsi files as the > kernel, there is no reason to have two of them. The same fdt can be shared > between the bootloader and the kernel. Theoretically we could still do that > now between u-boot and freebsd, but being maintained by different projects, > the shared dts will have an unavoidable dichotomy.3. Seamless > bootstrapping. Right now, the bootloader and kernel are completely separate > entities, so once the kernel takes control, it ends up having to initialize > a bunch of HW that the bootloader has already take care of. This makes > sense now because there are no guarantees on what has and has not been > initialized by u-boot and what could change in future. With the bootloader > part of the freebsd base, we might actually be able to just do post-init > work on the kernel and this could actually improve boot times (and in the > embedded world, this counts for a lot)4. Use our default toolchain. Clang > (binutils is unavoidable at this point till the llvm linker is mature). I > already compiled my bare-metal code on Jetson-TK1 using Clang+binutils and > it ran quite well, llvm has has gotten pretty mature at this point. I > stopped using gcc for my arm compilation a long time ago, even for the > freebsd kernel. Disadvantages:1. Embedded world is fragmented, too many > machine/arch specific variations. Code maintainability could be a > nightmare.2. Testing low level is difficult. You don't even have a uart > console in bare-metal, so you'll have to rely on JTAG (sometimes really > expensive lauterbachs) or poring through assembly. Plus we need to find > people with embedded hardware willing to test them.3. Adoptability. I don't > think people will warm up to a new bootloader soon, particularly those who > have u-boot experience. Without contributors, this will die a slow > agonizing death. What does the community think? Is this something that > could actually help? If yes, I'm willing to start working on a > proof-of-concept. My test vehicle would be the Jetson TK1. > I think this is a great idea and I really wonder why the FreeBSD world seems to be so enamored of u-boot. One reason that people choose FreeBSD over Linux for embedded work is because it avoids the difficulties of the GPL. But of course, u-boot is GPL. The nice thing about u-boot is that it is one program that can be configured for many platforms. However, for the embedded world, I think a better approach to booting would be to fully document the boot requirements of the kernel itself, so that we can all write our own bootloaders for our own highly customized embedded platforms. I have tried to boot freebsd myself from a standalone loader, skipping u-boot and ubldr. I've only had partial success so far. This is something that I am going to have to address in the coming months. My intent would be to post my techniques for booting from bare metal without ubldr as I figure it out. But it will be a few weeks at least before I can work on it again. Right now, my approach is: 1. Keep a copy of the FreeBSD kernel on my FAT32 boot partition, and load that instead of the one on the UFS partition. 2. Compile the FDT into the kernel. 3. Configure the peripherals in my boot loader before starting FreeBSD. The kernel seems to require that certain things be configured by u-boot. Part of the idea here is avoid having to include UFS code in the boot loader. This approach is able to start booting the kernel but fails when it gets to loading the SD-Card drivers. I think. It's been a while since I last tried it. I hope you'll keep us apprised of your progress as well. PS I am working on Xilinx Zynq. Lee From owner-freebsd-arm@freebsd.org Sun Nov 20 21:48:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA711C4C072 for ; Sun, 20 Nov 2016 21:48:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::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 9A5C07C5 for ; Sun, 20 Nov 2016 21:48:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x230.google.com with SMTP id l8so75599397iti.1 for ; Sun, 20 Nov 2016 13:48:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=jPBTYp8/mE+9MUNT/8qy+7AGeY5Vw23VabtXQOHaNxM=; b=Vx32mixOPdxU1M4qWgh0NW3/rqlI+yJdv/wrOCGd2uFRK7faqfQqFcb9fM6VoJF6/q 9F+LnPYqoBUGg/LaGenBpX80OTDD8Fbx763bJdFzPr6OYQnGR9UbG7kZCZZJhciloUjY JZSvFThZKnKhnj5KDpHJGvuHPIhEPeGmvEdWyxqp0tOUkWwaClLPc5O7lkWAK2lF1rmB 0/1Top2FtEbbrdLw/5xkN9AGXX2ZbVq/W+C9g8dKcJWbgLakaKfH7i0egdqU8qYH3ecU 8Sgx9LFYU5bB8MP2MmWSFLOC/AdENiNJDVBycdXc1WIRanIc3MrhwylRDoB2w0a8sIAm QINw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=jPBTYp8/mE+9MUNT/8qy+7AGeY5Vw23VabtXQOHaNxM=; b=gjD4ffnreKKjLmo4enwpCHqsOiVkJGHHM4MHbeJpzi7eSoEBAu1QaU/PxeaEfFg4Or p3HPt21VsbYGbo1qke8h3da67pl0fCcLM/3EEe5SzFCSR/j5miXMerLgmDwJJHpj3l8j CSZbYr6o4hXHzMJfCXMzqe1BiyXSX5+CYJyNIFz6/TdJGQ1FRbpE2iz4HW3prLc3fwcH gjG9VEuVd38PeibqLQXcV+CcWlulHkoRtDckNnDQPmmIoJOrnm1UWvAB4ENxj+njBlnz 1b/HuRjnCirImEw729YHfFOn1vWGA8xTsWXPQLFd7V3joeuw8qryLQPMk5j76NYCLm9G NSnw== X-Gm-Message-State: AKaTC017Wl0yk0EzND79/72BfRzmF+ke4NptNwzDV38BVS9MxqIWOaV8mDIbjRPgmtiSJbPKJFDlgHpQunfwnQ== X-Received: by 10.36.84.138 with SMTP id t132mr5251651ita.103.1479678531678; Sun, 20 Nov 2016 13:48:51 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.66 with HTTP; Sun, 20 Nov 2016 13:48:51 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <583197f2.11e2630a.2d4ed.1acfSMTPIN_ADDED_BROKEN@mx.google.com> References: <58306c9b.4e79630a.a07d9.cf58SMTPIN_ADDED_BROKEN@mx.google.com> <58309eb5.9942620a.e27b3.24f7SMTPIN_ADDED_BROKEN@mx.google.com> <583197f2.11e2630a.2d4ed.1acfSMTPIN_ADDED_BROKEN@mx.google.com> From: Warner Losh Date: Sun, 20 Nov 2016 14:48:51 -0700 X-Google-Sender-Auth: DK2wHkykNwm3Dprj5-vldtPBXo0 Message-ID: Subject: Re: Creating FreeBSD/arm bootable SD card for Cubieboards from FreeBSD 11.0 image files for Wintel only users. To: John.Kitz@xs4all.nl Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 21:48:52 -0000 On Sun, Nov 20, 2016 at 5:32 AM, John W. Kitz wrote: > On Sat, Nov 19, 2016 at 11:48 AM, John W. Kitz wrot= e: >>> To rephrase my question; am I correct in assuming that the FreeBSD >>> release >>> 11.0 SD-card image file contains everything one needs to do a first >>> time installation of FreeBSD on a cubieboard or cubieboard2? I.e. I do >>> not or do no longer need to install the SPL loader and U-boot programs >>> on the SD-card, since they are either an integral part of or not >>> needed when using the image file. > >>Yes. If you can image the file onto an SD card verbatim, and the image is= exactly right for your board, that's all you need to do. If you are trying= >to use the image not on a Cubieboard2, but on something newer, then you'l= l need to install the right u-boot package and follow the directions in the= >readme file to put the combined SPL+uboot.img file onto your card. You ma= y also need to copy a .DTB file for your board and possibly a newer kernel = >depending on how different things are. >> >>https://www.raspberrypi.org/documentation/installation/installing-images/= windows.md >>might be helpful for you, since images are images, even though that site = is for the Raspberry Pi. > > All, > > Thanks for the various replies. > > In lieu of the availability of an image file for one of the more recent C= ubie products I am planning to give it a try on a cubieboard2. You're unlikely to have a good day doing that. > Does anybody on this list happen to know if future FreeBSD releases are p= lanned to include images for more recent Cubie hardware? Which specific hardware? In the embedded space, there's no standardization, so even minor variants can need their own u-boot. We may have a u-boot ready for that... Warner From owner-freebsd-arm@freebsd.org Sun Nov 20 22:45: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 3D1D4C4CDB9 for ; Sun, 20 Nov 2016 22:45:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 042C71D5E for ; Sun, 20 Nov 2016 22:45:36 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id n13so26537734ioe.2 for ; Sun, 20 Nov 2016 14:45:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=NVG7NhArPo+tIG5SENe3XOqQ7EDt6lbfv1njO298E48=; b=BgQ55dMaFCF4aTCHsNUwicPpzMaBRMPUgE0yhHsmP/x+bMFcRxsFmG+TBF7uASblru zAOfu8CekC0w/1zduvIAtxnEEkXBbYUate5HIsKgl0qywI2uSckQnayij4A1REa6E646 Ko8ZViTdAlGOUnlGm8ak8HBS3k5ppHcz8v85TU1v6QH+fUIG/LTDfd0oPUD/oujFoWjG dN1BuaPUr9NehlTEai54kCSBCAJQBODqNwG+glKweByxHZ/2uwMnugfM72W5zXe3d2Y/ AODRLRtBQd22GWXg1ipcorx5yvsHCGieRRGU8L38oTuk27mYzbvWlQrZcBHR+DnQcLMS 3JcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=NVG7NhArPo+tIG5SENe3XOqQ7EDt6lbfv1njO298E48=; b=Aqv0yTRvQod8esocX3Syg2vDMv7ky5PcTqOE5+ZKdLUIu8PUexota2G84VytYD1gPh 7uzOvSTH9J7X2RJ/K5J8uohLSQnr9Wf8vudvvOgOBLq+qYoDnvOviRlcLOOm3ReGlvYt lRldmqwR4aT4VI0Gh584R9jk5Uht/LUqU/FPr3Y9ynadfjggMo/0qh8GfRwEOhfcOjtj KD0S2dHLsHQ01Pc84bhnfhQNi6wjyURjOAss/FvbJdc/p/efYFhgyxlZX3O9cO4zQ16j XwtfHmSGKSisNJblkAP8JWM6HKx2DFsoIALvt2OPqTjUgRdPvUpK05AiNvPpFgm6Xsrm 6hag== X-Gm-Message-State: AKaTC03SC0rv1T8mwEsWxNuksicCVC2MAu6sAn8EBhGQu9LSDaLgSOWeLOq0CgmcAx0jue95y46QE041wAD4mA== X-Received: by 10.107.132.74 with SMTP id g71mr8575429iod.19.1479681935173; Sun, 20 Nov 2016 14:45:35 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.66 with HTTP; Sun, 20 Nov 2016 14:45:34 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: References: <234108602.628399.1478324542467.ref@mail.yahoo.com> <234108602.628399.1478324542467@mail.yahoo.com> From: Warner Losh Date: Sun, 20 Nov 2016 15:45:34 -0700 X-Google-Sender-Auth: jG--9dHtcLuTZB-p_MgyofJD8_g Message-ID: Subject: Re: Low level boot loader for freebsd To: Lee D Cc: girivs82@yahoo.com, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 22:45:36 -0000 On Sun, Nov 20, 2016 at 12:08 PM, Lee D wrote: > On Sat, Nov 5, 2016 at 1:42 AM, Shankar Giri via freebsd-arm < > freebsd-arm@freebsd.org> wrote: > >> Serious problems with blank emails, so I'm using my alternate email >> address. Hopefully this will go through.-----------------------------------Just >> an idea I'm throwing out. I decided to do a bit of baremetal coding on my >> Jetson-TK1 that got me thinking. Right now FreeBSD relies on uboot as the >> low level bootloader and ubldr uses the u-boot API to bootstrap on top of >> it. I'm thinking of extending the functionality of ubldr to remove the >> u-boot dependency and use our own baremetal lowlevel hookups (well, name >> might have to be changed since it won't be using u-boot >> anymore). Advantages:1. Low level bootstrapping code part of FreeBSD tree. >> Using the libstand library and the low level hookups, we'd get the low >> level bootloader compiled while building world+kernel.2. Sharing the same >> fdt. Since the low level bootloader uses the same dts/dtsi files as the >> kernel, there is no reason to have two of them. The same fdt can be shared >> between the bootloader and the kernel. Theoretically we could still do that >> now between u-boot and freebsd, but being maintained by different projects, >> the shared dts will have an unavoidable dichotomy.3. Seamless >> bootstrapping. Right now, the bootloader and kernel are completely separate >> entities, so once the kernel takes control, it ends up having to initialize >> a bunch of HW that the bootloader has already take care of. This makes >> sense now because there are no guarantees on what has and has not been >> initialized by u-boot and what could change in future. With the bootloader >> part of the freebsd base, we might actually be able to just do post-init >> work on the kernel and this could actually improve boot times (and in the >> embedded world, this counts for a lot)4. Use our default toolchain. Clang >> (binutils is unavoidable at this point till the llvm linker is mature). I >> already compiled my bare-metal code on Jetson-TK1 using Clang+binutils and >> it ran quite well, llvm has has gotten pretty mature at this point. I >> stopped using gcc for my arm compilation a long time ago, even for the >> freebsd kernel. Disadvantages:1. Embedded world is fragmented, too many >> machine/arch specific variations. Code maintainability could be a >> nightmare.2. Testing low level is difficult. You don't even have a uart >> console in bare-metal, so you'll have to rely on JTAG (sometimes really >> expensive lauterbachs) or poring through assembly. Plus we need to find >> people with embedded hardware willing to test them.3. Adoptability. I don't >> think people will warm up to a new bootloader soon, particularly those who >> have u-boot experience. Without contributors, this will die a slow >> agonizing death. What does the community think? Is this something that >> could actually help? If yes, I'm willing to start working on a >> proof-of-concept. My test vehicle would be the Jetson TK1. >> > > I think this is a great idea and I really wonder why the FreeBSD world > seems to be so enamored of u-boot. It is universally available. Lower-level boot loaders have been tried, and are kinda actually supported in places. However, as a project this represents a huge investment of time and effort for little return. > One reason that people choose FreeBSD over Linux for embedded work is > because it avoids the difficulties of the GPL. But of course, u-boot is > GPL. True, but the GPL is confined only to u-boot. > The nice thing about u-boot is that it is one program that can be > configured for many platforms. Correct. The project can leverage u-boot to work on a lot more platforms that we'd otherwise be able to support. > However, for the embedded world, I think a better approach to booting would > be to fully document the boot requirements of the kernel itself, so that we > can all write our own bootloaders for our own highly customized embedded > platforms. You are, of course, free to do this. Loading the kernel directly even mostly works, so long as you get the metadata structures that ubldr creates to be in place correctly. Alternatively, you can create a custom ubldr-like thing that talks to your boot loader if you want to allow loading of modules at boot time. > I have tried to boot freebsd myself from a standalone loader, skipping > u-boot and ubldr. I've only had partial success so far. This is something > that I am going to have to address in the coming months. Most likely, the meta-data is missing or corrupted that the kernel is expecting to find. > My intent would be to post my techniques for booting from bare metal > without ubldr as I figure it out. But it will be a few weeks at least > before I can work on it again. That would be cool. The early arm ports bypassed /boot/loader entirely, but people were upset that you couldn't set tuneables, nor could you load modules. For some applications, this is critical. For others, it's not needed. > Right now, my approach is: > > 1. Keep a copy of the FreeBSD kernel on my FAT32 boot partition, and load > that instead of the one on the UFS partition. > 2. Compile the FDT into the kernel. > 3. Configure the peripherals in my boot loader before starting FreeBSD. > The kernel seems to require that certain things be configured by u-boot. Depending on the platform, you may be seeing that we don't adequately implement pinmux, or that our dts doesn't completely describe the pins correctly. Also, on many boards, the primary boot loader and/or u-boot is expected to configure the DRAM memory controller completely. The kernel has no code to do that. Maybe the boot loader you are using is running out of SRAM and not configuring DRAM quite right, which means loading the kernel into DRAM and jumping to it isn't going to work. > Part of the idea here is avoid having to include UFS code in the boot > loader. It's quite small, I don't see why you'd want to. For the Atmel AT91RM9200, boot1 fits into about 6.5k and can load a kernel off of UFS SD card directly. It loads a compressed kernel and then decompresses it because that's faster than loading the uncompressed kernel. And requires that you have fewer partitions on your card, which simplifies deployment. > This approach is able to start booting the kernel but fails when it gets to > loading the SD-Card drivers. I think. It's been a while since I last > tried it. > > I hope you'll keep us apprised of your progress as well. I'd be interested as well. In general, FreeBSD/arm will continue to use u-boot, especially in the release engineering process. However, most of the folks working in that area are open to non-intrusive changes that facilitates other booting environments, so long as they are well maintained. Warner From owner-freebsd-arm@freebsd.org Sun Nov 20 22:53: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 19C19C4C270 for ; Sun, 20 Nov 2016 22:53:33 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb1-smtp-cloud3.xs4all.net (lb1-smtp-cloud3.xs4all.net [194.109.24.22]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 970F42B2 for ; Sun, 20 Nov 2016 22:53:31 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud3.xs4all.net with ESMTP id ANtM1u0044VixDu01NtN3Y; Sun, 20 Nov 2016 23:53:23 +0100 Reply-To: From: "John W. Kitz" To: "'freebsd-arm'" References: <58306c9b.4e79630a.a07d9.cf58SMTPIN_ADDED_BROKEN@mx.google.com> <58309eb5.9942620a.e27b3.24f7SMTPIN_ADDED_BROKEN@mx.google.com> <583197f2.11e2630a.2d4ed.1acfSMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Subject: RE: Creating FreeBSD/arm bootable SD card for Cubieboards from FreeBSD 11.0 image files for Wintel only users. Date: Sun, 20 Nov 2016 23:53:21 +0100 Message-ID: <001a01d24380$e5952f40$b0bf8dc0$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJDd+KodrgshmAVRNOagAY8MKrsPAABjfkw Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 22:53:33 -0000 Warner, > In lieu of the availability of an image file for one of the more = recent Cubie products I am planning to give it a try on a cubieboard2. You're unlikely to have a good day doing that. JKi: Please elaborate. The names = "FreeBSD-11.0-RELEASE-arm-armv6-CUBIEBOARD.img.xz" and = "FreeBSD-11.0-RELEASE-arm-armv6-CUBIEBOARD2.img.xz" do suggest that = these particular images are specifically aimed at cubieboard 1 and 2 = hardware or am I overlooking something? > Does anybody on this list happen to know if future FreeBSD releases = are planned to include images for more recent Cubie hardware? Which specific hardware? In the embedded space, there's no = standardization, so even minor variants can need their own u-boot. We = may have a u-boot ready for that... JKi: At this point either the cubieboard 3 or 4 seem to suite my = requirements best, but given that the image naming convention does seem = to suggest that there is no image available for either yet, I thought = I'd give it a try using the cubieboard2 first. Regards, Jk. From owner-freebsd-arm@freebsd.org Sun Nov 20 23:15: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 4C198C4C669 for ; Sun, 20 Nov 2016 23:15:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 10B98B85 for ; Sun, 20 Nov 2016 23:15:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22f.google.com with SMTP id j191so90715684ita.1 for ; Sun, 20 Nov 2016 15:15:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=ITmu800YUMgyifFgp12UvArUbz1sSn4xDOm2JFmJHj8=; b=WqB+Ub/rCWIuXtSAafN0cirZk1rMn4WfffVzJQF/wWZn1W92aqvTqqedVzz8iHW0+I fmXcSYkkmNk5GeNbuJ0hT6/3rWZ0SHPCSgsjdAZjAql3mYzLFwVJLE6emeCT1PbWR13j 5s/VfvGa+890wGPRI0hK//zG3wsEcKwumi0aG+202F5/a7vSb51Bg2htBJv+5+ouQ+nX Emj67jpULvh/ELG182NowcdHQ3Gtoj6cGoLWlYs625j7/l94UT81SG1TsIoVz4momepd ih9Mw57Ihm+BRj8Vl7UmwXNvq6rdmc8N4+Yep4BR28uf9ZdDpvm2bglL3GGLbX3QawLG ioxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=ITmu800YUMgyifFgp12UvArUbz1sSn4xDOm2JFmJHj8=; b=G7nJcUpOK140YoeIA/X3ctYQEr9bxLyJ3p/46tzeuWix0M9pboX7pi1wzyRgxP3x3s Yk9oCsoY06To0hVZjVm0drAaqGRtCOG6ziJFH5iSPgmBTJ0J3VM23DqL+/7Fp+r3XvM0 0zo1As1bGuWSViTYreT0SPomb+vhy+kNWyCqwbz6tc0j0fYS6VO52czIhh5xe52J6Gfh SngLtgAa6f60HBRSNCnwshuxA4F+Y0ObKl5s7PKhgTQ59QbjxjSdCHCNjhuXefFTuHee Ip4cY38YEgxLR+sVslDg0vemuqsNM8mayjZ1LX1PU+HkUs4RAtWPT7gZH+vCgiDGiFNE 9uRQ== X-Gm-Message-State: AKaTC02Hx1oyacjAQMLCYNE46XJyuSdbsr5WkvlZUWiwSYqp+xheSlf6p1ihLQHZYcCBOhGkCPdJLVFNLOT1fg== X-Received: by 10.36.84.138 with SMTP id t132mr5438484ita.103.1479683718486; Sun, 20 Nov 2016 15:15:18 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.134.66 with HTTP; Sun, 20 Nov 2016 15:15:17 -0800 (PST) X-Originating-IP: [69.53.245.200] In-Reply-To: <58322974.4e47620a.75a76.9c91SMTPIN_ADDED_BROKEN@mx.google.com> References: <58306c9b.4e79630a.a07d9.cf58SMTPIN_ADDED_BROKEN@mx.google.com> <58309eb5.9942620a.e27b3.24f7SMTPIN_ADDED_BROKEN@mx.google.com> <583197f2.11e2630a.2d4ed.1acfSMTPIN_ADDED_BROKEN@mx.google.com> <58322974.4e47620a.75a76.9c91SMTPIN_ADDED_BROKEN@mx.google.com> From: Warner Losh Date: Sun, 20 Nov 2016 16:15:17 -0700 X-Google-Sender-Auth: 0UegnOU6RUYWyEpKORe976VekLQ Message-ID: Subject: Re: Creating FreeBSD/arm bootable SD card for Cubieboards from FreeBSD 11.0 image files for Wintel only users. To: John.Kitz@xs4all.nl Cc: freebsd-arm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Nov 2016 23:15:19 -0000 On Sun, Nov 20, 2016 at 3:53 PM, John W. Kitz wrote: > Warner, > >> In lieu of the availability of an image file for one of the more recent = Cubie products I am planning to give it a try on a cubieboard2. > > You're unlikely to have a good day doing that. > > JKi: Please elaborate. The names "FreeBSD-11.0-RELEASE-arm-armv6-CUBIEBOA= RD.img.xz" and "FreeBSD-11.0-RELEASE-arm-armv6-CUBIEBOARD2.img.xz" do sugge= st that these particular images are specifically aimed at cubieboard 1 and = 2 hardware or am I overlooking something? You're right. The CUBIEBOARD kernel is for the A10-based cubieboard. These are rather hard to obtain these days (I had to look around to find one at a reasonable price). Cubieboard-2 is easier to find, since it is the A-20-based one. The difference between these two images is that the A10 one is UP while the A20 one is SMP, so the kernels are different. I suspect that the cubieboard 3 may work with the proper u-boot and dtb file, since it too is based on the A-20. The cubieboard 4 might or might not work. We have support for the A83t in the kernel and some A80 support for the A80 specific clock configuration, but I've not tried it, nor have I seen reports of others that have. There is a dts for it, so it should be easy to test out. >> Does anybody on this list happen to know if future FreeBSD releases are = planned to include images for more recent Cubie hardware? > > Which specific hardware? In the embedded space, there's no standardizatio= n, so even minor variants can need their own u-boot. We may have a u-boot = ready for that... > > JKi: At this point either the cubieboard 3 or 4 seem to suite my requirem= ents best, but given that the image naming convention does seem to suggest = that there is no image available for either yet, I thought I'd give it a tr= y using the cubieboard2 first. If you have a cubieboard2, the FreeBSD-11.0-RELEASE-arm-armv6-CUBIEBOARD2.img.xz image, when decompressed, will work for you. IF you have a cubieboard3, it may kinda work or not (not sure how specifically compatible the two boards are, and at this level the differences matter). However, all is not lost. I believe that you'll be able to copy the cubieboard3 dtb to /boot/dtb of this image, and use a cubieboard3 u-boot-sunxi-with-spl.bin that u-boot can produce. If you'd like to go this route, I can help you as well. The u-boot port is likely super-easy since the version of u-boot we base all the Allwinner ports on is new enough to support it w/o further patches. I'm less sure about the cubieboard 4. As for our plans in the future as a project, we're coming to grips with needing to have so many images around. This simply doesn't scale. So there's many efforts underway right now. The first of them is to create a GENERIC kernel that can boot on all this different hardware. Many of the boards have been converted over to this scheme already, though not all of the code has been merged into stable/11. Next, we're unifying the wild-west of ports that are in the tree today. This effort is something I'm coordinating, and hopefully will be done by the end of the year. As you can imagine, there's a lot of testing to do here across a broad range of hardware. Unfortunately, you need a specific u-boot for each board type (with some minor exceptions among closely related boards). Finally, there are efforts underway to ensure we can create one image that can trivially be flavored to boot on all the hardware we support. This is less well defined at the moment, but we're looking to put all the possible u-boot images onto the image, as well as providing a method to flavor the image once it is downloaded and placed into a SD card, but before it has been put into the target. These efforts are currently on the drawing board. Hope this helps Warner From owner-freebsd-arm@freebsd.org Mon Nov 21 03:35: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 42F90C473BF for ; Mon, 21 Nov 2016 03:35:24 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::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 0CB54A91 for ; Mon, 21 Nov 2016 03:35:23 +0000 (UTC) (envelope-from embaudarm@gmail.com) Received: by mail-qk0-x22c.google.com with SMTP id n204so335351152qke.2 for ; Sun, 20 Nov 2016 19:35:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0kx7VFBDfUhxc4/0pJnkIREGk6Z2dxHBz5zkyQiSXzM=; b=F2pQfFmHDHqSANzvL6NyxvUZokwV2oYiBiOAGkdVGalz4p++qgnB3e4gRxvWdObulj OUjZk3ta8dXQLakVPm/4i44AB7pxdI0zNQYY0UnkYnmyncXNpg1gA2ZNTUROUmzEIpta abgw5fNh7MSHhcdwQXxPq5g9ZlmNnyQfSM5lxRe46JhxZYmL1SUUyVWpFXkl2NeeXvdU QppKZKeskx/WqjPrzXiskeS2HMVTAtKbqtppQu8h+DPo23uyE1K419Xt0aYtPQHDlZUp n8UDzHYPPHDXH/afF/kA8KU2ImebtO6uWFHSXokmJEde5JspRB8XSEYs4zjYCBMNrR8V 1uPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0kx7VFBDfUhxc4/0pJnkIREGk6Z2dxHBz5zkyQiSXzM=; b=LMo1b5bn/EcNNCOIW3sWacib6C2CbHE2iWp5oPncRV3DwJhKH9olGvuBGDqormqUOh oI08qoOWePWZwERbRVd20u7NNHaYZh5gxduK8RO4q3DRqhgCDgst4fRR6uhiFiM1ahDB wkK2JYIfhVdDlK2ftTJs50cvjVFSa8w010T7ZtO7aM7bgYvAvob7AfMSDZCXyCecvAZ8 7GZBs79c8LxaaGrwgPXku/76KMFFD1l1IDmIyWoUf9/x3dCbVVrIczOS+lFVjsSQrFqA LRcjXdKV+iv2PWO9l5wX6/KttMicafNy1lLenQ8RGmUJuHSGZ1s3Ex9S98GFDXqiiJyQ h4fg== X-Gm-Message-State: AKaTC00oaCWVPvXIlvI3WmFCzGs34/cMWL18JqQTe/cUpVmiSZch3USR/qr34gLj3XFCmVMESoAmETRdhoCLEw== X-Received: by 10.55.23.65 with SMTP id i62mr12598165qkh.238.1479699323203; Sun, 20 Nov 2016 19:35:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.41.210 with HTTP; Sun, 20 Nov 2016 19:35:22 -0800 (PST) In-Reply-To: References: <234108602.628399.1478324542467.ref@mail.yahoo.com> <234108602.628399.1478324542467@mail.yahoo.com> From: Lee D Date: Sun, 20 Nov 2016 22:35:22 -0500 Message-ID: Subject: Re: Low level boot loader for freebsd To: Warner Losh Cc: girivs82@yahoo.com, "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 03:35:24 -0000 Agreed that u-boot is great for letting you get on with the core task of working on FreeBSD itself. > Part of the idea here is avoid having to include UFS code in the boot > > loader. > > It's quite small, I don't see why you'd want to. The idea was to avoid the mental overhead and time of learning the UFS internals and teasing out the UFS dependencies from the kernel tree. However that Atmel executable you mention is probably a great example of how to do it. I'll check it out. I'd love to ditch the DOS partition for the reasons you mention. And also because in my case I want the bootloader to live in QSPI flash. Thanks, Lee From owner-freebsd-arm@freebsd.org Mon Nov 21 10:30:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96786C4C638 for ; Mon, 21 Nov 2016 10:30:58 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud3.xs4all.net (lb3-smtp-cloud3.xs4all.net [194.109.24.30]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3149B6EE for ; Mon, 21 Nov 2016 10:30:57 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud3.xs4all.net with ESMTP id AaVi1u00N4VixDu01aVjER; Mon, 21 Nov 2016 11:29:44 +0100 Reply-To: From: "John W. Kitz" To: "'freebsd-arm'" References: <58306c9b.4e79630a.a07d9.cf58SMTPIN_ADDED_BROKEN@mx.google.com> <58309eb5.9942620a.e27b3.24f7SMTPIN_ADDED_BROKEN@mx.google.com> <583197f2.11e2630a.2d4ed.1acfSMTPIN_ADDED_BROKEN@mx.google.com> <58322974.4e47620a.75a76.9c91SMTPIN_ADDED_BROKEN@mx.google.com> In-Reply-To: Subject: RE: Creating FreeBSD/arm bootable SD card for Cubieboards from FreeBSD 11.0 image files for Wintel only users. Date: Mon, 21 Nov 2016 11:29:36 +0100 Message-ID: <000001d243e2$2d4b5fb0$87e21f10$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJDg/ZZjfkfKvE+QjWUfKdF8/jykwAW3WMw Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 10:30:58 -0000 Warner, For the time being I'll stick with trying it on a cubieboard2 first. = Thanks for your offer to help should I decide to go with the = cubieboard3, it's very likely I'll have additional questions as things = progress, for the time being thanks for the information provided to me = so far. If I understand the future plans you've outlined correctly, I'd say from = a more or less end-user perspective that would be ideal. It looks like a lot of progress was made through the collective efforts = of many since this relatively cheap hardware first caught my attention = back in October of 2013 (see = https://lists.freebsd.org/pipermail/freebsd-questions/2013-October/254055= .html). Regards, Jk. From owner-freebsd-arm@freebsd.org Mon Nov 21 11:53: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 459EBC4D245 for ; Mon, 21 Nov 2016 11:53:26 +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 C1189CBA for ; Mon, 21 Nov 2016 11:53:25 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from bach.cs.huji.ac.il ([132.65.81.13]) by kabab.cs.huji.ac.il with esmtp id 1c8n2e-000G0I-G3; Mon, 21 Nov 2016 13:45:44 +0200 From: Daniel Braniss Message-Id: Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: aw_thermal breakage on Allwinner H3 SoC Date: Mon, 21 Nov 2016 13:45:44 +0200 In-Reply-To: <20161120141305.27d20efc@zeta.dino.sk> Cc: Jared McNeill , freebsd-arm@freebsd.org To: Milan Obuch References: <20161024165820.16e6dd6f@zeta.dino.sk> <20161025180314.38ea1e96@zeta.dino.sk> <20161025202609.0958c55d@zeta.dino.sk> <20161025213913.310b502e@zeta.dino.sk> <20161120141305.27d20efc@zeta.dino.sk> X-Mailer: Apple Mail (2.3251) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 11:53:26 -0000 > On 20 Nov 2016, at 15:13, Milan Obuch wrote: >=20 > On Sat, 19 Nov 2016 11:03:09 -0400 (AST) > Jared McNeill > = wrote: >=20 >> On Tue, 25 Oct 2016, Milan Obuch wrote: >>=20 >>> One more observation: booting verbose shows following >>> aw_thermal0: mem >>> 0x1c25000-0x1c253ff irq 29 on simplebus0 aw_thermal0: #0: alarm 42C >>> hyst 15C shut 65C >>>=20 >>> which is for me wrong - shutdown temperature 65 degrees is >>> unacceptably low. =20 >>=20 >> In r308833 I've increased the shutdown temperature to 105 as well as=20= >> adjusted the temperature conversion formulas to match the BSP. Along >> with that, I've bumped the alarm threshold to 90C. It's working well >> on the two different H3 boards I have, can you give it a shot? >>=20 >> Cheers, >> Jared >=20 > Hi, >=20 > I build new kernel using svn revision 308866, now it changed to >=20 > aw_thermal0: mem = 0x1c25000-0x1c253ff irq 29 on simplebus0 > aw_thermal0: #0: alarm 90C hyst 15C shut 105C >=20 > so I will try to put some load on it. This should lead to higher > temperatures, currently I have 67 degrees. I am interested in longer > lasting load... >=20 > Thanks for notice. >=20 > Regards, > Milan tried on a orange pi one and all seems ok now. thanks, danny From owner-freebsd-arm@freebsd.org Mon Nov 21 15:47: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 4BC7BC4C064 for ; Mon, 21 Nov 2016 15:47:18 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.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 1E104E4D for ; Mon, 21 Nov 2016 15:47:17 +0000 (UTC) (envelope-from peter.garshtja@ambient-md.com) Received: by mail-io0-x22a.google.com with SMTP id j65so43040608iof.0 for ; Mon, 21 Nov 2016 07:47:17 -0800 (PST) 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:from:date:message-id:subject:to :cc; bh=3Vn9VlN2K/KjPon+Ro479GbC2+XHvfeg0QbLzZxh+8Q=; b=Z+UjwlIQOcEW6tCuWViN8EwjzY265bHWuK/C8mOLRZpv5CR/Nid3d7OwQyhv8XRBnr 4Vr4xq6hYk2s4jLyYRSwoHtQcZ+qM5cUei5lnzBkpsadrO3pSfJ4//ljdgwZU71TNwbj SHoOXzu7bPa5YBE/w/Tr3IUjHsWUzXAtwnGWXnaAZWH45YkZdimMObQWqDljRiDJhDuv veyX/ZTXS7IWeLJNdmg+jSNSgi1y9DJRzs9j0Ev0lcJiInafD9fdwM5nUMmM7EBd/Ne0 9gmWoSNafEBzg+QpoCDK/N1Q8P/yHyhjckoCBVSGPd+Gl32RVx0F+7tQY10/8/Vgt0S4 tifA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Vn9VlN2K/KjPon+Ro479GbC2+XHvfeg0QbLzZxh+8Q=; b=hIj5ZMy+L6rERzKALfQhghWEeB2F8nAuiR+sXrNBpL9wdIEYq4idu9Rhzdxkiga5zE CLrPBQeMG7BCHfy6WHhCNjsEr8qcz+Aqnj5Dzy9ceyNYxvPe+tEUSh6xIc4wQORfccqZ Wi0qSqDPWWNt6YLEfbyYRyKeydqVCSHp2cZLBusu7SxAxCELkS2G9Mj/ngeI5hXnJMXk rNhQ+jflrBWTO3pAo9Vhec/GZek+vCVVFOBJ+YslqsgeSNXdzVRW8twhxIYv4J9RlrFn P6LEVpz4sYIb4rRM/i3RdQHZWO3JjuIk/vfGIz3dww96pKXgNNgSElR9RoDfcz1TaTD3 MKEg== X-Gm-Message-State: AKaTC01Q2H24rT0/M8Scd0UpKwNa9JtSSCPZ6PpcKcyvhXBpwHYc7Vkas+RulgNT0UOQmkIb/uJuvTAy+C4Wxw== X-Received: by 10.107.146.196 with SMTP id u187mr11059029iod.34.1479743237286; Mon, 21 Nov 2016 07:47:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.74.134 with HTTP; Mon, 21 Nov 2016 07:47:16 -0800 (PST) X-Originating-IP: [66.158.136.226] In-Reply-To: <20161120031219.GM34078@cicely7.cicely.de> References: <71a6710e-c7c3-473f-042a-37cb00d309e2@ambient-md.com> <20161120031219.GM34078@cicely7.cicely.de> From: peter garshtja Date: Mon, 21 Nov 2016 10:47:16 -0500 Message-ID: Subject: Re: python: spidev To: ticso@cicely.de Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 15:47:18 -0000 Greetings, *The only way to use SPI from userland is to either do a slow bitbang via GPIO from userland, or by writing a kernel driver.* Can you explain me "what is" or "how to do" slow bitbang via GPIO ? *I did wrote a kernel driver for that case. It basicly does nothing more than creating a /dev/apa102 device and all data you write into it will be pushed out via SPI.* Sounds interesting, could you please publish the code and also explain how to write to /dev/matrix device via SPI ? Thanks in advance, Peter On Sat, Nov 19, 2016 at 10:12 PM, Bernd Walter wrote: > On Sat, Nov 19, 2016 at 03:02:29PM -0500, Peter Garshtja wrote: > > Greetings, > > > > Has anybody experience with python spidev library on RPI2 FreeBSD 11 > ? > > > > I have a led matrix max7219 trying to connect it with gpio, and > > apparently python spidev library is only for linux, i just wonder if > > there any chances to run this library on freebsd ? > > FreeBSD has a driver for the hardware SPI on the supported rasperry > boards, but unfortunately no support to access it from userland. > The only way to use SPI from userland is to either do a slow bitbang > via GPIO from userland, or by writing a kernel driver. > > With such a small matrix doing bitbang via GPIO from usrland should be > fast enough and it isn't very difficult. > > A few weeks ago I did a bigger matrix of 800 APA102 LEDs, which are > also SPI and in that case I really needed high speed. > I did wrote a kernel driver for that case. > It basicly does nothing more than creating a /dev/apa102 device and > all data you write into it will be pushed out via SPI. > The FreeBSD raspberry SPI driver only supports a common SPI frequency > and mode via sysctl interface, which may be a problem if you want to > access different devices. > > If you want to experiment with that driver I can publish the code. > It had been used on a raspberry 1 B+, but should work on any board > with a supported SPI controller. > > > here is the tutorial that i tried to follow in order to make this led > > matrix working on rpi2 under freebsd. > > > > https://github.com/rm-hull/max7219 > > > > -- > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > From owner-freebsd-arm@freebsd.org Mon Nov 21 16:01:26 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 26875C4C625 for ; Mon, 21 Nov 2016 16:01:26 +0000 (UTC) (envelope-from tj@enoti.me) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 01F141814 for ; Mon, 21 Nov 2016 16:01:25 +0000 (UTC) (envelope-from tj@enoti.me) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3A1E920764; Mon, 21 Nov 2016 11:01:24 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Mon, 21 Nov 2016 11:01:24 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=smtpout; bh=F2NNJF7LIT5EQs HZRcRpK3prsaY=; b=q/CAWx5sVDnA0bMyA7fjhsDLMoHujzOMkC1IL3jrXEKfEe kKL15B1Hu56Ic43bbEtbr9Ouwzi7xfxpGCbpMbtyg8lNH4Sp0NkSFlILB3iFAlwN rnSQWifUvuXBI2LMArbi5AzugnRdD+0eHQI1OMs2QPGARSt6JihaOtgk/Jh7Y= X-ME-Sender: X-Sasl-enc: BJn+m+lkwgZPibmtCiphyXTf8t7EtadeAM8CWDtWkPWQ 1479744083 Received: from tom-desk.erg.abdn.ac.uk (tom-desk.erg.abdn.ac.uk [139.133.204.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 7F78A25057; Mon, 21 Nov 2016 11:01:23 -0500 (EST) Date: Mon, 21 Nov 2016 16:01:18 +0000 From: tj To: Peter Garshtja Cc: "freebsd-arm@freebsd.org" Subject: Re: python: spidev Message-ID: <20161121160117.GA85737@tom-desk.erg.abdn.ac.uk> References: <71a6710e-c7c3-473f-042a-37cb00d309e2@ambient-md.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71a6710e-c7c3-473f-042a-37cb00d309e2@ambient-md.com> User-Agent: Mutt/1.6.1 (2016-04-27) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 16:01:26 -0000 On Sat, Nov 19, 2016 at 03:02:29PM -0500, Peter Garshtja wrote: > Greetings, > > Has anybody experience with python spidev library on RPI2 FreeBSD 11 ? > > I have a led matrix max7219 trying to connect it with gpio, and > apparently python spidev library is only for linux, i just wonder if > there any chances to run this library on freebsd ? > > here is the tutorial that i tried to follow in order to make this led > matrix working on rpi2 under freebsd. > > https://github.com/rm-hull/max7219 There have been a few implementations of a userspace interface to spi, spigen ended up winning and was committed by adrian. https://lists.freebsd.org/pipermail/svn-src-head/2016-May/087329.html The interface is different to the linux implementation, but it shouldn't be too hard to write the bits to use it from python. - - [tj] From owner-freebsd-arm@freebsd.org Mon Nov 21 16:19: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 762EFC4CF81 for ; Mon, 21 Nov 2016 16:19:03 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E7D7775F for ; Mon, 21 Nov 2016 16:19:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 98862839; Mon, 21 Nov 2016 17:18:59 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=mPDIDrdelUWlIjqxuowPsSTMQSs=; b=gTaMPkp9fuCylsdLwF1KnKuwulF7 cfB3ymbWHzWEGzDHvAmjT33DLcQQ5jVfsrMK2q85j82AoXV6A7EGazXU7ydmShsF 9ySAsNMyav7KgtHmJfy5vfKBjnZ627zo2wVkNXwazT1Hk/xJxua1xHsxyYa6cKbc 7WMrujof7YIjAdk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=BuFsojnMBmICYwnX2LJ+jHSPngitjys8mjuP8Y+EWio2mPCDdoCrypSa RZNvDjWyMbNjvh8ZUBlr5VfsXjDefLJh4oTBhEgx1EJ1V0kNohnqN4XOcjfNd/QJ bHBfsX91bNek3ur9bBuHuiz5k/bYhwcS0jjDcucUX/casL8GDYk= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 108ff40c TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Mon, 21 Nov 2016 17:18:59 +0100 (CET) Date: Mon, 21 Nov 2016 17:18:59 +0100 From: Emmanuel Vadot To: Peter Garshtja Cc: "freebsd-arm@freebsd.org" Subject: Re: python: spidev Message-Id: <20161121171859.f9a7b128712676d7ebeb7aa1@bidouilliste.com> In-Reply-To: <71a6710e-c7c3-473f-042a-37cb00d309e2@ambient-md.com> References: <71a6710e-c7c3-473f-042a-37cb00d309e2@ambient-md.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 16:19:03 -0000 On Sat, 19 Nov 2016 15:02:29 -0500 Peter Garshtja wrote: > Greetings, > > Has anybody experience with python spidev library on RPI2 FreeBSD 11 ? > > I have a led matrix max7219 trying to connect it with gpio, and > apparently python spidev library is only for linux, i just wonder if > there any chances to run this library on freebsd ? > > here is the tutorial that i tried to follow in order to make this led > matrix working on rpi2 under freebsd. > > https://github.com/rm-hull/max7219 > > Thanks in advance, > > Peter > > _______________________________________________ > 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" Hello, I've added SPI bitbang to my python gpio lib[1] a few month ago, I didn't make a release after that so you will need to compile the module itself. You will need to patch you python[2] to use the system compiler and not the cross building one too. You don't have to recompile the packages, just patch directly _sysconfigdata.py and config/Makefile. Cheers, [1] https://github.com/evadot/fbsd_gpio_py [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208282 -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Mon Nov 21 19:07: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 81525C4D311 for ; Mon, 21 Nov 2016 19:07:18 +0000 (UTC) (envelope-from ewongwon@bell.net) Received: from BLU004-OMC3S2.hotmail.com (blu004-omc3s2.hotmail.com [65.55.116.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 45D7189C for ; Mon, 21 Nov 2016 19:07:17 +0000 (UTC) (envelope-from ewongwon@bell.net) Received: from BLU436-SMTP20 ([65.55.116.74]) by BLU004-OMC3S2.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Mon, 21 Nov 2016 11:07:11 -0800 X-TMN: [I5NqvBSYt/APTw0d6s+SX81xQcxkudPY] X-Originating-Email: [ewongwon@bell.net] Message-ID: From: iCloud Subject: Violated Terms And Conditions To: freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Mon, 21 Nov 2016 20:06:12 +0100 X-Antivirus: avast! (VPS 161121-0, 21/11/2016), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 21 Nov 2016 19:07:10.0071 (UTC) FILETIME=[75AC5870:01D2442A] Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Nov 2016 19:07:18 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Dear freebsd-arm@freebsd.org, A recent attempt to login to your account was restricted =2E. Click the link below and then sign in using your Apple ID and password to restore full access to you account. Verify now > You will be unable to use your Apple ID or make purchases until this p= rocess is completed Apple Support My Apple ID | Support | Privac y Policy Copyright =A9 2016 Apple Inc. 1 Infinite Loop, Cupertino, CA 95014, United States? All Rights R= eserved. From owner-freebsd-arm@freebsd.org Tue Nov 22 11:27:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3D9A0C4F56C for ; Tue, 22 Nov 2016 11:27:52 +0000 (UTC) (envelope-from vova@fbsd.ru) Received: from fbsd.ru (mx.fbsd.ru [178.213.227.68]) (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 C2B7A1AC5 for ; Tue, 22 Nov 2016 11:27:51 +0000 (UTC) (envelope-from vova@fbsd.ru) Received: from [185.152.193.239] (helo=[10.192.38.97]) by fbsd.ru with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87 (FreeBSD)) (envelope-from ) id 1c99Ep-0008pd-7D for freebsd-arm@freebsd.org; Tue, 22 Nov 2016 14:27:47 +0300 User-Agent: Microsoft-MacOutlook/f.1c.1.161117 Date: Tue, 22 Nov 2016 14:27:46 +0300 Subject: OrangePI plus2e on AllWinner H3 - first success From: "Vladimir B. Grebenschikov" To: Message-ID: Thread-Topic: OrangePI plus2e on AllWinner H3 - first success Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 11:27:52 -0000 Hi=20 I am try to get FreeBSD run on OrangePI plus2e - http://www.orangepi.org/or= angepiplus2e/ It is ALLWINNER H3 SoC, and from first glance it should work, Linux boots o= k on the chip (although wired ethernet does not work) As far as I found not much information about running FreeBSD on the board, = some short explanation what I did and what happened below. 1. Build flash (combining instructions from https://wiki.freebsd.org/FreeBS= D/arm/Cubieboard and from https://wiki.freebsd.org/FreeBSD/arm/Allwinner) and write it on SD-card (only installworld and distribution) 2. Adopt u-boot port to use orangepi-plus2e config (see below), and write i= t on SD-card also (as in port README), https://bugs.freebsd.org/bugzilla/sho= w_bug.cgi?id=3D214729 3. Connect serial console (do not forgot about TTL levels on board),=20 now it starts, shows right amount of memory and found hardware: U-Boot SPL 2016.09 (Nov 22 2016 - 01:00:45) DRAM: 2048 MiB Trying to boot from MMC1 U-Boot 2016.09 (Nov 22 2016 - 01:00:45 +0300) Allwinner Technology ------------- CPU: Allwinner H3 (SUN8I 1680) Model: Xunlong Orange Pi Plus 2E I2C: ready DRAM: 2 GiB WARNING: Caches not enabled MMC: SUNXI SD/MMC: 0, SUNXI SD/MMC: 1 reading u-boot.env ** Unable to read "u-boot.env" from mmc0:1 ** Using default environment In: serial Out: serial Err: serial Net: phy interface7 eth0: ethernet@1c30000 starting USB... USB0: USB EHCI 1.00 USB1: USB OHCI 1.0 USB2: USB EHCI 1.00 USB3: USB OHCI 1.0 USB4: USB EHCI 1.00 USB5: USB OHCI 1.0 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr.bin reading ubldr.bin ** Unable to read file ubldr.bin ** =3D> ------------- Warning about cache a bit surprises me 4. Load kernel as in instruction (it was written on FAT partition of SD car= d) =3D> fatload mmc 0 0x40200000 kernel reading kernel 8336460 bytes read in 1110 ms (7.2 MiB/s) =3D> so far everything looks ok =E2=80=A6 5. Now try to start FreeBSD kernel =E2=80=93 with no luck: =3D> go 0x40200000 ## Starting application at 0x40200000 ... =E2=80=A6. Nothing, LEDs on board are still off =E2=80=A6 6. Ok, let=E2=80=99s try to put whole /boot on FAT partition =E2=80=93 much better =E2=80=A6 scanning bus 0 for devices... 1 USB Device(s) found scanning bus 2 for devices... 1 USB Device(s) found scanning bus 4 for devices... 1 USB Device(s) found Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr.bin reading ubldr.bin 225100 bytes read in 77 ms (2.8 MiB/s) ## No elf image at address 0x42000000 ## Starting application at 0x42000000 ... Consoles: U-Boot console Compatible U-Boot API signature found @0xbbf426d0 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@srv.fbsd.ru, Mon Nov 21 14:59:11 MSK 2016) DRAM: 2048MB MMC Device 2 not found Number of U-Boot devices: 2 U-Boot env: loaderdev=3D'mmc 0' Found U-Boot device: disk Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: /boot/kernel/kernel data=3D0x6708e4+0x1a771c syms=3D[0x4+0x90cd0+0x4+0xa6cd8] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... No valid device tree blob found! Type '?' for a list of commands, 'help' for more detailed help. loader> aha=E2=80=A6 dtb: loader> load -t dtb boot/dtb/orangepi-plus-2e.dtb boot/dtb/orangepi-plus-2e.dtb size=3D0x51ac 7. Now try to boot: loader> boot sing DTB from loaded file 'boot/dtb/orangepi-plus-2e.dtb'. Kernel entry at 0x42200100... Kernel args: (null) 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 12.0-CURRENT #0 90a2ed0(master): Mon Nov 21 12:29:40 MSK 2016 root@srv.fbsd.ru:/usr/obj/arm.armv6/usr/src2/sys/ALLWINNER arm FreeBSD clang version 3.8.0 (tags/RELEASE_380/final 262564) (based on LLVM = 3.8.0) WARNING: WITNESS option enabled, expect reduced performance. VT: init without driver. CPU: ARM Cortex-A7 r0p5 (ECO: 0x00000000) CPU Features: Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7, PXN, LPAE, Coherent Walk Optional instructions: SDIV/UDIV, UMULL, SMULL, SIMD(ext) LoUU:2 LoC:3 LoUIS:2 Cache level 1: 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc 32KB/32B 2-way instruction cache Read-Alloc Cache level 2: 512KB/64B 8-way unified cache WB Read-Alloc Write-Alloc real memory =3D 2147483648 (2048 MB) avail memory =3D 2087354368 (1990 MB) FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs random: entropy device external interface kbd0 at kbdmux0 ofwbus0: aw_ccu0: on ofwbus0 clk_fixed0: on aw_ccu0 clk_fixed1: on aw_ccu0 aw_pll0: mem 0x1c20000-0x1c20003 on aw_ccu0 clk_fixed2: on aw_ccu0 aw_pll1: mem 0x1c20028-0x1c2002b on aw_ccu0 clk_fixed3: on aw_ccu0 clk_fixed4: on aw_ccu0 aw_cpuclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_axiclk0: mem 0x1c20050-0x1c20053 on aw_ccu0 aw_ahbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_ahbclk1: mem 0x1c2005c-0x1c2005f on aw_ccu0 aw_apbclk0: mem 0x1c20054-0x1c20057 on aw_ccu0 aw_apbclk1: mem 0x1c20058-0x1c2005b on aw_ccu0 aw_gate0: mem 0x1c20060-0x1c20073 on aw_ccu0 aw_mmcclk0: mem 0x1c20088-0x1c2008b on aw_ccu0 aw_mmcclk1: mem 0x1c2008c-0x1c2008f on aw_ccu0 aw_mmcclk2: mem 0x1c20090-0x1c20093 on aw_ccu0 aw_usbclk0: mem 0x1c200cc-0x1c200cf on aw_ccu0 clk_fixed5: on aw_ccu0 aw_gate1: mem 0x1f01428-0x1f0142b on aw_ccu0 aw_modclk0: mem 0x1f01454-0x1f01457 on aw_ccu0 aw_pll2: mem 0x1c20008-0x1c2000b on aw_ccu0 aw_thsclk0: mem 0x1c20074-0x1c20077 on aw_ccu0 aw_codecclk0: mem 0x1c20140-0x1c20143 on aw_ccu0 simplebus0: on ofwbus0 aw_reset0: mem 0x1c202c0-0x1c202cb on simplebus0 aw_reset1: mem 0x1c202d0-0x1c202d3 on simplebus0 aw_reset2: mem 0x1c202d8-0x1c202db on simplebus0 aw_reset3: mem 0x1f014b0-0x1f014b3 on simplebus0 iichb0: mem 0x1c2ac00-0x1c2afff i= rq 29 on simplebus0 iicbus0: on iichb0 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 regfix0: on ofwbus0 regfix1: on ofwbus0 regfix2: on ofwbus0 regfix3: on ofwbus0 regfix4: on ofwbus0 regfix5: on ofwbus0 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 aw_sid0: mem 0x1c14000-0x1c143ff on simple= bus0 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 awusbphy0: mem 0x1c19400-0x1c1942b,0x1c1a800-0x1c1a803,= 0x1c1b800-0x1c1b803,0x1c1c800-0x1c1c803,0x1c1d800-0x1c1d803 on simplebus0 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 gic0: mem 0x1c81000-0x1c81fff,0x1c82000-= 0x1c82fff,0x1c84000-0x1c85fff,0x1c86000-0x1c87fff irq 23 on simplebus0 gic0: pn 0x10, arch 0x2, rev 0x1, implementer 0x43b irqs 160 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 gpio0: mem 0x1c20800-0x1c20bff irq 14,15= on simplebus0 gpiobus0: on gpio0 gpio1: mem 0x1f02c00-0x1f02fff irq 27 on= simplebus0 gpiobus1: on gpio1 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 generic_timer0: irq 0,1,2,3 on ofwbus0 Timecounter "ARM MPCore Timecounter" frequency 24000000 Hz quality 1000 Event timer "ARM MPCore Eventtimer" frequency 24000000 Hz quality 1000 rtc0: mem 0x1f00000-0x1f00053 irq 24,25 on simplebus0 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 cpulist0: on ofwbus0 cpu0: on cpulist0 cpufreq_dt0: on cpu0 cpufreq_dt0: no regulator for cpu@0 device_attach: cpufreq_dt0 attach returned 6 cpu1: on cpulist0 cpu2: on cpulist0 cpu3: on cpulist0 a31dmac0: mem 0x1c02000-0x1c02fff irq 4 on simpl= ebus0 a10_mmc0: mem 0x1c0f000-0x1c0ffff = irq 5 on simplebus0 mmc0: on a10_mmc0 a10_mmc1: mem 0x1c10000-0x1c10fff = irq 6 on simplebus0 mmc1: on a10_mmc1 a10_mmc2: mem 0x1c11000-0x1c11fff = irq 7 on simplebus0 mmc2: on a10_mmc2 ehci0: mem 0x1c1b000-0x1c1b0ff ir= q 8 on simplebus0 usbus0: EHCI version 1.0 usbus0 on ehci0 ehci1: mem 0x1c1c000-0x1c1c0ff ir= q 10 on simplebus0 usbus1: EHCI version 1.0 usbus1 on ehci1 ehci2: mem 0x1c1d000-0x1c1d0ff ir= q 12 on simplebus0 usbus2: EHCI version 1.0 usbus2 on ehci2 gpioc0: on gpio0 aw_wdog0: mem 0x1c20ca0-0x1c20cbf irq 18 on simple= bus0 =EF=BF=BD=EF=BF=BDuart0: mem 0x1c28000-0x1c= 283ff irq 19 on simplebus0 uart0: console (961538,n,8,1) gpioc1: on gpio1 awg0: mem 0x1c30000-0x1c30103,0x1c00030-0x1c00= 033 irq 28 on simplebus0 miibus0: on awg0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000b= aseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-f= low rgephy1: PHY 1 on miibus0 rgephy1: none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX, 100baseT= X-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000b= aseT-FDX-master, 1000baseT-FDX-flow, 1000baseT-FDX-flow-master, auto, auto-f= low awg0: Ethernet address: 02:20:36:eb:80:da iic0: on iicbus0 iichb1: mem 0x1f02400-0x1f027ff i= rq 32 on simplebus0 iichb1: could not find clock device_attach: iichb1 attach returned 2 aw_thermal0: mem 0x1c25000-0x1c253ff = irq 33 on simplebus0 pcm0: mem 0x1c22c00-0x1c22cff,0x1f015c0-0x1f015c3 i= rq 34 on simplebus0 gpioled0: on ofwbus0 cryptosoft0: Timecounters tick every 1.000 msec usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus= 0 ugen1.1: at usbus1 uhub1: on usbus= 1 ugen2.1: at usbus2 uhub2: on usbus= 2 mmcsd0: 8GB at mmc0 50.0MH= z/4bit/65535-block a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 a10_mmc1: error rint: 0x00000100 mmc1: No compatible cards found on bus a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00008018 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 a10_mmc2: error rint: 0x00000100 mmcsd1: 16GB at mmc= 2 52.0MHz/8bit/65535-block Release APs WARNING: WITNESS option enabled, expect reduced performance. Root mount waiting for: usbus2 usbus1 usbus0 uhub0: 1 port with 1 removable, self powered uhub2: 1 port with 1 removable, self powered uhub1: 1 port with 1 removable, self powered Loader variables: Manual root filesystem specification: : [options] Mount using filesystem and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/cd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/cd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) Abort manual input mountroot> ufs:/dev/mmcsd0s2a Trying to mount root from ufs:/dev/mmcsd0s2a []... /etc/rc: WARNING: hostid: unable to figure out a UUID from DMI data, genera= ting a new one Setting hostuuid: 163024e2-f669-11de-a77e-230d85878639. Setting hostid: 0x914f0eb3. eval: cannot open /etc/fstab: No such file or directory No suitable dump device was found. eval: cannot open /etc/fstab: No such file or directory fstab: /etc/fstab:0: No such file or directory Warning! No /etc/fstab: skipping disk checks. fstab: /etc/fstab:0: No such file or directory Mounting local filesystems:fstab: /etc/fstab:0: No such file or directory . ELF ldconfig path: /lib /usr/lib /usr/lib/compat random: unblocking device. Soft Float compatibility ldconfig path: /etc/rc: WARNING: $hostname is not set -- see rc.conf(5). Setting up harvesting: [UMA],[FS_ATIME],SWI,INTERRUPT,NET_NG,NET_ETHER,NET_= TUN,MOUSE,KEYBOARD,ATTACH,CACHED Feeding entropy: . Starting Network: lo0 awg0. lo0: flags=3D8049 metric 0 mtu 16384 options=3D600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 groups: lo nd6 options=3D21 awg0: flags=3D8802 metric 0 mtu 1500 options=3D8000b ether 02:20:36:eb:80:da media: Ethernet autoselect (none) nd6 options=3D29 Starting devd. Starting Network: awg0. awg0: flags=3D8802 metric 0 mtu 1500 options=3D8000b ether 02:20:36:eb:80:da media: Ethernet autoselect (none) nd6 options=3D29 add host 127.0.0.1: gateway lo0 fib 0: route already in table add host ::1: gateway lo0 fib 0: route already in table add net fe80::: gateway ::1 add net ff02::: gateway ::1 add net ::ffff:0.0.0.0: gateway ::1 add net ::0.0.0.0: gateway ::1 Generating host.conf. fstab: /etc/fstab:0: No such file or directory fstab: /etc/fstab:0: No such file or directory Creating and/or trimming log files. Starting syslogd. Clearing /tmp (X related). Updating motd:. Mounting late filesystems:fstab: /etc/fstab:0: No such file or directory . fstab: /etc/fstab:0: No such file or directory ^CScript /etc/rc.d/sendmail interrupted Starting cron. eval: cannot open /etc/fstab: No such file or directory Starting background file system checks in 60 seconds. Fri Jan 1 00:03:54 UTC 2010 FreeBSD/arm (Amnesiac) (ttyu0) login: Finally, it boots,=20 ethernet adapter looks working ok: media: Ethernet autoselect (1000b= aseT ) wifi was not auto-detected on boot (Realtek RTL8189ETV, IEEE 802.11 b/g/n) even SMP looks works as expected: last pid: 743; load averages: 1.03, 0.42, 0.36 up 0+00:16:12 00:1= 6:34 13 processes: 5 running, 8 sleeping CPU: 100% user, 0.0% nice, 0.0% system, 0.0% interrupt, 0.0% idle Mem: 10M Active, 1380K Inact, 49M Wired, 13M Buf, 1936M Free Swap: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMA= ND 738 root 1 98 0 6696K 2840K CPU1 1 0:19 103.05% sh 737 root 1 99 0 6696K 2812K CPU3 3 0:21 101.11% sh 741 root 1 92 0 6696K 2840K RUN 2 0:11 99.44% sh 740 root 1 93 0 6696K 2840K CPU0 0 0:12 96.06% sh 743 root 1 20 0 7616K 2972K CPU2 2 0:00 0.57% top =E2=80=A6 =20 How to make orangepi-plus2e specific port: $ diff -u u-boot-orangepi-one/Makefile u-boot-orangepi-plus2e/Makefile --- u-boot-orangepi-one/Makefile 2016-07-12 23:22:16.000000000 +0300 +++ u-boot-orangepi-plus2e/Makefile 2016-11-22 01:00:30.715760000 +0300 @@ -8,7 +8,7 @@ MASTERDIR=3D ${.CURDIR}/../u-boot-olimex-a20-som-evb DESCR=3D ${.CURDIR}/pkg-descr -MODEL=3D orangepi-one -BOARD_CONFIG=3D orangepi_one_defconfig +MODEL=3D orangepi-plus2e +BOARD_CONFIG=3D orangepi_plus2e_defconfig .include "${MASTERDIR}/Makefile" Some very basic patch on crochet tool: https://github.com/freebsd/crochet/p= ull/168 -- Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-arm@freebsd.org Tue Nov 22 14:56: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 C9FD1C4FCAB for ; Tue, 22 Nov 2016 14:56:14 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 83898E24 for ; Tue, 22 Nov 2016 14:56:14 +0000 (UTC) (envelope-from jiashiun@gmail.com) Received: by mail-ua0-x22c.google.com with SMTP id 12so16439345uas.2 for ; Tue, 22 Nov 2016 06:56:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rnQYkD1z9ecEEiQyZ5NrRnniSJKb0YIDdJrrWoUhNH0=; b=qxpXh0VM5yIqIBDoTlIiAbNn3p4lQF1mXuU8AR2l/ZrD0u3jP9q+6qkxj5vtt7sGJE 7tBdNDV4EOxyHM4KYiHFjHoUj7NShhI4m7s8yXd882Chs0mGyTw5X0nzfXF2NYuaNsbD E1NjksEXxMdu2N4Z2bh4DWNDYQY/NYIJMoaNVG81sXgCi/RY+Z3TgLTyZBlsYFY+gU+L 6x6BR8s7H560aL0tkAJNkYgF9k9mGdvHb/mEYnguO9JMaoRxY6b2HBF/xUj0YFV5IMyE a9ZpI3GdJaEY7tk4+pvtPx8rjEyoi7lKI4sjQ7RjpHi4/WHmK5aROSulgPdX7cWA5hNU q8VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rnQYkD1z9ecEEiQyZ5NrRnniSJKb0YIDdJrrWoUhNH0=; b=ATREEL3suB4BM6q6ALOn8wQrVHVnZr9HMYGjYG8bNDU6F+9AS0oudCMWeTd008ee/D fnVjhQHVFSyeUX2cLqDS6tgIvfWWLrxlpepBuxqnvXfSjb0H5h+0Hd0+uRH3Vi/ZLB8b 3oUTPcXT4QJtsAtylD9yyx2J/VhOwqxLQOBxomjO70xZ4aG88yx/tAYSM99ucKKolxhw m2o+1dLBXrIeSXnI9Naz8SGAUr6tLbr2QvN4zverYM3xHkztUUeQSBrA1uvafybHacfm wbJjkBPe3d9nFJhopPyinZ+0/fw3wMkg/PHyNp5LlFhbnDvVhteorky57UqwPMkTq1lI 04bg== X-Gm-Message-State: AKaTC00aYyXFiTRGNdalFUF/XXs4yLlF3eItFy7a7jkx9W5N8TGs+EN357m1xSUUqPuoYXexeQLevBhZ3s9kHA== X-Received: by 10.176.2.145 with SMTP id 17mr8950682uah.38.1479826573023; Tue, 22 Nov 2016 06:56:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.69.214 with HTTP; Tue, 22 Nov 2016 06:55:42 -0800 (PST) In-Reply-To: <20161118172528.GA56313@www.zefox.net> References: <20161118172528.GA56313@www.zefox.net> From: Jia-Shiun Li Date: Tue, 22 Nov 2016 22:55:42 +0800 Message-ID: Subject: Re: RPI2: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 b6 d0 e8 00 00 18 00 To: bob prohaska Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 14:56:14 -0000 If it keeps complaining at the same offset (3rd to 6th byte) then it probably is. You can do a whole disk read scanning through it to see if it will be stuck at the same position every time. -Jia-Shiun. On Sat, Nov 19, 2016 at 1:25 AM, bob prohaska wrote: > Lately -head on an RPI2 has started showing what looks like a recovered > error > on the console shortly after rebooting: > > Thu Nov 17 09:30:18 PST 2016 > > FreeBSD/arm (www.zefox.com) (ttyu0) > > login: Nov 17 09:31:36 www su: bob to root on /dev/pts/0 > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 b6 d0 e8 00 00 18 00 > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > (da0:umass-sim0:0:0:0): Retrying command > > > FreeBSD/arm (www.zefox.com) (ttyu0) > > > It repeats verbatim between OS builds and reboots. No detectable problems > otherwise are apparent. Uname -a reports: > FreeBSD 12.0-CURRENT (RPI2) #13 r308792: Thu Nov 17 23:13:55 PST 2016 > > da0 is a USB flash drive hosting /usr, /var, /tmp and swap, root is on > micro-SD. > > Is this suggestive of hardware trouble? > > Thanks for reading! > > bob prohaska > > _______________________________________________ > 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 Tue Nov 22 16:00: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 2BA2FC4CA6A for ; Tue, 22 Nov 2016 16:00:28 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [69.239.235.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F01011830 for ; Tue, 22 Nov 2016 16:00:27 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id uAMG0Oqm073945 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 22 Nov 2016 08:00:25 -0800 (PST) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id uAMG0OwY073944; Tue, 22 Nov 2016 08:00:24 -0800 (PST) (envelope-from fbsd) Date: Tue, 22 Nov 2016 08:00:24 -0800 From: bob prohaska To: Jia-Shiun Li Cc: "freebsd-arm@freebsd.org" Subject: Re: RPI2: (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 b6 d0 e8 00 00 18 00 Message-ID: <20161122160024.GC56313@www.zefox.net> References: <20161118172528.GA56313@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 16:00:28 -0000 On Tue, Nov 22, 2016 at 10:55:42PM +0800, Jia-Shiun Li wrote: > If it keeps complaining at the same offset (3rd to 6th byte) then it > probably is. The error didn't recur on the next reboot, FWIW. > You can do a whole disk read scanning through it to see > if it will be stuck at the same position every time. > Is there a favorite utility for the purpose? > -Jia-Shiun. > Thanks for writing! bob prohaska > On Sat, Nov 19, 2016 at 1:25 AM, bob prohaska wrote: > > > Lately -head on an RPI2 has started showing what looks like a recovered > > error > > on the console shortly after rebooting: > > > > Thu Nov 17 09:30:18 PST 2016 > > > > FreeBSD/arm (www.zefox.com) (ttyu0) > > > > login: Nov 17 09:31:36 www su: bob to root on /dev/pts/0 > > (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 b6 d0 e8 00 00 18 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command > > > > > > FreeBSD/arm (www.zefox.com) (ttyu0) > > > > > > It repeats verbatim between OS builds and reboots. No detectable problems > > otherwise are apparent. Uname -a reports: > > FreeBSD 12.0-CURRENT (RPI2) #13 r308792: Thu Nov 17 23:13:55 PST 2016 > > > > da0 is a USB flash drive hosting /usr, /var, /tmp and swap, root is on > > micro-SD. > > > > Is this suggestive of hardware trouble? > > > > Thanks for reading! > > > > bob prohaska > > > > _______________________________________________ > > 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 Tue Nov 22 20:31: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 58A10C50134 for ; Tue, 22 Nov 2016 20:31:24 +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 3B70CDA6 for ; Tue, 22 Nov 2016 20:31:23 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: a5845575-b0f2-11e6-94b7-cbe6054a74b1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id a5845575-b0f2-11e6-94b7-cbe6054a74b1; Tue, 22 Nov 2016 20:31:29 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAMKVJar001885; Tue, 22 Nov 2016 13:31:20 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1479846679.1889.8.camel@freebsd.org> Subject: Re: PPS input on GPIO pin RPI2. From: Ian Lepore To: Peter =?ISO-8859-1?Q?Ankerst=E5l?= Cc: "freebsd-arm@FreeBSD.org" Date: Tue, 22 Nov 2016 13:31:19 -0700 In-Reply-To: <3FE31F8E-CFDF-4C36-89F8-B90EB8AC2D8D@pean.org> References: <56FCEE15.60109@pean.org> <1460061822.1091.314.camel@freebsd.org> <794E7B45-5512-4032-8CBE-7D2BD1533BD4@pean.org> <1479426298.59911.135.camel@freebsd.org> <1479426521.59911.137.camel@freebsd.org> <0D888B68-3231-4611-83FA-47DCD1A75CA5@pean.org> <1479837907.12501.39.camel@freebsd.org> <3FE31F8E-CFDF-4C36-89F8-B90EB8AC2D8D@pean.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 20:31:24 -0000 On Tue, 2016-11-22 at 20:57 +0100, Peter Ankerstål wrote: > > > > > > So without overlay support, you need to modify the dts file for your > > board to add the pps device.  For my wandboards I added it at the root > > of the device tree (not as a child of some existing bus).  You can > > append something like this to the end of your existing dts file: > > > >    / { > >         pps@0     { > >              compatible = "pps-gpio"; > >              gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; > >              status = "okay"; > >         }; > >    }; > > > > I don't know much about rpi, but I vaguely recall it only has one gpio > > controller, so probably replace gpio3 with just gpio.  I'm not sure > > what to do about pin config on an rpi, it just needs to be an input > > pin, preferably without any pullup or pulldown enabled.   > > > > Oh yeah, and... be careful about voltage... many PPS sources emit a 5v > > pulse, and rpi pins are 3.3v inputs.  I've gotten around that in the > > past with passive voltage dividers made from a pair of 50-ohm > > resistors; the roughly 2.5v pulse you get from tapping the middle of > > the divider is plenty to get sensed on the gpio pin. > > > > > Thanks. I actually have a gps that outputs 3.3v. (adafruit). > > I added this: >         pps@0  { >                 compatible = "pps-gpio"; >                 gpios = <&gpio 27 0>; >                 status = "okay"; >         }; > > and it now works fine: > > gpiopps0: on ofwbus0 > gpiopps0: PPS input on gpio0 pin 27 > > added link /dev/pps0 -> gpiopps0 > > and have server 127.127.22.0 in ntp.conf. > > root@ntp:~ # ntpq -p >      remote   refid    st t when poll reach   delay   offset  jitter > ==================================================================== > oPPS(0)       .PPS.    0 l   17   64  377    0.000    1.803   0.014 > *gbg1.ntp.se  .PPS.    1 u   23   64  377    7.309    1.764   0.054 > +gbg2.ntp.se  .PPS.    1 u    7   64  377    7.173    1.765   0.041 Cool!  I notice we lost the CC to the arm@ list somewhere along the line.  I've added it back for this reply, so that other folks can see how to get this all configured. For those following along... this setup uses a PPS to make the kernel clock very accurate, but also requires another (network-based) ntp peer to provide the time-of-day.  The minimum entries you need in ntp.conf for a configuration like this are:   server 127.127.22.0 prefer   fudge  127.127.22.0 stratum 0   server iburst prefer Of particular importance is that the 'prefer' keyword is needed on the pps (127.127.22.0) server and any one of the network servers. For a pure GPS solution that doesn't require another network ntp server to number the seconds, the 'gpsd' port knows how to talk to most gps receivers via a serial connection.  That's about all I know about gpsd. -- Ian From owner-freebsd-arm@freebsd.org Tue Nov 22 20:44: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 92A3AC504AA for ; Tue, 22 Nov 2016 20:44:22 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [52.16.239.146]) (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 28C80159C for ; Tue, 22 Nov 2016 20:44:21 +0000 (UTC) (envelope-from peter@pean.org) Received: from system.jails.se (system.jails.se [172.31.20.14]) by system.jails.se (Postfix) with SMTP id 9DB5F4D9E52 for ; Tue, 22 Nov 2016 21:44:13 +0100 (CET) Received: from lune.pean.org (h148n9-u-a31.ias.bredband.telia.com [213.67.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by system.jails.se (Postfix) with ESMTPSA id E55DB4D9E4D; Tue, 22 Nov 2016 21:44:12 +0100 (CET) From: =?utf-8?Q?Peter_Ankerst=C3=A5l?= Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_73610912-0D67-4A8F-A993-B650D465BB7D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: PPS input on GPIO pin RPI2. Date: Tue, 22 Nov 2016 21:44:11 +0100 In-Reply-To: <1479846679.1889.8.camel@freebsd.org> Cc: "freebsd-arm@FreeBSD.org" To: Ian Lepore References: <56FCEE15.60109@pean.org> <1460061822.1091.314.camel@freebsd.org> <794E7B45-5512-4032-8CBE-7D2BD1533BD4@pean.org> <1479426298.59911.135.camel@freebsd.org> <1479426521.59911.137.camel@freebsd.org> <0D888B68-3231-4611-83FA-47DCD1A75CA5@pean.org> <1479837907.12501.39.camel@freebsd.org> <3FE31F8E-CFDF-4C36-89F8-B90EB8AC2D8D@pean.org> <1479846679.1889.8.camel@freebsd.org> X-Mailer: Apple Mail (2.3251) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Nov 22 21:44:13 2016 X-DSPAM-Confidence: 0.9899 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 5834ae1d18887417781788 X-DSPAM-Factors: 27, but, 0.01000, Subject*Re+#+input+on+GPIO, 0.01000, Lepore+#+#+org, 0.01000, Subject*input+#+GPIO+#+RPI2., 0.01000, org, 0.01000, org, 0.01000, Subject*on+GPIO, 0.01000, ian+freebsd+#+wrote, 0.01000, From*Peter_Ankerst%c3%a5l, 0.01000, From*Peter_Ankerst%c3%a5l, 0.01000, On+#+#+2016, 0.01000, Mime-Version*OS+X, 0.01000, freebsd+#+wrote, 0.01000, ian+#+#+wrote, 0.01000, Lepore+ian+freebsd, 0.01000, Subject*input+on+GPIO+pin, 0.01000, Mime-Version*Mac+OS+X+Mail, 0.01000, ian+freebsd+org, 0.01000, Subject*Re+PPS+input, 0.01000, Subject*Re+PPS+#+on, 0.01000, To*Ian+#+ian, 0.01000, Mime-Version*X+Mail+10.1, 0.01000, To*Lepore+ian+freebsd.org, 0.01000, To*Ian+Lepore, 0.01000, Mime-Version*1.0+Mac+OS+X+Mail, 0.01000, Subject*PPS+input+on, 0.01000, Ian+#+ian+freebsd+org, 0.01000 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Nov 2016 20:44:22 -0000 --Apple-Mail=_73610912-0D67-4A8F-A993-B650D465BB7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Nov 2016, at 21:31, Ian Lepore wrote: >=20 > Cool! I notice we lost the CC to the arm@ list somewhere along the > line. I've added it back for this reply, so that other folks can see > how to get this all configured. >=20 > For those following along... this setup uses a PPS to make the kernel > clock very accurate, but also requires another (network-based) ntp = peer > to provide the time-of-day. The minimum entries you need in ntp.conf > for a configuration like this are: >=20 > server 127.127.22.0 prefer > fudge 127.127.22.0 stratum 0 > server iburst prefer >=20 > Of particular importance is that the 'prefer' keyword is needed on the > pps (127.127.22.0) server and any one of the network servers. >=20 > For a pure GPS solution that doesn't require another network ntp = server > to number the seconds, the 'gpsd' port knows how to talk to most gps > receivers via a serial connection. That's about all I know about = gpsd. >=20 Actually ntpd knows how to interpet NMEA (including timestamps) output = which is usually output on the serial interface of your GPS. All you need to do is to hook up it to the serial interface of your = machine running ntpd and link your serial device to /dev/pps1 for = example. and then have something like this in ntp.conf: server 127.127.20.1 mode 17 fudge 127.127.20.1 time1 +0.140 the first line tells ntpd to look for NMEA on /dev/pps1 and some = settings about baudrate and so on.=20 the second line is to compensate for the delay of the serial interface = which you will have to figure out in some way.=20 More information about this here: = http://support.ntp.org/bin/view/Support/ConfiguringNMEARefclocks --Apple-Mail=_73610912-0D67-4A8F-A993-B650D465BB7D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIL0TCCBeIw ggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwx FjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmlj YXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4X DTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmvmCSsu1d52DXsCR58zJQbCtB2/A5uFqNx WacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnmVkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+C evdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx 7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PIdopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8U lVS8pkIsoGGJtMuWjLL4tq2hYQuuN0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1Ud DwEB/wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB /wIBADAyBgNVHR8EKzApMCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmww ZgYIKwYBBQUHAQEEWjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYI KwYBBQUHMAKGJGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQU JIFsOWG+SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYD VR0gBDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY0JdO ruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpFNjDmQbcM 3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9uRbhjTu/b0x2 Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p6q/CW+uVrZiSW57+ q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOvZ3UDsTDTagXpRDIKQLZo 02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOumZhLP+SWJQnjpLpSlUOj95uf 1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7RX6gVr0fQoCyMczNzCTcRXYHY0tq 2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO/ZskmSY8wtAk24orAc0vwXgYanqNsBX5 Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsNJQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1 UeGp/2deoprGevfnxWB+vHNQiu85o6MwggXnMIIEz6ADAgECAhAdwkZzPAAYv96HE98uZJjPMA0G CSqGSIb3DQEBCwUAMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20g Q2xhc3MgMSBDbGllbnQgQ0EwHhcNMTYwMTI2MTcxODQ0WhcNMTcwMTI2MTcxODQ0WjA4MRcwFQYD VQQDDA5wZXRlckBwZWFuLm9yZzEdMBsGCSqGSIb3DQEJARYOcGV0ZXJAcGVhbi5vcmcwggIiMA0G CSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCwqV33CkA0AcJKEWGdaBVRxR37sXxEkkhq19lru5yk DJpYi6ocVvMFQVss9Yk16i2E1DdktxK6zYI/6XmAJqa/QblJeX535zVAVE/9+5rcV3yXb7HdfSAu b5OxvZvd5hTt3YxmCXeDC0pMzZke0bX2oVUqUgLmlWuo+S8yVW1GIWDP8G1u3FJnnGx31S3ZNiq4 vPdpCZzttSPAQS8Ev6mwxAI6TRFrtvqfHI3kbPpqXRoWBCwwzfGN3y01QM/K4hbEo78BdaIq61cI MZv6kHyx0zGdhdhUiLlMvM5FcFlhCju49c7mJekFfVahpQVmYOq1q04v6km3lFj/HqJy9BDVKe/x z7RKBqIF06msyWdGCN5KKpRDIkuWEUByFWJkrMiTi5lkXY7oSWGzVK7RIHdidpy6tbcsFdDLB8Hh 7Wh/3r8eGP9VSyUUEwuK/aKfaQYFhCyNXHrWjJpHzbcjP6Xf6rrbavZfOU++wN8aqGEwEQa7QKKh 9Sd8KQd8BdwwYohfwoNUsrRoOr3UHKvzFzyln7hQBiFjHpnLWTLBdF7Z8Uit5vqLpP6WfMdZE1h8 dEC7suFtBRziZQUdqjB+qFxSDB494pZW0ZxYXboBxxJDPWfanZaJnTRE52f3zqC21e3gewiX2Uw9 yfr0mDnkYln6ezySA22q51vt+HY4CGSnjQIDAQABo4IBrjCCAaowCwYDVR0PBAQDAgSwMB0GA1Ud JQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQ04RHsQYirZqzw URApkWCeAOCFvzAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggrBgEFBQcBAQRj MGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5BggrBgEFBQcwAoYtaHR0 cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0MDgGA1UdHwQxMC8wLaAr oCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQxLmNybDAZBgNVHREEEjAQgQ5w ZXRlckBwZWFuLm9yZzAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wRgYDVR0g BD8wPTA7BgsrBgEEAYG1NwECBDAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEBALwG9xRbvTNO3YlZYPQ/aurIp1fbO+W1c80gBL0Y 1jeW2Rwb0EF6EMkpsl/gFALmktGvDkEaNWGvj7d/eUNv3kUceiUod7sbiBNSN2oiVxqe7RcfVYY1 cNTCJsxGeC+c533jJzEWgB9ZIULyTawUBvYEsT0phiX17hQuRL8F/aJyUcyz+yFccZHMVe6DxuAe mJ/PMcKUe1xb3tcCtSQW8FIfY9KDuxKeiU6mXi7RXAiIIq8tFNkJYsPtNIkKtOeGwjLidaNG1nMi xGKc7fl+G6VGmMvZv6mSE1LPqPZJUwXgbcfVIIrpDEGkDS5AP5/o6DZr8AiOe2Za1pCO3f+Dv3cx ggROMIIESgIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhAdwkZzPAAYv96HE98uZJjPMAkGBSsOAwIaBQCgggGZMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MTEyMjIwNDQxMlowIwYJKoZI hvcNAQkEMRYEFGEOybKZMWx5cTZKwzE2h7Gim/DtMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkG A1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQ HcJGczwAGL/ehxPfLmSYzzCBnAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAU BgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQHcJGczwAGL/ehxPf LmSYzzANBgkqhkiG9w0BAQEFAASCAgAroTECgdtAmSjeAc9tW6KfjSDcX/Shetyz8rNUPifAk+yG xfT4Vii/IOFlKREpfs+krauccUMRn5sbQvmdcY41wudgD5bsiB5MEA3/9BnLrFUakDBoo6lBM/kN qyLjJKij7ZUaUJcTOw8kWqqTaAQEkvqv19k2Jn8zIuuVVQH/tJDcAacF+CP5PmsbDp8u5mhV49EZ cpp4k7YvrzM3gwITBgoKA1XJ/28Tq9jVv7xUYPUqZyRJzKpdOD0nmHhVmxI5YiAOplIv0XWeu4Ef jnir1y9qNCGa9T9RnZ6FZckEPAYScILlyUtbHddCfek23uJmoABH/e+Sl7DSSGU6HUFrxTwwyxy4 Sz9Ea0qI5y5ZMj9chktSNcLyu9Voa9fF5USQE+tl0JWyK1g+eezX79FJg9umt1lSwAHGHhQ1VDqV GyaJTn4esDMzkwrWGVI9Z92lyCVi48EXavRz4Q5ZvuLmPYc/nbqr4xmvEOY4z/VXV/TF4KCKmZkK 51F5gU5g1aFKaykqm7xI6hqOZ1l23qgYyXzR66S34z72zvjAP8kdZqJe3mbv+tP2QjWyTFVQX0/F ow48y56gGv86cy3MRDGPVqE+hSyQiVaJNPy790oaw/X/c4mZZY05FsCEBAMatiBHIU2NPVXTz7d+ nLYocqw+JCnnGD9H7p1xti61TZT8aAAAAAAAAA== --Apple-Mail=_73610912-0D67-4A8F-A993-B650D465BB7D-- From owner-freebsd-arm@freebsd.org Wed Nov 23 10:46:25 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 44EF9C4FE78 for ; Wed, 23 Nov 2016 10:46:25 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb2-smtp-cloud3.xs4all.net (lb2-smtp-cloud3.xs4all.net [194.109.24.26]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DE1CB18C for ; Wed, 23 Nov 2016 10:46:24 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud3.xs4all.net with ESMTP id BNl81u0064VixDu01Nl9ah; Wed, 23 Nov 2016 11:45:10 +0100 Reply-To: From: "John W. Kitz" To: "'freebsd-arm'" Subject: How do U-boot and SPL compare to an IML and an IPL on a mainframe? Date: Wed, 23 Nov 2016 11:45:11 +0100 Message-ID: <000501d24576$ac4339b0$04c9ad10$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJFdqqKbvQn1B0SSF+1OH69NPhU7A== Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 10:46:25 -0000 Hi, While I'm waiting for the delivery of my first ARM based board, I was wondering if someone would be kind enough to provide a brief explanation (or a link to one) of how U-boot and SPL (and related software) in de UNIX world, required in the process of starting up some systems, compare to an Initial Microcode Load (IML) and an Initial Program Load (IPL) in the world of mainframes. In others words am I correct in assuming that U-boot more or less does what an IML does and that SPL more or less does what an IPL does? Thanks and regards, Jk. From owner-freebsd-arm@freebsd.org Wed Nov 23 11:45: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 43264C50547 for ; Wed, 23 Nov 2016 11:45:36 +0000 (UTC) (envelope-from tinaskitchen@sympatico.ca) Received: from BLU004-OMC3S37.hotmail.com (blu004-omc3s37.hotmail.com [65.55.116.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "*.outlook.com", Issuer "Microsoft IT SSL SHA2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 04F21DE for ; Wed, 23 Nov 2016 11:45:35 +0000 (UTC) (envelope-from tinaskitchen@sympatico.ca) Received: from BLU437-SMTP5 ([65.55.116.74]) by BLU004-OMC3S37.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 23 Nov 2016 03:44:28 -0800 X-TMN: [wVY+D/xOVOXFvByyqrqyWqFTqVV7P8+J] X-Originating-Email: [tinaskitchen@sympatico.ca] Message-ID: From: Payroll =?ISO-8859-1?Q?Management=A9?= Subject: Payroll Management Position To: freebsd-arm@freebsd.org MIME-Version: 1.0 Date: Wed, 23 Nov 2016 12:43:24 +0100 X-Antivirus: avast! (VPS 161122-1, 22/11/2016), Outbound message X-Antivirus-Status: Clean X-OriginalArrivalTime: 23 Nov 2016 11:44:25.0921 (UTC) FILETIME=[F1083B10:01D2457E] Content-Type: text/plain Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 11:45:36 -0000 - This mail is in HTML. Some elements may be ommited in plain text. - Payroll Management, Inc is currently searching for self motivated appl= icants (male/female) who are reliable, articulate and eager to learn w= ith minimal supervision required to work-from-home.Successful candidat= es will be responsible for processing paychecks of workers on a weekly= and bi-weekly basis with Payroll software which will be provided upon= training. ? Excellent organization skills and ability to multitask and juggle mu= ltiple priorities. ? Organized Part Time/Full Time Salary (Minimum): $700.00 If interested, Submit resume/cover letter to: jacksoncullen328@gmail.com or on my cell (813) 9678844 you may leave a message or text should i'= m not available to receive calls. Cullen Jackson, From owner-freebsd-arm@freebsd.org Wed Nov 23 15:49: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 62AF8C515BC for ; Wed, 23 Nov 2016 15:49:09 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 009AA269 for ; Wed, 23 Nov 2016 15:49:08 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 5f42bd0d-b194-11e6-b17f-19517aec265d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 5f42bd0d-b194-11e6-b17f-19517aec265d; Wed, 23 Nov 2016 15:49:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uANFmvsT003902; Wed, 23 Nov 2016 08:48:57 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1479916137.1889.28.camel@freebsd.org> Subject: Re: How do U-boot and SPL compare to an IML and an IPL on a mainframe? From: Ian Lepore To: John.Kitz@xs4all.nl, "'freebsd-arm'" Date: Wed, 23 Nov 2016 08:48:57 -0700 In-Reply-To: <000501d24576$ac4339b0$04c9ad10$@Kitz@xs4all.nl> References: <000501d24576$ac4339b0$04c9ad10$@Kitz@xs4all.nl> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 15:49:09 -0000 On Wed, 2016-11-23 at 11:45 +0100, John W. Kitz wrote: > Hi, > > While I'm waiting for the delivery of my first ARM based board, I was > wondering if someone would be kind enough to provide a brief > explanation (or > a link to one) of how U-boot and SPL (and related software) in de > UNIX > world, required in the process of starting up some systems, compare > to an > Initial Microcode Load (IML) and an Initial Program Load (IPL) in the > world > of mainframes. > > In others words am I correct in assuming that U-boot more or less > does what > an IML does and that SPL more or less does what an IPL does? > > Thanks and regards, Jk. Heh.  IPL.  That brings back memories.  Old old memories. Typically a modern arm SOC has a little bit of ROM code, just enough to read a small initial bootcode from a few selected devices (sdcard, eeprom, spi flash, etc).  Very often that small initial bootcode is loaded into some on-chip SRAM and that's what limits the size of the initial bootcode.  In the u-boot world, that small bootcode is SPL.  Another thing that's often true is that the arm core is running on some slow clock at this point, usually 32KHz, sometimes 24MHz. On many systems, the SPL code is responsible for configuring clocks and DRAM.  The SPL code also has larger and more-complete device drivers so that it can load the next stage from a wider variety of devices.  The next stage gets loaded into DRAM and typically runs with the cpu at or near full speed, caches enabled, etc. The next stage in some systems is the kernel.  That's especially true on things like phones where the boot process has to be so fast you don't even notice it.  On more general-purpose systems the next stage is u-boot, which does further system configuration and then continues by loading the next stage loader (which in freebsd is ubldr, a u-boot aware form of loader(8)). All in all, rather than IML (which has no analog on small arm chips) and IPL, a better analogy for the role of u-boot is that of a PC BIOS.  It's responsible for basic system hardware bringup and getting the next stage of bootloader running.  Like a pc bios, u-boot is still around while that next stage loader is running, and it can provide basic services for that loader such as a low-level device IO API.  Unlike a pc bios, however, there comes a time when u-boot is just gone; it doesn't hang around providing services forever. -- Ian From owner-freebsd-arm@freebsd.org Wed Nov 23 21:16:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82EB6C5129D for ; Wed, 23 Nov 2016 21:16:52 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 22E6CC4 for ; Wed, 23 Nov 2016 21:16:51 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id BZGh1u00L4VixDu01ZGiiS; Wed, 23 Nov 2016 22:16:43 +0100 Reply-To: From: "John W. Kitz" To: "'freebsd-arm'" Subject: Re: How to change MAC address on RPI-B? Date: Wed, 23 Nov 2016 22:16:45 +0100 Message-ID: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJFzuTkrgipbA2DTVyTeWW/O44EzA== Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2016 21:16:52 -0000 Reiner, I'm curious if you needed a driver change to be able to set a locally administered mac address, does that mean it's impossible for you to set it through uEnv.txt? Jk. From owner-freebsd-arm@freebsd.org Thu Nov 24 08:33: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 32C3AC53A1E for ; Thu, 24 Nov 2016 08:33:19 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from deinprogramm.de (deinprogramm.de [88.198.58.179]) by mx1.freebsd.org (Postfix) with ESMTP id F111F181 for ; Thu, 24 Nov 2016 08:33:18 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from jellaby.local (unknown [195.52.203.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deinprogramm.de (Postfix) with ESMTPSA id 9B58B3028B for ; Thu, 24 Nov 2016 08:23:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=deinprogramm.de; s=default; t=1479975823; bh=vQZMlKBJE3MY3Qj9GnqDX40Idz4yCCAwznvxvqLPinI=; h=From:To:Subject:Date; b=M7nqapyekOI0YuGROHuJB3lJ/wLtqhxKrgmLhrIrNyW1S9w4sUJ7talrE6wJobd3U gOmlZxaRl1cGUsfq6NQBppdI6yzplTEHH8QhBRfRwcfXAHaBD6KImD/v+2Oq6hhQcg 4XjP8qeyst8dJH1HKYxLTIwzJ46HFlFCbt9FDPXc= Received: from jellaby.local.deinprogramm.de (localhost [IPv6:::1]) by jellaby.local (Postfix) with ESMTP id 8B9C392D1AA2 for ; Thu, 24 Nov 2016 09:23:43 +0100 (CET) From: Michael Sperber To: freebsd-arm@freebsd.org Subject: Can't get 11.0-RELEASE to boot on Banana PI M3 Date: Thu, 24 Nov 2016 09:23:43 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 08:33:19 -0000 I'm new to this list (and to FreeBSD on ARM), so forgive me if I'm asking something trivial: I built a FreeBSD 11.0-RELEASE image for my BPI M3 using Crochet, by the book as far as I can tell. The result doesn't boot, and I see no external indication that anything is happening. (I.e. no LEDs blinking, as they usually do when a working image boots up.) This thread: http://permalink.gmane.org/gmane.os.freebsd.devel.arm/14466 ... led me to believe uboot might currently be broken. Is that indeed the case? Any instructions I could follow to get a working version. Any help would be much appreciated! -- Regards, Mike From owner-freebsd-arm@freebsd.org Thu Nov 24 21:17: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 B59E8C53EDA for ; Thu, 24 Nov 2016 21:17:10 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-32.reflexion.net [208.70.210.32]) (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 7AAC7F29 for ; Thu, 24 Nov 2016 21:17:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 26943 invoked from network); 24 Nov 2016 21:16:48 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 24 Nov 2016 21:16:48 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 24 Nov 2016 16:17:09 -0500 (EST) Received: (qmail 27598 invoked from network); 24 Nov 2016 21:17:09 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Nov 2016 21:17:09 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 828FDEC7977; Thu, 24 Nov 2016 13:17:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 From: Mark Millard In-Reply-To: Date: Thu, 24 Nov 2016 13:17:01 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Michael Sperber X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 21:17:10 -0000 On 2016-Nov-24, at 12:23 AM, Michael Sperber wrote: > I'm new to this list (and to FreeBSD on ARM), so forgive me if I'm > asking something trivial: >=20 > I built a FreeBSD 11.0-RELEASE image for my BPI M3 using Crochet, by = the > book as far as I can tell. The result doesn't boot, and I see no > external indication that anything is happening. (I.e. no LEDs = blinking, > as they usually do when a working image boots up.) >=20 > This thread: >=20 > http://permalink.gmane.org/gmane.os.freebsd.devel.arm/14466 >=20 > ... led me to believe uboot might currently be broken. Is that indeed > the case? Any instructions I could follow to get a working version. >=20 > Any help would be much appreciated! >=20 > --=20 > Regards, That link is about the BPi-M2 (not BPI-M3). As far as u-boot goes there = is: # ls -ld /usr/ports/sysutils/u-boot-*m[0-9] drwxr-xr-x 2 root wheel 4 Jul 24 17:02 = /usr/ports/sysutils/u-boot-bananapim2 drwxr-xr-x 3 root wheel 6 Jul 24 17:02 = /usr/ports/sysutils/u-boot-sinovoip-bpi-m3 I've successfully used the second with a BPi-M3 (as it was at the time anyway). I've access to a BPi-M3 V1.2 board with the power barrel connector instead of a small cell-phone-USB style power connector. I have a heatsink and a 3.3V fan. A 10 W (5V 2A) power supply was not enough so I'm using a 15 W (5V 3A) power supply so far. Trying to use a fan on the 5V always prevented booting, even with the 15 W power supply. The vintage of crochet that I used only allowed using head (CURRENT). I changed it to not check for that so that I could use stable/11 : diff --git a/lib/board.sh b/lib/board.sh index 98f54bc..926813c 100644 --- a/lib/board.sh +++ b/lib/board.sh @@ -83,7 +83,7 @@ strategy_add $PHASE_POST_CONFIG board_defined =20 # TODO: Not every board requires -CURRENT; copy this into all the # board setups and remove it from here. -strategy_add $PHASE_CHECK freebsd_current_test +#strategy_add $PHASE_CHECK freebsd_current_test =20 board_check_image_size_set ( ) { # Check that IMAGE_SIZE is set. Crochet makes the mistake of using a file in the file system as the swap-space when creating a swap-space is enabled. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 on why this is currently not a good idea --it can hang/lock-up. The swap space should be a separate partition instead because things are not working correctly for file based swap-spaces. So I avoided this. (The issue is not likely to stop a BPi-M3 from booting.) If one wants to create a swap partition after the basic install it is likely best to avoid the automatic growfs option: That would lead to needing to shrink a partition to make room for the swap-space partition. Growing to less than the full space available is easier, leaving room to add the swap partition as well. Initially not having a swap-space should be fine: it should still boot and operate, allowing one to do the rest of the steps to create a swap-space and set up to use it if one wants such. Soft updates journaling is also enabled by crochet. This has some tradeoffs according to: http://www.wonkity.com/~wblock/docs/html/ssd.html (The page is not about crochet, just about the author's recommendations for FreeeBSD generally.) Quoting: > Soft updates journaling (SUJ) is not used for two reasons: there > have been problems with SUJ that prevent the use of dump(8) to > back up filesystems, and SUJ=E2=80=99s killer feature is dramatically=20= > reduced fsck(8) times. But SSDs provide dramatically reduced > fsck(8) times anyway. So adjustments for this are another possibility. I sometimes use dump and restore so I wanted to avoid SUJ. Also after the initial boot of the BPi-M3 I changed things to have the root file system on a USB SSD where the SDHC performance does not matter after the kernel is loaded. I knew up front that I was going to do that. (The gpart create's -n figure below is way larger than I need on the SDHC but it is what I used.) diff --git a/lib/disk.sh b/lib/disk.sh index 53dfb10..507d28e 100644 --- a/lib/disk.sh +++ b/lib/disk.sh @@ -386,7 +386,7 @@ disk_ufs_create ( ) { NEW_UFS_SLICE=3D`gpart add -t freebsd -a 512k ${SIZE_ARG} = ${DISK_MD} | sed -e 's/ .*//'` || exit 1 NEW_UFS_SLICE_NUMBER=3D`echo ${NEW_UFS_SLICE} | sed -e = 's/.*[^0-9]//'` =20 - gpart create -s BSD ${NEW_UFS_SLICE} + gpart create -s BSD -n 20 ${NEW_UFS_SLICE} NEW_UFS_PARTITION=3D`gpart add -t freebsd-ufs -a 64k = ${NEW_UFS_SLICE} | sed -e 's/ .*//'` || exit 1 =20 NEW_UFS_DEVICE=3D/dev/${NEW_UFS_PARTITION} @@ -398,7 +398,7 @@ disk_ufs_create ( ) { # This makes reboots tolerable if you just pull power # Note: A slow SDHC reads about 1MB/s, so a 30MB # journal can delay boot by 30s. - tunefs -j enable -S 4194304 ${NEW_UFS_DEVICE} + #tunefs -j enable -S 4194304 ${NEW_UFS_DEVICE} # Turn on NFSv4 ACLs tunefs -N enable ${NEW_UFS_DEVICE} =20 As for "pulling power": the power switch shuts down like "shutdown -p now" so I just do not pull out the power cord. I either type the command or push the button. I'm not doing things for which those would be likely to fail or to be unavailable. [FYI: The index of recommendation articles is at: http://www.wonkity.com/~wblock/docs/ ] Note: After the initial boot via crochet I've used normal FreeBSD cross-build techniques to update instead of using crochet. (I did confirm the ability to buildworld buildkernel on the BPi-M3. That is part of how I judge "stable enough that I'll use it".) Note: It is not obvious from the various related FreeBSD web pages and the like but so far FreeBSD only uses 4 of the 8 cores in the A83T that the BPi-M3 has. =46rom what I've been told the "pmap" implementation would need a lot of work even though all the cores are of the same time. For one each cluster of 4 cores has a shared cache but there is no cache spanning both clusters. So context swapping the core in use has variable criteria depending on the from vs. to target (or a very sub-optimal implementation that gets less advantages from the cache sharing that is possible). Unless someone with a personal interest and the right background knowledge decides to do the work, it seems likely it will stay limited to 4 cores. Also some might take the point of view "do not bother unless you also handle the bigLITTLE combinations of cores of different types as well". That likely would make things much more complicated. Note: -n for "gpart create" is described as (in "man 8 gpart"): > -n entries The number of entries in the partition = table. > Every partitioning scheme has a minimum = and > maximum number of entries. This option = allows > tables to be created with a number of = entries > that is within the limits. Some = schemes have a > maximum equal to the minimum and some = schemes > have a maximum large enough to be = considered > unlimited. By default, partition = tables are > created with the minimum number of = entries. I did not find what the minimum was so I was explicit instead. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Nov 24 21:22: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 40345C54057 for ; Thu, 24 Nov 2016 21:22:02 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id ABF5E305 for ; Thu, 24 Nov 2016 21:22:01 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id d4d6c0c2; Thu, 24 Nov 2016 22:21:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=ks9/rAKEWfQ+T4vD1ev9qc/gfbM=; b=s6xHyBL41VxWctWv8/7jUe4UuSkS Sd6Joyg+3V0oQiQumvDSVs85rV65Kfyfr/DODG0e8KIAoZtyM3zYNx4xG7I3aDiE NeJZu5LzoeXUvB0+9Tnhnxacs4RT1BxqR7dzwxhFiPjiv21apddkpQOK5DeoA3qi C37Bfrto6XkUps4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=bI+grfXtTVgVkuq3px6rLKVOg8grAS5FBn+8TyIwGUByWXCs0Y3PntYT 1BNkHqwXl2KxAkA2qb2dKvJkkGN/MIO/JliMRFrwJ7hMYzmBPDFRdQA0qpYK4QiF JbnINix6jfUj/h8gzma6d3GPVZerZ0q0XjXoPsKgS2tOhJvUeT4= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 63cfeaa6 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Thu, 24 Nov 2016 22:21:52 +0100 (CET) Date: Thu, 24 Nov 2016 22:21:52 +0100 From: Emmanuel Vadot To: Michael Sperber Cc: freebsd-arm@freebsd.org Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 Message-Id: <20161124222152.dfd02dcafdc25182b6b46e50@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.29; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 21:22:02 -0000 On Thu, 24 Nov 2016 09:23:43 +0100 Michael Sperber wrote: > > I'm new to this list (and to FreeBSD on ARM), so forgive me if I'm > asking something trivial: > > I built a FreeBSD 11.0-RELEASE image for my BPI M3 using Crochet, by the > book as far as I can tell. The result doesn't boot, and I see no > external indication that anything is happening. (I.e. no LEDs blinking, > as they usually do when a working image boots up.) > > This thread: > > http://permalink.gmane.org/gmane.os.freebsd.devel.arm/14466 > > ... led me to believe uboot might currently be broken. Is that indeed > the case? Any instructions I could follow to get a working version. > > Any help would be much appreciated! > > -- > Regards, > Mike Hello, Do you have a serial cable attached ? We do not support HDMI output on this SoC right now so that just might be it. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Thu Nov 24 22:00: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 A8D1EC54BE4 for ; Thu, 24 Nov 2016 22:00:17 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-34.reflexion.net [208.70.210.34]) (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 5317A19BD for ; Thu, 24 Nov 2016 22:00:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 25023 invoked from network); 24 Nov 2016 22:00:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 24 Nov 2016 22:00:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Thu, 24 Nov 2016 17:00:00 -0500 (EST) Received: (qmail 24920 invoked from network); 24 Nov 2016 22:00:00 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 24 Nov 2016 22:00:00 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 89471EC907A; Thu, 24 Nov 2016 14:00:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 From: Mark Millard In-Reply-To: <20161124222152.dfd02dcafdc25182b6b46e50@bidouilliste.com> Date: Thu, 24 Nov 2016 14:00:13 -0800 Cc: freebsd-arm Content-Transfer-Encoding: 7bit Message-Id: <66508AA3-436A-4D9E-AAB5-B85D0B4FC40C@dsl-only.net> References: <20161124222152.dfd02dcafdc25182b6b46e50@bidouilliste.com> To: Michael Sperber X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2016 22:00:17 -0000 On 2016-Nov-24, at 1:21 PM, Emmanuel Vadot wrote: > On Thu, 24 Nov 2016 09:23:43 +0100 > Michael Sperber wrote: > >> >> I'm new to this list (and to FreeBSD on ARM), so forgive me if I'm >> asking something trivial: >> >> I built a FreeBSD 11.0-RELEASE image for my BPI M3 using Crochet, by the >> book as far as I can tell. The result doesn't boot, and I see no >> external indication that anything is happening. (I.e. no LEDs blinking, >> as they usually do when a working image boots up.) As for LED's: the BPi-M3 that I have access to is up running a FreeBSD stable/11 vintage and the red LED stays on instead of blinking. >> This thread: >> >> http://permalink.gmane.org/gmane.os.freebsd.devel.arm/14466 >> >> ... led me to believe uboot might currently be broken. Is that indeed >> the case? Any instructions I could follow to get a working version. >> >> Any help would be much appreciated! >> >> -- >> Regards, >> Mike > > Hello, > > Do you have a serial cable attached ? We do not support HDMI output on > this SoC right now so that just might be it. > > -- > Emmanuel Vadot Good point. In my reply I should have pointed him at the "Supported devices" table on: https://wiki.freebsd.org/FreeBSD/arm/Allwinner and its A83T column. The content may at times reflect head instead of stable/11 in some respects but what it indicates as not working in head would also generally not work in stable/11 or release/11.0.? or releng/11.0 . Listed as "not supported": Audio (analog) Audio (HDMI) Framebuffer HDMI video and that implicitly means serial cable use --or ssh use. (I do both.) I'll note that cpufreq and powerd do not yet work together despite what might expect from the table. If I understand right that is true of head for the BPi-M3, not just stable/11 and other 11 variants. (It likely will get to the point of being MFC'd later sometime.) There is no mention of it on this or any other page that I've found but only 4 of the 8 cores for an A83T are supported: the others go unused. (Also noted in my prior message.) One oddity of tracking functionality is that head now has, for example, both ALLWINNER and GENERIC but stable/11 and other 11's do not have GENERIC. It might be that at times ALLWINNER and GENERIC are not super/subsets of each other but that both omit something that the other has that could apply to the BPi-M3. Some material is being MFC'd to stable/11 but there might be some things that are not to be MFC'd. I do not know if GENERIC will ever move to stable/11. Fixing one bad typo in my prior message: > all the cores are of the same time should have been: all the cores are of the same type === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Nov 25 03:26: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 0136DC4DAAF for ; Fri, 25 Nov 2016 03:26:32 +0000 (UTC) (envelope-from Olivier.Nicole@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) (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 A9518869 for ; Fri, 25 Nov 2016 03:26:31 +0000 (UTC) (envelope-from Olivier.Nicole@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (localhost [127.0.0.1]) by mail.cs.ait.ac.th (Postfix) with ESMTP id 8AAC9D7884 for ; Fri, 25 Nov 2016 10:26:22 +0700 (ICT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.ait.ac.th; h= content-type:content-type:mime-version:message-id:date:date :subject:subject:from:from:received:received:received; s= selector1; t=1480044381; x=1481858782; bh=eqyxClDDhLRdsfDaG+61gJ 8G2eQOS7iT2EmVQgmr7Z0=; b=WqwLWpFPGUIg4Zu7ZNKpEvINIeQbKsWi2GVXui 8X0Qw5liXrIT5x6vFXHzmiKPpMjhCDyTv08n2Oj06eCCfTsIJUTvg8T9eYAjfUP3 ubmCw4R1bptG7tNNaMlcrxhkvIXaP5Uu+21r/1RmlU9Ad4r2RdbmXmbqTa1ilFJG LquNc= X-Virus-Scanned: amavisd-new at cs.ait.ac.th Received: from mail.cs.ait.ac.th ([127.0.0.1]) by mail.cs.ait.ac.th (mail.cs.ait.ac.th [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id PvkQxetTSb0F for ; Fri, 25 Nov 2016 10:26:21 +0700 (ICT) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.cs.ait.ac.th (Postfix) with ESMTPS id 6E48BD7882 for ; Fri, 25 Nov 2016 10:26:21 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.15.2/8.15.2/Submit) id uAP3QKZE029714; Fri, 25 Nov 2016 10:26:20 +0700 (ICT) (envelope-from on@banyan.cs.ait.ac.th) From: Olivier To: freebsd-arm@freebsd.org Subject: Raspberry Pi advice Date: Fri, 25 Nov 2016 10:26:20 +0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 03:26:32 -0000 Hi, I am not sure I am on the right list, if not, please help and point me to the correct one. Many years ago, I wrote an application that tale two mouse buttons as input and uses a relay card, interfaced to the printer port, as output. It become more and more difficult to find motherboard with printer port, plus some changes on the way the OS is treating the mouse, makes me consider moving to Raspberry Pi. My questions are the following: - which version buying? 2B or 3B? - how GPIO does GPIO work? I need one input to generate interupts and the other one to generate interupts but that I can also be able to pull the value when there has been no interrupt. Is that possible? - would it be possible to use the GPIO to generate a signal to sound like a siren? Best regards and thanks for the help, Olivier -- From owner-freebsd-arm@freebsd.org Fri Nov 25 08:28:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8795CC522EB for ; Fri, 25 Nov 2016 08:28:52 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from deinprogramm.de (deinprogramm.de [88.198.58.179]) by mx1.freebsd.org (Postfix) with ESMTP id 4F800B87 for ; Fri, 25 Nov 2016 08:28:51 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from jellaby.local (p4FD1D170.dip0.t-ipconnect.de [79.209.209.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deinprogramm.de (Postfix) with ESMTPSA id ED4643028B for ; Fri, 25 Nov 2016 08:28:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=deinprogramm.de; s=default; t=1480062524; bh=Kb1KYOcP2DxrUhcy4jW0r4mS5+6lk0lTpD2q9LDMpso=; h=From:To:Subject:References:Date:In-Reply-To; b=XgQ7hFbAQeBmBbsJsG0ZcVjiqgEiZDUzCefCbI8GdU0rqDJ+vI7xlbVczX5wMGbQ7 GfVfex/4UVkklo1XJ46lNgSI8TleF6nuYB/ADwIwEh/utqJlojIk0kfzvcQ4Zf3QHW B27zRRTGZujSD74qNopphEbWjJGYk/kiHY4BjrMY= Received: from jellaby.local.deinprogramm.de (localhost [IPv6:::1]) by jellaby.local (Postfix) with ESMTP id 339A492E0B84 for ; Fri, 25 Nov 2016 09:28:44 +0100 (CET) From: Michael Sperber To: freebsd-arm@freebsd.org Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 References: Date: Fri, 25 Nov 2016 09:28:44 +0100 In-Reply-To: (Mark Millard's message of "Thu, 24 Nov 2016 13:17:01 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 08:28:52 -0000 Thanks for all the info - very useful! I was hoping that I could get by without hooking up serial equipment, but the Ethernet port never comes up. Now, just to make sure I get this right - hooking up a serial port in the FreeBSD notes means using a USB/serial interface on the BPI, right? (Rather than expecting serial on some of the BPI's I/O pins.) -- Regards, Mike From owner-freebsd-arm@freebsd.org Fri Nov 25 08:47: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 E2C3CC5296A for ; Fri, 25 Nov 2016 08:47:47 +0000 (UTC) (envelope-from hf@dropcut.net) Received: from dropcut.net (dropcut.net [78.46.130.151]) (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 B2A2BA0E for ; Fri, 25 Nov 2016 08:47:47 +0000 (UTC) (envelope-from hf@dropcut.net) Received: by dropcut.net (Postfix, from userid 1001) id 8367F5080C81; Fri, 25 Nov 2016 09:39:03 +0100 (CET) Date: Fri, 25 Nov 2016 09:39:03 +0100 From: c279@dropcut.net To: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi advice Message-ID: <20161125083903.GA25648@dropcut.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 08:47:48 -0000 Hi Oliver, On Fri, Nov 25, 2016 at 10:26:20AM +0700, Olivier wrote: > I am not sure I am on the right list, if not, please help and point me > to the correct one. This mailing list is primarily for individuals working to port FreeBSD to new ARM-based systems and improve existing support. General resources for the Raspberry Pi might be: * https://www.raspberrypi.org/resources/ * https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/robot/buttons_and_switches/ * https://learn.adafruit.com/category/raspberry-pi > ... > My questions are the following: > - which version buying? 2B or 3B? The Raspberry Pi 2 has the best support[0] as of today. You can roll your own image for the Raspberry Pi 3[1] if you need to. I personally would choose an RPi2 for FreeBSD at this point. > - how GPIO does GPIO work? I need one input to generate interupts and > the other one to generate interupts but that I can also be able to > pull the value when there has been no interrupt. Is that possible? Yes. Here[2] is an example in C and in Python[3]. > - would it be possible to use the GPIO to generate a signal to sound > like a siren? Yes, but you can also attach speakers to the 3.5mm jack. This might be easier than fiddeling with GPIO fpr this purpose. > Best regards and thanks for the help, You're welcome, -hf [0] https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi [1] https://github.com/zxombie/freebsd/tree/arm64-rpi3 [2] https://vzaigrin.wordpress.com/2014/04/18/working-with-gpio-on-raspberry-pi-with-freebsd/ [3] https://vzaigrin.wordpress.com/2015/02/02/web-control-of-raspberry-pi-gpio-in-freebsd/comment-page-1/ From owner-freebsd-arm@freebsd.org Fri Nov 25 09:13:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D68AAC5356A for ; Fri, 25 Nov 2016 09:13:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-35.reflexion.net [208.70.210.35]) (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 8A635CB8 for ; Fri, 25 Nov 2016 09:13:58 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13985 invoked from network); 25 Nov 2016 09:13:37 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 25 Nov 2016 09:13:37 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 25 Nov 2016 04:14:03 -0500 (EST) Received: (qmail 3687 invoked from network); 25 Nov 2016 09:14:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Nov 2016 09:14:02 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id ABF5FEC9024; Fri, 25 Nov 2016 01:13:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Raspberry Pi advice [RPI2B V1.2 is not ARMv7A but Cortex-A53, I'm afraid; slower than RPI3B, no WiFi/Bluetooth] From: Mark Millard In-Reply-To: <20161125083903.GA25648@dropcut.net> Date: Fri, 25 Nov 2016 01:13:51 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0292B13C-7E72-49F0-AC24-FC0B5496E7DC@dsl-only.net> References: <20161125083903.GA25648@dropcut.net> To: c279@dropcut.net, Olivier X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 09:13:59 -0000 On 2016-Nov-25, at 12:39 AM, c279 at dropcut.net wrote: > Hi Oliver, >=20 > On Fri, Nov 25, 2016 at 10:26:20AM +0700, Olivier wrote: >> I am not sure I am on the right list, if not, please help and point = me >> to the correct one. > This mailing list is primarily for individuals working to port FreeBSD > to new ARM-based systems and improve existing support. > General resources for the Raspberry Pi might be: > * https://www.raspberrypi.org/resources/ > * = https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/robot/buttons_and_= switches/ > * https://learn.adafruit.com/category/raspberry-pi >=20 >> ...=20 >> My questions are the following: >> - which version buying? 2B or 3B? > The Raspberry Pi 2 has the best support[0] as of today. You can roll > your own image for the Raspberry Pi 3[1] if you need to. I personally > would choose an RPi2 for FreeBSD at this point. RPI2B V1.1 and before I think that is. The information I've found on ordering a RPI2B V1.2 indicates is is now also a (slower) 64-bit arm (Cortex-A53 quad core in a BCM2837), like the RPI3B. For example: = https://www.raspberrypi.org/forums/viewtopic.php?f=3D63&t=3D163856 (=46rom= Oct.) And: = https://www.element14.com/community/community/raspberry-pi/raspberrypi2 And: = http://www.cnx-software.com/2016/11/21/raspberry-pi-2-gets-an-upgrade-to-6= 4-bit-broadcom-bcm2837-processor-with-pcb-version-1-2/ (You can find more.) "Previous versions of Raspberry Pi 2 Model B use the BCM2836 SoC, which contains a quad-core ARM Cortex-A7 processor. The Raspberry Pi 2 Model B v1.2 board uses BCM2837, which contains a quad-core ARM Cortex-A53 = processor." (This is from the element14 page.) RPI2B V1.1 is out of production from what I can tell, although one might still be able to find one. It gets harder to find one over time. RPI2B V1.2 does not have WiFi/Bluetooth built in. It is too bad that they did not at least name it Raspberry Pi 2C. >> - how GPIO does GPIO work? I need one input to generate interupts and >> the other one to generate interupts but that I can also be able to >> pull the value when there has been no interrupt. Is that possible? > Yes. Here[2] is an example in C and in Python[3]. >=20 >> - would it be possible to use the GPIO to generate a signal to sound >> like a siren? > Yes, but you can also attach speakers to the 3.5mm jack. This might be > easier than fiddeling with GPIO fpr this purpose. >=20 >=20 >> Best regards and thanks for the help, > You're welcome, >=20 > -hf >=20 >=20 >=20 > [0] https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi > [1] https://github.com/zxombie/freebsd/tree/arm64-rpi3 > [2] = https://vzaigrin.wordpress.com/2014/04/18/working-with-gpio-on-raspberry-p= i-with-freebsd/ > [3] = https://vzaigrin.wordpress.com/2015/02/02/web-control-of-raspberry-pi-gpio= -in-freebsd/comment-page-1/ =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Nov 25 09:26: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 ED3B1C53A3B for ; Fri, 25 Nov 2016 09:26:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-30.reflexion.net [208.70.210.30]) (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 8854E16F4 for ; Fri, 25 Nov 2016 09:26:27 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 8199 invoked from network); 25 Nov 2016 09:26:24 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 25 Nov 2016 09:26:24 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 25 Nov 2016 04:26:06 -0500 (EST) Received: (qmail 30891 invoked from network); 25 Nov 2016 09:26:06 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Nov 2016 09:26:06 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4937DEC90D2; Fri, 25 Nov 2016 01:26:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 From: Mark Millard In-Reply-To: Date: Fri, 25 Nov 2016 01:26:19 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <2FDCF73E-4E05-47D2-A8D4-7C48D86BACC7@dsl-only.net> References: To: Michael Sperber X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 09:26:29 -0000 On 2016-Nov-25, at 12:28 AM, Michael Sperber wrote: > Thanks for all the info - very useful! > > I was hoping that I could get by without hooking up serial equipment, > but the Ethernet port never comes up. Does the Ethernet port have a light turned on when it is connected and has had a chance to boot? If it does then the boot got far enough to do that much. > Now, just to make sure I get this right - hooking up a serial port in > the FreeBSD notes means using a USB/serial interface on the BPI, right? > (Rather than expecting serial on some of the BPI's I/O pins.) There are 3 separate pins next to the Ethernet port that have the kernel messages and such and allow a login after booting. Unlike a RPI2B running FreeBSD stable/11 I've had problems with dropped text when connected to the BPi-M3. (Same cable connected to the same old Mac laptop [via USB] running the same software.) > -- > Regards, > Mike === Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Nov 25 10:03:30 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E7A8C543CD for ; Fri, 25 Nov 2016 10:03:30 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from deinprogramm.de (deinprogramm.de [88.198.58.179]) by mx1.freebsd.org (Postfix) with ESMTP id DA38DCF7 for ; Fri, 25 Nov 2016 10:03:29 +0000 (UTC) (envelope-from sperber@deinprogramm.de) Received: from jellaby.local (p4FD1D170.dip0.t-ipconnect.de [79.209.209.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deinprogramm.de (Postfix) with ESMTPSA id CAA7E305B4; Fri, 25 Nov 2016 10:03:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=deinprogramm.de; s=default; t=1480068206; bh=S8xNjcIcIYiykNNZ/AFiIOQtYcg1LLbZ9296QRuFMxc=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=tQXXMEIemEjwf/81qFvFjGD0aZmGNIfEFhFmdKPhVMbQ1vh15tni8NxBUmodYC3Ec yLJ6arS4ZX0wo3ZvMHwkfPaN1sXqbqQUmEIvRfPa30MEonrCBYEVLf3JVFSFYKJfbw Oe4/25RCmvK9Ua5ybv9SF8jNjPezZR3bWMJ1GKSA= Received: from jellaby.local.deinprogramm.de (localhost [IPv6:::1]) by jellaby.local (Postfix) with ESMTP id 6023892EC828; Fri, 25 Nov 2016 11:03:27 +0100 (CET) From: Michael Sperber To: Mark Millard Cc: freebsd-arm@freebsd.org Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 References: <2FDCF73E-4E05-47D2-A8D4-7C48D86BACC7@dsl-only.net> Date: Fri, 25 Nov 2016 11:03:27 +0100 In-Reply-To: <2FDCF73E-4E05-47D2-A8D4-7C48D86BACC7@dsl-only.net> (Mark Millard's message of "Fri, 25 Nov 2016 01:26:19 -0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (darwin) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 10:03:30 -0000 Mark Millard writes: > Does the Ethernet port have a light turned on when it is connected > and has had a chance to boot? If it does then the boot got far > enough to do that much. No. (And the router it's plugged into also doesn't light up.) >> Now, just to make sure I get this right - hooking up a serial port in >> the FreeBSD notes means using a USB/serial interface on the BPI, right? >> (Rather than expecting serial on some of the BPI's I/O pins.) > > There are 3 separate pins next to the Ethernet port that have the > kernel messages and such and allow a login after booting. Ah, thanks ... but that's not standard RS232, right? (BPI homepages says "TTL".) If it isn't, what kind of hardware connects to that? -- Regards, Mike From owner-freebsd-arm@freebsd.org Fri Nov 25 10:58: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 4674DC532E1 for ; Fri, 25 Nov 2016 10:58:01 +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 9A35FD81 for ; Fri, 25 Nov 2016 10:58:00 +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 8F15A406061; Fri, 25 Nov 2016 02:57:51 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Michael Sperber cc: freebsd-arm@freebsd.org, hmurray@megapathdsl.net From: Hal Murray Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 In-Reply-To: Message from Michael Sperber of "Fri, 25 Nov 2016 11:03:27 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Nov 2016 02:57:51 -0800 Message-Id: <20161125105751.8F15A406061@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 10:58:01 -0000 sperber@deinprogramm.de said: > Ah, thanks ... but that's not standard RS232, right? (BPI homepages says > "TTL".) If it isn't, what kind of hardware connects to that? The normal setup for RS232 is that the transmit and receive signals come out of a big chip (SOC, or PCI UART, or USB UART, or ...) and then go through a level converter which is typically a MAX-232 or one of many clones or variants. The "TTL" is telling you that it doesn't have that level converter chip. You can either add a level converter chip and then plug it into a real RS-232 port, or find some setup that also doesn't have the level converter and speaks TTL levels. Adafruit and probably many others sell a USB UART without the level converter for applications like this. https://www.adafruit.com/product/954 Sometimes, TTL means 3V CMOS levels and 5V from real TTL/CMOS will fry your expensive chip. Best to check carefully. The above part says 3V. It also has an extra power wire that you get to ignore. -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Fri Nov 25 14: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 AC9DFC545BF for ; Fri, 25 Nov 2016 14:07:34 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-29.reflexion.net [208.70.210.29]) (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 5B2F0A86 for ; Fri, 25 Nov 2016 14:07:33 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24269 invoked from network); 25 Nov 2016 14:07:12 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 25 Nov 2016 14:07:12 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.20.0) with SMTP; Fri, 25 Nov 2016 09:07:33 -0500 (EST) Received: (qmail 24881 invoked from network); 25 Nov 2016 14:07:33 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Nov 2016 14:07:33 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 56FA5EC907A; Fri, 25 Nov 2016 06:07:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 From: Mark Millard In-Reply-To: <20161125105751.8F15A406061@ip-64-139-1-69.sjc.megapath.net> Date: Fri, 25 Nov 2016 06:07:25 -0800 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <9211EF99-1E69-4BC0-91CC-DF6604FE8655@dsl-only.net> References: <20161125105751.8F15A406061@ip-64-139-1-69.sjc.megapath.net> To: Michael Sperber X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 14:07:34 -0000 On 2016-Nov-25, at 2:57 AM, Hal Murray = wrote: > sperber at deinprogramm.de said: >> Ah, thanks ... but that's not standard RS232, right? (BPI homepages = says >> "TTL".) If it isn't, what kind of hardware connects to that?=20 >=20 > The normal setup for RS232 is that the transmit and receive signals = come out=20 > of a big chip (SOC, or PCI UART, or USB UART, or ...) and then go = through a=20 > level converter which is typically a MAX-232 or one of many clones or=20= > variants. The "TTL" is telling you that it doesn't have that level = converter=20 > chip. >=20 > You can either add a level converter chip and then plug it into a real = RS-232=20 > port, or find some setup that also doesn't have the level converter = and=20 > speaks TTL levels. Adafruit and probably many others sell a USB UART = without=20 > the level converter for applications like this. > https://www.adafruit.com/product/954 I use one of those from adafruit for a BPi-M3, a RPI2B V1.1, or a = Pine64. > Sometimes, TTL means 3V CMOS levels and 5V from real TTL/CMOS will fry = your=20 > expensive chip. Best to check carefully. The above part says 3V. It = also=20 > has an extra power wire that you get to ignore. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Nov 25 15:33:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7820BC54E3F for ; Fri, 25 Nov 2016 15:33:05 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout09.t-online.de (mailout09.t-online.de [194.25.134.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BF2788F for ; Fri, 25 Nov 2016 15:33:04 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd21.aul.t-online.de (fwd21.aul.t-online.de [172.20.27.66]) by mailout09.t-online.de (Postfix) with SMTP id 45FDF42336A8 for ; Fri, 25 Nov 2016 16:24:59 +0100 (CET) Received: from [192.168.10.43] (rw8sWeZ1ohvP6jVLLEfHPSmeoCuALmMLQe4-axbMJmuzXWobnCh1DEGKdq1CwG5wnk@[86.56.56.128]) by fwd21.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAIMz-00QOh60; Fri, 25 Nov 2016 16:24:57 +0100 Subject: Re: How to change MAC address on RPI-B? References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> To: freebsd-arm@freebsd.org From: diffusae Message-ID: <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> Date: Fri, 25 Nov 2016 16:24:56 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: rw8sWeZ1ohvP6jVLLEfHPSmeoCuALmMLQe4-axbMJmuzXWobnCh1DEGKdq1CwG5wnk X-TOI-MSGID: 2fee28c9-5ad8-494d-9ea1-f81ac7157700 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 15:33:05 -0000 Hi John, yes it is possible to set the MAC address at boot with the last patch from HPS. You only need to change driver and kernel, than it works. I've tried to set it in uEnv.txt: This sets the MAC address before the FreeBSD kernel boots. You can change it with U-Boot, but after running the kernel it's always the same MAC address of the device. Also with a change in the RPI FDT file it wasn't possible. Regards, On 23.11.2016 22:16, John W. Kitz wrote: > Reiner, > > I'm curious if you needed a driver change to be able to set a locally > administered mac address, does that mean it's impossible for you to set it > through uEnv.txt? > > Jk. > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Nov 25 16:31: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 07BD8C55488 for ; Fri, 25 Nov 2016 16:31:16 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A829DE1E for ; Fri, 25 Nov 2016 16:31:14 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd27.aul.t-online.de (fwd27.aul.t-online.de [172.20.26.132]) by mailout12.t-online.de (Postfix) with SMTP id 6B9FD41FCF69 for ; Fri, 25 Nov 2016 17:31:12 +0100 (CET) Received: from [192.168.10.43] (XjAm6kZ-Yh--TQGIiuH8gqpdwr2JUap3K6I2KPrLCJFGJN9-3QArmlfjAwKuc95QNs@[86.56.56.128]) by fwd27.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAJP2-0bGfy40; Fri, 25 Nov 2016 17:31:08 +0100 Subject: Re: Rapsberry pi B & VirtualBox crosscompile References: To: freebsd-arm@freebsd.org From: diffusae Message-ID: <8f1fee66-7521-1053-0cac-5a3c70a2c9ec@t-online.de> Date: Fri, 25 Nov 2016 17:31:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: XjAm6kZ-Yh--TQGIiuH8gqpdwr2JUap3K6I2KPrLCJFGJN9-3QArmlfjAwKuc95QNs X-TOI-MSGID: d502b3f1-ded0-4eeb-a8be-3d959472bfcb X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:31:16 -0000 Hi! I've tried to build a local pkg repository with poudriere and qemu-arm-static on amd64 for armv6 32bit (RPI-B). I am using FreeBSD 11.0-STABLE on both architectures. The build system runs in a VirtualBox environment. For the most packages it works well and with the native-xtools it's also quite fast. But there are some package which won't be build anyway. Unfortunately with package dependencies I like to build. For now, I've recognized it for the following packages: m4, ruby22 and gcc, which has a memory exhausted error, the other packages hang on configure (qemu-arm-static conftest) on different checks: lang/gcc (process:87381): GLib-ERROR (recursed) **: gmem.c:166: failed to allocate 32 bytes{standard input}: Assembler messages: This looks like a problem to build 32bit binaries on 64bit architecture, but I am not sure. devel/m4 checking for working C stack overflow detection... yes lang/ruby22 checking for broken backtrace... make: Working in: /usr/ports/lang/ruby22 I can manually skip the the tests, if I modify the configure script and the packages will be build. Also, if use gcc to compile ruby22 (USE_GCC?= yes) the package will be build. But I don't know how set a variable in make.conf or Makefile to disable the specific configure checks, so poudriere will run automatically with it. I am not sure, if my setup is correct. Thanks a lot Regards, On 15.11.2016 03:39, Mark Millard wrote: > > On 2016-Nov-14, at 5:19 PM, peter garshtja wrote: > >> Hi Krzysztof, >> >> If you want to build packages for your arm system on x86 arch then check it >> here https://github.com/PetruGarstea/FreePI/wiki/Building-FreePI-packages >> >> However freebsd 11 unofficial supports arm pkg repository. >> >> Regards, >> Peter >> >> On Nov 14, 2016 19:25, "Krzysztof Kowalski" wrote: >> >>> Hello there, >>> In few days I will get my 'brand new' RPi B. I would like to have on it >>> FreeBSD 10.3-RELEASE and build ports on it. But as we know, it has low >>> processor power so best way to bulid packages is to use distcc. >>> My question is; >>> Will it works, if I'll use FreeBSD 10.3-RELEASE x84_64, started in >>> VirtualBox with few CPU, to distcc with RPi? I mention that RPi & VB will >>> be connected by crossover ethernet (no switch and only WiFi router at the >>> house where I'll configure RPi). >>> Thanks in advance, best regards, >>> Krzysztof > > One gotcha to using the pkg repository for those that buildworld themselves with > options like -mcpu= (such as -mcpu=corex-a7 for an RPI2B <= V1.1) is that the > software support for instructions that are missing in armv6 but present on the > specific processor/architecture are not always put in place by buildworld. > > This leads to some pure armv6 software (such as from the pkg repository) failing > for lack of routines in the more specialized buildworld context: Undefined symbols > that a just-armv6 buildworld would define. > > If the policy were for buildworld to build the routines despite instructions being > available for the -mcpu= or other more specific context specified for buildworld > then more pkg's from the repository might work for the more targeted buildworld's. > > As I remember pkg itself can have this issue for -mcpu= and the like. But in that > case pkg-static should work fine because it does not depend on the buildworld > libraries for such routines: they are already built in. > > Overall this is somewhat related to the likes of lang/gcc6 based compiles targeting > just armv6 needing -rpath use to avoid failing for things that are "internal > support" (even for arithmetic), like: > > /usr/local/lib/gcc6/libstdc++.so.6: Undefined symbol "__aeabi_uldivmod" > > where /lib/libgcc_s.so.1 does not implement the routine (depending on how buildworld > was done?) but /usr/local/lib/gcc6/libgcc_s.so.1 does implement. > > === > Mark Millard > markmi at dsl-only.net > > _______________________________________________ > 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 Fri Nov 25 16:42: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 ED621C557B6 for ; Fri, 25 Nov 2016 16:42:51 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 AB96F900 for ; Fri, 25 Nov 2016 16:42:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id uAPGgUoR022075; Fri, 25 Nov 2016 08:42:36 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id uAPGgJmX022074; Fri, 25 Nov 2016 08:42:19 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201611251642.uAPGgJmX022074@pdx.rh.CN85.dnsmgr.net> Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 In-Reply-To: <20161125105751.8F15A406061@ip-64-139-1-69.sjc.megapath.net> To: Hal Murray Date: Fri, 25 Nov 2016 08:42:19 -0800 (PST) CC: Michael Sperber , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:42:52 -0000 > > sperber@deinprogramm.de said: > > Ah, thanks ... but that's not standard RS232, right? (BPI homepages says > > "TTL".) If it isn't, what kind of hardware connects to that? > > The normal setup for RS232 is that the transmit and receive signals come out > of a big chip (SOC, or PCI UART, or USB UART, or ...) and then go through a > level converter which is typically a MAX-232 or one of many clones or > variants. The "TTL" is telling you that it doesn't have that level converter > chip. > > You can either add a level converter chip and then plug it into a real RS-232 > port, or find some setup that also doesn't have the level converter and > speaks TTL levels. Adafruit and probably many others sell a USB UART without > the level converter for applications like this. > https://www.adafruit.com/product/954 > > Sometimes, TTL means 3V CMOS levels and 5V from real TTL/CMOS will fry your > expensive chip. Best to check carefully. The above part says 3V. It also > has an extra power wire that you get to ignore. Be SURE to ignore that extra power wire! If your USB/Serial adapter also has a power wire DO NOT CONNECT IT. Many of these embeded boards provide a power pin with the serial interface that can be used to power something external, like a level shifter, and many of the USB/Serial adapters also bring out the USB 5V rail on a wire. DO NOT CONNECT THE TWO! That being said, there are many aftermarket USB/Serial cables avaliable, usually a 3.3V version of these well work everywhere as long as it has 5V tolerent inputs, which most of the newer ones do, check the specs from the vendor. 3.3V outputs well satisfy the input requirements of a 5V TTL/CMOS circuit and not cause it problems, the opposite is not always true. Watch your lead length and wire sizes if you need to do anything funny to get this connected, capacitive loading of any kind on this type of signal can cause character loss, especially at speeds above 9600 baud. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Nov 25 16:50: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 610F7C55920 for ; Fri, 25 Nov 2016 16:50:33 +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 45B8AAFE for ; Fri, 25 Nov 2016 16:50:33 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 15923a74-b32f-11e6-a7af-b587c64a4c62 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 15923a74-b32f-11e6-a7af-b587c64a4c62; Fri, 25 Nov 2016 16:49:09 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAPGnO5K008960; Fri, 25 Nov 2016 09:49:24 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1480092564.1889.70.camel@freebsd.org> Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 From: Ian Lepore To: "Rodney W. Grimes" , Hal Murray Cc: freebsd-arm@freebsd.org, Michael Sperber Date: Fri, 25 Nov 2016 09:49:24 -0700 In-Reply-To: <201611251642.uAPGgJmX022074@pdx.rh.CN85.dnsmgr.net> References: <201611251642.uAPGgJmX022074@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 16:50:33 -0000 On Fri, 2016-11-25 at 08:42 -0800, Rodney W. Grimes wrote: > > > > > > sperber@deinprogramm.de said: > > > > > > Ah, thanks ... but that's not standard RS232, right?  (BPI > > > homepages says > > > "TTL".)  If it isn't, what kind of hardware connects to that?  > > The normal setup for RS232 is that the transmit and receive signals > > come out  > > of a big chip (SOC, or PCI UART, or USB UART, or ...) and then go > > through a  > > level converter which is typically a MAX-232 or one of many clones > > or  > > variants.  The "TTL" is telling you that it doesn't have that level > > converter  > > chip. > > > > You can either add a level converter chip and then plug it into a > > real RS-232  > > port, or find some setup that also doesn't have the level converter > > and  > > speaks TTL levels.  Adafruit and probably many others sell a USB > > UART without  > > the level converter for applications like this. > >   https://www.adafruit.com/product/954 > > > > Sometimes, TTL means 3V CMOS levels and 5V from real TTL/CMOS will > > fry your  > > expensive chip.  Best to check carefully.  The above part says > > 3V.  It also  > > has an extra power wire that you get to ignore. > Be SURE to ignore that extra power wire!  If your USB/Serial adapter > also has > a power wire DO NOT CONNECT IT.  Many of these embeded boards provide > a power > pin with the serial interface that can be used to power something > external, > like a level shifter, and many of the USB/Serial adapters also bring > out the > USB 5V rail on a wire.  DO NOT CONNECT THE TWO!  > Ummm... say what? I power my rpi boards using the 5v power from the USB serial adapter connected to the 5v pin on the rpi header.  I can't imagine any reason not to. > That being said, there are many aftermarket USB/Serial cables > avaliable, > usually a 3.3V version of these well work everywhere as long as it > has > 5V tolerent inputs, which most of the newer ones do, check the specs > from the vendor.  3.3V outputs well satisfy the input requirements of > a 5V TTL/CMOS circuit and not cause it problems, the opposite is not > always true. > Usb serial adapter based on Prolific chipsets are NOT 5v tolerant.  Those based on FTDI chips are.  Those are the two big names in usb- serial chips, but there are others out there too; you have to check the datasheet to be sure. > Watch your lead length and wire sizes if you need to do anything > funny > to get this connected, capacitive loading of any kind on this type of > signal can cause character loss, especially at speeds above 9600 > baud. > Ummm... that sounds pretty bogus too, considering that I've run ftdi chips at 12mbps using breadboards with a rat's nest of wiring to carry the comms signals to other boards. -- Ian From owner-freebsd-arm@freebsd.org Fri Nov 25 17:07: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 7F14CC55E44 for ; Fri, 25 Nov 2016 17:07:43 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 47F263D8; Fri, 25 Nov 2016 17:07:43 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id uAPH7dAt022171; Fri, 25 Nov 2016 09:07:39 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id uAPH7Y4K022170; Fri, 25 Nov 2016 09:07:34 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201611251707.uAPH7Y4K022170@pdx.rh.CN85.dnsmgr.net> Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 In-Reply-To: <1480092564.1889.70.camel@freebsd.org> To: Ian Lepore Date: Fri, 25 Nov 2016 09:07:34 -0800 (PST) CC: Hal Murray , freebsd-arm@freebsd.org, Michael Sperber X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:07:43 -0000 [ Charset ISO-8859-1 unsupported, converting... ] > On Fri, 2016-11-25 at 08:42 -0800, Rodney W. Grimes wrote: > > > > > > > > > sperber@deinprogramm.de said: > > > > > > > > Ah, thanks ... but that's not standard RS232, right???(BPI > > > > homepages says > > > > "TTL".)??If it isn't, what kind of hardware connects to that?? > > > The normal setup for RS232 is that the transmit and receive signals > > > come out? > > > of a big chip (SOC, or PCI UART, or USB UART, or ...) and then go > > > through a? > > > level converter which is typically a MAX-232 or one of many clones > > > or? > > > variants.??The "TTL" is telling you that it doesn't have that level > > > converter? > > > chip. > > > > > > You can either add a level converter chip and then plug it into a > > > real RS-232? > > > port, or find some setup that also doesn't have the level converter > > > and? > > > speaks TTL levels.??Adafruit and probably many others sell a USB > > > UART without? > > > the level converter for applications like this. > > > ? https://www.adafruit.com/product/954 > > > > > > Sometimes, TTL means 3V CMOS levels and 5V from real TTL/CMOS will > > > fry your? > > > expensive chip.??Best to check carefully.??The above part says > > > 3V.??It also? > > > has an extra power wire that you get to ignore. > > Be SURE to ignore that extra power wire!??If your USB/Serial adapter > > also has > > a power wire DO NOT CONNECT IT.??Many of these embeded boards provide > > a power > > pin with the serial interface that can be used to power something > > external, > > like a level shifter, and many of the USB/Serial adapters also bring > > out the > > USB 5V rail on a wire.??DO NOT CONNECT THE TWO!? > > > > Ummm... say what? > > I power my rpi boards using the 5v power from the USB serial adapter > connected to the 5v pin on the rpi header. ?I can't imagine any reason > not to. You either have a USB port wiling to supply more than the 500mA from the standard, or are running your RPI under very light load. This is NOT the recomended path to power a RPI, and if the RPI is getting power from the micro usb port your connecting 2 power supplies in parallel, which is bad. If you plub a USB device into your RPI that draws significant current it well probably reboot due to power loss. For information on how much power your PI wants/needs: https://www.raspberrypi.org/help/faqs/#powerReqs > > > That being said, there are many aftermarket USB/Serial cables > > avaliable, > > usually a 3.3V version of these well work everywhere as long as it > > has > > 5V tolerent inputs, which most of the newer ones do, check the specs > > from the vendor.??3.3V outputs well satisfy the input requirements of > > a 5V TTL/CMOS circuit and not cause it problems, the opposite is not > > always true. > > > > Usb serial adapter based on Prolific chipsets are NOT 5v tolerant. > ?Those based on FTDI chips are. ?Those are the two big names in usb- > serial chips, but there are others out there too; you have to check the > datasheet to be sure. >From my read of the Prolific data sheet that is not clear, they specify 3.3v and 3.3v 5v tolerent, but then they do not clearly state which pins are 3.3v and which are 3.3v+5v tolerent. I'll take your word that they don't like 5V on the serial rx pin. > > Watch your lead length and wire sizes if you need to do anything > > funny > > to get this connected, capacitive loading of any kind on this type of > > signal can cause character loss, especially at speeds above 9600 > > baud. > > > > Ummm... that sounds pretty bogus too, considering that I've run ftdi > chips at 12mbps using breadboards with a rat's nest of wiring to carry > the comms signals to other boards. Iout of most of these chips is 4mA, you are welcome to do the RC calculations. You can often get away with amazingly poor setups, then suddenly get bitten by what looks to be just fine but drops characters. Full level RS-232 specifies cable length of 50ft at 19200, your not going to get away with that using CMOS 4mA drivers unless you have very low loss cable. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Nov 25 17:12: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 838A9C540EE for ; Fri, 25 Nov 2016 17:12:32 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 149A69C6 for ; Fri, 25 Nov 2016 17:12:31 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id uAPHCEYE012923 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Nov 2016 18:12:15 +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 uAPHCC6D068560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Nov 2016 18:12:12 +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 uAPHCBqF003732; Fri, 25 Nov 2016 18:12:11 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id uAPHC8Iw003731; Fri, 25 Nov 2016 18:12:08 +0100 (CET) (envelope-from ticso) Date: Fri, 25 Nov 2016 18:12:08 +0100 From: Bernd Walter To: Mark Millard Cc: c279@dropcut.net, Olivier , freebsd-arm@freebsd.org Subject: Re: Raspberry Pi advice [RPI2B V1.2 is not ARMv7A but Cortex-A53, I'm afraid; slower than RPI3B, no WiFi/Bluetooth] Message-ID: <20161125171208.GC291@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20161125083903.GA25648@dropcut.net> <0292B13C-7E72-49F0-AC24-FC0B5496E7DC@dsl-only.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0292B13C-7E72-49F0-AC24-FC0B5496E7DC@dsl-only.net> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507, URI_TRY_3LD=0.331 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:12:32 -0000 On Fri, Nov 25, 2016 at 01:13:51AM -0800, Mark Millard wrote: > On 2016-Nov-25, at 12:39 AM, c279 at dropcut.net wrote: > > > Hi Oliver, > > > > On Fri, Nov 25, 2016 at 10:26:20AM +0700, Olivier wrote: > >> I am not sure I am on the right list, if not, please help and point me > >> to the correct one. > > This mailing list is primarily for individuals working to port FreeBSD > > to new ARM-based systems and improve existing support. > > General resources for the Raspberry Pi might be: > > * https://www.raspberrypi.org/resources/ > > * https://www.cl.cam.ac.uk/projects/raspberrypi/tutorials/robot/buttons_and_switches/ > > * https://learn.adafruit.com/category/raspberry-pi > > > >> ... > >> My questions are the following: > >> - which version buying? 2B or 3B? > > The Raspberry Pi 2 has the best support[0] as of today. You can roll > > your own image for the Raspberry Pi 3[1] if you need to. I personally > > would choose an RPi2 for FreeBSD at this point. > > RPI2B V1.1 and before I think that is. The information I've found on > ordering a RPI2B V1.2 indicates is is now also a (slower) 64-bit arm > (Cortex-A53 quad core in a BCM2837), like the RPI3B. Slower than the same BCM2837 on the Pi3, but I don't think it is slower compared to the older Pi2 models. > For example: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=163856 (From Oct.) > And: https://www.element14.com/community/community/raspberry-pi/raspberrypi2 > And: http://www.cnx-software.com/2016/11/21/raspberry-pi-2-gets-an-upgrade-to-64-bit-broadcom-bcm2837-processor-with-pcb-version-1-2/ > (You can find more.) > > "Previous versions of Raspberry Pi 2 Model B use the BCM2836 SoC, which > contains a quad-core ARM Cortex-A7 processor. The Raspberry Pi 2 Model B > v1.2 board uses BCM2837, which contains a quad-core ARM Cortex-A53 processor." > (This is from the element14 page.) > > RPI2B V1.1 is out of production from what I can tell, although one might > still be able to find one. It gets harder to find one over time. > > RPI2B V1.2 does not have WiFi/Bluetooth built in. > > It is too bad that they did not at least name it Raspberry Pi 2C. >From the pricepoint the new Pi2 Rev 1.2 is the same as the Pi3, but at lower CPU clock and without the WiFi/BT. I don't see any good reasons to buy a Pi2 anymore, unless for some regularoty reasons you can't have a WiFi/BT chip mounted or need the old LED location. Well - and curiosity, that's why I bought one of the Rev 1.2 myself. In direct comparison the Pi2B Rev 1.1 and Rev 1.2 look the same. The only difference is the revsion on the silk screen and the BCM chip. > > > >> - how GPIO does GPIO work? I need one input to generate interupts and > >> the other one to generate interupts but that I can also be able to > >> pull the value when there has been no interrupt. Is that possible? > > Yes. Here[2] is an example in C and in Python[3]. > > > >> - would it be possible to use the GPIO to generate a signal to sound > >> like a siren? > > Yes, but you can also attach speakers to the 3.5mm jack. This might be > > easier than fiddeling with GPIO fpr this purpose. > > > > > >> Best regards and thanks for the help, > > You're welcome, > > > > -hf > > > > > > > > [0] https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi > > [1] https://github.com/zxombie/freebsd/tree/arm64-rpi3 > > [2] https://vzaigrin.wordpress.com/2014/04/18/working-with-gpio-on-raspberry-pi-with-freebsd/ > > [3] https://vzaigrin.wordpress.com/2015/02/02/web-control-of-raspberry-pi-gpio-in-freebsd/comment-page-1/ > > > === > Mark Millard > markmi at dsl-only.net > > > _______________________________________________ > 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" -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Nov 25 17:17: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 21552C5429E for ; Fri, 25 Nov 2016 17:17:36 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AA4C7B4E for ; Fri, 25 Nov 2016 17:17:35 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id uAPHHVGx013010 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 25 Nov 2016 18:17:31 +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 uAPHHTxx068619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Nov 2016 18:17:29 +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 uAPHHS9S003743; Fri, 25 Nov 2016 18:17:28 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id uAPHHS8h003742; Fri, 25 Nov 2016 18:17:28 +0100 (CET) (envelope-from ticso) Date: Fri, 25 Nov 2016 18:17:28 +0100 From: Bernd Walter To: Michael Sperber Cc: Mark Millard , freebsd-arm@freebsd.org Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 Message-ID: <20161125171728.GD291@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <2FDCF73E-4E05-47D2-A8D4-7C48D86BACC7@dsl-only.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, RP_MATCHES_RCVD=-1.507 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:17:36 -0000 On Fri, Nov 25, 2016 at 11:03:27AM +0100, Michael Sperber wrote: > > Mark Millard writes: > > > Does the Ethernet port have a light turned on when it is connected > > and has had a chance to boot? If it does then the boot got far > > enough to do that much. > > No. (And the router it's plugged into also doesn't light up.) > > >> Now, just to make sure I get this right - hooking up a serial port in > >> the FreeBSD notes means using a USB/serial interface on the BPI, right? > >> (Rather than expecting serial on some of the BPI's I/O pins.) > > > > There are 3 separate pins next to the Ethernet port that have the > > kernel messages and such and allow a login after booting. > > Ah, thanks ... but that's not standard RS232, right? (BPI homepages > says "TTL".) If it isn't, what kind of hardware connects to that? If you are located near Moers you can pick one up for free. Just contact me. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Nov 25 17:46: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 F2D53C54BFC for ; Fri, 25 Nov 2016 17:46:35 +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 D7F5EE4D for ; Fri, 25 Nov 2016 17:46:35 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 1c712918-b337-11e6-94b7-cbe6054a74b1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 1c712918-b337-11e6-94b7-cbe6054a74b1; Fri, 25 Nov 2016 17:46:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAPHkQ3k009070; Fri, 25 Nov 2016 10:46:26 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1480095986.1889.76.camel@freebsd.org> Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 From: Ian Lepore To: "Rodney W. Grimes" Cc: Michael Sperber , freebsd-arm@freebsd.org Date: Fri, 25 Nov 2016 10:46:26 -0700 In-Reply-To: <201611251707.uAPH7Y4K022170@pdx.rh.CN85.dnsmgr.net> References: <201611251707.uAPH7Y4K022170@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 17:46:36 -0000 On Fri, 2016-11-25 at 09:07 -0800, Rodney W. Grimes wrote: > [ Charset ISO-8859-1 unsupported, converting... ] > > > > On Fri, 2016-11-25 at 08:42 -0800, Rodney W. Grimes wrote: > > > > > > > > > > > > > > > > > > > sperber@deinprogramm.de said: > > > > > > > > > > > > > > > Ah, thanks ... but that's not standard RS232, right???(BPI > > > > > homepages says > > > > > "TTL".)??If it isn't, what kind of hardware connects to > > > > > that?? > > > > The normal setup for RS232 is that the transmit and receive > > > > signals > > > > come out? > > > > of a big chip (SOC, or PCI UART, or USB UART, or ...) and then > > > > go > > > > through a? > > > > level converter which is typically a MAX-232 or one of many > > > > clones > > > > or? > > > > variants.??The "TTL" is telling you that it doesn't have that > > > > level > > > > converter? > > > > chip. > > > > > > > > You can either add a level converter chip and then plug it into > > > > a > > > > real RS-232? > > > > port, or find some setup that also doesn't have the level > > > > converter > > > > and? > > > > speaks TTL levels.??Adafruit and probably many others sell a > > > > USB > > > > UART without? > > > > the level converter for applications like this. > > > > ? https://www.adafruit.com/product/954 > > > > > > > > Sometimes, TTL means 3V CMOS levels and 5V from real TTL/CMOS > > > > will > > > > fry your? > > > > expensive chip.??Best to check carefully.??The above part says > > > > 3V.??It also? > > > > has an extra power wire that you get to ignore. > > > Be SURE to ignore that extra power wire!??If your USB/Serial > > > adapter > > > also has > > > a power wire DO NOT CONNECT IT.??Many of these embeded boards > > > provide > > > a power > > > pin with the serial interface that can be used to power something > > > external, > > > like a level shifter, and many of the USB/Serial adapters also > > > bring > > > out the > > > USB 5V rail on a wire.??DO NOT CONNECT THE TWO!? > > > > > Ummm... say what? > > > > I power my rpi boards using the 5v power from the USB serial > > adapter > > connected to the 5v pin on the rpi header. ?I can't imagine any > > reason > > not to. > You either have a USB port wiling to supply more than the 500mA > from the standard, or are running your RPI under very light load. > This is NOT the recomended path to power a RPI, and if the RPI is > getting power from the micro usb port your connecting 2 power > supplies in parallel, which is bad. > And why exactly is two sources of +5v a problem (not that I said I was doing that, but I have at times done that, and it works just fine)? > If you plub a USB device into your RPI that draws significant > current it well probably reboot due to power loss. > > For information on how much power your PI wants/needs: > https://www.raspberrypi.org/help/faqs/#powerReqs > > > > > > > > > > That being said, there are many aftermarket USB/Serial cables > > > avaliable, > > > usually a 3.3V version of these well work everywhere as long as > > > it > > > has > > > 5V tolerent inputs, which most of the newer ones do, check the > > > specs > > > from the vendor.??3.3V outputs well satisfy the input > > > requirements of > > > a 5V TTL/CMOS circuit and not cause it problems, the opposite is > > > not > > > always true. > > > > > Usb serial adapter based on Prolific chipsets are NOT 5v tolerant. > > ?Those based on FTDI chips are. ?Those are the two big names in > > usb- > > serial chips, but there are others out there too; you have to check > > the > > datasheet to be sure. > From my read of the Prolific data sheet that is not clear, they > specify > 3.3v and 3.3v 5v tolerent, but then they do not clearly state which > pins are 3.3v and which are 3.3v+5v tolerent.   I'll take your word > that they don't like 5V on the serial rx pin. > They are actually very clear that of the IO pins, only the RESET_N pin is 5v tolerant. > > > > > > > > Watch your lead length and wire sizes if you need to do anything > > > funny > > > to get this connected, capacitive loading of any kind on this > > > type of > > > signal can cause character loss, especially at speeds above 9600 > > > baud. > > > > > Ummm... that sounds pretty bogus too, considering that I've run > > ftdi > > chips at 12mbps using breadboards with a rat's nest of wiring to > > carry > > the comms signals to other boards. > Iout of most of these chips is 4mA,  you are welcome to do the RC > calculations.  You can often get away with amazingly poor setups, > then suddenly get bitten by what looks to be just fine but drops > characters. > > Full level RS-232 specifies cable length of 50ft at 19200, your > not going to get away with that using CMOS 4mA drivers unless  > you have very low loss cable. Nice introduction of a red herring.  Who said anything about 50 foot cables?  Oh wait... you did.  Only you. -- Ian From owner-freebsd-arm@freebsd.org Fri Nov 25 18:39: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 ED992C55AD8 for ; Fri, 25 Nov 2016 18:39:24 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 7552DE25; Fri, 25 Nov 2016 18:39:23 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id uAPIdIwe022652; Fri, 25 Nov 2016 10:39:18 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id uAPIdIuV022651; Fri, 25 Nov 2016 10:39:18 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201611251839.uAPIdIuV022651@pdx.rh.CN85.dnsmgr.net> Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 In-Reply-To: <1480095986.1889.76.camel@freebsd.org> To: Ian Lepore Date: Fri, 25 Nov 2016 10:39:18 -0800 (PST) CC: Michael Sperber , freebsd-arm@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 18:39:25 -0000 > On Fri, 2016-11-25 at 09:07 -0800, Rodney W. Grimes wrote: > > > On Fri, 2016-11-25 at 08:42 -0800, Rodney W. Grimes wrote: > > > > > sperber@deinprogramm.de said: > > > > > > > > > > > > > > > > > > Ah, thanks ... but that's not standard RS232, right???(BPI > > > > > > homepages says > > > > > > "TTL".)??If it isn't, what kind of hardware connects to > > > > > > that?? > > > > > The normal setup for RS232 is that the transmit and receive > > > > > signals > > > > > come out? > > > > > of a big chip (SOC, or PCI UART, or USB UART, or ...) and then > > > > > go > > > > > through a? > > > > > level converter which is typically a MAX-232 or one of many > > > > > clones > > > > > or? > > > > > variants.??The "TTL" is telling you that it doesn't have that > > > > > level > > > > > converter? > > > > > chip. > > > > > > > > > > You can either add a level converter chip and then plug it into > > > > > a > > > > > real RS-232? > > > > > port, or find some setup that also doesn't have the level > > > > > converter > > > > > and? > > > > > speaks TTL levels.??Adafruit and probably many others sell a > > > > > USB > > > > > UART without? > > > > > the level converter for applications like this. > > > > > ? https://www.adafruit.com/product/954 > > > > > > > > > > Sometimes, TTL means 3V CMOS levels and 5V from real TTL/CMOS > > > > > will > > > > > fry your? > > > > > expensive chip.??Best to check carefully.??The above part says > > > > > 3V.??It also? > > > > > has an extra power wire that you get to ignore. > > > > Be SURE to ignore that extra power wire!??If your USB/Serial > > > > adapter > > > > also has > > > > a power wire DO NOT CONNECT IT.??Many of these embeded boards > > > > provide > > > > a power > > > > pin with the serial interface that can be used to power something > > > > external, > > > > like a level shifter, and many of the USB/Serial adapters also > > > > bring > > > > out the > > > > USB 5V rail on a wire.??DO NOT CONNECT THE TWO!? > > > > > > > Ummm... say what? > > > > > > I power my rpi boards using the 5v power from the USB serial > > > adapter > > > connected to the 5v pin on the rpi header. ?I can't imagine any > > > reason > > > not to. > > You either have a USB port wiling to supply more than the 500mA > > from the standard, or are running your RPI under very light load. > > This is NOT the recomended path to power a RPI, and if the RPI is > > getting power from the micro usb port your connecting 2 power > > supplies in parallel, which is bad. > > > > And why exactly is two sources of +5v a problem (not that I said I was > doing that, but I have at times done that, and it works just fine)? ``Works just fine'' are famous last words when the smoke comes out of a) your power supplies or b) your board cause of power supply failure. What you are doing is called brute force paralleling of power supplies, and any good EE knows that is just a bad idea(tm) becuase power supplies are not designed to do that. Google up parallel power supplies and read for more information, lots of it out there, some bad, some good. > > > If you plub a USB device into your RPI that draws significant > > current it well probably reboot due to power loss. > > > > For information on how much power your PI wants/needs: > > https://www.raspberrypi.org/help/faqs/#powerReqs > > > > > > > > > > > > > > That being said, there are many aftermarket USB/Serial cables > > > > avaliable, > > > > usually a 3.3V version of these well work everywhere as long as > > > > it > > > > has > > > > 5V tolerent inputs, which most of the newer ones do, check the > > > > specs > > > > from the vendor.??3.3V outputs well satisfy the input > > > > requirements of > > > > a 5V TTL/CMOS circuit and not cause it problems, the opposite is > > > > not > > > > always true. > > > > > > > Usb serial adapter based on Prolific chipsets are NOT 5v tolerant. > > > ?Those based on FTDI chips are. ?Those are the two big names in > > > usb- > > > serial chips, but there are others out there too; you have to check > > > the > > > datasheet to be sure. > > From my read of the Prolific data sheet that is not clear, they > > specify > > 3.3v and 3.3v 5v tolerent, but then they do not clearly state which > > pins are 3.3v and which are 3.3v+5v tolerent.???I'll take your word > > that they don't like 5V on the serial rx pin. > > > > They are actually very clear that of the IO pins, only the RESET_N pin > is 5v tolerant. Somehow I missed that in reading the datasheet. > > > > Watch your lead length and wire sizes if you need to do anything > > > > funny > > > > to get this connected, capacitive loading of any kind on this > > > > type of > > > > signal can cause character loss, especially at speeds above 9600 > > > > baud. > > > > > > > Ummm... that sounds pretty bogus too, considering that I've run > > > ftdi > > > chips at 12mbps using breadboards with a rat's nest of wiring to > > > carry > > > the comms signals to other boards. > > Iout of most of these chips is 4mA,??you are welcome to do the RC > > calculations.??You can often get away with amazingly poor setups, > > then suddenly get bitten by what looks to be just fine but drops > > characters. > > > > Full level RS-232 specifies cable length of 50ft at 19200, your > > not going to get away with that using CMOS 4mA drivers unless? > > you have very low loss cable. > > Nice introduction of a red herring. ?Who said anything about 50 foot > cables? ?Oh wait... you did. ?Only you. Again, I would suggest googling up single ended signaling, serial cmos wire length, ttl over ribbon cable, etc, just cause it works for you on a bench does not make it good design practice and that it well work all over. In general CMOS or TTL signals are not really desinged to go great distances without carefull impedence control and signal integrity considerations, neither of which exist in some random wiring. Sure, I have crammed 10Mhz signals down a meter of ribon cable and gotten away with it, but thats not a sound design practice, genreally TTL/CMOS signars are considered to have a sub 1 meter usable signal length. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Fri Nov 25 18:41: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 9DA77C55CB1 for ; Fri, 25 Nov 2016 18:41:10 +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 845631000; Fri, 25 Nov 2016 18:41:10 +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 46C71406061; Fri, 25 Nov 2016 10:41:09 -0800 (PST) X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3 To: Ian Lepore cc: freebsd-arm@freebsd.org, hmurray@megapathdsl.net From: Hal Murray Subject: Re: Can't get 11.0-RELEASE to boot on Banana PI M3 In-Reply-To: Message from Ian Lepore of "Fri, 25 Nov 2016 10:46:26 MST." <1480095986.1889.76.camel@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 25 Nov 2016 10:41:09 -0800 Message-Id: <20161125184109.46C71406061@ip-64-139-1-69.sjc.megapath.net> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 18:41:10 -0000 ian@freebsd.org said: > And why exactly is two sources of +5v a problem (not that I said I was doing > that, but I have at times done that, and it works just fine)? That connects 2 regulated power supplies together. They are unlikely to be trying to regulate to the exact same voltage. If the connection is solid, one power supply would probably turn off and let the other do all the work. If the connection is crappy (long thin wires), then they will share the load with the size of each share depending on the voltage from that supply and the resistance of the wires/connectors between the supply and the load. Things get interesting if you turn one supply off. The other supply will try to power everything on that side. That may look like a short circuit. USB sources are supposed to handle short circuits but I wouldn't be surprised if low cost gear got hot or let the smoke out. Power flowing the wrong way isn't something designers think of when they are trying to save pennies. -- These are my opinions. I hate spam. From owner-freebsd-arm@freebsd.org Fri Nov 25 19:56: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 566DBC55669 for ; Fri, 25 Nov 2016 19:56:15 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F353C397 for ; Fri, 25 Nov 2016 19:56:14 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id CKw31u0084VixDu01Kw5zr; Fri, 25 Nov 2016 20:56:05 +0100 Reply-To: From: "John W. Kitz" To: "'freebsd-arm'" References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> In-Reply-To: <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> Subject: RE: How to change MAC address on RPI-B? Date: Fri, 25 Nov 2016 20:56:04 +0100 Message-ID: <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJHMT44SOvRXlvkTk63Nm1fBL58QwAILS5Q Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 19:56:15 -0000 Reiner, So when doing so the locally administered MAC address is passed on from uEnv.txt to the O/S during boot and is then used to override the globally unique MAC address or does the O/S check both the information found in its configuration files and what is configured in uEnv.txt before configuring and activating the network interface(s)? Makes me wonder which of the two (i.e. locally administered through uEnv.txt or locally administered through the O/S) takes precedence. In addition this might affect configuration decisions when one would want to configure a device for net booting (at least when browsing through what can be configured by means of uEnv.txt I believe that was one of the options I saw) through uEnv.txt? Jk. From owner-freebsd-arm@freebsd.org Fri Nov 25 23:17: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 B1E0BC54CBB for ; Fri, 25 Nov 2016 23:17:41 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout12.t-online.de (mailout12.t-online.de [194.25.134.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 77913E24 for ; Fri, 25 Nov 2016 23:17:41 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd11.aul.t-online.de (fwd11.aul.t-online.de [172.20.27.152]) by mailout12.t-online.de (Postfix) with SMTP id 6B1F741F7232 for ; Sat, 26 Nov 2016 00:07:41 +0100 (CET) Received: from [192.168.10.43] (ZZm7imZEZh3lher83DFgG2UeFoWcKANPwDu5iFFT7fKVLEwJCeb8o59VjdvqryTQot@[86.56.56.128]) by fwd11.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAPam-07aljE0; Sat, 26 Nov 2016 00:07:40 +0100 Subject: Re: How to change MAC address on RPI-B? References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> To: freebsd-arm@freebsd.org From: diffusae Message-ID: <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> Date: Sat, 26 Nov 2016 00:07:40 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ID: ZZm7imZEZh3lher83DFgG2UeFoWcKANPwDu5iFFT7fKVLEwJCeb8o59VjdvqryTQot X-TOI-MSGID: cd5da6c5-0e3c-43ff-8993-8ba6197a72fe X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Nov 2016 23:17:41 -0000 Hi John, On 25.11.2016 20:56, John W. Kitz wrote: > So when doing so the locally administered MAC address is passed on from > uEnv.txt to the O/S during boot and is then used to override the globally I didn't think, that it will be passed from the U-Boot Enviroment settings. You can set the MAC address, but the FreeBSD kernel shows always the unique MAC address. > unique MAC address or does the O/S check both the information found in its > configuration files and what is configured in uEnv.txt before configuring > and activating the network interface(s)? Which configuration files do you mean? AFAIK there is only the FDT blob. I guess it ignores the setting in uEnv.txt. > Makes me wonder which of the two (i.e. locally administered through uEnv.txt > or locally administered through the O/S) takes precedence. Only the unique MAC address and the locally administered MAC address, will take affect. > In addition this might affect configuration decisions when one would want to > configure a device for net booting (at least when browsing through what can > be configured by means of uEnv.txt I believe that was one of the options I > saw) through uEnv.txt? Personally, I like u-boot. It has various options, runs on a lot of devices and it's also nice to handle. Best regards, From owner-freebsd-arm@freebsd.org Sat Nov 26 05:19: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 B101FC5576A for ; Sat, 26 Nov 2016 05:19:00 +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 93C32FEA for ; Sat, 26 Nov 2016 05:19:00 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: db338a78-b397-11e6-94b7-cbe6054a74b1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id db338a78-b397-11e6-94b7-cbe6054a74b1; Sat, 26 Nov 2016 05:19:08 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAQ5IvMp010019; Fri, 25 Nov 2016 22:18:57 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1480137537.1889.97.camel@freebsd.org> Subject: Re: How to change MAC address on RPI-B? From: Ian Lepore To: diffusae , freebsd-arm@freebsd.org Date: Fri, 25 Nov 2016 22:18:57 -0700 In-Reply-To: <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 05:19:00 -0000 On Sat, 2016-11-26 at 00:07 +0100, diffusae wrote: > Hi John, > > On 25.11.2016 20:56, John W. Kitz wrote: > > > > > So when doing so the locally administered MAC address is passed on > > from > > uEnv.txt to the O/S during boot and is then used to override the > > globally > I didn't think, that it will be passed from the U-Boot Enviroment > settings. You can set the MAC address, but the FreeBSD kernel shows > always the unique MAC address. > > > > > unique MAC address or does the O/S check both the information found > > in its > > configuration files and what is configured in uEnv.txt before > > configuring > > and activating the network interface(s)? > Which configuration files do you mean? AFAIK there is only the FDT > blob. > I guess it ignores the setting in uEnv.txt. > > > > > Makes me wonder which of the two (i.e. locally administered through > > uEnv.txt > > or locally administered through the O/S) takes precedence. > Only the unique MAC address and the locally administered MAC address, > will take affect. > > > > > In addition this might affect configuration decisions when one > > would want to > > configure a device for net booting (at least when browsing through > > what can > > be configured by means of uEnv.txt I believe that was one of the > > options I > > saw) through uEnv.txt? > Personally, I like u-boot. It has various options, runs on a lot of > devices and it's also nice to handle. > > Best regards, > _ I looked into this tonight, and there is some code missing in u-boot to handle passing a mac address set in the u-boot environment into the kernel via the fdt data. It would be pretty simple to fix.  We need to add an ethernet0 alias pointing to the /axi/usb/hub/ethernet node to our rpi dts, and the attached patch needs to replace the current one in the u-boot-rpi port. This lets you set usbethaddr in the u-boot environment (via uEnv.txt or saved directly using saveenv), and it will get used by both u-boot and freebsd. Having gotten it this far, I don't really have time right now to get the patch committed to ports.  Hopefully somebody else can help with that. -- Ian From owner-freebsd-arm@freebsd.org Sat Nov 26 05:22: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 08E3CC55C21 for ; Sat, 26 Nov 2016 05:22:14 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9A694641 for ; Sat, 26 Nov 2016 05:22:13 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 48d370e5-b398-11e6-b17f-19517aec265d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 48d370e5-b398-11e6-b17f-19517aec265d; Sat, 26 Nov 2016 05:22:13 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAQ5Lx4o010027; Fri, 25 Nov 2016 22:21:59 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1480137719.1889.98.camel@freebsd.org> Subject: Re: How to change MAC address on RPI-B? From: Ian Lepore To: diffusae , freebsd-arm@freebsd.org Date: Fri, 25 Nov 2016 22:21:59 -0700 In-Reply-To: <1480137537.1889.97.camel@freebsd.org> References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 05:22:14 -0000 On Fri, 2016-11-25 at 22:18 -0700, Ian Lepore wrote: > On Sat, 2016-11-26 at 00:07 +0100, diffusae wrote: > > > > Hi John, > > > > On 25.11.2016 20:56, John W. Kitz wrote: > > > > > > > > > > > So when doing so the locally administered MAC address is passed > > > on > > > from > > > uEnv.txt to the O/S during boot and is then used to override the > > > globally > > I didn't think, that it will be passed from the U-Boot Enviroment > > settings. You can set the MAC address, but the FreeBSD kernel shows > > always the unique MAC address. > > > > > > > > > > > unique MAC address or does the O/S check both the information > > > found > > > in its > > > configuration files and what is configured in uEnv.txt before > > > configuring > > > and activating the network interface(s)? > > Which configuration files do you mean? AFAIK there is only the FDT > > blob. > > I guess it ignores the setting in uEnv.txt. > > > > > > > > > > > Makes me wonder which of the two (i.e. locally administered > > > through > > > uEnv.txt > > > or locally administered through the O/S) takes precedence. > > Only the unique MAC address and the locally administered MAC > > address, > > will take affect. > > > > > > > > > > > In addition this might affect configuration decisions when one > > > would want to > > > configure a device for net booting (at least when browsing > > > through > > > what can > > > be configured by means of uEnv.txt I believe that was one of the > > > options I > > > saw) through uEnv.txt? > > Personally, I like u-boot. It has various options, runs on a lot of > > devices and it's also nice to handle. > > > > Best regards, > > _ > I looked into this tonight, and there is some code missing in u-boot > to > handle passing a mac address set in the u-boot environment into the > kernel via the fdt data. > > It would be pretty simple to fix.  We need to add an ethernet0 alias > pointing to the /axi/usb/hub/ethernet node to our rpi dts, and the > attached patch needs to replace the current one in the u-boot-rpi > port. > > This lets you set usbethaddr in the u-boot environment (via uEnv.txt > or > saved directly using saveenv), and it will get used by both u-boot > and > freebsd. > > Having gotten it this far, I don't really have time right now to get > the patch committed to ports.  Hopefully somebody else can help with > that. > > -- Ian Looks like I forgot to attach the patch.  Try again... -- Ian From owner-freebsd-arm@freebsd.org Sat Nov 26 09:21: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 22430C57E22 for ; Sat, 26 Nov 2016 09:21:09 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BF406FCD for ; Sat, 26 Nov 2016 09:21:08 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id CZLx1u0024VixDu01ZLyjE; Sat, 26 Nov 2016 10:20:59 +0100 Reply-To: From: "John W. Kitz" To: References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> In-Reply-To: <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> Subject: RE: How to change MAC address on RPI-B? Date: Sat, 26 Nov 2016 10:20:57 +0100 Message-ID: <000901d247c6$6a8d5670$3fa80350$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJHciWcXzvHmUl5QSmiRF72AJyACgAUCP3w Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 09:21:09 -0000 Reiner, My remarks are based on this example: "autoload=no ethaddr=12:34:56:78:99:aa <=== fdt_high=ffffffff serverip=192.168.1.130 bootargs=earlyprintk console=ttyS0,115200 boot_tftp=dhcp; tftp 0x46000000 arch/arm/boot/uImage; tftp 0x49000000 arch/arm/boot/dts/sun7i-a20-cubieboard2.dtb; bootm 0x46000000 - 0x49000000 uenvcmd=run boot_tftp" which I found in this http://linux-sunxi.org/UEnv.txt article and a bit of documentation that is being referred to in it, which can be found here https://www.kernel.org/doc/Documentation/kernel-parameters.txt. > So when doing so the locally administered MAC address is passed on > from uEnv.txt to the O/S during boot and is then used to override the > globally I didn't think, that it will be passed from the U-Boot Enviroment settings. You can set the MAC address, but the FreeBSD kernel shows always the unique MAC address. JKi: Please note that my remarks weren't intended to be a statement, rather a question. > unique MAC address or does the O/S check both the information found in > its configuration files and what is configured in uEnv.txt before > configuring and activating the network interface(s)? Which configuration files do you mean? AFAIK there is only the FDT blob. I guess it ignores the setting in uEnv.txt. JKi: Also please note that I have no experience using an ARM based board at this time. I've only ordered one recently. > Makes me wonder which of the two (i.e. locally administered through > uEnv.txt or locally administered through the O/S) takes precedence. Only the unique MAC address and the locally administered MAC address, will take affect. JKi: Looking at the email exchange on this topic I thought it was established previously that this can't be true. > In addition this might affect configuration decisions when one would > want to configure a device for net booting (at least when browsing > through what can be configured by means of uEnv.txt I believe that was > one of the options I > saw) through uEnv.txt? Regards, Jk. From owner-freebsd-arm@freebsd.org Sat Nov 26 09:27: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 55801C54015 for ; Sat, 26 Nov 2016 09:27:08 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "*.xs4all.nl", Issuer "GlobalSign Domain Validation CA - SHA256 - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id F23CA762 for ; Sat, 26 Nov 2016 09:27:07 +0000 (UTC) (envelope-from John.Kitz@xs4all.nl) Received: from picard ([82.95.89.208]) by smtp-cloud2.xs4all.net with ESMTP id CZT41u0044VixDu01ZT5Cl; Sat, 26 Nov 2016 10:27:05 +0100 Reply-To: From: "John W. Kitz" To: References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> In-Reply-To: <1480137537.1889.97.camel@freebsd.org> Subject: RE: How to change MAC address on RPI-B? Date: Sat, 26 Nov 2016 10:27:11 +0100 Message-ID: <000c01d247c7$452a4db0$cf7ee910$@Kitz@xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AdJHpK4zmzIcvcMlT+ylrHT99yqvpQAIdGng Content-Language: en-us X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 09:27:08 -0000 Ian, On Sat, 2016-11-26 at 00:07 +0100, diffusae wrote: > Hi John, >=20 > On 25.11.2016 20:56, John W. Kitz wrote: >=20 > >=20 > > So when doing so the locally administered MAC address is passed on=20 > > from uEnv.txt to the O/S during boot and is then used to override=20 > > the globally > I didn't think, that it will be passed from the U-Boot Enviroment=20 > settings. You can set the MAC address, but the FreeBSD kernel shows=20 > always the unique MAC address. >=20 > >=20 > > unique MAC address or does the O/S check both the information found=20 > > in its configuration files and what is configured in uEnv.txt before = > > configuring and activating the network interface(s)? > Which configuration files do you mean? AFAIK there is only the FDT=20 > blob. > I guess it ignores the setting in uEnv.txt. >=20 > >=20 > > Makes me wonder which of the two (i.e. locally administered through=20 > > uEnv.txt or locally administered through the O/S) takes precedence. > Only the unique MAC address and the locally administered MAC address,=20 > will take affect. >=20 > >=20 > > In addition this might affect configuration decisions when one would = > > want to configure a device for net booting (at least when browsing=20 > > through what can be configured by means of uEnv.txt I believe that=20 > > was one of the options I > > saw) through uEnv.txt? > Personally, I like u-boot. It has various options, runs on a lot of=20 > devices and it's also nice to handle. >=20 > Best regards, > _ I looked into this tonight, and there is some code missing in u-boot to handle passing a mac address set in the u-boot environment into the = kernel via the fdt data. It would be pretty simple to fix. =A0We need to add an ethernet0 alias pointing to the /axi/usb/hub/ethernet node to our rpi dts, and the = attached patch needs to replace the current one in the u-boot-rpi port. This lets you set usbethaddr in the u-boot environment (via uEnv.txt or saved directly using saveenv), and it will get used by both u-boot and freebsd. Having gotten it this far, I don't really have time right now to get the patch committed to ports. =A0Hopefully somebody else can help with that. JKi: I was just curious, but have no immediate use for the features discussed in this particular thread at this time. So please don't make = the effort to get mentioned changes implemented because of this thread. From owner-freebsd-arm@freebsd.org Sat Nov 26 12:57: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 72A9CC56124 for ; Sat, 26 Nov 2016 12:57:40 +0000 (UTC) (envelope-from jrc@skylon.demon.co.uk) Received: from smtp.demon.co.uk (mdfmta010.mxout.tch.inty.net [91.221.169.51]) (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 11BF5BD4 for ; Sat, 26 Nov 2016 12:57:38 +0000 (UTC) (envelope-from jrc@skylon.demon.co.uk) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id 59D45401987 for ; Sat, 26 Nov 2016 12:51:58 +0000 (GMT) Received: from mdfmta010.tch.inty.net (unknown [127.0.0.1]) by mdfmta010.tch.inty.net (Postfix) with ESMTP id 3072840195A for ; Sat, 26 Nov 2016 12:51:58 +0000 (GMT) Received: from skylon.dyndns.org (unknown [81.104.142.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta010.tch.inty.net (Postfix) with ESMTP for ; Sat, 26 Nov 2016 12:51:58 +0000 (GMT) Received: from router.home.verminmedia.com ([192.168.199.1] helo=[192.168.199.2]) by skylon.dyndns.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_2) (envelope-from ) id 1cAcRx-0005hU-IM for freebsd-arm@freebsd.org; Sat, 26 Nov 2016 12:51:25 +0000 To: freebsd-arm@freebsd.org From: John Connett Subject: Booting FreeBSD from Windows 10 IoT Core EFI? Message-ID: Date: Sat, 26 Nov 2016 12:51:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1CPDHEKLWXfu4ownoB2PljnKU9iERh3vJ" X-MDF-HostID: 19 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 12:57:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1CPDHEKLWXfu4ownoB2PljnKU9iERh3vJ Content-Type: multipart/mixed; boundary="X2Ownw6LaGMhimNsKfwEjN2oiJ9uH0o0E"; protected-headers="v1" From: John Connett To: freebsd-arm@freebsd.org Message-ID: Subject: Booting FreeBSD from Windows 10 IoT Core EFI? --X2Ownw6LaGMhimNsKfwEjN2oiJ9uH0o0E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Windows 10 IoT Core on Raspberry Pi 3 (and Dragonboard 410c) appears to boot using EFI. The following link demonstrates that a faulty boot can result in an EFI start prompt: https://social.msdn.microsoft.com/Forums/en-US/426f4537-59c3-4fe1-9f09-26= 47a9c8b71d/raspberry-pi-3-booting-to-efi-screen Has anyone tried booting FreeBSD using this version of EFI? I suspect it originates from Broadcom and is probably licensed for use on their devices. Might be an alternative to the "u-boot efi option" mentioned on a thread in this list last month. I have both a Raspberry Pi 3 and Dragonboard 410c on which I could experiment if someone could give me pointer on where to start. --X2Ownw6LaGMhimNsKfwEjN2oiJ9uH0o0E-- --1CPDHEKLWXfu4ownoB2PljnKU9iERh3vJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iLMEAQECAB0WIQSkgaq2sCio4xbyyp3JMiZNt4huWQUCWDmFQAAKCRDJMiZNt4hu WWm+A/wMJwAM7rI3bUTox0fcq+guvEw9pajQLKdtQj2mYk4/GyfF6OQ8JuM5R0hu LOucRHFRf70EptnbIcubInIng6m5u3gWdwltBuNlFd6URPqW5W+pmkK+Jfru2OsM KpwANe7P0pAXLhxhz6Baiz7UQCHk0Cs4gURnja0qORH+5y9/vg== =6lgZ -----END PGP SIGNATURE----- --1CPDHEKLWXfu4ownoB2PljnKU9iERh3vJ-- From owner-freebsd-arm@freebsd.org Sat Nov 26 17:35: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 2183DC5701A for ; Sat, 26 Nov 2016 17:35:23 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B2F3778C for ; Sat, 26 Nov 2016 17:35:22 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: b81e2d97-b3fe-11e6-b17f-19517aec265d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id b81e2d97-b3fe-11e6-b17f-19517aec265d; Sat, 26 Nov 2016 17:35:28 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAQHZEKf011517; Sat, 26 Nov 2016 10:35:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1480181714.1889.103.camel@freebsd.org> Subject: Re: How to change MAC address on RPI-B? From: Ian Lepore To: John.Kitz@xs4all.nl, freebsd-arm@freebsd.org Date: Sat, 26 Nov 2016 10:35:14 -0700 In-Reply-To: <000c01d247c7$452a4db0$cf7ee910$@Kitz@xs4all.nl> References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <000c01d247c7$452a4db0$cf7ee910$@Kitz@xs4all.nl> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 17:35:23 -0000 On Sat, 2016-11-26 at 10:27 +0100, John W. Kitz wrote: > Ian, > > On Sat, 2016-11-26 at 00:07 +0100, diffusae wrote: > > > > Hi John, > > > > On 25.11.2016 20:56, John W. Kitz wrote: > > > > > > > > > > > So when doing so the locally administered MAC address is passed > > > on  > > > from uEnv.txt to the O/S during boot and is then used to > > > override  > > > the globally > > I didn't think, that it will be passed from the U-Boot Enviroment  > > settings. You can set the MAC address, but the FreeBSD kernel > > shows  > > always the unique MAC address. > > > > > > > > > > > unique MAC address or does the O/S check both the information > > > found  > > > in its configuration files and what is configured in uEnv.txt > > > before  > > > configuring and activating the network interface(s)? > > Which configuration files do you mean? AFAIK there is only the FDT  > > blob. > > I guess it ignores the setting in uEnv.txt. > > > > > > > > > > > Makes me wonder which of the two (i.e. locally administered > > > through  > > > uEnv.txt or locally administered through the O/S) takes > > > precedence. > > Only the unique MAC address and the locally administered MAC > > address,  > > will take affect. > > > > > > > > > > > In addition this might affect configuration decisions when one > > > would  > > > want to configure a device for net booting (at least when > > > browsing  > > > through what can be configured by means of uEnv.txt I believe > > > that  > > > was one of the options I > > > saw) through uEnv.txt? > > Personally, I like u-boot. It has various options, runs on a lot > > of  > > devices and it's also nice to handle. > > > > Best regards, > > _ > I looked into this tonight, and there is some code missing in u-boot > to > handle passing a mac address set in the u-boot environment into the > kernel > via the fdt data. > > It would be pretty simple to fix.  We need to add an ethernet0 alias > pointing to the /axi/usb/hub/ethernet node to our rpi dts, and the > attached > patch needs to replace the current one in the u-boot-rpi port. > > This lets you set usbethaddr in the u-boot environment (via uEnv.txt > or > saved directly using saveenv), and it will get used by both u-boot > and > freebsd. > > Having gotten it this far, I don't really have time right now to get > the > patch committed to ports.  Hopefully somebody else can help with > that. > > JKi: I was just curious, but have no immediate use for the features > discussed in this particular thread at this time. So please don't > make the > effort to get mentioned changes implemented because of this thread. Well, it's wrong and it needs to be fixed.  For every other arm board, you can set a mac addr in u-boot and it remains in effect when freebsd is running.  It's not right for rpi to be different.  It probably affects rpi2 as well.  And, really, anything with usb ethernet. I wonder why the mailing list is stripping diff attachments now?  That never used to happen.  Hrm, probably because after my last pkg upgrade, Evolution is now flagging the attachment as text/x-csrc; it used to be x-patch.  I've put the patch here... https://people.freebsd.org/~ian/patch-common_cmd__boot.c -- Ian From owner-freebsd-arm@freebsd.org Sat Nov 26 17:42: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 26E23C57422 for ; Sat, 26 Nov 2016 17:42:35 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout10.t-online.de (mailout10.t-online.de [194.25.134.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E0B71C90; Sat, 26 Nov 2016 17:42:34 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd21.aul.t-online.de (fwd21.aul.t-online.de [172.20.27.66]) by mailout10.t-online.de (Postfix) with SMTP id 4C35041E51D5; Sat, 26 Nov 2016 18:32:38 +0100 (CET) Received: from [192.168.10.43] (rXvy+wZXrh9X3zA-XJCsoMSrsLaxIsnB0fE6qthhyg-QiJOkSqwp2gCP0X35ar4ZIc@[86.56.56.128]) by fwd21.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAgq4-22rrzk0; Sat, 26 Nov 2016 18:32:36 +0100 Subject: Re: How to change MAC address on RPI-B? To: Ian Lepore , freebsd-arm@freebsd.org References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <1480137719.1889.98.camel@freebsd.org> From: diffusae Message-ID: Date: Sat, 26 Nov 2016 18:32:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480137719.1889.98.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: rXvy+wZXrh9X3zA-XJCsoMSrsLaxIsnB0fE6qthhyg-QiJOkSqwp2gCP0X35ar4ZIc X-TOI-MSGID: 95225627-3909-41c5-82da-abf2c4ef6ca9 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 17:42:35 -0000 Hi Ian, I've applied it to the sysutils/u-boot-rpi port and test the package with the RPI-B. The configured usbethaddr is set in the u-boot environment, but it will not passed to the kernel via the FTD blob. The FreeBSD kernel always have the BIA of the NIC. But I think, you are right, the RPis FTD data is available before the u-boot enviroment is set. So unfortunately that doesn't work a the moment. Best regards, On 26.11.2016 06:21, Ian Lepore wrote: >> I looked into this tonight, and there is some code missing in u-boot >> > to >> > handle passing a mac address set in the u-boot environment into the >> > kernel via the fdt data. >> > >> > It would be pretty simple to fix. We need to add an ethernet0 alias >> > pointing to the /axi/usb/hub/ethernet node to our rpi dts, and the >> > attached patch needs to replace the current one in the u-boot-rpi >> > port. >> > >> > This lets you set usbethaddr in the u-boot environment (via uEnv.txt >> > or >> > saved directly using saveenv), and it will get used by both u-boot >> > and >> > freebsd. >> > >> > Having gotten it this far, I don't really have time right now to get >> > the patch committed to ports. Hopefully somebody else can help with >> > that. >> > >> > -- Ian > Looks like I forgot to attach the patch. Try again... From owner-freebsd-arm@freebsd.org Sat Nov 26 17:58: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 0B6C5C579CA for ; Sat, 26 Nov 2016 17:58: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 E36CA998 for ; Sat, 26 Nov 2016 17:58:40 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: f84aee6b-b401-11e6-94b7-cbe6054a74b1 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id f84aee6b-b401-11e6-94b7-cbe6054a74b1; Sat, 26 Nov 2016 17:58:43 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAQHwWCP011572; Sat, 26 Nov 2016 10:58:32 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1480183112.1889.108.camel@freebsd.org> Subject: Re: How to change MAC address on RPI-B? From: Ian Lepore To: diffusae , freebsd-arm@freebsd.org Date: Sat, 26 Nov 2016 10:58:32 -0700 In-Reply-To: References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <1480137719.1889.98.camel@freebsd.org> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 17:58:41 -0000 On Sat, 2016-11-26 at 18:32 +0100, diffusae wrote: > Hi Ian, > > I've applied it to the sysutils/u-boot-rpi port and test the package > with the RPI-B. The configured usbethaddr is set in the u-boot > environment, but it will not passed to the kernel via the FTD blob. > The > FreeBSD kernel always have the BIA of the NIC. > > But I think, you are right, the RPis FTD data is available before the > u-boot enviroment is set. > > So unfortunately that doesn't work a the moment. > > Best regards, It also requires a change to sys/boot/fdt/dts/arm/rpi.dts and recompile and put the new rpi.dtb file on the fat partition of the sdcard.  I just committed the change for that as r309195. This stuff does work, I tested it last night. -- Ian From owner-freebsd-arm@freebsd.org Sat Nov 26 18:17:25 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 C0ABEC57091 for ; Sat, 26 Nov 2016 18:17:25 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 83C75362; Sat, 26 Nov 2016 18:17:25 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd19.aul.t-online.de (fwd19.aul.t-online.de [172.20.27.65]) by mailout11.t-online.de (Postfix) with SMTP id 0E6A44253A7A; Sat, 26 Nov 2016 19:17:17 +0100 (CET) Received: from [192.168.10.43] (X7l22wZOrhNwXvS1I6G0nDfPHjRSU6epfs1uD8hnaYlrHMzG1BggXCALKzaqR0dw1k@[86.56.56.128]) by fwd19.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAhXI-2UwEWu0; Sat, 26 Nov 2016 19:17:16 +0100 Subject: Re: How to change MAC address on RPI-B? To: Ian Lepore , freebsd-arm@freebsd.org References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <1480137719.1889.98.camel@freebsd.org> <1480183112.1889.108.camel@freebsd.org> From: diffusae Message-ID: Date: Sat, 26 Nov 2016 19:17:15 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480183112.1889.108.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: X7l22wZOrhNwXvS1I6G0nDfPHjRSU6epfs1uD8hnaYlrHMzG1BggXCALKzaqR0dw1k X-TOI-MSGID: 1ab104be-3563-49f4-9653-36efb63a8fa9 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 18:17:25 -0000 Ahh, sorry. I guess, that I've did something wrong. Didn't know about that additional change. So it will be available at r309195 soon? Can't find the change at the moment. I will recompile and test it again. Thanks a lot for you help. On 26.11.2016 18:58, Ian Lepore wrote: > On Sat, 2016-11-26 at 18:32 +0100, diffusae wrote: >> Hi Ian, >> >> I've applied it to the sysutils/u-boot-rpi port and test the package >> with the RPI-B. The configured usbethaddr is set in the u-boot >> environment, but it will not passed to the kernel via the FTD blob. >> The >> FreeBSD kernel always have the BIA of the NIC. >> >> But I think, you are right, the RPis FTD data is available before the >> u-boot enviroment is set. >> >> So unfortunately that doesn't work a the moment. >> >> Best regards, > > It also requires a change to sys/boot/fdt/dts/arm/rpi.dts and recompile > and put the new rpi.dtb file on the fat partition of the sdcard. I > just committed the change for that as r309195. > > This stuff does work, I tested it last night. > > -- Ian > From owner-freebsd-arm@freebsd.org Sat Nov 26 19:09: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 94F6DC57350 for ; Sat, 26 Nov 2016 19:09:02 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout06.t-online.de (mailout06.t-online.de [194.25.134.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 57E87211; Sat, 26 Nov 2016 19:09:02 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd08.aul.t-online.de (fwd08.aul.t-online.de [172.20.26.151]) by mailout06.t-online.de (Postfix) with SMTP id 5031841C66C1; Sat, 26 Nov 2016 20:08:54 +0100 (CET) Received: from [192.168.10.43] (SaZ+d+ZBQhJco0BMgWEymOxFfE9QqSi2OfgmlHXH2F28snWyrPGMo6XjE5H6pIfgpJ@[86.56.56.128]) by fwd08.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAiLF-2xj8zI0; Sat, 26 Nov 2016 20:08:53 +0100 Subject: Re: How to change MAC address on RPI-B? To: Ian Lepore , freebsd-arm@freebsd.org References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <1480137719.1889.98.camel@freebsd.org> <1480183112.1889.108.camel@freebsd.org> From: diffusae Message-ID: <31f627db-5992-ccff-a9df-67f4793f8a12@t-online.de> Date: Sat, 26 Nov 2016 20:08:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480183112.1889.108.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: SaZ+d+ZBQhJco0BMgWEymOxFfE9QqSi2OfgmlHXH2F28snWyrPGMo6XjE5H6pIfgpJ X-TOI-MSGID: e3a23a8e-8eaf-4a20-9b51-c849438e3aab X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 19:09:02 -0000 Yes, indeed, it works. Just need the change in rpi.dts, too ;-) Regards On 26.11.2016 18:58, Ian Lepore wrote: > This stuff does work, I tested it last night. From owner-freebsd-arm@freebsd.org Sat Nov 26 19:22: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 709DCC57BCF for ; Sat, 26 Nov 2016 19:22:22 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout03.t-online.de (mailout03.t-online.de [194.25.134.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02E9AE87 for ; Sat, 26 Nov 2016 19:22:21 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd04.aul.t-online.de (fwd04.aul.t-online.de [172.20.26.149]) by mailout03.t-online.de (Postfix) with SMTP id BCD6C42364B3 for ; Sat, 26 Nov 2016 20:16:15 +0100 (CET) Received: from [192.168.10.43] (TbKQMcZJwh1rxokXc1Y4pTCWIWHQmx1KJn1HpnyFxTWK3q-Wjf7yxxKylY84vBywic@[86.56.56.128]) by fwd04.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAiSG-4AzJtg0; Sat, 26 Nov 2016 20:16:08 +0100 Subject: Re: How to change MAC address on RPI-B? References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <000c01d247c7$452a4db0$cf7ee910$@Kitz@xs4all.nl> <1480181714.1889.103.camel@freebsd.org> To: freebsd-arm@freebsd.org From: diffusae Message-ID: <6a99a76e-5de7-f2bd-6539-2780444dd2cc@t-online.de> Date: Sat, 26 Nov 2016 20:16:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480181714.1889.103.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: TbKQMcZJwh1rxokXc1Y4pTCWIWHQmx1KJn1HpnyFxTWK3q-Wjf7yxxKylY84vBywic X-TOI-MSGID: e0a895fc-7571-489a-af06-c0c54e445e90 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 19:22:22 -0000 Hi! Does anyone, what this means: U-Boot> env save Saving Environment to FAT... writing uboot.env FAT: Misaligned buffer address (1db41d78) FAT: Misaligned buffer address (1db43d78) done Misaligned buffer address? Maybe a fsck on the FAT partition should help. Regards, On 26.11.2016 18:35, Ian Lepore wrote: > On Sat, 2016-11-26 at 10:27 +0100, John W. Kitz wrote: >> Ian, >> >> On Sat, 2016-11-26 at 00:07 +0100, diffusae wrote: >>> >>> Hi John, >>> >>> On 25.11.2016 20:56, John W. Kitz wrote: >>> >>>> >>>> >>>> So when doing so the locally administered MAC address is passed >>>> on >>>> from uEnv.txt to the O/S during boot and is then used to >>>> override >>>> the globally >>> I didn't think, that it will be passed from the U-Boot Enviroment >>> settings. You can set the MAC address, but the FreeBSD kernel >>> shows >>> always the unique MAC address. >>> >>>> >>>> >>>> unique MAC address or does the O/S check both the information >>>> found >>>> in its configuration files and what is configured in uEnv.txt >>>> before >>>> configuring and activating the network interface(s)? >>> Which configuration files do you mean? AFAIK there is only the FDT >>> blob. >>> I guess it ignores the setting in uEnv.txt. >>> >>>> >>>> >>>> Makes me wonder which of the two (i.e. locally administered >>>> through >>>> uEnv.txt or locally administered through the O/S) takes >>>> precedence. >>> Only the unique MAC address and the locally administered MAC >>> address, >>> will take affect. >>> >>>> >>>> >>>> In addition this might affect configuration decisions when one >>>> would >>>> want to configure a device for net booting (at least when >>>> browsing >>>> through what can be configured by means of uEnv.txt I believe >>>> that >>>> was one of the options I >>>> saw) through uEnv.txt? >>> Personally, I like u-boot. It has various options, runs on a lot >>> of >>> devices and it's also nice to handle. >>> >>> Best regards, >>> _ >> I looked into this tonight, and there is some code missing in u-boot >> to >> handle passing a mac address set in the u-boot environment into the >> kernel >> via the fdt data. >> >> It would be pretty simple to fix. We need to add an ethernet0 alias >> pointing to the /axi/usb/hub/ethernet node to our rpi dts, and the >> attached >> patch needs to replace the current one in the u-boot-rpi port. >> >> This lets you set usbethaddr in the u-boot environment (via uEnv.txt >> or >> saved directly using saveenv), and it will get used by both u-boot >> and >> freebsd. >> >> Having gotten it this far, I don't really have time right now to get >> the >> patch committed to ports. Hopefully somebody else can help with >> that. >> >> JKi: I was just curious, but have no immediate use for the features >> discussed in this particular thread at this time. So please don't >> make the >> effort to get mentioned changes implemented because of this thread. > > Well, it's wrong and it needs to be fixed. For every other arm board, > you can set a mac addr in u-boot and it remains in effect when freebsd > is running. It's not right for rpi to be different. It probably > affects rpi2 as well. And, really, anything with usb ethernet. > > I wonder why the mailing list is stripping diff attachments now? That > never used to happen. Hrm, probably because after my last pkg upgrade, > Evolution is now flagging the attachment as text/x-csrc; it used to be > x-patch. I've put the patch here... > > https://people.freebsd.org/~ian/patch-common_cmd__boot.c > > -- Ian > > _______________________________________________ > 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 Nov 26 19:35: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 A050DC57FF1 for ; Sat, 26 Nov 2016 19:35:31 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E0251486 for ; Sat, 26 Nov 2016 19:35:30 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-User: 8058a255-b40f-11e6-b17f-19517aec265d X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 73.78.92.27 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [73.78.92.27]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id 8058a255-b40f-11e6-b17f-19517aec265d; Sat, 26 Nov 2016 19:35:36 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id uAQJZM6j011716; Sat, 26 Nov 2016 12:35:22 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <1480188922.1889.114.camel@freebsd.org> Subject: Re: How to change MAC address on RPI-B? From: Ian Lepore To: diffusae , freebsd-arm@freebsd.org Date: Sat, 26 Nov 2016 12:35:22 -0700 In-Reply-To: <6a99a76e-5de7-f2bd-6539-2780444dd2cc@t-online.de> References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <000c01d247c7$452a4db0$cf7ee910$@Kitz@xs4all.nl> <1480181714.1889.103.camel@freebsd.org> <6a99a76e-5de7-f2bd-6539-2780444dd2cc@t-online.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 19:35:31 -0000 On Sat, 2016-11-26 at 20:16 +0100, diffusae wrote: > Hi! > > Does anyone, what this means: > > U-Boot> env save > Saving Environment to FAT... > writing uboot.env > FAT: Misaligned buffer address (1db41d78) > FAT: Misaligned buffer address (1db43d78) > done > > Misaligned buffer address? Maybe a fsck on the FAT partition should > help. > > Regards, > That's a bug in the u-boot code that I've never bothered to track down since it doesn't seem to hurt anything.  It means that the buffer it's using to write the env data to the sdcard is not aligned to a cache line boundary in memory. -- Ian > On 26.11.2016 18:35, Ian Lepore wrote: > > > > On Sat, 2016-11-26 at 10:27 +0100, John W. Kitz wrote: > > > > > > Ian, > > > > > > On Sat, 2016-11-26 at 00:07 +0100, diffusae wrote: > > > > > > > > > > > > Hi John, > > > > > > > > On 25.11.2016 20:56, John W. Kitz wrote: > > > > > > > > > > > > > > > > > > > > > > > > So when doing so the locally administered MAC address is > > > > > passed > > > > > on  > > > > > from uEnv.txt to the O/S during boot and is then used to > > > > > override  > > > > > the globally > > > > I didn't think, that it will be passed from the U-Boot > > > > Enviroment  > > > > settings. You can set the MAC address, but the FreeBSD kernel > > > > shows  > > > > always the unique MAC address. > > > > > > > > > > > > > > > > > > > > > > > > unique MAC address or does the O/S check both the information > > > > > found  > > > > > in its configuration files and what is configured in uEnv.txt > > > > > before  > > > > > configuring and activating the network interface(s)? > > > > Which configuration files do you mean? AFAIK there is only the > > > > FDT  > > > > blob. > > > > I guess it ignores the setting in uEnv.txt. > > > > > > > > > > > > > > > > > > > > > > > > Makes me wonder which of the two (i.e. locally administered > > > > > through  > > > > > uEnv.txt or locally administered through the O/S) takes > > > > > precedence. > > > > Only the unique MAC address and the locally administered MAC > > > > address,  > > > > will take affect. > > > > > > > > > > > > > > > > > > > > > > > > In addition this might affect configuration decisions when > > > > > one > > > > > would  > > > > > want to configure a device for net booting (at least when > > > > > browsing  > > > > > through what can be configured by means of uEnv.txt I believe > > > > > that  > > > > > was one of the options I > > > > > saw) through uEnv.txt? > > > > Personally, I like u-boot. It has various options, runs on a > > > > lot > > > > of  > > > > devices and it's also nice to handle. > > > > > > > > Best regards, > > > > _ > > > I looked into this tonight, and there is some code missing in u- > > > boot > > > to > > > handle passing a mac address set in the u-boot environment into > > > the > > > kernel > > > via the fdt data. > > > > > > It would be pretty simple to fix.  We need to add an ethernet0 > > > alias > > > pointing to the /axi/usb/hub/ethernet node to our rpi dts, and > > > the > > > attached > > > patch needs to replace the current one in the u-boot-rpi port. > > > > > > This lets you set usbethaddr in the u-boot environment (via > > > uEnv.txt > > > or > > > saved directly using saveenv), and it will get used by both u- > > > boot > > > and > > > freebsd. > > > > > > Having gotten it this far, I don't really have time right now to > > > get > > > the > > > patch committed to ports.  Hopefully somebody else can help with > > > that. > > > > > > JKi: I was just curious, but have no immediate use for the > > > features > > > discussed in this particular thread at this time. So please don't > > > make the > > > effort to get mentioned changes implemented because of this > > > thread. > > Well, it's wrong and it needs to be fixed.  For every other arm > > board, > > you can set a mac addr in u-boot and it remains in effect when > > freebsd > > is running.  It's not right for rpi to be different.  It probably > > affects rpi2 as well.  And, really, anything with usb ethernet. > > > > I wonder why the mailing list is stripping diff attachments > > now?  That > > never used to happen.  Hrm, probably because after my last pkg > > upgrade, > > Evolution is now flagging the attachment as text/x-csrc; it used to > > be > > x-patch.  I've put the patch here... > > > > https://people.freebsd.org/~ian/patch-common_cmd__boot.c > > > > -- Ian > > > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.o > > rg" > > > _______________________________________________ > 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 Nov 26 20:15: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 B7DE0C57BBA for ; Sat, 26 Nov 2016 20:15:48 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from mailout07.t-online.de (mailout07.t-online.de [194.25.134.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mailout00.t-online.de", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7A79C99C; Sat, 26 Nov 2016 20:15:48 +0000 (UTC) (envelope-from punasipuli@t-online.de) Received: from fwd32.aul.t-online.de (fwd32.aul.t-online.de [172.20.26.144]) by mailout07.t-online.de (Postfix) with SMTP id 0D2A9425B7BC; Sat, 26 Nov 2016 21:15:39 +0100 (CET) Received: from [192.168.10.43] (r22jewZ6YhBthu5GPnKgtYfLAGrjL42dBgzvmRsUZ2Iz4sEJVUOuQvMJ51+mVsxQl4@[86.56.56.128]) by fwd32.t-online.de with (TLSv1.2:ECDHE-RSA-AES256-SHA encrypted) esmtp id 1cAjNq-1zKi120; Sat, 26 Nov 2016 21:15:38 +0100 Subject: Re: How to change MAC address on RPI-B? To: Ian Lepore , freebsd-arm@freebsd.org References: <001701d245ce$e64e33f0$b2ea9bd0$@Kitz@xs4all.nl> <454137dc-30f7-cd33-6c75-0cc3045090dd@t-online.de> <002801d24755$f9017420$eb045c60$@Kitz@xs4all.nl> <177ae37f-db52-c7ee-77fa-d9bc7d61b4ee@t-online.de> <1480137537.1889.97.camel@freebsd.org> <000c01d247c7$452a4db0$cf7ee910$@Kitz@xs4all.nl> <1480181714.1889.103.camel@freebsd.org> <6a99a76e-5de7-f2bd-6539-2780444dd2cc@t-online.de> <1480188922.1889.114.camel@freebsd.org> From: diffusae Message-ID: Date: Sat, 26 Nov 2016 21:15:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1480188922.1889.114.camel@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-ID: r22jewZ6YhBthu5GPnKgtYfLAGrjL42dBgzvmRsUZ2Iz4sEJVUOuQvMJ51+mVsxQl4 X-TOI-MSGID: 6a6ea098-5ed3-400c-80db-ef4bc232f293 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Nov 2016 20:15:48 -0000 Yes, it really looks like that and it doesn't hurt anything. I only was wondering about that. Thanks for your explanation. I don't have svn write access, so I cannot commit your changes to ports. Best regards, On 26.11.2016 20:35, Ian Lepore wrote: > That's a bug in the u-boot code that I've never bothered to track down > since it doesn't seem to hurt anything. It means that the buffer it's > using to write the env data to the sdcard is not aligned to a cache > line boundary in memory. > > -- Ian