armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Mark Millard markmi at dsl-only.net
Wed Aug 9 20:45:02 UTC 2017


On 2017-Aug-9, at 12:14 PM, Sylvain Garrigues <sylvain at sylvaingarrigues.com> wrote:

> I have a kernel.bin (compiled with TARGET_ARCH=armv6) which boots perfectly
> on my Raspberry Pi 2 v1.1, and I don't understand why the same kernel.bin
> does't boot on my Raspberry Pi 3. I have same DTB and config.txt, with
> enable_uart=1.
> 
> I can see in the kernel source code that the cortex-a53 is a listed
> supported processor, and the raspberry pi 3 boots by default in aarch32
> mode which is compatible with code compiled for armv6.

It is not so simple. Quoting:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0801a/BABBDFIH.html

. . .
"A processor based on ARMv8 can run applications built
for AArch32 and AArch64 states but a change between
AArch32 and AArch64 states can only happen at exception
boundaries."
. . .
"A processor can only execute instructions from the
instruction set that matches its current execution
state. A processor in AArch32 state cannot execute
A64 instructions, and a processor in AArch64 state
cannot execute A32 or T32 instructions. You must
ensure that the processor never receives instructions
from the wrong instruction set for the current execution
state."

Also, quoting:

https://community.arm.com/processors/f/discussions/2874/aarch32-in-armv8

. . .
"The ARMv8 architecture says that it is IMPLEMENTATION
DEFINED whether you come out of reset in AArch32 or
AArch64.  Which basically means it is up to the
processor and chip designers.  For the ARM's Cortex-A53
and Cortex-A57 processors it is controlled by a signal
(AA64nAA32) which is sampled at reset.  A chip designer
could tie the signal to a fixed value, or provide some
way to control it (e.g. a jumper)."

"Assuming you came out of reset in AArch32 then you
could run ARMv7 code, as ARMv8 AArch32 is an evolution
of ARMv7.  But you would still need to look at porting
any processor/chip/board specific code, just as you
would if moving between different ARMv7 parts."

. . . "I would expect at least the first stage boot
code (aka boot rom) to be written for AArch64 for most
ARMv8-A systems.  This is because it is quite simple to
go from a 64-bit boot loader to a 32-bit or 64-bit OS.
While it is quite tricky to get from 32-bit boot code
to a 64-bit OS.  Meaning a 64-bit boot loader can be
more flexible. This kind of code also tends to be very
chip specific anyway."

Back to non-quotes. . .

FreeBSD does not have the state change management for ARMv8: it only
uses/has an aarch64 configuration (once FreeBSD's initial configuration
is in place anyway). There is no logic for ongoing execution-state
changes as far as I know.

As far as I know no one has set up a boot sequence for FreeBSD to
go to an aarch32 variant of FreeBSD from some earlier stage of
the boot sequence. For the operating system kernel aarch32 execution
state and armv7 may be related but not identical even if for
user processes a kernel can be designed to support armv7 programs.

Raspian runs under aarch32 on Cortex-53 by starting in aarch64 and
switching to aarch32 (possibly in boot loader code) as I understand.
It likely stays in the aarch32 execution state, not supporting
aarch64 after switching.

There are linux's that run aarch64 but allow aarch32 processes
if I understand right. This is definitely more work for the
operating system implementers to support the context
switching and aarch32 operation.

> So what's wrong and what shall be done to make our armv6 kernel boot on a
> raspberry pi 3?

In the usual FreeBSD manor: if you (and/or others) do the work and
donate it then FreeBSD would likely adopt it. (Background knowledge
tends to limit who can do such in a timely manor.)

> Also for some time now the new raspberry pi 2 available (starting from v1.2
> board revision) also have a cortex-a53 and the same soc than raspberry pi 3
> so it would be great to have a working FreeBSD/armv6 image for these recent
> famous boards.

FreeBSD is not good at pointing out the V1.1- vs. V1.2+ issue for
what is called "raspberry pi 2". Going from armv7 to armv8 with
only a version number change only fits well with operating systems
that have aarch32 support (or that avoid aarch64). "raspberry pi
2v8" would have been better for the wider range of operating
systems so that the name was sufficient to make clear the mismatch.

> I am interested in getting directions to make this happen (modifications
> needed in locore-v6.S?)

To my knowledge no one has said they have ever figured this
out for FreeBSD: it is a research project for whoever is
interested enough to bother.

> Sylvain
> PS: If you ask why I don't use the arm64 kernel, it's because the vchiq
> driver does not work yet in 64 bit mode.


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



More information about the freebsd-arm mailing list