From owner-freebsd-arm@freebsd.org Mon Oct 31 08:53: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 019EAC2893A for ; Mon, 31 Oct 2016 08:53:29 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-56.reflexion.net [208.70.210.56]) (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 A66311FF6 for ; Mon, 31 Oct 2016 08:53:28 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 13228 invoked from network); 31 Oct 2016 08:54:18 -0000 Received: from unknown (HELO rtc-sm-01.app.dca.reflexion.local) (10.81.150.1) by 0 (rfx-qmail) with SMTP; 31 Oct 2016 08:54:18 -0000 Received: by rtc-sm-01.app.dca.reflexion.local (Reflexion email security v8.10.0) with SMTP; Mon, 31 Oct 2016 04:53:25 -0400 (EDT) Received: (qmail 10583 invoked from network); 31 Oct 2016 08:53:25 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 31 Oct 2016 08:53:25 -0000 Received: from [192.168.1.106] (c-76-115-7-162.hsd1.or.comcast.net [76.115.7.162]) by iron2.pdx.net (Postfix) with ESMTPSA id 70ED0EC8814 for ; Mon, 31 Oct 2016 01:53:20 -0700 (PDT) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Subject: BPi-M3's A83T: "socket" 0 and "socket" 1 (clusters 0 and 1): how difficult/messy to enable use of both? Message-Id: Date: Mon, 31 Oct 2016 01:53:19 -0700 To: freebsd-arm X-Mailer: Apple Mail (2.3251) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 08:53:29 -0000 I attempted a boot of a BPi-M3 (A83T based) via a linux image and I = noted that the boot sequence reported: [ 0.040298] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000 [ 0.040383] Setting up static identity map for 0x4076b5a8 - = 0x4076b600 [ 0.010000] CPU1: Booted secondary processor [ 0.010000] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001 [ 0.010000] CPU2: Booted secondary processor [ 0.010000] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002 [ 0.010000] CPU3: Booted secondary processor [ 0.010000] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003 [ 0.260089] CPU4: failed to boot: -22 [ 0.300067] CPU5: failed to boot: -22 [ 0.340070] CPU6: failed to boot: -22 [ 0.380092] CPU7: failed to boot: -22 [ 0.380310] Brought up 4 CPUs [ 0.380335] SMP: Total of 4 processors activated (19200.00 BogoMIPS). . . . [somewhat later in the sequence] . . . [ 0.010000] CPU4: Booted secondary processor [ 0.010000] CPU4: thread -1, cpu 0, socket 1, mpidr 80000100 [ 0.010000] CPU5: Booted secondary processor [ 0.010000] CPU5: thread -1, cpu 1, socket 1, mpidr 80000101 [ 0.010000] CPU6: Booted secondary processor [ 0.010000] CPU6: thread -1, cpu 2, socket 1, mpidr 80000102 [ 0.010000] CPU7: Booted secondary processor [ 0.010000] CPU7: thread -1, cpu 3, socket 1, mpidr 80000103 [I'll note that all 8 cores are of the same type (cortex-a7) for the = A83T: This is not an arm big/LITTLE context mixing core types but a more = symmetric form of NUMA(?), more like sockets with the same type of = multi-core processor in each socket and no cache spanning across the = sockets, although RAM does span the "sockets" for the A83T.] This suggests that the linux folks made the two clusters of cores in the = A83T (Allwinner's A83T_User_Manual_v1.5.1_20150513.pdf terminology ) fit = into the linux socket handling structure (a.k.a. NUMA structure, I = presume). (About 29 pages of the 547 page = A83T_User_Manual_v1.5.1_20150513.pdf mention "cluster", mostly for = details of the clusters' various control, status, mask, gating, and = power registers.) Not that I consider it likely to be reasonable but I'll ask: How likely = is it that someone could be given various pointers and bootstrap = themselves into possibly enabling such dual-cluster usage for the A83T = to a useful degree in FreeBSD? How independent of other SOC/board = details would the effort/result be (given that the A83T is what is in = use)? Would there be some sequence of stages to the effort? (The details = would probably be part of the pointers that I mentioned. . .) =3D=3D=3D Mark Millard markmi at dsl-only.net