From owner-freebsd-arm@freebsd.org Tue Sep 26 20:39:44 2017 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D5503E20E45 for ; Tue, 26 Sep 2017 20:39:44 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: from asp.reflexion.net (outbound-mail-210-79.reflexion.net [208.70.210.79]) (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 9893675704 for ; Tue, 26 Sep 2017 20:39:43 +0000 (UTC) (envelope-from markmi@dsl-only.net) Received: (qmail 14589 invoked from network); 26 Sep 2017 20:33:02 -0000 Received: from unknown (HELO mail-cs-02.app.dca.reflexion.local) (10.81.19.2) by 0 (rfx-qmail) with SMTP; 26 Sep 2017 20:33:02 -0000 Received: by mail-cs-02.app.dca.reflexion.local (Reflexion email security v8.40.3) with SMTP; Tue, 26 Sep 2017 16:33:02 -0400 (EDT) Received: (qmail 17976 invoked from network); 26 Sep 2017 20:33:02 -0000 Received: from unknown (HELO iron2.pdx.net) (69.64.224.71) by 0 (rfx-qmail) with (AES256-SHA encrypted) SMTP; 26 Sep 2017 20:33:02 -0000 Received: from [192.168.1.109] (c-67-170-167-181.hsd1.or.comcast.net [67.170.167.181]) by iron2.pdx.net (Postfix) with ESMTPSA id 831D1EC8559; Tue, 26 Sep 2017 13:33:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: CUBOX snapshots working? From: Mark Millard In-Reply-To: <1506452204.73082.147.camel@freebsd.org> Date: Tue, 26 Sep 2017 13:33:00 -0700 Cc: Emmanuel Vadot , freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <1AA5D8DD-17C5-4F12-AD44-2EB8491B2BA5@dsl-only.net> References: <201709260339.VAA16701@mail.lariat.net> <1506435673.73082.129.camel@freebsd.org> <201709261732.LAA21422@mail.lariat.net> <20170926200446.c188fda613df2ffb894b1ff3@bidouilliste.com> <1506450112.73082.143.camel@freebsd.org> <20170926204622.67ae9edbca62e2dcdbd1ea31@bidouilliste.com> <1506452204.73082.147.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.3273) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Sep 2017 20:39:44 -0000 On 2017-Sep-26, at 11:56 AM, Ian Lepore wrote: > On Tue, 2017-09-26 at 20:46 +0200, Emmanuel Vadot wrote: >> On Tue, 26 Sep 2017 12:21:52 -0600 >> Ian Lepore wrote: >> >>> >>> On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote: >>>> >>>> On Tue, 26 Sep 2017 11:32:21 -0600 >>>> Brett Glass wrote: >>>> >>>>> >>>>> >>>>> One would think that sauce for the goose would be sauce for the >>>>> gander. But is this particular Cubox now useless with FreeBSD? >>>>> And if so, why? It is not an unusual model. The Cubox does work >>>>> if I flash their "Ignition" startup software (which is used to >>>>> bootstrap by downloading various OS images) to the same >>>>> Micro SD card. >>>>> >>>>> --Brett Glass >>>> The problem isn't FreeBSD related, it's U-Boot related. >>>> >>>> You could test build mainline u-boot just to confirm that it >>>> isn't >>>> something due to our ports. >>>> >>> If we used to provide working cubox images and we don't anymore, >>> it's >>> hard to call that anything but a freebsd problem. >> There is working cubox images, the last one is from yesterday. >> You even say yourself that you did test it and that it worked. >> Do we even know if the snapshot worked for this board ? >> Brett, could you test the 11.0 release for example ? (I don't >> remember >> if for 11.1 we already switch u-boot or not). >> >>> >>> You seem to be implying that this is another problem caused by >>> switching from vendor-specific to mainline uboot. I'm not sure >>> that's >>> the case here, but if it is, be clear: It is purely a freebsd >>> problem, >>> because it was purely our choice (not mine) to switch from >>> something >>> that worked to something that doesn't. >>> >>> -- Ian >> Yes, maybe switching to mainline for IMX boards was a premature one, >> I >> honestly don't have IMX board and don't know which way we should >> take. >> All I can say is that for TI and Allwinner board, mainline U-Boot is >> better (at least the support is the same). If you want to switch back >> to vendor u-boot for IMX board fell free to do so (as long as you >> don't >> change the other SoC U-Boot). >> > > No, the mainline uboot for TI is NOT better. It cannot netboot, and > that is a regression from the previous version, which worked just fine. A64 (or at least Pine64+ 2GB) also has regressed, at least temporarily. But as far as I can tell the intent is for a temporarily status, not an indefinitely long one. I'd guess other examples might also have such an intent. (But I do not know one way or the other.) A64 status (skip if do not care): I found and reported a fix for the non-debug kernel boot hangup for A64 (or at least the Pine64+ 2GB I had access to to test): Index: /usr/src/sys/arm64/arm64/mp_machdep.c =================================================================== --- /usr/src/sys/arm64/arm64/mp_machdep.c (revision 323246) +++ /usr/src/sys/arm64/arm64/mp_machdep.c (working copy) @@ -236,7 +236,9 @@ atomic_store_rel_int(&aps_ready, 1); /* Wake up the other CPUs */ - __asm __volatile("sev"); + __asm __volatile( + "dsb ish \n" + "sev \n"); printf("Release APs\n"); I added this patch to bugzilla 222234. (There could be a more optimal dsb variant than ish. But this was sufficient in the context that I could test.) I also added one for the other use of sev instruction that I found: Index: /usr/src/sys/arm64/arm64/identcpu.c =================================================================== --- /usr/src/sys/arm64/arm64/identcpu.c (revision 323676) +++ /usr/src/sys/arm64/arm64/identcpu.c (working copy) @@ -1109,6 +1109,9 @@ /* Wake up the other CPUs */ atomic_store_rel_int(&ident_lock, 0); - __asm __volatile("sev" ::: "memory"); + __asm __volatile( + "dsb ish \n" + "sev \n" + ::: "memory"); } } It looks like A64 just got a bunch of USB updates, including a fix and ECHI related material. (I do not know if ECHI is now generally operable yet.) This was another area that had regressed but has been worked on. At this point I do not know if the reported: Failed assertion: "nstime_compare(&decay->epoch, &time) <= 0" is a general problem or not. The times involved seems to trace back through use of binuptime and into soc specific code from my quick look around. It did not seem to trace back to an adjustable time. (If so: no worry about ntpd misbehavior.) === Mark Millard markmi at dsl-only.net