From owner-freebsd-arm@freebsd.org Sun Feb 28 01:55:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9BB7AB61BF for ; Sun, 28 Feb 2016 01:55:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6B18C1C4D for ; Sun, 28 Feb 2016 01:55:04 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 10720 invoked from network); 28 Feb 2016 01:55:20 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 01:55:20 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sat, 27 Feb 2016 20:55:16 -0500 (EST) Received: (qmail 5319 invoked from network); 28 Feb 2016 01:55:16 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 01:55:16 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id B11781C43D0; Sat, 27 Feb 2016 17:54:57 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: Date: Sat, 27 Feb 2016 17:55:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> To: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Roman Divacky , Dimitry Andric X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 01:55:05 -0000 I discovered on powerpc that __builtin_dwarf_cfa() for clang 3.8.0 and = g++ do not agree. For powerpc this breaks C++ exception handling (via = the use in libgcc_s's unwind handling), resulting in uncaught exceptions = and SEGV's. objdump -d for the two line source file below shows the low = level differences. > extern void g(void*); > void f() { g(__builtin_dwarf_cfa()); } I've also shown the same issue for powerpc64. The issue is where g's argument value points relative to f's frame and = f's caller's frame (since __builtin_dwarf_cfa() is called by f, not g). And now for armv6 . . . > # clang++ -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-littlearm >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> push {fp, lr} > 00000004 <_Z1fv+0x4> mov fp, sp > 00000008 <_Z1fv+0x8> mov r0, fp > 0000000c <_Z1fv+0xc> bl 00000000 <_Z1gPv> > 00000010 <_Z1fv+0x10> pop {fp, pc} vs. > # g++5 -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-littlearm >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> push {fp, lr} > 00000004 <_Z1fv+0x4> add fp, sp, #4, 0 > 00000008 <_Z1fv+0x8> add r3, fp, #4, 0 > 0000000c <_Z1fv+0xc> mov r0, r3 > 00000010 <_Z1fv+0x10> bl 00000000 <_Z1gPv> > 00000014 <_Z1fv+0x14> nop ; (mov r0, r0) > 00000018 <_Z1fv+0x18> pop {fp, pc} They do not agree. So any infrastructure based on __builtin_dwarf_cfa() use will be = compiler sensitive for armv6 as well. [It is my understanding that what g++ does is what the normal sort of = .eh_frame infrastructure is designed for: pointing between the caller's = and called's frames.] For reference: powerpc64 and powerpc results. . . > # clang++ -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 0000000000000000 <._Z1fv> mflr r0 > 0000000000000004 <._Z1fv+0x4> std r31,-8(r1) > 0000000000000008 <._Z1fv+0x8> std r0,16(r1) > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > 0000000000000014 <._Z1fv+0x14> mr r3,r31 > 0000000000000018 <._Z1fv+0x18> bl 0000000000000018 <._Z1fv+0x18> > 000000000000001c <._Z1fv+0x1c> nop > 0000000000000020 <._Z1fv+0x20> addi r1,r1,128 > 0000000000000024 <._Z1fv+0x24> ld r0,16(r1) > 0000000000000028 <._Z1fv+0x28> ld r31,-8(r1) > 000000000000002c <._Z1fv+0x2c> mtlr r0 > 0000000000000030 <._Z1fv+0x30> blr > ... r3 does not point to a boundary with f's caller's stack frame. By contrast for g++49: > # g++49 -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o | = more >=20 > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 0000000000000000 <._Z1fv> mflr r0 > 0000000000000004 <._Z1fv+0x4> std r0,16(r1) > 0000000000000008 <._Z1fv+0x8> std r31,-8(r1) > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > 0000000000000014 <._Z1fv+0x14> addi r9,r31,128 > 0000000000000018 <._Z1fv+0x18> mr r3,r9 > 000000000000001c <._Z1fv+0x1c> bl 000000000000001c <._Z1fv+0x1c> > 0000000000000020 <._Z1fv+0x20> nop > 0000000000000024 <._Z1fv+0x24> addi r1,r31,128 > 0000000000000028 <._Z1fv+0x28> ld r0,16(r1) > 000000000000002c <._Z1fv+0x2c> mtlr r0 > 0000000000000030 <._Z1fv+0x30> ld r31,-8(r1) > 0000000000000034 <._Z1fv+0x34> blr > 0000000000000038 <._Z1fv+0x38> .long 0x0 > 000000000000003c <._Z1fv+0x3c> .long 0x90001 > 0000000000000040 <._Z1fv+0x40> lwz r0,1(r1) r3 does point to a boundary with f's caller's stack frame. For TARGET_ARCH=3Dpowerpc, clang 3.8.0 first: > # clang++ -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> bl 00000018 <_Z1fv+0x18> > 0000001c <_Z1fv+0x1c> addi r1,r1,16 > 00000020 <_Z1fv+0x20> lwz r0,4(r1) > 00000024 <_Z1fv+0x24> lwz r31,-4(r1) > 00000028 <_Z1fv+0x28> mtlr r0 > 0000002c <_Z1fv+0x2c> blr Then g++5 (5.3): > # g++5 -c -g -std=3Dc++11 -Wall -pedantic builtin_dwarf_cfa.cpp > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o >=20 > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd >=20 >=20 > Disassembly of section .text: > 00000000 <_Z1fv> stwu r1,-16(r1) > 00000004 <_Z1fv+0x4> mflr r0 > 00000008 <_Z1fv+0x8> stw r0,20(r1) > 0000000c <_Z1fv+0xc> stw r31,12(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> addi r9,r31,16 > 00000018 <_Z1fv+0x18> mr r3,r9 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> nop > 00000024 <_Z1fv+0x24> addi r11,r31,16 > 00000028 <_Z1fv+0x28> lwz r0,4(r11) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> lwz r31,-4(r11) > 00000034 <_Z1fv+0x34> mr r1,r11 > 00000038 <_Z1fv+0x38> blr The historical note below is from before I'd discovered powerpc64 or = armv6 have the same sort of issue. But it gives an example use that is = broken for powerpc and powerpc64. (I do not know if armv6 uses the same = infrastructure.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-27, at 3:31 PM, Mark Millard wrote: >=20 > [Top post for dinging the low level problem that directly breaks c++ = exception handling for TARGET_ARCH=3Dpowerpc for clang 3.8.0 generated = code.] >=20 > I've tracked down the c++ exception problem for TARGET_ARCH=3Dpowerpc = via clang 3.8.0: misbehavior of clang 3.8.0 code generation for = __builtin_dwarf_cfa () as used in: >=20 > #define uw_init_context(CONTEXT) = \ > do = \ > { = \ > /* Do any necessary initialization to access arbitrary stack = frames. \ > On the SPARC, this means flushing the register windows. */ = \ > __builtin_unwind_init (); = \ > uw_init_context_1 (CONTEXT, __builtin_dwarf_cfa (), = \ > __builtin_return_address (0)); = \ > } = \ > while (0) > . . . > 85 _Unwind_Reason_Code > 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) > 87 { > 88 struct _Unwind_Context this_context, cur_context; > 89 _Unwind_Reason_Code code; > 90=09 > 91 /* Set up this_context to describe the current stack frame. = */ > 92 uw_init_context (&this_context); >=20 > In the below r4 ends up with the __builtin_dwarf_cfa () value supplied = to uw_init_context_1: >=20 > Dump of assembler code for function _Unwind_RaiseException: > 0x419a8fd8 <+0>: mflr r0 > 0x419a8fdc <+4>: stw r31,-148(r1) > 0x419a8fe0 <+8>: stw r30,-152(r1) > 0x419a8fe4 <+12>: stw r0,4(r1) > 0x419a8fe8 <+16>: stwu r1,-2992(r1) > 0x419a8fec <+20>: mr r31,r1 > . . . > 0x419a9094 <+188>: mr r4,r31 > 0x419a9098 <+192>: mflr r30 > 0x419a909c <+196>: lwz r5,2996(r31) > 0x419a90a0 <+200>: mr r3,r28 > 0x419a90a4 <+204>: bl 0x419a929c >=20 > That r4 ends up holding the stack pointer value for after it has been = decremented. r4 is not pointing at the boundary with the caller's frame. >=20 > The .eh_frame information and unwind code is set up for pointing at = the boundary with the caller's frame. So the cfa relative addressing is = messed up for what it actually extracts. >=20 > Contrast this with gcc/g++ 5.3's TARGET_ARCH=3Dpowerpc64 code where r4 = is made to be at the boundary with the caller's frame: >=20 > Dump of assembler code for function _Unwind_RaiseException: > 0x00000000501cb810 <+0>: mflr r0 > 0x00000000501cb814 <+4>: stdu r1,-5648(r1) > . . . > 0x00000000501cb8d0 <+192>: addi r4,r1,5648 > 0x00000000501cb8d4 <+196>: stw r12,5656(r1) > 0x00000000501cb8d8 <+200>: mr r28,r3 > 0x00000000501cb8dc <+204>: addi r31,r1,2544 > 0x00000000501cb8e0 <+208>: mr r3,r27 > 0x00000000501cb8e4 <+212>: addi r29,r1,112 > 0x00000000501cb8e8 <+216>: bl 0x501cae60 >=20 >=20 > NOTE: The powerpc (32-bit) issue may in some way be associated with = the clang 3.8.0 powerpc ABI violation in how it handles the stack = pointer for FreeBSD: TARGET_ARCH=3Dpowerpc is currently using a "red = zone", decrementing the stack pointer late, and incrementing the stack = pointer early compared to the FreeBSD ABI rules. (This is similar to the = official FreeBSD ABI for TARGET_ARCH=3Dpowerpc64.) >=20 >=20 >=20 >=20 > =3D=3D=3D > Mark Millard > markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Feb 28 08:41:58 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A1747AB7F02; Sun, 28 Feb 2016 08:41:58 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (mail.vlakno.cz [91.217.96.224]) by mx1.freebsd.org (Postfix) with ESMTP id 32242188C; Sun, 28 Feb 2016 08:41:57 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: by vlakno.cz (Postfix, from userid 1002) id 49D291E20F9C; Sun, 28 Feb 2016 09:39:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=vlakno.cz; s=mail; t=1456648774; bh=kdnu7GPiW5BPapHqf8pxugQ40PsHcIvJJjTTfaaTzX4=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=LOZZTVzKU6rfjOclY1Av/Vsu40I0SMXGWL+ZFGWf/hjUpx4mtx8BYF7s2otcocOsp A7Xk96hKfB0qoTKYMSs9Ayd/ahaEvcvPdggdPJr8Knq2SXfe8vHd/YP2YTOgZ0E/Xk mKiPUYuNAdvwhHnIxodZ3wZVYmxob1mxVgp0ZLX4= Date: Sun, 28 Feb 2016 09:39:34 +0100 From: Roman Divacky To: Mark Millard Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Dimitry Andric Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update Message-ID: <20160228083934.GA60222@vlakno.cz> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 08:41:58 -0000 Mark, __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic eh_dwarf_cfa. There's a depth argument (which defaults to 0, saying it's correct for most targets). Then the intrinsic gets lowered in SelectionDAG using PPCTargetLowering::LowerFRAMEADDR() Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that LowerFRAMEADDR() does something sensible? There's a loop depth-times, so I wonder if that makes a difference. Thanks, Roman On Sat, Feb 27, 2016 at 05:55:02PM -0800, Mark Millard wrote: > I discovered on powerpc that __builtin_dwarf_cfa() for clang 3.8.0 and g++ do not agree. For powerpc this breaks C++ exception handling (via the use in libgcc_s's unwind handling), resulting in uncaught exceptions and SEGV's. objdump -d for the two line source file below shows the low level differences. > > > extern void g(void*); > > void f() { g(__builtin_dwarf_cfa()); } > > I've also shown the same issue for powerpc64. > > The issue is where g's argument value points relative to f's frame and f's caller's frame (since __builtin_dwarf_cfa() is called by f, not g). > > And now for armv6 . . . > > > # clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-littlearm > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> push {fp, lr} > > 00000004 <_Z1fv+0x4> mov fp, sp > > 00000008 <_Z1fv+0x8> mov r0, fp > > 0000000c <_Z1fv+0xc> bl 00000000 <_Z1gPv> > > 00000010 <_Z1fv+0x10> pop {fp, pc} > > vs. > > > # g++5 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-littlearm > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> push {fp, lr} > > 00000004 <_Z1fv+0x4> add fp, sp, #4, 0 > > 00000008 <_Z1fv+0x8> add r3, fp, #4, 0 > > 0000000c <_Z1fv+0xc> mov r0, r3 > > 00000010 <_Z1fv+0x10> bl 00000000 <_Z1gPv> > > 00000014 <_Z1fv+0x14> nop ; (mov r0, r0) > > 00000018 <_Z1fv+0x18> pop {fp, pc} > > > They do not agree. > > So any infrastructure based on __builtin_dwarf_cfa() use will be compiler sensitive for armv6 as well. > > [It is my understanding that what g++ does is what the normal sort of .eh_frame infrastructure is designed for: pointing between the caller's and called's frames.] > > > For reference: powerpc64 and powerpc results. . . > > > # clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd > > > > > > Disassembly of section .text: > > 0000000000000000 <._Z1fv> mflr r0 > > 0000000000000004 <._Z1fv+0x4> std r31,-8(r1) > > 0000000000000008 <._Z1fv+0x8> std r0,16(r1) > > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > > 0000000000000014 <._Z1fv+0x14> mr r3,r31 > > 0000000000000018 <._Z1fv+0x18> bl 0000000000000018 <._Z1fv+0x18> > > 000000000000001c <._Z1fv+0x1c> nop > > 0000000000000020 <._Z1fv+0x20> addi r1,r1,128 > > 0000000000000024 <._Z1fv+0x24> ld r0,16(r1) > > 0000000000000028 <._Z1fv+0x28> ld r31,-8(r1) > > 000000000000002c <._Z1fv+0x2c> mtlr r0 > > 0000000000000030 <._Z1fv+0x30> blr > > ... > > r3 does not point to a boundary with f's caller's stack frame. > > By contrast for g++49: > > > # g++49 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o | more > > > > builtin_dwarf_cfa.o: file format elf64-powerpc-freebsd > > > > > > Disassembly of section .text: > > 0000000000000000 <._Z1fv> mflr r0 > > 0000000000000004 <._Z1fv+0x4> std r0,16(r1) > > 0000000000000008 <._Z1fv+0x8> std r31,-8(r1) > > 000000000000000c <._Z1fv+0xc> stdu r1,-128(r1) > > 0000000000000010 <._Z1fv+0x10> mr r31,r1 > > 0000000000000014 <._Z1fv+0x14> addi r9,r31,128 > > 0000000000000018 <._Z1fv+0x18> mr r3,r9 > > 000000000000001c <._Z1fv+0x1c> bl 000000000000001c <._Z1fv+0x1c> > > 0000000000000020 <._Z1fv+0x20> nop > > 0000000000000024 <._Z1fv+0x24> addi r1,r31,128 > > 0000000000000028 <._Z1fv+0x28> ld r0,16(r1) > > 000000000000002c <._Z1fv+0x2c> mtlr r0 > > 0000000000000030 <._Z1fv+0x30> ld r31,-8(r1) > > 0000000000000034 <._Z1fv+0x34> blr > > 0000000000000038 <._Z1fv+0x38> .long 0x0 > > 000000000000003c <._Z1fv+0x3c> .long 0x90001 > > 0000000000000040 <._Z1fv+0x40> lwz r0,1(r1) > > r3 does point to a boundary with f's caller's stack frame. > > For TARGET_ARCH=powerpc, clang 3.8.0 first: > > > # clang++ -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> mflr r0 > > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > > 00000008 <_Z1fv+0x8> stw r0,4(r1) > > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > > 00000010 <_Z1fv+0x10> mr r31,r1 > > 00000014 <_Z1fv+0x14> mr r3,r31 > > 00000018 <_Z1fv+0x18> bl 00000018 <_Z1fv+0x18> > > 0000001c <_Z1fv+0x1c> addi r1,r1,16 > > 00000020 <_Z1fv+0x20> lwz r0,4(r1) > > 00000024 <_Z1fv+0x24> lwz r31,-4(r1) > > 00000028 <_Z1fv+0x28> mtlr r0 > > 0000002c <_Z1fv+0x2c> blr > > Then g++5 (5.3): > > > # g++5 -c -g -std=c++11 -Wall -pedantic builtin_dwarf_cfa.cpp > > # /usr/local/bin/objdump -d --prefix-addresses builtin_dwarf_cfa.o > > > > builtin_dwarf_cfa.o: file format elf32-powerpc-freebsd > > > > > > Disassembly of section .text: > > 00000000 <_Z1fv> stwu r1,-16(r1) > > 00000004 <_Z1fv+0x4> mflr r0 > > 00000008 <_Z1fv+0x8> stw r0,20(r1) > > 0000000c <_Z1fv+0xc> stw r31,12(r1) > > 00000010 <_Z1fv+0x10> mr r31,r1 > > 00000014 <_Z1fv+0x14> addi r9,r31,16 > > 00000018 <_Z1fv+0x18> mr r3,r9 > > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > > 00000020 <_Z1fv+0x20> nop > > 00000024 <_Z1fv+0x24> addi r11,r31,16 > > 00000028 <_Z1fv+0x28> lwz r0,4(r11) > > 0000002c <_Z1fv+0x2c> mtlr r0 > > 00000030 <_Z1fv+0x30> lwz r31,-4(r11) > > 00000034 <_Z1fv+0x34> mr r1,r11 > > 00000038 <_Z1fv+0x38> blr > > > The historical note below is from before I'd discovered powerpc64 or armv6 have the same sort of issue. But it gives an example use that is broken for powerpc and powerpc64. (I do not know if armv6 uses the same infrastructure.) > > === > Mark Millard > markmi at dsl-only.net > > On 2016-Feb-27, at 3:31 PM, Mark Millard wrote: > > > > [Top post for dinging the low level problem that directly breaks c++ exception handling for TARGET_ARCH=powerpc for clang 3.8.0 generated code.] > > > > I've tracked down the c++ exception problem for TARGET_ARCH=powerpc via clang 3.8.0: misbehavior of clang 3.8.0 code generation for __builtin_dwarf_cfa () as used in: > > > > #define uw_init_context(CONTEXT) \ > > do \ > > { \ > > /* Do any necessary initialization to access arbitrary stack frames. \ > > On the SPARC, this means flushing the register windows. */ \ > > __builtin_unwind_init (); \ > > uw_init_context_1 (CONTEXT, __builtin_dwarf_cfa (), \ > > __builtin_return_address (0)); \ > > } \ > > while (0) > > . . . > > 85 _Unwind_Reason_Code > > 86 _Unwind_RaiseException(struct _Unwind_Exception *exc) > > 87 { > > 88 struct _Unwind_Context this_context, cur_context; > > 89 _Unwind_Reason_Code code; > > 90 > > 91 /* Set up this_context to describe the current stack frame. */ > > 92 uw_init_context (&this_context); > > > > In the below r4 ends up with the __builtin_dwarf_cfa () value supplied to uw_init_context_1: > > > > Dump of assembler code for function _Unwind_RaiseException: > > 0x419a8fd8 <+0>: mflr r0 > > 0x419a8fdc <+4>: stw r31,-148(r1) > > 0x419a8fe0 <+8>: stw r30,-152(r1) > > 0x419a8fe4 <+12>: stw r0,4(r1) > > 0x419a8fe8 <+16>: stwu r1,-2992(r1) > > 0x419a8fec <+20>: mr r31,r1 > > . . . > > 0x419a9094 <+188>: mr r4,r31 > > 0x419a9098 <+192>: mflr r30 > > 0x419a909c <+196>: lwz r5,2996(r31) > > 0x419a90a0 <+200>: mr r3,r28 > > 0x419a90a4 <+204>: bl 0x419a929c > > > > That r4 ends up holding the stack pointer value for after it has been decremented. r4 is not pointing at the boundary with the caller's frame. > > > > The .eh_frame information and unwind code is set up for pointing at the boundary with the caller's frame. So the cfa relative addressing is messed up for what it actually extracts. > > > > Contrast this with gcc/g++ 5.3's TARGET_ARCH=powerpc64 code where r4 is made to be at the boundary with the caller's frame: > > > > Dump of assembler code for function _Unwind_RaiseException: > > 0x00000000501cb810 <+0>: mflr r0 > > 0x00000000501cb814 <+4>: stdu r1,-5648(r1) > > . . . > > 0x00000000501cb8d0 <+192>: addi r4,r1,5648 > > 0x00000000501cb8d4 <+196>: stw r12,5656(r1) > > 0x00000000501cb8d8 <+200>: mr r28,r3 > > 0x00000000501cb8dc <+204>: addi r31,r1,2544 > > 0x00000000501cb8e0 <+208>: mr r3,r27 > > 0x00000000501cb8e4 <+212>: addi r29,r1,112 > > 0x00000000501cb8e8 <+216>: bl 0x501cae60 > > > > > > NOTE: The powerpc (32-bit) issue may in some way be associated with the clang 3.8.0 powerpc ABI violation in how it handles the stack pointer for FreeBSD: TARGET_ARCH=powerpc is currently using a "red zone", decrementing the stack pointer late, and incrementing the stack pointer early compared to the FreeBSD ABI rules. (This is similar to the official FreeBSD ABI for TARGET_ARCH=powerpc64.) > > > > > > > > > > === > > Mark Millard > > markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Feb 28 10:46:30 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C8C9AB679F for ; Sun, 28 Feb 2016 10:46:30 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 10E9A12A1 for ; Sun, 28 Feb 2016 10:46:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 16428 invoked from network); 28 Feb 2016 10:46:25 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 10:46:25 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 05:46:20 -0500 (EST) Received: (qmail 26052 invoked from network); 28 Feb 2016 10:46:20 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 10:46:20 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id D21271C43C6; Sun, 28 Feb 2016 02:46:25 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <20160228083934.GA60222@vlakno.cz> Date: Sun, 28 Feb 2016 02:46:26 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 10:46:30 -0000 On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Sun Feb 28 18:38:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33500AB77F2 for ; Sun, 28 Feb 2016 18:38:37 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: from relay.waschbuesch.it (relay.waschbuesch.it [IPv6:2a00:cba0:0:100::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ED98D19DA for ; Sun, 28 Feb 2016 18:38:36 +0000 (UTC) (envelope-from martin@waschbuesch.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id: Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type; bh=LKoU9lpBSBnjrs/zTGtl2Wcya8qq97J5h4ZOz8Zgw2w=; b=NFGIGF2lxUh9 i3luK+0P/UHubcd6wjfbpGANSSBOrKIaow3zXB9K4e4osmC4l6VF27mFj1LQBOUdeh2RuA/r4YATj Km7Kww2JknOBy4w0A68tDXV8pu0CPnCLzSZ1ttxzQ1Q03SatoQbMa13TBiuGVFEo32JkArMs5bxar 07Ifo=; Received: by relay.waschbuesch.it with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim) (envelope-from ) id 1aa6Ej-0005rN-5d for freebsd-arm@freebsd.org; Sun, 28 Feb 2016 18:38:33 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FreeBSD on Utilite (revisited) From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= In-Reply-To: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> Date: Sun, 28 Feb 2016 19:38:32 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 18:38:37 -0000 > Am 27.02.2016 um 17:15 schrieb Martin Waschb=C3=BCsch = : >=20 > What I do know: The device has both, mmc and mSATA. Which does disk0 = refer to? > Also, I tried playing around with u-boot env $loaderdev, but to no = avail. >=20 > Any and all help is appreciated! Update: While ubldr does not seem to be able to recognize the mmc devices, it = does work with usb, so I got as far as loader, but am now stuck with = with finding, adapting or creating the right .dts file for fdt. I am a little confused about the kernel sources having dts stuff both in = /usr/src/sys/gnu/dts/ as well as /usr/src/sys/boot/fdt/dts/. But anyway, = at least making a little progress... Martin From owner-freebsd-arm@freebsd.org Sun Feb 28 18:39:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0B9E2AB783C for ; Sun, 28 Feb 2016 18:39:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C40321A3B for ; Sun, 28 Feb 2016 18:39:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x22f.google.com with SMTP id y89so101065861qge.2 for ; Sun, 28 Feb 2016 10:39:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=aPtgOnBQfq0+YNS8kLam/1SlG9FlpmQsl8bIpeYYCCE=; b=h0B4uIK9nKDe7m6P17gGEC6an8gWMCl3U1LWTiG2gHqNDV1jUAqJ1XPtxCJYqze0AF 3GKUtGQ44aFNc14FQxmg6JFc9ctpIgbAen33Vs5pwpDF4IcFriPxlOk0TCV1Jil1yuid ZxS5gHMmFfAO1SlAAe/ZhboMWp2rCdhy1xN50Rj+xwW1agW3l2P0JDOodeIzSD/3l2NG aau9H4+9W4kFEWP3wbgu97O7lr5TSb3pKcGkQHAU0ot26YDL1UgQIHYGgSSd/XZbK1Kn eyKYo12reMQ15DT23Exm2C9Ssgwj6hlFzVujR8b+nver0UEulve+7msqheTDm2OxqrZ2 l8pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=aPtgOnBQfq0+YNS8kLam/1SlG9FlpmQsl8bIpeYYCCE=; b=I2+L7Ge+vfpdTDO0Kn3SVAdusLkAOmC5Ry3llphd9CsplWEv9CblWNEQAhdLZr03zZ PMO+CA0mygy6C6tn7Plu44IUWl2qgVewiPndly+JN14sYo7WKLG/YkmVYbdHG3J3ZzeN ae7+fA4K7x4uGC0yHrnNlahlCik5gnzwUDjF8lKX54djFqrzIXONAaX/7NPZj/2Hbm38 bHvGvldydG8AUA6BwJ9lsYV++FNB8MAqdxfEBQKeah7oIZ0MbvIVlQ07PUxhROdgm7lE zWdjZVxK73oAajiBQU8Bns8Ew777+vr8r0PsV4x0veLLc0X5eVpdHCb4nwO8bNQ02VQM WSIQ== X-Gm-Message-State: AD7BkJIKQ1Id+2CNSvpilsqB6Lp6wERxUWZ+nEkjxzEunFf8tOnOf+341wPcXEk2SQZmIpRGSdQMZdceSkjWcg== MIME-Version: 1.0 X-Received: by 10.140.28.162 with SMTP id 31mr14850350qgz.81.1456684782645; Sun, 28 Feb 2016 10:39:42 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Sun, 28 Feb 2016 10:39:42 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> Date: Sun, 28 Feb 2016 11:39:42 -0700 X-Google-Sender-Auth: 8kv-wIE3MBNksKShZ4QEqVOCID4 Message-ID: Subject: Re: FreeBSD on Utilite (revisited) From: Warner Losh To: =?UTF-8?Q?Martin_Waschb=C3=BCsch?= Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 18:39:44 -0000 On Sun, Feb 28, 2016 at 11:38 AM, Martin Waschb=C3=BCsch wrote: > > > Am 27.02.2016 um 17:15 schrieb Martin Waschb=C3=BCsch >: > > > > What I do know: The device has both, mmc and mSATA. Which does disk0 > refer to? > > Also, I tried playing around with u-boot env $loaderdev, but to no avai= l. > > > > Any and all help is appreciated! > > Update: > > While ubldr does not seem to be able to recognize the mmc devices, it doe= s > work with usb, so I got as far as loader, but am now stuck with with > finding, adapting or creating the right .dts file for fdt. > I am a little confused about the kernel sources having dts stuff both in > /usr/src/sys/gnu/dts/ as well as /usr/src/sys/boot/fdt/dts/. But anyway, = at > least making a little progress... > > Cool! Keep us posted. Warner From owner-freebsd-arm@freebsd.org Sun Feb 28 22:20:36 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BBECAB727E for ; Sun, 28 Feb 2016 22:20:36 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-157.reflexion.net [208.70.211.157]) (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 016E610FF for ; Sun, 28 Feb 2016 22:20:35 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 4558 invoked from network); 28 Feb 2016 22:20:32 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 22:20:32 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 17:20:47 -0500 (EST) Received: (qmail 4711 invoked from network); 28 Feb 2016 22:20:47 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 28 Feb 2016 22:20:47 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 779A1B1E001; Sun, 28 Feb 2016 14:20:29 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> Date: Sun, 28 Feb 2016 14:20:32 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain , Dimitry Andric Content-Transfer-Encoding: quoted-printable Message-Id: <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Feb 2016 22:20:36 -0000 In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; > =20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, = Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > =20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); > =20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; > =20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; > =20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, = DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Feb 29 01:41:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8EFFAAD5CF for ; Mon, 29 Feb 2016 01:41:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9BF0E194 for ; Mon, 29 Feb 2016 01:41:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31484 invoked from network); 29 Feb 2016 01:41:00 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 01:41:00 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 20:40:53 -0500 (EST) Received: (qmail 21805 invoked from network); 29 Feb 2016 01:40:52 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 01:40:52 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 05472B1E001; Sun, 28 Feb 2016 17:40:54 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> Date: Sun, 28 Feb 2016 17:40:58 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 01:41:07 -0000 Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, = Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, = DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most = targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Feb 29 04:49:42 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32A1DAB8588 for ; Mon, 29 Feb 2016 04:49:42 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-155.reflexion.net [208.70.211.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E7991126C for ; Mon, 29 Feb 2016 04:49:41 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 31363 invoked from network); 29 Feb 2016 04:49:57 -0000 Received: from unknown (HELO mail-cs-01.app.dca.reflexion.local) (10.81.19.1) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 04:49:57 -0000 Received: by mail-cs-01.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Sun, 28 Feb 2016 23:49:53 -0500 (EST) Received: (qmail 16577 invoked from network); 29 Feb 2016 04:49:53 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 04:49:53 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 1E0D0B1E001; Sun, 28 Feb 2016 20:49:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> Date: Sun, 28 Feb 2016 20:49:38 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 04:49:42 -0000 Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Feb 29 06:14:00 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 50182AB8169 for ; Mon, 29 Feb 2016 06:14:00 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-154.reflexion.net [208.70.211.154]) (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 14AD31E5E for ; Mon, 29 Feb 2016 06:13:59 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 24033 invoked from network); 29 Feb 2016 06:13:58 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 06:13:58 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 29 Feb 2016 01:13:51 -0500 (EST) Received: (qmail 31036 invoked from network); 29 Feb 2016 06:13:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 06:13:50 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id E470DB1E001; Sun, 28 Feb 2016 22:13:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> Date: Sun, 28 Feb 2016 22:13:56 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 06:14:00 -0000 Back to the "case Builtin::BI__builtin_dwarf_cfa" and = "PPCTargetLowering::LowerFRAMEADDR" context: I made the wrong change and need to retry. The detail. . . Passing a 1 through instead of zero did not do what I expected to the = code generated. Instead it added one instruction: addi r3,r3,1 resulting in (objdump -d --prefix-addresses on the .o): > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> addi r3,r3,1 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> addi r1,r1,16 > 00000024 <_Z1fv+0x24> lwz r0,4(r1) > 00000028 <_Z1fv+0x28> lwz r31,-4(r1) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> blr In other words: it added the 1 as a byte offset like the comments that I = thought were wrong said. Since it does not appear that PPCTargetLowering::LowerFRAMEADDR would do = that with a 1 I conclude that PPCTargetLowering::LowerFRAMEADDR is not = involved with that figure. So looking around. . . /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp = has: > case Intrinsic::eh_dwarf_cfa: { > SDValue CfaArg =3D = DAG.getSExtOrTrunc(getValue(I.getArgOperand(0)), sdl, > = TLI.getPointerTy(DAG.getDataLayout())); > SDValue Offset =3D DAG.getNode(ISD::ADD, sdl, > CfaArg.getValueType(), > = DAG.getNode(ISD::FRAME_TO_ARGS_OFFSET, sdl, > CfaArg.getValueType()), > CfaArg); > SDValue FA =3D DAG.getNode( > ISD::FRAMEADDR, sdl, TLI.getPointerTy(DAG.getDataLayout()), > DAG.getConstant(0, sdl, = TLI.getPointerTy(DAG.getDataLayout()))); > setValue(&I, DAG.getNode(ISD::ADD, sdl, FA.getValueType(), > FA, Offset)); > return nullptr; And so sure enough the argument is an offset as used by this code. And what I call the frame depth is plugged in as 0 here via = "DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))". The = offset is applied after getting the frame address. So I get to revert my change and try again changing the above call to = use a 1 instead. It does not look like this changes the time frames in my history notes: = it has been using frame depth zero since V2.7 when "case = Builtin::BI__builtin_dwarf_cfa" appeared. In general my overall questions about the target triple controlling = which value to use (in DAG.getConstant hrere) still apply: It is not = obvious that something that has been using frame depth 0 since V2.7 can = be immediately changed to frame depth 1 for all contexts. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 8:49 PM, Mark Millard wrote: Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, = false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Feb 29 06:29:43 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 591D8AB8543 for ; Mon, 29 Feb 2016 06:29:43 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2E21D3BB for ; Mon, 29 Feb 2016 06:29:43 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-pf0-x232.google.com with SMTP id 124so25177225pfg.0 for ; Sun, 28 Feb 2016 22:29:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:content-transfer-encoding:message-id:date:subject:from :in-reply-to:references:to; bh=DTfcJB6HDff6DAOoyONitNAVfe1ZkKPFQZh7WUdib6g=; b=VLbVVEC3m1gfoSnsqaOaXkxLKef1MWm9CrDowv7TE7SCLXvr8hJGIx+h9EQ7T6S3gm +Ak00Ygyy0xw8HXi/XpkbClCt3VrxNPn8YQ6c9MLviEO0EnBrFQNHLNp/LhRLcbAYsYZ zzwyVVS+tLK0vVcAjG/hmjFNBSHpBljUhjH7jILFfnZlNvo8BjTFwz55PvkiDQh2YbCx rcOsZgY5aOfCjol+JmW6FRWsmP6QqKxallaBrKUM39RtPYaGNStjR98ar/7MH2PpA9Wu HjYuIniEnia0eDolRmvq22c8GC6pS/Bz8h3s96d5V6Wwr1o7mkSCctG+sRgDY0jhvTcG vWFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:content-transfer-encoding :message-id:date:subject:from:in-reply-to:references:to; bh=DTfcJB6HDff6DAOoyONitNAVfe1ZkKPFQZh7WUdib6g=; b=jwYyIETvkzP9pJQhjCm5rekuh0KrMa29eYdsjOIV3PEVUWUBxt9zpfNt8X6f1EN40c lrWsGUzR5xqwPUejkKiHycz8GDHyeDwe2uZm/0iaTMe+2EI2NvPMJTUxsqXgNFNbzxNw Mi8CFHIh21JyoWkpI4/VMXYjlZgSaRXisEjavSUC9iKNzQtxLBtZvmPFCZrEq9/RUhW9 RYAarKC3UQQy3FOs8KC1BazcO/ljXg8PxlXOeCBiTPmabJZju5TOnsZQnjS8E5nvdGqR uzxa1pNNUNIBtXl5m9CRRt33yIy8kEsFFm/ZHxLRZHxzpOxnakW7x8YwJyBq23SpSkLf ZcZQ== X-Gm-Message-State: AD7BkJJJXig7yQhQIlaYPzE5FEAL/MlvGpNtnpK1DhPHW7z+NzZGT4I91296m9RZ2RDSBw== X-Received: by 10.98.7.14 with SMTP id b14mr20124922pfd.40.1456727382689; Sun, 28 Feb 2016 22:29:42 -0800 (PST) Received: from [127.0.0.1] ([216.113.200.184]) by smtp.gmail.com with ESMTPSA id x1sm35013608pfi.42.2016.02.28.22.29.41 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 28 Feb 2016 22:29:41 -0800 (PST) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Mailer: BlackBerry Email (10.3.2.2876) Message-ID: <20160229062941.4374611.32643.3487@gmail.com> Date: Sun, 28 Feb 2016 22:29:41 -0800 Subject: Re: FreeBSD on Utilite (revisited) From: Russell Haley In-Reply-To: <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> To: =?utf-8?q?Martin_Waschb=C3=BCsch?= , freebsd-arm@freebsd.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 06:29:43 -0000 It seems compulab's imx6 som is called the CM-FX6. There are some imx6-cm-f= x6 and imx6q-cm-fx6 files in their linux kernel on github? =E2=80=8Ehttps://github.com/utilite-computer/linux-kernel/tree/utilite/deve= l/arch/arm/boot/dts Russ Sent=C2=A0from=C2=A0my=C2=A0BlackBerry=C2=A010=C2=A0smartphone=C2=A0on=C2= =A0the=C2=A0Koodo=C2=A0network. =C2=A0 Original Message =C2=A0 From: Martin Waschb=C3=BCsch Sent: Sunday, February 28, 2016 10:38 AM To: freebsd-arm@freebsd.org Subject: Re: FreeBSD on Utilite (revisited) > Am 27.02.2016 um 17:15 schrieb Martin Waschb=C3=BCsch : >=20 > What I do know: The device has both, mmc and mSATA. Which does disk0 refe= r to? > Also, I tried playing around with u-boot env $loaderdev, but to no avail. >=20 > Any and all help is appreciated! Update: While ubldr does not seem to be able to recognize the mmc devices, it does = work with usb, so I got as far as loader, but am now stuck with with findin= g, adapting or creating the right .dts file for fdt. I am a little confused about the kernel sources having dts stuff both in /u= sr/src/sys/gnu/dts/ as well as /usr/src/sys/boot/fdt/dts/. But anyway, at l= east making a little progress... Martin _______________________________________________ freebsd-arm@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-arm To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Feb 29 07:18:18 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22FBEAB794A for ; Mon, 29 Feb 2016 07:18:18 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: from relay.waschbuesch.it (relay.waschbuesch.it [IPv6:2a00:cba0:0:100::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DE2791519 for ; Mon, 29 Feb 2016 07:18:17 +0000 (UTC) (envelope-from martin@waschbuesch.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type; bh=4Minrp+bHUWo4p56pNOnY8/feqVbCs5CaJbykSIdMng=; b=DgL49AZAbDMO tXTYQVIOWvXjVACA9S3kQ9n4zLj8AKj1bkH/m0xOyqE4F7Pt5QN3z08lAQ1DEYff0dPV7gReEbecx ev/3qU/1t7nEEoza/ZEtb3X5o3zob0VOee85tXllXWmGHE6GKVFKBB9miXiET0oBMwMCCFrxgIwWn PBKD8=; Received: by relay.waschbuesch.it with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim) (envelope-from ) id 1aaI5r-000DUj-RZ; Mon, 29 Feb 2016 07:18:11 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FreeBSD on Utilite (revisited) From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= In-Reply-To: <20160229062941.4374611.32643.3487@gmail.com> Date: Mon, 29 Feb 2016 08:18:11 +0100 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> <20160229062941.4374611.32643.3487@gmail.com> To: Russell Haley X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 07:18:18 -0000 > Am 29.02.2016 um 07:29 schrieb Russell Haley : >=20 > It seems compulab's imx6 som is called the CM-FX6. There are some = imx6-cm-fx6 and imx6q-cm-fx6 files in their linux kernel on github? >=20 > = =E2=80=8Ehttps://github.com/utilite-computer/linux-kernel/tree/utilite/dev= el/arch/arm/boot/dts Thank you, Russ. There already is a dts file for the cm-fx6 in the FreeBSD kernel sources for instance /usr/src/sys/gnu/dts/arm/imx6q-cm-fx6.dts However, the same is true for the Wandboard /usr/src/sys/gnu/dts/arm/imx6qdl-wandboard.dtsi and yet, Crochet uses the files found under /usr/src/sys/boot/fdt/dts/arm/ So, I went with the wandboard-quad.dts file from there, seeing as it = should be quite similar to my Utilite Pro. So far, no luck. Once the loader slurps in the compiled .dtb, the system = hangs with no further sign of activity. Martin From owner-freebsd-arm@freebsd.org Mon Feb 29 07:49:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CCE71AB6A3E for ; Mon, 29 Feb 2016 07:49:52 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from id.bluezbox.com (id.bluezbox.com [45.55.20.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AFA5E7A3 for ; Mon, 29 Feb 2016 07:49:52 +0000 (UTC) (envelope-from gonzo@id.bluezbox.com) Received: from [76.102.118.237] (helo=[10.0.1.7]) by id.bluezbox.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aaIaN-000Amb-Iw; Sun, 28 Feb 2016 23:49:44 -0800 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FreeBSD on Utilite (revisited) From: Oleksandr Tymoshenko In-Reply-To: Date: Sun, 28 Feb 2016 23:49:43 -0800 Cc: Russell Haley , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> <20160229062941.4374611.32643.3487@gmail.com> To: =?utf-8?Q?Martin_Waschb=C3=BCsch?= X-Mailer: Apple Mail (2.3112) Sender: gonzo@id.bluezbox.com X-Spam-Level: -- X-Spam-Report: Spam detection software, running on the system "id.bluezbox.com", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: > On Feb 28, 2016, at 11:18 PM, Martin Waschbüsch wrote: > > >> Am 29.02.2016 um 07:29 schrieb Russell Haley : >> >> It seems compulab's imx6 som is called the CM-FX6. There are some imx6-cm-fx6 and imx6q-cm-fx6 files in their linux kernel on github? >> >> ‎https://github.com/utilite-computer/linux-kernel/tree/utilite/devel/arch/arm/boot/dts > > Thank you, Russ. > > There already is a dts file for the cm-fx6 in the FreeBSD kernel sources > for instance /usr/src/sys/gnu/dts/arm/imx6q-cm-fx6.dts > > However, the same is true for the Wandboard > /usr/src/sys/gnu/dts/arm/imx6qdl-wandboard.dtsi > and yet, Crochet uses the files found under > /usr/src/sys/boot/fdt/dts/arm/ [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level mail domains are different 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: github.com] -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 07:49:52 -0000 > On Feb 28, 2016, at 11:18 PM, Martin Waschb=C3=BCsch = wrote: >=20 >=20 >> Am 29.02.2016 um 07:29 schrieb Russell Haley : >>=20 >> It seems compulab's imx6 som is called the CM-FX6. There are some = imx6-cm-fx6 and imx6q-cm-fx6 files in their linux kernel on github? >>=20 >> = =E2=80=8Ehttps://github.com/utilite-computer/linux-kernel/tree/utilite/dev= el/arch/arm/boot/dts >=20 > Thank you, Russ. >=20 > There already is a dts file for the cm-fx6 in the FreeBSD kernel = sources > for instance /usr/src/sys/gnu/dts/arm/imx6q-cm-fx6.dts >=20 > However, the same is true for the Wandboard > /usr/src/sys/gnu/dts/arm/imx6qdl-wandboard.dtsi > and yet, Crochet uses the files found under > /usr/src/sys/boot/fdt/dts/arm/ In early days of FDT support number of supported ARM boards was really small and people tended to write their own DTS files from the scratch, instead of using ones from Linux due to licensing concerns. These DTS files were placed to boot/dts/fdt. As number of supported hardware grew it became clear that this practice is a dead end, we can't keep up with changes provided by vendors. So after some research it was concluded that we can bring DTS files from Linux. I don't remember exact reasoning but the gist of it: they're not code, they're set=20 of facts about hardware. "Upstream" files were placed to gnu/dts. Some of the files in boot/dts/fdt are just wrappers around vendor-provided dts/dtsi files, fixing Linux-specific=20 idiosyncrasies or adding new nodes. for instances, there is no PRUSS node in Linux DTS for beaglebone, but=20 boot/fdt/dts/arm/beaglebone-common.dtsi adds it. You should be able to use .dts file in either directory, build system checks boot/fdt first and then gnu/ AFAIR.=20 >=20 > So, I went with the wandboard-quad.dts file from there, seeing as it = should be quite similar to my Utilite Pro. > So far, no luck. Once the loader slurps in the compiled .dtb, the = system hangs with no further sign of activity. Check stdout/stderr settings in =E2=80=9Cchosen=E2=80=9D node. Looks = like imx6q-cm-fx6.dts uses UART4 for serial output while Wandboard=20 quad uses UART0.= From owner-freebsd-arm@freebsd.org Mon Feb 29 08:49:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33E59AB15DC for ; Mon, 29 Feb 2016 08:49:14 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 15CE71E75; Mon, 29 Feb 2016 08:49:14 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 62D7A238; Mon, 29 Feb 2016 08:49:13 +0000 (UTC) Date: Mon, 29 Feb 2016 08:49:09 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: sgalabov@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1065824219.163.1456735751695.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2480 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 08:49:14 -0000 FreeBSD_HEAD_arm64 - Build #2480 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2480/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2480/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2480/console Change summaries: 296183 by sgalabov: This review aims at introducing ubldr (loader with U-Boot interface) for MIPS (32 and 64-bit, LE and BE). The changes were tested with QEMU's 'mips' target. Most of the implementation was lifted from the ARM version, the appropriate MIPS-specific things were implemented. With these changes I am able to go all the way through the u-boot->ubldr->kernel boot chain in QEMU on all combinations of bit-ness and endian-ness. For the tests I've used FAT32 disk images (as FAT32 is supported by U-boot), which include /boot/kernel/kernel and /boot/kernel/ubldr.bin In U-boot I do: fatload ide 0 /boot/kernel/ubldr.bin; go where LOAD_ADDR is 80800000 for 32-bit and ffffffff80800000 for 64-bit Then it's the usual ubldr that takes over and loads and starts a kernel. Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5313 296182 by sgalabov: These changes attempt to put things in order before the introduction of MIPS ubldr. The changes are mostly dealing with removing unnecessary casts from the U-Boot API (we're passing only pointers, no obvious reason to cast them to uint32_t), cleaning up some compiler warnings and using the proper printf format specifiers in order to be able to compile cleanly for both 32-bit and 64-bit MIPS targets. Reviewed by: imp Approved by: adrian (mentor) Sponsored by: Smartcom - Bulgaria AD Differential Revision: https://reviews.freebsd.org/D5312 The end of the build log: [...truncated 114271 lines...] cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/aarch64 -I/usr/src/sys/boot/ficl/../common -c /usr/src/sys/boot/ficl/aarch64/sysdep.c -o sysdep.o --- all_subdir_secure --- --- evp_acnf.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_acnf.c -o evp_acnf.po --- all_subdir_share --- --- kk_Cyrl_KZ.UTF-8.LC_COLLATE --- localedef -D -U -i /usr/src/share/colldef/kk_Cyrl_KZ.UTF-8.src -f /usr/src/share/colldef/../../tools/tools/locale/etc/final-maps/map.UTF-8 /usr/obj/arm64.aarch64/usr/src/share/colldef/kk_Cyrl_KZ.UTF-8 --- all_subdir_sys --- --- softcore.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/aarch64 -I/usr/src/sys/boot/ficl/../common -c softcore.c -o softcore.o --- libficl.a --- --- all_subdir_secure --- --- evp_cnf.po --- --- all_subdir_sys --- building static ficl library --- all_subdir_secure --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_cnf.c -o evp_cnf.po --- all_subdir_sys --- /usr/local/aarch64-freebsd/bin/ar -crD libficl.a `NM='/usr/local/aarch64-freebsd/bin/nm' NMFLAGS='' lorder dict.o ficl.o fileaccess.o float.o loader.o math64.o prefix.o search.o stack.o tools.o vm.o words.o sysdep.o softcore.o | tsort -q` /usr/local/aarch64-freebsd/bin/ranlib -D libficl.a ===> sys/boot/forth (all) --- beastie.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/beastie.4th.8 > beastie.4th.8.gz --- brand.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/brand.4th.8 > brand.4th.8.gz --- check-password.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/check-password.4th.8 > check-password.4th.8.gz --- color.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/color.4th.8 > color.4th.8.gz --- delay.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/delay.4th.8 > delay.4th.8.gz --- loader.conf.5.gz --- gzip -cn /usr/src/sys/boot/forth/loader.conf.5 > loader.conf.5.gz --- loader.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/loader.4th.8 > loader.4th.8.gz --- menu.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/menu.4th.8 > menu.4th.8.gz --- menusets.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/menusets.4th.8 > menusets.4th.8.gz --- version.4th.8.gz --- gzip -cn /usr/src/sys/boot/forth/version.4th.8 > version.4th.8.gz ===> sys/boot/common (all) --- loader.8.gz --- gzip -cn /usr/src/sys/boot/common/loader.8 > loader.8.gz --- zfsloader.8.gz --- gzip -cn /usr/src/sys/boot/common/zfsloader.8 > zfsloader.8.gz --- all_subdir_secure --- --- evp_enc.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_enc.c -o evp_enc.po --- all_subdir_sys --- ===> sys/boot/fdt (all) --- fdt.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/../../contrib/libfdt//fdt.c -o fdt.o --- fdt_ro.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/../../contrib/libfdt//fdt_ro.c -o fdt_ro.o --- all_subdir_secure --- --- evp_err.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_err.c -o evp_err.po --- all_subdir_sys --- --- fdt_wip.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/../../contrib/libfdt//fdt_wip.c -o fdt_wip.o --- fdt_sw.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/../../contrib/libfdt//fdt_sw.c -o fdt_sw.o --- all_subdir_secure --- --- evp_key.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_key.c -o evp_key.po --- all_subdir_sys --- --- fdt_rw.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/../../contrib/libfdt//fdt_rw.c -o fdt_rw.o --- all_subdir_secure --- --- evp_lib.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_lib.c -o evp_lib.po --- all_subdir_sys --- --- fdt_strerror.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/../../contrib/libfdt//fdt_strerror.c -o fdt_strerror.o --- fdt_empty_tree.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/../../contrib/libfdt//fdt_empty_tree.c -o fdt_empty_tree.o --- fdt_loader_cmd.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -I/usr/src/sys/boot/fdt/../../contrib/libfdt/ -I/usr/src/sys/boot/fdt/../common/ -ffreestanding -Wformat -Wall -ffreestanding -Wformat -msoft-float -D_STANDALONE -mgeneral-regs-only -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/fdt/fdt_loader_cmd.c -o fdt_loader_cmd.o --- all_subdir_secure --- --- evp_pbe.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_pbe.c -o evp_pbe.po --- all_subdir_share --- --- ko_KR.UTF-8.LC_COLLATE --- localedef -D -U -i /usr/src/share/colldef/ko_KR.UTF-8.src -f /usr/src/share/colldef/../../tools/tools/locale/etc/final-maps/map.UTF-8 /usr/obj/arm64.aarch64/usr/src/share/colldef/ko_KR.UTF-8 --- all_subdir_secure --- --- evp_pkey.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/evp_pkey.c -o evp_pkey.po --- all_subdir_sys --- --- libfdt.a --- building static fdt library /usr/local/aarch64-freebsd/bin/ar -crD libfdt.a `NM='/usr/local/aarch64-freebsd/bin/nm' NMFLAGS='' lorder fdt.o fdt_ro.o fdt_wip.o fdt_sw.o fdt_rw.o fdt_strerror.o fdt_empty_tree.o fdt_loader_cmd.o | tsort -q` /usr/local/aarch64-freebsd/bin/ranlib -D libfdt.a ===> sys/boot/efi (all) --- all --- ===> sys/boot/efi/fdt (all) --- all_subdir_secure --- --- m_dss.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/m_dss.c -o m_dss.po --- all_subdir_sys --- --- efi_fdt.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -ffreestanding -msoft-float -mgeneral-regs-only -I/usr/src/sys/boot/efi/fdt/../../../../lib/libstand/ -I/usr/src/sys/boot/efi/fdt/../include -I/usr/src/sys/boot/efi/fdt/../include/arm64 -I/usr/src/sys/boot/efi/fdt/../../fdt -I/usr/src/sys/boot/efi/fdt/../../common -I/usr/src/sys/boot/efi/fdt/../../.. -I. -ffreestanding -Wformat -msoft-float -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -c /usr/src/sys/boot/efi/fdt/efi_fdt.c -o efi_fdt.o --- libefi_fdt.a --- building static efi_fdt library /usr/local/aarch64-freebsd/bin/ar -crD libefi_fdt.a `NM='/usr/local/aarch64-freebsd/bin/nm' NMFLAGS='' lorder efi_fdt.o | tsort -q` /usr/local/aarch64-freebsd/bin/ranlib -D libefi_fdt.a ===> sys/boot/efi/libefi (all) --- all_subdir_secure --- --- m_dss1.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/m_dss1.c -o m_dss1.po --- all_subdir_sys --- --- delay.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -msoft-float -mgeneral-regs-only -I/usr/src/sys/boot/efi/libefi/../include -I/usr/src/sys/boot/efi/libefi/../include/arm64 -I/usr/src/sys/boot/efi/libefi/../../../../lib/libstand -I/usr/src/sys/boot/efi/libefi/../../common -D__printf__=__freebsd_kprintf__ -DTERM_EMU -ffreestanding -Wformat -msoft-float -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/sys/boot/efi/libefi/delay.c -o delay.o --- efi_console.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -msoft-float -mgeneral-regs-only -I/usr/src/sys/boot/efi/libefi/../include -I/usr/src/sys/boot/efi/libefi/../include/arm64 -I/usr/src/sys/boot/efi/libefi/../../../../lib/libstand -I/usr/src/sys/boot/efi/libefi/../../common -D__printf__=__freebsd_kprintf__ -DTERM_EMU -ffreestanding -Wformat -msoft-float -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/sys/boot/efi/libefi/efi_console.c -o efi_console.o --- all_subdir_secure --- --- m_ecdsa.po --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/m_ecdsa.c -o m_ecdsa.po --- all_subdir_sys --- --- efinet.o --- --- all_subdir_secure --- --- m_md4.po --- --- all_subdir_sys --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -msoft-float -mgeneral-regs-only -I/usr/src/sys/boot/efi/libefi/../include -I/usr/src/sys/boot/efi/libefi/../include/arm64 -I/usr/src/sys/boot/efi/libefi/../../../../lib/libstand -I/usr/src/sys/boot/efi/libefi/../../common -D__printf__=__freebsd_kprintf__ -DTERM_EMU -ffreestanding -Wformat -msoft-float -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /usr/src/sys/boot/efi/libefi/efinet.c -o efinet.o --- all_subdir_secure --- cc -B/usr/local/aarch64-freebsd/bin/ -pg -O2 -pipe -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -DTERMIOS -DANSI_SOURCE -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -I/usr/obj/arm64.aarch64/usr/src/secure/lib/libcrypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/modes -std=gnu89 -fstack-protector-strong -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp/m_md4.c -o m_md4.po --- all_subdir_sys --- In file included from /usr/src/sys/boot/efi/libefi/efinet.c:39: /usr/src/sys/boot/efi/libefi/../../common/dev_net.c:114:7: error: unused variable 'temp' [-Werror,-Wunused-variable] char temp[FNAME_SIZE]; ^ 1 error generated. *** [efinet.o] Error code 1 make[6]: stopped in /usr/src/sys/boot/efi/libefi 1 error make[6]: stopped in /usr/src/sys/boot/efi/libefi *** [all] Error code 2 make[5]: stopped in /usr/src/sys/boot/efi 1 error make[5]: stopped in /usr/src/sys/boot/efi *** [all] Error code 2 make[4]: stopped in /usr/src/sys/boot 1 error make[4]: stopped in /usr/src/sys/boot *** [all] Error code 2 make[3]: stopped in /usr/src/sys 1 error make[3]: stopped in /usr/src/sys *** [all_subdir_sys] Error code 2 make[2]: stopped in /usr/src --- all_subdir_secure --- A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/secure/lib/libcrypto *** [all] Error code 2 make[4]: stopped in /usr/src/secure/lib 1 error make[4]: stopped in /usr/src/secure/lib *** [all_subdir_secure/lib] Error code 2 make[3]: stopped in /usr/src/secure 1 error make[3]: stopped in /usr/src/secure *** [all_subdir_secure] Error code 2 make[2]: stopped in /usr/src --- all_subdir_share --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/share/colldef *** [all_subdir_share/colldef] Error code 2 make[3]: stopped in /usr/src/share 1 error make[3]: stopped in /usr/src/share *** [all_subdir_share] Error code 2 make[2]: stopped in /usr/src --- all_subdir_lib --- --- nv_array_tests --- A failure has been detected in another branch of the parallel make make[6]: stopped in /usr/src/lib/libnv/tests *** [nv_array_tests] Error code 2 make[5]: stopped in /usr/src/lib/libnv/tests 1 error make[5]: stopped in /usr/src/lib/libnv/tests *** [all] Error code 2 make[4]: stopped in /usr/src/lib/libnv 1 error make[4]: stopped in /usr/src/lib/libnv *** [all_subdir_lib/libnv] Error code 2 make[3]: stopped in /usr/src/lib 1 error make[3]: stopped in /usr/src/lib *** [all_subdir_lib] Error code 2 make[2]: stopped in /usr/src 4 errors make[2]: stopped in /usr/src *** [everything] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildworld] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson7627354255028544984.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Mon Feb 29 11:00:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3CCDAB89E5 for ; Mon, 29 Feb 2016 11:00:23 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id B5EA31F00; Mon, 29 Feb 2016 11:00:23 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 1EDD4278; Mon, 29 Feb 2016 11:00:22 +0000 (UTC) Date: Mon, 29 Feb 2016 11:00:18 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: sephe@FreeBSD.org, sgalabov@FreeBSD.org, wma@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1263107910.165.1456743621641.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1065824219.163.1456735751695.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1065824219.163.1456735751695.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2481 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 11:00:23 -0000 FreeBSD_HEAD_arm64 - Build #2481 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2481/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2481/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2481/console Change summaries: 296189 by wma: Fix fdt_get_mem_regions() to work with 64-bit addresses Use u_long instead of uint32_t variables to avoid overflow in case of PA space bigger than 32-bit. Obtained from: Semihalf Submitted by: Michal Stanek Sponsored by: Annapurna Labs Approved by: cognet (mentor) Reviewed by: andrew, br, wma Differential revision: https://reviews.freebsd.org/D5393 296188 by sephe: hyperv/channel: Add sysctl node for channel owner cpu And add sysctl node for sub-channel's channel id. MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5489 296187 by sephe: hyperv/hn: Utilize mbuf flowid MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5488 296186 by sgalabov: Fix build failure introduced by r296182 Approved by: adrian (mentor) 296185 by sephe: hyperv/hn: Put LRO aggregation limit settings under FreeBSD version check This simplifies MFC to 10-stable MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5487 296184 by sephe: hyperv/hn: Switch to if_transmit by default after r296178 MFC after: 1 week Sponsored by: Microsoft OSTC Differential Revision: https://reviews.freebsd.org/D5485 From owner-freebsd-arm@freebsd.org Mon Feb 29 11:20:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EABD2AB826B for ; Mon, 29 Feb 2016 11:20:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AA7CFC2A for ; Mon, 29 Feb 2016 11:20:51 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22445 invoked from network); 29 Feb 2016 11:21:07 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 11:21:07 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Mon, 29 Feb 2016 06:20:43 -0500 (EST) Received: (qmail 22058 invoked from network); 29 Feb 2016 11:20:43 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 29 Feb 2016 11:20:43 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 51895B1E001; Mon, 29 Feb 2016 03:20:48 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> Date: Mon, 29 Feb 2016 03:20:48 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 11:20:52 -0000 TARGET_ARCH=3Dpowerpc: Using Frame Depth 1 in "case = Intrinsic::eh_dwarf_cfa" (and Offset 0 in "case = Builtin::BI__builtin_dwarf_cfa") for PPCTargetLowering::LowerFRAMEADDR = related use has allowed getting into _Unwind_RaiseException_Phase2 and = __cxxabiv1::__gxx_personality_v0. The example is the 8 line example = compiled under g++ 4.2.1 but then used under a buildworld that was built = with clang 3.8.0: # ldd exception_test.g++421.powerpc=20 exception_test.g++421.powerpc: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x41840000) libm.so.5 =3D> /lib/libm.so.5 (0x4196a000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x419a1000) libc.so.7 =3D> /lib/libc.so.7 (0x419c0000) _Unwind_RaiseException_Phase2 is well past the point of the failure and = crash from having Frame Depth 0 instead. It is getting a SEGV during the _Unwind_SetGR called via: 710 /* For targets with pointers smaller than the word size, we = must extend the 711 pointer, and this extension is target dependent. */ 712 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), 713 __builtin_extend_pointer (ue_header)); for: _Unwind_SetGR (context=3D0xffffd570, index=3D3, val=3D1105272896) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 context->reg[3] is 0x0 and so its use in the following gets the SEGV. 217 ptr =3D context->reg[index]; 218=09 219 if (size =3D=3D sizeof(_Unwind_Ptr)) 220 * (_Unwind_Ptr *) ptr =3D val; I'm not going to try to analyze the source of this before getting some = sleep. For the 8 line program being compiled by clang++ 3.8.0 instead the = results are different than the above and than the original behavior: The = program does not crash abnormally but also does not find the catch = clause that it should. The std::terminate gets its normal SIGABRT = instead of an earlier SEGV. Again I'm not going to try to analyze the details before getting some = sleep. But I will mention that I've also already submitted a report that = libgcc_s does not completely implement DW_CFA_remember_state and = DW_CFA_restore_state and that the code generated on powerpc64 touches = the defect and so ends up with misbehavior. These might be similar. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 10:13 PM, Mark Millard = wrote: Back to the "case Builtin::BI__builtin_dwarf_cfa" and = "PPCTargetLowering::LowerFRAMEADDR" context: I made the wrong change and need to retry. The detail. . . Passing a 1 through instead of zero did not do what I expected to the = code generated. Instead it added one instruction: addi r3,r3,1 resulting in (objdump -d --prefix-addresses on the .o): > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> addi r3,r3,1 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> addi r1,r1,16 > 00000024 <_Z1fv+0x24> lwz r0,4(r1) > 00000028 <_Z1fv+0x28> lwz r31,-4(r1) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> blr In other words: it added the 1 as a byte offset like the comments that I = thought were wrong said. Since it does not appear that PPCTargetLowering::LowerFRAMEADDR would do = that with a 1 I conclude that PPCTargetLowering::LowerFRAMEADDR is not = involved with that figure. So looking around. . . /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp = has: > case Intrinsic::eh_dwarf_cfa: { > SDValue CfaArg =3D DAG.getSExtOrTrunc(getValue(I.getArgOperand(0)), = sdl, > = TLI.getPointerTy(DAG.getDataLayout())); > SDValue Offset =3D DAG.getNode(ISD::ADD, sdl, > CfaArg.getValueType(), > DAG.getNode(ISD::FRAME_TO_ARGS_OFFSET, = sdl, > CfaArg.getValueType()), > CfaArg); > SDValue FA =3D DAG.getNode( > ISD::FRAMEADDR, sdl, TLI.getPointerTy(DAG.getDataLayout()), > DAG.getConstant(0, sdl, = TLI.getPointerTy(DAG.getDataLayout()))); > setValue(&I, DAG.getNode(ISD::ADD, sdl, FA.getValueType(), > FA, Offset)); > return nullptr; And so sure enough the argument is an offset as used by this code. And what I call the frame depth is plugged in as 0 here via = "DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))". The = offset is applied after getting the frame address. So I get to revert my change and try again changing the above call to = use a 1 instead. It does not look like this changes the time frames in my history notes: = it has been using frame depth zero since V2.7 when "case = Builtin::BI__builtin_dwarf_cfa" appeared. In general my overall questions about the target triple controlling = which value to use (in DAG.getConstant hrere) still apply: It is not = obvious that something that has been using frame depth 0 since V2.7 can = be immediately changed to frame depth 1 for all contexts. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 8:49 PM, Mark Millard wrote: Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Mon Feb 29 20:14:29 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E344FAB91FB for ; Mon, 29 Feb 2016 20:14:29 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm50-vm6.bullet.mail.bf1.yahoo.com (nm50-vm6.bullet.mail.bf1.yahoo.com [216.109.115.237]) (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 A21FA19B2 for ; Mon, 29 Feb 2016 20:14:29 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456776698; bh=pEh6U591zvBD+oOLqJjyt/9iKYGQiQMvs0ODQxLKzag=; h=From:Subject:Date:References:To:In-Reply-To:From:Subject; b=aWoC9W02m3mebrzjYgBOQ253ZdE9AYOFkeRx9cWwtNLe7dI/u1Y7OXmeKlVKcogE25UQ33F8wI928pKOFSQUfQUkXslEBa+tsbnTu3d29qkMC6OF19Y0shoa3/VDqOdcdqnZJ6cRjAvdbhMMpgDFbWwCXrIJK/+qTv/HbUcZNHwGSBTjtIqMaLw4v/Du3gUZHWUrbu1XASAW/vAWXMlqGZrhZd86y/vTSUYl2bj7iAYNUiMNiR7Mf6jGkzHV+UfaOtmcBvJ65hadqPmYv4elqvH+w2W87zIlTH7bPP4gY2zhzBHQC1racUCsY3fXXuSx04fTSkmBYh4mXtulvgcdSA== Received: from [66.196.81.173] by nm50.bullet.mail.bf1.yahoo.com with NNFMP; 29 Feb 2016 20:11:38 -0000 Received: from [98.139.211.193] by tm19.bullet.mail.bf1.yahoo.com with NNFMP; 29 Feb 2016 20:11:38 -0000 Received: from [127.0.0.1] by smtp202.mail.bf1.yahoo.com with NNFMP; 29 Feb 2016 20:11:38 -0000 X-Yahoo-Newman-Id: 64579.70030.bm@smtp202.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Hs2VWJQVM1nFFvRBFMJ7q7G7t1tQM.s1xScuJO.x90BfvbT WLKRzfXrYQRBEhjIjZCE3fGqjZ7zl7rlZ8.oR4McT2Cz6bmZAquaFBf5BG6V fa34NFV6uypfD.C4B1NWvies49AAT_P9ZHOsBQIDmS6h5auuUYde8a4XmPiW eEyzavZzRsBbSauCV5svDxfhZYUNGJqYOmdtuJ1cJj6AMDuIia0wA9tIaLNh QozIOP5DU0K_Qce1CC.FxuXa6PeQ7TLjDN3bV4afL7L4YB_RbI88EyV2Ed.n 4mzKsYtV8hnJKKfeBKB.TYEEjzMnMhJZa4_jqb62odgQupb9XPztxI2lAp_X Nu5l_yF2mKq9rvgfWXzgEpD.HGtKrrn.9ZsVoWyxdjm3tytPNI0CEPqSW.mN ZZMLBc12AZaHG0AOlB_g12tSHc1QslU6sVL94VzXEznhTPGp7HPUseFzTS0_ 4YXzZ2iX5LjSL.NiRb8WLHHyz3H84Tvrx.6FSOCy6OEM3NQUWhgn6rzz2uU6 3d29y6_31NAYG6K.MUAULUBy19qo35SjhvS3zI6AU9LRcT01r X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV From: Thomas Skibo Content-Type: multipart/mixed; boundary="Apple-Mail=_7BB33126-1C35-48DD-AE65-BC1CF00904CF" Message-Id: <0E2B7566-8E95-4570-AD00-353A9392E6D8@yahoo.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: u-boot and ubldr on arm64 Date: Mon, 29 Feb 2016 12:11:35 -0800 References: <5A031837-F7D6-467F-A6B7-35B1F0A467D9@yahoo.com> To: freebsd-arm@freebsd.org In-Reply-To: X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 20:14:30 -0000 --Apple-Mail=_7BB33126-1C35-48DD-AE65-BC1CF00904CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I feel like I dropped the ball on this one. Should I put these changes = up on phabricator? Can I do that without being a committer? The = Raspberry Pi 3 will need this I think.=20 I=E2=80=99ve attached a cleaned-up diff. =E2=80=94 Thomas Skibo thomasskibo@yahoo.com --Apple-Mail=_7BB33126-1C35-48DD-AE65-BC1CF00904CF Content-Disposition: attachment; filename=ubldr_arm64.txt Content-Type: text/plain; name="ubldr_arm64.txt" Content-Transfer-Encoding: quoted-printable Index: sys/boot/Makefile.arm64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/Makefile.arm64 b/head/sys/boot/Makefile.arm64 --- a/head/sys/boot/Makefile.arm64 (revision 295842) +++ b/head/sys/boot/Makefile.arm64 (working copy) @@ -4,4 +4,4 @@ SUBDIR+=3D fdt .endif =20 -SUBDIR+=3D efi +SUBDIR+=3D efi uboot Index: sys/boot/arm64/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/Makefile b/head/sys/boot/arm64/Makefile --- a/head/sys/boot/arm64/Makefile (revision 295842) +++ b/head/sys/boot/arm64/Makefile (working copy) @@ -1,3 +1,5 @@ # $FreeBSD$ =20 +SUBDIR=3D uboot + .include Index: sys/boot/arm64/Makefile.inc =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/Makefile.inc = b/head/sys/boot/arm64/Makefile.inc new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/Makefile.inc (working copy) @@ -0,0 +1,3 @@ +# $FreeBSD$ + +.include "../Makefile.inc" Index: sys/boot/arm64/uboot/Makefile =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/uboot/Makefile = b/head/sys/boot/arm64/uboot/Makefile new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/uboot/Makefile (working copy) @@ -0,0 +1,159 @@ +# $FreeBSD$ + +.include + +FILES=3D ubldr ubldr.bin + +NEWVERSWHAT=3D "U-Boot loader" ${MACHINE_ARCH} +BINDIR?=3D /boot +INSTALLFLAGS=3D -b +WARNS?=3D 1 +# Address at which ubldr will be loaded. +# This varies for different boards and SOCs. +UBLDR_LOADADDR?=3D 0x1000000 + +# Architecture-specific loader code +SRCS=3D start.S conf.c self_reloc.c vers.c + +.if !defined(LOADER_NO_DISK_SUPPORT) +LOADER_DISK_SUPPORT?=3D yes +.else +LOADER_DISK_SUPPORT=3D no +.endif +LOADER_UFS_SUPPORT?=3D yes +LOADER_CD9660_SUPPORT?=3D no +LOADER_EXT2FS_SUPPORT?=3D no +.if ${MK_NAND} !=3D "no" +LOADER_NANDFS_SUPPORT?=3D yes +.else +LOADER_NANDFS_SUPPORT?=3D no +.endif +LOADER_NET_SUPPORT?=3D yes +LOADER_NFS_SUPPORT?=3D yes +LOADER_TFTP_SUPPORT?=3D no +LOADER_GZIP_SUPPORT?=3D no +LOADER_BZIP2_SUPPORT?=3D no +.if ${MK_FDT} !=3D "no" +LOADER_FDT_SUPPORT=3D yes +.else +LOADER_FDT_SUPPORT=3D no +.endif + +.if ${LOADER_DISK_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_DISK_SUPPORT +.endif +.if ${LOADER_UFS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_UFS_SUPPORT +.endif +.if ${LOADER_CD9660_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_CD9660_SUPPORT +.endif +.if ${LOADER_EXT2FS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_EXT2FS_SUPPORT +.endif +.if ${LOADER_NANDFS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_NANDFS_SUPPORT +.endif +.if ${LOADER_GZIP_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_GZIP_SUPPORT +.endif +.if ${LOADER_BZIP2_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_BZIP2_SUPPORT +.endif +.if ${LOADER_NET_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_NET_SUPPORT +.endif +.if ${LOADER_NFS_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_NFS_SUPPORT +.endif +.if ${LOADER_TFTP_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -DLOADER_TFTP_SUPPORT +.endif +.if ${LOADER_FDT_SUPPORT} =3D=3D "yes" +CFLAGS+=3D -I${.CURDIR}/../../fdt +CFLAGS+=3D -I${.OBJDIR}/../../fdt +CFLAGS+=3D -DLOADER_FDT_SUPPORT +LIBUBOOT_FDT=3D ${.OBJDIR}/../../uboot/fdt/libuboot_fdt.a +LIBFDT=3D ${.OBJDIR}/../../fdt/libfdt.a +.endif + +CFLAGS+=3D -DNETIF_OPEN_CLOSE_ONCE + +.if ${MK_FORTH} !=3D "no" +# Enable BootForth +BOOT_FORTH=3D yes +CFLAGS+=3D -DBOOT_FORTH -I${.CURDIR}/../../ficl = -I${.CURDIR}/../../ficl/aarch64 +LIBFICL=3D ${.OBJDIR}/../../ficl/libficl.a +.endif + +# Always add MI sources +.PATH: ${.CURDIR}/../../common +.include "${.CURDIR}/../../common/Makefile.inc" +CFLAGS+=3D -I${.CURDIR}/../../common +CFLAGS+=3D -I. + +CLEANFILES+=3D vers.c loader.help + +CFLAGS+=3D -ffreestanding -msoft-float + +LDFLAGS=3D -nostdlib -static -T = ${.CURDIR}/ldscript.${MACHINE_CPUARCH} + +# Pull in common loader code +.PATH: ${.CURDIR}/../../uboot/common +.include "${.CURDIR}/../../uboot/common/Makefile.inc" +CFLAGS+=3D -I${.CURDIR}/../../uboot/common + +# U-Boot standalone support library +LIBUBOOT=3D ${.OBJDIR}/../../uboot/lib/libuboot.a +CFLAGS+=3D -I${.CURDIR}/../../uboot/lib +CFLAGS+=3D -I${.OBJDIR}/../../uboot/lib + +# where to get libstand from +CFLAGS+=3D -I${.CURDIR}/../../../../lib/libstand/ + +# clang doesn't understand %D as a specifier to printf +NO_WERROR.clang=3D + +DPADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} = ${LIBSTAND} +LDADD=3D ${LIBFICL} ${LIBUBOOT} ${LIBFDT} ${LIBUBOOT_FDT} = -lstand + +OBJS+=3D ${SRCS:N*.h:R:S/$/.o/g} + +vers.c: ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version + sh ${.CURDIR}/../../common/newvers.sh ${.CURDIR}/version = ${NEWVERSWHAT} + +loader.help: help.common help.uboot ${.CURDIR}/../../fdt/help.fdt + cat ${.ALLSRC} | \ + awk -f ${.CURDIR}/../../common/merge_help.awk > ${.TARGET} + +ldscript.abs: + echo "UBLDR_LOADADDR =3D ${UBLDR_LOADADDR};" >${.TARGET} + +ldscript.pie: + echo "UBLDR_LOADADDR =3D 0;" >${.TARGET} + +ubldr: ${OBJS} ldscript.abs ${.CURDIR}/ldscript.${MACHINE_CPUARCH} = ${DPADD} + ${CC} ${CFLAGS} -T ldscript.abs ${LDFLAGS} \ + -o ${.TARGET} ${OBJS} ${LDADD} + +ubldr.pie: ${OBJS} ldscript.pie ${.CURDIR}/ldscript.${MACHINE_CPUARCH} = ${DPADD} + ${CC} ${CFLAGS} -T ldscript.pie ${LDFLAGS} -pie -Wl,-Bsymbolic \ + -o ${.TARGET} ${OBJS} ${LDADD} + +ubldr.bin: ubldr.pie + ${OBJCOPY} -S -O binary ubldr.pie ${.TARGET} + +CLEANFILES+=3D ldscript.abs ldscript.pie ubldr ubldr.pie ubldr.bin + +.if !defined(LOADER_ONLY) +.PATH: ${.CURDIR}/../../forth +.include "${.CURDIR}/../../forth/Makefile.inc" + +# Install loader.rc. +FILES+=3D loader.rc +# Put sample menu.rc on disk but don't enable it by default. +FILES+=3D menu.rc +FILESNAME_menu.rc=3D menu.rc.sample +.endif + +.include Index: sys/boot/arm64/uboot/conf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/uboot/conf.c = b/head/sys/boot/arm64/uboot/conf.c new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/uboot/conf.c (working copy) @@ -0,0 +1,94 @@ +/*- + * Copyright (c) 2008 Semihalf, Rafal Jaworowski + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in = the + * documentation and/or other materials provided with the = distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, = THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR = PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE = LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE = GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, = STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN = ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY = OF + * SUCH DAMAGE. + * + */ + +#include +__FBSDID("$FreeBSD$"); + +#include +#include "bootstrap.h" +#include "libuboot.h" + +#if defined(LOADER_NET_SUPPORT) +#include "dev_net.h" +#endif + +struct devsw *devsw[] =3D { +#if defined(LOADER_DISK_SUPPORT) || defined(LOADER_CD9660_SUPPORT) + &uboot_storage, +#endif +#if defined(LOADER_NET_SUPPORT) + &netdev, +#endif + NULL +}; + +struct fs_ops *file_system[] =3D { +#if defined(LOADER_UFS_SUPPORT) + &ufs_fsops, +#endif +#if defined(LOADER_CD9660_SUPPORT) + &cd9660_fsops, +#endif +#if defined(LOADER_EXT2FS_SUPPORT) + &ext2fs_fsops, +#endif +#if defined(LOADER_NANDFS_SUPPORT) + &nandfs_fsops, +#endif +#if defined(LOADER_NFS_SUPPORT) + &nfs_fsops, +#endif +#if defined(LOADER_TFTP_SUPPORT) + &tftp_fsops, +#endif +#if defined(LOADER_GZIP_SUPPORT) + &gzipfs_fsops, +#endif +#if defined(LOADER_BZIP2_SUPPORT) + &bzipfs_fsops, +#endif + NULL +}; + +struct netif_driver *netif_drivers[] =3D { +#if defined(LOADER_NET_SUPPORT) + &uboot_net, +#endif + NULL, +}; + +struct file_format *file_formats[] =3D { + &uboot_elf, + NULL +}; + +extern struct console uboot_console; + +struct console *consoles[] =3D { + &uboot_console, + NULL +}; Index: sys/boot/arm64/uboot/help.uboot =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/uboot/help.uboot = b/head/sys/boot/arm64/uboot/help.uboot new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/uboot/help.uboot (working copy) @@ -0,0 +1,27 @@ +$FreeBSD$ + = +#########################################################################= ###### +# Tubenv DShow or import U-Boot environment variables + + ubenv [varname ...] + + Display U-Boot environment variables, or import them into the + loader environment (which makes them available in the kernel). + = +#########################################################################= ###### +# Tubenv Simport DImport U-Boot env vars + + ubenv import [varname ...] + + If no variable names are specified, all U-Boot environment + variables are imported. Each variable is prefixed with "uboot." + to avoid any possible conflicts with loader or kernel variables. + = +#########################################################################= ###### +# Tubenv Sshow DShow U-Boot env vars + + ubenv show [varname ...] + + If no variable names are specified, all U-Boot environment + variables are shown. + Index: sys/boot/arm64/uboot/ldscript.aarch64 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/uboot/ldscript.aarch64 = b/head/sys/boot/arm64/uboot/ldscript.aarch64 new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/uboot/ldscript.aarch64 (working copy) @@ -0,0 +1,133 @@ +/* $FreeBSD$ */ + +OUTPUT_ARCH(aarch64) +ENTRY(_start) +SECTIONS +{ + /* Read-only sections, merged into text segment: */ + . =3D UBLDR_LOADADDR + SIZEOF_HEADERS; + .text : + { + *(.text) + /* .gnu.warning sections are handled specially by elf32.em. */ + *(.gnu.warning) + *(.gnu.linkonce.t*) + } =3D0 + _etext =3D .; + PROVIDE (etext =3D .); + .interp : { *(.interp) } + .hash : { *(.hash) } + .dynsym : { *(.dynsym) } + .dynstr : { *(.dynstr) } + .gnu.version : { *(.gnu.version) } + .gnu.version_d : { *(.gnu.version_d) } + .gnu.version_r : { *(.gnu.version_r) } + .rela.text : + { *(.rela.text) *(.rela.gnu.linkonce.t*) } + .rela.data : + { *(.rela.data) *(.rela.gnu.linkonce.d*) } + .rela.rodata : + { *(.rela.rodata) *(.rela.gnu.linkonce.r*) } + .rela.got : { *(.rela.got) } + .rela.got1 : { *(.rela.got1) } + .rela.got2 : { *(.rela.got2) } + .rela.ctors : { *(.rela.ctors) } + .rela.dtors : { *(.rela.dtors) } + .rela.init : { *(.rela.init) } + .rela.fini : { *(.rela.fini) } + .rela.bss : { *(.rela.bss) } + .rela.plt : { *(.rela.plt) } + .rela.sdata : { *(.rela.sdata) } + .rela.sbss : { *(.rela.sbss) } + .rela.sdata2 : { *(.rela.sdata2) } + .rela.sbss2 : { *(.rela.sbss2) } + .init : { *(.init) } =3D0 + .fini : { *(.fini) } =3D0 + .rodata : { *(.rodata) *(.gnu.linkonce.r*) } + .rodata1 : { *(.rodata1) } + .sdata2 : { *(.sdata2) } + .sbss2 : { *(.sbss2) } + /* Adjust the address for the data segment to the next page up. */ + . =3D ((. + 0x1000) & ~(0x1000 - 1)); + .data : + { + *(.data) + *(.gnu.linkonce.d*) + CONSTRUCTORS + } + .data1 : { *(.data1) } + .got1 : { *(.got1) } + .dynamic : { *(.dynamic) } + /* Put .ctors and .dtors next to the .got2 section, so that the = pointers + get relocated with -mrelocatable. Also put in the .fixup pointers. + The current compiler no longer needs this, but keep it around for = 2.7.2 */ + PROVIDE (_GOT2_START_ =3D .); + .got2 : { *(.got2) } + PROVIDE (__CTOR_LIST__ =3D .); + .ctors : { *(.ctors) } + PROVIDE (__CTOR_END__ =3D .); + PROVIDE (__DTOR_LIST__ =3D .); + .dtors : { *(.dtors) } + PROVIDE (__DTOR_END__ =3D .); + PROVIDE (_FIXUP_START_ =3D .); + .fixup : { *(.fixup) } + PROVIDE (_FIXUP_END_ =3D .); + PROVIDE (_GOT2_END_ =3D .); + PROVIDE (_GOT_START_ =3D .); + .got : { *(.got) } + .got.plt : { *(.got.plt) } + PROVIDE (_GOT_END_ =3D .); + /* We want the small data sections together, so single-instruction = offsets + can access them all, and initialized data all before = uninitialized, so + we can shorten the on-disk segment size. */ + .sdata : { *(.sdata) } + _edata =3D .; + PROVIDE (edata =3D .); + .sbss : + { + PROVIDE (__sbss_start =3D .); + *(.sbss) + *(.scommon) + *(.dynsbss) + PROVIDE (__sbss_end =3D .); + } + .plt : { *(.plt) } + .bss : + { + PROVIDE (__bss_start =3D .); + *(.dynbss) + *(.bss) + *(COMMON) + } + _end =3D . ; + PROVIDE (end =3D .); + /* Stabs debugging sections. */ + .stab 0 : { *(.stab) } + .stabstr 0 : { *(.stabstr) } + /* DWARF debug sections. + Symbols in the DWARF debugging sections are relative to the = beginning + of the section so we begin them at 0. */ + /* DWARF 1 */ + .debug 0 : { *(.debug) } + .line 0 : { *(.line) } + /* GNU DWARF 1 extensions */ + .debug_srcinfo 0 : { *(.debug_srcinfo) } + .debug_sfnames 0 : { *(.debug_sfnames) } + /* DWARF 1.1 and DWARF 2 */ + .debug_aranges 0 : { *(.debug_aranges) } + .debug_pubnames 0 : { *(.debug_pubnames) } + /* DWARF 2 */ + .debug_info 0 : { *(.debug_info) } + .debug_abbrev 0 : { *(.debug_abbrev) } + .debug_line 0 : { *(.debug_line) } + .debug_frame 0 : { *(.debug_frame) } + .debug_str 0 : { *(.debug_str) } + .debug_loc 0 : { *(.debug_loc) } + .debug_macinfo 0 : { *(.debug_macinfo) } + /* SGI/MIPS DWARF 2 extensions */ + .debug_weaknames 0 : { *(.debug_weaknames) } + .debug_funcnames 0 : { *(.debug_funcnames) } + .debug_typenames 0 : { *(.debug_typenames) } + .debug_varnames 0 : { *(.debug_varnames) } + /* These must appear regardless of . */ +} Index: sys/boot/arm64/uboot/loader.conf =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/uboot/loader.conf = b/head/sys/boot/arm64/uboot/loader.conf new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/uboot/loader.conf (working copy) @@ -0,0 +1,13 @@ +# This is defaults/loader.conf for ARM 64, containing defaults for = loader(8). +# Do not modify the contents of this file, instead put your = customizations +# into /boot/loader.conf or /boot/loader.conf.local +# $FreeBSD$ + +autoboot_delay=3D10 +bootfile=3D"kernel" # Kernel name (possibly absolute path) +kernel=3D"kernel" # /boot sub-directory containing kernel and = modules +loader_conf_files=3D"/boot/loader.conf /boot/loader.conf.local" +module_path=3D"/boot/kernel;/boot/modules;/boot/dtb" +nextboot_conf=3D"/boot/nextboot.conf" +nextboot_enable=3D"NO" +verbose_loading=3D"NO" Index: sys/boot/arm64/uboot/start.S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/uboot/start.S = b/head/sys/boot/arm64/uboot/start.S new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/uboot/start.S (working copy) @@ -0,0 +1,122 @@ +/*- + * Copyright (c) 2008 Semihalf, Rafal Czubak + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in = the + * documentation and/or other materials provided with the = distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' = AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, = THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR = PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE = LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR = CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE = GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS = INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, = STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN = ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY = OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#include +#include + + .text + .extern _C_LABEL(self_reloc), _C_LABEL(main) + .weak _DYNAMIC + +/* + * Entry point to the loader that U-Boot passes control to. + */ + .globl _start +_start: + + /*=20 + * Do self-relocation when the weak external symbol _DYNAMIC is = non-NULL. + * When linked as a dynamic relocatable file, the linker = automatically + * defines _DYNAMIC with a value that is the offset of the = dynamic + * relocation info section. + * Note that we're still on u-boot's stack here, but the = self_reloc=20 + * code uses only a couple dozen bytes of stack space. + */ + ldr x15, =3D.here_off /* .here_off is a symbol = whose value */ + ldr x0, [x15] /* is its own offset in the text = seg. */ + sub x0, x15, x0 /* Get its pc-relative address = and */ + ldr x1, .dynamic_off /* subtract its value and we get = */ + cmp x1, #0 /* x0 =3D physaddr we were = loaded at. */ + b.eq 2f + add x1, x1, x0 /* x1 =3D dynamic section = physaddr. */ + bl _C_LABEL(self_reloc) /* Do reloc if _DYNAMIC is = non-NULL. */ +2:=09 + /* Hint where to look for the API signature */ + ldr x15, =3Duboot_address + mov x0, sp + str x0, [x15] + + /* Save U-Boot's x18 */ + ldr x15, =3Dsaved_regs + str x18, [x15, #0] + + /*=20 + * Start loader. This is basically a tail-recursion call; if = main() + * returns, it returns to u-boot (which reports the value = returned x0). + */ + b main + + /*=20 + * Data for self-relocation, in the text segment for pc-rel = access. + */ + .align 3 +.here_off: + .quad . +.dynamic_off: + .quad _DYNAMIC + +/* + * syscall() + */ +ENTRY(syscall) + /* Save caller's lr, x18 */ + ldr x15, =3Dsaved_regs + str x18, [x15, #8] + str lr, [x15, #16] +=09 + /* Restore U-Boot's x18 */ + ldr x18, saved_regs +=09 + /* Call into U-Boot */ + ldr lr, =3Dreturn_from_syscall + ldr x15, syscall_ptr + br x15 +return_from_syscall: + /* Restore loader's x18 and lr */ + ldr lr, saved_regs + 16 + ldr x18, saved_regs + 8 + /* Return to caller */ + ret + +/* + * Data section + */ + .data + .align 3 + .globl syscall_ptr +syscall_ptr: + .quad 0 + + .globl uboot_address +uboot_address: + .quad 0 + +saved_regs: + .quad 0 /* U-Boot's x18 */ + .quad 0 /* Loader's x18 */ + .quad 0 /* Loader's lr */ Index: sys/boot/arm64/uboot/version =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/arm64/uboot/version = b/head/sys/boot/arm64/uboot/version new file mode 10644 --- /dev/null (nonexistent) +++ b/head/sys/boot/arm64/uboot/version (working copy) @@ -0,0 +1,6 @@ +$FreeBSD$ + +NOTE ANY CHANGES YOU MAKE TO THE BOOTBLOCKS HERE. The format of this +file is important. Make sure the current version number is on line 6. + +1.0: Initial U-Boot/arm64 version derived from U-boot/arm. Index: sys/boot/common/load_elf.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/common/load_elf.c = b/head/sys/boot/common/load_elf.c --- a/head/sys/boot/common/load_elf.c (revision 295842) +++ b/head/sys/boot/common/load_elf.c (working copy) @@ -50,6 +50,10 @@ #define ELF_TARG_MACH EM_X86_64 #endif =20 +#if defined(__aarch64__) +#define KERN_ALIGN (2 * 1024 * 1024) +#endif + typedef struct elf_file { Elf_Phdr *ph; Elf_Ehdr *ehdr; @@ -198,7 +202,7 @@ * leave dest set to the value calculated by = archsw.arch_loadaddr() and * passed in to this function. */ -#ifndef __arm__ +#if !defined(__arm__) && !defined(__aarch64__) if (ehdr->e_type =3D=3D ET_EXEC) dest =3D (ehdr->e_entry & ~PAGE_MASK); #endif @@ -375,6 +379,23 @@ #ifdef ELF_VERBOSE printf("ehdr->e_entry 0x%08x, va<->pa off %llx\n", = ehdr->e_entry, off); #endif +#elif defined(__aarch64__) + /* + * The elf headers in arm kernels specify virtual addresses in = all + * header fields, even the ones that should be physical = addresses. + * We assume the entry point is in the first 2MB, and masking = the lower + * bits will leave us with the virtual address the kernel was = linked + * at. We subtract that from the load offset, making 'off' into = the + * value which, when added to a virtual address in an elf = header, + * translates it to a physical address. We do the va->pa = conversion on + * the entry point address in the header now, so that later we = can + * launch the kernel by just jumping to that address. + */ + off -=3D ehdr->e_entry & ~(KERN_ALIGN - 1); + ehdr->e_entry +=3D off; +#ifdef ELF_VERBOSE + printf("ehdr->e_entry %p, va<->pa off 0x%llx\n", ehdr->e_entry, = off); +#endif #else off =3D 0; /* other archs use direct mapped kernels = */ #endif Index: sys/boot/efi/loader/bootinfo.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/efi/loader/bootinfo.c = b/head/sys/boot/efi/loader/bootinfo.c --- a/head/sys/boot/efi/loader/bootinfo.c (revision 295842) +++ b/head/sys/boot/efi/loader/bootinfo.c (working copy) @@ -221,7 +221,7 @@ if (fp->f_args) MOD_ARGS(addr, fp->f_args, c); v =3D fp->f_addr; -#if defined(__arm__) +#if defined(__arm__) || defined(__aarch64__) v -=3D __elfN(relocation_offset); #endif MOD_ADDR(addr, v, c); @@ -351,7 +351,7 @@ vm_offset_t dtbp; int dtb_size; #endif -#if defined(__arm__) +#if defined(__arm__) || defined(__aarch64__) vm_offset_t vaddr; size_t i; /* @@ -440,7 +440,7 @@ md =3D file_findmetadata(kfp, MODINFOMD_KERNEND); bcopy(&kernend, md->md_data, sizeof kernend); =20 -#if defined(__arm__) +#if defined(__arm__) || defined(__aarch64__) *modulep -=3D __elfN(relocation_offset); =20 /* Do relocation fixup on metadata of each module. */ Index: sys/boot/uboot/common/main.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/uboot/common/main.c = b/head/sys/boot/uboot/common/main.c --- a/head/sys/boot/uboot/common/main.c (revision 295842) +++ b/head/sys/boot/uboot/common/main.c (working copy) @@ -133,7 +133,7 @@ size =3D memsize(si, t[i]); if (size > 0) printf("%s: %lldMB\n", ub_mem_type(t[i]), - size / 1024 / 1024); + (unsigned long long)size / 1024 / 1024); } } =20 @@ -512,7 +512,7 @@ { =20 printf("heap base at %p, top at %p, used %d\n", end, sbrk(0), - sbrk(0) - end); + (int)(sbrk(0) - end)); =20 return (CMD_OK); } Index: sys/boot/uboot/lib/copy.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/uboot/lib/copy.c = b/head/sys/boot/uboot/lib/copy.c --- a/head/sys/boot/uboot/lib/copy.c (revision 295842) +++ b/head/sys/boot/uboot/lib/copy.c (working copy) @@ -40,7 +40,7 @@ * MD primitives supporting placement of module data=20 */ =20 -#ifdef __arm__ +#if defined(__arm__) || defined(__aarch64__) #define KERN_ALIGN (2 * 1024 * 1024) #else #define KERN_ALIGN PAGE_SIZE Index: sys/boot/uboot/lib/disk.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/uboot/lib/disk.c = b/head/sys/boot/uboot/lib/disk.c --- a/head/sys/boot/uboot/lib/disk.c (revision 295842) +++ b/head/sys/boot/uboot/lib/disk.c (working copy) @@ -156,8 +156,8 @@ } =20 if (size % SI(dev).bsize) { - stor_printf("size=3D%d not multiple of device block = size=3D%d\n", - size, SI(dev).bsize); + stor_printf("size=3D%ld not multiple of device block = size=3D%d\n", + (long)size, SI(dev).bsize); return (EIO); } bcount =3D size / SI(dev).bsize; Index: sys/boot/uboot/lib/elf_freebsd.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/uboot/lib/elf_freebsd.c = b/head/sys/boot/uboot/lib/elf_freebsd.c --- a/head/sys/boot/uboot/lib/elf_freebsd.c (revision 295842) +++ b/head/sys/boot/uboot/lib/elf_freebsd.c (working copy) @@ -81,7 +81,7 @@ return (error); =20 entry =3D (void *)e->e_entry; - printf("Kernel entry at 0x%x...\n", (unsigned)entry); + printf("Kernel entry at 0x%p...\n", entry); =20 dev_cleanup(); printf("Kernel args: %s\n", fp->f_args); Index: sys/boot/uboot/lib/glue.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D diff --git a/head/sys/boot/uboot/lib/glue.c = b/head/sys/boot/uboot/lib/glue.c --- a/head/sys/boot/uboot/lib/glue.c (revision 295842) +++ b/head/sys/boot/uboot/lib/glue.c (working copy) @@ -109,7 +109,7 @@ { int c; =20 - if (!syscall(API_GETC, NULL, (uint32_t)&c)) + if (!syscall(API_GETC, NULL, (uintptr_t)&c)) return (-1); =20 return (c); @@ -120,7 +120,7 @@ { int t; =20 - if (!syscall(API_TSTC, NULL, (uint32_t)&t)) + if (!syscall(API_TSTC, NULL, (uintptr_t)&t)) return (-1); =20 return (t); @@ -130,7 +130,7 @@ ub_putc(char c) { =20 - syscall(API_PUTC, NULL, (uint32_t)&c); + syscall(API_PUTC, NULL, (uintptr_t)&c); } =20 void @@ -137,7 +137,7 @@ ub_puts(const char *s) { =20 - syscall(API_PUTS, NULL, (uint32_t)s); + syscall(API_PUTS, NULL, (uintptr_t)s); } =20 /**************************************** @@ -166,7 +166,7 @@ si.mr_no =3D UB_MAX_MR; memset(&mr, 0, sizeof(mr)); =20 - if (!syscall(API_GET_SYS_INFO, &err, (u_int32_t)&si)) + if (!syscall(API_GET_SYS_INFO, &err, (uintptr_t)&si)) return (NULL); =20 return ((err) ? NULL : &si); @@ -483,7 +483,7 @@ { char *value; =20 - if (!syscall(API_ENV_GET, NULL, (uint32_t)name, = (uint32_t)&value)) + if (!syscall(API_ENV_GET, NULL, (uintptr_t)name, = (uintptr_t)&value)) return (NULL); =20 return (value); @@ -493,7 +493,7 @@ ub_env_set(const char *name, char *value) { =20 - syscall(API_ENV_SET, NULL, (uint32_t)name, (uint32_t)value); + syscall(API_ENV_SET, NULL, (uintptr_t)name, (uintptr_t)value); } =20 static char env_name[256]; @@ -510,7 +510,7 @@ * internally, which handles such case */ env =3D NULL; - if (!syscall(API_ENV_ENUM, NULL, (uint32_t)last, = (uint32_t)&env)) + if (!syscall(API_ENV_ENUM, NULL, (uintptr_t)last, = (uintptr_t)&env)) return (NULL); =20 if (env =3D=3D NULL || last =3D=3D env) --Apple-Mail=_7BB33126-1C35-48DD-AE65-BC1CF00904CF-- From owner-freebsd-arm@freebsd.org Mon Feb 29 22:58:36 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5EEC3AB82E4 for ; Mon, 29 Feb 2016 22:58:36 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (vps.rulingia.com [103.243.244.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.rulingia.com", Issuer "Let's Encrypt Authority X1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F0FF9816 for ; Mon, 29 Feb 2016 22:58:35 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (c122-106-195-17.belrs5.nsw.optusnet.com.au [122.106.195.17]) by vps.rulingia.com (8.15.2/8.15.2) with ESMTPS id u1TMwJlI023367 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 1 Mar 2016 09:58:25 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id u1TMwBBE021082 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 1 Mar 2016 09:58:11 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id u1TMwB5U021081 for freebsd-arm@freebsd.org; Tue, 1 Mar 2016 09:58:11 +1100 (AEDT) (envelope-from peter) Date: Tue, 1 Mar 2016 09:58:11 +1100 From: Peter Jeremy To: freebsd-arm@freebsd.org Subject: FreeBSD on the RaspberryPi 3 Message-ID: <20160229225811.GB74374@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="24zk1gE8NUlDmwG9" Content-Disposition: inline X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.24 (2015-08-30) X-Greylist: Sender succeeded STARTTLS authentication, not delayed by milter-greylist-4.4.3 (vps.rulingia.com [103.243.244.15]); Tue, 01 Mar 2016 09:58:25 +1100 (AEDT) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 22:58:36 -0000 --24zk1gE8NUlDmwG9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Has anyone gotten close enough to a RPi3 to know how difficult it will be to get FreeBSD to run on it - in particular the Bluetooth and WiFi? --=20 Peter Jeremy --24zk1gE8NUlDmwG9 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJW1M0DXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFRUIyOTg2QzMwNjcxRTc0RTY1QzIyN0Ux NkE1OTdBMEU0QTIwQjM0AAoJEBall6Dkogs00QkP/R+vPcufpaKap9Sc4S2Ls2KD 3lfd4qJqel5K7i9XL8QMfdd6GckMc1o9TCPu7CjGcSdaypHuneavNlIHGfVxb/BB 0YLSXfVEE8OuQdLBba8gAgOqwYG7/Uz4sSTGnnwCE8knLQMZ7cpPS39dFzjL1U7g f5OsYW2aBcTWnkeHgFHdABGOZbZzOMKesB6wpJxJC9AyAmo4Jf8fPq0ycyqjFsYj eC7BRe5rwXMBEZKuH1/4iT980SqeO45KRxNDsSSNK54/PaBlvx72WjWR3iPuj+cr WDXDwk+ORsut3/fThjy9eg+t8wB0tfFZNl3Gysa4hjD1KN6LjT9wSUTzQOie4cE5 K8WqDHLtKLWpDgYDmp3iApud81b5coq1NgZGFeIEo17Deq1uT6w8RzSnP6KdD6w8 U2ViN0crI/PB2fGCwmKDdyEGGIrnrlacuS1k1qVex8DoX6XCcViNUdP4BiXW8AlP o2MLb7+qu/iEX73Oney3gDzE4voJjKtnoQNopykPkoz22PiuiD/wauxoX+clEWmj k3oMbwy1Fq0me88M7Ihgtdzuls5uRuO/Q2TWceM4KFoyhGP3CaJzz8Sl14ogmxPh Xhl2wrMxZjRSQNJ7qjU2qAwXz5O8rY928MJwUHtBDGCSk0t0+idwfulE83W82uNH ESDG8EhOvNv3SYhqTfvA =S5lw -----END PGP SIGNATURE----- --24zk1gE8NUlDmwG9-- From owner-freebsd-arm@freebsd.org Mon Feb 29 22:59:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 54D74AB8330 for ; Mon, 29 Feb 2016 22:59:23 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id 3A90188D; Mon, 29 Feb 2016 22:59:23 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 027003F5; Mon, 29 Feb 2016 22:59:21 +0000 (UTC) Date: Mon, 29 Feb 2016 22:59:11 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: avos@FreeBSD.org, bdrewery@FreeBSD.org, jkim@FreeBSD.org, np@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <1163079373.167.1456786760284.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2485 - Failure MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: FAILURE Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 22:59:23 -0000 FreeBSD_HEAD_arm64 - Build #2485 - Failure: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2485/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2485/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2485/console Change summaries: 296240 by jkim: Merge byacc 20150711. 296239 by avos: net80211: do not enforce promiscuous mode for AP scan Drivers should set their own filters via ic_scan_start()/ic_scan_end() callbacks; and we don't need frames other than beacons or probe responses. (Note: this was a noop since r287197 due to promiscuous mode with bridge workaround) Tested with Intel 3945BG, RTL8188EU and WUSB54GC in HOSTAP mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5474 296238 by bdrewery: FAST_DEPEND: Prefer .OBJDIR depend files. Sponsored by: EMC / Isilon Storage Division 296237 by avos: net80211: fix scanning after D5145 (PR 197498 related) - In case, when we are doing -> INIT (FEXT_REINIT) -> state transition, cancel_scan() may be called in the first transition. Reenqueue second state transition, so things will be executed in order. - Discard any AUTH+ state transition request when INIT -> SCAN transition is not done. - Allow to track discarded state transitions via 'state' debugging category. Tested with: * RTL8188EU, HOSTAP mode. * RTL8188CUS, STA mode. * Intel 3945BG, IBSS and STA modes. PR: 197498 Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5482 296236 by np: Fix some whitespace nits in cxgbetool.c. No functional change. 296235 by avos: net80211: cleanup ieee80211_scan_sw.c Make it look more consistently. No functional changes. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5152 296234 by avos: net80211: refactor scan_signal() - Pass scan state and additional internal flags as a parameters. - Add locked version. Tested with: * Intel 3945BG, STA mode. * RTL8188EU, STA mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5148 296233 by avos: net80211: wakeup scan_start() task when null data frame was actually transmitted - Use M_TXCB mechanism to report about null data frame transmission. - Increase timeout from 1 to 10 ms (the previous one may be not enough for non-empty queue). Tested with: * Intel 3945BG, STA mode. * RTL8188CUS, STA mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5147 296232 by avos: net80211: split scan_task() (#3) (into scan_start() and scan_curchan_task() functions) (This part should fix the problem, described in https://lists.freebsd.org/pipermail/freebsd-wireless/2016-January/006420.html) - Rename ss_scan_task into ss_scan_start (better describes it's current purpose) - Utilize taskqueue_*_timeout() functions instead of current mechanism: * reschedule scan_curchan_task() via taskqueue_enqueue_timeout() for every 'maxdwell' msecs (will replace infinite loop + sleeping for 'maxdwell' period via cv_wait()); * rerun the task immediately when an external event occurs (instead of waking it up via cv_signal()) Also, use mtx_sleep() to wait for null frame transmission (allows to drop conditional variable). Tested with: * Intel 3945BG, STA mode; * RTL8188EU, STA mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5145 296231 by avos: net80211: split scan_task() (#2) (add scan_end() function) Tested with: * Intel 3945BG, STA mode. * RTL8188EU, IBSS mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5143 296230 by avos: net80211: split scan_task() (#1) (replace 'done' label with scan_done() function) Tested with: * Intel 3945BG, STA mode. * RTL8188EU, IBSS mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5142 296229 by avos: net80211: utilize ss_scanend variable from scan_state structure Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5140 296228 by avos: net80211: reduce code verbosity in scan_task() (ieee80211_scan_sw.c) Add local *ss_priv variable (no functional changes) Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5139 296227 by avos: net80211: reduce code duplication between ieee80211_swscan_cancel_scan() and ieee80211_swscan_cancel_anyscan() Tested with: * Intel 3945BG, STA mode. * RTL8188EU, HOSTAP mode. Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5133 296226 by avos: network.subr: avoid unnecessary reinitialization Do not start interface when wpa_supplicant or hostapd is used; they will restart it anyway Tested with: * Intel 3945BG, STA mode (wpa_supplicant) * RTL8188EU, HOSTAP mode (hostapd) Approved by: adrian (mentor) Differential Revision: https://reviews.freebsd.org/D5486 The end of the build log: [...truncated 182115 lines...] --- ieee80211_xauth.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/wlan_xauth/../../net80211/ieee80211_xauth.c -o ieee80211_xauth.o --- all_subdir_wlan --- --- ieee80211_node.o --- ctfconvert -L VERSION -g ieee80211_node.o --- ieee80211_output.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_output.c -o ieee80211_output.o --- all_subdir_wlan_wep --- ctfconvert -L VERSION -g ieee80211_crypto_wep.o --- wlan_wep.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o wlan_wep.kld ieee80211_crypto_wep.o ctfmerge -L VERSION -g -o wlan_wep.kld ieee80211_crypto_wep.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk wlan_wep.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % wlan_wep.kld --- wlan_wep.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o wlan_wep.ko.full ieee80211_crypto_wep.o --- wlan_wep.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug wlan_wep.ko.full wlan_wep.ko.debug --- wlan_wep.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=wlan_wep.ko.debug wlan_wep.ko.full wlan_wep.ko --- all_subdir_wlan --- --- ieee80211_phy.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_phy.c -o ieee80211_phy.o --- all_subdir_wlan_xauth --- ctfconvert -L VERSION -g ieee80211_xauth.o --- wlan_xauth.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o wlan_xauth.kld ieee80211_xauth.o ctfmerge -L VERSION -g -o wlan_xauth.kld ieee80211_xauth.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk wlan_xauth.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % wlan_xauth.kld --- all_subdir_usb --- ctfconvert -L VERSION -g atp.o --- all_subdir_wlan_xauth --- --- wlan_xauth.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o wlan_xauth.ko.full ieee80211_xauth.o --- wlan_xauth.ko.debug --- --- all_subdir_usb --- --- atp.kld --- --- all_subdir_wlan_xauth --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug wlan_xauth.ko.full wlan_xauth.ko.debug --- all_subdir_usb --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o atp.kld atp.o --- all_subdir_wlan_xauth --- --- wlan_xauth.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=wlan_xauth.ko.debug wlan_xauth.ko.full wlan_xauth.ko --- all_subdir_usb --- ctfmerge -L VERSION -g -o atp.kld atp.o --- all_subdir_usb/uhid --- ===> usb/uhid (all) --- all_subdir_usb/atp --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk atp.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % atp.kld --- atp.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o atp.ko.full atp.o --- atp.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug atp.ko.full atp.ko.debug --- atp.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=atp.ko.debug atp.ko.full atp.ko --- all_subdir_wlan --- --- ieee80211_power.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_power.c -o ieee80211_power.o --- all_subdir_usb --- --- all_subdir_usb/uhid --- --- uhid.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/usb/uhid/../../../dev/usb/input/uhid.c -o uhid.o --- all_subdir_wlan --- --- ieee80211_phy.o --- ctfconvert -L VERSION -g ieee80211_phy.o --- all_subdir_xl --- ===> xl (all) --- if_xl.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/xl/../../dev/xl/if_xl.c -o if_xl.o --- all_subdir_usb --- ctfconvert -L VERSION -g uhid.o --- uhid.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o uhid.kld uhid.o ctfmerge -L VERSION -g -o uhid.kld uhid.o --- all_subdir_wlan --- --- ieee80211_power.o --- ctfconvert -L VERSION -g ieee80211_power.o --- all_subdir_usb --- :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk uhid.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % uhid.kld --- uhid.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o uhid.ko.full uhid.o --- uhid.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug uhid.ko.full uhid.ko.debug --- uhid.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=uhid.ko.debug uhid.ko.full uhid.ko --- all_subdir_usb/ukbd --- ===> usb/ukbd (all) --- all_subdir_xl --- --- xlphy.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/xl/../../dev/xl/xlphy.c -o xlphy.o --- all_subdir_usb --- --- ukbd.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/usb/ukbd/../../../dev/usb/input/ukbd.c -o ukbd.o --- all_subdir_xl --- ctfconvert -L VERSION -g xlphy.o --- all_subdir_wlan --- --- ieee80211_proto.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_proto.c -o ieee80211_proto.o --- ieee80211_output.o --- ctfconvert -L VERSION -g ieee80211_output.o --- all_subdir_usb --- --- all_subdir_usb/ums --- ===> usb/ums (all) --- ums.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/usb/ums/../../../dev/usb/input/ums.c -o ums.o --- all_subdir_usb/ukbd --- ctfconvert -L VERSION -g ukbd.o --- ukbd.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o ukbd.kld ukbd.o ctfmerge -L VERSION -g -o ukbd.kld ukbd.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ukbd.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % ukbd.kld --- ukbd.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o ukbd.ko.full ukbd.o --- ukbd.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug ukbd.ko.full ukbd.ko.debug --- ukbd.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=ukbd.ko.debug ukbd.ko.full ukbd.ko --- rijndael-api-fst.o --- cc -B/usr/local/aarch64-freebsd/bin/ -c -O -pipe -g -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -Werror /usr/src/sys/crypto/rijndael/rijndael-api-fst.c --- modules-all --- --- all_subdir_wlan --- --- ieee80211_proto.o --- ctfconvert -L VERSION -g ieee80211_proto.o --- ieee80211_scan.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_scan.c -o ieee80211_scan.o --- all_subdir_xl --- --- if_xl.o --- ctfconvert -L VERSION -g if_xl.o --- if_xl.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o if_xl.kld if_xl.o xlphy.o ctfmerge -L VERSION -g -o if_xl.kld if_xl.o xlphy.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk if_xl.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % if_xl.kld --- if_xl.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o if_xl.ko.full if_xl.o xlphy.o --- if_xl.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug if_xl.ko.full if_xl.ko.debug --- if_xl.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=if_xl.ko.debug if_xl.ko.full if_xl.ko --- all_subdir_wlan --- --- ieee80211_scan_sw.o --- --- rijndael-api-fst.o --- ctfconvert -L VERSION -g rijndael-api-fst.o --- modules-all --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/wlan/../../net80211/ieee80211_scan_sw.c -o ieee80211_scan_sw.o --- all_subdir_zfs --- ===> zfs (all) --- all_subdir_usb --- --- all_subdir_usb/ums --- ctfconvert -L VERSION -g ums.o --- ums.kld --- /usr/local/aarch64-freebsd/bin/ld -d -warn-common -r -d -o ums.kld ums.o ctfmerge -L VERSION -g -o ums.kld ums.o :> export_syms awk -f /usr/src/sys/conf/kmod_syms.awk ums.kld export_syms | xargs -J% /usr/local/aarch64-freebsd/bin/objcopy % ums.kld --- ums.ko.full --- /usr/local/aarch64-freebsd/bin/ld -Bshareable -d -warn-common -o ums.ko.full ums.o --- ums.ko.debug --- /usr/local/aarch64-freebsd/bin/objcopy --only-keep-debug ums.ko.full ums.ko.debug --- ums.ko --- /usr/local/aarch64-freebsd/bin/objcopy --strip-debug --add-gnu-debuglink=ums.ko.debug ums.ko.full ums.ko --- all_subdir_usb/udbp --- ===> usb/udbp (all) --- udbp.o --- cc -B/usr/local/aarch64-freebsd/bin/ -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/arm64.aarch64/usr/src/sys/GENERIC/opt_global.h -I. -I/usr/src/sys -fno-common -g -fPIC -I/usr/obj/arm64.aarch64/usr/src/sys/GENERIC -mgeneral-regs-only -ffixed-x18 -ffreestanding -fwrapv -fstack-protector -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-error-pointer-sign -Wno-error-shift-negative-value -std=iso9899:1999 -c /usr/src/sys/modules/usb/udbp/../../../dev/usb/misc/udbp.c -o udbp.o --- all_subdir_wlan --- /usr/src/sys/modules/wlan/../../net80211/ieee80211_scan_sw.c:598:23: error: unused variable 'vap' [-Werror,-Wunused-variable] struct ieee80211vap *vap = ss->ss_vap; ^ /usr/src/sys/modules/wlan/../../net80211/ieee80211_scan_sw.c:660:23: error: unused variable 'vap' [-Werror,-Wunused-variable] struct ieee80211vap *vap = ss->ss_vap; ^ 2 errors generated. *** [ieee80211_scan_sw.o] Error code 1 make[4]: stopped in /usr/src/sys/modules/wlan --- all_subdir_zfs --- A failure has been detected in another branch of the parallel make make[4]: stopped in /usr/src/sys/modules/zfs *** [all_subdir_zfs] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_wlan --- --- ieee80211_scan.o --- ctfconvert -L VERSION -g ieee80211_scan.o 1 error make[4]: stopped in /usr/src/sys/modules/wlan *** [all_subdir_wlan] Error code 2 make[3]: stopped in /usr/src/sys/modules --- all_subdir_usb --- ctfconvert -L VERSION -g udbp.o A failure has been detected in another branch of the parallel make make[5]: stopped in /usr/src/sys/modules/usb/udbp *** [all_subdir_usb/udbp] Error code 2 make[4]: stopped in /usr/src/sys/modules/usb 1 error make[4]: stopped in /usr/src/sys/modules/usb *** [all_subdir_usb] Error code 2 make[3]: stopped in /usr/src/sys/modules 3 errors make[3]: stopped in /usr/src/sys/modules *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC 1 error make[2]: stopped in /usr/obj/arm64.aarch64/usr/src/sys/GENERIC *** [buildkernel] Error code 2 make[1]: stopped in /usr/src 1 error make[1]: stopped in /usr/src *** [buildkernel] Error code 2 make: stopped in /usr/src 1 error make: stopped in /usr/src Build step 'Execute shell' marked build as failure [PostBuildScript] - Execution post build scripts. [FreeBSD_HEAD_arm64] $ /bin/sh -xe /tmp/hudson5517669458253927340.sh + export 'PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin' + export 'jname=FreeBSD_HEAD_arm64' + echo 'clean up jail FreeBSD_HEAD_arm64' clean up jail FreeBSD_HEAD_arm64 + sudo jail -r FreeBSD_HEAD_arm64 + sudo ifconfig igb0 inet6 2610:1c1:1:607c::104:1 -alias + sudo umount FreeBSD_HEAD_arm64/usr/src + sudo umount FreeBSD_HEAD_arm64/dev + sudo rm -fr FreeBSD_HEAD_arm64 + true + sudo chflags -R noschg FreeBSD_HEAD_arm64 + sudo rm -fr FreeBSD_HEAD_arm64 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any From owner-freebsd-arm@freebsd.org Mon Feb 29 23:42:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6A7AAB94D5 for ; Mon, 29 Feb 2016 23:42:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AFBC5687 for ; Mon, 29 Feb 2016 23:42:40 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22e.google.com with SMTP id y8so7947419igp.0 for ; Mon, 29 Feb 2016 15:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=+63cLonzguiPriClHOZ7i+zW4CQlkaiEhy6dcFIL08w=; b=iC9nBh+IFqGdAEduPq44AtcA2PjFMb6rzKVEt2WJQ0fIErsdsAkjYlwrgH2v0Pbj2T phCXqQrH04w3SO7gD0KOHlRZc4hOgq1QWfmETKqv69oL9sp4dSBzn/x64LDHLMN0Y+i5 ZRootOC36Ufg2qoEIy3XRs3npRYA2iKJOkpcbGGMr+uV1c64dpzuS81CdtWq/vmUDEgP y9Pa02yfxiNb8AnODdufU+ufucwMAGqJ2dXbDAgRsNwbcj9JybjlZg+6glGQ0Lnu0LDc b8NJN3pfw9isiVYHoQSTb09a5Htn9z8pzRG9KyrJTl11PeLU/iHNgmkKSaTSImetPJF7 Jhfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+63cLonzguiPriClHOZ7i+zW4CQlkaiEhy6dcFIL08w=; b=S1FW77AibFkuDrfkKie2aF4BavtgL4nPFzRyJp/K2H2tfXNLEy09jmo58vUfg5CKaz u3nfp1xLB9XL02edrQPhrTUYho83MhaGq44+4238rm0dmh1+bOxSjVqW0HCv+16TWkvC CjP7jAwR8OMO0sP2+Vf2bQccbl8HMSAyjdBn7lTROgAcU6k3nn/r4s2o10EPf8ZNCoUR UGVbp48l7uZKIQcPGS8qBYwDHoBFOMBTeMCy2hSX8UxbDhXZHAcr5+aO8FxNGun9OFon KLPg9DBTPkG6rL3boWwhHPOa2x3650hqtgjX3hFmfKeHW/SUokGPuccyDXE3kTtEX2HD BFSg== X-Gm-Message-State: AD7BkJLsbJnhKPR4CEKA5DJET4dhTlmj6RiWADIfwbWXbnVkw4PBZcf/XmF2QKETKMgMS2XUXNYO+o9+cTVa0Q== MIME-Version: 1.0 X-Received: by 10.50.137.33 with SMTP id qf1mr94768igb.37.1456789359949; Mon, 29 Feb 2016 15:42:39 -0800 (PST) Received: by 10.36.14.19 with HTTP; Mon, 29 Feb 2016 15:42:39 -0800 (PST) In-Reply-To: <20160229225811.GB74374@server.rulingia.com> References: <20160229225811.GB74374@server.rulingia.com> Date: Mon, 29 Feb 2016 15:42:39 -0800 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Adrian Chadd To: Peter Jeremy Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Feb 2016 23:42:40 -0000 There's no sdio wifi support, and no sdio bus support yet. So unless the BT is USB, it's not going to happen! sorry, -adrian On 29 February 2016 at 14:58, Peter Jeremy wrote: > Has anyone gotten close enough to a RPi3 to know how difficult it will be > to get FreeBSD to run on it - in particular the Bluetooth and WiFi? > > -- > Peter Jeremy From owner-freebsd-arm@freebsd.org Tue Mar 1 00:00:01 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 227CEAB9BCE for ; Tue, 1 Mar 2016 00:00:01 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B6319C53 for ; Tue, 1 Mar 2016 00:00:00 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u1TNxcVm053733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2016 00:59:39 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u1TNxXIw057733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2016 00:59:33 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u1TNxWKM060038; Tue, 1 Mar 2016 00:59:32 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u1TNxU1p060037; Tue, 1 Mar 2016 00:59:30 +0100 (CET) (envelope-from ticso) Date: Tue, 1 Mar 2016 00:59:29 +0100 From: Bernd Walter To: Adrian Chadd Cc: Peter Jeremy , "freebsd-arm@freebsd.org" Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160229235929.GA59803@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20160229225811.GB74374@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 00:00:01 -0000 On Mon, Feb 29, 2016 at 03:42:39PM -0800, Adrian Chadd wrote: > There's no sdio wifi support, and no sdio bus support yet. > > So unless the BT is USB, it's not going to happen! As far as I know the WiFi/BT is a Broadcom SDIO chip. So much about our chances... > On 29 February 2016 at 14:58, Peter Jeremy wrote: > > Has anyone gotten close enough to a RPi3 to know how difficult it will be > > to get FreeBSD to run on it - in particular the Bluetooth and WiFi? RS wrote that I will receive my order on wednesday. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Tue Mar 1 00:03:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6139FAB7389 for ; Tue, 1 Mar 2016 00:03:52 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 352D6111C for ; Tue, 1 Mar 2016 00:03:52 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=ZulNU4PG c=1 sm=1 tr=0 a=aps9VBOkFNN2EN8VlaEDew==:117 a=aps9VBOkFNN2EN8VlaEDew==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=B-X5g-zTAAAA:8 a=_R24L-flNkb6E0RjGEEA:9 a=CjuIK1q_8ugA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 166.170.220.175 is neither permitted nor denied by domain of rcn.com) Received: from [166.170.220.175] ([166.170.220.175:29165] helo=[10.212.180.50]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPA id 40/8B-31527-06CD4D65; Mon, 29 Feb 2016 19:03:45 -0500 References: <20160229225811.GB74374@server.rulingia.com> Mime-Version: 1.0 (1.0) In-Reply-To: <20160229225811.GB74374@server.rulingia.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: freebsd-arm@freebsd.org X-Mailer: iPhone Mail (13D15) From: Erik Moe Subject: Re: FreeBSD on the RaspberryPi 3 Date: Mon, 29 Feb 2016 18:03:44 -0600 To: Peter Jeremy X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 00:03:52 -0000 I ordered one from element14 this morning. No ETA when it will arrive. =46rom= what I've read recent versions of NOOBS or Raspbian will run on it. So I t= hink you can run a 32-bit OS on the RPI3, which would mean you could run the= current version of FreeBSD on the RPI3. It's not entirely clear to me. I q= uote from the website: "At launch, we are using the same 32-bit Raspbian userland that we use on ot= her Raspberry Pi devices; over the next few months we will investigate wheth= er there is value in moving to 64-bit mode." They only talk about userland and not the about the kernel. But from my lim= ited knowledge of ARMv8, I think it's possible. I doubt that FreeBSD would support WiFi and Bluetooth out the gate. Erik > On Feb 29, 2016, at 4:58 PM, Peter Jeremy wrote: >=20 > Has anyone gotten close enough to a RPi3 to know how difficult it will be > to get FreeBSD to run on it - in particular the Bluetooth and WiFi? >=20 > --=20 > Peter Jeremy From owner-freebsd-arm@freebsd.org Tue Mar 1 00:22:53 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D9719AB7EF4 for ; Tue, 1 Mar 2016 00:22:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 97096269 for ; Tue, 1 Mar 2016 00:22:53 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qg0-x22d.google.com with SMTP id b67so130134357qgb.1 for ; Mon, 29 Feb 2016 16:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=018b0aWNVfYLZC/xkwpP9c5CZTUtZ6ptPdjA+Oe3diI=; b=Da5risa+U+jyjfPlsI1FMj3XBeLma1omb5nMWpkRvKNPRT507PjRKfWof3KeMLCyzp OgvGXF0E5YR7XKMCNr9pqV7Ecp/PVXu7rmVnaFjZYpr+c6GBqC0XKKOWSj3hdqC9w4AT p2DoEy1yrFHUOBNaz2S0RZhz6dWY47D4BgvN1s+3d9B5ko7TM5cCBjIvR21nBtOAAHg/ XA07QFOrGmfoJXCO0wPwkQr+0bzyLeiJvmYBVqveLi4CXybkZrvSmwoUfNrLne5cTd9M 5BYEbVuBGV5GcH9IEy5lbEU0K0F+BmvGvSpmglKSh3A/jIIBsZBjgs7OMWF4Ht9vg+xz LTnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=018b0aWNVfYLZC/xkwpP9c5CZTUtZ6ptPdjA+Oe3diI=; b=TzGbw826yTd/jI9fwABs7PFSdW6Kc8f43s/ztM24keV+nI/RfkOSlc/vRoYPzH8bjV nS6/hp29/JctYARM0xuekiiXEoisrqh+8fqoufFceOC9Tdr1Ip+pHSdzkAGJeCSdIl3V sGeC0b1S+cVwj5U59GxtwC86Jwqso9Z/rgla0AGMpKz9Kp2QBxhoSv5HQVsh3XYVl48X 7TOtmMqeCdNWKvZyhdfBRX58w2WmIctnmMfw2cd7fQDq/XXpstb7wFIt1DbYGeGygBLF sDtcJUvVgvARm3D63nkPhhY97bLqeMuNtwixQNff2PsJ43oP51HxgBdKHe4puGdj6WE+ BB0Q== X-Gm-Message-State: AD7BkJJVrkMh9rSYGODI2yhqsg9YUA2+Cb0nTufJoPBiTxvxgdKJtAfoRB2Y1QyHamgTRd93 X-Received: by 10.140.23.139 with SMTP id 11mr22838164qgp.62.1456791772579; Mon, 29 Feb 2016 16:22:52 -0800 (PST) Received: from mutt-hardenedbsd (c-73-135-80-144.hsd1.md.comcast.net. [73.135.80.144]) by smtp.gmail.com with ESMTPSA id m82sm12053821qkh.8.2016.02.29.16.22.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Feb 2016 16:22:51 -0800 (PST) Date: Mon, 29 Feb 2016 19:22:49 -0500 From: Shawn Webb To: Peter Jeremy Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160301002249.GA61549@mutt-hardenedbsd> References: <20160229225811.GB74374@server.rulingia.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6" Content-Disposition: inline In-Reply-To: <20160229225811.GB74374@server.rulingia.com> X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 00:22:54 -0000 --y0ulUmNC+osPPQO6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2016 at 09:58:11AM +1100, Peter Jeremy wrote: > Has anyone gotten close enough to a RPi3 to know how difficult it will be > to get FreeBSD to run on it - in particular the Bluetooth and WiFi? Hey Peter, We at HardenedBSD have ordered ten of them, eight of which will be given out for free at BSDCan. My hope is that we'll have FreeBSD running on the RPI3 by the end of the conference. I'll also be at the FreeBSD DevSummit and I hope that we'll have multiple late-night hackathons to get it working. Thanks, --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --y0ulUmNC+osPPQO6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1ODWAAoJEGqEZY9SRW7uW3sP+wajT3WqhgkCDPME9sl7M1ua G4pKOJafedXfccW02gXGGNu6W8GoHXRKGqz4BDJ1EFLM8Odj+BX/iLUBzM8ocrbI r7YVS+cMeECisCPaeuNebiTInsZfFwyGODOpHiRCGZG3H4CdjZVAMQvpMRHU3MyG mSL95ZMbrZKkQqp5TCi0F92BnVhAgdQ4MkG5EoiSPeSMZR0Mr/jtpnr7Nk3QQSBV dIVX50OziuNYcy0cn0pUelZyq4qL/1Tg405Tp0XEqkFV//bp7IkmLk13wjWqrrgu t5X7F1rroHzs2K68zHFTXfJWbwG3h2RMFvHXEtZ6bodBwJ0ml6eWjFghxFhzzFn8 TfcphKX9SHc6zsdVNOnZriT1jMJsuxr0YhlO5VbWKAILWCNKET7J44Zx+SkqllsP MWchW+x7bh/XdxBCKx02AQxT+Txt8UQ1iiZ5W95Wa/jyHChwZ8lKv/AbTQBPVMyp 1ayxtkuIjQRdxoqaIfblLATZ9ugJEStcV+UUHg2+R3HgQTgqzO67jiNP5f7dzwGS YNX1A7WpzgQCgqbHhetGVbs0Vg+wF3Fzr+dzpgS9wvQ10U4UNSBEN60mG1ZghQVb p+jsYp8PW/vlwvD2GdYCvTysPlSuQfxnSTLzJwGIFkcy4GTrA29P9mHEZjEIBJJV aWfE7NfZgQIXbHAS7kC6 =qUcG -----END PGP SIGNATURE----- --y0ulUmNC+osPPQO6-- From owner-freebsd-arm@freebsd.org Tue Mar 1 01:00:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B012CAB8F2D for ; Tue, 1 Mar 2016 01:00:56 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (jenkins-9.freebsd.org [8.8.178.209]) by mx1.freebsd.org (Postfix) with ESMTP id A5DFF19D5; Tue, 1 Mar 2016 01:00:56 +0000 (UTC) (envelope-from jenkins-admin@FreeBSD.org) Received: from jenkins-9.freebsd.org (localhost [127.0.0.1]) by jenkins-9.freebsd.org (Postfix) with ESMTP id 5095442D; Tue, 1 Mar 2016 01:00:56 +0000 (UTC) Date: Tue, 1 Mar 2016 01:00:53 +0000 (GMT) From: jenkins-admin@FreeBSD.org To: glebius@FreeBSD.org, jenkins-admin@FreeBSD.org, freebsd-arm@FreeBSD.org Message-ID: <117617624.169.1456794055267.JavaMail.jenkins@jenkins-9.freebsd.org> In-Reply-To: <1163079373.167.1456786760284.JavaMail.jenkins@jenkins-9.freebsd.org> References: <1163079373.167.1456786760284.JavaMail.jenkins@jenkins-9.freebsd.org> Subject: FreeBSD_HEAD_arm64 - Build #2486 - Fixed MIME-Version: 1.0 X-Jenkins-Job: FreeBSD_HEAD_arm64 X-Jenkins-Result: SUCCESS Precedence: bulk Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 01:00:56 -0000 FreeBSD_HEAD_arm64 - Build #2486 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2486/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2486/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_arm64/2486/console Change summaries: 296241 by glebius: Fix !IEEE80211_DEBUG build. From owner-freebsd-arm@freebsd.org Tue Mar 1 02:07:07 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2A48AAA99BF for ; Tue, 1 Mar 2016 02:07:07 +0000 (UTC) (envelope-from adrian.chadd@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 EC08D133C for ; Tue, 1 Mar 2016 02:07:06 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x234.google.com with SMTP id 9so204140307iom.1 for ; Mon, 29 Feb 2016 18:07:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=nBr3yPd0W738OeFGGDnRlREE/rHONRlM0rRKayj01Bc=; b=r7nihInpznklcqhFi8AzS9kkdK1uMDPA56hkih8qDviFWC1CQYfvTsoXe0Jz1wl42o Gw56A6inzFk2YAmsBX/K7e+jZerY250KEuEbJxhYfGl4HB1XLESMc5f8reFCl0S5qaG4 LKI4DPMRR22Prk8nIUEXsrv4+aJPzY2jbVsfP1y3I8L69ox9K8CckWo41C9w5GQX8gZe khdGYhahPmMBglnmMTd8JEZ4p1ZyIP57OS5P0byOiDpuEw5DLSmDgxmu99dxLbX/xCvP 9HTqG5VR4dPbvL0Bj5V4o+TdGJx1Y/24dPqD3JpuFKIhD26yaWiNLiUllAevRnhiwN5h 4i6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=nBr3yPd0W738OeFGGDnRlREE/rHONRlM0rRKayj01Bc=; b=b38nsgfSI2W6sxUnP55E9bCSEZ2tIcNYYbo0H89/+IfuFW0laz6/20R09llwpeeIn1 3nx6GPvbVaL+Qf8dLbQKajLTcziETo6eZZ0cA8NooQmbNJoa8tlxafVYKKjbcT61eqbM vtJuHgG9G3kECpj6GHWWqsPRm7F0wnutMhjFXPQiBaWY2BFc0ZfKs0FpPKuBo23DmfJf RkJR5pliLAkmonqJjZJulnvqzOGvfVc22plXDTNniMDn6unmr/hC11XS7h2PuFww1AHV mQmgyPifif5MZfO3ymLFyX4KECSfPvjBlg2IJkRl7xE74nw8/WId3UXFTG6URqThni/q 4Olw== X-Gm-Message-State: AG10YOSmq+zxDqTQ5KTEukZ5P1VqRe4pRhE+Yj9k+EaeRnENANgJ5z4mUGoiCu2aaFqRZaQ8qQFbl68hlBFhaA== MIME-Version: 1.0 X-Received: by 10.107.162.144 with SMTP id l138mr21025299ioe.123.1456798026398; Mon, 29 Feb 2016 18:07:06 -0800 (PST) Received: by 10.36.14.19 with HTTP; Mon, 29 Feb 2016 18:07:06 -0800 (PST) In-Reply-To: <20160301002249.GA61549@mutt-hardenedbsd> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> Date: Mon, 29 Feb 2016 18:07:06 -0800 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Adrian Chadd To: Shawn Webb Cc: Peter Jeremy , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 02:07:07 -0000 Someone ordered me one, so I can take a crack at the broadcom sdio bits. It'll require the ARM SDIO driver to first work.. -a From owner-freebsd-arm@freebsd.org Tue Mar 1 02:08:47 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6336AAA9B21 for ; Tue, 1 Mar 2016 02:08:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2FC821734 for ; Tue, 1 Mar 2016 02:08:47 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x231.google.com with SMTP id y8so8717159igp.1 for ; Mon, 29 Feb 2016 18:08:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Fo8Lh/ddTEer2KXbetsLLUGrEmjp0tP9gMiv5kuH+Jk=; b=jfyywhpmsPq7Tkt+DfFLVzYRgUReLmSmzmgcxsTzNao1lJ31/eX1j5pdX2jl896V3C jJ1/jFxw5pexw0xreGRoi08xj1cEccErR/dRNOVOq28gnm24gvCNGi07I3jBIBylw6MR YMh92o4EKYGg3S2EBzGAu+/S9mWXJL3yve3JBSZlEinHHVC03mx2xdU5if8ZPmQ42C7L h/H/SxBU8FZJjmfFcxmc8JUZnJnITzyBR1h0cn5yor0AYoGbI7XFbfAyPFzES7qaNBqF jyaYYKDK7bvEoC0ZGSzOfJ4xTbSB7XO9DgFPr/vWQOJQpBcfkgE470W0SXNQ6Ec23TZB yOEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Fo8Lh/ddTEer2KXbetsLLUGrEmjp0tP9gMiv5kuH+Jk=; b=cP5GGIzT8xMJIxI0aLGSA6MxEPaqr4NqjxdDI5/lH0eRlkuvVlNFVnzs00X8C92Txk e/AqYd5WWJ2vD8sDdirGyVcjrepdDduJSrzwTIdnxBTV9BRembVFoebltLYCUAY6puBm FQ2+tHemm4eM0nIxF/fsFOnwwBqF7L9fVCzzu8hgre4xciSUdBDZBhBCBVfvcaNo9ecq SIcacFgtTXcyN8UtLOg1ECS773Sb8qZTiQryvBfW51dZOBzpHYgr5CMEhRV/GjSxcBHc 9fWvaVNNMgq4r6G7x+zbt+EsJ3rukn3Oq6hc3Sl/TJTSVO6R3SJtjWameXIj4as1Lw6W gE7g== X-Gm-Message-State: AD7BkJLBqlV7dLjQ2Io4YqJtk3b5jgwpSNyQG+RcF6nfTJrATn620pebOXw1kggA/4Lj8M9HQJUDK8zlhD0fSg== MIME-Version: 1.0 X-Received: by 10.50.78.200 with SMTP id d8mr981936igx.61.1456798126520; Mon, 29 Feb 2016 18:08:46 -0800 (PST) Received: by 10.36.14.19 with HTTP; Mon, 29 Feb 2016 18:08:46 -0800 (PST) In-Reply-To: References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> Date: Mon, 29 Feb 2016 18:08:46 -0800 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Adrian Chadd To: Shawn Webb Cc: Peter Jeremy , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 02:08:47 -0000 And as a side note: people /actually/ want to see wifi happen on the raspberry pi 3 - don't bug me, bug the freebsd foundation. Please tell the foundation this. I've already had a handful of people email / facebook / gchat me asking me about it, and I hate to say "Sorry, I'm burnt out." :-) So yes, tell the foundation that this is an absolute hard requirement and let's see if we can get them to put up a bounty for it to get someone to do the work. -a From owner-freebsd-arm@freebsd.org Tue Mar 1 04:04:17 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 114D0AB8F03 for ; Tue, 1 Mar 2016 04:04:17 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A2EDF10F2 for ; Tue, 1 Mar 2016 04:04:15 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u2143gwk055520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 1 Mar 2016 05:03:53 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u2143Y1b063157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 1 Mar 2016 05:03:34 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u2143YnA060911; Tue, 1 Mar 2016 05:03:34 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u2143Wfb060910; Tue, 1 Mar 2016 05:03:32 +0100 (CET) (envelope-from ticso) Date: Tue, 1 Mar 2016 05:03:32 +0100 From: Bernd Walter To: Shawn Webb Cc: Peter Jeremy , freebsd-arm@freebsd.org Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160301040331.GB59803@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160301002249.GA61549@mutt-hardenedbsd> X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 04:04:17 -0000 On Mon, Feb 29, 2016 at 07:22:49PM -0500, Shawn Webb wrote: > On Tue, Mar 01, 2016 at 09:58:11AM +1100, Peter Jeremy wrote: > > Has anyone gotten close enough to a RPi3 to know how difficult it will be > > to get FreeBSD to run on it - in particular the Bluetooth and WiFi? > > Hey Peter, > > We at HardenedBSD have ordered ten of them, eight of which will be given > out for free at BSDCan. My hope is that we'll have FreeBSD running on > the RPI3 by the end of the conference. I'll also be at the FreeBSD > DevSummit and I hope that we'll have multiple late-night hackathons to > get it working. I think the most interesting point about this board is that it is a rather inexpensive arm64. That said, the remaining parameters don't match up for a 64bit system, so I guess it is just good for the purpose of doing arm64 as such. But from what I've read the official images for the board are just running a 32bit Linux kernel. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Tue Mar 1 04:42:34 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BECEFAB93BC for ; Tue, 1 Mar 2016 04:42:34 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 723B5671 for ; Tue, 1 Mar 2016 04:42:33 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id VAA03437; Mon, 29 Feb 2016 21:37:45 -0700 (MST) Message-Id: <201603010437.VAA03437@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Feb 2016 21:37:32 -0700 To: ticso@cicely.de, Shawn Webb From: Brett Glass Subject: Re: FreeBSD on the RaspberryPi 3 Cc: freebsd-arm@freebsd.org In-Reply-To: <20160301040331.GB59803@cicely7.cicely.de> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 04:42:34 -0000 At 09:03 PM 2/29/2016, Bernd Walter wrote: >I think the most interesting point about this board is that it is >a rather inexpensive arm64. I'm still waiting for a board in this category that has 2 GbE ports... or even one GbE port that can really, really run flat out at full capacity so that I could multiply it into more ports via a VLAN switch. Combined with the FreeBSD IP stack, this could be SUPER-useful. --Brett From owner-freebsd-arm@freebsd.org Tue Mar 1 04:51:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11E5DAB95EF for ; Tue, 1 Mar 2016 04:51:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0405B8DE; Tue, 1 Mar 2016 04:51:16 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 859F114CF; Tue, 1 Mar 2016 04:51:15 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Tue, 1 Mar 2016 04:51:13 +0000 From: Glen Barber To: Brett Glass Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160301045113.GN6870@FreeBSD.org> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZmZU9S7l/XJx5q9b" Content-Disposition: inline In-Reply-To: <201603010437.VAA03437@mail.lariat.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 04:51:16 -0000 --ZmZU9S7l/XJx5q9b Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 09:37:32PM -0700, Brett Glass wrote: > I'm still waiting for a board in this category that has 2 GbE ports... or > even one GbE port that can really, really run flat out at full capacity so > that I could multiply it into more ports via a VLAN switch. Combined with > the FreeBSD IP stack, this could be SUPER-useful. >=20 BananaPi has a GigE port. root@a20:~ # ifconfig dwc0 | grep media media: Ethernet autoselect (1000baseT ) Glen --ZmZU9S7l/XJx5q9b Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1R+8AAoJEAMUWKVHj+KTksgP/0LAobgJ8M1VGzc/bMQndxNc DsnwmpGrosAs9cwDzyNgyuElDmatXRHbp47bawqpaSSRjN/89Sq+7jsCeQxoZDs5 /j7KWkXo8tUHWk3fcrkr9bShCt7aofe/k0aX7disxqEsJ3uez/z0fzCdaMQdrCnm wCHioDBWu05/fMFUBEN5UWSo+mpglFl2269k6mXK5XUi7SOFdLwnR41PCJEPsjDu Y+2df/MzyFXsgqd7hkOlTfQaLTxKW2+BTJSnjLucNYfl8cIigg+QqndxndDu/x67 3YlbUvFZjnt/oPdb0Ez7osGK00zgakHlrGEcFcYudLeL1MIl8/q/fO9UtFQdWh5K D/cEH+dqwsS1rN1oU/XPqbYX+ztPPBGtEmdxNXfAC8AAniqjtm25EbBPWl/WnPsp TGjAhotzo+V67exO/cdN/LOasuKC7bXcZseUVxKq0c+HwuttEwqzdWwFsoCEQJoJ loiTZ33tl00N+W3/S13RpGKiI9kJoSO3/NL7GPivdl1Y56LHTSpIffmYtLiaRRwu nYsoADM1SDcONljCnL6u5YkBjK/tPGjf0tqZ58ZA2b7mOJ4opaA7WyIVjC0vkC7x D7rWTvCIYhpkWDYmu7clQMyC3h2nW03TVIUqBwgxyKwcTo3FRweJMy3WumXTQiQS zt4as5zffXLqhAlUd29X =IBdg -----END PGP SIGNATURE----- --ZmZU9S7l/XJx5q9b-- From owner-freebsd-arm@freebsd.org Tue Mar 1 04:57:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93D43AB97CB for ; Tue, 1 Mar 2016 04:57:06 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id 3EAB3AE1; Tue, 1 Mar 2016 04:57:05 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id VAA03570; Mon, 29 Feb 2016 21:57:02 -0700 (MST) Message-Id: <201603010457.VAA03570@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 29 Feb 2016 21:56:41 -0700 To: Glen Barber From: Brett Glass Subject: Re: FreeBSD on the RaspberryPi 3 Cc: freebsd-arm@FreeBSD.org In-Reply-To: <20160301045113.GN6870@FreeBSD.org> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <20160301045113.GN6870@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 04:57:06 -0000 At 09:51 PM 2/29/2016, Glen Barber wrote: >BananaPi has a GigE port. > > root@a20:~ # ifconfig dwc0 | grep media > media: Ethernet autoselect (1000baseT ) Indeed it does! But the SoC's internal bus can only drive it at about 300 Mbps. Try to push it to capacity and it drops packets. --Brett From owner-freebsd-arm@freebsd.org Tue Mar 1 05:04:05 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 49DD7AC397C for ; Tue, 1 Mar 2016 05:04:05 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EEA911CB9; Tue, 1 Mar 2016 05:04:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by freefall.freebsd.org (Postfix) with ESMTP id 63F26189F; Tue, 1 Mar 2016 05:04:04 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Date: Tue, 1 Mar 2016 05:04:02 +0000 From: Glen Barber To: Brett Glass Cc: freebsd-arm@FreeBSD.org Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160301050402.GO6870@FreeBSD.org> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <20160301045113.GN6870@FreeBSD.org> <201603010457.VAA03570@mail.lariat.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="YyxzkC/DtE3JUx8+" Content-Disposition: inline In-Reply-To: <201603010457.VAA03570@mail.lariat.net> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event X-PEKBAC-Definition: Problem Exists, Keyboard Between Admin/Computer User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 05:04:05 -0000 --YyxzkC/DtE3JUx8+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 09:56:41PM -0700, Brett Glass wrote: > At 09:51 PM 2/29/2016, Glen Barber wrote: >=20 > >BananaPi has a GigE port. > > > > root@a20:~ # ifconfig dwc0 | grep media > > media: Ethernet autoselect (1000baseT ) >=20 > Indeed it does! But the SoC's internal bus can only drive it at about 300= Mbps. > Try to push it to capacity and it drops packets. >=20 Hmm. Never noticed this, my arm test bench is on a VLAN with a 10/100 switch. It's still faster than 100Mb/s. :) Thanks for noting this. Glen --YyxzkC/DtE3JUx8+ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1SLCAAoJEAMUWKVHj+KT2VkP/3bz+Vp1zwLkl8bct4EWuB9q Bl8vHzVCGJar++NHOoAhYb4OkM1x7wdjuxw6UqFWahGGcK6qP9nYREkYRIHJIr/S w7YmI/IaTid8WsLByKqObIUzbcPKVQBYWBoAiNRN2B/9+iEBdtLwx9m90SCqgGyp eKoGwwuXNck7Qtn3AXaagP2BHfZ5+KoYGApg5mbmG32o/q9/feVjI0oVamjc4EWT GQmyvnZ632rzIMnbY0qKRD6pYvBkkqpVZBojirc/fHlIt6dr1yHMI92hL1iTs9+i 2sAvI44p/qJkTSPk3uQ0tLRN2f3Y5YCxn1+LAV63nKj58FonvYqTQI1bDTn5PzLU Se04UanKZIeTvfa3yH8sYTq7Km5mqXZTLl19bZ1NMOkw3erIUjwamlEOxIZcQWWN FQc+QUylT23lJwLDkzUfAQL3vbzBAf0pFBhGLYE2HRdJG31P+XPttF9jR63VpOYA XA9DhCW4XvArt1CaFaELXIQJSjeTQoKqAymT3kp9QuF9Gi3ZD4LFht5/JMF0rpTR UwIRZiKz+aVYW+GTa+vGxm9r6LS6qGJdhOIwvVmAI0XPH9cZVx7hbgykrq2ufH3p KlgS8xDa0LIR/usxA1qh8j/rqXzLT3tnyw+TYok/eY1ae7P7946YCPl89OIz9pfM /DMNMxTAUnj+5SP1n+Qo =9Yr4 -----END PGP SIGNATURE----- --YyxzkC/DtE3JUx8+-- From owner-freebsd-arm@freebsd.org Tue Mar 1 05:36:40 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5FC29AB91DC for ; Tue, 1 Mar 2016 05:36:40 +0000 (UTC) (envelope-from steve@sohara.org) Received: from uk1mail2513.mymailbank.co.uk (UK1MAIL2513-PERMANET.IE.mymailbank.co.uk [217.69.47.44]) by mx1.freebsd.org (Postfix) with ESMTP id D3D16110D for ; Tue, 1 Mar 2016 05:36:39 +0000 (UTC) (envelope-from steve@sohara.org) Received: from smtp.lan.sohara.org (UnknownHost [88.151.27.41]) by uk1mail2513-d.mymailbank.co.uk with SMTP; Tue, 1 Mar 2016 05:36:11 +0000 Received: from [192.168.63.1] (helo=steve.lan.sohara.org) by smtp.lan.sohara.org with smtp (Exim 4.86 (FreeBSD)) (envelope-from ) id 1aacyi-000GwP-Js for freebsd-arm@freebsd.org; Tue, 01 Mar 2016 05:36:12 +0000 Date: Tue, 1 Mar 2016 05:36:12 +0000 From: Steve O'Hara-Smith To: freebsd-arm@freebsd.org Subject: Re: FreeBSD on the RaspberryPi 3 Message-Id: <20160301053612.88fbae5f2db0c2d2661e36cc@sohara.org> In-Reply-To: <201603010437.VAA03437@mail.lariat.net> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> X-Mailer: Sylpheed 3.4.3 (GTK+ 2.24.29; amd64-portbld-freebsd10.1) X-Clacks-Overhead: "GNU Terry Pratchett" 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.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 05:36:40 -0000 On Mon, 29 Feb 2016 21:37:32 -0700 Brett Glass wrote: > At 09:03 PM 2/29/2016, Bernd Walter wrote: > > >I think the most interesting point about this board is that it is > >a rather inexpensive arm64. > > I'm still waiting for a board in this category that has 2 GbE > ports... or even one GbE port that can really, really run flat out > at full capacity so that I could multiply it into more ports via a > VLAN switch. Combined with the FreeBSD IP stack, this could be > SUPER-useful. The new Odroid C2 looks promising in that regard - it seems to be a well balanced and inexpensive arm64. -- Steve O'Hara-Smith From owner-freebsd-arm@freebsd.org Tue Mar 1 05:24:44 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7AF6ABC067 for ; Tue, 1 Mar 2016 05:24:43 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::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 B242D11BD for ; Tue, 1 Mar 2016 05:24:43 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-ob0-x232.google.com with SMTP id ts10so156733779obc.1 for ; Mon, 29 Feb 2016 21:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8qtSiEqCpUCHU3Wkum9XUSzPXsopO4/e6gOXot7MPcI=; b=GnZvKG0fWTqMb1ABWUIxKgEySwxlmpaaux6/dASGv6SOqCtxtkiJNNPdq9kOCr8NjP 4F71ScV+4OHqku5DS++KTR8jZhpGyW9ijHNeB9Es/Ny/fY6daGvtMPclBj5ZwGty9ATp 4oTyskLr/7Zmxqs8CBHVSItwVxMWRok5Dff9U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8qtSiEqCpUCHU3Wkum9XUSzPXsopO4/e6gOXot7MPcI=; b=ccp1Q2LJmM2obglMiPOmlLmMzMphduv/wCpk4Sc7nSBhAkVZ265qmmuhPAZR07D1nd ov17ufeZxwy6HVIuVqFMcw9OPq6wJ6sKwzDECCPHWekTYDJmgHfLZgxpQMFzL+KLHt8P FubnkYlt4cRMZUlWwvIpPxxwdBqHoAjnrrb1hWssdk3c6nTRgOMdXn/S9pkKIRmyzBpm uRRlLC9qdUEJQlWbTAet+nqt4s+MiTj1TNR90eNtfcSCVVoqy0Z9pE5bpHqTD635kTY3 KuUY8riig89Hugrc6QItJcX+5rAk1ACg+8dtySGJAShZ7KWTXmc7es7NgVlk3bjALD2y AX/w== X-Gm-Message-State: AD7BkJIyr725zhRz0IS1QiCuou5n1mLEoyH6sqv0C5KVFMXnM7O8mGyIhbnToKLGuYXzhA== X-Received: by 10.60.78.105 with SMTP id a9mr14620203oex.76.1456809882840; Mon, 29 Feb 2016 21:24:42 -0800 (PST) Received: from ?IPv6:2001:470:1f0f:281:35f2:b89a:8649:a5e1? ([2001:470:1f0f:281:35f2:b89a:8649:a5e1]) by smtp.gmail.com with ESMTPSA id qf5sm9006835obc.12.2016.02.29.21.24.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 21:24:41 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD on the RaspberryPi 3 From: Jim Thompson X-Mailer: iPhone Mail (13D15) In-Reply-To: <201603010437.VAA03437@mail.lariat.net> Date: Mon, 29 Feb 2016 23:24:40 -0600 Cc: ticso@cicely.de, Shawn Webb , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <638DC0E8-2126-4AE9-9A23-44794465B61D@netgate.com> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> To: Brett Glass X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 05:24:44 -0000 -- Jim > On Feb 29, 2016, at 10:37 PM, Brett Glass wrote: >=20 > At 09:03 PM 2/29/2016, Bernd Walter wrote: >=20 >> I think the most interesting point about this board is that it is >> a rather inexpensive arm64. >=20 > I'm still waiting for a board in this category that has 2 GbE ports... or e= ven one GbE port that can really, really run flat out at full capacity so th= at I could multiply it into more ports via a VLAN switch. Combined with the = FreeBSD IP stack, this could be SUPER-useful. This one has 3x GigEnet. One is connected to a switch, one to an SFP cage, o= ne to a RJ45. http://i.imgur.com/4CUMXyv.jpg It doesn't run FreeBSD, yet, but Semihalf just checked in a lot of work in f= or the SoC in Dec/Jan. So maybe soon. I don't plan to work on it much befor= e returning from AsiaBSDCon 2016.=20 This one (the one in front) is basically a Beaglebone Black: http://i.imgur.= com/plk1Iaf.jpg Not the two (3, really) port switch. It's intended to be an open source (hw &= sw) BMC. Thus the motherboard which serves as a dev platform for same.=20 With a bit of luck, I'll be able to show it running FreeBSD at ASIABSDCon 20= 16.=20 Maybe not fast enough for your (Brett's) wants though. I could certainly sp= in it into a small 2-port ARM board without too much effort. Internet of Thi= ngs w/FreeBSD? The Solid Run Clear Fog behind it (same as the first pic) certainly could, a= nd should run FreeBSD (11-CURRENT) (*) before BSDCan 2016.=20 The CZ.net Router Turris board has the same Marvell SoC S the SolidRun Clear= Fog series, but can be had for $99.=20 https://www.turris.cz/en/ I could certainly bring the two ClearFog Pro boards and the Router Turris bo= ard I have coming (April) to BSDCan if someone wants to hack/test. Jim * and pfSense... There may or may not be a future Netgate board of ... (ahem= ) similar construction. =20= From owner-freebsd-arm@freebsd.org Tue Mar 1 06:13:28 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BDEDCABE864 for ; Tue, 1 Mar 2016 06:13:28 +0000 (UTC) (envelope-from draymond@foxvalley.net) Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by mx1.freebsd.org (Postfix) with SMTP id 6DF8C9EA for ; Tue, 1 Mar 2016 06:13:27 +0000 (UTC) (envelope-from draymond@foxvalley.net) Received: (qmail 3034 invoked from network) for freebsd-arm@freebsd.org; 29 Feb 2016 23:46:47 -0600 Received: from 71-211-200-198.hlrn.qwest.net (HELO ?192.168.1.3?) (draymond@71.211.200.198) by mail.foxvalley.net with SMTP; 29 Feb 2016 23:46:47 -0600 Subject: Re: FreeBSD on the RaspberryPi 3 To: freebsd-arm@freebsd.org References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <20160301045113.GN6870@FreeBSD.org> <201603010457.VAA03570@mail.lariat.net> From: Dan Raymond Message-ID: <56D52CC7.9050804@foxvalley.net> Date: Mon, 29 Feb 2016 22:46:47 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <201603010457.VAA03570@mail.lariat.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 06:13:28 -0000 On 2/29/2016 9:56 PM, Brett Glass wrote: > At 09:51 PM 2/29/2016, Glen Barber wrote: > >> BananaPi has a GigE port. >> >> root@a20:~ # ifconfig dwc0 | grep media >> media: Ethernet autoselect (1000baseT ) > > Indeed it does! But the SoC's internal bus can only drive it at about > 300 Mbps. > Try to push it to capacity and it drops packets. The Odroid C2 has a Gigabit Ethernet port that runs at full speed. According to the iperf tests linked below it hits over 900 Mbit/sec on both reads and writes. http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438 From owner-freebsd-arm@freebsd.org Tue Mar 1 07:11:06 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 233A5ABBE94 for ; Tue, 1 Mar 2016 07:11:06 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-211-156.reflexion.net [208.70.211.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DA1311ED6 for ; Tue, 1 Mar 2016 07:11:05 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 22399 invoked from network); 1 Mar 2016 07:10:58 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 1 Mar 2016 07:10:58 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v7.80.0) with SMTP; Tue, 01 Mar 2016 02:10:50 -0500 (EST) Received: (qmail 32433 invoked from network); 1 Mar 2016 07:10:50 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with SMTP; 1 Mar 2016 07:10:50 -0000 X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network X-No-Relay: not in my network Received: from [192.168.1.8] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 460761C43C4; Mon, 29 Feb 2016 23:10:50 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: clang 3.8.0 can mess up __builtin_dwarf_cfa (), at least for TARGET_ARCH=armv6, powerpc, powerpc64: a bug 207325 update From: Mark Millard In-Reply-To: Date: Mon, 29 Feb 2016 23:10:56 -0800 Cc: freebsd-arm , FreeBSD PowerPC ML , FreeBSD Toolchain Content-Transfer-Encoding: quoted-printable Message-Id: References: <83B8741C-B4C9-4EFB-A3B4-473F8F165984@dsl-only.net> <80EA4460-E842-46F5-B006-2A83FBBEE845@dsl-only.net> <366B67F9-6A14-4906-8545-1B57A3FF53B8@dsl-only.net> <20160228083934.GA60222@vlakno.cz> <22AD8E4F-B3F2-455E-8EBE-2C70E428D44A@dsl-only.net> <462637FA-6FD2-4421-8F0C-0DF565E94FA6@dsl-only.net> <8D92D76D-9FBC-45F6-A20D-0C2A8B38D291@dsl-only.net> <33D5358F-6783-44C1-8155-86FB93CABE6F@dsl-only.net> <9DE18EC5-3C16-4B17-A0D0-5B5386961627@dsl-only.net> To: Roman Divacky X-Mailer: Apple Mail (2.2104) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 07:11:06 -0000 [TARGET_ARCH=3Dpowerpc context for all the evidence.] I found another clang++ 3.8.0 vs. g++ 4.2.1 difference where the system = libgcc_s depends on how it works for g++ 4.2.1 when clang 3.8.0 does not = work the same way: _Unwind_RaiseException is special in a way that makes it save and = restore lots of registers it does not directly use. (I'm not sure what = triggers having so many registers saved/restored.) But gcc/g++ 4.2.1 saves and restores more registers than clang/clang++ = 3.8.0 does. That in turn leaves .eh_frame information for more registers = for _Unwind_RaiseException for the gcc/g++ 4.2.1 context. _Unwind_RaiseException from a clang++ 3.8.0 build of libgcc_s does not = have save/restore for r3, r4, r5, r6, "r70" (from mfcr, dwarfdump = notation). The C++ exception handling library code in libgcc_s depends = on r3 (as one example). The pointer for r3 ends up being 0x0 and that = causes a crash in examples that get that far using the system's = libgcc_s. _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has = save/restore for r3, r4, r5, r6, "r70" (from mfcr). Later below I list one form of the specific evidence for the = differences. It may be that this and the __builtin_dwarf_cfa() "fix" covers all the = problems for when libstdc++/libsupc++ are involved with the system = libgcc_s instead of libc++/libcxxrt being involved. In my view the registers to save/restore in routines like = _Unwind_RaiseException should be considered as part of the overall ABI = criteria. Under the rule "the TARGET_ARCH=3Dpowerpc ABI is always such = that it is gcc/g++ 4.2.1 compatible", I take it that clang 3.8.0 is = wrong for FreeBSD TARGET_ARCH=3Dpowerpc here: Another ABI violation. TARGET_ARCH=3Dpowerpc64 and possibly others could have the same sort of = issue. I've never gotten a clang/clang++ based TARGET_ARCH=3Dpowerpc64 = as far as a complete buildworld. And for now I'm more interested in = finding new types of errors for TARGET_ARCH=3Dpowerpc rather then what = range of TARGET_ARCH's get a specific clang 3.8.0 problem. Separately from the above I've shown that copying the following 3 files = to a gcc 4.2.1 buildworld/buildkernel TARGET_ARCH=3Dpowerpc context = allows exception_test.clang++380.powerpc to run just fine: > exception_test.clang++380.powerpc > /usr/lib/libc++.so.1 > /lib/libcxxrt.so.1 (debug files for the libraries also copied) That leaves the following libraries listed by ldd as being from the gcc = 4.2.1 buildworld: > /lib/libm.so.5 > /lib/libc.so.7 > /lib/libgcc_s.so.1 > # ldd exception_test.clang++380.powerpc > exception_test.clang++380.powerpc: > libc++.so.1 =3D> /usr/lib/libc++.so.1 (0x4183e000) > libcxxrt.so.1 =3D> /lib/libcxxrt.so.1 (0x41917000) > libm.so.5 =3D> /lib/libm.so.5 (0x41942000) > libc.so.7 =3D> /lib/libc.so.7 (0x41979000) > libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x41b1d000) exception_test.clang++380.powerpc used with the clang 3.8.0 buildworld = and its libgcc_s shows different behavior not likely to be explained by = the _Unwind_RaiseException register save/restore differences. (The lack = of some saves/restores would still be a problem if I get = exception_test.clang++380.powerpc to get that far before doing something = odd.) I'm still trying to get evidence of the specific low-level problem for = exception_test.clang++380.powerpc. It may be some time before I figure = out anything useful. Using some dwarfdump -v -v -F output for the evidence of register = save/restore differences. . . _Unwind_RaiseException from a g++ 4.2.1 build of libgcc_s has r3, r4, = r5, r6, r70 (from mfcr). The library depends on r3 (as one example). > fde section offset 1104 0x00000450 cie offset for fde: 1108 = 0x00000454 > 0 DW_CFA_advance_loc 8 (8 * 1) > 1 DW_CFA_def_cfa_offset 3024 > 4 DW_CFA_advance_loc1 156 > 6 DW_CFA_offset r4 -232 (58 * -4) > 8 DW_CFA_offset r3 -236 (59 * -4) > 10 DW_CFA_offset r28 -160 (40 * -4) > 12 DW_CFA_offset r27 -164 (41 * -4) > 14 DW_CFA_offset r26 -168 (42 * -4) > 16 DW_CFA_offset r25 -172 (43 * -4) > 18 DW_CFA_offset r24 -176 (44 * -4) > 20 DW_CFA_offset r23 -180 (45 * -4) > 22 DW_CFA_offset r22 -184 (46 * -4) > 24 DW_CFA_offset r21 -188 (47 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r19 -196 (49 * -4) > 30 DW_CFA_offset r18 -200 (50 * -4) > 32 DW_CFA_offset r17 -204 (51 * -4) > 34 DW_CFA_offset r16 -208 (52 * -4) > 36 DW_CFA_offset r15 -212 (53 * -4) > 38 DW_CFA_offset r14 -216 (54 * -4) > 40 DW_CFA_offset r63 -8 (2 * -4) > 42 DW_CFA_offset r62 -16 (4 * -4) > 44 DW_CFA_offset r61 -24 (6 * -4) > 46 DW_CFA_offset r60 -32 (8 * -4) > 48 DW_CFA_offset r59 -40 (10 * -4) > 50 DW_CFA_offset r58 -48 (12 * -4) > 52 DW_CFA_offset r57 -56 (14 * -4) > 54 DW_CFA_offset r56 -64 (16 * -4) > 56 DW_CFA_offset r55 -72 (18 * -4) > 58 DW_CFA_offset r54 -80 (20 * -4) > 60 DW_CFA_offset r53 -88 (22 * -4) > 62 DW_CFA_offset r52 -96 (24 * -4) > 64 DW_CFA_offset r51 -104 (26 * -4) > 66 DW_CFA_offset r50 -112 (28 * -4) > 68 DW_CFA_offset r49 -120 (30 * -4) > 70 DW_CFA_offset r48 -128 (32 * -4) > 72 DW_CFA_offset r47 -136 (34 * -4) > 74 DW_CFA_offset r46 -144 (36 * -4) > 76 DW_CFA_register r70 =3D r12 > 79 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 82 DW_CFA_advance_loc 32 (32 * 1) > 83 DW_CFA_offset r5 -228 (57 * -4) > 85 DW_CFA_offset r31 -148 (37 * -4) > 87 DW_CFA_offset r30 -152 (38 * -4) > 89 DW_CFA_offset r29 -156 (39 * -4) > 91 DW_CFA_offset_extended r70 -220 (55 * -4) > 94 DW_CFA_offset r6 -224 (56 * -4) > 96 DW_CFA_nop > 97 DW_CFA_nop > 98 DW_CFA_nop _Unwind_RaiseException from clang++ 3.8.0 build of libgcc_s does not = have has r3, r4, r5, r6, r70 (from mfcr). The library depends on r3 (as = one example). > fde section offset 692 0x000002b4 cie offset for fde: 696 0x000002b8 > 0 DW_CFA_advance_loc 20 (5 * 4) > 1 DW_CFA_def_cfa_offset 2992 > 4 DW_CFA_offset r31 -148 (37 * -4) > 6 DW_CFA_offset r30 -152 (38 * -4) > 8 DW_CFA_offset_extended_sf r65 4 (-1 * -4) > 11 DW_CFA_advance_loc 4 (1 * 4) > 12 DW_CFA_def_cfa_register r31 > 14 DW_CFA_offset r14 -216 (54 * -4) > 16 DW_CFA_offset r15 -212 (53 * -4) > 18 DW_CFA_offset r16 -208 (52 * -4) > 20 DW_CFA_offset r17 -204 (51 * -4) > 22 DW_CFA_offset r18 -200 (50 * -4) > 24 DW_CFA_offset r19 -196 (49 * -4) > 26 DW_CFA_offset r20 -192 (48 * -4) > 28 DW_CFA_offset r21 -188 (47 * -4) > 30 DW_CFA_offset r22 -184 (46 * -4) > 32 DW_CFA_offset r23 -180 (45 * -4) > 34 DW_CFA_offset r24 -176 (44 * -4) > 36 DW_CFA_offset r25 -172 (43 * -4) > 38 DW_CFA_offset r26 -168 (42 * -4) > 40 DW_CFA_offset r27 -164 (41 * -4) > 42 DW_CFA_offset r28 -160 (40 * -4) > 44 DW_CFA_offset r29 -156 (39 * -4) > 46 DW_CFA_offset r30 -152 (38 * -4) > 48 DW_CFA_offset r31 -148 (37 * -4) > 50 DW_CFA_offset r46 -144 (36 * -4) > 52 DW_CFA_offset r47 -136 (34 * -4) > 54 DW_CFA_offset r48 -128 (32 * -4) > 56 DW_CFA_offset r49 -120 (30 * -4) > 58 DW_CFA_offset r50 -112 (28 * -4) > 60 DW_CFA_offset r51 -104 (26 * -4) > 62 DW_CFA_offset r52 -96 (24 * -4) > 64 DW_CFA_offset r53 -88 (22 * -4) > 66 DW_CFA_offset r54 -80 (20 * -4) > 68 DW_CFA_offset r55 -72 (18 * -4) > 70 DW_CFA_offset r56 -64 (16 * -4) > 72 DW_CFA_offset r57 -56 (14 * -4) > 74 DW_CFA_offset r58 -48 (12 * -4) > 76 DW_CFA_offset r59 -40 (10 * -4) > 78 DW_CFA_offset r60 -32 (8 * -4) > 80 DW_CFA_offset r61 -24 (6 * -4) > 82 DW_CFA_offset r62 -16 (4 * -4) > 84 DW_CFA_offset r63 -8 (2 * -4) > 86 DW_CFA_nop =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-29, at 3:20 AM, Mark Millard wrote: TARGET_ARCH=3Dpowerpc: Using Frame Depth 1 in "case = Intrinsic::eh_dwarf_cfa" (and Offset 0 in "case = Builtin::BI__builtin_dwarf_cfa") for PPCTargetLowering::LowerFRAMEADDR = related use has allowed getting into _Unwind_RaiseException_Phase2 and = __cxxabiv1::__gxx_personality_v0. The example is the 8 line example = compiled under g++ 4.2.1 but then used under a buildworld that was built = with clang 3.8.0: # ldd exception_test.g++421.powerpc=20 exception_test.g++421.powerpc: libstdc++.so.6 =3D> /usr/local/lib/gcc49/libstdc++.so.6 = (0x41840000) libm.so.5 =3D> /lib/libm.so.5 (0x4196a000) libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x419a1000) libc.so.7 =3D> /lib/libc.so.7 (0x419c0000) _Unwind_RaiseException_Phase2 is well past the point of the failure and = crash from having Frame Depth 0 instead. It is getting a SEGV during the _Unwind_SetGR called via: 710 /* For targets with pointers smaller than the word size, we = must extend the 711 pointer, and this extension is target dependent. */ 712 _Unwind_SetGR (context, __builtin_eh_return_data_regno (0), 713 __builtin_extend_pointer (ue_header)); for: _Unwind_SetGR (context=3D0xffffd570, index=3D3, val=3D1105272896) at = /usr/src/gnu/lib/libgcc/../../../contrib/gcc/unwind-dw2.c:207 context->reg[3] is 0x0 and so its use in the following gets the SEGV. 217 ptr =3D context->reg[index]; 218=09 219 if (size =3D=3D sizeof(_Unwind_Ptr)) 220 * (_Unwind_Ptr *) ptr =3D val; I'm not going to try to analyze the source of this before getting some = sleep. For the 8 line program being compiled by clang++ 3.8.0 instead the = results are different than the above and than the original behavior: The = program does not crash abnormally but also does not find the catch = clause that it should. The std::terminate gets its normal SIGABRT = instead of an earlier SEGV. Again I'm not going to try to analyze the details before getting some = sleep. But I will mention that I've also already submitted a report that = libgcc_s does not completely implement DW_CFA_remember_state and = DW_CFA_restore_state and that the code generated on powerpc64 touches = the defect and so ends up with misbehavior. These might be similar. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 10:13 PM, Mark Millard = wrote: Back to the "case Builtin::BI__builtin_dwarf_cfa" and = "PPCTargetLowering::LowerFRAMEADDR" context: I made the wrong change and need to retry. The detail. . . Passing a 1 through instead of zero did not do what I expected to the = code generated. Instead it added one instruction: addi r3,r3,1 resulting in (objdump -d --prefix-addresses on the .o): > Disassembly of section .text: > 00000000 <_Z1fv> mflr r0 > 00000004 <_Z1fv+0x4> stw r31,-4(r1) > 00000008 <_Z1fv+0x8> stw r0,4(r1) > 0000000c <_Z1fv+0xc> stwu r1,-16(r1) > 00000010 <_Z1fv+0x10> mr r31,r1 > 00000014 <_Z1fv+0x14> mr r3,r31 > 00000018 <_Z1fv+0x18> addi r3,r3,1 > 0000001c <_Z1fv+0x1c> bl 0000001c <_Z1fv+0x1c> > 00000020 <_Z1fv+0x20> addi r1,r1,16 > 00000024 <_Z1fv+0x24> lwz r0,4(r1) > 00000028 <_Z1fv+0x28> lwz r31,-4(r1) > 0000002c <_Z1fv+0x2c> mtlr r0 > 00000030 <_Z1fv+0x30> blr In other words: it added the 1 as a byte offset like the comments that I = thought were wrong said. Since it does not appear that PPCTargetLowering::LowerFRAMEADDR would do = that with a 1 I conclude that PPCTargetLowering::LowerFRAMEADDR is not = involved with that figure. So looking around. . . /usr/src/contrib/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp = has: > case Intrinsic::eh_dwarf_cfa: { > SDValue CfaArg =3D DAG.getSExtOrTrunc(getValue(I.getArgOperand(0)), = sdl, > = TLI.getPointerTy(DAG.getDataLayout())); > SDValue Offset =3D DAG.getNode(ISD::ADD, sdl, > CfaArg.getValueType(), > DAG.getNode(ISD::FRAME_TO_ARGS_OFFSET, = sdl, > CfaArg.getValueType()), > CfaArg); > SDValue FA =3D DAG.getNode( > ISD::FRAMEADDR, sdl, TLI.getPointerTy(DAG.getDataLayout()), > DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))); > setValue(&I, DAG.getNode(ISD::ADD, sdl, FA.getValueType(), > FA, Offset)); > return nullptr; And so sure enough the argument is an offset as used by this code. And what I call the frame depth is plugged in as 0 here via = "DAG.getConstant(0, sdl, TLI.getPointerTy(DAG.getDataLayout()))". The = offset is applied after getting the frame address. So I get to revert my change and try again changing the above call to = use a 1 instead. It does not look like this changes the time frames in my history notes: = it has been using frame depth zero since V2.7 when "case = Builtin::BI__builtin_dwarf_cfa" appeared. In general my overall questions about the target triple controlling = which value to use (in DAG.getConstant hrere) still apply: It is not = obvious that something that has been using frame depth 0 since V2.7 can = be immediately changed to frame depth 1 for all contexts. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 8:49 PM, Mark Millard wrote: Here is what the "ABI for the ARM 32 32-bit Architecture" "DWARF for the = ARM Architecture" document says about the CFA: > 3.4 Canonical Frame Address >=20 > The term Canonical Frame Address (CFA) is defined in [GDWARF], =C2=A76.4= , Call Frame Information. This ABI adopts the typical definition of CFA = given there. > =EF=81=AF The CFA is the value of the stack pointer (r13) at the call = site in the previous frame. This, with the armv6 code I've shown via "objdump -d", indicates that = for armv6 clang++'s __builtin_dwarf_cfa() return value is not the same = value as the official ARM ABI indicates. It also indicates that what g++ = returns does match the official ARM ABI. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 5:40 PM, Mark Millard wrote: Looking some at clang/llvm history shows releases/branches: V2.6 did not have "case Builtin::BI__builtin_dwarf_cfa". V2.7 did have "case Builtin::BI__builtin_dwarf_cfa" but = PPCTargetLowering::LowerFRAMEADDR ignored the argument. V2.8 had PPCTargetLowering::LowerFRAMEADDR using its argument (as a = frame depth, not a byte offset). The apparently incorrect (not matching g++ frame depth returned) = comments, naming, and value (when viewed as a frame depth) for "case = Builtin::BI__builtin_dwarf_cfa" started in V2.7 and continues to this = day. That is a lot of time for various dependencies on the clang = (mis)definition to accumulate across everything that uses clang. It may be that limiting any change to specific TARGET_ARCH's for FreeBSD = is appropriate. FreeBSD would likely need to list the appropriate = TARGET_ARCH's, likely including powerpc and powerpc64 since clang before = 3.8.0 was not in use for buildworld for powerpc/powerpc64. Still this may have consequences for ports that use clang and might = reference clang-compiled __builtin_dwarf_cfa() use, possibly from a = lang/clang* instead of the system clang. My guess is that the = interoperability with being able to use g++ vintages as well may lead to = (modern?) lang/clang*'s tracking the fix for FreeBSD TARGET_ARCH's that = are fixed. I can ignore all this and build a system based on using 1 as the frame = depth just to test, just as a matter of proof of concept for powerpc. = (Powerpc64 hits a system libgcc_s defect and so needs more before C++ = exceptions can be tested overall.) =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:20 PM, Mark Millard wrote: In /usr/src/contrib/llvm/tools/clang/lib/CodeGen/CGBuiltin.cpp there is: > case Builtin::BI__builtin_dwarf_cfa: { > // The offset in bytes from the first argument to the CFA. > // > // Why on earth is this in the frontend? Is there any reason at > // all that the backend can't reasonably determine this while > // lowering llvm.eh.dwarf.cfa()? > // > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; >=20 > Value *F =3D CGM.getIntrinsic(Intrinsic::eh_dwarf_cfa); > return RValue::get(Builder.CreateCall(F, > llvm::ConstantInt::get(Int32Ty, = Offset))); > } I would have guessed that the internal argument was how many frames away = on the stack to go from what 0 produces (high er address direction). = g++'s __builtin_dwarf_cfa() returns the address for the next frame = compared to clang 3.8.0 (higher address direction). I'd call that more of a frame depth than an offset. .eh_frame and its = cfa material use offset terminology as byte offsets. And the comments = above talk of an offset in bytes --but "next frame" distances in bytes = would not be constant. Looking at a use of LowerFRAMEADDR in a LowerRETURNADDR, for example, > SDValue ARMTargetLowering::LowerRETURNADDR(SDValue Op, SelectionDAG = &DAG) const{ > . . . > EVT VT =3D Op.getValueType(); > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); > if (Depth) { > SDValue FrameAddr =3D LowerFRAMEADDR(Op, DAG); > SDValue Offset =3D DAG.getConstant(4, dl, MVT::i32); > return DAG.getLoad(VT, dl, DAG.getEntryNode(), > DAG.getNode(ISD::ADD, dl, VT, FrameAddr, Offset), > MachinePointerInfo(), false, false, false, 0); > } > . . . > } (PPCTargetLowering::LowerRETURNADDR is similar.)=20 This has a mix of Depth and Offset overall, with the depth going to = LowerFRAMEADDR via Op but Offset used later in GAG.getLoad via adding to = the FrameAddr. This would lead me to guess that the terminology and comments in "case = Builtin::BI__builtin_dwarf_cfa" are wrong and that the = Builder.CreateCall has been given a frame depth, not an offset. > SDValue PPCTargetLowering::LowerFRAMEADDR(SDValue Op, > SelectionDAG &DAG) const { > SDLoc dl(Op); > unsigned Depth =3D = cast(Op.getOperand(0))->getZExtValue(); >=20 > MachineFunction &MF =3D DAG.getMachineFunction(); > MachineFrameInfo *MFI =3D MF.getFrameInfo(); > MFI->setFrameAddressIsTaken(true); >=20 > EVT PtrVT =3D = DAG.getTargetLoweringInfo().getPointerTy(MF.getDataLayout()); > bool isPPC64 =3D PtrVT =3D=3D MVT::i64; >=20 > // Naked functions never have a frame pointer, and so we use r1. For = all > // other functions, this decision must be delayed until during PEI. > unsigned FrameReg; > if (MF.getFunction()->hasFnAttribute(Attribute::Naked)) > FrameReg =3D isPPC64 ? PPC::X1 : PPC::R1; > else > FrameReg =3D isPPC64 ? PPC::FP8 : PPC::FP; >=20 > SDValue FrameAddr =3D DAG.getCopyFromReg(DAG.getEntryNode(), dl, = FrameReg, > PtrVT); > while (Depth--) > FrameAddr =3D DAG.getLoad(Op.getValueType(), dl, DAG.getEntryNode(), > FrameAddr, MachinePointerInfo(), false, false, > false, 0); > return FrameAddr; > }=20 Again Op is called Depth --and is used to get from one frame pointer = value to the next: a frame depth. To match g++ 4.2.1 the value to use is 1 for depth. Overall, at least applied to powerpc/powerpc64: > . . . > // TODO: If there's a satisfactory reason, add a target hook for > // this instead of hard-coding 0, which is correct for most targets. > int32_t Offset =3D 0; I think the comments in this area are actually talking about byte = offsets, not depths and are just wrong. A byte offset of 0 would make = sense relative to hardcoding but the value is actually a frame depth --a = very different context. I think that the naming of the variable is just wrong: it should be = called Depth. And I think that the comments should have originally talked about using = a hard coded Depth 1 to match g++ and preexisting library usage of = __builtin_dwarf_cfa() for C++ and other exception handling (.eh_frame = usage). ANd the code should avhe matched. As far as I can tell this error in the "case = Builtin::BI__builtin_dwarf_cfa:" design was not caught until now. But since the mess has been around a longtime just switching everything = to match the g++ context now likely has its own problems. (Not just a = FreeBSD issue.) For FreeBSD I expect that Depth 1 could be used for powerpc and = powerpc64: if it has been wrong for a long time (not just 3.8.0) then = powerpc/powerpc64 FreeBSD has likely been broken for C++ exception = handling when buildworld was via clang for just as long. (But only = recently has clang gotten this near working for buildworld for at least = one of powerpc/powerpc64. Currently powerpc is closer, given that = powerpc64 does not support softfloat last I knew.) For other TARGET_ARCH's: For FreeBSD armv6 it is less clear to me: it is based on clang as it is = and I do not know what C++ exception ABI it uses. If a modern gcc/g++ = buildworld had problems with C++ exception handling, does anything need = to be done about it? For FreeBSD armv6 and the like: is xtoolchain like = support important? FreeBSD may have similar questions for other TARGET_ARCH's. =3D=3D=3D Mark Millard markmi at dsl-only.net On 2016-Feb-28, at 2:46 AM, Mark Millard wrote: On 2016-Feb-28, at 12:39 AM, Roman Divacky = wrote: >=20 > Mark, >=20 > __builtin_dwarf_cfa() is lowered in clang to llvm intrinsic = eh_dwarf_cfa. > There's a depth argument (which defaults to 0, saying it's correct for = most > targets).=20 >=20 > Then the intrinsic gets lowered in SelectionDAG using > PPCTargetLowering::LowerFRAMEADDR() >=20 >=20 > Can you check that 1) the depth should be 0 for ppc64/ppc32 2) that > LowerFRAMEADDR() does something sensible? >=20 > There's a loop depth-times, so I wonder if that makes a difference. >=20 > Thanks, Roman "Lowered"? I'm not familiar with the clang code base or its terminology. = Handed off to a lower level interface, may be? As near as I can tell libgcc_s could be made to deal with clang 3.8.0's = way of __builtin_dwarf_cfa() working for powerpc/powerpc64. But then use = with g++ would be broken on powerpc/powerpc64 unless there were some = sort of live "which compiler's type of code" test also involved. Having only one libgcc_s and multiple compilers using it for a given = TARGET_ARCH=3D (for example, devel/powerpc64-xtoolchain-gcc like uses) = suggests sticking to one convention per TARGET_ARCH=3D for = __builtin_dwarf_cfa(). I would guess that g++ conventions win in this type of context for = FreeBSD, under the guideline of trying to be gcc 4.2.1 "ABI" compatible. = libgcc_s from FreeBSD works for C++ exceptions with its gcc 4.2.1 for = powerpc and powerpc64 as things are as far as I know. But for clang++ FreeBSD is one context among many and other libraries = may be based on clang 3.8.0's existing interpretation, without gcc/g++ = compatibility constraints. (I've no experience with earlier clang = vintages for the issue.) It may be that any change needs to be FreeBSD = target-triple specific for all I know. In essence: making the convention = part of the ABI chosen. I'll probably get some sleep before looking much at the code that you = reference. A quick look at part of it suggests a fair amount of = research/study for me to interpret things reliably. The loop may be somewhat analogous to _Unwind_RaiseException's loop, but = for a specific depth. I would currently guess that depth 1 would match = gcc 4.2.1's result for __builtin_dwarf_cfa(). But there was also some other "address"(?) builtin support routine = nearby that seemed to call into LowerFRAMEADDR() and I've no clue if g++ = 4.2.1 uses the same depth-figure standard for both sorts of things or = not. For all I know both types of builtins(?) might have mismatches with = gcc/g++ 4.2.1 and both might need fixes. I do vaguely remember seeing a builtin in FreeBSD code for something = that had an explicit number in the argument list, possibly = __builtin_frame_address(n)(?). But I only saw __builtin_dwarf_cfa() with = no argument in the argument list as far as I remember. If clang 3.8.0 and gcc 4.2.1 disagreed about what the numbering standard = referred to for __builtin_frame_address(n) (or whatever it was), that = would not be good and compatibility would imply conversions between the = conventions for the 2 FreeBSD contexts. I have not checked for armv6 related clang++ vs. g++ compatibility for = C++ exception-handling. If anything is not operating for that context I = expect that it would be g++ that generated buildworld code that did not = work based on the FreeBSD source code: clang/clang++ is the normal = compiler and kyua seemed to operate, unlike on the powerpc/powerpc64. I've never tried to build armv6 via an equivalent of = devel/powerpc64-gcc. I do not know if armv6 even uses the same sort of = C++ exception-handling ABI or not. But I do know that = __builtin_dwarf_cfa() is not compatible between clang++ and g++ from the = 2-line source and comparing objdump -d results. So more than powerpc/powerpc64 might be involved overall. =3D=3D=3D Mark Millard markmi at dsl-only.net From owner-freebsd-arm@freebsd.org Tue Mar 1 06:56:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9B8FCABB0E7 for ; Tue, 1 Mar 2016 06:56:22 +0000 (UTC) (envelope-from martin@waschbuesch.de) Received: from relay.waschbuesch.it (relay.waschbuesch.it [IPv6:2a00:cba0:0:100::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.waschbuesch.it", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5D2931A82 for ; Tue, 1 Mar 2016 06:56:22 +0000 (UTC) (envelope-from martin@waschbuesch.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=waschbuesch.de; s=dkim; h=To:References:Message-Id: Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type; bh=FTLte7xs5DsLBRm9y7kPo6ogpxJNR2JyO6PDrD6v0d0=; b=OxbNWPI1UvyE 58fneRj+TPu4fHbGxNadWVL9QjkhaLBw8AtWVQAKRG6Bt+27FMiUcxiTATITSzJJrobJcBjZQJt6/ MsrlZe+HGncRF9Jfs63Ok5jjkdkAQuRRNwR3YJnjGHytAjaShHgP97ELGQlljl8u/g9DemSNlPdCr Evb+o=; Received: by relay.waschbuesch.it with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim) (envelope-from ) id 1aaeEC-0003Rj-QR for freebsd-arm@freebsd.org; Tue, 01 Mar 2016 06:56:16 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: FreeBSD on Utilite (revisited) From: =?utf-8?Q?Martin_Waschb=C3=BCsch?= In-Reply-To: Date: Tue, 1 Mar 2016 07:56:16 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8262C265-A9F6-4336-9A33-4A97BE7451F6@waschbuesch.de> <6531E2F1-0682-4220-B148-BA7061C50B79@waschbuesch.de> <20160229062941.4374611.32643.3487@gmail.com> To: freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 06:56:22 -0000 > Am 29.02.2016 um 08:49 schrieb Oleksandr Tymoshenko = : >=20 >>=20 >> On Feb 28, 2016, at 11:18 PM, Martin Waschb=C3=BCsch = wrote: >>=20 >>=20 >>> Am 29.02.2016 um 07:29 schrieb Russell Haley : >>>=20 >>> It seems compulab's imx6 som is called the CM-FX6. There are some = imx6-cm-fx6 and imx6q-cm-fx6 files in their linux kernel on github? >>>=20 >>> = =E2=80=8Ehttps://github.com/utilite-computer/linux-kernel/tree/utilite/dev= el/arch/arm/boot/dts >>=20 >> Thank you, Russ. >>=20 >> There already is a dts file for the cm-fx6 in the FreeBSD kernel = sources >> for instance /usr/src/sys/gnu/dts/arm/imx6q-cm-fx6.dts >>=20 >> However, the same is true for the Wandboard >> /usr/src/sys/gnu/dts/arm/imx6qdl-wandboard.dtsi >> and yet, Crochet uses the files found under >> /usr/src/sys/boot/fdt/dts/arm/ >=20 > In early days of FDT support number of supported ARM boards was really > small and people tended to write their own DTS files from the scratch, > instead of using ones from Linux due to licensing concerns. These > DTS files were placed to boot/dts/fdt. As number of supported hardware > grew it became clear that this practice is a dead end, we can't keep > up with changes provided by vendors. So after some research it was > concluded that we can bring DTS files from Linux. I don't remember > exact reasoning but the gist of it: they're not code, they're set=20 > of facts about hardware. "Upstream" files were placed to gnu/dts. >=20 > Some of the files in boot/dts/fdt are just wrappers around > vendor-provided dts/dtsi files, fixing Linux-specific=20 > idiosyncrasies or adding new nodes. for instances, there > is no PRUSS node in Linux DTS for beaglebone, but=20 > boot/fdt/dts/arm/beaglebone-common.dtsi adds it. >=20 > You should be able to use .dts file in either directory, build system > checks boot/fdt first and then gnu/ AFAIR.=20 Thanks for that explanation. This makes sense now. >>=20 >> So, I went with the wandboard-quad.dts file from there, seeing as it = should be quite similar to my Utilite Pro. >> So far, no luck. Once the loader slurps in the compiled .dtb, the = system hangs with no further sign of activity. >=20 >=20 > Check stdout/stderr settings in =E2=80=9Cchosen=E2=80=9D node. Looks = like > imx6q-cm-fx6.dts uses UART4 for serial output while Wandboard=20 > quad uses UART0. That is a valuable piece of information, thanks! I also noticed that for IMX6 kernel config, ROOTDEV is hardcoded. Maybe = I am overlooking something, but why go to all the length of making sure = u-boot runs and loads ubldr to have loader capabilities and then not = specify the desired rootdev via loader but compile it into the kernel? Obviously, I do not know if the Wandboard supports it, but the Utilite = can boot from either mmc, usb or msata.= From owner-freebsd-arm@freebsd.org Tue Mar 1 09:00:17 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DC438ABDBA5 for ; Tue, 1 Mar 2016 09:00:17 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A29461FB2 for ; Tue, 1 Mar 2016 09:00:17 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ob0-x22f.google.com with SMTP id jj9so8730951obb.3 for ; Tue, 01 Mar 2016 01:00:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=n6VWepyS9D9obrWRpPbOxAAjeoX2SpCEEFAcueRpI64=; b=RZcOUjEVS9TcFAOzvGBdHdPh7VF6UeTrns3NpLts3agA+vT/N5gW56IIAdDa4f/Dzh YG8Yo1192DNXH0DDue1hYAiZS/bA/4Rv3rUSK++NthZ9U0YCUMyiPoYCTfDZUpwpuVKC lpk0RX3bnwQdrbzlW307c9tNXTRskbQFnFwWMHqB0WgsJV+OpzWujYmtAivfNl0NbE5d MZnLqzIeqrssV/h4WEJnLX+pj6C9AotwdDkn7CPF285bhWkq4ts4BK96jYbCkq6pUPaa z0C+j9YISbW1i8P2e6evRfp/tqHfDm6tvPIGYWxsAX4NErVrnZPJuIECBpIxXt4WX/nh yicQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=n6VWepyS9D9obrWRpPbOxAAjeoX2SpCEEFAcueRpI64=; b=m88bZsvZepXPHuf/qGDb/qaLuSq/ZsbXUudiCLVUIZdCteapcnHP1jkSg3bxqtTDWm +pFf4cnXH7ouggVjsGQaAawn+ImxQfi01Zpm4+VJZG5nqGfkyZK8t4D1rUzm1aX21q7I wjL9LUya8uIR+hNFEpmYqUPwifRKR15kvMfRAWKmaHCCvqRO0BlJA8FaDijKKZslWCNS Ozs8G/KhPGz89xTs4Y6atlNTsof6Y5wATEurNsoFXZqdcr8/urx4GNAYSQdfctdTXzps pW5bzxrFKTiaVC3Njqoq+W3F8yx5jGIrut3qqlOEJN1J0n4XajJWUhDMNpRB7wV+Qn7E puLA== X-Gm-Message-State: AD7BkJLmUbIe91KyI+AAbzz/O02kxhsUbik7M8neVIM+vtSZPzbzqjdvpuX6/+pPHC8zgpqpb4Q6oFTSVCIQ5A== MIME-Version: 1.0 X-Received: by 10.182.158.42 with SMTP id wr10mr15035147obb.37.1456822816731; Tue, 01 Mar 2016 01:00:16 -0800 (PST) Received: by 10.182.133.101 with HTTP; Tue, 1 Mar 2016 01:00:16 -0800 (PST) In-Reply-To: <638DC0E8-2126-4AE9-9A23-44794465B61D@netgate.com> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <638DC0E8-2126-4AE9-9A23-44794465B61D@netgate.com> Date: Tue, 1 Mar 2016 17:00:16 +0800 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Ganbold Tsagaankhuu To: Jim Thompson Cc: Brett Glass , freebsd-arm , "ticso@cicely.de" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 09:00:18 -0000 On Tue, Mar 1, 2016 at 1:24 PM, Jim Thompson wrote: > > > > > -- Jim >> On Feb 29, 2016, at 10:37 PM, Brett Glass wrote: >> >> At 09:03 PM 2/29/2016, Bernd Walter wrote: >> >>> I think the most interesting point about this board is that it is >>> a rather inexpensive arm64. >> >> I'm still waiting for a board in this category that has 2 GbE ports... o= r even one GbE port that can really, really run flat out at full capacity s= o that I could multiply it into more ports via a VLAN switch. Combined with= the FreeBSD IP stack, this could be SUPER-useful. > > This one has 3x GigEnet. One is connected to a switch, one to an SFP cage= , one to a RJ45. http://i.imgur.com/4CUMXyv.jpg > > It doesn't run FreeBSD, yet, but Semihalf just checked in a lot of work i= n for the SoC in Dec/Jan. So maybe soon. I don't plan to work on it much b= efore returning from AsiaBSDCon 2016. > > This one (the one in front) is basically a Beaglebone Black: http://i.img= ur.com/plk1Iaf.jpg Nice. I wish there could be an ARM board (with 2-3 Ethernet ports (Gigabit or Fast Ethernet)) which costs less than 100$, maybe 50$-60$ but powerful and fast enough to do some SSL encryption/decryption for small home network appliance. Ganbold > > Not the two (3, really) port switch. It's intended to be an open source (= hw & sw) BMC. Thus the motherboard which serves as a dev platform for same= . > > With a bit of luck, I'll be able to show it running FreeBSD at ASIABSDCon= 2016. > > Maybe not fast enough for your (Brett's) wants though. I could certainly= spin it into a small 2-port ARM board without too much effort. Internet of= Things w/FreeBSD? > > The Solid Run Clear Fog behind it (same as the first pic) certainly could= , and should run FreeBSD (11-CURRENT) (*) before BSDCan 2016. > > The CZ.net Router Turris board has the same Marvell SoC S the SolidRun Cl= earFog series, but can be had for $99. > > https://www.turris.cz/en/ > > I could certainly bring the two ClearFog Pro boards and the Router Turris= board I have coming (April) to BSDCan if someone wants to hack/test. > > Jim > > * and pfSense... There may or may not be a future Netgate board of ... (a= hem) similar construction. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Mar 1 11:02:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 02C2CABD809 for ; Tue, 1 Mar 2016 11:02:37 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.0x20.net", Issuer "mail.0x20.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B91721AD7 for ; Tue, 1 Mar 2016 11:02:36 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id CA6C06DF91B; Tue, 1 Mar 2016 12:02:33 +0100 (CET) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.7/8.14.7) with ESMTP id u21B2XDn007733; Tue, 1 Mar 2016 12:02:33 +0100 (CET) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.7/8.14.7/Submit) id u21B2VmY005844; Tue, 1 Mar 2016 12:02:31 +0100 (CET) (envelope-from lars) Date: Tue, 1 Mar 2016 12:02:31 +0100 From: Lars Engels To: Ganbold Tsagaankhuu Cc: Jim Thompson , freebsd-arm , "ticso@cicely.de" Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160301110231.GH20687@e-new.0x20.net> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <638DC0E8-2126-4AE9-9A23-44794465B61D@netgate.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HZmXSWY/1Xf1kK7R" Content-Disposition: inline In-Reply-To: X-Editor: VIM - Vi IMproved 7.4 X-Operation-System: FreeBSD 8.4-RELEASE-p23 User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:02:37 -0000 --HZmXSWY/1Xf1kK7R Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 01, 2016 at 05:00:16PM +0800, Ganbold Tsagaankhuu wrote: > On Tue, Mar 1, 2016 at 1:24 PM, Jim Thompson wrote: > > > > > > > > > > -- Jim > >> On Feb 29, 2016, at 10:37 PM, Brett Glass wrote: > >> > >> At 09:03 PM 2/29/2016, Bernd Walter wrote: > >> > >>> I think the most interesting point about this board is that it is > >>> a rather inexpensive arm64. > >> > >> I'm still waiting for a board in this category that has 2 GbE > >> ports... or even one GbE port that can really, really run flat out > >> at full capacity so that I could multiply it into more ports via a > >> VLAN switch. Combined with the FreeBSD IP stack, this could be > >> SUPER-useful. > > > > This one has 3x GigEnet. One is connected to a switch, one to an SFP > > cage, one to a RJ45. http://i.imgur.com/4CUMXyv.jpg > > > > It doesn't run FreeBSD, yet, but Semihalf just checked in a lot of > > work in for the SoC in Dec/Jan. So maybe soon. I don't plan to work > > on it much before returning from AsiaBSDCon 2016. > > > > This one (the one in front) is basically a Beaglebone Black: http://i.i= mgur.com/plk1Iaf.jpg >=20 > Nice. I wish there could be an ARM board (with 2-3 Ethernet ports > (Gigabit or Fast Ethernet)) which costs less than 100$, maybe 50$-60$ > but powerful and fast enough to do some SSL encryption/decryption for > small home network appliance. The Banana Pi Router Board? http://www.banana-pi.com/eacp_view.asp?id=3D64 --HZmXSWY/1Xf1kK7R Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQF8BAEBCgBmBQJW1XbGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4RjQwMDE3RTRERjUzMTI1N0FGRTUxNDlF NTRDQjM3RDNBMDg5RDZEAAoJEOVMs306CJ1t1okIALlrdi0Fhs0p3gIAlu/sQyR2 ARznkhPABUmJVnx0c1YUB/3dKrjFhiZGlfuzUvEjwunHVuarqdbO+bpWiVsXgyp1 mcPZx8cUJKPhzfMnzKDw0lvD6liHSBIg1tsTDg830CBZd7CZpMMkfeO3W6dGJc9b TGU+ko+BODslOEpNqr3nsedgrdYv5PQMNDy/HixLILAAV12V98h1MoeR2GSN+u4y AEnobe5u+Oi6Gvm+WQz9TOSPC/gN9rdTYFg4mdGAqkx+E+RjbB+QZ0ydcCSSzNL8 2ROc1yRr6qQsNHbhgTNdJ2yvmRusY2Yk7f2CkPqXe/A3t7EgMt3fStT8RR/9Phc= =Odiy -----END PGP SIGNATURE----- --HZmXSWY/1Xf1kK7R-- From owner-freebsd-arm@freebsd.org Tue Mar 1 11:04:17 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B7BCABD867 for ; Tue, 1 Mar 2016 11:04:17 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::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 2FB171B5A for ; Tue, 1 Mar 2016 11:04:17 +0000 (UTC) (envelope-from ganbold@gmail.com) Received: by mail-ob0-x233.google.com with SMTP id xx9so49649774obc.2 for ; Tue, 01 Mar 2016 03:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=k18PEYFdpuxIJBRvKPg1C0xDCEgmjXEkUYxxGnhFhM8=; b=Ajqj4w0C/xzK5zDvBoW1pnvJiMHe1eobX7nSAxa1oXRFFcODsWdf/LGmfzbv/PeLlo E4TaGAfkQbexoKwhP4I/P26Fx8cO5cCR/GI/C5yLiFM0WXsRGGiXEgz8Q5vLsxG5FCUD EnPCSjoaUEfvFXOlleiLz15OCiQJkDGWPahnME78Nrtw59DJ4z7Wlq/J+rFzu7buvxOa KNHbivoJVTbr++tEL/47WURgBlaYw8M9lEnJujhM4JaDhOQHevWg5XTzy5CRiSJUNSXn zWOZdKv4OSvPNGX23xJEb3dYmxeH8MzP1gdqirWt0FJTF7WOlwbNkOovf0oMSzg4v61/ 173w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=k18PEYFdpuxIJBRvKPg1C0xDCEgmjXEkUYxxGnhFhM8=; b=Lx6aDexxfpF8dblyJLNj4vvKnTv/uUiOEsNsd5pN64lHOzzgqmhcWx47mr57KoX0h5 qgZqTAaXtw6HdSp2cm+40upmlHFAI0U7zypn9oAdAlDwQAhWZ2rpkp9w6IDgV3xZ5yKm uLSBSexFL5nqD5oQqfrlgugaE0H+jK7Es9dUCDuGbK2ecdLMWdgHTto7WJTWQYc+YeDt gRYJLWr3Z1fJOPeENlp/Y7wnwM9impr4uJWHItegdqCZ75WhdaC0IzqEudj5lirNWH6r pfc941Bx5nGS8GADHpKLfsihyIztxUAXU+R0+WtbaNoPzGGL9dRU+OAHdpBXD5YKfamG vF5w== X-Gm-Message-State: AD7BkJLfAnqPB5I0N7jODLT9GdE097PwLK2kiCOzPrkFlgc1sW9E4+WOtOVAXvnUy773MUO75c6oROMSQagEzQ== MIME-Version: 1.0 X-Received: by 10.182.158.42 with SMTP id wr10mr15416640obb.37.1456830256474; Tue, 01 Mar 2016 03:04:16 -0800 (PST) Received: by 10.182.133.101 with HTTP; Tue, 1 Mar 2016 03:04:16 -0800 (PST) In-Reply-To: <20160301110231.GH20687@e-new.0x20.net> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <638DC0E8-2126-4AE9-9A23-44794465B61D@netgate.com> <20160301110231.GH20687@e-new.0x20.net> Date: Tue, 1 Mar 2016 19:04:16 +0800 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Ganbold Tsagaankhuu To: Lars Engels Cc: Jim Thompson , freebsd-arm , "ticso@cicely.de" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 11:04:17 -0000 On Tue, Mar 1, 2016 at 7:02 PM, Lars Engels wrote: > On Tue, Mar 01, 2016 at 05:00:16PM +0800, Ganbold Tsagaankhuu wrote: >> On Tue, Mar 1, 2016 at 1:24 PM, Jim Thompson wrote: >> > >> > >> > >> > >> > -- Jim >> >> On Feb 29, 2016, at 10:37 PM, Brett Glass wrote: >> >> >> >> At 09:03 PM 2/29/2016, Bernd Walter wrote: >> >> >> >>> I think the most interesting point about this board is that it is >> >>> a rather inexpensive arm64. >> >> >> >> I'm still waiting for a board in this category that has 2 GbE >> >> ports... or even one GbE port that can really, really run flat out >> >> at full capacity so that I could multiply it into more ports via a >> >> VLAN switch. Combined with the FreeBSD IP stack, this could be >> >> SUPER-useful. >> > >> > This one has 3x GigEnet. One is connected to a switch, one to an SFP >> > cage, one to a RJ45. http://i.imgur.com/4CUMXyv.jpg >> > >> > It doesn't run FreeBSD, yet, but Semihalf just checked in a lot of >> > work in for the SoC in Dec/Jan. So maybe soon. I don't plan to work >> > on it much before returning from AsiaBSDCon 2016. >> > >> > This one (the one in front) is basically a Beaglebone Black: http://i.imgur.com/plk1Iaf.jpg >> >> Nice. I wish there could be an ARM board (with 2-3 Ethernet ports >> (Gigabit or Fast Ethernet)) which costs less than 100$, maybe 50$-60$ >> but powerful and fast enough to do some SSL encryption/decryption for >> small home network appliance. > > The Banana Pi Router Board? http://www.banana-pi.com/eacp_view.asp?id=64 It seemed slow to me and costs more than 60$. Ganbold From owner-freebsd-arm@freebsd.org Tue Mar 1 12:38:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8076FAB6F07 for ; Tue, 1 Mar 2016 12:38:22 +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 6EACB1F9B for ; Tue, 1 Mar 2016 12:38:22 +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 u21CcMkX050364 for ; Tue, 1 Mar 2016 12:38:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 206229] [patch] Move Atmel's USB OHCI controller FDT driver Date: Tue, 01 Mar 2016 12:38:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: sgalabov@freebsd.org X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: resolution cc bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 12:38:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206229 Stanislav Galabov changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED CC| |sgalabov@freebsd.org Status|In Progress |Closed --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Mar 1 12:48:24 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 12659ABD39E for ; Tue, 1 Mar 2016 12:48:24 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id BC40B14A8 for ; Tue, 1 Mar 2016 12:48:23 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qk0-x231.google.com with SMTP id s68so68300895qkh.3 for ; Tue, 01 Mar 2016 04:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardenedbsd-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=qmHxWg+DF/zt0Ztibpr8tgiJwlT+zi3AXyxy7YMwn0o=; b=AS80nyYrAynnaec4K+3GblyLZBU227dOihrzAR6ZZbc20dfyVqkJNae9Y+yv4MzEFX ChK3v7SZh0tqkJNLkXIL/Dv/gvUJBKf1m1nDTIeuAb/WZVAJbjkLmjub1AML4+rfOJev kpaW5v5G/L2pUnRnWJst/xBNajuPDr4bweheAd+4GEQuABd0gCDrqi0M+e0qyg4sB7uZ A8v0SPxxlxfZmu19T0Lx6mxF9F3hcaQdIX1uqnoUF6Bd78spuDyTDz8mvD7cLI4IFV9H 2449sWvlgKGZGbRmrPzJxgDVqZymQzFuSDrOGiRrBs63zD6NjbAn8VdQ7VyJ9a5iMBap Wxfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=qmHxWg+DF/zt0Ztibpr8tgiJwlT+zi3AXyxy7YMwn0o=; b=h5MTxU8T1NuTAajqdoy9tnI9mr2Zbt+g9+JLleR8mhqZNjy/LnbZBd438rOFxvUVqX t81dEdnDl6aiFefk3J8pGUMj/RQ/dC3DFLs12GwafsroOnGHUXHOj6SdueoKoWquS5wj uA2jzM+i/oB1GPa/VlVpkG8ubXNQS+ZAURQxn3HvaSJNlT60cncep6rTtskwEO7/HUwS czm3Hsjuf+mvdI3vOF4IE7/fl/ZdL/cBnk3DNEPv0jnJyYPqVNghCcUUiK/9d6/BlvbY GwEeL/8Sx3Bkn+X89hEhMT6irG9MInnTiDV+r/mIxUYGb6/b5eceYbFfdfNtkGHYc4Aa 7axQ== X-Gm-Message-State: AD7BkJJFsf4o8j2Pe11Qf42eBLDLtOKXNFousEN6UOJGvOEbJ2uTYzyg1wnXz8YjJrChIhIA X-Received: by 10.55.82.137 with SMTP id g131mr25815868qkb.66.1456836502856; Tue, 01 Mar 2016 04:48:22 -0800 (PST) Received: from mutt-hardenedbsd (c-73-135-80-144.hsd1.md.comcast.net. [73.135.80.144]) by smtp.gmail.com with ESMTPSA id 50sm12888986qgh.15.2016.03.01.04.48.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Mar 2016 04:48:21 -0800 (PST) Date: Tue, 1 Mar 2016 07:48:19 -0500 From: Shawn Webb To: Dan Raymond Cc: freebsd-arm@freebsd.org Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160301124819.GB61549@mutt-hardenedbsd> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <20160301045113.GN6870@FreeBSD.org> <201603010457.VAA03570@mail.lariat.net> <56D52CC7.9050804@foxvalley.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy" Content-Disposition: inline In-Reply-To: <56D52CC7.9050804@foxvalley.net> X-Operating-System: FreeBSD mutt-hardenedbsd 11.0-CURRENT-HBSD FreeBSD 11.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0x6A84658F52456EEE User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 12:48:24 -0000 --H1spWtNR+x+ondvy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 29, 2016 at 10:46:47PM -0700, Dan Raymond wrote: > On 2/29/2016 9:56 PM, Brett Glass wrote: > > At 09:51 PM 2/29/2016, Glen Barber wrote: > > > >> BananaPi has a GigE port. > >> > >> root@a20:~ # ifconfig dwc0 | grep media > >> media: Ethernet autoselect (1000baseT ) > > > > Indeed it does! But the SoC's internal bus can only drive it at about= =20 > > 300 Mbps. > > Try to push it to capacity and it drops packets. >=20 > The Odroid C2 has a Gigabit Ethernet port that runs at full speed.=20 > According to the iperf tests linked below it hits over 900 Mbit/sec on=20 > both reads and writes. I'll also be bringing one of these to hack on at BSDCan, thanks to a generous donation from SoldierX. Thanks, --=20 Shawn Webb HardenedBSD GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE --H1spWtNR+x+ondvy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJW1Y+RAAoJEGqEZY9SRW7uJvwP/24VTsIjxjA13iHRVtQx2Kl7 LKwpb3Uqc9a0jZkC6VGay69o8obeRyOpoCzwJQkJSkUJ2haJkMCQ3e7Ir8kONujZ dSqpEMgq5SfkvGACfWtBqEIPPWhvjfh86yzL8F+ErwDyv/aVFzF2A9rWrFAfQL5q zR3aUySc7fcsO3IXbRkXL/Ve8twOeSgUOlTRNuqfYh8F3TrEKKLUNo7YB+hup6U4 z8PJdY5+Pz4qU3dmXqrabT4LuUTQXVOBOZ9MMyYsJwhQGhsX4m8kNZo18OgQ3s1a HLH6N1p8ddZaAfwOK6zx4puU1pCJujAsuDip8k55I2dh+IPFWXvDdPqUySW2mwdR zD4A4BBCET5abDdpXWaGFtFsBwJsQQ1MjOklq10YHWbwjlGwZHXNzwxcqCKoZXmo cp1coF3h+VaC5piPgRZhngdWKctBa2eEx+cvQ5e7c5xFJVAV39WHgx8CztkmIzT/ 2PKcyeW2PKYoYFb1vizl2TUxV6jmi5+CWcH2Fh9wiypkBjrsCmaCRkv84QZw+9Nz nTdRb4TFoSE6q27lE+BoBlO0nbgY6IPm4SchxlvNu+fzTd7i6ChxhQtG/kQDEAvq prX+8Z/J3YFg8IGWEEbgxRszyrnWPKK3EC+PmbyXOouYHZK6kGijQAfOLIRLIwes 7OEJWpHEEhVgCMfcg2Tc =niTE -----END PGP SIGNATURE----- --H1spWtNR+x+ondvy-- From owner-freebsd-arm@freebsd.org Tue Mar 1 14:46:12 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6E3B6ABDA3D for ; Tue, 1 Mar 2016 14:46:12 +0000 (UTC) (envelope-from mst@semihalf.com) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 353AC161C for ; Tue, 1 Mar 2016 14:46:12 +0000 (UTC) (envelope-from mst@semihalf.com) Received: by mail-oi0-x236.google.com with SMTP id m82so130063864oif.1 for ; Tue, 01 Mar 2016 06:46:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=dQGxXCiAMObGnxXqx01FjHgAwi61BOWJ72Fh5etLO50=; b=yc+eTjz2isu5nJq40T4bRw7JS6FWRNvEnS6yN2UiuycbxiZvss65NcnUcOBjsWEX1w eAVBipmd1U59IPvU42E4HouN3VmJOdfflPmZ6mR7GAaypj1c0CQsKTCDGlM0Kp5yOVfg 76Zo+sOjsrmGJj+PsftXrfJSkUdCJKu7aU5SBxodfNpcDiBpYjzgRNqOo7kDXCWL/rrF NVizAmuGrX5jZriOsyBwgmYMBmc/rDuI6AYS/B3bFDdaBcVjg/kdHgI6ZMUBoAzthmf+ SCNKMZdGCRGtfLPLUfiL8dcuZIrI/O0askbSqu1Vb/zfP5WQpS0FqKhOSxObhMvFpI+K PTlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=dQGxXCiAMObGnxXqx01FjHgAwi61BOWJ72Fh5etLO50=; b=KweoEbsgyVZM9XY6EIovrmaf8etSi0+4f42KFSIoWgVlMW9ebMI34hqyJS1ynSstql fznPiguR7fiL7gKhUGyYjzOdfzldAeId0pzsix5eso9jBSgpFkqBX8+ZLqh1wyuu+G/D D1IN7qlIidqWfSLXThyobx+5ffUxialr6aYENhrqpXMtcwQTfthoAHra5T5jdoCN9Xj2 0SAqBRZThPTbiN9nKiV/VM3TQtRuuI7rT/cv5nrg9josZVPIvnVlyh/zKwCCZXi5EZ6r uRSydoaSrkw4UK6hcH3T4NcIK/oZYl5K9Mb2qxaiw/KgVHsP9jyiNkrFcztA2/5xce3q b+bw== X-Gm-Message-State: AD7BkJJszellGLxGVruE4OhyqnWN34iY+3tAPgmcN5R2UGsHXyidFT5YT+g9tuJUAJp5EhP81AFiggW3Z6/9eQ== MIME-Version: 1.0 X-Received: by 10.202.55.198 with SMTP id e189mr2476998oia.85.1456843571572; Tue, 01 Mar 2016 06:46:11 -0800 (PST) Received: by 10.182.24.196 with HTTP; Tue, 1 Mar 2016 06:46:11 -0800 (PST) In-Reply-To: <0E2B7566-8E95-4570-AD00-353A9392E6D8@yahoo.com> References: <5A031837-F7D6-467F-A6B7-35B1F0A467D9@yahoo.com> <0E2B7566-8E95-4570-AD00-353A9392E6D8@yahoo.com> Date: Tue, 1 Mar 2016 15:46:11 +0100 Message-ID: Subject: Re: u-boot and ubldr on arm64 From: =?UTF-8?Q?Micha=C5=82_Stanek?= To: Thomas Skibo Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 14:46:12 -0000 2016-02-29 21:11 GMT+01:00 Thomas Skibo via freebsd-arm : > > > I feel like I dropped the ball on this one. Should I put these changes u= p on phabricator? Can I do that without being a committer? The Raspberry = Pi 3 will need this I think. > > I=E2=80=99ve attached a cleaned-up diff. > > =E2=80=94 > Thomas Skibo > thomasskibo@yahoo.com Feel free to submit the patch on Phabricator, you don't have to be a committer to do that. I will test the cleaned-up version soon on the arm64 board I have. Regards, Michal Stanek From owner-freebsd-arm@freebsd.org Tue Mar 1 16:03:49 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4ED93ABFB58 for ; Tue, 1 Mar 2016 16:03:49 +0000 (UTC) (envelope-from brett@lariat.net) Received: from mail.lariat.net (mail.lariat.net [66.62.230.51]) by mx1.freebsd.org (Postfix) with ESMTP id F403010A4 for ; Tue, 1 Mar 2016 16:03:48 +0000 (UTC) (envelope-from brett@lariat.net) Received: from Toshi.lariat.net (IDENT:ppp1000.lariat.net@localhost [127.0.0.1]) by mail.lariat.net (8.9.3/8.9.3) with ESMTP id JAA08726; Tue, 1 Mar 2016 09:03:10 -0700 (MST) Message-Id: <201603011603.JAA08726@mail.lariat.net> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 01 Mar 2016 09:01:03 -0700 To: Lars Engels , Ganbold Tsagaankhuu From: Brett Glass Subject: Re: FreeBSD on the RaspberryPi 3 Cc: freebsd-arm , "ticso@cicely.de" In-Reply-To: <20160301110231.GH20687@e-new.0x20.net> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <638DC0E8-2126-4AE9-9A23-44794465B61D@netgate.com> <20160301110231.GH20687@e-new.0x20.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:03:49 -0000 At 04:02 AM 3/1/2016, Lars Engels wrote: >The Banana Pi Router Board? http://www.banana-pi.com/eacp_view.asp?id=64 Looked at this. Alas, it has one of the SoCs (the Allwinner) with limited internal bus capacity. It can't process a full gig of traffic in software, even just bridging it at the MAC layer. Wish it could! --Brett From owner-freebsd-arm@freebsd.org Tue Mar 1 16:06:11 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 52BBAABFD80 for ; Tue, 1 Mar 2016 16:06:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::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 1B3B912F1 for ; Tue, 1 Mar 2016 16:06:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qg0-x233.google.com with SMTP id d32so89425607qgd.0 for ; Tue, 01 Mar 2016 08:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=L6zDqAEgWv1sVk0wcvqv4UHPqxkGuHbboBkfBpso9aE=; b=VVxfEXtHPaXadyPdahRTDLMP9YkDrX2P6cR9yIZ8K/dBox7GirUKNhMIBCV41tyVKo oWp7s3Hl5HrdK0UsNGyKTtuQYee8t32fDEFh4h45MAg5D4yBmimoyXgXD3Wp6Aal+j7M 0zA1AaS1kSdPPfODUxa1iEmZDL265xa+OgQAq1pGvgtCFcQ9XcQP1dyq6jOeSf/hntrv zQzEboTjZkTijhTJxsvMfb5aXCI1yjzH+HsYdB3vZHLFyOJQB6BEcDr05K5DAe9DP3WC MpPmQ3G+yJoHd/YMQKVtIzhy/xvtoVq2yfIn5wQgZXfP/qKP7Ze3P1vexC5N32CW46Ee vtBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=L6zDqAEgWv1sVk0wcvqv4UHPqxkGuHbboBkfBpso9aE=; b=QiX9QKBI7EG0du50tHJnmVX+VUL6QYdoRAB19ZlMocBxhyQUId8Qb3rRX4Z13ixYJ5 bwAgYiknopI73Q6+BC62yz5RmFP/RswEX3K34UX7vKC86L2LNfMi3ApgvsxpZL8X5dQi 4FmAHDc+HxvwMSsHszNEc/R3/TkVFCDlZIbDIeS89ZkMFQX/8nXflMGgLHW8FXm7g5I+ 0XE/lkJ0Dr0Fz1DO30jycuiVVKoA5HONwRGn8MYNxgjd8oRquT82EINnXd+JCOLQ9JDI Bo086PUxQ1QBjrERYKaHN5aKgK49U8sA53VSTJJjK+ZVKTgWh1HjLXaowTua71vQHPcJ aoDA== X-Gm-Message-State: AD7BkJLS4dTgnlqi2JPeQ2k3zDtsqsW0fwQvSgrU5Gysg6tlesd7c1bPDCwi9aEYapumnPdwUMb+E+QM+4R95w== MIME-Version: 1.0 X-Received: by 10.140.99.69 with SMTP id p63mr27172613qge.97.1456848370030; Tue, 01 Mar 2016 08:06:10 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Tue, 1 Mar 2016 08:06:09 -0800 (PST) X-Originating-IP: [69.53.245.34] In-Reply-To: References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> Date: Tue, 1 Mar 2016 09:06:09 -0700 X-Google-Sender-Auth: EBUjo2ZjcDU61rSnAFEUNujT3Oo Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Warner Losh To: Adrian Chadd Cc: Shawn Webb , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:06:11 -0000 There's a CAM-ified mmc/sd stack. This has support for the popular SD bridges that can also do SDIO. There's no wifi nor bt driver for it yet, though. We need to get behind that effort. Warner On Mon, Feb 29, 2016 at 7:07 PM, Adrian Chadd wrote: > Someone ordered me one, so I can take a crack at the broadcom sdio bits. > > It'll require the ARM SDIO driver to first work.. > > > -a > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Mar 1 16:31:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C26D5AC0751 for ; Tue, 1 Mar 2016 16:31:23 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::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 900E6176F for ; Tue, 1 Mar 2016 16:31:23 +0000 (UTC) (envelope-from jim@netgate.com) Received: by mail-ob0-x235.google.com with SMTP id xx9so58187540obc.2 for ; Tue, 01 Mar 2016 08:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netgate.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Z/J1c1lh9F8DsEuuNHIj1U6LpvMzb4CojDHnAgxNGk=; b=VNFc1ZS1oI4k029F2MBREG0I1O4g2PtlOlpaJFgcr/tIwttqfR6amEz6HLXxEnLaWY jUrnBo4Z5AD15uA+jF/ArNWzi05/dwVFJLAfyPu5TbIIrwcil6eJnd6NaEOBNDcoqHJs edccOjycDAVFuhVUA6pTaf+btnVeNBnIm52h8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6Z/J1c1lh9F8DsEuuNHIj1U6LpvMzb4CojDHnAgxNGk=; b=XdyoKnsB2ufJZeAM7BXzz1+IQUGEsqFz1I7DBdvHHyOS/Dt/fQcx3Swzuhu/OHAFni jpQYMiKtVTeoJyUIUQbWPRWPd3pAyJb28i7cOC+bytGkKv8Z/mjCJUWujIZk0latjoSa CjDACKNbiUXm4awCz2oX92b0qEZe7ncZqeBJ57wHlXuXyamx5EN+eU8Db0fVqaT2a91F PTn/Mhu0+lW4pJnzoCQV4glQwW6/HC798BgOM+PqziBhr4aaGOIExIcngLFmtkCImWLE q3/WuhTUBh3YZalpfQX38Z5LNdld/8swrMYq6XP4P8ZgngM2p1VzxuHMnj4VT9pMV6lK HV9A== X-Gm-Message-State: AD7BkJJWAsHpzbB6UwyXtB1+K0i2tuFjovHWtTvl7wb+4TYgd+1PuMNHH7a/HAbN42K7Dg== X-Received: by 10.182.86.33 with SMTP id m1mr16835874obz.48.1456849882594; Tue, 01 Mar 2016 08:31:22 -0800 (PST) Received: from [172.21.0.15] (65-36-116-65.dyn.grandenetworks.net. [65.36.116.65]) by smtp.gmail.com with ESMTPSA id ge2sm4691266obb.28.2016.03.01.08.31.20 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 08:31:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: FreeBSD on the RaspberryPi 3 From: Jim Thompson X-Mailer: iPhone Mail (13D15) In-Reply-To: <20160301124819.GB61549@mutt-hardenedbsd> Date: Tue, 1 Mar 2016 10:31:20 -0600 Cc: Dan Raymond , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <89F6CB35-543A-40B2-B4A5-1D57124EDD73@netgate.com> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <20160301045113.GN6870@FreeBSD.org> <201603010457.VAA03570@mail.lariat.net> <56D52CC7.9050804@foxvalley.net> <20160301124819.GB61549@mutt-hardenedbsd> To: Shawn Webb X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 16:31:23 -0000 > On Mar 1, 2016, at 6:48 AM, Shawn Webb wrote:= >=20 > I'll also be bringing one of these to hack on at BSDCan, thanks to a > generous donation from SoldierX. I should have a Pine64 by BSDCan as well, and can bring it.=20 (Perhaps I should thank Mrs. Thompson for putting up with^W^W^W supporting m= y hardware habit for 26 years.) A comparison of RPi3, Odroid C2, and Pine64 is here: http://www.cnx-software.com/2016/03/01/raspberry-pi-3-odroid-c2-and-pine-a64= -development-boards-comparison/ Jim From owner-freebsd-arm@freebsd.org Tue Mar 1 17:28:35 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 826A8ABDE8F for ; Tue, 1 Mar 2016 17:28:35 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm18-vm0.bullet.mail.bf1.yahoo.com (nm18-vm0.bullet.mail.bf1.yahoo.com [98.139.213.138]) (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 3A42D19F1 for ; Tue, 1 Mar 2016 17:28:35 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456853308; bh=WLysxy2AaAqnPdWdFfguUSBBpiIFtyrqEYaMJCir63I=; h=Subject:From:In-Reply-To:Date:References:To:From:Subject; b=kWnzS6ilz18dDryc+MGVcGnYXZtOlqjdIXdrHlYGAqzIkDHpQqLGAT/vXsMnFQKf8bNKBsCsRT+VoUq2vzOqXGJ+iauisBPOFj9TojJiVOmHy+AIZ6Sc/jpq+/vro+7Z2cYedwbSA8ESi8hpZe+HppsBE7xlnFgWSy5vOPDT2qnvLXV7hExOkWFhfL6cGiBdhKbzk6baFp32vtMDwuzIgEm11498Rs0kCbinjCIIaMS3cVkjdErtZ04HoBBjEIL088wbINZiClOKUFN+S10/DEwt9LKgK4NemOUUZjBqLOyvtJYM7ockxpSWi6FF3XtyecVU+OQEluIyUW+glNO3nQ== Received: from [66.196.81.172] by nm18.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 17:28:28 -0000 Received: from [98.139.213.9] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 17:28:28 -0000 Received: from [127.0.0.1] by smtp109.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 17:28:28 -0000 X-Yahoo-Newman-Id: 429060.51890.bm@smtp109.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: K7NUWg8VM1mzeSLR9M8ifi2G0_g4UK.2zYTOBkXCjVAdxdd _q2crsXI3ithJzCp_1JvYxZncTaoK5MJE6jIkUgOY8vO.b0GjCxtnkFngVz_ NUTLwhwGcdoPQK5KkbwbBybUMWPn5kNyP1JyWeS11PozCZ0X64u0bgbX75um CUa.M0oTgvwvHhM27fGdsSOM4mRs.i7TbcvZIgY9YBhh.yNCEuBu9kRuO5oU 8iuApjQa5oxS3tVoar83vviEAraM.7B7yCMcwP2sAQdLogmVf2dr5tz1iWlC N_ldOIR9q5HeqXCJA0KNp.26JpLLkmyBR_UfluvUVFXYUEFhheDurI5HS4EQ gV6b34AOCX5y6FpX.2B6Q.7GZbVn8BXU9cV96IkDb3NNign6aunM6panclaK Vhlz1TjYEtPuxgyN8ukvhc2s1AcVu7unjiTTo8C0DiQTvbW2CUBL.0heyH1Z pG9uL2kWjx4FNFXUTYEvRqIgwewVZFQlt864.ERyol5vjtjGWzHgcbe8j6ud KYNqZnAdGFONBpV8UX0On5n8jvNR3PqSZTkCB2w-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: u-boot and ubldr on arm64 From: Thomas Skibo In-Reply-To: Date: Tue, 1 Mar 2016 09:28:26 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <51D56C05-1390-4B2B-A6B9-04366CE33387@yahoo.com> References: <5A031837-F7D6-467F-A6B7-35B1F0A467D9@yahoo.com> <0E2B7566-8E95-4570-AD00-353A9392E6D8@yahoo.com> To: =?utf-8?Q?Micha=C5=82_Stanek?= , freebsd-arm@freebsd.org X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 17:28:35 -0000 > On Mar 1, 2016, at 6:46 AM, Micha=C5=82 Stanek = wrote: >=20 > 2016-02-29 21:11 GMT+01:00 Thomas Skibo via freebsd-arm > : >>=20 >>=20 >> I feel like I dropped the ball on this one. Should I put these = changes up on phabricator? Can I do that without being a committer? = The Raspberry Pi 3 will need this I think. >>=20 >> I=E2=80=99ve attached a cleaned-up diff. >>=20 >> =E2=80=94 >> Thomas Skibo >> thomasskibo@yahoo.com >=20 > Feel free to submit the patch on Phabricator, you don't have to be a > committer to do that. I will test the cleaned-up version soon on the > arm64 board I have. >=20 > Regards, > Michal Stanek Thanks. I started the process but it turns out some work for making u-boot = 64-bit compatible (for mips) went in just last night so there are = conflicts where we both solved the same issues and compiler warnings. = I=E2=80=99ll merge those changes into my tree and re-test. My revision = will touch fewer files now which is good. =E2=80=94Thomas =E2=80=94 Thomas Skibo thomasskibo@yahoo.com From owner-freebsd-arm@freebsd.org Tue Mar 1 18:04:13 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E092ABF449 for ; Tue, 1 Mar 2016 18:04:13 +0000 (UTC) (envelope-from fulda@seznam.cz) Received: from wifi.nekropolis.cz (wifi.nekropolis.cz [185.14.235.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wifi", Issuer "wifi" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B47DA1616 for ; Tue, 1 Mar 2016 18:04:12 +0000 (UTC) (envelope-from fulda@seznam.cz) Received: from [10.88.62.44] (home10 [10.88.62.44]) by wifi.nekropolis.cz (8.14.9/8.14.9) with ESMTP id u21I42gh022119 for ; Tue, 1 Mar 2016 19:04:02 +0100 (CET) (envelope-from fulda@seznam.cz) Subject: Re: FreeBSD on the RaspberryPi 3 To: freebsd-arm@freebsd.org References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <20160301040331.GB59803@cicely7.cicely.de> <201603010437.VAA03437@mail.lariat.net> <638DC0E8-2126-4AE9-9A23-44794465B61D@netgate.com> <20160301110231.GH20687@e-new.0x20.net> <201603011603.JAA08726@mail.lariat.net> From: Jindrich Fucik Message-ID: <56D5D991.90806@seznam.cz> Date: Tue, 1 Mar 2016 19:04:01 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <201603011603.JAA08726@mail.lariat.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:04:13 -0000 Dne 1.3.2016 v 17:01 Brett Glass napsal(a): >> The Banana Pi Router Board? http://www.banana-pi.com/eacp_view.asp?id=64 > Looked at this. Alas, it has one of the SoCs (the Allwinner) with > limited internal bus capacity. It can't process a full gig of traffic in > software, even just bridging it at the MAC layer. Wish it could! Wall, this is question what are you prefer. Allwinner have sata on chip, than every single performance test that including disk operations have banana pi faster. http://www.htpcguides.com/raspberry-pi-vs-pi-2-vs-banana-pi-pro-benchmarks/ The problem is, that you can not enjoy it with FreeBSD, because it does not work once SATA SSD disk is plugged in. Jindra From owner-freebsd-arm@freebsd.org Tue Mar 1 18:38:24 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 28100AC020E for ; Tue, 1 Mar 2016 18:38:24 +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 18C131CD2 for ; Tue, 1 Mar 2016 18:38:24 +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 u21IcNIY031243 for ; Tue, 1 Mar 2016 18:38:23 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 207621] SATA SSD / Allwinner A20 Date: Tue, 01 Mar 2016 18:38:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: fulda@seznam.cz 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.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 18:38:24 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207621 Bug ID: 207621 Summary: SATA SSD / Allwinner A20 Product: Base System Version: 11.0-CURRENT Hardware: arm OS: Any Status: New Severity: Affects Some People Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: fulda@seznam.cz This bug affect boards with Allwinner A20 chips. Once they have attached SA= TA SSD disk (no necessary to mount, only plugged in), then you will have troub= les with reading more files from SD card. I did small experiment - download last image (same experience with previous one), boot, and without any modifications start reading files from SD. Atta= ched sata ssd have no UFS/FAT partition and no any partition is mounted. (my hardware is Banana PI M1) Here is three examples: read disk using tar with transfer data to another process (wc) and without = (to dev/null) Outputs from my experiment follows. (Other affected people:=20 https://lists.freebsd.org/pipermail/freebsd-arm/2016-February/013229.html https://lists.freebsd.org/pipermail/freebsd-arm/2016-February/013274.html ) Jindra --------------------------------------------- SATA disk attached, but not used: --------------------------------------------- root@a20:~ # uname -a FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 05:22:= 46 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20 a= rm root@a20:~ # tar cf - /usr | wc tar: Removing leading '/' from member names panic: vm_page_insert_after: page already inserted cpuid =3D 0 KDB: enter: panic [ thread pid 679 tid 100084 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> --------------------------------------------- root@a20:~ # tar cf /dev/null /usr tar: Removing leading '/' from member names panic: vm_page_insert_after: page already inserted cpuid =3D 0 KDB: enter: panic [ thread pid 644 tid 100067 ] Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! db> --------------------------------------------- NO SATA disk attached: --------------------------------------------- root@a20:~ # uname -a FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 05:22:= 46 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20 a= rm root@a20:~ # tar cf - /usr | wc tar: Removing leading '/' from member names 5994501 28169833 716206080 root@a20:~ # root@a20:~ # halt Feb 17 05:37:21 a20 halt: halted by root Feb 17 05:37:21 a20 syslogd: exiting on signal 15 Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...2 1 0 0 done All buffers synced. lock order reversal: 1st 0xc45b3db4 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xc432cc94 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2617 stack backtrace: lock order reversal: 1st 0xc45b3b74 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222 2nd 0xc45b35d4 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:994 stack backtrace: Uptime: 3m12s The operating system has halted. Please press any key to reboot. --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Tue Mar 1 20:41:39 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C2461ABE73F for ; Tue, 1 Mar 2016 20:41:39 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) Received: from nm37-vm4.bullet.mail.bf1.yahoo.com (nm37-vm4.bullet.mail.bf1.yahoo.com [72.30.238.204]) (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 797A911DC for ; Tue, 1 Mar 2016 20:41:39 +0000 (UTC) (envelope-from thomasskibo@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1456864712; bh=0sw3SyLG3OhN6rW1Lv4wBpE6AlZ1O+oT3e5iqSBowXE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject; b=djQ139Ywya/Rqt4gH0rN4X9SQpuwpucbSi+6zASmHI4yV9icBqhFrMClAbEeVC17lDugemHtLXG3KHp864UH3yyFk//KDjEh4RARaahhO4eN13lhYyMBouEbYGF+l426mEqU2ioRNgLgK+j9L0QiCmguESnyA8Vb0Ajz25FmQuJCGd+LHmApQHy/MYEZh1b3zpRIWqM2QVV6dXRlFYyfqlbViOOERVC24Gr31LV193uL7EFRHhLCsiwqRjXzZQ8DsRV+uJBp6WobOyS1iC7t9AL+0v4VoeZSHJT2MKDxjcz8q5hFUs47RfzYE6FjNyN9fQwpC/CRT9TK2YBpQj5dIg== Received: from [98.139.170.181] by nm37.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 20:38:32 -0000 Received: from [68.142.230.70] by tm24.bullet.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 20:38:32 -0000 Received: from [127.0.0.1] by smtp227.mail.bf1.yahoo.com with NNFMP; 01 Mar 2016 20:38:32 -0000 X-Yahoo-Newman-Id: 488251.63070.bm@smtp227.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: rPepfk0VM1mkVgTcb3AzccHcaZuAwSjz6WzQJQWXx0P_JtG 5dAQDZsEzKiz_xgOaja4Q7HeVZynxhqS0RDoPDrOtZa1ehKEqT0TqgkEpaka Zm8IMw3OKED7Andv0ANtMy4Muo.MTgxyQ21AzBaAOIyUle2dBOjdvhJTA2Ow DMGHnyjyLbxyxpAh6BFMznjHaq5PaJrzqq.zhk0OWWEvJ6nLZ0K0SMVdubqh El.5CJBwn6W74EPPHTgZO4Jj796mF5be.6f1kFimMcV1VQ1S3ehGxa_oH.iB TI5c5szw9g0iNG1NPUbdQJqtcTDAIIUclW.bMrhp2VRF4.8VcXxgl_9O8zM. 4Yw.h0E2RHkmUD2BLoEnvggPI07LA1QavaG4zPb58veslO51RvrT9UWG9Lqv gGTC6pBmX4GS61noXKiyI8orQ1_4NLCgb_vjkKbeRGqP.Ydajaiei1dVdOyc L91OlduyybqA4xwgiuxDz5DFstaTbVkTHMEeDuygZHyWNHgJlw_ZS97sLXIg bkA5WAUw93WEytlaf1CQ9syRe45U._1FoTPtU_Q-- X-Yahoo-SMTP: .8Dytk6swBAeTUTcf.ezO8BKaYfn.mUV Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: u-boot and ubldr on arm64 From: Thomas Skibo In-Reply-To: Date: Tue, 1 Mar 2016 12:38:31 -0800 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <5A031837-F7D6-467F-A6B7-35B1F0A467D9@yahoo.com> <0E2B7566-8E95-4570-AD00-353A9392E6D8@yahoo.com> To: =?utf-8?Q?Micha=C5=82_Stanek?= X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 20:41:39 -0000 > On Mar 1, 2016, at 6:46 AM, Micha=C5=82 Stanek = wrote: >=20 > 2016-02-29 21:11 GMT+01:00 Thomas Skibo via freebsd-arm > : >>=20 >>=20 >> I feel like I dropped the ball on this one. Should I put these = changes up on phabricator? Can I do that without being a committer? = The Raspberry Pi 3 will need this I think. >>=20 >> I=E2=80=99ve attached a cleaned-up diff. >>=20 >> =E2=80=94 >> Thomas Skibo >> thomasskibo@yahoo.com >=20 > Feel free to submit the patch on Phabricator, you don't have to be a > committer to do that. I will test the cleaned-up version soon on the > arm64 board I have. >=20 > Regards, > Michal Stanek Okay, done. https://reviews.freebsd.org/D5512 I=E2=80=99m looking for = a reviewer. =E2=80=94Thomas From owner-freebsd-arm@freebsd.org Tue Mar 1 22:11:52 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36FFBABF0E1 for ; Tue, 1 Mar 2016 22:11:52 +0000 (UTC) (envelope-from franco.ricc@gmail.com) Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::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 C437F1C6A for ; Tue, 1 Mar 2016 22:11:51 +0000 (UTC) (envelope-from franco.ricc@gmail.com) Received: by mail-wm0-x233.google.com with SMTP id l68so53288151wml.1 for ; Tue, 01 Mar 2016 14:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3DzpPKOMmSzVGqvU/FrahaYbd5oPmQN4S58OGDIIMe4=; b=E3NilB6Kz2rahAg0OdYsQK6RJTkoSZi0QJqngZ+o1PGpxI8kc+9bk8HGnYcqzlLFJi YqERqQiCkcyDJNpq5dAYm1aIHuXKbnYPLv1qd/naE+AbrBQm1azlLqwfw8JcABNPy+PK T0MVvtY/0mX8BzhmumvHKuCHS9y9dmJ58KMVMABskB3aZof4xD9zuN9CgkW3xHCSqHCj Njh00dALegtJvPi3XF1ORHijJYYqOscyJfYNvDTSNbwwzQz/F8FV717dwWZliel5PzBc Q3de9Yn13proMT4HEPSrb0WxCS1yn9CD5iA4D2JGOAFxFB1qZ997mD0YLYxUShp1nvuI Pshw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3DzpPKOMmSzVGqvU/FrahaYbd5oPmQN4S58OGDIIMe4=; b=SdIiwVyCbkFcUdbWsTD7tmQ25h5/dUoCJm5FvRCIlNDNoh5znIOmesac6FP78X8jhc BWOKvH+/l+GeEpDko4ChH/bYLSS9QDRHZneKvcUKK6uUekAqoSBD9d4swRFmuFRUoRz3 qfAwN8yIyxzYQXV6nR2ZCWKDJZ6nc/OHbsYwmqgB18RQ6DZMgdhkKNL4j/pI2YdPYPfp UzlO5eKXBctsBZOcbEKLxN6U1b9J4xSH67z5H1q0soAbpHUcds+OEHqxjhRAuzkiWX+d HfCaoSJXJWs4inlEdaEDfIuU+f2XVsyUZhpfrdy6Qwax0BOgoHz1vRKdoZhX499OzAmT x0Mg== X-Gm-Message-State: AD7BkJIsRjuX4emK4S0ZfXw9l0cTj/AAlYd5WN3z3+BnTG4c7VInQNdxiFX23JOsk08MPA== X-Received: by 10.28.9.71 with SMTP id 68mr1179082wmj.33.1456870310329; Tue, 01 Mar 2016 14:11:50 -0800 (PST) Received: from [192.168.20.5] (host241-216-dynamic.6-87-r.retail.telecomitalia.it. [87.6.216.241]) by smtp.gmail.com with ESMTPSA id ys9sm32762839wjc.35.2016.03.01.14.11.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 01 Mar 2016 14:11:48 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: Banana pi pro SATA From: Franco Ricci In-Reply-To: <56D0830E.8090802@seznam.cz> Date: Tue, 1 Mar 2016 23:11:47 +0100 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D0830E.8090802@seznam.cz> To: Jindrich Fucik X-Mailer: Apple Mail (2.1510) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2016 22:11:52 -0000 Hi Jindra, you are right, the problem is related to disk attached while I reading = form SD. If I boot from SATA disk and I never read nothing form SD all seems to = work fine. Franco On 26 Feb, 2016, at 5:53 PM, Jindrich Fucik wrote: > Franco Ricci franco.ricci at uniroma1.it > Sat Feb 20 09:59:19 UTC 2016 >=20 > > After several days I found that problem was HD type. > > With a rotational HD all works fine. > > I don't know why. >=20 > Hello Franco, >=20 > I fave found, that it does not matter you are using disk or not. > Only the fact the disk is attached mean, that you will have troubles = with reading more files from SD card. > I did small experiment - download last image (same epeerience with = previous one), boot, and without any modifications start reading files = from SD. Attached sata ssd have no UFS/FAT partition and no any = partition is mounted. (my hardware is Banana PI M1) >=20 > Here is three examples: > read disk using tar with transfer data to another process (wc) and = without (to dev/null) >=20 > Interesting is, that after successful read, when I'm trying to "halt" = the computer I'm receiving fantastic error I not understand. >=20 > Outputs from my experiment follows. >=20 > Jindra >=20 > --------------------------------------------- > SATA disk attached, but not used: > --------------------------------------------- > root@a20:~ # uname -a >=20 > FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 = 05:22:46 UTC 2016 = root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20 arm > root@a20:~ # tar cf - /usr | wc >=20 > tar: Removing leading '/' from member names > panic: vm_page_insert_after: page already inserted > cpuid =3D 0 > KDB: enter: panic > [ thread pid 679 tid 100084 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> >=20 > --------------------------------------------- > root@a20:~ # tar cf /dev/null /usr >=20 > tar: Removing leading '/' from member names > panic: vm_page_insert_after: page already inserted > cpuid =3D 0 > KDB: enter: panic > [ thread pid 644 tid 100067 ] > Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! > db> >=20 >=20 > --------------------------------------------- > NO SATA disk attached: > --------------------------------------------- >=20 > root@a20:~ # uname -a >=20 > FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 = 05:22:46 UTC 2016 = root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20 arm > root@a20:~ # tar cf - /usr | wc >=20 > tar: Removing leading '/' from member names > 5994501 28169833 716206080 > root@a20:~ # > root@a20:~ # halt >=20 > Feb 17 05:37:21 a20 halt: halted by root >=20 > Feb 17 05:37:21 a20 syslogd: exiting on signal 15 >=20 > Waiting (max 60 seconds) for system process `vnlru' to stop...done > Waiting (max 60 seconds) for system process `bufdaemon' to stop...done > Waiting (max 60 seconds) for system process `syncer' to stop... > Syncing disks, vnodes remaining...2 1 0 0 done > All buffers synced. > lock order reversal: > 1st 0xc45b3db4 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222 > 2nd 0xc432cc94 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2617 > stack backtrace: > lock order reversal: > 1st 0xc45b3b74 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222 > 2nd 0xc45b35d4 devfs (devfs) @ = /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:994 > stack backtrace: > Uptime: 3m12s >=20 > The operating system has halted. > Please press any key to reboot. > _______________________________________________ > 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 Wed Mar 2 05:21:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8A5F4AC05F7 for ; Wed, 2 Mar 2016 05:21:46 +0000 (UTC) (envelope-from fehrist@codeghar.com) Received: from mail-pa0-x229.google.com (mail-pa0-x229.google.com [IPv6:2607:f8b0:400e:c03::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 687771B15 for ; Wed, 2 Mar 2016 05:21:46 +0000 (UTC) (envelope-from fehrist@codeghar.com) Received: by mail-pa0-x229.google.com with SMTP id bj10so57010792pad.2 for ; Tue, 01 Mar 2016 21:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codeghar-com.20150623.gappssmtp.com; s=20150623; h=message-id:date:from:reply-to:user-agent:mime-version:to:subject :content-transfer-encoding; bh=Ao2wiaeoGsPYhW6M2Sq75hUPiVTat2kKskAZXik9FlM=; b=FA+45+Tg2AE3cpXQwubwNqZVOmaIP8GuWyjmTYwwkrRI/+Rc/vFqvnx88ysR8Uu1uV X5AKmlIm0BW5N8dCdJhDuRnYHVfy5CSfsjG5raYJe1wV40pYlJTUMhJyf+RSWJI/JQLo w/ixVOfhj6J14YdiyYFgbHBFNS3RgOwCQTkIU/X/3AU8LYF9gLWpM4Vk9hjb1/gL4d15 n62z43g/klyJPHtMVY9jqDtOGOAk2uhoak/KYD9vXNjjz1hXmXXUcZ3Y2Rx/4x0s2I03 rEDPbWEj56v1SQB/iT+xGE8G2zwNc+FbJLegZzPH3akMNjy9ffU3cseLfSAhpbjLMkOy 16hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:user-agent :mime-version:to:subject:content-transfer-encoding; bh=Ao2wiaeoGsPYhW6M2Sq75hUPiVTat2kKskAZXik9FlM=; b=EWyY5Qjw2Jobm95qiDbrL1aj9kedPXwmdvF4Raboc1Bf3rjyJTvsIT+1SMZPlLxoU6 CrPzsxnaHaMSWx6mWPuHAio3QfMZIlcyB9RTU7fEtsv2vVIYFbwaZWXprNnjP4OBnj9O CNEqfU9pg4CDfYbfe4Y94M3To9XidtIbG3BooyF74Q7UF58CdFQUtPsqSVzUxotKns/z ry0rdRGKNCBd8WFahOMR5qe/09WKHQURUN13wHZ7HK4ngaR/gia0sydu2PosUTRl0anL m9YcQtvv7HmOcnygz+M8RfAdLHqwD1SR0dmkFeZdmZygKBilia0wMi9RZWVubcQK7pZu +PqQ== X-Gm-Message-State: AD7BkJKlQKJXYbQJ/8CwxxFYCOT6uAws0UOwaRzqCaG1FSIeLQXz1iP7JhpaxipnDXp1uQ== X-Received: by 10.66.147.164 with SMTP id tl4mr34788146pab.40.1456896105759; Tue, 01 Mar 2016 21:21:45 -0800 (PST) Received: from heer.internal.jugni.xyz ([2601:600:8300:9b4:6d88:3678:3689:39b9]) by smtp.googlemail.com with ESMTPSA id q2sm25670683pfq.88.2016.03.01.21.21.44 for (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Mar 2016 21:21:44 -0800 (PST) Message-ID: <56D67867.4060908@codeghar.com> Date: Tue, 01 Mar 2016 21:21:43 -0800 From: Hamza Sheikh Reply-To: fehrist@codeghar.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: freebsd-arm Subject: Packaging 11.0 base for ARM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 05:21:46 -0000 I'm unclear on status of packaging base in 11.0 for ARM. 1. Will 11.0-RELEASE package base so it will get binary updates using pkg instead of freebsd-update? 2. Will 11.0-RELEASE base be packaged for ARM in addition to i386 and amd64? -- Hamza Sheikh Twitter: @aikchar From owner-freebsd-arm@freebsd.org Wed Mar 2 11:38:02 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B08EFABFD2A; Wed, 2 Mar 2016 11:38:02 +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 7B44310ED; Wed, 2 Mar 2016 11:38:02 +0000 (UTC) (envelope-from ilya@bakulin.de) DKIM-Filter: OpenDKIM Filter v2.10.3 olymp.kibab.com 0AB254E673 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=bakulin.de; s=default; t=1456918673; bh=Gy7ZMoxFyYqWXCvOa1ZhRaM7rQtdziEduW2OmH6lrSs=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ks9g5zzp1XgHbGiLJjde1n4odFlIgdJI+7dFHBimcS4xX2PY50CcOFONFswDXJOPq wSX8svbdOfwtZ5mHemtMLlJ3NnLAm2IaLULnf8AOOvIqyNahON5JbQdLyciClPXnGw rCTvY8s8VGAzTcdzcM5nbNM6KVAFs1TbHlbmifsQ= MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 02 Mar 2016 12:37:52 +0100 From: Ilya Bakulin To: Adrian Chadd Cc: Shawn Webb , freebsd-arm@freebsd.org, owner-freebsd-arm@freebsd.org, imp@FreeBSD.org Subject: Re: FreeBSD on the RaspberryPi 3 Organization: Deglitch Networks In-Reply-To: References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> Message-ID: <437ca32e613c8ecc6825e6da18ca64b1@bakulin.de> X-Sender: ilya@bakulin.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 11:38:02 -0000 On 2016-03-01 03:07, Adrian Chadd wrote: > Someone ordered me one, so I can take a crack at the broadcom sdio > bits. > > It'll require the ARM SDIO driver to first work.. > Actually SDIO support I'm working on is not ARM-specific, it can work with any SDHC driver FreeBSD already has support for. With the release of RPi3 I'm kinda feel really motivated to finish SDIO implementation ASAP. I've already ordered one board yesterday. Anyone who wants to track progress just keep an eye on https://reviews.freebsd.org/D4761. Short summary: my stack is already able to init SDIO cards and do data transfers. I need to implement some missing bits, but it's in a good shape. I'm doing this work in my spare time, so cannot make any promises, though. -- Ilya From owner-freebsd-arm@freebsd.org Wed Mar 2 11:55:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 37851AC0341 for ; Wed, 2 Mar 2016 11:55:16 +0000 (UTC) (envelope-from fulda@seznam.cz) Received: from wifi.nekropolis.cz (wifi.nekropolis.cz [185.14.235.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "wifi", Issuer "wifi" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id DBD261AF1 for ; Wed, 2 Mar 2016 11:55:15 +0000 (UTC) (envelope-from fulda@seznam.cz) Received: from [10.88.62.44] (home10 [10.88.62.44]) by wifi.nekropolis.cz (8.14.9/8.14.9) with ESMTP id u22BtBRw024447; Wed, 2 Mar 2016 12:55:11 +0100 (CET) (envelope-from fulda@seznam.cz) Subject: Re: Banana pi pro SATA To: Franco Ricci References: <56D0830E.8090802@seznam.cz> Cc: freebsd-arm@freebsd.org From: Jindrich Fucik Message-ID: <56D6D49E.4010407@seznam.cz> Date: Wed, 2 Mar 2016 12:55:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 11:55:16 -0000 OK, good info for me. BTW - I was raised bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=207621 Dne 1.3.2016 v 23:11 Franco Ricci napsal(a): > Hi Jindra, > you are right, the problem is related to disk attached while I reading form SD. > If I boot from SATA disk and I never read nothing form SD all seems to work fine. > > Franco > > > On 26 Feb, 2016, at 5:53 PM, Jindrich Fucik wrote: > >> Franco Ricci franco.ricci at uniroma1.it >> Sat Feb 20 09:59:19 UTC 2016 >> >>> After several days I found that problem was HD type. >>> With a rotational HD all works fine. >>> I don't know why. >> >> Hello Franco, >> >> I fave found, that it does not matter you are using disk or not. >> Only the fact the disk is attached mean, that you will have troubles with reading more files from SD card. >> I did small experiment - download last image (same epeerience with previous one), boot, and without any modifications start reading files from SD. Attached sata ssd have no UFS/FAT partition and no any partition is mounted. (my hardware is Banana PI M1) >> >> Here is three examples: >> read disk using tar with transfer data to another process (wc) and without (to dev/null) >> >> Interesting is, that after successful read, when I'm trying to "halt" the computer I'm receiving fantastic error I not understand. >> >> Outputs from my experiment follows. >> >> Jindra >> >> --------------------------------------------- >> SATA disk attached, but not used: >> --------------------------------------------- >> root@a20:~ # uname -a >> >> FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 05:22:46 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20 arm >> root@a20:~ # tar cf - /usr | wc >> >> tar: Removing leading '/' from member names >> panic: vm_page_insert_after: page already inserted >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 679 tid 100084 ] >> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >> db> >> >> --------------------------------------------- >> root@a20:~ # tar cf /dev/null /usr >> >> tar: Removing leading '/' from member names >> panic: vm_page_insert_after: page already inserted >> cpuid = 0 >> KDB: enter: panic >> [ thread pid 644 tid 100067 ] >> Stopped at $d.7: ldrb r15, [r15, r15, ror r15]! >> db> >> >> >> --------------------------------------------- >> NO SATA disk attached: >> --------------------------------------------- >> >> root@a20:~ # uname -a >> >> FreeBSD a20 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r295683: Wed Feb 17 05:22:46 UTC 2016 root@releng2.nyi.freebsd.org:/usr/obj/arm.armv6/usr/src/sys/A20 arm >> root@a20:~ # tar cf - /usr | wc >> >> tar: Removing leading '/' from member names >> 5994501 28169833 716206080 >> root@a20:~ # >> root@a20:~ # halt >> >> Feb 17 05:37:21 a20 halt: halted by root >> >> Feb 17 05:37:21 a20 syslogd: exiting on signal 15 >> >> Waiting (max 60 seconds) for system process `vnlru' to stop...done >> Waiting (max 60 seconds) for system process `bufdaemon' to stop...done >> Waiting (max 60 seconds) for system process `syncer' to stop... >> Syncing disks, vnodes remaining...2 1 0 0 done >> All buffers synced. >> lock order reversal: >> 1st 0xc45b3db4 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222 >> 2nd 0xc432cc94 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2617 >> stack backtrace: >> lock order reversal: >> 1st 0xc45b3b74 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1222 >> 2nd 0xc45b35d4 devfs (devfs) @ /usr/src/sys/fs/msdosfs/msdosfs_vfsops.c:994 >> stack backtrace: >> Uptime: 3m12s >> >> The operating system has halted. >> Please press any key to reboot. >> _______________________________________________ >> 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 Wed Mar 2 18:26:02 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E68FAC264A for ; Wed, 2 Mar 2016 18:26:02 +0000 (UTC) (envelope-from tom@snnap.net) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::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 2299D11A9 for ; Wed, 2 Mar 2016 18:26:02 +0000 (UTC) (envelope-from tom@snnap.net) Received: by mail-lb0-x233.google.com with SMTP id k15so12294460lbg.0 for ; Wed, 02 Mar 2016 10:26:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snnap-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=3DCw++Yz6zUNKwrgNZD6tjiiWy27+jFTJSybNPatnbQ=; b=z6SoO4sSqWZoSAR877M1411ZoXZs0iucd7FUaxQbGPFiy8dFuPMlTsVM3Gzs/5NXB9 jYAsFAY+FetYiURQ7GX3pJi22Ubyv7PJonF1VrH0ZWeH2xYzu6Yxb1UtKYpLQPjmqo4J J0l+Z7ZjKYOuL+jnZSYomz1/TInbckAH6KcyUmcpU5o/AAwk7grfckzTt+dsy32wMN53 SnHmiqoHuxWN0l1b25Zv84mCgce7nI4RtDbrV5o+L9dIue9pl1kCetkbpceWP7eEerNU FzJ7fbTnZBa34iUExum9h9tyQBNkbwuIDRP0UKytjdtXEPh1sfoeHEWl9j5TlVxJb7Ss YEuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=3DCw++Yz6zUNKwrgNZD6tjiiWy27+jFTJSybNPatnbQ=; b=X0wpQZs2JrMebBGdcMjxZN6hoDRWnPuQZSRJbpgQ7ifEclIxrkFqQKdQVTAcoOYylD s6dmvRoUhjkdtb+EYjpVQ9LIYrG2hbMzfDl9W9xAFDglKfS8w0m2LuI5EcgxuQ5/PqPo pw0oaJ7l4Zxrb360ugiTuOQ9FIHMtSGhiyz1MH09C+sRc0xGrTDCFW8gc4wyuenlyEnA 4QZNR2KVG+41plN7H8DrZs1jKFSYSWo50kruZNjSYUlLUKmapbSZX9qXk9rjGkdV24dW e4rQferlGCj1b+6obAwZ67WB6Ag9d1uiT6MTJlKPljs/yVqjSUN+SnCTkbJ9LYlSM7cm AzFg== X-Gm-Message-State: AD7BkJKDQs4qinOWYivAnIqspVe0+Tosafm/JfJ7AMjQm9pvM5yqF5OTDAq8cm9LojM8g91YIH+ybIbsk+tCqA== MIME-Version: 1.0 X-Received: by 10.112.171.70 with SMTP id as6mr10682376lbc.85.1456943160062; Wed, 02 Mar 2016 10:26:00 -0800 (PST) Received: by 10.25.41.205 with HTTP; Wed, 2 Mar 2016 10:25:59 -0800 (PST) X-Originating-IP: [2001:470:1f09:1cc2:68e2:568b:d4be:4daa] In-Reply-To: <20160229225811.GB74374@server.rulingia.com> References: <20160229225811.GB74374@server.rulingia.com> Date: Wed, 2 Mar 2016 18:25:59 +0000 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Tom Storey To: Peter Jeremy Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 18:26:02 -0000 Ive just got my rpi 3, took the SD card straight out of my rpi 2 and stuck it in, doesnt boot - stuck on the multi coloured screen. Back in the rpi 2 and boots up straight away. I suspect its some device tree thing. The usual suspect. Doesnt look like it will be an easy straight swap. Or the 11-current I am running is too damn old... On 29 February 2016 at 22:58, Peter Jeremy wrote: > Has anyone gotten close enough to a RPi3 to know how difficult it will be > to get FreeBSD to run on it - in particular the Bluetooth and WiFi? > > -- > Peter Jeremy From owner-freebsd-arm@freebsd.org Wed Mar 2 18:57:50 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 20D14AC0485 for ; Wed, 2 Mar 2016 18:57:50 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D8DE21867 for ; Wed, 2 Mar 2016 18:57:49 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk0-x22e.google.com with SMTP id s5so86201100qkd.0 for ; Wed, 02 Mar 2016 10:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=UwjJP1W+QCUE7qnU52JsiUGO3wSDCnGyDQrzigAiZIM=; b=RqAJyjO5pKpt7bVkatC9wCeb+BzkHTK568uQc2Qn0NAk7N6ae2G7UxuihxkKC3HuGR rUNaLdxYTpWJy9QmjGwDP6mQxHbqdwh3tDou+psVQPSuJzr/dHPGLOlb8FDGc31vqLV+ VpiBGSp/tMAWVwX0nUwPyxKY80xO0typgZxMNGF6Mi9Y2Onuq67lS28asteSZfJiw1FK kUQgOoyvqieJdl9Y09EuSWQTei3rqpFJ2G6hMzUq9s8XqhNeHgLLoiF5u+K6ZmogCaYk fBpUEhKEFj4cATMwyk23ZAqm2wZYHmssiPJRGR/tSfYBPYf7cTMsMybVQ7iO2ew8cs3H i8gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=UwjJP1W+QCUE7qnU52JsiUGO3wSDCnGyDQrzigAiZIM=; b=lUmz93uC4WPRR1s+fI/+bBxyKPjlEVPWf9/EaSyPz+r6zIUa3sgANf4Ulv+XjAaTvA SwO6ZrDFC7FNVqdi7vgAS7hv6G7j2m3loppsPaEM5iMhReChfCWbWOYdXrZSbKhX9bdz 0CS1+CkFrSVDV834ie/ImhttP3ELBiy8w453KZIw2zqH32NRprzTZboqANBsQFhJZ9Ij T8ICkDGtbiVXH7XLicpv8nMtSIYs5VWa9377QNGwwRRZw8AiZj5k2ScDJyvaoU3ts/6i JClTkBORcUaIVQDSoMD7+sQjsE8XHk08znQJa4P8tlKBxEKNspbwyTkDEHsS4c89d0lw wkGQ== X-Gm-Message-State: AD7BkJLKi/MQvsJMSTkK77mMnyIcIk5XseguoEtlDE5uUBuefhLoxEb2IzNrtcDLZ2yQpC4/W/nxs5gJoExS7A== MIME-Version: 1.0 X-Received: by 10.55.80.68 with SMTP id e65mr35593193qkb.46.1456945068805; Wed, 02 Mar 2016 10:57:48 -0800 (PST) Sender: wlosh@bsdimp.com Received: by 10.140.30.166 with HTTP; Wed, 2 Mar 2016 10:57:48 -0800 (PST) X-Originating-IP: [50.253.99.174] In-Reply-To: References: <20160229225811.GB74374@server.rulingia.com> Date: Wed, 2 Mar 2016 11:57:48 -0700 X-Google-Sender-Auth: RVaGChnvtzG4REN32g--c0zSfL8 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Warner Losh To: Tom Storey Cc: Peter Jeremy , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 18:57:50 -0000 I suspect that we'll need an aarch64 kernel and userland, at the very least, to make this work. Plus there's likely some dragons hiding in uboot / ubldr. Warner On Wed, Mar 2, 2016 at 11:25 AM, Tom Storey wrote: > Ive just got my rpi 3, took the SD card straight out of my rpi 2 and > stuck it in, doesnt boot - stuck on the multi coloured screen. Back in > the rpi 2 and boots up straight away. > > I suspect its some device tree thing. The usual suspect. > > Doesnt look like it will be an easy straight swap. Or the 11-current I > am running is too damn old... > > On 29 February 2016 at 22:58, Peter Jeremy wrote: > > Has anyone gotten close enough to a RPi3 to know how difficult it will be > > to get FreeBSD to run on it - in particular the Bluetooth and WiFi? > > > > -- > > Peter Jeremy > _______________________________________________ > 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 Wed Mar 2 22:42:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 38A48AC280A for ; Wed, 2 Mar 2016 22:42:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05BE01A3B for ; Wed, 2 Mar 2016 22:42:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-ig0-x22f.google.com with SMTP id i18so1066231igh.1 for ; Wed, 02 Mar 2016 14:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=YuuTW7LDMk+dIHrHI0OcOkWKx2orjpy8WJOLv1f1XGU=; b=ZmsFLitKmVI4OGc/Hsq4rVRpy5lJR67llzQk32uE4eML9B6hgFFKUwehkOHXMk00MS BRX7MVnC7VgIrdvxqdpDvJSAscsC4aStgec+TiYJNZPT5c7M6bNTSBUdekinfT5kDBPj oGysXug2w3XuHoA7mBH913oSx/WvqSDkfdrBPtkQoPdkTmFh2wUqmroSnMBeN5dnHR/P NV6zgtPfKsn/poCjp5Uzxd+LYbmIiKzz7t8ar2/ipf6QjmsmYud+JVTZfLODnX7uyfM0 AONfOvJOon3aRWYNPGAk77mO+7FYiM1ldVPRbEJ2wmaTIBaZ/pPBKRao665MZjisNaAA 5+aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=YuuTW7LDMk+dIHrHI0OcOkWKx2orjpy8WJOLv1f1XGU=; b=a0akh5jiiY34k4yapjebrSFTW/qL2d5Sb2Bj1G4L9sFs1LzorA74YupfEAvLRIIoIw 6XEHX490uxiA7DaN/7hfKQrsViLd4HxDurv/Uozy2LoWPGS3FYRUpygo7qwZWspMvB8l E3faWTYktfHN2v5fPQdMecOjffvM/+QQwiaJW5oJBJx2ZSec1AtklV/pSQFbYVCzaeah xErpb5ImX61kg6kRDMLwv67KMspnXvlBo4bRFhrb0nDyxD1at2RFsjVR6KfmxnYyTdtT oPazAYpI64/spzKC0oiNJR6Tw/e85krk9Kwe/sA1aLaLS1MCq2mwKsDl0l3NCqWi2aR1 BMpQ== X-Gm-Message-State: AD7BkJIupGujBWyQi9HFrXUNn/sc/ibm41vP9js44r91klsZ4ftlTT8Hl3oCawOBHFbCrzKeQ9VW04ZCOxV7/g== MIME-Version: 1.0 X-Received: by 10.50.78.200 with SMTP id d8mr2249554igx.61.1456958538320; Wed, 02 Mar 2016 14:42:18 -0800 (PST) Received: by 10.36.14.19 with HTTP; Wed, 2 Mar 2016 14:42:18 -0800 (PST) In-Reply-To: References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> Date: Wed, 2 Mar 2016 14:42:18 -0800 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Adrian Chadd To: Warner Losh Cc: Shawn Webb , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 22:42:19 -0000 i'm about to try it on this t420 to see if I get cam sdio bus stuff with what's in this box. if so I can take a crack at the marvell sdio driver. but yeah, I'd like someone else to do / own the broadcom stuff. -a On 1 March 2016 at 08:06, Warner Losh wrote: > There's a CAM-ified mmc/sd stack. This has support for the popular > SD bridges that can also do SDIO. There's no wifi nor bt driver for it > yet, though. > > We need to get behind that effort. > > Warner > > On Mon, Feb 29, 2016 at 7:07 PM, Adrian Chadd > wrote: >> >> Someone ordered me one, so I can take a crack at the broadcom sdio bits. >> >> It'll require the ARM SDIO driver to first work.. >> >> >> -a >> _______________________________________________ >> 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 Wed Mar 2 22:43:20 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8DC7AC2921; Wed, 2 Mar 2016 22:43:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 95F611AC8; Wed, 2 Mar 2016 22:43:20 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: by mail-io0-x231.google.com with SMTP id l127so8330156iof.3; Wed, 02 Mar 2016 14:43:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=2ZQ0cYqysD+KomBlDfOhWO7sbjltEdhd/s02jx1Jia0=; b=oKiiW07G+EdccxUkUAseW0HAU8V/K9ocLKNopqYtrSTiRSmMjkWqiWTL632RR3Qjh/ BGJL3tIhOaVCaja+eqBqfv9x/Dq3b4ayLG6sN9aVfbRhQfH5edB4iUj42mvfezlbPf7n Gpia0eyYbIXC+rj9g8DwY8U6XXEopUQEsDge6EaRv/x9wgBsryPQr6St83pQA4T8YCZI RUbgKZ6tAQZnGis2evWUkIhBj3dkwYsW2IERaeAcM9rkO4jzRAVJGkXzRnT5zpb6DC9v 6s/vbMDPBBY+TAFhXvb72RX5s7d+M8OTLhABAkI2GxGipsStW9RhHOBEunGMbUNQ444a 4BRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2ZQ0cYqysD+KomBlDfOhWO7sbjltEdhd/s02jx1Jia0=; b=HZwbpM9QQxptueCGXKwK71F2jsWzRLL3uOOuPHBQ7plkGbhFfWR3o4wjiZxWYaFKMA wkv78mbXXbSh/DY6NaVZ9qpqdpAiyc0QPC0qu96rXGUt9zGevzg21LwA5bli6H+VfPMg aefxviUpVLMOqAZYUZPpKcu0doUwCl+f844DBbSHUWGkvtxKG3OIoJ+Z54q0ZuQxFi+z 7ypwVGK+4u8DCwl1llL9XoOnw2FYUNsKxTvCNMEYp7DUBYpjdN9qJNL1P4WCT2k1aPYb bzSB538CzL+0WK4BsfllIq1ksQIjBjkhqTrj8j/a0Ox0cV1iY7G9Ik9Z83WdKB/+tw/e xQmg== X-Gm-Message-State: AG10YORXAajZUOU7Y5dwhFGISHo6sHInhemOD1F0eXpnVPFROjTZnitvAff5ew/ZRXflsbxYmyqLUIdCFmt/nQ== MIME-Version: 1.0 X-Received: by 10.107.132.142 with SMTP id o14mr31864461ioi.75.1456958599977; Wed, 02 Mar 2016 14:43:19 -0800 (PST) Received: by 10.36.14.19 with HTTP; Wed, 2 Mar 2016 14:43:19 -0800 (PST) In-Reply-To: <437ca32e613c8ecc6825e6da18ca64b1@bakulin.de> References: <20160229225811.GB74374@server.rulingia.com> <20160301002249.GA61549@mutt-hardenedbsd> <437ca32e613c8ecc6825e6da18ca64b1@bakulin.de> Date: Wed, 2 Mar 2016 14:43:19 -0800 Message-ID: Subject: Re: FreeBSD on the RaspberryPi 3 From: Adrian Chadd To: Ilya Bakulin Cc: Shawn Webb , "freebsd-arm@freebsd.org" , owner-freebsd-arm@freebsd.org, Warner Losh Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 22:43:20 -0000 hiya, I'll give this a shot tonight on my -head pc. Poke me on IRC. :) -a On 2 March 2016 at 03:37, Ilya Bakulin wrote: > On 2016-03-01 03:07, Adrian Chadd wrote: >> >> Someone ordered me one, so I can take a crack at the broadcom sdio bits. >> >> It'll require the ARM SDIO driver to first work.. >> > > Actually SDIO support I'm working on is not ARM-specific, it can work with > any SDHC driver FreeBSD already has support for. > > With the release of RPi3 I'm kinda feel really motivated to finish SDIO > implementation ASAP. I've already ordered one board yesterday. > > Anyone who wants to track progress just keep an eye on > https://reviews.freebsd.org/D4761. > Short summary: my stack is already able to init SDIO cards and do data > transfers. I need to implement some missing bits, but it's in a good shape. > > I'm doing this work in my spare time, so cannot make any promises, though. > > -- > Ilya From owner-freebsd-arm@freebsd.org Thu Mar 3 07:10:04 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B71AAC2F14 for ; Thu, 3 Mar 2016 07:10:04 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::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 C78B41C81 for ; Thu, 3 Mar 2016 07:10:03 +0000 (UTC) (envelope-from russ.haley@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id e6so12734537vkh.2 for ; Wed, 02 Mar 2016 23:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HdNpmWofFb31hkd6GCZOsekzmdCiR0LTXbv93sgZuw4=; b=MqYcGAs2w/TPrhwWgtRxC23Xg8IpAi59Gp6bvb8pV272xJNrEborcJW1hCXPOi5JQ3 p1iuUJuJw0jXjBzrJ4Ruh8/Co3ZstzPOUF161a/5pk3bPe2SfmTiCHKlh8lv1A1dyKGH 8X5ENtGoNa6EpRiRMqoj1xrTnSayCHIYn6nlS1LR/W2vK5k6q51ozCC0tsX7wCotnZnK nqrChlnuqvaEXn3VMIkNvpawXMrI12fmX2erQGvGw39pKj2c9ux2C0vpJeOPJOeMn/fi jffEwxDxaJUvEYUdT0A4Wtk5a9b3GePE3G3fpRExLIoJgh3qyrvcxgBo9LAyBS7Y0T0h 8gbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HdNpmWofFb31hkd6GCZOsekzmdCiR0LTXbv93sgZuw4=; b=Hrl+6b7zHes7n0GfAyFOAAntAmpmN8FiS+7jVyNJ8BgVHtkTsBwCSlpXGSDmjEQw7i 3h8L7hKqwitt/cxVga6xOVOZo2cKiiGLALmfnZWwdg1sIgL41jJ4/2h0qIna2rD710ji aj8spj0qklI1zoI8czwOQamTKXvgusi2egz8kfwx8MbcFlakY7Q4wjbRrhwEm0ktSeQ3 YwmRERjHGTbT0IGZ0oJeF7DDbsWi8QJU47Vds5gnZhC14QATe+3yWvmc9Su09029by9F 1laMTrehY1F7/BqPNMqz2mpovzhGp/CbHjPGOGLHIwdk+rxA8swJoLdEqc41ZT4Hd4OJ m4Hw== X-Gm-Message-State: AD7BkJITb42sL+37QMMLlwPypHf4VbBzs48RU7qOkZ8xCv8E4UuBxM7uk+ua4OEOAVAODpmaLA3MkY7meYq3og== MIME-Version: 1.0 X-Received: by 10.31.141.75 with SMTP id p72mr764977vkd.13.1456989002814; Wed, 02 Mar 2016 23:10:02 -0800 (PST) Received: by 10.31.54.13 with HTTP; Wed, 2 Mar 2016 23:10:02 -0800 (PST) In-Reply-To: <1456154162.1294.51.camel@freebsd.org> References: <20140216111153.GA74858@olymp.kibab.com> <5C2CF572-360D-4CA0-81C7-18A5C455AED5@bsdimp.com> <20140224142642.GA32538@olymp.kibab.com> <53120EE8.1080600@bakulin.de> <5688F015.4090002@bakulin.de> <6942A46B-110B-4E1F-9DA1-F965009E8E92@FreeBSD.org> <38dd08fc2a5930d58b09e9bd3cb6d3e7@bakulin.de> <1456154162.1294.51.camel@freebsd.org> Date: Wed, 2 Mar 2016 23:10:02 -0800 Message-ID: Subject: Re: MMC/SDIO stack under CAM From: Russell Haley To: Ilya Bakulin Cc: "freebsd-arm@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 07:10:04 -0000 Hello Ilya, I have tried running patch D4761 against r296336 and ran into a make error. As follows: cd /usr/src svn patch /usr/patches/D4761.diff U etc/mtree/BSD.include.dist > applied hunk @@ -92,6 +92,8 @@ with fuzz 2 > applied hunk @@ -224,7 +226,7 @@ with offset 2 U include/Makefile U lib/libcam/Makefile U sbin/camcontrol/camcontrol.c U sys/Makefile A sys/arm/conf/BEAGLEBONE-CAM U sys/arm/ti/ti_sdhci.c U sys/cam/cam_ccb.h U sys/cam/cam_xpt.c U sys/cam/cam_xpt_internal.h A sys/cam/mmc A sys/cam/mmc/mmc.h A sys/cam/mmc/mmc_all.h A sys/cam/mmc/mmc_bus.h A sys/cam/mmc/mmc_da.c A sys/cam/mmc/mmc_sdio.h A sys/cam/mmc/mmc_sdio.c A sys/cam/mmc/mmc_xpt.c A sys/cam/mmc/mmcreg.h U sys/conf/files > applied hunk @@ -1554,10 +1557,10 @@ with offset 6 > applied hunk @@ -1960,6 +1963,7 @@ with offset 10 A sys/dev/mmcnull A sys/dev/mmcnull/Makefile A sys/dev/mmcnull/mmcnull.c U sys/dev/sdhci/sdhci.h U sys/dev/sdhci/sdhci.c A sys/modules/mmcnull A sys/modules/mmcnull/Makefile root@a5e5b565-d3ae-11e5-a511-0c54a518c15b:/usr/src # ls .arcconfig bin rescue .arclint cddl sbin .svn contrib secure COPYRIGHT crypto share LOCKS etc sys MAINTAINERS gnu targets Makefile include tests Makefile.inc1 kerberos5 tools ObsoleteFiles.inc lib usr.bin README libexec usr.sbin UPDATING release #make TARGET=arm TARGET_ARCH=armv6 KERNCONF=IMX6 -j20 buildkernel ... --- mmc_da.o --- /usr/src/sys/cam/mmc/mmc_da.c:855:20: error: format specifies type 'unsigned long' but the argument has type 'uint64_t' (aka 'unsigned long long') [-Werror,-Wformat] softc->csd.capacity, ^~~~~~~~~~~~~~~~~~~ /usr/src/sys/cam/cam_debug.h:97:10: note: expanded from macro 'CAM_DEBUG' printf printfargs; \ ^ --- modules-all --- --- all_subdir_accf_dns --- --- accf_dns.o --- --- mmc_da.o --- 1 error generated. *** [mmc_da.o] Error code 1 make[2]: stopped in /usr/obj/arm.armv6/usr/src/sys/IMX6 --- modules-all --- Thanks, Russ On Mon, Feb 22, 2016 at 7:16 AM, Ian Lepore wrote: > On Sun, 2016-02-21 at 23:28 -0800, Russell Haley wrote: >> On Mon, Feb 15, 2016 at 9:33 PM, Warner Losh wrote: >> > On Mon, Feb 15, 2016 at 7:22 AM, NGie Cooper > > > wrote: >> > >> > > >> > > > On Feb 15, 2016, at 02:13, Ilya Bakulin >> > > > wrote: >> > > > >> > > > On 2016-02-11 19:54, Stanislav Sedov wrote: >> > > > > > On Feb 11, 2016, at 10:47 AM, Ilya Bakulin > > > > > > > wrote: >> > > > > > I'll use an excellent opportunity to post a small status >> > > > > > update about >> > > my work :-) >> > > > > > * SDHC controller on Wandboard now works with the new >> > > > > > stack; >> > > > > > * SDIO block read now works! >> > > > > > * camcontrol userland app is extended to support "mmcsdcmd" >> > > > > > command >> > > that allows to send MMC commands from userland apps directly to >> > > the card >> > > via pass(4) device -- now we can write WLAN driver in userland : >> > > -D >> > > > > Great news, userspace drivers are the best!:) >> > > > > So what are the remaining pieces that prevent this work from >> > > > > hitting >> > > the HEAD? >> > > > > -- >> > > > > Stanislav Sedov >> > > > > ST4096-RIPE >> > > > >> > > > Hi Stas, >> > > > >> > > > As I'm not a committer, someone needs to review my code and >> > > > assist in >> > > intergration into -HEAD :-) >> > > > Currently nobody was able to do a review because of -ENOTIME. >> > > > The only feature that is missing in the new stack (from my PoV) >> > > > is >> > > working with high-speed cards -- I just haven't implemented >> > > switching to >> > > high-speed mode yet. Although now it's possible to send required >> > > commands >> > > to the card and then switch controller speed -- all using >> > > camcontrol >> > > mmcsdcmd :-). >> > > > >> > > > Do you know anyone not on CC line who is able to help me with >> > > > this? Or >> > > maybe you could even find some time yourself? >> > > >> > > Hi Ilya, >> > > Could you please post the patch to phrabricator and CC the >> > > interested >> > > parties/me? >> > > >> > >> > It's been up on phab for a while. There's been some comments on it. >> > There's >> > some >> > things wrong still that I've been meaning to get bcak to Ilya on. >> > >> > When it is ready, I plan on committing this. It goes hand in hand >> > with the >> > nvme CAM stuff >> > I've been working on. >> > >> > Anybody can take a look at it: https://reviews.freebsd.org/D4761 >> > >> >> I tried to apply the SDIO patch like this: >> >> mv ~/Downloads/D4761.diff /usr/patches >> >> Then from within my build jail: >> cd /usr/src >> patch < /usr/patches/D4761.diff >> >> and I wind up with the mmc source files in my root. What should my >> working directory be when applying this patch? > > That's an annoying historical quirk of patch... for files in the > patches where the path doesn't already exist in your filesystem it just > creates the files in the current dir, unless you add -p0, which will > make it create missing directories. (-p normally tells it how many > leading dir nodes to strip from the paths found in the patches, but -p0 > is magical in that it strips nothing but creates dirs). > > -- Ian > From owner-freebsd-arm@freebsd.org Thu Mar 3 14:39:32 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB314A93E16 for ; Thu, 3 Mar 2016 14:39:32 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "raven.bwct.de", Issuer "BWCT" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4A536A6A for ; Thu, 3 Mar 2016 14:39:31 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id u23Ed8xH091083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 3 Mar 2016 15:39:15 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id u23Ed2tB021636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 3 Mar 2016 15:39:02 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTP id u23Ed1Kd068322; Thu, 3 Mar 2016 15:39:01 +0100 (CET) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id u23Ed0O5068321; Thu, 3 Mar 2016 15:39:00 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Mar 2016 15:39:00 +0100 From: Bernd Walter To: Warner Losh Cc: Tom Storey , "freebsd-arm@freebsd.org" Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160303143900.GL63541@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20160229225811.GB74374@server.rulingia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 10.2-RELEASE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2016 14:39:32 -0000 On Wed, Mar 02, 2016 at 11:57:48AM -0700, Warner Losh wrote: > I suspect that we'll need an aarch64 kernel and userland, at the very least, > to make this work. Plus there's likely some dragons hiding in uboot / ubldr. Would be greatest, but to my knowledge the official Raspberry Linux images also just run a 32bit kernel for now. This probably mean we could be the first 64bit OS on that hardware... -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Fri Mar 4 13:33:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7B2149DBD4E for ; Fri, 4 Mar 2016 13:33:37 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 4A963AA9 for ; Fri, 4 Mar 2016 13:33:36 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=ZulNU4PG c=1 sm=1 tr=0 a=aps9VBOkFNN2EN8VlaEDew==:117 a=aps9VBOkFNN2EN8VlaEDew==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=0m7h8hzpAAAA:8 a=6I5d2MoRAAAA:8 a=kd0zDrYRPft-03L5HhIA:9 a=CjuIK1q_8ugA:10 a=-FEs8UIgK8oA:10 a=NWVoK91CQyQA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 166.170.220.175 is neither permitted nor denied by domain of rcn.com) Received: from [166.170.220.175] ([166.170.220.175:32958] helo=[10.212.180.50]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPA id 46/35-31527-AAE89D65; Fri, 04 Mar 2016 08:33:30 -0500 References: <20160229225811.GB74374@server.rulingia.com> <20160303143900.GL63541@cicely7.cicely.de> Mime-Version: 1.0 (1.0) In-Reply-To: <20160303143900.GL63541@cicely7.cicely.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Cc: Warner Losh , "freebsd-arm@freebsd.org" X-Mailer: iPhone Mail (13D15) From: Erik Moe Subject: Re: FreeBSD on the RaspberryPi 3 Date: Fri, 4 Mar 2016 07:33:29 -0600 To: ticso@cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 13:33:37 -0000 It looks like Raspbian was updated just before the release of the Pi 3. I d= ownloaded it and looked at the u-boot parts. At the very least there is a ne= w dtb file that is Pi 3 specific. > On Mar 3, 2016, at 8:39 AM, Bernd Walter wrote: >=20 >> On Wed, Mar 02, 2016 at 11:57:48AM -0700, Warner Losh wrote: >> I suspect that we'll need an aarch64 kernel and userland, at the very lea= st, >> to make this work. Plus there's likely some dragons hiding in uboot / ubl= dr. >=20 > Would be greatest, but to my knowledge the official Raspberry Linux images= > also just run a 32bit kernel for now. > This probably mean we could be the first 64bit OS on that hardware... >=20 > --=20 > B.Walter http://www.bwct.de > Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Fri Mar 4 14:08:22 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 03E0F9DA80C for ; Fri, 4 Mar 2016 14:08:22 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id C91F0A7C for ; Fri, 4 Mar 2016 14:08:21 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-142.nat-2.net.cam.ac.uk [131.111.5.142]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 55FC5D7A17; Fri, 4 Mar 2016 13:58:24 +0000 (UTC) Date: Fri, 4 Mar 2016 13:58:21 +0000 From: Andrew Turner To: Warner Losh Cc: Tom Storey , "freebsd-arm@freebsd.org" Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160304135821.79d140ae@zapp> In-Reply-To: References: <20160229225811.GB74374@server.rulingia.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.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.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 14:08:22 -0000 On Wed, 2 Mar 2016 11:57:48 -0700 Warner Losh wrote: > I suspect that we'll need an aarch64 kernel and userland, at the very > least, to make this work. Plus there's likely some dragons hiding in > uboot / ubldr. Someone should try updating the firmware on the RPI2 image, and teaching the kernel about the Cortex-A53 in cpufunc.c. I suspect with these two FreeBSD will boot in AArch32. Andrew From owner-freebsd-arm@freebsd.org Fri Mar 4 14:24:59 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 266259DAE54 for ; Fri, 4 Mar 2016 14:24:59 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from planck.konjz.org (vmae8814.bsws.de [81.209.182.218]) (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 A0E1B6EA for ; Fri, 4 Mar 2016 14:24:57 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from [192.168.27.109] (cpe-98-14-243-238.nyc.res.rr.com [98.14.243.238]) (authenticated bits=0) by planck.konjz.org (8.14.8/8.14.8) with ESMTP id u24E4YL1015805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 4 Mar 2016 09:04:35 -0500 (EST) To: "freebsd-arm@freebsd.org" From: George Rosamond Subject: OpenBSD RPi3 dmesg and install prompt Message-ID: <56D995F2.10909@ceetonetechnology.com> Date: Fri, 4 Mar 2016 09:04:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Names: RDNS_DYNAMIC X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.74 on 81.209.182.218 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 14:24:59 -0000 fyi: http://ix.io/oJV g From owner-freebsd-arm@freebsd.org Fri Mar 4 14:31:14 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D55DF9DA12F for ; Fri, 4 Mar 2016 14:31:14 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::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 64C398A5 for ; Fri, 4 Mar 2016 14:31:14 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lb0-x232.google.com with SMTP id bc4so62905985lbc.2 for ; Fri, 04 Mar 2016 06:31:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:to:message-id:date:user-agent:mime-version; bh=ty+nUGodLYKGjUxLmimhywloCqVqzHMqfNc/id+ecLs=; b=Z58AyyjLztSWSPXVNYrzfh/XRwUqKHJ/XyGkwm/2cN6jgnf/7WU1EeOlmHGzXdvnj4 Ix4995D0F5eBc4yE0vE68f6IrB6elbSw9JTCfU4UZTx4tj8Pd5tFdVLNwvXGnO33Vey0 ewYi0PLEqSAuXBqlG3ESpXRT+dRHidE3kpHK7XIIxANtmCF9geIFatI/io+viDy54WlF qtBLAmKtX8yJoJydyb+XvhuIazXMIuAx+fi3rbCCRJQgGMB+qBi4fmh1ddwXRKLdPAbH Es9tyI0N5YN350hlua5LLukH9jX3IAPskkjZGptUptK+r3NYGw1E7Xm+3J9Can66+BnB paxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version; bh=ty+nUGodLYKGjUxLmimhywloCqVqzHMqfNc/id+ecLs=; b=gqKdgDW0toXdeTMIP/hVwS20U/lrQSsczDe2dAQKI5ngtvYQ3JytK/B8rHu7DgSmkt SUt6tRthTnANmmN+cXGyHl6GTTaFfMkbz+8Uxy1znoSUNOqKPJl+AVl7FctWNSN52EPN 4VDzfAIV0Bf8rjHWvehTTpd3R9DKC9xpZDpsO2OJcq0rL/KrjrtBQhxhM42uCVZzKdvq cfT5aMsZzYjLyItaudcPGP3isQ0+FbHgNw4nYjsjrMXnXamqECKOUn2bLD6bldqQ4en6 wLCOHuh5PwK/lsxyOVmIppsSnq6MK2eiKW3couWh/rAY20nmrVY4IAkHOGCn6f25DA+3 K5Kg== X-Gm-Message-State: AD7BkJLpgQrCJOLc33QY6dEqwJ+otaDnFECRcY6W8wdqpXJuMGVLDyUogJG6WveUsORIuw== X-Received: by 10.25.151.149 with SMTP id z143mr2762347lfd.72.1457101872520; Fri, 04 Mar 2016 06:31:12 -0800 (PST) Received: from [192.168.1.131] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.googlemail.com with ESMTPSA id t17sm640762lfd.17.2016.03.04.06.31.11 for (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Mar 2016 06:31:11 -0800 (PST) From: Jukka Ukkonen Subject: Odd hang during boot on RPI2 for 2 days now X-Enigmail-Draft-Status: N1110 To: freebsd-arm Message-ID: <56D99C2E.4020301@gmail.com> Date: Fri, 4 Mar 2016 16:31:10 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------040206050109000707000103" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 14:31:15 -0000 This is a multi-part message in MIME format. --------------040206050109000707000103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello all, A couple of days ago I rebuilt 11-current for my RPI2. For some odd and still unexplained reason it started hanging after it had found the USB keyboard during the auto-configure. I have tried "svn update" a few times since the problem started, but apparently there has been no patch to this. The latest svn version which I have tried is 296383. I attach the dmesg.boot from the last known good boot. It shows the last known properly booting system was 11.0-CURRENT r296310. I have also marked the place where the boot now hangs as follows ... ... kbd1 at ukbd0 *** smsc0: chip 0xec00, rev. 0002 ... Everything before the "***" mark seems to work just fine. At the mark all progress stops and none of the messages normally seen after this point are shown. Has something changed perhaps in a manner which could cause this hang? --jau --------------040206050109000707000103 Content-Type: text/plain; charset=UTF-8; name="last_good_dmesg.boot" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="last_good_dmesg.boot" S0RCOiBkZWJ1Z2dlciBiYWNrZW5kczogZGRiCktEQjogY3VycmVudCBiYWNrZW5kOiBkZGIK Q29weXJpZ2h0IChjKSAxOTkyLTIwMTYgVGhlIEZyZWVCU0QgUHJvamVjdC4KQ29weXJpZ2h0 IChjKSAxOTc5LCAxOTgwLCAxOTgzLCAxOTg2LCAxOTg4LCAxOTg5LCAxOTkxLCAxOTkyLCAx OTkzLCAxOTk0CglUaGUgUmVnZW50cyBvZiB0aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlh LiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1h cmsgb2YgVGhlIEZyZWVCU0QgRm91bmRhdGlvbi4KRnJlZUJTRCAxMS4wLUNVUlJFTlQgIzAg cjI5NjMxMDogV2VkIE1hciAgMiAxNTowOToyMSBFRVQgMjAxNgogICAgamF1QHNsZWlwbmly Oi90YW5rL2Zpc2gvamF1L1hjb21wL29iai9hcm0uYXJtdjZoZi90YW5rL2Zpc2gvamF1L1hj b21wL3NyYy5oZWFkL3N5cy9SUEkyIGFybQpGcmVlQlNEIGNsYW5nIHZlcnNpb24gMy43LjEg KHRhZ3MvUkVMRUFTRV8zNzEvZmluYWwgMjU1MjE3KSAyMDE1MTIyNQpWVDogaW5pdCB3aXRo b3V0IGRyaXZlci4Kc2VtYV9zeXNpbml0CkNQVTogQ29ydGV4IEE3IHJldiA1IChDb3J0ZXgt QSBjb3JlKQogU3VwcG9ydGVkIGZlYXR1cmVzOiBBUk1fSVNBIFRIVU1CMiBKQVpFTExFIFRI VU1CRUUgQVJNdjQgU2VjdXJpdHlfRXh0CiBXQiBlbmFibGVkIExBQlQgYnJhbmNoIHByZWRp Y3Rpb24gZGlzYWJsZWQKTG9VVToyIExvQzozIExvVUlTOjIgCkNhY2hlIGxldmVsIDE6IAog MzJLQi82NEIgNC13YXkgZGF0YSBjYWNoZSBXQiBSZWFkLUFsbG9jIFdyaXRlLUFsbG9jCiAz MktCLzMyQiAyLXdheSBpbnN0cnVjdGlvbiBjYWNoZSBSZWFkLUFsbG9jCkNhY2hlIGxldmVs IDI6IAogNTEyS0IvNjRCIDgtd2F5IHVuaWZpZWQgY2FjaGUgV0IgUmVhZC1BbGxvYyBXcml0 ZS1BbGxvYwpyZWFsIG1lbW9yeSAgPSA5ODk4NTE2NDggKDk0MyBNQikKYXZhaWwgbWVtb3J5 ID0gOTU2NDAzNzEyICg5MTIgTUIpCkZyZWVCU0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0 ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcwpyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVybmFsIGlu dGVyZmFjZQprYmQwIGF0IGtiZG11eDAKb2Z3YnVzMDogPE9wZW4gRmlybXdhcmUgRGV2aWNl IFRyZWU+CnNpbXBsZWJ1czA6IDxGbGF0dGVuZWQgZGV2aWNlIHRyZWUgc2ltcGxlIGJ1cz4g bWVtIDB4M2YwMDAwMDAtMHgzZmZmZmZmZiBvbiBvZndidXMwCmJjbTI4MzYwOiA8QnJvYWRj b20gYmNtMjgzNj4KZ2VuZXJpY190aW1lcjA6IDxBUk12NyBHZW5lcmljIFRpbWVyPiBpcnEg NzIsNzMsNzUsNzQgb24gb2Z3YnVzMApUaW1lY291bnRlciAiQVJNIE1QQ29yZSBUaW1lY291 bnRlciIgZnJlcXVlbmN5IDE5MjAwMDAwIEh6IHF1YWxpdHkgMTAwMApFdmVudCB0aW1lciAi QVJNIE1QQ29yZSBFdmVudHRpbWVyIiBmcmVxdWVuY3kgMTkyMDAwMDAgSHogcXVhbGl0eSAx MDAwCmludGMwOiA8QkNNMjgzNSBJbnRlcnJ1cHQgQ29udHJvbGxlcj4gbWVtIDB4YjIwMC0w eGIzZmYgb24gc2ltcGxlYnVzMApiY213ZDA6IDxCQ00yNzA4LzI4MzUgV2F0Y2hkb2c+IG1l bSAweDEwMDAxYy0weDEwMDAyNyBvbiBzaW1wbGVidXMwCmdwaW8wOiA8QkNNMjcwOC8yODM1 IEdQSU8gY29udHJvbGxlcj4gbWVtIDB4MjAwMDAwLTB4MjAwMGFmIGlycSA1Nyw1OSw1OCw2 MCBvbiBzaW1wbGVidXMwCmdwaW8wOiByZWFkLW9ubHkgcGluczogNDYsNDgtNTMuCmdwaW8w OiByZXNlcnZlZCBwaW5zOiA0OC01My4KZ3Bpb2J1czA6IDxPRlcgR1BJTyBidXM+IG9uIGdw aW8wCmdwaW9sZWQwOiA8R1BJTyBsZWQ+IGF0IHBpbiAzNSBvbiBncGlvYnVzMApncGlvbGVk MTogPEdQSU8gbGVkPiBhdCBwaW4gNDcgb24gZ3Bpb2J1czAKZ3Bpb2MwOiA8R1BJTyBjb250 cm9sbGVyPiBvbiBncGlvMAppaWNoYjA6IDxCQ00yNzA4LzI4MzUgQlNDIGNvbnRyb2xsZXI+ IG1lbSAweDIwNTAwMC0weDIwNTAxZiBpcnEgNjEgb24gc2ltcGxlYnVzMAppaWNidXMwOiA8 T0ZXIEkyQyBidXM+IG9uIGlpY2hiMAppaWMwOiA8STJDIGdlbmVyaWMgSS9PPiBvbiBpaWNi dXMwCmlpY2hiMTogPEJDTTI3MDgvMjgzNSBCU0MgY29udHJvbGxlcj4gbWVtIDB4ODA0MDAw LTB4ODA0MDFmIGlycSA2MSBvbiBzaW1wbGVidXMwCmlpY2J1czE6IDxPRlcgSTJDIGJ1cz4g b24gaWljaGIxCmlpYzE6IDxJMkMgZ2VuZXJpYyBJL08+IG9uIGlpY2J1czEKZHMzMjMxMDog PE1heGltIERTMzIzMSBSVEM+IGF0IGFkZHIgMHhkMCBvbiBpaWNidXMxCnNwaTA6IDxCQ00y NzA4LzI4MzUgU1BJIGNvbnRyb2xsZXI+IG1lbSAweDIwNDAwMC0weDIwNDAxZiBpcnEgNjIg b24gc2ltcGxlYnVzMApzcGlidXMwOiA8T0ZXIFNQSSBidXM+IG9uIHNwaTAKYmNtX2RtYTA6 IDxCQ00yODM1IERNQSBDb250cm9sbGVyPiBtZW0gMHg3MDAwLTB4N2ZmZiwweGUwNTAwMC0w eGUwNWZmZiBpcnEgMjQsMjUsMjYsMjcsMjgsMjksMzAsMzEsMzIsMzMsMzQsMzUsMzYgb24g c2ltcGxlYnVzMAptYm94MDogPEJDTTI4MzUgVmlkZW9Db3JlIE1haWxib3g+IG1lbSAweGI4 ODAtMHhiOGJmIGlycSAxIG9uIHNpbXBsZWJ1czAKc2RoY2lfYmNtMDogPEJyb2FkY29tIDI3 MDggU0RIQ0kgY29udHJvbGxlcj4gbWVtIDB4MzAwMDAwLTB4MzAwMGZmIGlycSA3MCBvbiBz aW1wbGVidXMwCm1tYzA6IDxNTUMvU0QgYnVzPiBvbiBzZGhjaV9iY20wCnVhcnQwOiA8UHJp bWVDZWxsIFVBUlQgKFBMMDExKT4gbWVtIDB4MjAxMDAwLTB4MjAxZmZmIGlycSA2NSBvbiBz aW1wbGVidXMwCnVhcnQwOiBjb25zb2xlICgxMTUyMDAsbiw4LDEpCnZjaGlxMDogPEJDTTI4 MzUgVkNISVE+IG1lbSAweGI4MDAtMHhiODRmIGlycSAyIG9uIHNpbXBsZWJ1czAKdmNoaXE6 IGxvY2FsIHZlciA4IChtaW4gMyksIHJlbW90ZSB2ZXIgOC4KcGNtMDogPFZDSElRIGF1ZGlv PiBvbiB2Y2hpcTAKYmNtMjgzeF9kd2NvdGcwOiA8RFdDIE9URyAyLjAgaW50ZWdyYXRlZCBV U0IgY29udHJvbGxlciAoYmNtMjgzeCk+IG1lbSAweDk4MDAwMC0weDk5ZmZmZiBpcnEgMTcg b24gc2ltcGxlYnVzMAp1c2J1czAgb24gYmNtMjgzeF9kd2NvdGcwCmNwdWxpc3QwOiA8T3Bl biBGaXJtd2FyZSBDUFUgR3JvdXA+IG9uIG9md2J1czAKY3B1MDogPE9wZW4gRmlybXdhcmUg Q1BVPiBvbiBjcHVsaXN0MApiY20yODM1X2NwdWZyZXEwOiA8Q1BVIEZyZXF1ZW5jeSBDb250 cm9sPiBvbiBjcHUwCmNwdTE6IDxPcGVuIEZpcm13YXJlIENQVT4gb24gY3B1bGlzdDAKY3B1 MjogPE9wZW4gRmlybXdhcmUgQ1BVPiBvbiBjcHVsaXN0MApjcHUzOiA8T3BlbiBGaXJtd2Fy ZSBDUFU+IG9uIGNwdWxpc3QwCmZiMDogPEJDTTI4MzUgVlQgZnJhbWVidWZmZXIgZHJpdmVy PiBvbiBvZndidXMwCmZiZDAgb24gZmIwClZUOiBpbml0aWFsaXplIHdpdGggbmV3IFZUIGRy aXZlciAiZmIiLgpmYjA6IDE2MDB4MTIwMCgxNjAweDEyMDBAMCwwKSAyNGJwcApmYjA6IGZi c3dhcDogMSwgcGl0Y2ggNDgwMCwgYmFzZSAweDNkMmQyMDAwLCBzY3JlZW5fc2l6ZSA1NzYw MDAwCmNyeXB0b3NvZnQwOiA8c29mdHdhcmUgY3J5cHRvPgpUaW1lY291bnRlcnMgdGljayBl dmVyeSAxMC4wMDAgbXNlYwpJUHNlYzogSW5pdGlhbGl6ZWQgU2VjdXJpdHkgQXNzb2NpYXRp b24gUHJvY2Vzc2luZy4KdXNidXMwOiA0ODBNYnBzIEhpZ2ggU3BlZWQgVVNCIHYyLjAKdWdl bjAuMTogPERXQ09URz4gYXQgdXNidXMwCnVodWIwOiA8RFdDT1RHIE9URyBSb290IEhVQiwg Y2xhc3MgOS8wLCByZXYgMi4wMC8xLjAwLCBhZGRyIDE+IG9uIHVzYnVzMAptbWNzZDA6IDY0 R0IgPFNESEMgICAgICAgMC4xIFNOIEQwQjUwMTg0IE1GRyAwMS8yMDE1IGJ5IDQwIEJFPiBh dCBtbWMwIDQxLjZNSHovNGJpdC82NTUzNS1ibG9jawpiY20yODM1X2NwdWZyZXEwOiBBUk0g NjAwTUh6LCBDb3JlIDI1ME1IeiwgU0RSQU0gNDAwTUh6LCBUdXJibyBPRkYKUmVsZWFzZSBB UHMKVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1ZnM6L2Rldi9tbWNzZDBzMmEgW10uLi4K dWh1YjA6IDEgcG9ydCB3aXRoIDEgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQKdWdlbjAuMjog PHZlbmRvciAweDA0MjQ+IGF0IHVzYnVzMAp1aHViMTogPHZlbmRvciAweDA0MjQgcHJvZHVj dCAweDk1MTQsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMi4wMCwgYWRkciAyPiBvbiB1c2J1czAK dWh1YjE6IE1UVCBlbmFibGVkCnVodWIxOiA1IHBvcnRzIHdpdGggNCByZW1vdmFibGUsIHNl bGYgcG93ZXJlZApyYW5kb206IHVuYmxvY2tpbmcgZGV2aWNlLgp1Z2VuMC4zOiA8dmVuZG9y IDB4MDQyND4gYXQgdXNidXMwCnNtc2MwOiA8dmVuZG9yIDB4MDQyNCBwcm9kdWN0IDB4ZWMw MCwgcmV2IDIuMDAvMi4wMCwgYWRkciAzPiBvbiB1c2J1czAKc21zYzA6IGNoaXAgMHhlYzAw LCByZXYuIDAwMDIKbWlpYnVzMDogPE1JSSBidXM+IG9uIHNtc2MwCnVrcGh5MDogPEdlbmVy aWMgSUVFRSA4MDIuM3UgbWVkaWEgaW50ZXJmYWNlPiBQSFkgMSBvbiBtaWlidXMwCnVrcGh5 MDogIG5vbmUsIDEwYmFzZVQsIDEwYmFzZVQtRkRYLCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1G RFgsIGF1dG8KdWUwOiA8VVNCIEV0aGVybmV0PiBvbiBzbXNjMAp1ZTA6IEV0aGVybmV0IGFk ZHJlc3M6IGI4OjI3OmViOjIzOmZkOmIxCnVnZW4wLjQ6IDxNaXRzdW1pIEVsZWN0cmljPiBh dCB1c2J1czAKdWh1YjI6IDxNaXRzdW1pIEVsZWN0cmljIEh1YiBpbiBBcHBsZSBFeHRlbmRl ZCBVU0IgS2V5Ym9hcmQsIGNsYXNzIDkvMCwgcmV2IDEuMTAvNC4xMCwgYWRkciA0PiBvbiB1 c2J1czAKdWh1YjI6IDMgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgYnVzIHBvd2VyZWQKdWdl bjAuNTogPE1pdHN1bWkgRWxlY3RyaWM+IGF0IHVzYnVzMAp1a2JkMDogPE1pdHN1bWkgRWxl Y3RyaWMgQXBwbGUgRXh0ZW5kZWQgVVNCIEtleWJvYXJkLCBjbGFzcyAwLzAsIHJldiAxLjEw LzQuMTAsIGFkZHIgNT4gb24gdXNidXMwCmtiZDEgYXQgdWtiZDAKKioqCnNtc2MwOiBjaGlw IDB4ZWMwMCwgcmV2LiAwMDAyCnVlMDogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04KdWUw OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVAKdWhpZDA6IDxNaXRzdW1pIEVsZWN0cmljIEFw cGxlIEV4dGVuZGVkIFVTQiBLZXlib2FyZCwgY2xhc3MgMC8wLCByZXYgMS4xMC80LjEwLCBh ZGRyIDU+IG9uIHVzYnVzMAo= --------------040206050109000707000103-- From owner-freebsd-arm@freebsd.org Fri Mar 4 15:00:16 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48EDE9DAE24 for ; Fri, 4 Mar 2016 15:00:16 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id 1AC0BA44 for ; Fri, 4 Mar 2016 15:00:15 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp (global-5-142.nat-2.net.cam.ac.uk [131.111.5.142]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id D708CD7A17; Fri, 4 Mar 2016 15:00:14 +0000 (UTC) Date: Fri, 4 Mar 2016 15:00:13 +0000 From: Andrew Turner To: George Rosamond Cc: "freebsd-arm@freebsd.org" Subject: Re: OpenBSD RPi3 dmesg and install prompt Message-ID: <20160304150013.12fa2684@zapp> In-Reply-To: <56D995F2.10909@ceetonetechnology.com> References: <56D995F2.10909@ceetonetechnology.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.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.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 15:00:16 -0000 On Fri, 4 Mar 2016 09:04:34 -0500 George Rosamond wrote: > fyi: > > http://ix.io/oJV And FreeBSD runs under arm64 to multiuser: http://pastebin.ca/3387711 Andrew From owner-freebsd-arm@freebsd.org Fri Mar 4 19:29:23 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E76EB9DB008 for ; Fri, 4 Mar 2016 19:29:23 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B61E380E for ; Fri, 4 Mar 2016 19:29:23 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.101] (p508F054F.dip0.t-ipconnect.de [80.143.5.79]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 671EE1C104DAF; Fri, 4 Mar 2016 20:29:20 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: OpenBSD RPi3 dmesg and install prompt From: Michael Tuexen In-Reply-To: <20160304150013.12fa2684@zapp> Date: Fri, 4 Mar 2016 20:29:19 +0100 Cc: George Rosamond , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: 7bit Message-Id: <1F782CC4-7301-40FB-95D8-27D00BFA17A8@freebsd.org> References: <56D995F2.10909@ceetonetechnology.com> <20160304150013.12fa2684@zapp> To: Andrew Turner X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 19:29:24 -0000 > On 04 Mar 2016, at 16:00, Andrew Turner wrote: > > On Fri, 4 Mar 2016 09:04:34 -0500 > George Rosamond wrote: > >> fyi: >> >> http://ix.io/oJV > > And FreeBSD runs under arm64 to multiuser: > > http://pastebin.ca/3387711 Cool! What changes / steps are needed? Best regards Michael > > Andrew > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Fri Mar 4 21:18:41 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4F09F9DA603 for ; Fri, 4 Mar 2016 21:18:41 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from planck.konjz.org (vmae8814.bsws.de [81.209.182.218]) (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 DC9DDE23; Fri, 4 Mar 2016 21:18:39 +0000 (UTC) (envelope-from george@ceetonetechnology.com) Received: from [192.168.27.109] (cpe-98-14-243-238.nyc.res.rr.com [98.14.243.238]) (authenticated bits=0) by planck.konjz.org (8.14.8/8.14.8) with ESMTP id u24LIXpA030906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 4 Mar 2016 16:18:34 -0500 (EST) Subject: Re: OpenBSD RPi3 dmesg and install prompt To: Michael Tuexen , Andrew Turner References: <56D995F2.10909@ceetonetechnology.com> <20160304150013.12fa2684@zapp> <1F782CC4-7301-40FB-95D8-27D00BFA17A8@freebsd.org> Cc: "freebsd-arm@freebsd.org" From: George Rosamond Message-ID: <56D9FBA9.8050303@ceetonetechnology.com> Date: Fri, 4 Mar 2016 16:18:33 -0500 MIME-Version: 1.0 In-Reply-To: <1F782CC4-7301-40FB-95D8-27D00BFA17A8@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Names: RDNS_DYNAMIC X-Mail-Provider: KonjZ X-Scanned-By: MIMEDefang 2.74 on 81.209.182.218 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 21:18:41 -0000 On 03/04/16 14:29, Michael Tuexen wrote: >> On 04 Mar 2016, at 16:00, Andrew Turner wrote: >> >> On Fri, 4 Mar 2016 09:04:34 -0500 >> George Rosamond wrote: >> >>> fyi: >>> >>> http://ix.io/oJV >> >> And FreeBSD runs under arm64 to multiuser: >> >> http://pastebin.ca/3387711 > Cool! > > What changes / steps are needed? > Just forwarded that from freenode #metabug. It's a dmesg from patrick@ OpenBSD. He might reply here.... g From owner-freebsd-arm@freebsd.org Fri Mar 4 21:34:56 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B6BF69DABE8 for ; Fri, 4 Mar 2016 21:34:56 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.franken.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 840D6A05 for ; Fri, 4 Mar 2016 21:34:56 +0000 (UTC) (envelope-from tuexen@freebsd.org) Received: from [192.168.1.101] (p508F054F.dip0.t-ipconnect.de [80.143.5.79]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 48A8A1C0B4628; Fri, 4 Mar 2016 22:34:54 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Subject: Re: OpenBSD RPi3 dmesg and install prompt From: Michael Tuexen In-Reply-To: <56D9FBA9.8050303@ceetonetechnology.com> Date: Fri, 4 Mar 2016 22:34:52 +0100 Cc: Andrew Turner , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <56D995F2.10909@ceetonetechnology.com> <20160304150013.12fa2684@zapp> <1F782CC4-7301-40FB-95D8-27D00BFA17A8@freebsd.org> <56D9FBA9.8050303@ceetonetechnology.com> To: George Rosamond X-Mailer: Apple Mail (2.3112) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2016 21:34:56 -0000 > On 04 Mar 2016, at 22:18, George Rosamond = wrote: >=20 > On 03/04/16 14:29, Michael Tuexen wrote: >>> On 04 Mar 2016, at 16:00, Andrew Turner = wrote: >>>=20 >>> On Fri, 4 Mar 2016 09:04:34 -0500 >>> George Rosamond wrote: >>>=20 >>>> fyi: >>>>=20 >>>> http://ix.io/oJV >>>=20 >>> And FreeBSD runs under arm64 to multiuser: >>>=20 >>> http://pastebin.ca/3387711 >> Cool! >>=20 >> What changes / steps are needed? >>=20 >=20 > Just forwarded that from freenode #metabug. It's a dmesg from = patrick@ > OpenBSD. I was referring to FreeBSD booting under arm64... Best regards Michael >=20 > He might reply here.... >=20 > g >=20 >=20 From owner-freebsd-arm@freebsd.org Sat Mar 5 20:49:51 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7D413A13401 for ; Sat, 5 Mar 2016 20:49:51 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 4041B1C0 for ; Sat, 5 Mar 2016 20:49:50 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=BcB4quZ2 c=1 sm=1 tr=0 a=kLIaxcRmAfIWWG5Fo3VFTQ==:117 a=kLIaxcRmAfIWWG5Fo3VFTQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=NEAV23lmAAAA:8 a=7Qk2ozbKAAAA:8 a=6I5d2MoRAAAA:8 a=C79PXPfj0Ncwu58fhjAA:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp01.rcn.cmh.synacor.com: 24.148.20.83 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.83] ([24.148.20.83:22236] helo=[192.168.1.175]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES256-SHA) id 02/15-30987-7664BD65; Sat, 05 Mar 2016 15:49:43 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: FreeBSD on the RaspberryPi 3 From: Erik Moe In-Reply-To: <20160304135821.79d140ae@zapp> Date: Sat, 5 Mar 2016 14:49:43 -0600 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3265A43A-885B-42F8-984E-46C385FECFA2@rcn.com> References: <20160229225811.GB74374@server.rulingia.com> <20160304135821.79d140ae@zapp> To: Andrew Turner X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 20:49:51 -0000 My RaspberryPi 3 arrived last night. I=E2=80=99ve taken the latest = RPI-2 snapshot and updated to the latest firmware. I can tell it=E2=80=99= s booting up, but it=E2=80=99s getting hung up somewhere. I can=E2=80=99t= tell where because the serial console is spitting out gibberish. The = serial console issue is not specific to FreeBSD. I had the same issue = trying to get the serial console working on Raspbian. There is a thread = discussing the problem here: = https://github.com/RPi-Distro/repo/issues/22. On Raspbian I was able to = get around the serial console issue by adding "force_turbo=3D1=E2=80=9D = to the config.txt, but that doesn=E2=80=99t seem to work on FreeBSD. Erik > On Mar 4, 2016, at 7:58 AM, Andrew Turner = wrote: >=20 > On Wed, 2 Mar 2016 11:57:48 -0700 > Warner Losh wrote: >=20 >> I suspect that we'll need an aarch64 kernel and userland, at the very >> least, to make this work. Plus there's likely some dragons hiding in >> uboot / ubldr. >=20 > Someone should try updating the firmware on the RPI2 image, and > teaching the kernel about the Cortex-A53 in cpufunc.c. I suspect with > these two FreeBSD will boot in AArch32. >=20 > Andrew > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sat Mar 5 20:55:09 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1D57FA13628 for ; Sat, 5 Mar 2016 20:55:09 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from kif.fubar.geek.nz (kif.fubar.geek.nz [178.62.119.249]) by mx1.freebsd.org (Postfix) with ESMTP id E36726A0 for ; Sat, 5 Mar 2016 20:55:08 +0000 (UTC) (envelope-from andrew@fubar.geek.nz) Received: from zapp.Home (5ec222d2.skybroadband.com [94.194.34.210]) by kif.fubar.geek.nz (Postfix) with ESMTPSA id 78C1CD7A17; Sat, 5 Mar 2016 20:55:02 +0000 (UTC) Date: Sat, 5 Mar 2016 20:54:53 +0000 From: Andrew Turner To: Erik Moe Cc: Warner Losh , "freebsd-arm@freebsd.org" Subject: Re: FreeBSD on the RaspberryPi 3 Message-ID: <20160305205453.24bfca73@zapp.Home> In-Reply-To: <3265A43A-885B-42F8-984E-46C385FECFA2@rcn.com> References: <20160229225811.GB74374@server.rulingia.com> <20160304135821.79d140ae@zapp> <3265A43A-885B-42F8-984E-46C385FECFA2@rcn.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; amd64-portbld-freebsd11.0) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 20:55:09 -0000 Try setting "init_uart_clock=3D3000000". Andrew On Sat, 5 Mar 2016 14:49:43 -0600 Erik Moe wrote: > My RaspberryPi 3 arrived last night. I=E2=80=99ve taken the latest RPI-2 > snapshot and updated to the latest firmware. I can tell it=E2=80=99s boo= ting > up, but it=E2=80=99s getting hung up somewhere. I can=E2=80=99t tell whe= re because > the serial console is spitting out gibberish. The serial console > issue is not specific to FreeBSD. I had the same issue trying to get > the serial console working on Raspbian. There is a thread discussing > the problem here: https://github.com/RPi-Distro/repo/issues/22. On > Raspbian I was able to get around the serial console issue by adding > "force_turbo=3D1=E2=80=9D to the config.txt, but that doesn=E2=80=99t see= m to work on > FreeBSD. >=20 > Erik >=20 >=20 > > On Mar 4, 2016, at 7:58 AM, Andrew Turner > > wrote: > >=20 > > On Wed, 2 Mar 2016 11:57:48 -0700 > > Warner Losh wrote: > > =20 > >> I suspect that we'll need an aarch64 kernel and userland, at the > >> very least, to make this work. Plus there's likely some dragons > >> hiding in uboot / ubldr. =20 > >=20 > > Someone should try updating the firmware on the RPI2 image, and > > teaching the kernel about the Cortex-A53 in cpufunc.c. I suspect > > with these two FreeBSD will boot in AArch32. > >=20 > > Andrew > > _______________________________________________ > > freebsd-arm@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > > To unsubscribe, send any mail to > > "freebsd-arm-unsubscribe@freebsd.org" =20 >=20 From owner-freebsd-arm@freebsd.org Sat Mar 5 21:19:37 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7F42DA13E10 for ; Sat, 5 Mar 2016 21:19:37 +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 5784AE84 for ; Sat, 5 Mar 2016 21:19:37 +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 u25LJbXC014743 for ; Sat, 5 Mar 2016 21:19:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 207728] [patch] duplicated FREEBSD_BOOT_LOADER config option in sys/arm/broadcom/bcm2835/std.rpi Date: Sat, 05 Mar 2016 21:19:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: jiashiun@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 keywords bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 21:19:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D207728 Bug ID: 207728 Summary: [patch] duplicated FREEBSD_BOOT_LOADER config option in sys/arm/broadcom/bcm2835/std.rpi Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Only Me Priority: --- Component: arm Assignee: freebsd-arm@FreeBSD.org Reporter: jiashiun@gmail.com Keywords: patch Created attachment 167746 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D167746&action= =3Dedit Remove duplicated option FREEBSD_BOOT_LOADER The option FREEBSD_BOOT_LOADER has been added to sys/arm/conf/std.armv6. Th= ere is no need to have it in std.rpi now. How to reproduce: as of base r296415: jsli@4cbsd:/usr/src # time make -sj4 TARGET=3Darm TARGET_ARCH=3Darmv6 KERNC= ONF=3DRPI2 buildkernel -------------------------------------------------------------- >>> Kernel build for RPI2 started on Sun Mar 6 05:13:50 CST 2016 -------------------------------------------------------------- =3D=3D=3D> RPI2 -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- WARNING: duplicate option `FREEBSD_BOOT_LOADER' encountered. Kernel build directory is /usr/obj/arm.armv6/usr/src/sys/RPI2 Don't forget to do ``make cleandepend && make depend'' --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-arm@freebsd.org Sat Mar 5 21:40:46 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 36B9BA928CB for ; Sat, 5 Mar 2016 21:40:46 +0000 (UTC) (envelope-from e.moe@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 0652FC5F for ; Sat, 5 Mar 2016 21:40:45 +0000 (UTC) (envelope-from e.moe@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.1 cv=ZulNU4PG c=1 sm=1 tr=0 a=kLIaxcRmAfIWWG5Fo3VFTQ==:117 a=kLIaxcRmAfIWWG5Fo3VFTQ==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=6I5d2MoRAAAA:8 a=OA2lqS22AAAA:8 a=NEAV23lmAAAA:8 a=7Qk2ozbKAAAA:8 a=KlDsoipUaRnV-jtHF-QA:9 a=wKSZJLQF0MkymDBu:21 a=Kg-bxbX7rXO71c4r:21 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZS5tb2VAcmNuLmNvbQ== Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=e.moe@rcn.com; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=e.moe@rcn.com; spf=neutral; sender-id=neutral Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=e.moe; auth=pass (PLAIN) Received-SPF: neutral (smtp02.rcn.cmh.synacor.com: 24.148.20.83 is neither permitted nor denied by domain of rcn.com) Received: from [24.148.20.83] ([24.148.20.83:37575] helo=[192.168.1.175]) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.2.43620 r(Platform:3.6.2.0)) with ESMTPSA (cipher=AES256-SHA) id 4F/2D-31527-C525BD65; Sat, 05 Mar 2016 16:40:44 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) Subject: Re: FreeBSD on the RaspberryPi 3 From: Erik Moe In-Reply-To: <20160305205453.24bfca73@zapp.Home> Date: Sat, 5 Mar 2016 15:40:43 -0600 Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8E0082B4-9A6D-4AA4-9E58-591D962247CC@rcn.com> References: <20160229225811.GB74374@server.rulingia.com> <20160304135821.79d140ae@zapp> <3265A43A-885B-42F8-984E-46C385FECFA2@rcn.com> <20160305205453.24bfca73@zapp.Home> To: Andrew Turner X-Mailer: Apple Mail (2.3096.5) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2016 21:40:46 -0000 Nice! That fixed the serial console issues. It gets as far as loading = the kernel, but that=E2=80=99s about it. U-Boot 2015.04 (Feb 17 2016 - 10:41:14) DRAM: 944 MiB WARNING: Caches not enabled RPI: Board rev 8 outside known range RPI Unknown model MMC: bcm2835_sdhci: 0 reading uboot.env ** Unable to read "uboot.env" from mmc0:1 ** Using default environment In: serial Out: lcd Err: lcd Net: Net Initialization Skipped No ethernet found. Hit any key to stop autoboot: 0 Booting from: mmc 0 ubldr reading ubldr 262739 bytes read in 330 ms (777.3 KiB/s) ## Starting application at 0x02000094 ... Consoles: U-Boot console Compatible U-Boot API signature found @3ab4a4c8 FreeBSD/armv6 U-Boot loader, Revision 1.2 (root@releng2.nyi.freebsd.org, Wed Feb 17 11:04:47 UTC 2016) DRAM: 944MB Number of U-Boot devices: 1 U-Boot env: loaderdev=3D'mmc 0' Found U-Boot device: disk Checking unit=3D0 slice=3D partition=3D... good. Booting from disk0s2a: /boot/kernel/kernel data=3D0x5f7ee4+0xf011c = syms=3D[0x4+0x820c0+0x4+0x9490f] Hit [Enter] to boot immediately, or any other key for command prompt. Booting [/boot/kernel/kernel]... Using DTB provided by U-Boot at address 0x100. Kernel entry at 0x2200100... Kernel args: (null) > On Mar 5, 2016, at 2:54 PM, Andrew Turner = wrote: >=20 > Try setting "init_uart_clock=3D3000000". >=20 > Andrew >=20 > On Sat, 5 Mar 2016 14:49:43 -0600 > Erik Moe wrote: >=20 >> My RaspberryPi 3 arrived last night. I=E2=80=99ve taken the latest = RPI-2 >> snapshot and updated to the latest firmware. I can tell it=E2=80=99s = booting >> up, but it=E2=80=99s getting hung up somewhere. I can=E2=80=99t tell = where because >> the serial console is spitting out gibberish. The serial console >> issue is not specific to FreeBSD. I had the same issue trying to get >> the serial console working on Raspbian. There is a thread discussing >> the problem here: https://github.com/RPi-Distro/repo/issues/22. On >> Raspbian I was able to get around the serial console issue by adding >> "force_turbo=3D1=E2=80=9D to the config.txt, but that doesn=E2=80=99t = seem to work on >> FreeBSD. >>=20 >> Erik >>=20 >>=20 >>> On Mar 4, 2016, at 7:58 AM, Andrew Turner >>> wrote: >>>=20 >>> On Wed, 2 Mar 2016 11:57:48 -0700 >>> Warner Losh wrote: >>>=20 >>>> I suspect that we'll need an aarch64 kernel and userland, at the >>>> very least, to make this work. Plus there's likely some dragons >>>> hiding in uboot / ubldr. =20 >>>=20 >>> Someone should try updating the firmware on the RPI2 image, and >>> teaching the kernel about the Cortex-A53 in cpufunc.c. I suspect >>> with these two FreeBSD will boot in AArch32. >>>=20 >>> Andrew >>> _______________________________________________ >>> freebsd-arm@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm >>> To unsubscribe, send any mail to >>> "freebsd-arm-unsubscribe@freebsd.org" =20 >>=20 >=20