AMI has announced support of Redfish for AArch64:
UEFI has a bytecode, the uEfi ByteCode (EBC). It has traditionally been a bytecode used to consolidate all 3 Intel platforms (x86, x64, Itanic), into a single bytecode, so there only needs to be a single driver on the flash, saving flash memory. Unfortunately, it only supported Intel platforms, not ARM, so it was not a universal bytecode for EFI, only a bytecode for Intel systems. Now, someone has ported AArch64 to ARM, so now EBC may now be more interesting!
Import the AArch64 EBC implementation from
Tested with MdeModulePkg/Application/HelloWorld built for EBC.
Would appreciate some reviewing and testing.
Jeff Brasen (1):
MdeModulePkg/EbcDxe: Add AARCH64 EBC VM support
Leif Lindholm (1):
ArmVirtPkg: enable EBC interpreter for AArch64 QEMU
Tom Stevens of ARM posted a blog with a new list of links for developers new to ARM. About 40 links, mostly on ARM assembly and C, Cortex-M, NEON, ARMv8/AArch64. Here’s a list of the initial 10 or so links’s titles:
Getting Started with ARM Microcontroller and Assembly Programming
How to Load Constants in Assembly for ARM Architecture
Branch and Call Sequences Explained
Building Customized Debug and Trace Solutions for Multicore SoCs
Caches and Self-Modifying Code
Code Size: A Comprehensive Comparison of MicroMIPS32 and Thumb Code Size Using Many Megabytes of Customer Code
How to Call a Function from ARM Assembler
Designing in ARM: Part One- Switching Microcontrollers
Getting Started with ARM Assembly and C Programming
Detecting Overflow from MUL
If this were done outside ARM.com, it’d probably github-hosted and called ‘awesome-arm-development.md’. (BTW, I’m slowly working on an ‘awesome firmware’ link collection, if someone doesn’t do one first…)
Shannon Zhao of Huawei submitted a 17-part patch to the Linux-ARM-kernel, Linux-EFI, Linux-Kernel, and Xen-devel lists, which adds ACPI support for Xen Dom0 on AArch64 systems.
This patch set adds ACPI support for Xen Dom0 on ARM64. The relevant Xen ACPI on ARM64 design document could be found from . The corresponding Xen patches can be fetched from .
Xen: ACPI: Hide UART used by Xen
xen/grant-table: Move xlated_setup_gnttab_pages to common place
Xen: xlate: Use page_to_xen_pfn instead of page_to_pfn
arm/xen: Use xen_xlate_map_ballooned_pages to setup grant table
xen: memory : Add new XENMAPSPACE type XENMAPSPACE_dev_mmio
Xen: ARM: Add support for mapping platform device mmio
Xen: ARM: Add support for mapping AMBA device mmio
Xen: public/hvm: sync changes of HVM_PARAM_CALLBACK_VIA ABI from Xen
xen/hvm/params: Add a new delivery type for event-channel in HVM_PARAM_CALLBACK_IRQ
arm/xen: Get event-channel irq through HVM_PARAM when booting with ACPI
ARM: XEN: Move xen_early_init() before efi_init()
ARM64: ACPI: Check if it runs on Xen to enable or disable ACPI
ARM: Xen: Document UEFI support on Xen ARM virtual platforms
XEN: EFI: Move x86 specific codes to architecture directory
ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services
FDT: Add a helper to get specified name subnode
Xen: EFI: Parse DT parameters for Xen specific UEFI
Hanjun Guo of Huawei submitted a 12-part patch to the Linux-ACPI, Linux-ARM-Kernel, and Linux-Kernel lists, which adds ACPU NUMA (Non-Uniform Memory Access) support for AArch64 systems.
Based on Ganapat’s v9 dt based NUMA patch set  for ARM64, this patch set introduce the ACPI based configuration to provide NUMA information. ACPI 5.1 already introduced NUMA support for ARM64, which can get the NUMA domain information from SRAT and SLIT table, so parse those two tables to get mappings from cpu/mem to numa node configration and system locality.
acpi, numa: Use pr_fmt() instead of printk
acpi, numa: Replace ACPI_DEBUG_PRINT() with pr_debug()
acpi, numa: remove duplicate NULL check
acpi, numa: introduce ACPI_HAS_NUMA_ARCH_FIXUP
arm64, acpi, numa: NUMA support based on SRAT and SLIT
acpi, numa: Enable ACPI based NUMA on ARM64
acpi, numa: move acpi_numa_slit_init() to common place
arm64, numa: rework numa_add_memblk()
x86, acpi, numa: cleanup acpi_numa_processor_affinity_init()
acpi, numa: move bad_srat() and srat_disabled() to common place
acpi, numa: remove unneeded acpi_numa=1
acpi, numa: reuse acpi_numa_memory_affinity_init()
Olimex is working on an Open Source Hardware-based AArch64-based laptop, based on their Open Source Hardware-based AArch64 dev board. They have a update on the system. Including some prototype pictures:
“needless to mention this window button will become Tux. :-)”
I wonder about what firmware they’ll use, and if the use will be able to update it themselves, from source….
Quoting their documentation:
Estuary provides a total solution for general-purpose computer based on aarch64 architecture. Anyone can quickly bring up an ARM64 platform – both software and hardware with Estuary. The major goals for Estuary project are:
* A stable\available quick start solution based on ARM64 computer, so that anyone can easily get and bring up the complete development environment, so that you can just focus on your particular field quickly.
* A common basic platform, which should be sustainable and will be continuously improved, can attract\absorb and integrate all 3rd part achievement ceaselessly.
* Sufficient technological documentation, so that any user or partner can easily get useful help from it.
* Simple and effective communication forum for ARM64 ecosystem, so that users can interact and share each other to improve ARM64 ecosystem.
* A bug tracking system, so that anyone can raise, track and help to resolve the issues, this will help to mature the solution and enhance the ecosystem.
* Multiple ARM64-based hardware platforms, and related software to speed up the ARM64 ecosystem development.
* The most key goal of Estuary project is to support, enable and speed up the maturity of ARM64 ecosystem.
For hardware, they currently support two AArch64 SOC boards, D01, D02 boards. For OS, they support Linux or Windows. For, firmware they say they support “Multi-kinds of boot loader will be enabled for Estuary, include but not limited to UEFI\Grub, uboot.” But currently they appear to support UEFI and GRUB. Amongst the other tools included in Estuary is a LAVA system, Linaro’s Automated Validation system, which performs continuous integration on QEMU- and multiple ARM-based devices, letting you reinstall firmware, OS, run pre-OS tests, and gather results.
They include their UEFI changes in their project changelogs, eg their 2.0 release from last month included two entries on UEFI:
9. Pubished the latest UEFI source code for D02 and eanbled building UEFI from source code directly.
11. Upgraded UEFI to add PCIE scaning.
a. Remove GE4 and keep only GE5 on UEFI, to avoid confusion with 2 NICs.
b. Re-enable PCI Express link up for port 1 and 2 (According to PCI Express slots on the board).
c. Fix PXE timeout issue.
d. Re-enable showbrdnum and setbrdnum commands on EBL.
e. Fix several other bugs.
They are still using Ubuntu 12.04.