Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 1 Nov 2017 20:53:57 -0500
From:      Kyle Evans <kevans@freebsd.org>
To:        Mark Millard <markmi@dsl-only.net>
Cc:        Carl Johnson <carlj@peak.org>, freebsd-arm@freebsd.org
Subject:   Re: RPi2 snapshot for armv7 won't boot.
Message-ID:  <CACNAnaG6-TLv=Q9oJ8Uux6vGnXEY6FEcfoANrNzb=4MDUWpVCA@mail.gmail.com>
In-Reply-To: <5B61C831-45A1-454F-B38B-DCE40B969F95@dsl-only.net>
References:  <86fu9xmx3u.fsf@elm.localnet> <5B61C831-45A1-454F-B38B-DCE40B969F95@dsl-only.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Nov 1, 2017 6:24 PM, "Mark Millard" <markmi@dsl-only.net> wrote:

On 2017-Nov-1, at 3:51 PM, Carl Johnson <carlj@peak.org> wrote:

> I had previously tried to upgrade my RPi2 12.0-CURRENT system from armv6
> to armv7, but it then refused to boot.  This time I downloaded the
> latest snapshot (r325156 from 20171030) and it also refuses to boot for
> exactly the same reason.  In every case the kernel loads, but then it
> reports that init has died, and then panics and drops into kdb.  It
> gives a stack backtrace, but that doesn't mean anything to me.
>
> Is this just me, or is anybody else having this problem?  If others have
> the problem, is there some workaround to get it working?
>
> Thanks in advance for any ideas.

Others are also seeing the problem, not just on
RPI2's.

It looks like it broke between:

-r324743 and -r325156

someplace relative to whatever is causing the
init problem.

Details that lead me to that conclusion, if
you care. . .

One of the FreeBSD folks contacted me privately because his
bananapi-m3 experiments were getting the init problem and
he was hoping I could test independently to see if the
problem was local to his attempt to modernize the BPI-M3
support so it would again eventually be supported.

I had to be doing other things but was able to report
that my context was a working variant of -r324743 and
showed him the two small diffs that I used. (The issues
needing the diffs are not tied to any init behavior.)

He tried his experiment against -r324743 and his
experimental code and *.dt* based .dts booted fine.

It looks like something after -r324743 broke things
such that the init problem exists for armv7.

[I'm still not active for investigating any of this.]

===
Mark Millard
markmi at dsl-only.net


For any interested: I think I've got it narrowed down to somewhere between
or including r324950 - r324882 (last good I've tested).

Looking at the logs, I don't see too many commits in there that could've
broken something this fundamental, but I think my bisect only has three
more steps until I can say for sure.

Thanks,

Kyle Evans



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACNAnaG6-TLv=Q9oJ8Uux6vGnXEY6FEcfoANrNzb=4MDUWpVCA>