Re: ARM 64?

[Mathew McBride <matt@traverse.com.au>]

[-- Attachment #1: Type: text/plain, Size: 10962 bytes --]

Hi Michael,
I gave the arm64 snapshot a go under virtualization on our boards. 
The kernel dies very quickly, I had to use earlycon to get some output.

It looks like ACPI isn't enabled? (CONFIG_ACPI=n in config/kernel/kernel.config.aarch64-ipfire)

Our board does not use ACPI, but under virtualization, the Linaro UEFI/EDK2 blobs for QEMU use ACPI exclusively, as do recent "ARM Server"/SBSA boards I believe. Your APM Mustang certainly pre-dates the 'mainstream' ARM64 switch to ACPI.
CONFIG_ACPI=y will not prevent the kernel working on boards that use the FDT/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/kernel-config#L4102

efi: Getting EFI parameters from FDT:
efi: EFI v2.60 by EDK II
efi:  SMBIOS 3.0=0x5bdb0000  ACPI 2.0=0x585b0000  MEMATTR=0x58e27018
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


On 26/7/18, 7:50 pm, "Michael Tremer" <michael.tremer(a)ipfire.org> wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512
    
    Hello guys,
    
    so here is a quick status update on aarch64 & EFI:
    
    * 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.
    
    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.
    
    * 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.
    
    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.
    
    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.
    
    So, that is the July update from my side. Please feel free to ask any
    questions if there are any.
    
    Best,
    - -Michael
    
    On Mon, 2018-06-18 at 18:11 +0200, Peter Müller wrote:
    > Hello,
    > 
    > this looks quite good - I am strongly interested. :-)
    > 
    > Best regards,
    > Peter Müller
    > 
    > > 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 many
    > > > TLS,IPSec etc. operations)
    > > > I am certain that an RNG is part of the SEC engine, but I need to check the
    > > > driver status on Linux.
    > > > 
    > > > /proc/crypto output for those interested:
    > > > https://gist.github.com/mcbridematt/11f14c78ed4e35e97adf2f027010e374
    > > 
    > > Wow, that is a very extensive list of supported ciphers and hashes as well as
    > > the combination of HMAC + cipher mode.
    > > 
    > > IPsec in the kernel will basically be not consuming any CPU cycles for crypto.
    > > 
    > > Best,
    > > -Michael
    > > 
    > > > 
    > > > Regards,
    > > > Mathew 
    > > > 
    > > > On 15/6/18, 3:09 am, "Peter Müller" <peter.mueller(a)link38.eu> wrote:
    > > > 
    > > >     Hello,
    > > >     
    > > >     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.
    > > >     
    > > >     Apart from some low-level backdoors (baked into USB, ... firmware chips)
    > > >     it seems like this is suitable for security relevant devices. Looking
    > > >     forward to hear some experiences with IPFire on it. :-)
    > > >     
    > > >     Best regards,
    > > >     Peter Müller
    > > >     
    > > >     > Hey Matt,
    > > >     > 
    > > >     > On Mon, 2018-05-28 at 20:32 +1000, Mathew McBride wrote:
    > > >     >> Hi Michael,
    > > >     >>
    > > >     >> Just in response to your questions:
    > > >     >> On 25/5/18, 11:10 pm, "Michael Tremer" <michael.tremer(a)ipfire.org>
    > > > wrote:
    > > >     >>     
    > > >     >>     
    > > >     >>     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 Raspberry Pi, but
    > > > not a
    > > >     >>     Mustang.
    > > >     >>     
    > > >     >> 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=Traverse+LS1043+Prototype
    > > >     > 
    > > >     > I had a look at that. And yes indeed, it is a bit hard to figure 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.
    > > >     > 
    > > >     > That might actually turn out to be a bigger marketing problem, but we
    > > > will see
    > > >     > that in the future.
    > > >     > 
    > > >     >> To give an idea of the Cortex (ARM designed)-based core performance:
    > > >     >>
    > > >     >> The LS1043 has the same A53 cores as the RPi3, but performs better due
    > > > to
    > > >     >> having more cache, DDR4 etc (and higher clock).
    > > >     > 
    > > >     > Performance is also coming from the rest of the periphery. The 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.
    > > >     > 
    > > >     > We have been trying to tell people that they should look out for some
    > > > specific
    > > >     > features like cache and good single-core performance.
    > > >     > 
    > > >     >> A72 is about double A53 in performance (and power consumption!) per
    > > > MHz, as
    > > >     >> A72 is a modern out-of-order speculative core (it did get hit with the
    > > >     >> Meltdown/Spectre issue).
    > > >     > 
    > > >     > Yes, wouldn't mind to have some systems based on that one since the A53
    > > > will be
    > > >     > too slow for really large enterprise deployments.
    > > >     > 
    > > >     >> 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 of 'harder',
    > > > so the
    > > >     >> high network performance comes from having very good network silicon,
    > > > taking
    > > >     >> advantage of crypto accelerators etc.
    > > >     > 
    > > >     > I prefer the NICs in the SoC which gives great performance. The
    > > > 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.
    > > >     > 
    > > >     >>     > There is a TrustZone firmware running in the ring/EL above the
    > > > OS, for
    > > >     >> the NXP
    > > >     >>     > Layerscape/QorIQ SoC's this firmware is open source, and not
    > > > strictly
    > > >     >> required
    > > >     >>     > to run the system (it gets loaded by u-boot after power on).
    > > >     >>     
    > > >     >>     What does the firmware do?
    > > >     >> It implements some vendor-specific power-management extensions (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 environment for
    > > > secure
    > > >     >> boot, private key storage and other things.
    > > >     > 
    > > >     > Great that this is entirely open.
    > > >     > 
    > > >     > -Michael
    > > >     > 
    > > >     >>
    > > >     >>     
    > > >     >> Cheers,
    > > >     >> Matt
    > > >     >>  
    > > >     >>
    > > >     >>
    > > >     
    > > >     -- 
    > > >     "We don't care.  We don't have to.  We're the Phone Company."
    > > >     
    > > >     
    > > > 
    > > > 
    > 
    > 
    -----BEGIN PGP SIGNATURE-----
    
    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=
    =khkX
    -----END PGP SIGNATURE-----
    
    




[-- Attachment #2: ipfire-edk2-failure.txt --]
[-- Type: text/plain, Size: 3130 bytes --]

Loading Linux 4.14.50-ipfire ...
Loading initial ramdisk ...
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Exiting boot services and installing virtual address map...
Booting Linux on physical CPU 0x0
Linux version 4.14.50-ipfire (root@arm64-01.builders.ipfire.org) (gcc version 7.3.0 (GCC)) #1 SMP Tue Jul 31 18:37:31 GMT 2018
Boot CPU: AArch64 Processor [410fd034]
earlycon: pl11 at MMIO 0x0000000009000000 (options '')
bootconsole [pl11] enabled
efi: Getting EFI parameters from FDT:
efi: EFI v2.60 by EDK II
efi:  SMBIOS 3.0=0x5bdb0000  ACPI 2.0=0x585b0000  MEMATTR=0x58e27018
cma: Reserved 8 MiB at 0x000000005f800000
Failed to find device node for boot cpu
missing boot CPU MPIDR, not enabling secondaries
random: get_random_bytes called from start_kernel+0xe4/0x5a0 with crng_init=0
percpu: Embedded 22 pages/cpu @ffffffc01f7db000 s49176 r8192 d32744 u90112
Detected VIPT I-cache on CPU0
CPU features: enabling workaround for ARM erratum 845719
Built 1 zonelists, mobility grouping on.  Total pages: 129024
Kernel command line: BOOT_IMAGE=/vmlinuz-4.14.50-ipfire root=UUID=75fb2f6c-ed03-4f5c-820a-0b7d764d89fe earlycon=pl011,0x9000000 ro panic=10
PID hash table entries: 2048 (order: 2, 16384 bytes)
Dentry cache hash table entries: 65536 (order: 7, 524288 bytes)
Inode-cache hash table entries: 32768 (order: 6, 262144 bytes)
Memory: 467604K/524288K available (9724K kernel code, 1308K rwdata, 3348K rodata, 2048K init, 527K bss, 48492K reserved, 8192K cma-reserved)
Virtual kernel memory layout:
    modules : 0xffffff8000000000 - 0xffffff8008000000   (   128 MB)
    vmalloc : 0xffffff8008000000 - 0xffffffbebfff0000   (   250 GB)
      .text : 0xffffff8008080000 - 0xffffff8008a00000   (  9728 KB)
    .rodata : 0xffffff8008a00000 - 0xffffff8008e00000   (  4096 KB)
      .init : 0xffffff8008e00000 - 0xffffff8009000000   (  2048 KB)
      .data : 0xffffff8009000000 - 0xffffff8009147200   (  1309 KB)
       .bss : 0xffffff8009147200 - 0xffffff80091cb058   (   528 KB)
    fixed   : 0xffffffbefe7fb000 - 0xffffffbefec00000   (  4116 KB)
    PCI I/O : 0xffffffbefee00000 - 0xffffffbeffe00000   (    16 MB)
    vmemmap : 0xffffffbf00000000 - 0xffffffc000000000   (     4 GB maximum)
              0xffffffbf00000000 - 0xffffffbf00800000   (     8 MB actual)
    memory  : 0xffffffc000000000 - 0xffffffc020000000   (   512 MB)
SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
ftrace: allocating 30266 entries in 119 pages
Hierarchical RCU implementation.
        RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=1.
RCU: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=1
NR_IRQS: 64, nr_irqs: 64, preallocated irqs: 0
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