armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Sylvain Garrigues
Hello,

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.

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

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.

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

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.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Mark Millard-2
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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Mark Millard-2
On 2017-Aug-9, at 1:38 PM, Mark Millard <markmi at dsl-only.net> wrote:

> 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.

Quoting some more: ARM_v8_Instruction_Set_Architecture_%28Overview%29.pdf :

"In ARMv8 AArch32 the A32, T32 and T32EE instruction sets
are broadly equivalent to the instructions sets named ARM,
Thumb and ThumbEE respectively in [v7A]."
. . .
"The following are obsoleted in ARMv8:

        • A32 SWP and SWPB instructions.

        • Jazelle (only trivial implementations are supported).

        • VFP short vectors and asynchronous bounces.

        • Fast Context Switch Extension (FCSE)."

"The following are deprecated in ARMv8 and may be disabled by
privileged software:

        • A32 and T32 CP15 barriers CP15DSB, CP15ISB and CP15DMB.

        • A32 and T32 SETEND instruction.

        • A subset of T32 IT instruction functionality, as described in §6.1 below.

        • T32EE instructions and coprocessor registers are both deprecated and optional."

"In addition some of the new functionality provided by the A64
instruction set is independent of the general purpose register
width and therefore equally applicable to AArch32 state, namely:
enhanced barrier types; hints; load- acquire and store-release;
new IEEE 754-2008 operations; and cryptography extensions.
Accordingly these new instructions are added to the A32 and
T32 instruction sets by ARMv8 as described below."

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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Sylvain Garrigues
In reply to this post by Mark Millard-2
Hello,

2017-08-09 22:38 GMT+02:00 Mark Millard <[hidden email]>:
>
> 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.


On Raspberry Pi 3, the cortex-a53 processor starts in the aarch32 state if
I'm correct, provided you don't add any arm_control=0x200 line in
config.txt (no arm_control by default).



> > So what's wrong and what shall be done to make our armv6 kernel boot on a
> > raspberry pi 3?
>
> > 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.


Apparently some people may have, so did Warner say a few weeks ago:
*"I've been told of people claiming to run a newer rpi2 **(v1.2 or newer)
in 32-bit mode, but I've not been able to confirm the **people who are
making the claims."*
(see this "Creating armv7 MACHINE_ARCH" thread:
https://docs.freebsd.org/cgi/getmsg.cgi?fetch=168619+0+/usr/local/www/mailindex/archive/2017/freebsd-arm/20170618.freebsd-arm
)


I just plugged my serial cable and put debug char at almost every
instruction in locore-v6.S to understand why we get the to raspberry pi
rainbow screen of depth before entering initarm: it seems to happen just
after the switch to virtual address with "ldr pc, =1f" (
https://github.com/freebsd/freebsd/blob/master/sys/arm/arm/locore-v6.S#L491).
That's when I don't get any more serial output although I did setup
early_putc and SOCDEV_PA & VA machinery to have early boot output - which I
do get with rpi2 v1.1).

I can try more debug if given instructions.

Sylvain
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Warner Losh
On Wed, Aug 9, 2017 at 4:08 PM, Sylvain Garrigues <
[hidden email]> wrote:

>
> > > So what's wrong and what shall be done to make our armv6 kernel boot
> on a
> > > raspberry pi 3?
> >
> > > 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.
>
>
> Apparently some people may have, so did Warner say a few weeks ago:
> *"I've been told of people claiming to run a newer rpi2 **(v1.2 or newer)
> in 32-bit mode, but I've not been able to confirm the **people who are
> making the claims."*
> (see this "Creating armv7 MACHINE_ARCH" thread:
> https://docs.freebsd.org/cgi/getmsg.cgi?fetch=168619+0+/
> usr/local/www/mailindex/archive/2017/freebsd-arm/20170618.freebsd-arm
> )
>

For the record, I was never able to track anybody down that had done it
successfully. It was mostly "I tried the image and it didn't work" or "I
had the old version that worked" when I talked to people about it.

Warner
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Mark Millard-2
In reply to this post by Sylvain Garrigues

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

> . . .
>
> On Raspberry Pi 3, the cortex-a53 processor starts in the aarch32 state if I'm correct, provided you don't add any arm_control=0x200 line in config.txt (no arm_control by default).  
>
> . . .

[As we go beyond what I can find material to quote that
directly applies take the word of folks like Ian Lepore
(and others) over anything I write. (I'm lookging up
things as I go.)]

Seems to be as you say above. But. . .

Note: aarch32 does not support armv6, just an
variation on armv7. I've already listed in prior
submittals some differences between aarch32 and
armv7 that I found mention of. (Linux goes so far
as to be configurable to partially-emulate some
missing instructions, for example. FreeBSD does
not.)

FreeBSD for aarch64 on an rpi3 is only designed to deal
with its sysutils/u-boot-rpi3 u-boot context:

# more /usr/local/share/u-boot/u-boot-rpi3/config.txt
arm_control=0x200
dtparam=audio=on,i2c_arm=on,spi=on
dtoverlay=mmc
dtoverlay=pi3-disable-bt
device_tree_address=0x100
kernel=u-boot.bin

This indicates that this u-boot likely is in control of
the aarch32 vs. aarch64 execution state that the FreeBSD
kernel starts in. And u-boot-rpi3 sets up aarch64 and
the aarch64 FreeBSD kernel requires that if I understand
right.

FreeBSD has no established u-boot variant for starting
armv8 in an aarch32 execution state (or cortex-a53
specifically) and no later stages of booting that
are designed to handle handoff from such a u-boot
variant. At least that is my understanding.

Similarly for FreeBSD armv6 (/v7) on an rpi2v1.1 (or before):

# more /usr/local/share/u-boot/u-boot-rpi2/config.txt
disable_commandline_tags=0
device_tree_address=0x100
device_tree=rpi2.dtb
kernel=u-boot.bin

This u-boot-rpi2 is not designed to deal with
armv8 related early boot issues or other
aarach32 vs. armv7 differences at all:
It is limited to armv6/7: The design and
implementation predate the v8 context and no
armv8 or aarch32 support has been added as far
as I know.  u-boot-rpi2, later loader stages,
and possibly even FreeBSD may well still use
instructions (or other things) that are not
supported by the aarch32 execution state on
armv8 (cortex-a53).

There is no u-boot variant that is explicitly
for rpi2v1.2+.


Overall: Supporting aarch32 is not automatic
even if one starts from armv7 or specifically
a cortex-a53 context unless one was lucky
enough to happen to not touch or depend on
any of the differences at any stage.



[Note: My /usr/ports/ is at:

# svnlite info /usr/ports/ | grep "Re[plv]"
Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 447082
Last Changed Rev: 447082
]

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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Mark Millard-2
On 2017-Aug-9, at 4:58 PM, Mark Millard <markmi at dsl-only.net> wrote:

> On 2017-Aug-9, at 3:08 PM, Sylvain Garrigues <sylvain at sylvaingarrigues.com> wrote:
>
>> . . .
>>
>> On Raspberry Pi 3, the cortex-a53 processor starts in the aarch32 state if I'm correct, provided you don't add any arm_control=0x200 line in config.txt (no arm_control by default).  
>>
>> . . .
>
> [As we go beyond what I can find material to quote that
> directly applies take the word of folks like Ian Lepore
> (and others) over anything I write. (I'm lookging up
> things as I go.)]
>
> Seems to be as you say above. But. . .
>
> Note: aarch32 does not support armv6, just an
> variation on armv7. I've already listed in prior
> submittals some differences between aarch32 and
> armv7 that I found mention of. (Linux goes so far
> as to be configurable to partially-emulate some
> missing instructions, for example. FreeBSD does
> not.)
>
> FreeBSD for aarch64 on an rpi3 is only designed to deal
> with its sysutils/u-boot-rpi3 u-boot context:
>
> # more /usr/local/share/u-boot/u-boot-rpi3/config.txt
> arm_control=0x200
> dtparam=audio=on,i2c_arm=on,spi=on
> dtoverlay=mmc
> dtoverlay=pi3-disable-bt
> device_tree_address=0x100
> kernel=u-boot.bin
>
> This indicates that this u-boot likely is in control of
> the aarch32 vs. aarch64 execution state that the FreeBSD
> kernel starts in. And u-boot-rpi3 sets up aarch64 and
> the aarch64 FreeBSD kernel requires that if I understand
> right.
>
> FreeBSD has no established u-boot variant for starting
> armv8 in an aarch32 execution state (or cortex-a53
> specifically) and no later stages of booting that
> are designed to handle handoff from such a u-boot
> variant. At least that is my understanding.
>
> Similarly for FreeBSD armv6 (/v7) on an rpi2v1.1 (or before):
>
> # more /usr/local/share/u-boot/u-boot-rpi2/config.txt
> disable_commandline_tags=0
> device_tree_address=0x100
> device_tree=rpi2.dtb
> kernel=u-boot.bin
>
> This u-boot-rpi2 is not designed to deal with
> armv8 related early boot issues or other
> aarach32 vs. armv7 differences at all:
> It is limited to armv6/7: The design and
> implementation predate the v8 context and no
> armv8 or aarch32 support has been added as far
> as I know.  u-boot-rpi2, later loader stages,
> and possibly even FreeBSD may well still use
> instructions (or other things) that are not
> supported by the aarch32 execution state on
> armv8 (cortex-a53).
>
> There is no u-boot variant that is explicitly
> for rpi2v1.2+.
>
>
> Overall: Supporting aarch32 is not automatic
> even if one starts from armv7 or specifically
> a cortex-a53 context unless one was lucky
> enough to happen to not touch or depend on
> any of the differences at any stage.
> . . .

I'll remind that if you try an old enough rpi2 B V1.1-
raspbian image/boot files it will not boot a rpi3. At
a given point they announced a file set that started to
support booting the rpi3. Quoting a reference to this:

https://www.raspberrypi.org/forums/viewtopic.php?t=58151

says:

"If you use a PI3, note that it will only boot past
the "rainbow screen" if you feed it the right (latest)
boot files. So in case of trouble try using the latest
Raspbian from the download page, or try updating your
older software on an earlier PI on which it boots,
with Raspbian that should work."

And:

https://www.raspberrypi.org/blog/raspberry-pi-3-on-sale/

says:

"You’ll need a recent NOOBS or Raspbian image from our
downloads page."



So: Raspbian and its related boot files did not
automatically support the rpi3 but had to be
changed to do so.



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

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Sylvain Garrigues
In reply to this post by Mark Millard-2
Hi,

2017-08-10 1:58 GMT+02:00 Mark Millard <[hidden email]>:
>
> Overall: Supporting aarch32 is not automatic
> even if one starts from armv7 or specifically
> a cortex-a53 context unless one was lucky
> enough to happen to not touch or depend on
> any of the differences at any stage.


 Thanks. I guess though that it's quite easily feasible for someone
familiar with arm lower level initialization.

I can see NetBSD managed to make the armv7 kernel boot on Raspberry Pi 3
with one commit:
Get the RPI3 working (in aarch32 mode) by recognising Cortex A53 CPUs. -
https://github.com/IIJ-NetBSD/netbsd-src/commit/00335f7adc380a125d045279c1a0f5525fb557da

Same for OpenBSD folks:
http://marc.info/?l=openbsd-tech&m=145692659524971&w=2

Plus FreeBSD's RPI2 armv6 kernel does boot and recognize the cortex-a53
with qemu-aarch64:
qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -m 1024 -smp 4 -kernel
kernel.bin -serial stdio -dtb rpi2.dtb

So I guess we too are really not far to boot RPI2 "armv6" kernel on
raspberry pi 2 v1.2 and raspberry pi 3.
I wish I could help.

Sylvain
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Mark Millard-2
On 2017-Aug-10, at 6:51 AM, Sylvain Garrigues <sylvain at sylvaingarrigues.com> wrote:

> 2017-08-10 1:58 GMT+02:00 Mark Millard <[hidden email]>:
>> Overall: Supporting aarch32 is not automatic
>> even if one starts from armv7 or specifically
>> a cortex-a53 context unless one was lucky
>> enough to happen to not touch or depend on
>> any of the differences at any stage.
>
>  Thanks. I guess though that it's quite easily feasible for someone familiar with arm lower level initialization.
>
> I can see NetBSD managed to make the armv7 kernel boot on Raspberry Pi 3 with one commit:
> Get the RPI3 working (in aarch32 mode) by recognising Cortex A53 CPUs. - https://github.com/IIJ-NetBSD/netbsd-src/commit/00335f7adc380a125d045279c1a0f5525fb557da

Interesting.

> Same for OpenBSD folks:
> http://marc.info/?l=openbsd-tech&m=145692659524971&w=2

This one (OpenBSD) says (note the "including some other
(still) local diffs"):

"This way, and including some other (still) local diffs, I have
the brand new raspberry Pi 3 in multiuser:  http://ix.io/oJV "

So the reference only has some of of the code changes shown.

And the boot log shows:

cpu0 at mainbus0: ARM Cortex A53 rev 4 (ARMv7 core)
cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
cpu0: 32KB(64b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache

So just one cpu. But for all I know OpenBSD might not have
been SMP capable on a rpi2 at the time either.

The boot log also shows:

gpio at bcmgpio0 not configured
broadcom0: device bcmsdhc unit 0 not found


So for OpenBSD the code change shown was just the start of the
update as far as I can tell.

> Plus FreeBSD's RPI2 armv6 kernel does boot and recognize the cortex-a53 with qemu-aarch64:
> qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -m 1024 -smp 4 -kernel kernel.bin -serial stdio -dtb rpi2.dtb

Interesting. How clean is the boot log?

At least for raspbian there were separate files for rpi3
when rpi3 was first supported:

arch/arm/boot/dts/bcm2710-rpi-3-b.dts
arch/arm/boot/dts/bcm2710.dtsi

Later there was:

arch/arm/boot/dts/overlays/pi3-disable-bt-overlay.dts
arch/arm/boot/dts/overlays/pi3-miniuart-bt-overlay.dts
arch/arm/boot/dts/overlays/pi3-disable-wifi-overlay.dts
arch/arm/boot/dts/overlays/pi3-act-led-overlay.dts

as well as some updates to some of those files. (I'm
not sure that I found all such files that are rpi3
specific [possibly covering rpi2v1.2 as well?].)

I suspect the qemu-system-aarch64 use is simulating
a rpi2's details as listed in rpi2.dtb instead of the
rpi3's details. (But using a cortex-a53 CPU model.)
There may well be work in supporting the rpi3's
details in the kernel and/or boot loading stages for
all I know.

What happens if a rpi3 dtb file is used instead of
rpi2.dtb ?


> So I guess we too are really not far to boot RPI2 "armv6" kernel on raspberry pi 2 v1.2 and raspberry pi 3.
> I wish I could help.

Since I'm finding these things as I go I've no clue
what I've not found. So I can not tell how close to
correct you are.


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



_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: armv6 kernel support for Raspberry Pi 3 in default aarch32 mode

Sylvain Garrigues
Actually, with latest u-boot and static RPI2 DTB embedded in kernel, I've
managed to make the RPI2 kernel boot on my RPI3 and recognize all
cortex-a53 processors.

I've got errors then because the DTB mustn't be static, the RPI firmware
patches it with required values before giving control to kernel.

I still need to figure out why the kernel doesn't like the DTB provided by
firmware when it's not static, and panics with "OF_init failed with the
found device tree" in initarm, but apart from that I feel like we are close
to having a 32-bit OS for RPI3 and new RPI2 v1.2.


Copyright (c) 1992-2017 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 12.0-CURRENT #45 14d0c5770e7(master)-dirty: Fri Aug 11 17:31:04
CEST 2017
    [hidden email]:/usr/obj/arm.armv6/usr/src/sys/GENERIC arm
FreeBSD clang version 5.0.0 (branches/release_50 309439) (based on LLVM
5.0.0svn)
VT: init without driver.
CPU: ARM Cortex-A53 r0p4 (ECO: 0x00000080)
CPU Features:
  Multiprocessing, Thumb2, Security, Virtualization, Generic Timer, VMSAv7,
  PXN, LPAE, Coherent Walk
Optional instructions:
  SDIV/UDIV, UMULL, SMULL, SIMD(ext)
LoUU:2 LoC:3 LoUIS:2
Cache level 1:
 32KB/64B 4-way data cache WB Read-Alloc Write-Alloc
 32KB/64B 2-way instruction cache Read-Alloc
Cache level 2:
 512KB/64B 16-way unified cache WB Read-Alloc Write-Alloc
...



2017-08-10 18:04 GMT+02:00 Mark Millard <[hidden email]>:

> On 2017-Aug-10, at 6:51 AM, Sylvain Garrigues <sylvain at
> sylvaingarrigues.com> wrote:
>
> > 2017-08-10 1:58 GMT+02:00 Mark Millard <[hidden email]>:
> >> Overall: Supporting aarch32 is not automatic
> >> even if one starts from armv7 or specifically
> >> a cortex-a53 context unless one was lucky
> >> enough to happen to not touch or depend on
> >> any of the differences at any stage.
> >
> >  Thanks. I guess though that it's quite easily feasible for someone
> familiar with arm lower level initialization.
> >
> > I can see NetBSD managed to make the armv7 kernel boot on Raspberry Pi 3
> with one commit:
> > Get the RPI3 working (in aarch32 mode) by recognising Cortex A53 CPUs. -
> https://github.com/IIJ-NetBSD/netbsd-src/commit/
> 00335f7adc380a125d045279c1a0f5525fb557da
>
> Interesting.
>
> > Same for OpenBSD folks:
> > http://marc.info/?l=openbsd-tech&m=145692659524971&w=2
>
> This one (OpenBSD) says (note the "including some other
> (still) local diffs"):
>
> "This way, and including some other (still) local diffs, I have
> the brand new raspberry Pi 3 in multiuser:  http://ix.io/oJV "
>
> So the reference only has some of of the code changes shown.
>
> And the boot log shows:
>
> cpu0 at mainbus0: ARM Cortex A53 rev 4 (ARMv7 core)
> cpu0: DC enabled IC enabled WB disabled EABT branch prediction enabled
> cpu0: 32KB(64b/l,2way) I-cache, 32KB(64b/l,4way) wr-back D-cache
>
> So just one cpu. But for all I know OpenBSD might not have
> been SMP capable on a rpi2 at the time either.
>
> The boot log also shows:
>
> gpio at bcmgpio0 not configured
> broadcom0: device bcmsdhc unit 0 not found
>
>
> So for OpenBSD the code change shown was just the start of the
> update as far as I can tell.
>
> > Plus FreeBSD's RPI2 armv6 kernel does boot and recognize the cortex-a53
> with qemu-aarch64:
> > qemu-system-aarch64 -M raspi2 -cpu cortex-a53 -m 1024 -smp 4 -kernel
> kernel.bin -serial stdio -dtb rpi2.dtb
>
> Interesting. How clean is the boot log?
>
> At least for raspbian there were separate files for rpi3
> when rpi3 was first supported:
>
> arch/arm/boot/dts/bcm2710-rpi-3-b.dts
> arch/arm/boot/dts/bcm2710.dtsi
>
> Later there was:
>
> arch/arm/boot/dts/overlays/pi3-disable-bt-overlay.dts
> arch/arm/boot/dts/overlays/pi3-miniuart-bt-overlay.dts
> arch/arm/boot/dts/overlays/pi3-disable-wifi-overlay.dts
> arch/arm/boot/dts/overlays/pi3-act-led-overlay.dts
>
> as well as some updates to some of those files. (I'm
> not sure that I found all such files that are rpi3
> specific [possibly covering rpi2v1.2 as well?].)
>
> I suspect the qemu-system-aarch64 use is simulating
> a rpi2's details as listed in rpi2.dtb instead of the
> rpi3's details. (But using a cortex-a53 CPU model.)
> There may well be work in supporting the rpi3's
> details in the kernel and/or boot loading stages for
> all I know.
>
> What happens if a rpi3 dtb file is used instead of
> rpi2.dtb ?
>
>
> > So I guess we too are really not far to boot RPI2 "armv6" kernel on
> raspberry pi 2 v1.2 and raspberry pi 3.
> > I wish I could help.
>
> Since I'm finding these things as I go I've no clue
> what I've not found. So I can not tell how close to
> correct you are.
>
>
> ===
> Mark Millard
> markmi at dsl-only.net
>
>
>
>
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "[hidden email]"