From owner-freebsd-arm@freebsd.org  Sun Sep 25 00:19:08 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 2A25BBDE2EC
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Sun, 25 Sep 2016 00:19:08 +0000 (UTC)
 (envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-63.reflexion.net
 [208.70.210.63])
 (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 DE7FD84E
 for <freebsd-arm@freebsd.org>; Sun, 25 Sep 2016 00:19:07 +0000 (UTC)
 (envelope-from markmi@dsl-only.net)
Received: (qmail 9165 invoked from network); 25 Sep 2016 00:12:26 -0000
Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1)
 by 0 (rfx-qmail) with SMTP; 25 Sep 2016 00:12:26 -0000
Received: by mail-cs-01.app.dca.reflexion.local
 (Reflexion email security v8.00.0) with SMTP;
 Sat, 24 Sep 2016 20:12:32 -0400 (EDT)
Received: (qmail 28171 invoked from network); 25 Sep 2016 00:12:31 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
 by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Sep 2016 00:12:31 -0000
Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net
 [70.189.131.151])
 by iron2.pdx.net (Postfix) with ESMTPSA id 4D64FEC8FEB;
 Sat, 24 Sep 2016 17:12:25 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
From: Mark Millard <markmi@dsl-only.net>
In-Reply-To: <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
Date: Sat, 24 Sep 2016 17:12:24 -0700
Cc: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
 freebsd-arm <freebsd-arm@freebsd.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
To: Warner Losh <imp@bsdimp.com>
X-Mailer: Apple Mail (2.3124)
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 00:19:08 -0000

On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote:

> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> =
wrote:
>> [A resend since I forget to list free-arm in the To: the first time.]
>>=20
>> =46rom https://www.freebsd.org/platforms/arm.html :
>>=20
>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD =
project does not provide official releases or pre-built packages for =
this platform due to it primarily targeting the embedded arena. However, =
FreeBSD/ARM is being actively developed and maintained, is well =
supported, and provides an excellent framework for building ARM-based =
systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 =
supports ARMv6 and ARMv7 processors, including SMP on the latter.
>>=20
>> "does not provide official releases or pre-built packages"?
>>=20
>>> # uname -apKU
>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: =
Sun Aug 28 03:17:54 PDT 2016     =
markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG  arm =
armv6 1100502 1100502
>>=20
>>> # pkg search '.*' | wc
>>>  21349  155540 1596736
>>=20
>> Will 11.0-RELEASE change the tier level for any of the specific =
arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files =
built, such as for RPI2?
>>=20
>> Even if all the officially built arm-armv6 variants stay tier 2, the =
wording on the web page likely needs to be changed because so much is =
built and available that the above quote claims is not available.
>=20
> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
> amd64 due to the fragmented nature of the arm world. On the platforms
> we run on and create releases for, however, it's my opinion that it is
> Tier 1: it has been running in production a while, things people
> expect from a FreeBSD system are present, you can get decent support
> if you ask questions, there's no known major gotchas in deploying this
> hardware. The only remaining annoying issue is the 'u-boot' problem
> where we have to have a different u-boot image for every board and no
> standardized way to convert a 'generic' image into one that's specific
> for specific boards. For x86 this is all done with the installer since
> that boot environment is more standardized. Does this last issue keep
> arm from being Tier 1? That's a judgement call, but I think the
> project should promote w/o this last issue.

Interesting and good to know. Thanks.

I might have guessed that going along with the u-boot issue would be the =
fanout in:

11.0/sys/arm/ . . .

allwinner/a10/
allwinner/a20/
allwinner/a31/
allwinner/a83t/
allwinner/h3/
. . .
broadcom/bcm2835/
. . .

(Full list not shown.)

I was thinking that this might make the tier level specific to the =
status of each such directory's content so that it was the combination =
of that and the sysutils/u-boot-*/ status that made the difference for =
assigning the level.  I'd guess that lack of a usable directory in =
either place would not be tier 2 even. Similarly until the required =
sys/arm/*/* and sysutils/u-boot-*/ directory-tree content have reached a =
sufficiently complete status.

I'd expect that there will always be a lag for what exists in the world =
vs. what has these materials worked out in FreeBSD.


>> Also from https://www.freebsd.org/platforms/arm.html :
>>=20
>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms =
follow a set of standard conventions, and a single FreeBSD build will =
work on hardware from multiple vendors. As a result, FreeBSD will =
provide official releases for FreeBSD/arm64 and packages will be =
available. FreeBSD/arm64 is on the path to becoming a Tier 1 =
architecture.
>>=20
>> Will 11.0-RELEASE make arm64/aarch64 Tier 1?
>>=20
>> [I will note that, while there are no official builds for the Pine64 =
family (A64 based) that are under the Allwinner arm activity, the SOC's =
involved are Cortex-A53 64-bit arm based. They likely do not fit in the =
"standard conventions" or arm64/aarch64 would be where they would have =
been supported. Some rewording might be appropriate for the above quote =
as well.]
>=20
> No. aarch64 isn't Tier 1 yet. There's many small bits that are
> missing. It is quite solidly Tier 2, but we don't have a linker, we
> don't have widespread hardware availability, we don't have production
> experience with the platform. Most things work, but there's still some
> gotchas. There's still the 'u-boot' problem with many arm64 systems
> because for systems that use u-boot to bootstrap UEFI, you need a
> different image for each board (some closely related board families
> can get by with one to be pedantic). All these issues are still
> significant barriers to production use. It's not been officially
> promoted yet and I don't think the time is quite right yet.

Intersting as well. I'd guess that conceptually this probably would =
apply to both:

sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/
(presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ )

and. . .

sys/arm64/cavium/
sys/arm64/cloudabi64/

So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a =
difference yet for tier level.

> Warner

Thanks again for the notes.

=3D=3D=3D
Mark Millard
markmi at dsl-only.net


From owner-freebsd-arm@freebsd.org  Sun Sep 25 04:21:09 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 47033BE9707;
 Sun, 25 Sep 2016 04:21:09 +0000 (UTC)
 (envelope-from russ.haley@gmail.com)
Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com
 [IPv6:2607:f8b0:400c:c05::22f])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id F29CBEA4;
 Sun, 25 Sep 2016 04:21:08 +0000 (UTC)
 (envelope-from russ.haley@gmail.com)
Received: by mail-vk0-x22f.google.com with SMTP id z126so18820319vkd.0;
 Sat, 24 Sep 2016 21:21:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=HR5m8jhBvw3EId8GNMY/0AwEF4ng6yUm5Kwml8joCLU=;
 b=LB9kOPUaP8ZwPG/EbHcn8/lziBYfTj5VpjqVrx9m/1aBVJe0G8qVTFcz/ZhxgLlDF5
 NZfZ7bx+ZwOe262U9eITWjy0D3TwjNGvokHhw4jo3nxGGsnmVdDCwcqzvHUepblPHCOD
 GcrK1Wtr6s2J0paz2PXCjMBfSAHapuKG4KvdZtAVuaOxfX9kSYFZdjPalu146QHZndUp
 C6PUb5PSscKKkgvY1Y9lEkQ4fpl/V/xZZrvxuiZEnl4LCwsFH5BzK6jJVx+tptqqbBkq
 4u+lbHh4jgnzqUIoJRfRNhHQrMx9O9mgTnOfxCmv/SDW8y1IdcBnAiInx09mDxk+kvRs
 eTzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=HR5m8jhBvw3EId8GNMY/0AwEF4ng6yUm5Kwml8joCLU=;
 b=aEzA/aY+g0erehnIFD9QWQ3c0G5pXvS/xXpu5j2krjLg5Lo7SKC02kDqCuTAJdrXhH
 sxXTETEv9mmj5Q0q0xfwdvtVRDpbDbjVcFAB5ZcGfQpzRchO1p/m7bZUthkL8DknaAG4
 IyuDvQ1FeC87mtVce0dJ1HdvQ5tPxf7BbSonGiQJ2t8nHQsuJ+C7CZd5lcbWju1A+Rxo
 l/ZQCaRRV2bpc7fSKGvETKvLd5o+r7bn7al7FGLZlZIVrqy4yHF8xt0Men7fh79UKV26
 4EaIX/1y7ajnxGv6wICuKBcEbwxEyUtSIMU06+oI0Y2JydIe3azocEsnJ1NOvGPo/DIi
 j3jg==
X-Gm-Message-State: AA6/9RlTJ6EWZTt2BEQxAGAOu4XwnnpeAlo8NnkrN0Qv8rzb3tRpH43LFI8PZzRqn2mHAnhr1uCytMY6dIcvkA==
X-Received: by 10.31.242.206 with SMTP id q197mr3668053vkh.46.1474777268017;
 Sat, 24 Sep 2016 21:21:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.124.202 with HTTP; Sat, 24 Sep 2016 21:21:07 -0700 (PDT)
In-Reply-To: <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
 <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
From: Russell Haley <russ.haley@gmail.com>
Date: Sat, 24 Sep 2016 21:21:07 -0700
Message-ID: <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
To: Mark Millard <markmi@dsl-only.net>
Cc: Warner Losh <imp@bsdimp.com>, freebsd-arm <freebsd-arm@freebsd.org>, 
 FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 04:21:09 -0000

On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard <markmi@dsl-only.net> wrote:
> On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote:
>
>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> wrot=
e:
>>> [A resend since I forget to list free-arm in the To: the first time.]
>>>
>>> From https://www.freebsd.org/platforms/arm.html :
>>>
>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project=
 does not provide official releases or pre-built packages for this platform=
 due to it primarily targeting the embedded arena. However, FreeBSD/ARM is =
being actively developed and maintained, is well supported, and provides an=
 excellent framework for building ARM-based systems. FreeBSD/arm supports A=
RMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processor=
s, including SMP on the latter.
>>>
>>> "does not provide official releases or pre-built packages"?
>>>
>>>> # uname -apKU
>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun =
Aug 28 03:17:54 PDT 2016     markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr=
/src/sys/RPI2-NODBG  arm armv6 1100502 1100502
>>>
>>>> # pkg search '.*' | wc
>>>>  21349  155540 1596736
>>>
>>> Will 11.0-RELEASE change the tier level for any of the specific arm-arm=
v6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such as =
for RPI2?
>>>
>>> Even if all the officially built arm-armv6 variants stay tier 2, the wo=
rding on the web page likely needs to be changed because so much is built a=
nd available that the above quote claims is not available.
>>
>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
>> amd64 due to the fragmented nature of the arm world. On the platforms
>> we run on and create releases for, however, it's my opinion that it is
>> Tier 1: it has been running in production a while, things people
>> expect from a FreeBSD system are present, you can get decent support
>> if you ask questions, there's no known major gotchas in deploying this
>> hardware. The only remaining annoying issue is the 'u-boot' problem
>> where we have to have a different u-boot image for every board and no
>> standardized way to convert a 'generic' image into one that's specific
>> for specific boards.

I'll point out again that barebox is an excellent alternative to u-boot (IM=
HO):
- Supports most, if not all of the boards that FreeBSD supports, plus
many that it doesn't
- Single source tree for all boards. Specify build time parameters to
build one or all the images
- Well supported community with central maintainer-ship
- Simple, familiar shell interface  (*awesome*)
- Excellent documentation (u-boots is good too though)
- Has support for (U)EFI
- Supports quemu aarch64 (not *quite*sure what the means though)

To be fair, I'm not saying the problem is the fault of denx, but
barebox has a lot going for it. The maintainer was very keen to see it
ported top FreeBSD and was willing to support the effort. I ran into
some build time linux api requirements, but he didn't think that would
be much to overcome (and it wasn't I just kept adding the patches he
sent me and the build moved forward. As always, I ran out of time for
the really fun stuff). While I am a hopeless dreamer and I'm sure I've
over simplified the problem, I thought it would be neat to see FreeBSD
upstream support for zfs and ufs to the barebox boot loader and do
away with ubldr. We would then have a modern, easy to use, boot loader
that supports the standard startup toolchain.

Either way, if installers move to a pkgng based method (so cool) then
installing u-boot and arm binaries from pkg-static will be the same as
x86 (ha ha I said that with a straight face!).

>>For x86 this is all done with the installer since
>> that boot environment is more standardized. Does this last issue keep
>> arm from being Tier 1? That's a judgement call, but I think the
>> project should promote w/o this last issue.

How does a platform get promoted? Is that something the Core team decides?

I see two facts about current Arm support that show platform maturity:
a) u-boot is in the ports tree and we have Lego-easy build scripts in
crochet that could be called an installation method. Building for arm
is not difficult anymore.
b)Arm requires images, not installers. Correct me if I'm wrong but,
installers are a tool primarily invented for x86 PC type computers.
FreeBSD publishes standardized ISOs for all supported Arm platforms
that work by simply "xzcat | dd" onto the sd card (or wherever you
need it).   I'm not sure how standardized or manual that build process
is, but I would think that if the Arm platform support is able to keep
up with the standard FreeBSD release cycle (i.e. not break every other
release) then there would be no reason to NOT call it tier 1?

What I don't know about is "official" documentation for building for
arm and supporting cross building to Arm. Will someone need to write
an "Arm Handbook" to be promoted?

Cheers,
Russ

>
> Interesting and good to know. Thanks.
>
> I might have guessed that going along with the u-boot issue would be the =
fanout in:
>
> 11.0/sys/arm/ . . .
>
> allwinner/a10/
> allwinner/a20/
> allwinner/a31/
> allwinner/a83t/
> allwinner/h3/
> . . .
> broadcom/bcm2835/
> . . .
>
> (Full list not shown.)
>
> I was thinking that this might make the tier level specific to the status=
 of each such directory's content so that it was the combination of that an=
d the sysutils/u-boot-*/ status that made the difference for assigning the =
level.  I'd guess that lack of a usable directory in either place would not=
 be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-bo=
ot-*/ directory-tree content have reached a sufficiently complete status.
>
> I'd expect that there will always be a lag for what exists in the world v=
s. what has these materials worked out in FreeBSD.
>
>
>>> Also from https://www.freebsd.org/platforms/arm.html :
>>>
>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms follo=
w a set of standard conventions, and a single FreeBSD build will work on ha=
rdware from multiple vendors. As a result, FreeBSD will provide official re=
leases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is o=
n the path to becoming a Tier 1 architecture.
>>>
>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1?
>>>
>>> [I will note that, while there are no official builds for the Pine64 fa=
mily (A64 based) that are under the Allwinner arm activity, the SOC's invol=
ved are Cortex-A53 64-bit arm based. They likely do not fit in the "standar=
d conventions" or arm64/aarch64 would be where they would have been support=
ed. Some rewording might be appropriate for the above quote as well.]
>>
>> No. aarch64 isn't Tier 1 yet. There's many small bits that are
>> missing. It is quite solidly Tier 2, but we don't have a linker, we
>> don't have widespread hardware availability, we don't have production
>> experience with the platform. Most things work, but there's still some
>> gotchas. There's still the 'u-boot' problem with many arm64 systems
>> because for systems that use u-boot to bootstrap UEFI, you need a
>> different image for each board (some closely related board families
>> can get by with one to be pedantic). All these issues are still
>> significant barriers to production use. It's not been officially
>> promoted yet and I don't think the time is quite right yet.
>
> Intersting as well. I'd guess that conceptually this probably would apply=
 to both:
>
> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/
> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ )
>
> and. . .
>
> sys/arm64/cavium/
> sys/arm64/cloudabi64/
>
> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a di=
fference yet for tier level.
>
>> Warner
>
> Thanks again for the notes.
>
> =3D=3D=3D
> 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  Sun Sep 25 06:10:47 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 2A8B5BE8B05
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Sun, 25 Sep 2016 06:10:47 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: from mail-it0-x235.google.com (mail-it0-x235.google.com
 [IPv6:2607:f8b0:4001:c0b::235])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id E2B2162B
 for <freebsd-arm@freebsd.org>; Sun, 25 Sep 2016 06:10:46 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: by mail-it0-x235.google.com with SMTP id o3so48677458ita.1
 for <freebsd-arm@freebsd.org>; Sat, 24 Sep 2016 23:10:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bsdimp-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc:content-transfer-encoding;
 bh=uGkLDd2L62s0iz+iWbFM5qC1zvqnVU/ulEAtpR38sV8=;
 b=H7VMloZcBldbBRdlpytXeLIIMvgLJH/91BWZd8oQkXvszI7lh1doFw9GGQZIbFan7q
 z4JHkKp+jdLuLW7XF+7OS+V4ZIkcIfQ9cbiS6G8CAsD2f5UmAtsZUWYtDIx1p7sI6453
 AZR4YmpogVpeH1/tS3ZxXPsHGNVtQ7kldce1a4V4fHf+nw4lBbYkdtRNpto6vnY3Pis9
 7XJ1gdwwXIWgCDmq3qEWVIGRKnmMUT31OHzWPGAhcaTZMd3Hh4j6aXYfw8C3lNbgA/RY
 o2a0Z6Rwp+o79MOPbGXfMYktvJ5jgrKAUAdSnFiKsUKl4Ip6y0VAaxFi8TCYT9QKufDO
 pzLg==
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=uGkLDd2L62s0iz+iWbFM5qC1zvqnVU/ulEAtpR38sV8=;
 b=GZ2YbsMEYBGwoacH+rcqXPGFJ93PlLZCrahKHyEo+B3QCZIuyUZVAyCmR+zGcR6H++
 vL3iAl+1/Hdotau3xIkENScadq4jONyo2OCY91onTK8XaF8/YBPDTyNXxklm1/EWuSuU
 keRLINNhOxAgLCapLmXJr/wmU4lkJKQsDtK6XmLk7dU9MJOmltUQvRDLIfAA3WwF7ppj
 Uzuzqst04cKlZphdWt6EuaZNnYW65G5a5yyLSuV6smiL080t07uv4/xaxZIHqy65oXv1
 wGB38okSm1kyWZ0RBVIQ5w9eFwVK3fEu7WDCV3OHpuRQG/7j6TMTtM9TeCSd5usSSB3i
 3pKg==
X-Gm-Message-State: AA6/9RnCzPq5RSkZIKvU3PBB5RV87SoGvTcJJ1xu9sBgVZbCgy7YTwKxcDjT3B5MeDMAlZIVm0vtK/3/VpPpBA==
X-Received: by 10.36.58.133 with SMTP id m127mr931821itm.79.1474783845897;
 Sat, 24 Sep 2016 23:10:45 -0700 (PDT)
MIME-Version: 1.0
Sender: wlosh@bsdimp.com
Received: by 10.36.65.7 with HTTP; Sat, 24 Sep 2016 23:10:45 -0700 (PDT)
X-Originating-IP: [69.53.245.200]
In-Reply-To: <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
 <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
 <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Sun, 25 Sep 2016 00:10:45 -0600
X-Google-Sender-Auth: 2ppeaJ_eoltWttM19XyzCBbiCKo
Message-ID: <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF+EEwww@mail.gmail.com>
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
To: Russell Haley <russ.haley@gmail.com>
Cc: Mark Millard <markmi@dsl-only.net>, freebsd-arm <freebsd-arm@freebsd.org>, 
 FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 06:10:47 -0000

On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley <russ.haley@gmail.com> wrot=
e:
> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard <markmi@dsl-only.net> wrote=
:
>> On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote:
>>
>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> wro=
te:
>>>> [A resend since I forget to list free-arm in the To: the first time.]
>>>>
>>>> From https://www.freebsd.org/platforms/arm.html :
>>>>
>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD projec=
t does not provide official releases or pre-built packages for this platfor=
m due to it primarily targeting the embedded arena. However, FreeBSD/ARM is=
 being actively developed and maintained, is well supported, and provides a=
n excellent framework for building ARM-based systems. FreeBSD/arm supports =
ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processo=
rs, including SMP on the latter.
>>>>
>>>> "does not provide official releases or pre-built packages"?
>>>>
>>>>> # uname -apKU
>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun=
 Aug 28 03:17:54 PDT 2016     markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/us=
r/src/sys/RPI2-NODBG  arm armv6 1100502 1100502
>>>>
>>>>> # pkg search '.*' | wc
>>>>>  21349  155540 1596736
>>>>
>>>> Will 11.0-RELEASE change the tier level for any of the specific arm-ar=
mv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such as=
 for RPI2?
>>>>
>>>> Even if all the officially built arm-armv6 variants stay tier 2, the w=
ording on the web page likely needs to be changed because so much is built =
and available that the above quote claims is not available.
>>>
>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
>>> amd64 due to the fragmented nature of the arm world. On the platforms
>>> we run on and create releases for, however, it's my opinion that it is
>>> Tier 1: it has been running in production a while, things people
>>> expect from a FreeBSD system are present, you can get decent support
>>> if you ask questions, there's no known major gotchas in deploying this
>>> hardware. The only remaining annoying issue is the 'u-boot' problem
>>> where we have to have a different u-boot image for every board and no
>>> standardized way to convert a 'generic' image into one that's specific
>>> for specific boards.
>
> I'll point out again that barebox is an excellent alternative to u-boot (=
IMHO):

Doesn't matter, still has the same issues that u-boot has.

But does it support the u-boot ABI?

> - Supports most, if not all of the boards that FreeBSD supports, plus
> many that it doesn't
> - Single source tree for all boards. Specify build time parameters to
> build one or all the images
> - Well supported community with central maintainer-ship
> - Simple, familiar shell interface  (*awesome*)
> - Excellent documentation (u-boots is good too though)
> - Has support for (U)EFI
> - Supports quemu aarch64 (not *quite*sure what the means though)

Right, u-boot has all these things, except maybe the shell interface
(not sure what you mean by that).

> To be fair, I'm not saying the problem is the fault of denx, but
> barebox has a lot going for it. The maintainer was very keen to see it
> ported top FreeBSD and was willing to support the effort. I ran into
> some build time linux api requirements, but he didn't think that would
> be much to overcome (and it wasn't I just kept adding the patches he
> sent me and the build moved forward. As always, I ran out of time for
> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
> over simplified the problem, I thought it would be neat to see FreeBSD
> upstream support for zfs and ufs to the barebox boot loader and do
> away with ubldr. We would then have a modern, easy to use, boot loader
> that supports the standard startup toolchain.

We can't easily do away with ubldr if we want to support tunables, kernel
modules loaded at boot time and a few other nifty features like nextboot.

> Either way, if installers move to a pkgng based method (so cool) then
> installing u-boot and arm binaries from pkg-static will be the same as
> x86 (ha ha I said that with a straight face!).

Yea, not so much. You have to build the bootable image not on the
target system, like you do on x86. We'd have to have something that
installs uboot onto a generic image (perhaps with hooks for kernels
since those aren't generic on armv6) and then put that into a bootable
SD card.

>>>For x86 this is all done with the installer since
>>> that boot environment is more standardized. Does this last issue keep
>>> arm from being Tier 1? That's a judgement call, but I think the
>>> project should promote w/o this last issue.
>
> How does a platform get promoted? Is that something the Core team decides=
?

Yes.

> I see two facts about current Arm support that show platform maturity:
> a) u-boot is in the ports tree and we have Lego-easy build scripts in
> crochet that could be called an installation method. Building for arm
> is not difficult anymore.

Except corchet isn't in the tree, and the solution is horrible. It's
a script for each SoC, and those scripts are now scattered about.
Plus that's a creation from source model, not a creation from
RE produced bits model, which is needed for Tier 1.

> b)Arm requires images, not installers. Correct me if I'm wrong but,
> installers are a tool primarily invented for x86 PC type computers.
> FreeBSD publishes standardized ISOs for all supported Arm platforms
> that work by simply "xzcat | dd" onto the sd card (or wherever you
> need it).   I'm not sure how standardized or manual that build process
> is, but I would think that if the Arm platform support is able to keep
> up with the standard FreeBSD release cycle (i.e. not break every other
> release) then there would be no reason to NOT call it tier 1?

Creating the images is currently a pita. That's it.

> What I don't know about is "official" documentation for building for
> arm and supporting cross building to Arm. Will someone need to write
> an "Arm Handbook" to be promoted?

No. While useful, most of that already exists.

Warner

>> Interesting and good to know. Thanks.
>>
>> I might have guessed that going along with the u-boot issue would be the=
 fanout in:
>>
>> 11.0/sys/arm/ . . .
>>
>> allwinner/a10/
>> allwinner/a20/
>> allwinner/a31/
>> allwinner/a83t/
>> allwinner/h3/
>> . . .
>> broadcom/bcm2835/
>> . . .
>>
>> (Full list not shown.)
>>
>> I was thinking that this might make the tier level specific to the statu=
s of each such directory's content so that it was the combination of that a=
nd the sysutils/u-boot-*/ status that made the difference for assigning the=
 level.  I'd guess that lack of a usable directory in either place would no=
t be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-b=
oot-*/ directory-tree content have reached a sufficiently complete status.
>>
>> I'd expect that there will always be a lag for what exists in the world =
vs. what has these materials worked out in FreeBSD.
>>
>>
>>>> Also from https://www.freebsd.org/platforms/arm.html :
>>>>
>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms foll=
ow a set of standard conventions, and a single FreeBSD build will work on h=
ardware from multiple vendors. As a result, FreeBSD will provide official r=
eleases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is =
on the path to becoming a Tier 1 architecture.
>>>>
>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1?
>>>>
>>>> [I will note that, while there are no official builds for the Pine64 f=
amily (A64 based) that are under the Allwinner arm activity, the SOC's invo=
lved are Cortex-A53 64-bit arm based. They likely do not fit in the "standa=
rd conventions" or arm64/aarch64 would be where they would have been suppor=
ted. Some rewording might be appropriate for the above quote as well.]
>>>
>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are
>>> missing. It is quite solidly Tier 2, but we don't have a linker, we
>>> don't have widespread hardware availability, we don't have production
>>> experience with the platform. Most things work, but there's still some
>>> gotchas. There's still the 'u-boot' problem with many arm64 systems
>>> because for systems that use u-boot to bootstrap UEFI, you need a
>>> different image for each board (some closely related board families
>>> can get by with one to be pedantic). All these issues are still
>>> significant barriers to production use. It's not been officially
>>> promoted yet and I don't think the time is quite right yet.
>>
>> Intersting as well. I'd guess that conceptually this probably would appl=
y to both:
>>
>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/
>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ )
>>
>> and. . .
>>
>> sys/arm64/cavium/
>> sys/arm64/cloudabi64/
>>
>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a d=
ifference yet for tier level.
>>
>>> Warner
>>
>> Thanks again for the notes.
>>
>> =3D=3D=3D
>> 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  Sun Sep 25 07:13:34 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 EFEABBE97D4;
 Sun, 25 Sep 2016 07:13:34 +0000 (UTC)
 (envelope-from russ.haley@gmail.com)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com
 [IPv6:2607:f8b0:400c:c08::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 AA9D71AC;
 Sun, 25 Sep 2016 07:13:34 +0000 (UTC)
 (envelope-from russ.haley@gmail.com)
Received: by mail-ua0-x230.google.com with SMTP id q42so80503861uaq.1;
 Sun, 25 Sep 2016 00:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=3w18S6CCpMbBbLQxKd8MkMZ4N+6E7eGEY06c06Td6pU=;
 b=PTl/HldNjG7KiUs5wNtM0cJ+lhvcsw93zL7vgz224BD/yU/MmsPxHAQuv6Iveuv6p0
 ra15D6naSj8E53PANRefr/Qxr4JF6YtBYZ+BlNo5vzHAnjOIRwCPrk3t7e5oCkTyLPmC
 HNcIA7Jvpu2ZYHhy1uvDK3hs2Eeuzh26/GXvrEOQUGx15j/2J5BXTQimUo4J4Kmi8zrJ
 qCfB7wI0muhzRKfO8j6wNKPJxBSurfrpDRYk4jsP3B65U3JqZZRCfnyT7YzKPJsoGgWc
 jSeBb08KgsVDvGDrwU0Eya6M4BhLUIGSFX9cWbPXCN9jTvLtUzYMwBHiK+wm+HoPI1NC
 p7aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=3w18S6CCpMbBbLQxKd8MkMZ4N+6E7eGEY06c06Td6pU=;
 b=EDjEi3vxlwwptxgugmnxDZP5qruis0vAU0eY2CgMs6kk+Ra4tvvKX30PodvEZArghi
 8GiJiuKKHl9L5j67zr+bKk5GUjb2b0Oo3JNFJSP8p3Bac/h5yVkd6o8xoC4RSJPaT4Ko
 BsvZPl55VBw5VyOtFTc+Qo1MqJ0CUiBrlz4jKXYFSTW96rFEcMax1S1exKx8n3hbbzGV
 2tGEixTOJi/pU536ah2Zi85g4h5Ivnk8aG53hn7wB+L7f5fJrtiqcnkE3Fdcbi7WhZOJ
 uLsPTBLian5nG9CNuFYFRKScCbCrLGey+ymUujfqDWTNudS2PxxhnByEPG5pqqjv3kAM
 vlOA==
X-Gm-Message-State: AA6/9Rnbm1pfW2+SabB+2ADBqYVgn+xQxd4SNag1W4oC3Oc9kI8jPxGfXhMlclM5CiwjwungLRl1EXyT9EIVFA==
X-Received: by 10.176.3.197 with SMTP id 63mr7815345uau.149.1474787613540;
 Sun, 25 Sep 2016 00:13:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.124.202 with HTTP; Sun, 25 Sep 2016 00:13:31 -0700 (PDT)
In-Reply-To: <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF+EEwww@mail.gmail.com>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
 <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
 <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
 <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF+EEwww@mail.gmail.com>
From: Russell Haley <russ.haley@gmail.com>
Date: Sun, 25 Sep 2016 00:13:31 -0700
Message-ID: <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com>
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
To: Warner Losh <imp@bsdimp.com>
Cc: Mark Millard <markmi@dsl-only.net>, freebsd-arm <freebsd-arm@freebsd.org>, 
 FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 07:13:35 -0000

On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh <imp@bsdimp.com> wrote:
> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley <russ.haley@gmail.com> wr=
ote:
>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard <markmi@dsl-only.net> wrot=
e:
>>> On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote:
>>>
>>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> wr=
ote:
>>>>> [A resend since I forget to list free-arm in the To: the first time.]
>>>>>
>>>>> From https://www.freebsd.org/platforms/arm.html :
>>>>>
>>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD proje=
ct does not provide official releases or pre-built packages for this platfo=
rm due to it primarily targeting the embedded arena. However, FreeBSD/ARM i=
s being actively developed and maintained, is well supported, and provides =
an excellent framework for building ARM-based systems. FreeBSD/arm supports=
 ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 process=
ors, including SMP on the latter.
>>>>>
>>>>> "does not provide official releases or pre-built packages"?
>>>>>
>>>>>> # uname -apKU
>>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Su=
n Aug 28 03:17:54 PDT 2016     markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/u=
sr/src/sys/RPI2-NODBG  arm armv6 1100502 1100502
>>>>>
>>>>>> # pkg search '.*' | wc
>>>>>>  21349  155540 1596736
>>>>>
>>>>> Will 11.0-RELEASE change the tier level for any of the specific arm-a=
rmv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such a=
s for RPI2?
>>>>>
>>>>> Even if all the officially built arm-armv6 variants stay tier 2, the =
wording on the web page likely needs to be changed because so much is built=
 and available that the above quote claims is not available.
>>>>
>>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
>>>> amd64 due to the fragmented nature of the arm world. On the platforms
>>>> we run on and create releases for, however, it's my opinion that it is
>>>> Tier 1: it has been running in production a while, things people
>>>> expect from a FreeBSD system are present, you can get decent support
>>>> if you ask questions, there's no known major gotchas in deploying this
>>>> hardware. The only remaining annoying issue is the 'u-boot' problem
>>>> where we have to have a different u-boot image for every board and no
>>>> standardized way to convert a 'generic' image into one that's specific
>>>> for specific boards.
>>
>> I'll point out again that barebox is an excellent alternative to u-boot =
(IMHO):
>
> Doesn't matter, still has the same issues that u-boot has.
u-boot has a different sources for almost each board we support (due
to the usual FOSS issues). That is NOT the case in barebox. There is
one source and it's kept up to date by the team, not the vendors.

> But does it support the u-boot ABI?
I'd have to look into this.
>
>> - Supports most, if not all of the boards that FreeBSD supports, plus
>> many that it doesn't
>> - Single source tree for all boards. Specify build time parameters to
>> build one or all the images
>> - Well supported community with central maintainer-ship
>> - Simple, familiar shell interface  (*awesome*)
>> - Excellent documentation (u-boots is good too though)
>> - Has support for (U)EFI
>> - Supports quemu aarch64 (not *quite*sure what the means though)
>
> Right, u-boot has all these things, except maybe the shell interface
> (not sure what you mean by that).
Instead of stringing together variables and commands, it uses a
scripting language like a simplified sh. Want to change how something
boots? Update a script. Save it to disk (it has it's own persistence
mechanisms) and export it.

>> To be fair, I'm not saying the problem is the fault of denx, but
>> barebox has a lot going for it. The maintainer was very keen to see it
>> ported top FreeBSD and was willing to support the effort. I ran into
>> some build time linux api requirements, but he didn't think that would
>> be much to overcome (and it wasn't I just kept adding the patches he
>> sent me and the build moved forward. As always, I ran out of time for
>> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
>> over simplified the problem, I thought it would be neat to see FreeBSD
>> upstream support for zfs and ufs to the barebox boot loader and do
>> away with ubldr. We would then have a modern, easy to use, boot loader
>> that supports the standard startup toolchain.
>
> We can't easily do away with ubldr if we want to support tunables, kernel
> modules loaded at boot time and a few other nifty features like nextboot.

Are these things not in standard loader? Should they be?

>> Either way, if installers move to a pkgng based method (so cool) then
>> installing u-boot and arm binaries from pkg-static will be the same as
>> x86 (ha ha I said that with a straight face!).
>
> Yea, not so much. You have to build the bootable image not on the
> target system, like you do on x86.

Doesn't the current ports and packages cross build everything that's marked=
?

> We'd have to have something that
> installs uboot onto a generic image (perhaps with hooks for kernels
> since those aren't generic on armv6) and then put that into a bootable
> SD card.

The x86 installer (that I argue is a platform legacy) has to customize
the bootloader for each installation. If we HAVE to use an installer
on arm, what wrong prompting the user for some input (i.e. what som
are you using) while including all the u-boots  in the ports tree and
all the supported kernels, then just installing the correct ones for
the board (with input from the user)?

>>>>For x86 this is all done with the installer since
>>>> that boot environment is more standardized. Does this last issue keep
>>>> arm from being Tier 1? That's a judgement call, but I think the
>>>> project should promote w/o this last issue.
>>
>> How does a platform get promoted? Is that something the Core team decide=
s?
>
> Yes.
>
>> I see two facts about current Arm support that show platform maturity:
>> a) u-boot is in the ports tree and we have Lego-easy build scripts in
>> crochet that could be called an installation method. Building for arm
>> is not difficult anymore.
>
> Except corchet isn't in the tree, and the solution is horrible. It's
> a script for each SoC, and those scripts are now scattered about.
> Plus that's a creation from source model, not a creation from
> RE produced bits model, which is needed for Tier 1.
Both correctable sins, especially as it's BSD licensed. My point was
that even building a SOM specific image is relatively painless with
the right scripts. Hell, I've even got a custom build script that
could be modified for generic use.

>> b)Arm requires images, not installers. Correct me if I'm wrong but,
>> installers are a tool primarily invented for x86 PC type computers.
>> FreeBSD publishes standardized ISOs for all supported Arm platforms
>> that work by simply "xzcat | dd" onto the sd card (or wherever you
>> need it).   I'm not sure how standardized or manual that build process
>> is, but I would think that if the Arm platform support is able to keep
>> up with the standard FreeBSD release cycle (i.e. not break every other
>> release) then there would be no reason to NOT call it tier 1?
>
> Creating the images is currently a pita. That's it.
I see. So not so mature.

>> What I don't know about is "official" documentation for building for
>> arm and supporting cross building to Arm. Will someone need to write
>> an "Arm Handbook" to be promoted?
>
> No. While useful, most of that already exists.

Thanks for the response Warner, I always appreciate the chance to
learn more about FreeBSD.
Russ

> Warner
>
>>> Interesting and good to know. Thanks.
>>>
>>> I might have guessed that going along with the u-boot issue would be th=
e fanout in:
>>>
>>> 11.0/sys/arm/ . . .
>>>
>>> allwinner/a10/
>>> allwinner/a20/
>>> allwinner/a31/
>>> allwinner/a83t/
>>> allwinner/h3/
>>> . . .
>>> broadcom/bcm2835/
>>> . . .
>>>
>>> (Full list not shown.)
>>>
>>> I was thinking that this might make the tier level specific to the stat=
us of each such directory's content so that it was the combination of that =
and the sysutils/u-boot-*/ status that made the difference for assigning th=
e level.  I'd guess that lack of a usable directory in either place would n=
ot be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-=
boot-*/ directory-tree content have reached a sufficiently complete status.
>>>
>>> I'd expect that there will always be a lag for what exists in the world=
 vs. what has these materials worked out in FreeBSD.
>>>
>>>
>>>>> Also from https://www.freebsd.org/platforms/arm.html :
>>>>>
>>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms fol=
low a set of standard conventions, and a single FreeBSD build will work on =
hardware from multiple vendors. As a result, FreeBSD will provide official =
releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is=
 on the path to becoming a Tier 1 architecture.
>>>>>
>>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1?
>>>>>
>>>>> [I will note that, while there are no official builds for the Pine64 =
family (A64 based) that are under the Allwinner arm activity, the SOC's inv=
olved are Cortex-A53 64-bit arm based. They likely do not fit in the "stand=
ard conventions" or arm64/aarch64 would be where they would have been suppo=
rted. Some rewording might be appropriate for the above quote as well.]
>>>>
>>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are
>>>> missing. It is quite solidly Tier 2, but we don't have a linker, we
>>>> don't have widespread hardware availability, we don't have production
>>>> experience with the platform. Most things work, but there's still some
>>>> gotchas. There's still the 'u-boot' problem with many arm64 systems
>>>> because for systems that use u-boot to bootstrap UEFI, you need a
>>>> different image for each board (some closely related board families
>>>> can get by with one to be pedantic). All these issues are still
>>>> significant barriers to production use. It's not been officially
>>>> promoted yet and I don't think the time is quite right yet.
>>>
>>> Intersting as well. I'd guess that conceptually this probably would app=
ly to both:
>>>
>>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/
>>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ )
>>>
>>> and. . .
>>>
>>> sys/arm64/cavium/
>>> sys/arm64/cloudabi64/
>>>
>>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a =
difference yet for tier level.
>>>
>>>> Warner
>>>
>>> Thanks again for the notes.
>>>
>>> =3D=3D=3D
>>> 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  Sun Sep 25 09:06:19 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 0BF8FBE97EA;
 Sun, 25 Sep 2016 09:06:19 +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 6F50161A;
 Sun, 25 Sep 2016 09:06:17 +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 e1f576f8;
 Sun, 25 Sep 2016 10:59:34 +0200 (CEST)
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=Q/AEsWSuJ7fPslsjr+gDPT7sa3I=; b=FsTM63OtxNLGwlKEPGy2I6zlnh0L
 LFPckQOmuM50VPx2G8iypvuFxdK3UXtRQBD9xqQRmaV4P9V/u6zNwm6yUYPiHI5s
 f4yhr4cFFZrUwRnhhl5dcK4Od1JPtVEK/TNOI6KexI/YmmcBz+XGvNXCnYHlxg2y
 CXlianbQqNgvFKs=
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=oabMqTLMB2cjHXnrsUiIy/IYmcS/M4+1n9DzCNdZv/vn2MH68kwybjV0
 IKthBV+DcUQaxrXJ3fnqVCLGLYrevPc7x0ToPb3da/TqNrT41Z+kO3SczzmNgoTY
 z9uaMbJNuuq5yv5+fuUTV3E/mI3mxU2Q0oznXhoFpvA+4dLOxrQ=
Received: from knuckles.blih.net (free-229-194.mediaworksit.net
 [109.111.229.194])
 by mail.blih.net (OpenSMTPD) with ESMTPSA id e737a702
 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO;
 Sun, 25 Sep 2016 10:59:33 +0200 (CEST)
Date: Sun, 25 Sep 2016 10:59:30 +0200
From: Emmanuel Vadot <manu@bidouilliste.com>
To: Russell Haley <russ.haley@gmail.com>
Cc: Warner Losh <imp@bsdimp.com>, freebsd-arm <freebsd-arm@freebsd.org>,
 FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>, Mark Millard
 <markmi@dsl-only.net>
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
Message-Id: <20160925105930.2039e17f47a177a7465c9ee7@bidouilliste.com>
In-Reply-To: <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
 <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
 <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
 <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF+EEwww@mail.gmail.com>
 <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.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." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 09:06:19 -0000

On Sun, 25 Sep 2016 00:13:31 -0700
Russell Haley <russ.haley@gmail.com> wrote:

> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh <imp@bsdimp.com> wrote:
> > On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley <russ.haley@gmail.com> wrote:
> >> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard <markmi@dsl-only.net> wrote:
> >>> On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote:
> >>>
> >>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> wrote:
> >>>>> [A resend since I forget to list free-arm in the To: the first time.]
> >>>>>
> >>>>> From https://www.freebsd.org/platforms/arm.html :
> >>>>>
> >>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD project does not provide official releases or pre-built packages for this platform due to it primarily targeting the embedded arena. However, FreeBSD/ARM is being actively developed and maintained, is well supported, and provides an excellent framework for building ARM-based systems. FreeBSD/arm supports ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 processors, including SMP on the latter.
> >>>>>
> >>>>> "does not provide official releases or pre-built packages"?
> >>>>>
> >>>>>> # uname -apKU
> >>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: Sun Aug 28 03:17:54 PDT 2016     markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/usr/src/sys/RPI2-NODBG  arm armv6 1100502 1100502
> >>>>>
> >>>>>> # pkg search '.*' | wc
> >>>>>>  21349  155540 1596736
> >>>>>
> >>>>> Will 11.0-RELEASE change the tier level for any of the specific arm-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such as for RPI2?
> >>>>>
> >>>>> Even if all the officially built arm-armv6 variants stay tier 2, the wording on the web page likely needs to be changed because so much is built and available that the above quote claims is not available.
> >>>>
> >>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
> >>>> amd64 due to the fragmented nature of the arm world. On the platforms
> >>>> we run on and create releases for, however, it's my opinion that it is
> >>>> Tier 1: it has been running in production a while, things people
> >>>> expect from a FreeBSD system are present, you can get decent support
> >>>> if you ask questions, there's no known major gotchas in deploying this
> >>>> hardware. The only remaining annoying issue is the 'u-boot' problem
> >>>> where we have to have a different u-boot image for every board and no
> >>>> standardized way to convert a 'generic' image into one that's specific
> >>>> for specific boards.
> >>
> >> I'll point out again that barebox is an excellent alternative to u-boot (IMHO):
> >
> > Doesn't matter, still has the same issues that u-boot has.
> u-boot has a different sources for almost each board we support (due
> to the usual FOSS issues). That is NOT the case in barebox. There is
> one source and it's kept up to date by the team, not the vendors.

 This is not true, U-Boot support all the platforms we are running on
right now in a single source tree.
 I think that the only ports that is not using the main U-Boot is the
wandboard one and I think that Warner have it working now.

> > But does it support the u-boot ABI?
> I'd have to look into this.
> >
> >> - Supports most, if not all of the boards that FreeBSD supports, plus
> >> many that it doesn't
> >> - Single source tree for all boards. Specify build time parameters to
> >> build one or all the images
> >> - Well supported community with central maintainer-ship
> >> - Simple, familiar shell interface  (*awesome*)
> >> - Excellent documentation (u-boots is good too though)
> >> - Has support for (U)EFI
> >> - Supports quemu aarch64 (not *quite*sure what the means though)
> >
> > Right, u-boot has all these things, except maybe the shell interface
> > (not sure what you mean by that).
> Instead of stringing together variables and commands, it uses a
> scripting language like a simplified sh. Want to change how something
> boots? Update a script. Save it to disk (it has it's own persistence
> mechanisms) and export it.

 You can do the same with U-Boot.

> >> To be fair, I'm not saying the problem is the fault of denx, but
> >> barebox has a lot going for it. The maintainer was very keen to see it
> >> ported top FreeBSD and was willing to support the effort. I ran into
> >> some build time linux api requirements, but he didn't think that would
> >> be much to overcome (and it wasn't I just kept adding the patches he
> >> sent me and the build moved forward. As always, I ran out of time for
> >> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
> >> over simplified the problem, I thought it would be neat to see FreeBSD
> >> upstream support for zfs and ufs to the barebox boot loader and do
> >> away with ubldr. We would then have a modern, easy to use, boot loader
> >> that supports the standard startup toolchain.
> >
> > We can't easily do away with ubldr if we want to support tunables, kernel
> > modules loaded at boot time and a few other nifty features like nextboot.
> 
> Are these things not in standard loader? Should they be?

 They are in the standard loader, using ubldr,loader or loader.efi
doesn't matter but we have to use one of them.

> >> Either way, if installers move to a pkgng based method (so cool) then
> >> installing u-boot and arm binaries from pkg-static will be the same as
> >> x86 (ha ha I said that with a straight face!).
> >
> > Yea, not so much. You have to build the bootable image not on the
> > target system, like you do on x86.
> 
> Doesn't the current ports and packages cross build everything that's marked?
> 
> > We'd have to have something that
> > installs uboot onto a generic image (perhaps with hooks for kernels
> > since those aren't generic on armv6) and then put that into a bootable
> > SD card.
> 
> The x86 installer (that I argue is a platform legacy) has to customize
> the bootloader for each installation. If we HAVE to use an installer
> on arm, what wrong prompting the user for some input (i.e. what som
> are you using) while including all the u-boots  in the ports tree and
> all the supported kernels, then just installing the correct ones for
> the board (with input from the user)?
> 
> >>>>For x86 this is all done with the installer since
> >>>> that boot environment is more standardized. Does this last issue keep
> >>>> arm from being Tier 1? That's a judgement call, but I think the
> >>>> project should promote w/o this last issue.
> >>
> >> How does a platform get promoted? Is that something the Core team decides?
> >
> > Yes.
> >
> >> I see two facts about current Arm support that show platform maturity:
> >> a) u-boot is in the ports tree and we have Lego-easy build scripts in
> >> crochet that could be called an installation method. Building for arm
> >> is not difficult anymore.
> >
> > Except corchet isn't in the tree, and the solution is horrible. It's
> > a script for each SoC, and those scripts are now scattered about.
> > Plus that's a creation from source model, not a creation from
> > RE produced bits model, which is needed for Tier 1.
> Both correctable sins, especially as it's BSD licensed. My point was
> that even building a SOM specific image is relatively painless with
> the right scripts. Hell, I've even got a custom build script that
> could be modified for generic use.
> 
> >> b)Arm requires images, not installers. Correct me if I'm wrong but,
> >> installers are a tool primarily invented for x86 PC type computers.
> >> FreeBSD publishes standardized ISOs for all supported Arm platforms
> >> that work by simply "xzcat | dd" onto the sd card (or wherever you
> >> need it).   I'm not sure how standardized or manual that build process
> >> is, but I would think that if the Arm platform support is able to keep
> >> up with the standard FreeBSD release cycle (i.e. not break every other
> >> release) then there would be no reason to NOT call it tier 1?
> >
> > Creating the images is currently a pita. That's it.
> I see. So not so mature.
> 
> >> What I don't know about is "official" documentation for building for
> >> arm and supporting cross building to Arm. Will someone need to write
> >> an "Arm Handbook" to be promoted?
> >
> > No. While useful, most of that already exists.
> 
> Thanks for the response Warner, I always appreciate the chance to
> learn more about FreeBSD.
> Russ
> 
> > Warner
> >
> >>> Interesting and good to know. Thanks.
> >>>
> >>> I might have guessed that going along with the u-boot issue would be the fanout in:
> >>>
> >>> 11.0/sys/arm/ . . .
> >>>
> >>> allwinner/a10/
> >>> allwinner/a20/
> >>> allwinner/a31/
> >>> allwinner/a83t/
> >>> allwinner/h3/
> >>> . . .
> >>> broadcom/bcm2835/
> >>> . . .
> >>>
> >>> (Full list not shown.)
> >>>
> >>> I was thinking that this might make the tier level specific to the status of each such directory's content so that it was the combination of that and the sysutils/u-boot-*/ status that made the difference for assigning the level.  I'd guess that lack of a usable directory in either place would not be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u-boot-*/ directory-tree content have reached a sufficiently complete status.
> >>>
> >>> I'd expect that there will always be a lag for what exists in the world vs. what has these materials worked out in FreeBSD.
> >>>
> >>>
> >>>>> Also from https://www.freebsd.org/platforms/arm.html :
> >>>>>
> >>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms follow a set of standard conventions, and a single FreeBSD build will work on hardware from multiple vendors. As a result, FreeBSD will provide official releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 is on the path to becoming a Tier 1 architecture.
> >>>>>
> >>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1?
> >>>>>
> >>>>> [I will note that, while there are no official builds for the Pine64 family (A64 based) that are under the Allwinner arm activity, the SOC's involved are Cortex-A53 64-bit arm based. They likely do not fit in the "standard conventions" or arm64/aarch64 would be where they would have been supported. Some rewording might be appropriate for the above quote as well.]
> >>>>
> >>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are
> >>>> missing. It is quite solidly Tier 2, but we don't have a linker, we
> >>>> don't have widespread hardware availability, we don't have production
> >>>> experience with the platform. Most things work, but there's still some
> >>>> gotchas. There's still the 'u-boot' problem with many arm64 systems
> >>>> because for systems that use u-boot to bootstrap UEFI, you need a
> >>>> different image for each board (some closely related board families
> >>>> can get by with one to be pedantic). All these issues are still
> >>>> significant barriers to production use. It's not been officially
> >>>> promoted yet and I don't think the time is quite right yet.
> >>>
> >>> Intersting as well. I'd guess that conceptually this probably would apply to both:
> >>>
> >>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/
> >>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ )
> >>>
> >>> and. . .
> >>>
> >>> sys/arm64/cavium/
> >>> sys/arm64/cloudabi64/
> >>>
> >>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a difference yet for tier level.
> >>>
> >>>> Warner
> >>>
> >>> Thanks again for the notes.
> >>>
> >>> ===
> >>> 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"
> _______________________________________________
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"


-- 
Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>

From owner-freebsd-arm@freebsd.org  Sun Sep 25 10:02:09 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 6EA56BE687A
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Sun, 25 Sep 2016 10:02:09 +0000 (UTC)
 (envelope-from markmi@dsl-only.net)
Received: from asp.reflexion.net (outbound-mail-210-72.reflexion.net
 [208.70.210.72])
 (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 24972F9
 for <freebsd-arm@freebsd.org>; Sun, 25 Sep 2016 10:02:08 +0000 (UTC)
 (envelope-from markmi@dsl-only.net)
Received: (qmail 30664 invoked from network); 25 Sep 2016 09:55:17 -0000
Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1)
 by 0 (rfx-qmail) with SMTP; 25 Sep 2016 09:55:17 -0000
Received: by mail-cs-01.app.dca.reflexion.local
 (Reflexion email security v8.00.0) with SMTP;
 Sun, 25 Sep 2016 05:55:32 -0400 (EDT)
Received: (qmail 28027 invoked from network); 25 Sep 2016 09:55:32 -0000
Received: from unknown (HELO iron2.pdx.net) (69.64.224.71)
 by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 25 Sep 2016 09:55:32 -0000
Received: from [192.168.0.105] (ip70-189-131-151.lv.lv.cox.net
 [70.189.131.151])
 by iron2.pdx.net (Postfix) with ESMTPSA id 48356EC8A8B;
 Sun, 25 Sep 2016 02:55:26 -0700 (PDT)
From: Mark Millard <markmi@dsl-only.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Subject: Just FYI: FreeBSD-11.0-RELEASE-arm64-aarch64.raw under qemu on
 odroid-c2 Ubuntu 16.04.1 LTS
Message-Id: <27466846-3031-47C7-82FE-808FCE920E69@dsl-only.net>
Date: Sun, 25 Sep 2016 02:55:25 -0700
To: FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>,
 freebsd-arm <freebsd-arm@freebsd.org>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 10:02:09 -0000

This is just an FYI about my attempt to use =
FreeBSD-11.0-RELEASE-arm64-aarch64.raw under Ubuntu's qemu on an =
odroid-c2. (This is my first ever use of qemu. I've no clue about how =
well the qemu for this context works --or how well for any other =
context.)

Context of use of FreeBSD 11.0-RELEASE:

> Welcome to Ubuntu 16.04.1 LTS (GNU/Linux 3.14.79-83 aarch64)
. . .
> root@odroid64:~# uname -ap
> Linux odroid64 3.14.79-83 #1 SMP PREEMPT Thu Sep 22 13:47:47 BRT 2016 =
aarch64 aarch64 aarch64 GNU/Linux

> qemu-system-aarch64 -m 1024M -enable-kvm -cpu host -M virt \
>         -bios QEMU_EFI.fd -nographic \
>         -drive =
format=3Draw,if=3Dnone,file=3DFreeBSD-11.0-RELEASE-arm64-aarch64.raw,id=3D=
hd0 \
>         -device virtio-blk-device,drive=3Dhd0 \
>         -device virtio-net-device,netdev=3Dnet0 \
>         -netdev user,id=3Dnet0 \
>         -smp cpus=3D4

Note the "-nographic".

The QEMU_EFI.fd is from:

=
https://releases.linaro.org/components/kernel/uefi-linaro/15.12/release/qe=
mu64/QEMU_EFI.fd

> # freebsd-version -ku; uname -apKU
> 11.0-RELEASE
> 11.0-RELEASE
> FreeBSD odroidc2FBSD 11.0-RELEASE FreeBSD 11.0-RELEASE #0 r306211: Fri =
Sep 23 11:42:02 UTC 2016     =
root@releng2.nyi.freebsd.org:/usr/obj/arm64.aarch64/usr/src/sys/GENERIC  =
arm64 aarch64 1100122 1100122



Issue #0: "random" illegal instruction faults in FreeBSD use

Example *.core file names for an occasional "illegal instruction" (other =
times the same command works fine):

cron.core
fsck_ufs.core
ifconfig.core
login.core
ntpd.core
route.core
sh.core
shutdown.core
top.core
vi.core

All these programs usually/frequently work fine.

Some programs tend to not leave .core files and cause me to have to log =
in again when they get the illegal instruction fault. ps is a command =
that has had this happen.


Issue #1: command input/output stops

For both the serial console and an ssh into Ubuntu from which I start up =
qemu for FreeBSD. . .

Special keys, such as up-arrow for command line recall, stop the =
input/output for typing commands and such. It is ignoring what is typed =
(not just not displaying it). I end up having to kill the =
qemu-system-aarch64 process from Ubuntu or use "Control-a x". Sometimes =
"Control-a x" does not work.

Sometimes pasting text into the window cause such input/output hangups =
in FreeBSD use.

Usually qemu's "Control-A x" sequence will quit qemu. So usually there =
must be some amount of processing of what is typed but at some stage the =
text is otherwise being ignored. (I normally kill qemu-system-aarch64 =
from another Ubuntu command shell.)



Other point(s):

I've not managed to get FreeBSD qemu to even ping a numeric address ("No =
route to host"). But this may be just my current ignorance of how things =
are supposed to be configured, both in Ubuntu and in FreeBSD and on the =
command line options to qemu-system-aarch64. I've not put much effort =
into figuring such out given the more basic problems above. (The =
environment the attempt was done from is dhcp based.)

=3D=3D=3D
Mark Millard
markmi at dsl-only.net


From owner-freebsd-arm@freebsd.org  Sun Sep 25 15:57:29 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 13351BE8273;
 Sun, 25 Sep 2016 15:57:29 +0000 (UTC)
 (envelope-from tim@kientzle.com)
Received: from monday.kientzle.com (kientzle.com [142.254.26.11])
 (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 E3947EE8;
 Sun, 25 Sep 2016 15:57:28 +0000 (UTC)
 (envelope-from tim@kientzle.com)
Received: (from root@localhost)
 by monday.kientzle.com (8.14.4/8.14.4) id u8PFvISP062229;
 Sun, 25 Sep 2016 15:57:18 GMT (envelope-from tim@kientzle.com)
Received: from [192.168.2.106] (192.168.1.101 [192.168.1.101])
 by kientzle.com with SMTP id w39erfebfkspmgvzbf2vpmx3vi;
 Sun, 25 Sep 2016 15:57:18 +0000 (UTC)
 (envelope-from tim@kientzle.com)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3243\))
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
From: Tim Kientzle <tim@kientzle.com>
In-Reply-To: <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com>
Date: Sun, 25 Sep 2016 08:57:18 -0700
Cc: Warner Losh <imp@bsdimp.com>, freebsd-arm <freebsd-arm@freebsd.org>,
 FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Transfer-Encoding: 7bit
Message-Id: <9BFF1495-8142-4C2F-8919-D9A870D3E2BD@kientzle.com>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
 <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
 <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
 <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF+EEwww@mail.gmail.com>
 <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com>
To: Russell Haley <russ.haley@gmail.com>
X-Mailer: Apple Mail (2.3243)
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 15:57:29 -0000


> On Sep 25, 2016, at 12:13 AM, Russell Haley <russ.haley@gmail.com> wrote:
> 
>> We can't easily do away with ubldr if we want to support tunables, kernel
>> modules loaded at boot time and a few other nifty features like nextboot.
> 
> Are these things not in standard loader? Should they be?

"ubldr" *is* the standard loader.  It's built from (mostly) the same
source as loader(8) used on x86.  But, where loader(8) uses the BIOS
interface to access the disk, "ubldr" uses the U-Boot ABI to
access the disk.

FreeBSD's current boot sequence for ARM boards looks like this:
   * U-Boot loads ubldr
   * ubldr uses U-Boot to access disk and console
   * ubldr loads the kernel, kernel modules, and sets kernel tunables

To replace U-Boot, bare box would either have to duplicate
everything ubldr does (which is a lot) or would have to provide
the U-Boot ABI (or something similar) so that ubldr can provide
the final boot stage.

Tim



From owner-freebsd-arm@freebsd.org  Sun Sep 25 17:19:57 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 F301CBE98DC
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Sun, 25 Sep 2016 17:19:56 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com
 [IPv6:2607:f8b0:4001:c0b::22d])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id B6F27B1B
 for <freebsd-arm@freebsd.org>; Sun, 25 Sep 2016 17:19:56 +0000 (UTC)
 (envelope-from wlosh@bsdimp.com)
Received: by mail-it0-x22d.google.com with SMTP id r192so55402619ita.0
 for <freebsd-arm@freebsd.org>; Sun, 25 Sep 2016 10:19:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=bsdimp-com.20150623.gappssmtp.com; s=20150623;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:cc:content-transfer-encoding;
 bh=qGvEMyB29f9K9/MEbbEa5i3Kmfo/gfnVwXX/y/Yv6wc=;
 b=B+xivf9WzjKeUlCQbMpYfsYB/p0IQ84iTg0G2q5XCW0ihCVYpOl3WjP2x5x6IDFcbw
 iPRVgakKjp2wVqdNjpMT3HSDubIHJvwxg3dgn4qhmdJl7LtKIRPk/n4yq77amHTUg7AB
 Wrhvr/kEL9JJyVIuvmb4MFZHNM7aD+iffMPMLzm0dBmQ91Z22+W+WM5xM1R4G9ysXJLx
 snIF4LaAcPYen9CliUeaYSQ/8iRKBXwQ0cAEmzxwyvQ9FoyKlSYvgWuD1dpmiBBjyMdG
 pgpVBHKMbbQIRdkAjw8kXG/QHFiNXOWSGO45/qBzxgJg9GBVCnAXPg3GtVQru5HWfy4r
 uwIA==
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=qGvEMyB29f9K9/MEbbEa5i3Kmfo/gfnVwXX/y/Yv6wc=;
 b=hlHJhS/D04culbiaZ1jTgKfMwvNJmeZADEe1I7hTyOrp+Vosk7SQkyJYtfDp7ymx+u
 G2rHW6He0SbvQfWVtegCdpD/9/vUKQFLJgVP7nIMU1UHv+83uf4DQ2NhZqYJIdBdh5pA
 6XyVJ3H0ZyCpqBrQViOBzZgiF4nsOfZXs9gigrpy7zNnAXyBqYu3u5YJCsW8U1pr88nE
 lI2lxhR3UizJuqf82KXglTkXB8h608XcVmncmv51uPsHL8xqy1GBgP9Qcij0P8GEq8Os
 aFf4XJt49yE2ETI2CUg20tfqt+NBAcMNf1PypMRleL93qqNU7pXLByfoNy8bAGKjlx8n
 8n+A==
X-Gm-Message-State: AA6/9RkoXHAuMC8pdv3IoxRuk8dnOCtk1nHvkbnyUcAtrvn6zbTQdL+SKF1Ws/cpnjBfj9shfDuN8B7eBfBGCw==
X-Received: by 10.36.14.68 with SMTP id 65mr12200559ite.99.1474823995988; Sun,
 25 Sep 2016 10:19:55 -0700 (PDT)
MIME-Version: 1.0
Sender: wlosh@bsdimp.com
Received: by 10.36.65.7 with HTTP; Sun, 25 Sep 2016 10:19:55 -0700 (PDT)
X-Originating-IP: [50.253.99.174]
In-Reply-To: <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
 <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
 <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
 <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF+EEwww@mail.gmail.com>
 <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com>
From: Warner Losh <imp@bsdimp.com>
Date: Sun, 25 Sep 2016 11:19:55 -0600
X-Google-Sender-Auth: LsklrTS85t_g121n76IX46KNqBc
Message-ID: <CANCZdfo9BMThmEvnwmm3rg1OMU=SsETKSBUiX-wwjUDdnT2M5Q@mail.gmail.com>
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
To: Russell Haley <russ.haley@gmail.com>
Cc: Mark Millard <markmi@dsl-only.net>, freebsd-arm <freebsd-arm@freebsd.org>, 
 FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Sep 2016 17:19:57 -0000

On Sun, Sep 25, 2016 at 1:13 AM, Russell Haley <russ.haley@gmail.com> wrote=
:
> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh <imp@bsdimp.com> wrote:
>> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley <russ.haley@gmail.com> w=
rote:
>>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard <markmi@dsl-only.net> wro=
te:
>>>> On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote:
>>>>
>>>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> w=
rote:
>>>>>> [A resend since I forget to list free-arm in the To: the first time.=
]
>>>>>>
>>>>>> From https://www.freebsd.org/platforms/arm.html :
>>>>>>
>>>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD proj=
ect does not provide official releases or pre-built packages for this platf=
orm due to it primarily targeting the embedded arena. However, FreeBSD/ARM =
is being actively developed and maintained, is well supported, and provides=
 an excellent framework for building ARM-based systems. FreeBSD/arm support=
s ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 proces=
sors, including SMP on the latter.
>>>>>>
>>>>>> "does not provide official releases or pre-built packages"?
>>>>>>
>>>>>>> # uname -apKU
>>>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: S=
un Aug 28 03:17:54 PDT 2016     markmi@FreeBSDx64:/usr/obj/clang/arm.armv6/=
usr/src/sys/RPI2-NODBG  arm armv6 1100502 1100502
>>>>>>
>>>>>>> # pkg search '.*' | wc
>>>>>>>  21349  155540 1596736
>>>>>>
>>>>>> Will 11.0-RELEASE change the tier level for any of the specific arm-=
armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such =
as for RPI2?
>>>>>>
>>>>>> Even if all the officially built arm-armv6 variants stay tier 2, the=
 wording on the web page likely needs to be changed because so much is buil=
t and available that the above quote claims is not available.
>>>>>
>>>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
>>>>> amd64 due to the fragmented nature of the arm world. On the platforms
>>>>> we run on and create releases for, however, it's my opinion that it i=
s
>>>>> Tier 1: it has been running in production a while, things people
>>>>> expect from a FreeBSD system are present, you can get decent support
>>>>> if you ask questions, there's no known major gotchas in deploying thi=
s
>>>>> hardware. The only remaining annoying issue is the 'u-boot' problem
>>>>> where we have to have a different u-boot image for every board and no
>>>>> standardized way to convert a 'generic' image into one that's specifi=
c
>>>>> for specific boards.
>>>
>>> I'll point out again that barebox is an excellent alternative to u-boot=
 (IMHO):
>>
>> Doesn't matter, still has the same issues that u-boot has.
> u-boot has a different sources for almost each board we support (due
> to the usual FOSS issues). That is NOT the case in barebox. There is
> one source and it's kept up to date by the team, not the vendors.

Actually, that's no longer the case. All boards we support have all
their bits in u-boot's main repo. But you can't say no one will fork
barebox to get their support out faster, which is why we have the
current situation in ports... u-boot forked because it was so popular,
and the forks rejoined.

>> But does it support the u-boot ABI?
> I'd have to look into this.
>>
>>> - Supports most, if not all of the boards that FreeBSD supports, plus
>>> many that it doesn't
>>> - Single source tree for all boards. Specify build time parameters to
>>> build one or all the images
>>> - Well supported community with central maintainer-ship
>>> - Simple, familiar shell interface  (*awesome*)
>>> - Excellent documentation (u-boots is good too though)
>>> - Has support for (U)EFI
>>> - Supports quemu aarch64 (not *quite*sure what the means though)
>>
>> Right, u-boot has all these things, except maybe the shell interface
>> (not sure what you mean by that).
> Instead of stringing together variables and commands, it uses a
> scripting language like a simplified sh. Want to change how something
> boots? Update a script. Save it to disk (it has it's own persistence
> mechanisms) and export it.

Sounds cool.

>>> To be fair, I'm not saying the problem is the fault of denx, but
>>> barebox has a lot going for it. The maintainer was very keen to see it
>>> ported top FreeBSD and was willing to support the effort. I ran into
>>> some build time linux api requirements, but he didn't think that would
>>> be much to overcome (and it wasn't I just kept adding the patches he
>>> sent me and the build moved forward. As always, I ran out of time for
>>> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
>>> over simplified the problem, I thought it would be neat to see FreeBSD
>>> upstream support for zfs and ufs to the barebox boot loader and do
>>> away with ubldr. We would then have a modern, easy to use, boot loader
>>> that supports the standard startup toolchain.
>>
>> We can't easily do away with ubldr if we want to support tunables, kerne=
l
>> modules loaded at boot time and a few other nifty features like nextboot=
.
>
> Are these things not in standard loader? Should they be?

ubldr is the standard loader, just spelled in a funky way and living
on a place u-boot can see :). We have different loaders for different
environments. even on x86 we have /boot/loader for BIOS boots and
/boot/loader.efi for EFI boots.

>>> Either way, if installers move to a pkgng based method (so cool) then
>>> installing u-boot and arm binaries from pkg-static will be the same as
>>> x86 (ha ha I said that with a straight face!).
>>
>> Yea, not so much. You have to build the bootable image not on the
>> target system, like you do on x86.
>
> Doesn't the current ports and packages cross build everything that's mark=
ed?

For builds from source, yes. But that's different than installing from
FreeBSD's installer.

>> We'd have to have something that
>> installs uboot onto a generic image (perhaps with hooks for kernels
>> since those aren't generic on armv6) and then put that into a bootable
>> SD card.
>
> The x86 installer (that I argue is a platform legacy) has to customize
> the bootloader for each installation. If we HAVE to use an installer
> on arm, what wrong prompting the user for some input (i.e. what som
> are you using) while including all the u-boots  in the ports tree and
> all the supported kernels, then just installing the correct ones for
> the board (with input from the user)?

Ummm, you can't boot anything to do that work like you can on x86.

>>>>>For x86 this is all done with the installer since
>>>>> that boot environment is more standardized. Does this last issue keep
>>>>> arm from being Tier 1? That's a judgement call, but I think the
>>>>> project should promote w/o this last issue.
>>>
>>> How does a platform get promoted? Is that something the Core team decid=
es?
>>
>> Yes.
>>
>>> I see two facts about current Arm support that show platform maturity:
>>> a) u-boot is in the ports tree and we have Lego-easy build scripts in
>>> crochet that could be called an installation method. Building for arm
>>> is not difficult anymore.
>>
>> Except corchet isn't in the tree, and the solution is horrible. It's
>> a script for each SoC, and those scripts are now scattered about.
>> Plus that's a creation from source model, not a creation from
>> RE produced bits model, which is needed for Tier 1.
> Both correctable sins, especially as it's BSD licensed. My point was
> that even building a SOM specific image is relatively painless with
> the right scripts. Hell, I've even got a custom build script that
> could be modified for generic use.

Yea, a developer can do it with little pain. However, compared to the
pain to boot Linux on these boards, the pain is quite high and you
need to know way too much to make it work.

BTW, my 'horrible' comment was given the state of things today: we
have scattered knowledge of how to make images, custom one-off that
work on some boards well, and fail on others. We have crazy, quirky
things that aren't well integrated into the tree. Crochet itself
solves an interesting problem, but does so a bit in isolation.

>>> b)Arm requires images, not installers. Correct me if I'm wrong but,
>>> installers are a tool primarily invented for x86 PC type computers.
>>> FreeBSD publishes standardized ISOs for all supported Arm platforms
>>> that work by simply "xzcat | dd" onto the sd card (or wherever you
>>> need it).   I'm not sure how standardized or manual that build process
>>> is, but I would think that if the Arm platform support is able to keep
>>> up with the standard FreeBSD release cycle (i.e. not break every other
>>> release) then there would be no reason to NOT call it tier 1?
>>
>> Creating the images is currently a pita. That's it.
> I see. So not so mature.

Yes. It's an area I work on when I have time to make better...

Warner

>>> What I don't know about is "official" documentation for building for
>>> arm and supporting cross building to Arm. Will someone need to write
>>> an "Arm Handbook" to be promoted?
>>
>> No. While useful, most of that already exists.
>
> Thanks for the response Warner, I always appreciate the chance to
> learn more about FreeBSD.
> Russ
>
>> Warner
>>
>>>> Interesting and good to know. Thanks.
>>>>
>>>> I might have guessed that going along with the u-boot issue would be t=
he fanout in:
>>>>
>>>> 11.0/sys/arm/ . . .
>>>>
>>>> allwinner/a10/
>>>> allwinner/a20/
>>>> allwinner/a31/
>>>> allwinner/a83t/
>>>> allwinner/h3/
>>>> . . .
>>>> broadcom/bcm2835/
>>>> . . .
>>>>
>>>> (Full list not shown.)
>>>>
>>>> I was thinking that this might make the tier level specific to the sta=
tus of each such directory's content so that it was the combination of that=
 and the sysutils/u-boot-*/ status that made the difference for assigning t=
he level.  I'd guess that lack of a usable directory in either place would =
not be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/u=
-boot-*/ directory-tree content have reached a sufficiently complete status=
.
>>>>
>>>> I'd expect that there will always be a lag for what exists in the worl=
d vs. what has these materials worked out in FreeBSD.
>>>>
>>>>
>>>>>> Also from https://www.freebsd.org/platforms/arm.html :
>>>>>>
>>>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms fo=
llow a set of standard conventions, and a single FreeBSD build will work on=
 hardware from multiple vendors. As a result, FreeBSD will provide official=
 releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 i=
s on the path to becoming a Tier 1 architecture.
>>>>>>
>>>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1?
>>>>>>
>>>>>> [I will note that, while there are no official builds for the Pine64=
 family (A64 based) that are under the Allwinner arm activity, the SOC's in=
volved are Cortex-A53 64-bit arm based. They likely do not fit in the "stan=
dard conventions" or arm64/aarch64 would be where they would have been supp=
orted. Some rewording might be appropriate for the above quote as well.]
>>>>>
>>>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are
>>>>> missing. It is quite solidly Tier 2, but we don't have a linker, we
>>>>> don't have widespread hardware availability, we don't have production
>>>>> experience with the platform. Most things work, but there's still som=
e
>>>>> gotchas. There's still the 'u-boot' problem with many arm64 systems
>>>>> because for systems that use u-boot to bootstrap UEFI, you need a
>>>>> different image for each board (some closely related board families
>>>>> can get by with one to be pedantic). All these issues are still
>>>>> significant barriers to production use. It's not been officially
>>>>> promoted yet and I don't think the time is quite right yet.
>>>>
>>>> Intersting as well. I'd guess that conceptually this probably would ap=
ply to both:
>>>>
>>>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/
>>>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ )
>>>>
>>>> and. . .
>>>>
>>>> sys/arm64/cavium/
>>>> sys/arm64/cloudabi64/
>>>>
>>>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make a=
 difference yet for tier level.
>>>>
>>>>> Warner
>>>>
>>>> Thanks again for the notes.
>>>>
>>>> =3D=3D=3D
>>>> 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  Mon Sep 26 04:03:32 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 5E8D1BE83D4;
 Mon, 26 Sep 2016 04:03:32 +0000 (UTC)
 (envelope-from russ.haley@gmail.com)
Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com
 [IPv6:2607:f8b0:400c:c05::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 09688BA;
 Mon, 26 Sep 2016 04:03:32 +0000 (UTC)
 (envelope-from russ.haley@gmail.com)
Received: by mail-vk0-x22c.google.com with SMTP id z126so37771435vkd.0;
 Sun, 25 Sep 2016 21:03:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc:content-transfer-encoding;
 bh=iADDNrBlTH0JqYCNNhbcwEoGJITLYOtnB0Sll8KcL8U=;
 b=AENVV+mQDzd/jAzsGq5d+wLxGMQTdYwD/EGWn21H5E97dktyCcWjeok5i1zDI7MZKt
 FBtzUgbAcpLxcnI6bZeANYzMDbH2er5RgV2hqvsutcenM3cfIwmkvUByu5I3h+TiM6Cp
 HKJihonCS2E5wYMOBCyWs3Sf9Q8vO8Erux4lr5VLBW9n/BwoZokTSBtIwOzzrX9BZpBH
 szkQ3cVOYU8owOAfRjLwZYyIivr16EKZtBdCyoO7JM7FQhM62LO5CXFr7y35MlBk0dzj
 WtG/Ak1lK/H0i0+FsKVIaconn5yAswGiuiWf/pYswzVrwcyoUdJIhzvi42qzbW61OeiM
 RSEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc:content-transfer-encoding;
 bh=iADDNrBlTH0JqYCNNhbcwEoGJITLYOtnB0Sll8KcL8U=;
 b=UHUcA4/5FHZKfRxjWmtw7/v5WyGYyufEpWlXSs/zQkbaH7SR7euzJIaSw1NdmNH4kr
 bJirHoW6H0TLdYzsLiFoRgYjKolLcit1aEEFdJqOq1x0yrm6jEH++XUxtZPGMdgn1Oru
 Rf77E8GpamWIbljuXLkTDIBJXkM6lo6YA/kl7xMAZYrWX7tTNBv/yhb+LGEe3MC6OM9E
 UfYKeTV7ofv7cnU6HXEP0N2NRGtQlT9ado0qRA0gQJBgvqSBIdFgo8HvwbnMKFya/LxT
 8TkDlA8E1npKVI6JaP3R+QE+QL+Uf0kwIQK1F6SVrhMdaMjXcwIzGyGR70YC95ys/84a
 WfkA==
X-Gm-Message-State: AA6/9RmCc8L0zsVMmv1nCO/lWi8gXEQZFg1LHyw8A7z9j6T+CspSrd0v8CRvzCRE1XP6SIC5Y7msKtTAzDNtJQ==
X-Received: by 10.31.5.19 with SMTP id 19mr5592437vkf.75.1474862610967; Sun,
 25 Sep 2016 21:03:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.124.202 with HTTP; Sun, 25 Sep 2016 21:03:30 -0700 (PDT)
In-Reply-To: <CANCZdfo9BMThmEvnwmm3rg1OMU=SsETKSBUiX-wwjUDdnT2M5Q@mail.gmail.com>
References: <4076CFFA-7BE2-4E1B-A7E8-08FD8FC27D21@dsl-only.net>
 <332FA120-31E5-4D31-B63E-A0DFDD7DEFC7@dsl-only.net>
 <CANCZdfqM17qzZg2SqwJRTWO67KCnAC+HYKatcb8CBHF3TM7kFg@mail.gmail.com>
 <4F04B0C0-DAB1-4EEA-A3A0-4FAA89AD93E2@dsl-only.net>
 <CABx9NuRv69k0u84+3bpDGPM1U7DsZJUtBC42jktk3ttinY9p+A@mail.gmail.com>
 <CANCZdfpBzh15fJdQ559MQv1J=5TrbSfgdziKMVUW-kDF+EEwww@mail.gmail.com>
 <CABx9NuTFobc1e4UxsLSPKLTtMgt37QDgR99xHhkdCkc7qPHCxA@mail.gmail.com>
 <CANCZdfo9BMThmEvnwmm3rg1OMU=SsETKSBUiX-wwjUDdnT2M5Q@mail.gmail.com>
From: Russell Haley <russ.haley@gmail.com>
Date: Sun, 25 Sep 2016 21:03:30 -0700
Message-ID: <CABx9NuQy-Jh8cNDz5iA_dWzPyF4dJHQW6JJoOyjnSkk=FdrhQQ@mail.gmail.com>
Subject: Re: 11.0-RELEASE tier level for arm64/aaarch64 and the officially
 built arm/armv6 variants?
To: Warner Losh <imp@bsdimp.com>
Cc: Mark Millard <markmi@dsl-only.net>, freebsd-arm <freebsd-arm@freebsd.org>, 
 FreeBSD-STABLE Mailing List <freebsd-stable@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 04:03:32 -0000

On Sun, Sep 25, 2016 at 10:19 AM, Warner Losh <imp@bsdimp.com> wrote:
> On Sun, Sep 25, 2016 at 1:13 AM, Russell Haley <russ.haley@gmail.com> wro=
te:
>> On Sat, Sep 24, 2016 at 11:10 PM, Warner Losh <imp@bsdimp.com> wrote:
>>> On Sat, Sep 24, 2016 at 10:21 PM, Russell Haley <russ.haley@gmail.com> =
wrote:
>>>> On Sat, Sep 24, 2016 at 5:12 PM, Mark Millard <markmi@dsl-only.net> wr=
ote:
>>>>> On 2016-Sep-24, at 2:11 PM, Warner Losh <imp@bsdimp.com> wrote:
>>>>>
>>>>>> On Fri, Sep 23, 2016 at 8:29 PM, Mark Millard <markmi@dsl-only.net> =
wrote:
>>>>>>> [A resend since I forget to list free-arm in the To: the first time=
.]
>>>>>>>
>>>>>>> From https://www.freebsd.org/platforms/arm.html :
>>>>>>>
>>>>>>>> 32-bit ARM is officially a Tier 2 architecture, as the FreeBSD pro=
ject does not provide official releases or pre-built packages for this plat=
form due to it primarily targeting the embedded arena. However, FreeBSD/ARM=
 is being actively developed and maintained, is well supported, and provide=
s an excellent framework for building ARM-based systems. FreeBSD/arm suppor=
ts ARMv4 and ARMv5 processors. FreeBSD/armv6 supports ARMv6 and ARMv7 proce=
ssors, including SMP on the latter.
>>>>>>>
>>>>>>> "does not provide official releases or pre-built packages"?
>>>>>>>
>>>>>>>> # uname -apKU
>>>>>>>> FreeBSD rpi2 11.0-PRERELEASE FreeBSD 11.0-PRERELEASE #5 r304943M: =
Sun Aug 28 03:17:54 PDT 2016     markmi@FreeBSDx64:/usr/obj/clang/arm.armv6=
/usr/src/sys/RPI2-NODBG  arm armv6 1100502 1100502
>>>>>>>
>>>>>>>> # pkg search '.*' | wc
>>>>>>>>  21349  155540 1596736
>>>>>>>
>>>>>>> Will 11.0-RELEASE change the tier level for any of the specific arm=
-armv6 variants that have FreeBSD-11.0-*-arm-armv6-*.img* files built, such=
 as for RPI2?
>>>>>>>
>>>>>>> Even if all the officially built arm-armv6 variants stay tier 2, th=
e wording on the web page likely needs to be changed because so much is bui=
lt and available that the above quote claims is not available.
>>>>>>
>>>>>> armv6 is basically Tier 1 right now, though not as Tier 1 as i386 or
>>>>>> amd64 due to the fragmented nature of the arm world. On the platform=
s
>>>>>> we run on and create releases for, however, it's my opinion that it =
is
>>>>>> Tier 1: it has been running in production a while, things people
>>>>>> expect from a FreeBSD system are present, you can get decent support
>>>>>> if you ask questions, there's no known major gotchas in deploying th=
is
>>>>>> hardware. The only remaining annoying issue is the 'u-boot' problem
>>>>>> where we have to have a different u-boot image for every board and n=
o
>>>>>> standardized way to convert a 'generic' image into one that's specif=
ic
>>>>>> for specific boards.
>>>>
>>>> I'll point out again that barebox is an excellent alternative to u-boo=
t (IMHO):
>>>
>>> Doesn't matter, still has the same issues that u-boot has.
>> u-boot has a different sources for almost each board we support (due
>> to the usual FOSS issues). That is NOT the case in barebox. There is
>> one source and it's kept up to date by the team, not the vendors.
>
> Actually, that's no longer the case. All boards we support have all
> their bits in u-boot's main repo. But you can't say no one will fork
> barebox to get their support out faster, which is why we have the
> current situation in ports... u-boot forked because it was so popular,
> and the forks rejoined.

Good show, I'm not advocating change for change sake and have had good
success with u-boot as a novice. I'll have to have a look in the ports
tree. I wasn't aware that so much progress had been made. I wish I had
time to skulk on the IRC channel too. :(


Russ
>>> But does it support the u-boot ABI?
>> I'd have to look into this.
>>>
>>>> - Supports most, if not all of the boards that FreeBSD supports, plus
>>>> many that it doesn't
>>>> - Single source tree for all boards. Specify build time parameters to
>>>> build one or all the images
>>>> - Well supported community with central maintainer-ship
>>>> - Simple, familiar shell interface  (*awesome*)
>>>> - Excellent documentation (u-boots is good too though)
>>>> - Has support for (U)EFI
>>>> - Supports quemu aarch64 (not *quite*sure what the means though)
>>>
>>> Right, u-boot has all these things, except maybe the shell interface
>>> (not sure what you mean by that).
>> Instead of stringing together variables and commands, it uses a
>> scripting language like a simplified sh. Want to change how something
>> boots? Update a script. Save it to disk (it has it's own persistence
>> mechanisms) and export it.
>
> Sounds cool.
>
>>>> To be fair, I'm not saying the problem is the fault of denx, but
>>>> barebox has a lot going for it. The maintainer was very keen to see it
>>>> ported top FreeBSD and was willing to support the effort. I ran into
>>>> some build time linux api requirements, but he didn't think that would
>>>> be much to overcome (and it wasn't I just kept adding the patches he
>>>> sent me and the build moved forward. As always, I ran out of time for
>>>> the really fun stuff). While I am a hopeless dreamer and I'm sure I've
>>>> over simplified the problem, I thought it would be neat to see FreeBSD
>>>> upstream support for zfs and ufs to the barebox boot loader and do
>>>> away with ubldr. We would then have a modern, easy to use, boot loader
>>>> that supports the standard startup toolchain.
>>>
>>> We can't easily do away with ubldr if we want to support tunables, kern=
el
>>> modules loaded at boot time and a few other nifty features like nextboo=
t.
>>
>> Are these things not in standard loader? Should they be?
>
> ubldr is the standard loader, just spelled in a funky way and living
> on a place u-boot can see :). We have different loaders for different
> environments. even on x86 we have /boot/loader for BIOS boots and
> /boot/loader.efi for EFI boots.
>
>>>> Either way, if installers move to a pkgng based method (so cool) then
>>>> installing u-boot and arm binaries from pkg-static will be the same as
>>>> x86 (ha ha I said that with a straight face!).
>>>
>>> Yea, not so much. You have to build the bootable image not on the
>>> target system, like you do on x86.
>>
>> Doesn't the current ports and packages cross build everything that's mar=
ked?
>
> For builds from source, yes. But that's different than installing from
> FreeBSD's installer.
>
>>> We'd have to have something that
>>> installs uboot onto a generic image (perhaps with hooks for kernels
>>> since those aren't generic on armv6) and then put that into a bootable
>>> SD card.
>>
>> The x86 installer (that I argue is a platform legacy) has to customize
>> the bootloader for each installation. If we HAVE to use an installer
>> on arm, what wrong prompting the user for some input (i.e. what som
>> are you using) while including all the u-boots  in the ports tree and
>> all the supported kernels, then just installing the correct ones for
>> the board (with input from the user)?
>
> Ummm, you can't boot anything to do that work like you can on x86.
>
>>>>>>For x86 this is all done with the installer since
>>>>>> that boot environment is more standardized. Does this last issue kee=
p
>>>>>> arm from being Tier 1? That's a judgement call, but I think the
>>>>>> project should promote w/o this last issue.
>>>>
>>>> How does a platform get promoted? Is that something the Core team deci=
des?
>>>
>>> Yes.
>>>
>>>> I see two facts about current Arm support that show platform maturity:
>>>> a) u-boot is in the ports tree and we have Lego-easy build scripts in
>>>> crochet that could be called an installation method. Building for arm
>>>> is not difficult anymore.
>>>
>>> Except corchet isn't in the tree, and the solution is horrible. It's
>>> a script for each SoC, and those scripts are now scattered about.
>>> Plus that's a creation from source model, not a creation from
>>> RE produced bits model, which is needed for Tier 1.
>> Both correctable sins, especially as it's BSD licensed. My point was
>> that even building a SOM specific image is relatively painless with
>> the right scripts. Hell, I've even got a custom build script that
>> could be modified for generic use.
>
> Yea, a developer can do it with little pain. However, compared to the
> pain to boot Linux on these boards, the pain is quite high and you
> need to know way too much to make it work.
>
> BTW, my 'horrible' comment was given the state of things today: we
> have scattered knowledge of how to make images, custom one-off that
> work on some boards well, and fail on others. We have crazy, quirky
> things that aren't well integrated into the tree. Crochet itself
> solves an interesting problem, but does so a bit in isolation.
>
>>>> b)Arm requires images, not installers. Correct me if I'm wrong but,
>>>> installers are a tool primarily invented for x86 PC type computers.
>>>> FreeBSD publishes standardized ISOs for all supported Arm platforms
>>>> that work by simply "xzcat | dd" onto the sd card (or wherever you
>>>> need it).   I'm not sure how standardized or manual that build process
>>>> is, but I would think that if the Arm platform support is able to keep
>>>> up with the standard FreeBSD release cycle (i.e. not break every other
>>>> release) then there would be no reason to NOT call it tier 1?
>>>
>>> Creating the images is currently a pita. That's it.
>> I see. So not so mature.
>
> Yes. It's an area I work on when I have time to make better...
>
> Warner
>
>>>> What I don't know about is "official" documentation for building for
>>>> arm and supporting cross building to Arm. Will someone need to write
>>>> an "Arm Handbook" to be promoted?
>>>
>>> No. While useful, most of that already exists.
>>
>> Thanks for the response Warner, I always appreciate the chance to
>> learn more about FreeBSD.
>> Russ
>>
>>> Warner
>>>
>>>>> Interesting and good to know. Thanks.
>>>>>
>>>>> I might have guessed that going along with the u-boot issue would be =
the fanout in:
>>>>>
>>>>> 11.0/sys/arm/ . . .
>>>>>
>>>>> allwinner/a10/
>>>>> allwinner/a20/
>>>>> allwinner/a31/
>>>>> allwinner/a83t/
>>>>> allwinner/h3/
>>>>> . . .
>>>>> broadcom/bcm2835/
>>>>> . . .
>>>>>
>>>>> (Full list not shown.)
>>>>>
>>>>> I was thinking that this might make the tier level specific to the st=
atus of each such directory's content so that it was the combination of tha=
t and the sysutils/u-boot-*/ status that made the difference for assigning =
the level.  I'd guess that lack of a usable directory in either place would=
 not be tier 2 even. Similarly until the required sys/arm/*/* and sysutils/=
u-boot-*/ directory-tree content have reached a sufficiently complete statu=
s.
>>>>>
>>>>> I'd expect that there will always be a lag for what exists in the wor=
ld vs. what has these materials worked out in FreeBSD.
>>>>>
>>>>>
>>>>>>> Also from https://www.freebsd.org/platforms/arm.html :
>>>>>>>
>>>>>>>> Initial support for 64-bit ARM is complete. 64-bit ARM platforms f=
ollow a set of standard conventions, and a single FreeBSD build will work o=
n hardware from multiple vendors. As a result, FreeBSD will provide officia=
l releases for FreeBSD/arm64 and packages will be available. FreeBSD/arm64 =
is on the path to becoming a Tier 1 architecture.
>>>>>>>
>>>>>>> Will 11.0-RELEASE make arm64/aarch64 Tier 1?
>>>>>>>
>>>>>>> [I will note that, while there are no official builds for the Pine6=
4 family (A64 based) that are under the Allwinner arm activity, the SOC's i=
nvolved are Cortex-A53 64-bit arm based. They likely do not fit in the "sta=
ndard conventions" or arm64/aarch64 would be where they would have been sup=
ported. Some rewording might be appropriate for the above quote as well.]
>>>>>>
>>>>>> No. aarch64 isn't Tier 1 yet. There's many small bits that are
>>>>>> missing. It is quite solidly Tier 2, but we don't have a linker, we
>>>>>> don't have widespread hardware availability, we don't have productio=
n
>>>>>> experience with the platform. Most things work, but there's still so=
me
>>>>>> gotchas. There's still the 'u-boot' problem with many arm64 systems
>>>>>> because for systems that use u-boot to bootstrap UEFI, you need a
>>>>>> different image for each board (some closely related board families
>>>>>> can get by with one to be pedantic). All these issues are still
>>>>>> significant barriers to production use. It's not been officially
>>>>>> promoted yet and I don't think the time is quite right yet.
>>>>>
>>>>> Intersting as well. I'd guess that conceptually this probably would a=
pply to both:
>>>>>
>>>>> sys/arm/allwinner/a64/ and sysutils/u-boot/pine64/
>>>>> (presuming, contrary to fact, that 11.0 had sys/arm/allwinner/a64/ )
>>>>>
>>>>> and. . .
>>>>>
>>>>> sys/arm64/cavium/
>>>>> sys/arm64/cloudabi64/
>>>>>
>>>>> So just sys/arm/ vs. sys/arm64/ for an aarch64 would not really make =
a difference yet for tier level.
>>>>>
>>>>>> Warner
>>>>>
>>>>> Thanks again for the notes.
>>>>>
>>>>> =3D=3D=3D
>>>>> 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  Mon Sep 26 12:52:47 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 AB307BE6849
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Mon, 26 Sep 2016 12:52:47 +0000 (UTC)
 (envelope-from danny@cs.huji.ac.il)
Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org
 [IPv6:2001:1900:2254:206a::50:5])
 by mx1.freebsd.org (Postfix) with ESMTP id 918ACE82
 for <freebsd-arm@freebsd.org>; Mon, 26 Sep 2016 12:52:47 +0000 (UTC)
 (envelope-from danny@cs.huji.ac.il)
Received: by mailman.ysv.freebsd.org (Postfix)
 id 9085CBE6847; Mon, 26 Sep 2016 12:52:47 +0000 (UTC)
Delivered-To: arm@mailman.ysv.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org
 [IPv6:2001:1900:2254:206a::19:1])
 by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8FCD7BE6846
 for <arm@mailman.ysv.freebsd.org>; Mon, 26 Sep 2016 12:52:47 +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 5FE08E7D
 for <arm@freebsd.org>; Mon, 26 Sep 2016 12:52:46 +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 1boVOb-0006CS-FV; Mon, 26 Sep 2016 15:52:33 +0300
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: ALL WINNER high temp. stop
From: Daniel Braniss <danny@cs.huji.ac.il>
In-Reply-To: <F9921024-17CF-4654-83B1-CD4D705DA25D@cs.huji.ac.il>
Date: Mon, 26 Sep 2016 15:52:33 +0300
Cc: arm@freebsd.org
Message-Id: <6E63B10F-86C5-45EE-8D8B-2192D8C8A63C@cs.huji.ac.il>
References: <B11041B2-0EDD-4E20-8684-CB471C17D81B@cs.huji.ac.il>
 <20160917171911.a2ec80da747ba373ba3d1b4a@bidouilliste.com>
 <5ADFE16E-FD60-45B1-8CF1-6FFC10BABBDE@cs.huji.ac.il>
 <20160917195544.a2a8bbdb113029700fa7642d@bidouilliste.com>
 <588E44BB-40BF-40B8-9C5A-BA025AB87E00@cs.huji.ac.il>
 <alpine.DEB.2.11.1609180930230.641@dis.invisible.ca>
 <4F7891B0-FBD7-451C-BA42-50F872804C95@cs.huji.ac.il>
 <08E5651B-A28E-4BE8-803B-650CD2434979@cs.huji.ac.il>
 <01D85517-15ED-46FF-8C11-5A774EC1262F@cs.huji.ac.il>
 <alpine.DEB.2.11.1609210745050.641@dis.invisible.ca>
 <7BFD291A-E619-4DE4-9BBB-C1F40E81F12A@cs.huji.ac.il>
 <F9921024-17CF-4654-83B1-CD4D705DA25D@cs.huji.ac.il>
To: Jared McNeill <jmcneill@invisible.ca>
X-Mailer: Apple Mail (2.3124)
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2016 12:52:47 -0000


> On 21 Sep 2016, at 14:22, Daniel Braniss <danny@cs.huji.ac.il> wrote:
>=20
>>=20
>> On 21 Sep 2016, at 14:13, Daniel Braniss <danny@cs.huji.ac.il =
<mailto:danny@cs.huji.ac.il>> wrote:
>>=20
>>=20
>>> On 21 Sep 2016, at 13:49, Jared McNeill <jmcneill@invisible.ca> =
wrote:
>>>=20
>>> CPU frequency scaling is supported now. Have you added operating =
points to the dts? Without a heatsink or fan, you need to set a =
reasonable set of operating points.
>>>=20
>>> 64C does seem quite low, the thermal driver uses the power-on =
default temperature for the shutdown temperature though (which should be =
> 100C).
>>>=20
>>> Are you sure you are using the correct compat string for the thermal =
driver in your dts? Different SoCs use a different formula for reading =
the temperature.
>>=20
>> I=E2=80=99m using what you sent me :-)
>> =
https://github.com/jaredmcneill/freebsd/blob/allwinner-h3/sys/boot/fdt/dts=
/arm/orangepi-plus-2e.dts#L12 =
<https://github.com/jaredmcneill/freebsd/blob/allwinner-h3/sys/boot/fdt/dt=
s/arm/orangepi-plus-2e.dts#L12> =
<https://github.com/jaredmcneill/freebsd/blob/allwinner-h3/sys/boot/fdt/dt=
s/arm/orangepi-plus-2e.dts#L121 =
<https://github.com/jaredmcneill/freebsd/blob/allwinner-h3/sys/boot/fdt/dt=
s/arm/orangepi-plus-2e.dts#L121>>
>>=20
>=20
> here is my dts for the orange-one:
> /*-
> * Copyright (c) 2016 Jared McNeill <jmcneill@invisible.ca =
<mailto:jmcneill@invisible.ca>>
> * All rights reserved.
> *
> * Redistribution and use in source and binary forms, with or without
> * modification, are permitted provided that the following conditions
> * are met:
> * 1. Redistributions of source code must retain the above copyright
> *    notice, this list of conditions and the following disclaimer.
> * 2. Redistributions in binary form must reproduce the above copyright
> *    notice, this list of conditions and the following disclaimer in =
the
> *    documentation and/or other materials provided with the =
distribution.
> *
> * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' =
AND
> * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, =
THE
> * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR =
PURPOSE
> * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE =
LIABLE
> * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR =
CONSEQUENTIAL
> * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE =
GOODS
> * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS =
INTERRUPTION)
> * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, =
STRICT
> * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN =
ANY WAY
> * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY =
OF
> * SUCH DAMAGE.
> *
> * $FreeBSD$
> */
> #include "sun8i-h3-orangepi-one.dts"
>=20
> / {
>        clocks {
> 	       ths_clk: clk@1c20074 {
> 	       	       #clock-cells =3D <0>;
> 		       compatible =3D "allwinner,sun8i-h3-ths-clk";
> 		       reg =3D <0x01c20074 0x4>;
> 		       clocks =3D <&osc24M>;
> 		       clock-output-names =3D "ths";
> 		};
>        };
> 	soc {
> 		emac: ethernet@1c30000 {
> 			compatible =3D "allwinner,sun8i-h3-emac";
> 			reg =3D <0x01c30000 0x104>, <0x01c00030 0x4>;
> 			reg-names =3D "emac", "syscon";
> 			interrupts =3D <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
> 			resets =3D <&ahb_rst 17>;
> 			reset-names =3D "ahb";
> 			clocks =3D <&bus_gates 17>;
> 			clock-names =3D "ahb";
> 			#address-cells =3D <1>;
> 			#size-cells =3D <0>;
> 			status =3D "disabled";
> 		};
> 	=09
> 		sid: eeprom@01c14000 {
> 			compatible =3D "allwinner,sun8i-h3-sid";
> 			reg =3D <0x01c14000 0x400>;
> 		};
>=20
> 		rtp: rtp@1c25000 {
> 			compatible =3D "allwinner,sun8i-h3-ts";
> 			reg =3D <0x01c25000 0x400>;
> 			interrupts =3D <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> 			clocks =3D <&bus_gates 72>,<&ths_clk>;
> 			clock-names =3D "ahb", "ths";
> 			resets =3D <&apb1_rst 8>;
> 			#thermal-sensor-cells =3D <0>;
> 		};
>=20
> 	};
> };
>=20
> &mmc0_pins_a {
> 	allwinner,pull =3D <SUN4I_PINCTRL_PULL_UP>;
> };
>=20
> &pio {
>        emac_pins_rgmii_a: emac_rgmii@0 {
>                allwinner,pins =3D "PD0", "PD1", "PD2", "PD3", "PD4", =
"PD5",
>                		 "PD7", "PD8", "PD9", "PD10", "PD12", =
"PD13",
> 				 "PD15", "PD16", "PD17";
>                allwinner,function =3D "emac";
>                allwinner,drive =3D <SUN4I_PINCTRL_40_MA>;
>                allwinner,pull =3D <SUN4I_PINCTRL_NO_PULL>;
>        };
>=20
> 	emac_phy_reset_pin: emac_phy_reset_pin@0 {
> 		allwinner,pins =3D "PD6";
> 		allwinner,function =3D "gpio_out";
> 		allwinner,drive =3D <SUN4I_PINCTRL_10_MA>;
> 		allwinner,pull =3D <SUN4I_PINCTRL_NO_PULL>;
> 	};
> };
>=20
>=20
> /*
> * Board-specific stuff here
> */
>=20
> / {
> 	/*
> 	model =3D "Xunlong Orange Pi One";
> 	compatible =3D "xunlong,orangepi-one", "allwinner,sun8i-h3";
> 	*/
> 	reg_gmac_3v3: gmac-3v3 {
> 		compatible =3D "regulator-fixed";
> 		pinctrl-names =3D "default";
> 		pinctrl-0 =3D <&emac_phy_reset_pin>;
> 		regulator-name =3D "gmac-3v3";
> 		regulator-min-microvolt =3D <3300000>;
> 		regulator-max-microvolt =3D <3300000>;
> 		startup-delay-us =3D <100000>;
> 		enable-active-high;
> 		gpio =3D <&pio 3 6 GPIO_ACTIVE_HIGH>;
> 	};
> };
>=20
> &emac {
> 	phy-supply =3D <&reg_gmac_3v3>;
> 	phy-mode =3D "mii";
> 	phy =3D <&phy1>;
>=20
> 	allwinner,leds-active-low;
> 	status =3D "okay";
>=20
> 	allwinner,use-internal-phy;
> 	resets =3D <&ahb_rst 17>,<&ahb_rst 66>;
> 	reset-names =3D "ahb", "ephy";
> 	clocks =3D <&bus_gates 17>,<&bus_gates 128>;
> 	clock-names =3D "ahb","ephy";
>=20
> 	phy1: ethernet-phy@1 {
> 		reg =3D <1>;
> 	};
> };
>=20
> &ehci2 {
> 	status =3D "okay";
> };
>=20
>=20
>>=20
>>>=20
>>> Cheers,
>>> Jared
>>>=20
>>> On Wed, 21 Sep 2016, Daniel Braniss wrote:
>>>=20
>>>> hi all,
>>>> now that there is thermal control, trying to compile e.g. from =
ports
>>>> portmaster, heats up the cpu, which somewhere around 64C
>>>> decides to halt.
>>>> Now, I remember some weeks ago, with a kernel version
>>>> without the thermal stuff compiling python and all went ok,
>>>> so
>>>> Q: what is the thermal high water mark?
>>>> Q: are the latest changes overheating the cpu, or is the thermal =
driver over
>>>>  cautious?
>>>>=20
>>>> danny
>>>>=20
>>>>=20
>>>>=20


I added a printf to see what is read off the thermal sensor, and the =
first surprise is that it prints it twice for each
sysctl call, next, if I apply the formula from the docs:
	temp =3D (val - 2794) / -14.882
the numbers are much higher!=20

val	C	C=E2=80=99
5ef: 32C  85.67C
5f4: 32C  85.34C
5e0: 34C  86.68C
5e6: 34C  86.28C
5de: 35C  86.82C
5d2: 36C  87.62C
5ca: 37C  88.16C
5ba: 39C  89.24C
5ae: 40C  90.04C
5a9: 41C  90.38C
59d: 42C  91.18C
581: 46C  93.07C
549: 53C  96.83C
541: 54C  97.37C
536: 55C  98.11C
51e: 58C  99.72C
516: 59C 100.26C
509: 60C 101.13C
502: 61C 101.60C
4f7: 62C 102.34C
4ef: 63C 102.88C
4f4: 63C 102.54C
4ea: 64C 103.21C
4eb: 64C 103.14C

Accordingly, the the SHUT0_T_HOT is 0x4E9, and so it shuts down at ~ =
64/103, but I checking the temperature
externally and when it shows 35C, sysctl says 38C but val is 0x5C0

so what the f=E2=80=A6. is going on here?

danny



From owner-freebsd-arm@freebsd.org  Tue Sep 27 21:32:04 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 14F70BEA756
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Tue, 27 Sep 2016 21:32:04 +0000 (UTC)
 (envelope-from embaudarm@gmail.com)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com
 [IPv6:2607:f8b0:400d:c09::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 C689E10DB
 for <freebsd-arm@freebsd.org>; Tue, 27 Sep 2016 21:32:03 +0000 (UTC)
 (envelope-from embaudarm@gmail.com)
Received: by mail-qk0-x230.google.com with SMTP id t7so30264475qkh.2
 for <freebsd-arm@freebsd.org>; Tue, 27 Sep 2016 14:32:03 -0700 (PDT)
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=457kYpONf9KbzukloZL2ih6dhXwXdooh2CcblZWPTUQ=;
 b=YHjCdc43PSh2p18BLNp/BjGSXwdAzK9xmxCY2mjwc3uQ6uatyOUUPYYI66GW/xbKdM
 G4I0JAqMm5E8ztyMYWIHKA5QrZuGVWmUw7Dh41TBomKymhRi0p+GturO50b9EB5Wislo
 zXOGW0XSaMEBEimcjK3sekKDgu1MXzA9QDkdWQI7PX17kEIClEfn31VK0gJzYWkXaVze
 YcfsjEUqoX7JHGXyJ89+rtOa8TUpjW1C7doDu8L0ma9Y/SiO7W5RjLQFXgcv4Qj5iTnz
 963+w0+wLnItA3oDpRbxVgZhtbaaInw6AUJo7BIkUc6pm7uJCGMYkURh+mjCAvq0Ycjx
 A+Pg==
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=457kYpONf9KbzukloZL2ih6dhXwXdooh2CcblZWPTUQ=;
 b=MbEPNQukUMjwgMLsrFaX2tRuRdIrloRzYXVUR+sMDfcOllgqyvOwC/JT/WERd8uMuh
 DNqH7c02IhMe6JJHuH+WcVnLiruZyG6yet83b35ymdlftPDOWFv8CjvxYV19QGrWPjrA
 5FVXQY+gwOyzgMomxg50I/RtWDwHdHVX82xSeLENv1wJiiDx2J6fRfHl0Bk4yOd/ZZYG
 IH8wa/7FPsYaFLT8zzd/Jrh2TP2jBlltQBVgnRJpqMBm5HtdptW4TAZFAVrlS76ThlU6
 xYW1/Zw6qSUrac7v7VXvm+d638PpgF3pXxx0naIdUGn5iSdIwGI0D33eS7YNCvvovR6H
 Fppg==
X-Gm-Message-State: AA6/9RkeJn3hoSY/BrUnqUJEoqWtam4YkyKRDKvvVTJnwyECfdiUDIB51GHNpx8JCJ4urmhZO1b6DLBXvN/sKw==
X-Received: by 10.55.188.195 with SMTP id m186mr32255208qkf.180.1475011922797; 
 Tue, 27 Sep 2016 14:32:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.42.194 with HTTP; Tue, 27 Sep 2016 14:32:02 -0700 (PDT)
From: Lee D <embaudarm@gmail.com>
Date: Tue, 27 Sep 2016 17:32:02 -0400
Message-ID: <CANC_bnOVu7bKvv+mBDb0=hESw17r3B5cccutvBkYdaWrUXAN_w@mail.gmail.com>
Subject: SD-Card driver modification for Zynq questions
To: freebsd-arm <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." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 21:32:04 -0000

Hello,

I have designed a custom Xilinx Zynq board that I am running FreeBSD
10.3 on.

Everything is working well except for my second SD-Card.  The
problem is that I cannot run the card at maximum speed due to a
hardware signal integrity limitation -- which was expected and is
not an issue.

However, it does not seem to be possible to configure the
FreeBSD driver to run at lower than the maximum card speed.  There is
a "max-frequency" parameter that I can set in the DTS file.  But
that parameter specifies the clock frequency of the SDIO controller
in the Zynq part, not the maximum frequency of the card.

If "max-frequency" is changed, then the card ceases to work at all.

So, my questions:

1. Is there a way to set the maximum data rate for card communications?

2. How can I add a parameter to the sdhci/mmc driver so that I can
set the maximum data rate for the card, in the DTS file?

3. Would you please review my hacked-in MMC driver changes, below?

My mmc.c hacks:

In order to limit the maximum card frequency to 20MHz, I tracked down
the place where it was being set in the mmc.c file, and hacked in a
hard-coded limitation.

In src/sys/dev/mmc/mmc.c, in the mmc_calculate_clock() function, right
before the call to mmcbr_set_timing(), I inserted the following code:

  if (device_get_unit(sc->dev) == 1) {
    int max_dtr_limit=20000000;
    if (max_dtr > max_dtr_limit) {
      max_dtr=max_dtr_limit;
    }
    max_timing=0;
  }

The intent is to lower the "max_dtr" variable to 20MHz for device
#1 only.  I am also turning off high speed timing for that device.

This seems to work well.  Is this a viable change for my board?
Is this a good place to insert this limitation?  I don't really
understand the full SDIO/MMC ecosystem so I'm kind of flying
blind here.

Some background:

My DTS file entry looks like this:

  sdhci@101000 {
    compatible = "xlnx,zy7_sdhci";
    reg = <0x101000 0x1000>;
    interrupts = <0x4F>;
    interrupt-parent = <0x1>;
    max-frequency = <0x5f5e100>; // 100 MHz
  };

The reason that I must  limit the maximum data rate to the card
is because I have the card slot connected to the Zynq using EMIO pins.
Xilinx warns that the maximum card data rates will not work when
using EMIO.

Thank you,

Lee

From owner-freebsd-arm@freebsd.org  Wed Sep 28 14:17:01 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 3FC00C013D7
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Wed, 28 Sep 2016 14:17:01 +0000 (UTC)
 (envelope-from thomasskibo@yahoo.com)
Received: from nm21-vm7.bullet.mail.gq1.yahoo.com
 (nm21-vm7.bullet.mail.gq1.yahoo.com [98.136.217.54])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 0D6C211CD
 for <freebsd-arm@freebsd.org>; Wed, 28 Sep 2016 14:17:00 +0000 (UTC)
 (envelope-from thomasskibo@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1475072214; bh=orAva9iqKCWev4Uw6Dbk06QnI0nk7yruEjSj5vBC9Fg=;
 h=From:Subject:Date:To:From:Subject;
 b=PI2FoDBj46ioG4sne6zErsgPLFO776GOFo0gD+JM3CFNWFsBAUSccYwNqQnEsEP3WA6bxtqQ398oRu6XYZEg4hCNDeXgDxIeiQN7GurPCErKXwALtW9FVNnYlbdilnxRVq1kbsDx7v6ZIoY0CKRZ872KcgvOMrnATjXUKt3AYgBox5K2dhPywR3wTv1Isc/QrvZaVB6qGbeyX5JSfZ1Xus5JMneF2hMP+5r3pTxVrOXSw1fCtp86cTSCh7UFTOcLttV8s9syG1BHqHjgBuaHK1T6/tybEDaZd6Xp1b/mIpmDlwSlzIwX8aaraUlABnUEgXCqGTzAsoYysKQpta25FA==
Received: from [216.39.60.180] by nm21.bullet.mail.gq1.yahoo.com with NNFMP;
 28 Sep 2016 14:16:54 -0000
Received: from [98.136.164.65] by tm16.bullet.mail.gq1.yahoo.com with NNFMP;
 28 Sep 2016 14:16:54 -0000
Received: from [127.0.0.1] by smtp227.mail.gq1.yahoo.com with NNFMP;
 28 Sep 2016 14:16:54 -0000
X-Yahoo-Newman-Id: 171281.88073.bm@smtp227.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: c2ptatAVM1nxxOaYNUuisHk3PN8ly8LqA56omdFgjzINuJe
 mv80IUBLZOOEaWz6Hlh_cyBk6nYIbNIOhPkKNtKFfKBUSJ6vsbi2Az40UNrz
 gPRd2OqVwWhyRQyD.NOeFyHlKe7uPYBaqGUtokYUCUoGLk0UPkeKe8wjsQbt
 swpeXfebfG5sZRWQ4uQjeqWNr5cm6NlvNaQvtmCLRk5Xgk027RDCowy62ieM
 tsBz0LzYZ82l00jBco6x5I0fgyfh7fnyQDT9DYWstrb1o_JB.QO4CRVKyjDc
 w.Ruf6rpn7_te3O.tigD_8fHZkA59U1q9T2YCwzOzPIfk_28Wo3YTaolhLXU
 vhDyVvbhHVc7mkux_djtZ3KcM.1EE6MXdKVMWudfrBavzkoxskCAOPT148yS
 A0mvqYP70aivV0DPqn3565XvJsxwUI2EPywI7QSIayY7kyJ2pR_hpC22h0Ef
 .IrK.qVENkxPrzNb8.kmvTVymk0RLB4p44AQkzu4cYZn2dcks9_fsT5D5PGw
 Ggl62h1LKaMc9HhEUhqjOrhz5hJZ0WZpxLq7E5j0.hKNAQbSutRyQaePoDRe
 qPFV9DQh4sxaYp.rzNg--
X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV
From: Thomas Skibo <thomasskibo@yahoo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: SD-Card driver modification for Zynq questions
Message-Id: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
Date: Wed, 28 Sep 2016 07:16:52 -0700
To: freebsd-arm@freebsd.org,
 Lee D <embaudarm@gmail.com>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2016 14:17:01 -0000


Why not just set max-frequency to 200Mhz in the DTS file entry?



=E2=80=94=E2=80=94
Thomas Skibo
thomasskibo@yahoo.com




From owner-freebsd-arm@freebsd.org  Wed Sep 28 21:01:12 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 9AF7BC01621
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Wed, 28 Sep 2016 21:01:12 +0000 (UTC)
 (envelope-from gonzo@id.bluezbox.com)
Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155])
 (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 827EB99A
 for <freebsd-arm@freebsd.org>; Wed, 28 Sep 2016 21:01:12 +0000 (UTC)
 (envelope-from gonzo@id.bluezbox.com)
Received: from [208.184.220.60] (helo=limiting-factor.dolby.net)
 by id.bluezbox.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
 (Exim 4.86_2 (FreeBSD)) (envelope-from <gonzo@id.bluezbox.com>)
 id 1bpLyR-000KVF-Vv; Wed, 28 Sep 2016 14:01:04 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Subject: Re: SD-Card driver modification for Zynq questions
From: Oleksandr Tymoshenko <gonzo@bluezbox.com>
In-Reply-To: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
Date: Wed, 28 Sep 2016 14:00:34 -0700
Cc: freebsd-arm@freebsd.org,
 Lee D <embaudarm@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com>
References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
To: Thomas Skibo <thomasskibo@yahoo.com>
X-Mailer: Apple Mail (2.3226)
Sender: gonzo@id.bluezbox.com
X-Spam-Level: --
X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 The administrator of that system for details.
 
 Content preview:  > On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm
    <freebsd-arm@freebsd.org> wrote: > > > Why not just set max-frequency to
   200Mhz in the DTS file entry? From quick glance it’s not going to help.
   Slot’s max_clk is set to that value but then it’s overwritten in sdhci_init_slot
    by value obtained from register. We need to fix it and also add tunable for
    non-fdt systems. [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2016 21:01:12 -0000


> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm =
<freebsd-arm@freebsd.org> wrote:
>=20
>=20
> Why not just set max-frequency to 200Mhz in the DTS file entry?

=46rom quick glance it=E2=80=99s not going to help. Slot=E2=80=99s =
max_clk is set to that value but then it=E2=80=99s
overwritten in sdhci_init_slot by value obtained from register.  We need =
to fix it and also
add tunable for non-fdt systems.  =20=

From owner-freebsd-arm@freebsd.org  Wed Sep 28 21:52:14 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 2B5F4C0116B
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Wed, 28 Sep 2016 21:52:14 +0000 (UTC)
 (envelope-from thomasskibo@yahoo.com)
Received: from nm29-vm5.bullet.mail.gq1.yahoo.com
 (nm29-vm5.bullet.mail.gq1.yahoo.com [98.136.216.180])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by mx1.freebsd.org (Postfix) with ESMTPS id 00FC81A8
 for <freebsd-arm@freebsd.org>; Wed, 28 Sep 2016 21:52:13 +0000 (UTC)
 (envelope-from thomasskibo@yahoo.com)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048;
 t=1475099376; bh=b8y+CoinN7eENoOX5cG75/JmktDWZPuILuhdQNauUx0=;
 h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject;
 b=ljPD6+o8ivgQpY7BhJ5gEPXiaaUmmMHDso5HWVW5U0x3qQlfMWDm/wFwcSL82FgvcEIRaSOOqFbyXWF5yFlLegVe8d59UWOqhGilKaJ75nVVGwuBbIYWG+hYkOUrlQmUUlbHXP+1KGeCniNmIGk4AddcvjzpkuNVk1i4HH2mY84rkUNCpurzULKiYAX7tcNsWMOWAon1FcKrpcjxCckvPg8fvlw57C5//Mkb37vka5yYWEX5/UcKWUGi8Prv4GH1khbPdNtDvxu1EIaTv1IYpitDaC/IW064dELz7u22wmtPrFz0KZj+oNSBG/VskG3G+mQjT/VS6jQqzvjjDOz4dw==
Received: from [98.137.12.61] by nm29.bullet.mail.gq1.yahoo.com with NNFMP;
 28 Sep 2016 21:49:36 -0000
Received: from [208.71.42.204] by tm6.bullet.mail.gq1.yahoo.com with NNFMP;
 28 Sep 2016 21:49:36 -0000
Received: from [127.0.0.1] by smtp215.mail.gq1.yahoo.com with NNFMP;
 28 Sep 2016 21:49:36 -0000
X-Yahoo-Newman-Id: 15103.96361.bm@smtp215.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: _9NaADMVM1m8q8gXzWDaQ9BrAI2TKR0Dsmbr5VflJ7I1wDJ
 pWFXId9xX5msOqMJpfs5qHZRJHojawFSTgUNl9_9hBy9LB4CeOgIAh5PbvnM
 lT9Rq7D.BljFZ.56Kq3rAXNNOhfdPA0b9p1u1hZzG7Q3lvNX6yzzJ6AuLzKA
 mOY6hK1G5V1JZdlMqZda4MY5J_DeyBAoI7T.9ARpoLtVZjHaQofXcWjFVSTB
 xzzlsXhEBwyUCf1pSBRwzXg1x_zHr.BNCxlejRNZfsUhttrQEZUSLcwHywNj
 O7XgWM4__m9CnIk0X3rDsape6ni8VHvbxKvOs3FrIXDtxOyvTveMVcRww0MR
 qAvD_Oy3Jql6tkg7NcnepMy207wM3y0z4ox8WLQr8meGp9OCelCvgNN6VkEV
 sRtGgFg315an31lm57njkmOhRp3Cd3XKUgGB3p9rVbiqCHKfwt2OUADiWWm7
 6L1_Y2xk.Bk7ayOEeQRXbxa0DSG_KXDuVBvyxQiSeLXJdl3wmPmlVoXYhXdu
 YivsIVA9dHaUi54yq88lB3PsLuUFOtEZHfvjgmGOs9gCxLmym7rY-
X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: SD-Card driver modification for Zynq questions
From: Thomas Skibo <thomasskibo@yahoo.com>
In-Reply-To: <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com>
Date: Wed, 28 Sep 2016 14:49:33 -0700
Cc: freebsd-arm@freebsd.org,
 Lee D <embaudarm@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A3168D37-D612-4E3C-BECB-68EE306534BB@yahoo.com>
References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
 <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com>
To: Oleksandr Tymoshenko <gonzo@bluezbox.com>
X-Mailer: Apple Mail (2.3124)
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2016 21:52:14 -0000


> On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com> =
wrote:
>=20
>=20
>> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm =
<freebsd-arm@freebsd.org> wrote:
>>=20
>>=20
>> Why not just set max-frequency to 200Mhz in the DTS file entry?
>=20
> =46rom quick glance it=E2=80=99s not going to help. Slot=E2=80=99s =
max_clk is set to that value but then it=E2=80=99s
> overwritten in sdhci_init_slot by value obtained from register.  We =
need to fix it and also
> add tunable for non-fdt systems.  =20

I checked the Zynq manual and it looks like it doesn=E2=80=99t provide a =
frequency in the capabilities register so sdhci_init_slot() won=E2=80=99t =
change the slot=E2=80=99s max_clk.



From owner-freebsd-arm@freebsd.org  Wed Sep 28 21:54:31 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 1B124C0124B
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Wed, 28 Sep 2016 21:54:31 +0000 (UTC)
 (envelope-from gonzo@id.bluezbox.com)
Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155])
 (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 F20002D7
 for <freebsd-arm@freebsd.org>; Wed, 28 Sep 2016 21:54:30 +0000 (UTC)
 (envelope-from gonzo@id.bluezbox.com)
Received: from [208.184.220.60] (helo=limiting-factor.dolby.net)
 by id.bluezbox.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
 (Exim 4.86_2 (FreeBSD)) (envelope-from <gonzo@id.bluezbox.com>)
 id 1bpMo8-000Kaa-5F; Wed, 28 Sep 2016 14:54:28 -0700
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Subject: Re: SD-Card driver modification for Zynq questions
From: Oleksandr Tymoshenko <gonzo@bluezbox.com>
In-Reply-To: <A3168D37-D612-4E3C-BECB-68EE306534BB@yahoo.com>
Date: Wed, 28 Sep 2016 14:53:58 -0700
Cc: freebsd-arm@freebsd.org,
 Lee D <embaudarm@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <9859398E-0592-4B8F-A3DA-0364970A92B4@bluezbox.com>
References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
 <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com>
 <A3168D37-D612-4E3C-BECB-68EE306534BB@yahoo.com>
To: Thomas Skibo <thomasskibo@yahoo.com>
X-Mailer: Apple Mail (2.3226)
Sender: gonzo@id.bluezbox.com
X-Spam-Level: --
X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 The administrator of that system for details.
 
 Content preview:  > On Sep 28, 2016, at 2:49 PM, Thomas Skibo <thomasskibo@yahoo.com>
    wrote: > > >> On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com>
    wrote: >> >> >>> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm
    <freebsd-arm@freebsd.org> wrote: >>> >>> >>> Why not just set max-frequency
    to 200Mhz in the DTS file entry? >> >> From quick glance it’s not going
    to help. Slot’s max_clk is set to that value but then it’s >> overwritten
    in sdhci_init_slot by value obtained from register. We need to fix it and
    also >> add tunable for non-fdt systems. > > I checked the Zynq manual and
    it looks like it doesn’t provide a frequency in the capabilities register
    so sdhci_init_slot() won’t change the slot’s max_clk. [...] 
 
 Content analysis details:   (-2.9 points, 5.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -1.0 ALL_TRUSTED            Passed through trusted hosts only via SMTP
 -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1%
                             [score: 0.0000]
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Sep 2016 21:54:31 -0000


> On Sep 28, 2016, at 2:49 PM, Thomas Skibo <thomasskibo@yahoo.com> =
wrote:
>=20
>=20
>> On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko =
<gonzo@bluezbox.com> wrote:
>>=20
>>=20
>>> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm =
<freebsd-arm@freebsd.org> wrote:
>>>=20
>>>=20
>>> Why not just set max-frequency to 200Mhz in the DTS file entry?
>>=20
>> =46rom quick glance it=E2=80=99s not going to help. Slot=E2=80=99s =
max_clk is set to that value but then it=E2=80=99s
>> overwritten in sdhci_init_slot by value obtained from register.  We =
need to fix it and also
>> add tunable for non-fdt systems.  =20
>=20
> I checked the Zynq manual and it looks like it doesn=E2=80=99t provide =
a frequency in the capabilities register so sdhci_init_slot() won=E2=80=99=
t change the slot=E2=80=99s max_clk.

You=E2=80=99re right, I misread code, max-frequency can do the trick.  =
Still tunable may be a good idea.=20=

From owner-freebsd-arm@freebsd.org  Fri Sep 30 02:29:08 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 A4605C02484
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Fri, 30 Sep 2016 02:29:08 +0000 (UTC)
 (envelope-from embaudarm@gmail.com)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com
 [IPv6:2607:f8b0:400d:c09::22e])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id 5EE351A7B
 for <freebsd-arm@freebsd.org>; Fri, 30 Sep 2016 02:29:08 +0000 (UTC)
 (envelope-from embaudarm@gmail.com)
Received: by mail-qk0-x22e.google.com with SMTP id n189so22277909qke.0
 for <freebsd-arm@freebsd.org>; Thu, 29 Sep 2016 19:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=lt7XdQQo85Bfx5fnu21/6HmBZeL80EjEqhmS6WRmgM8=;
 b=opoYAYyJumFvZ8LH1q/iH6S7BZee8XCd/+rdricu7Fu8gIYPMpgkg9BrJ8N4u8gXxG
 NOL4do1Tbi5omYSjMOIlT0PH9Gwus6nN/I6fuL7PLL8tSLHC1FOScnOwpFv7zXTyT04w
 /+KH2BrutU8IY5PUwazVZB74UG3XjkVRFsbxDinDheV50TcLTvyb8h1qipxYwrqdP8Jo
 zaTJWVLhaKf97+cthHqouCT5kWsnJ27Qm5kef8xA9wwYiBiyen7YaIxc5MN60u4kNDi1
 r8zq22fJn1ogeDHkG6Vhmi2mZki/C2T16zOGk08oo+ILV0sBbsvp7CFXDhVf/bwsGWxj
 eQuw==
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=lt7XdQQo85Bfx5fnu21/6HmBZeL80EjEqhmS6WRmgM8=;
 b=K0mH3E2JGWj7dYfJ0V+2OCejYw7U/vRX2o1LbugLU/xi/H+KpDwrqzjZeTX5aFnGdP
 +Npz8xVvOn+JJuPI9qCnOp9zfkewsl1n7Ug4gSUW+joPs7MVACvn7DKBK8ROz0VxdSgN
 /hOjvZNPNfGJPdtbj0nQYV454rFXByP/2R9QEiB6yt+kcRbdFLflQm+Npo/NaoygPV56
 jr8Sv+18s0pCahkxgFasA6dcwtASOpR9JR2kx44oKGxFOXqT/9uF/eyO4NwhaLdwA73b
 8wa+oDdBlA1B1/e41JQTJfPuWQQBCCN1BB6/sKNKQ1GyFQDxH7i0CPg1NrnPgkZFIc9R
 wBSg==
X-Gm-Message-State: AA6/9RmMhRpRrLinvFUBWKBsEdAZa54ihFjpBfAjAN277esJ+KYSmUQfl0fqF6e4tc7g5Iv/vb1irmAxtgRWDg==
X-Received: by 10.55.104.199 with SMTP id d190mr4825572qkc.163.1475202547651; 
 Thu, 29 Sep 2016 19:29:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.42.194 with HTTP; Thu, 29 Sep 2016 19:29:07 -0700 (PDT)
In-Reply-To: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
From: Lee D <embaudarm@gmail.com>
Date: Thu, 29 Sep 2016 22:29:07 -0400
Message-ID: <CANC_bnN+Eey8Dhn2kyWtYC0R_he8Xx9DL8D8VqGzuoL5g29O5Q@mail.gmail.com>
Subject: Re: SD-Card driver modification for Zynq questions
To: Thomas Skibo <thomasskibo@yahoo.com>
Cc: freebsd-arm <freebsd-arm@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 02:29:08 -0000

On Wed, Sep 28, 2016 at 10:16 AM, Thomas Skibo <thomasskibo@yahoo.com>
 wrote:

>
> Why not just set max-frequency to 200Mhz in the DTS file entry?
>
> =E2=80=94=E2=80=94
> Thomas Skibo
> thomasskibo@yahoo.com
>
>
I hadn't thought of that.  I think you are suggesting that I tell the
driver that the clock speed is higher than it is so all of the clock
divisors are set higher, which would result in a lower data rate.

That's a clever idea,  but I think I would actually have to set the
max-frequency to 500MHz, since some cards are capable of operating up to
100MHz and my SD-Card slot can only run (safely) at 20MHz.   That means at
that all normal 25MHz cards would run dramatically slower than they need
to.

In the event that I can't figure out how to make a new DTS file parameter
for max data rate, do you think that my modification is a decent way to
accomplish my goal?

Thanks,

Lee

From owner-freebsd-arm@freebsd.org  Fri Sep 30 02:39:45 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 398EAC027EB
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Fri, 30 Sep 2016 02:39:45 +0000 (UTC)
 (envelope-from embaudarm@gmail.com)
Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com
 [IPv6:2607:f8b0:400d:c09::22e])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (verified OK))
 by mx1.freebsd.org (Postfix) with ESMTPS id E67F31EED
 for <freebsd-arm@freebsd.org>; Fri, 30 Sep 2016 02:39:44 +0000 (UTC)
 (envelope-from embaudarm@gmail.com)
Received: by mail-qk0-x22e.google.com with SMTP id z190so95562965qkc.3
 for <freebsd-arm@freebsd.org>; Thu, 29 Sep 2016 19:39:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=2f1E0jqHHo6f7pjCPWL8fmRr+ttIB5m8y1uckocyLlI=;
 b=MOPeycF6S/4im561F4U/ldFRj8Ac7eGwhNXQ2lIxxMCa6l/8pAW2QRKUIJGlJ5v5Ej
 0G+sTygvRkpAKfxAngnk0rH+3BNXlYN2UUAwJOKDcSj7vTcSPAlAIbfvCWvTDhlzGzga
 AxLFYmsCNsn1/BCYOKOgBY+vyXBPWSrVGT1Z5ZVfgig3WsUt1mGgITEgbauOolFuZC4A
 qJ7DxhpIt8btBzlKIYIJtfsZSd5q929QK9LO99RLRlPVsDoW6HwELUm3SOVcQ9oxOmfN
 NaBlaLqcnb7llmTHDcPV9uAcPlQZao+5sDccAfuY+LMHU3WQZ9Kgb/PPpEXXHoGYwMW5
 zvJw==
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=2f1E0jqHHo6f7pjCPWL8fmRr+ttIB5m8y1uckocyLlI=;
 b=iyTSDWKYj4L8isNxijhuIG/mRohQQr062rYPr1DxSjj90BAn2YbkwL+jN/qHneY4TG
 NuYkZxdGgfH+P9TXzn4/c9TVKPXmfCF6VMUKcZK+Le3uhWY2X9dUuyFhMO1j/n8WNxMY
 V/VstFU4EfRF68DLDjbl0XmY+SBaHAN3zKaY1uPSRSfrFYbTM7ZjEYYDbQBSXTv61Zsh
 mArKXne23nBfUY5WhWtBneMv6hzbx2l76fTc5YCmb+pCCggsS4ThDzMyI/ZdiyvIRLI7
 wA6sJC5QUF7bkITclPGqr6llRXTK9Di1ClzYBX1KdkFY32EakeBO0ydpy/pt46AVneok
 lAsw==
X-Gm-Message-State: AA6/9RkHl6UVrF3fIz4ovVvA1noLve7DLdgSshZs32KSjsF4aK0FNayvCYxuYZ83cCLXP7+SBxr9TgWLK92NwQ==
X-Received: by 10.55.185.130 with SMTP id j124mr4480503qkf.84.1475203184134;
 Thu, 29 Sep 2016 19:39:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.42.194 with HTTP; Thu, 29 Sep 2016 19:39:43 -0700 (PDT)
In-Reply-To: <9859398E-0592-4B8F-A3DA-0364970A92B4@bluezbox.com>
References: <02E012FA-342E-4EB7-99F2-733FA7990BDD@yahoo.com>
 <49016789-66F8-4B34-9FA7-8E97143634AF@bluezbox.com>
 <A3168D37-D612-4E3C-BECB-68EE306534BB@yahoo.com>
 <9859398E-0592-4B8F-A3DA-0364970A92B4@bluezbox.com>
From: Lee D <embaudarm@gmail.com>
Date: Thu, 29 Sep 2016 22:39:43 -0400
Message-ID: <CANC_bnMz6As=0FKnWTHN4_xSoWNugHJeHR9HCcAO8XMwRyhUmw@mail.gmail.com>
Subject: Re: SD-Card driver modification for Zynq questions
To: Oleksandr Tymoshenko <gonzo@bluezbox.com>
Cc: Thomas Skibo <thomasskibo@yahoo.com>, freebsd-arm <freebsd-arm@freebsd.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Content-Filtered-By: Mailman/MimeDel 2.1.23
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 02:39:45 -0000

On Wed, Sep 28, 2016 at 5:53 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com>
wrote:

>
> > On Sep 28, 2016, at 2:49 PM, Thomas Skibo <thomasskibo@yahoo.com> wrote=
:
> >
> >
> >> On Sep 28, 2016, at 2:00 PM, Oleksandr Tymoshenko <gonzo@bluezbox.com>
> wrote:
> >>
> >>
> >>> On Sep 28, 2016, at 7:16 AM, Thomas Skibo via freebsd-arm <
> freebsd-arm@freebsd.org> wrote:
> >>>
> >>>
> >>> Why not just set max-frequency to 200Mhz in the DTS file entry?
> >>
> >> From quick glance it=E2=80=99s not going to help. Slot=E2=80=99s max_c=
lk is set to that
> value but then it=E2=80=99s
> >> overwritten in sdhci_init_slot by value obtained from register.  We
> need to fix it and also
> >> add tunable for non-fdt systems.
> >
> > I checked the Zynq manual and it looks like it doesn=E2=80=99t provide =
a
> frequency in the capabilities register so sdhci_init_slot() won=E2=80=99t=
 change
> the slot=E2=80=99s max_clk.
>
> You=E2=80=99re right, I misread code, max-frequency can do the trick.  St=
ill
> tunable may be a good idea.


Setting max-frequency to an incorrect value will technically work, but it
will make many cards run much more slowly than they need to.  See my other
post.

It would be nice to have a DTS file parameter to set the max data rate of
the card.  Do you have any pointers on where I might find information on
how to do this?

I have read "FreeBSD Device Drivers: A guide for the intrepid", but it only
scratches the surface.  I've written a few drivers for my custom devices
but I think I am pretty far from being able to do any serious kernel work.
One thing I am confused about is how drivers talk to each other.  I spent a
few days trying to understand the source for the mmc and sdhci drivers but
there is a lot going on that I couldn't figure out.

Thanks,

Lee

From owner-freebsd-arm@freebsd.org  Fri Sep 30 23:28:22 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 7B1F2C04DDE
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Fri, 30 Sep 2016 23:28:22 +0000 (UTC)
 (envelope-from contact=lactasoy.com@txm15.net)
Received: from svout-c19-48.txmsv.com (svout-c19-48.txmsv.com [203.150.19.48])
 by mx1.freebsd.org (Postfix) with ESMTP id C0FAF10F5
 for <freebsd-arm@freebsd.org>; Fri, 30 Sep 2016 23:28:21 +0000 (UTC)
 (envelope-from contact=lactasoy.com@txm15.net)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=mail; d=txm15.net;
 h=Date:Sender:To:From:Reply-to:Subject:Message-ID:List-Unsubscribe:MIME-Version:Content-Type;
 i=contact=3Dlactasoy.com@txm15.net; 
 bh=Vl/v6vSvAZtoSc5Sb1HHqKEjcuw=;
 b=eW2Dig010Ah6aCl8O8ovC8YdON+37HEtrGSpnYe1ZeIVhWOGAc71UFjOhgLcNpXZ0e5GY+ko3bkw
 uL1dY886NcbScDhtkOOCjBsL/Bd/FXXHX4bhfUlDIfPnLZmQk/B3Yvrb8awClAlsvaM42ffcYK5s
 wfo3eM1S8SjRwcKzuCY=
DomainKey-Signature: a=rsa-sha1; c=nofws; q=dns; s=mail; d=txm15.net;
 b=Ncmt2BrQ72Owvk6RSZCOwBUf+T/H+H4Iw8KFL/6HpfMcBVKrQgILdDHpXULgiTNiij6kKt3w/1o8
 wKiaX8lMNRU6e1sJWgiZsEbbzKmRxcEOS4f3sBIDry6JP7S4nuELmkPYCS0saFMhqF2AAi/Vy1BZ
 4AU7C8z0NvHIjl+0E+o=;
Received: from localhost.localdomain (203.150.19.243) by
 svout-c19-48.txmsv.com for <freebsd-arm@freebsd.org>;
 Sat, 1 Oct 2016 06:25:07 +0700 (envelope-from
 <contact=lactasoy.com@txm15.net>)
Date: Sat, 1 Oct 2016 06:25:06 +0700
Sender: =?UTF-8?B?4LmB4Lil4LiE4LiV4Liy4LiL4Lit4LiiIOC4nuC4peC4seC4h+C5gOC4iCDguJ7guKXguLHguIfguYPguIg=?=
 <contact=lactasoy.com@txm15.net>
To: freebsd-arm@freebsd.org
From: =?UTF-8?B?4LmB4Lil4LiE4LiV4Liy4LiL4Lit4LiiIOC4nuC4peC4seC4h+C5gOC4iCA=?=
 =?UTF-8?B?4Lie4Lil4Lix4LiH4LmD4LiI?= <contact@lactasoy.com>
Reply-to: =?UTF-8?B?4LmB4Lil4LiE4LiV4Liy4LiL4Lit4LiiIOC4nuC4peC4seC4h+C5gOC4iCA=?=
 =?UTF-8?B?4Lie4Lil4Lix4LiH4LmD4LiI?= <contact@lactasoy.com>
Subject: =?windows-874?B?4L7VwqfD6MfB4arD7KHUqKHDw8G51ekgoefgu+e5yujHucu51uin47mh0sPK?=
 =?windows-874?B?wbe6t9i5qujHwuDLxdfNvNnpu+jHwuLDpMvRx+OoIKHRuiDDvi6o2MzSxaeh?=
 =?windows-874?B?w7PsysDSodKq0rTkt8I=?=
Message-ID: <0254238926b6b7784eb9a3058da71c01@localhost.localdomain>
X-Mailer: TaxiMail2 
X-Mailer-Pool: recipient-5
X-Campaign: 515-51-d008qvb-57eef1dc59d262335406c940
X-Complaints-To: fbl@txm15.net
X-Report-Abuse: http://lactasoy.th.listmng.com/cb/f/515/51/d008qvb
X-Report-Abuse-To: fbl@txm15.net
MIME-Version: 1.0
Content-Type: text/plain; charset = "UTF-8"
Content-Transfer-Encoding: base64
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." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Sep 2016 23:28:22 -0000

LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CklzIHRoaXMgZW1haWwgbm90IGRpc3BsYXlpbmcgY29ycmVjdGx5PyBWaWV3IGl0IGluIHlvdXIg
YnJvd3NlciBhdCBodHRwOi8vbGFjdGFzb3kudGgubGlzdG1uZy5jb20vY2IvYi81MTUvNTEvZDAw
OHF2Yi9GCgpUaGlzIG1lc3NhZ2Ugd2FzIGRlbGl2ZXJlZCB0byBmcmVlYnNkLWFybUBmcmVlYnNk
Lm9yZy4KSWYgeW91IHByZWZlciBub3QgdG8gcmVjZWl2ZSB0aGVzZSBtZXNzYWdlcyBpbiB0aGUg
ZnV0dXJlLCBwbGVhc2UgdW5zdWJzY3JpYmUgYXQgaHR0cDovL2xhY3Rhc295LnRoLmxpc3Rtbmcu
Y29tL2cvdS81MTUvNTEvZDAwOHF2Yi9GCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQrCqSAyMDE2IExhY3Rhc295IENvLiwgTHRkLiBBbGwg
cmlnaHQgcmVzZXJ2ZWQuCiAzMzUyIFN1a2h1bXZpdCBSb2FkLCBCYW5nbmEsIEJhbmduYSwgQmFu
Z2tvayAxMDI2MA==


From owner-freebsd-arm@freebsd.org  Sat Oct  1 10:30:44 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 552F3C037A6
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Sat,  1 Oct 2016 10:30:44 +0000 (UTC)
 (envelope-from yamori813@yahoo.co.jp)
Received: from nh504-vm3.bullet.mail.kks.yahoo.co.jp
 (nh504-vm3.bullet.mail.kks.yahoo.co.jp [183.79.57.89])
 by mx1.freebsd.org (Postfix) with SMTP id EB04BF03
 for <freebsd-arm@freebsd.org>; Sat,  1 Oct 2016 10:30:43 +0000 (UTC)
 (envelope-from yamori813@yahoo.co.jp)
Received: from [183.79.100.141] by nh504.bullet.mail.kks.yahoo.co.jp with
 NNFMP; 01 Oct 2016 10:29:00 -0000
Received: from [183.79.100.133] by t504.bullet.mail.kks.yahoo.co.jp with NNFMP;
 01 Oct 2016 10:29:00 -0000
Received: from [127.0.0.1] by omp502.mail.kks.yahoo.co.jp with NNFMP;
 01 Oct 2016 10:29:00 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 615565.39995.bm@omp502.mail.kks.yahoo.co.jp
Received: (qmail 96744 invoked by uid 60001); 1 Oct 2016 10:29:00 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp;
 s=yj20110701; t=1475317740; bh=Bv2UJk3q1fm/9i+WlI2nd+2DuoaWzB2P9L0/IJm+APw=;
 h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=IBe5gaqfoCmfI/YoqA0ZTrZf9z1vV2sDH6xunuEoyvFIE1N5eFHx00vZtKz003sSHMU496Wl53qKo+BpovmD9/dzi45hL05L+RdvmJSopXg16QAIYeb6YkuW669FmG+gxihz2gV/OZ/Off28sB5W3goNWRyYY2761Jpli0Ak7yA=
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=yj20110701; d=yahoo.co.jp;
 h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:References:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
 b=nHPBrNHwiiQaPBevpJwF1TXaif5i8CplM0kGkuIhLDr9uyzEo3Tm8I/9tmByP7psVXWFfpV0oJ5eY2irQCn8xwFGv/payXZXnRbiIlS/MME346pTiR5ZJRFvPWoFgl4IJSWFtOTAKnKTdr4yB1J246vCPq9HesvdSj6W0YdJ8cA=;
Message-ID: <309539.93259.qm@web101708.mail.ssk.yahoo.co.jp>
X-YMail-OSG: 27qY8KEVM1llD4RCDtXy_vqg4E1msiltw8irnfQLt6ZXHF9erRKOTfroBnra6ti5gQvhXt0PYvl7nHjamDO19wmROwj8.7ig_9C6ZHkhL8PuWz2zY5GVDGHcrf5TqmkK7b4Tx5tkuOvuZ06SN1_ppT2rA7x9ZtRzNPvkBiNZ6POoz0_BWoPyEFGKfXNZF12NbqYKpnKS6imtsBm0M9h4GLSYhArLT7G8tAaNVDaDKXTnXdhjwtFmw86K7Q5WjZ79L3gzygYqX5wBn5M865KuJ222Ak33oUNyvo3HE.GBwc5Ta7hrzdKVolQQoQGQwdlmFghtfm_iRedN1iRh4zDd6TvCdNDjQbIsop2XXFD3hNFMWea7hfXW.nuC87IdGupa0E2O4Kwq8amAgOilioXOZizPmwitKgpS2A9qZTHLbuyamgH_k8AahPCHed6GxGhAfkPly6Y3_g.q1RHQ8ryyeHUVrEmpaM4Wg9owMUUiw06xYATPsbwgMoMahl3fP5LRP8oCwvj9h945UFzf_QpV2vzbuT4cxr7gz2Qevs8ZnJpyt6O9K47o
Received: from [110.134.196.53] by web101708.mail.ssk.yahoo.co.jp via HTTP;
 Sat, 01 Oct 2016 19:29:00 JST
X-Mailer: YahooMailWebService/0.8.111_69
X-YMail-JAS: L0slSO8VM1kFGkK3cRzFaelj5d5WQzNoWXkWL3KJ5B0XHuWMMS5x6TXGDkNcPmi8U6QYWnM6xCFqFrrSVr3rZKAPKLaczIAvQYT.SdQkaYRUJXaBLwhgulz7JnLzG_pv93Sr
References: <201604191539.u3JFdkHx048678@repo.freebsd.org>
 <CAJ-VmonyZR-CiPxceAvVzxDjL7WXDAix-Pmj2RRqp+9gj3u0hA@mail.gmail.com>
 <20160419171243.GA30453@bsdpad.com>
 <CACVs6=_pN9VAz1kkQQAL-ftKof+kkn5MgxDP1kWj9kM-x=AzbQ@mail.gmail.com>
 <1461097280.1232.34.camel@freebsd.org>
 <CAD44qMV1bRA9USafKLSdKv8CcES34G8Kbt54OspaAA_Xdb07xg@mail.gmail.com>
 <CAJ-Vmo=GiP_NXfBz5ZsJkBm8Ypm-t0udZRqX9BkTa0KuC1bvrw@mail.gmail.com>
 <CAD44qMWJeTNuXS+B1ecJUFN63dweYZRKKG4Ek7kxMk-Mme7=+Q@mail.gmail.com>
 <CAD44qMWbOUaveDtq+Hn_cYAiU_VGwFEgYJ1vSFYv=4G9XSzzbQ@mail.gmail.com>
 <CAJ-Vmokwd2wYDMrHQYGBbfvDZ6=32EatZp3k-j1cwUYDMFf+Tg@mail.gmail.com>
 <CAD44qMWAEGYJWANW6-4Pf-cCcgsRP_JYbSNhz6Xtv8AM+HwD0w@mail.gmail.com>
 <CAJ-Vmo=ZMygr--HRQen8QQs+bME0_u3KKwgwk3zzm6QNHwYZ6g@mail.gmail.com>
Date: Sat, 1 Oct 2016 19:29:00 +0900 (JST)
From: Mori Hiroki <yamori813@yahoo.co.jp>
Reply-To: Mori Hiroki <yamori813@yahoo.co.jp>
Subject: Re: svn commit: r298274 - head/sys/dev/spibus
To: Adrian Chadd <adrian@freebsd.org>, Patrick Kelsey <pkelsey@freebsd.org>
Cc: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>,
 Ruslan Bukin <br@freebsd.org>,
 "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org>
In-Reply-To: <CAJ-Vmo=ZMygr--HRQen8QQs+bME0_u3KKwgwk3zzm6QNHwYZ6g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
X-BeenThere: freebsd-arm@freebsd.org
X-Mailman-Version: 2.1.23
Precedence: list
List-Id: "Porting FreeBSD to ARM processors." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Oct 2016 10:30:44 -0000

Hi.=0A=0AI add SD card socket to my=A0WZR-HP-G300NH(AR9132).=0A=0Ahttps://f=
lic.kr/p/MAuUBf=0A=0A=0AI am looking forward to support mmcspi.=0A=0ARegard=
s=0A=0AHiroki Mori=0A=0A=0A----- Original Message -----=0A> From: Adrian Ch=
add <adrian@freebsd.org>=0A> To: Patrick Kelsey <pkelsey@freebsd.org>=0A> C=
c: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org>; Ruslan Bukin <br@fr=
eebsd.org>; "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org>=0A> Date:=
 2016/5/26, Thu 14:00=0A> Subject: Re: svn commit: r298274 - head/sys/dev/s=
pibus=0A> =0A> On 25 May 2016 at 18:57, Patrick Kelsey <pkelsey@freebsd.org=
> wrote:=0A>> =0A>>  On Fri, May 20, 2016 at 2:35 AM, Adrian Chadd <adrian@=
freebsd.org> =0A> wrote:=0A>>> =0A>>>  I've reviewed the patches from luiz,=
 and these look fine. but =0A> indeed,=0A>>>  this patchset does set/releas=
e the bus each transaction so we can do=0A>>>  multiple transactions whilst=
 holding the bus.=0A>>> =0A>>>  Which is fine, but it means I have to undo =
ruslan's removal in the =0A> below=0A>>>  commit.=0A>>> =0A>>>  I'm happy t=
o run through and do each of the spi bus drivers (as =0A> there=0A>>>  are =
more now than the two you patched) but it's a bit close to the=0A>>>  11.0-=
release cycle to go and churn the spibus code.=0A>>> =0A>>>  But, if people=
 think it's worth doing it so we can try to get =0A> mmcspi=0A>>>  into the=
 tree before 11.0-rel is cut, I'm happy to run through and =0A> do=0A>>>  i=
t. I actually have some AR9331 stuff now that could use mmcspi. :)=0A>>> =
=0A>>>  What do people think?=0A>>> =0A>> =0A>>  Thanks, Adrian.=A0 My opin=
ion is that the changes to the spi bus interface =0A> and=0A>>  the corresp=
onding changes to the spi bus drivers you are talking about are=0A>>  very =
straightforward and low risk.=A0 There is non-zero other interest out=0A>> =
 there in using the mmcspi driver, based on the couple of emails I've=0A>> =
 received seeking help on the subject in the last six months or so, so I=0A=
>>  don't think this would be just a commit for the sake of getting some=0A=
>>  interesting new code in.=0A> =0A> loos and i are thinking about it. I m=
ay start landing some of the=0A> spibus changes tonight just to lay the fou=
ndation.=0A> =0A> =0A> =0A> -adrian=0A> ___________________________________=
____________=0A> freebsd-mips@freebsd.org mailing list=0A> https://lists.fr=
eebsd.org/mailman/listinfo/freebsd-mips=0A> To unsubscribe, send any mail t=
o =0A> "freebsd-mips-unsubscribe@freebsd.org"=0A> 

From owner-freebsd-arm@freebsd.org  Sat Oct  1 23:18:08 2016
Return-Path: <owner-freebsd-arm@freebsd.org>
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 DA83FA94E60
 for <freebsd-arm@mailman.ysv.freebsd.org>;
 Sat,  1 Oct 2016 23:18:08 +0000 (UTC)
 (envelope-from lists@felix-maurer.de)
Received: from mail.felix-maurer.de (felix-maurer.de
 [IPv6:2a02:c200:1:10:3:0:7193:1])
 by mx1.freebsd.org (Postfix) with ESMTP id A898F19A
 for <freebsd-arm@freebsd.org>; Sat,  1 Oct 2016 23:18:08 +0000 (UTC)
 (envelope-from lists@felix-maurer.de)
Received: from Felix-MBP.fritz.box
 (p2003008B2F5CE700D94B6D71FB913B91.dip0.t-ipconnect.de
 [IPv6:2003:8b:2f5c:e700:d94b:6d71:fb91:3b91])
 by mail.felix-maurer.de (Postfix) with ESMTPSA id 933781B84770
 for <freebsd-arm@freebsd.org>; Sun,  2 Oct 2016 01:17:05 +0200 (CEST)
Message-ID: <57F0440A.4060709@felix-maurer.de>
Date: Sun, 02 Oct 2016 01:17:30 +0200
From: Felix Maurer <lists@felix-maurer.de>
User-Agent: Postbox 5.0.3 (Macintosh/20160930)
MIME-Version: 1.0
To: freebsd-arm@freebsd.org
Subject: FreeBSD on Pine64: ubldr for arm64
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset=UTF-8
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." <freebsd-arm.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arm/>
List-Post: <mailto:freebsd-arm@freebsd.org>
List-Help: <mailto:freebsd-arm-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>,
 <mailto:freebsd-arm-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 01 Oct 2016 23:18:08 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

I am currently trying to build a FreeBSD image with Crochet to boot on
the Pine64.

Thanks to the sysutils/u-boot-pine64 port I already got a working SPL
that starts U-Boot. The normal way to continue booting a image built by
Crochet is to start ubldr. But at the moment there is no arm64 version
of ubldr in the tree.
The only thing I found about this is this diff:
https://reviews.freebsd.org/D5512 . It has been lying around there since
March and the last comments state that the changes are unnecessary now
for the RPI3 because a way has been found to boot on a RPI3 without
U-Boot. Now I have two questions:

1. Is there a chance for the diff to make it into the tree? Although it
is no longer needed for the RPI3 it may be needed by other boards.
2. As an alternative: What is this mysterious way to boot without U-Boot
and may this be possible for other boards like the Pine64?

Regards,
Felix
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCgAGBQJX8EQKAAoJEEy46Yy6oqJ0ZZYQAIdDp6zwuCa7FsP1XGcOomnw
qYftBWerVZZYuiXKrwtmAaKDY/OTn4WNwvEMUa5Zp4ny01QUV5DW+TcbDfdfV/9W
T+dNOhsbzWbUvaK3U2y8fmrNs8TswtEENpFhlaPWNeloDqocFtvyvTKS7IQQYnMQ
UFE+VPvMw9kZORKblNdQb4e4sGgQdq2QtyFaPmtrpzg8ax0NJFciRG7myhrVqQ5R
kOClK5loPJSfSebN7YpePablGHjXyS/IKjtvds5VpDMe8jJ8b+dPmHCumeSJ6vor
lccX6J+WXlLtdCeIBD8Z1TMT4XKX6Gz60WWMSf6XysNldkxl2y2k9mfSTTxGdygc
SSDpRGZh7xqwySZhF6/7L6Wz/uwXp9iI94BgW+uTXlJ0+GARt+xR4ArNL4jYFED2
eLxvTyVVxt8lCVMJZAPdVH87SEB1MNEwzYzu8r7Hmj+5q9rUyv3bJeCnRPdf9XAP
DQVRYvimVW7uR21REYlwb+uS/169As0g7LR5kk2zBbaemc8PcL4QAvyTNwpLWYfS
qznwqcN1ca1Unoo9vn7zYPmBavKunobrbjl4GjKDh1kuOmWKx4C+LUj7qT8+yAY9
SgD/98Wl8QMTNmCdgICVMYHdyzDVO66WLBI48kbEESi1RT/ESbQAm6bCScl8h+Av
/znPEvXG2SCueYu34EPF
=CGiK
-----END PGP SIGNATURE-----