Date: Tue, 26 Sep 2017 13:33:00 -0700 From: Mark Millard <markmi@dsl-only.net> To: Ian Lepore <ian@freebsd.org> Cc: Emmanuel Vadot <manu@bidouilliste.com>, freebsd-arm@freebsd.org Subject: Re: CUBOX snapshots working? Message-ID: <1AA5D8DD-17C5-4F12-AD44-2EB8491B2BA5@dsl-only.net> In-Reply-To: <1506452204.73082.147.camel@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2017-Sep-26, at 11:56 AM, Ian Lepore <ian at freebsd.org> wrote:
> On Tue, 2017-09-26 at 20:46 +0200, Emmanuel Vadot wrote:
>> On Tue, 26 Sep 2017 12:21:52 -0600
>> Ian Lepore <ian at freebsd.org> wrote:
>>
>>>
>>> On Tue, 2017-09-26 at 20:04 +0200, Emmanuel Vadot wrote:
>>>>
>>>> On Tue, 26 Sep 2017 11:32:21 -0600
>>>> Brett Glass <brett at lariat.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1AA5D8DD-17C5-4F12-AD44-2EB8491B2BA5>