From owner-freebsd-arm@freebsd.org Sun Jun 18 07:21:02 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4076CD8AF7F for ; Sun, 18 Jun 2017 07:21:02 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from nh602-vm10.bullet.mail.ssk.yahoo.co.jp (nh602-vm10.bullet.mail.ssk.yahoo.co.jp [182.22.90.35]) by mx1.freebsd.org (Postfix) with SMTP id CE8F02C3B for ; Sun, 18 Jun 2017 07:21:01 +0000 (UTC) (envelope-from yamori813@yahoo.co.jp) Received: from [182.22.66.105] by nh602.bullet.mail.ssk.yahoo.co.jp with NNFMP; 18 Jun 2017 07:17:55 -0000 Received: from [182.22.91.131] by t603.bullet.mail.ssk.yahoo.co.jp with NNFMP; 18 Jun 2017 07:17:55 -0000 Received: from [127.0.0.1] by omp604.mail.ssk.yahoo.co.jp with NNFMP; 18 Jun 2017 07:17:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 193272.39462.bm@omp604.mail.ssk.yahoo.co.jp Received: (qmail 20323 invoked by uid 60001); 18 Jun 2017 07:17:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.jp; s=yj20110701; t=1497770275; bh=4e3IkrT7iC8f/hW6FCeKIxdi8nD9OPo9KpcTrX3kxII=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:X-YMail-JAS:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=otZ/dpNpLkN8er6+PXwvBZKUKwWQGKrV8TJ9RyAGuyJYQH+dkiTzRnaL997+S6//R9dbRo+KUbpflMJS4pcdyfnJLl7i5mWHEUUwu7YqyfVCyVD7ebaG0kejRBhWdTnqv/HnCmGlylZJBWmsoN4s6BsZKo6WEubMm3tKr/A42kY= 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:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=n1kqmoPoOnSyzVs5f7YbotSRtD/13fQqj+2nPq8vJH36CAjJ8Oma64BGPHPHtkFmFx8PAjvrUFLdnmg7/Jkbo4ga9VKpTomTALEbZYgcCOQcjKMv3odGZjzcQoZOmmyAIhpEZ+HlTVQqmcZwIpLkJtKW4zgKYFTbPc0yOwqYwrM=; Message-ID: <23328.14569.qm@web101713.mail.ssk.yahoo.co.jp> X-YMail-OSG: 0RnM4FkVM1l70LT396EbbQvqRigfM.Wb8M_FLpOJzQeqNImX8OdNRQ0TxuMGT9KPNLIfRLroeFKLCNKw4q1d9pozDL0ZDmucu.TkIU.XKCYE4CS9MOkYetGZTQZWmHkjvsVBFMJO_2WMHSb5w.Zcryt7EarKsAReIXswuBN4hKHlZITsolty4h_hMHOsCsrirE_dE7vwmVuabQgeH5scPq5ANUrmSiXF2p2cWq8kqYO3P130vRhVi1ybfRKRRroZI_vZ_rhh2Z_TkAa19HfqWE0flyZCKxrYa4YnSfqRaC5scE.p1ujmZHVXleZCdBsJdzDqz6Omi7n9dUP_8gp2aVp02RpU88I51UloVstyQkQ5AQm_4jOuVZXyUFLrcxZWUIj96WDW_3AKbMOg0yCPeck3zNAydqzJSJdP0GsdgjBSG9_FbYhhnZghWuv8hJ7abwyyxs4aR3mEQ3861y_eNroQdU5ueDjKaVcy68qnYPiNxN.enpHIrpMfwfhphadhLkIcGjdJ8lKnCfV_dbKitBaNIad4LVeBzaO4EXx6CKLr7BK8FrL4QlGSBzfFSf5TI_xiGKlMAZiEhrXFC7g5ej.CB6KRZo43LICOwXJATWg- Received: from [61.24.128.67] by web101713.mail.ssk.yahoo.co.jp via HTTP; Sun, 18 Jun 2017 16:17:54 JST X-Mailer: YahooMailWebService/0.8.111_71 X-YMail-JAS: F4NRzowVM1lOqcQ4ebbXJfvOZJ2Inop5rd7cbzozU0_GQMc.BbX63HgspxOvoGeTrcM8fMDWnsgFRm38n7PSBiHCQOK07JrG2_KTIwBT8zYKnLDYABsgAuSx7IyWsG6E8YGS Date: Sun, 18 Jun 2017 16:17:54 +0900 (JST) From: Mori Hiroki Reply-To: Mori Hiroki Subject: build error To: "freebsd-arm@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 07:21:02 -0000 Hi=A0=0A=0AI have build error today head code.=0A=0Acc -target arm-gnueabi-= freebsd12.0 --sysroot=3D/storage/home/hiroki/obj//storage/h=0Aome/hiroki/zr= outer/tmp//arm.arm/storage/home/hiroki/freebsd/tmp -B/storage/home/=0Ahirok= i/obj//storage/home/hiroki/zrouter/tmp//arm.arm/storage/home/hiroki/freebsd= =0A/tmp/usr/bin -c -x assembler-with-cpp -DLOCORE -O2 -pipe -fno-strict-ali= asing=A0 =A0=0A-nostdinc=A0 -I. -I/storage/home/hiroki/freebsd/sys -I/stora= ge/home/hiroki/freebsd=0A/sys/contrib/libfdt -I/storage/home/hiroki/freebsd= /sys/gnu/dts/include -D_KERNEL=0A=A0-DHAVE_KERNEL_OPTION_HEADERS -include o= pt_global.h -march=3Darmv5te -funwind-tabl=0Aes -MD=A0 -MF.depend.elf_note.= o -MTelf_note.o -ffreestanding -fwrapv -Wall -Wredun=0Adant-decls -Wnested-= externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-a=0Arith -Winlin= e -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=3D__freebsd_kprin=0Atf= __ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -W= no-=0Aerror-tautological-compare -Wno-error-empty-body -Wno-error-parenthes= es-equality=0A=A0-Wno-error-unused-function -Wno-error-pointer-sign -Wno-er= ror-shift-negative-va=0Alue -Wno-error-address-of-packed-member=A0 -mfpu=3D= none=A0 -std=3Diso9899:1999=A0 -Werror=A0=0A/storage/home/hiroki/freebsd/sy= s/arm/arm/elf_note.S=0A/storage/home/hiroki/freebsd/sys/sys/param.h:272:12:= error: unexpected token in=A0=0Aargument list=0Aextern int maxbcachebuf;= =0A=A0=A0 =A0 =A0 =A0 =A0 ^=0A*** Error code 1=0A=0AStop.=0Abmake[3]: stopp= ed in /storage/home/hiroki/obj/storage/home/hiroki/zrouter/tmp/ar=0Am.arm/s= torage/home/hiroki/freebsd/sys/Buffalo_WZR2-G300N=0A*** Error code 1=0A=0AS= top.=0Abmake[2]: stopped in /storage/home/hiroki/freebsd=0A*** Error code 1= =0A=0AStop.=0Amake[1]: stopped in /storage/home/hiroki/freebsd=0A*** Error = code 1=0A=0AStop.=0Amake: stopped in /storage/home/hiroki/zrouter=0A From owner-freebsd-arm@freebsd.org Mon Jun 19 01:22:20 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CA19DD92052 for ; Mon, 19 Jun 2017 01:22:20 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8A952826F3 for ; Mon, 19 Jun 2017 01:22:19 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31990 invoked from network); 19 Jun 2017 01:22:13 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 19 Jun 2017 01:22:13 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Sun, 18 Jun 2017 21:22:13 -0400 (EDT) Received: (qmail 16117 invoked from network); 19 Jun 2017 01:22:13 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jun 2017 01:22:13 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 62B3AEC902B; Sun, 18 Jun 2017 18:22:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Creating armv7 MACHINE_ARCH From: Mark Millard In-Reply-To: Date: Sun, 18 Jun 2017 18:22:11 -0700 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170612152808.6094931.74364.27128@gmail.com> <2A90A527-7DCA-4442-9322-0EA96236583C@dsl-only.net> <3CC8DE8A-CCF2-4856-A43E-6B259BDE8B2C@dsl-only.net> To: Russell Haley X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 01:22:20 -0000 FYI: I'll provide the following example of the types of issues that can show up in trying to support old 32-bit code on an armv8 via AArch32 state mode. This is from OpenSuse's = https://bugzilla.opensuse.org/show_bug.cgi?id=3D1029158 : Tom Rini wrote on 2017-03-13 15:11:25 UTC : > If one wants to use legacy aarch32 binaries, the CONFIG_COMPAT option = needs to be set in the kernel, and today we do this. This in turn = allows some aarch32 binaries to run easily. However, there is a large = world of software that is "armhf" but rather than being tuned for ARMv7 = is tuned for ARMv6 (and the RPi). In order for this to run = ARMV8_DEPRECATED and then at least CP15_BARRIER_EMULATION needs to be = enabled (the other 2 options would also likely be helpful). >=20 > The real-world example here is that at least today, the Docker "armhf" = scratch builds (and in turn lots of stuff is based on this) do not just = run and you will get for example: > [ 1961.636326] python[3661]: undefined instruction: = pc=3D00000000f6965dbc > [ 1961.636336] Code: e5821060 e3a01000 e5821064 e5821068 (ee070fba)=20 > (this is also true of busybox). > And then with the options enabled: > [ 37.605796] "ls" (1464) uses deprecated CP15 Barrier instruction at = 0xc95dc > ... > [ 72.888570] "python" (1881) uses deprecated CP15 Barrier = instruction at 0xf6ab4dbc So full support can involve software emulation of some instructions that otherwise would be classified as illegal instructions or possibly as deprecated instructions. OpenSuse had a fix merged into the kernel near the end of 2017-Mar. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2017-Jun-12, at 10:37 PM, Russell Haley = wrote: Thanks Mark! I'll chew on that for a couple of days. :D Russ On Mon, Jun 12, 2017 at 7:01 PM, Mark Millard = wrote: >=20 > On 2017-Jun-12, at 4:10 PM, Russell Haley = wrote: >=20 >> Okay, feel free to ignore me, I'm not going to get the time drill = into >> the source code for my own questions so I don't expect anyone else >> too. However, I'll ask anyway. I'm too confused to try and inline >> these questions. Lets see if I understand: >>=20 >> - armv7 does not support 64 bit instructions (according to Wikipedia? >> I claim no expertise.) >=20 > It does not support AArch64 instructions but does support AArch32 > instructions (or is a good approximation). >=20 > AArch32 was actually created later to be armv7-a like. >=20 >> - FreeBSD has an armv6 "architecture" that is supports armv6 and = armv7 >> on Pre-Cortex-A-53 processors that is not supported on A-53 through >> the emulated AArch32. >=20 > There are actually architectures (by ARM's > definitions). . . >=20 > ARMv6, ARMv6T2, ARMv6Z, ARMv6K, ARMV6-M > ARMv7-M, ARMv7E-M, ARMv7-R, ARMv7-A > ARMv8-A, ARMv8.1-A ARMv8.2-Am ARMV8.3-A, ARMv8-R, ARMv8-M >=20 > I'm going to largely ignore much of > that variation in structure. >=20 > ARM has continued to produce/make new variations for both > 32-bit and 64-bit in overlapping time frames. So the > "Pre-Cortex-A53" presumes to much about relative timing. >=20 > Technically the old RPI2s (V1.1 and before) have > Cortex-A7's and the new V1.2's have Cortex-A53's. > RPI3 is also Cortex-A53 based. >=20 > Cortex-A7 includes an implementation of armv7-A architecture > (but is not the only one). > Cortex-A53 includes an implementation of armv8-A architecture > (but is not the only one). > (Both include other things as well. And the System On A Chip has even > more stuff than the Cortex-A's in question.) >=20 > Cortex-A's are specific CPUs/cores that are also > examples of the specific architecture(s) they implement. >=20 > If a kernel supports armv7-a it can support a variety of > CPUs that all implement armv7-a architecture. It may not > support things in the CPUs that are beyond that > architecture. >=20 > If a kernel supports armv8-a it can support a variety of > CPUs that all implement armv8-a architecture. It may not > support things in the CPUs that are beyond that > architecture. >=20 > Note there are also issues of support of the System On > a Chip involved as well. More than ARM is involved > overall. >=20 >=20 >=20 >> - Cortex A-53 can support armv8 (AArch64) and armv7 (AArch32) = instructions >=20 > As I remember armv8-a specifies: >=20 > A) Optional support: AArch64 > (Cortex-A32 is ARMv8-A archtecture but only 32-bit) > (ARMv8-R architecture is always only 32-bit as I understand) > (ARMv8-M architecture is always only 32-bit as I understand) > B) Optional support: AArch32 > (Cortex-A35/53/57/72/73 are ARMv8-A and have both) > (Cortex-A55/75 are ARMV8.2-A architecture and have both) > (But variants can be produced that omit AArch32.) > C) Various things specific to armv8-a > might go beyond what AArch64 and > AArch32 specify. >=20 > Note: AArch32 has 2 instruction sets > (A32/ARM and T32/Thumb), like armv7-a > does. AArch64 has A64. (I'm not giving > thumb version numbers here but there > are versioned vintages.) >=20 > So 1 architecture (armv8-a) has at least > 3 instruction sets when both AArch64 > and AArch32 are implemented. >=20 > AArch64 state: A64 >=20 > AArch32 state: A32 and T32 >=20 > There can be context switching between > these states as I understand. >=20 > (I'll not get into the NEON distinctions > and such so the above is simplified.) >=20 > armv8-a does not necessarily uniquely identify > the interrupt controller or its software > interface, as an example of variation that is > not an instruction set issue: register > interfaces to other hardware. ARM provides > GIC-400 and GIC-500 and others. But the > controller does not have to come from ARM. >=20 > While Cortex-A53 has a default/reference > interrupt controller(s), it is possible to > build variations that use other ones as > I understand. >=20 > Similar points go for Cortex-A7. >=20 > The other parts of a System On a Chip are for non-arm > aspects and may have some mixed degree on commonality > independently of ARM. But the kernel may deal with > such specifics as well. >=20 >> - The current proposal is to split the armv6 and armv7 into their own >> "architectures" >=20 > ARM defines these as distinct architectures. > That is not a FreeBSD specific terminology. > But much of the armv6 is common with armv7. >=20 > armv7 architecture has more than armv6 architecture does: > it is an update. Having armv7 implemented separately > in FreeBSD means more completely/correctly identifying > what is there compared to pretending it is an armv6. >=20 >> FreeBSD has an Arm 64 bit kernel build. I don't see what the >> TARGET_ARCH settings in the wiki and know little about it, but will >> conjecture that it doesn't have a TARGET_ARCH=3Darmv8 (please correct = me >> if I'm wrong). >=20 > FreeBSD has TARGET=3Darm64 TARGET_ARCH=3Daarch64 . That combination > is for armv8-A with AArch64 currently. Cortex-A32 is not > supported because it lacks AArch64. >=20 > FreeBSD's TARGET=3Darm64 TARGET_ARCH=3Daarch64 may grow to span > armv8.1 or such as well for all I know. Cortex-A53 is one > example of an armv8 implementation that the kernel supports > (presuming certain interrupt controllers and such). There are > others. >=20 >> What I was trying to ask was: is the kernel development moving in a >> direction that clearly indicates the differences in the instructions >> vs the architectures (or have I grossly simplified the problem)? Will >> it be possible to target a Cortex-A53 and build for 32 or 64 bit >> support? Or is this just to fix RPi? >=20 > Instruction sets are part of an architecture but not all of it. > They are not independent of architecture. Talking of an overall > architecture includes covering the instruction set(s). One > architecture can have multiple instruction sets as part of it. >=20 > TARGET=3Darm64 TARGET_ARCH=3Daarch64 may get a "lib32" (compat32) > implementation someday if someone is motivated to do the > work. That would enable AArch32 user processes. >=20 > What exists now and will in the future is mostly tied to > choices of volunteers that say "I'm going to provide > " and then manage to complete whatever it was. > (Clearly a "we are going to" is also an option.) >=20 > A similar points would go for TARGET_ARCH=3Darmv7 supporting > something like Cortex-A53 in AArch32 mode (Raspian like). >=20 > So at this point no one knows if or when as far as I know. >=20 > armv6 and armv7 architectures are strongly overlapping for what > is in armv6. The GENERIC kernel for what is currently a > TARGET_ARCH=3Darmv6 build actually builds for armv7 and will not > work on armv6. One has to use a different kernel configuration > than GENERIC for armv6 (such as the one for the older RPI vintage > that was armv6 based). >=20 > Identifying an armv7-a build as a armv6 build has odd > consequences for software that tries to figure out what > can be depended on. >=20 >> In terms of Raspbian, I had assumed they were just supporting Aarch32 >> across both processor models. Many of the drivers would be the same >> source if they share components so I would think it would be = "simple". >> I didn't see anything in my brief look at it today to indicate >> otherwise. >=20 > For Cortex-A53: Raspian supports just AArch32 state, > not AArch64 state for rpi2 V1.2 and RPI3. (I do not > know if early boot is temporarily AArch64 or not.) >=20 > For Cortex-A7: Cortex-A7 predates AArch32 and is armv7-a > directly but AArch32 was designed to appear to be be > nearly the same as armv7-a. So Raspian is supporting > armv7-a directly for rpi2 V1.1 and V1.0. >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net >=20 > On Mon, Jun 12, 2017 at 2:07 PM, Warner Losh wrote: >>=20 >>=20 >> On Mon, Jun 12, 2017 at 2:35 PM, Mark Millard = wrote: >>>=20 >>>=20 >>> On 2017-Jun-12, at 1:00 PM, Mark Millard = wrote: >>>=20 >>>> On Mon, Jun 12, 2017 at 1:00 PM, Mark Millard >>>> wrote: >>>>> On 2017-Jun-12, at 12:16 PM, Russell Haley >>>>> wrote: >>>>>=20 >>>>>> On Mon, Jun 12, 2017 at 10:36 AM, Mark Millard >>>>> dsl-only.net> wrote: >>>>>>>=20 >>>>>>> On 2017-Jun-12, at 8:39 AM, Warner Losh = wrote: >>>>>>>=20 >>>>>>>> . . . >>>>>>>>=20 >>>>>>>> Plus, we aren't quite doing what Ian wanted. He wanted a full >>>>>>>> rename. The >>>>>>>> proposal on the able is to add an armv7 TARGET_ARCH in 12. Not = to >>>>>>>> rename or >>>>>>>> remove armv6. Sadly, that will still be there since the RPI >>>>>>>> foundation >>>>>>>> keeps finding new ways to repackage the rpi into new boards = that are >>>>>>>> just >>>>>>>> too cheap to ignore. >>>>>>>=20 >>>>>>> On 2017-Jun-12, at 6:59 AM, Andrew Turner >>>>>>> wrote: >>>>>>>=20 >>>>>>>> I like this. My understanding is adding armv7 would also fix = many of >>>>>>>> the currently broken ports that assume they are being built for = armv7 as >>>>>>>> many Linux distros target ARMv7+. >>>>>>>>=20 >>>>>>>> It should also be noted the GENERIC kernel is likely to only = ever >>>>>>>> target ARMv7+ even without an armv7 TARGET_ARCH. >>>>>>>=20 >>>>>>>=20 >>>>>>> Hopefully the choices related to TARGET and TARGET_ARCH >>>>>>> for armv7 end up identifying the context to port builds >>>>>>> so that many would just automatically do the right thing. >>>>>>>=20 >>>>>>>=20 >>>>>>> As for GENERIC: >>>>>>>=20 >>>>>>> powerpc has. . . >>>>>>>=20 >>>>>>> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc and GENERIC >>>>>>> TARGET=3Dpowerpc TARGET_ARCH=3Dpowerpc64 and GENERIC64 >>>>>>>=20 >>>>>>> So there is precedent for more than one GENERIC* >>>>>>> for a family, with which one being appropriate >>>>>>> being based on TARGET_ARCH. >>>>>>>=20 >>>>>>> For powerpc TARGET=3Dpowerpc implicitly uses >>>>>>> TARGET_ARCH=3Dpowerpc when TARGET_ARCH is not >>>>>>> specified (if I remember right). Which should >>>>>>> be the default for armv6 vs. armv7 might go >>>>>>> the other direction (TARGET_ARCH=3Darmv7 by >>>>>>> default). >>>>>>>=20 >>>>>>>=20 >>>>>>> Side note: >>>>>>>=20 >>>>>>> A caution about talking about "rpi2" as >>>>>>> an example. . . >>>>>>>=20 >>>>>>> Raspberry Pi 2 Model B V1.2 is Cortex-A53 based >>>>>>> (so arm64/aarch64). (A BCM2837, not a BCM2836.) >>>>>>> This dates about to something like 2014 based >>>>>>> on the pictures showing the (c) notice on the >>>>>>> boards. >>>>>>>=20 >>>>>>> V1.1 and before were armv7 (BCM2836) based. >>>>>>>=20 >>>>>>> Unless a kernel and world are made that can >>>>>>> also configure/handle a Cortex-A53 in a >>>>>>> armv7-like manor there will be two different >>>>>>> GENERIC builds in order to span the "rpi2" >>>>>>> family, based on just V1.2+ vs. V1.1 and >>>>>>> before. >>>>>>>=20 >>>>>>> (A single, modern distribution of the official >>>>>>> Raspbian software for the rpi2 does support >>>>>>> all the V1.x boards if I understand right.) >>>>>>=20 >>>>>> I am confused. I don't see any documentation about Raspbian = supporting >>>>>> 64 bit? >>>>>=20 >>>>> 64-bit Cortex-A53's can be configure to operate in a >>>>> 32-bit mode (AArch32). Raspian does that for RPI2 V1.2 >>>>> and for RPI3. >>>>>=20 >>>>> Raspian does not (yet?) support a 64-bit mode (AArch64). >>>>>=20 >>>>> The Cortex-A53 can support either. As I understand it >>>>> is possible for an OS to allow a user processes to be >>>>> one or the other, different processes using the different >>>>> modes. That does not mean that all operating systems >>>>> bother to. >>>>>=20 >>>>> If I remember right the official Ubuntu for an ODroid-C2 >>>>> allows both AArch64 and AArch32 user programs (and >>>>> so processes, with shared library types tracking). >>>>>=20 >>>>>> =46rom Arm at >>>>>> = https://www.arm.com/products/processors/cortex-a/cortex-a53-processor.php:= >>>>>> "The Cortex-A53 supports the full ARMv8-A architecture. It not = only >>>>>> runs 64-bit applications also seamlessly and efficiently runs = legacy >>>>>> ARM 32-bit applications." >>>>>>=20 >>>>>> I assume that means it handles armv7-A without issue? (In fact, = many >>>>>> on this board know it does) >>>>>=20 >>>>> I've not gone through the details but targeting AArch32 >>>>> probably means targeting a subset of armv7. Or may be >>>>> to support both requires targeting a common subset of both. >>>>> (My guess is that AArch32 is the definition of a common >>>>> subset for 32-bit, at least for user processes.) >>>>>=20 >>>>> Raspian targets just AArch32 on armv7 and Cortex-A53 >>>>> (user space). (If I've got the definition of AArch32 >>>>> right: otherwise a common subset.) >>>>>=20 >>>>> FreeBSD targets armv7 and AArch64 separately (via >>>>> separate GENERIC kernels). I'm not aware of FreeBSD >>>>> targeting AArch32 at all on cores capable of AArch64. >>>>> FreeBSD possibly does not restrict itself to AArch32 >>>>> (user processes) on armv7 if AArch32 is really a >>>>> subset. >>>>=20 >>>> I thought all 64 bit Arm instructions are defined in armv8? >>>=20 >>> (I assume you are not trying to indicate armv8.1, armv8.2 >>> and such. Cortex-A53 is older than those and so does not >>> have the newer things involved.) >>>=20 >>> That Cortex-A53 allows armv8 64-bit arm code is not in >>> dispute. But the operating system in involved in setting >>> up what will actually work based on how it configures >>> things and operates. Much of this is the kernel. >>=20 >>=20 >> Correct. >>=20 >>>=20 >>> Cortex-A53 also supports AArch32, i.e., 32 bit instructions. >>> So that the 64-bit instructions all being there does not >>> of itself prevent using a 32-bit mode instead. >>>=20 >>> (The kernel likely has to deal with more specifics of >>> processor variations than user code does not. My notes >>> are really about the user process model, not the all >>> the kernel details.) >>>=20 >>> Raspian deals with armv7's that have no 64-bit support >>> and with Cortex-A53's that do. It presents a user-process >>> model that is 32-bit only, even on Cortex-A53's that allow >>> for 64-bit (but do not required user programs to be AArch64 >>> code). >>>=20 >>> Ubuntu for ODroid-C2 does not deal with armv7's but does >>> allow both 64-bit (AArch64) and 32-bit (AArch32) user >>> processes as I remember, on its Cortex-A53's. >>>=20 >>> FreeBSD armv7 does not support Cortext-A53 or anything >>> that allows 64-bit (that allows AArch64). This is a kernel >>> level issue. >>=20 >>=20 >> Not a hugely difficult issue to fix, but one nobody had fixed... >>=20 >>>=20 >>> FreeBSD aarch64 does not support having AArch32 user >>> processes. Nor does its kernel support processors that >>> do not support aarch64 (so it does not support armv7). >>=20 >>=20 >> Executing a 32-bit /bin/cat on aarch64 level support exists outside = the >> tree, according to the hallway track at BSDcan, so it will only be a = matter >> of time before compat32 exists there I think. >>=20 >> There's a further complication is that the aarch32 unit of aarch64 >> processors is optional. Not all of them have it, so that can be a = problem... >> IIRC, the early aarch64 targets didn't have this feature... >>=20 >>>=20 >>> These are simply examples of different choices about >>> what combinations of the technical possibilities to >>> put effort into supporting in the kernels (and >>> possibly elsewhere). None of the alternatives is >>> automatic. None are independent of software choices >>> that must be made by each operating system. >>=20 >>=20 >> Yes. They all require somebody to be interested in doing the work. >>=20 >> Warner >>=20 >>=20 >>=20 >=20 From owner-freebsd-arm@freebsd.org Mon Jun 19 06:46:30 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1A217D97002 for ; Mon, 19 Jun 2017 06:46:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C0DED66596 for ; Mon, 19 Jun 2017 06:46:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 18791 invoked from network); 19 Jun 2017 06:46:27 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Jun 2017 06:46:27 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 19 Jun 2017 02:46:27 -0400 (EDT) Received: (qmail 25803 invoked from network); 19 Jun 2017 06:46:27 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jun 2017 06:46:27 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 90612EC8029; Sun, 18 Jun 2017 23:46:26 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125] Message-Id: <9B6857F6-FD8E-43B7-B142-050E51EE68AB@dsl-only.net> Date: Sun, 18 Jun 2017 23:46:25 -0700 To: freebsd-arm , FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 06:46:30 -0000 This is a variant of the wording in bugzilla 220125: Unless buildworld (not just kernel-toolchain) is used before buildkernel the result for arm64 is: --- armv8_crypto_wrap.o --- In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang= /4.0.0/include/arm_neon.h:31:10: fatal error: 'stdint.h' file not found #include ^~~~~~~~~~ --- all_subdir_armv8crypto --- *** [armv8_crypto_wrap.o] Error code 1 Doing a kernel-toolchain build establishes: # ls -dlT /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/* drwxr-xr-x 2 root wheel 2 Jun 18 22:14:57 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/arpa drwxr-xr-x 2 root wheel 2 Jun 18 22:14:59 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/gssapi drwxr-xr-x 2 root wheel 2 Jun 18 22:14:57 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/protocols drwxr-xr-x 2 root wheel 2 Jun 18 22:14:58 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/rpc drwxr-xr-x 2 root wheel 2 Jun 18 22:14:58 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/rpcsvc drwxr-xr-x 2 root wheel 2 Jun 18 22:14:59 2017 /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/include/xlocale which excludes the following that a buildworld establishes (shown from a different build): # find /usr/obj/cortexA53_clang/ -name stdint.h -print | more = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/sys/stdint.= h = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/c++/v1/stdi= nt.h = /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/c++/v1/tr1/= stdint.h /usr/obj/cortexA53_clang/arm64.aarch64/usr/src/tmp/usr/include/stdint.h One of: A) kernel-toolchain needs to establish a stdint.h that would be found vs. B) arm_neon.h needs to avoid needing stdint.h (presumes armv8_crypto_wrap.c is correct to include arm_neon.h ) at least if the kernel-toolchain then buildkernel sequence is to be supported for arm64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Jun 19 06:58:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 21FCCD97276; Mon, 19 Jun 2017 06:58:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8A0B66A2D; Mon, 19 Jun 2017 06:58:15 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::1844:6e86:51da:285f] (unknown [IPv6:2001:470:7a58:0:1844:6e86:51da:285f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 3DC151DDF7; Mon, 19 Jun 2017 08:58:07 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_8BCD7550-BEF8-4E57-9A25-5FBD27DC51AB"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125] Date: Mon, 19 Jun 2017 08:57:57 +0200 In-Reply-To: <9B6857F6-FD8E-43B7-B142-050E51EE68AB@dsl-only.net> Cc: freebsd-arm , FreeBSD Toolchain To: Mark Millard References: <9B6857F6-FD8E-43B7-B142-050E51EE68AB@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 06:58:16 -0000 --Apple-Mail=_8BCD7550-BEF8-4E57-9A25-5FBD27DC51AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 19 Jun 2017, at 08:46, Mark Millard wrote: >=20 > This is a variant of the wording in bugzilla 220125: >=20 > Unless buildworld (not just kernel-toolchain) is used before > buildkernel the result for arm64 is: >=20 > --- armv8_crypto_wrap.o --- > In file included from = /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: > = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang= /4.0.0/include/arm_neon.h:31:10: > fatal error: 'stdint.h' file not found ... > A) kernel-toolchain needs to establish a stdint.h > that would be found > vs. > B) arm_neon.h needs to avoid needing stdint.h > (presumes armv8_crypto_wrap.c is correct to > include arm_neon.h ) >=20 > at least if the kernel-toolchain then buildkernel > sequence is to be supported for arm64. Solution A is problematic because it then would require to install headers into ${WORLDTMP}. This is what buildworld does. Solution B is problematic because arm_neon.h uses stdint.h types extensively. Maybe the solution with the least amount of work is to provide a kernel-specific wrapper header with the stdint.h types. Otherwise, just use buildworld before buildkernel. -Dimitry --Apple-Mail=_8BCD7550-BEF8-4E57-9A25-5FBD27DC51AB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllHdgEACgkQsF6jCi4glqNR/gCZAXSo9eVtCuqjIVeKgs/XMEtg 7u4AoIwiE22tjwL/5g06Txfrqv2mtf0y =Qfey -----END PGP SIGNATURE----- --Apple-Mail=_8BCD7550-BEF8-4E57-9A25-5FBD27DC51AB-- From owner-freebsd-arm@freebsd.org Mon Jun 19 07:55:04 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4DE2ED97EC0 for ; Mon, 19 Jun 2017 07:55:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-16.reflexion.net [208.70.210.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 006FF68188 for ; Mon, 19 Jun 2017 07:55:03 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24642 invoked from network); 19 Jun 2017 07:55:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 19 Jun 2017 07:55:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Mon, 19 Jun 2017 03:55:02 -0400 (EDT) Received: (qmail 15928 invoked from network); 19 Jun 2017 07:55:01 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 19 Jun 2017 07:55:01 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 2B5A9EC8029; Mon, 19 Jun 2017 00:55:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125] From: Mark Millard In-Reply-To: Date: Mon, 19 Jun 2017 00:55:00 -0700 Cc: freebsd-arm , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <1AF272E5-5715-45F2-955B-B2D85B7F08B0@dsl-only.net> References: <9B6857F6-FD8E-43B7-B142-050E51EE68AB@dsl-only.net> To: Dimitry Andric X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 07:55:04 -0000 On 2017-Jun-18, at 11:57 PM, Dimitry Andric wrote: > On 19 Jun 2017, at 08:46, Mark Millard wrote: >>=20 >> This is a variant of the wording in bugzilla 220125: >>=20 >> Unless buildworld (not just kernel-toolchain) is used before >> buildkernel the result for arm64 is: >>=20 >> --- armv8_crypto_wrap.o --- >> In file included from = /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46: >> = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang= /4.0.0/include/arm_neon.h:31:10: >> fatal error: 'stdint.h' file not found > ... >> A) kernel-toolchain needs to establish a stdint.h >> that would be found >> vs. >> B) arm_neon.h needs to avoid needing stdint.h >> (presumes armv8_crypto_wrap.c is correct to >> include arm_neon.h ) (B) variant: Possibly finding a distinct stdint.h when there is no $(WORLDTMP} tied one to be found? (Avoiding needing the specific stdint.h that is used when buildworld is used first.) Look in some new place as a last resort (extended search path list)? >> at least if the kernel-toolchain then buildkernel >> sequence is to be supported for arm64. >=20 > Solution A is problematic because it then would require to install > headers into ${WORLDTMP}. This is what buildworld does. Is there anyplace outside of $(WORLDTMP} where an alternate stdint.h could be made to be found if the ${WORLDTMP} places do not have one to find? (The include notation is currently .) Might some place related to (using my example full path just for illustration, showing post-subsitutions): = /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang= /4.0.0/include/ be allowed have its own "failover" stdint.h to find as a last resort? (I do not claim this is well thought out.) > Solution B is problematic because arm_neon.h uses stdint.h types > extensively. The instance of the file name need not be from the usual place when there is no $(WORLDTMP} tied stdint.h to find? So a different stdint.h instead of no stdint.h ? > Maybe the solution with the least amount of work is to provide a > kernel-specific wrapper header with the stdint.h types. With also avoiding the #include that would otherwise fail? > Otherwise, just use buildworld before buildkernel. For now buildworld first is what I'd do for arm64. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Jun 20 09:36:27 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10E78D93BD5; Tue, 20 Jun 2017 09:36:27 +0000 (UTC) (envelope-from ilya@bakulin.de) Received: from olymp.kibab.com (olymp6.kibab.com [IPv6:2a01:4f8:160:84c1::2]) by mx1.freebsd.org (Postfix) with ESMTP id D4CE17A8FE; Tue, 20 Jun 2017 09:36:26 +0000 (UTC) (envelope-from ilya@bakulin.de) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Tue, 20 Jun 2017 11:36:17 +0200 From: Ilya Bakulin To: Neeraj Pal Cc: freebsd-arm@freebsd.org, owner-freebsd-arm@freebsd.org Subject: Re: Support for Raspberry Pi 3 wifi broadcom driver in FreeBSD Organization: Deglitch Networks In-Reply-To: References: Message-ID: <9d29575ccb57d1543ec78705bfd001b4@bakulin.de> X-Sender: ilya@bakulin.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 09:36:27 -0000 Hi Neeraj, no, wireless chip of RPi3 is not supported in FreeBSD. The support depends on the new SD/SDIO stack integration. Once it is integrated, someone has to write a driver for the chip. No ETAs on both tasks. On 2017-06-16 06:04, Neeraj Pal wrote: > Hello all, > > I want to know about wireless driver support for *Raspberry Pi 3*. > > Is there any support for Raspberry Pi 3 wireless Broadcom (*brcmfmac*) > driver? > Because i feels difficulty to set-up wireless in Raspberry Pi 3 > (installed > *FreeBSD*). > > > > *Details :[root@rpi3 /usr/home/raspberry]# *uname -a > *FreeBSD rpi3 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318898M: Thu May 25 > 15:07:15 MDT 2017 > raspberry@hive.raspbsd.org:/usr/home/brd/rpi3/crochet/work/obj/arm64.aarch64/usr/src/sys/GENERIC > arm64* > _______________________________________________ > 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" -- Mit freundlichen Grüßen, Ilya Bakulin From owner-freebsd-arm@freebsd.org Wed Jun 21 00:15:36 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 17AD7DA5527; Wed, 21 Jun 2017 00:15:36 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C551D79145; Wed, 21 Jun 2017 00:15:35 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: by mail-io0-x232.google.com with SMTP id y77so1247008ioe.3; Tue, 20 Jun 2017 17:15:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GIAcVvb8lEgSMOpQ/ByZ2xz9l0JMsudb/uBWXXkl8TQ=; b=hFLFDBxlTF2iLYWsE28HX0LblQ1DgZAh+zhJ8RESQsl8zJCzeFyBvCiDcJ8L4lTTL5 usInDa2qCsk9tIRjHF0c88vj+zeLUGk8r7gC90T3KAk0/0sXbUJoBYmH/1UiRj3fnl0X +sJWidQOD+xCI+hROv8J3sQIo4Uv1wNIvdV9pZH3/Q9P67QTMmBQCG7fnu/EqJWKAhC1 pYGd2WicKC59L/h3saZ5AiMn4OeV04uoff2SeeQwkRtc+qxM5UfRQs2Mgxb/j24ame45 tZfgp9GKduo4IxUwZ7ziSiPyS9eFEP95/f6w2cmqWcjGdtwMTrwThNKPr6H5lZx8YHMl dFyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GIAcVvb8lEgSMOpQ/ByZ2xz9l0JMsudb/uBWXXkl8TQ=; b=C91vvckj/bQltb93YZA+0Fe9VcVCEjVC4Ke0vy8k2j9DzfXo+Rot0V9g3C45n07123 aXqFITukNK+f+lp7rNNIpGmIhLfSDfbSFxCgclPvbZo+IvIILpPJkIO6LSTsUEMq1Ywg Cw4AlDbsUFbW+23X6SbZgMy5Sw0dqSaq4jZYXHa4ILlJbFLE7JtllbpCsdbdWzXbEvTA Krmp/jhE/8xq63sOmkhqmD1u/hYMCoLfg08gkj3si2OBTbcq78X2AQ5kajDUsSYZl4xJ CLSf/ldrT8wavhsxub+lY9o+vRHXEtPhXlDPsV8aDdfAS6cJO0HenNbtKqcDVnl3Xa92 2a7w== X-Gm-Message-State: AKS2vOy7GI2S4n4DDolTFF0oXll1SKUqWUkMHIDSPyMrIVfWce0AQ3la xHHJeaHanOU5rpj30aBsdX2AN73JyQ== X-Received: by 10.107.195.15 with SMTP id t15mr28276828iof.182.1498004134791; Tue, 20 Jun 2017 17:15:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.8.208 with HTTP; Tue, 20 Jun 2017 17:15:34 -0700 (PDT) In-Reply-To: References: <9B6857F6-FD8E-43B7-B142-050E51EE68AB@dsl-only.net> From: Ryan Stone Date: Tue, 20 Jun 2017 20:15:34 -0400 Message-ID: Subject: Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125] To: Dimitry Andric Cc: Mark Millard , freebsd-arm , FreeBSD Toolchain Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 00:15:36 -0000 On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric wrote: > Solution B is problematic because arm_neon.h uses stdint.h types > extensively. > If I manually modify the arm_neon.h file to instead say this, the problem is avoided and the kernel builds: #ifdef _KERNEL #include #else #include #endif Do you think that the llvm devs would be willing to take a change to NeonEmitter that does this on FreeBSD? This may not be a complete solution, though, as googling seems to indicate that gcc also provides a arm_neon.h and it also #includes From owner-freebsd-arm@freebsd.org Wed Jun 21 02:20:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 225B0DA6BDB for ; Wed, 21 Jun 2017 02:20:37 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DFD087BCAF for ; Wed, 21 Jun 2017 02:20:36 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io0-x234.google.com with SMTP id k93so2382929ioi.2 for ; Tue, 20 Jun 2017 19:20:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jF2GdXfENCb8NfxuXjTavP9gv2WvSbU4+m00oXD9kvQ=; b=ONLgmtc04gtrhiMPwPcWv9i0CFTPgFKdT0adeZhiJ7okDu+5NqCv2eLAY2tpIG+Y+u DYTm6yocJdXkh6obT+fz4pHKKYGXDQLprzMQJNZECi/mBaiAUlsXtAftFOVagz+wYQ7w vzdY+If78y9SrAmYpUq2hSFnh/uI9bbc+jO+iEHjqd7tYBCtf0vgaxDkuvh2buAHwDPe 9XD+ovvXfIRVlmuWXz3XT8b6pSkjIj4nISO4hDeLsyjwrqbpBPTSxOdhguU8oFzp6B23 GI+sSjmJFh44nK7UHBfTwyv4ZrXerxeBpwXI9mvkQGVqw25lYTMRfYodS0okTcOa5zFK s+UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jF2GdXfENCb8NfxuXjTavP9gv2WvSbU4+m00oXD9kvQ=; b=cJ/wTs60osjMlRb8Ppw+teCMZ1YMlPDoMR2M+Eoa5TcjZ/AMc+oLrRTsm41KyZHkVL xf2bAiIbOBgvj1/5kZqHgVN/kSSlu7uFElc3ZEws9KrBiAIK9g0W0AG99OiEm2xQHW0D OzTSQQjQBW9p4Mq/Zhlqh2Gheizo//VjL6HXiDJRh/HHfUrp4MWWp6x7webXt4dA33kA J3gPl/YaU6zHrtC6jJi4137kp5G3I+s0/eZYAoacqPBg7hjlR6hxgNAlZnkWe59fqQ5A PG+WeqBok8oOIO3HULnvRvFRK8MTPoDUbS2lEnjXAAq+CzHsfXbJxv2bx2HpxJfg/vXL ZTmA== X-Gm-Message-State: AKS2vOyM/5znIZJU6RlsrE9YXkAFrtWsNecKLjGpCkPmbqwPcVivLcIr KV0Hirp0JvXlne0qMbuxF9W+5GSAfB/w X-Received: by 10.107.188.3 with SMTP id m3mr1278126iof.113.1498011636174; Tue, 20 Jun 2017 19:20:36 -0700 (PDT) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.107.10.86 with HTTP; Tue, 20 Jun 2017 19:20:15 -0700 (PDT) In-Reply-To: References: From: Ed Maste Date: Tue, 20 Jun 2017 22:20:15 -0400 X-Google-Sender-Auth: 6B-1dQKVFI6PRB_Sh2Siv7ATJ3k Message-ID: Subject: Re: Creating armv7 MACHINE_ARCH To: Warner Losh Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 02:20:37 -0000 On 8 June 2017 at 16:27, Warner Losh wrote: > While the kernel doesn't really need an armv7 support, there will be a > better match to other systems if we create a armv7 MACHINE_ARCH. Let me add one more point in this discussion: LLVM's lld linker currently assumes an armv7 target. Introducing armv7 MACHINE_ARCH will allow us to enable lld for armv7, leaving arm/armv6 to use binutils (old version in the base system, or port/pkg). From owner-freebsd-arm@freebsd.org Wed Jun 21 06:33:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BBB0D87A73; Wed, 21 Jun 2017 06:33:42 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A46582315; Wed, 21 Jun 2017 06:33:42 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from [IPv6:2001:470:7a58::9566:2e4e:8fb0:5a26] (unknown [IPv6:2001:470:7a58:0:9566:2e4e:8fb0:5a26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id EDE581DF4D; Wed, 21 Jun 2017 08:33:39 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_51A3155A-FCF3-4593-ABDA-71EC2D149934"; protocol="application/pgp-signature"; micalg=pgp-sha1 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125] Date: Wed, 21 Jun 2017 08:33:36 +0200 In-Reply-To: Cc: freebsd-arm , FreeBSD Toolchain To: Ryan Stone References: <9B6857F6-FD8E-43B7-B142-050E51EE68AB@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 06:33:42 -0000 --Apple-Mail=_51A3155A-FCF3-4593-ABDA-71EC2D149934 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 21 Jun 2017, at 02:15, Ryan Stone wrote: > > On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric wrote: > >> Solution B is problematic because arm_neon.h uses stdint.h types >> extensively. >> > > If I manually modify the arm_neon.h file to instead say this, the problem > is avoided and the kernel builds: > > #ifdef _KERNEL > #include > #else > #include > #endif > > Do you think that the llvm devs would be willing to take a change to > NeonEmitter that does this on FreeBSD? > > This may not be a complete solution, though, as googling seems to indicate > that gcc also provides a arm_neon.h and it also #includes Indeed. It seems this header is not really designed to be included from kernel space. It is probably easiest to provide a kernel wrapper for stdint.h, maybe even just for arm. -Dimitry --Apple-Mail=_51A3155A-FCF3-4593-ABDA-71EC2D149934 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAllKE0QACgkQsF6jCi4glqPmYwCgr4kvpP675xDZQosA5G3yBjth o3MAn0OIRqqxHMmorkvJxWo418O6avkm =/4Xt -----END PGP SIGNATURE----- --Apple-Mail=_51A3155A-FCF3-4593-ABDA-71EC2D149934-- From owner-freebsd-arm@freebsd.org Wed Jun 21 11:56:58 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6C52D8D527 for ; Wed, 21 Jun 2017 11:56:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C50DF662F1 for ; Wed, 21 Jun 2017 11:56:58 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v5LBuwxN090902 for ; Wed, 21 Jun 2017 11:56:58 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 220181] Subject: Freebsd 11 on APU via sdcard no boot Date: Wed, 21 Jun 2017 11:56:58 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: simplerezo@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 11:56:58 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D220181 Bug ID: 220181 Summary: Subject: Freebsd 11 on APU via sdcard no boot Product: Base System Version: 11.0-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: simplerezo@gmail.com I have many PC Engines APU and APU2 (https://www.pcengines.ch/apu.htm) and i used to install on it Freebsd (actually 10.3). I'm having a lot of difficulty installing Freebsd 11 on their sdcard: when i turn on the engine it never boot. I discovered the problem trying to install opnsense 17.1 (https://forum.opnsense.org/index.php?topic=3D4872.msg19180) As i said in this report: Using the serial com port, here is what it says on SD boot: on apu1: "ehci_wait_td error - status=3D10000d40 USB transmission failed" on apu2: "Timeout at sdcard_waitw" When i upgrade opnsense 16.7 (freebsd 10.3) to 17.1 (freebsd 11) the problem not occur, I can reboot without problem. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Thu Jun 22 01:13:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3FCD3D9CFC5 for ; Thu, 22 Jun 2017 01:13:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0D28F2F2 for ; Thu, 22 Jun 2017 01:13:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x233.google.com with SMTP id h134so5811610iof.2 for ; Wed, 21 Jun 2017 18:13:25 -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; bh=1THpptkXjv4d9UY3D0g/QP2F+6clX9m8enKiC+1i6uE=; b=eXuT0RsXhxBaDOqjlNQw7dCRkH77VuwfAXegTegpl37JqEIHqtojNZL0Y+fAtbT5ps l3baoTDN4tXPhn/XqwcfflLRUHNfD9SdbfdhbJptajwU2rTZ6gbjLozYd4r8/voP2452 1Q92kdmDWq7cSZyZW+6kNHHrsX+uVf9VsZPdWARxtqo5uH+LUIRgUJtE34hqq7NEKQ4T 2m6FTuQi8T/t5YciqkLwzwrcjpZ09xqgHHcEgcthozGcVYDCAoasH6c1ikn07OKvNuc2 oTbr524A1l3rXjCokqPHcphbq+wWPscV/5DK278tFV444OFS/7a7KF7j9UN9eRw7ahvI umVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=1THpptkXjv4d9UY3D0g/QP2F+6clX9m8enKiC+1i6uE=; b=bZtRbTp0+BGR71iWl3I5HLGOBAPHs+NOMniq8/XdrK7ymVJyedaehBtm2EZNZqzAc2 MoA8TTmVC3XUE5WuvcUinQ1FsKMe1ZO7OMmT4qEbLKUUo/uKABRYQq/sffgeCea3Vf7U pc9TJI/A8S7kK6wx/wL07v35IVEXefrDpRdfoH0FcY2tQadRQ8whQS6JfbdyvoFHrlAK Dhp1+yUXRqVlev9fD1Xiq03fDl16Zs92z0bmo0Wd36mGGqc06s+V1u8F5StZvMgCkoah sfSuNFYX5A7Mg4qV4mCzHnvoJ/BlzR87d+mu6pPgwDdy6nVPN9RMT0fShd44JsdNho3Y iFJA== X-Gm-Message-State: AKS2vOwt8PP8F7PS+t69L9nRL5kgeKwxxRepxYaIcuPphIkdmZ4wUy32 fkL6QnVQByXQOWUrPTe2Nxp2l6o8VuOo X-Received: by 10.107.16.217 with SMTP id 86mr40515ioq.134.1498094005125; Wed, 21 Jun 2017 18:13:25 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.192.69 with HTTP; Wed, 21 Jun 2017 18:13:24 -0700 (PDT) X-Originating-IP: [216.9.110.3] In-Reply-To: References: From: Warner Losh Date: Wed, 21 Jun 2017 19:13:24 -0600 X-Google-Sender-Auth: PnPVLL942fLJAAuaih8EtMFB-HI Message-ID: Subject: Re: Deorbiting armv4 and armv5 support To: Ronald Klop Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:13:26 -0000 On Sun, Jun 11, 2017 at 10:41 PM, Warner Losh wrote: > > > On Sun, Jun 11, 2017 at 3:28 PM, Ronald Klop wrote: > >> On Thu, 08 Jun 2017 22:22:51 +0200, Warner Losh wrote: >> >> Greetings, >>> >>> The pmap in armv4/5 has been broken for years at this point. It basically >>> works, but has issues with unaligned buffers. Since these have remained >>> unfixed for a long time, and most of the main ARM developers have given >>> up >>> trying to fix it, I think it would be best to retire the support rather >>> than waste people's time that seem to be working only to discover after a >>> lot of effort that it's busted. >>> >>> Since the consensus at the FreeBSD developer's summit appeared to be >>> 'let's >>> let it go'. It would remove the TARGET_ARCH arm and armeb. armv6 would >>> remain unaffected (though see a parallel thread). >>> >>> Warner >>> >> >> What branches are you talking about? >> > > I'm thinking only the -current branch. > > However, I'm thinking now that I'll write up something more formal (the > FCP process) and start maybe a 3 month timeout. There's two leads on a fix, > I'll be looking at one of them in the next few days. If one of these fixes > is good, I'll merge it. The second one is a long shot, though... > > So, my current plan is that if it remains unfixed by, say Sept 1, 2017, > I'll deorbit. I may adjust that date depending on the timing of the 12 > branch, since I want to get this resolved before the branch... > I've managed to get my old Atmel AT91SMA9G20 based board working, so I'm officially withdrawing this idea. I heard from a few people that had no issues with their armv5 boards and was wondering what I was talking about. I've found the root cause to my issues, so I think we're in good shape from a functional point of view. It looks like the unaligned issues that I'd seen in prior versions have been fixed at least since Feb of this year, maybe longer. As a side note, both the armv4 and armv6 busdma implementations work on armv4/5 hardware. Though the v6 implementation seems to use about 20-30% more memory in a quick test... Warner From owner-freebsd-arm@freebsd.org Thu Jun 22 01:39:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A6904D9E8BE for ; Thu, 22 Jun 2017 01:39:16 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (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 6BF4A1A4D for ; Thu, 22 Jun 2017 01:39:15 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 727 invoked from network); 22 Jun 2017 01:39:14 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 22 Jun 2017 01:39:14 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 21 Jun 2017 21:39:14 -0400 (EDT) Received: (qmail 24572 invoked from network); 22 Jun 2017 01:39:14 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Jun 2017 01:39:14 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 4BE6EEC8143; Wed, 21 Jun 2017 18:39:13 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: head -r320192 vs. devel/aarch64-xtoolchain-gcc and devel/aarch64-binutils (/usr/ports -r443557): "liblto_plugin.so: error loading plugin: Service unavailable" for .pico link Message-Id: <15079239-4CE5-43E9-831D-994ADA0D5213@dsl-only.net> Date: Wed, 21 Jun 2017 18:39:12 -0700 To: freebsd-arm , FreeBSD Toolchain X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:39:16 -0000 For the first time ever I attempted to do an amd64 -> aarch64 cross build that was xtoolchain based for buildworld buildkernel . It failed as shown below. This was while linking with .pico files. [Note: I used ". . ." in place of most of the huge .pico file list.] --- libc.so.7.full --- building shared library libc.so.7 --- libc_pic.a --- building special pic c library --- libc.so.7.full --- /usr/local/bin/aarch64-freebsd-ld: = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:= error loading plugin: Service unavailable collect2: error: ld returned 1 exit status *** [libc.so.7.full] Error code 1 make[4]: stopped in /usr/src/lib/libc .ERROR_TARGET=3D'libc.so.7.full' = .ERROR_META_FILE=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/sr= c/lib/libc/libc.so.7.full.meta' .MAKE.LEVEL=3D'4' MAKEFILE=3D'' .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes = verbose' _ERROR_CMD=3D'@echo building shared library libc.so.7; @rm -f libc.so.7 = libc.so; /usr/local/bin/aarch64-unknown-freebsd12.0-gcc -mcpu=3Dcortex-a53= -isystem = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/include = -L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = -B/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp = -B/usr/local/aarch64-freebsd/bin/ -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'/usr/local/aarch64-freebsd/bin/nm' NMFLAGS=3D'' lorder = machdep_ldisQ.pico . . . wmemset.pico | tsort -q` -lcompiler_rt -lssp_nonshared;' .CURDIR=3D'/usr/src/lib/libc' .MAKE=3D'make' = .OBJDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/lib/lib= c' .TARGETS=3D'all' DESTDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp' LD_LIBRARY_PATH=3D'' MACHINE=3D'arm64' MACHINE_ARCH=3D'aarch64' MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64' MAKESYSPATH=3D'/usr/src/share/mk' MAKE_VERSION=3D'20170510' = PATH=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/leg= acy/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/sb= in:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/bin:/sb= in:/bin:/usr/sbin:/usr/bin' SRCTOP=3D'/usr/src' OBJTOP=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src' .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/libc/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/lib/libc/aarch64/Makefile.inc /usr/src/lib/libc/db/Makefile.inc = /usr/src/lib/libc/db/btree/Makefile.inc = /usr/src/lib/libc/db/db/Makefile.inc = /usr/src/lib/libc/db/hash/Makefile.inc = /usr/src/lib/libc/db/man/Makefile.inc = /usr/src/lib/libc/db/mpool/Makefile.inc = /usr/src/lib/libc/db/recno/Makefile.inc = /usr/src/lib/libc/compat-43/Makefile.inc = /usr/src/lib/libc/gdtoa/Makefile.inc /usr/src/lib/libc/gen/Makefile.inc = /usr/src/lib/libc/aarch64/gen/Makefile.inc = /usr/src/lib/libc/gmon/Makefile.inc /usr/src/lib/libc/iconv/Makefile.inc = /usr/src/lib/libc_nonshared/Makefile.iconv = /usr/src/lib/libc/inet/Makefile.inc /usr/src/lib/libc/isc/Makefile.inc = /usr/src/lib/libc/locale/Makefile.inc /usr/src/lib/libc/md/Makefile.inc = /usr/src/lib/libc/nameser/Makefile.inc = /usr/src/lib/libc/net/Makefile.inc /usr/src/lib/libc/nls/Makefile.inc = /usr/src/lib/libc/posix1e/Makefile.inc = /usr/src/lib/libc/regex/Makefile.inc = /usr/src/lib/libc/resolv/Makefile.inc = /usr/src/lib/libc/stdio/Makefile.inc = /usr/src/lib/libc/stdlib/Makefile.inc = /usr/src/lib/libc/stdlib/jemalloc/Makefile.inc = /usr/src/lib/libc/stdtime/Makefile.inc = /usr/src/lib/libc/string/Makefile.inc = /usr/src/lib/libc/aarch64/string/Makefile.inc = /usr/src/lib/libc/sys/Makefile.inc /usr/src/sys/sys/syscall.mk = /usr/src/lib/libc/aarch64/sys/Makefile.inc = /usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc = /usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc = /usr/src/lib/libc/yp/Makefile.inc = /usr/src/lib/libc/capability/Makefile.inc /usr/src/share/mk/bsd.lib.mk = /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/local.init.mk = /usr/src/share/mk/src.init.mk /usr/src/lib/libc/../Makefile.inc = /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk = /usr/src/share/mk/bsd.symver.mk /usr/src/share/mk/bsd.nls.mk = /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.incs.mk = /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.links.mk = /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk = /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk = /usr/src/share/mk/bsd.sys.mk' .PATH=3D'. /usr/src/lib/libc /usr/src/lib/libc/db/btree = /usr/src/lib/libc/db/db /usr/src/lib/libc/db/hash = /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool = /usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 = /usr/src/lib/libc/gdtoa /usr/src/lib/libc/aarch64/gen = /usr/src/lib/libc/gen /usr/src/contrib/libc-pwcache = /usr/src/contrib/libc-vis /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv = /usr/src/lib/libc/inet /usr/src/lib/libc/isc /usr/src/lib/libc/locale = /usr/src/lib/libmd /usr/src/lib/libc/nameser /usr/src/lib/libc/net = /usr/src/lib/libc/nls /usr/src/lib/libc/posix1e /usr/src/lib/libc/regex = /usr/src/lib/libc/resolv /usr/src/lib/libc/stdio = /usr/src/lib/libc/stdlib /usr/src/lib/libc/stdlib/jemalloc = /usr/src/lib/libc/stdtime /usr/src/contrib/tzcode/stdtime = /usr/src/lib/libc/aarch64/string /usr/src/lib/libc/string = /usr/src/sys/libkern /usr/src/contrib/cortex-strings/src/aarch64 = /usr/src/lib/libc/aarch64/sys /usr/src/lib/libc/sys = /usr/src/lib/libc/secure /usr/src/lib/libc/rpc /usr/src/lib/libc/. = /usr/src/lib/libc/uuid /usr/src/lib/libc/xdr /usr/src/lib/libc/yp = /usr/src/sys/kern /usr/src/lib/libc/capability' 1 error # ls -lT = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin/* -r-xr-xr-x 1 root wheel 390264 Jun 17 15:06:21 2017 = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin/gengtype The build context was: # more = ~/sys_build_scripts.amd64-host/make_cortexA53_nodebug_incl_clang_xtoolchai= n-gcc-amd64-host.sh=20 kldload -n filemon && \ script = ~/sys_typescripts/typescript_make_cortexA53_nodebug_incl_clang_xtoolchain-= gcc-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-= host" \ WITH_META_MODE=3Dyes \ MAKEOBJDIRPREFIX=3D"/usr/obj/cortexA53_xtoolchain-gcc" \ make $* # more /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host TO_TYPE=3Daarch64 TOOLS_TO_TYPE=3D${TO_TYPE} VERSION_CONTEXT=3D12.0 # KERNCONF=3DGENERIC-NODBG TARGET=3Darm64 .if ${.MAKE.LEVEL} =3D=3D 0 TARGET_ARCH=3D${TO_TYPE} .export TARGET_ARCH .endif # WITHOUT_CROSS_COMPILER=3D WITHOUT_SYSTEM_COMPILER=3D # WITH_LIBCPLUSPLUS=3D WITHOUT_BINUTILS_BOOTSTRAP=3D WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D WITHOUT_CLANG_BOOTSTRAP=3D WITH_CLANG=3D WITH_CLANG_IS_CC=3D WITH_CLANG_FULL=3D WITH_CLANG_EXTRAS=3D WITHOUT_LLD_BOOTSTRAP=3D WITH_LLD=3D WITH_LLD_IS_LD=3D WITH_LLDB=3D # WITH_BOOT=3D WITHOUT_LIB32=3D # WITHOUT_GCC_BOOTSTRAP=3D WITHOUT_GCC=3D WITHOUT_GCC_IS_CC=3D WITHOUT_GNUCXX=3D # NO_WERROR=3D #WERROR=3D MALLOC_PRODUCTION=3D # WITH_REPRODUCIBLE_BUILD=3D WITH_DEBUG_FILES=3D # XCFLAGS+=3D -mcpu=3Dcortex-a53 XCXXFLAGS+=3D -mcpu=3Dcortex-a53 # There is no XCPPFLAGS but XCPP gets XCFLAGS content. # # # For TO (so-called "cross") stages . . . # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . . # CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc X_COMPILER_TYPE=3Dgcc CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ .if ${.MAKE.LEVEL} =3D=3D 0 = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gc= c = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g= ++ = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-c= pp .export XCC .export XCXX .export XCPP XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings .export XAS .export XAR .export XLD .export XNM .export XOBJCOPY .export XOBJDUMP .export XRANLIB .export XSIZE .export XSTRINGS .endif # # # =46rom based on clang (via system). . . # .if ${.MAKE.LEVEL} =3D=3D 0 CC=3D/usr/bin/clang CXX=3D/usr/bin/clang++ CPP=3D/usr/bin/clang-cpp .export CC .export CXX .export CPP .endif # more /usr/src/sys/arm64/conf/GENERIC-NODBG # # GENERIC -- Custom configuration for the arm64/aarch64 # include "GENERIC" ident GENERIC-NODBG makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols options ALT_BREAK_TO_DEBUGGER options KDB # Enable kernel debugger support # For minimum debugger support (stable branch) use: #options KDB_TRACE # Print a stack trace for a = panic options DDB # Enable the kernel debugger # Extra stuff: #options VERBOSE_SYSINIT # Enable verbose sysinit = messages #options BOOTVERBOSE=3D1 #options BOOTHOWTO=3DRB_VERBOSE #options KTR #options KTR_MASK=3DKTR_TRAP ##options KTR_CPUMASK=3D0xF #options KTR_VERBOSE # Disable any extra checking for. . . nooptions DEADLKRES # Enable the deadlock resolver nooptions INVARIANTS # Enable calls of extra sanity = checking nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS nooptions WITNESS # Enable checks to detect = deadlocks and cycles nooptions WITNESS_SKIPSPIN # Don't run witness on spinlocks = for speed nooptions DIAGNOSTIC nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones nooptions BUF_TRACKING nooptions FULL_BUF_TRACKING =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Thu Jun 22 01:51:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DE345D9F69E for ; Thu, 22 Jun 2017 01:51:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-14.reflexion.net [208.70.210.14]) (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 A2A09249F for ; Thu, 22 Jun 2017 01:51:09 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 5931 invoked from network); 22 Jun 2017 01:55:14 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 22 Jun 2017 01:55:14 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.40.1) with SMTP; Wed, 21 Jun 2017 21:51:07 -0400 (EDT) Received: (qmail 28915 invoked from network); 22 Jun 2017 01:51:07 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 22 Jun 2017 01:51:07 -0000 Received: from [192.168.1.114] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id F1B4EEC8143; Wed, 21 Jun 2017 18:51:06 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: head -r320192 vs. devel/aarch64-xtoolchain-gcc and devel/aarch64-binutils (/usr/ports -r443557): "liblto_plugin.so: error loading plugin: Service unavailable" for .pico link Date: Wed, 21 Jun 2017 18:51:06 -0700 References: <15079239-4CE5-43E9-831D-994ADA0D5213@dsl-only.net> To: freebsd-arm , FreeBSD Toolchain In-Reply-To: <15079239-4CE5-43E9-831D-994ADA0D5213@dsl-only.net> Message-Id: <6CAD4727-7B73-4583-B29B-7A3D071CE78D@dsl-only.net> X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 01:51:10 -0000 [I add a note showing aarch64-freebsd-ld is statically linked.] On 2017-Jun-21, at 6:39 PM, Mark Millard wrote: > For the first time ever I attempted to do an amd64 -> aarch64 > cross build that was xtoolchain based for buildworld buildkernel . > It failed as shown below. This was while linking with .pico > files. >=20 > [Note: I used ". . ." in place of most of the huge .pico file list.] >=20 > --- libc.so.7.full --- > building shared library libc.so.7 > --- libc_pic.a --- > building special pic c library > --- libc.so.7.full --- > /usr/local/bin/aarch64-freebsd-ld: = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/liblto_plugin.so:= error loading plugin: Service unavailable > collect2: error: ld returned 1 exit status > *** [libc.so.7.full] Error code 1 FYI: /usr/local/bin/aarch64-freebsd-ld is statically linked. # file /usr/local/bin/aarch64-freebsd-ld* /usr/local/bin/aarch64-freebsd-ld: ELF 64-bit LSB executable, = x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 12.0 = (1200033), FreeBSD-style, not stripped /usr/local/bin/aarch64-freebsd-ld.bfd: ELF 64-bit LSB executable, = x86-64, version 1 (FreeBSD), statically linked, for FreeBSD 12.0 = (1200033), FreeBSD-style, not stripped > make[4]: stopped in /usr/src/lib/libc > .ERROR_TARGET=3D'libc.so.7.full' > = .ERROR_META_FILE=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/sr= c/lib/libc/libc.so.7.full.meta' > .MAKE.LEVEL=3D'4' > MAKEFILE=3D'' > .MAKE.MODE=3D'meta missing-filemon=3Dyes missing-meta=3Dyes silent=3Dyes= verbose' > _ERROR_CMD=3D'@echo building shared library libc.so.7; @rm -f = libc.so.7 libc.so; /usr/local/bin/aarch64-unknown-freebsd12.0-gcc = -mcpu=3Dcortex-a53 -isystem = /usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/include = -L/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = -B/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/lib = --sysroot=3D/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp = -B/usr/local/aarch64-freebsd/bin/ -nodefaultlibs = -Wl,--version-script=3DVersion.map -shared -Wl,-x -Wl,--fatal-warnings = -Wl,--warn-shared-textrel -o libc.so.7.full -Wl,-soname,libc.so.7 = `NM=3D'/usr/local/aarch64-freebsd/bin/nm' NMFLAGS=3D'' lorder = machdep_ldisQ.pico > . . . > wmemset.pico | tsort -q` -lcompiler_rt -lssp_nonshared;' > .CURDIR=3D'/usr/src/lib/libc' > .MAKE=3D'make' > = .OBJDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/lib/lib= c' > .TARGETS=3D'all' > DESTDIR=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp' > LD_LIBRARY_PATH=3D'' > MACHINE=3D'arm64' > MACHINE_ARCH=3D'aarch64' > MAKEOBJDIRPREFIX=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64' > MAKESYSPATH=3D'/usr/src/share/mk' > MAKE_VERSION=3D'20170510' > = PATH=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/legacy= /usr/sbin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/lega= cy/usr/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/leg= acy/bin:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/sb= in:/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src/tmp/usr/bin:/sb= in:/bin:/usr/sbin:/usr/bin' > SRCTOP=3D'/usr/src' > OBJTOP=3D'/usr/obj/cortexA53_xtoolchain-gcc/arm64.aarch64/usr/src' > .MAKE.MAKEFILES=3D'/usr/src/share/mk/sys.mk = /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk = /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host = /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/bsd.suffixes.mk = /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk = /usr/src/share/mk/src.sys.mk /dev/null /usr/src/lib/libc/Makefile = /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk = /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk = /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.compiler.mk = /usr/src/lib/libc/aarch64/Makefile.inc /usr/src/lib/libc/db/Makefile.inc = /usr/src/lib/libc/db/btree/Makefile.inc = /usr/src/lib/libc/db/db/Makefile.inc = /usr/src/lib/libc/db/hash/Makefile.inc = /usr/src/lib/libc/db/man/Makefile.inc = /usr/src/lib/libc/db/mpool/Makefile.inc = /usr/src/lib/libc/db/recno/Makefile.inc = /usr/src/lib/libc/compat-43/Makefile.inc = /usr/src/lib/libc/gdtoa/Makefile.inc /usr/src/lib/libc/gen/Makefile.inc = /usr/src/lib/libc/aarch64/gen > /Makefile.inc /usr/src/lib/libc/gmon/Makefile.inc = /usr/src/lib/libc/iconv/Makefile.inc = /usr/src/lib/libc_nonshared/Makefile.iconv = /usr/src/lib/libc/inet/Makefile.inc /usr/src/lib/libc/isc/Makefile.inc = /usr/src/lib/libc/locale/Makefile.inc /usr/src/lib/libc/md/Makefile.inc = /usr/src/lib/libc/nameser/Makefile.inc = /usr/src/lib/libc/net/Makefile.inc /usr/src/lib/libc/nls/Makefile.inc = /usr/src/lib/libc/posix1e/Makefile.inc = /usr/src/lib/libc/regex/Makefile.inc = /usr/src/lib/libc/resolv/Makefile.inc = /usr/src/lib/libc/stdio/Makefile.inc = /usr/src/lib/libc/stdlib/Makefile.inc = /usr/src/lib/libc/stdlib/jemalloc/Makefile.inc = /usr/src/lib/libc/stdtime/Makefile.inc = /usr/src/lib/libc/string/Makefile.inc = /usr/src/lib/libc/aarch64/string/Makefile.inc = /usr/src/lib/libc/sys/Makefile.inc /usr/src/sys/sys/syscall.mk = /usr/src/lib/libc/aarch64/sys/Makefile.inc = /usr/src/lib/libc/secure/Makefile.inc /usr/src/lib/libc/rpc/Makefile.inc = /usr/src/lib/libc/uuid/Makefile.inc /usr/src/lib/libc/xdr/Makefile.inc = /usr/s > rc/lib/libc/yp/Makefile.inc /usr/src/lib/libc/capability/Makefile.inc = /usr/src/share/mk/bsd.lib.mk /usr/src/share/mk/bsd.init.mk = /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk = /usr/src/lib/libc/../Makefile.inc /usr/src/share/mk/bsd.libnames.mk = /usr/src/share/mk/src.libnames.mk /usr/src/share/mk/bsd.symver.mk = /usr/src/share/mk/bsd.nls.mk /usr/src/share/mk/bsd.files.mk = /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.confs.mk = /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.dep.mk = /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk = /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' > .PATH=3D'. /usr/src/lib/libc /usr/src/lib/libc/db/btree = /usr/src/lib/libc/db/db /usr/src/lib/libc/db/hash = /usr/src/lib/libc/db/man /usr/src/lib/libc/db/mpool = /usr/src/lib/libc/db/recno /usr/src/lib/libc/compat-43 = /usr/src/lib/libc/gdtoa /usr/src/lib/libc/aarch64/gen = /usr/src/lib/libc/gen /usr/src/contrib/libc-pwcache = /usr/src/contrib/libc-vis /usr/src/lib/libc/gmon /usr/src/lib/libc/iconv = /usr/src/lib/libc/inet /usr/src/lib/libc/isc /usr/src/lib/libc/locale = /usr/src/lib/libmd /usr/src/lib/libc/nameser /usr/src/lib/libc/net = /usr/src/lib/libc/nls /usr/src/lib/libc/posix1e /usr/src/lib/libc/regex = /usr/src/lib/libc/resolv /usr/src/lib/libc/stdio = /usr/src/lib/libc/stdlib /usr/src/lib/libc/stdlib/jemalloc = /usr/src/lib/libc/stdtime /usr/src/contrib/tzcode/stdtime = /usr/src/lib/libc/aarch64/string /usr/src/lib/libc/string = /usr/src/sys/libkern /usr/src/contrib/cortex-strings/src/aarch64 = /usr/src/lib/libc/aarch64/sys /usr/src/lib/libc/sys = /usr/src/lib/libc/secure /usr/src/lib/libc/rpc /usr/src/li > b/libc/. /usr/src/lib/libc/uuid /usr/src/lib/libc/xdr = /usr/src/lib/libc/yp /usr/src/sys/kern /usr/src/lib/libc/capability' > 1 error >=20 > # ls -lT = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin/* > -r-xr-xr-x 1 root wheel 390264 Jun 17 15:06:21 2017 = /usr/local/libexec/gcc/aarch64-unknown-freebsd12.0/6.3.0/plugin/gengtype >=20 >=20 > The build context was: >=20 > # more = ~/sys_build_scripts.amd64-host/make_cortexA53_nodebug_incl_clang_xtoolchai= n-gcc-amd64-host.sh=20 > kldload -n filemon && \ > script = ~/sys_typescripts/typescript_make_cortexA53_nodebug_incl_clang_xtoolchain-= gcc-amd64-host-$(date +%Y-%m-%d:%H:%M:%S) \ > env __MAKE_CONF=3D"/root/src.configs/make.conf" SRCCONF=3D"/dev/null" = SRC_ENV_CONF=3D"/root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-= host" \ > WITH_META_MODE=3Dyes \ > MAKEOBJDIRPREFIX=3D"/usr/obj/cortexA53_xtoolchain-gcc" \ > make $* >=20 >=20 > # more /root/src.configs/src.conf.cortexA53-xtoolchain-gcc.amd64-host > TO_TYPE=3Daarch64 > TOOLS_TO_TYPE=3D${TO_TYPE} > VERSION_CONTEXT=3D12.0 > # > KERNCONF=3DGENERIC-NODBG > TARGET=3Darm64 > .if ${.MAKE.LEVEL} =3D=3D 0 > TARGET_ARCH=3D${TO_TYPE} > .export TARGET_ARCH > .endif > # > WITHOUT_CROSS_COMPILER=3D > WITHOUT_SYSTEM_COMPILER=3D > # > WITH_LIBCPLUSPLUS=3D > WITHOUT_BINUTILS_BOOTSTRAP=3D > WITHOUT_ELFTOOLCHAIN_BOOTSTRAP=3D > WITHOUT_CLANG_BOOTSTRAP=3D > WITH_CLANG=3D > WITH_CLANG_IS_CC=3D > WITH_CLANG_FULL=3D > WITH_CLANG_EXTRAS=3D > WITHOUT_LLD_BOOTSTRAP=3D > WITH_LLD=3D > WITH_LLD_IS_LD=3D > WITH_LLDB=3D > # > WITH_BOOT=3D > WITHOUT_LIB32=3D > # > WITHOUT_GCC_BOOTSTRAP=3D > WITHOUT_GCC=3D > WITHOUT_GCC_IS_CC=3D > WITHOUT_GNUCXX=3D > # > NO_WERROR=3D > #WERROR=3D > MALLOC_PRODUCTION=3D > # > WITH_REPRODUCIBLE_BUILD=3D > WITH_DEBUG_FILES=3D > # > XCFLAGS+=3D -mcpu=3Dcortex-a53 > XCXXFLAGS+=3D -mcpu=3Dcortex-a53 > # There is no XCPPFLAGS but XCPP gets XCFLAGS content. > # > # > # For TO (so-called "cross") stages . . . > # So-called-cross via ${TO_TYPE}-xtoolchain-gcc/${TO_TYPE}-gcc. . . > # TOOLS_TO_TYPE based on ${TO_TYPE}-xtoolchain-gcc related binutils. . = . > # > CROSS_TOOLCHAIN=3D${TO_TYPE}-gcc > X_COMPILER_TYPE=3Dgcc > CROSS_BINUTILS_PREFIX=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ > .if ${.MAKE.LEVEL} =3D=3D 0 > = XCC=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-gc= c > = XCXX=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-g= ++ > = XCPP=3D/usr/local/bin/${TOOLS_TO_TYPE}-unknown-freebsd${VERSION_CONTEXT}-c= pp > .export XCC > .export XCXX > .export XCPP > XAS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/as > XAR=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ar > XLD=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ld > XNM=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/nm > XOBJCOPY=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objcopy > XOBJDUMP=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/objdump > XRANLIB=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/ranlib > XSIZE=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/size > #NO-SUCH: XSTRINGS=3D/usr/local/${TOOLS_TO_TYPE}-freebsd/bin/strings > XSTRINGS=3D/usr/local/bin/${TOOLS_TO_TYPE}-freebsd-strings > .export XAS > .export XAR > .export XLD > .export XNM > .export XOBJCOPY > .export XOBJDUMP > .export XRANLIB > .export XSIZE > .export XSTRINGS > .endif > # > # > # =46rom based on clang (via system). . . > # > .if ${.MAKE.LEVEL} =3D=3D 0 > CC=3D/usr/bin/clang > CXX=3D/usr/bin/clang++ > CPP=3D/usr/bin/clang-cpp > .export CC > .export CXX > .export CPP > .endif >=20 >=20 > # more /usr/src/sys/arm64/conf/GENERIC-NODBG > # > # GENERIC -- Custom configuration for the arm64/aarch64 > # >=20 > include "GENERIC" >=20 > ident GENERIC-NODBG >=20 > makeoptions DEBUG=3D-g # Build kernel with gdb(1) = debug symbols >=20 > options ALT_BREAK_TO_DEBUGGER >=20 > options KDB # Enable kernel debugger = support >=20 > # For minimum debugger support (stable branch) use: > #options KDB_TRACE # Print a stack trace for a = panic > options DDB # Enable the kernel debugger >=20 > # Extra stuff: > #options VERBOSE_SYSINIT # Enable verbose sysinit = messages > #options BOOTVERBOSE=3D1 > #options BOOTHOWTO=3DRB_VERBOSE > #options KTR > #options KTR_MASK=3DKTR_TRAP > ##options KTR_CPUMASK=3D0xF > #options KTR_VERBOSE >=20 > # Disable any extra checking for. . . > nooptions DEADLKRES # Enable the deadlock resolver > nooptions INVARIANTS # Enable calls of extra sanity = checking > nooptions INVARIANT_SUPPORT # Extra sanity checks of = internal structures, required by INVARIANTS > nooptions WITNESS # Enable checks to detect = deadlocks and cycles > nooptions WITNESS_SKIPSPIN # Don't run witness on = spinlocks for speed > nooptions DIAGNOSTIC > nooptions MALLOC_DEBUG_MAXZONES # Separate malloc(9) zones > nooptions BUF_TRACKING > nooptions FULL_BUF_TRACKING =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Fri Jun 23 14:44:28 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76EF9DA5F2A for ; Fri, 23 Jun 2017 14:44:28 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: from mail.openmailbox.org (lb1.openmailbox.org [5.79.108.160]) (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 39F8D3215 for ; Fri, 23 Jun 2017 14:44:27 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: by mail.openmailbox.org (Postfix, from userid 20002) id CDAC35429E3; Fri, 23 Jun 2017 15:42:54 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1498225378; bh=okup7jrt3NM/u9uft2WayafSkEak5pNGdwK9ZB5mSRY=; h=Date:From:To:Subject:From; b=xb1JyevfKKYfF6UDF3yzXwQaVC/AZ1NnKD2/kytGMZ6hhOpNm3ujCSB6PSs1NnBkx zfyl7guvNzonCbCg5UeswkkfOADrprU1XEEHwhZh3WzwdC9xH/71Ky+H+AIAU3BH4z p62pF9IRfvG1Wa7P7kXBupdhm3aTAG7q0SDE12/w= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ZDZR002 X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=MISSING_MID,NO_RECEIVED, NO_RELAYS,T_DKIM_INVALID autolearn=disabled version=3.4.0 Date: Fri, 23 Jun 2017 13:42:19 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1498225373; bh=okup7jrt3NM/u9uft2WayafSkEak5pNGdwK9ZB5mSRY=; h=Date:From:To:Subject:From; b=1FvwHkLaBkGewy/2XGfpuWCObMJ5KvB/8FlEGx5ttZBjAPd1JOKqmhKXI1aCBzVEp p9e7UrspRW9HQ3o+eFrhzVAyo/addPOoEX6dam/bTnGkZgr+BcG0CJuXYJHJEt4WYe jEulAro1yNeNfZhSLAG9FugXHiUyturYePwnsAVU= From: sig6247 To: freebsd-arm@freebsd.org Subject: bananapi.dtb hangs with usr.bin/dtc MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20170623134258.CDAC35429E3@mail.openmailbox.org> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 14:44:28 -0000 Hi, I'm running 12.0-CURRENT r320136 on BananaPi M1+, it hangs at booting: Booting... /boot/dtb/bananapi.dtb size=0xe1a1 Loaded DTB from file 'bananapi.dtb'. Kernel entry at 0x42200100... Kernel args: (null) I tried to switch back to gnu/usr.bin/dtc and regenerated the bananapi.dtb with make_dtb.sh, this board boots again. Thanks, From owner-freebsd-arm@freebsd.org Fri Jun 23 15:19:16 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 99963DA6843 for ; Fri, 23 Jun 2017 15:19:16 +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 0CB50643D0 for ; Fri, 23 Jun 2017 15:19:15 +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 b2fff127; Fri, 23 Jun 2017 17:19:07 +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=7VnrhL55j6Ox9IHP1IKFOUEbI9Y=; b=Y35cf/pliWyJbdmbDHGp6EnFu0vs 11q8EZCw6hL2nLaliYl1+lIy1O4QwSwXoMuUC/6vojl3C4CjR2aTOj0ZmnkumAgL +HwGL1q/v7aM+WqER/zv5r+MF/eVIQWoDrQisAx6y0lRnhlNmJ+05QC/jNp8RBqw VIXYV4eEbc/OLck= 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=VTHtXW4vwLKV9F3KgIQB2VvxWdEVYwON11E+ZV0UD5o/OhCjdOxBng+4 oz00AImZKYFMoR+VVaMkL6m8F0XD3oVzT9FRj+9lirzX9gJpsq+ATBGGy3oKRRLc D4VZsHbd9m4vANssZKBo1ZbTp+t7s+kR8LR/VRj4YmwKejoFjc8= Received: from arcadia (evadot.gandi.net [217.70.181.36]) by mail.blih.net (OpenSMTPD) with ESMTPSA id f8daad4f TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 23 Jun 2017 17:19:07 +0200 (CEST) Date: Fri, 23 Jun 2017 17:19:06 +0200 From: Emmanuel Vadot To: sig6247 Cc: freebsd-arm@freebsd.org Subject: Re: bananapi.dtb hangs with usr.bin/dtc Message-Id: <20170623171906.88eb4178c7e305716a6b19ce@bidouilliste.com> In-Reply-To: <20170623134258.CDAC35429E3@mail.openmailbox.org> References: <20170623134258.CDAC35429E3@mail.openmailbox.org> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 15:19:16 -0000 On Fri, 23 Jun 2017 13:42:19 +0000 sig6247 wrote: > > Hi, > > I'm running 12.0-CURRENT r320136 on BananaPi M1+, > it hangs at booting: > > Booting... > /boot/dtb/bananapi.dtb size=0xe1a1 > Loaded DTB from file 'bananapi.dtb'. > Kernel entry at 0x42200100... > Kernel args: (null) > > I tried to switch back to gnu/usr.bin/dtc and regenerated > the bananapi.dtb with make_dtb.sh, this board boots again. > > Thanks, > _______________________________________________ > 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" The aliases seems weird : aliases { ethernet0 = "/soc@01c00000", "/ethernet@01c50000"; serial0 = "/soc@01c00000", "/serial@01c28000"; serial1 = "/soc@01c00000", "/serial@01c28c00"; serial2 = "/soc@01c00000", "/serial@01c29c00"; }; I'll look into it. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Fri Jun 23 18:07:22 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F11F4D86A2F for ; Fri, 23 Jun 2017 18:07:22 +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 4A98D6E66B for ; Fri, 23 Jun 2017 18:07:21 +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 23075361; Fri, 23 Jun 2017 20:07:19 +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=h+9quiQENTY4wCc19Q1IrpMkpg4=; b=V0YXE+ZWjKE2dZKRRGnzRmGpDldp PTcNfFuklcxRCODDEfzHqkYxfCFu4AxnUD76of/VSuI2jlikHI5R8/J8rlY0pFcW ixWMWrN8MictEOfbJ0vb5wP22+pugJS4Yi5rfEwd0OX3j2/xX3xxeVWH+JSLCoOS 5zBbHFll9VYI4Vs= 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=CgtcYvTHPWYHTQKtP6qf9CwptD6XTkv8WyDka5CUqzV/zN/3y9aBd6Du 232xJyJ653TKAyXYyjcfN77BdLlOKk33q1VKE8anmXcM8UiQSwxx1Ofd5l7J8NGE 85cVO9/who9bEoElwcpEF2cMBjYCMcoHcRvqSxpdIHFNdzBPyh8= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 53ee2e6e TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Fri, 23 Jun 2017 20:07:19 +0200 (CEST) Date: Fri, 23 Jun 2017 20:07:18 +0200 From: Emmanuel Vadot To: Emmanuel Vadot Cc: sig6247 , freebsd-arm@freebsd.org Subject: Re: bananapi.dtb hangs with usr.bin/dtc Message-Id: <20170623200718.53c30c8701a128f48165579e@bidouilliste.com> In-Reply-To: <20170623171906.88eb4178c7e305716a6b19ce@bidouilliste.com> References: <20170623134258.CDAC35429E3@mail.openmailbox.org> <20170623171906.88eb4178c7e305716a6b19ce@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 18:07:23 -0000 On Fri, 23 Jun 2017 17:19:06 +0200 Emmanuel Vadot wrote: > On Fri, 23 Jun 2017 13:42:19 +0000 > sig6247 wrote: > > > > > Hi, > > > > I'm running 12.0-CURRENT r320136 on BananaPi M1+, > > it hangs at booting: > > > > Booting... > > /boot/dtb/bananapi.dtb size=0xe1a1 > > Loaded DTB from file 'bananapi.dtb'. > > Kernel entry at 0x42200100... > > Kernel args: (null) > > > > I tried to switch back to gnu/usr.bin/dtc and regenerated > > the bananapi.dtb with make_dtb.sh, this board boots again. > > > > Thanks, > > _______________________________________________ > > 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" > > The aliases seems weird : > > aliases { > > ethernet0 = "/soc@01c00000", "/ethernet@01c50000"; > serial0 = "/soc@01c00000", "/serial@01c28000"; > serial1 = "/soc@01c00000", "/serial@01c28c00"; > serial2 = "/soc@01c00000", "/serial@01c29c00"; > }; > > I'll look into it. > > -- > Emmanuel Vadot > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" I've fixed the issue here https://github.com/davidchisnall/dtc/pull/23 I have some changes to pull from the github repo so I'll update our in-tree version when all of them are merged. Sorry for the breakage and thanks for reporting. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Jun 24 11:13:42 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2FAC9D9C8CA for ; Sat, 24 Jun 2017 11:13:42 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DF21D65DD3 for ; Sat, 24 Jun 2017 11:13:41 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: by mail-oi0-x235.google.com with SMTP id c189so36798411oia.2 for ; Sat, 24 Jun 2017 04:13:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=SZHxnh13y+Gn7rtwooLCWN9QwGABOQ9R5dy9yXM1QaI=; b=t9M3CbBlt+hzoucwdoilg+gNy7xTGMTnZzadjOe2d3ZRIvVlCo5kn5GdX1HZj7CS+8 PA5CIh2rro7Bl65jdHRXBvuJgvORd52GSji7y7mBiWq9rN0FPRfyiTvrMSZLhM8AnskA Q718knulvLEInmkorIHutloJI3mp2WzLmiCYth2JNMRaoN5mMxtvhQU5YYZjUuxP7/gJ asTAtA2FMnMctudCbo1FBHGQnPkgZZ2uwAT+jkruYOpMTmBjI/o3o0+5thJGJwLRoEQT ROc7QC9qhkz71+i2u/0S6pmYtxcrxrcFaZP+qtc4k6qBFOv2EFOtmfts5DqalJ+gzHUL i4Qw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=SZHxnh13y+Gn7rtwooLCWN9QwGABOQ9R5dy9yXM1QaI=; b=iuVppYtkU2T4g+FmI9Iet6qyeKeX5AjGUXjEUTxPugl/NTGOM+ddR/Yo/gKRiI17Hx wYhT1clCmFVmsonGOOXg791pzvJEzsMHyYdQAmMHbdQlM3VN2d6+2hdiqLNhLr27JaDE ks9O+0vhAzxJP2w5UVDC25+sokxSI21Sa/rVrgqasRNuMBnMg/TSBGpoWWhBBvyy7XA+ Qyz1QRljaNSoG3ScHSkJ9ozTif1j9ZvJKaNGSP2IgMhpo6m2JU0hRsc8+5GNuYe90B6s VZH3IY7mI8Yiq65/XarujCMDQXT1A+c2NvVr0hTTqTFIZGWGo7dWd/1qCcfcQiIhuyRu DALw== X-Gm-Message-State: AKS2vOyWl5IkRIcKrhqCon7aUEQQ24icbtu+OfwWJQIIjG9DBUgmtTFl PWrbp4hs8N9ePqHQGmJHXt3qwZhcVGetuOA= X-Received: by 10.202.80.197 with SMTP id e188mr4184375oib.50.1498302820952; Sat, 24 Jun 2017 04:13:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.29.73 with HTTP; Sat, 24 Jun 2017 04:13:40 -0700 (PDT) From: Johnny Sorocil Date: Sat, 24 Jun 2017 13:13:40 +0200 Message-ID: Subject: Orange Pi Zero support To: freebsd-arm@freebsd.org Content-Type: multipart/mixed; boundary="001a113b06da6926fa0552b2cfc0" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 11:13:42 -0000 --001a113b06da6926fa0552b2cfc0 Content-Type: text/plain; charset="UTF-8" Hi all! I am trying to run FreeBSD on Orange Pi Zero board (Allwinner H2+ SoC). I have few questions: 1) How to build vanilla u-boot which will be capable booting FreeBSD kernel? I have managed to load ubldr, but not the kernel. 2) How to use newer Linux dts/dtb files? 1) u-boot This is how I built u-boot: git clone git://git.denx.de/u-boot.git cd u-boot git checkout v2017.05 # apply patch so it can be built on FreeBSD (tested on FreeBSD 11.1-BETA1) (in the attachment) gmake ARCH=arm CROSS_COMPILE=arm-none-eabi- orangepi_zero_defconfig gmake -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi- dd if=u-boot-sunxi-with-spl.bin conv=notrunc,sync of=/dev/mmcsd0 bs=1024 seek=8 In the u-boot prompt: fatload mmc 0 0x42000000 ubldr.bin setenv fdtfile sun8i-h3-orangepi-one.dtb go 0x4200000 ubldr will work as expected, but kernel will hang at the start. If I use /usr/local/share/u-boot/u-boot-orangepi-one/u-boot-sunxi-with-spl.bin then the kernel and userland will boot normally. This is tested booting -CURRENT from Jul 22 (git: 57e30b47aab) 2) newer DTS/DTB If I use sun8i-h3-orangepi-one.dtb from FreeBSD source tree then the board will boot fine, but I don't have network. I can also boot normally if the dtb file is rebuilt manually: cd /usr/src/sys/gnu/dts/arm cpp -P -x assembler-with-cpp -I /usr/src/sys/gnu/dts/include -include sun8i-h3-orangepi-plus.dts /dev/null | dtc -O dtb -o ./sun8i-h3-rebuilt.dtb ls -lh sun8i-h3-rebuilt.dtb -rw-r--r-- 1 root wheel 15K Jun 24 13:02 sun8i-h3-rebuilt.dtb But, if dtb files from Armbian (Linux 4.11) are used, kernel will hang: Using DTB from loaded file 'boot/dtb-4.11.3-sun8i/sun8i-h2-plus-orangepi-zero.dtb'. Kernel entry at 0x42200100... Kernel args: -v The same file boots Linux without problems. I don't know why newer dtb files won't work because there is no output on serial console. Any ideas how to make it work? --001a113b06da6926fa0552b2cfc0 Content-Type: text/plain; charset="US-ASCII"; name="uboot_v2017.05.diff" Content-Disposition: attachment; filename="uboot_v2017.05.diff" Content-Transfer-Encoding: base64 X-Attachment-Id: f_j4b37e9x0 ZGlmZiAtLWdpdCBhL2xpYi9iY2guYyBiL2xpYi9iY2guYwppbmRleCBlYzUzNDgzNzc0Li5iNDVj NTA3YzUxIDEwMDY0NAotLS0gYS9saWIvYmNoLmMKKysrIGIvbGliL2JjaC5jCkBAIC02MSw3ICs2 MSwxMSBAQAogI2luY2x1ZGUgPGxpbnV4L2JpdG9wcy5oPgogI2Vsc2UKICNpbmNsdWRlIDxlcnJu by5oPgorI2lmZGVmIF9fRnJlZUJTRF9fCisjaW5jbHVkZSA8bWFjaGluZS9lbmRpYW4uaD4KKyNl bHNlCiAjaW5jbHVkZSA8ZW5kaWFuLmg+CisjZW5kaWYKICNpbmNsdWRlIDxzdGRpbnQuaD4KICNp bmNsdWRlIDxzdGRsaWIuaD4KICNpbmNsdWRlIDxzdHJpbmcuaD4KQEAgLTExMiw3ICsxMTYsNyBA QCBzdHJ1Y3QgZ2ZfcG9seV9kZWcxIHsKIAl1bnNpZ25lZCBpbnQgICBjWzJdOwogfTsKIAotI2lm ZGVmIFVTRV9IT1NUQ0MKKyNpZiBkZWZpbmVkIFVTRV9IT1NUQ0MgJiYgIWRlZmluZWQgX19GcmVl QlNEX18KIHN0YXRpYyBpbnQgZmxzKGludCB4KQogewogCWludCByID0gMzI7Cg== --001a113b06da6926fa0552b2cfc0-- From owner-freebsd-arm@freebsd.org Sat Jun 24 11:30:39 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ADE43D9CBDB for ; Sat, 24 Jun 2017 11:30:39 +0000 (UTC) (envelope-from amutu@amutu.com) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::229]) (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 7A78466276 for ; Sat, 24 Jun 2017 11:30:39 +0000 (UTC) (envelope-from amutu@amutu.com) Received: by mail-ot0-x229.google.com with SMTP id r67so45688668ota.1 for ; Sat, 24 Jun 2017 04:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amutu-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YAkyJ7NsLUaeSywTPEgfx7xnKMfE7dRURTJIrHh0LFI=; b=vRCW/LaCYvdreoNVQfugxQqq35cDUhITw1WR1mYZIvL1e8a2uDsC/V3t8syz77A5NB WJNaQNXNzK8uVCI+GmJeKSs0ly0qkdXxlkwJ7jw3YVjRSPQeY6I5VzTCxDwDfMxk/Z9n m/4zR1fO1PoZAciiQfnY/LrwH3D+7QMWnZG3Enn4ZY2Jf/bSNH+3EjW4DFVU4J9gh/gC wB0c5JCUl+V59CwcV/cxuL35m9owsenOV1Xxjvrzmg368Mhx57W8MUSSa7670DYcXGSd hmODF3XPcB5Ol6D0QrOp1z5IaV1RXO/tsVX/QgkLbJDF1w+5AbK5Q0F2tnEQ4EHxGj+s JFMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YAkyJ7NsLUaeSywTPEgfx7xnKMfE7dRURTJIrHh0LFI=; b=qimkmryOaCvNY+VfFDU95GICHqUOqC1ixo2AD4Yu/7X6AgVuPd7lv+upwCISNcdwwH fgGqm6vjYg+Hyd4NNd2uCMLcel+LWopWCkGFbc+NRaTh5++PRKc7m35gZp730ctw7ZFv vijqrs2X50cPEQDdAb15c89syeIPLYFd4lAkkJFs6xFDYDhfw0D3cMzgdSoluUBaTK6c 799+AOeFUiyhRRZibis2/RXlFAEVinlxSlfyMQky5hLb9y/xUclBBXjJmoJW/8XhEGZ9 3fWdPlpI0Qwmn5CSqXKh9qOQGMRQE8j4d3xibHQFoVtn2Zk29xdTTU1X1osHKhAGA0Za sL8w== X-Gm-Message-State: AKS2vOzcdRFigZ++5ow7m9C2b09GX1FZtOdvR4D3wRcv55ibEYlzHe1I r15C5i+7v0xdurifKotUew== X-Received: by 10.157.60.151 with SMTP id z23mr5971801otc.222.1498303838717; Sat, 24 Jun 2017 04:30:38 -0700 (PDT) Received: from mail-ot0-f170.google.com (mail-ot0-f170.google.com. [74.125.82.170]) by smtp.gmail.com with ESMTPSA id q106sm3659072ota.20.2017.06.24.04.30.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 24 Jun 2017 04:30:38 -0700 (PDT) Received: by mail-ot0-f170.google.com with SMTP id y47so45714499oty.0 for ; Sat, 24 Jun 2017 04:30:36 -0700 (PDT) X-Received: by 10.157.35.131 with SMTP id t3mr7175907otb.118.1498303836561; Sat, 24 Jun 2017 04:30:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.133.136 with HTTP; Sat, 24 Jun 2017 04:30:16 -0700 (PDT) In-Reply-To: References: From: Jov Date: Sat, 24 Jun 2017 19:30:16 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Orange Pi Zero support To: Johnny Sorocil Cc: freebsd-arm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 11:30:39 -0000 Hi=EF=BC=8C I have tried orangepi plus 2e imange and this can be used to boot and run orange pi zero and one.All except ethernet works well. I build uboot use this: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D214729 and use crochet build the image. I see a previous thread say dts files from linux can not be used on FreeBSD directly and should be modified. Jov 2017-06-24 19:13 GMT+08:00 Johnny Sorocil : > Hi all! > > I am trying to run FreeBSD on Orange Pi Zero board (Allwinner H2+ SoC). > > I have few questions: > 1) How to build vanilla u-boot which will be capable booting FreeBSD > kernel? I have managed to load ubldr, but not the kernel. > 2) How to use newer Linux dts/dtb files? > > 1) u-boot > This is how I built u-boot: > git clone git://git.denx.de/u-boot.git > cd u-boot > git checkout v2017.05 > # apply patch so it can be built on FreeBSD (tested on FreeBSD 11.1-BETA1= ) > (in the attachment) > gmake ARCH=3Darm CROSS_COMPILE=3Darm-none-eabi- orangepi_zero_defconfig > gmake -j4 ARCH=3Darm CROSS_COMPILE=3Darm-none-eabi- > dd if=3Du-boot-sunxi-with-spl.bin conv=3Dnotrunc,sync of=3D/dev/mmcsd0 bs= =3D1024 > seek=3D8 > > In the u-boot prompt: > fatload mmc 0 0x42000000 ubldr.bin > setenv fdtfile sun8i-h3-orangepi-one.dtb > go 0x4200000 > ubldr will work as expected, but kernel will hang at the start. > If I use > /usr/local/share/u-boot/u-boot-orangepi-one/u-boot-sunxi-with-spl.bin the= n > the kernel and userland will boot normally. > This is tested booting -CURRENT from Jul 22 (git: 57e30b47aab) > > 2) newer DTS/DTB > If I use sun8i-h3-orangepi-one.dtb from FreeBSD source tree then the boar= d > will boot fine, but I don't have network. > I can also boot normally if the dtb file is rebuilt manually: > cd /usr/src/sys/gnu/dts/arm > cpp -P -x assembler-with-cpp -I /usr/src/sys/gnu/dts/include -include > sun8i-h3-orangepi-plus.dts /dev/null | dtc -O dtb -o ./sun8i-h3-rebuilt.d= tb > ls -lh sun8i-h3-rebuilt.dtb > -rw-r--r-- 1 root wheel 15K Jun 24 13:02 sun8i-h3-rebuilt.dtb > But, if dtb files from Armbian (Linux 4.11) are used, kernel will hang: > Using DTB from loaded file > 'boot/dtb-4.11.3-sun8i/sun8i-h2-plus-orangepi-zero.dtb'. > Kernel entry at 0x42200100... > Kernel args: -v > The same file boots Linux without problems. > > I don't know why newer dtb files won't work because there is no output on > serial console. > Any ideas how to make it work? > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Sat Jun 24 12:47:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 83277D9E548 for ; Sat, 24 Jun 2017 12:47:26 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from fragranza.investici.org (fragranza.investici.org [IPv6:2a00:1dc0:2479::19]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.autistici.org", Issuer "Autistici/Inventati Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3EC146817E for ; Sat, 24 Jun 2017 12:47:25 +0000 (UTC) (envelope-from aggaz@paranoici.org) Received: from [178.175.144.26] (fragranza [178.175.144.26]) (Authenticated sender: aggaz@paranoici.org) by localhost (Postfix) with ESMTPSA id 4EF9C2C0173 for ; Sat, 24 Jun 2017 12:47:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paranoici.org; s=stigmate; t=1498308442; bh=1hYX4qvIRJ0iF9ym2YK+VMHJG74kh4TG3AaEyNVB5pU=; h=Subject:To:References:From:Date:In-Reply-To; b=HZY2p6LVVdlSiDmne4BjDZjftlsWqpqqi8rOmmzPKR9mG/RRyvF0yvVoAATBkcUWs O+pCRz9tQDxzMijtPBZxiondhUd7VMkZRgnTdK+ab7krMWORB0JfM8qgowQTgBbhrr 9uxbhfN1g+CFH5iEEzWUMbiTxUHtiRiFoqzWYCNE= Subject: Re: Orange Pi Zero support To: freebsd-arm@freebsd.org References: From: aggaz Message-ID: Date: Sat, 24 Jun 2017 14:47:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 12:47:26 -0000 Hello, try something like this: http://freebsd.1045724.x6.nabble.com/Re-FreeBSD-12-CURRENT-on-OrangePi-One-td6185280.html Regards > Hi all! > > I am trying to run FreeBSD on Orange Pi Zero board (Allwinner H2+ SoC). > > I have few questions: > 1) How to build vanilla u-boot which will be capable booting FreeBSD > kernel? I have managed to load ubldr, but not the kernel. > 2) How to use newer Linux dts/dtb files? > > 1) u-boot > This is how I built u-boot: > git clone git://git.denx.de/u-boot.git > cd u-boot > git checkout v2017.05 > # apply patch so it can be built on FreeBSD (tested on FreeBSD 11.1-BETA1) > (in the attachment) > gmake ARCH=arm CROSS_COMPILE=arm-none-eabi- orangepi_zero_defconfig > gmake -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi- > dd if=u-boot-sunxi-with-spl.bin conv=notrunc,sync of=/dev/mmcsd0 bs=1024 > seek=8 > > In the u-boot prompt: > fatload mmc 0 0x42000000 ubldr.bin > setenv fdtfile sun8i-h3-orangepi-one.dtb > go 0x4200000 > ubldr will work as expected, but kernel will hang at the start. > If I use > /usr/local/share/u-boot/u-boot-orangepi-one/u-boot-sunxi-with-spl.bin then > the kernel and userland will boot normally. > This is tested booting -CURRENT from Jul 22 (git: 57e30b47aab) > > 2) newer DTS/DTB > If I use sun8i-h3-orangepi-one.dtb from FreeBSD source tree then the board > will boot fine, but I don't have network. > I can also boot normally if the dtb file is rebuilt manually: > cd /usr/src/sys/gnu/dts/arm > cpp -P -x assembler-with-cpp -I /usr/src/sys/gnu/dts/include -include > sun8i-h3-orangepi-plus.dts /dev/null | dtc -O dtb -o ./sun8i-h3-rebuilt.dtb > ls -lh sun8i-h3-rebuilt.dtb > -rw-r--r-- 1 root wheel 15K Jun 24 13:02 sun8i-h3-rebuilt.dtb > But, if dtb files from Armbian (Linux 4.11) are used, kernel will hang: > Using DTB from loaded file > 'boot/dtb-4.11.3-sun8i/sun8i-h2-plus-orangepi-zero.dtb'. > Kernel entry at 0x42200100... > Kernel args: -v > The same file boots Linux without problems. > > I don't know why newer dtb files won't work because there is no output on > serial console. > Any ideas how to make it work? > -------------- next part -------------- > diff --git a/lib/bch.c b/lib/bch.c > index ec53483774..b45c507c51 100644 > --- a/lib/bch.c > +++ b/lib/bch.c > @@ -61,7 +61,11 @@ > #include > #else > #include > +#ifdef __FreeBSD__ > +#include > +#else > #include > +#endif > #include > #include > #include > @@ -112,7 +116,7 @@ struct gf_poly_deg1 { > unsigned int c[2]; > }; > > -#ifdef USE_HOSTCC > +#if defined USE_HOSTCC && !defined __FreeBSD__ > static int fls(int x) > { > int r = 32; From owner-freebsd-arm@freebsd.org Sat Jun 24 12:51:51 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B8D91D9E746 for ; Sat, 24 Jun 2017 12:51:51 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: from mail.openmailbox.org (lb1.openmailbox.org [5.79.108.160]) (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 7B89968307 for ; Sat, 24 Jun 2017 12:51:51 +0000 (UTC) (envelope-from sig6247@openmailbox.org) Received: by mail.openmailbox.org (Postfix, from userid 20002) id 8F3E250160F; Sat, 24 Jun 2017 14:51:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1498308707; bh=68l9eESz4ITT32lhKweoXn4ysgQ13Jf9zvhON0pDTBI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ySqw7bQfWbA78FcRqMYcuJzB20A+XOGCJSwhFyfCSuh6BiBLUY01Ye6VbCkdLzpSl GYyRQIOLDjrpNiZe2aWIdA+yBkLkfx3BTDJ/2J5tTvd9XnIsljLUaYF+3KsjeRCiBO nur7hNU2rr4R0TfrI14NyIGSahUrh2zA+BG+U58Q= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on ZDZR003 X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=MISSING_MID,NO_RECEIVED, NO_RELAYS,T_DKIM_INVALID,URIBL_BLOCKED autolearn=disabled version=3.4.0 Date: Sat, 24 Jun 2017 12:51:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=openmailbox.org; s=openmailbox; t=1498308705; bh=68l9eESz4ITT32lhKweoXn4ysgQ13Jf9zvhON0pDTBI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CgnbTzjiM5MxHGbVbNEzPsNXA2cUQw1M0mc79Fkd62UcVanmyZOIcDSepgke9Zs7I 1FyjcyuLG8pkOzTQiH5TPsquHI8nRXmgUSO6iZdkHUPOGWAWT3hYYj4QkLFiMR99l8 JDdD9MwvTvm0G0eoSWvMirAovk6uOzyhH3W6LcWc= From: sig6247 To: freebsd-arm@freebsd.org Subject: Re: bananapi.dtb hangs with usr.bin/dtc In-Reply-To: <20170623200718.53c30c8701a128f48165579e@bidouilliste.com> (Emmanuel Vadot's message of "Fri, 23 Jun 2017 20:07:18 +0200") References: <20170623134258.CDAC35429E3@mail.openmailbox.org> <20170623171906.88eb4178c7e305716a6b19ce@bidouilliste.com> <20170623200718.53c30c8701a128f48165579e@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-Id: <20170624125147.8F3E250160F@mail.openmailbox.org> X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 12:51:51 -0000 On Fri, 23 Jun 2017 20:07:18 +0200, Emmanuel Vadot wrote: > I've fixed the issue here https://github.com/davidchisnall/dtc/pull/23 > > I have some changes to pull from the github repo so I'll update our > in-tree version when all of them are merged. > > Sorry for the breakage and thanks for reporting. Hi Emmanuel, Thanks so much for your quick response. I just tested the patch, it worked on my BananaPi M1+. Thanks From owner-freebsd-arm@freebsd.org Sat Jun 24 15:15:46 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23A53DA06FB for ; Sat, 24 Jun 2017 15:15:46 +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 8F38E6F944 for ; Sat, 24 Jun 2017 15:15:45 +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 08db13d1; Sat, 24 Jun 2017 17:15:42 +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=YTwgelJlZTMYrWQa0ZGcmFdRzSg=; b=fBfNTILjB2HrXu8wyPoUI313j6c7 zpf/xaoO80XidkywbXyC8wrVFbBj6vmSvR5RAJRxMneWH29tA3R7dsBCyhQPcLRM s1Jj/TEchBao8P0qy5igqWu89sVKjHYaVMxfZB6wHWWMKtvq5pkdJWwhBXjWxwv4 EWUHu5ozh12OQSw= 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=GNnmq+I8pnbG+zog8J6JaBvqVFT6ASarZnEOxw/MIi19BryVdpXBPOA0 yZ4E+TDT7KXHOA//sHJ2SjQJEidKWVY5oTwbkX28r3A16+4tKsJoT9ofA14p+dzY SFP9V4/+zlX2zHUJjHfNMKbIAo+2sFd0nYUQXm/in2AvTpeVDPA= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 57810d43 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 24 Jun 2017 17:15:42 +0200 (CEST) Date: Sat, 24 Jun 2017 17:15:39 +0200 From: Emmanuel Vadot To: Johnny Sorocil Cc: freebsd-arm@freebsd.org Subject: Re: Orange Pi Zero support Message-Id: <20170624171539.3b6a73b245b05e649a62933c@bidouilliste.com> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 15:15:46 -0000 On Sat, 24 Jun 2017 13:13:40 +0200 Johnny Sorocil wrote: > Hi all! > > I am trying to run FreeBSD on Orange Pi Zero board (Allwinner H2+ SoC). > > I have few questions: > 1) How to build vanilla u-boot which will be capable booting FreeBSD > kernel? I have managed to load ubldr, but not the kernel. The easiest way is to use my github fork (https://github.com/evadot/u-boot/tree/freebsd) This have all the patches for FreeBSD that haven't made upstream yet. As soon as U-Boot 2017.07 is out (it should be out on July 10th) I'll create a new branch on the FreeBSD fork (https://github.com/freebsd/u-boot). Step to compile U-Boot: export CROSS_COMPILE=arm-none-eabi- gmake board_defconfig gmake menuconfig (and select "Enable FreeBSD boot") gmake > 2) How to use newer Linux dts/dtb files? For Allwinner it's straight forward, with a few exception we use the Linux DTS untouched. > 1) u-boot > This is how I built u-boot: > git clone git://git.denx.de/u-boot.git > cd u-boot > git checkout v2017.05 > # apply patch so it can be built on FreeBSD (tested on FreeBSD 11.1-BETA1) > (in the attachment) > gmake ARCH=arm CROSS_COMPILE=arm-none-eabi- orangepi_zero_defconfig > gmake -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi- > dd if=u-boot-sunxi-with-spl.bin conv=notrunc,sync of=/dev/mmcsd0 bs=1024 > seek=8 > > In the u-boot prompt: > fatload mmc 0 0x42000000 ubldr.bin > setenv fdtfile sun8i-h3-orangepi-one.dtb > go 0x4200000 > ubldr will work as expected, but kernel will hang at the start. > If I use > /usr/local/share/u-boot/u-boot-orangepi-one/u-boot-sunxi-with-spl.bin then > the kernel and userland will boot normally. > This is tested booting -CURRENT from Jul 22 (git: 57e30b47aab) > > 2) newer DTS/DTB > If I use sun8i-h3-orangepi-one.dtb from FreeBSD source tree then the board > will boot fine, but I don't have network. > I can also boot normally if the dtb file is rebuilt manually: > cd /usr/src/sys/gnu/dts/arm > cpp -P -x assembler-with-cpp -I /usr/src/sys/gnu/dts/include -include > sun8i-h3-orangepi-plus.dts /dev/null | dtc -O dtb -o ./sun8i-h3-rebuilt.dtb > ls -lh sun8i-h3-rebuilt.dtb > -rw-r--r-- 1 root wheel 15K Jun 24 13:02 sun8i-h3-rebuilt.dtb > But, if dtb files from Armbian (Linux 4.11) are used, kernel will hang: > Using DTB from loaded file > 'boot/dtb-4.11.3-sun8i/sun8i-h2-plus-orangepi-zero.dtb'. > Kernel entry at 0x42200100... > Kernel args: -v > The same file boots Linux without problems. > > I don't know why newer dtb files won't work because there is no output on > serial console. > Any ideas how to make it work? There is nothing on the serial console because we miss the h2 definition in aw_machdep.c I've started to add proper support for it today but there is some problems with some old clocks drivers. I'm currently patching them and hope to commit H2Plus support today or tomorow. Cheers, -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Jun 24 16:43:09 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4B9E9DA1F54 for ; Sat, 24 Jun 2017 16:43:09 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B86C172769 for ; Sat, 24 Jun 2017 16:43:07 +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 0f6859b0; Sat, 24 Jun 2017 18:42:59 +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=vGw72WwabWCG5HuGYKeFWVdLfLU=; b=qnY4OxM5qJ2k8cBg7/cJGX1tObWZ KWdhfF1u+hP89W2CXKKElEl1NISvMWiwzTwncIUEckhyUDix+EnTrzKkR1CquA3i fMHKACKg3Anjq1U04daE4LUgJ9+MQnsi5RdREtX8Pn8EkRbMlLY63speF4z23yMT jZNLUcQuU9ff7ck= 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=YByKOkCcYF5A5P58u6KbLTSsvbmzWp+EZy+CX49f8rpUdFCMxEXcob4P 45rnaZQiPXKm1iQ+w1cl9YVzu7bZHuO8lNDxZ7cJbdyo0SumRSykDFh0olgqUN4b vJOvzIzrEiRZtq/JUdbqwzvvSLz483LnjcBNxx7VRJ0wIqGlXFU= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 6b4a62e9 TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 24 Jun 2017 18:42:59 +0200 (CEST) Date: Sat, 24 Jun 2017 18:42:59 +0200 From: Emmanuel Vadot To: Emmanuel Vadot Cc: Johnny Sorocil , freebsd-arm@freebsd.org Subject: Re: Orange Pi Zero support Message-Id: <20170624184259.d2b7d2e6fbe6120cde572a33@bidouilliste.com> In-Reply-To: <20170624171539.3b6a73b245b05e649a62933c@bidouilliste.com> References: <20170624171539.3b6a73b245b05e649a62933c@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 16:43:09 -0000 On Sat, 24 Jun 2017 17:15:39 +0200 Emmanuel Vadot wrote: > On Sat, 24 Jun 2017 13:13:40 +0200 > Johnny Sorocil wrote: > > > Hi all! > > > > I am trying to run FreeBSD on Orange Pi Zero board (Allwinner H2+ SoC). > > > > I have few questions: > > 1) How to build vanilla u-boot which will be capable booting FreeBSD > > kernel? I have managed to load ubldr, but not the kernel. > > The easiest way is to use my github fork > (https://github.com/evadot/u-boot/tree/freebsd) This have all the > patches for FreeBSD that haven't made upstream yet. > As soon as U-Boot 2017.07 is out (it should be out on July 10th) I'll > create a new branch on the FreeBSD fork > (https://github.com/freebsd/u-boot). > > Step to compile U-Boot: > > export CROSS_COMPILE=arm-none-eabi- > gmake board_defconfig > gmake menuconfig (and select "Enable FreeBSD boot") > gmake > > > 2) How to use newer Linux dts/dtb files? > > For Allwinner it's straight forward, with a few exception we use the > Linux DTS untouched. > > > 1) u-boot > > This is how I built u-boot: > > git clone git://git.denx.de/u-boot.git > > cd u-boot > > git checkout v2017.05 > > # apply patch so it can be built on FreeBSD (tested on FreeBSD 11.1-BETA1) > > (in the attachment) > > gmake ARCH=arm CROSS_COMPILE=arm-none-eabi- orangepi_zero_defconfig > > gmake -j4 ARCH=arm CROSS_COMPILE=arm-none-eabi- > > dd if=u-boot-sunxi-with-spl.bin conv=notrunc,sync of=/dev/mmcsd0 bs=1024 > > seek=8 > > > > In the u-boot prompt: > > fatload mmc 0 0x42000000 ubldr.bin > > setenv fdtfile sun8i-h3-orangepi-one.dtb > > go 0x4200000 > > ubldr will work as expected, but kernel will hang at the start. > > If I use > > /usr/local/share/u-boot/u-boot-orangepi-one/u-boot-sunxi-with-spl.bin then > > the kernel and userland will boot normally. > > This is tested booting -CURRENT from Jul 22 (git: 57e30b47aab) > > > > 2) newer DTS/DTB > > If I use sun8i-h3-orangepi-one.dtb from FreeBSD source tree then the board > > will boot fine, but I don't have network. > > I can also boot normally if the dtb file is rebuilt manually: > > cd /usr/src/sys/gnu/dts/arm > > cpp -P -x assembler-with-cpp -I /usr/src/sys/gnu/dts/include -include > > sun8i-h3-orangepi-plus.dts /dev/null | dtc -O dtb -o ./sun8i-h3-rebuilt.dtb > > ls -lh sun8i-h3-rebuilt.dtb > > -rw-r--r-- 1 root wheel 15K Jun 24 13:02 sun8i-h3-rebuilt.dtb > > But, if dtb files from Armbian (Linux 4.11) are used, kernel will hang: > > Using DTB from loaded file > > 'boot/dtb-4.11.3-sun8i/sun8i-h2-plus-orangepi-zero.dtb'. > > Kernel entry at 0x42200100... > > Kernel args: -v > > The same file boots Linux without problems. > > > > I don't know why newer dtb files won't work because there is no output on > > serial console. > > Any ideas how to make it work? > > There is nothing on the serial console because we miss the h2 > definition in aw_machdep.c > I've started to add proper support for it today but there is some > problems with some old clocks drivers. I'm currently patching them and > hope to commit H2Plus support today or tomorow. > > Cheers, > > -- > Emmanuel Vadot > _______________________________________________ > 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" Sometime I'm just stupid and find problem where there is none. H2+ support has been commited in r320315. Ethernet and Wifi isn't supported yet. Let me know if you have any problems. -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Sat Jun 24 17:31:37 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41EB0DA2DDF for ; Sat, 24 Jun 2017 17:31:37 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0E95673EE6 for ; Sat, 24 Jun 2017 17:31:36 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: by mail-ot0-x234.google.com with SMTP id u13so48334573otd.2 for ; Sat, 24 Jun 2017 10:31:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eLfKIWCND+F/YO25f2btKcP2tYj29FGAsDi/8zT5YW8=; b=U9takOKwTjFidqQNDqqPsQXYjOaH2o7/7Vx/OXTLZc+p12b/9wd3QmMOqNic4tqANI qWGDaoVJoT6sl8xUki9dasPvheunh2WYoMOTYD4UVsO9fa6/oPLoeeS0gJ/NINUpWzKw ZqI5m83hXA2p6Y/JACQBEdY4hFrB1lqkCoIHuzP7BD3RZlmFPSWGOttnuiT1T8lf/aC2 kRTodwkYo9K9c8QNhA9daO9ubTw3GTEC+VnQaHiRU1XGvH5rE/VCYZuyaN2eG54Ueu9P yeXyWU9YfTmSbRpiyOhq0jEkwNot1Xv38uYovXaLuElSh3DTzULcOVql1G8zneKlKCTs 28Rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eLfKIWCND+F/YO25f2btKcP2tYj29FGAsDi/8zT5YW8=; b=Fw1HvBRoQ+x46qRmpMhQf2WkT108YHo0nDx+Yzik8CcGv9BvLn0ZuzPaT3pSelRW7a nvwYF+L4RHoyxNkwix1EIdcD/HlupVrw8ms4munfOeRAxyVpPDFSCDmsTZ2Pb8/EYg7U oHDdJNT6hgCyxf5LicUUOXLYmMQqSn3n0xHo1F+c6dKdqObALfVut0tN9YorL4s5stgE jBu7WnvoZQYUs0wa3sGmeEut9L6w4woYOh0EpKpIXldyHLqUmjPJFV4J62NCxCDzP0fj UtkDX1DgAARkjqtmdump+edPmH7Nw/8ZSaljaACQ8pDkUEkEKamg5M6KJH1GRzz/R2Oq fWEA== X-Gm-Message-State: AKS2vOyBuWyOte0qZruwSigm4XOZwi4BMnhBME1s6Ase5bszr1JmjsbN wwfUoc2VA9M7Mz7m8j22nau0EA/zz+WHXQk= X-Received: by 10.157.63.146 with SMTP id r18mr9052717otc.225.1498325496107; Sat, 24 Jun 2017 10:31:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.29.73 with HTTP; Sat, 24 Jun 2017 10:31:35 -0700 (PDT) In-Reply-To: <20170624171539.3b6a73b245b05e649a62933c@bidouilliste.com> References: <20170624171539.3b6a73b245b05e649a62933c@bidouilliste.com> From: Johnny Sorocil Date: Sat, 24 Jun 2017 19:31:35 +0200 Message-ID: Subject: Re: Orange Pi Zero support To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 17:31:37 -0000 On Sat, Jun 24, 2017 at 5:15 PM, Emmanuel Vadot wrote: > There is nothing on the serial console because we miss the h2 > definition in aw_machdep.c > I've started to add proper support for it today but there is some > problems with some old clocks drivers. I'm currently patching them and > hope to commit H2Plus support today or tomorow. It's nice to hear that :) I was experimenting with dts files (copied ethernet and emac part to the working dts file) - there will be output on the serial console, but no network: # dmesg | grep awg awg0: mem 0x1c30000-0x1c30103,0x1c00030-0x1c00033 irq 35 on simplebus0 dfs awg0: PHY type: rgmii, conf mode: reg awg0: EMAC clock: 0x00140006 awg0: AHB frequency 300000000 Hz, MDC div: 0x3 awg0: soft reset timed out device_attach: awg0 attach returned 60 Datasheet for H3 says that soft reset should be performed only after all clock inputs are valid. Is that because kernel is using old clock drivers? Are these assumptions correct: - the kernel will automatically use if_awg driver for the network card (even on H2+ which doesn't have a Gb interface) if there is a correct ethernet entry in dts? - when using newer Linux dts file (for H2+) there is no output on the serial console because dts file states that this is H2+, but FreeBSD kernel doesn't know what to do with H2+? - newer Linux dts files (which defines SoC as H2+) will be able to be used to boot FreeBSD? What is the status of FreeBSD SDIO support? Can I somehow help with the porting effort? Maybe slightly OT: How kernel is debugged? Connect JTAG debugger and then single step? What to use from HW and SW for that purpose? From owner-freebsd-arm@freebsd.org Sat Jun 24 17:33:35 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 423A2DA2E68 for ; Sat, 24 Jun 2017 17:33:35 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05ABE740E7 for ; Sat, 24 Jun 2017 17:33:35 +0000 (UTC) (envelope-from jsorocil@gmail.com) Received: by mail-ot0-x234.google.com with SMTP id y47so48467170oty.0 for ; Sat, 24 Jun 2017 10:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=X/yl+Tbx9BaVXt73SsHFpNovkcSwN0wr4MMWFQjCUkE=; b=ipT0FAH87vQZeb0iLUWfMpN6YXU1CGewVBZWcw1NOx1lsvnOaVrkoJmoX8YnZZwBqR 2ZiOohPiWEnhL/qBH2m57cbaTHUtgai15Jv9qED3zmdRfEVbAagyMX4osvZXrwDzWFyI bZ3rTIBGS03YUFbillBdGY6aZKKPgWApdVjMTpsJOMExOcGfy3EMs70BTh1Kgzqyz2g2 4jBDZt4WW5S+cblXwzNz0to+mFGPvTR1cGb5Icb4o5xDi7cPkykM7fqKNZ1Ot0w34EC2 zLPM3GaMUQWvKK7J5tRFdoUjTxpi7emRP0EUZ/WChQPl28ZFmBawulB59I+EtecdXDUh sfMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=X/yl+Tbx9BaVXt73SsHFpNovkcSwN0wr4MMWFQjCUkE=; b=Hc4bbqcLwxul9Jb0WYLdu+MdtO71oWjZDdRndoA+ych9OT0DoOIcqE+yckMuljiFxR j63fLYXdnfUdSTeODzpY0+yzY1cthQj0KgwSTPqrCiMWBIqcQs51wp/PWdEQjgAYdCs+ +hTaGixP1xAk5LBusV/xmBtJBnJ8EOUBwF40LwptBKdEmO02pzvhoWy7uZKCQNpqNrJk YSWZX35DyboXLz1PcevV1p0+74y1wm7I3Zs251dFyHnnsqDjHyPvrp3inm4Fg94wk9yJ tWMS4cHgzGf+Wx28bht9AaBkRap7qj/jpxigZncof35FPnWDNNknH67FczFcgUXkSZqX vFtw== X-Gm-Message-State: AKS2vOz8XoFdUC0Za0Q5Y+Z1zxdjoDrxtlXnFLfqOYA3aobL+Wbor70P xBu3+d8XsckuirHu7CoM5P6g6M8/ksbQzHk= X-Received: by 10.157.37.10 with SMTP id k10mr8324863otb.258.1498325614444; Sat, 24 Jun 2017 10:33:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.29.73 with HTTP; Sat, 24 Jun 2017 10:33:34 -0700 (PDT) In-Reply-To: <20170624184259.d2b7d2e6fbe6120cde572a33@bidouilliste.com> References: <20170624171539.3b6a73b245b05e649a62933c@bidouilliste.com> <20170624184259.d2b7d2e6fbe6120cde572a33@bidouilliste.com> From: Johnny Sorocil Date: Sat, 24 Jun 2017 19:33:34 +0200 Message-ID: Subject: Re: Orange Pi Zero support To: Emmanuel Vadot Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 17:33:35 -0000 On Sat, Jun 24, 2017 at 6:42 PM, Emmanuel Vadot wrote: > Sometime I'm just stupid and find problem where there is none. > H2+ support has been commited in r320315. > > Ethernet and Wifi isn't supported yet. > > Let me know if you have any problems. > Great, thank you! -CURRENT is building and I'll report back results From owner-freebsd-arm@freebsd.org Sat Jun 24 17:55:26 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CF9D0DA3248 for ; Sat, 24 Jun 2017 17:55:26 +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 3768174736 for ; Sat, 24 Jun 2017 17:55:25 +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 3371c5c9; Sat, 24 Jun 2017 19:55:22 +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=UsbZiFJ9sgZieHx4CQMamJuFqOo=; b=MhqVkqsEicrSZGYr9YgkIcYB6g4I hKGoT37aMZ4BmP3MkbdiEtA11B+2PLT5wfS0n9Q9NFNUsRl0oQW2YAx48CBmyrEJ GNEnu9FdorE3WnRedlScGu/mGNINrBdfPVHPVIdMWNF+PnNMgMl+YYRYYea1rMM5 9mWtKK+vk5sdty8= 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=FSRRxmWRSqAa5VXZwyTuoJ2Cizr6lpduswxe9aJpfZ17wCLqt/VWeDAx J5gqhjwn+K3rKqf/ufjAHdrhVi5Tk8TFSXCDADrnMVondOswRjIVVs869J5gY/df kAEXSGKqPPfSU8nJBNZY+pTqGLO7jri6RUhevBjie7gkviSbmUM= Received: from knuckles.blih.net (ip-54.net-82-216-203.roubaix.rev.numericable.fr [82.216.203.54]) by mail.blih.net (OpenSMTPD) with ESMTPSA id c4c3aede TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Sat, 24 Jun 2017 19:55:22 +0200 (CEST) Date: Sat, 24 Jun 2017 19:55:21 +0200 From: Emmanuel Vadot To: Johnny Sorocil Cc: freebsd-arm@freebsd.org Subject: Re: Orange Pi Zero support Message-Id: <20170624195521.e8628c9c9c8b7f736022c78e@bidouilliste.com> In-Reply-To: References: <20170624171539.3b6a73b245b05e649a62933c@bidouilliste.com> X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.31; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 17:55:26 -0000 On Sat, 24 Jun 2017 19:31:35 +0200 Johnny Sorocil wrote: > On Sat, Jun 24, 2017 at 5:15 PM, Emmanuel Vadot > wrote: > > > There is nothing on the serial console because we miss the h2 > > definition in aw_machdep.c > > I've started to add proper support for it today but there is some > > problems with some old clocks drivers. I'm currently patching them and > > hope to commit H2Plus support today or tomorow. > > It's nice to hear that :) > > I was experimenting with dts files (copied ethernet and emac part to the > working dts file) - there will be output on the serial console, but no > network: > # dmesg | grep awg > awg0: mem > 0x1c30000-0x1c30103,0x1c00030-0x1c00033 > irq 35 on simplebus0 dfs > awg0: PHY type: rgmii, conf mode: reg > awg0: EMAC clock: 0x00140006 > awg0: AHB frequency 300000000 Hz, MDC div: 0x3 > awg0: soft reset timed out > device_attach: awg0 attach returned 60 > Datasheet for H3 says that soft reset should be performed only after all > clock inputs are valid. > Is that because kernel is using old clock drivers? For H3 we switch to clkng already. The problem is that dts binding were not standardized when we added the driver (they will be in Linux 4.12). > Are these assumptions correct: > - the kernel will automatically use if_awg driver for the network card > (even on H2+ which doesn't have a Gb interface) if there is a correct > ethernet entry in dts? Yes. > - when using newer Linux dts file (for H2+) there is no output on the > serial console because dts file states that this is H2+, but FreeBSD > kernel doesn't know what to do with H2+? Not anymore but yes. > - newer Linux dts files (which defines SoC as H2+) will be able to be > used to boot FreeBSD? Yes. > What is the status of FreeBSD SDIO support? Not sure, maybe imp@ or kibab@ can answer that question. > Can I somehow help with the porting effort? > > Maybe slightly OT: > How kernel is debugged? Connect JTAG debugger and then single step? > What to use from HW and SW for that purpose? I mostly use printf because I don't have jtag hardware and I'm lazy :) -- Emmanuel Vadot