Hi; this email is intended mainly to raise awareness of an
issue which some people here might care about but be currently
unaware of, and to see if anybody already has a plan to deal with it.
The VM System Specification for ARM Processors:
http://www.linaro.org/docs/vm-system-specification-arm-processors/
defines the contract between a VM implementaton (like KVM/QEMU or
Xen) and an image to run on it (like a distro's ISO installer image).
This specification mandates that we boot by treating the image as
a UEFI ISO image with a FAT32 filesystem. So the VM (and QEMU in
particular) needs to have a custom UEFI firmware image if it wants to
support booting these images, and that UEFI needs to understand FAT32.
Unfortunately the Tianocore UEFI implementation, though mostly BSD
licensed, has a critical piece which is not. The FAT filesystem driver
license is "BSD plus may only be used as part of EFI"; full license
text on this web page:
http://tianocore.sourceforge.net/wiki/Edk2-fat-driver
This is redistributable, but obviously not Free by either the OSI or
Debian Free Software Guidelines definitions. Accordingly it would have
to go in Debian "non-free" and other distro equivalents. (This is
exactly where the x86 Tianocore-derived UEFI implementation, OVMF,
is currently distributed.)
So the default place we're likely to end up if nobody takes any
action is that to use typically distributed ISO images with QEMU
the end-user will need to install the UEFI blob on their host system
from non-free or other distro equivalent (or download it themselves
from the upstream Tianocore website, perhaps).
The question then is: is this outcome unacceptable or undesirable
to anybody? Is anybody planning some other approach?
Some notes:
(1) The VM spec doesn't require that the VM supports *only* the UEFI
ISO image format, so it's not the case that QEMU is useless
without the UEFI firmware. For instance, you could have a Free UEFI
variant which omitted the FAT driver, and pick one of the other
filesystem types that Tianocore supports for your distro's CD images.
(Obviously those images would then probably not be able to boot on h/w,
and conversely "standard" images wouldn't boot on the Free-UEFI.)
(2) When describing or proposing a solution to this it's important
to be clear about the distinction between copyright licensing issues
and patent issues. The problem with the tianocore FAT driver is its
copyright license. Anybody proposing a reimplementation with a different
license needs to consider whether they run into patent problems.
(I'm not going to state an opinion either way about whether such
a reimplementation would potentially intersect any FAT related
patents or whether the MS license for purposes of implementing EFI
would avoid problems or not.)
(3) I imagine that a lot of this ground has already been covered
when considering x86 and OVMF; the only difference for ARM is that
there's no standard Free-licensed alternative firmware, so the problem
is a little more acute. If anybody has a pointer to previous
discussion or conclusions that might save us some argument.
(4) If the "default outcome" is actually at least not unacceptable
to anybody then we can of course simply do nothing...
thanks
-- PMM
Hi All,
This is just a heads-up that we've run into quite a horrible crash +
data corruption issue with MariaDB when running sysbench with a large
number of threads on a couple of AArch64 platforms.
I believe the problem can be attributed to the code used to release
the custom mutexes used by the storage engine.
I have logged a ticket (and attached an emergency fix) here:
https://mariadb.atlassian.net/browse/MDEV-6615
Cheers,
--
Steve Capper
Hi all,
Current snapshots of Debian Jessie installer snapshots, as well as the
kernel packages, support providing the system console information via
the chosen node 'stdout-path' property instead of on the command line.
This is enabled by two patches backported from 3.17 to Jessie's 3.16
kernel, together with three small patches currently in Linus's tree,
awaiting 3.19-rc1.
The first two are actually sufficient for models, but the additional
ones are required to be able to specify options (like baudrate).
The commits are:
>From 3.16
a208ffd251d08ed7ba6bdf3ae1e423373fb12d3d - of: Enable console on
serial ports specified by /chosen/stdout-path
3482f2c52b77bf6596e24aae82e204a0603eba66 - of: Create
of_console_check() for selecting a console specified in /chosen
>From current Linus
2a9d832cc9aae21ea827520fef635b6c49a06c6d - of: Add bindings for
chosen node, stdout-path
75c28c09af99a0db0ccd8b4395469761aa736543 - of: add optional options
parameter to of_find_node_by_path()
7914a7c5651a51617d952e8fa745000ed8c4f001 - of: support passing console
options with stdout-path
Linaro 2014.12 UEFI release sets this option for FVP/Foundation Base
models.
QEMU 2.2 does the same for all (?) arm64 platforms.
ACPI platforms will be able to do something similar with SPCR.
/
Leif
I am having difficulty figuring out the include and library paths to
compile hello.cpp with cross-toolchain arm-linux-gnueabihf installed via
'sudo apt-get install gcc-arm-linux-gnueabihf' on Ubuntu 14.04 PC
I can set up Eclipse (Luna) to build hello.c, but not hello.cpp
hello.c search paths:
Cross-tools path: /usr/bin
tools prefix: arm-linux-gnueabihf-
compilergcc
linker gcc
assembler as
include /usr/arm-linux-gnueabihf/include
libraries /usr/arm-linux-gnueabihf/lib
hello.cpp search paths:
Cross-tools path: /usr/bin
tools prefix: arm-linux-gnueabihf-
compilercpp
linker cpp
assembler as
include /usr/arm-linux-gnueabihf/include
libraries /usr/arm-linux-gnueabihf/lib
Build Output (-v):
21:14:27 **** Build of configuration Debug for project rockchip_hello ****
make all
Building file: ../src/rockchip_hello.cpp
Invoking: Cross G++ Compiler
arm-linux-gnueabihf-cpp -I/usr/arm-linux-gnueabihf/include -O0 -g3 -Wall
-fmessage-length=0 -print-prog-name=cc1plus -v -MMD -MP
-MF"src/rockchip_hello.d" -MT"src/rockchip_hello.d" -o
"src/rockchip_hello.o" "../src/rockchip_hello.cpp"
Using built-in specs.
cc1plus
COLLECT_GCC=arm-linux-gnueabihf-cpp
Finished building: ../src/rockchip_hello.cpp
Building target: rockchip_hello
Invoking: Cross G++ Linker
arm-linux-gnueabihf-cpp -L/usr/arm-linux-gnueabihf/lib -o
"rockchip_hello" ./src/rockchip_hello.o
arm-linux-gnueabihf-cpp: error: ./src/rockchip_hello.o: No such file or
directory
arm-linux-gnueabihf-cpp: warning: ‘-x c’ after last input file has no effect
arm-linux-gnueabihf-cpp: fatal error: no input files
compilation terminated.
make: *** [rockchip_hello] Error 4
21:14:27 Build Finished (took 65ms)
Hi folks,
As a heads-up, there's a long standing bug in the way Firefox handles
register assignment in XPCOM for 32-bit ARM:
https://bugzilla.mozilla.org/show_bug.cgi?id=1050258
The symptoms are random data corruption and crashes.
(details of bug and fix in the link above).
Whilst upstream go through the motions of getting this fix merged, I
would encourage you to pull in the fix for now into your packages (or
at least keep an eye on this bug report).
Cheers,
--
Steve
