From mboxrd@z Thu Jan 1 00:00:00 1970
From: Mathew McBride <matt@traverse.com.au>
To: development@lists.ipfire.org
Subject: Re: ARM 64?
Date: Sun, 19 Aug 2018 18:54:22 +1000
Message-ID: <55025D1B-BA00-47EE-A951-1DBC62383DC1@traverse.com.au>
In-Reply-To: <dc4aa7eb2b10d89ecd1952f309fe3a8a38016925.camel@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============4422746591844460447=="
List-Id: <development.lists.ipfire.org>
--===============4422746591844460447==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Hi Michael,
I gave the arm64 snapshot a go under virtualization on our boards.=20
The kernel dies very quickly, I had to use earlycon to get some output.
It looks like ACPI isn't enabled? (CONFIG_ACPI=3Dn in config/kernel/kernel.co=
nfig.aarch64-ipfire)
Our board does not use ACPI, but under virtualization, the Linaro UEFI/EDK2 b=
lobs for QEMU use ACPI exclusively, as do recent "ARM Server"/SBSA boards I b=
elieve. Your APM Mustang certainly pre-dates the 'mainstream' ARM64 switch to=
ACPI.
CONFIG_ACPI=3Dy will not prevent the kernel working on boards that use the FD=
T/Device tree method, just that an ACPI device table will be used instead of =
FDT if it exists.
Here is the set of options I use (I think these are the arm64 defaults) that =
work with EDK2:
https://gitlab.com/traversetech/traverse-kernel-patches/blob/kernel-4-14/kern=
el-config#L4102
efi: Getting EFI parameters from FDT:
efi: EFI v2.60 by EDK II
efi: SMBIOS 3.0=3D0x5bdb0000 ACPI 2.0=3D0x585b0000 MEMATTR=3D0x58e27018
cma: Reserved 8 MiB at 0x000000005f800000
Failed to find device node for boot cpu
missing boot CPU MPIDR, not enabling secondaries
..
Kernel panic - not syncing: No interrupt controller found.
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.14.50-ipfire #1
Call trace:
[<ffffff800808b078>] dump_backtrace+0x0/0x288
[<ffffff800808b324>] show_stack+0x24/0x30
[<ffffff80088dc108>] dump_stack+0x9c/0xbc
[<ffffff80080a7b14>] panic+0x140/0x29c
[<ffffff8008e07c30>] init_IRQ+0x1c8/0x208
[<ffffff8008e016c4>] start_kernel+0x33c/0x5a0
Rebooting in 10 seconds..
Reboot failed -- System halted
Full boot log attached.
Cheers,
Matt
=EF=BB=BFOn 26/7/18, 7:50 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> =
wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
=20
Hello guys,
=20
so here is a quick status update on aarch64 & EFI:
=20
* EFI: We have a separate branch with a bootloader that runs in EFI
mode for x86_64 and aarch64. We won't support 32 bit x86 and EFI.
=20
It seems to be running quite okay on most hardware, although we haven't
really tested enough yet to say if is ready for production. All in all
we might merge it for Core 124, but since there was no feedback
whatsoever it is hard to make that decision, yet.
=20
* aarch64: We got a booting kernel and userland. It runs on the RPi 3
with a little bit of manual configuration of the bootloader. Generally
I do not want to support any SBCs, but Arne used this one for testing
at least.
=20
Since we don't have any other hardware and especially nothing that
supports EFI, we haven't brought the two things together, but are
looking forward to do this soon.
=20
I have launched a virtual machine with both, aarch64 and EFI on the APM
Mustang that I have available and it is running well. It is fast, it is
stable and we don't expect a big backlog of bugs that we need to solve
before this is ready to be shipped.
=20
So, that is the July update from my side. Please feel free to ask any
questions if there are any.
=20
Best,
- -Michael
=20
On Mon, 2018-06-18 at 18:11 +0200, Peter M=C3=BCller wrote:
> Hello,
>=20
> this looks quite good - I am strongly interested. :-)
>=20
> Best regards,
> Peter M=C3=BCller
>=20
> > On Mon, 2018-06-18 at 09:40 +1000, Mathew McBride wrote:
> > > Hi Peter,
> > > There are two crypto options on our board:
> > > - ARMv8 Cryptography instructions (similar to AES-NI on x86)
> > > - Freescale SEC/CAAM engine (a 'hardware accelerator' that can do m=
any
> > > TLS,IPSec etc. operations)
> > > I am certain that an RNG is part of the SEC engine, but I need to c=
heck the
> > > driver status on Linux.
> > >=20
> > > /proc/crypto output for those interested:
> > > https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374
> >=20
> > Wow, that is a very extensive list of supported ciphers and hashes as=
well as
> > the combination of HMAC + cipher mode.
> >=20
> > IPsec in the kernel will basically be not consuming any CPU cycles fo=
r crypto.
> >=20
> > Best,
> > -Michael
> >=20
> > >=20
> > > Regards,
> > > Mathew=20
> > >=20
> > > =EF=BB=BFOn 15/6/18, 3:09 am, "Peter M=C3=BCller" <peter.mueller(a)=
link38.eu> wrote:
> > >=20
> > > Hello,
> > > =20
> > > this board sounds very interesting indeed (trustworthy hardware=
- yay!).
> > > However, after reading the datasheet it did not became clear to=
me if it
> > > has some built-in random number generator and/or cryptography
> > > acceleration.
> > > =20
> > > Apart from some low-level backdoors (baked into USB, ... firmwa=
re chips)
> > > it seems like this is suitable for security relevant devices. L=
ooking
> > > forward to hear some experiences with IPFire on it. :-)
> > > =20
> > > Best regards,
> > > Peter M=C3=BCller
> > > =20
> > > > Hey Matt,
> > > >=20
> > > > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
> > > >> Hi Michael,
> > > >>
> > > >> Just in response to your questions:
> > > >> =EF=BB=BFOn 25/5/18, 11:10 pm, "Michael Tremer" <michael.tre=
mer(a)ipfire.org>
> > > wrote:
> > > >> =20
> > > >> =20
> > > >> I think you hardware is good enough for a builder. But I=
still am
> > > not sure
> > > >> what
> > > >> to expect from the CPU. It will be faster than a Raspber=
ry Pi, but
> > > not a
> > > >> Mustang.
> > > >> =20
> > > >> We did some benchmarks with the Phoronix test suite a while =
ago, this
> > > will
> > > >> give you an idea:
> > > >> http://openbenchmarking.org/result/1708303-TR-
> > > >> 1703199RI93&obr_hgv=3DTraverse+LS1043+Prototype
> > > >=20
> > > > I had a look at that. And yes indeed, it is a bit hard to fig=
ure out the
> > > > performance by the CPU name alone for most ARM SoCs. There is=
no
> > > branding in
> > > > order of performance (or similar) like Intel has.
> > > >=20
> > > > That might actually turn out to be a bigger marketing problem=
, but we
> > > will see
> > > > that in the future.
> > > >=20
> > > >> To give an idea of the Cortex (ARM designed)-based core perf=
ormance:
> > > >>
> > > >> The LS1043 has the same A53 cores as the RPi3, but performs =
better due
> > > to
> > > >> having more cache, DDR4 etc (and higher clock).
> > > >=20
> > > > Performance is also coming from the rest of the periphery. Th=
e RPi has a
> > > slow
> > > > and not very stable USB bus to talk to the network to and SD =
card
> > > storage. Even
> > > > with a faster CPU it might very often just wait for data.
> > > >=20
> > > > We have been trying to tell people that they should look out =
for some
> > > specific
> > > > features like cache and good single-core performance.
> > > >=20
> > > >> A72 is about double A53 in performance (and power consumptio=
n!) per
> > > MHz, as
> > > >> A72 is a modern out-of-order speculative core (it did get hi=
t with the
> > > >> Meltdown/Spectre issue).
> > > >=20
> > > > Yes, wouldn't mind to have some systems based on that one sin=
ce the A53
> > > will be
> > > > too slow for really large enterprise deployments.
> > > >=20
> > > >> The latest gen of ARM64 server cores would all be well above=
A72, your
> > > Mustang
> > > >> is probably around the A72 level.
> > > >>
> > > >> In general, ARM network SoCs try to work 'smarter' instead o=
f 'harder',
> > > so the
> > > >> high network performance comes from having very good network=
silicon,
> > > taking
> > > >> advantage of crypto accelerators etc.
> > > >=20
> > > > I prefer the NICs in the SoC which gives great performance. T=
he
> > > disadvantage
> > > > only is that they sometimes to odd configurations like 5x 1G =
and 1x 10G
> > > in this
> > > > case which I don't really understand. The only use-case that =
makes sense
> > > to me
> > > > is a server but for that the CPU is too slow and people would=
probably
> > > go for a
> > > > A72-class CPU.
> > > >=20
> > > >> > There is a TrustZone firmware running in the ring/EL a=
bove the
> > > OS, for
> > > >> the NXP
> > > >> > Layerscape/QorIQ SoC's this firmware is open source, a=
nd not
> > > strictly
> > > >> required
> > > >> > to run the system (it gets loaded by u-boot after powe=
r on).
> > > >> =20
> > > >> What does the firmware do?
> > > >> It implements some vendor-specific power-management extensio=
ns (PSCI),
> > > as well
> > > >> as some TPM-like functions.
> > > >> NXP provides a good overview: https://github.com/qoriq-open-=
source/ppa-
> > > generic
> > > >> /blob/integration/ReleaseNotes.txt
> > > >> I am not a security expert, but it could be a good test envi=
ronment for
> > > secure
> > > >> boot, private key storage and other things.
> > > >=20
> > > > Great that this is entirely open.
> > > >=20
> > > > -Michael
> > > >=20
> > > >>
> > > >> =20
> > > >> Cheers,
> > > >> Matt
> > > >> =20
> > > >>
> > > >>
> > > =20
> > > --=20
> > > "We don't care. We don't have to. We're the Phone Company."
> > > =20
> > > =20
> > >=20
> > >=20
>=20
>=20
-----BEGIN PGP SIGNATURE-----
=20
iQIzBAEBCgAdFiEE5/rW5l3GGe2ypktxgHnw/2+QCQcFAltZmUsACgkQgHnw/2+Q
CQcNfw//VkhXWguNNy/rsjeNLxNlzkJaeb9VXVar6vaTwvq6CcjgNtoRHJcsYU5t
Pk550WufwCeWk1b8VjmGrO1AAfMow/aXVfYJ+wlR0vpi/pwiX596wt1PLcGYMlCB
Ye8Zz4N1FjR1wh8Mqv1aH9AAYhzAKp80GM3bAxU4IRaENutMpdLnOpL9/tiMeoNs
hK9P9skFobvMVQxi+BoF8aWVJrpuVlNP56a/JE/8CVB85El7YnqxLixoDuL1GHjN
6E4CSqtLM8OY9morx32yxd9XvvanxiivAlCnzu8vII8OMuf050fGDV/WHTMlXNEc
S/C5Uua3tcGRInsf2LwPuZ3nMHL4nVIvLUMioMVeCEjoLftQOGgOUK/gV7AOYoy8
WicItyGRduY3IxB79LkRRKy7nZyRTeUm9zxEqsNmT6MquQDhrNa9hQB5LB2N3ZQv
L7CHgeXxtHt5F7n7PQJaICCf0Zl0BM4yP8NK5bpK8YVYP30s8dQxWBbhEuYDO241
ryYIaZ6Xv3cOEH7Md97+2aMsuyXepI/ZW/wpFI//MlkOXoWHNKLDyigmy5rPbQNW
gHIyp7xGOTYOoZPh/jii9dYDwQWNvNMESzC+AsYkBWLmyTYtsexIYts3FIXxunp8
9sqknx/jvhYNsR+9F8htZ9lAhI9fgqqGe9wBPp+blDRE/VNa+Jc=3D
=3DkhkX
-----END PGP SIGNATURE-----
=20
=20
--===============4422746591844460447==
Content-Type: text/plain
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ipfire-edk2-failure.txt"
MIME-Version: 1.0
TG9hZGluZyBMaW51eCA0LjE0LjUwLWlwZmlyZSAuLi4KTG9hZGluZyBpbml0aWFsIHJhbWRpc2sg
Li4uCkVGSSBzdHViOiBCb290aW5nIExpbnV4IEtlcm5lbC4uLgpFRkkgc3R1YjogVXNpbmcgRFRC
IGZyb20gY29uZmlndXJhdGlvbiB0YWJsZQpFRkkgc3R1YjogRXhpdGluZyBib290IHNlcnZpY2Vz
IGFuZCBpbnN0YWxsaW5nIHZpcnR1YWwgYWRkcmVzcyBtYXAuLi4KQm9vdGluZyBMaW51eCBvbiBw
aHlzaWNhbCBDUFUgMHgwCkxpbnV4IHZlcnNpb24gNC4xNC41MC1pcGZpcmUgKHJvb3RAYXJtNjQt
MDEuYnVpbGRlcnMuaXBmaXJlLm9yZykgKGdjYyB2ZXJzaW9uIDcuMy4wIChHQ0MpKSAjMSBTTVAg
VHVlIEp1bCAzMSAxODozNzozMSBHTVQgMjAxOApCb290IENQVTogQUFyY2g2NCBQcm9jZXNzb3Ig
WzQxMGZkMDM0XQplYXJseWNvbjogcGwxMSBhdCBNTUlPIDB4MDAwMDAwMDAwOTAwMDAwMCAob3B0
aW9ucyAnJykKYm9vdGNvbnNvbGUgW3BsMTFdIGVuYWJsZWQKZWZpOiBHZXR0aW5nIEVGSSBwYXJh
bWV0ZXJzIGZyb20gRkRUOgplZmk6IEVGSSB2Mi42MCBieSBFREsgSUkKZWZpOiAgU01CSU9TIDMu
MD0weDViZGIwMDAwICBBQ1BJIDIuMD0weDU4NWIwMDAwICBNRU1BVFRSPTB4NThlMjcwMTgKY21h
OiBSZXNlcnZlZCA4IE1pQiBhdCAweDAwMDAwMDAwNWY4MDAwMDAKRmFpbGVkIHRvIGZpbmQgZGV2
aWNlIG5vZGUgZm9yIGJvb3QgY3B1Cm1pc3NpbmcgYm9vdCBDUFUgTVBJRFIsIG5vdCBlbmFibGlu
ZyBzZWNvbmRhcmllcwpyYW5kb206IGdldF9yYW5kb21fYnl0ZXMgY2FsbGVkIGZyb20gc3RhcnRf
a2VybmVsKzB4ZTQvMHg1YTAgd2l0aCBjcm5nX2luaXQ9MApwZXJjcHU6IEVtYmVkZGVkIDIyIHBh
Z2VzL2NwdSBAZmZmZmZmYzAxZjdkYjAwMCBzNDkxNzYgcjgxOTIgZDMyNzQ0IHU5MDExMgpEZXRl
Y3RlZCBWSVBUIEktY2FjaGUgb24gQ1BVMApDUFUgZmVhdHVyZXM6IGVuYWJsaW5nIHdvcmthcm91
bmQgZm9yIEFSTSBlcnJhdHVtIDg0NTcxOQpCdWlsdCAxIHpvbmVsaXN0cywgbW9iaWxpdHkgZ3Jv
dXBpbmcgb24uICBUb3RhbCBwYWdlczogMTI5MDI0Cktlcm5lbCBjb21tYW5kIGxpbmU6IEJPT1Rf
SU1BR0U9L3ZtbGludXotNC4xNC41MC1pcGZpcmUgcm9vdD1VVUlEPTc1ZmIyZjZjLWVkMDMtNGY1
Yy04MjBhLTBiN2Q3NjRkODlmZSBlYXJseWNvbj1wbDAxMSwweDkwMDAwMDAgcm8gcGFuaWM9MTAK
UElEIGhhc2ggdGFibGUgZW50cmllczogMjA0OCAob3JkZXI6IDIsIDE2Mzg0IGJ5dGVzKQpEZW50
cnkgY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA2NTUzNiAob3JkZXI6IDcsIDUyNDI4OCBieXRl
cykKSW5vZGUtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiAzMjc2OCAob3JkZXI6IDYsIDI2MjE0
NCBieXRlcykKTWVtb3J5OiA0Njc2MDRLLzUyNDI4OEsgYXZhaWxhYmxlICg5NzI0SyBrZXJuZWwg
Y29kZSwgMTMwOEsgcndkYXRhLCAzMzQ4SyByb2RhdGEsIDIwNDhLIGluaXQsIDUyN0sgYnNzLCA0
ODQ5MksgcmVzZXJ2ZWQsIDgxOTJLIGNtYS1yZXNlcnZlZCkKVmlydHVhbCBrZXJuZWwgbWVtb3J5
IGxheW91dDoKICAgIG1vZHVsZXMgOiAweGZmZmZmZjgwMDAwMDAwMDAgLSAweGZmZmZmZjgwMDgw
MDAwMDAgICAoICAgMTI4IE1CKQogICAgdm1hbGxvYyA6IDB4ZmZmZmZmODAwODAwMDAwMCAtIDB4
ZmZmZmZmYmViZmZmMDAwMCAgICggICAyNTAgR0IpCiAgICAgIC50ZXh0IDogMHhmZmZmZmY4MDA4
MDgwMDAwIC0gMHhmZmZmZmY4MDA4YTAwMDAwICAgKCAgOTcyOCBLQikKICAgIC5yb2RhdGEgOiAw
eGZmZmZmZjgwMDhhMDAwMDAgLSAweGZmZmZmZjgwMDhlMDAwMDAgICAoICA0MDk2IEtCKQogICAg
ICAuaW5pdCA6IDB4ZmZmZmZmODAwOGUwMDAwMCAtIDB4ZmZmZmZmODAwOTAwMDAwMCAgICggIDIw
NDggS0IpCiAgICAgIC5kYXRhIDogMHhmZmZmZmY4MDA5MDAwMDAwIC0gMHhmZmZmZmY4MDA5MTQ3
MjAwICAgKCAgMTMwOSBLQikKICAgICAgIC5ic3MgOiAweGZmZmZmZjgwMDkxNDcyMDAgLSAweGZm
ZmZmZjgwMDkxY2IwNTggICAoICAgNTI4IEtCKQogICAgZml4ZWQgICA6IDB4ZmZmZmZmYmVmZTdm
YjAwMCAtIDB4ZmZmZmZmYmVmZWMwMDAwMCAgICggIDQxMTYgS0IpCiAgICBQQ0kgSS9PIDogMHhm
ZmZmZmZiZWZlZTAwMDAwIC0gMHhmZmZmZmZiZWZmZTAwMDAwICAgKCAgICAxNiBNQikKICAgIHZt
ZW1tYXAgOiAweGZmZmZmZmJmMDAwMDAwMDAgLSAweGZmZmZmZmMwMDAwMDAwMDAgICAoICAgICA0
IEdCIG1heGltdW0pCiAgICAgICAgICAgICAgMHhmZmZmZmZiZjAwMDAwMDAwIC0gMHhmZmZmZmZi
ZjAwODAwMDAwICAgKCAgICAgOCBNQiBhY3R1YWwpCiAgICBtZW1vcnkgIDogMHhmZmZmZmZjMDAw
MDAwMDAwIC0gMHhmZmZmZmZjMDIwMDAwMDAwICAgKCAgIDUxMiBNQikKU0xVQjogSFdhbGlnbj02
NCwgT3JkZXI9MC0zLCBNaW5PYmplY3RzPTAsIENQVXM9MSwgTm9kZXM9MQpmdHJhY2U6IGFsbG9j
YXRpbmcgMzAyNjYgZW50cmllcyBpbiAxMTkgcGFnZXMKSGllcmFyY2hpY2FsIFJDVSBpbXBsZW1l
bnRhdGlvbi4KICAgICAgICBSQ1UgcmVzdHJpY3RpbmcgQ1BVcyBmcm9tIE5SX0NQVVM9OCB0byBu
cl9jcHVfaWRzPTEuClJDVTogQWRqdXN0aW5nIGdlb21ldHJ5IGZvciByY3VfZmFub3V0X2xlYWY9
MTYsIG5yX2NwdV9pZHM9MQpOUl9JUlFTOiA2NCwgbnJfaXJxczogNjQsIHByZWFsbG9jYXRlZCBp
cnFzOiAwCktlcm5lbCBwYW5pYyAtIG5vdCBzeW5jaW5nOiBObyBpbnRlcnJ1cHQgY29udHJvbGxl
ciBmb3VuZC4KQ1BVOiAwIFBJRDogMCBDb21tOiBzd2FwcGVyLzAgTm90IHRhaW50ZWQgNC4xNC41
MC1pcGZpcmUgIzEKQ2FsbCB0cmFjZToKWzxmZmZmZmY4MDA4MDhiMDc4Pl0gZHVtcF9iYWNrdHJh
Y2UrMHgwLzB4Mjg4Cls8ZmZmZmZmODAwODA4YjMyND5dIHNob3dfc3RhY2srMHgyNC8weDMwCls8
ZmZmZmZmODAwODhkYzEwOD5dIGR1bXBfc3RhY2srMHg5Yy8weGJjCls8ZmZmZmZmODAwODBhN2Ix
ND5dIHBhbmljKzB4MTQwLzB4MjljCls8ZmZmZmZmODAwOGUwN2MzMD5dIGluaXRfSVJRKzB4MWM4
LzB4MjA4Cls8ZmZmZmZmODAwOGUwMTZjND5dIHN0YXJ0X2tlcm5lbCsweDMzYy8weDVhMApSZWJv
b3RpbmcgaW4gMTAgc2Vjb25kcy4uClJlYm9vdCBmYWlsZWQgLS0gU3lzdGVtIGhhbHRlZA==
--===============4422746591844460447==--